Checklist 15 ข้อก่อนจ้าง Pentest — เตรียมอะไรบ้างให้ได้ผลดีที่สุด

การเตรียมตัวที่ดีก่อนจ้าง Pentest ส่งผลโดยตรงต่อคุณภาพของผลลัพธ์ที่ได้ บทความนี้รวบรวม 15 ข้อที่ควรเตรียมแบ่งเป็น 3 ระยะ ตั้งแต่ก่อนขอราคาจนถึงหลังได้รายงาน

กลุ่ม A: ก่อนขอราคา (5 ข้อ)

ข้อมูลเหล่านี้ช่วยให้ผู้ให้บริการประเมินราคาและระยะเวลาได้แม่นยำ หากไม่มีข้อมูลครบ ราคาที่ได้จะเป็นเพียงการประมาณคร่าว ๆ

✅ 1. กำหนด Scope ให้ชัดเจน

สิ่งที่ต้องเตรียม: รายการระบบ/แอปพลิเคชัน/เครือข่ายที่ต้องการทดสอบ

Tips: ยิ่ง scope ชัด ราคายิ่งแม่นยำ หากยังไม่แน่ใจขอบเขต สามารถปรึกษาผู้ให้บริการเพื่อช่วยกำหนด scope ที่เหมาะสมได้ ดูแนวทางเพิ่มเติมที่ คู่มือ Pentest

✅ 2. ระบุประเภทและจำนวนระบบ

สิ่งที่ต้องเตรียม: ข้อมูลทางเทคนิคพื้นฐานของแต่ละระบบ

• Technology stack — ภาษาโปรแกรม, framework, database, web server
• จำนวน — จำนวน URL, API endpoint, IP address, mobile platform
• Authentication — มีระบบ login กี่ role (admin, user, moderator ฯลฯ)
• สถาปัตยกรรม — monolith, microservices, serverless

Tips: ส่ง architecture diagram (แม้เป็น high-level) ช่วยให้ผู้ให้บริการเข้าใจระบบได้เร็วขึ้น

✅ 3. ระบุ Environment ที่จะทดสอบ

สิ่งที่ต้องเตรียม: ตัดสินใจว่าจะทดสอบบน environment ใด

Tips: สำหรับระบบที่ไม่สามารถหยุดให้บริการได้ (เช่น Internet Banking) ควรใช้ staging environment ที่ mirror จาก production ล่าสุด ข้อกำหนด ธปท. สกช. 5/2566 ไม่ได้ระบุบังคับให้ทดสอบบน production แต่คาดหวังว่าผลลัพธ์สะท้อนความเสี่ยงจริงของระบบที่ให้บริการ [1]

✅ 4. ตรวจสอบข้อกำหนด Compliance

สิ่งที่ต้องเตรียม: รายการมาตรฐานและข้อกำหนดที่องค์กรต้องปฏิบัติตาม

ข้อกำหนดที่พบบ่อยสำหรับองค์กรในประเทศไทย:

• ธปท. สกช. 5/2566 — สถาบันการเงิน: VA + Pentest ปีละ 1 ครั้ง [1]
• มาตรฐานเว็บไซต์ สกมช. 2568 — หน่วยงานรัฐ: VA บังคับ, Pentest ตามระดับผลกระทบ [2]
• PCI DSS — ระบบรับชำระเงิน: Pentest ปีละ 1 ครั้ง + ASV scan รายไตรมาส
• ISO 27001 — ต้องทดสอบความปลอดภัยเป็นระยะ
• PDPA — มาตรการรักษาความปลอดภัยที่เหมาะสม [3]

Tips: แจ้งข้อกำหนดที่เกี่ยวข้องให้ผู้ให้บริการทราบตั้งแต่ต้น เพื่อให้รายงานตอบโจทย์ compliance ได้ตรงจุด ดูรายละเอียดที่ Compliance Guide

✅ 5. ประมาณงบประมาณ

สิ่งที่ต้องเตรียม: กรอบงบประมาณคร่าว ๆ

ปัจจัยที่มีผลต่อราคา:

• ขนาด scope (จำนวนระบบ, endpoints, IP)
• ความซับซ้อน (custom business logic, จำนวน role)
• ประเภทการทดสอบ (Black/Grey/White-box)
• ข้อกำหนดพิเศษ (retest, executive presentation, compliance-specific report format)

Tips: อ่าน VA กับ Pentest ต่างกันอย่างไร เพื่อเข้าใจความแตกต่างด้านราคา ใช้ Scope Questionnaire + ร่าง TOR เพื่อเตรียมข้อมูลขอใบเสนอราคา

กลุ่ม B: ก่อนเริ่มทดสอบ (5 ข้อ)

หลังจากเลือกผู้ให้บริการแล้ว ข้อเตรียมการเหล่านี้ต้องเสร็จก่อนวันเริ่มทดสอบ

✅ 6. ลงนาม NDA (Non-Disclosure Agreement)

สิ่งที่ต้องเตรียม: สัญญารักษาความลับระหว่างสองฝ่าย

NDA ควรครอบคลุม:

• ขอบเขตข้อมูลที่ถือว่าเป็นความลับ
• ระยะเวลาการรักษาความลับ
• ข้อกำหนดการทำลายข้อมูลหลังสิ้นสุดโครงการ
• บทลงโทษเมื่อฝ่าฝืน

Tips: NDA ควรลงนามก่อนแลกเปลี่ยนข้อมูลทางเทคนิคใด ๆ ผู้ให้บริการ Pentest มืออาชีพจะเป็นฝ่ายเสนอ NDA เอง

✅ 7. กำหนด Rules of Engagement (RoE)

สิ่งที่ต้องเตรียม: เอกสารข้อตกลงวิธีการทดสอบ

RoE ควรระบุ:

• ช่วงเวลาที่อนุญาตให้ทดสอบ — เช่น วันจันทร์–ศุกร์ 09:00–18:00 หรือ 24/7
• ระบบ/IP ที่ห้ามทดสอบ (out-of-scope) — เช่น ระบบ third-party, production database ที่มีข้อมูลจริง
• ประเภทการทดสอบที่อนุญาต/ไม่อนุญาต — เช่น DoS testing, social engineering
• ขั้นตอนเมื่อพบช่องโหว่ร้ายแรง — แจ้งใครทันที ผ่านช่องทางไหน
• ช่องทางติดต่อฉุกเฉิน — เบอร์โทร, email ของทั้งสองฝ่าย

Tips: ประกาศ ธปท. สกช. 5/2566 กำหนดให้ผู้ทดสอบต้องมี “ความเป็นอิสระ” [1] — RoE ช่วยรับรองว่าการทดสอบดำเนินการอย่างเป็นอิสระภายใต้ขอบเขตที่ตกลงกัน

✅ 8. เตรียม Credential (สำหรับ Grey/White-box)

สิ่งที่ต้องเตรียม: บัญชีผู้ใช้สำหรับการทดสอบ

หากเป็น Grey-box หรือ White-box test ควรเตรียม:

• บัญชีผู้ใช้แต่ละ role — admin, user, moderator ฯลฯ (อย่างน้อย 2 บัญชีต่อ role เพื่อทดสอบ horizontal access control)
• API key / token — สำหรับ API testing
• VPN access — หากทดสอบระบบภายใน
• Source code access — สำหรับ White-box testing

Tips: ใช้บัญชีทดสอบเฉพาะ ไม่ใช้บัญชีจริงของพนักงาน และสร้างข้อมูลทดสอบที่ไม่ใช่ข้อมูลจริงของลูกค้า

✅ 9. สร้าง Test Account พร้อมข้อมูลทดสอบ

สิ่งที่ต้องเตรียม: บัญชีทดสอบและข้อมูลจำลอง

• สร้าง test account ที่มีข้อมูลเพียงพอสำหรับการทดสอบ (เช่น มีรายการสั่งซื้อ, มีประวัติธุรกรรม)
• ข้อมูลทดสอบควรเป็นข้อมูลจำลอง (synthetic data) ไม่ใช่ข้อมูลจริงของลูกค้า — โดยเฉพาะอย่างยิ่งเมื่อทดสอบบน staging environment
• เปิดการเข้าถึงที่จำเป็น เช่น whitelist IP ของผู้ทดสอบ (หากมี WAF)

Tips: แจ้งผู้ให้บริการล่วงหน้าว่ามี WAF, IPS หรือ rate limiting หรือไม่ หากจำเป็น อาจต้อง whitelist IP ของผู้ทดสอบในช่วงทดสอบเพื่อให้ได้ผลลัพธ์ที่ครบถ้วน (แต่บางองค์กรเลือกไม่ whitelist เพื่อทดสอบ defense-in-depth)

✅ 10. แจ้ง Stakeholder ที่เกี่ยวข้อง

สิ่งที่ต้องเตรียม: การสื่อสารภายในองค์กร

ควรแจ้งให้ทราบล่วงหน้า:

• ทีม IT/Security — เพื่อไม่ให้ตกใจเมื่อเห็น traffic ผิดปกติ
• ทีม SOC / MSSP — เพื่อ track activity ของ Pentest แยกจาก real attack
• ผู้บริหาร — เพื่อรับทราบและอนุมัติ
• ทีม DevOps — เพื่อเตรียม rollback plan หากเกิดปัญหา
• Cloud/Hosting Provider — บาง provider กำหนดให้แจ้ง Pentest ล่วงหน้า (เช่น AWS ไม่จำเป็นต้องแจ้งสำหรับ service ส่วนใหญ่ แต่มีข้อยกเว้นบาง service)

Tips: จัดทำ communication plan สั้น ๆ ระบุว่าใครต้องรู้อะไร เมื่อไหร่ และช่องทางติดต่อฉุกเฉิน

กลุ่ม C: หลังได้รายงาน (5 ข้อ)

รายงาน Pentest มีค่าก็ต่อเมื่อนำไปปฏิบัติ ข้อเหล่านี้ช่วยให้การแก้ไขเป็นระบบ

✅ 11. Review Findings ร่วมกับผู้ทดสอบ

สิ่งที่ต้องทำ: ประชุม review รายงานร่วมกัน

• ขอ debrief session กับทีมผู้ทดสอบ
• ถามรายละเอียดเพิ่มเติมสำหรับ finding ที่ไม่ชัดเจน
• ยืนยัน severity rating ร่วมกัน — บาง finding อาจมี business context ที่ทำให้ severity เปลี่ยน
• ตรวจสอบว่าผลลัพธ์ครอบคลุม scope ที่ตกลงไว้

Tips: ผู้ให้บริการที่ดีจะเสนอ debrief session เป็นส่วนหนึ่งของบริการ — หากไม่มี ควรขอ

✅ 12. จัดลำดับความสำคัญ (Prioritize)

สิ่งที่ต้องทำ: จัดอันดับ finding ตามความเสี่ยงจริงขององค์กร

แนวทางจัดลำดับ:

Tips: ประกาศ ธปท. สกช. 5/2566 กำหนดว่าช่องโหว่ระดับ Critical และ High ทุกรายการต้องได้รับการแก้ไขพร้อมหลักฐานการทดสอบซ้ำยืนยัน [1]

✅ 13. วางแผนและดำเนินการ Remediation

สิ่งที่ต้องทำ: แก้ไขช่องโหว่ตามลำดับที่จัดไว้

• มอบหมาย finding แต่ละรายการให้ผู้รับผิดชอบเฉพาะ (ทีม dev, infra, cloud)
• กำหนด deadline ตามตาราง prioritization
• ติดตามความคืบหน้าผ่าน issue tracker (Jira, Azure DevOps ฯลฯ)
• ตรวจสอบ fix ในระดับโค้ดก่อน deploy — ไม่ใช่แค่ workaround

Tips: สำหรับ finding ที่แก้ไขเชิงเทคนิคทันทีไม่ได้ ให้จัดทำ compensating control เป็นมาตรการชั่วคราว (เช่น WAF rule, network ACL) แต่ต้องวางแผนแก้ไขที่ root cause ด้วย

✅ 14. ทำ Retest

สิ่งที่ต้องทำ: ให้ผู้ทดสอบเดิมทดสอบซ้ำเพื่อยืนยันว่าแก้ไขเรียบร้อย

• ทดสอบซ้ำทุก finding ระดับ Critical และ High — ตาม best practice และข้อกำหนด ธปท.
• ตกลงเรื่อง retest scope ล่วงหน้า — บางผู้ให้บริการรวม retest ในราคาเดิม บางรายคิดเพิ่ม
• ขอรายงาน retest แยกต่างหากที่ระบุสถานะ pass/fail ของแต่ละ finding

Tips: Retest ควรทำโดยผู้ทดสอบรายเดิมเพื่อความต่อเนื่อง และหลักเกณฑ์ ธปท. กำหนดให้ต้องมีหลักฐานการแก้ไขและทดสอบซ้ำ [1]

✅ 15. จัดเก็บ Attestation และวางแผนรอบถัดไป

สิ่งที่ต้องทำ: จัดเก็บหลักฐานและเตรียมรอบถัดไป

• จัดเก็บรายงาน — Pentest Report, Retest Report, Executive Summary
• ใช้เป็นหลักฐาน Compliance — แนบกับ IT risk self-assessment ส่ง ธปท. หรือใช้ตอบ compliance audit
• เปรียบเทียบกับปีก่อน — จำนวน finding ลดลงหรือเพิ่มขึ้น ประเภท finding เปลี่ยนไปอย่างไร
• วางแผนรอบถัดไป — กำหนดงบประมาณและ timeline สำหรับ Pentest ปีหน้า
• นำเสนอผู้บริหาร — สรุปผลลัพธ์และแนวโน้มเสนอต่อคณะกรรมการหรือผู้บริหาร

Tips: Verizon DBIR 2025 รายงานว่าช่องโหว่ใหม่เกิดขึ้นตลอดเวลา — การ exploit ช่องโหว่เป็นช่องทางเริ่มต้นของการโจมตีถึง 20% [4] การทดสอบครั้งเดียวไม่เพียงพอ ควรทำเป็นรอบ (อย่างน้อยปีละ 1 ครั้ง)

สรุป Checklist

ขั้นตอนถัดไป

1. อ่าน คู่มือ Pentest ฉบับสมบูรณ์ สำหรับรายละเอียดกระบวนการทำงาน
2. ใช้ Scope Questionnaire + ร่าง TOR เพื่อเตรียมข้อมูลขอใบเสนอราคา
3. ดู บริการทดสอบเจาะระบบ ทั้งหมดของ ITSL
4. อ่าน Pentest คืออะไร สำหรับพื้นฐานก่อนตัดสินใจ

แหล่งอ้างอิง

1. ประกาศ ธปท. สกช. 5/2566 เรื่องหลักเกณฑ์การกำกับดูแลความเสี่ยงด้านเทคโนโลยีสารสนเทศ ข้อ 6.6–6.7 — bot.or.th
2. ประกาศ กมช. เรื่องมาตรฐานการรักษาความมั่นคงปลอดภัยสำหรับเว็บไซต์ พ.ศ. 2568 — ncsa.or.th
3. พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) มาตรา 37 — ratchakitcha.soc.go.th
4. Verizon, 2025 Data Breach Investigations Report — verizon.com/dbir