ISO 27001 ต้องทำ Penetration Test หรือไม่? ข้อกำหนด หลักฐาน และความถี่ที่ผ่านการตรวจรับรอง
"ISO 27001 ระบุไว้ตรงไหนว่าต้องทำ Penetration Test"
ไม่มีครับ อ่านทั้งมาตรฐานก็ไม่พบคำนี้ ทีมที่กำลังจัดงบประมาณขอการรับรองมักยกประเด็นนี้ขึ้นมา และในแง่ตัวบทถือว่าถูกต้อง แต่เมื่อถึงการตรวจ Stage 2 ผู้ตรวจประเมินจะถามคำถามเดียว: องค์กรพิสูจน์อย่างไรว่ามาตรการทางเทคนิคต้านทานการโจมตีได้จริง หากคำตอบเดียวที่มีคือรายงานการติดตั้งแพตช์ การตรวจครั้งนั้นมักจบที่ Finding
ความคาดหวังนี้มาจากข้อกำหนดสามส่วนที่ทำงานร่วมกัน Annex A 8.8 กำหนดให้ระบุช่องโหว่ทางเทคนิคและประเมินความเสี่ยงจากช่องโหว่เหล่านั้น A 8.29 กำหนดให้ทดสอบความปลอดภัยในขั้นพัฒนาและตรวจรับระบบ และ Clause 9.1 ซึ่งเป็นข้อที่องค์กรมองข้ามบ่อยที่สุด กำหนดให้ประเมินว่ามาตรการทำงานตามวัตถุประสงค์หรือไม่ เครื่องมือสแกนยืนยันได้ว่าติดตั้งแพตช์แล้ว แต่มีเพียงการทดสอบโจมตีเท่านั้นที่ยืนยันได้ว่ามาตรการต้านทานได้จริง การทดสอบเจาะระบบคือวิธีผลิตหลักฐานดังกล่าวออกมาเป็นเอกสาร และผู้ตรวจประเมินถือเป็นคำตอบมาตรฐาน
มาตรการใหม่ในฉบับปี 2022 อีกสองข้อใช้หลักฐานชุดเดียวกัน A 8.28 (Secure Coding) มี Code Review และเครื่องมือ SAST เป็นหลักฐานประจำวัน ขณะที่ผลทดสอบเจาะระบบที่สืบย้อนไปถึงข้อบกพร่องในโค้ดคือตัวชี้วัดว่ามาตรการนี้ได้ผลจริงหรือไม่ ส่วน A 5.7 (Threat Intelligence) รับรายงานทดสอบเป็นข้อมูลประกอบได้โดยตรง เพราะรายงานบันทึกเทคนิคการโจมตีที่ใช้กับระบบขององค์กรจริง
หลักฐานหกรายการที่ผู้ตรวจประเมินขอ
การทดสอบเป็นงานเพียงครึ่งเดียว Clause 7.5 กำหนดให้จัดเก็บเอกสารหลักฐาน และจากงานเตรียมความพร้อมให้องค์กรไทยเข้ารับการตรวจรับรอง ผู้ตรวจประเมินขอเอกสารชุดเดียวกันแทบทุกครั้ง:
- วิธีการทดสอบและผู้ทดสอบ ซึ่งต้องเป็นอิสระจากทีมที่พัฒนาระบบ
- รายการช่องโหว่พร้อมระดับ Severity และผลประเมินความเสี่ยงรายข้อ
- หลักฐานการแก้ไขและการทดสอบซ้ำ รายช่องโหว่
- กระบวนการจัดการช่องโหว่ที่ระบุผู้รับผิดชอบและกำหนดเวลาแก้ไขตามระดับ Severity
- ตารางการทดสอบที่สอดคล้องกับ Risk Treatment Plan และขอบเขต ISMS
- บันทึก Management Review ที่แสดงว่าผลการทดสอบถึงผู้บริหาร
รายการที่ 3 คือจุดที่การตรวจไม่ผ่านบ่อยที่สุด รายงานอายุสิบเอ็ดเดือนที่มีช่องโหว่ Critical ค้างสิบรายการโดยไม่มีหลักฐานทดสอบซ้ำ ส่งผลเสียมากกว่าไม่มีรายงาน เพราะเป็นเอกสารยืนยันว่าองค์กรทราบแล้วแต่ไม่ได้ดำเนินการ นี่คือเหตุผลที่กรอบ PROVE ของเรากำหนดให้การทดสอบซ้ำเป็นขั้นตอนที่ปิดช่องโหว่ หลักฐานการปิดที่ได้จากขั้นตอนนี้คือเอกสารที่ผู้ตรวจประเมินต้องการเห็นโดยตรง
จัดทำ Control Mapping ในระดับที่พอดี
คำถามที่ทีม ISMS ถามเป็นประจำคือต้องทำ Mapping ละเอียดเพียงใด มักเกิดหลังมีข้อเสนอให้จัดทำตารางเชื่อมโยงทุกช่องโหว่กับทุกมาตรการ ระดับนั้นเกินความจำเป็น ตารางเดียวในเอกสารจัดการช่องโหว่ครอบคลุมข้อกำหนดแล้ว:
| หลักฐาน | ข้อกำหนดหลัก | ข้อกำหนดรอง |
|---|---|---|
| รายงาน VA Scan รายไตรมาส | A 8.8 | Clause 9.1 |
| รายงานทดสอบเจาะระบบประจำปี | A 8.8, Clause 9.1 | A 5.7 |
| ทดสอบก่อนขึ้นระบบใหม่ | A 8.29 | A 8.25, A 8.28 |
| หลักฐานทดสอบซ้ำและปิดช่องโหว่ | A 8.8 | Clause 10 |
| ช่องโหว่ที่บันทึกเข้า Risk Register | Clause 6.1.2 | A 5.7 |
จากนั้นให้ผู้ให้บริการเพิ่มหน้า Compliance Mapping หนึ่งหน้าไว้ในรายงาน หน้าเดียวนี้ตอบคำถามด้านความเชื่อมโยงได้ในการตรวจเกือบทุกครั้ง ความละเอียดที่มากกว่านี้ใช้แรงงานเพิ่มโดยผลการตรวจไม่เปลี่ยน
ข้อผิดพลาดที่ทำให้การรับรองไม่ผ่านจริงคือเรื่องขอบเขต ไม่ใช่เรื่อง Mapping หาก Statement of Applicability ครอบคลุมทั้งระบบลูกค้าและระบบ HR ภายใน แต่ทดสอบเฉพาะระบบลูกค้า ช่องว่างนี้ผู้ตรวจประเมินตรวจพบได้ทันที อีกประเด็นคือการใช้ VA Scan แทนการทดสอบเจาะระบบ ซึ่งใช้แทนกันไม่ได้ สองแนวทางนี้ตอบคนละส่วนของ A 8.8 และ Surveillance Audit สอบถามทั้งสองส่วนมากขึ้นทุกปี เราเปรียบเทียบไว้ละเอียดที่ Vulnerability Assessment (VA) ต่างจาก Pentest อย่างไร
ความถี่และจังหวะเวลาที่เหมาะสม
มาตรฐานไม่กำหนดรอบการทดสอบ จึงเป็นหน้าที่ของ Risk Treatment Plan ขององค์กรที่ต้องกำหนดเอง รอบที่ผ่านการตรวจอย่างสม่ำเสมอ: ทดสอบเจาะระบบเต็มรูปแบบปีละครั้ง โดยจัดจังหวะให้รายงานยังเป็นปัจจุบันในวันตรวจ VA Scan รายไตรมาส หรือรายเดือนสำหรับระบบที่เปิดสู่อินเทอร์เน็ต และทดสอบเพิ่มเฉพาะส่วนหลังการเปลี่ยนแปลงสำคัญ ได้แก่ ระบบใหม่ Release ขนาดใหญ่ การย้ายโครงสร้างพื้นฐาน หรือเหตุการณ์ด้านความปลอดภัย
บันทึกรอบการทดสอบนี้ลงในเอกสารกระบวนการจัดการช่องโหว่ด้วย การทดสอบที่มีคุณภาพแต่ดำเนินการโดยไม่มีตารางกำหนด ยังคงเป็นประเด็นในการตรวจ เพราะสิ่งที่ผู้ตรวจประเมินตรวจคือระบบบริหารจัดการ และการทดสอบที่ไม่มีการวางแผนคือหลักฐานว่าระบบไม่ได้ดำเนินงานจริง
ด้านจังหวะเวลา: ทดสอบก่อน Stage 2 โดยเหลือเวลาเพียงพอสำหรับแก้ไขและทดสอบซ้ำ ล่วงหน้าสามเดือนคือระยะที่เหมาะสม ล่วงหน้าสามสัปดาห์หมายความว่ารายงานจะเข้าห้องตรวจพร้อมช่องโหว่ Critical ที่ยังเปิดอยู่ ซึ่งขัดกับวัตถุประสงค์ของการมีรายงานตั้งแต่ต้น
การทดสอบหนึ่งงาน ตอบสามหน่วยงานกำกับ
องค์กรไทยแทบไม่มีรายใดทำ ISO 27001 เพียงมาตรฐานเดียว และความทับซ้อนนี้เป็นข้อได้เปรียบ สถาบันการเงินมีแนวทาง ธปท. ที่กำหนดการทดสอบเจาะระบบประจำปีโดยหน่วยงานอิสระอยู่แล้ว ผู้ควบคุมข้อมูลส่วนบุคคลอยู่ภายใต้ PDPA มาตรา 37 ซึ่งใช้เกณฑ์มาตรการที่ "เหมาะสม" และเมื่อ สคส. ประเมินเกณฑ์นี้หลังเกิดเหตุ รายงานทดสอบฉบับล่าสุดคือหลักฐานที่มีน้ำหนักที่สุด การทดสอบประจำปีหนึ่งงานที่กำหนดขอบเขตอย่างรอบคอบจึงตอบทั้งสามกรอบพร้อมกัน: กำหนดขอบเขตตามแนว ISMS เพิ่มระบบเฉพาะของแต่ละหน่วยงานกำกับ เช่น ช่องทาง Mobile Banking สำหรับ ธปท. และระบบประมวลผลข้อมูลส่วนบุคคลสำหรับ PDPA แล้วใช้รายงานฉบับเดียวกันกับทุกกรอบ
ข้อกำหนดแบบแยกรายมาตรการอยู่ที่หน้า ISO 27001 ของเรา
กำลังเตรียมเข้ารับการตรวจรับรองและต้องการความมั่นใจว่าหลักฐานการทดสอบจะผ่านเกณฑ์ แจ้งวันตรวจของคุณมาที่เรา เรากำหนดขอบเขตการทดสอบให้สอดคล้องกับ ISO พร้อมหน้า Compliance Mapping ที่ผู้ตรวจประเมินขอ และส่งใบเสนอราคาภายใน 48 ชั่วโมง
บริการที่เกี่ยวข้อง
- การทดสอบเจาะระบบ ทดสอบประจำปีและก่อนขึ้นระบบใหม่ พร้อม PoC ทุกช่องโหว่และรอบทดสอบซ้ำ
- การประเมินช่องโหว่ (VA) สแกนรายไตรมาสพร้อมตรวจยืนยันโดยผู้เชี่ยวชาญ ตอบโจทย์ A 8.8
- ISO 27001 Compliance Testing ข้อกำหนดหลักฐานรายมาตรการและรายงานพร้อมยื่นตรวจ
