แนวทางการทดสอบเจาะระบบ (Security Assessment Approach)

การทดสอบเจาะระบบไม่ได้มีรูปแบบเดียว — แนวทางที่เลือกส่งผลโดยตรงต่อความครอบคลุมและประเภทช่องโหว่ที่จะพบ การเลือกรูปแบบที่เหมาะสมขึ้นอยู่กับ scope, วัตถุประสงค์การทดสอบ, ระดับการเข้าถึงที่ให้ และ ระดับความมั่นใจที่ต้องการ

3 แนวทางการทดสอบ

⬛ Black-box — มุมมองจากภายนอก (Outside-in View)

Dynamic Analysis — จำลองมุมมองของผู้โจมตีที่ไม่มีข้อมูลภายในใด ๆ

สิ่งที่ผู้ทดสอบได้รับ:

• ❌ ไม่มีข้อมูลภายในของระบบ
• ❌ ไม่มี credential / username / password
• ✅ ยืนยันเป้าหมาย (target) เท่านั้น

เหมาะสำหรับ:

• ต้องการรู้ว่าระบบมีอะไรเปิดเผยต่อภายนอกบ้าง
• จำลองสถานการณ์ถูกโจมตีจากอินเทอร์เน็ต
• ตรวจสอบว่าหน้า login และ public-facing ปลอดภัยหรือไม่

ข้อจำกัด: ไม่สามารถตรวจฟังก์ชันที่อยู่หลัง login ได้ ทำให้อาจพลาดช่องโหว่ด้าน authorization และ business logic ภายใน

---

🔲 Grey-box — มุมมองตาม Role (Role-based View)

Dynamic Analysis — รูปแบบที่ นิยมมากที่สุด เพราะให้ความครอบคลุมสูงและพบช่องโหว่ได้ลึกกว่า Black-box มาก

สิ่งที่ผู้ทดสอบได้รับ:

• ✅ ยืนยันเป้าหมาย (target)
• ✅ Credential ของแต่ละ role (admin, user ปกติ, ผู้ดูแลระบบ ฯลฯ)
• ✅ รายละเอียดฟังก์ชันและเมนูหลัก

เหมาะสำหรับ:

• ต้องการตรวจสอบเชิงลึกทุกฟังก์ชัน ทุก role
• ตรวจ authorization — user ระดับหนึ่งเข้าถึงข้อมูลของอีก role ได้หรือไม่
• ตรวจ business logic ที่ซับซ้อน เช่น กระบวนการอนุมัติ, การโอนเงิน, การเปลี่ยนสิทธิ์

ทำไมแนะนำ Grey-box: ช่องโหว่ที่รุนแรงที่สุดมักอยู่หลัง login — เช่น Broken Access Control ซึ่งเป็นอันดับ 1 ของ OWASP Top 10 2025 ถ้าไม่มี credential ก็ตรวจไม่ถึง

---

⬜ White-box — มุมมองระดับ Source Code (Source-level View)

Static Analysis — ตรวจสอบลึกที่สุดโดยวิเคราะห์ source code โดยตรง

สิ่งที่ผู้ทดสอบได้รับ:

• ✅ Source code ของระบบ
• ✅ Functional specification / เอกสารออกแบบ
• ✅ Architecture diagram (ถ้ามี)

เหมาะสำหรับ:

• ระบบที่พัฒนาเอง (in-house) ต้องการตรวจคุณภาพ code ด้านความปลอดภัย
• ต้องการพบช่องโหว่ที่มองจากภายนอกไม่เห็น เช่น hardcoded credentials, insecure cryptography, race conditions ในระดับ code
• ต้องการผลที่ครอบคลุมที่สุดสำหรับระบบที่มีความสำคัญสูง

ข้อดี: พบช่องโหว่ได้มากที่สุดและลึกที่สุด เหมาะกับระบบที่ถือข้อมูลสำคัญหรืออยู่ภายใต้ regulator ที่เข้มงวด

---

เปรียบเทียบ 3 แนวทาง

	Black-box	Grey-box	White-box
ข้อมูลที่ได้รับ	เป้าหมายเท่านั้น	Credential ทุก role + ฟังก์ชัน	Source code + specification
ประเภทการวิเคราะห์	Dynamic	Dynamic	Static + Dynamic
ความครอบคลุม	ภายนอก	ภายนอก + ภายใน	ลึกสุดถึงระดับ code
พบ business logic	จำกัด	✅ สูง	✅ สูงมาก
พบ authorization	จำกัด	✅ สูง	✅ สูงมาก
ระยะเวลา	น้อยที่สุด	ปานกลาง	มากที่สุด
เหมาะกับ	External scan	ระบบทุกประเภท	ระบบ in-house สำคัญ

คำแนะนำ: สำหรับองค์กรส่วนใหญ่ Grey-box เป็นรูปแบบที่คุ้มค่าที่สุด — ครอบคลุมทั้งมุมมองภายนอกและภายใน พบช่องโหว่ด้าน authorization และ business logic ที่ Black-box ตรวจไม่ถึง

วิธีการทดสอบ

• เลือกรูปแบบตาม scope, วัตถุประสงค์ และระดับความมั่นใจที่ต้องการ
• ทดสอบทั้ง Dynamic Analysis (ระบบที่ทำงานจริง) และ Static Analysis (source code)
• ปรับเปลี่ยนได้ระหว่างโครงการตามความจำเป็น

สิ่งที่คุณจะได้รับ

• รายงานฉบับสมบูรณ์พร้อม executive summary
• รายการช่องโหว่ + ระดับความรุนแรง + ขั้นตอนทำซ้ำ (PoC)
• คำแนะนำแก้ไขเฉพาะจุดภาษาไทย
• รายงาน retest หลังแก้ไข
• หนังสือรับรองผลการทดสอบ (attestation letter)

ระยะเวลา

ขึ้นกับรูปแบบที่เลือกและขนาดระบบ

ราคาโดยประมาณ

Grey-box เป็นรูปแบบที่นิยมและคุ้มค่าที่สุด — คำนวณงบเอง

คำถามที่พบบ่อย

ควรเลือก Black-box, Grey-box หรือ White-box

ขึ้นกับวัตถุประสงค์ ถ้าต้องการจำลองมุมมองแฮกเกอร์ภายนอก → Black-box ถ้าต้องการตรวจสอบเชิงลึกทุก role → Grey-box (แนะนำมากที่สุด) ถ้าต้องการตรวจลึกถึงระดับ source code → White-box

สามารถผสมหลายรูปแบบในโครงการเดียวได้ไหม

ได้ เราสามารถเริ่มจาก Black-box เพื่อดูมุมมองภายนอก แล้วต่อด้วย Grey-box เพื่อตรวจเชิงลึกภายใน ขึ้นกับ scope ที่ตกลงกัน

Grey-box ต้องเตรียมอะไรบ้าง

เตรียม credential ของทุก role (เช่น admin, user ปกติ, ผู้ดูแลระบบ) พร้อมรายละเอียดฟังก์ชันหลักของระบบ — เราจะส่ง checklist ให้ก่อนเริ่มงาน