วิธีสร้าง SOC แบบ Lightweight ด้วย Wazuh + Open Source

ทำไมโปรแกรมความปลอดภัยส่วนใหญ่ถึงล้มเหลวก่อนเริ่มต้น

"เราต้องการ SOC" ประโยคนี้มักได้ยินในทุกองค์กรที่เพิ่งถูกโจมตี ไม่ผ่านการตรวจสอบ หรือเพิ่งจ้าง CISO คนแรก สิ่งที่ตามมาคือการนำเสนอของ vendor SIEM เชิงพาณิชย์ ใบเสนอราคาหลักล้านบาท และ timeline การติดตั้ง 12 เดือน

ทีมส่วนใหญ่เดินออกจากห้องประชุมนั้นแล้วไม่ทำอะไรเลย

ความจริงที่น่าขันคือ Security Operations Center ที่ใช้งานได้จริง สามารถตรวจจับภัยคุกคาม แจ้งเตือนพฤติกรรมผิดปกติ จัดการ incident และรองรับข้อกำหนดของ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (PDPA) ได้ส่วนใหญ่ สามารถสร้างได้ด้วย open source tools ในราคาเพียงไม่กี่พันบาทต่อเดือนสำหรับค่า cloud VM

สิ่งที่ต้องลงทุนคือเวลาและความเชี่ยวชาญ ไม่ใช่งบประมาณ

คู่มือนี้จะพาคุณผ่านการสร้าง lightweight SOC stack โดยใช้ Wazuh เป็นแกนหลัก เครื่องมือเสริมที่ควรเพิ่ม วิธีเขียน detection rules ที่ใช้งานได้จริง และวิธีดำเนินการโดยไม่ทำให้ทีมความปลอดภัยขนาดเล็กหมดแรง

PDPA กับความจำเป็นของ SOC สำหรับธุรกิจไทย

ก่อนลงรายละเอียดทางเทคนิค ควรทำความเข้าใจว่าทำไม SOC ถึงไม่ใช่แค่ทางเลือก แต่เป็นสิ่งที่ธุรกิจไทยหลายแห่งต้องมี

พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) กำหนดให้ผู้ควบคุมข้อมูลและผู้ประมวลผลข้อมูลต้องดำเนินการ:

มาตรการรักษาความปลอดภัย (มาตรา 37): ต้องมีมาตรการทางเทคนิคและการบริหารจัดการที่เหมาะสมเพื่อป้องกันการสูญหาย เข้าถึงโดยไม่ได้รับอนุญาต ใช้งาน เปลี่ยนแปลง หรือเปิดเผยข้อมูลส่วนบุคคล
การแจ้งเหตุละเมิดข้อมูล (มาตรา 37(4)): ต้องแจ้ง PDPC ภายใน 72 ชั่วโมงหลังพบเหตุ และแจ้งเจ้าของข้อมูลโดยไม่ชักช้าในกรณีที่มีความเสี่ยงสูง
การเก็บ log และหลักฐาน: แม้ PDPA จะไม่ระบุรายละเอียดการเก็บ log โดยตรง แต่การพิสูจน์ว่า "ดำเนินมาตรการที่เหมาะสม" ต้องอาศัยหลักฐานเชิงเทคนิค ซึ่ง log และ audit trail คือหลักฐานสำคัญ

SOC ที่สร้างจากคู่มือนี้จะสร้าง audit trail ที่ต้องการ ตรวจจับการ breach ได้เร็วพอที่จะแจ้งภายใน 72 ชั่วโมง และสร้างหลักฐานเอกสารที่แสดงว่าองค์กรดำเนินมาตรการความปลอดภัยที่เหมาะสมแล้ว

สิ่งที่ lightweight SOC ต้องทำได้จริง

ก่อนเลือกเครื่องมือ ควรกำหนด minimum viable capability ก่อน lightweight SOC ต้องครอบคลุมสี่สิ่ง:

Visibility: รู้ว่าเกิดอะไรขึ้นบน endpoint, network และ cloud workload ของคุณ Log จากทุกที่ normalize เป็น format ที่ค้นหาและ query ได้

Detection: ระบุ event ที่บ่งชี้ว่ามีบางอย่างผิดปกติ การเข้าถึงโดยไม่ได้รับอนุญาต lateral movement การรันมัลแวร์ การขโมยข้อมูล misconfiguration

Alerting และ Triage: แสดง alert ที่ถูกต้องให้คนที่ถูกต้องพร้อม context เพียงพอสำหรับการตัดสินใจ ไม่ใช่ flood ของ noise และไม่ใช่ความเงียบ

Response: ลงมือทำ บล็อก IP แยก host เปิด case บันทึกสิ่งที่เกิดขึ้น

Stack ที่ใช้ในคู่มือนี้

Layer	เครื่องมือ	บทบาท
SIEM / XDR	Wazuh	Log collection, rule-based detection, FIM, vulnerability scanning, active response
Network IDS	Suricata	Network-level threat detection, protocol analysis
Threat intelligence	MISP	IOC management, threat sharing
Incident response	DFIR-IRIS	Case management, investigation tracking, analyst workflow
Automation (ทางเลือก)	Shuffle	SOAR-lite, webhook-based playbooks

ส่วนที่ 1: Wazuh — แกนหลักของทุกอย่าง

Wazuh คือกระดูกสันหลังของ stack นี้ ทำหน้าที่เป็น SIEM, XDR, Host-based Intrusion Detection System (HIDS), File Integrity Monitor (FIM), vulnerability scanner และ active response engine พร้อมกัน และเป็น free open source ทำให้เป็น anchor ที่ชัดเจนสำหรับ SOC ที่มีทรัพยากรจำกัด

สถาปัตยกรรมภาพรวม

flowchart TD
    subgraph Endpoints
        A1["Windows Agent"]
        A2["Linux Agent"]
        A3["macOS Agent"]
    end

    subgraph Network
        SUR["Suricata (IDS)\nวิเคราะห์ network traffic"]
        FW["Firewall / FortiGate / VPN\nSyslog forwarding"]
    end

    subgraph Wazuh Core
        MGR["Wazuh Manager\nRule engine · Decoder pipeline · Active response"]
        IDX["Wazuh Indexer\n(OpenSearch)"]
        DASH["Wazuh Dashboard\nAlerts · FIM · Vuln · Compliance · PDPA"]
    end

    subgraph Enrichment & Response
        MISP["MISP\nThreat intelligence · IOC feeds"]
        IRIS["DFIR-IRIS\nCase management · Investigation"]
        SHF["Shuffle (ทางเลือก)\nSOAR playbooks · Auto-triage"]
    end

    A1 -->|"Encrypted log stream"| MGR
    A2 -->|"Encrypted log stream"| MGR
    A3 -->|"Encrypted log stream"| MGR
    SUR -->|"EVE JSON via syslog"| MGR
    FW -->|"Syslog (UDP/TCP 514)"| MGR

    MGR -->|"Indexed alerts"| IDX
    IDX --> DASH

    MGR -->|"IOC lookup"| MISP
    MGR -->|"Alert webhook"| SHF
    SHF -->|"Create case"| IRIS
    MGR -->|"Direct integration"| IRIS

สิ่งที่ Wazuh ให้คุณทันทีหลังติดตั้ง

เมื่อ deploy Wazuh และเชื่อมต่อ agent ตัวแรก คุณจะได้รับทันที:

Log collection และ normalization จาก Windows Event Log, Linux syslog, macOS Unified Log และ application log format กว่าหลายสิบแบบ
MITRE ATT&CK mapping — ruleset เริ่มต้นของ Wazuh ผูก event หลายพันรายการกับ ATT&CK tactics และ techniques
File Integrity Monitoring (FIM) — แจ้งเตือน real-time เมื่อมีการเปลี่ยนแปลง file, directory, permission และ ownership
Security Configuration Assessment (SCA) — สแกน CIS benchmark อัตโนมัติบน endpoint พร้อม pass/fail ใน dashboard
Vulnerability detection — software inventory จาก agent เทียบกับฐานข้อมูล CVE ที่อัปเดตต่อเนื่อง
Active response — การดำเนินการอัตโนมัติที่กำหนดค่าได้เมื่อ rule ทำงาน เช่น บล็อก IP ผ่าน firewalld หรือ iptables kill process หรือรัน custom script

ติดตั้ง Wazuh

วิธีที่เร็วที่สุดคือ all-in-one install script บนเซิร์ฟเวอร์ Ubuntu 22.04

Minimum specs สำหรับ deployment ขนาดเล็ก (ถึง ~50 agents):

4 vCPU, 8 GB RAM, 100 GB SSD
Ubuntu 22.04 LTS
Open ports: 1514/UDP (agent communication), 1515/TCP (agent enrollment), 443/TCP (dashboard)

# ดาวน์โหลดและรัน Wazuh installation assistant
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
bash wazuh-install.sh -a

คำสั่งเดียวนี้ติดตั้ง Wazuh Manager, Indexer (OpenSearch) และ Dashboard บน host เดียวกัน สำหรับ production ที่มี agent มากกว่า 50 ตัว ควรแยกทั้งสามส่วนออกจากกัน

หลังติดตั้ง ดึง admin password:

tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

จากนั้นเข้าไปที่ https://YOUR_SERVER_IP แล้ว login ด้วย admin และ password ที่ได้

Enroll agents

Linux:

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor \
  -o /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
  https://packages.wazuh.com/4.x/apt/ stable main" \
  | tee /etc/apt/sources.list.d/wazuh.list
apt update && apt install -y wazuh-agent
WAZUH_MANAGER="YOUR_MANAGER_IP" WAZUH_AGENT_NAME="web-01" \
  dpkg-reconfigure wazuh-agent
systemctl enable --now wazuh-agent

Windows (PowerShell):

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.x.x-1.msi `
  -OutFile wazuh-agent.msi
msiexec /i wazuh-agent.msi /q `
  WAZUH_MANAGER="YOUR_MANAGER_IP" `
  WAZUH_AGENT_NAME="workstation-01"
NET START WazuhSvc

ส่วนที่ 2: เขียน Detection Rules ที่ใช้งานได้จริง

Ruleset เริ่มต้นของ Wazuh เป็นจุดเริ่มต้นที่ดี แต่ในทางปฏิบัติคุณต้องเขียน custom rules เพื่อตรวจจับภัยคุกคามเฉพาะที่สำคัญสำหรับ environment ของคุณ และ suppress noise ที่ไม่จำเป็น

วิธีที่ Wazuh rules ทำงาน

Wazuh ประมวลผล log event ทุกรายการผ่าน decoder pipeline ก่อน (ซึ่งแยก structured field จาก raw log text) จากนั้น evaluate event ที่ decode แล้วกับ rule tree Custom rules อยู่ใน /var/ossec/etc/rules/local_rules.xml

Rule severity level วิ่งจาก 0 ถึง 15 ระดับ 1–3 คือ informational, 4–6 คือ low, 7–11 คือ medium, 12–15 คือ high/critical เฉพาะระดับ 7 ขึ้นไปที่สร้าง alert ใน default configuration

ตัวอย่างที่ 1: ตรวจจับ SSH Brute Force

Rule นี้ทำงานเมื่อ source IP เดียวกันสร้าง failed SSH authentication มากกว่า 5 ครั้งภายใน 60 วินาที:

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="sshd,authentication_failed,">

  <rule id="100001" level="10" frequency="5" timeframe="60">
    <if_matched_sid>5716</if_matched_sid>
    <same_source_ip />
    <description>SSH brute force: มากกว่า 5 ครั้งใน 60 วินาที จาก $(srcip)</description>
    <mitre>
      <id>T1110.001</id>
    </mitre>
    <group>attack,brute_force,</group>
  </rule>

</group>

ตัวอย่างที่ 2: ตรวจจับ PowerShell ที่น่าสงสัย

Rule นี้ทำงานบน PowerShell invocation ที่มี obfuscation patterns ทั่วไป เช่น base64-encoded commands, download cradles หรือ execution policy bypass:

<rule id="100010" level="12">
  <if_group>windows,sysmon,</if_group>
  <field name="win.eventdata.commandLine" \
    type="pcre2">(?i)(FromBase64String|EncodedCommand|DownloadString|DownloadFile|bypass|hidden|WebClient)</field>
  <description>PowerShell ที่น่าสงสัย: พบ obfuscation หรือ download cradle</description>
  <mitre>
    <id>T1059.001</id>
  </mitre>
  <group>attack,execution,powershell,</group>
</rule>

หมายเหตุ: Rule นี้ต้องการ Sysmon ที่ติดตั้งบน Windows endpoint และ Wazuh Sysmon ruleset ที่โหลดแล้ว ติดตั้ง Sysmon ด้วย SwiftOnSecurity config สำหรับ coverage สูงสุด

ตัวอย่างที่ 3: Match IOC จาก CDB List

Wazuh รองรับ Constant Database (CDB) lists สำหรับการ lookup แบบรวดเร็ว pattern นี้ช่วย match log event กับรายการ malicious IP, domain หรือ hash ที่รู้จัก:

# สร้าง/อัปเดต IOC list
echo "185.220.101.45:" >> /var/ossec/etc/lists/malicious-ips
echo "194.165.16.11:" >> /var/ossec/etc/lists/malicious-ips

<rule id="100020" level="13">
  <if_group>firewall,</if_group>
  <list field="srcip" lookup="match_key">etc/lists/malicious-ips</list>
  <description>การเชื่อมต่อจาก IP ที่เป็นอันตราย: $(srcip)</description>
  <mitre>
    <id>T1071</id>
  </mitre>
  <group>attack,threat_intel,</group>
</rule>

Rule Tuning: Suppress False Positives

Wazuh deployment ใหม่ทุกตัวจะสร้าง alert ท่วมหน้าจอในสัปดาห์แรก ส่วนใหญ่เป็น false positive ใช้ <overwrite> rules เพื่อลด severity หรือ whitelist ด้วย <list>:

<!-- Suppress failed login จาก monitoring user ที่รู้จัก -->
<rule id="100030" level="0" overwrite="yes">
  <if_sid>5716</if_sid>
  <user>monitoring-svc</user>
  <description>Suppress: expected failed login จาก monitoring service account</description>
</rule>

วินัยสำคัญ: อย่า suppress ทั้ง rule class เลย Suppress เฉพาะเงื่อนไขที่เข้าใจชัดเจน บันทึกทุก suppression พร้อม justification และตรวจสอบทุกไตรมาส

ส่วนที่ 3: Suricata สำหรับ Network Visibility

Wazuh agent ให้ endpoint visibility ที่ดีเยี่ยม แต่ lateral movement, command-and-control traffic และการขโมยข้อมูลมักทิ้งร่องรอยบน network ที่ไม่เคยแตะ endpoint log Suricata ปิดช่องว่างนี้

Suricata คือ high-performance network IDS/IPS ที่ตรวจสอบ traffic แบบ real-time ผ่าน signature-based detection engine (compatible กับ Snort rules), protocol analyzer และ file extraction engine มัน output logs ในรูปแบบ EVE JSON ซึ่ง Wazuh ingest ได้โดยตรง

ติดตั้ง Suricata

# Ubuntu 22.04
add-apt-repository ppa:oisf/suricata-stable -y
apt update && apt install -y suricata

# ดาวน์โหลด Emerging Threats ruleset ล่าสุด
suricata-update

กำหนดค่า Suricata ให้ feed Wazuh

แก้ไข /etc/suricata/suricata.yaml เพื่อตั้ง interface ที่ monitor และเปิด EVE JSON output:

af-packet:
  - interface: eth0

outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      types:
        - alert
        - http
        - dns
        - tls
        - flow

จากนั้นกำหนดค่า Wazuh ให้ ingest EVE log ใน ossec.conf:

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

Wazuh มี built-in decoders และ rules สำหรับ Suricata EVE JSON อยู่แล้ว alert จะปรากฏใน dashboard ทันทีหลัง ingest พร้อม MITRE ATT&CK mapping

ส่วนที่ 4: MISP สำหรับ Threat Intelligence

Detection rule ที่ match malicious IP หรือ domain ที่รู้จักมีประโยชน์มากกว่า alert "anomalous connection" ทั่วไปหลายเท่า MISP (Malware Information Sharing Platform) คือ open source standard สำหรับจัดการและแชร์ threat intelligence ทั้ง IOC, threat actor profiles, malware samples และข้อมูล incident

ใน lightweight SOC, MISP ทำหน้าที่สองอย่าง: เป็น database ที่ analyst คัดสรร IOC และเป็น feed ที่เติมข้อมูลใน CDB list ที่ Wazuh ใช้สำหรับ real-time matching

รัน MISP

git clone https://github.com/MISP/misp-docker
cd misp-docker
cp template.env .env
# แก้ไข .env: ตั้ง MISP_BASEURL, admin email และ password
docker compose up -d

เชื่อมต่อ IOC Feeds ฟรี

MISP รองรับ automatic sync จาก public threat feeds feeds ฟรีที่ควรเปิดใช้ใน Settings → Feeds:

CIRCL OSINT Feed — IOC รอบด้านจาก Luxembourg’s national CERT
Abuse.ch URLhaus — URL แจกจ่ายมัลแวร์ที่ยังทำงานอยู่
Abuse.ch Feodo Tracker — botnet C2 IPs (Emotet, TrickBot, Qakbot)
AlienVault OTX — IOC จากชุมชน (ต้องการ API key ฟรี)

Automate IOC → Wazuh CDB Sync

#!/usr/bin/env python3
# misp_to_cdb.py — รันทุก 30 นาทีผ่าน cron
import requests, json, os

MISP_URL = "https://your-misp-instance"
MISP_KEY = "YOUR_API_KEY"
CDB_PATH = "/var/ossec/etc/lists/malicious-ips"

headers = {"Authorization": MISP_KEY, "Accept": "application/json",
           "Content-Type": "application/json"}

payload = {"returnFormat": "json", "type": "ip-dst",
           "tags": ["tlp:white", "tlp:green"], "limit": 5000}

r = requests.post(f"{MISP_URL}/attributes/restSearch",
                  headers=headers, json=payload, verify=False)
attrs = r.json().get("response", {}).get("Attribute", [])

with open(CDB_PATH, "w") as f:
    for attr in attrs:
        f.write(f"{attr['value']}:\n")

os.system("/var/ossec/bin/wazuh-logtest -U")  # reload CDB lists
print(f"Synced {len(attrs)} IOCs to {CDB_PATH}")

ส่วนที่ 5: DFIR-IRIS สำหรับ Case Management

Wazuh สร้าง alert, MISP ให้ context แต่ไม่มีเครื่องมือใดตอบคำถามว่า "ใครกำลังสืบสวน เขาพบอะไรแล้ว และสถานะปัจจุบันคืออะไร" นั่นคือสิ่งที่ DFIR-IRIS ทำ

DFIR-IRIS คือ open source collaborative incident response platform มี case management system พร้อม timeline, evidence tracking, asset register, IOC correlation, task assignment และ built-in integrations กับ MISP และ Wazuh เมื่อ alert ใน Wazuh ยกระดับเป็น incident case จะถูกเปิดใน IRIS และ analyst ทำงานสืบสวนที่นั่น

สิ่งนี้สำคัญมากในบริบทของ PDPA เพราะ IRIS สร้าง audit trail อัตโนมัติของกระบวนการสืบสวนทั้งหมด ถ้าองค์กรถูกถามจาก PDPC ว่า "ท่านจัดการ incident อย่างไร" IRIS คือเอกสารตอบคำถามนั้น

รัน DFIR-IRIS

git clone https://github.com/dfir-iris/iris-web
cd iris-web
cp .env.model .env
# แก้ไข .env: ตั้ง IRIS_ADM_PASSWORD และ IRIS_SECRET_KEY
docker compose up -d

เข้าถึงได้ที่ http://localhost:4433

เชื่อม Wazuh alert กับ IRIS case

#!/usr/bin/env python3
# iris_create_case.py — เรียกโดย Wazuh active response บน high-severity alerts
import sys, json, requests

IRIS_URL = "http://your-iris-instance:4433"
IRIS_API_KEY = "YOUR_IRIS_API_KEY"

alert = json.loads(sys.stdin.read())
rule_desc = alert.get("rule", {}).get("description", "Unknown")
agent_name = alert.get("agent", {}).get("name", "Unknown")
level = alert.get("rule", {}).get("level", 0)

if level < 12:
    sys.exit(0)  # สร้าง case อัตโนมัติเฉพาะ alert ระดับ high/critical

payload = {
    "case_name": f"[AUTO] {rule_desc}",
    "case_description": json.dumps(alert, indent=2),
    "case_customer": 1,
    "case_soc_id": alert.get("id", ""),
    "custom_attributes": {}
}

r = requests.post(f"{IRIS_URL}/manage/cases/add",
                  headers={"Authorization": f"Bearer {IRIS_API_KEY}"},
                  json=payload)
print(r.json())

ส่วนที่ 6: Shuffle สำหรับ Automation

Shuffle คือ open source SOAR platform ที่ใช้ visual workflow builder เชื่อมต่อ security tools ผ่าน webhook และ API ใน lightweight SOC มันทำหน้าที่เป็นชั้นกาว รับ Wazuh alert webhook, enrich กับ MISP, สร้าง IRIS case และแจ้ง analyst ผ่าน LINE Notify, Slack หรืออีเมล

Tip สำหรับทีมในไทย: Shuffle รองรับ webhook ออกไปยังทุก endpoint รวมถึง LINE Notify API ซึ่ง alert critical security incidents ผ่าน LINE group ของทีม SOC เป็นวิธีที่ได้ผลจริงในบริบทการทำงานของไทย

Deploy Shuffle

git clone https://github.com/Shuffle/Shuffle
cd Shuffle
docker compose up -d

เข้าถึงได้ที่ http://localhost:3001

Basic Triage Workflow

flowchart LR
    W["Wazuh\nAlert ระดับสูง\n(level ≥ 12)"] -->|"Webhook POST"| SHF

    subgraph Shuffle Workflow
        SHF["Trigger\nParse alert JSON"] --> ENR["Enrich\nLookup srcip ใน MISP API"]
        ENR --> DEC{"พบ IOC\nหรือเปล่า?"}
        DEC -->|"ใช่"| HIGH["ตั้ง severity = CRITICAL\nเพิ่ม MISP context"]
        DEC -->|"ไม่"| MED["คง severity = HIGH"]
        HIGH --> CASE["IRIS\nสร้าง case พร้อม context"]
        MED --> CASE
        CASE --> NOTIFY["แจ้ง analyst\nLINE Notify / Slack / Email"]
    end

เชื่อม Wazuh กับ Shuffle ด้วยการเพิ่มใน ossec.conf:

<integration>
  <n>shuffle</n>
  <hook_url>http://your-shuffle-instance:3001/api/v1/hooks/YOUR_HOOK_ID</hook_url>
  <level>12</level>
  <alert_format>json</alert_format>
</integration>

การดำเนินงาน SOC จริง

การมีเครื่องมือทำงานคือส่วนที่ง่าย การดำเนินงาน SOC อย่างมีประสิทธิภาพต้องการกระบวนการ ไม่ใช่แค่ infrastructure

Alert Triage SLA

กำหนด response time targets ก่อนเริ่ม โมเดลสามระดับที่เรียบง่าย:

ระดับ	Wazuh Level	เวลาตอบสนองเป้าหมาย	ตัวอย่าง
Critical	15	15 นาที	พบ Ransomware IOC, การขโมยข้อมูลที่ active
High	12–14	2 ชั่วโมง	Brute force สำเร็จ, privilege escalation
Medium	7–11	24 ชั่วโมง	Failed login ซ้ำๆ, process ที่น่าสงสัย
Low	4–6	รีวิวรายสัปดาห์	Policy violations, informational

กระบวนการทำงานของ Analyst รายวัน

Triage ตอนเช้า (30 นาที): รีวิว alert ระดับ high/critical จากคืนที่ผ่านมาใน Wazuh dashboard สำหรับแต่ละ alert: เป็น true positive หรือ false positive? True positive เปิด case ใน IRIS False positive เพิ่ม suppression rule พร้อมเอกสาร
IOC sweep (15 นาที): ตรวจ MISP สำหรับ feed ใหม่ที่ sync ข้ามคืน รีวิว IOC match ใหม่ใน Wazuh อัปเดต CDB list ถ้าจำเป็น
รีวิว open case (20 นาที): รีวิว active case ใน IRIS อัปเดต investigation notes, assign task, escalate หรือ close
Rule maintenance (ตามที่ต้องการ): หลังพบ false positive ใดๆ ใน triage ให้เขียน suppression rule ทันที อย่าปล่อยให้ noise สะสม

Metrics ที่สำคัญ

ติดตามรายสัปดาห์เพื่อรู้ว่า SOC กำลังพัฒนาขึ้นหรือเปล่า:

Mean Time to Detect (MTTD): เวลาเฉลี่ยจากเหตุการณ์เกิดขึ้นจนถึง alert ถ้าตัวเลขนี้สูงขึ้น log pipeline มีปัญหาความล่าช้า
Mean Time to Respond (MTTR): เวลาเฉลี่ยจาก alert จนถึง case ปิด ถ้าตัวเลขนี้สูงขึ้น ทีมมีปัญหา triage efficiency
False positive rate: จำนวน alert ที่ปิดเป็น false positive / alert ทั้งหมด เป้าหมายต่ำกว่า 20%
Coverage gaps: รีวิว MITRE ATT&CK Navigator รายเดือน Tactics และ techniques ใดที่ยังไม่มี detection rules ครอบคลุม ให้ prioritize เขียน rules สำหรับช่องว่างที่เกี่ยวข้องมากที่สุด

การจัดการ Alert Fatigue

Alert fatigue คือตัวทำลาย SOC program อย่างเงียบๆ เมื่อ analyst เผชิญกับ alert คุณภาพต่ำนับร้อยรายการต่อวัน พวกเขาจะเริ่มเพิกเฉยทุกอย่าง รวมถึงภัยคุกคามจริงด้วย

วิธีป้องกัน:

Tune อย่างจริงจังในสัปดาห์แรก ใช้เวลาสัปดาห์แรกเกือบทั้งหมดในการ suppress false positive alert stream ที่เงียบและมีความแม่นยำสูงมีค่ากว่า stream ที่ครอบคลุมแต่มี noise มาก
ตั้งเป้าหมายปริมาณ alert ทีม analyst หนึ่งหรือสองคนสามารถ triage ได้จริงประมาณ 20–50 alert ที่มีความหมายต่อวัน ถ้าสร้าง 500 รายการนั่นคือปัญหา tuning ไม่ใช่ปัญหา capacity
ใช้ level threshold Alert แบบ real-time เฉพาะระดับ 7 ขึ้นไป ระดับ 4–6 เข้า queue สำหรับรีวิวรายสัปดาห์
รีวิว suppression เป็นประจำ Suppression ที่ valid เมื่อสามเดือนก่อนอาจซ่อน attack vector จริงอยู่ในขณะนี้ ตรวจสอบทุก suppression rule ทุกไตรมาส

สิ่งที่ Stack นี้ไม่ครอบคลุม — และวิธีขยาย

SOC ที่สร้างจากคู่มือนี้จะจัดการภัยคุกคามส่วนใหญ่ที่องค์กรขนาดเล็กถึงกลางเผชิญ แต่มีช่องว่างที่ควรรู้

Cloud workloads: ถ้า infrastructure วิ่งบน AWS, GCP หรือ Azure เป็นหลัก เพิ่ม Wazuh cloud module integrations Wazuh ingest CloudTrail, AWS GuardDuty, Azure Activity Logs และ GCP Audit Logs ได้โดยตรง

Container และ Kubernetes: Wazuh agent รันเป็น DaemonSet ใน Kubernetes cluster ได้ สำหรับ container runtime visibility ที่ลึกกว่า ลองผสาน Falco เข้ากับ Wazuh

การเก็บ log ตาม PDPA: Wazuh เก็บ log เริ่มต้น 90 วัน PDPA กำหนดให้เก็บหลักฐานที่เกี่ยวข้องตามสมเหตุสมผล ซึ่งในทางปฏิบัติหลายองค์กรเก็บ 12 เดือน ขยาย retention ใน OpenSearch index lifecycle policy หรือ archive log เย็นไปยัง object storage

UEBA: Rule engine ของ Wazuh ยอดเยี่ยมสำหรับ signature-based detection แต่ support anomaly-based detection น้อย สำหรับ behavioral baselines ลองใช้ OpenSearch Anomaly Detection plugin ที่รันบน OpenSearch instance เดียวกันกับที่ Wazuh ใช้อยู่แล้ว

วิธีที่ Simplico สร้างสิ่งนี้ให้ลูกค้า

ที่ Simplico เรา deploy stack นี้หรือ variant ของมันให้กับลูกค้าที่ต้องการ security monitoring ที่ใช้งานได้จริงโดยไม่มีค่าใช้จ่ายและความซับซ้อนของ commercial SIEM งานของเราครอบคลุม:

Initial deployment และ hardening: All-in-one หรือ distributed Wazuh install, agent rollout บน endpoint และ server, Suricata บน network perimeter, MISP พร้อม feed configuration เริ่มต้น, DFIR-IRIS setup

Detection engineering: Custom decoder และ rule development สำหรับ environment เฉพาะของลูกค้า รวมถึง FortiGate log format, application stack, ERP และ ecommerce platform เราเขียน rule ไม่ใช่แค่ติดตั้ง

PDPA readiness documentation: เราส่งมอบเอกสารที่แสดงให้เห็นว่ามาตรการทางเทคนิคครอบคลุมข้อกำหนดของ PDPA อย่างไร รวมถึง incident response playbook สำหรับกระบวนการแจ้งเหตุภายใน 72 ชั่วโมง

Tuning sprints: สองสัปดาห์แรกหลัง deployment คือการ tuning อย่างหนัก เราติดตาม false positive ทุกรายการ เขียน suppression rule และลด alert volume ลงสู่ระดับที่จัดการได้ก่อนส่งมอบให้ทีมของลูกค้า

Runbook documentation: SOC ดีแค่ไหนขึ้นอยู่กับคนที่ดำเนินงาน เราส่งมอบ analyst runbook สำหรับ alert type ที่พบบ่อยที่สุด ว่าต้องตรวจอะไร triage อย่างไร escalate เมื่อใด และ close อย่างไร

ถ้าทีมของคุณกำลังประเมินว่าจะสร้าง security monitoring capability และต้องการหลีกเลี่ยงข้อผิดพลาดที่พบบ่อย ติดต่อ Simplico →

สรุป

การสร้าง lightweight SOC ด้วย open source tools เป็นสิ่งที่ทำได้จริงอย่างสมบูรณ์ ส่วนประกอบมีอยู่แล้ว integrate กันได้ดี และค่า infrastructure รวมสำหรับองค์กรขนาดเล็กอยู่ที่หลักพันบาทต่อเดือน ไม่ใช่หลักล้าน

การลงทุนอยู่ที่เวลาและความเชี่ยวชาญ Wazuh ใช้บ่ายวันหนึ่งในการติดตั้งและหนึ่งเดือนในการ tune ให้ดี MISP ต้องการการ curate feed อย่างต่อเนื่อง IRIS ต้องการ analyst ที่จะใช้มันจริงๆ เครื่องมือไม่ได้ดูแลตัวเอง

แต่สำหรับองค์กรที่ลงทุนนั้น ผลลัพธ์คือ security monitoring capability ที่ตรวจจับภัยคุกคามได้ทัดเทียม commercial solution สร้างหลักฐานเอกสารที่จำเป็นสำหรับ PDPA compliance และสามารถขยายและ customize ได้ในแบบที่ commercial SIEM ที่ล็อคอยู่ไม่เคยอนุญาต

การตัดสินใจหลักไม่ซับซ้อน:

เริ่มด้วย Wazuh อย่างเดียว tune ให้ดีก่อนเพิ่มเครื่องมืออื่น
เพิ่ม Suricata เร็วๆ network visibility จับสิ่งที่ endpoint agent พลาดได้
เพิ่ม MISP เมื่อมีคนดูแล IOC database ที่ไม่มีใครดูแลแย่กว่าไม่มีเลย
เพิ่ม IRIS เมื่อมี alert มากพอที่จะต้องการ case tracking อย่าเพิ่มวันแรก
เพิ่ม Shuffle เมื่อ triage workflow เสถียรพอที่จะ automate บางส่วน

สร้างแบบ incremental Tune อย่างต่อเนื่อง บันทึกเอกสารทุกอย่าง

Simplico คือบริษัทพัฒนาซอฟต์แวร์และผลิตภัณฑ์ที่ตั้งอยู่ในกรุงเทพฯ เชี่ยวชาญด้าน AI/RAG applications, security engineering, ecommerce integrations และ ERP connectivity สำหรับตลาดไทย ญี่ปุ่น และภูมิภาคเอเชียตะวันออกเฉียงใต้ เรียนรู้เพิ่มเติมได้ที่ simplico.net