CyberSecurity Foundation EP.29 — IDS / IPS / WAF / RASP: ตำรวจตรวจการในเมือง

Series: CyberSecurity Foundation — รากฐาน Security สำหรับยุค AI (ภาษาคน)

Part 0 — WHY: เมืองนี้ทำไมต้องมียาม

EP.01 — Cybersecurity คือเรื่องของคุณ

EP.02 — 4 เคสที่เปลี่ยนวงการ

EP.03 — CIA Triad

EP.04 — Defense in Depth + Diversity

EP.05 — Assume Breach + Risk

Part 1 — HOW: ระบบนิเวศของเมือง 6. EP.06 — ระบบนิเวศของโจร 7. EP.07 — ระบบนิเวศของผู้ป้องกัน 8. EP.08 — Framework: ISO/NIST/COBIT/CIS 9. EP.09 — Compliance Theater

Part 2 — Identity: บัตรประชาชน + กุญแจห้อง 10. EP.10 — IAM Lifecycle: เข้า / ย้าย / ออก 11. EP.11 — Authentication: 3 Factors + AAA 12. EP.12 — Password 101: MD5 / bcrypt / Salt / Pepper 13. EP.13 — MFA + Biometric 14. EP.14 — Kerberos 15. EP.15 — Federation + SSO 16. EP.16 — Authorization: RBAC / ABAC / MAC / DAC 17. EP.17 — PAM + Zero Trust

Part 3 — Data: ของในเซฟ 18. EP.18 — Data Classification + Lifecycle 19. EP.19 — Cryptography 101 20. EP.20 — Symmetric Crypto: AES 21. EP.21 — Asymmetric Crypto: RSA + DH 22. EP.22 — Hashing 23. EP.23 — PKI + Certificates 24. EP.24 — TLS / HTTPS 25. EP.25 — Email Security: SPF / DKIM / DMARC 26. EP.26 — Privacy Engineering

Part 4 — Infrastructure: ถนน กำแพง ท่อ 27. EP.27 — Network Foundation + Firewall 4 Generation 28. EP.28 — Segmentation + DMZ + Microsegmentation 29. EP.29 — IDS / IPS / WAF / RASP: ตำรวจตรวจการในเมือง ← คุณอยู่ตรงนี้

Part 4 (ต่อ) + Part 5-6 — กำลังเขียนต่อ

ครับ EP.27 เราติดตั้ง ป้อมยามหน้าหมู่บ้าน (firewall 4 รุ่น) ครบ EP.28 เรา แบ่งเมืองเป็นย่าน (segmentation + DMZ + microsegmentation) โจรเข้าย่านหนึ่งแล้ว ก็เข้าย่านอื่นไม่ได้ง่ายๆ ครับ

แต่มีคำถามที่ค้างใจครับ — ถ้าโจรผ่านป้อมยามไปแล้ว (เพราะปลอม pass + เพราะ phishing ลูกหลานยาม + เพราะ rule ของ firewall เปิด port ที่ควรปิด) — ใครจะเห็นเขาในเมือง?

ลองนึกฉากครับ — โจรปลอมเอกสารผ่านป้อมยามได้. เข้าเมืองมาแล้ว. เดินไปย่านโกดัง (ที่บริษัทเก็บข้อมูลลูกค้า). เริ่มงัดประตูโกดัง. ป้อมยามที่ประตูเมืองอยู่ไกลออกไป — ไม่เห็น. กำแพงระหว่างย่านก็อยู่นิ่ง — ไม่ตื่นกลางดึก

คำถาม — ใครจะรู้ว่ามีโจรกำลังงัดโกดัง?

คำตอบของเมืองจริงครับ — ตำรวจตรวจการ. เป็นคนที่ เดินตรวจ ในเมืองตลอดเวลา + ดู behavior ที่ผิดปกติ + report กลับห้องสายตรวจ + (บางที) เข้าไปจับ ด้วย

นี่คือเรื่องของ EP.29 ครับ — ในโลก security เรามี ตำรวจ 4 แบบ ที่ทำงานคนละบทบาท แต่ ใช้ร่วมกันเป็นชั้นๆ:

IDS (Intrusion Detection System) = ตำรวจที่เห็น + report แต่ไม่หยุดโจร
IPS (Intrusion Prevention System) = ตำรวจที่เห็นแล้ว block ทันที — แลกด้วย latency
WAF (Web Application Firewall) = ยามหน้าร้าน web — กรอง HTTP เฉพาะ Layer 7
RASP (Runtime Application Self-Protection) = ยามที่นั่งอยู่ในร้านเอง — เห็นสิ่งที่ยามหน้าร้านไม่เห็น

ลองนึก เมืองที่ของมีค่า ของเราอีกครั้งครับ. EP.27-28 เราติดตั้ง โครงสร้างคงที่ (firewall + segmentation). EP.29 นี้คือ คนที่เดินจริง ในเมือง — มี eyes + brain + (บางที) มี handcuff. โจรที่ผ่าน infrastructure ได้ ยังต้องผ่าน คน

เริ่มจากตำรวจที่เห็นแต่ไม่หยุดก่อนครับ — IDS — เพราะนี่คือชั้นพื้นฐานที่สุดที่ตำรวจอีก 3 แบบจะ build ทับลงไป

IDS — ตำรวจตรวจการที่เห็น + report แต่ไม่หยุดโจร#

ลองนึกภาพง่ายๆ ก่อนครับ. ตำรวจคนหนึ่งเดินตรวจในเมืองตลอดคืน. เขามี วิทยุ + กล้องบันทึก + สมุดจด. ถ้าเห็นใครทำท่าแปลก เขาจะ — บันทึก + รายงานกลับห้องสายตรวจ + ไม่เข้าไปจับเอง

นี่คือ IDS (Intrusion Detection System) — ระบบตรวจจับการบุกรุก ครับ. เน้นคำว่า Detection — มันแค่ เห็น + แจ้ง ไม่ block

อ้าว — ถ้าไม่ block แล้วเก็บไว้ทำไม? คำถามนี้สำคัญครับ. คำตอบมี 3 ข้อ:

Visibility — บริษัทคุณ เห็น ว่าโจรพยายามอะไรอยู่ — เห็น pattern ของ attack — เห็น insider ที่ทำผิดปกติ. ถ้าไม่มี IDS — โจรเข้าเมืองมา 6 เดือนแล้ว คุณยังไม่รู้ (industry average ของการ detect breach จากรายงาน IBM Cost of a Data Breach Report = ประมาณ 200 วัน — ครึ่งปี)
No false-positive impact — IDS แค่ report — ถ้าจับผิด (false positive) ก็แค่ alert ที่ผิด. ระบบที่ block แบบ aggressive (IPS) ถ้าจับผิด — service ดับ
Forensics + compliance — log ของ IDS เป็น หลักฐาน เวลาสืบคดี + ใช้ตอบ audit ของ ISO 27001 / PCI DSS

3 วิธีที่ตำรวจตรวจการดูออกว่าใครเป็นโจร#

ลองนึกง่ายๆ — ตำรวจดูออกว่าใครเป็นโจรได้ 3 ทาง: (1) จำหน้าโจรในแฟ้ม — เคยจับ เคยเห็น (signature). (2) เห็นพฤติกรรมแปลก — ตี 3 มีคนขนของออกจากโกดัง 5 ตัน ไม่ปกติ (anomaly). (3) จำสคริปต์อาชญากรรม — scan → phishing → ดึง credential → กระโดดเครื่อง = 4 step ของโจร (behavior)

ในโลก IDS:

Signature-based = Snort (open source) — มี rule database ของ payload ที่รู้จัก (เช่น string ' OR '1'='1). เร็ว + false positive ต่ำ — แต่ zero-day จับไม่ได้
Anomaly-based = Darktrace — เรียน baseline ของเมือง ด้วย ML แล้วเทียบ. จับ zero-day ได้ — แต่ false positive สูง + ต้อง learn หลายสัปดาห์
Behavior-based = CrowdStrike Falcon — รู้ TTP ของโจรตาม MITRE ATT&CK Framework + connect dots ข้าม step. แม่น + เห็น attack chain — แต่ แพง + complex

และเครื่องมือ enterprise อื่นๆ (Suricata, Microsoft Defender XDR, Palo Alto Cortex XDR, Vectra AI) ส่วนใหญ่ผสม ทั้ง 3 แบบ เข้าด้วยกัน — signature จับโจรเก่า / anomaly จับโจรใหม่ / behavior connect dot

มุมผู้บริหาร: ถ้าฝ่าย IT บอกคุณว่า “บริษัทเราติด IDS แล้ว — มี alert วันละ 10,000 ครั้ง” — นี่ไม่ใช่ข่าวดีครับ. ตามรายงาน Verizon DBIR / IBM Cost of a Data Breach Report — เวลาเฉลี่ยจาก breach ถึงตอน detect = ประมาณ 200 วัน. เหตุผลใหญ่ที่สุด = alert fatigue — analyst เห็น alert เยอะเกินจะตามไหว. คำถามที่ควรถามทีม IT — “ในแต่ละวัน เรา investigate alert กี่ %? mean time to detect (MTTD) เท่าไร? mean time to respond (MTTR) เท่าไร?” KPI ที่สำคัญ ไม่ใช่จำนวน alert — แต่เป็น ratio ของ alert ที่เราตามทันจริง + เวลาที่ใช้ตามจน close ticket ได้

IPS — ตำรวจที่เห็นแล้ว block ทันที (แลกด้วยอะไรบ้าง)#

ตำรวจตรวจการมีพี่น้องอีกคน — ตำรวจตั้งด่านหยุดรถ. ถ้าเห็นรถที่ดูน่าสงสัย ไม่แค่ report — เขา โบกให้หยุด + ตรวจค้น + ปฏิเสธไม่ให้ผ่าน

นี่คือ IPS (Intrusion Prevention System) — ระบบป้องกันการบุกรุก. ใช้เครื่องมือ detection แบบเดียวกับ IDS (signature + anomaly + behavior) — แต่ผลคนละแบบ

ความต่างของ IDS กับ IPS — เรื่องเดียวคือ placement (จุดติดตั้ง)

ลองนึก network diagram. IDS วางแบบ out-of-band — มันต่อกับ mirror port / SPAN port / network TAP ที่ copy traffic มาดู — traffic ของจริงยังวิ่งของมัน. IDS เห็น สำเนา

IPS วาง in-line — มันนั่งกลาง path ของ traffic จริง — ทุก packet ต้องผ่านมัน. มันตัดสิน — ส่งต่อ หรือ drop. มันเป็น gatekeeper ของจริง

Trade-off ที่ต้องเข้าใจ

ในเมื่อ IPS วาง in-line — มันมี 3 ราคา ที่ต้องจ่าย:

1. Latency (ดีเลย์) — ทุก packet ต้องผ่านการ inspect. ถ้า IPS ช้า — application ช้า. enterprise IPS เก่งๆ (Palo Alto, Fortinet, Cisco Firepower) วันนี้ inspect ได้ที่ multi-Gbps ด้วย latency หลัก μs (microsecond) — แต่ถ้า config ผิด หรือ rule เยอะเกิน — ก็ช้าได้

2. False positive = Service down — IPS จับผิด = block legitimate traffic = service ของลูกค้าเปิดไม่ได้. ลองนึก e-commerce กำลังจะกด ชำระเงิน — IPS เห็น HTTP request มี string ที่ดูเหมือน SQL injection (แต่จริงๆ ลูกค้าพิมพ์ description ที่มีคำว่า OR พอดี) — block. ลูกค้าชำระไม่ได้ — บริษัทขาดทุน

3. Single point of failure — ถ้า IPS ตาย — ทั้ง network ตาย (ถ้าวาง in-line ไม่มี bypass). enterprise IPS ที่ดีต้องมี fail-open mode (ตายแล้วปล่อย traffic ผ่าน — เสีย security แต่ service ยังอยู่) หรือ fail-closed mode (ตายแล้ว block ทุกอย่าง — security แน่นแต่ service ดับ) — ต้องเลือกตาม risk profile

Detection ปรับ tune ยังไง

ทีม security ใหม่ของบริษัท — มักทำ 2 strategy เมื่อติด IPS ครั้งแรก:

Phase 1: Monitor-only mode (IDS-mode) — เปิด IPS ในโหมด detect-only หลายเดือน. ดู alert. tune rule ที่ false positive เยอะ. ไม่ block อะไรเลย
Phase 2: Selective blocking — เปิด block เฉพาะ rule ที่ confidence สูง (signature ของ malware ที่รู้จัก + exploit ของ CVE สำคัญ). rule ที่ confidence ต่ำ คง alert-only ไว้

นี่คือ approach ที่ลด service-down incidence ได้มาก. องค์กรที่เปิด IPS แบบ all-blocking ตั้งแต่วันแรก — ส่วนใหญ่จบที่ปิด IPS ภายใน 3 เดือน เพราะ ทำให้ service ดับเยอะเกินจะรับ

IDS-only ดีเมื่อไร — IPS ดีเมื่อไร#

Scenario	Best fit
Network ของ R&D / engineering ที่ traffic แปลกๆ บ่อย	IDS — ไม่อยาก block ของจริง
Production e-commerce ที่ traffic standard	IPS — block known attack ทันที
DMZ ที่เผชิญ internet โดยตรง	IPS — internet hostile มาก
Internal LAN ระหว่าง office	IDS — ภายในไม่อยาก block พนักงาน
Compliance ที่ขอให้มี “detection capability”	IDS เพียงพอ
Compliance ที่ขอให้มี “prevention capability” (เช่น PCI DSS)	ต้อง IPS

ในความเป็นจริง — enterprise ใหญ่ใช้ทั้งคู่ — IPS at perimeter (ป้อมยามหน้าเมือง) + IDS internal (ตำรวจเดินตรวจในเมือง) — เพื่อให้ทั้ง prevent + visibility

มุมผู้บริหาร: pattern คลาสสิคของวงการ — บริษัทไทยขนาดกลางซื้อ IPS รุ่นเรือธงราคาหลักล้านบาท. ติดตั้งวันแรก เปิด rule ทุกชิ้นเป็น block mode. ผ่านไป 2 สัปดาห์ — e-commerce checkout มีปัญหา 12 ครั้ง — แต่ละครั้ง revenue หาย หลักแสน. CFO หัวร้อน. CISO ต้องอธิบายว่าทำไม security investment กลับทำให้ business ขาดทุน. คำถามที่ board ควรถามก่อนอนุมัติ IPS — “ทีม security เรามี change management process สำหรับ rule ของ IPS ไหม? ใครอนุมัติเปิด block? rollback plan เป็นยังไง? ในเดือนแรกเปิด monitor-only ก่อนใช่ไหม?” การไม่ถามคำถามพวกนี้ = เปิดประตูให้ self-inflicted outage

Network IDS/IPS vs Host IDS/IPS — ทำไมต้องใช้คู่กัน#

ตำรวจตรวจการมี 2 ทีม ที่ทำงานคนละมุม

ทีม 1 — Network-based (NIDS / NIPS) = ตำรวจที่เดินตามถนน. เขาเห็น ใครเดินผ่านถนนไปไหน — เห็น packet ที่วิ่งระหว่างเครื่อง — เห็น traffic ข้าม network boundary. แต่ — เขาไม่เห็นว่าในบ้านแต่ละหลังกำลังเกิดอะไร

ทีม 2 — Host-based (HIDS / HIPS) = ยามที่นั่งอยู่ในบ้านแต่ละหลัง. ติดตั้งเป็น agent ในแต่ละ server / laptop / endpoint. เห็น — process ที่ทำงานในเครื่อง + file ที่ถูกแก้ + registry change + system call. แต่ — เขาไม่เห็นว่าเครื่องอื่นในเมืองกำลังเกิดอะไร

ลองนึกตัวอย่าง 2 ฉากครับ

ฉาก 1 — NIDS เห็น HIDS ไม่เห็น

โจรอยู่นอกเมือง — ยิง port scan ไปยัง 100 servers ของบริษัท เพื่อหาช่องโหว่. NIDS ที่ network perimeter — เห็นชัด — มี IP เดียวยิง SYN packet ไปยัง port หลายร้อย port ใน 5 วินาที — แจ้งเตือน

แต่ HIDS ที่อยู่ใน server แต่ละตัว — เห็น เฉพาะ packet ที่ถึงตัวเอง — 1-2 packet จาก IP นั้น. ไม่รู้ว่า IP เดียวกันยิง 100 servers — ไม่เห็นภาพรวม

ฉาก 2 — HIDS เห็น NIDS ไม่เห็น

โจรเข้าเมืองสำเร็จแล้ว — login เป็น admin ของเครื่อง database. รัน command mimikatz.exe (tool ดูดรหัสจาก memory ของ Windows). แต่ — traffic ออกจากเครื่องไม่มี (mimikatz รันใน-memory ไม่ส่ง data ออก)

NIDS ที่ดู network ไม่เห็นอะไรเลย — เพราะ ไม่มี packet ผิดปกติ. แต่ HIDS ที่อยู่ในเครื่อง — เห็นชัด — มี process ใหม่ชื่อ mimikatz.exe ที่ access LSASS process memory — แจ้งเตือน

ใน 2 ฉากนี้ — ทั้งคู่จำเป็น. ถ้ามี NIDS อย่างเดียว — โจรที่อยู่ในเมืองแล้ว มองไม่เห็น. ถ้ามี HIDS อย่างเดียว — โจรที่ scan port ไม่เห็นรู้ตัวจนกว่าโจรจะเริ่มเข้าเครื่อง

HIDS รุ่นใหม่ — กลายเป็น EDR#

ในช่วง 5 ปีที่ผ่านมา HIDS วิวัฒนาการเป็น EDR (Endpoint Detection and Response) — CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint, Carbon Black เป็นยี่ห้อหลัก

EDR ต่างจาก HIDS เก่ายังไง:

เห็นมากกว่า — process tree, parent-child relationship, file hash, network connection, registry change — ทั้งหมดเป็น timeline
Behavior detection — ไม่ใช่แค่ signature — เห็นว่า Word.exe spawn cmd.exe ที่ spawn powershell.exe — pattern ของ malware
Response automation — auto-isolate เครื่อง + auto-kill process + auto-rollback file change (ransomware)
Cloud-native + lightweight — ไม่กิน CPU เครื่องเหมือน antivirus เก่า

ความท้าทาย — agent ต้องลง. server ที่ลง agent ไม่ได้ (legacy system, OT/ICS) — ไม่ได้ป้องกัน. ในเคสจริง — บริษัทที่มี EDR coverage 70-80% มักโดน breach ผ่านเครื่อง 20-30% ที่เหลือ — server เก่าๆ ที่ลง agent ไม่ได้

มุมผู้บริหาร: คำถามที่ถามทีม IT — “EDR ของเราครอบคลุมเครื่องกี่ % ของทั้งบริษัท?” ถ้าตอบ “98%” — ถามต่อ “2% ที่เหลือคือเครื่องอะไร — เครื่องสำคัญที่สุดของบริษัทรึเปล่า?” pattern คลาสสิคของวงการ — server ที่ critical ที่สุดมัก lap ไม่ได้ เพราะเป็น OS เก่าที่ vendor ไม่ support agent. นี่คือ blind spot ที่โจรเข้าผ่านได้สบาย. solution ไม่ใช่บังคับลง — แต่ต้อง compensating control = แยก network ของเครื่องพวกนั้น (กลับไปดู EP.28 — microsegmentation) + log traffic ทุกชิ้น + อ่าน vendor support roadmap ว่าจะ upgrade เมื่อไร

WAF — ยามหน้าร้านที่อ่าน HTTP เป็น (Layer 7 + OWASP Top 10)#

NIDS/NIPS เก่งครับ — แต่มี จุดบอด หนึ่งที่ใหญ่มาก. มันดู packet ระดับ Layer 3-4 (IP + TCP/UDP) เก่ง — แต่พอเป็น HTTP request (Layer 7) — มันเห็นแค่ “มี packet ขนาด 1.4KB ไปที่ port 443 ของ web server” — ไม่เข้าใจว่าใน HTTP body มี SQL injection payload อยู่

ลองนึก ตำรวจที่เก่งเรื่องรถบรรทุก — เขารู้ว่ารถพ่วงคันไหนหนักผิดปกติ — รู้ว่าใครวิ่งเลนสวน. แต่ — ถ้ารถบรรทุกขนของถูกกฎหมาย แล้วในลังของ ซ่อนยาเสพติด — ตำรวจคนนี้ตรวจไม่ออก

นี่คือเหตุที่เรามี WAF (Web Application Firewall) — firewall เฉพาะ web application. มันคือ ยามหน้าร้าน web ที่ เปิดลังของได้ + อ่าน HTTP เป็น + เข้าใจ context ของ web app

WAF ป้องกันอะไรบ้าง — OWASP Top 10#

OWASP (Open Web Application Security Project) เป็นองค์กรไม่แสวงผลกำไรที่จัดทำ Top 10 ของช่องโหว่ web app ที่พบบ่อยที่สุด — update ทุกๆ 3-4 ปี. Top 10 ปี 2021:

Broken Access Control — ผู้ใช้ A เห็น data ของผู้ใช้ B (เช่น เปลี่ยน URL จาก ?user=123 เป็น ?user=124)
Cryptographic Failures — เก็บ password เป็น plain text, ใช้ MD5 (กลับไปดู EP.22)
Injection — SQL injection, NoSQL injection, OS command injection
Insecure Design — design ผิดตั้งแต่แรก
Security Misconfiguration — เปิด admin console ให้ public, default password
Vulnerable Components — ใช้ library ที่มี CVE
Authentication Failures — brute force, credential stuffing
Software/Data Integrity Failures — supply chain attack (เคส SolarWinds)
Logging/Monitoring Failures — ไม่มี log = detect ไม่ได้
SSRF (Server-Side Request Forgery) — บังคับ server ไปร้อง URL ที่โจรกำหนด (เคส Capital One)

WAF เก่งที่สุดกับ #3 Injection + #10 SSRF + บางส่วนของ #1, #5, #7. ส่วน #2, #4, #6, #8, #9 WAF ช่วยไม่ค่อยได้ — ต้องแก้ที่ระดับ application

Vendor หลัก + Deploy 3 แบบ#

Cloud-based — Cloudflare WAF (SME + startup ใช้กันมาก — ราคาเอื้อม) / AWS WAF (สำหรับ workload บน AWS)
On-premise — Imperva (enterprise standard) / F5 Advanced WAF (ถ้าใช้ F5 load balancer อยู่แล้ว)
Open source — ModSecurity (free + ใช้กับ Apache/Nginx/IIS + มี OWASP CRS เป็น default rule)

และตัวอื่นๆ (Azure Front Door, Akamai Kona, Barracuda) ก็ยังมีในตลาด — เลือกตาม stack ที่บริษัทใช้อยู่

WAF ทำงานยังไง — 2 mode#

Negative security model (blacklist) — block สิ่งที่ดูเหมือน attack. default ของ OWASP CRS. ข้อเสีย — โจรหา bypass technique ใหม่ๆ ได้
Positive security model (whitelist) — allow เฉพาะที่ matched กับ specification ของ app. เช่น “endpoint /api/order รับเฉพาะ POST + JSON body ที่มี field product_id (int) + quantity (int 1-100)” — อะไรนอกนี้ block. แม่นมาก — แต่ต้องเขียน rule ตาม API spec ทุกชิ้น

ในความเป็นจริง — modern WAF ใช้ทั้งคู่ + machine learning ช่วยสร้าง baseline ของ application traffic

กับดักของ WAF — misconfig ทำลายทุกอย่าง#

WAF ที่ติดตั้งผิด = ของเล่น. 2 กับดักคลาสสิค:

1. Bypass via direct origin IP — WAF อยู่ข้างหน้า (เช่น Cloudflare) — แต่ web server origin มี public IP ที่ทุกคนเข้าได้. โจรหา origin IP เจอ — เลี่ยง WAF ตรงไปที่ server. fix — firewall ที่ origin allow เฉพาะ IP range ของ WAF service เท่านั้น

2. WAF ในโหมด “log-only” — ทีมติดตั้ง WAF แล้วเปิดเป็น monitor-only เพื่อ tune. ผ่านไป 6 เดือน — ยังไม่ได้เปลี่ยนเป็น block mode. WAF กลายเป็น expensive logging tool. นี่เป็น pattern ที่บริษัทไทยติดบ่อยมาก

มุมผู้บริหาร: WAF เป็นการลงทุนที่ ROI ชัดเจนที่สุดสำหรับบริษัทที่มี web-facing service — แต่ WAF ไม่ใช่ “ของที่ติดแล้วลืม”. คำถามที่ผู้บริหารต้องถาม — “WAF ของเรา block mode หรือ log-only mode? + origin IP เปิด public หรือ allowlist เฉพาะ WAF?” เคส Capital One 2019 — บริษัทมี WAF แต่ misconfigure SSRF rule — ข้อมูลลูกค้า 106 ล้านคนหลุด + ค่าปรับ $80M

RASP — ยามที่นั่งอยู่ใน app เอง (เห็นที่ WAF เห็นไม่ครบ)#

WAF เก่งครับ — แต่มี จุดบอด อีกอันที่ใหญ่กว่าที่คนคิด

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

WAF อยู่ระหว่าง user กับ web app. มันเห็น HTTP request — แต่ไม่เห็นว่าใน app เกิดอะไรหลังจาก request เข้า:

ถ้า request มี SQL injection payload — WAF อาจจับได้
แต่ถ้า payload encode มาแบบที่ WAF ไม่รู้จัก — payload ผ่าน WAF — เข้าไปใน app — เมื่อ app decode + ส่ง query ไป database — ตอนนี้ malicious SQL กำลังจะ execute แล้ว — WAF ไม่เห็นแล้ว

นี่คือเหตุที่เรามี RASP (Runtime Application Self-Protection) — ระบบป้องกันที่อยู่ใน runtime ของ application เอง

RASP ทำงานยังไง#

ลองนึก ยามที่ฝังตัวเข้าไปอยู่ใน app. มันไม่ใช่ระบบนอก — มันเป็น library / agent ที่โหลดเข้าไปใน JVM (Java), CLR (.NET), Node.js runtime, Python interpreter ของ application

ที่ฝังในเลเวลนี้ — RASP เห็น:

input ที่เข้ามาในแต่ละ function (รวมถึง decoded version หลัง WAF)
SQL query ที่ app กำลังจะส่งไป database (เห็น query string จริง — ถ้ามี injection คือเห็น)
OS command ที่ app กำลังจะ exec
file path ที่ app กำลังจะอ่าน/เขียน (เช็ค path traversal)
deserialization ของ untrusted data

ถ้า RASP เห็น attack กำลังจะเกิด ตอน runtime — มันสามารถ:

Block การ execute ของ malicious operation (ไม่ส่ง query ที่มี injection ไป database)
Alert + log context เต็ม (stack trace + payload)
Throw exception ใน app เพื่อหยุดที่ตรงนั้น

RASP เห็นที่ WAF ไม่เห็น#

ตัวอย่าง 1 — Encoded payload

โจรส่ง SQL injection ที่ encode 3 ชั้น (URL encode → Base64 → JSON wrapper). WAF เห็น JSON string ที่ดูปกติ — ผ่าน. app decode ออกมา — ก่อนส่ง query — RASP เห็น query string จริง ที่มี ' OR '1'='1 — block

ตัวอย่าง 2 — Business logic context

โจรส่ง request ปกติ แต่พฤติกรรม abuse — เช่น เรียก /api/transfer 1,000 ครั้งต่อนาที. WAF เห็น HTTP ปกติ — ผ่านหมด. RASP เห็น context ของ business operation + state ของ app — ตรวจ rate ของ business action ได้

ตัวอย่าง 3 — Zero-day

CVE ใหม่ของ Spring Framework (เคส Spring4Shell ปี 2022) — WAF ทั่วโลกใช้เวลาหลายวันกว่าจะออก signature. RASP ที่ฝัง JVM เห็นว่า user input กำลังจะ trigger reflection attack ผ่าน ClassLoader manipulation — block ได้ตั้งแต่วันแรกแม้ไม่มี signature เฉพาะ

Vendor หลัก#

Contrast Security — ผู้นำตลาด pure-play RASP. มี IAST (Interactive Application Security Testing) ในตัวด้วย
OpenRASP (open source ของ Baidu) — ฟรี + รองรับ Java + PHP — แต่ ecosystem เล็กกว่า commercial

และตัวอื่นๆ (Imperva RASP, Signal Sciences, Veracode Runtime Protection) ก็มีในตลาด enterprise

กับดักของ RASP#

RASP เก่ง — แต่มี ราคา ที่ต้องคิด:

1. Performance overhead — RASP รันใน-process กับ app — กิน CPU + memory บางส่วน. ทั่วไป overhead 3-8% — แต่ workload ที่ latency-sensitive (HFT trading, real-time gaming) อาจรับไม่ได้

2. Language support — RASP ส่วนใหญ่ support Java + .NET + Node + Python + PHP + Ruby. ถ้า app เขียนด้วยภาษาอื่น (Rust, Go, Elixir) — option จำกัด

3. ราคา — RASP commercial แพง — มัก license ต่อ application หรือต่อ instance — สำหรับองค์กรที่มี microservices หลายสิบตัว — bill หนัก

4. ไม่ใช่ silver bullet — ยังต้องการ WAF + IDS/IPS. RASP คือ last line of defense ไม่ใช่แทนที่ทั้งหมด

ลำดับ deploy ที่แนะนำในวงการ#

เริ่ม = WAF + EDR (cover ใหญ่ที่สุดของ attack surface)
เพิ่ม = NIDS/NIPS ที่ network boundary
สุดท้าย (สำหรับ crown-jewel app) = RASP ที่ app ที่สำคัญที่สุด (เช่น core banking, payment system)

ไม่จำเป็นที่ทุก app ต้องมี RASP — เลือกที่ app ที่หลุดแล้วบริษัทเจ๊งจริงๆ

มุมผู้บริหาร: RASP เหมาะกับองค์กรที่มี crown-jewel application ที่ custom-built (banking core / payment / EMR). องค์กรที่ใช้แต่ SaaS (Salesforce + Slack + Office 365) — ไม่ต้องคิด RASP. คำถามที่ board ควรถาม CISO — “top 5 application ของบริษัท — ถ้าเกิด zero-day + WAF ยังไม่มี signature — เรามี runtime defense ไหม?” ถ้าตอบ “ไม่มี” = gap ที่ต้อง prioritize

เคสจริงที่เปลี่ยนวงการ + บทเรียน#

Equifax 2017 — ถ้ามี IDS/WAF/RASP ที่ดี — น่าจะจับได้#

สิ่งที่เกิดขึ้น — Equifax (credit bureau ใหญ่ที่สุดของ US) มี web app ใช้ Apache Struts เป็น framework. มีนาคม 2017 — Apache ประกาศ CVE-2017-5638 (Remote Code Execution ผ่าน Content-Type header). Equifax ไม่ patch ใน 2 เดือนกว่า. โจรใช้ exploit เข้าระบบ — อยู่ในเครือข่าย 76 วัน — ดูดข้อมูล 147 ล้านคน (ชื่อ + เลขประกันสังคม + ที่อยู่ + driver license + บางคนเลขบัตรเครดิต)

ค่าปรับ + settlement = $1.4 พันล้าน USD. CEO + CIO + CSO ลาออก

ที่ IDS/WAF/RASP จะช่วยได้ยังไง

WAF ที่ดี — Apache Struts exploit ใช้ Content-Type header ที่มี OGNL expression ผิดปกติ. WAF กับ rule update ของ ModSecurity OWASP CRS — ออก signature สำหรับ CVE-2017-5638 ภายใน 1-2 วัน. ถ้า Equifax มี WAF + auto-update signature — payload โดน block ตั้งแต่ request แรก
IDS/NIPS — ระหว่าง 76 วันที่โจรอยู่ในเครือข่าย — มี C2 (Command and Control) traffic ออกไปยัง IP ของโจร. NIDS ที่ดี + threat intelligence feed — น่าจะเห็น C2 traffic + แจ้งเตือนภายในไม่กี่วัน
RASP — Apache Struts vulnerability คือ OGNL injection ที่ runtime ของ Java. RASP ที่ติด JVM ของ app — เห็น OGNL expression ที่มาจาก user input + เห็นกำลังจะ exec OS command — block ได้แม้ไม่มี signature เฉพาะของ CVE นี้

บทเรียน — defense-in-depth ต้องครบทุกชั้น. patch ช้า = พลาด — แต่ WAF + IDS + RASP เป็น compensating control ที่ซื้อเวลาให้ทีมตามทัน

Capital One 2019 — WAF ที่ misconfig = WAF ที่ไม่มี#

สิ่งที่เกิดขึ้น — Capital One (ธนาคารใหญ่ของ US) ใช้ AWS. อดีตพนักงาน AWS รู้จัก SSRF (Server-Side Request Forgery) vulnerability ใน ModSecurity WAF ที่ Capital One ใช้. โจรส่ง payload SSRF บังคับ web app ไปเรียก EC2 metadata service ที่ http://169.254.169.254/ — ดึง IAM role credentials ออกมา — ใช้ credentials นั้น list + download S3 bucket — ข้อมูลลูกค้า 106 ล้านคน หลุด

ค่าปรับ — $80M** จาก OCC + ค่ายอม **$ 190M ในคดี class action. โจรโดนจับ — ไม่ใช่เพราะ Capital One detect — แต่เพราะโจรไปโพสต์อวดบน GitHub

ที่น่าเศร้า — Capital One มี WAF (ModSecurity). แต่ rule config ปล่อยให้ payload SSRF ผ่านไปที่ application

บทเรียน — WAF ที่ตั้งผิด ไม่ป้องกันอะไร. การมี WAF ไม่พอ — ต้องมี:

Rule review เป็นประจำ — ทุก 3-6 เดือน
Bypass testing — ทดสอบว่าโจรเลี่ยง WAF ได้ไหม
Defense-in-depth — ถ้า WAF พลาด — มี IMDSv2 (metadata service version 2 ที่ต้องการ token) + IAM least privilege ที่จำกัดสิ่งที่ credential ทำได้ + RASP ที่เห็น SSRF กำลังจะเรียก internal IP

สรุป + 2 leader takeaways#

ข้อหนึ่ง — IDS/IPS/WAF/RASP ไม่ใช่ replacement กัน — เป็น layers

ลองนึกถนนเข้าเมือง — มี ป้อมยาม (firewall) ที่ประตู → ตำรวจเดินตรวจ (IDS) ในเมือง → ตำรวจตั้งด่าน (IPS) ที่จุดเสี่ยง → ยามหน้าร้าน (WAF) ที่หน้า web app → ยามในร้าน (RASP) ที่อยู่ใน app เอง

ผู้บริหารบางคนถามว่า “มี firewall + WAF แล้ว ต้องมี IDS/IPS อีกไหม?” คำตอบของวงการ — มี. แต่ละชั้นจับ attack คนละแบบ — ไม่ทดแทนกัน:

Firewall = block port + IP
IDS/IPS = block based on packet content + behavior
WAF = block HTTP attack (OWASP Top 10)
RASP = block runtime attack ใน app เอง

โจรที่จะถึง crown jewel ของบริษัท — ต้องผ่านทั้ง 5 ชั้น. ถ้าชั้นใดชั้นหนึ่ง miss — ชั้นถัดไปยังจับได้. นี่คือ defense-in-depth (กลับไปดู EP.04)

ข้อสอง — KPI ที่ผู้บริหารควรถาม ไม่ใช่ “เรามี IDS/WAF ไหม” — แต่เป็น “ระบบ detection ของเรา detect breach ได้กี่วัน + tune ทุกเท่าไร”

ตามข่าวรายงาน security ของวงการ — mean time to identify (MTTI) ของ breach ในปี 2024 = ประมาณ 194 วัน. การมี IDS/WAF ที่ config ไว้แล้วเลิกดู — เท่ากับมีกล้องวงจรปิดที่ไม่มีคนดู

คำถามที่ board ควรถาม CISO ทุกไตรมาส:

เรา detect breach เฉลี่ยใน X วัน — X เท่าไร? เทียบกับ industry benchmark
alert volume ต่อวัน — analyst ของเรา investigate กี่ %?
WAF + IDS rule update ครั้งสุดท้าย — เมื่อไร?
bypass testing / red team ครั้งล่าสุด — เมื่อไร? finding เป็นอย่างไร?
EDR coverage กี่ % ของ endpoint ทั้งบริษัท? 20% ที่เหลือคือเครื่องอะไร?

ในเคสบริษัทไทยขนาดกลางที่ทำ security maturity assessment — ตอบคำถามพวกนี้ได้ดีไม่ถึง 20% — ส่วนใหญ่บอก “มีเครื่อง — แต่ไม่รู้ KPI”. การลงทุน คน + process สำหรับ tune + monitor — สำคัญกว่าการซื้อ box ใหม่

Tease EP.30 — VPN / Proxy / DNS Security#

ครับ — EP.27-29 ปิดด้วย ตำรวจครบทุกประเภท. ป้อมยาม + แบ่งย่าน + ตำรวจตรวจการ — โครงสร้างป้องกันใน-เมือง พร้อม

แต่เมืองในโลกจริง — ไม่ใช่ทุกคนทำงานในกำแพง. พนักงานต้องเข้าเมืองจากภายนอก — ลูกค้าต้องเข้าหา service ของบริษัท — server บริษัทต้องคุยกับ server บริษัทอื่น

ลองนึก scenario:

ผู้บริหารบริษัทไปประชุมที่ Singapore — ต้องเปิดอีเมลในโรงแรม — Wi-Fi โรงแรมปลอดภัยรึเปล่า?
บริษัทมี office 3 สาขา — สาขา A ต้องคุยกับฐานข้อมูลที่สาขา B — ใช้ internet เปิด ปลอดภัยไหม?
app ของบริษัทเรียก API ของ Stripe — รู้ได้ยังไงว่า DNS ตอบกลับ IP ที่ถูกของ Stripe จริง ไม่ใช่ IP ของโจร?

EP.30 — VPN + Proxy + DNS Security จะพาคุณรู้จัก:

ท่อใต้ดิน (VPN — IPsec / SSL VPN / Split vs Full tunnel) — ส่งของข้ามเมืองอย่างปลอดภัยยังไง?
คนกลางส่งของ (Forward Proxy vs Reverse Proxy + NAT) — ทำไมเมืองต้องมีคนกลาง?
สมุดที่อยู่ของเมือง (DNS) — ที่ใครก็แก้ได้ ปลอมได้ ทำให้ทั้งเมืองไปผิดที่
เคส Kaminsky DNS Attack 2008 — ตอนที่ DNS ทั่วโลกเกือบพัง — และทำไม DNSSEC / DoH / DoT ถึงเป็นทางออกของยุคนี้

ตำรวจตรวจการป้องกันคนที่อยู่ในเมือง — แต่ของบางอย่างต้องวิ่งข้ามเมืองทุกวัน — และเส้นทางนั้นมี trap ของตัวเอง — ดูกันใน EP.30 ครับ

→ EP.30 — VPN / Proxy / DNS Security: ท่อใต้ดิน + คนกลาง + สมุดที่อยู่ (เร็วๆ นี้)