สร้าง Security Operations Center (SOC) ใช้งานจริง ด้วย Open Source ทั้งระบบ

เบื้องหลังการสร้าง SOC ระดับ production สำหรับองค์กรขนาดกลาง โดยใช้ Wazuh, DFIR-IRIS และ middleware ที่เขียนเองด้วย Python — สิ่งที่ใช้ได้จริง สิ่งที่พังกลางทาง และเหตุผลทางวิศวกรรมที่สำคัญ

ถ้าคุณเคยขอใบเสนอราคา SIEM หรือ SOC platform เชิงพาณิชย์ คุณคงพอเดาได้ — ค่า license อย่างเดียวบางครั้งสูงกว่าเงินเดือนทีม analyst ที่ใช้งานเสียอีก ด้วยเหตุนี้ SOC แบบ open-source จึงน่าสนใจ แต่ปัญหาคือ การทำให้เครื่องมือเหล่านี้ทำงานร่วมกันอย่างเป็นระบบเดียว นั่นแหละคือจุดที่หลายโปรเจกต์ไปไม่ถึงปลายทาง

บทความนี้คือบันทึกจากสนามจริง ไม่มี SaaS ไม่มี cloud lock-in ทุกอย่างรันบน Docker บนเซิร์ฟเวอร์ของลูกค้าเอง และต้นทุน software รวมเป็น 0 บาท

โดยเฉพาะอย่างยิ่งสำหรับองค์กรในไทยที่ต้องปฏิบัติตาม PDPA และ พ.ร.บ. การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 การเก็บ log on-premises และมี audit trail ที่ตรวจสอบได้ ถือเป็นข้อกำหนดมากกว่าทางเลือก

ภาพรวมของระบบ

ส่วนงาน	เครื่องมือ	หน้าที่
Detection	Wazuh 4.x	เก็บ log, ถอดรหัส event, ออก alert จาก pattern ที่น่าสงสัย
Case Management	DFIR-IRIS	ที่ที่ analyst เข้าไป triage และปิดเคส
Integration	SOC Integrator (FastAPI)	middleware ที่เชื่อมทุกอย่างเข้าด้วยกัน
Threat Intel	VirusTotal + AbuseIPDB	เพิ่มข้อมูล IOC ให้ alert
Paging	PagerDuty	ปลุก on-call ตอนตี 3
Automation	Shuffle SOAR	workflow อัตโนมัติสำหรับ IOC
แหล่ง log	FortiGate, Windows AD, VMware ESXi, Sysmon	ระบบที่เรากำลัง monitor

ภาพรวมการสื่อสารระหว่างส่วนต่าง ๆ:

flowchart TD
    A["FortiGate / Windows AD / VMware / Sysmon"] -->|"syslog / agent"| B["Wazuh Manager"]
    B -->|"event และ alert"| C["Wazuh Indexer"]
    C -->|"poll ทุก 5 วินาที"| D["SOC Integrator (FastAPI)"]
    D -->|"enrich"| E["VirusTotal + AbuseIPDB"]
    D -->|"สร้าง alert"| F["DFIR-IRIS"]
    D -->|"ปลุก on-call"| G["PagerDuty"]
    D -->|"trigger workflow"| H["Shuffle SOAR"]
    F -->|"analyst triage"| I["KPI Dashboard"]

สิ่งที่ไม่ค่อยมีคนพูดถึงคือ ตัวเครื่องมือ open-source แต่ละตัวดีอยู่แล้ว แต่ไม่ได้ออกแบบมาให้ทำงานเป็น product เดียว Integration layer คือชั้นที่ทำให้รู้สึกว่าเป็นระบบเดียวกัน

ส่วนที่ 1 — Wazuh: จาก detection ทั่วไป สู่ detection ที่เข้ากับสภาพแวดล้อมของคุณ

Wazuh มาพร้อม rule ประมาณ 3,500 ข้อ ครอบคลุมเรื่องพื้นฐาน เช่น brute force, malware, process ที่ผิดปกติ แต่ rule กลาง ๆ จับได้แค่ภัยกลาง ๆ ถ้าจะ detect สิ่งที่สำคัญใน สภาพแวดล้อมจริงของคุณ — privileged account ของคุณ, IP range ของคุณ, pattern ที่ผิดปกติของคุณ — คุณต้องเขียน rule เอง

โครงสร้างไฟล์ rule

เราแยก rule ตาม use-case appendix ตามเอกสาร detection design ที่ลูกค้าเซ็นรับ:

wazuh_cluster/rules/
  soc-a1-ioc-rules.xml          # DNS / threat-intel hit
  soc-a2-fortigate-fw-rules.xml # firewall event
  soc-a3-fortigate-vpn-rules.xml# VPN event
  soc-a4-windows-ad-rules.xml   # Windows authentication
  soc-b1-vmware-rules.xml       # vCenter / ESXi
  soc-b2-logmon-rules.xml       # log-loss monitoring
  soc-c1-c3-rules.xml           # multi-stage correlation
  soc-ioc-cdb-rules.xml         # threat-intel CDB lookup

ทุก rule มีสองรูปแบบ: simulation (ใช้กับ test environment, ID ขึ้นต้น 100xxx) และ production (ปรับให้เข้ากับ traffic จริง, ID ขึ้นต้น 110xxx) ทั้งสองแบบอยู่ในไฟล์เดียวกัน เพื่อให้ test session เดียวครอบคลุมทั้งคู่

<!-- Simulation: trigger จาก JSON event ของ simulator -->
<rule id="100341" level="10">
  <if_sid>110350</if_sid>
  <description>A4-01 [SIM] Windows: privileged account auth failure</description>
  <group>soc_sim,a4,windows,auth,</group>
</rule>

<!-- Production: match field จาก Windows event log จริง -->
<rule id="110341" level="10">
  <if_group>windows</if_group>
  <field name="win.eventdata.targetUserName" type="pcre2">(?i)(admin|adm_|svc_|sa_|-adm)</field>
  <field name="win.system.eventID">^4625$</field>
  <description>A4-01 [PROD] Privileged account auth failure</description>
  <group>soc_prod,a4,windows,auth,</group>
  <mitre><id>T1110</id></mitre>
</rule>

รายละเอียดเล็ก ๆ ที่หลายคนพลาด: field `location`

เมื่ออุปกรณ์ส่ง syslog เข้า Wazuh โดยตรง (ไม่ลง agent) Wazuh จะตั้ง agent.name = wazuh.manager และเก็บ source IP ไว้ใน field ชื่อ location รายละเอียดนี้แทบไม่มีใน document และเราใช้เวลาหลายชั่วโมงกว่าจะรู้

VMware ESXi ที่รองรับเฉพาะ syslog ต้องกรองด้วย IP ใน location:

<rule id="110401" level="12">
  <if_group>vmware</if_group>
  <field name="location" type="pcre2">^172\.16\.0\.(107|108|109|110)$</field>
  <match>Login failure</match>
  <description>B1-01 [PROD] vCenter login failure</description>
  <mitre><id>T1110</id></mitre>
</rule>

ถ้าไม่ใส่ filter นี้ อุปกรณ์ใดก็ตามที่ส่ง string "Login failure" จะ trigger rule นี้ทันที กรองให้เหลือแค่ ESXi 4 เครื่องช่วยตัด false positive ทิ้งหมด

Chain rule ภายใน แทนที่จะสู้กับมัน

Event SSH ของ ESXi ผ่าน decoder sshd ของ Wazuh ไม่ใช่ decoder vmware ดังนั้น if_group=vmware จับไม่ได้ วิธีที่ถูกคือ inherit จาก rule ภายในที่ trigger อยู่แล้ว:

<rule id="110404" level="10">
  <if_sid>5715</if_sid>  <!-- rule SSH success ภายใน -->
  <field name="location" type="pcre2">^172\.16\.0\.(107|108|109|110)$</field>
  <description>B1-04 [PROD] ESXi SSH success — verify ว่าได้รับอนุญาต</description>
  <mitre><id>T1021.004</id></mitre>
</rule>

Rule 5715 ทำการ parse ให้แล้ว เราแค่จำกัด scope ลง

Threat intel ผ่าน CDB list

CDB (Constant Database) ของ Wazuh ใช้ค้นค่าใน flat file แบบ O(log n) เราดูแล 3 list — IP, domain, hash ที่เป็นภัย — และ integrator refresh ทุก 4 ชั่วโมง ดึงจาก VirusTotal และ AbuseIPDB เฉพาะ IOC ที่มี hit ยืนยันใน 30 วันล่าสุด

<rule id="110600" level="13">
  <if_sid>22101</if_sid>
  <list field="data.srcip" lookup="match_key">etc/lists/malicious-ioc/malicious-ip</list>
  <description>FortiGate source IP ตรงกับ threat-intel list</description>
  <mitre><id>T1071</id></mitre>
</rule>

กับดัก Docker ที่กินเวลาเรา

Docker image ของ Wazuh เก็บ rule ใน named volume ที่ mount ที่ /var/ossec/etc ถ้าใช้ docker cp หรือ sed -i แก้ไฟล์ rule จะเงียบหรือ error "Device or resource busy" — inode ของ named volume ชนะตลอด

วิธีเดียวที่ใช้ได้แบบ in-place โดยไม่ต้อง restart container คือเขียนผ่าน Python open().write() จากใน container:

docker exec wazuh.manager python3 -c "
with open('/var/ossec/etc/rules/soc-a4-windows-ad-rules.xml', 'w') as f:
    f.write('''<group name=\"soc_mvp,...\">...</group>''')
"
docker exec wazuh.manager /var/ossec/bin/wazuh-control reload

CI/CD pipeline ทุกตัวที่แตะ rule production ของ Wazuh ควรรู้เรื่องนี้

ส่วนที่ 2 — Integrator: ชั้นที่ทำให้กลายเป็น product

นี่คือชิ้นที่ทำให้ Wazuh, IRIS และเครื่องมืออื่น ๆ รู้สึกเป็นระบบเดียว ไม่ใช่ 4 ระบบแยกกัน เป็น FastAPI service ที่ทำหน้าที่ 5 อย่าง

1. Alert sync

ทุก 5 วินาที integrator query Wazuh indexer หา event ใหม่ที่ตรงกับ rule production (rule.id:[110301 TO 110602]), normalize, แล้วสร้าง alert ใน IRIS deduplication ใช้ composite key เพื่อไม่ให้ event เดิมท่วม queue

2. IOC enrichment

สำหรับ rule ที่เกี่ยวกับ threat intel integrator จะเรียก VirusTotal และ AbuseIPDB ก่อน สร้าง alert ใน IRIS analyst เปิด alert แล้วเห็นทันที — confidence score, ประเภทภัย, last-seen date ไม่ต้องสลับ tab ไม่ต้อง copy-paste

3. Multi-stage correlation

การโจมตีบางแบบเห็นได้ก็ต่อเมื่อมอง event หลายตัวพร้อมกัน Wazuh rule ไม่มี state เราจึงรัน correlation engine บน PostgreSQL ตัวอย่างคลาสสิกคือ impossible travel — VPN login ของ user คนเดียวกันจาก 2 เมืองที่ไกลเกินกว่าจะเดินทางถึงกันในเวลาที่ผ่านไป:

async def _detect_impossible_travel(self, event: dict) -> dict | None:
    # ... ดู login ก่อนหน้าของ user นี้ ...
    distance_km = haversine(loc1, loc2)
    min_hours = distance_km / 900  # ความเร็วเครื่องบินพาณิชย์สูงสุด
    actual_hours = (ts2 - ts1).total_seconds() / 3600
    if actual_hours < min_hours:
        return {"confirmed": True, "distance_km": distance_km, ...}

ถ้า login จากกรุงเทพฯ 10:00 น. และ Frankfurt 11:30 น. นั่นเป็นไปไม่ได้ Integrator ยืนยัน C1 detection และสร้าง alert ระดับสูงใน IRIS พร้อม login ทั้งสอง event แนบไปด้วย

4. Group deduplication

password spray ครั้งเดียว สามารถสร้าง Windows event 4625 ได้เป็นพันใน 1 ชั่วโมง ถ้าทุกตัวกลายเป็น IRIS alert queue จะไร้ประโยชน์ทันที ดังนั้นเรา group ด้วย (rule_id, user, host) พร้อม cooldown ต่อ rule:

_GROUP_DEDUP_RULES: dict[str, int] = {
    "110341": 2,   # privileged account auth fail — 2 ชม.
    "110342": 2,   # service account auth fail — 2 ชม.
    "110344": 4,   # auth fail จาก public IP — 4 ชม.
    "110347": 4,   # runas / privilege impersonation — 4 ชม.
    "110359": 1,   # password spray — 1 ชม.
}

Event แรกสร้าง 1 alert event ถัดมาภายใน cooldown แค่ update last_seen และ log เก็บไว้สำหรับการ forensic แต่ไม่สร้าง alert ซ้ำ จุดสำคัญคือ logic การกดทับ alert มีเอกสารชัดเจน ตรวจสอบได้ — ดูได้เลยว่า event ไหนถูกกดทับด้วยเหตุผลอะไร เป็นข้อสำคัญสำหรับการ audit ตาม พ.ร.บ. ไซเบอร์ฯ

5. KPI tracking ตาม SLA

ทุก alert มี SLA timer ตามระดับความรุนแรง:

Severity	เป้า SLA
Critical	1 ชั่วโมง
High	4 ชั่วโมง
Medium	8 ชั่วโมง
Low	24 ชั่วโมง

Dashboard IRIS แสดง progress bar live ต่อ alert — เขียวคืออยู่ใน SLA, เหลืองคือเกิน 75 %, แดงคือ breach ผู้บริหารได้ตัวเลขตรง ๆ analyst เห็นว่าอันไหนเร่งด่วนจริง

แต่ละ alert ยังมี triage guideline ที่ load จาก YAML ตอน startup:

guidelines:
  110346:
    use_case: "A4-06 — Auth success จาก public IP"
    steps:
      - "ระบุ user และ source IP ทันที"
      - "ตรวจสอบว่าเป็น remote work หรือ travel ที่คาดไว้หรือไม่"
      - "ดู privileged action ที่ตามมาใน session"
      - "ถ้าไม่ใช่: บังคับ logout, reset credentials, block IP"

Analyst เปิด alert แล้วเห็น playbook ทันที ไม่ต้องเปิด wiki runbook อีก

ทำไมต้องแยก service ไม่ใช้ active-response ของ Wazuh?

Wazuh มี framework "active response" ที่รัน script ตอน rule match เราไม่ใช้ ด้วย 4 เหตุผล:

State — correlation ต้องการ history active-response script ไม่มี state
Async I/O — เรียก VirusTotal และ AbuseIPDB พร้อมกันทำง่ายมากใน async Python ทำใน shell ลำบาก
Testability — integrator มี REST API จริง replay event ได้ด้วย POST /monitor/wazuh/ingest ตรวจสอบทุกการตัดสินใจได้
Decoupling — IRIS, PagerDuty, Shuffle เปลี่ยนได้หมด Wazuh ไม่รู้จักตัวไหนเลย

ปัญหา dashboard 27 วินาที

ช่วงแรกที่ขึ้น production dashboard KPI ของ IRIS โหลดนาน 27 วินาที เรียก endpoint ตรง ๆ เร็ว (128 ms) แต่ผ่าน proxy chain ช้า

สาเหตุ: ทุก DB call ใช้ psycopg.connect() ซึ่งเป็น blocking call (~34 ms ต่อครั้ง รวม TCP setup และ auth) Auto-sync ของเราประมวลผลประมาณ 437 event ทุก 5 วินาที โดยมี DB call 2 ครั้งต่อ event:

437 event × 2 DB call × 34 ms = ~30 วินาที ที่ event loop ถูก block

HTTP request ใดก็ตามที่เข้ามาในช่วงนั้น ต้องรอคิวอยู่หลัง sync วิธีแก้คือเปลี่ยน per-call connection เป็น persistent pool:

# ก่อน: เปิด TCP connection ใหม่ทุกครั้ง
@contextmanager
def get_conn():
    with psycopg.connect(db_dsn(), ...) as conn:
        yield conn

# หลัง: ยืมจาก pool — ประมาณ 1 ms ต่อครั้ง
_pool: ConnectionPool | None = None

def init_pool() -> None:
    global _pool
    _pool = ConnectionPool(db_dsn(), min_size=2, max_size=10, ...)

@contextmanager
def get_conn():
    with _pool.connection() as conn:
        yield conn

เวลา load dashboard: 27 วิ → 0.2 วิ บทเรียน: ใน FastAPI service ที่ทำงานกับ database ต่อ request ใช้ async pool ตั้งแต่วันแรก

ปิด feedback loop

เมื่อ integrator ยืนยัน multi-stage detection (เช่น impossible travel) มันส่ง syslog message กลับเข้า Wazuh Wazuh มี rule ที่ match message นี้ และ trigger level-15 alert ใน dashboard ของ Wazuh เอง analyst ทำงานบน Wazuh หรือ IRIS ก็เห็น event เดียวกัน ไม่มี tool ไหนเป็น "ตัวหลัก"

ส่วนที่ 3 — DFIR-IRIS: customize โดยไม่ต้อง fork

DFIR-IRIS แข็งแรงตั้งแต่กล่อง — alert, case, IOC, timeline, report เราขยายเพิ่ม 2 ทาง โดยแตะ source upstream แค่บรรทัดเดียว

KPI dashboard เป็น Flask blueprint

IRIS เป็น Flask app เพิ่มหน้าใหม่ตรงไปตรงมา — เขียน blueprint, register หนึ่งครั้ง จบ

@kpi_dashboard_blueprint.route('/kpi-dashboard')
@ac_requires(no_cid_required=True)
def kpi_dashboard(caseid, url_redir):
    return render_template('kpi_dashboard.html', csrf_token=generate_csrf())

@kpi_dashboard_blueprint.route('/kpi-dashboard/api/alerts')
@ac_api_requires(Permissions.alerts_read)
def proxy_list_alerts():
    content, status, _ = _soc_get('/iris/alerts', request.args)
    return Response(content, status=status, content_type='application/json')

Frontend ใช้ Alpine.js — เล็ก ไม่ต้อง build poll endpoint และ render alert table แบบ live พร้อม SLA timer และ assign แบบคลิกเดียว

Structured alert note

แทนที่จะเป็น text อิสระ ทุก IRIS alert มี JSON note ที่มีโครงสร้างชัดเจน:

{
  "rule": {
    "id": "110344",
    "description": "Windows auth failure จาก public IP",
    "mitre": ["T1110"]
  },
  "asset": {
    "hostname": "FPFTPSRV02",
    "ip": "172.16.10.50",
    "os": "Windows"
  },
  "network": {
    "src_ip": "91.202.x.x",
    "dst_ip": "172.16.10.50",
    "protocol": "TCP"
  },
  "guideline": {
    "use_case": "Auth fail จาก public IP",
    "steps": ["ระบุ source IP และ geo-location", "..."]
  }
}

note อ่านง่ายสำหรับคน และ machine-readable สำหรับ filter และ report analyst search ด้วย rule.id หรือ asset.hostname ได้ ผู้บริหาร group ตาม MITRE technique ได้ — มีประโยชน์ทั้งงาน operation และรายงาน compliance ตาม PDPA

Customize IRIS โดยไม่ fork

ความล่อใจคือ fork project, แก้ source, deploy ราคาที่ต้องจ่ายคือ 6 เดือนถัดไปเมื่อ upstream release version ใหม่ และ fork ของคุณดริฟต์ไกลเกินกว่าจะ merge

วิธีของเรา:

Custom blueprint ทุกตัวอยู่ใน directory ที่ bind-mount เข้า container
Frontend compile แยก inject เป็น static bundle
บรรทัดเดียวใน __init__.py ของ upstream เพื่อ register blueprint

บรรทัดเดียวนั้นคือสิ่งที่เรา re-apply ตอน IRIS release version ใหม่ ที่เหลือเป็น additive ทั้งหมด

ส่วนที่ 4 — บทเรียนจากการใช้งานจริง

Disk จะเซอร์ไพรส์คุณ

logall=yes ใน config Wazuh เก็บ event ที่ถูก decode ทุกตัว ไม่ใช่แค่ตัวที่ออก alert ดีสำหรับ forensic deep-dive แย่สำหรับพื้นที่ disk การ investigation VMware ครั้งเดียวดัน disk เราถึง 86 % ตอนนี้เราปิดไว้เป็น default และเปิดเฉพาะ window ที่ targeted:

<global>
  <logall>no</logall>
  <logall_json>no</logall_json>
</global>

หมายเหตุสำหรับการ comply PDPA: ระยะเวลาเก็บ log ควรเป็น policy ที่ชัดเจน ไม่ใช่ผลข้างเคียงของพื้นที่ disk

Coverage vs alert fatigue เป็น tunable ไม่ใช่ tradeoff

ความล่อใจคือ suppress rule ที่ noisy คำตอบที่ดีกว่าคือ pattern group dedup ข้างบน — ทุก event ยังถูก log แต่มีแค่อันแรกใน cooldown ที่สร้าง alert ได้ coverage ครบ มี audit trail และคิว analyst ใช้งานได้

Monitor SOC ของตัวเอง

Integrator ping dependency ของตัวเอง — Wazuh manager, Wazuh indexer, IRIS, Shuffle, PagerDuty — ทุก 2 นาที ถ้าตัวไหนล่ม สร้าง IRIS alert ใน category system-health analyst เห็น infrastructure failure ในคิวเดียวกับ security alert ไม่ต้องมี monitoring tool ตัวที่ 2

Email ยังเป็น notification หลักที่ไว้ใจได้

Critical IRIS alert trigger email ไปทีม SOC และ mailbox สำรอง พร้อม alert title, severity, asset และ link ตรงไปที่ alert dashboard ล่มได้ inbox ไม่ล่ม

ตัวเลข

ตัวชี้วัด	ค่า
Custom Wazuh rule	86 ข้อ ใน 8 ไฟล์
Production rule ที่ trigger	17 จาก 64
IRIS alert ที่ประมวลผล	91,000+
Auto-sync cycle	ทุก 5 วินาที
IOC list refresh	ทุก 4 ชั่วโมง
KPI dashboard load (ก่อนแก้)	27 วินาที
KPI dashboard load (หลังแก้)	0.2 วินาที
DB call overhead (ก่อน / หลัง)	34 ms / ต่ำกว่า 1 ms

สิ่งที่จะทำต่างไป ถ้าทำใหม่

Async database ตั้งแต่วันแรก psycopg.connect() แบบ sync ใน FastAPI app เป็น performance trap ที่จะระเบิดทีหลัง เริ่มด้วย psycopg_pool.AsyncConnectionPool ก่อนเขียน repository ไฟล์แรก

Wazuh rule testing ใน CI API rule_test รับ raw log line และคืน rule ที่ trigger wrap ใน pytest fixture แล้วจับ rule conflict ก่อนเข้า production

แยก port สำหรับ simulation และ production log เราใช้ syslog 514 ทั้งสองแบบ จึงต้องมี dual-profile rule ถ้าใช้คนละ port จะเรียบกว่า

สรุป

SOC ระดับ production บน open-source ล้วน ๆ ไม่ใช่แค่ทำได้ แต่เป็นวิศวกรรมที่ดีจริง ๆ แต่ตัว open-source อย่างเดียวยังไม่เป็น product ชั้น integration — ส่วนที่ไม่มีใคร market — คือที่ที่ SOC จริงอยู่

ถ้าคุณกำลังประเมิน SIEM เชิงพาณิชย์ และตัวเลข license ทำให้คุณอึดอัด stack นี้คือทางเลือกที่จับต้องได้ ความยากไม่ใช่เครื่องมือ ความยากคือกาวที่เชื่อม

สำหรับองค์กรไทยที่อยู่ภายใต้ พ.ร.บ. ไซเบอร์ฯ และ PDPA สถาปัตยกรรมแบบนี้ตอบโจทย์เพิ่มเติมคือ — log อยู่ใน data center ของคุณเอง audit trail ตรวจสอบได้ และไม่ต้องส่งข้อมูล sensitive ไป cloud ต่างประเทศ

ที่ Simplico เราสร้างระบบ security ระดับ production บนพื้นฐาน open-source ถ้าคุณกำลังออกแบบ SOC, modernize ระบบ detection หรือกำลังหาทางหนีค่า license SIEM ติดต่อเรา