รายงานคือส่วนของการทดสอบเจาะระบบ (Penetration Test) ที่คงอยู่ต่อไป การทดสอบเกิดขึ้นในช่วงไม่กี่วันหรือไม่กี่สัปดาห์ แต่รายงานคือสิ่งที่นักพัฒนาของคุณใช้แก้ไข สิ่งที่ฝ่ายบริหารอ่าน และสิ่งที่คุณอาจแบ่งปันกับลูกค้าหรือพันธมิตร รายงานที่อ่อนอาจทำให้การทดสอบที่รอบคอบดูไม่มีสาระ ในขณะที่รายงานที่ชัดเจนจะเปลี่ยนข้อค้นพบให้เป็นการตัดสินใจ คู่มือนี้อธิบายว่ารายงานการทดสอบเจาะระบบระดับมืออาชีพโดยทั่วไปมีเนื้อหาอะไรบ้าง วิธีอ่าน และสิ่งที่ควรร้องขอก่อนเริ่มงาน
คืออะไร
รายงานการทดสอบเจาะระบบคือบันทึกเป็นลายลักษณ์อักษรว่ามีการทดสอบอะไร ทดสอบอย่างไร ภายใต้เงื่อนไขใด และพบอะไร รายงานควรอ่านได้โดยผู้อ่านสองกลุ่ม ผู้มีส่วนได้ส่วนเสียที่ไม่ใช่สายเทคนิคต้องการบทสรุปสั้น ๆ เกี่ยวกับความเสี่ยงโดยรวม ปัญหาที่สำคัญที่สุด และลำดับความสำคัญที่แนะนำ ทีมเทคนิคต้องการรายละเอียดของข้อค้นพบแต่ละข้อมากพอที่จะเข้าใจ ทำซ้ำได้ในสภาพแวดล้อมที่ปลอดภัย และแก้ไขได้ รายงานที่ดียังบันทึกข้อจำกัดของตนเองด้วย ได้แก่ สิ่งที่อยู่นอกขอบเขตงาน สิ่งที่ไม่สามารถทดสอบได้ และเงื่อนไขใด ๆ ที่ส่งผลต่อความครอบคลุม เช่น บัญชีทดสอบที่ไม่พร้อมใช้งานหรือช่วงเวลาทดสอบที่สั้นลง หากไม่มีข้อจำกัดเหล่านี้ ผู้อ่านอาจเข้าใจว่ารายงานครอบคลุมมากกว่าความเป็นจริง
เหมาะสำหรับใคร
คู่มือนี้มีประโยชน์สำหรับ:
- ผู้จัดซื้อที่กำลังเปรียบเทียบข้อเสนอ และต้องการทราบว่าจะได้รับผลงานส่งมอบอะไรจริง ๆ
- หัวหน้าทีมวิศวกรรมที่จะได้รับข้อค้นพบ และต้องวางแผนการแก้ไข
- ผู้จัดการที่ต้องแบ่งปันบทสรุปกับลูกค้า พันธมิตร ผู้ตรวจสอบ หรือคณะกรรมการ โดยไม่กล่าวเกินผลลัพธ์จริง
- ทีมที่เคยได้รับรายงานฉบับก่อนหน้าและพบว่ายากต่อการนำไปปฏิบัติ
ช่วยให้เข้าใจเรื่องใด
การรู้โครงสร้างที่ควรมีช่วยให้คุณตรวจสอบได้ว่า:
- ขอบเขตงานและกฎการปฏิบัติงานในรายงานตรงกับที่ตกลงกันไว้หรือไม่
- ข้อค้นพบแต่ละข้อมีหลักฐาน การจัดระดับความรุนแรงที่ชัดเจน และแนวทางการแก้ไขที่นำไปใช้ได้จริงหรือไม่
- ปัญหาใดต้องดำเนินการทันที และปัญหาใดสามารถวางแผนไว้ในรอบการพัฒนาตามปกติได้
- ข้อความใดที่แบ่งปันภายนอกได้อย่างปลอดภัย และข้อความใดควรอยู่กับเจ้าหน้าที่เทคนิคเท่านั้น
สิ่งที่รวมอยู่
- บทสรุปสำหรับผู้บริหาร: ภาพรวม ข้อค้นพบที่สำคัญที่สุด และลำดับความสำคัญที่แนะนำ ด้วยภาษาที่เข้าใจง่าย
- ขอบเขตงานและกฎการปฏิบัติงาน: เป้าหมาย สภาพแวดล้อม บทบาทผู้ใช้ วันที่ ช่วงเวลาทดสอบ และรายการที่ยกเว้น
- สรุประเบียบวิธี: แนวทางและกรอบอ้างอิงที่ใช้ เช่น แนวทางของ OWASP สำหรับเว็บแอปพลิเคชัน
- ทะเบียนข้อค้นพบ: แต่ละปัญหาพร้อมชื่อ ระดับความรุนแรง สินทรัพย์ที่ได้รับผลกระทบ คำอธิบาย การอ้างอิงหลักฐาน และผลกระทบทางธุรกิจ
- รายละเอียดทางเทคนิค: ขั้นตอนที่ทีมของคุณใช้เพื่อทำความเข้าใจและทำซ้ำปัญหาได้อย่างปลอดภัย
- แนวทางการแก้ไข: วิธีแก้ไขที่นำไปใช้ได้จริง และมาตรการบรรเทาระยะสั้นในกรณีที่เป็นประโยชน์
- ข้อจำกัด: สิ่งที่ไม่สามารถทดสอบได้และเหตุผล
- ส่วนการทดสอบซ้ำ: สถานะของข้อค้นพบที่ตกลงกันหลังจากทีมของคุณแก้ไขแล้ว ในกรณีที่รวมการทดสอบซ้ำไว้ในงาน
สิ่งที่ไม่รวมอยู่
- ข้อความว่าระบบปลอดภัยหรือไม่มีช่องโหว่เหลืออยู่หลังการทดสอบ
- ข้อค้นพบนอกขอบเขตงานที่ตกลงกันซึ่งนำเสนอราวกับว่าได้รับการทดสอบแล้ว
- การรับรอง การอนุมัติด้านการปฏิบัติตามข้อกำหนด หรือความเห็นการตรวจสอบอย่างเป็นทางการ
- การดำเนินการแก้ไข เว้นแต่จะตกลงกันแยกต่างหาก
เมื่อใดควรเลือกใช้
อ่านคู่มือนี้ก่อนลงนามในข้อเสนอการทดสอบ เพื่อให้คุณขอตัวอย่างรายงานและยืนยันโครงสร้างได้ คู่มือนี้ยังมีประโยชน์เมื่อได้รับรายงาน โดยใช้หัวข้อข้างต้นเป็นรายการตรวจสอบว่ามีสิ่งใดขาดหายไปหรือไม่ หากผู้มีส่วนได้ส่วนเสียขอให้คุณ "ส่งรายงาน pentest" ให้ตัดสินใจล่วงหน้าว่าพวกเขาต้องการเอกสารทางเทคนิคฉบับเต็ม หรือบทสรุปสำหรับผู้บริหารพร้อมหนังสือแจ้งสถานะการแก้ไข การแบ่งปันรายละเอียดทางเทคนิคฉบับเต็มอย่างกว้างขวางจะเพิ่มความเสี่ยง เพราะเป็นการอธิบายจุดอ่อนในระบบของคุณ
แนวทางของเรา
ขอความชัดเจนเรื่องระดับความรุนแรงก่อนเริ่มการทดสอบ ผู้ให้บริการหลายรายใช้มาตรวัดที่อิงกับโอกาสเกิดและผลกระทบ ซึ่งบางครั้งอ้างอิง CVSS สิ่งสำคัญคือมาตรวัดต้องสม่ำเสมอและมีคำอธิบาย ตกลงวิธีจัดเก็บและแบ่งปันหลักฐาน และผู้ติดต่อที่ระบุชื่อของคุณ เมื่อได้รับรายงานแล้ว ให้นัดการสรุปผลเพื่อให้นักพัฒนาถามคำถามได้ขณะที่บริบทยังชัดเจน แปลงทะเบียนข้อค้นพบเป็นทิกเก็ตที่มีผู้รับผิดชอบและวันเป้าหมาย และแก้ไขปัญหาที่มีระดับความรุนแรงสูงสุดก่อน จากนั้นขอการทดสอบซ้ำสำหรับข้อค้นพบที่ตกลงกัน เพื่อให้รายงานบันทึกได้ว่าสิ่งใดได้รับการแก้ไขแล้ว บริการ Penetration Testing ของเราส่งมอบบทสรุปสำหรับผู้บริหาร สรุปขอบเขตงานและกฎการปฏิบัติงาน ทะเบียนข้อค้นพบที่จัดระดับความรุนแรงพร้อมการอ้างอิงหลักฐาน รายละเอียดทางเทคนิคของข้อค้นพบแต่ละข้อ แผนการแก้ไขที่จัดลำดับความสำคัญ และผลการทดสอบซ้ำในกรณีที่รวมการทดสอบซ้ำไว้ในงาน ไม่ว่าคุณจะเลือกผู้ให้บริการรายใด ให้เก็บรายงานทุกเวอร์ชัน บันทึกว่าข้อค้นพบใดได้รับการยอมรับเป็นความเสี่ยงแทนการแก้ไข และบันทึกว่าใครเป็นผู้ตัดสินใจ บันทึกนั้นมักมีคุณค่าพอ ๆ กับตัวการทดสอบเอง เมื่อมีผู้สอบถามถึงสถานะความปลอดภัยของคุณในครั้งถัดไป
คำถามที่พบบ่อย
บทความที่เกี่ยวข้อง
เริ่มต้นใช้งาน
ต้องการรายงานที่ทีมของคุณนำไปปฏิบัติได้จริงหรือไม่?
แจ้งให้เราทราบว่าระบบใดต้องทดสอบ และใครจะเป็นผู้อ่านผลลัพธ์ เราจะยืนยันขอบเขตงาน กฎการปฏิบัติงาน และโครงสร้างรายงานเป็นลายลักษณ์อักษร
ขอขอบเขตงานเป็นลายลักษณ์อักษร