Как мы снижаем количество ложных срабатываний в мониторинге безопасности
Привет! Меня зовут Сергей, я начинающий аналитик второй линии SOC. Наша команда ежедневно разбирает срабатывания правил корреляции, создаёт новые детекты и поддерживает инструменты, с помощью которых контролируется защищённость корпоративной инфраструктуры.
Одна из ключевых задач SOC - разработать такую логику обнаружения угроз, которая будет одновременно чувствительной к подозрительной активности и устойчивой к ложным тревогам. Не менее важно подготовить понятную инструкцию по реагированию, чтобы после передачи правила на первую линию специалисты могли быстро классифицировать событие и принять необходимые меры.
На практике качество детекта определяется не только тем, способен ли он обнаружить атаку. Если правило генерирует сотни нерелевантных уведомлений, оно перегружает первую линию, замедляет обработку действительно опасных событий и постепенно снижает доверие к мониторингу. Поэтому борьба с ложными срабатываниями начинается ещё до написания запроса и продолжается на протяжении всего жизненного цикла правила.
Почему ложные срабатывания становятся проблемой
Представим типичный сценарий. Аналитик получает задачу создать правило, которое должно выявлять отклонение от нормального состояния системы. Он формулирует условие, проверяет его на нескольких примерах и убеждается, что детект действительно находит нужную активность. После этого правило выпускается в продуктивную среду.
Через несколько недель первая линия SOC сталкивается с сотнями уведомлений. Все они формально соответствуют условиям корреляции, но на деле связаны с обычными действиями администраторов, инженеров или пользователей. Аналитики тратят время на ручную проверку каждого события, а среди потока однотипных алертов легко пропустить настоящий инцидент.
В реальной инфраструктуре недостаточно убедиться, что запрос "работает". Необходимо понять, какие именно сценарии он обнаруживает, насколько они опасны, какие легитимные процессы выглядят аналогично и что произойдёт при изменении конфигурации источника событий.
FP и LTP: два разных типа нерелевантных срабатываний
False Positive (FP) - ложноположительное срабатывание. Правило сообщает об угрозе из-за ошибки в логике, некорректных данных или неверно заданных условий, хотя вредоносной активности не было.
Legitimate True Positive (LTP) - корректно обнаруженная, но легитимная активность. Правило действительно фиксирует описанное в его логике действие, однако выполняется оно в рамках штатного процесса.
Например, детект предназначен для выявления сетевого сканирования. Система регистрирует такое поведение, но инициатором оказывается инженер, который по регламенту проверяет подсети перед изменением сетевой конфигурации. Это не ошибка самого правила: оно правильно распознало активность. Однако для SOC такое событие всё равно означает дополнительную работу.
Причины FP и LTP различаются, поэтому требуют разных способов устранения. В первом случае нужно исправлять логику, данные или настройки источника. Во втором - уточнять контекст, добавлять исключения, учитывать владельцев систем и описывать допустимые сценарии в инструкции.
Основные источники ошибок
Ложные уведомления могут появиться из-за некорректной корреляции, слишком широких условий, неправильного выбора временного окна или отсутствия связи между несколькими событиями. Иногда проблема связана не с запросом, а с качеством данных: поля передаются в другом формате, меняется имя учётной записи, нарушается нормализация или временно недоступен один из источников.
Отдельный риск представляют списки обогащения. В них могут находиться устаревшие адреса, старые имена сервисных аккаунтов, неактуальные серверы или исключения, которые больше не соответствуют инфраструктуре. Если правило опирается на такой список, оно начинает принимать решения на основании неверного контекста.
Ещё одна распространённая причина - недостаточное тестирование. Аналитик проверяет очевидный сценарий атаки, но не моделирует действия администраторов, резервных систем, средств автоматизации, сканеров уязвимостей и сервисных учётных записей.
Жизненный цикл правила
Чтобы снизить число ложных срабатываний, мы рассматриваем разработку детекта как последовательный процесс.
1. Backlog и постановка задачи
Работа начинается с формулировки проблемы. На этом этапе важно ответить на несколько вопросов:
- какую угрозу или отклонение нужно обнаруживать;
- какие источники данных доступны;
- кто будет владельцем процесса;
- насколько критичны потенциальные последствия;
- как первая линия должна действовать после срабатывания;
- какие легитимные сценарии могут выглядеть похожим образом.
Чем точнее описана задача, тем меньше вероятность создать правило, которое формально соответствует требованиям, но не приносит практической пользы.
2. Analysis - изучение данных
До написания корреляции необходимо посмотреть, как нужные события выглядят в реальных журналах. Важно проверить названия полей, значения, формат времени, особенности нормализации и полноту данных.
Полезно анализировать не только подозрительные случаи, но и обычную активность. Именно она помогает понять, какие действия являются нормой для конкретной системы, команды или периода времени.
3. Implementation - реализация логики
На этапе разработки формируются условия детектирования, временные интервалы, связи между событиями и критерии исключений. Хорошее правило не должно быть чрезмерно общим. Если условие охватывает слишком много вариантов, количество нерелевантных срабатываний резко возрастает.
При этом чрезмерное усложнение также опасно: слишком большое число исключений может скрыть реальную атаку. Поэтому каждое исключение нужно обосновывать, документировать и регулярно пересматривать.
4. Testing - проверка сценариев
Тестирование должно включать несколько групп случаев:
- подтверждённую вредоносную активность;
- обычные действия пользователей;
- работу администраторов и инженеров;
- действия сервисных аккаунтов;
- автоматические процессы;
- неполные или некорректные события;
- пограничные значения и необычные временные интервалы.
Отдельно проверяется устойчивость правила к изменениям данных. Например, что произойдёт при смене имени узла, появлении нового контроллера домена или изменении формата записи события.
Если времени на полноценное наблюдение недостаточно, можно использовать исторические данные, воспроизведение событий и синтетические тестовые записи. Это не заменяет эксплуатационную проверку, но позволяет обнаружить часть проблем ещё до релиза.
5. Approving - согласование
Перед выпуском детект должен пройти проверку коллегами и владельцами соответствующих систем. Такой этап помогает заметить неочевидные легитимные сценарии, проверить корректность инструкции и убедиться, что исключения не создают опасных слепых зон.
В описании правила стоит фиксировать назначение, источники событий, логику, ограничения, примеры срабатываний и порядок действий первой линии. Чем понятнее документация, тем меньше времени потребуется на разбор каждого уведомления.
Что происходит после релиза
Публикация правила - не завершение работы. После включения в продуктивной среде необходимо отслеживать количество срабатываний, долю подтверждённых инцидентов, частоту повторяющихся исключений и время, которое аналитики тратят на обработку.
Если одно и то же легитимное событие возникает регулярно, это сигнал к улучшению логики. Иногда достаточно добавить атрибут контекста, например владельца системы, тип учётной записи или принадлежность IP-адреса к доверенному сегменту. В других случаях лучше разделить один общий детект на несколько специализированных правил с разным уровнем критичности.
Важно не превращать исключения в бесконечный список. Если в правило постоянно добавляются новые адреса, пользователи и процессы, вероятно, сама логика выбрана неправильно. В таком случае стоит вернуться к исходной задаче и пересмотреть модель нормального поведения.
Изменения через MR
Все изменения правила удобно проводить через merge request. Такой подход обеспечивает прозрачность и позволяет сохранить историю решений. В описании изменения следует указывать:
- какую проблему оно устраняет;
- какие события стали учитываться;
- какие исключения добавлены;
- какие риски появились;
- результаты тестирования;
- необходимость обновления инструкции для первой линии.
Проверка изменений несколькими специалистами снижает вероятность того, что временное решение или частное исключение попадёт в продуктивную среду без оценки последствий.
Как измерять результат
Снижение числа алертов само по себе не означает улучшение мониторинга. Если уведомлений стало меньше из-за слишком широких исключений, качество детектирования могло ухудшиться.
Поэтому необходимо оценивать сразу несколько показателей:
- общее количество срабатываний;
- долю FP и LTP;
- число подтверждённых инцидентов;
- среднее время анализа;
- количество повторных уведомлений;
- долю событий, переданных на дальнейшее расследование;
- время от обнаружения до изменения правила.
Полезно также отслеживать нагрузку на первую линию. Даже точный детект может стать проблемой, если его срабатывания требуют длительной ручной проверки и возникают в неудобное для команды время.
Практические принципы
Есть несколько правил, которые помогают поддерживать качество мониторинга:
1. Сначала изучать реальные данные, а затем писать корреляцию.
2. Разделять вредоносную активность, FP и легитимные совпадения.
3. Не полагаться на один признак, если его можно усилить контекстом.
4. Регулярно проверять актуальность списков обогащения.
5. Документировать каждое исключение.
6. Тестировать не только атаку, но и штатные процессы.
7. Пересматривать правило после изменений в инфраструктуре.
8. Не считать выпуск в продуктив финальной точкой.
Качественный детект - это не просто работающий запрос в SIEM. Это сочетание корректной логики, достоверных данных, понятного процесса реагирования и постоянной обратной связи от первой линии SOC. Если учитывать все эти элементы ещё на этапе постановки задачи, количество ложных срабатываний снижается, а сам мониторинг становится более полезным для обнаружения реальных угроз.