Schrödinger’s Misconfigurations

บ่ายวันพฤหัสบดี คุณกำลังเตรียมตัวกลับบ้านเร็วกว่าปกติสักหน่อย เพราะ... ก็ทำได้นี่นา แต่แล้วเจ้าตัวป่วนผู้ส่งการแจ้งเตือน (หรือที่รู้จักกันในชื่อ Slack) ก็เด้งข้อความใหม่ขึ้นมาในแชนเนล security alerts ของคุณ:

แย่แล้วสิ มีคนเพิ่งเปิด snapshot ของ storage volume ให้เป็นสาธารณะ นี่คือการโจมตีหรือเปล่า หรือเป็นความผิดพลาด หรือเป็นคนที่ไม่รู้ว่านโยบายกำหนดไว้อย่างไร

Misconfiguration มีสถานะอยู่สามแบบพร้อมกัน

นี่คือสิ่งที่ผมเริ่มเรียกว่า Schröedinger’s Misconfigurations เพราะผมมีนิสัยเสียในการหยิบหลักการของกลศาสตร์ควอนตัมมาอธิบายเรื่อง information security ผมคงแปลกใจมากหากคุณยังไม่เคยได้ยินเรื่องแมวของชเรอดิงเงอร์ ซึ่งเป็นการทดลองทางความคิดอันโด่งดังที่ Erwin Shröedinger ใช้อธิบายความย้อนแย้งของการซ้อนทับเชิงควอนตัมให้ Albert Einstein ฟัง กล่าวโดยย่อที่สุดคือ หากคุณขังแมวไว้ในกล่องพร้อมกับยาพิษที่ถูกกระตุ้นด้วยการสลายตัวของสารกัมมันตรังสี แมวตัวนั้นจะไม่ได้มีชีวิตอยู่และไม่ได้ตาย แต่อยู่ในสถานะที่ทั้งเป็นและตายไปพร้อมกัน จนกว่าคุณจะเปิดกล่องออกมาดู

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

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

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

คลาวด์มีคุณลักษณะ 5 ประการที่สนับสนุนแนวคิดนี้:

• ทีมคลาวด์/นักพัฒนามักมีอิสระในการบริหารจัดการ cloud infrastructure ของตนเองโดยตรงมากกว่า
• cloud management plane เข้าถึงได้ผ่านอินเทอร์เน็ต
• ต้นตอของการโจมตีบนคลาวด์ที่พบบ่อยที่สุด (ในปัจจุบัน) คือ credentials ที่ถูกขโมย
• misconfiguration จำนวนมากสร้างสถานะที่เหมือนกับการกระทำของผู้โจมตีทุกประการ (เช่น การเปิด snapshot ให้เป็นสาธารณะ)
• การสร้าง misconfiguration โดยไม่ตั้งใจเกิดขึ้นได้ง่าย และบางครั้งก็เกิดขึ้นโดยตั้งใจเพื่อตอบโจทย์การใช้งานบางอย่าง แต่ผู้ที่ลงมือทำไม่รู้ตัวว่านั่นคือปัญหาด้านความปลอดภัย

แนวคิดนี้ใช้ได้กับโครงสร้างพื้นฐานแบบดั้งเดิมเช่นกัน แม้จะในระดับที่น้อยกว่ามาก เพราะทีมงานมีอิสระน้อยกว่า นักพัฒนาที่ดูแลแอปพลิเคชันมักไม่มีสิทธิ์แก้ไข firewall rules และ route tables ได้โดยตรง แต่บนคลาวด์ เรื่องนี้เป็นเรื่องปกติพอสมควร อย่างน้อยก็ในบางสภาพแวดล้อม

สันนิษฐานว่าเป็นการโจมตีไว้ก่อนจนกว่าจะพิสูจน์ได้เป็นอย่างอื่น

หลักการสำคัญประการหนึ่งของ incident response บนคลาวด์คือ คุณต้องปฏิบัติต่อ misconfiguration ในฐานะ security incidents อย่างเด็ดขาด และต้องสันนิษฐานว่าเป็นการโจมตีจนกว่าจะพิสูจน์ได้เป็นอย่างอื่น

นี่คือการเปลี่ยนวิธีคิด เพราะงานด้านความปลอดภัยคุ้นเคยกับการมองในแง่ของช่องโหว่และ attack surface ซึ่งเรามองว่าเป็นสิ่งที่ต้องสแกนเป็นระยะ และโดยส่วนใหญ่ถือเป็นปัญหาที่ต้องทำ remediation ผมเสนอว่าในโลกของ cloud computing เราควรยกระดับ misconfiguration ที่ตรวจพบขึ้นมาอยู่ในระดับเดียวกับการแจ้งเตือนจาก IDS หรือ EDR สิ่งเหล่านี้ไม่ใช่เพียงประเด็นด้าน compliance แต่เป็นตัวบ่งชี้ที่อาจแสดงถึงการถูกบุกรุก

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

เนื่องจากผมต้องสรุปเนื้อหาให้กระชับสำหรับคลาสอบรม ผมจึงแบ่งแหล่งข้อมูล security telemetry ออกเป็นสามแหล่งหลัก:

• Logs
• เหตุการณ์จากผู้ให้บริการคลาวด์ (เช่น Security Hub events)
• misconfiguration บนคลาวด์ ซึ่งอาจมาจากเครื่องมือ CSPM ของคุณ, OSS scanners หรือเครื่องมือลักษณะเดียวกัน

คนส่วนใหญ่ที่ทำงานด้าน cloud security ซึมซับแนวคิดนี้ไปแล้ว เพียงแต่เราไม่ได้อธิบายออกมาเสมอไป หากคุณลองดูเครื่องมือ Cloud Detection and Response (CDR) บางตัว จะเห็นว่ามันสร้างการแจ้งเตือนจาก misconfiguration บางประเภท ซึ่งต่างจากรูปแบบมาตรฐานของเครื่องมือ CSPM ที่สร้าง findings ไว้ในรายงานและบน dashboard สิ่งเหล่านั้นสำคัญต่อ compliance และสุขอนามัยด้านความปลอดภัยโดยรวม แต่เนื่องจากผู้โจมตีทำสิ่งเลวร้ายอย่างการแชร์ disk image ไปยังบัญชีอื่นหรือฝัง backdoor เข้าถึง IAM roles misconfiguration ส่วนหนึ่งจึงจำเป็นต้องได้รับการปฏิบัติเสมือนเป็นตัวบ่งชี้การถูกบุกรุกจนกว่าจะพิสูจน์ได้เป็นอย่างอื่น

ภายในองค์กรของเรา (และบนแพลตฟอร์ม DisruptOps) เราจัดการเรื่องนี้ด้วยชุด real-time threat detectors ที่กระตุ้นการประเมินผลจาก API calls ที่ระบุไว้ ใช้เวลาราว 15-30 วินาทีในการระบุ misconfiguration และส่งต่อไปยังทีมความปลอดภัยและเจ้าของโปรเจกต์ผ่าน Slack (หรือ Teams) อย่างที่เห็นด้านบน การแจ้งเตือนเหล่านี้ได้รับการปฏิบัติเช่นเดียวกับ GuardDuty finding หรือ Indicator of Compromise อื่น ๆ แต่การใช้ ChatOps เพื่อยืนยันกิจกรรมยังช่วยให้เราคัดกรองได้รวดเร็วมาก โดยไม่ต้องวิเคราะห์เชิงลึกทุกครั้ง

สรุปสั้น ๆ: จัดการ misconfiguration สำคัญบนคลาวด์แบบใกล้เคียงเรียลไทม์ และปฏิบัติต่อมันเสมือนเป็นตัวบ่งชี้การถูกบุกรุกจนกว่าจะพิสูจน์ได้เป็นอย่างอื่น

ไม่มีแมวตัวใดได้รับอันตรายระหว่างการเขียนบทความนี้