การทดสอบเจาะระบบที่อันตราย: เมื่อขอบเขตที่ไม่ได้เขียนนำไปสู่ปัญหาทางกฎหมาย

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

เกิดอะไรขึ้น

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

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

ทำไมรูปแบบนี้จึงเกิดขึ้นซ้ำๆ

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

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

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

ขั้นตอนการโจมตีของผู้โจมตี (จากมุมมองของ pen-tester ที่มีขอบเขตไม่ชัดเจน)

จากมุมมองของ pen-tester ที่ดำเนินการภายใต้ขอบเขตที่ไม่ชัดเจน “คู่มือการเล่น” มักจะเกี่ยวข้องกับการดำเนินการที่เพิ่มขึ้นหลายขั้นตอน ซึ่งแม้จะตั้งใจให้ละเอียด แต่ก็สามารถนำไปสู่ปัญหาได้อย่างรวดเร็ว:

1. การสอดแนมเบื้องต้นและการระบุสินทรัพย์: หากไม่มีรายการสินทรัพย์ที่กำหนดไว้ ผู้ทดสอบอาจใช้ข้อมูลสาธารณะหรือเครื่องมืออัตโนมัติเพื่อระบุเป้าหมายที่เป็นไปได้ ซึ่งอาจรวมถึงสินทรัพย์ของบุคคลที่สามโดยไม่ได้ตั้งใจ เช่น CDN หรือบริการคลาวด์ที่ไม่ได้เป็นของลูกค้าโดยชัดแจ้ง ข้อกำหนดของ BugBunny.ai ห้ามการทดสอบสินทรัพย์ที่อยู่นอกขอบเขตที่ได้รับอนุญาตอย่างชัดเจน รวมถึงโครงสร้างพื้นฐานของบุคคลที่สาม
2. การตรวจสอบขอบเขตและการแจงนับ: ผู้ทดสอบสำรวจระบบที่ระบุเพื่อหาพอร์ต บริการ และจุดเข้าใช้งานที่เป็นไปได้ หาก RoE ไม่ได้กำหนดขอบเขตภายในและภายนอก หรือเครือข่ายย่อยที่เฉพาะเจาะจงอย่างชัดเจน ผู้ทดสอบอาจข้ามเข้าไปในพื้นที่ที่ละเอียดอ่อนก่อนเวลาอันควร
3. ความพยายามในการโจมตี: เมื่อระบุช่องโหว่ได้แล้ว ผู้ทดสอบจะดำเนินการโจมตีเพื่อแสดงผลกระทบ หากไม่มีการจำกัดการดำเนินการที่ทำลายล้างอย่างชัดเจน หรือโซน “ไป/ไม่ไป” ที่เฉพาะเจาะจง ความพยายามในการตรวจสอบแนวคิด (PoC) อาจทำให้เกิดการปฏิเสธการให้บริการหรือข้อมูลเสียหายโดยไม่ได้ตั้งใจ ซึ่งเกินกว่าที่ลูกค้าจะยอมรับได้
4. การเคลื่อนที่ด้านข้างและการเพิ่มสิทธิ์: ในการทดสอบที่ครอบคลุม ผู้ทดสอบมุ่งเป้าไปที่การเข้าถึงที่ลึกขึ้น หากขอบเขตไม่ได้ระบุวิธีการที่ยอมรับได้ หรือยกเว้นระบบที่สำคัญบางอย่างโดยชัดแจ้ง ผู้ทดสอบอาจส่งผลกระทบต่อสภาพแวดล้อมการผลิตหรือฟังก์ชันทางธุรกิจที่สำคัญโดยไม่ได้ตั้งใจ
5. การรายงานและการเปิดเผย: การทดสอบสิ้นสุดลง และมีการรายงานผล อย่างไรก็ตาม หากผลกระทบมีมากกว่าที่คาดไว้เนื่องจากปัญหาขอบเขต รายงานจะกลายเป็นเอกสารที่ก่อให้เกิดข้อโต้แย้งมากกว่าคุณค่า ซึ่งอาจนำไปสู่ข้อพิพาททางกฎหมายเกี่ยวกับความเสียหาย

สิ่งที่ผู้ป้องกันพลาดไป

CISO และวิศวกรความปลอดภัย ซึ่งทำหน้าที่เป็นผู้ป้องกันหลักในสถานการณ์นี้ มักจะพลาดองค์ประกอบสำคัญหลายประการ ประการแรก ความสำคัญสูงสุดของเอกสารกฎการมีส่วนร่วม (RoE) ที่ครอบคลุมและลงนามไม่สามารถกล่าวเกินจริงได้ ดังที่ Secure.com เน้นย้ำว่า RoE “ระบุสิ่งที่ทีมแดงได้รับอนุญาตให้ทำ สิ่งที่[สิ่ง]” และเปลี่ยนการทดสอบ “จากความเสี่ยงทางกฎหมายให้กลายเป็นการฝึกปฏิบัติที่ได้รับการอนุมัติและป้องกัน” หากไม่มีสิ่งนี้ การทดสอบจะมีผล “การแฮกโดยไม่ได้รับอนุญาตด้วยเจตนาที่ดีกว่า”

ประการที่สอง พวกเขาไม่สามารถมั่นใจได้ว่าขอบเขตมีความเฉพาะเจาะจงเพียงพอที่จะครอบคลุมความแตกต่างของโครงสร้างพื้นฐานสมัยใหม่ รวมถึงคลาวด์, API และการพึ่งพาบุคคลที่สาม “การทดสอบเจาะระบบเครือข่าย” ทั่วไปมักจะมองข้ามพื้นที่สำคัญที่ต้องมีการรวมหรือแยกออกอย่างชัดเจน คำแนะนำของ DeepStrike เกี่ยวกับประเภทขอบเขตที่แตกต่างกัน (เว็บ, API, คลาวด์, มือถือ ฯลฯ) เน้นย้ำถึงความต้องการความเฉพาะเจาะจงนี้ นอกจากนี้ การละเลยที่จะได้รับอนุญาตเป็นลายลักษณ์อักษรสำหรับสินทรัพย์เป้าหมายทั้งหมด โดยเฉพาะอย่างยิ่งที่จัดการโดยบุคคลที่สามหรือ MSP ทำให้เกิดช่องว่างทางกฎหมายที่สำคัญ ข้อกำหนดของ BugBunny.ai ระบุอย่างชัดเจนว่าผู้ใช้มีหน้าที่รับผิดชอบในการรับรองการปฏิบัติตามข้อกำหนดและจัดหาหลักฐานการอนุญาตเป็นลายลักษณ์อักษร

สุดท้าย ความเข้าใจว่าการทดสอบเจาะระบบไม่ได้ตอบสนองภาระผูกพันในการปฏิบัติตามข้อกำหนดทั้งหมดโดยอัตโนมัติ และการสแกนช่องโหว่ภายนอกนั้นแตกต่างจากการทดสอบเจาะระบบ มักถูกมองข้าม ตัวอย่างเช่น PCI DSS v4.0.1 กำหนดให้มีการสแกนช่องโหว่ภายนอกแยกต่างหากโดย ASV และการทดสอบเจาะระบบประจำปี ดังที่ Secusy ตั้งข้อสังเกต การรวมข้อกำหนดเหล่านี้เข้าด้วยกัน หรือการสมมติว่าข้อกำหนดหนึ่งครอบคลุมอีกข้อหนึ่งอาจนำไปสู่การค้นพบการปฏิบัติตามข้อกำหนด และที่สำคัญกว่านั้นคือช่องว่างด้านความปลอดภัย

รายการตรวจสอบการป้องกันเชิงปฏิบัติ

เพื่อป้องกันข้อพิพาทเกี่ยวกับขอบเขตและให้แน่ใจว่าการทดสอบเจาะระบบมีประสิทธิภาพ CISO และวิศวกรความปลอดภัยควรดำเนินการดังต่อไปนี้:

• กำหนดกฎการมีส่วนร่วม (RoE) และขอบเขตงาน (SOW) เป็นลายลักษณ์อักษร: ก่อนที่จะเริ่มการทดสอบ ให้แน่ใจว่าเอกสารทั้งสองฉบับครอบคลุม ลงนามโดยทุกฝ่าย และระบุวัตถุประสงค์ สินทรัพย์ การยกเว้น โปรโตคอลการสื่อสาร และการลงนามทางกฎหมาย DeepStrike สนับสนุนการอนุญาตเป็นลายลักษณ์อักษรก่อนเริ่มการทดสอบ
• จัดทำรายการสินทรัพย์และการพึ่งพาทั้งหมด: สร้างรายการที่ครบถ้วนของระบบ แอปพลิเคชัน เครือข่าย สภาพแวดล้อมคลาวด์ และบริการของบุคคลที่สามทั้งหมดที่อาจเกี่ยวข้องกับการทดสอบ ระบุอย่างชัดเจนว่าอะไรอยู่ในขอบเขต และที่สำคัญไม่แพ้กันคืออะไรอยู่นอกขอบเขต
• กำหนดวิธีการทดสอบและข้อจำกัด: ระบุประเภทของการทดสอบ (เช่น black box, white box) เทคนิคที่อนุญาต (เช่น ไม่มีวิศวกรรมสังคมหากไม่ได้รับอนุญาตอย่างชัดเจน) และการกระทำใดๆ ที่ถูกห้ามอย่างเด็ดขาด (เช่น ไม่มีการโจมตีแบบปฏิเสธการให้บริการ ไม่มีการกระทำที่ทำลายล้างนอกเหนือจากการตรวจสอบ PoC) นโยบายการใช้งานที่ยอมรับได้ของ BugBunny.ai เป็นตัวอย่างของข้อจำกัดดังกล่าว
• สร้างโปรโตคอลการสื่อสารที่ชัดเจน: ระบุวิธีการที่จะยกระดับการค้นพบที่สำคัญ ใครมีอำนาจในการหยุดการทดสอบ และความถี่ของการอัปเดต สิ่งนี้ช่วยให้ตอบสนองต่อปัญหาที่ไม่คาดคิดได้อย่างรวดเร็ว
• ตรวจสอบการอนุญาตสำหรับสินทรัพย์ของบุคคลที่สาม: หากการทดสอบเกี่ยวข้องกับระบบใดๆ ที่ไม่ได้เป็นเจ้าของหรือจัดการโดยองค์กรของคุณโดยตรง (เช่น ผู้ให้บริการคลาวด์, MSPs, CDNs) ให้ได้รับความยินยอมเป็นลายลักษณ์อักษรอย่างชัดเจนจากบุคคลที่สามเหล่านั้นสำหรับการทดสอบ BugBunny.ai ต้องการหลักฐานการอนุญาตสำหรับเป้าหมายทั้งหมด
• ปรับขอบเขตให้สอดคล้องกับวัตถุประสงค์ทางธุรกิจและการปฏิบัติตามข้อกำหนด: ตรวจสอบให้แน่ใจว่าขอบเขตสนับสนุนเป้าหมายเฉพาะโดยตรง เช่น หลักฐานการปฏิบัติตามข้อกำหนด (เช่น PCI DSS ข้อกำหนด 11.4) การรับประกันการเปิดตัวผลิตภัณฑ์ หรือการตรวจสอบสถานะ M&A ทำความเข้าใจว่ากรอบการปฏิบัติตามข้อกำหนดมักจะมีข้อกำหนดเฉพาะสำหรับการทดสอบประเภทต่างๆ ดังที่ Secusy เน้นย้ำสำหรับ PCI DSS
• พิจารณาความเป็นอิสระของผู้ทดสอบ: โดยเฉพาะอย่างยิ่งสำหรับ MSPs ให้ประเมินความขัดแย้งทางผลประโยชน์ที่อาจเกิดขึ้น ดังที่ Safe Harbour Security ชี้ให้เห็น ผู้ตรวจสอบและผู้ประกันภัยกำลังตรวจสอบความเป็นอิสระของการทดสอบอย่างเข้มงวดมากขึ้น โดยชอบการตรวจสอบความถูกต้องที่เป็นกลางมากกว่าการทดสอบที่ดำเนินการโดยผู้ให้บริการที่จัดการสภาพแวดล้อมด้วย

การทดสอบเชิงรุกสมัยใหม่จะตรวจจับสิ่งนี้ได้อย่างไร

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

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

สิ่งที่ต้องจับตาดูต่อไป

ภูมิทัศน์ด้านกฎระเบียบที่เปลี่ยนแปลงไปและการตรวจสอบที่เพิ่มขึ้นจากผู้ตรวจสอบและผู้ประกันภัยจะยังคงผลักดันความต้องการการทดสอบความปลอดภัยที่ตรวจสอบได้และเป็นกลาง องค์กรต้องเฝ้าระวังการบังคับใช้ข้อกำหนดการทดสอบที่เป็นอิสระที่เข้มงวดขึ้น โดยเฉพาะอย่างยิ่งที่เกี่ยวกับ MSPs และสภาพแวดล้อมคลาวด์ คำแนะนำของ UK NCSC ดังที่ Safe Harbour Security อ้างถึง ได้เน้นย้ำถึงข้อกังวลเกี่ยวกับการทดสอบที่นำโดยผู้ให้บริการโดยไม่มีการกำกับดูแลแล้ว

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