В предыдущем разборе мы вывели из оперативного контура SIEM около 85% потока событий. EPS упал с 18 тысяч до 2 700, алертов стало в десять раз меньше, а команда наконец начала успевать их разбирать.
У этой истории есть опасный побочный эффект.
Кто-нибудь обязательно прочитает её как инструкцию:
SIEM дорогой и шумный? Удалите 85% логов. Проверено консультантом.
Нет.
Число 85% было результатом анализа конкретной инфраструктуры, а не целевым показателем. В другой компании правильный результат может оказаться 20%, 60% или вообще минус 5%, потому что выяснится: нужные журналы туда ещё не подключили.
Сократить поток несложно. Сложно доказать, что вместе с шумом вы не вырезали телеметрию, которая понадобится во время следующего инцидента.
Поэтому сегодня без красивой философии. Ниже – инженерная схема, по которой можно чистить SIEM без ритуального жертвоприношения видимости.
Главное правило: сначала зависимость, потом ножницы
Нельзя начинать с вопроса:
Какой источник генерирует больше всего EPS?
Начинать нужно с другого:
Какие сценарии обнаружения и расследования перестанут работать, если этот источник исчезнет?
Высокий объём сам по себе не делает данные бесполезными. Журналы DNS, успешные входы, разрешённые соединения NGFW или события создания процессов могут генерировать огромный поток. При этом именно они помогают восстановить цепочку атаки.
Проблема обычно не в существовании этих данных, а в неверном маршруте. Их отправляют в дорогой оперативный контур, хотя части из них достаточно дешёвого поиска или архивного хранения.
Перед любым отключением нужна карта зависимостей:
Бизнес-процесс
↓
Угроза
↓
Сценарий обнаружения
↓
Правило / аналитика
↓
Источник → тип события → обязательные поля
↓
Действие аналитика
↓
Тест, который доказывает работоспособность
Если источник ни к чему не привязан, это ещё не повод его удалить. Возможно, у вас не бесполезный источник, а недостроенное обнаружение.
Но если никто не может назвать ни сценарий, ни расследование, ни требование хранения, ради которого данные поступают в SIEM, разговор становится предметнее.
Карточка детекции вместо шаманства
У каждого рабочего сценария должен быть минимальный контракт. Не обязательно сразу покупать отдельную платформу Detection Engineering. Для начала хватит YAML в Git или даже нормально оформленной таблицы.
Пример внутренней карточки:
id: DET-PRIV-001
name: Подозрительный привилегированный вход
business_process: Управление критичной инфраструктурой
threat: Компрометация административной учётной записи
telemetry:
- source: Windows Security
events: [4624, 4672, 4688]
required_fields:
- user
- source_ip
- logon_type
- process_name
- command_line
- source: VPN
required_fields:
- user
- source_ip
- device_id
- result
owner: SOC L2
response: IR-PLAYBOOK-07
sla_minutes: 15
test: ART-T1078
last_successful_test: 2026-07-10
Это не спецификация Sigma, а простой внутренний контракт. Его задача – сделать зависимость видимой.
Сами правила удобно хранить в vendor-neutral формате Sigma, а затем конвертировать или адаптировать под конкретную платформу. Но наличие YAML-файла ещё не превращает запрос в зрелую детекцию.
У правила всё равно должны быть:
– владелец;
– ожидаемые поля;
– понятный результат;
– плейбук реакции;
– тест;
– дата последней успешной проверки.
Правило без теста – это гипотеза. Правило без действия – уведомление о тревожности автора.
Четыре маршрута: HOT, WARM, COLD, DROP
После построения карты данные можно делить по назначению.
| Уровень | Для чего нужен | Типичный доступ | Пример данных |
|---|---|---|---|
| HOT | Детектирование и быстрая реакция | Секунды и минуты | Привилегии, EDR, IdP, критичные изменения |
| WARM | Расследование и ретроспективный поиск | Минуты | Успешные входы, DNS, proxy, разрешённый трафик |
| COLD | Архив, аудит, редкие расследования | Часы | Полные технологические журналы, длительное хранение |
| DROP | Нигде не используется | Никогда | Дубли, бессмысленный debug, повторяющийся health-шум |
Сроки хранения здесь намеренно не указаны. Они зависят от требований регуляторов, договоров, модели угроз, возможностей расследования и цены простоя.
Универсальная рекомендация «держите HOT 30 дней, а COLD год» выглядит удобно, пока не выясняется, что ваш инцидент обнаружили через 45 дней, а нужные данные уже экономно исчезли.
HOT – не значит «всё важное навсегда»
В HOT должны находиться события и поля, которые реально участвуют в оперативной аналитике.
Например, для обнаружения подозрительного входа важны не миллионы одинаковых записей сами по себе, а сочетание:
– пользователя;
– источника подключения;
– типа входа;
– устройства;
– времени;
– результата;
– привилегий;
– связанной активности после входа.
Если парсер теряет source_ip или logon_type, формально события продолжают поступать. Фактически детекция уже сломана.
WARM – место для контекста
Не каждая запись должна обрабатываться корреляционным движком в реальном времени.
Массовые успешные входы, полные DNS-журналы, разрешённые сетевые соединения и технологические события приложений часто нужны при расследовании. Их можно хранить в более дешёвом поисковом контуре и поднимать по запросу.
Ключевое слово – «поисковом».
Архив, который можно получить только через заявку администратору хранилища, недельное согласование и молитву о сохранности индекса, для реагирования почти бесполезен.
COLD – данные, а не цифровое кладбище
Холодный контур должен иметь проверенный процесс возврата данных:
- Кто запрашивает восстановление?
- За какое время архив становится доступен?
- Сохраняются ли схема и временные метки?
- Можно ли проверить целостность?
- Чем и как эти данные будут искать?
Если никто ни разу не поднимал архив обратно, это не уровень хранения. Это акт веры в объектное хранилище.
DROP – только после доказательства
В DROP отправляются данные, для которых выполнены все условия:
– их не использует ни одно правило;
– они не нужны в расследованиях;
– на них нет требований аудита и хранения;
– они дублируются более качественным источником;
– их отключение прошло тест и canary-период;
– есть понятный способ быстро вернуть поток.
Сначала докажите, что данные не нужны. Потом отключайте.
Шаг 1. Снимите базовую линию
До изменений соберите минимум две недели статистики. Если инфраструктура живёт месячными закрытиями, квартальными работами или редкими batch-процессами, период должен захватить и их.
Для каждого источника полезно измерить:
– средний и пиковый EPS;
– объём в гигабайтах за сутки;
– количество типов событий;
– долю ошибок парсинга;
– заполненность обязательных полей;
– количество правил, использующих источник;
– количество алертов;
– долю подтверждённых инцидентов;
– частоту поисковых запросов при расследованиях;
– стоимость хранения и обработки.
Простейший запрос на поиск главных генераторов может выглядеть так:
SELECT
source,
event_id,
COUNT(*) AS events,
SUM(raw_size_bytes) AS bytes,
COUNT(DISTINCT host) AS hosts
FROM security_events
WHERE event_time >= NOW() - INTERVAL '14 days'
GROUP BY source, event_id
ORDER BY events DESC;
Синтаксис придётся адаптировать под вашу платформу. Смысл запроса простой: сначала увидеть, кто создаёт поток, а не назначать виноватым Windows по старой корпоративной традиции.
Шаг 2. Постройте матрицу использования
Для каждого типа события заполните таблицу:
| Источник | Событие | Правила | Расследования | Аудит | Маршрут | Решение |
|---|---|---|---|---|---|---|
| Windows Security | 4624 | 7 | да | да | HOT + WARM | фильтровать, не удалять |
| Sysmon | Network connection | 2 | да | нет | WARM | вывести из real-time |
| NGFW | Allow | 1 | да | да | WARM | агрегировать |
| Monitoring | Host alive | 0 | нет | нет | DROP | оставить в Zabbix |
Один источник может идти сразу по двум маршрутам.
Например, подозрительные входы привилегированных пользователей остаются в HOT, а массовая штатная аутентификация уходит в WARM. Не обязательно выбирать между «собирать всё» и «выключить журналирование».
Фильтр можно применять:
– на агенте;
– на коллекторе;
– в pipeline нормализации;
– перед индексированием;
– через маршрутизацию в разные хранилища.
Чем раньше вы отбрасываете гарантированно бесполезные данные, тем меньше платите за транспорт и обработку. Но тем выше цена ошибки. Поэтому фильтрацию на источнике включают последней, когда решение уже проверено ниже по цепочке.
Шаг 3. Проверьте не наличие логов, а результат детекции
После изменения маршрута нужно воспроизвести поведение, которое обязано обнаруживаться.
Для точечных тестов удобно использовать Atomic Red Team – библиотеку небольших воспроизводимых тестов, сопоставленных с MITRE ATT&CK. Для более длинных цепочек и автоматизированной эмуляции можно применять MITRE CALDERA.
Но запуск теста – только половина работы.
Нормальная проверка выглядит так:
Действие выполнено
↓
Нужное событие появилось на источнике
↓
Коллектор его принял
↓
Парсер сохранил обязательные поля
↓
Правило отработало
↓
Алерт объединился с контекстом
↓
Аналитик получил понятное действие
Если тест дошёл до SIEM, но потерял командную строку, пользователя или адрес источника, зелёная галочка преждевременна.
Свежая версия MITRE ATT&CK тоже стала полезнее для такой работы. Начиная с ATT&CK v18, старые Data Sources были выведены из основной модели, а защитная часть перестроена вокруг Detection Strategies, платформенных Analytics и Data Components. Это ближе к реальному вопросу инженера: не «какой лог у нас есть», а «какую аналитику мы строим и какие компоненты данных ей нужны». Изменение описано в официальном обзоре ATT&CK v18.
Шаг 4. Делайте canary, а не пятничный обрыв
Не выключайте источник сразу во всей инфраструктуре.
Безопасная последовательность:
- Выберите ограниченную группу систем или 5–10% узлов.
- Сохраните старый маршрут параллельно новому.
- Сравните количество событий и обязательные поля.
- Запустите тесты детекций.
- Проведите несколько реальных расследований через новый контур.
- Проверьте пиковые и ночные процессы.
- Только после этого расширяйте изменение.
У каждой операции должен быть rollback:
– кто возвращает поток;
– какой конфиг откатывается;
– сколько времени занимает возврат;
– потеряны ли события за период отключения;
– где лежит резервная копия pipeline.
Если возврат требует собирать конфигурацию заново по сообщениям в Telegram, это не rollback. Это археология.
Шаг 5. Мониторьте здоровье детекций
Обычный мониторинг отвечает на вопрос: «SIEM жив?»
Detection health должен отвечать на вопрос: «SIEM всё ещё способен увидеть нужное?»
Минимальный дашборд:
| Метрика | Что показывает |
|---|---|
| Ingestion freshness | Когда пришло последнее событие от источника |
| Parser success rate | Какая доля событий разобрана без ошибок |
| Required field coverage | Заполнены ли поля, нужные правилам |
| Detection execution | Запускаются ли правила без ошибок |
| Alert latency | Сколько прошло от события до алерта |
| Last successful test | Когда сценарий последний раз подтверждался тестом |
| Owner / SLA | Кто и за сколько должен реагировать |
Отдельно следите за «тихой смертью» источника.
Ноль алертов может означать спокойный день. А может означать, что коллектор перестал принимать события три недели назад, и все очень довольны качеством настроек.
Replay важнее красивого дашборда
Перед изменением сохраните репрезентативный набор данных:
– нормальную дневную активность;
– ночные и регламентные работы;
– известные ложные срабатывания;
– подтверждённые инциденты;
– результаты контролируемых атакующих тестов.
После изменения прогоните этот набор через новый pipeline и сравните:
– какие правила сработали;
– какие перестали;
– какие поля потерялись;
– сколько алертов объединилось;
– как изменилось время обработки;
– какие расследования больше нельзя провести.
Replay превращает спор «кажется, мы ничего не потеряли» в проверяемый результат.
Без replay любое сокращение логов держится на памяти людей. А память особенно избирательна через полгода, когда приходит аудитор или шифровальщик.
Что точно не надо делать
Резать только по EPS
Самый шумный источник может быть главным источником контекста. Объём – причина исследовать данные, а не приговор.
Удалять поля ради экономии без проверки правил
Иногда событие остаётся, но становится бесполезным после нормализации. Особенно быстро исчезают command line, source IP, идентификатор устройства и исходный пользователь.
Оставлять всё в HOT «на всякий случай»
Это самый дорогой способ не принимать архитектурные решения.
Отправлять данные в архив без теста восстановления
Если архив нельзя поднять в сроки расследования, его практическая ценность сильно ниже, чем написано в политике хранения.
Считать отсутствие алертов успехом
Тишина в SOC бывает двух видов: вы хорошо настроились или у вас всё сломалось. Внешне выглядит одинаково.
Минимальный план на две недели
Дни 1–3: инвентаризация
– выгрузить источники, EPS и объём;
– связать правила с источниками и полями;
– найти владельцев сценариев;
– отметить требования хранения.
Дни 4–6: проектирование маршрутов
– назначить HOT, WARM, COLD или DROP;
– убрать очевидные дубли;
– определить контрольные метрики;
– подготовить rollback.
Дни 7–9: тестовый контур
– включить новый pipeline на ограниченной группе;
– выполнить replay;
– запустить Atomic-тесты;
– проверить расследования.
Дни 10–12: canary
– расширить изменение до 5–10% инфраструктуры;
– наблюдать пиковые периоды;
– проверить заполнение полей и задержку;
– собрать обратную связь аналитиков.
Дни 13–14: решение
– зафиксировать результаты;
– согласовать масштабирование;
– обновить документацию;
– назначить дату следующего теста.
За две недели вы не перестроите весь SOC. Но уже сможете безопасно убрать часть очевидного шума и, что важнее, получить повторяемый процесс.
В итоге
Сокращение потока SIEM – не проект по экономии лицензии. Экономия появляется как приятный побочный эффект.
Главный результат – управляемая телеметрия:
Сценарий → нужные данные → правильный маршрут → воспроизводимый тест
Не ставьте KPI «снизить EPS на 50%». Он почти гарантированно научит команду удалять данные быстрее, чем понимать их ценность.
Лучший показатель звучит иначе:
Все критичные сценарии прошли тест, расследования сохранили контекст, а бесполезный поток больше не съедает деньги и внимание аналитиков.
SIEM не обязан видеть всё.
Он обязан стабильно видеть то, после чего команда понимает, что произошло и что делать дальше.