Why We Designed a SOC Integrator Instead of Direct Tool-to-Tool Connections
Modern SOC stacks are powerful.
You can connect:
- Wazuh (Detection & Correlation)
- Shuffle (SOAR Automation)
- IRIS (Case Management)
- PagerDuty (Escalation & On-call)
But here’s the problem most organizations discover too late:
Direct integrations between tools become operational chaos.
Instead of connecting everything directly, we introduced a new architecture component:
SOC Integrator — an API Orchestration Layer
This article explains why this design decision matters.
The Problem with Direct Integrations
In many deployments, teams configure:
- Wazuh → Shuffle webhook
- Shuffle → IRIS case creation
- Wazuh → PagerDuty trigger
- Shuffle → PagerDuty escalation
- IRIS → Custom scripts
At first, it works.
Six months later:
- Duplicate alerts
- Conflicting severity levels
- Inconsistent case titles
- Broken workflows after rule tuning
- Hard-to-debug API errors
- No centralized audit trail of automation decisions
This becomes what we call SOC spaghetti architecture.
Our Design Decision: Introduce a SOC Integrator
Instead of tool-to-tool wiring, we implemented a single integration layer that:
- Receives alerts from Wazuh
- Normalizes and enriches them
- Applies customer-specific logic
- Calls the appropriate APIs
- Tracks every action
This component becomes the control plane of the SOC.
Architecture Overview
Logical Flow
Log Sources
↓
Wazuh (Detection & Correlation)
↓
SOC Integrator (API Orchestration Layer)
↓
├─ Shuffle (Automation / Enrichment)
├─ IRIS (Case Management)
└─ PagerDuty (Escalation)System Diagram (Mermaid)
flowchart LR
A["Log Sources
Firewall / DNS / IDS / VPN / Windows / AD"] --> B["Wazuh
Detection & Correlation"]
B --> S["SOC Integrator
API Orchestration Layer"]
S --> C["Shuffle
SOAR Automation"]
S --> D["IRIS (iris-web)
Case Management"]
S --> E["PagerDuty
On-call Escalation"]
C -->|"Enrichment / IOC Match Results"| S
S -->|"Create/Update Case + Evidence"| D
S -->|"SEV-1/SEV-2 Escalation"| E
S --> F["SOC Dashboard / Reporting
(Optional)"]Key principle:
All outbound actions go through one controlled integration module.
What the SOC Integrator Actually Does
1. Alert Normalization
Different rules generate different formats.
The SOC Integrator:
- Standardizes fields (src_ip, dst_ip, user, hostname, rule_id)
- Aligns severity levels (Low / Medium / High → SEV-3 / SEV-2 / SEV-1)
- Applies allowlists and suppression logic
- Deduplicates recurring events
This avoids:
- Duplicate PagerDuty incidents
- Multiple IRIS cases for the same root cause
- Alert storms during scanning events
2. Workflow Orchestration
Instead of configuring routing logic across multiple platforms, decisions are centralized:
- IOC hit → Trigger Shuffle enrichment workflow
- VPN login outside Thailand → Create IRIS case
- AD brute force + IOC match → Escalate to PagerDuty
All logic lives in one place.
This makes tuning and auditing dramatically easier.
3. Controlled Escalation
The SOC Integrator decides:
- Which events trigger PagerDuty
- Which severity maps to which escalation policy
- SLA tracking logic
- Re-open logic if an event repeats
This ensures executive-level incidents are not triggered accidentally due to poor rule tuning.
4. API Governance & Reliability
Enterprise SOC environments require:
- Retry logic
- Rate limiting
- Idempotency protection
- API credential rotation
- Full audit logging
Most SOAR playbooks do not enforce these standards strictly.
The SOC Integrator enforces production-grade API discipline.
Why This Matters for Customers
Easier Rule Tuning
When detection rules change, routing logic does not break.
Cleaner Incident Lifecycle
Cases are structured consistently with proper tagging and evidence mapping.
Reduced False Positives
Deduplication and contextual suppression are centralized.
Scalability
Adding new use cases (DNS IOC, VPN geo anomaly, Impossible Travel) requires minimal workflow rework.
Vendor Flexibility
If you change case management or SOAR platform later, you only rewrite one integration layer.
Strategic Perspective
Many integrators focus on:
"How do we connect tools?"
We focus on:
"How do we control detection flow as a system?"
That shift separates a proof-of-concept deployment from a production-ready SOC design.
Conclusion
Security tools are powerful individually.
But without orchestration control, they create noise.
By introducing a SOC Integrator API layer, we transformed a collection of tools into a structured, scalable security platform.
If you are designing a Wazuh-based SOC and want it production-ready — not just working — this architectural decision is critical.
Get in Touch with us
Chat with Us on LINE
iiitum1984
Related Posts
- The Price of Intelligence: What AI Really Costs
- 为什么你的 RAG 应用在生产环境中会失败（以及如何修复）
- Why Your RAG App Fails in Production (And How to Fix It)
- AI 时代的 AI-Assisted Programming：从《The Elements of Style》看如何写出更高质量的代码
- AI-Assisted Programming in the Age of AI: What *The Elements of Style* Teaches About Writing Better Code with Copilots
- AI取代人类的迷思：为什么2026年的企业仍然需要工程师与真正的软件系统
- The AI Replacement Myth: Why Enterprises Still Need Human Engineers and Real Software in 2026
- NSM vs AV vs IPS vs IDS vs EDR：你的企业安全体系还缺少什么？
- NSM vs AV vs IPS vs IDS vs EDR: What Your Security Architecture Is Probably Missing
- AI驱动的 Network Security Monitoring（NSM）
- AI-Powered Network Security Monitoring (NSM)
- 使用开源 + AI 构建企业级系统
- How to Build an Enterprise System Using Open-Source + AI
- AI会在2026年取代软件开发公司吗？企业管理层必须知道的真相
- Will AI Replace Software Development Agencies in 2026? The Brutal Truth for Enterprise Leaders
- 使用开源 + AI 构建企业级系统（2026 实战指南）
- How to Build an Enterprise System Using Open-Source + AI (2026 Practical Guide)
- AI赋能的软件开发 —— 为业务而生，而不仅仅是写代码
- AI-Powered Software Development — Built for Business, Not Just Code
- Agentic Commerce：自主化采购系统的未来（2026 年完整指南）
