วิธีการทดสอบ
วิธีการทดสอบ
เราทำงานตามลำดับขั้นที่กำหนดไว้และบันทึกทุกขั้นตอน ผลการทดสอบจึงตรวจสอบย้อนหลังและทำซ้ำได้ ทั้งโดยทีมเราเองและผู้ตรวจสอบภายนอก
ขั้นตอนการทำงาน
-
กำหนดขอบเขตและขออนุญาต
ระบุระบบเป้าหมาย สภาพแวดล้อม ช่วงเวลา และผู้ประสานงาน แล้วขอหนังสืออนุญาตเป็นลายลักษณ์อักษรก่อนเริ่มทุกครั้ง
-
Rules of Engagement
ตกลงกันว่าอะไรทำได้ อะไรทำไม่ได้ เช่น การทดสอบที่อาจกระทบความพร้อมใช้งาน ช่องทางแจ้งเหตุฉุกเฉิน และเงื่อนไขที่ต้องหยุดทดสอบทันที
-
ทำ Threat Model
ทำความเข้าใจสถาปัตยกรรม ขอบเขตความเชื่อถือ และทรัพย์สินที่มีค่า เพื่อใช้เวลาทดสอบกับจุดที่ให้ผลคุ้มค่าที่สุด
-
ทดสอบด้วยมือร่วมกับเครื่องมือ
ใช้เครื่องมือกวาดหา attack surface ในวงกว้าง แล้วเจาะลึกด้วยมือในจุดที่ต้องเข้าใจบริบทของระบบจึงจะเจอช่องโหว่
-
ยืนยันว่าโจมตีได้จริง
พิสูจน์ในระบบที่ได้รับอนุญาตว่าช่องโหว่ใช้โจมตีได้จริง เพื่อแยกความเสี่ยงจริงออกจากความเสี่ยงบนกระดาษ
-
วิเคราะห์ผลกระทบ
ประเมินผลกระทบต่อธุรกิจตามสภาพการใช้งานจริงของคุณ ไม่ใช่ดูจากคะแนนพื้นฐานอย่างเดียว
-
รายงานพร้อมหลักฐาน
ทุกข้อค้นพบมีขั้นตอนทำซ้ำ หลักฐาน ระดับความรุนแรงตาม CVSS และคำแนะนำการแก้ที่เจาะจง
-
ให้คำปรึกษาการแก้ไข
ประชุมรีวิวผลกับทีมของคุณ อธิบายต้นเหตุ และช่วยจัดลำดับว่าควรแก้อะไรก่อน
-
ทดสอบซ้ำ
ทดสอบรายการที่แก้แล้วอีกรอบ เพื่อยืนยันว่าแก้ได้ผลและไม่สร้างปัญหาใหม่
-
รายงานปิดงาน
สรุปสถานะสุดท้ายของทุกข้อค้นพบ ในรูปแบบที่แนบประกอบการตรวจสอบภายในหรือการกำกับดูแลได้
เราทดสอบเฉพาะระบบที่ได้รับอนุญาตเป็นลายลักษณ์อักษร และอยู่ในขอบเขตที่ตกลงกันไว้เท่านั้น
มาตรฐานและกรอบอ้างอิง
เราใช้มาตรฐานเปิดต่อไปนี้เป็นกรอบกำหนดความครอบคลุมและเป็นภาษากลางในการรายงานผล การอ้างอิงมาตรฐานเหล่านี้ไม่ได้แปลว่าเราได้รับการรับรองหรือเป็นพาร์ตเนอร์กับองค์กรผู้จัดทำ
| มาตรฐาน | เวอร์ชันที่อ้างอิง |
|---|---|
| OWASP Web Security Testing Guide | 4.2 |
| OWASP Application Security Verification Standard | 5.0.0 |
| OWASP Top 10 | 2025 |
| OWASP API Security Top 10 | 2023 |
| OWASP MASVS | 2.1.0 |
| OWASP MASTG | 2.0.0 |
| CVSS | 4.0 |
ตรวจสอบเลขเวอร์ชันกับแหล่งข้อมูลทางการล่าสุดเมื่อ .
การสื่อสารระดับความรุนแรง
เราให้คะแนนด้วย CVSS v4.0 และแสดงเสมอว่าคะแนนมาจากปัจจัยใด พร้อมอธิบายผลกระทบตามสภาพระบบของคุณเป็นภาษาที่เข้าใจง่าย
| ระดับ | ความหมายในรายงาน | ควรทำอย่างไร |
|---|---|---|
| วิกฤต | โจมตีได้จริงและนำไปสู่การยึดระบบหรือเข้าถึงข้อมูลสำคัญในวงกว้าง | แจ้งทันทีระหว่างทดสอบ และควรแก้เป็นอันดับแรก |
| สูง | โจมตีได้และกระทบความลับ ความถูกต้อง หรือความพร้อมใช้งานอย่างมีนัยสำคัญ | วางแผนแก้ในรอบปล่อยงานถัดไป |
| ปานกลาง | โจมตีได้ภายใต้เงื่อนไขบางอย่าง หรือผลกระทบจำกัด | ใส่ไว้ในแผนงานแก้ไขตามปกติ |
| ต่ำ | ผลกระทบจำกัด หรือต้องอาศัยเงื่อนไขที่เกิดขึ้นยาก | แก้เมื่อมีโอกาสเหมาะสม |
| ข้อสังเกต | ไม่ใช่ช่องโหว่โดยตรง แต่ปรับแล้วช่วยลดความเสี่ยงโดยรวม | นำไปปรับมาตรฐานภายในและงาน hardening |
ข้อจำกัดที่เราระบุไว้เสมอ
- การทดสอบเจาะระบบคือการประเมิน ณ ช่วงเวลาหนึ่ง ภายใต้ขอบเขตหนึ่ง ไม่ใช่การรับประกันว่าระบบไม่มีช่องโหว่
- รายงานระบุเสมอว่าส่วนไหนอยู่นอกขอบเขต และส่วนไหนทดสอบได้ไม่เต็มที่เพราะเวลา สิทธิ์เข้าถึง หรือความเสี่ยงต่อระบบที่ให้บริการอยู่
- เราไม่แตะระบบที่ไม่มีหนังสืออนุญาตเป็นลายลักษณ์อักษร แม้จะเชื่อมต่อกับระบบเป้าหมายก็ตาม
- ข้อมูลและหลักฐานทั้งหมดเก็บและส่งมอบผ่านช่องทางที่เข้ารหัส และลบตามกำหนดเวลาที่ระบุในสัญญา
ติดต่อเรา
เริ่มจากคุยกันก่อน
เล่าคร่าว ๆ ว่าระบบเป็นแบบไหน อยากให้ทดสอบอะไร แล้วเราจะเสนอขอบเขต ระยะเวลา และวิธีทดสอบที่เหมาะกลับไปให้
เราทดสอบเฉพาะระบบที่ได้รับอนุญาตเป็นลายลักษณ์อักษร และอยู่ในขอบเขตที่ตกลงกันไว้เท่านั้น