SOC без шума: как писать правила корреляции, которые работают
Правила корреляции служат мозговым центром SOC, превращая огромный поток сырых логов в управляемые, приоритизированные сигналы о реальных угрозах. Такие сигналы повышают эффективность детектирования, ускоряют реагирование и снижают нагрузку на аналитиков. Но как оценить качество правил? В статье отвечаем на этот вопрос и разбираем принципы построения детектирующей логики на нескольких примерах.
Подход к написанию правил
Что детектировать
Для начала необходимо определиться с объектом детектирования, то есть с самой атакой. Стандартом в этой области служит фреймворк MITRE ATT&CK, который описывает цепочку атаки на уровнях тактик, техник и процедур.
Тактика — верхнеуровневое описание цели конкретного этапа атаки. Например, повышение привилегий или доступ к учетным данным.
Техника — детальный способ достижения тактической цели. Например, эксплуатация уязвимостей или дамп адресного пространства процесса LSASS.exe.
Процедура — конкретный вариант реализации техники. Например, эксплуатация определенной CVE или использование конкретных функций утилиты mimikatz для кражи секретов из памяти LSASS.exe.
В идеале детектирующая логика должна быть нацелена на тактики, но из‑за того, что они слишком абстрактны, это почти невозможно. Прицел на процедуры тоже имеет минусы:
- Правила становятся «экзактовыми» (заточенными под конкретную процедуру), то есть детектируют лишь один из множества способов достижения цели атакующими. Это ведет к образованию слепых зон в мониторинге.
- Проявляется эффект «вечного второго номера». Из‑за узкой направленности правила не срабатывают на незначительно отличающиеся действия злоумышленника, что оставляет возможность только для реагирования на атаку вместо ее предотвращения.
- Поскольку процедур, требующих детектирования, очень много, количество правил чрезмерно растет. В результате усложняется управление библиотекой контента и планирование разработки новых детектов.
Поэтому в качестве цели для детектирующей логики оптимально выбирать техники. Это не всегда реализуемо, и иногда приходиться писать «экзакты», но в большинстве случаев целью должны быть техники.
- procdump;
- rundll32.exe + comsvcs.dll::MiniDump;
- Task manager;
- использование функции MiniDumpWriteDump (Win32 API);
- mimikatz, lazagne, nanodump и другие.
Как детектировать
После того как мы определились с объектом детектирования, необходимо понять, как выбрать события, на основе которых строить детект, и поля в этих событиях. Проще всего выполнить этот этап, проведя тестовую атаку в лабораторных условиях и собрав телеметрию. Многое зависит от сенсора, точнее, от того, насколько детальную информацию он предоставляет. В ряде случаев (например, если используются штатные журналы Windows) необходимые поля приходится обогащать из других событий. Скажем, имя пользователя отображается не везде. Чтобы получить его, можно найти по Logon ID в событии входа соответствующее событие 4624, где имя учетной записи указано.
При тестировании также рекомендуется варьировать способы реализации атаки: менять порядок аргументов в командной строке, расположение исполняемого файла, вызывать функции не по имени, а по ординалу и так далее. Это позволит получить более полную картину и написать правило, покрывающее несколько сценариев.
Рассмотрим три примера правил, детектирующих загрузку файлов на хост с помощью PowerShell (T1105 Ingress Tool Transfer):
Базовое «экзактовое» правило
dev_os_type: windows AND event_type: ProcessCreateWin AND proc_file_path: powershell.exe AND cmdline: Invoke-WebRequest
Расширенное правило
dev_os_type: windows
AND proc_file_path: powershell.exe
AND cmdline: (
"WebClient" OR "DownloadData" OR "DownloadDataAsync"
OR "DownloadDataTaskAsync" OR "DownloadFile" OR "DownloadFileAsync"
OR "DownloadFileTaskAsync" OR "DownloadString" OR "DownloadStringAsync" OR
"DownloadStringTaskAsync" OR "OpenReadAsync" OR "OpenReadTaskAsync"
OR "FileWebRequest" OR "FtpWebRequest" OR "HttpWebRequest" OR "WebRequest" OR
"WebRequestMethods" OR "curl" OR "wget" OR "RestMethod" OR "WinHttpRequest" OR
"WinHttp" OR "iwr" OR "irm" OR "internetExplorer.Application" OR "Msxml2.XMLHTTP"
OR "MsXml2.ServerXmlHttp"
)
Оптимальное по охвату правило
dev_os_type: windows
AND (
cmdline: ("powershell" OR "SyncAppvPublishingServer" OR "pwsh")
OR proc_file_originalfilename: "PowerShell.EXE"
OR proc_file_productname: "PowerShell Core 6"
OR proc_file_description: "Windows PowerShell"
OR event_log_source: "Microsoft-Windows-PowerShell"
OR event_log_source: PowerShell
) AND
(
cmdline: (
"WebClient" OR "DownloadData" OR "DownloadDataAsync"
OR "DownloadDataTaskAsync" OR "DownloadFile" OR "DownloadFileAsync"
OR "DownloadFileTaskAsync" OR "DownloadString" OR "DownloadStringAsync" OR
"DownloadStringTaskAsync" OR "OpenReadAsync" OR "OpenReadTaskAsync"
OR "FileWebRequest" OR "FtpWebRequest" OR "HttpWebRequest" OR "WebRequest" OR
"WebRequestMethods" OR "curl" OR "wget" OR "RestMethod" OR "WinHttpRequest" OR
"WinHttp" OR "iwr" OR "irm" OR "internetExplorer.Application" OR "Msxml2.XMLHTTP"
OR "MsXml2.ServerXmlHttp"
)
OR cmdline: (
"System.Xml.XmlDocument" OR "Excel.Application" OR "Word.Application")
AND cmdline: ( "http" OR "ftp" OR "sftp")
)
OR (
cmdline: "BitsTransfer"
AND -cmdline: "upload"
)
OR cmdline: (
"tseuqerbew" OR "tseuqerptth" OR "dohtemtser" OR "tneilCbeW" OR
"daolnwod" OR "ptthlmx" OR "2lmxsm"
)
)
Хорошее правило корреляции должно выявлять использование злоумышленником той или иной техники, даже если детали ее реализации отличаются. При этом оно не должно срабатывать на легитимную активность.
Оценка качества
Существуют качественные характеристики, по которым можно оценить, насколько правило эффективное:
- Выявляет релевантную активность — ту, вероятность встретить которую в реальных атаках достаточно высока.
- Стоимость обхода правила высока для атакующего, потому что оно нацелено на TTPs — верхние уровни «пирамиды боли» Дэвида Бьянко.
- Выявляет атаку на достаточно раннем этапе, чтобы при анализе и подтверждении инцидента сохранялась возможность остановить атаку до нанесения значительного ущерба.
- Легко читается, то есть при взгляде на его код можно быстро понять, что оно детектирует.
Однако эти характеристики довольно условны: одному сотруднику кажется так, другому — иначе. Например, правило, написанное экспертом, простое и понятное для него. Однако для аналитика L1 оно может быть неочевидным, что в лучшем случае увеличит время триажа. С ростом базы контента и команды контролировать каждое правило и поддерживать единообразие становится слишком сложно. Чтобы оценивать качество объективно, необходимы другие показатели. С этим помогают статистические характеристики.
Рассмотрим основные метрики, используемые в BI.ZONE SOC для оценки детектирующего контента:
- TP rate (true positive rate);
- INC rate (incident rate);
- количество срабатываний правила в единицу времени (например, в неделю);
- количество исключений для правила;
- количество исключений, добавленных за единицу времени (месяц, квартал);
- количество уникальных заказчиков, у которых срабатывало правило;
- количество дней, в которые фиксировались срабатывания;
- эффективность правила.
Разберем подробнее метрики, которые дают наиболее полную картину работы детектов.
TP rate рассчитается как отношение алертов, перешедших в инциденты и закрытых со статусами true positive и benign positive, к общему количеству алертов по данному правилу. Он показывает, какая доля алертов действительно является вредоносной активностью или действиями red team. Сама по себе эта метрика может служить лишь фильтром для отсеивания правил, которые слишком часто срабатывают на легитимную активность.
INC rate считается как отношение алертов, по которым были созданы инциденты, к общему числу алертов по этому правилу. Он отображает, какая доля алертов переходит в инциденты. В совокупности с TP rate эта метрика может дать много информации о правилах.
Эффективность правила считается как отношение алертов, перешедших в инциденты, закрытые как true positive и benign positive, к общему количеству TP‑ и BP‑инцидентов по всем правилам. Эта метрика подсвечивает лучшие сценарии, по которым мы чаще всего выявляем злоумышленников, и помогает приоритизировать эти правила.
Интерпретация метрик
При анализе метрик могут возникнуть различные сочетания значений, опираясь на которые можно принимать решение о доработке или отключении правила. Рассмотрим некоторые из таких сочетаний:
| Высокий TP rate | Низкий TP rate | |
|---|---|---|
| Высокий INC rate |
Такое сочетание характерно для хороших правил, которые редко срабатывают на легитимную активность пользователей, администраторов или ПО. К такому сочетанию и стоит стремиться как к целевому |
Это сочетание указывает на то, что аналитик не может самостоятельно отличить вредоносную активность от легитимной из‑за их сильной схожести в инфраструктуре или что триаж занимает чрезмерно много времени. Такие правила мы называем double meaning. Высокий INC rate говорит о частом уточнении контекста у заказчика, а низкий TP rate — о большом количестве легитимной активности (администраторов, пользователей, штатных специалистов по кибербезопасности), выявляемой правилом. Пример — правила на port forwarding с помощью SSH. Если правило срабатывает часто, то оно нуждается либо в автоматизации проверок легитимности, либо в доработке логики |
| Низкий INC rate |
Данное сочетание невозможно, поскольку каждый true‑positive‑алерт переходит в инцидент |
Эта комбинация свойственна правилам, часто срабатывающим на легитимную активность. При этом аналитик в большинстве случаев способен определить легитимность в ходе триажа. Такие правила требуют доработки логики или написания исключений. Если сработок много и отфильтровать false‑positive‑алерты невозможно, имеет смысл рассмотреть перевод правила в процесс threat hunting (при условии, что логика покрывает релевантные для этого процесса техники) |
Остальные метрики из приведенного перечня — количество срабатываний в неделю, число уникальных заказчиков, количество дней с фиксацией алертов — служат полезным контекстом при анализе. Они позволяют различать ситуации, когда правило генерировало всплеск false‑positive‑алертов в рамках одной инфраструктуры или в конкретный день. Такие всплески могут искажать общие INC rate и TP rate, поэтому их важно учитывать.
Помимо метрик и их сочетаний, на оценку качества правил влияют и другие аспекты.
Отдельного внимания засуживает количество исключений. Этот параметр может сигнализировать о том, что правило слишком широкое и его логика нуждается в обогащении дополнительными условиями.
Важно соблюдать и регулярность ревью. Каждое правило необходимо проверять хотя бы раз в год, однако на частоту и приоритет должен влиять показатель количества срабатываний. Высокие значения говорят о том, что правило создает нагрузку на дежурную смену, и в сочетании с низкими INC rate и TP rate это можно интерпретировать как работу аналитиков вхолостую. Правила с таким сочетанием характеристик необходимо пересматривать вне очереди (до истечения TTR, time to review).
Малое количество срабатываний (вплоть до отсутствия срабатываний вовсе) может говорить как о чрезмерно узкой логике правила, так и об ошибке в логике, из‑за которой оно просто не работает. Для таких правил критически важно иметь BAS‑тесты, чтобы подтверждать работоспособность даже при отсутствии срабатываний на реальной телеметрии.
Написание правил корреляции — комплексный процесс, где важен каждый этап: от выбора объекта детектирования до постанализа с опорой на метрики. Разумеется, процесс не исчерпывается описанным в статье: есть и другие шаги — например, написание и ревью исключений или качественная трансформация правила в гипотезу для threat hunting. Четко описанные и адаптированные под специфику организации (учитывающие особенности телеметрии, инфраструктуры и стека корреляции), все эти этапы обеспечивают стабильное и качественное управление детектирующим контентом.
Также делимся 29 правилами, демонстрирующими очень хорошие результаты по нашим метрикам. Они написаны для телеметрии BI.ZONE EDR, но могут быть адаптированы для использования со стандартной телеметрией Windows и Sysmon.