บทนำ

ใน 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 ได้