Vulnerability Scanning — เด็กส่องไฟฉายของเมือง#

Vulnerability Scanning (การสแกนหาช่องโหว่) = ใช้ เครื่องมืออัตโนมัติ สแกนระบบเพื่อหาช่องโหว่ที่เป็นที่รู้จัก. Tool ที่ใช้บ่อย — Nessus (Tenable), Qualys VMDR, Rapid7 InsightVM, OpenVAS (open source)

หลักการทำงาน — Scanner มี database ของ CVE (Common Vulnerabilities and Exposures) ที่ MITRE จัดเก็บ. CVE คือ เลขทะเบียน ของช่องโหว่ทุกตัวที่ถูกเปิดเผยในวงการ — เช่น CVE-2017-0144 = ช่องโหว่ SMB ของ Windows ที่ WannaCry ใช้ (ที่เราคุยใน EP.41). Scanner เดินไปทุก IP / port / service ของบริษัท แล้ว เทียบกับ CVE database — ถ้าเจอเวอร์ชันของ software ที่ตรงกับ CVE → รายงานออกมา

ผลลัพธ์ของ Vuln Scan — list ของ CVE ที่เจอ + CVSS Score (Common Vulnerability Scoring System — คะแนน 0-10 ของความรุนแรง). คะแนน 9.0-10.0 = Critical, 7.0-8.9 = High, 4.0-6.9 = Medium, 0.1-3.9 = Low

ลองนึกภาพครับ — บริษัทมี server 500 ตัว. Vuln scan รายเดือนรันออกมาเป็น report ยาวเป็นพันรายการ — บอกว่ามี CVE-2024-xxx อยู่ที่ server-101, server-203, server-378. ทีม IT รับ report มา patch ตามลำดับ severity. ทุกเดือนวนใหม่ — เพราะมี CVE ใหม่ออกทุกวัน + มี server ใหม่ลง production ทุกสัปดาห์

จุดอ่อนของ Vuln Scan — บอกแค่ว่า “อาจมีรู” ไม่บอกว่า “รูนี้ใช้ได้จริงไหม”. ลองนึกตัวอย่าง — scanner เจอ CVE-2024-xxx severity 9.8 ที่ server-101. แต่ในความเป็นจริง server-101 อยู่หลัง firewall ที่บล็อก port นั้น 100% — โจรเข้าไม่ได้. CVE มี แต่ exploit ไม่ได้. Vuln scanner ไม่รู้ context นี้ — ต้องใช้คนตรวจต่อ

False positive เยอะมาก. บริษัทที่ทำ vuln scan ครั้งแรก — มักจะเจอ critical 200-500 รายการ. 80-90% ของ critical จะเป็น false positive หรือ low actual risk เมื่อมีคนนั่งดู context

มุมผู้บริหาร — Vuln Scan ไม่ใช่ “งานเสร็จ” — เป็น “งานเริ่ม”

ถ้า CISO เดินมาบอก “เราทำ vuln scan แล้ว เจอ 0 critical” — ถามต่อ 2 คำถาม. คำถามที่ 1: scope ครอบคลุมกี่เปอร์เซ็นต์ของระบบ? (ถ้าครอบคลุม 30% — ตัวเลข 0 critical ไม่มีความหมาย). คำถามที่ 2: คนตรวจ scan result หรือเปล่า? — เพราะ scanner ออก raw ออกมาเป็นพัน — ถ้าไม่มีคนนั่ง triage ลำดับ + ตรวจ false positive — ตัวเลขที่ส่งให้ผู้บริหารดู ไม่ใช่ความจริง. Vuln Scan = “ระบบเตือนภัย” — ยังต้องใช้คนตัดสินว่าเตือนอันไหนของจริง

5 เป้าหมายของ Vulnerability Assessment (VA) — Vuln Scan เป็น “เครื่องมือ” หนึ่งที่ใช้ใน Vulnerability Assessment (VA) — กระบวนการที่กว้างกว่า. VA ที่ทำครบจะตอบ 5 คำถาม

1. เจอ system + service ทุกตัวที่เข้าถึงได้ — ครอบคลุม scope (เชื่อมโยงเป้า 1 ของ Security Testing ด้านบน)
2. เจอ vuln ที่รู้จัก — match กับ CVE database
3. คะแนน risk — คิด CVSS score ของแต่ละ vuln
4. จัดลำดับการแก้ — ตามความสำคัญของ asset + ความน่าจะถูกใช้
5. ติดตามตามเวลา — trend ของจำนวน vuln + SLA compliance ในการ patch

5 ข้อนี้แตกต่างจาก Vuln Scan ตัวเดียว ตรงที่ — Scan ตอบแค่ข้อ 2. ส่วนข้อ 1 + 3 + 4 + 5 ต้องการ คน + process — ซึ่งคือ VM Lifecycle ที่จะคุยตอนท้าย EP

Penetration Testing — โจร (กลับใจ) ที่ลองเข้าจริง#

Penetration Testing (การทดสอบเจาะระบบ — เรียกย่อ “Pen Test”) = ก้าวต่อจาก Vuln Scan. ไม่ใช่แค่ “หารู” — แต่ “ลองเปิดประตูเข้าจริง” เพื่อพิสูจน์ว่า vulnerability ที่เจอ — ใช้โจมตีได้จริงไหม + เข้าไปได้ลึกแค่ไหน

ความต่างของ Pen Test กับ Vuln Scan ที่ผู้บริหารเข้าใจง่ายที่สุด — มีคนนั่งทำ. Pen tester ไม่ใช่ tool. Pen tester เป็น คน ที่มีทักษะระดับ mid-senior — รู้ทั้ง network / web / OS / cloud + รู้วิธีคิดแบบโจร

ลองนึกฉาก — Vuln scanner รัน เจอว่า web server ของบริษัทเปิด port 8080 ที่มี admin panel ของ Tomcat. Scanner รายงาน CVSS 7.5 (High). จบ. Pen tester อ่าน report นั้น แล้วเดินต่อ — ลอง default credential (tomcat/tomcat) → เข้าได้ → อัปโหลด WAR file ที่เป็น web shell → ได้ shell บน server → ดู environment variable → เจอ database credential → connect database → ดูดข้อมูลลูกค้า 5 ล้าน record

จากเดิมที่ vuln scan บอก “CVSS 7.5” → pen tester พิสูจน์ว่า เคสนี้ = full database breach. คนละเรื่องเลยใช่ไหมครับ — ทั้งที่ vuln เดียวกัน

Pen Test ปกติทำ ปีละ 1-2 ครั้ง หรือ ก่อน major release. ราคาในไทย $20K-150K USD ต่อ scope. Scope ปกติคือ — เว็บ application หนึ่งตัว หรือ external network ของบริษัท หรือ internal network ของแผนกหนึ่ง

Output คือ report ที่มี

• Executive summary — สำหรับผู้บริหาร (สั้น 1-2 หน้า — risk level + business impact)
• Technical findings — สำหรับทีม IT (ลึก — เคยทำอะไรกับ vuln แต่ละตัว + วิธีแก้)
• Attack narrative — เล่า “เข้าได้ยังไงตั้งแต่ต้นจนจบ” (story telling)
• Remediation roadmap — ลำดับการแก้ตาม priority

ความสำคัญที่ผู้บริหารมักมองข้าม — Pen Test ที่ดีจะ map finding กับ business risk ไม่ใช่แค่ technical risk. Pen tester ที่อยู่แค่ระดับ “เข้าได้ + ออกได้” — ระดับเริ่มต้น. Pen tester ระดับ senior จะตอบให้ได้ว่า “เข้าได้แล้ว = บริษัทเสียอะไรเป็นเงิน”. ยกตัวอย่างเช่น “ผ่าน SSRF ตัวนี้ → เข้า internal network → เข้า S3 bucket ที่เก็บข้อมูลบัตรเครดิตลูกค้า 5 ล้าน → ถ้าโจรจริงเอาออก = ค่าปรับ PDPA + ค่าเสียหาย ~150 ล้านบาท”

มุมผู้บริหาร: Pattern ที่บริษัทไทยติดบ่อย — จ้าง pen test ปีละครั้งเพราะ PCI DSS / ISO 27001 บังคับ จ้างถูกที่สุดที่ผ่าน รับ report ใส่แฟ้ม ไม่ patch finding ปีหน้าจ้างใหม่เจอ finding ชุดเดิม = compliance theater. ผู้บริหารต้องถามทีม — “finding จาก pen test ปีที่แล้ว — patch ครบหรือยัง?” ถ้าตอบไม่ได้ทันที = เสียเงินจ้าง pen test เปล่าและยังเสี่ยงเท่าเดิม

Red Team — แก๊งโจรปลอมตัวที่เข้ามาทดสอบยาม#

Red Team (ทีมแดง — ทีมจำลองศัตรู) = ระดับสูงสุดของ offensive testing. แต่อย่าเข้าใจผิดว่ามันคือ “Pen Test ที่ใหญ่ขึ้น” — มัน คนละจุดประสงค์

• Pen Test ตอบ: ระบบของเรามีรูตรงไหน + รูแต่ละรูเข้าได้แค่ไหน?
• Red Team ตอบ: ทีมรับของเรา (Blue Team) ตรวจจับได้หรือเปล่า?

ลองนึกฉาก. บริษัทใหญ่ในอเมริกาจ้าง red team. ทีม red มี 8 คน — มี hacker / มี social engineer / มี physical pen tester / มี analyst. เป้าหมายของ engagement ที่ตกลงกับ CEO + CISO เท่านั้น (ไม่มีใครในทีม security รู้):

“ภายใน 6 เดือน — เข้าให้ถึง crown jewel ซึ่งคือไฟล์ Q4_acquisition_targets.xlsx ใน folder ของ CFO โดยที่ทีม SOC ไม่ตรวจจับ”

3 เดือนแรก — red team ทำ recon ทั้งบน OSINT (LinkedIn / GitHub / Twitter) + เริ่ม spear phishing พนักงานเป้าหมาย. โจมตีเข้า laptop ของ junior accountant 1 คนได้สำเร็จ — ผ่าน document Excel ที่มี macro

เดือนที่ 4 — red team อยู่ในเครื่อง junior accountant 30 วัน โดย EDR ของบริษัทไม่เด้ง. ทำ lateral movement ไป file server → mapping ของ folder ทั้งบริษัท → เจอ folder ของแผนก finance

เดือนที่ 5 — เข้า laptop ของ finance manager ผ่าน Pass the Hash → เจอ note ที่บอก share path ของ CFO

เดือนที่ 6 — เข้าถึง share ของ CFO → ดาวน์โหลด Q4_acquisition_targets.xlsx → mission accomplished

ในช่วง 6 เดือนนี้ — SOC ของบริษัทไม่เด้ง alert สำคัญแม้แต่ครั้งเดียว. ทุก movement ของ red team ปลอมตัวกลืนกับ normal traffic — ใช้ tool ที่ดูเหมือน admin tool ปกติ (Living off the Land — ที่เราคุยใน EP.44) — เดินผ่าน detection ของบริษัท

หลัง engagement จบ — red team ทำ debrief กับ blue team. ทีม blue เห็น log ทั้งหมดของสิ่งที่ red team ทำ — แล้ว เรียนรู้ pattern ที่ตัวเองพลาด. นี่คือ output ที่แท้จริงของ Red Team — ไม่ใช่ list of vuln. แต่เป็น bookmarks ของจุดที่ detection ของเราพังตรงไหน

Red Team ที่ดี = บริษัทขนาดใหญ่ที่มี internal red team (Google / Microsoft / Goldman) + engagement ที่ต่อเนื่อง (Continuous Adversary Emulation) — ไม่ใช่ “ปีละครั้ง”. ฝั่งโจรจริงไม่หยุดหายใจ — Red Team ก็ไม่หยุด

Purple Team = อันนี้คือ tweak ใหม่. แทนที่ Red กับ Blue จะแยกกัน — ให้ทำงานร่วมกัน real-time. Red attack → Blue ดู log → ปรับ detection → Red attack ใหม่. รอบเร็วขึ้น learning เร็วขึ้น. เหมาะกับบริษัทที่ Blue team ยังไม่พร้อมจะรับ Red Team แบบลับ

สีของทีม security — Red / Blue / Purple ยังไม่ครบ เพิ่ม White + Yellow#

วงการ security ใช้ สี เรียกบทบาทของทีมแต่ละกลุ่มในการซ้อมรบครับ หลายคนรู้แค่ 3 สีหลัก คือ Red (โจร), Blue (ยาม), Purple (สะพานเชื่อม 2 ฝั่ง) แต่ถ้าซ้อมรบจริงในบริษัทใหญ่ มีอีก 2 สีที่ขาดไม่ได้

White Team — กรรมการของการซ้อมรบ. ในการซ้อม Red vs Blue ใหญ่ๆ — ถ้าไม่มีกรรมการ มีโอกาสซ้อมแล้ว Red ทำเรื่องที่ “เกินขอบเขต” แล้วเกิด downtime จริง หรือ Blue บอกว่า “เราจับได้” แล้วเถียงกันไม่จบ. White Team จึงรับ 6 หน้าที่

• วาง scope + เป้าหมาย — งวดนี้จะวัดอะไร (จับ flag? ลด MTTD? ทดสอบ playbook IR?)
• เขียน rules of engagement — technique อะไรอนุญาต, asset ไหนห้ามแตะ (production payment / ระบบช่วยชีวิต), ช่วงเวลาไหนหยุด
• brief ทุกฝ่าย ก่อนเริ่ม
• เฝ้าดูระหว่างซ้อม + ตัดสินข้อพิพาท (“Red เข้าได้ตรงนี้จริงไหม?” / “Blue จับได้ก่อน Red ถึง target ไหม?”)
• หยุดการซ้อม ทันทีถ้าเริ่มเกิดความเสียหายจริง
• เขียน after-action report ให้ผู้บริหาร

Yellow Team — คนสร้างของ. Red กับ Blue คุยกันเรื่อง “หาช่องโหว่ vs จับโจร” — แต่ช่องโหว่ส่วนใหญ่เกิดตอนเขียนโค้ด. ถ้า developer เขียนโค้ดให้ปลอดภัยตั้งแต่ต้น — Red ก็ไม่มีอะไรให้แฮก. Yellow Team จึงรับงาน

• ทำ threat modeling ตั้งแต่ออกแบบ — ก่อนเขียน code บรรทัดแรก
• ใช้ secure coding standard (เช่น OWASP ASVS — Application Security Verification Standard)
• รัน SAST / DAST / SCA ใน CI/CD pipeline (รายละเอียดอยู่ใน EP.34 — DevSecOps + Shift-Left)
• patch ทันทีเมื่อ Red Team หรือ pen tester เจอช่องโหว่
• ฝึก developer เรื่อง pitfall ที่เจอบ่อย (SQL injection, IDOR, hardcoded secret)

นอกจาก 5 สีหลัก วงการเริ่มพูดถึงอีก 2 สีในช่วงหลัง — Orange Team = security awareness ของคนที่ไม่ใช่ engineer (HR, finance, ผู้บริหาร — กลุ่มที่โดน BEC + phishing เยอะที่สุด). Green Team = จุดทับซ้อนของ IT operations กับ security — เน้นทำให้ DevSecOps culture ไหลลื่น (ไม่ใช่ทีมแยกใหม่ — เป็นการ ops ที่ฝัง security ตั้งแต่ deploy)

มุมผู้บริหาร — สีของทีมไม่ใช่ใบประกาศ เป็นบทบาทที่ใครๆ ก็เล่นได้

ใน pattern ของบริษัทไทย ผู้บริหารชอบ “ตั้ง Red Team” ตามกระแสโดยไม่มี White Team กำกับ ผลคือ Red เข้าทำงานจริงโดยไม่มี scope ที่ชัด → ทำของพังจริง → ฟ้องกันเอง หรือ Red กับ Blue ทะเลาะกันว่า “ใครชนะ” เพราะไม่มีกรรมการตัดสิน กฎง่ายๆ คือก่อนจะตั้ง Red Team ต้องมี White Team ก่อน (อาจเป็น CISO + Legal + Chief Risk Officer ที่ทำหน้าที่กรรมการ) และก่อนจะหวังให้ Red หาช่องโหว่เจอน้อยลง ต้องมี Yellow Team ที่ทำให้ developer เขียนโค้ดปลอดภัยตั้งแต่ต้นครับ

มุมผู้บริหาร — Red Team ไม่ใช่ “ทำเพื่อหารู” — ทำเพื่อ “วัดทีมรับ”

ถ้าบริษัทยังไม่มี SOC ที่ตอบ alert ได้ภายในชั่วโมง — อย่าเพิ่งทำ Red Team. ทำ Vuln Scan + Pen Test + BAS ก่อน. Red Team มีค่าก็ต่อเมื่อมี Blue Team ที่จะเรียนรู้จากการแพ้ของตัวเอง. การจ้าง Red Team ราคา $1M แต่ Blue Team ของเรา ไม่มี process รับ debrief = เผาเงินทิ้ง. ขั้นบันได ตามนี้ — (1) Vuln Scan รายเดือน → (2) Pen Test รายปี → (3) BAS รายวัน (continuous validation) → (4) Purple Team → (5) Red Team. ข้ามขั้นไม่ได้

BAS (Breach and Attack Simulation) — Red Team ในกล่อง#

เราเพิ่งคุยกันว่า Red Team แพง — $500K-2M ต่อปี — และต้องมี Blue Team ที่พร้อมรับ. คำถามที่ตามมา — “บริษัทขนาดกลางที่อยากรู้ว่า detection ของตัวเองดีแค่ไหน — ทำยังไง?”

คำตอบในช่วง 5-7 ปีหลัง — BAS (Breach and Attack Simulation)

BAS = แพลตฟอร์มซอฟต์แวร์ที่รัน technique ของโจรจริง (mapped กับ MITRE ATT&CK ที่เราคุยใน EP.39) ซ้ำๆ บนระบบของบริษัท อัตโนมัติ + ต่อเนื่อง — แล้วเช็คว่า control แต่ละชั้น (EDR / SIEM / WAF / firewall) ตรวจจับ + บล็อก ได้กี่เปอร์เซ็นต์ของ technique ที่รัน

ลองนึกง่ายๆ — BAS = “หุ่นยนต์ Red Team ที่ทำงาน 24/7” แต่:

• ไม่คิดสร้างสรรค์ — รันเฉพาะ playbook ที่ตั้งไว้
• ไม่ทำ social engineering — เน้น technical technique ใน infrastructure
• ไม่ปลอมตัว physical — รันบน endpoint / network / cloud

ตัวอย่าง playbook ที่ BAS รัน:

• T1059 — Command and Scripting Interpreter (รัน PowerShell ที่ดู malicious — EDR เด้งไหม?)
• T1003 — Credential Dumping (พยายามดูด LSASS — EDR + SIEM จับไหม?)
• T1486 — Data Encrypted for Impact (จำลอง ransomware encrypt file ใน folder จำกัด — backup ทำงาน + alert เด้งไหม?)
• T1190 — Exploit Public-Facing Application (รัน exploit จำลอง — WAF บล็อกไหม?)

Platform หลัก 4 ตัว

• AttackIQ — เน้น MITRE ATT&CK coverage matrix. ลูกค้า — บริษัท Fortune 500
• SafeBreach — เน้น breach scenario แบบ end-to-end (kill chain เต็ม). มี library 25,000+ attack
• Cymulate — focused on SaaS-delivered + ใช้ง่ายขึ้นสำหรับ mid-market
• Picus Security — มี automated mitigation recommendation (แนะนำ rule SIEM ที่ต้องเพิ่ม)

Output ของ BAS = coverage matrix — ตารางที่บอก “technique T1003 — รันไป 50 ครั้ง — EDR จับได้ 42 / 50 = 84% coverage. SIEM alert ได้ 35 / 50 = 70%”. ตัวเลขนี้ใช้ตัดสินใจได้ทันทีว่า — ต้องปรับ rule SIEM หรือ ต้องเปลี่ยน EDR

ความต่างของ BAS กับ Red Team (ที่ผู้บริหารต้องเข้าใจ)

ใช้ BAS แทน Red Team ได้ไหม? — ไม่ได้. ตอบคำถามคนละแบบ. BAS ตอบ “control พื้นฐานของเราจับ technique มาตรฐานได้กี่ %”. Red Team ตอบ “ถ้าโจรที่คิดสร้างสรรค์เข้ามา — ทีมเราตอบสนองยังไง”

แต่ BAS ทดแทน Red Team ระดับเริ่มต้นได้ สำหรับบริษัทที่ Blue Team ยังไม่พร้อม. ลำดับที่ถูก — BAS ก่อน เพื่อให้ Blue Team เห็น gap + ปรับ detection rule + ผ่าน technique มาตรฐานได้ → แล้วค่อยจ้าง Red Team ที่จะทดสอบขั้น advanced

มุมผู้บริหาร — BAS = “เครื่องวัดอุณหภูมิ” ของ Blue Team

Pattern คลาสสิคที่บริษัทไทยทำผิด — ซื้อ EDR แพง $200K/ปี → installed → ไม่เคยทดสอบว่าจับ technique อะไรได้บ้าง. CISO เดินมาบอกผู้บริหาร “เรามี EDR ของ vendor ดัง” — แต่ตอบไม่ได้ว่ามัน catch rate กี่ % สำหรับ technique ที่ ransomware ใช้จริง. BAS คือเครื่องมือที่ทำให้คำถามนี้ตอบได้เป็นตัวเลข — และทำซ้ำได้ทุกเดือนเพื่อ track improvement. ถ้าผู้บริหารต้องการ KPI ของ security operation ที่ measurable + repeatable — BAS coverage % เป็น metric ที่ดีกว่า “จำนวน alert ที่ทีม SOC handle” หลายเท่า

Phase 1: Reconnaissance (สำรวจ)#

Reconnaissance (การสำรวจ) = เก็บข้อมูลของเป้าหมายก่อน จะ touch ระบบจริง. แบ่ง 2 แบบ

• Passive Reconnaissance — ใช้ข้อมูลสาธารณะที่ไม่ต้อง interact กับ target. ใช้ OSINT (Open Source Intelligence) — LinkedIn / Crunchbase / Glassdoor / GitHub / Shodan / Censys / domain WHOIS / DNS record. เป้าหมายไม่รู้ว่ากำลังถูกสำรวจ
• Active Reconnaissance — เริ่ม touch target แล้ว — เช่น ping / DNS query / lookup. มีร่องรอย — ถ้า target มี IDS ตื่นตัวอาจเห็น

ตัวอย่าง passive recon ที่ pen tester เริ่มจาก:

• LinkedIn → รู้ชื่อพนักงาน / ตำแหน่ง / structure ของบริษัท → เป้าหมายของ spear phishing
• GitHub → search “company.com” → บางครั้งเจอ developer commit API key + password ลง public repo
• Shodan → search องค์กรของบริษัท → เห็น IP / open port / service / version
• Job posting → “We’re hiring Senior Splunk Engineer with experience in AWS GovCloud” → รู้เลยว่าบริษัทใช้ Splunk + AWS GovCloud

ประเด็นที่ผู้บริหารควรลองทันที — สั่งทีม IT ทำ OSINT self-assessment — Google search ชื่อบริษัทบวกคำว่า “password” / “API key” / “config” — ดูว่ามีอะไรหลุดออกไปบน internet หรือเปล่า. Pattern ที่เจอได้ทั่วไป — developer commit .env ขึ้น GitHub โดยไม่รู้ตัว แล้ว delete ออก — แต่ git history เก็บไว้. ของหลุดแล้วเก็บไม่ได้ครับ

Phase 2: Scanning + Enumeration (สแกน + แจกแจง)#

หลังรู้ surface area แล้ว — pen tester เริ่ม scan เพื่อหา service ที่เปิดอยู่. Tool หลัก — Nmap (port scan), Masscan (มหาศาลเร็ว), Burp Suite / OWASP ZAP (web app scan), Nessus / OpenVAS (vuln scan)

แล้วเข้าสู่ Enumeration (การแจกแจงข้อมูลละเอียด) — เก็บข้อมูลเชิงลึกของ service แต่ละตัว. ตัวอย่าง — เจอ port 445 (SMB) เปิด → enumerate ว่า user / share / permission มีอะไรบ้าง. เจอ port 443 → enumerate ว่า certificate ใคร ใช้ TLS version อะไร — มี subdomain อะไรบ้าง — virtual host เปิดอะไรไว้

ขั้นนี้ — pen tester เริ่มสร้าง map ในหัว ของ attack surface ทั้งหมด

Phase 3: Exploitation (ใช้ช่องโหว่เข้าระบบ)#

Exploitation = ใช้ช่องโหว่ที่เจอ — เข้าระบบจริง. ความแตกต่างกับ vuln scan ที่ขีดเส้นใต้ — เริ่มที่ phase นี้

Tool ที่ดังที่สุด — Metasploit Framework — module ของ exploit หลายพันตัวที่พร้อมใช้. Pen tester เลือก exploit ที่ match กับ service ที่เจอ → ตั้ง payload → ยิง

แต่ pen tester ระดับ senior — ไม่พึ่ง Metasploit เป็นหลัก. เพราะ exploit ที่มีใน Metasploit — EDR ของบริษัทรู้จักหมด. Senior จะเขียน custom exploit หรือ modify payload ให้ evade detection

Phase 4: Post-Exploitation (เข้าได้แล้วทำอะไรต่อ)#

เข้าได้แล้ว — phase นี้สำคัญที่สุดในมุมของ business impact

Post-Exploitation ครอบคลุม 5 กิจกรรม:

ประเด็นสำคัญที่ผู้บริหารต้องเข้าใจในขั้นนี้ — “เข้าได้” ไม่เท่ากับ “เสียหาย”. Pen test ที่ดีต้อง report business impact ที่แท้จริง — ไม่ใช่แค่ “เข้าได้”. เคสที่เจอได้ทั่วไป — pen tester รายงาน “ได้ Domain Admin” จบ. ผู้บริหารอ่านแล้วไม่รู้ว่ามันแย่แค่ไหน. Pen tester ระดับ senior จะเขียนต่อครับ — “ได้ Domain Admin → access ทุก server → simulate ดูดข้อมูลลูกค้า / encrypt all data ภายใน 4 ชั่วโมง → ถ้าเป็นโจรจริง = ransomware breach + GDPR fine ~€20M + downtime 2 สัปดาห์”. อันนี้คือ report ที่ผู้บริหารใช้ตัดสินใจได้

Phase 5: Reporting (เขียนรายงาน)#

Phase นี้บางทีเป็น 50% ของเวลา ของ engagement ทั้งหมด. Pen tester ที่ทักษะดีอาจเขียน report ห่วย — report ที่อ่านไม่รู้เรื่อง = engagement ที่เผาเงินทิ้ง

Report ที่ดี มี 3 ชั้น

• Executive summary — 1-2 หน้า — risk + business impact + roadmap. ผู้บริหารอ่านได้
• Findings detail — ทีม IT อ่าน — มี CVSS score + screenshot + reproduction step + remediation
• Appendix / raw output — สำหรับ audit + future reference

Phase 6: Cleanup + Retest (เก็บกวาด + ทดสอบซ้ำ)#

หลัง report ส่ง — pen tester ต้อง เก็บกวาด ทุก artifact ที่ทำไว้บนระบบ — backdoor, user ที่สร้าง, file ที่ฝัง, log ที่ดัดแปลง. ถ้าทิ้งไว้ — โจรจริงอาจเก็บได้

Retest — หลังบริษัท patch แล้ว — pen tester กลับมาทดสอบซ้ำว่า fix ใช้ได้จริง. อย่าข้าม retest — เพราะ fix ที่ทำผิด = vuln เดิมยังอยู่

Black Box — pen tester ไม่รู้อะไรเลย#

Black Box Testing = pen tester ได้แค่ ชื่อบริษัท หรือ domain เริ่มต้น. ไม่ได้ network diagram / source code / credential. ต้องเริ่มจาก recon เอง

• ข้อดี — จำลอง โจรจริงจากภายนอก ที่ใกล้เคียงที่สุด. เจอสิ่งที่โจรจะเจอ
• ข้อเสีย — ช้า + แพง เพราะใช้เวลา recon เยอะ + อาจพลาด vuln สำคัญที่อยู่ในซอกลึก
• เหมาะกับ — external pen test ของ public-facing system. หรือเมื่อต้องการจำลอง “โจรไม่รู้จักเรา”

White Box — pen tester ได้ทุกอย่าง#

White Box Testing = pen tester ได้ ทุกอย่าง — source code / network diagram / credential ทุก role / architecture document / build pipeline

• ข้อดี — เร็ว + ครอบคลุม + ลึก. หา vuln ในซอกที่ Black Box ไม่มีวันเจอ — เช่น race condition ใน code, business logic flaw, secret ใน config
• ข้อเสีย — ไม่จำลองโจรจริง. โจรจริงไม่ได้ source code (ในกรณีส่วนใหญ่)
• เหมาะกับ — testing ใหม่ก่อน launch product, code review เชิงลึก, internal critical system

Gray Box — กลางๆ#

Gray Box Testing = pen tester ได้บางส่วน — เช่น user credential ระดับธรรมดา (ไม่ใช่ admin) + network range + service inventory. ไม่ได้ source code

• ข้อดี — balance ระหว่างความเร็วและความสมจริง. จำลองโจรที่เข้ามาได้แล้ว 1 step (ได้ user account จากการ phishing) + เริ่มเดินต่อจากตรงนั้น
• ข้อเสีย — ไม่ได้สุดทั้งสองด้าน
• เหมาะกับ — pen test ส่วนใหญ่ในชีวิตจริง — ที่ผสมความสมจริงและความครอบคลุม

แต่ละแบบเจอ bug ต่างกัน#

ผู้บริหารต้องเข้าใจประเด็นนี้ครับ — 3 แบบไม่ใช่ “ระดับความเก่งของ pen tester” — เป็น “ประเภทของ vuln ที่จะเจอ”

Black Box จะเจอ:

• Vuln ที่ external-facing — โจรจริงเข้าทาง public internet
• Misconfiguration ใน load balancer / WAF / DNS
• Information disclosure จาก error message

White Box จะเจอ:

• Logic flaw ลึกใน code
• Hardcoded secret
• Insecure deserialization
• Race condition

Gray Box จะเจอ:

• Privilege escalation จาก user → admin
• Lateral movement ระหว่าง internal system
• Authorization bug ใน API

ถ้าบริษัทอยากครอบคลุมจริง — ต้องทำหลายแบบ ในช่วงเวลาต่างกัน

มุมผู้บริหาร: Pattern คลาสสิค — บริษัทขอ “Black Box pen test” เพราะคิดว่าเป็นระดับยากที่สุด ดีที่สุด — จริงๆ ไม่ใช่. Black Box ใช้เวลา recon 60-70% ของ engagement = เจอ bug น้อยกว่า White Box ในเวลาเท่ากัน. ถ้าเป้าหมายคือ “ปลอดภัยจริง” → White/Gray Box ได้ value ต่อเงินมากกว่า. ถ้าเป้าหมายคือ “จำลองโจรจริง” → Black Box

MAST (Mobile Application Security Testing)#

MAST = security testing ที่ทำเฉพาะ iOS app + Android app. ทำไมต้องแยก? เพราะ mobile app มีโลกที่ web app ไม่มี — เครื่องที่ user ถือ (อาจ jailbreak / root ได้), data ที่เก็บใน local storage, IPC ระหว่าง app, certificate pinning. SAST / DAST แบบ web app ตามไม่ทัน

แบ่งย่อย 2 แบบ

• Static MAST — decompile ไฟล์ APK (Android) / IPA (iOS) → วิเคราะห์ bytecode + manifest. หา hardcoded secret, permission ที่ขอเกิน, library เก่าที่มี CVE
• Dynamic MAST — install app บนเครื่องจริง (หรือ emulator) → ใช้เครื่องมือ inject เช่น Frida / Objection เพื่อ hook function ขณะรัน → ดูว่าแอปทำอะไรจริงเทียบกับที่โฆษณา

Tool หลัก — NowSecure (commercial), Veracode MAST (commercial), MobSF (open source — ฟรี ลองได้เลย)

6 เรื่องที่ MAST ทดสอบเสมอ

• Jailbreak / root detection — app รู้หรือไม่ว่ารันบนเครื่อง compromised?
• Certificate pinning — app ผูกกับ certificate ของ server ที่กำหนดหรือเปล่า (ถ้าไม่ผูก — MITM ได้ง่าย)
• Local data encryption — ข้อมูล sensitive ที่เก็บใน device — เข้ารหัสหรือเปล่า?
• IPC (Inter-Process Communication) — Intent ของ Android หรือ URL scheme ของ iOS — มี input validation ไหม?
• Reverse engineering protection — มี obfuscation ไหม?
• API security — endpoint ที่ mobile call — มี authentication + rate limit ไหม?

มุมผู้บริหาร: Pattern คลาสสิค — บริษัทไทยทำ pen test เว็บแอป แต่ไม่ทำของ mobile app ทั้งที่ผู้ใช้ 70-80% ใช้ผ่าน mobile. ถ้าบริษัทมี mobile app — บังคับ MAST อย่างน้อยปีละ 1 ครั้ง เป็นบรรทัดฐาน. ตัวอย่างจริงที่เจอบ่อย — แอป mobile banking ของบางประเทศที่เก็บ session token ใน plain text บน device → user คนหนึ่งโดน malware ขโมย token → โอนเงินไปได้

Fuzz Testing (Fuzzing) — ป้อนขยะให้ระบบเพื่อดูว่าจะพังตรงไหน#

Fuzz Testing = ป้อน input สุ่ม หรือบิดเบี้ยว ให้กับโปรแกรม เพื่อดูว่ามันจะ crash, hang, leak memory, หรือเปิดช่องโหว่ตรงไหน. หลักการง่ายๆ — โปรแกรมส่วนใหญ่ถูกเขียนมาเพื่อรองรับ input ที่ “ปกติ” — แต่โจรไม่ป้อน input ปกติ. Fuzzing เลียนแบบสิ่งที่โจรทำ — ป้อนของแปลกๆ ไปเรื่อยๆ จนกว่าจะเจอจุดที่ระบบรับไม่ไหว

แบ่ง 3 แบบ

• Mutation-based fuzzing — เริ่มจาก input ที่ valid แล้วบิดสุ่ม (เปลี่ยน byte, เพิ่มความยาว, ตัดทิ้ง). ง่าย ใช้ทันที
• Generation-based fuzzing — สร้าง input จาก grammar / spec (เช่น มี grammar ของ JSON หรือ ของ protocol HTTP → generate input ที่ถูก syntax แต่ค่าเพี้ยน). ลึกกว่า — เจอ bug ที่ mutation พลาด
• Coverage-guided fuzzing — ใช้ code coverage เป็นตัวนำทาง. ถ้า mutation รุ่นใหม่ทำให้รัน code branch ที่ไม่เคยรัน → เก็บ mutation นั้นไว้เป็น seed ของรุ่นต่อ. Tool หลัก — AFL (American Fuzzy Lop), libFuzzer, Honggfuzz

ใช้กับอะไรได้บ้าง — implementation ของ network protocol (ส่ง packet ที่ผิด spec), parser (XML, JSON, image format), file format handler (PDF reader, video codec), API endpoint

Google OSS-Fuzz — โครงการของ Google ที่รัน fuzz ให้ open-source project ใหญ่ๆ ฟรี 24/7 บน Google Cloud. ตั้งแต่ปี 2016 — เจอ bug มากกว่า 30,000 ตัว ใน open source — ครอบคลุม OpenSSL, FFmpeg, sqlite, curl, ฯลฯ. หลาย bug เป็น security-critical ที่ถ้าไม่เจอด้วย fuzz อาจกลายเป็น 0-day

มุมผู้บริหาร: Fuzz testing เป็นเครื่องมือของ developer / security engineer — ผู้บริหารไม่ต้องลงรายละเอียด. แต่ต้องรู้ว่าถ้าบริษัทสร้าง software ที่รับ input จากภายนอก (API, file parser, network protocol) — ควรมี fuzz ใน CI/CD. การไม่ทำ fuzz = ส่ง software ที่ไม่เคยทดสอบ edge case ออกไปให้ลูกค้าเป็นคน “เจอ bug” — บางตัวจะเป็น security bug ที่เสียหายมหาศาล

Platform หลัก 4 ตัว#

• HackerOne — ใหญ่ที่สุด. ลูกค้า — U.S. Department of Defense (Hack the Pentagon), GitHub, Shopify, Uber, Slack, GitLab. จ่ายไปแล้วรวม $300+ ล้าน USD
• Bugcrowd — เบอร์ 2. ลูกค้า — Mastercard, Tesla, Atlassian, ServiceNow
• Zero Day Initiative (ZDI) ของ Trend Micro — เน้น 0-day ระดับ enterprise software. รางวัลสูงสุดที่จ่าย — $400K+ ต่อ bug. จัดงาน Pwn2Own ทุกปี
• Apple Security Bounty — Apple บริหารเอง. สูงสุด $2 ล้าน USD สำหรับ zero-click kernel exploit chain บน iOS

กติกาที่ทำให้มัน work#

Bug Bounty ที่ดี — ต้องมีกติกา 4 อย่าง

1. Scope ที่ชัด — ระบุ domain / asset / function ที่ allowed test + ระบุที่ห้าม test (production database / customer PII / 3rd party service)
2. Severity rating + payout table — มี table ที่บอก “Critical = $10K-50K, High =$2K-10K, Medium = $500-2K, Low =$100-500”. Researcher รู้ก่อนเริ่ม
3. Triage process — ทีม security ของบริษัท (หรือ platform) ตรวจ + verify + categorize ทุก report. ตอบ researcher ภายใน 7-14 วัน
4. Safe Harbor clause — บอกว่าไม่ฟ้องร้อง researcher ที่ทำตาม scope. ข้อนี้ critical — เพราะถ้าไม่มี researcher จะกลัวติดคุก (เคส Coalfire ด้านล่าง)

ทำไม Bug Bounty ดี#

ลองนึกตัวเลข. Pen test 1 ครั้ง 4 สัปดาห์ — มี pen tester 2-3 คนทำ. รวม person-week 8-12 weeks. ราคาประมาณ $100K

Bug Bounty ที่เปิดอยู่ทั้งปี — มี researcher 5,000-10,000 คนที่ “อาจ” หลายเวลาว่างมาดู. ความถี่ของการตรวจ = ตลอดเวลา. และจ่ายเฉพาะที่เจอจริง — ROI ดีกว่าหลายเท่า

Apple จ่าย bug bounty ปี 2023 ประมาณ **$20 ล้าน USD** — เทียบกับการจ้าง internal red team เต็มเวลา 50 คน (ราคา$40-50M/ปี ที่ Bay Area) — แบบ bounty ได้ coverage ที่กว้างกว่าหลายเท่า

ข้อจำกัดของ Bug Bounty#

• ไม่เหมาะกับบริษัทที่ security ยังอ่อน — เพราะเปิดประตูให้ researcher เข้ามา 5,000 คน = traffic เพียบ. ถ้า log ของบริษัทยังไม่มีระบบจัดการ — จะเสีย noise มหาศาล
• Duplicate hell — bug เดียวกัน 50 คนรายงาน. Triage หนัก
• Researcher coverage ไม่สม่ำเสมอ — ส่วนใหญ่ดูที่ low-hanging fruit. Bug ลึกในซอก — ไม่ค่อยมีคนทำ (เพราะใช้เวลาเยอะ + อาจไม่ได้รางวัล)
• ไม่ทดแทน Red Team — Bug Bounty หา vuln. Red Team ทดสอบ detection. คนละจุดประสงค์

มุมผู้บริหาร — Bug Bounty ไม่ใช่ “ของฟรี”

ลำดับที่ถูก — (1) มี internal security team ที่พร้อม triage report → (2) ทำ pen test ครอบ baseline → (3) patch finding ของ pen test → (4) เปิด private bounty ก่อน (เชิญ researcher 20-50 คนที่เลือก) → (5) ค่อยเปิด public bounty. ถ้าเปิด public bounty ตั้งแต่ day 1 ของ program — จะถูก researcher 1,000 คนถล่ม + report ที่ duplicate + ทีมเหนื่อยจน burnout. เริ่มเล็ก ทำต่อเนื่อง ขยายช้าๆ

Google Project Zero — 90-Day Policy ที่เปลี่ยนวงการ#

ปี 2014 Google ตั้งทีม Project Zero — ทีม security researcher 30-40 คนที่หาช่องโหว่ใน software ของบริษัทอื่น (Microsoft, Apple, Adobe, Samsung, ฯลฯ). มี policy ที่ดัง — เปิดเผย:

“เราจะแจ้ง vendor + ให้ 90 วัน + 14 วัน grace period (ถ้า vendor ขอ). หลัง 90 วัน — เราเปิดเผยช่องโหว่ต่อสาธารณะ ไม่ว่า vendor จะ patch แล้วหรือไม่”

Policy นี้ถูกวิจารณ์หนักในช่วงแรก — โดยเฉพาะ Microsoft. มีกรณีที่ Project Zero เปิดเผย vuln ของ Windows 2 วันก่อน Patch Tuesday ที่ Microsoft วางแผนจะแก้อยู่แล้ว — สื่อตี Google ว่า “irresponsible”

แต่ในระยะยาว — policy นี้ทำให้ vendor patch เร็วขึ้นจริง. ก่อน Project Zero — Microsoft / Adobe / Oracle ใช้เวลา patch เฉลี่ย 6-12 เดือน. หลัง Project Zero — เหลือ 30-60 วัน (เพราะกลัว disclosure)

ในปี 2022 Project Zero ปรับ policy เป็น “90+30” — เพิ่ม 30 วันหลัง patch ออกก่อน technical detail เปิดเผย — เพื่อให้คนใช้ทันได้ update

Apple Security Research Device Program#

ปี 2020 Apple ออก Security Research Device (SRD) program — แจก iPhone พิเศษ ที่มี shell access ให้กับ researcher ที่ผ่าน vetting. ก่อนหน้านี้ — researcher ที่จะหา iOS vuln ต้อง jailbreak เครื่องตัวเอง ก่อน — ซึ่งละเมิด ToS

SRD เปลี่ยนเกม — researcher ที่ผ่านโครงการได้ device + tooling official + safe harbor — และเริ่มทำให้ iOS security improvement ระหว่าง Apple กับ research community เร็วขึ้นมาก

เคส Coalfire 2019 — กระดาษไม่ครบ = ติดคุก#

ปี 2019 บริษัท Coalfire (pentest firm) ได้รับสัญญาจากรัฐ Iowa Judicial Branch ให้ทดสอบ physical security ของ courthouse ในเมือง Polk County และ Dallas County. มี scope statement ที่อนุญาตให้ pen tester เข้า courthouse นอกเวลาทำการ — เพื่อทดสอบ alarm + lock + access control

วันที่ 11 กันยายน 2019 — pen tester 2 คน (Justin Wynn + Gary Demercurio) เข้า Dallas County Courthouse ตอนกลางคืน. Triggered alarm. Sheriff มาถึง — pen tester แสดงสัญญา + จดหมายจาก Iowa Judicial Branch

ปัญหา — Iowa Judicial Branch (รัฐ) มีอำนาจครอบคลุม Iowa Supreme Court เท่านั้น. Dallas County Courthouse เป็นของ County — คนละ jurisdiction. Sheriff ตัดสิน — สัญญาที่ pentester ถือ ไม่มีผลครอบคลุม County property

ผลคือ — pen tester 2 คน โดนจับติดคุก 12 ชั่วโมง — ตั้งข้อหา 3rd degree burglary (ข้อหาที่หนัก). Coalfire ต้องวุ่นแก้คดี — สุดท้ายข้อหาถูกลดลงเป็น trespass แล้วยกฟ้องในปี 2020. แต่ — ติดคุกคืนนั้นเกิดขึ้นจริง

บทเรียนของวงการจากเคสนี้ — paperwork สำคัญกว่า technical skill. ถ้า pen tester ไม่มีกระดาษอนุญาตที่ถูก jurisdiction + ถูกครอบคลุม asset = อาจติดคุกจริง ไม่ว่าจะมีสัญญากับบริษัทแม่หรือไม่. หลังเคสนี้ — pentest firm ทั่วโลก ปรับ template สัญญา ให้ระบุ jurisdiction + ครอบคลุม physical asset ทั้งหมดที่จะ test + ระบุชื่อ contact ของฝ่ายตำรวจท้องที่ที่ต้องโทรหากถูกจับ

Hacking Team 2015 — บริษัท security ที่โดนแฮกเสียเอง#

อีกเคสที่ผู้บริหารควรจำ — ปี 2015 บริษัท Hacking Team จาก Italy (ผลิต spyware ขายให้รัฐบาลทั่วโลก) โดนแฮก — โจรดูดข้อมูล 400 GB ออกมา + leak ลง internet — มี source code, internal email, customer list (รวมรัฐบาลที่ละเมิดสิทธิมนุษยชนหลายประเทศ), zero-day exploit ที่ Hacking Team ซื้อมาแต่ยังไม่ใช้

บทเรียน — แม้แต่บริษัท security ก็โดนแฮกได้. ไม่มีใครปลอดภัย 100%. Assume Breach mindset (ที่เราคุยใน EP.05) ต้องอยู่กับทุกคน — รวมทั้งคนที่ขาย security ให้คนอื่น

มุมผู้บริหาร: ถ้าบริษัทคุณเป็น vendor ที่ขาย software — ต้องมี vulnerability disclosure policy + security.txt (RFC 9116) หน้า website. ไม่มี = researcher ที่ใจดีอาจไม่รู้ทางติดต่อ → full disclosure → ลูกค้าของคุณพัง. ถ้าบริษัทคุณเป็นลูกค้าของ vendor — ก่อนซื้อ ถามว่า “vendor มี vulnerability disclosure policy ไหม + เคย patch ภายใน 90 วันที่ Project Zero ตั้ง deadline ไหม?” เป็นสัญญาณว่าความเป็นผู้ใหญ่ของ vendor มีแค่ไหน

6 ขั้นของ VM Lifecycle#

VM เป็น closed loop — จบขั้น 6 แล้วกลับไป 1 ใหม่. ไม่ใช่ project แต่เป็น operational process ที่ไม่หยุด

1
1. Discover (ค้นหา asset)
2
   ↓
3
2. Assess (สแกน + วิเคราะห์)
4
   ↓
5
3. Prioritize (จัดลำดับ)
6
   ↓
7
4. Remediate (แก้/patch)
8
   ↓
9
5. Verify (ตรวจซ้ำว่าแก้สำเร็จ)
10
   ↓
11
6. Report (รายงาน + วัด KPI)
12
   ↓
13
   วนกลับ 1

ขั้น 1: Discover — รู้ก่อนว่ามีอะไรต้อง scan

นี่คือขั้นที่บริษัทไทย ตกบ่อยที่สุด. ก่อนจะ scan ได้ — ต้องรู้ก่อนว่ามี asset อะไรบ้าง — ทุก server / endpoint / cloud instance / container / IoT device. ใช้ tool เช่น Asset Discovery ของ Tenable / Qualys, CMDB (Configuration Management Database) ของ ServiceNow, AWS Config / Azure Resource Graph สำหรับ cloud

ปัญหาคลาสสิค — บริษัทบอก “เรา scan ครบ” — แต่ scan เฉพาะ asset ที่อยู่ใน inventory. ของที่ shadow IT (พนักงานสร้างเอง) หรือ forgotten asset (server เก่าที่ลืม) — ไม่อยู่ใน scan. โจรเข้าผ่านจุดที่ไม่มีใครรู้ว่ามี

ขั้น 2: Assess — สแกน + วิเคราะห์ context

รัน vuln scanner (ตามที่คุยใน section Vuln Scan ก่อนหน้า) + รับ output ของ BAS (technique coverage) + รับ finding ของ pen test ล่าสุด → รวมเป็น single backlog ของ vuln ทั้งหมด

แต่ raw output ของ scanner ไม่พอ — ต้อง enrich ด้วย context:

• Asset criticality — vuln นี้อยู่บน production database (สำคัญ) หรือ test server (ไม่สำคัญ)?
• Exposure — internet-facing หรือ internal only?
• Compensating control — มี firewall / WAF / segmentation ที่กันได้ไหม?
• Exploit availability — มี public exploit (Metasploit / GitHub) แล้วหรือยัง?

ขั้น 3: Prioritize — CVSS อย่างเดียวไม่พอ

นี่คือขั้นที่ทำให้ VM ที่ดีต่างจาก VM ห่วย. CVSS ตัวเดียวไม่ใช่ priority — เพราะ CVSS วัด “ความรุนแรง” แต่ไม่วัด “ความน่าจะถูกใช้จริง”

วงการใช้ 3 framework ในการ prioritize:

• CVSS (Common Vulnerability Scoring System) — 0-10 score — บอกความรุนแรงทาง technical
• EPSS (Exploit Prediction Scoring System) — โดย FIRST.org — % โอกาสที่ vuln จะถูก exploit ใน 30 วัน. เปลี่ยน mindset จาก “patch ทุก critical” → “patch ที่จะถูกใช้จริง”
• KEV (Known Exploited Vulnerabilities) — โดย CISA (US) — รายการ vuln ที่ ถูก exploit ในธรรมชาติแล้ว. ของใน KEV = ต้อง patch ก่อนเสมอ

ตัวอย่างจริง — CVE หนึ่ง CVSS = 7.5 (High) แต่ EPSS = 0.3% (โอกาสต่ำ) + ไม่อยู่ใน KEV → priority ต่ำ. CVE อีกตัว CVSS = 6.0 (Medium) แต่ EPSS = 87% + อยู่ใน KEV → priority สูงสุด

บริษัทที่ patch ตาม CVSS อย่างเดียว = patch 200 critical ที่ไม่มีใครใช้ + พลาด 1 medium ที่ ransomware ใช้จริง

ขั้น 4: Remediate — patch / mitigate / accept

3 ทางเลือกในการจัดการ vuln แต่ละตัว:

• Patch — update software → กำจัด vuln. วิธีหลักที่ต้องทำ
• Mitigate — แก้ไม่ได้ทันที (เช่น software เก่าที่ vendor ไม่ patch) → ใช้ compensating control ลด risk (เช่น ปิด port / เพิ่ม WAF rule / segment network)
• Accept — risk ต่ำ + cost of fix สูง → ผู้บริหารเซ็นยอมรับ risk เป็นลายลักษณ์อักษร

SLA ตาม priority — บริษัทที่มี VM mature จะมี SLA ชัด เช่น:

ขั้น 5: Verify — ตรวจซ้ำว่า patch ทำงานจริง

นี่คือขั้นที่ทุกคนข้าม. Patch deploy แล้ว ≠ vuln หายไป. ต้อง re-scan asset นั้น + ยืนยันว่า scanner ไม่เจอ vuln เดิมอีก. ถ้ายังเจอ — patch ไม่ทำงาน (อาจ deploy ผิด version หรือ service ไม่ restart)

วงการเรียกขั้นนี้ว่า “Trust but verify” — Patch management ทีมบอกว่า patch แล้ว แต่ Security ทีมต้อง verify เอง

ขั้น 6: Report — KPI ที่ผู้บริหารต้องเห็น

VM ที่ดีต้อง report 3 ตัวเลขขั้นต่ำ ทุกเดือนให้ผู้บริหาร:

1. MTTR (Mean Time To Remediate) — ค่าเฉลี่ยจาก discover → patched. แยกตาม priority. Critical MTTR > 7 วัน = สัญญาณอันตราย
2. % SLA compliance — patch ทันตาม SLA กี่เปอร์เซ็นต์. ต่ำกว่า 90% = process มีปัญหา
3. Vulnerability debt — vuln ที่ เลย SLA แล้วยังไม่ patch. ตัวเลขนี้ต้องลดลงทุกเดือน — ถ้าโตขึ้น = ทีมแพ้ backlog

เคส Equifax 2017 — ตัวอย่างของ VM ที่ล้ม#

ปี 2017 — Equifax (credit bureau ใหญ่ของอเมริกา) breach — รั่ว 147 ล้าน record ของลูกค้า — ค่าปรับ + lawsuit รวม $1.4 พันล้าน USD

โจรเข้าผ่าน vuln ใน Apache Struts (CVE-2017-5638) — Apache patch ออกมา 6 สัปดาห์ก่อนที่ Equifax โดน

ในเอกสาร framework ทุกตัว — บอกว่า Equifax ต้องมี vulnerability management. ของจริง:

• ✅ Discover — Apache Struts อยู่ใน inventory
• ✅ Assess — scanner รายงาน CVE-2017-5638 หลัง patch ออก
• ❌ Prioritize — vuln นี้อยู่ใน production web application internet-facing — ควรเป็น critical
• ❌ Remediate — 6 สัปดาห์ไม่ patch — เพราะทีม assume ว่า patch ออกไปแล้ว (ไม่มี verify)
• ❌ Verify — ไม่ verify ว่า patch ทำงานจริง
• ❌ Report — KPI ที่บอก “เรามี vuln critical ที่เลย SLA 30 วัน” — ไม่มีคนเห็น

VM ที่มี process บนกระดาษแต่ไม่ทำงานจริง = vendor checkbox ที่จะเสีย $1.4B ในวันที่ใครคนใดคนหนึ่งเจอ vuln นั้นก่อน

มุมผู้บริหาร — Vuln Scan ไม่ใช่ Vulnerability Management

ถ้า CISO เดินมาบอก “เราทำ vulnerability management แล้ว” — ถามต่อ 3 คำถามทันที. คำถามที่ 1: MTTR ของ critical vuln ปัจจุบันเท่าไหร่? ถ้าตอบไม่ได้ทันที = ไม่มี VM. คำถามที่ 2: บริษัทเรามี vuln ที่เลย SLA กี่ตัวตอนนี้? ถ้าตอบ “ไม่ทราบ” = backlog ไม่มีใครดู. คำถามที่ 3: ใครเซ็น accept risk สำหรับ vuln ที่ตัดสินใจไม่ patch? ถ้าไม่มีลายเซ็น = ไม่มีใครรับผิด. VM ที่ดี ≠ มี scanner. VM ที่ดี = มี closed loop + SLA + KPI ที่วัดได้ + ลายเซ็นรับผิด

2 leader takeaways#

Takeaway 1: เลือกเครื่องมือให้ตรงคำถาม — อย่าให้คนขายเลือกให้

Pattern คลาสสิคของวงการ — vendor ของ pen test เดินมาขาย “Red Team Service” เพราะมัน margin สูง. CEO ของบริษัทกลางๆ ตอบรับเพราะ “ฟังดูใหญ่”. ทำไปแล้ว 6 เดือน — ได้ debrief 50 หน้า — Blue Team อ่านไม่เข้าใจเพราะยังไม่พร้อม — engagement กลายเป็น “ของหรูที่ไม่ได้ใช้”

ขั้นบันได 5 ระดับ ที่ตรงประเด็น — (1) Vuln Scan รายเดือน + VM Lifecycle ที่ปิด loop → (2) Pen Test รายปี + patch finding → (3) BAS รายวัน (วัด detection coverage ของ control) → (4) Purple Team (Red + Blue ทำงานร่วมกัน) → (5) Red Team แบบลับ. แต่ละขั้นใช้เงินมากขึ้น 3-10 เท่า — ข้ามขั้นไม่ได้ ของ value หาย. ผู้บริหารต้องถาม CISO ก่อนทุกครั้ง — “เราอยู่ขั้นไหนของบันได + เครื่องมือนี้ตอบคำถามอะไร” ไม่ใช่ “เครื่องมือนี้แพงพอที่จะรู้สึกปลอดภัยไหม”

Takeaway 2: Paperwork = ส่วนหนึ่งของ Security — ไม่ใช่งานน่าเบื่อ

เคส Coalfire สอนว่า — สัญญา + scope + jurisdiction ที่ชัด คือเส้นบางๆ ระหว่าง “pen tester ที่ทำงานถูก” กับ “อาชญากรในสายตากฎหมาย”. สำหรับบริษัทที่ จ้าง pen test — ต้องตรวจให้ครบ 4 อย่างก่อนเริ่ม

• Scope — ระบุ asset + IP range + ช่วงเวลา test
• Authorization letter — ผู้มีอำนาจของบริษัท + ผู้มีอำนาจของ asset ทุกตัว (ถ้าเป็น 3rd party host — ขออนุญาตเขาด้วย)
• Emergency contact — ชื่อ + เบอร์โทร 24/7 ของฝ่ายตำรวจท้องที่ + ฝ่ายกฎหมายของบริษัท
• Rules of Engagement — ห้ามอะไร / อนุญาตอะไร + ขั้นตอนเมื่อเจอ critical finding

CISO + Legal Counsel ของบริษัทต้องเซ็นทุกครั้ง — ไม่ใช่ delegation ให้ IT manager. เพราะถ้าเกิดเรื่อง — คนที่รับผิดทางกฎหมายคือ entity ที่เซ็น. และในมุมของบริษัทที่ เป็น pen test firm — มี insurance + legal cover + template สัญญาที่ลึก เป็นการลงทุนที่ optional ไม่ได้