Детали инфраструктуры изменены, цифры обезличены и округлены.
В первой части я рассказывал о компании, которая купила тяжёлый SIEM раньше, чем поняла, что именно собирается с его помощью обнаруживать.
Источники подключили. Дашборды нарисовали. События потекли рекой. Формально проект состоялся.
Оставалась небольшая техническая формальность – сделать так, чтобы всё это приносило пользу.
На первом рабочем совещании я задал три скучных вопроса:
- Что мы защищаем в первую очередь?
- Какие атаки хотим обнаруживать?
- Что должен сделать аналитик после срабатывания каждого правила?
С первым вопросом справились примерно наполовину. В ответ на второй начали перечислять средства защиты. После третьего в комнате стало заметно тише.
Выяснилось, что SIEM собирает почти всё, до чего смогли дотянуться интеграторы. Но между событием и решением редко существовал законченный процесс.
У системы было много глаз. Просто никто не договорился, куда именно смотреть.
Неприятное предложение
Первый совет прозвучал почти как саботаж:
Давайте пока не будем подключать новые источники. Сначала разберёмся с тем, что уже собираем.
Через несколько дней предложение стало ещё неприятнее:
Около 85% потока нужно вывести из оперативного контура SIEM.
Бизнес отреагировал предсказуемо.
Компания заплатила за «полную видимость», а приглашённый консультант предлагает добровольно видеть меньше. Примерно как купить телескоп, а потом заклеить большую часть линзы изолентой.
Но удалять журналы вслепую мы не собирались.
Задача была в другом – перестать использовать дорогую платформу обнаружения как универсальный склад системных событий.
SIEM должен помогать принимать решения. Всё остальное можно хранить дешевле, агрегировать или не собирать вообще.
Откуда взялись 85%
На старте система принимала около 18 тысяч событий в секунду от 70–80 источников. В часы пик поток становился почти вдвое больше.
На дашбордах выглядело солидно.
Основную массу создавали:
– разрешённые соединения межсетевых экранов;
– штатные успешные входы пользователей;
– полные журналы DNS и прокси;
– информационные сообщения приложений;
– события резервного копирования и мониторинга;
– активность легитимных сканеров;
– служебные сигналы доступности;
– одинаковые события, приходившие одновременно из ОС, EDR и сетевого оборудования.
Отдельным видом искусства были повторы.
Один подозрительный вход мог породить несколько десятков алертов. VPN увидел аутентификацию. Контроллер домена записал вход. EDR заметил новую сессию. Межсетевой экран зафиксировал соединения.
Каждая система честно сообщала о происходящем, а SIEM так же честно превращал один эпизод в фестиваль тревожности.
Аналитик получал не один инцидент с собранным контекстом, а двадцать поводов открыть двадцать вкладок.
Мы не удалили данные. Мы изменили маршрут
Поток разделили на три уровня.
Оперативный контур SIEM
Здесь оставили события, которые нужны для обнаружения и быстрой реакции:
– критичные события Active Directory и Kerberos;
– изменения привилегированных групп;
– IdP, VPN и удалённый доступ;
– EDR и отключение средств защиты;
– административные действия на NGFW и WAF;
– события публичных приложений;
– управление учётными записями в облаках;
– доступ к резервным копиям и виртуализации;
– аудит критичных бизнес-систем;
– DNS и сетевые события из особо важных сегментов.
Это не означало, что каждое такое событие немедленно становилось алертом. Оно просто оставалось доступным для оперативной корреляции.
Дешёвое хранение
Сюда отправили данные, которые могут понадобиться при расследовании, но не обязаны постоянно обрабатываться SIEM:
– массовые успешные входы;
– разрешённый сетевой трафик;
– полные DNS-журналы;
– журналы прокси;
– подробные технологические события приложений;
– часть сетевой телеметрии.
При инциденте их можно поднять и восстановить цепочку действий. Но больше не нужно платить за их непрерывную корреляцию и заставлять аналитика смотреть на каждое штатное движение пользователя.
Корзина
Полностью перестали собирать только откровенный мусор:
– дублирующиеся события;
– отладочные сообщения без диагностической ценности;
– повторяющиеся служебные уведомления;
– события, которые не использовались ни в расследованиях, ни в отчётности;
– сигналы доступности, уже контролируемые системой мониторинга.
Перед отключением каждого типа данных проверяли требования к хранению, потребности расследований и обязательства перед регуляторами.
Потому что бездумно удалить 85% журналов так же глупо, как бездумно собрать их все. Просто лицензия в первом случае страдает меньше.
От источников перешли к сценариям
Раньше логика была такой:
Есть источник → подключаем источник → потом придумываем, что с ним делать
Мы перевернули процесс:
Есть критичный процесс → есть угроза → нужны определённые данные →
есть логика обнаружения → есть понятное действие
Вместо 430 разрозненных правил сформировали 12 основных сценариев:
- Подозрительное использование привилегированной учётной записи.
- Добавление пользователя в административную группу.
- Активность отключённой или уволенной учётной записи.
- Аномальный вход через VPN или поставщика идентификации.
- Отключение EDR, журналирования или другого средства защиты.
- Горизонтальное перемещение между узлами.
- Подозрительное поведение сервисной учётной записи.
- Изменение настроек межсетевого экрана, WAF или удалённого доступа.
- Доступ к резервным копиям и попытка их удаления.
- Административные действия в системе виртуализации.
- Атака на публичное приложение с последующей активностью внутри сети.
- Необычная выгрузка данных из критичной системы.
Одному сценарию могли соответствовать несколько правил. Поэтому после чистки осталось 64 активных правила, а не двенадцать.
Для каждого сценария появилась нормальная карточка:
– какой бизнес-процесс защищаем;
– какие активы участвуют;
– какую угрозу обнаруживаем;
– какие данные для этого нужны;
– что считается подтверждением;
– кто отвечает за разбор;
– что именно он должен сделать;
– в какой срок;
– когда сценарий последний раз проверяли.
Правило без владельца отключалось.
Правило, после которого никто не знает, что делать, тоже отключалось.
Если аналитик может только написать в чат «коллеги, посмотрите, тут что-то подозрительное», это ещё не сценарий обнаружения. Это автоматизированный способ поделиться тревогой.
Полезнее всего оказалась кнопка «подавить»
Большую часть шума создавали не плохие правила, а отсутствие контекста.
SIEM не знал, что:
– ночью идёт плановое резервное копирование;
– сканер уязвимостей легально обходит сотни адресов;
– сервисная учётная запись действительно работает с несколькими серверами;
– администратор выполняет согласованные работы;
– массовые входы связаны с перезапуском терминалов;
– часть подозрительной активности происходит во время обновления.
Мы добавили:
– окна технических работ;
– перечни штатных сканеров;
– контекст сервисных учётных записей;
– критичность активов;
– подавление повторов;
– объединение связанных событий в один инцидент;
– пороговые значения;
– обратную связь от аналитиков.
Последний пункт оказался особенно важным.
Раньше аналитик закрывал ложное срабатывание, и на этом всё заканчивалось. На следующий день правило снова приносило ему тот же алерт.
После изменений каждое регулярное ложное срабатывание превращалось в задачу на настройку сценария.
SIEM наконец начал учиться. Не самостоятельно, конечно. С помощью слегка уставших людей.
Что получилось
После первой волны изменений картина выглядела так:
| Показатель | До | После |
|---|---|---|
| Поток в оперативном контуре | 18 000 EPS | 2 700 EPS |
| Активные правила | 430 | 64 |
| Алерты за сутки | около 900 | 60–80 |
| Срабатывания без полезного действия | около 90% | 30–40% |
| Среднее время первичного разбора | 35 минут | 8 минут |
| Формализованные сценарии | неизвестно | 12 |
Количество алертов упало больше чем в десять раз.
Злоумышленники не получили праздничный пропуск в инфраструктуру. Наоборот, аналитики впервые начали успевать разбирать события, которые действительно могли привести к инциденту.
Раньше команда видела 900 тревог, но могла качественно обработать не больше сотни. Остальные либо закрывались поверхностно, либо отправлялись в бесконечный список «посмотреть позже».
После изменений поток хотя бы начал соответствовать количеству людей.
Иногда зрелость выглядит не как новая коробка, дашборд или модуль с искусственным интеллектом.
Иногда это момент, когда объём работы наконец перестаёт быть издевательством над командой.
Почему бизнес сначала не поверил
Самый сложный вопрос задал руководитель:
Мы покупали SIEM, чтобы видеть всё. Почему теперь вы предлагаете видеть меньше?
Ответили так:
Сейчас система видит всё, но команда не успевает понять ничего. Мы уменьшаем не защищённость, а количество данных, которые не приводят ни к одному решению.
После этого бизнесу перестали показывать количество подключённых источников и объём обработанных событий как главные показатели успеха.
Вместо них появились другие вопросы:
– сколько значимых событий действительно разобрано;
– сколько инцидентов подтверждено;
– как быстро началась реакция;
– сколько сценариев проверено;
– какой процент алертов привёл к полезному действию;
– сколько ложных срабатываний создало проблемы для ИТ и бизнеса.
Тысяча алертов в день выглядит внушительно ровно до момента, когда выясняется, что 950 из них никто толком не читает.
Выключили ли мы SIEM?
Нет.
Фраза «пришлось почти выключить» хорошо работает в заголовке, но технически произошло другое.
Мы выключили режим, в котором SIEM использовался как самое дорогое хранилище журналов в компании.
Архитектура стала выглядеть так:
Критичные события → SIEM и оперативная корреляция
Данные для расследований → дешёвое долговременное хранение
Технические показатели → система мониторинга
Дубли и бесполезный шум → не собираем
SIEM остался на месте. Изменились его роль и рацион.
Ferrari наконец перестали использовать как трактор.
Семь вопросов перед подключением источника
Теперь каждый новый источник проходил простую проверку:
- Какой бизнес-процесс он помогает защищать?
- Какую угрозу с его помощью обнаруживаем?
- Какие конкретно события нужны?
- Должны ли они находиться в оперативном контуре?
- Какое правило будет их использовать?
- Кто отреагирует на срабатывание?
- Что потеряем, если источник перестанет поступать?
Если на большую часть вопросов ответа не было, источник не подключали «на всякий случай».
Потому что «на всякий случай» – один из самых дорогих тарифных планов корпоративной ИБ.
В итоге
Ошибка была не в том, что компания купила Ferrari.
Ошибка была в попытке возить на ней всё подряд: картошку, кирпичи, мусор, технические журналы и иногда аналитика SOC.
Мы не стали менять машину. Сначала построили дорогу, определили маршрут и выкинули из багажника то, что там вообще не должно было лежать.
Поток событий сократился примерно на 85%.
Видимость не исчезла. Наоборот, впервые стало видно то, ради чего SIEM покупали.
Хороший SIEM – не тот, который собирает всё.
Хороший SIEM – тот, после сигнала которого кто-то понимает, что произошло, почему это важно и что делать дальше.