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:

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.