What You'll Learn
- Connect Shuffle to the full CyberBlueSOC tool stack — Wazuh, TheHive, MISP, Velociraptor, and notification channels — via REST APIs and webhooks
- Configure API integrations including authentication methods (API keys, basic auth, OAuth tokens) and webhook endpoints
- Build multi-tool orchestration workflows that chain actions across SIEM, threat intel, case management, and endpoint platforms
- Design automated enrichment pipelines that aggregate context from VirusTotal, AbuseIPDB, and MISP for any IOC type
- Implement automated containment actions including firewall blocks, account disablement, and endpoint isolation via Velociraptor
- Build notification workflows across multiple channels (Slack, email, PagerDuty) with severity-based routing, and apply these skills in Lab 14.3
The Connected SOC
In Lesson 14.1, you learned what SOAR is. In Lesson 14.2, you built individual playbooks. Now you connect everything together. A SOAR platform that is not integrated with your tools is a workflow editor with no purpose. The real power emerges when every tool in your stack can trigger, query, and act through Shuffle.
The goal is a fully connected SOC where:
- Wazuh fires an alert → Shuffle automatically enriches, triages, and creates a case
- MISP publishes new IOCs → Shuffle automatically pushes them to Wazuh for detection
- TheHive case reaches containment stage → Shuffle automatically isolates the endpoint via Velociraptor
- Analyst approves a containment action in TheHive → Shuffle executes the block at the firewall
No tool operates in isolation. Every tool feeds data to and receives actions from the orchestration layer.
API Integration Fundamentals
Authentication Methods
Every tool in your SOC stack exposes a REST API. Connecting Shuffle to each tool requires proper authentication:
| Tool | Auth Method | Configuration |
|---|---|---|
| Wazuh | API user + password → Bearer token | Authenticate first, receive JWT, use token for subsequent calls |
| TheHive | API key | Static key in Authorization: Bearer {api_key} header |
| MISP | API key | Static key in Authorization: {api_key} header |
| Velociraptor | API key or mTLS certificate | Certificate-based auth for production; API key for lab |
| VirusTotal | API key | Key in x-apikey header |
| AbuseIPDB | API key | Key in Key header |
| Slack | Bot OAuth token | Authorization: Bearer xoxb-... |
Webhook Configuration
Webhooks are the primary mechanism for real-time event-driven automation. Configure each tool to send events to Shuffle:
Wazuh → Shuffle webhook:
<!-- ossec.conf integration block -->
<integration>
<name>shuffle</name>
<hook_url>https://shuffle.cyberbluesoc.local/api/v1/hooks/wazuh_webhook_id</hook_url>
<level>8</level>
<alert_format>json</alert_format>
</integration>
This configuration sends all Wazuh alerts with level 8 or higher to Shuffle via webhook. The alert_format: json ensures Shuffle receives structured data it can parse.
TheHive → Shuffle webhook (via notifications):
{
"name": "Shuffle Notification",
"endpoint": "https://shuffle.cyberbluesoc.local/api/v1/hooks/thehive_webhook_id",
"events": ["case_created", "case_updated", "alert_created"],
"format": "json"
}
API Rate Limits
Respect rate limits to avoid being throttled or blocked:
| Service | Rate Limit | Strategy |
|---|---|---|
| VirusTotal (free) | 4 requests/minute | Queue lookups, batch when possible |
| VirusTotal (premium) | 30 requests/minute | Still queue, but less delay |
| AbuseIPDB (free) | 1,000 checks/day | Cache results, skip re-checks within 24 hours |
| MISP (self-hosted) | No hard limit | Self-imposed: 60 requests/minute to avoid overload |
| Wazuh API | No hard limit | Self-imposed: 30 requests/minute |
Cache enrichment results. If the same IP appears in 50 alerts within an hour, do not query VirusTotal 50 times. Cache the first result and reuse it for subsequent alerts containing the same IOC. Implement a cache expiry of 1-24 hours depending on the source.
Multi-Tool Orchestration Workflows
Workflow 1: Alert-to-Case Pipeline
The most fundamental orchestration workflow — takes a raw SIEM alert and produces an enriched, triaged case:
[Wazuh Webhook: Alert Level >= 8]
↓
[Parse Alert] — Extract: source IP, dest IP, hostname, user, rule ID
↓
[Deduplication Check] — Has this IOC been enriched in the last hour?
↙ ↘
Cached Fresh
↓ ↓
Use cache [Enrichment Sub-Playbook]
↓ → VirusTotal lookup
↓ → MISP search
↓ → AbuseIPDB check (if IP)
↓ ↓
↓ [Cache Results]
↓ ↓
└───────────────┘
↓
[Severity Scoring]
Score = base_rule_level + intel_match_bonus + vt_detection_bonus
HIGH: score >= 15 | MEDIUM: score >= 10 | LOW: score < 10
↓
[TheHive: Create Case]
Title, description, severity, tags, observables — all auto-populated
↓
[Notification Router]
HIGH → Slack #soc-critical + PagerDuty + email to L2
MEDIUM → Slack #soc-alerts + email to L1 queue
LOW → Slack #soc-low-priority (no page)
Workflow 2: Automated Enrichment Pipeline
A dedicated enrichment pipeline that any workflow can call:
[Input: IOC type + value]
↓
[Router: What type?]
├── IP Address:
│ → VirusTotal IP report
│ → AbuseIPDB check
│ → MISP search
│ → MaxMind GeoIP lookup
│ → Shodan host info
│
├── Domain:
│ → VirusTotal domain report
│ → MISP search
│ → WHOIS lookup
│ → DNS resolution history
│
├── Hash (MD5/SHA256):
│ → VirusTotal file report
│ → MISP search
│ → MalwareBazaar lookup
│
└── URL:
→ VirusTotal URL scan
→ MISP search
→ URLhaus check
↓
[Aggregate Results]
Combine all source results into a single enrichment object
Calculate composite confidence score
↓
[Return Enrichment Object]
Each IOC type routes to the most relevant enrichment sources. The pipeline returns a standardized enrichment object regardless of input type.
Workflow 3: Automated Containment
Containment workflows take defensive actions. These require the most careful design because mistakes have immediate impact:
[TheHive: Case status changed to "Containment"]
↓
[Read Case Observables] — Get IOCs marked for blocking
↓
[For Each Observable marked "ioc"]:
├── IP Address → [Firewall: Add to block list]
│ → Verify block applied
│ → Log action to TheHive case
│
├── Domain → [DNS Sinkhole: Add to blacklist]
│ → Verify sinkhole active
│ → Log action to TheHive case
│
├── Account → [Active Directory: Disable account]
│ → Force password reset
│ → Revoke active sessions
│ → Log action to TheHive case
│
└── Hostname → [Velociraptor: Network Isolation]
→ Collect volatile evidence first
→ Apply network isolation
→ Verify isolation (no outbound connections)
→ Log action to TheHive case
↓
[Post-Containment Verification]
→ Verify all blocks applied
→ Verify endpoint isolation
→ Update TheHive case with containment evidence
↓
[Notify IR Team]
→ "Containment complete. X IPs blocked, Y accounts disabled,
Z endpoints isolated. Evidence collection in progress."
Automated containment requires human approval gates for critical systems. Automatically isolating a developer laptop is low-risk. Automatically isolating a production database server can cause a business outage. Implement approval workflows where the analyst confirms the action in TheHive before Shuffle executes it.
Velociraptor Integration for Endpoint Actions
Velociraptor provides powerful endpoint actions that Shuffle can orchestrate:
| Action | VQL / API Call | Use Case |
|---|---|---|
| Collect artifacts | collect(client_id, artifacts) | Gather forensic evidence before containment |
| Network isolation | execve(argv=["netsh","advfirewall","set","allprofiles","firewallpolicy","blockinbound,blockoutbound"]) | Block all network traffic except Velociraptor heartbeat |
| Kill process | process_tracker_kill(pid) | Terminate malicious process |
| Quarantine file | upload(accessor="file", path=malware_path) then delete | Upload malware to server for analysis, remove from endpoint |
| Hunt across fleet | hunt(description, artifacts, conditions) | Search all endpoints for the same IOC |
Containment with evidence preservation:
Step 1: Collect volatile artifacts
→ Windows.System.Pslist (running processes)
→ Windows.Network.Netstat (active connections)
→ Windows.System.DNSCache (recent DNS queries)
Step 2: Collect persistence artifacts
→ Windows.Sys.StartupItems
→ Windows.System.TaskScheduler
Step 3: Upload suspicious files
→ Upload malware binary for analysis
Step 4: Apply network isolation
→ Block all inbound/outbound except Velociraptor
Step 5: Verify isolation
→ Confirm no outbound connections remain
Notification Workflows
Severity-Based Routing
Not every alert deserves a page at 3 AM. Route notifications based on severity and type:
| Severity | Slack Channel | PagerDuty | When | |
|---|---|---|---|---|
| CRITICAL | #soc-critical | L2 + Management | Page on-call L2 | Confirmed active compromise |
| HIGH | #soc-alerts | L2 queue | Alert (no page) | High-confidence malicious activity |
| MEDIUM | #soc-alerts | L1 queue | None | Suspicious activity requiring triage |
| LOW | #soc-low-priority | None | None | Informational, investigate during business hours |
Structured Notification Template
[SEVERITY] — [CATEGORY] — [HOSTNAME]
Alert: [Rule description]
Source: Wazuh Rule [ID], Level [X]
Host: [hostname] ([IP])
User: [username]
Time: [timestamp UTC]
Intel: [MISP match / No match] | VT: [X/Y detections]
Verdict: [MALICIOUS / SUSPICIOUS / UNKNOWN]
TheHive Case: [#case_id] — [link]
Action Required: [Specific next step for analyst]
Multi-Channel Coordination
For major incidents, notifications must reach multiple channels simultaneously:
[Incident declared CRITICAL]
↓
[Parallel notifications]:
→ Slack #incident-war-room: Full technical context
→ PagerDuty: Page on-call L2 and IR lead
→ Email to CISO: Executive summary
→ TheHive: Update case status to "Active Incident"
→ Slack #soc-general: "Major incident in progress — war room active"
Measuring Automation Effectiveness
After deploying automation, measure its impact:
Metrics to Track
| Metric | Before Automation | Target After | How to Measure |
|---|---|---|---|
| Mean enrichment time | 4 min/alert | <10 sec/alert | Shuffle execution logs |
| Mean case creation time | 8 min/alert | <15 sec/alert | TheHive case timestamps vs alert timestamps |
| Mean time to contain | 2-4 hours | <15 min (with approval gate) | TheHive containment task timestamps |
| Alerts enriched per day | 50-100 (analyst capacity) | All alerts (100%) | Shuffle execution count vs Wazuh alert count |
| False positive rate | Unknown (alerts skipped) | Measured (all alerts triaged) | Verdict distribution in TheHive |
| Analyst time on repetitive tasks | 60-70% of shift | <20% of shift | Time tracking / survey |
Continuous Improvement Cycle
Month 1: Deploy enrichment + notification workflows
→ Measure: enrichment time, notification delivery, false positive rate
→ Tune: Adjust severity scoring, fix API errors, update templates
Month 2: Add automated case creation
→ Measure: case creation time, field accuracy, analyst satisfaction
→ Tune: Improve field mapping, add missing observables
Month 3: Add automated containment (with approval gates)
→ Measure: time-to-contain, approval turnaround, containment accuracy
→ Tune: Refine approval thresholds, add edge case handling
Month 6: Review all workflows
→ Compare metrics to pre-automation baseline
→ Identify new automation candidates from analyst feedback
→ Retire or refactor underperforming playbooks
Automate the measurement itself. Build a Shuffle workflow that runs weekly, queries TheHive for case metrics, queries Shuffle for execution metrics, compiles a summary, and posts it to Slack. If you are measuring automation effectiveness manually, you have not automated enough.
Building the Complete Automated SOC
When all integrations are connected, the automated SOC operates as a continuous pipeline:
┌─────────────────┐
│ Alert Sources │
│ Wazuh · Suricata│
└────────┬────────┘
↓
┌─────────────────┐
│ Shuffle │
│ (Orchestrator) │
└────────┬────────┘
↓
┌──────────────┼──────────────┐
↓ ↓ ↓
┌────────────┐ ┌────────────┐ ┌────────────┐
│ Enrichment │ │ Case │ │ Notification│
│ Pipeline │ │ Creation │ │ Router │
│ VT·MISP·AIPDB│ │ TheHive │ │ Slack·Email │
└──────┬─────┘ └──────┬─────┘ └──────┬─────┘
↓ ↓ ↓
┌────────────┐ ┌────────────┐ ┌────────────┐
│ Verdict │ │ Containment│ │ Metrics │
│ Logic │ │ Velociraptor│ │ Dashboard │
└─────────────┘ └─────────────┘ └─────────────┘
The analyst's role shifts from performing these steps manually to supervising the automation, handling exceptions, making complex decisions, and continuously improving the playbooks based on what they observe.
Key Takeaways
- Integration is what makes SOAR valuable — Shuffle must be connected to Wazuh (alerts), TheHive (cases), MISP (intel), Velociraptor (endpoints), and notification channels to provide real automation
- Configure webhooks for real-time event-driven automation (Wazuh alerts → Shuffle) and API calls for on-demand actions (Shuffle → TheHive case creation, Velociraptor isolation)
- Cache enrichment results to avoid redundant API calls and respect rate limits — the same IOC in 50 alerts should only be queried once
- Automated containment requires human approval gates for high-impact actions (production servers, executive accounts) while allowing full automation for low-impact targets
- Preserve evidence before containment — always collect volatile artifacts via Velociraptor before applying network isolation
- Route notifications by severity: CRITICAL gets paged, HIGH gets Slack + email, LOW gets logged — not every alert deserves a 3 AM page
- Measure automation effectiveness with concrete metrics (enrichment time, case creation time, coverage rate) and compare against the pre-automation baseline
- The analyst's role evolves from executing repetitive tasks to supervising automation, handling exceptions, and improving playbooks
What's Next
You have connected the full CyberBlueSOC stack through Shuffle and built orchestration workflows that automate enrichment, case creation, containment, and notification. In Lesson 14.4 — the Capstone, you will apply everything from the entire course — SIEM analysis, threat intelligence, endpoint investigation, detection engineering, incident response, and automation — in a comprehensive scenario that simulates a real-world security incident from initial detection through automated response and final reporting.
Knowledge Check: Integration & Orchestration
10 questions · 70% to pass
What authentication method does Wazuh use for API access via Shuffle?
In the Wazuh-to-Shuffle webhook configuration, what does the <level>8</level> setting control?
Why should you cache enrichment results rather than querying VirusTotal for every alert containing the same IOC?
Before applying network isolation to an endpoint via Velociraptor, what must be done first?
In Lab 14.3, you build a multi-tool orchestration workflow. What determines whether a CRITICAL alert triggers a PagerDuty page versus a Slack message only?
Why do automated containment workflows require human approval gates for critical systems like production database servers?
In the alert-to-case pipeline, how is automated severity scoring calculated?
After deploying automation, what metric shows whether enrichment automation is actually working?
In Lab 14.3, you connect Shuffle to Velociraptor for automated endpoint actions. Which action sequence correctly handles a confirmed malicious process?
What is the recommended continuous improvement timeline for deploying SOAR automation?
0/10 answered