Привет! Меня зовут Сергей, я начинающий аналитик на Второй линии SOC. Команды нашего Отдела SOC каждый день разбирают сработки правил корреляции и разрабатывают эти самые правила, а также поддерживают технические инструменты, которые мы используем. Одна из наших задач — разработать точную логику детектирования для обеспечения качественного мониторинга состояния защищённости корпоративной вычислительной сети, а также подготовить понятную инструкцию по реагированию, чтобы в итоге без проблем передать обработку алертов на Первую линию SOC для дальнейшего разбора возникающих сработок.

И тут стоит подчеркнуть, что детект должен быть достаточно хорошим и в идеале не занимать весь капаситет L1 SOC ложными сработками. Первая линия организует непрерывный мониторинг состояния защищённости корпоративной вычислительной сети совершенно разными способами, о чём можно прочитать в статье моей коллеги Как измерить то, чего не видно: метрики SOC.

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

Базовая проблема Security Operations Center

Я думаю, что каждый аналитик SOC сталкивался с такой проблемой: потратил время на разработку правила, а оно создаёт детект False Positive. Получил задачу на разработку правила корреляции, которое должно со стопроцентной вероятностью ловить хакеров детектировать отклонение системы от базового и нормализованного состояния. Далее написал само правило, кое‑как потестировал и с мыслями «ну находит оно грубый перебор, и отлично» выпустил его на службу безопасности. А через пару недель Первая линия SOC потратила очень много времени на разбор 200 ложноположительных сработок и при этом не нашла ни одной релевантной аномалии. Именно поэтому в настоящих инфраструктурах всё намного сложнее, и требуется более точный и вымеренный подход к разработке правил, что далеко не всегда соблюдается. Очень часто некачественную разработку правила можно представить схемой ниже.

Почему же всё‑таки возникают ложные срабатывания?

Для начала определимся с терминологией. False Positive (FP) — это срабатывание, при котором правило указывает на искомую угрозу из‑за ошибки в логике, данных или условиях корреляции, хотя соответствующей вредоносной активности фактически не было. Отдельно мы выделяем Legitimate True Positive (LTP) — правило корректно обнаружило заданную активность, однако сама активность оказалась легитимной. Оба типа срабатываний требуют времени аналитиков на разбор, внесение исключений и поиск ошибки в правиле, чтобы понять, почему оно сработало на ложную или легитимную активность, поэтому при разработке правила важно учитывать их заранее.

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

Кроме того, проблемы могут возникнуть на стадии разработки самого правила, а именно из‑за недостаточности покрытия его тестами. Аналитик далеко не всегда заранее учитывает легитимную активность. Например, правило создано, чтобы отлавливать сканирование сети, и, казалось бы, что тут может пойти не так? А после релиза узнаётся, что какой‑нибудь сетевой инженер несколько раз в месяц производит сканирование подсетей для сбора статистики по задаче. И узнаётся это Первой линией SOC, которая может принять такую активность за что‑то страшное и подозрительное. Именно поэтому одного работающего запроса в SIEM недостаточно, а нужно учесть все потенциально возможные кейсы, которые правило способно обнаружить.

На данном моменте многие скажут, что зачастую времени, которое даётся на разработку правила, критически не хватает на покрытие его таким количеством тестов. Попросту не все готовы ждать неделю‑две, чтобы правило поймало несколько аномалий и причины этих аномалий были разобраны. Именно поэтому в команде появился процесс разработки правил безопасности. 

Критикуешь? Предлагай!

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

Сам этап разработки мы делим на 5 важных этапов:

• [Backlog] Осознать задачу и оценить возможность и необходимость её реализации.

• [Analysis] Провести предварительный анализ для реализации мониторинга.

• [Implementation] Реализовать мониторинг и вывести его в test.

• [Testing] Тестировать правила корреляции.

• [Approving] Согласовать правило с командой, которая будет разбирать сработки, и выполнить релиз правила в prod.

Backlog

Казалось бы, почему нельзя просто начать писать правило по заданному ТЗ? На самом деле стоит подробнее изучить задачу и собрать дополнительный контекст. На этом этапе разработчик‑аналитик правила уясняет задачу и продумывает реагирование. Аналитик может посоветоваться с коллегами о том, стоит ли реализовывать мониторинг в принципе, а также в чём заключается его ценность, так как понимание цели мониторинга является ключом к разгадке всего остального: к формированию плейбука, внесению исключений и даже критериев эскалации!

Бывает, что мы даже отменяем задачи, если понимаем, что описанная задача не подходит под мониторинг безопасности или такая активность покрывается другими правилами или иными СЗИ. Например, до настройки различных сканеров безопасности наш SOC писал правила на эксплуатацию некоторых известных и критичных уязвимостей с эксплойтами в публичном доступе. Однако, как только смежная команда настроила процесс регулярных сканирований, мы решили отключить правила на обнаружение потенциальной эксплуатации CVE_2023_36884, так как при появлении хоста с уязвимой ОС, сканер «увидит» такую уязвимость и будет просить владельцев скорее обновиться. Из отменённых мониторингов у нас есть детектирование подключения BadUSB, так как USB захарденены.

Analysis

На данном этапе разработчик проводит предварительный анализ для реализации мониторинга, в том числе оценивает качество и наличие необходимых источников событий. 

Задача становится труднее, если необходимые события вовсе отсутствуют не поступают в SIEM (конечно же, все события для мониторингов мы достаём именно оттуда): требуется проанализировать, каким образом можно подключить желанные события. Бывает же, чтобы необходимые события поступают не со всех серверов, в таком случае качество мониторинга тоже будет падать, потому что попросту не сможет увидеть активность с тех активов, которые не присылают логи. Путей несколько: расширение покрытия логами всех необходимых серверов, изменение файла конфигурации Sysmon, добавление нового EventCode в собираемые события WinEventLog или вежливый намёк разработчикам сервиса о том, что стоит подключить аудит‑логи сервиса для реализации мониторинга безопасности (да‑да, это тот момент, когда в жизни рядового айтишника появляется ИБ и просит его о чём‑то). В таком случае мы добиваемся поставки логов, оцениваем их полноту и достаточность, а после — нормализуем.

Если же логи всё же есть, но их качество плохое — например, событие записано сплошным текстом без каких‑либо разделителей или сама предоставляемая информация не является исчерпывающей, — то качество мониторинга также быстро падает:

• аналитик Второй линии дольше разбирается в смысле событий и их формате;

• этап разработки правила корреляции занимает больше времени;

• этап разработки плейбука для реагирования тоже занимает больше времени.

Implementation

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

— Написание запроса в SIEM, которое будет искать отклонение информационной системы от нормы.

За норму мы обычно принимаем состояние системы, в котором отсутствуют признаки компрометации и иные нехарактерные процессы. При этом выявление отклонений не ограничивается контролем пороговых значений: правила корреляции могут обнаруживать аномальное поведение, известные паттерны атак, несоответствия документации и подозрительные последовательности событий. Наиболее очевидный пример — установка Cobalt Strike на сервер, которая практически всегда указывает на потенциальную угрозу. Гораздо сложнее выявлять атаки среди легитимной активности; например, PsExec активно используется администраторами, но в руках злоумышленника может стать инструментом для удалённого выполнения команд и развития атаки.

На этапе написания запроса в SIEM аналитик уже может оценить потенциальные сработки, проанализировать их на наличие TP/FP, а также продумать возможные исключения, так как каждое почти каждое правило будет формировать легитимные сработки, разбирать которые — трата человеческого ресурса. Ну и кто‑то же должен думать о Первой линии SOC!

— Заполнение файла.yml в CatZone (узнать больше про нашу систему можно из данной статьи).

В данном манифесте.yml описано почти всё. Гибкая настройка правила даёт возможность менять его поведение, цель, а также сохранять историчность его изменений.

Testing

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

Я считаю, что именно этот шаг в разработке правила является критическим, так как помогает проверить детект на корректность:

• логику — запрос ищет то, что нужно, отсутствуют FN‑события;

• реализацию — запускается по ожидаемому расписанию, не присутствуют повторные сработки aka дубли, поля наполнены и наполнены ожидаемыми значениями;

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

При необходимости автор должен внести улучшения в правило, чтобы добиться максимального процента TP‑сработок, а также качества правила в целом.

Что ещё интересного? Автор может создавать искусственные сработки (об этом немного далее) для оценки качества мониторинга безопасности, что положительно скажется на следующем этапе. Конечно, никто не даст аналитику реплицировать домен или дампить локальный lsass, однако что‑то безобидное и простое всегда можно воспроизвести.

Приведу настоящий пример выполнения данного шага при разработке правила. Как грамотно протестировать работоспособность мониторинга безопасности, который намерен детектировать скрытие запланированной задачи в Windows? Конечно же, специально скрыть несколько запланированных задач несколькими способами и посмотреть, среагирует ли правило. Если учётная запись, от имени которой мы работает, состоит в группе локальных администраторов, то можно запустить PsExec и поменять несколько значений в реестре, чтобы скрыть задачу из планировщика. После удавшейся пакости подготовки искусственных событий для тестовой сработки остаётся только ждать её.

Кроме того, могут прийти алерты вовсе не на нашу активность, и их тоже нужно разбирать, потому что по мере разбора можно набрать вагон и маленькую тележку сработок, которые необходимо исключить, так как активность является легитимной. Если возвращаться к примеру из абзаца выше, то иногда при ручном обновлении Windows Security Descriptor некоторых запланированных задач легитимно и ожидаемо меняется, так что подобную активность точно не следует оставлять в сработках для prod правила.

Approving

Ну вот и всё! Пора выпускать правило в prod (ну только сначала пройти ревью) и передавать разбор сработок мониторинга безопасности на Первую линию SOC. Для этого автор правила создаёт Merge Request в Catzone с изменением статуса правила (заветный prod), и дальше ему нужно:

• Подготовить статистику по сработкам со дня последнего пересмотра: за период было N детектов, Y закрыто с такими‑то тегами.

• Выяснить, были ли искомые события созданы искусственно или произошли без лап автора.

• Оставить ссылку на одну (или несколько) сработок.

• Оставить один или несколько примеров для доказательства работоспособности поиска в SIEM.

• Составить понятное описание правила для ревьюеров, в том числе представителей Первой линии SOC.

Обычно далее следуют закономерные вопросы от ревьюеров (обычно руководителей Первой и Второй линии SOC) и последующие на них ответы, исправления в манифесте.yml, если замечания валидны. После того как все мнения выслушаны и все нюансы учтены, изменения принимаются и вносятся в main‑ветку репозитория. Вуаля! Правило доблестно служит мониторингу состояния защищённости корпоративной вычислительной сети.

Жизнь после релиза

Вывод правила в промышленную среду не завершает работу над ним. После релиза правило продолжает развиваться: мы анализируем его срабатывания, устраняем ошибки, уточняем логику и следим за тем, чтобы оно сохраняло ценность для мониторинга.

Одним из основных процессов является работа с исключениями. Специалисты Первой линии категоризируют сработки и добавляют исключения для легитимной активности, а разработчики правил проверяют данные изменения и регулярно пересматривают их. Исключения в первую очередь помогают сократить количество легитимных положительных срабатываний (LTP), но могут устранять и часть ложноположительных результатов (FP). При этом важно формулировать их достаточно узко, чтобы вместе с шумом не исключить реальную атаку и не увеличить риск появления FN‑результатов.

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

Отдельное направление работы — пересмотр legacy‑контента. Устаревшие правила необходимо периодически проверять на соответствие текущей инфраструктуре, моделям угроз и доступным данным. По результатам такого пересмотра правило может быть доработано, полностью переработано, объединено с другим правилом в одно более универсальное или выключено.

Качество правила также отражается с помощью метрики confidence. Она показывает, насколько мы уверены в корректности логики правила и точности срабатываний. Метрика меняется по мере накопления статистики и может расти и уменьшаться.

Также после релиза мы следим за метриками детектирования: количеством и динамикой срабатываний, долей FP и LTP, результатами обработки алертов и резкими отклонениями от привычного уровня. Всплеск срабатываний может быть связан как с реальной атакой, так и с изменением инфраструктуры, источника событий или поведения пользователей.

Если правило создаёт слишком много FP, мы последовательно проверяем качество и полноту данных, условия корреляции, пороги, временные окна и область действия правила. Кроме того, большое количество FP‑сработок может быть вызвано неверной логикой suppress, которая также требует исправления. После этого логику можно уточнить, разделить на несколько сценариев или дополнить точечными исключениями. Каждое изменение необходимо протестировать на исторических и тестовых данных, чтобы уменьшение шума не привело к пропуску атак.

Таким образом, после релиза правило может быть:

• дополнено исключениями;

• исправлено или доработано;

• пересмотрено на основании метрик;

• полностью переработано;

• объединено с другим правилом;

• выключено как устаревшее или утратившее ценность.

Изменение правила через MR

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

Чтобы ревьюер мог оценить изменение не только по коду, в описании MR разработчик объясняет его причину, прикладывает примеры результатов поиска в SIEM и показывает влияние новой логики на статистику срабатываний. Сравнение показателей до и после изменения помогает понять, действительно ли доработка уменьшает шум и сохраняет необходимую полноту детектирования.

Во время ревью более опытный коллега со Второй линии SOC проверяет корректность запроса, область действия правила, пороги, временные окна и исключения. Особое внимание уделяется тому, не стало ли условие слишком широким или, напротив, настолько узким, что часть вредоносной активности больше не будет обнаруживаться. Таким образом, MR становится не формальным этапом согласования, а способом независимо проверить качество детекта.

Отключение правила проходит по тому же принципу. В MR фиксируется причина отключения и, если проблема должна быть устранена, указывается задача на восстановление или переработку правила. Благодаря этому решение остаётся прозрачным, а временно отключённый детект не теряется среди других изменений.

Приведу пример выключенного впоследствии правила корреляции. Довольно долго мы в нашем парке правил держали такое, которое детектировало инструмент под названием Ruler для проведения различных атак, направленных на почтовые серверы. Без знания данных учётной записи пользователя злоумышленник мог только выполнять брутфорс, на что написан отдельный мониторинг, а само использование инструмента мы закрыли довольно большим правилом на вредоносные команды на серверах с ОС Windows. 

Финал

На этом жизненный цикл правила продолжается. Инфраструктура меняется, появляются новые легитимные сценарии, обновляются источники данных и способы атак. Вместе с этим меняются и сами правила. В них появляются новые исключения, дорабатывается логика, а какие‑то детекты со временем просто перестают быть актуальными.

Главная задача всей этой работы заключается в том, чтобы сработки правила оставались полезными. Чем точнее работает правило, тем меньше времени Первая линия SOC тратит на разбор лишних алертов и тем быстрее аналитики могут сосредоточиться на событиях, которые действительно требуют внимания.