ทดสอบเจาะระบบอย่างไร ให้ตอบโจทย์หน่วยงานกำกับดูแล

---

เมื่อพิจารณาข้อกำหนดของหน่วยงานกำกับดูแลเรื่องความมั่นคงปลอดภัยทางไซเบอร์ ไม่ว่าจะเป็นภายในประเทศ เช่น

ประกาศธนาคารแห่งประเทศไทย (ธปท.)

ประกาศคณะกรรมการกำกับหลักทรัพย์และตลาดหลักทรัพย์ (กลต.)

ประกาศคณะกรรมการกำกับและส่งเสริมการประกอบธุรกิจประกันภัย (คปภ.)

หรือ ระหว่างประเทศ ในบางครั้งแยกตามกลุ่มอุตสาหกรรม เช่น PCI-DSS ต่างก็กำหนดให้มีการทดสอบเจาะระบบ (Penetration Test) อยู่เสมอ องค์กรไหนที่มีความเชี่ยวชาญในข้อกำหนด และมีประสบการณ์ในการทดสอบเจาะระบบอยู่แล้ว ย่อมสามารถปฏิบัติตามได้ไม่ยาก แต่หากองค์กรไหนที่เพิ่งเริ่มหรือพอมีข้อมูลอยู่บ้างแล้ว บทความนี้แนะนำหลักสำคัญว่าจะต้องทำการทดสอบเจาะระบบอย่างไร เพื่อให้ตอบโจทย์เรื่องของความเสี่ยง (Risk) ตามข้อกำหนด

นอกจากนั้น บทความนี้ยังเหมาะกับผู้ที่ต้องการใช้ประโยชน์จากการทดสอบเจาะระบบให้เกิดประโยชน์สูงสุดกับองค์กรและหน้าที่การงานของทุกคน ไม่ใช่ให้การทดสอบเจาะระบบเป็นเพียงกิจกรรมทางเทคนิคของฝ่าย IT และ Cybersecurity เท่านั้น

---

Estimated reading time: 3 minutes

---

---

1. ทราบสภาพแวดล้อมทางธุรกิจ กฎข้อบังคับ และข้อกำหนด ที่ต้องทำตาม

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

• ลดความซ้ำซ้อนในการดำเนินการทดสอบและออกรายงาน หากเราทราบข้อกำหนดที่เกี่ยวข้องครบถ้วน เราสามารถที่จะดำเนินการทดสอบครั้งเดียวให้ผลที่ได้สอดคล้องกับข้อกำหนดทั้งหมดได้
• เราอาจจะสามารถใช้วิธีอื่นที่ประหยัดงบประมาณกว่า ซึ่งบางครั้งอาจหมายถึงการดำเนินการทดสอบในรูปแบบอื่น ๆ เช่น การประเมินช่องโหว่ (Vulnerability Assessment), การตรวจสอบการตั้งค่าของระบบ (Configuration Review), การตรวจสอบความผิดพลาดด้านความปลอดภัยของ Source Code (Source Code Security Review)
• หากข้อกำหนดแตกต่างกันชัดเจน เราก็จะสามารถวางแผนการดำเนินการทดสอบให้ครบถ้วนเหมาะสมได้ในคราวเดียว

ในส่วนนี้ผู้รับผิดชอบด้าน Security ต้องทำงานร่วมกับผู้รับผิดชอบด้าน Legal และ Compliance

---

2. กำหนดขอบเขตให้เหมาะสม

ลำดับถัดมาเราต้องจัดการเรื่องของขอบเขตการทดสอบครับว่าส่วนใดบ้างที่ต้องได้รับการทดสอบ ซึ่งจะจำแนกตามประเภททรัพย์สิน อันประกอบด้วย Data, Application, Hardware, Supply Chain, Human เพื่อที่จะ

1. ทดสอบได้ครบถ้วนตามข้อกำหนด และครอบคลุมทุกจุดที่เป็นส่วนสำคัญของการดำเนินธุรกิจ
2. คัดเลือก รูปแบบ วิธีการ มาตรฐาน (จะกล่าวถึงในหัวข้อถัดไป) และผู้เชี่ยวชาญให้เหมาะสมกับขอบเขตของการทดสอบ

ในบางกรณีขอบเขตของการทดสอบนั้นจะมีการกำหนดไว้อย่างชัดเจนแล้วตามข้อกำหนด เช่น PCI- DSS (CDE หรือ Card Data Environment หมายถึง People, Process, Technology ที่มีส่วนในการ จัดเก็บ, ประมวลผล, และส่งต่อ Card Holder Data และ Sensitive Authentication Data [SAD] ดูเพิ่มเติม)

หรืออาจจะแจ้งอย่างกว้าง ๆ ให้ผู้รับผิดชอบพิจารณาได้ตามความเหมาะสม เช่น ประกาศ กลต. ที่ สธ. 37/2559 เรื่อง ข้อกำหนดในรายละเอียดเกี่ยวกับการจัดให้มีระบบเทคโนโลยีสารสนเทศ

ในส่วนนี้ผู้รับผิดชอบด้าน Security สามารถขอคำแนะนำจากที่ปรึกษาภายนอกเพิ่มเติมได้ กรณีไม่มีประสบการณ์การดำเนินการมาก่อน

---

3. เลือกวิธีการและมาตรฐานที่เหมาะสม

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

1. รูปแบบการทดสอบ
   1. Application Penetration Test (Web/Mobile/Desktop etc.)
   2. Network Penetration Test
   3. Red Teaming/Intelligence-Led Penetration Test
   4. Purple Teaming
   5. Physical Penetration Test
   6. รูปแบบอื่น ๆ ที่เหมาะสมกับธุรกิจ สามารถสอบถามจากที่ปรึกษาผู้ให้บริการได้
2. ขั้นตอนในการทดสอบตั้งแต่เริ่มต้นจนมีการสอบทวน (Retest/Assurance Test) ผลการแก้ไข ส่วนสำคัญข้อหนึ่งในขั้นตอนคือควรจะต้องมีการจัดทำแบบจำลองของภัยคุกคาม (Threat Model) ก่อนที่จะพยายามค้นหาจุดอ่อน (Vulnerability) การดำเนินการลักษณะนี้จะช่วยให้การทดสอบครบถ้วนที่สุดภายในข้อจำกัดของงบประมาณ เวลา และทรัพยากรที่มี ตัวอย่างขั้นตอนในการทดสอบจากซีเนียส
3. มาตรฐานอ้างอิงจุดอ่อนสำหรับการวิเคราะห์เป้าหมาย เช่น
   1. OWASP Web
   2. OWASP Mobile
   3. OWASP API
   4. CVE
   5. CWE
   6. PCI-DSS Version 4.0 Requirement 6.2.4 และ 6.3.1
   7. Blockchain Smart Contract
   8. มาตรฐานอื่น ๆ สามารถสอบถามจากที่ปรึกษาผู้ให้บริการได้
4. ประเภทของการทดสอบ (รายระเอียดดังภาพด้านล่าง)
   1. Black-Box
   2. Grey-Box
   3. White-Box
5. การกำหนดระดับความเสี่ยง (Risk) และคำนิยาม เพื่อใช้ในการตัดสินใจในการจัดสรรทรัพยากรณ์เพื่อแก้ไขจุดอ่อน (Vulnerability)

---

4. แผนการควบคุมความเสี่ยงจากจุดอ่อนที่ค้นพบ ที่มีความชัดเจน

เมื่อได้รายงานผลการทดสอบมาแล้ว ซึ่งจะมีคำแนะนำในการแก้ไข ประกอบกับระดับความเสี่ยงมาด้วยกัน บางจุดอ่อนเราอาจจะเห็นควรให้แก้ไขในทันทีที่ได้รับรายงาน แต่มีบางจุดอ่อนที่เราไม่สามารถแก้ไขได้ในทันที ส่วนใหญ่จะเป็นจุดอ่อนที่ระดับความเสี่ยงต่ำถึงปานกลาง และมีข้อจำกัดทั้งในเชิงเทคนิคและธุรกิจ เราควรจะจัดทำแผนการแก้ไขให้เรียบร้อยมีวิธีการและกำหนดการที่ชัดเจน ได้รับความเห็นชอบจากผู้ที่มีความรับผิดชอบสูงสุด เพื่อเป็นหลักฐานและเป็นข้อมูลว่าไม่มีความเสี่ยงใดที่ถูกปล่อยปะละเลย ความเสี่ยงจากจุดอ่อนใดไม่สามารถแก้ไขได้โดยตรง ก็ให้ใช้การควบคุมทดแทน (Compensate) ที่ให้ผลลัพธ์เท่าเทียม หรือ ดีกว่าการควบคุมโดยตรง

---

5. การสื่อสารทำความเข้าใจ

ผลการทดสอบเจาะระบบต้องถูกนำเสนอให้กับฝ่ายต่าง ๆ ที่มีส่วนเกี่ยวข้อง เช่น ผู้บริหารระดับสูง หน่วยงานตรวจสอบภายในและภายนอก ผู้ดูแลระบบ ผู้พัฒนาระบบ เป็นต้น จึงต้องมีผู้ที่มีความพร้อมในการให้ข้อมูลที่เป็นประโยชน์ พร้อมตอบข้อซักถาม และให้คำแนะนำ ในรูปแบบที่แต่ละฝ่ายสามารถเข้าใจได้เป็นอย่างดี

ผู้ทดสอบเจาะระบบที่มีความใส่ใจงานของผู้รับการทดสอบ นอกจากจะต้องชำนาญการโจมตีแล้ว ยังต้องสามารถเติมเต็มบทบาทนี้ด้วย

---

6. การเฝ้าระวัง กรณีต้องการยอมรับความเสี่ยง (Risk Acceptance) หรือ กรณีมีความเสี่ยงหลงเหลือจากการควบคุม (Residual Risk)

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

---