Инциденты с SLA-таймингами должны детектироваться с минимальным числом False Positive, а также иметь четкий workflow обработки. При таком устройстве SOC гарантирует, что инцидент будет обработан за определённое время – для дальнейшего своевременного реагирования… Такой подход многие годы был справедлив для любого SOC (и нашего в том числе). Но в какой-то момент пришло осознание, что мы частично теряем полноту картины происходящего. Причина – в тех самых объективных ограничениях, накладываемых на сценарии. Ведь во множестве малорелевантных сработок (которые не могут быть обработаны на линиях мониторинга разумными ресурсами и в рамках SLA) порой таится самая соль происходящего инцидента.



Погоня за исключением False Positive приводит к периодическому False Negative, который, как известно, случается в самый неподходящий момент. С осознанием этого факта в мир SOC пришло такое явление, как Threat Hunting, призванное усилить классический процесс по мониторингу и закрыть указанные выше недостатки.

Само понятие Threat Hunting сейчас мелькает на всех коммерческих буклетах, но вопросов и споров о том, что это и как организовать процесс проактивного поиска угроз при работе SOC, достаточно много. Даже в своей команде мы периодически любим поспорить на эту тему, и наш лагерь JSOC в этом вопросе делится на две группы:

1. Одни верят, что процесс Threat Hunting основывается на гипотезах, которые уже были выдвинуты различными исследователями или были сформированы в результате анализа работы вредоносного файла или деятельности какой-либо хакерской группировки.

2. Другие верят, что процесс Threat Hunting основывается на гипотезах, которые специалист формирует и проверяет сам в нужный момент времени.

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

Вариант 1


Сюда мы относим написанные нами правила корреляции на различные атомарные события, простые детекты, которые могут косвенно свидетельствовать о происходящем инциденте, при этом данные детекты в отрыве от контекста могут быть абсолютно малозначимы, их логически сложно профильтровать на признаки False Positive и однозначно построить вокруг них workflow для инженеров с линии не представляется возможным.

О чем же речь? Приведем примеры двух правил, чтобы понять особенности «неправильных инцидентов».

В этой категории у нас есть, например, правило, выявляющее наличие в параметрах запускаемого процесса IP-адреса или FQDN. В действительности данное правило очень сложно пропустить сквозь сито False Positive, но при этом оно достаточно эффективное при обнаружении подозрительной активности.

Или вот, например, правило, детектирующее запуск макроса при открытии Word-документа (отслеживается запись в так называемые Trusted Records Registry Key значения, содержащего последовательность FF FF FF 7F). В большой инфраструктуре такое правило будет срабатывать очень часто, но при современных объёмах фишинга с использованием технологии макросов игнорировать его нельзя.

Понятное дело, что степень «фолсовости» у этих правил разная. Поэтому для каждого из них мы прописываем (а после запуска у заказчиков динамически изменяем) некий внутренний скоринг, который, используя механизмы ретроспективного анализа, показывает вероятность «боевого» детекта. Правила с высоким скорингом в том числе попадают в ServiceDesk для подсвечивания активностей по отношению к «типовым» инцидентам.

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

Вариант 2


В данном варианте работы к аналитику, занимающемуся проактивным поиском угроз, в качестве входных данных поступают не сработки каких-либо детектирующих правил, а так называемые raw events, вокруг которых можно строить гипотезы. И уже результатом этой активности становятся задачи по разработке правил, если удалось найти действительно что-то «интересное», не покрытое текущими детектами. И снова приведем два примера.

Событие создания процесса – Event id 4688 (Sysmon id 1)

Обрабатывая и анализируя данные по всем запущенным в инфраструктуре процессам, аналитик угроз ищет подозрительные события, анализируя различную информацию. Например:

— параметры запускаемых процессов: собрать статистику, обратить внимание на самые редкие командлайны, поискать в них ключевой набор слов/фраз, поискать наличие кодировки base64;

— путь до исполняемого файла: обратить внимание на запуск из особых директорий
(например, С:\User\Public, C:\Windows\Temp, C:\Windows\Debug\wia, C:\Windows\Tracing\ — в указанные директории возможно писать и запускать исполняемые файлы, не имея прав локального администратора);

— поискать интересные взаимосвязи Parent -> Process, которые не покрыты текущими правилами детекта.

Событие создания именного канала Pipe (Sysmon id 17)

Как известно, вредоносное программное обеспечение очень часто создает именованный канал для собственного межпроцессорного взаимодействия. И зачастую именованный канал имеет определенную маску в имени и какой-то генерируемый параметр, например, Evil_090920 (Evil – маска, 090920 – генерируемый параметр). Если имя именованного канала не находится в индикаторах компрометации, то само создание данного pipe не вызовет подозрения, тем не менее аналитик может обратить внимание на то, что в определенный момент времени (или через любой интервал времени) подобные неизвестные именованные каналы создавались на нескольких системах, что может косвенно свидетельствовать о распространении вредоносного кода.



В данном посте, рассказывая о том, как мы строим процесс Threat Hunting, мы опирались на события ОС Windows и Sysmon, выступающие в качестве источника для SIEM-системы. В действительности же источник событий и конечная система (лишь бы она это позволяла) для работы по проактивному поиску угроз для аналитика значения не имеет – ровно такую же философию можно применить, например, к EDR или NTA.

Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети