เหตุการณ์จอฟ้า หรือ Blue Screen Of Dead (BSOD) ที่เกิดขึ้นในวันที่ 19 กรกฎาคม 2024 กับอุปกรณ์ที่ใช้ระบบปฏิบัติการของ Microsoft Windows กว่า 8.5 ล้านเครื่องทั่วโลกหยุดทำงานพร้อมกันทั้งหมด สร้างความเสียหายเป็นวงกว้าง สายการบินหยุดชะงัก โรงพยาบาลได้รับผลกระทบ อุตสาหกรรมการเงินเองก็หนีไม่พ้นเช่นกัน ซึ่งเหตุการณ์ทั้งหมดนี้เกิดขึ้นจากความผิดพลาดจากการกระทำเล็กๆ น้อยๆ ในกระบวนการอัปเดตของซอฟต์แวร์แบบอัตโนมัติ จากผู้นำด้านความปลอดภัยไซเบอร์อย่าง CrowdStrike
ซึ่งแน่นอนว่ากระบวนการอัปเดตแบบอัตโนมัติเป็นกระบวนการที่ได้รับการยอมรับโดยสากล เพราะนั้นเท่ากับเป็นการลดภาระให้กับผู้ใช้งาน ไม่ต้องนั่งคลิ๊กอัปเดตเวอร์ชันเอง และไม่ใช่เพียงแค่ซอฟต์แวร์ของ CrowdStrike เท่านั้น หากรวมซอฟต์แวร์อื่นๆ เข้าไปด้วย ผู้ใช้งานอาจจะเสียประสิทธิภาพการทำงานและเวลา ไปวันละหลายนาทีทีเดียว
จากบทสัมภาษณ์และคำชี้แจงของ George Kurtz, CEO, CrowdStrike (อ้างอิง 1) เขาได้พูดถึงเหตุผลที่ต้องมีกระบวนการนี้เพื่อต้องการนำกลุ่มผู้ไม่หวังดีทางไซเบอร์อย่างน้อย 1 ก้าว ต้องการให้อุปกรณ์ทุกเครื่องที่ได้รับการปกป้องอยู่ มีความสามารถสูงสุดในการตรวจจับและปกป้องผู้ใช้งานจากภัยคุกคามไซเบอร์ จึงทำการส่งมอบเวอร์ชั่นใหม่ๆ เพื่ออัปเดทให้อุปกรณ์เหล่านั้นเก่งขึ้น ฉลาดขึ้น แต่ทว่าสิ่งนี้ก็เป็นเหตุของหายนะ ที่จริงๆ แล้วสามารถหลีกเลี่ยงได้ ?
เหตุการณ์นี้เป็นบทเรียนสำคัญให้กับองค์กรในหลายๆ เรื่อง รวมถึงตัวผู้ให้บริการอย่างบริษัท ไซเบอร์ อีลีท เอง เพราะเรากำลังอยู่ในยุคที่ใช้เทคโนโลยีเป็นส่วนประกอบในการดำเนินชีวิต โดยเฉพาะการทำงาน ลองนึกกันเล่นๆ ว่าทุกวันนี้เราใช้งานเทคโนโลยีอะไรบ้างไม่ว่าจะเป็นซอฟต์แวร์ ฮาร์ดแวร์ หรือแอปพลิเคชัน เรียกได้ว่านับไม่ถ้วน เราจึงเขียนบทความนี้เพื่อให้มั่นใจว่าทุกคนได้เรียนรู้อะไรบางอย่างจากเหตุการณ์ที่กล่าวไปข้างต้น
จากเหตุการณ์นี้ เป็นที่ชัดเจนเลยว่าสิ่งที่ทุกองค์กรควรพัฒนาปรับปรุงให้ดีมากที่สุดคือความยืดหยุ่นขององค์กรในการรับมือกับภัยคุกคาม (Cyber Resilience) หรือเหตุไม่คาดคิดแบบในกรณีเหตุการณ์จอฟ้า BSOD นี้ เนื่องจาก Technology Landscape หรือโครงสร้างของเทคโนโลยีขององค์กรในปัจจุบันมีความซับซ้อน และมีความปรับปรุงเปลี่ยนแปลงไปตามปัจจัยต่างๆ ที่อาจควบคุมได้หรือไม่ได้ ความผิดพลาดสามารถเกิดขึ้นได้จากจุดบกพร่องเล็กๆ แต่สามารถลุกลามไปในวงกว้างได้ ดังนั้น เพื่อให้การดำเนินงานขององค์กรเป็นไปได้อย่างมีประสิทธิภาพและต่อเนื่องมากยิ่งขึ้น องค์กรต้องมีการวางแผนล่วงหน้าเพื่อตั้งรับในกรณีที่ที่มีเหตุการณ์เหล่านี้เกิดขึ้น ยิ่งหลากหลายเหตุการณ์สมมติเท่าไหร่ ยิ่งเพิ่มความพร้อมให้กับองค์กรได้มากยิ่งขึ้นเท่านั้น
4 ปัจจัย สาเหตุหลักทุกการล่ม
ไซเบอร์ อีลีท ในฐานะผู้ให้บริการด้านความมั่นคงปลอดภัยทางไซเบอร์ มีกลยุทธ์ และแผนการรับมือจากทีมผู้เชี่ยวชาญ เพื่อมาเสริมความยืดหยุ่นให้กับองค์กร ให้มีความสามารถในการรับมือกับเหตุการณ์ทำนองนี้ได้อีกในอนาคต
ก่อนที่จะเข้าสู้กลยุทธ์หรือแนวทางที่ควรมีไว้เพื่อนป้องกันเหตุการณ์เหล่านี้ เราควรมาทำความรู้จักกับ 4 ปัจจัย ที่เป็นสาเหตุหลักในการล่มของระบบ โดยเราได้อ้างอิงมาจากเอกสารแนวทางการประเมินความเสี่ยง NIST SP 800-30 “NIST SP 800-30 Rev 1 Guide for Conducting Risk Assessments” (อ้างอิง 2) พบว่าจริงๆ แล้วมีปัจจัยที่เป็นภัยทางความมั่นคงไซเบอร์อยู่ด้วยปัจจัยหลักๆ 4 ประการ ได้แก่
- ความล้มเหลวเชิงโครงสร้างของการควบคุมทรัพยากรขององค์กร (Structural failures of organization-
controlled resources) - ความผิดพลาด อันเกิดจากฝีมือมนุษย์โดยการละเลยหน้าที่ (Human errors of omission or commission)
- ภัยทางธรรมชาติอันเป็นสิ่งที่สร้างขึ้นโดยฝีมือมนุษย์ และนอกเหนือการควบคุมขององค์กร (Natural and man-made disasters, accidents, and failures beyond the control of the organization)
- ภัยคุกคามจากผู้ไม่หวังดีภายนอก (Hostile cyber or physical attacks)
จาก 4 ข้อที่กล่าวมาทั้งหมด องค์กรส่วนใหญ่มักให้ความสำคัญไปที่ข้อ 4 ได้แก่ ภัยคุกคามจากผู้ไม่หวังดีภายนอก องค์กรส่วนใหญ่ป้องกันปัญหานี้ด้วยเทคโนโลยีที่เข้ามาสร้าง Protection สารพัดให้กับเครื่องข่าย อุปกรณ์ ข้อมูล และอื่นๆ อีกมากมาย ซึ่งทั้งหมดที่กล่าวมา ไม่ใช่เรื่องที่ผิดแต่อย่างใด เพียงแต่องค์กรควรมีการวางแผนรับมือกับข้ออื่นๆ ด้วยเช่นกัน โดยเฉพาะในกรณีนี้ปัจจัยข้อที่ว่า ความล้มเหลวเชิงโครงสร้างของการควบคุมทรัพยากรขององค์กร (Structural failures of organization-controlled resources) ดูจะเป็นปัจจัยที่ชัดเจนที่สุด ที่เป็นสาเหตุของการล่มครั้งใหญ่ครั้งนี้
อ้างอิงจากเอกสาร Preliminary Post Incident Review (PIR) (อ้างอิง 3) CrowdStrike ออกมายอมรับว่าเป็นความผิดพลาดของกระบวนการส่งข้อมูลอัปเดทที่ไม่ได้มีการทดสอบอย่างเพียงพอและรอบด้านไปยังเครื่อง Endpoint หรืออุปกรณ์ของผู้ใช้งาน ซึ่งเป็นกระบวนการที่เคยทำในการทำงานปกติ เหตุการณ์นี้ทำให้นึกถึงประโยคที่พูดกันขำขันในกลุ่มคนทำงานในด้าน IT ที่ว่า “Real man test on production” อย่างไรก็ตามเหตุการณ์นี้ได้ทำให้ประโยคนี้ขำน้อยลงแล้ว จากผลกระทบที่เกิดขึ้นโดยเฉพาะเมื่อเราอยู่ในโลกที่ทุกอย่างเชื่อมต่อกันอย่างซับซ้อนแบบปัจจุบันนี้
2 ข้อที่ต้องปฏิบัติถ้าหากต้องล้มอีก ต้องล้มไม่นาน
เมื่อเราได้ทราบ 4 ปัจจัยที่เป็นเหตุให้ระบบล่มกันแล้ว ตอนนี้ถึงเวลาที่เราต้องเรียนรู้แล้วว่า ถ้าต้องการเจอเข้ากับเหตุการณ์แบบนี้อีก จะต้องวางรูปแบบการจัดการระบบขององค์กรอย่างไร อ้างอิงจากเอกสาร NIST SP 800-160 เล่มที่ 1 “Engineering Trustworthy Secure Systems” (อ้างอิง 3) มีการพูดถึงหลักการและกลยุทธ์ที่องค์กรควรนำมาใช้ แต่ที่เราจะพูดถึงในวันนี้มีอยู่ 2 ประการ ได้แก่
- การกระจายสิทธิ์ (Distributed Privilege) แบ่งสิทธิ์การเข้าถึงในระบบคอมพิวเตอร์หรือเครือข่ายออกเป็นหลายส่วน แทนที่จะรวมศูนย์ไว้ที่จุดเดียวหรือบุคคลเดียว เช่น การแบ่งสิทธิ์ผู้ดูแลระบบออกเป็นหลายระดับ
- ล้มได้ ก็ต้องลุกให้เร็ว (Protective Failure) เหตุการณ์ความผิดพลาดต่างๆ สามารถเกิดขึ้นได้เสมอ ไม่ว่าจากปัจจัยภายใน หรือภายนอก องค์กรจึงต้องออกแบบระบบให้สามารถรักษาความปลอดภัยไว้ได้ ไม่ว่าจะเกิดอะไรขึ้น หรืออย่างน้อย หากระบบต้องถูกดาวน์ลง ก็ควรที่จะใช้เวลาในการกลับมาทำงานใหม่ได้ในเวลาที่สั้นที่สุด
ข้อที่ 2 ดูจะเป็นอะไรที่เข้ากับเหตุการณ์นี้มากที่สุดเพราะการวางแผน การติดกระดุมเม็ดแรกให้ดี ย่อมป้องกันความผิดพลาด และความยุ่งเหยิงที่จะเกิดขึ้นในอนาคตได้ดีเช่นกัน ไซเบอร์ อีลีท พร้อมให้คำปรึกษาให้กับองค์กรเพื่อออกแบบระบบตามมาตรฐาน NIST ให้แก่องค์กร ช่วยให้ท่านมั่นใจได้ว่าทุกๆ เหตุการณ์ ทุกๆ การล้ม ท่านจะมีความยืดหยุ่นมากพอที่จะลุกขึ้นมาดำเนินธุรกิจของท่านได้อย่างรวดเร็ว ด้วยวิธีการระบุความเสี่ยงตั้งแต่ยังไม่เกิดเหตุการณ์ เพื่อปรับปรุงโครงสร้างพื้นฐานของระบบให้มีความยืดหยุ่นและรองรับการเปลี่ยนแปลงได้ดียิ่งขึ้น
5 ข้อควรปฏิบัติจากผิดมาก เป็นผิดน้อย
หากท่านเป็นผู้ให้บริการ หรือผู้พัฒนาซอฟต์แวร์ เรามีข้อปฏิบัติ 5 ประการ ที่ได้รับการยอมรับในระดับสากล เพื่อให้ท่านนำมาประยุกต์ใช้ในกรณีที่องค์กรของท่านต้องการออกอัปเดตซอฟต์แวร์ หรือเปิดตัวซอฟต์แวร์ใหม่ๆ โดยมีรายละเอียดดังต่อนี้
- ทดสอบเบื้องต้นก่อนใช้งานจริง และการติดตั้งแบบแบ่ง Phase (Staged Rollouts and Phased Deployments)
- การทดสอบเบื้องต้นก่อนใช้งานจริง (Pilot Testing): ขั้นแรก ควรทดสอบการอัปเดตซอฟต์แวร์บนกลุ่มผู้ใช้กลุ่มเล็ก เพื่อหาข้อบกพร่องและตรวจสอบปัญหาต่างๆ ของระบบ ก่อนที่จะเปิดใช้งานให้กับผู้ใช้ทั้งหมด
- การติดตั้งแบบแบ่ง Phase (Phased Deployment): ดำเนินการอัปเดตเป็นระยะ อย่างค่อยเป็นค่อยไป โดยเริ่มจากระบบที่มีความสำคัญน้อยกว่า เพื่อให้แน่ใจว่าระบบมีความเสถียรและลดผลกระทบของปัญหาที่อาจเกิดขึ้น
- ควบคุมการอัปเดตด้วยการกำหนดเวลา (Controlled Update Scheduling)
- การกำหนดเวลาอัปเดตด้วยตนเอง (Manual Update Scheduling): ตั้งค่าซอฟต์แวร์ให้สามารถอนุมัติและกำหนดเวลาอัปเดตด้วยตนเอง วิธีนี้ช่วยให้มั่นใจว่าการอัปเดตจะเกิดขึ้นในช่วงเวลาที่เหมาะสม และส่งผลกระทบต่อการดำเนินงานน้อยที่สุด
- การชะลอการอัปเดตซอฟต์แวร์ (Deferred Updates): นโยบายที่ชะลอการอัปเดตซอฟต์แวร์จนกว่าจะมีการทดสอบภายในองค์กร เพื่อให้แน่ใจว่าซอฟต์แวร์ใหม่จะทำงานร่วมกันได้อย่างเข้ากันได้กับระบบที่มีอยู่เดิม
- การทดสอบและตรวจสอบภายในองค์กร (Internal Testing and Validation)
- สภาพแวดล้อมจำลอง (Sandbox Environment) : ใช้สภาพแวดล้อมแยกทดสอบหรือระบบจำลองที่เหมือนกับระบบจริง เพื่อทดสอบการอัปเดตอย่างละเอียดก่อนนำไปใช้กับระบบที่ใช้งานจริง
- การทดสอบอัตโนมัติ (Automated Testing): ใช้วิธีการทดสอบอัตโนมัติเพื่อตรวจสอบความสมบูรณ์และความเข้ากันได้ของการอัปเดตอย่างรวดเร็วและมีประสิทธิภาพ
- การแจ้งเตือนและการเปิดเผยข้อมูลอย่างครบถ้วนเกี่ยวกับการอัปเดต เพื่อให้ผู้ใช้งานเข้าใจ และเตรียมพร้อมรับมือกับการเปลี่ยนแปลงที่จะเกิดขึ้น (Update Notifications and Transparency)
- การแจ้งเตือนล่วงหน้าก่อนการอัปเดต (Pre-Update Notifications): ตรวจสอบให้แน่ใจว่าองค์กรของคุณได้รับแจ้งเตือนการอัปเดต และคำแนะนำในการเตรียมตัวจาก CrowdStrike เพื่อรับทราบข้อมูลสำคัญเกี่ยวกับการอัปเดตเวอร์ชั่นล่าสุด และผลกระทบที่อาจเกิดขึ้น
- รายละเอียดบันทึกการอัปเดต (Detailed Release Notes): ตรวจสอบรายละเอียดบันทึกการอัปเดตของ CrowdStrike เพื่อทำความเข้าใจขอบเขตและการเปลี่ยนแปลงทั้งหมดที่อยู่ในเวอร์ชันใหม่
- แผนตอบสนองต่อเหตุการณ์ที่มีประสิทธิภาพ (Robust Incident Response Plan)
- การเตรียมความพร้อม (Preparedness): พัฒนาหรืออัปเดตแผนการตอบสนองต่อเหตุการณ์ที่ครอบคลุม ซึ่งรวมถึงขั้นตอนในการย้อนกลับการอัปเดตอย่างรวดเร็วหากเกิดปัญหา กำหนดบทบาทและความรับผิดชอบอย่างชัดเจน
- การฝึกซ้อมเป็นประจำ (Regular Drills): ดำเนินการฝึกซ้อมอย่างสม่ำเสมอ เพื่อให้มั่นใจว่าทีมงานพร้อมรับมือกับเหตุการณ์ที่ไม่คาดคิดได้อย่างรวดเร็วและมีประสิทธิภาพ ซึ่งเราเพิ่งผ่านการฝึกซ้อมด้วยกันมาแล้ว จากเหตุการณ์นี้ 🙂
บริษัท ไซเบอร์ อีลีท ขอให้คำยืนยันกับลูกค้าที่ใช้บริการ Managed Security Service ของเราว่า เราจะยืนเคียงข้าง ให้คำปรึกษา แก้ไข และทำทุกอย่างเพื่อประโยชน์สูงสุดของท่านอย่างเต็มความสามารถ
When we stand together, we can be more resilient.
References:
อ้างอิง 1 https://www.youtube.com/watch?v=lHGH07iPASw
อ้างอิง 2 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf
อ้างอิง 3 https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/
อ้างอิง 4 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1r1.pdf
#CyberElite #CyberResilience #NIST #CrowdStrike #BlueScreenOfDead #BSOD
