การป้องกันมัลแวร์โอเพนซอร์ส: อะไรได้ผล (และอะไรไม่ได้ผล)

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

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

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

ความเข้าใจผิดทั่วไป

ตลอดเส้นทางการศึกษาด้านความปลอดภัยของซอฟต์แวร์ เราได้เห็นวิวัฒนาการของเทคนิคการโจมตีและแนวคิดที่หลากหลายจากผู้ที่ตระหนักถึงความปลอดภัย องค์กรต่างๆ มักเข้าใจผิดเกี่ยวกับสิ่งที่ได้ผลในการรับมือกับภัยคุกคามนี้ ดังนั้นก่อนอื่นเราจะมาดูสิ่งที่ไม่ได้ผล ซึ่งสรุปไว้ในรายการความเข้าใจผิดต่อไปนี้ (ไม่ใช่รายการที่ครอบคลุมทั้งหมด)

ความเข้าใจผิด #1: SCA เครื่องมือต่างๆ รายงานส่วนประกอบที่เป็นอันตรายอยู่แล้ว

แน่นอน! แต่หลังจากนั้น…เมื่ออาจจะสายเกินไปแล้วหากมีการใช้ส่วนประกอบนั้นในการสร้างซอฟต์แวร์ และผู้ไม่ประสงค์ดีได้แทรกซึมเข้าไปในกลุ่มนักพัฒนาแล้ว CI/CD ข้อมูลลับอาจถูกขโมยออกไป มีการดาวน์โหลดและติดตั้งมัลแวร์เพิ่มเติม และอาจเป็นไปได้ว่าผู้โจมตีได้เคลื่อนย้ายไปยังที่อื่นและเข้าถึงระบบได้แล้ว 

การวิเคราะห์องค์ประกอบซอฟต์แวร์ (SCAเครื่องมือเหล่านี้ถูกออกแบบมาเพื่อระบุช่องโหว่ที่รู้จักอยู่แล้ว เครื่องมือสมัยใหม่ทำงานได้ดีเยี่ยมโดยการเพิ่มอัตราส่วนสัญญาณต่อสัญญาณรบกวน เพื่อตรวจสอบว่าช่องโหว่นั้นสามารถเข้าถึงหรือใช้ประโยชน์ได้จริงหรือไม่ แต่เครื่องมือเหล่านี้ไร้ประโยชน์กับมัลแวร์ตัวใหม่ๆ ลองนึกถึงส่วนประกอบที่เป็นอันตรายว่าเป็นช่องโหว่แบบ Zero-day: เฉพาะเมื่อตรวจพบพฤติกรรมที่เป็นอันตรายเท่านั้น ส่วนประกอบนั้นจึงจะถูกรายงานไปยังรีจิสทรี ซึ่งหลังจากที่ทีมรักษาความปลอดภัยตรวจสอบแล้ว จะได้รับการยืนยันว่าเป็นส่วนประกอบที่เป็นอันตรายและถูกลบออกจากรีจิสทรี [1]. 

ณ จุดนั้น โลก (รวมถึง) SCA(s) รู้ว่าการติดตั้งหรือใช้งานคอมโพเนนต์ (หรือบางเวอร์ชันของคอมโพเนนต์ที่มีอยู่) นั้นไม่ใช่เรื่องดี แต่กรณีนี้เกิดขึ้นเมื่อคอมโพเนนต์นั้นไม่มีอยู่ในรีจิสทรีการรู้ว่าฉันมีช่องโหว่ในส่วนประกอบของบุคคลที่สาม หรือแม้แต่ส่วนประกอบที่ถูกจัดประเภทว่าเป็นอันตรายโดยรีจิสทรีนั้นเป็นเรื่องดี แต่โชคร้ายที่... SCA หรือเครื่องมือตรวจสอบทั่วไปไม่สามารถนำมาใช้ได้ในบริบทนี้ นอกเสียจาก SCAเครื่องมือตรวจสอบ (audit tool) สามารถรู้ล่วงหน้าได้ว่าส่วนประกอบใดเป็นอันตรายก่อนที่จะถูกนำไปใช้ในองค์กรของคุณ.

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

ความเข้าใจผิดข้อที่ 2: การควบคุมสคริปต์การติดตั้งในระหว่างการสร้างโปรแกรมจะช่วยป้องกันพฤติกรรมที่เป็นอันตรายจากส่วนประกอบโอเพนซอร์ส

โปรแกรมจัดการแพ็กเกจต่างๆ มีฟังก์ชันให้เรียกใช้สคริปต์ (ซึ่งรวมอยู่ในไฟล์บีบอัดของส่วนประกอบ) [2]), ด้วยเหตุผลที่ถูกต้องตามกฎหมาย เช่น การรวบรวมรายการที่จำเป็นบนแพลตฟอร์มต่างๆ การสร้างโค้ด หรือการรันการทดสอบ และเราทุกคนควรทราบว่าไฟล์บีบอัดเหล่านี้อาจถูกผู้ไม่ประสงค์ดีนำไปใช้ในทางที่ผิดได้ หากมีการแทรกสคริปต์ที่เป็นอันตรายไว้ในไฟล์บีบอัด หรือหากผู้โจมตีสามารถทำให้สคริปต์ที่เป็นอันตรายทำงานแทนสคริปต์ที่ดีได้

เมื่อทราบเช่นนี้แล้ว เราสามารถกำหนดค่าตัวจัดการแพ็กเกจให้ละเว้นสคริปต์ได้ ตัวอย่างเช่น ในกรณีของ NPM - ละเว้นสคริปต์ ธง (หรือคุณสมบัติการกำหนดค่าใน .npmrc ไฟล์) จะข้ามสคริปต์ระหว่างการติดตั้ง ซึ่งอาจก่อให้เกิดปัญหาบางอย่างเนื่องจากการเรียกใช้สคริปต์เป็นเรื่องปกติในระบบนิเวศหลายๆ ระบบ ตัวจัดการแพ็กเกจบางตัวไม่อนุญาตให้ปิดใช้งานการเรียกใช้สคริปต์ด้วยซ้ำ (คำแนะนำ: แจ้งเตือน “โปรแกรมจัดการแพ็กเกจใดบ้างที่ไม่อนุญาตให้ปิดการใช้งานสคริปต์การติดตั้ง?(ใน AI ที่คุณชื่นชอบ) แต่สิ่งนี้ไม่ได้ป้องกันโดยทั่วไป (เราจำเป็นต้องบังคับให้การตั้งค่าการข้ามปิดใช้งานมีอยู่ทุกที่) 

และเมื่อพฤติกรรมที่เป็นอันตรายไม่ได้อยู่ในสคริปต์การติดตั้ง แต่ในซอฟต์แวร์ที่จะทำงานในระหว่างการรันไทม์ ตัวเลือกนี้เพียงอย่างเดียวก็ไม่สามารถปกป้องเราได้ 

ความเข้าใจผิดข้อที่ 3: การกำหนดเวอร์ชันที่แน่นอนจะช่วยป้องกันการติดตั้งส่วนประกอบที่เป็นอันตราย

มีข้อแลกเปลี่ยนระหว่างการแก้ไขปัญหาตั้งแต่เนิ่นๆ และบ่อยครั้งกับ เวอร์ชันเปิด (โดยอนุญาตให้ตัวจัดการแพ็กเกจติดตั้งการอัปเดตใหม่โดยอัตโนมัติเมื่อมีการแก้ไขด้านความปลอดภัย) และ การตรึงเวอร์ชัน (โดยมีส่วนประกอบที่จำเป็นทั้งหมดทั้งทางตรงและทางอ้อมสำหรับซอฟต์แวร์ในเวอร์ชันคงที่) หลักการด้านความปลอดภัยนั้นดื้อรั้นและบางครั้งก็ขัดแย้งกันเอง ดังเช่นที่เกิดขึ้นกับหลักการ "แก้ไขช่องโหว่แต่เนิ่นๆ และแก้ไขช่องโหว่บ่อยๆ" “การอัปเกรดไม่ใช่เรื่องที่จะมองข้ามไปได้ง่ายๆ”โปรแกรมจัดการแพ็กเกจบางตัวจะทำการอัปเดตอัตโนมัติโดยใช้ช่วงหมายเลขเซิร์ฟเวอร์ตามวิธีที่แนะนำ เหมาะมากหากคุณต้องการรับการอัปเดตที่เป็นอันตรายด้วย! ใช่แล้ว ส่วนประกอบต่างๆ จำเป็นต้องได้รับการอัปเดตเพื่อรับการแก้ไขด้านความปลอดภัยที่ปิดช่องโหว่โดยเร็วที่สุด แต่...อย่าปล่อยให้โปรแกรมจัดการแพ็กเกจทำการอัปเดตโดยอัตโนมัติเด็ดขาด

ความเข้าใจผิดข้อที่ 4: การใช้ส่วนประกอบที่เชื่อถือได้นั้นปลอดภัย ส่วนประกอบที่เป็นอันตรายใดๆ จะถูกตรวจพบ เปิดเผย และลบออกอย่างรวดเร็ว

เหตุใดส่วนประกอบนี้จึงได้รับความไว้วางใจ? อาจเป็นเพราะมันได้รับความนิยมสูง มีผู้คนจำนวนมากคอยตรวจสอบหาช่องโหว่ มีผู้ร่วมพัฒนาจำนวนมาก และมีผู้ดูแลหลักหลายคนที่ตรวจสอบทุกอย่างอย่างละเอียดถี่ถ้วน pull requestsความเป็นจริงนั้นแตกต่างออกไปมาก ส่วนประกอบสำคัญบางอย่างได้รับการดูแลโดยนักพัฒนาเพียงคนเดียวที่ไม่ได้รับค่าตอบแทน เฟรมเวิร์กที่ใช้กันอย่างแพร่หลายมี ผู้ร่วมเขียนบทความประจำจำนวนหนึ่งโดยมีจำนวนลดลงอย่างรวดเร็ว commitต่อผู้ดูแล (โครงการยอดนิยมมักมีผู้ร่วมให้ข้อมูลจำนวนมากที่เข้ามาช่วยดูแลเป็นครั้งคราว) commit และจะไม่กลับมาอีกเลย) และโครงการยอดนิยมที่มีผู้ดูแลเพียงคนเดียวก็มีอยู่มากมาย

ลองนึกภาพตัวเองพูดว่า “อ๋อ เราใช้ Spring Boot / Angular / React / PyTorch / อิมเมจ Docker พื้นฐานอย่างเป็นทางการ ดังนั้นความเสี่ยงที่คุณพูดถึงจึงค่อนข้างต่ำ” บางทีอาจเป็นความจริง เราผู้จำหน่ายผลิตภัณฑ์รักษาความปลอดภัยมักสร้างความหวาดกลัวอยู่ตลอดเวลา และการเข้าไปแทรกแซงทีมพัฒนาเพื่อลดความเสี่ยงที่ยังถกเถียงกันอยู่นั้นเป็นเรื่องไร้สาระ คุณอาจอยากข้ามไปที่ย่อหน้าเกี่ยวกับการยอมรับความเสี่ยง (ในส่วนถัดไป) แล้วทุกอย่างก็จะจบลง แต่โชคร้ายที่ส่วนประกอบที่ได้รับความนิยมมากที่สุดมักเป็นเป้าหมายของผู้ไม่หวังดี และตัวอย่างเช่น ส่วนประกอบที่ได้รับความนิยม ไลบรารี PyTorch ถูกโจมตี ในอดีต

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

สิ่งที่ไม่ได้ผลในการต่อต้านส่วนประกอบที่เป็นอันตราย

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

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

การปิดใช้งานสคริปต์การติดตั้งอาจช่วยได้ แต่จำเป็นต้องบังคับใช้ทุกที่ที่ต้องติดตั้งส่วนประกอบนั้น เช่นเดียวกับการกำหนดเวอร์ชันตายตัว เนื่องจากไม่สามารถกำหนดเวอร์ชันตายตัวจากสถานะเริ่มต้นที่ปลอดภัยได้ตลอดไป

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

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

อย่างไรก็ตาม มีมาตรการควบคุมที่สามารถจัดการกับภัยคุกคามดังกล่าวได้ และควรพิจารณาใช้หากคุณไม่พอใจกับระดับความเสี่ยงที่ยอมรับได้ โปรดอ่านต่อ

อะไรบ้างที่ได้ผลในการป้องกันการโจมตีโดยใช้ส่วนประกอบที่เป็นอันตราย

การจัดการเวอร์ชันโซลิด

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

เตือนภัยล่วงหน้า

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

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

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