Skip to content

SOC Technology Stack

This article describes 10 deployed + 3 planned components of the SOC technology stack. Each is marked 🟢 Deployed or 🟡 Planned (Tier 3 roadmap — Suricata / Grafana / Sigma rules).

!!! info "State as of 2026-04-15" Tier 1 (core monitoring) completed 2026-04-13. Tier 2 (case management + SOAR + forensics) completed 2026-04-14. TheHive downgrade 5.5 → 4.1.24 AGPL performed 2026-04-15. Tier 3 (network IDS + executive dashboards + community rules) — on the roadmap, not yet deployed.

1. 🟢 Wazuh Agent

What it does: Lightweight agent installed on every server and workstation. Collects login events, file changes (FIM — File Integrity Monitoring), processes, USB connections, vulnerability data.

Status: 35 agents Active (coverage: internal infrastructure; 800 workstations not yet enrolled — TASK-092g scale-out).

Connections:

  • → Sends all collected data to Wazuh Manager

2. 🟢 Wazuh Manager

What it does: The SIEM brain. Receives data from agents and FortiGate (via syslog), compares events against detection rules, generates alerts. Can automatically block threats using Active Response.

Status: CT702, Wazuh v4.14.4.

Current real-world flow:

  • ← Receives data from Wazuh Agents (all endpoints)
  • ← Receives logs from FortiGate (firewall)
  • → Stores alerts in Wazuh Indexer (OpenSearch) — see #3
  • → Invokes custom-thehive.py → creates Alert in TheHive directly via API (NOT through Shuffle)
  • → Invokes custom-crowdsec-block.py → pushes decision to CrowdSec LAPI
  • → Invokes custom-teams.sh → notifies Microsoft Teams

Planned connections (not yet active):

  • → IoC (Indicators of Compromise) check against MISP CDB lists (MISP-to-Wazuh sync cron — TASK-092d subtask 28)
  • → Send alerts to Shuffle for orchestration (Shuffle deployed but no playbooks yet — subtask 22 deferred)

3. 🟢 Wazuh Indexer (OpenSearch)

What it does: Central SIEM log storage. Stores millions of records, full-text search in seconds. 3-node cluster: primary + 2 replicas for fault tolerance. OpenSearch is a fork of Elasticsearch — after the 2021 license change, OpenSearch emerged as the AWS-supported open-source alternative.

Status: CT701 (primary), CT704 (replica 1), CT705 (replica 2). OpenSearch 2.x bundled with Wazuh 4.14.4.

Connections:

  • ← Receives alerts and logs from Wazuh Manager
  • → Serves data to Wazuh Dashboard

!!! warning "This is NOT the only ES/OpenSearch in the SOC" The SOC stack has 3 separate ES/OpenSearch instances (detailed in the "Backend databases" section at the end):

- **Wazuh Indexer (OpenSearch)** — central security events DB (this section)
- **Cortex ES 7.17** — Cortex's internal DB (see #8)
- **Shuffle OpenSearch 2.18** — Shuffle's internal DB (see #9)

Separate instances with separate data. If someone says "check in ES" — clarify **which one**.

4. 🟢 Wazuh Dashboard

What it does: Analyst's primary UI. Web interface for alerts, graphs, attack maps, agent status, vulnerability reports, compliance dashboards. A Tier 1 analyst spends ~60% of their time here.

Status: CT703, https://wazuh.nasbu.edu.ua.

Connections:

  • ← Reads data from Wazuh Indexer (OpenSearch)

5. 🟢 MISP

What it does: TIP (Threat Intelligence Platform) — catalog of known malicious IPs, domains, file hashes, URLs. Syncs with CERT-UA and other public threat feeds.

Status: CT706 (Docker stack), MISP 2.5.36, https://misp.nasbu.edu.ua. ~570+ events in DB.

MISP internal stack: Apache + PHP + MariaDB + Redis + misp-modules (all inside Docker compose on CT706).

Connections:

  • ← Receives threat feeds from CERT-UA and other public sources
  • ← Queried by TheHive hourly — MISP events imported as TheHive Alerts
  • ← Queried by Cortex (MISP_2_1 analyzer — checks observable against local MISP)

Planned connection:

  • → Export IoCs to Wazuh CDB lists (TASK-092d subtask 28 — MISP→Wazuh cron)

6. 🟢 CrowdSec

What it does: Collaborative defense via blocklists. Local CrowdSec instance accepts decisions ("ban IP X for 4 hours") from Wazuh alerts. Exports decisions in a format FortiGate pulls as an external threat feed and DROPs at WAN.

Status: CT707, CrowdSec 1.7.7. LAPI at http://10.250.0.16:8080. blocklist-mirror exports feed at http://10.250.0.16/security/blocklist.

Connections:

  • ← Receives block decisions from Wazuh Manager (via custom-crowdsec-block.py)
  • ← Optionally: community blocklists from CrowdSec Network (not centrally enabled; only local decisions currently)
  • → blocklist-mirror exports feed → FortiGate pulls as external-resource (1 min refresh) → Policy 137 DROP

7. 🟢 TheHive

What it does: SIRP (Security Incident Response Platform) — the investigation journal. Serious alerts become cases. Who investigates, what was found, actions taken, observables parsed, verdict reached.

Status: CT710 (Docker), TheHive 4.1.24 AGPL (downgraded from 5.5 on 2026-04-15 — reason: OOM loop + 2-user license limits in 5.5 Community). https://thehive.nasbu.edu.ua. Org Academy-SOC.

Internal storage: BerkeleyJE (JanusGraph storage — embedded local graph DB) + Lucene (local full-text index). Bind mount at /opt/thehive-data/. Does NOT use external Elasticsearch (unlike TheHive 5.x).

Connections:

  • ← Receives Alerts directly from Wazuh Manager (via custom-thehive.py, POST /api/v1/alert)
  • ← Hourly sync of MISP events → Alerts (MISP connector in application.conf)
  • → Runs enrichment via Cortex (Cortex connector in application.conf)

8. 🟢 Cortex

What it does: Automated enrichment engine. Checks suspicious IPs, domains, hashes, URLs across external analyzers (VirusTotal, AbuseIPDB, MISP). One click in TheHive → Cortex runs 3-5 analyzers in parallel → verdict in 5-10 sec.

Status: CT711 (Docker), Cortex 4.0.1-1. https://cortex.nasbu.edu.ua.

Internal storage: Elasticsearch 7.17 (internal single-node in CT711) — stores analyzer runs, users, config.

Active analyzers:

  • VirusTotal_GetReport_3_1 — 500 lookups/day free tier
  • VirusTotal_Scan_3_1
  • AbuseIPDB_2_0 — 1000 lookups/day free tier
  • MISP_2_1 — observable lookup in our local MISP

Deferred: CyberChef_FromBase64/Hex/CharCode (TASK-092d subtask 21 — no pre-built Docker image available).

Connections:

  • ← Receives analysis requests from TheHive (auto-triggered on observable click)
  • → Queries external APIs: VirusTotal, AbuseIPDB
  • → Queries local MISP (CT706)

9. 🟢 Shuffle (current state: idle)

What it does: SOAR (Security Orchestration, Automation and Response) — the orchestra conductor. Visual playbooks: alert → auto-case → auto-enrichment → auto-block → Teams notification.

Status: CT712 (Docker), Shuffle :latest (2.2.0). https://shuffle.nasbu.edu.ua.

Internal storage: OpenSearch 2.18 (security disabled) + Shuffle backend + Shuffle frontend (all in Docker compose on CT712).

!!! warning "Shuffle is currently NOT in the active flow" Container is running, UI is accessible, but no playbooks have been written yet (TASK-092d subtask 22 deferred). The current automated flow bypasses Shuffle: Wazuh Manager calls custom Python/bash scripts directly (custom-thehive.py, custom-crowdsec-block.py, custom-teams.sh).

Once playbooks are written, Shuffle will take over from the custom scripts. Until then — Shuffle sits in the stack awaiting future use.

Planned connections:

  • ← Receives alerts from Wazuh Manager
  • → Creates cases in TheHive
  • → Triggers enrichment in Cortex
  • → Sends notifications to Microsoft Teams
  • → Pushes block rules to CrowdSec / FortiGate

10. 🟢 Velociraptor (server deployed, clients not yet)

What it does: DFIR (Digital Forensics & Incident Response) — endpoint forensics on demand. Collects artifacts from (potentially compromised) machines: processes, files, registry, memory. Mass searches ("hunts") across many PCs — a key feature for large deployments.

Status: CT713 (native Go binary + systemd, NOT Docker), Velociraptor 0.76.2. https://velociraptor.nasbu.edu.ua.

!!! warning "Agents not yet deployed" The Velociraptor server is running and the GUI is accessible. But Velociraptor clients on endpoints are NOT YET installed (TASK-092d subtask 26 — Phase 1 Linux infrastructure / Phase 2 Linux production / Phase 3 Windows AD deferred until PX3 migration completes).

Without clients — Velociraptor cannot run hunts. For now it's effectively an empty server awaiting agent connections.

Connections (planned after Phase 1 deployment):

  • ← Receives hunt/collection tasks from SOC analyst (web UI)
  • → Collects artifacts from endpoints (via Velociraptor clients)

11. 🟡 Suricata (planned — Tier 3)

What it does: NIDS (Network Intrusion Detection System) — network traffic watcher. Sees what host-based Wazuh agents cannot: exploit attempts, C2 communications, DNS tunneling, network-level lateral movement.

Status: ❌ NOT deployed. Tracked in BACKLOG as TASK-092e.

Blocker: requires a SPAN port (mirror port) on the core L3 Edgecore switch. If SPAN is unavailable — Suricata has nothing to listen on, and the component is not deployed at all.

Planned connection:

  • ← Captures network traffic (via span port / TAP)
  • → Sends alerts to Wazuh Manager via log integration

12. 🟡 Grafana (planned — Tier 3)

What it does: Executive dashboards for management. Monthly attack counts, vulnerable servers, compliance status. Designed for SOC Manager / CISO / leadership — not for daily Tier 1 analyst work.

Status: ❌ NOT deployed. TASK-092e. Requires a dedicated CT (plan: on PX7, 1c / 1GB / 10GB).

Planned connections:

  • ← Reads metrics from Wazuh Indexer (OpenSearch)
  • ← Optionally: Prometheus / node_exporter for infrastructure metrics

13. 🟡 Sigma Rules (planned — Tier 3)

What it does: Community-maintained detection rule library. Thousands of rules for known attack techniques: mimikatz usage, lateral movement, ransomware behavior. Rules are vendor-neutral (YAML), converted to a specific SIEM's format via converter.

Status: ❌ NOT imported. TASK-092e. Requires a sigma → Wazuh rules format converter.

Planned connection:

  • → Imported into Wazuh Manager as additional rule sets (100+ community rules)

Backend databases in the SOC stack (to avoid confusion)

Since multiple components use ES/OpenSearch as internal storage — summarized separately:

Component Backend What it stores Where it lives How to view
Wazuh Indexer OpenSearch 2.x (cluster) Security events, alerts, logs — central SIEM DB CT701+704+705 via Wazuh Dashboard
Cortex Elasticsearch 7.17 (single-node) Analyzer runs, users, config inside CT711 only via Cortex UI
Shuffle OpenSearch 2.18 (single-node, security disabled) Workflow state, execution logs inside CT712 only via Shuffle UI
TheHive 4.1 BerkeleyJE + Lucene (embedded) Cases, alerts, observables, tasks inside CT710 bind mount only via TheHive UI
MISP MariaDB + Redis Threat events, attributes, feed metadata inside CT706 only via MISP UI
CrowdSec SQLite + BoltDB Local decisions, metrics inside CT707 via cscli CLI

Takeaway: the term "ElasticSearch" in SOC context is ambiguous. Usually refers to Wazuh Indexer (central security events DB). When in doubt — clarify which one.

Last updated: 2026-04-15. Reflects state after Tier 2 deployment (2026-04-14) + TheHive 5.5 → 4.1.24 downgrade (2026-04-15). Tier 3 components (Suricata / Grafana / Sigma) are on the TASK-092e roadmap but not yet deployed.