ในการประชุม ELC + OpenIoT Summit สถาปนิกด้านความปลอดภัยของ Intel Ryan Ware จะอธิบายวิธีรับมือกับกระแสช่องโหว่ และจัดการความปลอดภัยของผลิตภัณฑ์ของคุณ
เมื่อพัฒนาซอฟต์แวร์โอเพนซอร์ส ช่องโหว่ด้านความปลอดภัยที่คุณต้องพิจารณาอาจท่วมท้นคุณ ช่องโหว่และการเปิดเผยทั่วไป (CVE) ID, ช่องโหว่วันศูนย์ และช่องโหว่อื่นๆ ดูเหมือนจะประกาศทุกวัน ด้วยกระแสข้อมูลเหล่านี้ คุณจะไม่ตามหลังได้อย่างไร?
สถาปนิกด้านความปลอดภัยของ Intel Ryan Ware กล่าวว่า “หากคุณเปิดตัวผลิตภัณฑ์ที่ใช้ Linux kernel 4.4.1 เคอร์เนลนั้นมี 9 CVE สำหรับเคอร์เนลนั้น ณ วันนี้ ทั้งหมดนี้จะส่งผลต่อผลิตภัณฑ์ของคุณ แม้ว่าคุณจะไม่รู้เมื่อโหลดมัน”
ในการประชุม ELC + OpenIoT Summit สถาปนิกด้านความปลอดภัยของ Intel Ryan Ware จะนำเสนอเกี่ยวกับวิธีการดำเนินการและจัดการความปลอดภัยของผลิตภัณฑ์ให้ประสบความสำเร็จ ในการพูดคุยของเขา Ware ได้พูดคุยเกี่ยวกับข้อผิดพลาดทั่วไปของนักพัฒนา กลยุทธ์ในการติดตามช่องโหว่ล่าสุด และอื่นๆ
Linux.com: ให้เริ่มจากต้น คุณสามารถแนะนำช่องโหว่และการเปิดเผยทั่วไป (CVE), วันศูนย์ และช่องโหว่อื่นๆ สั้นๆ ได้ไหม? พวกมันคืออะไร และทำไมจึงสำคัญ?
Ryan Ware: คำถามที่ดี ช่องโหว่และการเปิดเผยทั่วไป (CVE) เป็นฐานข้อมูลที่ดูแลโดย MITR Corporation (องค์กรไม่แสวงหากำไร) ตามคำขอของรัฐบาลสหรัฐ ปัจจุบันได้รับทุนสนับสนุนจากกระทรวงความมั่นคงแห่งมาตุภูมิสหรัฐ สร้างขึ้นในปี 1999 เพื่อรวมข้อมูลเกี่ยวกับช่องโหว่ด้านความปลอดภัยที่เปิดเผยทั้งหมด ช่องโหว่แต่ละอันมีตัวระบุของตัวเอง (CVE-ID) และสามารถอ้างอิงได้ คำว่า CVE ได้พัฒนาจากการหมายถึงฐานข้อมูลทั้งหมดไปเป็นช่องโหว่ด้านความปลอดภัยเดี่ยว: ช่องโหว่ CVE
ช่องโหว่หลายอันที่ปรากฏในฐานข้อมูล CVE เริ่มแรกเป็นช่องโหว่วันศูนย์ ช่องโหว่เหล่านี้ด้วยเหตุผลใดก็ตามไม่ได้ปฏิบัติตามกระบวนการเปิดเผยที่เป็นระเบียบมากขึ้น เช่น “การเปิดเผยอย่างรับผิดชอบ” สิ่งสำคัญคือ หากไม่มีผู้ขายซอฟต์แวร์สามารถตอบสนองผ่านการแก้ไขบางประเภท (โดยปกติคือแพตช์ซอฟต์แวร์) พวกมันจะกลายเป็นสาธารณะและสามารถใช้ประโยชน์ได้ ช่องโหว่เหล่านี้และช่องโหว่ซอฟต์แวร์ที่ยังไม่ได้แพตช์อื่นๆ มีความสำคัญอย่างยิ่ง เพราะก่อนที่จะแพตช์ซอฟต์แวร์ ช่องโหว่สามารถใช้ประโยชน์ได้ ในหลายๆ ด้าน การเปิดเผย CVE หรือวันศูนย์เหมือนกับการยิงปืน ก่อนที่การแข่งขันของคุณจะจบลง ลูกค้าของคุณมีความเสี่ยง
Linux.com: มีช่องโหว่กี่อัน? คุณกำหนดอย่างไรว่าอันไหนเกี่ยวข้องกับผลิตภัณฑ์ของคุณ?
Ryan: ก่อนจะพูดถึงจำนวน ทุกคนที่เปิดตัวซอฟต์แวร์ในรูปแบบใดก็ตามควรจำไว้ แม้คุณจะพยายามทุกวิถีทางเพื่อให้แน่ใจว่าซอฟต์แวร์ที่คุณเปิดตัวไม่มีช่องโหว่ที่รู้จัก ซอฟต์แวร์ของคุณจะมีช่องโหว่ พวกมันเพียงแต่ไม่รู้เท่านั้น ตัวอย่างเช่น หากคุณเปิดตัวผลิตภัณฑ์ที่ใช้ Linux kernel 4.4.1 ณ วันนี้ มี 9 CVE แล้ว ทั้งหมดนี้จะส่งผลต่อผลิตภัณฑ์ของคุณ แม้ว่าคุณจะไม่รู้เมื่อคุณใช้มัน
ในขณะนี้ ฐานข้อมูล CVE มี 80,957 รายการ (ณ วันที่ 30 มกราคม 2017) รวมถึงบันทึกทั้งหมดตั้งแต่ปี 1999 เมื่อมี 894 ปัญหาที่บันทึกไว้ จนถึงปัจจุบัน ตัวเลขที่มากที่สุดในหนึ่งปีคือปี 2014 เมื่อบันทึก 7,946 ปัญหา กล่าวคือ ฉันคิดว่าการที่ตัวเลขลดลงในสองปีที่ผ่านมาไม่ใช่เพราะช่องโหว่ด้านความปลอดภัยลดลง นี่คือสิ่งที่ฉันจะพูดในการพูดคุยของฉัน
Linux.com: นักพัฒนาสามารถใช้กลยุทธ์ใดได้บ้างเพื่อติดตามข้อมูลเหล่านี้?
Ryan: นักพัฒนาสามารถติดตามข้อมูลช่องโหว่ที่ไหลบ่าเข้ามานี้ได้หลายวิธี หนึ่งในเครื่องมือที่ฉันชอบที่สุดคือ CVE Details มันแสดงข้อมูลจาก MITRE ในรูปแบบที่เข้าใจง่ายมาก ฟังก์ชันที่ดีที่สุดคือความสามารถในการสร้างฟีด RSS ที่กำหนดเอง เพื่อให้คุณสามารถติดตามช่องโหว่ของคอมโพเนนต์ที่คุณสนใจ ผู้ที่มีความต้องการติดตามที่ซับซ้อนมากขึ้นสามารถเริ่มจากการดาวน์โหลดฐานข้อมูล MITR CVE (ให้ฟรี) และอัปเดตเป็นประจำ เครื่องมือที่ยอดเยี่ยมอื่นๆ เช่น cvechecker สามารถให้คุณตรวจสอบช่องโหว่ที่รู้จักในซอฟต์แวร์
สำหรับส่วนสำคัญของสแต็กซอฟต์แวร์ ฉันยังแนะนำเครื่องมือที่มีประโยชน์มาก: การมีส่วนร่วมในชุมชนอัปสตรีม พวกเขาคือผู้ที่เข้าใจซอฟต์แวร์ที่คุณใช้มากที่สุด ไม่มีผู้เชี่ยวชาญที่ดีกว่าพวกเขาในโลก ร่วมมือกับพวกเขา
Linux.com: คุณรู้ได้อย่างไรว่าผลิตภัณฑ์ของคุณแก้ไขช่องโหว่ทั้งหมดแล้ว? มีเครื่องมือที่แนะนำไหม?
Ryan: น่าเสียดาย อย่างที่ฉันพูดข้างต้น คุณไม่มีทางลบช่องโหว่ทั้งหมดออกจากผลิตภัณฑ์ของคุณได้ เครื่องมือบางอย่างที่กล่าวถึงข้างต้นเป็นสิ่งสำคัญ อย่างไรก็ตาม ฉันยังไม่ได้พูดถึงส่วนที่สำคัญสำหรับผลิตภัณฑ์ใดๆ ที่คุณเปิดตัว: กลไกการอัปเดตซอฟต์แวร์ หากคุณไม่สามารถอัปเดตซอฟต์แวร์ผลิตภัณฑ์ได้ทันที คุณจะไม่สามารถแก้ไขปัญหาความปลอดภัยเมื่อลูกค้าได้รับผลกระทบ ซอฟต์แวร์ของคุณต้องสามารถอัปเดตได้ และยิ่งกระบวนการอัปเดตง่ายเท่าไหร่ ลูกค้าของคุณจะได้รับการปกป้องที่ดีขึ้นเท่านั้น
Linux.com: นักพัฒนายังต้องรู้อะไรอีกเพื่อจัดการช่องโหว่ด้านความปลอดภัยให้ประสบความสำเร็จ?
Ryan: มีข้อผิดพลาดหนึ่งที่ฉันเห็นซ้ำแล้วซ้ำเล่า นักพัฒนาต้องจำไว้เสมอถึงแนวคิดการลดพื้นที่โจมตีให้น้อยที่สุด นี่หมายความว่าอะไร? ในทางปฏิบัติ นี่หมายความว่าให้รวมเฉพาะสิ่งที่ผลิตภัณฑ์ของคุณต้องการจริงๆ! นี่ไม่เพียงแต่รวมถึงการแน่ใจว่าคุณไม่เพิ่มแพ็กเกจซอฟต์แวร์ที่ไม่เกี่ยวข้องในผลิตภัณฑ์ของคุณ แต่ยังสามารถปิดการกำหนดค่าของฟังก์ชันที่ไม่ต้องการเพื่อคอมไพล์โปรเจกต์
นี่ช่วยอย่างไร? ลองนึกภาพว่านี่คือปี 2014 คุณเพิ่งมาทำงานและเห็นข่าวเทคโนโลยีเกี่ยวกับ Heartbleed คุณรู้ว่าคุณรวม OpenSSL ในผลิตภัณฑ์เพราะคุณต้องการทำฟังก์ชันการเข้ารหัสพื้นฐานบางอย่าง แต่ไม่ได้ใช้ TLS heartbeat ซึ่งเป็นปัญหาที่เกี่ยวข้องกับช่องโหว่นั้น คุณต้องการ:
a. ใช้เวลาทำงานกับลูกค้าและพันธมิตรผ่านการอัปเดตซอฟต์แวร์ที่สำคัญเพื่อแก้ไขปัญหาความปลอดภัยที่สำคัญนี้?
b. เพียงบอกลูกค้าและพันธมิตรของคุณว่าคุณคอมไพล์ผลิตภัณฑ์ OpenSSL ด้วยแฟล็ก “-DOPENSSLNOHEARTBEATS” พวกเขาจะไม่ได้รับผลกระทบ และคุณสามารถมุ่งเน้นไปที่ฟังก์ชันใหม่และกิจกรรมการผลิตอื่นๆ
วิธีที่ง่ายที่สุดในการแก้ไขช่องโหว่คือคุณไม่รวมช่องโหว่นั้น
(ภาพประกอบ: Creative Commons Zero Pixabay)
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
