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 = “ระบบเตือนภัย” — ยังต้องใช้คนตัดสินว่าเตือนอันไหนของจริง

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 แบบลับ

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

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

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 ครอบคลุม:

• Privilege Escalation (ยกระดับสิทธิ์) — เข้ามาเป็น user ธรรมดา → หาทางเป็น admin / root / Domain Admin
• Lateral Movement (เคลื่อนข้าง) — จากเครื่องแรก → เคลื่อนไปเครื่องที่ 2, 3, 4 ในเครือข่ายภายใน
• Persistence (ยึดถาวร) — ตั้ง backdoor ให้กลับเข้ามาได้แม้จะ reboot
• Data Exfiltration (ดูดข้อมูลออก) — ลองเอาข้อมูล sensitive ออกจริง (จำลอง — ไม่ได้เอาออกจริง)
• Pivot — ใช้เครื่องที่ได้เป็น base ไปโจมตี subnet อื่นที่เข้าตรงไม่ได้

ประเด็นสำคัญที่ผู้บริหารต้องเข้าใจในขั้นนี้ — “เข้าได้” ไม่เท่ากับ “เสียหาย”. 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

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 มีแค่ไหน

2 leader takeaways#

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

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

ขั้นบันได 4 ระดับ ที่ตรงประเด็น — (1) Vuln Scan รายเดือน + patch ตาม → (2) Pen Test รายปี + patch finding → (3) Purple Team (Red + Blue ทำงานร่วมกัน) → (4) Red Team แบบลับ. แต่ละขั้นใช้เงินมากขึ้น 5-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 ไม่ได้