Сущности в MDR

Есть много чем поделиться по части Detection engineering-а, однако, для обеспечения одинакового понимания требуются некоторые пояснения, которые я решил вынести в отдельную статью, эту статью, и здесь мы поговорим о том, чем мы оперируем в MDR - о событиях (или "сырых событиях"), алертах (по-русски в формальной литературе мы это называем "события безопасности") и инцидентах (иногда мы также используем американизм "кейс", в отличие от "инцидента", кейс не был опубликован заказчику).

События, "сырые события", "события телеметрии" или "телеметрия" - это минимальные сущности, которые прилетают от сенсоров, например, сенсоров EPP/EDR или NTA/NFT. Событие отражает какое-то действие, происходящее в системе. В событии надо соблюсти баланс между его низкоуровневостью, чтобы иметь возможность обнаружить активность с как можно большим контекстом (детализация также повысит шансы обнаружения и предоставит больше информации аналитику при расследовании), и, в то же время, хочется, чтобы событий было немного, иначе ими будет невозможно сложно управлять. Идеи событий возникают в процессе исследования угроз и придумывания логики обнаружения: мы решаем что нам надо обнаружить, а затем понимаем какие сырые события нам нужны, чтобы сделать детект. Мы стремимся не собирать события "впрок", поэтому за каждым событием скрыта какая-то история с конкретной целью сбора (как правило, это либо чтобы построить детект, либо, чтобы иметь возможность его расследовать - достоверно понять, фолса ли он или следствие реального инцидента).

Сырые события обогащаются всевозможным Threat intelligence (например) и, далее, на их основе формируются алерты. На данный момент, грубо мы различаем алерты двух типов: "простые" и "сложные". Простые - сделанные на базе одного события, Сложные - результат корреляции нескольких событий, стандартный продукт типового SIEM. Часто используемый нами американизм "хант" (hunt, от "threat hunting") представляет собой запрос, позволяющий найти сырые события, отражающие определенные действия атакующего, а найденные запросом события помечались именем этого ханта. Но с появлением сложной корреляции, наши некоторые коллеги корреляционные правила SIEM также называют "хантами" или "сложными хантами". Ханты в нашем случае связаны с техниками MITRE, поэтому обогащение\разметка событий хантами представляет собой одновременную разметку событий техниками и тактиками MITRE. Благодаря этой связи событие -> хант -> техника и тактика в наших отчетах MDR мы можем строить аналитику по популярным (имеющим хороший вклад) и менее фолсящим (имеющим хорошую конверсию) техникам MITRE ATT&CK.

Размеченные хантами события далее либо поднимаются в алерты, либо остаются просто обогащенными событиями, используемыми при расследовании других алертов. Внутри мы используем жаргонизм "проваливать событие в алерт". Критерием "проваливания" в алерт является конверсия ханта на лабораторных и исторических данных. Итак, алерт - это результат автоматического анализа сырых событий всевозможной детектирующей логикой. Алерт - это то, что прилетает в IRP/SOAR аналитикам SOC на расследование. Алерт содержит события, совокупность полей которых попала под условия формирования алерта.

Получив Алерт, аналитик сначала пытается его расследовать исключительно по данным, представленным в самом алерте. Для этого аналитик из алерта может провалиться в SIEM и посмотреть события в окрестности алерта и решить, например, что это ложное срабатывание и закрыть тему (соответственно, надо в перспективе позаниматься фильтрацией). Если по алерту не понятно и требуется подергать анализаторы, или сразу ясно, что это инцидент и надо формлять карточку инцидента заказчику - алерт импортируется в кейс. Опубликованный для заказчика кейс, как уже упоминали ранее, мы называем инцидентом. В соответствии с внутренними инструкциями аналитик должен найти все релевантные инциденту алерты и сырые события и связать (внутри мы используем американизм "слинковать") их с данным кейсом. Связывать релевантные алерты с кейсом важно, поскольку хант считается несконвертировавшимся, если он разметил событие в составе алерта, не связанного с опубликованным для заказчика кейсом (инцидентом) - это влияет на корректный подсчет конверсии ханта, что, в свою очередь, влияет на оценку его качества и качества детектирующей логики вообще. Также важно связывать с реальными инцидентами сырые события, не размеченные хантами - в нашей инфраструктуре это будет выглядеть как алерт по событию, не размеченному хантом - анализ таких событий позволит найти возможные идеи для новых хантов, хотя бы, сначала, для разметки, без проваливания в алерт.

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