Coordinated Vulnerability Disclosure เป็นศัพท์ที่ CERT/CC รณรงค์ให้ใช้แทนคำว่า Responsible Disclosure เนื่องจาก CERT/CC มองว่าคำว่า Responsible ในที่นี้มีความหมายที่คลุมเครือเกินไป
เมื่อมีการพบช่องโหว่ ผู้ที่ค้นพบช่องโหว่มักจะพยายามรายงานเจ้าของผลิตภัณฑ์ ไม่ว่าจะเป็นซอฟต์แวร์ ฮาร์ดแวร์หรือเซอร์วิสใดๆ ให้ทราบเพื่อให้ทำการแก้ไข ซึ่งในกระบวนการ Coordinated Vulnerability Disclosure นี้จะเป็นการทำงานร่วมกันระหว่างเจ้าของผลิตภัณฑ์กับผู้ค้นพบช่องโหว่เพื่อแก้ไขช่องโหว่ดังกล่าว โดยหลังจากที่มีการแก้ไขระยะหนึ่งแล้ว ผู้ค้นพบช่องโหว่ถึงจะเปิดเผยรายละเอียดของช่องโหว่ต่อสาธารณะ โดยอาจจะเปิดเผยบางส่วน (Limited Disclosure) หรือเปิดเผยข้อมูลทั้งหมด (Full Disclosure) ก็ได้ ซึ่ง Coordinated Vulnerability Disclosure จะเกิดขึ้นได้ต้องอาศัยทั้งความร่วมมือทั้งผู้ที่ค้นพบช่องโหว่และเจ้าของผลิตภัณฑ์
ตัวอย่างการรายงานช่องโหว่ที่ไม่ได้รับการตอบรับ นำไปสู่การเปิดเผยต่อสาธารณะ
ในอดีตมีเหตุการณ์จำนวนมากที่เกิดจากการที่ผู้ค้นพบช่องโหว่ตั้งใจรายงานช่องโหว่เพื่อให้เกิด Coordinated Vulnerability Disclosure กับเจ้าของผลิตภัณฑ์ แต่ไม่ได้รับการตอบรับจากเจ้าของผลิตภัณฑ์ ทำให้ผู้ค้นพบช่องโหว่ตัดสินใจเผยแพร่ช่องโหว่ดังกล่าวต่อสาธารณชนแทนเพื่อให้เกิดความตระหนักต่อช่องโหว่นั้น
ในบทความ rConfig v3.9.2 authenticated and unauthenticated RCE (CVE-2019-16663) and (CVE-2019-16662) ผู้เขียนบทความ Mohammad Askar ระบุว่าได้รายงานช่องโหว่ไปยังผู้พัฒนา rConfig ถึงช่องโหว่ที่ทำให้รันคำสั่งอันตรายจากระยะไกลได้ (RCE) แต่ไม่ได้รับการติดต่อกลับว่าจะมีการแก้ไขช่องโหว่หรือไม่ เขาจึงตัดสินใจเปิดเผยรายละเอียดเกี่ยวกับช่องโหว่เมื่อผ่านไป 35 วันหลังจากที่ไม่มีการตอบรับ
ตัวอย่างองค์กรที่ได้รับประโยชน์จากการรายงานช่องโหว่
ในเหตุการณ์ข้อมูลรั่วไหลของ Capital One ที่เกิดเมื่อเดือนกรกฏาคม 2019 ที่ผ่านมา Capital One ทราบเหตุการณ์นี้จากช่องทางที่เปิดให้นักวิจัยรายงานช่องโหว่ในวันที่ 17 กรกฏาคม 2019 มีผู้ใช้งาน GitHub พบการโพสข้อมูลที่น่าจะเป็นของ Capital One บน GitHub ข้อมูลดังกล่าวประกอบด้วย IP ของเซิร์ฟเวอร์และคำสั่งที่ใช้ดึงข้อมูลออกจากเซิร์ฟเวอร์ของ Amazon ที่ Capital One ใช้บริการ เมื่อสถาบันการเงิน Capital One ได้ทำการตรวจสอบไฟล์ดังกล่าว จึงพบการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาตโดยใช้คำสั่งเหล่านั้นเมื่อวันที่ 22 ถึง 23 มีนาคม 2019 และได้แจ้งไปยัง FBI ซึ่งได้ทำการติดตามจับกุมผู้ต้องสงสัยได้ในเวลาไม่นานต่อมา (สามารถอ่านรายละเอียดของเหตุการณ์ได้จาก https://www.i-secure.co.th/2019/07/capital-one-data-breach-analysis)
ทำอย่างไรให้เกิด Coordinated Vulnerability Disclosure
ดังที่กล่าวไปว่า Coordinated Vulnerability Disclosure จะเกิดขึ้นได้ต้องอาศัยทั้งความร่วมมือทั้งสองฝ่าย CERT NZ หรือศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์ของประเทศนิวซีแลนด์มีบทความที่น่าสนใจเกี่ยวกับวิธีรายงานช่องโหว่และวิธีรับรายงานอยู่ที่ How to report a vulnerability และ Getting a vulnerability report ซึ่งจะขอสรุปบางส่วนของบทความดังกล่าวไว้ดังนี้
เมื่อจะรายงานช่องโหว่ ผู้รายงานสามารถดูช่องทางการติดต่อได้จาก security.txt ซึ่ง security.txt อยู่ระหว่างการบรรจุเป็นมาตราฐานเพื่อใช้เป็นช่องทางระบุข้อมูลการติดต่อบนเว็บไซต์ ภายในจะประกอบด้วยช่องทางการติดต่อ PGP key และนโยบายในการรับรายงาน (vulnerability policy) ซึ่งในกรณีที่ไม่มี security.txt อาจค้นหาช่องทางติดต่อ IT support หรือ IT security หรือดูที่ข้อมูล WHOIS
ในรายงานช่องโหว่ควรมีรายละเอียดต่างๆ เช่น ชื่อผลิตภัณฑ์และรุ่นที่คิดว่าได้รับผลกระทบ และบอกผลกระทบที่น่าจะเกิดหากมีคนใช้ช่องโหว่โจมตีเป็นอย่างน้อย รวมถึงควรให้เวลาเจ้าของผลิตภัณฑ์ในการตรวจสอบรายงาน
ซึ่งในทางกลับกันองค์กรควรมีการระบุช่องทางการติดต่อสำหรับการรายงานช่องโหว่และนโยบายในการรับรายงาน (vulnerability policy) ไว้ใน security.txt หรือมีการระบุข้อมูลช่องทางติดต่อทีม IT support หรือทีม IT security ไว้ในเว็บไซต์ รวมถึงอัปเดตข้อมูล WHOIS ให้เป็นปัจจุบัน และมีแนวทางในการตรวจสอบรายงานดังกล่าว ทำการประเมินความเสี่ยง ตอบสนองต่อเหตุการณ์ และติดต่อประสานงานกับผู้แจ้งช่องโหว่
แหล่งอ้างอิง
ผู้ที่สนใจเกี่ยว Coordinated Vulnerability Disclosure สามารถอ่านได้จากแหล่งอ้างอิงดังต่อไปนี้
- The CERT Guide to Coordinated Vulnerability Disclosure https://vuls.cert.org/confluence/display/CVD
- What is Vulnerability Coordination? https://vuls.cert.org/confluence/pages/viewpage.action?pageId=4718642
- Vulnerability policy ของ Linkedin https://www.linkedin.com/help/linkedin/answer/62924
- https://securitytxt.org/
- rConfig v3.9.2 authenticated and unauthenticated RCE (CVE-2019-16663) and (CVE-2019-16662) https://shells.systems/rconfig-v3-9-2-authenticated-and-unauthenticated-rce-cve-2019-16663-and-cve-2019-16662/
- How to report a vulnerability https://www.cert.govt.nz/it-specialists/guides/how-to-report-a-vulnerability/
- Getting a vulnerability report https://www.cert.govt.nz/business/guides/responding-to-incidents/getting-a-vulnerability-report/
- A Method for Web Security Policies draft-foudil-securitytxt-08 https://tools.ietf.org/html/draft-foudil-securitytxt-08
- Microsoft's Approach to Coordinated Vulnerability Disclosure https://www.microsoft.com/en-us/msrc/cvd
- ตัวอย่าง security.txt ของ facebook.com https://www.facebook.com/security.txt
- ข้อเสนอมาตรฐานไฟล์ security.txt เพื่อใช้แจ้งเหตุภัยคุกคามไซเบอร์อยู่ในขั้นตอนสุดท้ายของการพิจารณาแล้ว https://www.thaicert.or.th/newsbite/2019-12-12-01.html
You must be logged in to post a comment.