“Платформа для мониторинга и реагирования, это не выбор коробки с галочкой, а архитектура решений. Мы взяли то, что работает, и склеили это так, что система перестала быть набором инструментов и стала единым механизмом.”
Три кита: разделение ответственности
Стандартная архитектура большинства SOC-платформ строится вокруг трёх основных функций: сбор и нормализация данных, корреляция событий и управление инцидентами. Попытка заставить один инструмент выполнять все три роли почти всегда приводит к компромиссам в производительности или функциональности. Мы отказались от поиска единого решения и выбрали специализированные инструменты, которые затем интегрировали в единый контур.
- Wazuh отвечает за сбор данных с агентов, обнаружение вторжений на хостах (HIDS) и базовую корреляцию на основе правил. Его ядро — форк OSSEC — проверено временем, а расширенная интеграция с Elasticsearch делает его не просто SIEM-агентом, а полноценным источником структурированных данных.
- ELK-стек (Elasticsearch, Logstash, Kibana) выполняет роль централизованного хранилища и аналитической платформы. Elasticsearch индексирует всё: и сырые логи от Wazuh, и события из других источников. Kibana, это не только дашборды, но и среда для расследования с помощью визуализаций и фильтров, которые трудно реализовать в других инструментах.
- TheHive специализируется на том, что плохо даётся первым двум: на управлении жизненным циклом инцидента. Это та часть, где события превращаются в задачи, распределяются между аналитиками, обрастают доказательствами (артефактами) и, наконец, закрываются с отчётом. Попытка вести это в тикетах или заметках Kibana приводит к хаосу при росте нагрузки.
Разделение позволяет масштабировать каждую часть независимо. Если растёт объём логов, можно масштабировать кластер Elasticsearch. Если увеличивается количество инцидентов, добавляются аналитики в TheHive без перестройки системы сбора.
Сбор и нормализация: от сырых логов до структурированных событий
Главная задача на этом этапе — превратить разнородный поток логов с сетевых устройств, серверов Windows, Linux и приложений в единый поток структурированных событий, пригодных для корреляции. Wazuh здесь играет первую скрипку, но не единственную.
Агенты Wazuh устанавливаются на конечные узлы. Помимо сбора логов, они в реальном времени отслеживают изменения в файловой системе (FIM), анализируют целостность файлов, проверяют соответствие политикам (CIS benchmarks). Все эти данные агенты отправляют на менеджер Wazuh. Менеджер сам по себе уже может выполнять простую корреляцию на основе XML-правил, но его настоящая сила — в интеграции с Elasticsearch. Каждое событие, прошедшее через движок правил Wazuh, попадает в индекс Elasticsearch в виде структурированного JSON-документа.
Почему не только Wazuh?
Некоторые источники данных (например, логи с межсетевых экранов, прокси-серверов или специализированных приложений) могут поступать напрямую через Logstash или Filebeat. В этом случае важен единый пайплайн обработки. Мы настраиваем Logstash-конвейеры так, чтобы все события, независимо от источника, обогащались одними и теми же метаданными: добавлялся тег источника, нормализовались IP-адреса, порты, имена пользователей. Ключевое поле event.module в Elasticsearch указывает, пришло ли событие от Wazuh, файрвола или другого источника. Это позволяет строить в Kibana дашборды, которые агрегируют данные по всем системам.
Пример обогащения в Logstash:
filter {
if [event][module] == "firewall" {
mutate { add_tag => ["network", "denied"] }
geoip { source => "src_ip" }
}
}Корреляция и обнаружение: два уровня логики
Корреляция в нашей системе работает на двух уровнях, что снижает нагрузку на центральную часть и ускоряет реакцию.
- Уровень правил Wazuh. На этом уровне отрабатывают быстрые, детерминированные сценарии, не требующие контекста из других систем. Например, правило срабатывает при множественных неудачных попытках входа на один хост за короткий промежуток времени. Wazuh генерирует оповещение и отправляет его в Elasticsearch. Реакция здесь может быть автоматической — через интеграцию с Active Response модулем Wazuh можно автоматически блокировать IP-адрес на файрволе.
- Уровень Kibana и Elasticsearch. Здесь работает корреляция, требующая более широкого контекста. С помощью механизма мониторинга в Elastic Stack (Watcher) или кастомных скриптов на Python, которые опрашивают Elasticsearch API, можно обнаружить сложные атаки. Например, связать неудачный вход на веб-сервер (событие от Wazuh) с последующей аномальной исходящей сетевой активностью с этого же сервера (событие от сетевого IDS). Такое сложное правило создаётся как запрос к Elasticsearch, а его срабатывание генерирует новое событие-оповещение высшего уровня.
Именно эти оповещения высокого уровня, созданные на втором этапе, становятся основным источником входных данных для TheHive. Мы не заваливаем аналитиков тысячами сырых событий от Wazuh. В TheHive попадают только те оповещения, которые прошли через фильтр сложной корреляции и представляют собой потенциальный инцидент.
Управление инцидентами: где начинается работа аналитика
Момент, когда оповещение из Elasticsearch попадает в TheHive,, это точка перехода от автоматического мониторинга к ручному расследованию. Интеграция осуществляется через специального «коннектора». TheHive постоянно опрашивает заданный индекс Elasticsearch по определённому запросу (например, ищет события с полем alert.severity выше определённого порога). Найденное событие автоматически создаёт в TheHive новый «кейс» или добавляется как новое оповещение в существующий.
Жизненный цикл инцидента в TheHive
Каждый инцидент в TheHive, это не просто тикет. Это структурированное рабочее пространство:
- Задачи (Tasks). Инцидент разбивается на этапы расследования: «Проверить логи аутентификации», «Проанализировать запущенные процессы», «Уведомить ответственных». Каждую задачу можно назначать конкретному аналитику, устанавливать сроки и отмечать как выполненную.
- Артефакты (Observables). В процессе работы аналитик добавляет в кейс найденные индикаторы: IP-адреса, хеши файлов, доменные имена. TheHive может автоматически отправлять эти артефакты на анализ во встроенный или внешний Cortex.
- Cortex — мозг реагирования. Это отдельный, но тесно интегрированный с TheHive движок анализа. Он содержит «анализаторы» — скрипты, которые проверяют артефакты по внешним источникам (например, ищут IP в блок-листах, проверяют хеш файла в VirusTotal, анализируют домен через PassiveTotal). Результаты анализа автоматически возвращаются в кейс, предоставляя аналитику готовую разведданную.
После завершения расследования в TheHive формируется стандартизированный отчёт, который можно экспортировать. Все действия, задачи и артефакты остаются в истории кейса, создавая полную аудит-трассу для последующего разбора или отчёта регулятору.
Интеграция в единый контур: обратная связь и автоматизация
Настоящая сила архитектуры проявляется, когда система замыкается в петлю. Обнаружение приводит к анализу, анализ — к решению, а решение — к автоматическому действию.
Сценарий: Cortex в процессе анализа артефакта в TheHive определяет злонамеренный IP-адрес. С помощью специального «ответчика» (responder) в Cortex можно автоматически сгенерировать команду для Wazuh Active Response, которая добавит этот IP в локальные правила блокировки на всех хостах или отправит команду на межсетевой экран.
Для этого используется API Wazuh. Пример простого ответчика в Cortex, который отправляет команду блокировки:
[КОД: Скрипт на Python, который получает IP-артефакт из TheHive, формирует JSON-запрос к API Wazuh Manager для выполнения активного ответа (blockip) на заданной группе агентов.]решение, принятое аналитиком в TheHive (или даже автоматически Cortex), превращается в конкретную техническую контрмеру в инфраструктуре, реализуемую через Wazuh. Это превращает SOC из пассивного наблюдателя в активного участника защиты.
Сложности, с которыми столкнётесь, и как их обойти
Сборка SOC из open-source компонентов, это не установка одного пакета. Проблемы носят в первую очередь эксплуатационный характер.
| Сложность | Проявление | Путь решения |
|---|---|---|
| Масштабирование Elasticsearch | Рост объёма логов приводит к замедлению поиска и отказу кластера. | Заложить избыточность с самого начала: отдельные ноды для мастеров, данных и клиентов. Жёстко настраивать политики retention (удаления старых индексов) через ILM (Index Lifecycle Management). |
| Производительность Wazuh Manager | При большом количестве агентов менед}ер не справляется с обработкой правил в реальном времени. | Разделить роли: выделить отдельные ноды менеджера для приёма событий и для их анализа. Использовать балансировку нагрузки для агентов. |
| Поддержание актуальности правил | Угрозы меняются, старые правила детектирования устаревают. | Настроить автоматическое обновление правил Wazuh из официальных репозиториев. Для корреляции в Elasticsearch заложить регулярный пересмотр и настройку Watcher-правил как часть регламента работы SOC. |
| Интеграционное тестирование | Обновление одного компонента (например, Elasticsearch) может сломать коннекторы в TheHive. | Развернуть полноценный staging-стенд, идентичный боевому, где проверяются все обновления. Автоматизировать тесты API-интеграций между компонентами. |
На что это не способно (и что нужно докупать)
Конструкция на ELK, Wazuh и TheHive покрывает значительную часть потребностей SOC, но у неё есть естественные границы.
Система слабо приспособлена для глубокого анализа сетевого трафика (Network Traffic Analysis, NTA). Wazuh и ELK работают с уже агрегированными сетевыми событиями (логи Suricata, Zeek). Для полноценного NTA потребуется отдельное решение, способное хранить и анализировать пакеты или метаданные потоков.
Автоматическое реагирование (SOAR) в этой связке, хотя и возможно через Cortex, требует значительных усилий по разработке и поддержке собственных «ответчиков». Промышленные SOAR-платформы предлагают сотни готовых интеграций, чего в open-source экосистеме просто нет.
Наконец, построение и поддержка такой системы требуют команды с глубокими знаниями в администрировании Linux, Elasticsearch, сетевой безопасности и разработке скриптов. Плата за отсутствие лицензий, это время и экспертиза ваших специалистов.