บทนำ

ใน 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:

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"