Google Project Zero ได้ประกาศการเปลี่ยนแปลงครั้งสำคัญในการจัดการการเปิดเผยช่องโหว่ด้วยนโยบาย Reporting Transparency ใหม่ การเปลี่ยนแปลงนี้มีจุดมุ่งหมายเพื่อแก้ไขปัญหาที่เพิ่มขึ้นในด้านไซเบอร์ซิเคียวริตี้ คือระยะเวลาที่ใช้ในการแก้ไขความปลอดภัยให้ไปถึงอุปกรณ์ของผู้ใช้งานจริง
ทีมวิจัยด้านความปลอดภัยได้ระบุสิ่งที่เขาเรียกว่า patch gap หรือช่องว่างการแพตช์ ซึ่งเป็นความล่าช้าระหว่างการค้นพบช่องโหว่กับการที่ผู้ใช้ติดตั้งการอัปเดตที่เกี่ยวข้อง ที่น่ากังวลมากกว่าคือ upstream patch gap ซึ่งเป็นสถานการณ์ที่ผู้จำหน่าย upstream มีการแก้ไขพร้อมใช้งานแล้ว แต่ downstream dependencies ยังไม่ได้นำมาผสานรวมเข้ากับผลิตภัณฑ์ของตน
ระบบเตือนภัยล่วงหน้าสำหรับช่องโหว่ด้านความปลอดภัย
ภายใต้นโยบายใหม่ Project Zero จะประกาศต่อสาธารณะภายในหนึ่งสัปดาห์หลังจากรายงานช่องโหว่ว่าได้มีการค้นพบปัญหาด้านความปลอดภัย การประกาศจะรวมถึงผู้จำหน่ายหรือโครงการโอเพนซอร์สที่ได้รับผลกระทบ ผลิตภัณฑ์เฉพาะ และกำหนดเวลาเปิดเผย 90 วัน อย่างไรก็ตาม รายละเอียดทางเทคนิคและโค้ด proof-of-concept จะยังคงเป็นความลับจนกว่าจะมีการเปิดเผยแบบเต็มรูปแบบ
สิ่งนี้แสดงให้เห็นถึงการเปลี่ยนแปลงครั้งใหญ่จากแนวทางการเปิดเผยแบบประสานงานแบบดั้งเดิม ซึ่งรายละเอียดช่องโหว่จะถูกเก็บเป็นความลับอย่างสมบูรณ์จนกว่าจะมีการแพตช์พร้อมใช้งาน การตอบสนองจากชุมชนมีความหลากหลาย โดยบางคนชื่นชมความโปร่งใส ขณะที่คนอื่นๆ กังวลเกี่ยวกับผลที่ตามมาที่อาจเกิดขึ้น
รายละเอียดนโยบายความโปร่งใสในการรายงานใหม่:
- ประกาศต่อสาธารณะภายใน 1 สัปดาห์หลังจากรายงานช่องโหว่
- ข้อมูลที่แชร์: ผู้จำหน่าย/โครงการที่ได้รับผลกระทบ ชื่อผลิตภัณฑ์ วันที่รายงาน และกำหนดเวลาเปิดเผยข้อมูล 90 วัน
- รายละเอียดทางเทคนิคและโค้ดสาธิตการโจมตียังคงเป็นความลับจนกว่าจะเปิดเผยข้อมูลทั้งหมด
- รักษานโยบาย 90+30 วันที่มีอยู่เดิม (90 วันสำหรับการแก้ไข + 30 วันสำหรับการนำแพทช์ไปใช้)
การสร้างสมดุลระหว่างความโปร่งใสกับความเสี่ยงด้านความปลอดภัย
นโยบายนี้ได้จุดประกายการถกเถียงเกี่ยวกับว่าการประกาศล่วงหน้าอาจช่วยเหลือผู้โจมตีหรือไม่ Project Zero โต้แย้งว่าประโยชน์มีมากกว่าความเสี่ยง เนื่องจากพวกเขาจะไม่แบ่งปันรายละเอียดทางเทคนิคที่อาจทำให้เกิดการใช้ประโยชน์ในทางที่ผิด อย่างไรก็ตาม นักวิจัยด้านความปลอดภัยได้แสดงความกังวลเกี่ยวกับความเป็นไปได้ในทางปฏิบัติของแนวทางนี้ โดยเฉพาะสำหรับโครงการโอเพนซอร์ส
สมาชิกชุมชนคนหนึ่งได้เน้นถึงความท้าทายสำคัญ สำหรับโครงการที่มีความเสถียรและมี commits น้อย การระบุการแก้ไขความปลอดภัยจาก repositories สาธารณะจะง่ายขึ้นมากเมื่อมีการประกาศช่องโหว่ สิ่งนี้อาจสร้างสภาวะการแข่งขันที่ผู้โจมตีพยายาม reverse-engineer ช่องโหว่จากการแก้ไขก่อนที่ผู้ใช้จะสามารถอัปเดตระบบของตนได้
ผลกระทบต่อผู้ดูแล Open Source
นโยบายนี้ได้ทำให้เกิดความกังวลเป็นพิเศษเกี่ยวกับผลกระทบต่อโครงการโอเพนซอร์สที่ดูแลโดยอาสาสมัคร ผู้ดูแลบางคนได้ถอยห่างจากงานของตนแล้วเนื่องจากแรงกดดันจากนักวิจัยด้านความปลอดภัย และแนวทางใหม่นี้อาจเพิ่มภาระดังกล่าว
มันยิ่งไม่น่าจะเป็นไปได้มากขึ้นกับ Google Project Zero นักวิจัยด้านความปลอดภัย white-hat ที่ดีที่สุดที่เงินซื้อได้ ที่คอยจับตาดูอาสาสมัครอย่างใกล้ชิด
การอภิปรายของชุมชนเผยให้เห็นความตึงเครียดระหว่างการปรับปรุงความปลอดภัยโดยรวมกับการสนับสนุนอาสาสมัครที่ดูแลโครงสร้างพื้นฐานที่สำคัญ บางคนโต้แย้งว่าความโปร่งใสที่เพิ่มขึ้นจะช่วยให้โครงการ downstream เตรียมพร้อมสำหรับการอัปเดต ขณะที่คนอื่นๆ กังวลว่าจะสร้างแรงกดดันและความสนใจที่ไม่พึงประสงค์ต่อผู้ดูแลที่มีภาระงานมากอยู่แล้ว
ช่องโหว่เริ่มต้นภายใต้นโยบายใหม่:
- มีการรายงานช่องโหว่ทั้งหมด 6 จุดในชุดเริ่มต้น
- ทั้ง 6 จุดเป็นซอฟต์แวร์กรรมสิทธิ์ (ไม่ใช่โอเพนซอร์ส)
- 3 จาก 6 จุดเป็นผลิตภัณฑ์ของ Google เอง
- ส่วนใหญ่ดูเหมือนจะเกี่ยวข้องกับฟังก์ชันการถ่ายโอนงานไปยังฮาร์ดแวร์
มองไปข้างหน้า
Project Zero ได้วางตำแหน่งสิ่งนี้เป็นช่วงทดลองและจะติดตามผลกระทบอย่างใกล้ชิด ความสำเร็จของนโยบายนี้น่าจะขึ้นอยู่กับว่ามันจะช่วยลดเวลาระหว่างการค้นพบช่องโหว่กับการปกป้องผู้ใช้ได้จริงหรือไม่ โดยไม่สร้างภาระที่ไม่จำเป็นต่อชุมชนการพัฒนาซอฟต์แวร์
ความคิดริเริ่มนี้สะท้อนถึงความท้าทายที่กว้างขึ้นในความปลอดภัยของซอฟต์แวร์สมัยใหม่ ซึ่ง supply chains ที่ซับซ้อนหมายความว่าช่องโหว่เดียวสามารถส่งผลกระทบต่อผลิตภัณฑ์ downstream ได้นับไม่ถ้วน ว่าแนวทางที่เน้นความโปร่งใสเป็นหลักนี้จะพิสูจน์ประสิทธิผลหรือไม่ยังคงต้องติดตาม แต่มันแสดงให้เห็นถึงการทดลองที่กล้าหาญในแนวทางการเปิดเผยช่องโหว่
อ้างอิง: Project Zero