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
- 用纯开源方案搭建生产级 SOC：Wazuh + DFIR-IRIS + 自研集成层实战记录
- How We Built a Real Security Operations Center With Open-Source Tools
- FarmScript：我们如何从零设计一门农业IoT领域特定语言
- FarmScript: How We Designed a Programming Language for Chanthaburi Durian Farmers
- 智慧农业项目为何止步于试点阶段
- Why Smart Farming Projects Fail Before They Leave the Pilot Stage
- ERP项目为何总是超支、延期，最终令人失望
- ERP Projects: Why They Cost More, Take Longer, and Disappoint More Than Expected
- AI Security in Production: What Enterprise Teams Must Know in 2026
- 弹性无人机蜂群设计：具备安全通信的无领导者容错网状网络
- Designing Resilient Drone Swarms: Leaderless-Tolerant Mesh Networks with Secure Communications
- NumPy广播规则详解：为什么`(3,)`和`(3,1)`行为不同——以及它何时会悄悄给出错误答案
- NumPy Broadcasting Rules: Why `(3,)` and `(3,1)` Behave Differently — and When It Silently Gives Wrong Answers
- 关键基础设施遭受攻击：从乌克兰电网战争看工业IT/OT安全
- Critical Infrastructure Under Fire: What IT/OT Security Teams Can Learn from Ukraine’s Energy Grid
- LM Studio代码开发的系统提示词工程：`temperature`、`context_length`与`stop`词详解
- LM Studio System Prompt Engineering for Code: `temperature`, `context_length`, and `stop` Tokens Explained
- LlamaIndex + pgvector: Production RAG for Thai and Japanese Business Documents
- simpliShop：专为泰国市场打造的按需定制多语言电商平台
- simpliShop: The Thai E-Commerce Platform for Made-to-Order and Multi-Language Stores
