Introduction

In a modern Security Operations Center (SOC), speed and consistency are everything. Manual triage is slow, inconsistent, and expensive. The solution is automated decision logic — a structured way to evaluate alerts and decide what action should happen automatically.

This article explains how to build automated decision systems using:

• Shuffle (SOAR platform)
• Wazuh (SIEM)
• DFIR-IRIS (Incident Response)
• PagerDuty (On-call alerting)
• A custom SOC Integrator (Django backend)

We’ll walk through concrete examples and recommended architecture.

---

Introduction to Shuffle Components

Before designing automated decision logic, it is important to understand the core components of Shuffle (SOAR platform) and how they work together.

1. Backend (Core Engine)

The backend is the automation engine. It:

• Executes workflows
• Handles triggers
• Manages app integrations
• Stores execution history

This is where the playbook logic actually runs.

2. Frontend (Web UI)

The web interface allows analysts and engineers to:

• Build workflows using drag-and-drop
• Configure integrations (API keys, credentials)
• Monitor execution logs
• Manage users and access control

It acts as the SOC automation control panel.

3. Apps (Integration Modules)

Apps are containerized connectors that allow Shuffle to interact with external systems such as:

• Wazuh (SIEM)
• DFIR-IRIS (Incident management)
• PagerDuty (On-call alerting)
• VirusTotal or threat intelligence platforms

Each app performs API calls and returns structured output back into the workflow.

4. Workflows (Playbooks)

Workflows define automation logic:

• Trigger (Webhook, schedule, manual)
• Conditions (IF/ELSE logic)
• Actions (API calls, enrichment, notifications)

Workflows are the brain of SOAR automation.

5. Orborus (App Runner)

Orborus is responsible for executing app containers. It connects the backend to Docker and ensures integration apps run securely and independently.

How Shuffle Components Work Together

Typical flow:

Wazuh → Webhook → Shuffle Backend → Workflow → App Execution → External Systems

Understanding these components makes it easier to design clean automated decision architecture.

---

What Is Automated Decision Logic?

Automated decision logic is a rule-based or score-based system that answers:

"Given this security alert, what should we do?"

Instead of an analyst deciding manually, the system decides:

• Ignore
• Enrich only
• Create incident case
• Create case + notify on-call
• Append to existing case

The goal is predictable, fast, and measurable incident handling.

---

Example Scenario: Suspicious VPN Login

Alert from Wazuh

A successful VPN login is detected with the following attributes:

• Country: Russia
• User: admin
• Severity: 12
• Source IP: 185.199.108.153

We want to automate the decision-making process.

---

Level 1: Simple IF / ELSE Decision

The most basic automation is condition-based.

Rule:

IF

• country != "Thailand"
• AND severity >= 10

THEN

• Enrich IP
• Create IRIS case
• Notify PagerDuty

ELSE

• Log and stop

This works well for early-stage SOC maturity.

---

Level 2: Risk Scoring Model (Recommended)

Single IF conditions are too rigid. A better approach is scoring.

Example Risk Model

Signal	Score
Country outside Thailand	+40
IP reputation malicious	+30
New user login	+25
Login at unusual hour	+15
MFA disabled	+20

Decision Threshold

• Score >= 70 → Critical (Create case + Page)
• Score 40–69 → Medium (Create case only)
• Score < 40 → Log only

This provides flexible and explainable automation.

---

Level 3: Stateful Decision (Correlation + Deduplication)

Advanced SOC systems must avoid duplicate cases.

Example rule:

"If the same IP triggered in the last 30 minutes, do not create a new case. Append to existing case instead."

This requires state management.

Options:

• Store correlation data in Django database
• Use Redis for temporary state
• Query IRIS before creating new case

This drastically reduces alert fatigue.

---

Recommended Architecture (Clean Separation)

The cleanest design is to separate responsibilities:

SOC Integrator (Django)

• Risk scoring
• Correlation
• Deduplication
• Decision output

Shuffle

• Workflow execution
• Calling integrations
• Trigger management

Flow

Wazuh → Shuffle Webhook → SOC Integrator /decide → Decision Response → Shuffle executes actions

Sequence Diagram (System Interaction)

sequenceDiagram
    autonumber

    participant WZ as Wazuh
    participant SH as Shuffle (Webhook/Workflow)
    participant SI as SOC Integrator (Django /decide)
    participant TI as Threat Intel (VT/AbuseIPDB)
    participant IR as DFIR-IRIS
    participant PD as PagerDuty

    WZ->>SH: POST Webhook (alert JSON)
    SH->>SI: POST /decide (normalized alert)
    SI-->>SH: Decision {ignore|enrich_only|create_case|create_case_and_page|append_case}

    alt decision == ignore
        SH-->>WZ: Tag/Comment: ignored + reason
    else decision == enrich_only
        SH->>TI: Enrich src_ip/domain
        TI-->>SH: Enrichment result
        SH-->>WZ: Tag/Comment: enriched + summary
    else decision == append_case
        SH->>IR: Add note to existing case (case_id)
        IR-->>SH: OK
        SH-->>WZ: Tag/Comment: appended_case + case_id
    else decision == create_case
        SH->>TI: Enrich src_ip/domain
        TI-->>SH: Enrichment result
        SH->>IR: Create case (title, description, severity)
        IR-->>SH: case_id
        SH-->>WZ: Tag/Comment: case_created + case_id
    else decision == create_case_and_page
        SH->>TI: Enrich src_ip/domain
        TI-->>SH: Enrichment result
        SH->>IR: Create case (title, description, severity)
        IR-->>SH: case_id
        SH->>PD: Trigger incident (critical) + case link
        PD-->>SH: incident_key
        SH-->>WZ: Tag/Comment: paged + case_id + incident_key
    end

This keeps business logic in code and automation in SOAR.

---

Example Decision API Response

Your SOC Integrator should return structured decisions:

Example 1 – Create case and page:

{
"decision": "create_case_and_page",
"severity": "critical",
"reason": "High risk VPN login",
"risk_score": 85,
"case_payload": {
"title": "Suspicious VPN Login – admin",
"description": "Login from Russia with malicious IP score"
}
}

Example 2 – Append to existing case:

{
"decision": "append_case",
"case_id": 1234,
"reason": "Repeated event within 30 minutes"
}

Example 3 – Ignore:

{
"decision": "ignore",
"reason": "Low risk score"
}

Shuffle simply branches based on "decision".

---

Why This Architecture Scales

Benefits:

• Version-controlled decision logic
• Testable scoring models
• Easier tuning over time
• Reduced false positives
• Clear audit trail

It also supports C1, C2, C3 service tiers:

C1 – Basic rule automation
C2 – Risk scoring + enrichment
C3 – Correlation + adaptive decision logic

---

Final Thoughts

Automated decision systems are not just about speed — they’re about consistency, scalability, and measurable security operations.

Start with simple IF rules.
Then implement scoring.
Then add correlation and state awareness.

That is how you move from reactive SOC to intelligent SOC.

---

If your organization is planning to implement automated decision systems or build a SOC Integrator layer, this architecture provides a practical and production-ready foundation.