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

เปิดฝา IDS ดูข้างใน — 4 ชิ้นส่วนที่ทำให้มันทำงานได้#

ก่อนหน้านี้เล่ารวมว่า IDS คือ “ตำรวจตรวจการ” — เห็น + แจ้ง + ไม่ block. แต่ในความเป็นจริงครับ ตัว IDS เองไม่ใช่กล่องเดี่ยว — มันเป็น ระบบที่ประกอบด้วย 4 ชิ้นส่วน ที่ทำหน้าที่คนละอย่าง. เวลาผู้บริหารคุยกับ vendor หรืออ่าน proposal รู้ 4 ชิ้นนี้แล้วจะอ่านสเปคออก

ลองนึกระบบกล้องวงจรปิดของห้างใหญ่ดูครับ — มี กล้อง หลายร้อยตัวกระจายตามจุดต่างๆ → ส่งภาพเข้า เครื่องประมวลผล ที่อยู่ห้อง server → ผู้ดูแลคุมผ่าน คอมพิวเตอร์ส่วนกลาง ในห้อง security → ดูภาพจริงผ่าน จอ ที่ผนัง.

4 ชิ้นนี้ — กล้อง / เครื่องประมวลผล / คอมพิวเตอร์ส่วนกลาง / จอ — ต่อกันเป็นระบบ. IDS ก็เหมือนกันเป๊ะครับ

จุดที่ exam ของ CISA ชอบทดสอบคือ ความต่างระหว่าง Sensor กับ Analyzer คนมักนึกว่าเป็นชิ้นเดียวกัน แต่ที่จริง sensor เก่งเรื่อง เก็บ (volume สูง, ใกล้แหล่ง traffic) ส่วน analyzer เก่งเรื่อง เข้าใจ (CPU เยอะ, มี rule database) enterprise ใหญ่มัก scale sensor แยกจาก analyzer คือ sensor 50 ตัว ส่งเข้า analyzer cluster กลาง 5 เครื่อง ลดต้นทุน

IDS Features — 6 อย่างที่ระบบดีๆ ต้องทำได้#

เวลา shopping IDS vendor ทุกเจ้าจะบอกว่าระบบของตัวเอง “ครบทุกอย่าง” checklist 6 ข้อนี้ใช้กรองความจริงจากการตลาดได้:

1. Continuous monitoring — ดู traffic / event 24/7 ไม่มีช่วงปิดเครื่อง ไม่มีช่วง maintenance ที่ตาบอด
2. Real-time alerting — ส่ง notification ทันที (email / Slack / SIEM webhook) ไม่ใช่รอ batch report ตอนเช้า — โจรไม่รอ
3. Pattern analysis — มี detection engine แบบ signature + anomaly + heuristic ผสมกัน (กลับไปดูหัวข้อก่อนหน้า)
4. Log correlation — link event ข้าม sensor หลายตัว + ข้าม source หลายชนิด — ไม่ใช่เห็น alert เดี่ยวๆ ที่ไม่ต่อ dot
5. Reporting — ออก compliance report สำหรับ ISO 27001 / PCI DSS / SOC 2 + trend analysis รายเดือน + incident timeline สำหรับ forensic
6. Integration — feed log + alert เข้า SIEM / SOAR เพื่อให้ automated response ทำงานต่อ — IDS ที่อยู่เดี่ยวๆ ไม่มี ecosystem = ของเล่น

ถ้า vendor ไหนตอบไม่ครบ 6 ข้อ ถามต่อเลยครับว่าเหลือข้อไหน แล้วจะ workaround ยังไง

IDS Limitations — 4 ข้อที่ auditor ต้องรู้#

นี่คือส่วนที่ exam ของ CISA ชอบหลอกครับ. คนมักคิดว่า “ติด IDS = ปลอดภัย” — แต่ที่จริง IDS มี จุดบอด 4 อย่าง ที่ผู้บริหารต้องเข้าใจ ไม่งั้นจะลงทุนผิดทาง:

1. Weak policy (rule ที่อ่อน) — rule ของ IDS ถ้าเขียนกว้างเกิน → false positive ท่วม จน analyst เลิกดู. ถ้าเขียนแคบเกิน → false negative โจรผ่าน. นี่คือ trade-off ที่ต้อง tune ตลอด — ไม่ใช่ติดวันแรกแล้วลืม
2. Application-level vulnerabilities — IDS ที่ดู network ไม่เห็น bug ระดับ application logic. ตัวอย่างคลาสสิค — SQL injection ที่ส่งผ่าน HTTPS — ถ้า IDS ไม่ได้ decrypt traffic (ที่ส่วนใหญ่ไม่ได้ทำ เพราะ key management ยุ่ง) — เห็นแค่ encrypted blob ผ่านไป. application โดน inject — IDS ไม่รู้
3. Backdoors — covert channel ที่โจรฝังไว้ + encrypted reverse shell — IDS อ่านเนื้อหาไม่ออก. โจรที่ฝัง backdoor ได้แล้ว ใช้ channel ที่ดูเหมือน HTTPS ปกติคุยกับ command-and-control server — IDS เห็นแค่ traffic ที่ดูปกติ
4. Identification & Authentication weakness — IDS ตรวจ traffic แต่ไม่ verify identity ของ user. insider ที่ login ด้วย credential ตัวเอง (legitimate) + ใช้สิทธิ์ที่มีอยู่ดูดข้อมูล — IDS เห็นเป็น traffic ปกติของ user คนนั้น. insider abuse ที่ใช้ access ของจริง — IDS จับไม่ได้

มุมผู้บริหาร: ถ้าทีม security เสนอลงทุน IDS เพิ่ม ถามให้ตรงประเด็นครับ “4 จุดบอดของ IDS เรามี compensating control อะไร?” application-level bug ต้องใช้ WAF / RASP เสริม (อ่านต่อในโพสต์นี้) encrypted backdoor ต้องใช้ EDR ที่เห็น process behavior ใน host insider abuse ต้องใช้ UEBA (User and Entity Behavior Analytics) + DLP IDS เป็น ชิ้นหนึ่ง ของ defense-in-depth ไม่ใช่ทั้งหมด

IDS Policy: Terminate Session vs Trace Session — เลือกอะไรเมื่อไร#

พอ IDS เจอ activity ที่ดูเป็น attack — ทีม security จะมี 2 ทางเลือกที่ขัดกันโดยสิ้นเชิงครับ:

• Terminate session — block IP / kill connection ทันที defensive ลด damage ที่กำลังเกิด
• Trace session — ปล่อยให้ connection ดำเนินต่อและ log ทุกอย่างที่โจรทำ offensive เก็บ intel ว่าโจรเป็นใคร / มาจากไหน / target อะไร

trade-off ชัดเจน:

• Terminate = หยุด attack ทันที แต่เสีย forensic data + โจรรู้ตัวว่าโดนจับและจะกลับมาใหม่ด้วยวิธีอื่น
• Trace = ได้ intel เต็มที่ แต่เสี่ยงให้โจรเจาะลึกขึ้นและขโมยข้อมูลมากขึ้นระหว่างที่กำลัง “ดู”

best practice ของวงการคือ mixed strategy:

• attack ที่ signature confidence สูง + payload เป็น known malware → terminate ทันที (ไม่มีอะไรต้อง trace, รู้อยู่แล้วว่าเป็นโจร)
• activity ที่ดูแปลก แต่ยังไม่ confirm → trace + log + redirect ไปยัง honeypot (เครื่องล่อที่ดูเหมือนของจริง แต่ไม่มี data จริง) โจรเล่นกับ honeypot ทีม security ดู behavior ทั้งหมดในที่ปลอดภัย

มุมผู้บริหาร: คำถามที่ board ควรถาม CISO ครับ “เรามี incident response playbook ที่กำหนดชัดไหมว่า attack ประเภทไหน terminate / ประเภทไหน trace? ใครมีอำนาจตัดสิน? honeypot infrastructure มีไหม?” ทีมที่ตอบไม่ได้ = ทุก incident จะตัดสินใจสดในห้อง war room ตอนตี 3 ผลคือพลาดทั้งสองทาง (block ของจริงโดยไม่ได้ตั้งใจ + trace ของที่ควร block)

IDS-only ดีเมื่อไร — 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

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 เมื่อไร

WIPS — ตำรวจของอากาศ (Wireless IPS)#

NIPS และ HIPS ดูแล traffic ที่วิ่งบนสาย + activity ที่เกิดในเครื่อง แต่ Wi-Fi เป็นโลกของตัวเองครับ มันวิ่งบนคลื่นวิทยุ ที่ใครก็ดักได้และใครก็ตั้ง access point ปลอมขึ้นมาได้ โดยที่ NIPS / HIPS ไม่เห็นเลย

ลองนึกห้างใหญ่ที่มี Wi-Fi ฟรีให้ลูกค้าครับ. โจรเอา laptop เปิด access point ชื่อ Mall_FreeWiFi (เหมือน SSID ของจริง) นั่งอยู่ที่ food court. ลูกค้าที่ไม่รู้ เครื่องก็เชื่อมเข้า AP ของโจรแทนของห้าง. ทุก traffic ของลูกค้าวิ่งผ่าน laptop โจรก่อนจะไปอินเทอร์เน็ต — username / password / cookie ของ Facebook / mobile banking โจรเห็นหมด. นี่คือ evil twin attack เคสคลาสสิคของ Wi-Fi

นี่แหละครับเหตุที่เรามี WIPS (Wireless Intrusion Prevention System) — IPS เฉพาะสำหรับ Wi-Fi มันคือ sensor วิทยุที่กระจายตามอาคาร คอยฟังคลื่น Wi-Fi รอบๆ และจับ pattern แปลก

WIPS จับอะไรได้:

• Rogue AP — access point ที่มีคนแอบเสียบเข้า network บริษัท (พนักงานเอา router ส่วนตัวมาเสียบใต้โต๊ะ เพื่อให้ Wi-Fi แรงขึ้น — โดยไม่รู้ว่าเปิดประตูให้โจรข้างนอกเข้า)
• Evil twin — AP ปลอมที่ตั้งชื่อเหมือนของจริง (เคสห้างข้างบน)
• Deauth attack — โจรส่ง packet บังคับให้ client หลุดจาก AP ของจริง → client พยายาม reconnect → ติด AP ปลอม
• KRACK — vulnerability ของ WPA2 ที่ปี 2017 ทำให้ทั้งวงการต้อง patch
• WPS attack — bruteforce PIN ของ WPS เพื่อเข้า Wi-Fi
• MAC spoofing — โจรปลอม MAC ของอุปกรณ์ที่ allow แล้ว เพื่อข้าม MAC filtering

WIPS block ยังไง:

• ส่ง deauth packet ไปยัง rogue AP เอง (jam มันให้ client หลุด)
• บังคับ client ที่หลงให้กลับไปเชื่อม AP ของจริง
• แจ้ง SOC ทันที + log location ของ rogue device (ผ่าน triangulation ของ sensor หลายตัว)

Vendor หลักของวงการ — Cisco Meraki MR, Aruba ClearPass + AirWave, Mojo Networks (เป็นของ Arista แล้ว), Extreme Networks AirDefense. ส่วนใหญ่ขายเป็น add-on ของ enterprise Wi-Fi controller — ถ้าใช้ access point ของ vendor นั้นอยู่แล้ว WIPS license จะถูกกว่าซื้อแยก

ใครจำเป็นต้องมี WIPS:

• Enterprise office ที่มี Wi-Fi ครอบคลุม — โดยเฉพาะถ้ามี BYOD policy
• Retail / hospitality — โดยเฉพาะที่รับบัตรเครดิต (PCI DSS บังคับสแกน rogue AP เป็นประจำ)
• Healthcare — HIPAA กำหนดให้ปกป้อง wireless network ที่ส่ง PHI (Protected Health Information)
• โรงเรียน / มหาวิทยาลัย — Wi-Fi เปิดให้ student เยอะ + risk ของ evil twin สูง

มุมผู้บริหาร: ถ้าบริษัทรับบัตรเครดิตและไม่มี WIPS ถาม CISO ตรงๆ ครับ “PCI DSS Requirement 11.1 ว่า quarterly wireless scan เราทำผ่าน WIPS หรือเดินสแกนเอง?” ถ้าตอบ “เดินสแกนเอง” = ทำผ่านได้แค่กระดาษ แต่ในความเป็นจริง rogue AP โผล่ระหว่างควอเตอร์ก็ไม่เห็น PCI auditor ที่จริงจังจะถาม detection coverage ไม่ใช่แค่เอกสาร

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

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

1. Broken Access Control — ผู้ใช้ A เห็น data ของผู้ใช้ B (เช่น เปลี่ยน URL จาก ?user=123 เป็น ?user=124)
2. Cryptographic Failures — เก็บ password เป็น plain text, ใช้ MD5 (กลับไปดู EP.22)
3. Injection — SQL injection, NoSQL injection, OS command injection
4. Insecure Design — design ผิดตั้งแต่แรก
5. Security Misconfiguration — เปิด admin console ให้ public, default password
6. Vulnerable Components — ใช้ library ที่มี CVE
7. Authentication Failures — brute force, credential stuffing
8. Software/Data Integrity Failures — supply chain attack (เคส SolarWinds)
9. Logging/Monitoring Failures — ไม่มี log = detect ไม่ได้
10. 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. มันไม่ใช่ระบบนอก — มันเป็น 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 — มันสามารถ:

1. Block การ execute ของ malicious operation (ไม่ส่ง query ที่มี injection ไป database)
2. Alert + log context เต็ม (stack trace + payload)
3. 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 ไม่พอ — ต้องมี:

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