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 Integrator，而不是直接进行 Tool-to-Tool 集成
- 基于 OCPP 1.6 的 EV 充电平台构建 面向仪表盘、API 与真实充电桩的实战演示指南
- Building an OCPP 1.6 Charging Platform A Practical Demo Guide for API, Dashboard, and Real EV Stations
- 软件开发技能的演进（2026）
- Skill Evolution in Software Development (2026)
- Retro Tech Revival：从经典思想到可落地的产品创意
- Retro Tech Revival: From Nostalgia to Real Product Ideas
- SmartFarm Lite — 简单易用的离线农场记录应用
- OffGridOps — 面向真实现场的离线作业管理应用
- OffGridOps — Offline‑First Field Operations for the Real World
- SmartFarm Lite — Simple, Offline-First Farm Records in Your Pocket
- 基于启发式与新闻情绪的短期价格方向评估（Python）
- Estimating Short-Term Price Direction with Heuristics and News Sentiment (Python)
- Rust vs Python：AI 与大型系统时代的编程语言选择
- Rust vs Python: Choosing the Right Tool in the AI & Systems Era
- How Software Technology Can Help Chanthaburi Farmers Regain Control of Fruit Prices
- AI 如何帮助发现金融机会
- How AI Helps Predict Financial Opportunities
- 在 React Native 与移动应用中使用 ONNX 模型的方法
- How to Use an ONNX Model in React Native (and Other Mobile App Frameworks)
