Всем привет! Сегодня расскажу вам о способе определения ложноположительных алертов, который был выработан совместно с коллегой по цеху и другом Николаем (@1Last) за время работы в SOC. К сожалению PhD в этом году перенесли, поэтому было принято решение поделиться данным способом тут.
Кому он будет полезен и для какой, собственно, цели:
Для руководителей SOC и руководителей дежурной L1 - L2 — как способ оптимизировать ресурсы SOC (потому что мы изначально идём по более вероятному пути): структурировано и обоснованно отсеивать значительный объем шума — по нашему опыту, до 60-80% алертов на этапе роста SOC или в плохо настроенных средах.
Для всех сотрудников (в том числе и руководителей SOC) — эффективно развивать экспертизу: обучение аналитиков глубокому пониманию окружения и бизнес-процессов, что увеличит вероятность обнаружения сложных атак.
Для аналитиков — использовать в повседневной деятельности подход, положительно зарекомендовавший себя на практике, и снизить ментальную нагрузку на принятие решения о вердикте алерта.
Проблематика
SOC постоянно балансирует между двумя рисками:
Пропустить реальную угрозу
Потратить ресурсы (которые ограничены) на анализ и расследование ложных срабатываний (False Positive).
Ключевая проблема в том, что аналитик, видя алерт, часто пытается сразу искать признаки атаки. Это ментально тяжело и медленно. Мы предлагаем сместить фокус: сначала проверить, не является ли активность ожидаемой и нормальной. Это быстрее и снижает когнитивную нагрузку.
Почему мы рассматриваем обратный утиный тест?
Классический эвристический принцип — «утиный тест» (если что-то выглядит, плавает и крякает как утка, то это утка) — хорошо служит для выявления инцидентов. Обратный «утиный тест» — это проверка гипотезы, связанной с тем, что если есть хотя бы одно доказательство легитимности активности, то скорее всего это не является инцидентом.
Изначально, мы рассматриваем поступивший алерт не как 100% инцидент (обычно в SOC больше 80% поступивших алертов – это не сработки на реальные атаки и действия злоумышленников), а как срабатывание правила корреляции, для которого ещё необходимо доказать, что сработка является инцидентом. По итогу, мы доказываем не факт инцидента, а ищем признаки ложноположительной сработки, но это не значит, что стоит ослабить бдительность и отбросить критическое мышление во время анализа поступающих алертов, так как злоумышленники с каждым днём применяют все более совершенные TTP, часто мимикрирующие под легитимные процессы и утилиты.
Ограничения применения методики
Методику не рекомендуется использовать:
если активность может быть продолжением известной атаки внутри инфраструктуры (операции red team либо действия злоумышленников)
если подозрительная активность зафиксирована на периметре или в рамках тактики «Initial access»
на алертах категории «malware» или активности известных hacktool'ов
на сетевых сканированиях со внешних адресов
Методика может быть применима:
с большой осторожностью – алерты с высоким приоритетом (с учётом особенностей инфраструктуры) и "недопустимые события"
если не можете спрофилировать или отключить правило без ущерба мониторингу – в противном случае профилируем/отключаем
Ретроспективный анализ (ретроспектива)
Первым пунктом предлагаемой методики считаем Ретроспективный анализ (наличие ретроспективы (выглядит как утка))
Что мы рассматривает в рамках данного пункта:
обоснование бизнес-логики - наличие аналогичной активности во временном промежутке до 90-180 дней (необходимо иметь тикеты либо письма/тикеты с чётким обоснованием совершённых действий и их периодичности)
при отсутствии подтверждения через тикеты - исторический профиль активности (мы проверяем наличие ретроспективы) - аналогичная активность с данного хоста/данной УЗ ранее либо циклично
аналогичная активность с другого хоста под другим пользователем (работа какого-то ПО, раскатка, установка ПО) – например, массовые сработки при обновлении ПО
возможная ошибка выполнения бизнес процесса (например, новый пользователь не разобрался в инструкциях)
аналогичная активность с другого хоста под тем же пользователем (работы администраторов)
Источники информации: IRP (SOAR), SIEM, NTA, Почта
Логика и бизнес-логика активности
Вторым пунктом мы проверяем логику и бизнес-логику процесса на предмет нарушений (плавает как утка)
Составляем описание с технической точки зрения, что произошло и почему, чем может быть вызвана активность из алерта, для этого в том числе необходимо получить информацию у администраторов сервисом или хостов, г��е была зафиксирована активность или бизнес-партнёров (Анализ цепочки действий и событий)
Мы исходим из утверждения, что
“Используемая логика и бизнес-логика уже учтены (внесены соответствующие исключения и т.д.) в системах ИБ, но на практике встречаются пограничные ситуации, когда необходимо учитывать не только требования безопасности, но и коммерческие риски. В таких случаях решение принимается с учетом баланса между этими двумя понятиями.”
Для этого:
проверяем цель нарушения БЛ
проверяем соответствие требованиям политики допустимого использования информационных активов (политике ИБ компании)
проверяем возможность непреднамеренных нарушений
проверяем, не было ли официальных разрешений на отклонение от политик (информация от L3 или владельцев сервиса, либо случаи, зафиксированные в базе знаний)
проверяем легитимность хэшей, ПО и процессов в целом (важно - бизнес-логика процессов в каждой компании своя)
Источники информации: Тикеты jira, база знаний, тематические чаты команд в мессенджерах, если есть – получение информации у Бизнес Партнеров и product manager’ов.
Опрос пользователя
Третьим пунктом является опрос пользователя (крякает как утка), а именно уточнение причины возникновения данной активности и в рамках какой цели(задачи) она была выполнена.
Подтверждение пользователя – один из важных фактов, в рамках подтверждения легитимности активности.
Для этого:
Необходимо проверить тикеты (заявки) в системе учета заявок (к примеру - jira).
В случае их отсутствия, составить письменный запрос (запрос через рабочую почту, мессенджеры, звонок по сотовой связи (иным способом)) для пользователя на предмет легитимности данной активности.
Не задавать только один вопрос – “является ли данная активность легитимной”, так как не каждый пользователь может понять, что именно это означает и своим ответом неосознанно/целенаправленно ввести вас в заблуждение.
В рамках переписки/общения с пользователем задавать наводящие вопросы, в рамках какой задачи, для какой цели, была активность, что именно делал пользователь. Важно получить соответствие ответов активности.
Важное предупреждение про опрос пользователя: Подтверждение со стороны инициатора активности — весомый аргумент, но не истина в последней инстанции. Учетная запись может быть скомпрометирована, а пользователь может ошибаться или намеренно вводить в заблуждение. Всегда перепроверяйте ответы пользователя по техническим логам. Если слова расходятся с действиями — это красный флаг и повод для углубленного расследования.
Итог
Почему это обратный duck-тест?
1.Если у нас нет:
ретроспективы
обоснования нарушения БЛ
подтверждения активности со стороны ее инициатора
то в таком случае данная активность является инцидентом и ее нужно расследовать.
2.Если присутствует хотя бы один из пунктов, то с большой долей вероятности это не является инцидентом и необходим дополнительный анализ активности.
3.Если присутствуют все перечисленные выше пункты, то данная активность не является инцидентом и имеет другой классификационный идентификатор.
Что делать с результатом? (Обратная связь)
Подтверждение, что алерт ложный — это не конец работы, а начало улучшения мониторинга. Обязательно стоит зафиксировать результат и передать его тем, кто настраивает правила корреляции.
Если мы трижды подтвердили, что конкретная активность легитимна, а алерт продолжает сыпаться — нужно:
1. Инициировать доработку правила (внесение исключения).
2. Обновить плейбуки (runbook) для аналитиков, чтобы они не тратили время на заведомо ложные сработки.
3. Если это массовое явление — уведомить смежные команды (админов, разработку) о том, что их действия порождают шум в SOC.
Без этого шага методика превращается в просто «фильтр», а не в инструмент оптимизации.
Всем спасибо за прочтение, буду рад обратной связи и комментариям :-)
Буду очень рад, если внедрение данной методики положительно скажется на работе вашего SOC :-)
P.S. Cформировали концепцию llm-агента на основе данной методики, о чем хочу написать дополнительно.
