บทนำ

ใน Security Operations Center (SOC) ยุคใหม่ “ความเร็ว” และ “ความสม่ำเสมอ” คือหัวใจสำคัญ การวิเคราะห์เหตุการณ์แบบ Manual นั้นช้า ไม่สม่ำเสมอ และมีต้นทุนสูง

ทางออกคือ Automated Decision Logic — โครงสร้างการตัดสินใจอัตโนมัติที่ประเมิน Alert และกำหนดการดำเนินการโดยไม่ต้องรอมนุษย์

บทความนี้อธิบายวิธีออกแบบระบบตัดสินใจอัตโนมัติโดยใช้:

• Shuffle (SOAR Platform)
• Wazuh (SIEM)
• DFIR-IRIS (Incident Response)
• PagerDuty (On-call Alerting)
• SOC Integrator แบบพัฒนาเอง (Django Backend)

เราจะอธิบายด้วยตัวอย่างจริงและสถาปัตยกรรมที่สามารถนำไปใช้งานได้จริง

---

ทำความเข้าใจองค์ประกอบของ Shuffle

ก่อนออกแบบระบบตัดสินใจอัตโนมัติ เราควรเข้าใจองค์ประกอบหลักของ Shuffle และการทำงานร่วมกันของแต่ละส่วน

1. Backend (Core Engine)

Backend คือหัวใจของระบบอัตโนมัติ ทำหน้าที่:

• รัน Workflow
• รับ Trigger
• จัดการ Integration App
• เก็บประวัติการทำงาน

นี่คือจุดที่ Playbook ถูกประมวลผลจริง

2. Frontend (Web UI)

หน้าเว็บสำหรับ:

• สร้าง Workflow แบบ Drag-and-drop
• ตั้งค่า API และ Credentials
• ตรวจสอบ Execution Log
• จัดการสิทธิ์ผู้ใช้งาน

เปรียบเสมือน Control Panel ของ SOC Automation

3. Apps (Integration Modules)

Apps คือ Connector ที่รันใน Container ใช้เชื่อมต่อระบบภายนอก เช่น:

• Wazuh (SIEM)
• DFIR-IRIS (Case Management)
• PagerDuty (On-call)
• VirusTotal หรือ Threat Intelligence Platform

แต่ละ App จะเรียก API และส่งผลลัพธ์กลับเข้า Workflow

4. Workflows (Playbooks)

Workflow คือ Logic ของระบบ ประกอบด้วย:

• Trigger (Webhook, Schedule, Manual)
• Condition (IF/ELSE)
• Action (Enrichment, สร้าง Case, แจ้งเตือน)

Workflow คือสมองของ SOAR

5. Orborus (App Runner)

Orborus ทำหน้าที่รัน Container ของ Apps และเชื่อมต่อ Backend กับ Docker เพื่อให้แต่ละ Integration ทำงานแยกจากกันอย่างปลอดภัย

การทำงานร่วมกันของ Shuffle

Flow ปกติ:

Wazuh → Webhook → Shuffle Backend → Workflow → App Execution → ระบบภายนอก

เมื่อเข้าใจส่วนประกอบเหล่านี้ จะสามารถออกแบบ Automated Decision Architecture ได้อย่างเป็นระบบ

---

Automated Decision Logic คืออะไร?

Automated Decision Logic คือระบบ Rule-based หรือ Score-based ที่ตอบคำถามว่า:

"เมื่อมี Security Alert นี้เข้ามา เราควรทำอะไรต่อ?"

แทนที่ Analyst จะตัดสินใจเอง ระบบจะตัดสินใจอัตโนมัติ เช่น:

• Ignore (ไม่ทำอะไร)
• Enrich เท่านั้น
• สร้าง Incident Case
• สร้าง Case + แจ้ง On-call
• Append เข้า Case เดิม

เป้าหมายคือการจัดการ Incident ที่รวดเร็ว สม่ำเสมอ และวัดผลได้

---

ตัวอย่างสถานการณ์: Suspicious VPN Login

Alert จาก Wazuh

ระบบตรวจพบการ Login VPN สำเร็จ โดยมีข้อมูล:

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

เราต้องการให้ระบบตัดสินใจอัตโนมัติ

---

ระดับที่ 1: IF / ELSE แบบพื้นฐาน

Rule:

IF

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

THEN

• Enrich IP
• สร้าง IRIS Case
• แจ้ง PagerDuty

ELSE

• บันทึก Log และจบ

เหมาะสำหรับองค์กรที่เพิ่งเริ่มต้นทำ Automation

---

ระดับที่ 2: Risk Scoring Model (แนะนำ)

การใช้ IF เดียวแข็งเกินไป ควรใช้ Scoring

ตัวอย่าง Risk Model

ปัจจัย	คะแนน
ประเทศนอกประเทศไทย	+40
IP มี Reputation อันตราย	+30
User ใหม่	+25
Login เวลาผิดปกติ	+15
ไม่มี MFA	+20

เกณฑ์การตัดสินใจ

• คะแนน >= 70 → Critical (สร้าง Case + Page)
• คะแนน 40–69 → Medium (สร้าง Case อย่างเดียว)
• คะแนน < 40 → Log เท่านั้น

แนวทางนี้ยืดหยุ่นและอธิบายได้

---

ระดับที่ 3: Stateful Decision (Correlation + Deduplication)

SOC ระดับสูงต้องลด Duplicate Case

ตัวอย่าง Rule:

"ถ้า IP เดิมเกิด Alert ซ้ำใน 30 นาที ไม่ต้องสร้าง Case ใหม่ ให้ Append เข้า Case เดิม"

ต้องมีการจัดเก็บ State เช่น:

• เก็บ Correlation ใน Django Database
• ใช้ Redis สำหรับ State ชั่วคราว
• Query IRIS ก่อนสร้าง Case ใหม่

ช่วยลด Alert Fatigue อย่างมาก

---

สถาปัตยกรรมที่แนะนำ (แยกหน้าที่ชัดเจน)

แยกความรับผิดชอบดังนี้:

SOC Integrator (Django)

• Risk Scoring
• Correlation
• Deduplication
• ส่งผลลัพธ์การตัดสินใจ

Shuffle

• รัน Workflow
• เรียก Integration ต่าง ๆ
• จัดการ Trigger

Flow

Wazuh → Shuffle Webhook → SOC Integrator /decide → Decision Response → Shuffle Execute 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

แนวทางนี้ช่วยให้ Business Logic อยู่ในโค้ด และ Automation อยู่ใน SOAR อย่างชัดเจน

---

ตัวอย่าง Decision API Response

SOC Integrator ควรส่งผลลัพธ์เป็นโครงสร้างที่ชัดเจน

ตัวอย่าง 1 – สร้าง Case และ 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"
}
}

ตัวอย่าง 2 – Append เข้า Case เดิม:

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

ตัวอย่าง 3 – Ignore:

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

Shuffle จะทำ Branch ตามค่า "decision"

---

ทำไมสถาปัตยกรรมนี้จึงขยายได้ในระดับองค์กร

ข้อดี:

• Logic อยู่ใน Version Control
• Test Scoring ได้
• ปรับ Tuning ได้ง่าย
• ลด False Positive
• มี Audit Trail ชัดเจน

รองรับ Service Tier เช่น:

C1 – Automation พื้นฐาน
C2 – Risk Scoring + Enrichment
C3 – Correlation + Adaptive Decision Logic

---

บทสรุป

Automated Decision System ไม่ได้มีเป้าหมายแค่ “เร็ว” แต่ต้อง “สม่ำเสมอ” และ “วัดผลได้”

เริ่มจาก IF ง่าย ๆ
พัฒนาไปสู่ Scoring
และเพิ่ม Correlation + State Awareness

นี่คือเส้นทางจาก Reactive SOC ไปสู่ Intelligent SOC

---

หากองค์กรของคุณกำลังวางแผนพัฒนา SOC Automation หรือสร้าง SOC Integrator Layer บทความนี้คือพื้นฐานที่สามารถนำไปใช้จริงใน Production ได้

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.

Continue reading “How to Build Automated Decision Logic in a Modern SOC (Using Shuffle + SOC Integrator)” →

现代 SOC（Security Operations Center，安全运营中心）通常由多种强大的安全工具组成。

例如：

• Wazuh（检测与关联分析）
• Shuffle（SOAR 自动化）
• IRIS（事件与案件管理）
• PagerDuty（告警升级与值班通知）

从技术上看，这些工具之间可以直接进行集成。

但许多组织在系统上线运行数月后，都会遇到同一个问题：

工具之间的直接集成会随着时间推移变得越来越复杂，最终难以控制。

因此，我们没有采用简单的工具直连模式，而是引入了一个关键架构组件：

SOC Integrator —— API 编排与控制层（API Orchestration Layer）

Continue reading “为什么我们选择设计 SOC Integrator，而不是直接进行 Tool-to-Tool 集成” →

現代のSOC（Security Operations Center）は非常に強力なツール群で構成されています。

例えば以下のような構成が可能です。

• Wazuh（検知・相関分析）
• Shuffle（SOAR自動化）
• IRIS（インシデント管理）
• PagerDuty（エスカレーション／オンコール対応）

しかし、多くの組織が運用開始から数か月後に直面する問題があります。

ツール同士を直接接続する構成は、時間とともに複雑化し、制御不能になりやすい という点です。

そこで私たちは、単純なツール間連携ではなく、以下のアーキテクチャを採用しました。

SOC Integrator — APIオーケストレーション層

Continue reading “なぜ私たちは Tool-to-Tool ではなく SOC Integrator を設計したのか” →

ระบบ SOC สมัยใหม่มีเครื่องมือที่ทรงพลังมาก

คุณสามารถเชื่อมต่อ:

• Wazuh (Detection & Correlation)
• Shuffle (SOAR Automation)
• IRIS (Case Management)
• PagerDuty (Escalation & On-call)

แต่ปัญหาที่หลายองค์กรพบหลังจากใช้งานไปสักระยะคือ:

การเชื่อมต่อแบบตรงระหว่างเครื่องมือหลายตัว ทำให้ระบบซับซ้อน ควบคุมยาก และขยายต่อได้ยาก

ดังนั้นแทนที่จะเชื่อมทุกอย่างเข้าหากันโดยตรง เราจึงออกแบบองค์ประกอบใหม่ในสถาปัตยกรรมชื่อว่า:

Continue reading “ทำไมเราจึงออกแบบ SOC Integrator แทนการเชื่อมต่อเครื่องมือแบบตรง ๆ (Tool-to-Tool)” →

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

Continue reading “Why We Designed a SOC Integrator Instead of Direct Tool-to-Tool Connections” →