HTSOC — Интегрированная система SOC для мониторинга, обнаружения и расследования событий

HTSOC — это самостоятельно построенная система Security Operations Center в лабораторной среде. Система объединяет сбор логов, обнаружение с помощью Splunk, управление алертами/кейсами через TheHive, анализ Observable через Cortex, поиск IOC с помощью MISP или VirusTotal, а затем координирует уведомления через n8n и Telegram.

CVE-2024-4577 — лишь один из use case, используемый для проверки способности многоуровневого обнаружения; весь проект не ограничивается одним CVE.

Содержание

• Цели
• Общая архитектура
• Компоненты
• Поток обработки
• Возможности обнаружения
• Структура репозитория
• Развертывание
• Тестирование и оценка
• Инвентаризация живой системы
• Эксплуатационный runbook
• Чек-лист тестирования

Цели

Система моделирует полный процесс SOC:

1. Сбор телеметрии с Linux, Windows, Apache и Sysmon.
2. Нормализация логов в Splunk по index/sourcetype.
3. Обнаружение подозрительного поведения с помощью SPL, correlation search, allowlist и оценки рисков.
4. Создание алерта с Observable для дальнейшего расследования аналитиком.
5. Управление алертами/кейсами в TheHive.
6. Предоставление аналитику возможности выбирать каждый Observable для запуска соответствующего анализатора в Cortex.
7. Поиск внутренних IOC через MISP или внешних источников через VirusTotal.
8. Отправка алертов и результатов анализа в Telegram.
9. Измерение MTTD, MTTN, MTTR, false positive и duplicate rate.

Общая архитектура

flowchart LR
    K[Kali или источник тестирования] --> W[Windows/XAMPP + Apache/PHP-CGI]
    L[Linux endpoint] --> F[Universal Forwarder]
    W --> A[Apache access/error log]
    W --> S[Windows Security + Sysmon]
    A --> F
    S --> F
    F --> SP[Splunk]
    L --> F
    SP -->|Alert webhook| TH[TheHive]
    TH -->|Alert + Observable| N[n8n]
    N --> T[Telegram]
    N -->|Analyzer, выбранный аналитиком| C[Cortex]
    C --> M[MISP]
    C --> V[VirusTotal]
    M --> N
    V --> N
    N --> T

Эталонная лабораторная топология

Указанные выше адреса предназначены только для лаборатории. При повторном развертывании замените их переменными окружения и не открывайте сервисы в Интернет.

Компоненты

Слой сбора данных

• Apache записывает исходный IP, HTTP-метод, URI, статус и User-Agent.
• Windows Security записывает входы в систему, создание процессов, служб и изменения прав.
• Sysmon дополняет цепочку процессов, командную строку, ProcessGuid, файлы, реестр и сетевые доказательства.
• Linux auth/syslog записывает активность аутентификации и системные события Linux.
• Universal Forwarder передает логи в Splunk согласно заданным input/sourcetype.

Слой обнаружения Splunk

Splunk — центр обнаружения системы. Поиски охватывают brute force login, подозрительный NTLM network logon, изменение групп с высокими привилегиями, lateral movement через SMB, создание новых служб Windows, закодированный PowerShell и PHP-CGI argument injection.

Слой управления расследованием

TheHive получает алерты из Splunk, отображает severity/source/title, сохраняет Observable и позволяет аналитику преобразовывать алерты в кейсы. Cortex получает Observable из TheHive для запуска анализаторов. MISP и VirusTotal — два параллельных варианта анализа, не обязательных для последовательного выполнения.

Слой оркестрации

n8n получает webhook из TheHive и отправляет первоначальный SOC-алерт в Telegram. Когда аналитик нажимает на Observable, n8n обрабатывает callback, определяет анализатор, создает задание Cortex, ожидает отчет и отправляет результат в Telegram. Механизмы update_id, callback_query_id, suppression и job ID предотвращают повторное выполнение.

Поток обработки

Поток алертов

Генерация лога
  → Universal Forwarder
  → Splunk search/correlation
  → TheHive alert
  → n8n webhook
  → Telegram SOC Alert

Поток анализа Observable

Аналитик нажимает Observable в Telegram
  → Telegram callback
  → n8n немедленно отвечает на callback
  → повторное получение Observable из TheHive
  → проверка типа Observable и анализатора
  → Cortex создает задание
  → n8n ожидает и получает отчет
  → Telegram отправляет результат

n8n не запускает автоматически все Observable сразу при поступлении алерта. Анализатор запускается только по выбору аналитика, что снижает затраты, уменьшает повторные уведомления и сохраняет контроль над расследованием.

Возможности обнаружения

Базовые detection

Базовые detection находятся в config/splunk/core-savedsearches.conf, с lookup для исключения легитимной активности:

Use case CVE-2024-4577

Этот use case имеет два уровня:

• Фаза 1 анализирует URI Apache, многоуровневое декодирование и ищет комбинации endpoint PHP, необычную кодировку, опцию -d, чувствительные имена PHP INI или php://input. Это подозрительный сигнал.
• Фаза 2 сопоставляет с Windows Security/Sysmon в ограниченном окне времени. Подозрительный дочерний процесс, созданный php-cgi.exe, является сильным доказательством; файлы/реестр/сеть — вспомогательными доказательствами.

Метаданные правил в формате Sigma находятся в detections/sigma/cve-2024-4577-php-cgi-argument-injection.yml. Поиск, выполняемый в Splunk, находится в config/splunk/install-cve-detections.ps1.

Структура репозитория

config/
├── forwarder/       конфигурация input/output Windows и Linux
├── misp/             имитированные IOC для внутреннего поиска
├── n8n/              шаблон workflow TheHive–Telegram–Cortex
├── splunk/           saved search, lookup и скрипт корреляции
└── sysmon/           конфигурация телеметрии Windows
deploy/              шаблон Docker Compose с удаленными секретами
detections/
└── sigma/            метаданные правил, независимые от вендора
scripts/
├── splunk/           обновление поисков через API
├── validation/       проверка готовности
└── windows/          установка телеметрии на целевую лабораторную машину
docs/                 эксплуатационная документация и Telegram callback

Сопоставление между исходным кодом и живой системой находится в инвентаризации системы. Реальный манифест workflow n8n с удаленными секретами находится в config/n8n/live-workflow-manifest.json; небольшой шаблон импорта хранится отдельно для безопасного создания новой лаборатории.

Развертывание

Docker stack

cp deploy/docker-compose.soc.example.yml deploy/docker-compose.yml
cp .env.example .env
# Заполните секреты через secret manager или локальный файл .env.
docker compose -f deploy/docker-compose.yml config
docker compose -f deploy/docker-compose.yml up -d
docker compose -f deploy/docker-compose.yml ps

Шаблон Compose развертывает TheHive, Cortex, MISP, Cassandra, Elasticsearch, MinIO, Redis и модули MISP. n8n в настоящее время работает как host service, а конфигурация workflow находится в config/n8n/.

Windows и Splunk

# PowerShell Administrator на лабораторной Windows
.\scripts\windows\install-lab-telemetry.ps1

# На машине Splunk, не записывайте пароль в исходный код
$env:SPLUNK_PASSWORD = '<local-secret>'
.\config\splunk\install-cve-detections.ps1
python .\scripts\splunk\update-correlation-searches.py

# Проверка готовности
.\scripts\validation\check-system-readiness.ps1

n8n, TheHive, Cortex и MISP

1. Импортируйте шаблон workflow в n8n.
2. Создайте отдельные учетные данные для TheHive, Cortex и Telegram.
3. Настройте webhook TheHive, указывающий на n8n.
4. Проверьте, что в Cortex есть соответствующие анализаторы MISP/VirusTotal.
5. При необходимости импортируйте образцы IOC во внутреннее событие MISP.

Подробности callback находятся в docs/telegram-callback-setup.md.

Тестирование и оценка

Тестирование выполняется снизу вверх:

1. Apache/Sysmon генерируют логи.
2. Forwarder передает логи в Splunk.
3. Splunk возвращает результаты detection с правильным index/sourcetype.
4. TheHive получает алерт и Observable.
5. n8n получает webhook один раз.
6. Telegram получает SOC-алерт.
7. Callback создает ровно одно задание Cortex.
8. Telegram получает отчет MISP или VirusTotal.

Показатели, используемые в лаборатории: MTTD от события до обнаружения Splunk, MTTN от алерта до уведомления в Telegram, MTTR от получения алерта до triage/закрытия кейса, False Positive Rate и Duplicate rate.