Threat Hunting многоликий

В этой заметке продолжу знакомить с некоторыми "нестандартными" процессами нашего SOC. Цель подобных публикаций - рассказать о практиках, которые действительно работают, и которые не часто можно встретить в академической литературе. Ранее я писал об организации Второй линии, а сегодня коснемся одной из множества задач этой команды.

TH - со времен первой публикации на русском языке, уже звучит как заезженный термин, тем более, что со времен первых упоминаний этого словосочетания, накопился внушительный объем материала и здесь едва ли можно что-то открыть с технической точки зрения, поэтому поговорим о процессах.

В нашем SOC TH используется обеими командами: командой исследований - для инженеринга детектирующей логики, командой мониторинга - для обнаружения атак.

Команда исследований и разработки (aka SOC R&D) - классическая "фиолетовая команда", отвечающая за развитие технологий обнаружения: поставщики телеметрии, события телеметрии и поля этих событий, обработка телеметрии - обогащение, разметка, корреляция, плейбуки и ранбуки для команды мониторинга на сгенеренные на базе всего этого конвейера обработки сырых событий телеметрии алерты. В процессе разработки, отладки и поддержки детектирующих правил команда SOC R&D тестирует правила обнаружения на реальных данных и, вполне себе часто, обнаруживает инциденты. Последовательность действий здесь ровно в соответствии с книжками - выработка гипотезы - придумывание поискового запроса к сырой телеметрии - получение результата - анализ результата - корректировка гипотезы и т.п. Это - один сценарий TH, "побочный продукт" исследований и разработки.

Проблема в том, что не все гипотезы можно превратить в хорошие алерты, генерящие разумное количество ложных срабатываний (см слайд FN против FP здесь), поэтому есть рабочие гипотезы, которые, в целом, находят атаки, но автоматизировать их пока нельзя (может быть масса причин: хант находится в отладке, пока нет необходимых полей событий телеметрии, пока нет необходимых обогащений и\или обработки в конвейере или\и на сенсоре и т.п.). Такие гипотезы прикапываются в базе знаний и используются в рамках специального процесса, выполняемого уже группой операционного мониторинга, аналитиками второй линии. В результате этой методичной проверки вручную пока еще не трансформированных в алерты гипотез, во-первых, находятся инциденты, а, во-вторых, проводится отладка, собирается статистика срабатываний и т.п. для потенциальных новых детектирущих правил. Здесь тот же классический TH, но уже с непосредственной целью обнаружения атак, а вот вклад в инжениринг новых детекторов - здесь "побочный продукт".

Следует отметить, что база знаний запросов TH постоянно изменяется: добавляются новые гипотезы, отлаженные и доработанные - переводятся в алерты, бывает и наоборот: какой-либо детектор декомпозируется и "более точная" его часть остается в виде алерта, а "наиболее глючная" - фиксируется в базе знаний для ручного ТН с рамках процесса второй линии операционной группы.