Blue Team: SIEM, логи, threat hunting

Разбираем, как защитники собирают логи со всей инфраструктуры, превращают их в обнаружения через SIEM и проактивно охотятся за угрозами.

Blue Team — команда защиты, которая обнаруживает атаки, реагирует на инциденты и проактивно ищет следы угроз в инфраструктуре.

Предыдущие уроки показали, как устроены AD, Kerberos и сегментация и где возникают слабости. Эта тема — про то, как всё это «видеть»: собрать события со всей сети, связать их в осмысленную картину и заметить атакующего как можно раньше. Хорошая защита измеряется не количеством стен, а скоростью обнаружения.

Зачем это знать

Атакующий, продвигаясь по сети, неизбежно оставляет следы: входы в неурочное время, массовые запросы билетов Kerberos, соединения между сегментами, которых раньше не было. Эти следы тонут в миллионах обычных событий. Задача Blue Team — построить систему, которая выуживает из шума именно подозрительное и поднимает тревогу до того, как инцидент станет катастрофой.

Сбор логов: фундамент обороны

Без логов обнаруживать нечего. Защитник централизованно собирает события из ключевых источников.

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

SIEM и корреляция

SIEM (Security Information and Event Management) — система, которая собирает логи в одном месте, нормализует их к общему виду и применяет правила, связывая разрозненные события в инциденты.

Сила SIEM — в корреляции. Одно событие «неудачный вход» само по себе безобидно. Но пять тысяч неудачных входов в одну учётку за минуту, а затем один удачный — это уже узнаваемый шаблон подбора пароля. Правило корреляции описывает такую логику.

# Псевдоправило корреляции (концепция, не синтаксис конкретного SIEM)
IF  событие = "неудачный вход"
    AND количество > 50 для одной учётки
    ЗА окно 1 минута
    ПОТОМ событие = "успешный вход" в ту же учётку
THEN поднять алерт: "возможный подбор пароля (brute force)"
    severity = high; назначить аналитику

Аналогично строятся правила на массовые запросы сервисных билетов со слабым шифрованием (след Kerberoasting), на вход админ-учётки на нетипичную для неё машину (нарушение модели уровней) или на новое соединение из пользовательского сегмента к базе данных (нарушение сегментации). Чтобы понять, что описывать в правилах, защитники опираются на матрицу MITRE ATT&CK — каталог известных техник атакующих.

Как это работает под капотом

Конвейер Blue Team — это поток: источники шлют события агентами или по syslog в централизованное хранилище, SIEM приводит разные форматы к единым полям (кто, что, когда, откуда), прогоняет через правила и поднимает алерты для аналитика. Ключевой компромисс — баланс между ложными срабатываниями и пропусками: слишком чувствительные правила утомят команду шумом, слишком грубые пропустят атаку. Поэтому правила постоянно настраивают на конкретную среду.

Threat hunting: проактивный поиск

Правила ловят известное. Но продвинутый атакующий может действовать так, что ни одно правило не сработает. Здесь подключается threat hunting — гипотезо-ориентированный поиск, когда аналитик не ждёт алерта, а сам выдвигает предположение и проверяет его по данным.

Цикл прост: гипотеза → поиск в логах → вывод. Например, гипотеза «возможно, атакующий закрепился через автозапуск» превращается в запрос: показать все недавно созданные сервисы и задачи автозапуска на серверах и отсортировать редкие, встречающиеся на одной-двух машинах. Аномалия — повод копать глубже. Так находят то, что обходит сигнатурные правила.

Сильная сторона threat hunting — опора на «нормальное». Прежде чем искать аномалию, полезно знать базовый профиль среды: какие учётки обычно логинятся на сервер, в какое время идёт основная активность, к каким внешним адресам штатно обращаются приложения. Тогда отклонение бросается в глаза. Например, гипотеза «нет ли скрытого канала управления через DNS» проверяется так: посмотреть на необычно длинные или частые DNS-запросы к редким доменам — нормальный трафик так не выглядит. Найденную аномалию документируют, и если она оказывается реальной техникой, по ней пишут новое правило корреляции — так разовая находка превращается в постоянное автоматическое обнаружение, и охота подпитывает SIEM.

Отдельная ценность threat hunting — обратная связь по полноте логов. Нередко в ходе охоты выясняется, что нужного события просто нет, потому что аудит не был включён. Это сразу превращается в задачу: дособрать источник. Так проактивный поиск не только ловит угрозы, но и постоянно улучшает саму видимость инфраструктуры.

Как защититься (выстроить оборону)

• Полнота сбора. Включите расширенный аудит на контроллерах домена, серверах и рабочих станциях; собирайте сеть, прокси и DNS. Нет лога — нет обнаружения.
• Защита логов. Отправляйте события в централизованное хранилище, недоступное на удаление обычным учёткам, чтобы атакующий не стёр следы.
• Правила под свою среду. Начните с типовых сценариев (подбор пароля, аномальные билеты Kerberos, нарушения сегментации) и настраивайте пороги, снижая ложные срабатывания.
• Регулярный threat hunting. Планомерно проверяйте гипотезы по матрице ATT&CK, не дожидаясь алертов.
• Учения и метрики. Совместно с Red Team проверяйте, что атаки реально видны, и измеряйте ключевые показатели: время обнаружения (MTTD) и время реагирования (MTTR).

Мониторинг и сбор логов ведите только в своей инфраструктуре или там, где у вас есть полномочия. Доступ к чужим системам и данным без разрешения наказуем (ст. 272 УК РФ).

Итоги

• Обнаружение начинается с полного и защищённого сбора логов со всех ключевых источников.
• SIEM нормализует события и через правила корреляции превращает разрозненный шум в инциденты.
• Правила опираются на известные техники (MITRE ATT&CK) и постоянно настраиваются под среду.
• Threat hunting проактивно ищет то, что обходит правила, по циклу «гипотеза → поиск → вывод».
• Зрелость защиты измеряется метриками MTTD/MTTR и проверяется совместными учениями с Red Team.