Технологічний стек 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 tierVirusTotal_Scan_3_1AbuseIPDB_2_0— 1000 lookups/день free tierMISP_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, ще не розгорнуті.