เลือกบริษัท Pentest อย่างไร? สิ่งที่ผู้บริหารไทยควรประเมินก่อนเซ็นสัญญา

Penetration Test ไม่ได้คุณภาพเท่ากันทุกงาน ผลลัพธ์จะออกมาเป็นการทดสอบที่ครอบคลุมหรือแค่ทำพอเป็นพิธี ขึ้นอยู่กับเรื่องเดียว: คุณจ้างบริษัทไหน

ตลาด cybersecurity ในไทยกำลังเติบโต ผู้ให้บริการมีให้เลือกมากมาย

ตั้งแต่บริษัทที่ปรึกษาข้ามชาติไปจนถึง freelancer จากทีม offensive security ที่เชี่ยวชาญจริง ไปจนถึงบริษัทที่แค่รัน scanner อัตโนมัติแล้วส่งผลลัพธ์มาเป็น "รายงาน pentest" โจทย์ของผู้ซื้อคือ ต้องแยกให้ออกก่อนเซ็นสัญญา

คู่มือนี้เขียนสำหรับ IT Director, Procurement Officer และ CISO ที่กำลังเลือกผู้ให้บริการ Penetration Testing ในไทย เนื้อหาครอบคลุมทั้งสิ่งที่ควรมองหา สิ่งที่ควรหลีกเลี่ยง และวิธีประเมินให้ได้ผลด้านความปลอดภัยจริง ไม่ใช่แค่ทำเพื่อให้ผ่าน checkbox

ทำไมการเลือกผู้ให้บริการถึงสำคัญ

Penetration Test จะดีหรือไม่ ขึ้นอยู่กับคนที่ทดสอบ ผู้ให้บริการ 2 รายที่ได้ scope เดียวกัน อาจส่งมอบผลลัพธ์ที่ต่างกันลิบ:

• บริษัท A รัน scanner อัตโนมัติ ใช้เวลาวัน-สองวันคลิกดูคร่าวๆ แล้วส่งรายงาน 200 หน้าที่เต็มไปด้วย output จากเครื่องมือ กับคำแนะนำแก้ไขแบบกว้างๆ ทุก finding มี CVSS score แต่ไม่มี business context ราคา: ฿80,000

• บริษัท B ให้ผู้เชี่ยวชาญใช้เวลา 10 วันทดสอบแอป พบช่องโหว่ business logic ที่ทำให้ผู้ใช้คนไหนก็ได้เข้าถึงข้อมูลทางการเงินของคนอื่น แล้ว chain กับช่องโหว่ IDOR จนทำ account takeover ได้เต็มรูปแบบ รายงานมาพร้อมขั้นตอน reproduce ทีละขั้น และคำแนะนำแก้ไขที่ developer ทำตามได้เลย ราคา: ฿350,000

รายงานบริษัท A ดูน่าประทับใจเพราะเล่มหนา ส่วนบริษัท B อาจมี finding น้อยกว่า แต่ทุก finding ถูก verify แล้ว exploit ได้จริง และเชื่อมโยงกับ business risk โดยตรง ถ้าเลือกตามราคาหรือจำนวนหน้าอย่างเดียว คุณจะได้บริษัท A เกือบแน่นอน

ผลกระทบมีจริง ค่าเสียหายเฉลี่ยจาก data breach ทั่วโลกอยู่ที่ $4.88M (IBM 2024) ช่องโหว่สำคัญที่หลุดไปจากการทดสอบ อาจสร้างความเสียหายมากกว่าส่วนต่างราคาระหว่างผู้ให้บริการหลายเท่า

เกณฑ์การประเมินหลัก

1. คุณสมบัติและใบรับรองของทีม

คุณภาพของ penetration test ขึ้นอยู่กับทักษะของคนที่ลงมือทดสอบจริง ต้องถามให้ชัดว่าใครจะรับผิดชอบงานของคุณ อย่าดูแค่ทีมรวมของบริษัท

ใบรับรองที่แสดงความสามารถ offensive จริง:

ใบรับรอง	สาขา	พิสูจน์อะไร
OSCP (Offensive Security Certified Professional)	Network และ application exploitation	สามารถเจาะระบบจริงในสภาพแวดล้อมสอบ
OSCE3 (Offensive Security Certified Expert 3)	Advanced web, exploit dev, evasion	ทักษะ offensive ระดับสูงในหลาย domain
OSWE (Offensive Security Web Expert)	White-box web app testing	สามารถหาและ exploit ช่องโหว่ผ่านการ review source code
eMAPT (eLearnSecurity Mobile Application Penetration Tester)	Mobile app security	Exploit แอปมือถือได้จริง (Android และ iOS)
eWPT (eLearnSecurity Web Application Penetration Tester)	Web app security	Exploit เว็บแอปได้จริง
CREST (ระดับต่างๆ)	Penetration testing ทั่วไป	ใบรับรองที่ได้รับการยอมรับในระดับสากล
CRTO (Certified Red Team Operator)	Red teaming กับ C2 frameworks	เทคนิค adversary simulation และ evasion
CRTA (Certified Red Team Analyst)	Threat intelligence สำหรับ red teaming	การวางแผนโจมตีแบบ intelligence-led

สิ่งที่ควรมองหา: ถามว่าคนที่จะมาทดสอบจริงมีใบรับรองอะไรบ้าง บริษัทอาจโชว์ 20 ใบรับรองบนเว็บไซต์ แต่ถ้าคนที่ลงมือทดสอบเป็น junior analyst ที่ไม่มี offensive certification ใบรับรองเหล่านั้นก็ไม่มีความหมายกับงานของคุณ

สิ่งที่ควรระวัง: ใบรับรองอย่าง CEH (Certified Ethical Hacker) และ CompTIA PenTest+ เป็นข้อสอบแบบ multiple-choice ที่วัดความรู้ทฤษฎี บอกได้ว่าเข้าใจแนวคิด แต่ไม่ได้พิสูจน์ว่าหาและ exploit ช่องโหว่ได้จริง จึงไม่ควรเป็น credential หลักของทีม pentest

2. Methodology (ระเบียบวิธีการทดสอบ)

Methodology ที่มีโครงสร้างชัดเจนช่วยให้การทดสอบครอบคลุมและสม่ำเสมอ ควรถามว่าผู้ให้บริการยึด framework อะไร และนำไปใช้งานจริงอย่างไร

Methodology มาตรฐานอุตสาหกรรม:

• OWASP WSTG (Web Security Testing Guide): Framework หลักสำหรับทดสอบ web application ครอบคลุม 91 test cases ใน 12 categories ผู้ให้บริการที่ทำ web app pentest ควรยึดตามนี้หรืออธิบายได้ว่าแนวทางของตนเทียบเท่าอย่างไร
• OWASP MASTG (Mobile Application Security Testing Guide): เทียบเท่า WSTG แต่สำหรับ mobile ครอบคลุมการทดสอบเฉพาะแพลตฟอร์มสำหรับ iOS และ Android
• PTES (Penetration Testing Execution Standard): Framework ครอบคลุมที่ cover ทั้ง engagement lifecycle ตั้งแต่ intelligence gathering จนถึง reporting
• OSSTMM (Open Source Security Testing Methodology Manual): Methodology เชิงวิทยาศาสตร์สำหรับวัดผล operational security

วิธีตรวจสอบ: ให้ผู้ให้บริการ walk through ขั้นตอนการทดสอบสำหรับงานประเภทของคุณ ถ้าอ้างว่าใช้ OWASP WSTG ต้องอธิบาย approach สำหรับ authentication testing, session management, input validation, business logic และ category อื่นๆ ได้ ถ้าตอบแค่กว้างๆ ว่า "เราทดสอบทุกช่องโหว่" นั่นเป็นสัญญาณเตือน

3. คุณภาพรายงาน

รายงานคือ deliverable หลัก developer ใช้แก้ปัญหา ผู้บริหารใช้เข้าใจความเสี่ยง auditor ใช้ตรวจ compliance ถ้ารายงานแย่ engagement ทั้งหมดก็สูญเปล่า

รายงานที่ดีมีอะไรบ้าง:

• Executive summary เขียนสำหรับผู้มีอำนาจตัดสินใจที่ไม่ใช่สาย technical (ผลกระทบทางธุรกิจ, ระดับความเสี่ยง, คำแนะนำเชิงกลยุทธ์)
• Technical findings พร้อม severity rating ที่ชัดเจน, ขั้นตอนการ reproduce ทีละขั้น และ screenshots/proof of exploitation
• Business context สำหรับทุก finding (ไม่ใช่แค่ "นี่คือ XSS ระดับ high" แต่ "XSS นี้ช่วยให้ผู้โจมตี hijack admin session และเข้าถึงข้อมูลลูกค้าทั้งหมดได้")
• Remediation guidance ที่ developer ทำตามได้จริง (code fix เฉพาะ, configuration change, architecture recommendation)
• Compliance mapping กับ framework ที่เกี่ยวข้อง (ธปท., PDPA, PCI DSS, ISO 27001) เมื่อจำเป็น
• Methodology overview อธิบายว่าทดสอบอะไร, ไม่ได้ทดสอบอะไร และทำไม

รายงานแย่หน้าตาเป็นอย่างไร:

• หลายร้อยหน้าของ output จาก scanner (Nessus, Burp Suite) โดยไม่มีการ verify โดยผู้เชี่ยวชาญ
• คำแนะนำการแก้ไขทั่วไปที่ copy มาจาก CVE databases
• ไม่แยกความแตกต่างระหว่างช่องโหว่ที่ยืนยันแล้วกับปัญหาที่อาจเป็นไปได้
• ไม่มี business impact analysis
• ไม่ระบุ scope (ทดสอบอะไรจริง)

วิธีตรวจสอบ: ขอดูรายงานตัวอย่างแบบ redacted ก่อนเซ็นสัญญา ผู้ให้บริการที่มีชื่อเสียงทุกรายควรยินดีแชร์ ตรวจดูว่ามีองค์ประกอบที่กล่าวมาข้างต้นหรือไม่

4. Remediation Support (การสนับสนุนหลังส่งรายงาน)

การหาช่องโหว่เป็นแค่ครึ่งเดียว สิ่งที่เกิดขึ้นหลังส่งรายงานก็สำคัญไม่แพ้กัน

Remediation support ที่ดีเป็นอย่างไร:

• Developer consultation: ทีมทดสอบพร้อมอธิบาย finding ให้ developer ของคุณ ตอบคำถามทางเทคนิค และแนะนำ approach ในการแก้ไข
• Verification retesting: หลังจากทีมของคุณแก้ไขแล้ว ผู้ให้บริการทดสอบซ้ำเฉพาะ finding ที่แก้ไขเพื่อยืนยันว่าแก้ได้ถูกต้อง
• Remediation prioritization: แนะนำว่าควรแก้ finding ไหนก่อนตาม exploitability และ business impact, ไม่ใช่แค่ CVSS score
• Timeline support: กรอบเวลาการแก้ไขที่สมเหตุสมผลตาม development cycle จริง

สิ่งที่ควรระวัง: ผู้ให้บริการที่ส่งรายงานแล้วหายไป ถ้า "remediation support" แปลว่าแค่ "ตอบอีเมลสักฉบับ" นั่นไม่ใช่ support จริง ถามให้ชัดว่ารวมอะไรบ้าง กี่ชั่วโมง consultation กี่รอบ retesting และภายในระยะเวลาเท่าไหร่

5. ประสบการณ์ด้าน Compliance

ถ้าองค์กรอยู่ในอุตสาหกรรมที่มีกฎระเบียบกำกับ ผู้ให้บริการ pentest ต้องเข้าใจข้อกำหนดเฉพาะของอุตสาหกรรมนั้น ไม่ใช่แค่ทดสอบความปลอดภัยทั่วไป

กรอบกฎระเบียบหลักของไทย:

หน่วยงาน	กรอบกฎระเบียบ	สิ่งที่ต้องการจากผู้ให้บริการ Pentest
ธปท.	IT Risk Management, iPentest	Pentest ประจำปีโดยบุคคลที่สามอิสระ; iPentest สำหรับ D-SIB พร้อม threat intelligence และ Red Team exercise
PDPA	มาตรา 37	"มาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม"; pentest ให้หลักฐานพิสูจน์ compliance
กลต.	ข้อกำหนดธุรกิจสินทรัพย์ดิจิทัล	ประเมินความปลอดภัยก่อนได้ใบอนุญาต รวมถึง smart contract audit
คปภ.	IT Risk Management 8 ด้าน	การทดสอบความปลอดภัยเป็นส่วนหนึ่งของ IT risk management สำหรับบริษัทประกัน
PCI DSS	Requirement 11.4	Pentest ประจำปีสำหรับสภาพแวดล้อมที่จัดการข้อมูลบัตร
ISO 27001	Annex A.8.8	การประเมิน technical vulnerability management

วิธีตรวจสอบ: ถามว่าเคยส่งงานตาม framework ใดบ้าง และขอ reference จากลูกค้าในอุตสาหกรรมเดียวกัน ผู้ให้บริการที่มีประสบการณ์กับ compliance ของ ธปท. จะรู้วิธีจัดรายงานและหลักฐานให้ auditor ยอมรับ ขณะที่ผู้ให้บริการที่ไม่เคยทำ อาจส่งงานที่เทคนิคดีแต่ยังตกข้อกำหนดด้านกฎระเบียบ

6. การสื่อสารและ Project Management

Pentest ไม่ใช่งาน "สั่งแล้วรอรับของ" การสื่อสารที่ดีตลอดกระบวนการ ช่วยให้ได้ผลลัพธ์ที่ดีขึ้นมาก

สิ่งที่ควรคาดหวัง:

• Pre-engagement scoping call: หารือรายละเอียดเกี่ยวกับสภาพแวดล้อม วัตถุประสงค์ ข้อจำกัด และช่วงเวลาทดสอบ
• Kick-off meeting: ยืนยัน scope, credentials, access requirements และขั้นตอน escalation
• Status updates เป็นประจำ: อัปเดตสั้นๆ เกี่ยวกับความคืบหน้า โดยเฉพาะสำหรับ engagement ที่ยาว
• Critical finding alerts: แจ้งเตือนทันทีเมื่อทีมพบช่องโหว่ระดับ critical หรือที่ exploit ได้จริง (ไม่รอจนถึงรายงานฉบับสุดท้าย)
• Debrief presentation: Walkthrough findings สำหรับทั้งสาย technical และฝ่ายบริหาร
• Dedicated point of contact: คนที่คุณติดต่อได้ตลอด engagement สำหรับคำถามหรือข้อกังวล

สัญญาณเตือน (Red Flags) ในการประเมินผู้ให้บริการ

เจอสัญญาณเหล่านี้ ควรตั้งคำถามจริงจัง หรือตัดผู้ให้บริการออกไปเลย

ราคาต่ำกว่าตลาดอย่างมาก

ถ้าเสนอราคาต่ำกว่า ฿100,000 สำหรับ penetration test เต็มรูปแบบ (ไม่ใช่ vulnerability scan) ต้องตั้งคำถามว่าจะได้อะไรจริง Penetration testing แบบมืออาชีพต้องใช้ผู้เชี่ยวชาญนั่งทดสอบระบบหลายวัน ถ้าราคาต่ำขนาดนั้น สิ่งที่ได้น่าจะเป็น automated scanning ที่มี manual effort น้อยมาก

สำหรับอ้างอิง ราคาเริ่มต้นจริงของ manual penetration testing ในไทยอยู่ที่ ฿150,000 ถึง ฿300,000 สำหรับ web application ขนาดเล็ก และสูงขึ้นสำหรับ scope ที่ซับซ้อนกว่า ดูรายละเอียดในบทความ คู่มือราคา Penetration Testing ในไทย

ไม่ระบุ Methodology

ถ้า proposal ไม่ระบุ testing methodology (OWASP WSTG, PTES, OSSTMM หรือเทียบเท่า) แปลว่าอาจไม่ได้ทดสอบอย่างเป็นระบบ พอไม่มี methodology ก็ไม่มีทางรู้ว่าทดสอบอะไรไปแล้ว และที่สำคัญกว่านั้น ไม่รู้ว่าอะไรที่ยังไม่ได้ทดสอบ

อ้าง "Scope ไม่จำกัด" หรือ "ทดสอบทุกอย่าง"

Penetration testing แบบมืออาชีพต้องกำหนด scope ให้ชัดเจน การอ้างว่า "scope ไม่จำกัด" หรือ "ทดสอบทุกอย่าง" บอกอะไรได้สองอย่าง คือไม่เข้าใจการ scope หรือไม่ตั้งใจจะเจาะลึกเรื่องไหนจริงจัง การทดสอบที่ดีต้องลึกและมีจุดเน้น ไม่ใช่ตื้นแต่กว้าง

ไม่มีรายงานตัวอย่างให้ดู

ถ้าไม่ยอมแชร์รายงานตัวอย่างแบบ redacted ก็ไม่มีทางประเมินคุณภาพ deliverable ล่วงหน้าได้ เรื่องนี้เป็นคำขอปกติในอุตสาหกรรม ผู้ให้บริการที่มีชื่อเสียงจะมีตัวอย่างพร้อมให้ดูอยู่แล้ว

ใช้แค่เครื่องมืออัตโนมัติแต่เรียกว่า "Pentest"

ผู้ให้บริการบางรายรัน vulnerability scanner (Nessus, Qualys, OpenVAS) แล้วเอา output มาส่งเป็น penetration test ทั้งที่จริงแล้วนี่คือ vulnerability assessment ไม่ใช่ penetration test สิ่งที่ทำให้ต่างกันคือฝีมือคน pentest จริงต้องมีผู้เชี่ยวชาญลงมือ exploit ระบบ ทดสอบ business logic และ chain ช่องโหว่เข้าด้วยกัน

วิธีแยกแยะ: ถามว่าเวลาทดสอบเป็น manual กี่เปอร์เซ็นต์ vs. automated ขอตัวอย่างช่องโหว่ business logic ที่เคยพบในงานที่ผ่านมา ถ้าตอบไม่ได้ เป็นไปได้สูงว่าพึ่งพา scanner

กำหนดเวลาคงที่ไม่ว่า Scope จะเป็นอะไร

"5 วันสำหรับ web app ทุกแบบ" เป็นสัญญาณเตือน เว็บไซต์ 10 หน้ากับแพลตฟอร์ม SaaS ที่มี 200 endpoints ต้องใช้เวลาต่างกันโดยสิ้นเชิง ถ้าเวลาทดสอบไม่เปลี่ยนตาม scope แสดงว่าไม่ได้ scope งานจริง

สัญญาณที่ดี (Green Flags): เครื่องบ่งชี้ผู้ให้บริการคุณภาพ

เผยแพร่งานวิจัยและมีส่วนร่วมกับชุมชน

ถ้าสมาชิกในทีมเผยแพร่งานวิจัยด้านความปลอดภัย ค้นพบ CVEs (Common Vulnerabilities and Exposures) แข่ง CTF (Capture The Flag) หรือ contribute ให้ open-source security tools สิ่งเหล่านี้บ่งบอกความเชี่ยวชาญ offensive ได้ดีกว่า marketing เพราะปลอมได้ยากกว่า

ระบุชื่อผู้ทดสอบพร้อมใบรับรองที่ตรวจสอบได้

ผู้ให้บริการที่ดีจะบอกได้ว่าใครจะทดสอบระบบของคุณ และใบรับรองของคนเหล่านั้นตรวจสอบได้จริง เช่น เช็คผู้ถือ OSCP ผ่าน directory ของ Offensive Security หรือสมาชิก CREST ผ่านเว็บไซต์ CREST

กระบวนการ Scoping ที่ชัดเจน

ผู้ให้บริการที่มีคุณภาพจะถามคำถามละเอียดก่อนเสนอราคา:

• มีกี่ endpoint, หน้า หรือ API route?
• มีกี่ user role และระดับ permission?
• สามารถเข้าถึง source code ได้หรือไม่ (black-box, gray-box, white-box)?
• ทดสอบในสภาพแวดล้อมไหน (staging, production หรือทั้งสอง)?
• มีข้อกำหนด compliance อะไรบ้าง?
• มีข้อจำกัดในการทดสอบหรือไม่ (ช่วงเวลา, ระบบที่ห้ามทดสอบ)?
• แอปเคยถูกทดสอบมาก่อนหรือไม่? มีรายงานเดิมให้ดูไหม?

ถ้าเสนอราคามาโดยไม่ถามคำถามเหล่านี้ก่อน แปลว่าเดา แล้วคุณก็จะจ่ายแพงเกินจริง หรือไม่ก็ได้การทดสอบที่ไม่เพียงพอ

Remediation Support หลัง Engagement

ผู้ให้บริการที่ดีจะรวม developer consultation และ verification retesting อย่างน้อย 1 รอบไว้ใน proposal หรือเสนอเป็น add-on ที่ระบุราคาชัด ไม่ใช่ส่งรายงานแล้วหายไป

โปร่งใสเรื่องข้อจำกัด

ไม่มี pentest ไหนเจอทุกอย่างได้ ผู้ให้บริการที่ดีจะระบุชัดว่าทดสอบอะไร ไม่ได้ทดสอบอะไร (และทำไม) รวมถึงข้อจำกัดของ engagement ความตรงไปตรงมาแบบนี้มีค่ากว่าการรับประกันแบบลมๆ แล้งๆ

คำถามที่ควรถามระหว่างประเมิน

ใช้ checklist นี้ตอน vendor evaluation call หรือระหว่างกระบวนการ RFP

เกี่ยวกับทีม

1. ใครจะถูกมอบหมายให้ทดสอบระบบของเราโดยเฉพาะ? มีใบรับรองอะไรและมีประสบการณ์กี่ปี?
2. ผู้ทดสอบคนเดียวกันจะพร้อมตอบคำถามระหว่าง remediation phase หรือไม่?
3. ทีมมีประสบการณ์กับ technology stack ของเราหรือไม่ (เช่น .NET, Java, React Native, AWS)?
4. แชร์ตัวอย่างงานวิจัย, CVEs หรือผลงาน CTF ของสมาชิกในทีมได้ไหม?

เกี่ยวกับ Methodology

5. ใช้ testing methodology อะไร? walkthrough ขั้นตอนสำหรับ engagement type ของเราได้ไหม?
6. เวลาทดสอบเป็น manual กี่เปอร์เซ็นต์ vs. automated?
7. ทดสอบ business logic อย่างไร? ยกตัวอย่างช่องโหว่ business logic ที่เคยพบในงานที่ผ่านมาได้ไหม?
8. ทดสอบ authentication และ authorization flaws นอกเหนือจาก OWASP Top 10 อย่างไร?

เกี่ยวกับ Deliverables

9. ขอดูรายงานตัวอย่างแบบ redacted ได้ไหม?
10. จัดลำดับ finding severity อย่างไร? ใช้ CVSS อย่างเดียวหรือรวม business context ด้วย?
11. รายงานมีขั้นตอนการ reproduce ทีละขั้นสำหรับทุก finding หรือไม่?

เกี่ยวกับกระบวนการ

12. ต้องการข้อมูลอะไรจากเราเพื่อให้ใบเสนอราคาที่แม่นยำ?
13. การทดสอบจะใช้เวลานานเท่าไหร่ และประเมินระยะเวลานั้นมาอย่างไร?
14. ถ้าพบ critical finding ระหว่างทดสอบ จัดการอย่างไร? แจ้งเราทันทีหรือไม่?
15. Remediation support รวมอะไรบ้าง? กี่ชั่วโมง consultation และกี่รอบ retesting?

เกี่ยวกับเงื่อนไขเชิงพาณิชย์

16. อะไรรวมอยู่ในราคาที่เสนอ vs. อะไรมีค่าใช้จ่ายเพิ่ม (retesting, consultation เพิ่มเติม, compliance mapping)?
17. มีแนวปฏิบัติด้าน data handling และ confidentiality สำหรับข้อมูลลูกค้าที่เข้าถึงระหว่างทดสอบอย่างไร?
18. ให้ reference จากลูกค้าในอุตสาหกรรมของเราได้ไหม?

ตารางประเมิน Proposal

ใช้ตาราง scoring นี้เปรียบเทียบผู้ให้บริการอย่างเป็นระบบ ให้คะแนนแต่ละเกณฑ์ 1 (แย่) ถึง 5 (ยอดเยี่ยม)

เกณฑ์ประเมิน	น้ำหนัก	บริษัท A	บริษัท B	บริษัท C
คุณสมบัติทีม (cert ที่เกี่ยวข้อง, ระบุชื่อผู้ทดสอบ)	20%	___ / 5	___ / 5	___ / 5
Methodology (มีโครงสร้าง, เหมาะกับ scope)	15%	___ / 5	___ / 5	___ / 5
คุณภาพรายงาน (จากการ review ตัวอย่าง)	15%	___ / 5	___ / 5	___ / 5
Remediation support (consultation, retesting)	15%	___ / 5	___ / 5	___ / 5
ประสบการณ์ compliance (framework ที่เกี่ยวข้อง)	10%	___ / 5	___ / 5	___ / 5
การสื่อสารและกระบวนการ (scoping, updates, debrief)	10%	___ / 5	___ / 5	___ / 5
ราคา (คุ้มค่าตาม scope, ไม่ใช่ถูกที่สุด)	10%	___ / 5	___ / 5	___ / 5
References และชื่อเสียง (ref ลูกค้า, งานวิจัย)	5%	___ / 5	___ / 5	___ / 5
คะแนนรวมถ่วงน้ำหนัก	100%	___	___	___

วิธีใช้ตารางนี้:

1. ปรับน้ำหนักตามลำดับความสำคัญของคุณ ถ้า compliance เป็นตัวขับเคลื่อนหลัก เพิ่มน้ำหนักของมัน ถ้าทดสอบ custom application ที่ซับซ้อน เพิ่มน้ำหนัก methodology และคุณสมบัติทีม
2. ให้คะแนนแต่ละผู้ให้บริการหลังจาก review proposal, รายงานตัวอย่าง และ evaluation call
3. คำนวณคะแนนรวมถ่วงน้ำหนักเพื่อเปรียบเทียบอย่างเป็นระบบ
4. ใช้คะแนนเป็น input ในการตัดสินใจ ไม่ใช่ปัจจัยเดียว ผู้ให้บริการที่ได้ 4.2 vs. 4.0 แทบไม่ต่างกัน; ใช้วิจารณญาณของคุณเรื่อง cultural fit และ responsiveness

เมื่อไหร่ควรเลือกผู้ให้บริการในไทย vs. บริษัทต่างชาติ

คำถามนี้เจอบ่อยมาก โดยเฉพาะในบริษัทข้ามชาติที่มีงบ security ระดับภูมิภาคหรือระดับโลก

ข้อดีของผู้ให้บริการไทย

• ความเชี่ยวชาญด้านกฎระเบียบ: เข้าใจข้อกำหนดของ ธปท., PDPA, กลต., คปภ. อย่างลึกซึ้ง และรู้ว่า auditor ไทยประเมินหลักฐาน compliance อย่างไร
• ภาษาและการสื่อสาร: สามารถ debrief, ให้คำปรึกษา developer และนำเสนอผู้บริหารเป็นภาษาไทยได้
• พร้อมทำงาน on-site: อยู่ในพื้นที่สำหรับ internal network testing, สภาพแวดล้อม air-gapped และการประชุม scoping แบบตัวต่อตัว
• เข้าใจบริบทตลาด: เข้าใจ threat landscape ของไทย, technology stack ที่นิยมในองค์กรไทย และแนวปฏิบัติทางธุรกิจในท้องถิ่น
• คุ้มค่า: ถูกกว่าผู้ให้บริการต่างชาติ 30-50% สำหรับคุณภาพที่เทียบเท่า เนื่องจากค่าใช้จ่ายในการดำเนินงานในท้องถิ่น
• Timezone ตรงกัน: สื่อสาร real-time ในเวลาทำงานของไทย; ตอบสนองทันทีสำหรับ critical findings

ข้อดีของผู้ให้บริการต่างชาติ

• Global benchmarking: ประสบการณ์ข้ามตลาดให้มุมมองที่กว้างกว่าเรื่อง attack trends
• การยอมรับแบรนด์: สำหรับองค์กรที่ต้องการชื่อที่เป็นที่รู้จักในระดับสากลบนรายงาน audit (แม้ว่าจะสำคัญน้อยลงเรื่อยๆ เมื่อผู้ให้บริการไทยสร้างชื่อเสียงได้แข็งแกร่งขึ้น)

คำแนะนำเชิงปฏิบัติ

สำหรับองค์กรส่วนใหญ่ที่ทำธุรกิจในไทย ผู้ให้บริการท้องถิ่นที่มี technical credential แข็งแกร่งมักเป็นตัวเลือกที่ดีกว่า ความรู้ด้านกฎระเบียบ การอยู่ในพื้นที่ และการสื่อสารที่ตรงกัน มีน้ำหนักมากกว่าชื่อเสียงของแบรนด์ต่างชาติ โดยเฉพาะสำหรับ:

• Engagement ที่ต้องการ compliance reporting เฉพาะ (ธปท., PDPA, PCI DSS)
• แอป mobile banking และ fintech ที่อยู่ภายใต้กฎระเบียบไทย
• Engagement ที่ต้องทดสอบ on-site
• องค์กรที่ทีม developer สื่อสารเป็นภาษาไทยเป็นหลัก

ผู้ให้บริการต่างชาติอาจเหมาะกว่าเมื่อ:

• ต้องการความเชี่ยวชาญเฉพาะทางที่ยังไม่มีในตลาดไทย
• นโยบายองค์กรกำหนดให้ใช้ vendor ระดับ global เฉพาะ
• Engagement เป็นส่วนหนึ่งของโปรแกรมข้ามประเทศที่ต้องการ methodology สม่ำเสมอทุกภูมิภาค

สรุปประเด็นสำคัญ

1. ประเมินผู้ทดสอบ ไม่ใช่แค่ชื่อบริษัท ถามว่าใครจะทดสอบจริง มีใบรับรองอะไร และมีประสบการณ์ที่เกี่ยวข้องกับเทคโนโลยีและอุตสาหกรรมของคุณหรือไม่

2. ขอดูรายงานตัวอย่างก่อนเซ็นสัญญา รายงานคือ deliverable จริง ถ้าดูคุณภาพล่วงหน้าไม่ได้ ก็เหมือนซื้อของโดยไม่ได้ดูของ

3. Methodology สำคัญ แนวทางที่มีโครงสร้าง (OWASP WSTG, PTES, OSSTMM) รับประกันความครอบคลุม ถ้าไม่มี คุณไม่มีทางรู้ว่าอะไรถูกทดสอบหรือไม่ถูกทดสอบ

4. ของถูกมักแพงทีหลัง Pentest ราคาต่ำกว่าตลาดที่พลาดช่องโหว่สำคัญ สร้าง false confidence และเปิดช่องให้องค์กรโดนโจมตี ลงทุนให้เหมาะกับระดับความเสี่ยง

5. Remediation support ขาดไม่ได้ รายงานที่ไม่มี follow-up consultation และ retesting ถือว่าได้แค่ครึ่งเดียวของบริการ ต้องมั่นใจว่า post-engagement support รวมอยู่ในข้อตกลง

6. ประสบการณ์ compliance ช่วยประหยัดเวลาและ rework ถ้าคุณอยู่ในอุตสาหกรรมที่มีกฎระเบียบ (ธนาคาร, ประกัน, สินทรัพย์ดิจิทัล, องค์กรที่จัดการข้อมูลส่วนบุคคล) เลือกผู้ให้บริการที่เคยส่งงานตามข้อกำหนดเฉพาะของคุณ

7. ใช้ตารางประเมิน การเปรียบเทียบอย่างเป็นระบบช่วยไม่ให้ตัดสินใจจากราคาหรือ sales presentation อย่างเดียว ให้คะแนนผู้ให้บริการตามเกณฑ์เดียวกัน

8. ผู้ให้บริการในไทยมักคุ้มค่าที่สุดสำหรับงานในไทย ความรู้ด้านกฎระเบียบ ภาษาที่ตรงกัน พร้อมลงพื้นที่ on-site และราคาที่สมเหตุสมผล ทำให้ผู้ให้บริการท้องถิ่นเหมาะกับ engagement ส่วนใหญ่ในไทย

---

กำลังเลือกผู้ให้บริการ Penetration Testing อยู่? ติดต่อ Reconix ได้เลย เรายินดีตอบทุกคำถามในคู่มือนี้ ไม่ว่าจะเรื่องทีม methodology หรือ approach ของเรา เพราะเราเชื่อว่าผู้ซื้อที่มีข้อมูลครบ จะเป็นลูกค้าที่ดีที่สุด

แหล่งข้อมูลที่เกี่ยวข้อง

• ค่าทดสอบเจาะระบบในไทยเท่าไหร่? (รายละเอียดราคาแยกตามประเภทบริการ)
• VA กับ Pentest ต่างกันอย่างไร? (ทำความเข้าใจสิ่งที่ต้องการก่อนเลือกผู้ให้บริการ)
• คู่มือข้อกำหนด iPentest ของ ธปท. (สำหรับสถาบันการเงินภายใต้กฎระเบียบ ธปท.)
• คู่มือ PDPA มาตรา 37 มาตรการรักษาความมั่นคงปลอดภัย (มาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสมหมายถึงอะไร)
• บริการของเรา (รายการบริการ Penetration Testing และ Security Assessment ทั้งหมด)

แหล่งอ้างอิงมาตรฐานอุตสาหกรรม

• OWASP Web Security Testing Guide (WSTG)
• OWASP Mobile Application Security Testing Guide (MASTG)
• Penetration Testing Execution Standard (PTES)
• OSSTMM (Open Source Security Testing Methodology Manual)
• CREST Accreditation
• Offensive Security Certification Program
• IBM Cost of a Data Breach Report 2024
• แนวปฏิบัติ ธปท. ด้านการบริหารความเสี่ยงเทคโนโลยีสารสนเทศ (FPG 21/2562)
• พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA)

---

บริการที่เกี่ยวข้องจาก Reconix

• Penetration Testing — บริการทดสอบเจาะระบบแบบครบวงจร ครอบคลุม Web, Mobile, Network และ Cloud
• Web Application Penetration Testing — ทดสอบเว็บแอปพลิเคชันและ API ตามมาตรฐาน OWASP WSTG
• Mobile Application Penetration Testing — ประเมินความปลอดภัยแอปมือถือ iOS และ Android ตาม OWASP MASTG
• Cybersecurity Consulting — บริการที่ปรึกษาด้านความปลอดภัยไซเบอร์ ช่วยวางแผนโปรแกรมทดสอบให้เหมาะกับองค์กร