Сегодня делал 15-и минутный доклад посвещенный атакам, основанным на штатном функционале легальных инструментов, в секции "Конвергенция последней линии защиты или единственно нужная защита?". Несмотря на то, что тема предвещает сложный контент, презентация была совсем нетехническая, однако, лично у меня все равно сложилось впечатление, что доклад был не формат и следовало бы рассказать про какие-то еще более концептуальные вещи.
Выкладываю презентацию.
Времени было 15 минут, а рассказать хотелось о многом, поэтому говорил быстро. Вполне возможно, что что-то не отложилось на слух, поэтому привожу в этом посте кратко драфт скрипта к слайдам.
О чем речь?
Инфраструктура первый эшелон
Анатомия современной таки
Инфраструктура
Мотивация
Некоторые примеры нестандартного использования
Некоторые примеры стандартного использования
За что зацепиться ђ Детекты/Ханты, Алерты
Конверсия детектов/хантов = NTP/(NTP + NFP)%
Приложения и Бизнес-процессы
Использование легальных возможностей приложений
Атаки на бизнес-процессы ([лайф-хакиk с оттенками грязи)
Что делать?
Эпилог 1(2). Безопасность это компромисс
Эпилог 2(2). Комбинируй эшелоны
Из зала был один вопрос: "Где в вашем докладе про конвергенцию? Тема нашей секции "Конвергенция последней линии...". Этот же вопрос потом повторился еще к одному докладчику, я решил, что это - критерий неформатности доклада, поскольку остальным спикерам такой вопрос не задавался, полагаю, в их докладах было как раз про конвергенцию. С нетерпением жду записи всех докладов, чтобы повнимательнее ознакомиться с материалом.
Я попытался ответить на этот вопрос, но, по-моему, спрашивающий не был удовлетворен. Что ж, давайте попробуем разобраться здесь, и, если среди читающих мои заметки, есть автор вопроса, надеюсь, мой ответ устроит.
По определению: Конвергенция - это объединение, сближение, схождение. В докладе я рассказывал о том, как на разных уровнях абстракции (инфраструктуре, приложении, бизнес-процессах) мы имеем объекты, объединяющие в себе функционал различного назначения в зависимости от контекста - одна и та же утилита операционной системы, или функция приложения, или свойство бизнес-процесса может нести в себе в одних условиях - желаемое благо (хорошо), а в других - недопустимый ущерб (плохо). Нож - хорошо для нарезки хлеба, но плохо, что им можно убить; вообще, любое оружие - это хорошо для защиты, но плохо, что с его использованием можно совершать преступления. SSO - это хорошо для удобства, но плохо, так как неизбежно приводит к доступности аутентификационных данных из памяти. Программы лояльности - это хорошо, так как это позаоляет привлекать клиентов, но плохо, так как с ними можно придумать много схем мошенничества и, связанные с этим риски, придется как-то адресовать.... В общем, думаю понятно.
Выкладываю презентацию.
Времени было 15 минут, а рассказать хотелось о многом, поэтому говорил быстро. Вполне возможно, что что-то не отложилось на слух, поэтому привожу в этом посте кратко драфт скрипта к слайдам.
О чем речь?
В моей презентации я расскажу, что возможность эксплуатации неизбежное следствие функционала, что уязвимости бизнес-логики существуют на всех уровнях модели OSI. Для обнаружения таких атак требуется экспертиза в бизнес-процессах и такая экспертиза плохо аутсорсится, так как никто не знает наши бизнес-процессы лучше нас самих.
Инфраструктура первый эшелон
Любое приложение имеет аутентификацию и авторизацию, что является инфраструктурными функциями, а любая атака это неавторизованный доступ. Поэтому первый эшелон преодоления для атакующего инфраструктурный.
Анатомия современной таки
Если рассмотреть анатомию современной атаки, то можно сделать следующие выводы.
- Использование специальных инструментов (будем дальше их называть "вредоносное ПО"), если и требуется, то только на этапах компрометации и закрепления. После компрометации и закрепления в сети, как правило, достижение целей выполняется полностью с использованием легальных инструментов: используются учетные записи реальных пользователей, имеющиеся в корпорации системы удаленного доступа и т.п.
- Как мы отметили ранее первый эшелон инфраструктура, поэтому применение специализированных инструментов для взлома, характерно именно для инфраструктурных компонент системы.
- Поскольку после закрепления атакующий использует легитимные инструменты, вероятность его обнаружения резко снижается со временем. Практика показывает, что чем дольше атака остается незамеченной в системе, тем сложнее от нее потом избавитьсяпочиститься.
Инфраструктура
Рассмотрим более детально, что творится в инфраструктуре
Мотивация
Как показывает практика, на уровне инфраструктуры тоже можно обойтись без аномалий и вредоносного ПО. На слайде представлена ссылка на выступление от 2013 года, демонстрирующее подход "Living off the land" выполнение вредоносных действий без использования вредоносного ПО и генерации аномалий. Мотивация понятна: оставаться как можно дольше незамеченным (мы помним, что чем дольше атакующий сидит в инфраструктуре, тем сложнее его оттуда вычистить), во-вторых, не надо тащить с собой инструменты, что само по себе может и не получиться сделать незаметно.
Некоторые примеры нестандартного использования
Здесь, во-первых, на помощь приходят возможности альтернативного использования штатных утилит операционной системы. В целом, такое использование нестандартно, и это может быть подозрительной аномалией.
Некоторые примеры стандартного использования
Однако, если посмотреть на инструменты, которые можно применять для вредоносных целей, не выходя за рамки их типового использования их гораздо больше! Если на это использование делать детекты, то ложных срабатываний будет очень и очень много.
За что зацепиться ђ Детекты/Ханты, Алерты
Чтобы сделать детекты на различные варианты использования легальных утилит в первую очередь нам нужны события сенсоров. Некоторые из них получить несложно, некоторые требуют ресурсоемкой разработки.
Во-вторых, нужно как-то обеспечивать и контролировать полноту покрытия всех возможных техник нашими детекторами.
В-третьих, нам нужна инфраструктура, способная эффективно обработать собираемые данные. И здесь обязательно встанет вопрос оптимизации.
Ну и, конечно, чтобы понимать какие данные собирать и как их обрабатывать, чтобы обеспечить достойное покрытие, нам нужны исследования. Только исследования, как операционный процесс, позволят обеспечивать стабильно хорошее качество обнаружения.
Конверсия детектов/хантов = NTP/(NTP + NFP)%
Если говорить о поиске и обнаружении атак, основанных на использовании только легальных инструментов, то неизбежен высокий процент ложных срабатываний для детекторов. Для управления ложными срабатываниями хорошей метрикой является конверсия детекта, выраженная в процентах. На основании ее можно определять
- приоритет взятия детектов в работу,
- порядок использования (алерт, который сразу надо расследовать; разметка событий, на которые надо обратить внимание или как обогащение для событий, требующих рассмотрения в совокупности с другими событиями пример разбивки приведен на слайде)
- ну и, конечно, метрика показывает эффективность детекта можно сразу определять неэффективные и дорабатывать их.
Приложения и Бизнес-процессы
С инфраструктурой, вкратце, понятно. Перейдем на уровень бизнес-процессов и приложений, их автоматизирующих.
Использование легальных возможностей приложений
На уровне приложений также полно функциональных особенностей, позволяющих атакующему их использовать в своих вредоносных целях. Вот лишь несколько примеров, исключительно для понимания.
Лидером, безусловно, является SSO, поскольку благодаря этому чудесному механизму аутентификационные данные (пароли, хеши, билеты Kerberos) хранятся в памяти и их можно оттуда извлекать и в дальнейшем использовать во своему усмотрению.
Следующий пример субъект, не имеющий сам прав, но имеющий права на назначение прав. Ярким примером здесь является Агент регистрации УЦ (Enrolment agent), который, как правило, не является админом в домене, но может зарегистрировать в УЦ (Enrol) сертификат для учетной записи админа и аутентифицироваться им. Ну и банально, если мы говорим о ERP, например, SAP, то данные, хранящиеся в приложении могут увидеть: админы базиса SAP если прав нет, могут себе легко дать, админы СУБД прямо в таблицах базы (в SAP есть функционал шифрования данных в базе, но я не видел, чтобы так кто-то делал), админы ОС, которые могут увидеть данные СУБД.
Третий пример про обфускацию данных она никогда не работает, всегда по косвенным признакам можно догадаться чей профиль мы смотрим.
Четвертый пример про DLP: если я имею доступ к данным, я могу их тиражировать: могу их запомнить, сфотографировать телефоном, переписать ручкой не важно, я всегда могу унести эти данные с собой.
Последний очевидный пример про накручивание счетчиков. Сайт определяет меня по моей локальной конфигурации, которой я полностью управляю. Здесь проблема в логике и это можно эксплуатировать.
Атаки на бизнес-процессы ([лайф-хакиk с оттенками грязи)
Но поднимемся еще выше - на уровень взаимоотношений между людьми, то, что наши приложения автоматизируют. Здесь тоже полно логических ошибок, позволяющих обходить различные ограничения. Я резко отрицательно отношусь к этим [лайф-хакиk, порой, попросту мошенничеству. Но, тем не менее, если занимается безопасностью бизнес-процессов, то схемы мошенничества надо очень хорошо знать, чтобы понимать как их можно обнаруживать и предотвращать, отслеживать на уровне каких-либо логов приложений или инфраструктуры.
Итак, есть лоукостеры, которые предлагают весьма выгодные условия перелета, при условии отсутствия багажа. С учетом того, что ручная кладь может достигать 10 кг, а вес чемодана не должен превышать 23 килограмма, получаем, что семья из шести человек в ручной клади может провести багажа на 3 чемодана, что по вещам вполне достаточно на две недели.
Раньше в электричках билеты продавались по тарифным зонам. Например, покупаете билет из пятой зоны до Москвы и обратно. Это позволяло весь день ездить по всем направлениям в пределах пятой зоны, так как не станция, до которой ехать и сколько раз можно проехать нигде не уточнялось.
Что касается схем мошенничества, то их великое множество. На слайде я привел два, скорее, классы, чем конкретные сценарии: карты лояльности и компенсацию расходов по чекам.
Что делать?
Ответ на вопрос что делать очевиден. Понять свои бизнес-процессы исследовать схемы атак придумать контроли построить операционные сервисы управлениям придуманными контролями анализ метрик этих сервисов позволит совершенствовать весь процесс.
Эпилог 1(2). Безопасность это компромисс
В завершении, высокоуровнево, хочу отметить, что атаки на бизнес-логику, с использованием штатных возможностей легальных компонентов следствие широкой функциональности приложений, что, в свою очередь, следствие высоких бизнес-требований. Мы сами постоянно хотим гибкости, широких возможностей, чтобы все можно было конфигурировать получайте за одно и возможности по эксплуатации.
Эпилог 2(2). Комбинируй эшелоны
Обнаруживать такого рода эксплуатации позволит все тот же эшелонированный подход из контролей на уровне инфраструктуры, приложений, бизнес-процессов и разумная комбинация аутсорсинга и работы внутренних подразделений.
Из зала был один вопрос: "Где в вашем докладе про конвергенцию? Тема нашей секции "Конвергенция последней линии...". Этот же вопрос потом повторился еще к одному докладчику, я решил, что это - критерий неформатности доклада, поскольку остальным спикерам такой вопрос не задавался, полагаю, в их докладах было как раз про конвергенцию. С нетерпением жду записи всех докладов, чтобы повнимательнее ознакомиться с материалом.
Я попытался ответить на этот вопрос, но, по-моему, спрашивающий не был удовлетворен. Что ж, давайте попробуем разобраться здесь, и, если среди читающих мои заметки, есть автор вопроса, надеюсь, мой ответ устроит.
По определению: Конвергенция - это объединение, сближение, схождение. В докладе я рассказывал о том, как на разных уровнях абстракции (инфраструктуре, приложении, бизнес-процессах) мы имеем объекты, объединяющие в себе функционал различного назначения в зависимости от контекста - одна и та же утилита операционной системы, или функция приложения, или свойство бизнес-процесса может нести в себе в одних условиях - желаемое благо (хорошо), а в других - недопустимый ущерб (плохо). Нож - хорошо для нарезки хлеба, но плохо, что им можно убить; вообще, любое оружие - это хорошо для защиты, но плохо, что с его использованием можно совершать преступления. SSO - это хорошо для удобства, но плохо, так как неизбежно приводит к доступности аутентификационных данных из памяти. Программы лояльности - это хорошо, так как это позаоляет привлекать клиентов, но плохо, так как с ними можно придумать много схем мошенничества и, связанные с этим риски, придется как-то адресовать.... В общем, думаю понятно.
