Перейти до змісту

Технологічний стек SOC

Ця стаття описує 10 розгорнутих + 3 заплановані компоненти технологічного стеку SOC. Статус кожного позначений 🟢 Розгорнуто або 🟡 Заплановано (Tier 3 roadmap — Suricata / Grafana / Sigma rules).

!!! info "Стан станом на 2026-04-15" Tier 1 (базовий моніторинг) завершено 2026-04-13. Tier 2 (case management + SOAR + forensics) завершено 2026-04-14. TheHive downgrade з 5.5 на 4.1.24 AGPL виконано 2026-04-15. Tier 3 (мережевий IDS + executive dashboards + community rules) — у roadmap, не розгорнуто.


1. 🟢 Wazuh Agent

Що робить: Легкий агент на кожному сервері та робочій станції. Збирає: логіни, зміни файлів (FIM — File Integrity Monitoring), процеси, USB-підключення, вразливості.

Статус: 35 агентів Active (покриття — внутрішня інфраструктура; 800 робочих станцій ще не охоплені, це TASK-092g — "масштабування").

З'єднання:

  • → Відправляє всі зібрані дані до Wazuh Manager

2. 🟢 Wazuh Manager

Що робить: Мозок SIEM. Отримує дані від агентів та від FortiGate (через syslog), порівнює події з правилами детекції, генерує alert'и. Може автоматично блокувати загрози (Active Response).

Статус: CT702, Wazuh v4.14.4.

З'єднання (поточний реальний flow):

  • ← Отримує дані від Wazuh Agents (всі ендпоінти)
  • ← Отримує логи від FortiGate (файрвол)
  • → Зберігає alert'и в Wazuh Indexer (OpenSearch) — див. #3
  • → Викликає custom-thehive.py → створює Alert у TheHive (напряму через API, НЕ через Shuffle)
  • → Викликає custom-crowdsec-block.py → рішення в CrowdSec LAPI
  • → Викликає custom-teams.sh → сповіщення в Microsoft Teams

Заплановані з'єднання (ще не активні):

  • → Перевірка IoC (Indicators of Compromise) через MISP CDB lists (субтаск "MISP-to-Wazuh CDB sync cron" у TASK-092d subtask 28)
  • → Відправка alert'ів у Shuffle для оркестрації (Shuffle deployed, але playbook'ів ще нема — subtask 22 deferred)

3. 🟢 Wazuh Indexer (OpenSearch)

Що робить: Центральне сховище логів SIEM. Зберігає мільйони записів, шукає за секунди. 3-нодовий кластер: primary + 2 replicas для відмовостійкості. Це форк Elasticsearch — після зміни ліцензії ES у 2021 році OpenSearch став open-source альтернативою, підтримуваною AWS.

Статус: CT701 (primary), CT704 (replica 1), CT705 (replica 2). OpenSearch 2.x у складі Wazuh 4.14.4.

З'єднання:

  • ← Отримує alert'и та логи від Wazuh Manager
  • → Віддає дані в Wazuh Dashboard

!!! warning "Важливо: це НЕ єдиний ES/OpenSearch у SOC" У SOC stack є 3 окремі бази типу ES/OpenSearch (детально — розділ "Backend-бази" наприкінці статті):

- **Wazuh Indexer (OpenSearch)** — центральна БД security events (цей розділ)
- **Cortex ES 7.17** — внутрішня БД Cortex (див. #8)
- **Shuffle OpenSearch 2.18** — внутрішня БД Shuffle (див. #9)

Це окремі інстанси з окремими даними. Якщо хтось каже "перевір у ES" — уточнюй, у **якому саме**.

4. 🟢 Wazuh Dashboard

Що робить: Основний UI аналітика. Web-інтерфейс для alert'ів, графіків, карт атак, статусу агентів, vulnerability reports, compliance dashboards. Tier 1 аналітик проводить тут ~60% часу.

Статус: CT703, https://wazuh.nasbu.edu.ua.

З'єднання:

  • ← Читає дані з Wazuh Indexer (OpenSearch)

5. 🟢 MISP

Що робить: TIP (Threat Intelligence Platform) — каталог відомих шкідливих IP, доменів, хешів файлів, URL. Синхронізується з CERT-UA та іншими публічними фідами.

Статус: CT706 (Docker stack), MISP 2.5.36, https://misp.nasbu.edu.ua. У базі зараз ~570+ events.

Внутрішній стек MISP: Apache + PHP + MariaDB + Redis + misp-modules (все всередині Docker compose на CT706).

З'єднання:

  • ← Отримує threat feeds від CERT-UA та інших публічних джерел
  • ← Запитується TheHive hourly — MISP events імпортуються як TheHive Alerts
  • ← Запитується Cortex (analyzer MISP_2_1 — перевірка observable у локальному MISP)

Заплановане з'єднання:

  • → Експорт IoC у Wazuh CDB lists (TASK-092d subtask 28 — cron MISP→Wazuh)

6. 🟢 CrowdSec

Що робить: Колективний захист через blocklists. Локальний CrowdSec інстанс приймає рішення (decisions) — "забанити IP X на 4 години". Експортує decisions у форматі, який FortiGate підтягує як external threat feed і DROP'ить на WAN.

Статус: CT707, CrowdSec 1.7.7. LAPI на http://10.250.0.16:8080. blocklist-mirror експортує feed на http://10.250.0.16/security/blocklist.

З'єднання:

  • ← Отримує рішення про блокування від Wazuh Manager (через custom-crowdsec-block.py)
  • ← Опціонально: community blocklists з CrowdSec Network (централізовано не увімкнено, тільки локальні decisions зараз)
  • blocklist-mirror експортує feed → FortiGate підтягує як external-resource (refresh 1 хв) → Policy 137 DROP

7. 🟢 TheHive

Що робить: SIRP (Security Incident Response Platform) — журнал розслідувань. Серйозні alert'и стають case'ами. Хто розслідує, що знайшов, які дії вжив, які observables розібрав, який вердикт.

Статус: CT710 (Docker), TheHive 4.1.24 AGPL (downgraded з 5.5 на 2026-04-15 — причина OOM loop + license limits 2 users у Community 5.5). https://thehive.nasbu.edu.ua. Org Academy-SOC.

Внутрішнє сховище: BerkeleyJE (JanusGraph storage — локальна embedded граф-БД) + Lucene (локальний повнотекстовий пошук). Bind mount у /opt/thehive-data/. Не використовує зовнішній Elasticsearch (на відміну від TheHive 5.x).

З'єднання:

  • ← Отримує Alert'и напряму від Wazuh Manager (через custom-thehive.py, POST /api/v1/alert)
  • ← Синхронізує MISP events hourly → Alert'и (MISP connector у application.conf)
  • → Запускає enrichment через Cortex (Cortex connector у application.conf)

8. 🟢 Cortex

Що робить: Автоматичний enrichment engine. Перевіряє підозрілі IP/домени/хеші/URL через зовнішні аналізатори (VirusTotal, AbuseIPDB, MISP). Один клік у TheHive → Cortex запускає 3-5 аналізаторів паралельно → вердикт за 5-10 сек.

Статус: CT711 (Docker), Cortex 4.0.1-1. https://cortex.nasbu.edu.ua.

Внутрішнє сховище: Elasticsearch 7.17 (внутрішній single-node у CT711) — зберігає analyzer runs, users, config.

Активні аналізатори:

  • VirusTotal_GetReport_3_1 — 500 lookups/день free tier
  • VirusTotal_Scan_3_1
  • AbuseIPDB_2_0 — 1000 lookups/день free tier
  • MISP_2_1 — перевірка observable у нашому локальному MISP

Deferred: CyberChef_FromBase64/Hex/CharCode (TASK-092d subtask 21 — немає pre-built Docker image).

З'єднання:

  • ← Отримує запити на аналіз від TheHive (автоматично при кліку на observable)
  • → Запитує зовнішні API: VirusTotal, AbuseIPDB
  • → Запитує локальний MISP (CT706)

9. 🟢 Shuffle (поточний стан: idle)

Що робить: SOAR (Security Orchestration, Automation and Response) — диригент оркестру. Візуальні playbook'и: alert → авто-case → авто-enrichment → авто-block → аналітик отримує Teams notification.

Статус: CT712 (Docker), Shuffle :latest (2.2.0). https://shuffle.nasbu.edu.ua.

Внутрішнє сховище: OpenSearch 2.18 (security disabled) + Shuffle backend + Shuffle frontend (все в Docker compose на CT712).

!!! warning "Shuffle наразі НЕ у активному flow" Контейнер працює, UI доступний, але жоден playbook не написано (TASK-092d subtask 22 deferred). Реальний автоматичний flow зараз йде повз Shuffle: Wazuh Manager викликає custom Python/bash скрипти напряму (custom-thehive.py, custom-crowdsec-block.py, custom-teams.sh).

Коли playbook'и буде написано, Shuffle перейме цю роль від custom scripts. До того — Shuffle у stack для майбутнього використання.

Заплановані з'єднання:

  • ← Отримувати alert'и від Wazuh Manager
  • → Створювати case'и в TheHive
  • → Запускати enrichment у Cortex
  • → Відправляти notifications у Microsoft Teams
  • → Відправляти правила блокування в CrowdSec / FortiGate

10. 🟢 Velociraptor (сервер розгорнуто, клієнти — ні)

Що робить: DFIR (Digital Forensics & Incident Response) — форензика на вимогу. Збирає артефакти з (потенційно скомпрометованих) машин: процеси, файли, registry, memory. Масовий пошук ("hunt") по багатьох ПК одночасно — ключова фіча для великих deployment'ів.

Статус: CT713 (native Go binary + systemd, НЕ Docker), Velociraptor 0.76.2. https://velociraptor.nasbu.edu.ua.

!!! warning "Агенти ще не розгорнуті" Velociraptor server працює, GUI доступний. Але Velociraptor клієнти на ендпоінтах ЩЕ НЕ встановлені (TASK-092d subtask 26 — Phase 1 Linux інфраструктура / Phase 2 Linux production / Phase 3 Windows AD відкладено до PX3 migration).

Без клієнтів — Velociraptor не може виконувати hunts. Зараз це фактично порожній сервер, що чекає підключення агентів.

З'єднання (заплановані після Phase 1 deployment):

  • ← Отримує завдання на hunt/collection від SOC-аналітика (web UI)
  • → Збирає артефакти з ендпоінтів (через Velociraptor клієнти)

11. 🟡 Suricata (заплановано — Tier 3)

Що робить: NIDS (Network Intrusion Detection System) — спостерігач мережевого трафіку. Бачить те, що host-based Wazuh агенти не можуть: спроби експлойтів, комунікації з C2 серверами, DNS tunneling, lateral movement на мережевому рівні.

Статус: ❌ НЕ розгорнуто. У BACKLOG як TASK-092e.

Блокер: потребує SPAN port (mirror port) на core L3 switch Edgecore. Якщо SPAN недоступний — Suricata не має що слухати, компонент не розгортається взагалі.

Заплановане з'єднання:

  • ← Захоплює мережевий трафік (через span port / TAP)
  • → Відправляє alert'и у Wazuh Manager через log integration

12. 🟡 Grafana (заплановано — Tier 3)

Що робить: Executive dashboards для керівництва. Кількість атак за місяць, вразливі сервери, compliance status. Для SOC Manager'а / CISO / керівництва, не для щоденної роботи Tier 1 аналітика.

Статус: ❌ НЕ розгорнуто. TASK-092e. Потребує окремого CT (план: на PX7, 1c / 1GB / 10GB).

Заплановані з'єднання:

  • ← Читає metrics з Wazuh Indexer (OpenSearch)
  • ← Опціонально: Prometheus / node_exporter для infrastructure metrics

13. 🟡 Sigma Rules (заплановано — Tier 3)

Що робить: Бібліотека detection-правил у community форматі. Тисячі правил для виявлення відомих атак: використання mimikatz, lateral movement, ransomware patterns. Правила універсальні (YAML), через конвертер трансформуються у формат конкретного SIEM.

Статус: ❌ НЕ імпортовано. TASK-092e. Потребує конвертер sigma → Wazuh rules format.

Заплановане з'єднання:

  • → Імпортується у Wazuh Manager як додаткові rule sets (100+ community rules)

Backend-бази у SOC стеку (щоб не плутати)

Оскільки кілька компонентів використовують ES/OpenSearch як внутрішнє сховище — зведемо окремо:

Компонент Backend Що зберігає Де живе Як дивитись
Wazuh Indexer OpenSearch 2.x (cluster) Security events, alerts, логи — центральна БД SIEM CT701+704+705 через Wazuh Dashboard
Cortex Elasticsearch 7.17 (single-node) Analyzer runs, users, config внутрі CT711 тільки через Cortex UI
Shuffle OpenSearch 2.18 (single-node, security disabled) Workflow state, execution logs внутрі CT712 тільки через Shuffle UI
TheHive 4.1 BerkeleyJE + Lucene (embedded) Cases, alerts, observables, tasks внутрі CT710 bind mount тільки через TheHive UI
MISP MariaDB + Redis Threat events, attributes, feed metadata внутрі CT706 тільки через MISP UI
CrowdSec SQLite + BoltDB Local decisions, metrics внутрі CT707 через cscli CLI

Висновок: термін "ElasticSearch" у SOC контексті — неоднозначний. Майже завжди мається на увазі Wazuh Indexer (центральна БД security events). Якщо виникає сумнів — уточнюй.


Останнє оновлення: 2026-04-15. Стаття відображає стан після Tier 2 deployment (2026-04-14) + TheHive 5.5→4.1.24 downgrade (2026-04-15). Tier 3 компоненти (Suricata / Grafana / Sigma) — у roadmap TASK-092e, ще не розгорнуті.