Pentest Plan

/pentest-plan — แผนทดสอบเจาะระบบ (Authorized Penetration Testing)

วางแผนและกำกับการทดสอบเจาะระบบ "แบบมืออาชีพ" ตั้งแต่ขอบเขต (scope) + Rules of Engagement ไปจนถึง methodology, การจัดลำดับความรุนแรง (CVSS), การออกรายงาน finding และการ retest — เน้นกระบวนการ ไม่ใช่การสอนโจมตีจริง

กฎเหล็ก (ห้ามข้าม): ทดสอบเจาะระบบได้ "เฉพาะระบบที่คุณมีสิทธิ์ทดสอบ และได้รับอนุญาตเป็นลายลักษณ์อักษร (written authorization) จากเจ้าของทรัพย์สินที่มีอำนาจลงนาม" เท่านั้น การยิงเป้าหมายที่ไม่ได้รับอนุญาต = ผิดกฎหมาย (เช่น พ.ร.บ. คอมพิวเตอร์ฯ / CFAA) ไม่ว่าจะเจตนาดีแค่ไหน ถ้าไม่มีหนังสืออนุญาต+ขอบเขตชัดเจน ห้ามเริ่ม สกิลนี้ช่วย "วางแผน/จัดกระบวนการ/เขียนรายงาน" เท่านั้น ไม่ให้ payload, exploit หรือคำสั่งโจมตีจริง

ใช้ตอนไหน

• ต้องจัด pen test / VAPT ให้ระบบ (web, API, mobile, internal network, cloud) ก่อน go-live หรือเป็นรอบประจำปี/ตามสัญญาลูกค้า
• ลูกค้า/compliance (PCI-DSS, ISO 27001 A.8.29, SOC 2) ขอ "penetration test report" ไม่ใช่แค่ scan
• ต้องร่าง Rules of Engagement (RoE) / scope statement / authorization letter ก่อนจ้าง third-party หรือก่อน internal red team ลงมือ
• ได้รายงานจากผู้ทดสอบมาแล้ว ต้องจัดลำดับความรุนแรง (CVSS) + ทำแผน remediation + กำหนด retest
• ต้องตัดสินใจว่าจ้าง third-party หรือใช้ internal team, จะทำ black/grey/white box, internal หรือ external

pen test ≠ automated security testing (/security-testing): /security-testing = เครื่องมืออัตโนมัติ (SAST/DAST/SCA/dependency scan) รันใน CI ทุก build, กว้างแต่ตื้น, หา known issue. Pentest = มนุษย์ผู้เชี่ยวชาญ จำลองผู้โจมตีจริง, ทำเป็นรอบ (point-in-time), เจาะลึก business logic + chained exploit + privilege escalation ที่เครื่องจับไม่ได้ ทั้งสองอย่างเสริมกัน ไม่แทนกัน — ทำ automated ให้สะอาดก่อน แล้วค่อยจ่ายเงินให้คนเก่งมาหาของที่เครื่องหาไม่เจอ

Input ที่ต้องถามก่อนเริ่ม

1. Authorization — มีหนังสืออนุญาตเป็นลายลักษณ์อักษรจากผู้มีอำนาจหรือยัง? ใครเป็นเจ้าของระบบ/ข้อมูล? ระบบโฮสต์บน infra ของใคร (ถ้าเป็น cloud เช่น AWS/Azure/GCP ต้องเช็ค policy ของผู้ให้บริการด้วย)
2. เป้าหมาย & ขอบเขต — รายการ targets (domains, IP ranges, URLs, API endpoints, app bundle id): อะไรอยู่ใน scope และที่สำคัญกว่า — อะไร out of scope (เด็ดขาด)
3. ประเภทการทดสอบ — black / grey / white box? internal (จากในเครือข่าย) หรือ external (จาก internet)? มี credential ให้หรือไม่?
4. สภาพแวดล้อม — ทดสอบบน prod, staging หรือ clone? ถ้าจำเป็นต้องทำบน prod มีข้อจำกัดอะไร (ห้ามแตะข้อมูลจริง, ห้ามทำ data-modifying action)?
5. วัตถุประสงค์ & motivation — compliance (PCI/ISO/SOC2), ก่อน launch, หลังเปลี่ยนสถาปัตยกรรมใหญ่, หรือ assurance ทั่วไป? มี crown-jewel asset อะไรที่ห่วงเป็นพิเศษ
6. เวลา & หน้าต่างทดสอบ (time window) — ช่วงวันที่ทดสอบได้, ช่วงเวลาในวัน (เช่น นอกเวลาทำการเพื่อลดผลกระทบ), deadline ส่งรายงาน
7. ข้อจำกัด/ข้อห้าม — ห้าม DoS/DDoS, ห้าม social engineering/phishing (เว้นได้รับอนุญาตชัดเจน), ห้าม exfiltrate ข้อมูลจริง, ห้ามแตะระบบ third-party ที่ฝังในหน้าเดียวกัน
8. ทีม & ผู้ติดต่อฉุกเฉิน (emergency contact) — ใครทดสอบ (internal/third-party + ใบรับรอง เช่น OSCP/GPEN/CREST)? ใครเป็น point of contact ฝั่งลูกค้าตลอด 24 ชม. ถ้าเกิดเหตุระบบล่ม
9. เกณฑ์ความรุนแรง — ใช้ CVSS v3.1/v4.0 หรือไม่, มี business-context override (เช่น ระบบจ่ายเงิน = ยกระดับ severity) หรือไม่

ขั้นตอน (Playbook)

เฟส 0 — Pre-engagement / Scoping (สำคัญที่สุด)

1. ยืนยัน legal authorization เป็นลายลักษณ์อักษร: ใครลงนามมีอำนาจจริง, ครอบคลุม target ทุกตัวที่จะยิง, ระบุช่วงเวลา ตรวจ ownership ของ IP/domain (ถ้าโฮสต์บน cloud/third-party ต้องมีสิทธิ์หรือแจ้งผู้ให้บริการตาม policy)
2. ร่าง Rules of Engagement (RoE) + scope table (เทมเพลตด้านล่าง) ให้ทุกฝ่ายเซ็นรับทราบก่อนลงมือ
3. นิยาม "ความสำเร็จ" + deliverable: รายงานอะไร, รูปแบบไหน, retest รวมในราคาหรือไม่
4. ตั้ง safe-word / kill switch และ emergency contact: ถ้าทดสอบทำให้ระบบเริ่มล่ม จะหยุดและแจ้งใครทันที

เฟส 1 — เลือก Methodology & แนวทาง

เลือกกรอบมาตรฐานให้เข้ากับเป้าหมาย (อ้างอิงเป็นกระบวนการ):

• PTES (Penetration Testing Execution Standard) — โครงรวม 7 เฟส ใช้เป็นกระดูกสันหลังของ engagement
• OWASP WSTG (Web Security Testing Guide) — checklist ครอบคลุมสำหรับ web app/API
• OWASP MASTG/MSTG — สำหรับ mobile app (iOS/Android)
• NIST SP 800-115 — Technical Guide to Information Security Testing (วิธีการ + การจัดการ)
• (เสริม) MITRE ATT&CK — แมป technique ที่จำลอง, OSSTMM — งาน network-centric จับคู่ box type: black box (ไม่มีข้อมูลภายใน, สมจริงสุดแต่ช้า), grey box (มี credential/บางส่วนของสถาปัตยกรรม, คุ้มเวลาสุด), white box (เข้าถึง source/architecture เต็ม, ครอบคลุมสุด)

เฟส 2 — Execution (ระดับกระบวนการ เท่านั้น)

ตามเฟสมาตรฐาน PTES — ผู้ทดสอบที่ได้รับอนุญาตเป็นผู้ลงมือ สกิลนี้ใช้กำกับ/ตรวจ ไม่ใช่สั่งโจมตี:

1. Reconnaissance / Information Gathering — รวบรวมข้อมูลเป้าหมายในขอบเขต (passive/active) ทำ asset & attack-surface inventory
2. Scanning / Enumeration — ระบุ service, version, จุดที่น่าสนใจ; แมปเทียบกับ scope (ของนอก scope ห้ามแตะ)
3. Vulnerability Analysis — วิเคราะห์ว่าจุดอ่อนใดมีจริง จัดลำดับความเป็นไปได้ในการ exploit (ลด false positive ก่อนรายงาน)
4. Exploitation — ผู้ทดสอบยืนยันช่องโหว่ "เท่าที่จำเป็นเพื่อพิสูจน์ impact" ภายใต้ RoE (proof-of-concept ที่ปลอดภัย, ไม่สร้างความเสียหาย/ไม่ดูดข้อมูลจริง) — สกิลนี้ไม่ให้ payload/PoC
5. Post-Exploitation — ประเมินผลกระทบจริง: เข้าถึงอะไรได้, ยกระดับสิทธิ์ได้แค่ไหน, pivot ได้หรือไม่ (ทุกอย่างยังอยู่ใน scope + บันทึกหลักฐานให้พอ reproduce); cleanup สิ่งที่วางไว้ทุกชิ้น
6. Reporting — รวบรวม finding → severity (CVSS) → remediation → executive summary

เฟส 3 — Reporting & Triage

1. แต่ละ finding ลงเทมเพลต (ด้านล่าง): title, severity, CVSS vector+score, affected asset, impact, evidence summary, remediation, retest status
2. จัด CVSS (v3.1/v4.0) + ปรับด้วย business context (asset criticality, exploitability จริง, data sensitivity) → priority สำหรับทีม dev
3. เขียน executive summary สำหรับผู้บริหาร (ความเสี่ยงรวม, top risks, สิ่งที่ต้องทำก่อน) + ส่วน technical สำหรับ dev
4. ส่งมอบรายงานผ่านช่องทางปลอดภัย (เข้ารหัส) — รายงาน pen test คือเอกสารลับชั้นสูง

เฟส 4 — Remediation & Retest

1. ทีม dev แก้ตาม priority; ออก ticket ผูกกับแต่ละ finding
2. Retest / re-validation: ผู้ทดสอบกลับมายืนยันว่าแต่ละ finding ถูกปิดจริง (ไม่ใช่ปิดบนกระดาษ) บันทึกลง retest log
3. ออก retest attestation / clean report เมื่อ Critical/High ปิดครบ — ใช้ยื่น compliance/ลูกค้า
4. feed บทเรียนกลับเข้า /dev-standards, /threat-model, /security-testing เพื่อกัน regression รอบหน้า

Output / Artifact (เทมเพลตพร้อมใช้)

1) Rules of Engagement (RoE) — โครงเอกสาร

# Rules of Engagement — <ชื่อโปรเจกต์/ระบบ>
เวอร์ชัน: 1.0 · วันที่: <YYYY-MM-DD> · ระดับชั้นความลับ: CONFIDENTIAL

## 1. Authorization
- เจ้าของระบบ/ผู้มีอำนาจอนุมัติ: <ชื่อ-ตำแหน่ง> ลงนาม: __________ วันที่: ______
- ผู้ทดสอบ (บริษัท/ทีม + ใบรับรอง): <...>
- หนังสืออนุญาตอ้างอิง: <เลขที่/ลิงก์>  | ยืนยันว่าเป้าหมายทั้งหมดเป็นทรัพย์สินของผู้อนุมัติ: [ ] ใช่

## 2. Scope (ดูตารางข้อ 6)
## 3. ประเภทการทดสอบ: [ ] Black [ ] Grey [ ] White  |  [ ] Internal [ ] External
## 4. หน้าต่างเวลา (Time Window)
- วันที่ทดสอบ: <เริ่ม> ถึง <สิ้นสุด>  | ช่วงเวลาที่อนุญาต: <เช่น 22:00–05:00 ICT>
- สภาพแวดล้อม: [ ] Production [ ] Staging [ ] Clone

## 5. ข้อห้าม (Prohibited / Out of bounds)
- [x] ห้าม DoS / DDoS / volumetric / resource exhaustion
- [x] ห้ามแก้ไข/ลบ/ดูด (exfiltrate) ข้อมูลจริงของลูกค้า — ใช้ข้อมูลทดสอบเท่านั้น
- [x] ห้าม social engineering / phishing (เว้นระบุอนุญาตชัดในข้อ 7)
- [x] ห้ามแตะ asset/บริการ third-party ที่ไม่อยู่ในกรรมสิทธิ์ผู้อนุมัติ
- [x] ห้ามทิ้ง backdoor/implant; ต้อง cleanup ทุกอย่างหลังเสร็จ

## 6. การจัดการเหตุฉุกเฉิน (Emergency Handling)
- Emergency contact (24/7): <ชื่อ / เบอร์ / ช่องทาง>
- เงื่อนไขหยุดทันที (kill switch): ระบบ degrade/down, แตะข้อมูลจริงโดยไม่ตั้งใจ, พบ breach ของผู้อื่น
- ช่องทางรายงานสด: <Slack/Line/โทร>

## 7. ข้อยกเว้นที่อนุญาตเป็นพิเศษ: <ระบุ หรือ "ไม่มี">
## 8. การส่งมอบ: รูปแบบรายงาน <...> · ส่งผ่านช่องทางเข้ารหัส <...> · retest รวม: [ ] ใช่ [ ] ไม่

2) Scope Table

3) Finding Report (ต่อ 1 ช่องโหว่)

### [F-001] <ชื่อ finding สั้น ชัด>
- **Severity:** Critical / High / Medium / Low / Info
- **CVSS:** 8.8 — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`  (ระบุ vector เสมอ)
- **Affected asset:** <URL/endpoint/host/parameter/component + version>
- **Category:** <เช่น OWASP WSTG / CWE-id>
- **Impact (ผลกระทบเชิงธุรกิจ):** <ผู้โจมตีที่ได้รับอนุญาตจำลองทำอะไรได้ → กระทบข้อมูล/เงิน/ชื่อเสียงอย่างไร>
- **Evidence summary:** <สรุปหลักฐานแบบ reproduce ได้ — request/response, screenshot, log ref; ไม่ลงรายละเอียด payload ในรายงานสาธารณะ>
- **Likelihood / Exploitability:** <ง่าย/ยาก, ต้องมี precondition อะไร>
- **Remediation (คำแนะนำแก้):** <แนวทางแก้ที่ชัด + reference เช่น secure coding guideline>
- **References:** <CWE / OWASP / vendor advisory>
- **Status:** Open / Fixed / Risk-Accepted  |  **Retest:** Not yet / Pass / Fail
- **Owner / Ticket:** <ผู้รับผิดชอบ / JIRA-xxx>

4) Retest Log

5) Severity Rollup (executive)

Checklist / Definition of Done

• มี written authorization จากผู้มีอำนาจ + ยืนยัน ownership ของทุก target (รวม cloud provider policy ถ้าเกี่ยวข้อง)
• RoE เซ็นครบทุกฝ่าย: scope, time window, ข้อห้าม (DoS/prod data), emergency contact ชัดเจน
• ระบุ box type + internal/external + environment (prod/staging/clone) แล้ว
• เลือก methodology (PTES + WSTG/MASTG/NIST 800-115) ตรงกับเป้าหมาย
• ทุก finding มี CVSS vector+score, impact เชิงธุรกิจ, remediation, evidence ที่ reproduce ได้
• รายงานแยก executive summary + technical detail; ส่งผ่านช่องทางเข้ารหัส
• Critical/High มี owner + ticket + วันที่แก้
• Retest ทำจริงและบันทึกใน retest log; ออก attestation เมื่อปิด Critical/High ครบ
• ยืนยัน cleanup: ไม่มี implant/test data/บัญชีค้างในระบบ
• บทเรียนป้อนกลับ /threat-model + /dev-standards + /security-testing

เคล็ดลับ & ข้อควรระวัง

• authorization ก่อนเสมอ ไม่มีข้อยกเว้น — ถ้าผู้ใช้ขอให้ทดสอบ/หาช่องโหว่ระบบที่ไม่ได้เป็นเจ้าของหรือไม่มีหนังสืออนุญาต ให้ปฏิเสธและอธิบายเรื่องความถูกกฎหมาย สกิลนี้ทำงานบนสมมุติฐานว่า "ได้รับอนุญาตและมีขอบเขตแล้วเท่านั้น"
• อยู่ในระดับวางแผน/กระบวนการ/รายงาน — ไม่ให้ exploit code, payload, หรือคำสั่งโจมตีที่ใช้ยิงจริง สิ่งที่ส่งมอบคือเอกสาร + การจัดลำดับ + คำแนะนำแก้ไข
• ทดสอบบน prod = ความเสี่ยงสูง — ถ้าเลี่ยงได้ใช้ staging/clone; ถ้าจำเป็นบน prod ต้องมี kill switch, นอกเวลาพีค, ห้ามแตะข้อมูลจริง และมีคนฝั่งลูกค้าเฝ้าตลอด
• scope creep คือกับดัก — เจอช่องน่าสนใจที่อยู่นอก scope ต้องหยุดและขออนุญาตเพิ่มเป็นลายลักษณ์อักษรก่อน ห้ามลุยเอง
• รายงานคือสินค้าจริง ไม่ใช่ตัว exploit — มูลค่าอยู่ที่ finding ที่ชัด, CVSS ที่ถูกต้อง, remediation ที่ทำตามได้ และ retest ที่พิสูจน์ว่าปิดจริง
• CVSS อย่างเดียวไม่พอ — ปรับด้วย business context: SQLi บนหน้า marketing กับบนระบบจ่ายเงิน คะแนนดิบอาจเท่ากันแต่ priority ต่างกันมาก
• third-party vs internal: third-party ให้มุมมองอิสระ + ใบรับรอง (OSCP/CREST/GPEN) เหมาะกับ compliance/ก่อน launch ใหญ่; internal team เร็ว+รู้ระบบลึก เหมาะกับรอบถี่ — แต่ระวัง conflict of interest, ควรสลับ third-party เป็นระยะ
• เก็บความลับ — รายงานระบุช่องโหว่ที่ยังไม่แก้ = เอกสารอันตราย เข้ารหัส, จำกัดผู้เข้าถึง, มี retention policy
• point-in-time — pen test ยืนยันสถานะ ณ วันที่ทดสอบเท่านั้น โค้ด/infra เปลี่ยน = ต้องทดสอบใหม่; ใช้ /security-testing ใน CI อุดช่องระหว่างรอบ

เชื่อมกับเฟสอื่น

• ก่อนหน้า: /security-testing — รัน automated SAST/DAST/SCA ให้สะอาดก่อน แล้วค่อยให้ pen test หาของที่เครื่องหาไม่เจอ
• ถัดไป: /release-deploy — ปิด Critical/High + retest pass ก่อน go-live; finding ที่ risk-accepted ต้องมีผู้อนุมัติ
• ภาพรวมทั้งวงจร: /sdlc-agile
• ป้อนกลับ: /threat-model (อัปเดต attack surface จาก finding จริง), /authn-authz-design + /sod-matrix (ช่องโหว่ด้านสิทธิ์), /dev-standards (secure coding gap ที่พบซ้ำ), /business-logic-spec (ช่องโหว่เชิง logic)