SIEM не хранит сырые логи вечно и не принимает решения самостоятельно. Платформа превращает разрозненные текстовые строки в структурированные события, применяет оконные функции для поиска аномалий и передаёт результат в SOAR, который исполняет заранее прописанные сценарии через внешние API.
Конвейер сбора, парсинга и хранения
Построение центра мониторинга начинается не с покупки лицензии, а с проектирования потока данных. Журналы операционных систем, межсетевых экранов, прокси-серверов и облачных сред генерируются в разных форматах, с разной частотой и разной степенью полезности. Конвейер SIEM решает задачу приведения этого хаоса к единому виду.
Коллекторы делятся на агентные и безагентные. Агентное решение вроде Winlogbeat или rsyslog устанавливается непосредственно на хост. Программа читает файлы *.evtx или /var/log/syslog в реальном времени, буферизует данные в локальную очередь и отправляет их по защищённому каналу на принимающий узел. Метод гарантирует доставку даже при временной потере связи с центральным сервером. Безагентный сбор работает через Windows Event Forwarding, WMI-запросы, SSH или прямые API-вызовы. WEF снижает нагрузку на сеть и позволяет централизованно управлять подписками, но требует доменной инфраструктуры и корректной настройки групповых политик.
Сырые данные попадают в парсер. Здесь применяются регулярные выражения, Grok-шаблоны или встроенные декодеры. Текст превращается в набор полей. Строка Failed password for root from 192.0.2.10 port 22 ssh2 распадается на user=root, src_ip=192.0.2.10, action=failed, service=ssh. После парсинга происходит нормализация. Разные вендоры называют одни и те же сущности по-разному. SourceAddress в одном фаерволе превращается в src_ip, ClientIP в прокси-сервере тоже становится src_ip. Нормализованные данные сохраняются в формате CEF, LEEF или JSON.
Хранение разделяется на горячий, тёплый и холодный уровни. Горячее хранилище держит индексы за последние 30–90 дней в оперативной памяти или на NVMe-накопителях. Поисковые запросы выполняются мгновенно. Тёплый уровень переносит данные на HDD-массивы с пониженной производительностью дисков. Холодный уровень архивирует логи в объектном хранилище или на ленточных библиотеках для соответствия регуляторным требованиям. Разделение снижает стоимость инфраструктуры и ускоряет реакцию аналитиков.
Ограничение пропускной способности коллектора создаёт ситуацию потери событий. При всплеске трафика в 50 000 событий в секунду очередь парсера переполняется. Агент начинает сбрасывать данные или переходит в режим backpressure, блокируя дальнейший приём. Настройка параметров queue.mem.events и pipeline.batch.size определяет, сколько событий буферизируется перед отправкой. Игнорирование этих параметров приводит к дырам в логах, которые атакующие используют для маскировки.
| Тип коллектора | Механика работы | Область применения | Требования к инфраструктуре |
|---|---|---|---|
| Агентный (Filebeat, Winlogbeat) | Чтение файлов/реестра, локальная очередь, отправка по TLS | Серверы, рабочие станции, критичные узлы | Установка ПО на каждый хост, управление сертификатами |
| Windows Event Forwarding | Подписки на события, групповая доставка через домен | Доменные контроллеры, файловые серверы, терминальные узлы | Настройка GPO, служба WinRM, права на чтение журналов |
| Агентless (API, Syslog, SNMP) | Опрос внешних систем, парсинг ответов, сохранение в хранилище | Облачные провайдеры, сетевое оборудование, SaaS-сервисы | Открытые порты, учётные данные с правами чтения, лимиты API |
Механика корреляции и синтаксис правил
Корреляционный движок не сравнивает строки напрямую. Система строит временные окна, применяет агрегационные функции и проверяет условия на соответствие заранее заданным шаблонам. Правило может быть статичным, реагирующим на одно событие, или контекстным, требующим последовательности действий в пределах заданного интервала.
Простое правило отслеживает множественные неудачные попытки входа. Сложное правило комбинирует событие аутентификации, геолокацию IP-адреса и статус учётной записи. Аналитик задаёт параметры окна, пороговые значения и условия исключения.
index=security EventCode=4624 Logon_Type IN (2, 3, 10)
| stats count as login_attempts, values(src_ip) as sources, latest(City) as location by TargetUserName
| where login_attempts > 50
| join type=inner [search index=geo src_ip=* | dedup src_ip | table src_ip, Country]
| where login_attempts > 10 AND location != "Moscow"Логика работает поэтапно. Фильтр отбирает события успешного входа по типам сессий. Агрегация подсчитывает количество попыток по имени пользователя и собирает уникальные IP-адреса. Присоединение данных геолокации обогащает результат. Финальное условие отбрасывает легитимные сценарии, если город соответствует ожидаемому, и генерирует алерт при превышении порога.
Другой распространённый сценарий отслеживает цепочку перебора с последующим успешным входом. Система считает EventID 4625 в окне 5 минут. При достижении 15 срабатываний правило переключается в режим ожидания EventID 4624 от того же IP в течение следующих 10 минут. Успешная аутентификация после массовых отказов формирует инцидент с высоким приоритетом. Правило учитывает легитимные сценарии сброса паролей, исключая учетные записи сервисных аккаунтов и доменных администраторов через справочник исключений.
Настройка исключений требует отдельного внимания. Слишком широкий белый список превращает правило в бесполезный генератор шума. Слишком узкий список блокирует легитимные действия систем резервного копирования или мониторинга. Аналитик ведёт журнал ложных срабатываний, корректирует пороги и добавляет контекстные фильтры по времени суток или названию хоста.
Как атакующие работают с журналами событий
Журналы операционной системы не защищены от модификации пользователем с правами локального администратора. Злоумышленник, получивший начальный доступ, первым делом проверяет аудит и отключает ведение журналов или очищает их содержимое. Операционная система фиксирует эти действия, но только если аудит настроен заранее.
Удаление журнала безопасности генерирует EventID 1102. Остановка службы Windows Event Log записывает EventID 7040 или 7036 в системный журнал. Изменение политик аудита отражается в EventID 4719. События остаются доступными, пока атакующий не перезагрузит машину в безопасном режиме или не использует утилиты для прямого редактирования файлов *.evtx.
Нормальная активность администратора выглядит предсказуемо. Вход происходит в рабочее время, с известного IP-адреса, через протокол RDP или SSH. Запускаются стандартные утилиты управления: mmc.exe, gpupdate.exe, services.msc. Родительский процесс соответствует ожидаемому. Подозрительная активность нарушает паттерны. Вход регистрируется в нерабочее время, с адреса, принадлежащего хостинг-провайдеру, через тип сессии 3 (сетевой). Сразу после входа запускается cmd.exe или powershell.exe с параметрами скрытого выполнения. Процесс обращается к lsass.exe, вызывает SeDebugPrivilege или экспортирует хеши.
Система мониторинга оценивает не только конкретные события, но и разрывы в потоке данных. Внезапное падение количества событий с хоста на 80 процентов при сохранении сетевой активности указывает на принудительную остановку служб журналирования. Правило корреляции сравнивает текущий EPS с медианным значением за последние 7 дней. Отклонение от нормы генерирует алерт среднего приоритета, требующий проверки состояния агента и политик аудита.
От алерта к расследованию: команды и артефакты
Алерт передаётся аналитику с минимальным контекстом. Задача специалиста превратить уведомление в картину инцидента. Исследование начинается с локального хоста или удалённой консоли управления.
Путь к журналам Windows: C:\Windows\System32\winevt\Logs\Security.evtx
Команда поиска последних 50 событий неудачного входа:
wevtutil qe Security /q:"*[System[(EventID=4625)]]" /f:text /rd:true /c:50Фильтрация по конкретному пользователю через PowerShell:
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625; Data='ivanov'} | Select TimeCreated, Message, Properties[5].ValueАнализ запущенных процессов за последний час:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=1; StartTime=(Get-Date).AddHours(-1)} | Select TimeCreated, MessageLinux-системы хранят журналы в /var/log/auth.log или /var/log/secure. Команда journalctl -u sshd --since "1 hour ago" выводит все попытки подключения. Поиск по IP: grep -E "Failed|Accepted" /var/log/auth.log | grep 192.0.2.10.
SOAR подключается на этапе обогащения и первичного реагирования. Playbook принимает алерт, извлекает IP-адрес и хеш файла, отправляет запросы к Threat Intelligence, проверяет репутацию домена в WHOIS, запрашивает у EDR дерево процессов и сетевые соединения хоста. Система формирует черновик отчёта, прикрепляет артефакты к тикету и предлагает действия: изолировать хост, заблокировать IP на фаерволе, сбросить пароль. Исполнение действий с высоким уровнем доступа проходит через ручное подтверждение. Автоматика не отключает контроллеры домена без согласования с инженером второй линии.
Интеграция SOAR и ограничения автоматизации
Платформа оркестрации не заменяет SIEM. Система выполняет API-вызовы, управляет состоянием сценариев и ведёт журнал исполненных действий. Архитектура SOAR включает движок выполнения плейбуков, хранилище учётных данных, коннекторы к внешним системам и интерфейс управления инцидентами.
Плейбук строится как граф зависимостей. Узел запрашивает данные из внешней системы, передаёт результат на следующий узел, проверяет условие и выбирает ветку исполнения. Ошибка на любом этапе останавливает сценарий или переводит его в режим ручного управления. Логи выполнения сохраняются с указанием временных меток, параметров запросов и ответов API.
Типичные сценарии автоматизации включают блокировку IP на уровне маршрутизатора, отзыв сессионных токенов в IAM-системе, создание задачи в ServiceNow и отправку уведомлений в корпоративный мессенджер. Сценарий фишингового реагирования извлекает вложения из письма, отправляет их в песочницу, проверяет хеши в базе угроз и удаляет письмо из почтовых ящиков через Exchange API.
Автоматизация сталкивается с ограничениями качества данных. Нормализованные поля содержат ошибки, геолокация IP возвращает неточные города, справочники активов не обновляются вовремя. Playbook, доверяющий неверным данным, блокирует легитимные учётные записи или оставляет атаку без внимания. Интеграция требует предварительной очистки эталонных данных, настройки проверок целостности ответов API и ведения журнала исключений.
| Ограничение | Влияние на работу | Способ снижения риска |
|---|---|---|
| Отсутствие расшифровки трафика | SIEM не видит содержимое HTTPS, DNS over TLS, SSH | Установка агентов EDR на хостах, сбор журналов приложений, использование TLS-инспекции на прокси |
| Задержка нормализации | Корреляция срабатывает позже, атакующий успевает переместиться | Настройка приоритетных каналов для критичных источников, оптимизация парсеров, разделение потоков по классам важности |
| Нестабильность внешних API | SOAR не может выполнить блокировку, тикет остаётся в подвешенном состоянии | Реализация повторных попыток, кэширование ответов, ручное подтверждение критичных действий |
| Отсутствие контекста активов | Алерт на тестовом сервере получает тот же приоритет, что на продуктивном домене | Интеграция с CMDB, присвоение тегов критичности, динамическое изменение порогов корреляции |
Приоритеты внедрения и следующие шаги
Развёртывание системы мониторинга требует последовательного подключения источников, настройки политик аудита и калибровки правил корреляции. Включение всех журналов одновременно создаёт шум и парализует работу аналитиков. Отключение аудита на критичных узлах оставляет инфраструктуру без телеметрии.
[√] Включить аудит успешных и неудачных входов, запуска процессов и доступа к файлам на контроллерах домена и файловых серверах. Пояснение: Базовые события формируют фундамент для корреляции. Без них правила работают с неполными данными.
[ ] Настроить коллекторы с локальной буферизацией и проверкой целостности очереди. Пояснение: Потеря событий при всплесках нагрузки создаёт слепые зоны, которые используются для обхода детектирования.
[ ] Разработать первые правила корреляции с окном 5–15 минут и пороговыми значениями, основанными на медианной активности за 7 дней. Пояснение: Статичные пороги генерируют ложные срабатывания при изменении нагрузки.
[ ] Подключить SOAR к системам в режиме только для чтения. Пояснение: Тестирование обогащения данных без изменения конфигурации инфраструктуры снижает риск блокировки легитимных процессов.
[ ] Ввести справочник исключений для сервисных учётных записей, заданий резервного копирования и мониторинга. Пояснение: Исключения требуют регулярного аудита. Устаревшие записи превращают правила в бесполезные генераторы алертов.
[ ] Отработать сценарий изоляции хоста и отзыва токенов в тестовой среде с ручным подтверждением на каждом шаге. Пояснение: Автоматизация критичных действий без проверки приводит к остановке продуктивных сервисов при ложном срабатывании.
Система мониторинга работает как фильтр, отделяющий рутинную активность от аномалий. Качество фильтра зависит от полноты журналов, точности парсинга и настройки исключений. Автоматизация реагирования ускоряет обработку инцидентов, но не заменяет проверку контекста и понимание архитектуры инфраструктуры.