การพัฒนาแอปพลิเคชั่นที่มีกำหนดส่งชัดเจน แต่เราไม่ชัดว่าจะแก้ช่องโหว่ที่ไม่รู้ว่าจะเจอกี่มากน้อยกันได้ทัน สุดท้ายผลออกมาก็ต้องหาวิธียอมรับความเสี่ยงที่ลูกค้าปลายทางไม่น่าพอใจเท่าไร จะดีกว่าไหมถ้าทีมพัฒนามองเห็นความเสี่ยงเหล่านี้ตั้งแต่ตอนออกแบบ แล้วหาทางอุดช่องโหว่ตั้งแต่แรก โดยเฉพาะยุค AI ที่แอปก็ต้องใช้ AI ที่โลกความเสี่ยงเปลี่ยนไปจากเดิมจากหน้ามือเป็นหลังมือ แบบยังไม่นับความคาดหวังความเร็วสูงมากแบบยุคนี้ครับ?
ในสภาพแวดล้อมการพัฒนาระบบที่ต้องเร่งส่งมอบให้ทันความต้องการทางธุรกิจ หลายองค์กรให้ความสำคัญกับการทดสอบเชิงฟังก์ชัน (QA Testing) เพื่อให้ระบบสามารถใช้งานได้ตามกำหนดเวลา แต่กลับลดน้ำหนักของการออกแบบด้านความปลอดภัยลงอย่างมีนัยสำคัญ ผลลัพธ์ที่เกิดขึ้นคือ แม้ระบบจะผ่านการทดสอบการใช้งานได้ครบถ้วน แต่เมื่อเข้าสู่กระบวนการทดสอบเชิงลึกอย่าง Penetration Testing กลับพบช่องโหว่ระดับวิกฤตจำนวนมาก และในหลายกรณี ทีมพัฒนาจำเป็นต้องเลือกระหว่างการแก้ไขที่มีผลกระทบต่อโครงสร้างระบบกับการยอมรับความเสี่ยงในเชิงธุรกิจ สถานการณ์ลักษณะนี้สะท้อนให้เห็นว่าปัญหาไม่ได้เกิดจากการขาดเครื่องมือ แต่เกิดจากการขาดกระบวนการคิดด้านความปลอดภัยตั้งแต่ช่วงเริ่มต้นของการออกแบบครับ
แนวคิด Shift Left Security จึงไม่ควรถูกตีความว่าเป็นเพียงการนำเครื่องมือด้านความปลอดภัยไปวางไว้ในกระบวนการ CI/CD เท่านั้น แต่ควรหมายถึงการยกระดับความสามารถของทีมพัฒนาให้สามารถพิจารณาภัยคุกคามได้ตั้งแต่ระดับ Architecture โดยเครื่องมือสำคัญในบริบทนี้คือ Threat Modeling ซึ่งหากดำเนินการอย่างถูกต้อง จะช่วยให้ทีมมองเห็นความเสี่ยงก่อนที่โค้ดจะถูกพัฒนา จุดตั้งต้นที่มีประสิทธิภาพคือการวิเคราะห์ Data Flow Diagram (DFD) โดยให้ความสำคัญกับเส้นทางการไหลของข้อมูล และโดยเฉพาะอย่างยิ่งจุดที่ข้อมูลตัดผ่าน Trust Boundary เนื่องจากช่องโหว่ที่มีผลกระทบสูงมักเกิดขึ้น ณ จุดที่ระบบ “ให้ความเชื่อถือ” กับข้อมูลหรือคำสั่งโดยไม่ได้รับการตรวจสอบอย่างเหมาะสม
เพื่อให้การวิเคราะห์มีโครงสร้างที่ชัดเจน องค์กรสามารถประยุกต์ใช้ Framework หลายรูปแบบร่วมกัน โดย STRIDE ใช้สำหรับการระบุประเภทของภัยคุกคาม DREAD สำหรับการจัดลำดับความเสี่ยง PASTA สำหรับการวิเคราะห์เชิงกระบวนการ และ OCTAVE สำหรับเชื่อมโยงความเสี่ยงในระดับธุรกิจ อย่างไรก็ตาม ในเชิงปฏิบัติ STRIDE มักเป็นจุดเริ่มต้นที่เหมาะสม เนื่องจากสามารถนำไปใช้ได้ทันทีและช่วยให้ทีมไม่มองข้ามภัยคุกคามพื้นฐานที่สำคัญ ไม่ว่าจะเป็นการปลอมแปลงตัวตน การแก้ไขข้อมูล การเปิดเผยข้อมูลโดยไม่ได้รับอนุญาต การปฏิเสธความรับผิด หรือการยกระดับสิทธิ์ ทั้งหมดนี้สามารถวิเคราะห์ได้โดยตรงจาก Data Flow ที่ออกแบบไว้ตั้งแต่ต้น
ในบริบทของระบบสมัยใหม่ที่มีการนำ AI และ LLM เข้ามาใช้งาน ความซับซ้อนของ Trust Boundary เพิ่มขึ้นอย่างมีนัยสำคัญ เนื่องจากระบบเริ่มมีลักษณะที่คำสั่งและข้อมูลไม่สามารถแยกออกจากกันได้อย่างชัดเจน ส่งผลให้ Framework แบบดั้งเดิมอาจไม่ครอบคลุมภัยคุกคามทั้งหมดที่เกิดขึ้นในระบบลักษณะนี้ แนวคิด ASTRIDE จึงถูกนำมาใช้ต่อยอดจาก STRIDE เพื่อรองรับความเสี่ยงเฉพาะของระบบ AI โดยเฉพาะในประเด็นที่เกี่ยวข้องกับการที่ระบบหรือ Agent ถูกชักจูงให้ใช้อำนาจของตนในทางที่ไม่เหมาะสม การปนเปื้อนของบริบทที่ทำให้โมเดลตีความข้อมูลผิดพลาด รวมถึงการละเมิดขอบเขตความเชื่อถือจากการที่ระบบยอมรับคำสั่งจากองค์ประกอบอื่นโดยไม่ได้ผ่านการตรวจสอบในฐานะข้อมูลที่ไม่เชื่อถือ
ยกตัวอย่าง ASTRIDE ของทาง Daybrake Security อันนี้ครับผม
https://daybreaksec.com/blog/astride-threat-modeling-framework/
https://github.com/DaybreakSec/ASTRIDE
เพราะระบบ AI โดยเฉพาะ LLM, Agent, และ Automation ทำให้ Trust Boundary ซับซ้อนขึ้นอย่างมาก เพราะ “คำสั่ง” และ “ข้อมูล” เริ่มแยกไม่ออก ทาง Daybrake เลยต่อยอดประเภทความเสี่ยงอันตรายจาก STRIDE เพิ่มอีกเป็น CCT ได้แก่
1. Confused Deputy ที่ใช้สิทธิ์ของ AI เป้าหมายให้เป็นประโยชน์มากกว่าการบริการผู้ใช้ปกติ เช่น การพร้อมพ์โดยตรงหรืออ้อมให้เข้าไปอ่านข้อมูลความลับมาตอบ ที่เราต้องเข้มงวดกับการทำ Least Privilege ตัว AI พร้อมๆ กับการทำ Rule-based Input Validation
2. Context Pollution ที่โดน Prompt Injection จากช่องทางที่เราไม่ได้อุดช่องโหว่ไว้เพราะมองว่าเป็นช่องทางป้อนข้อมูลเข้าที่น่าไว้ใจ ส่วนใหญ่เป็นข้อมูลจากทางอ้อม (eXternal Prompt Injection Attack; XPIA) เช่น จาก RAG หรือเว็บไซต์กับเอกสารที่ไปเสิร์ชมา ซึ่งถ้าเราทำ Threat Modelling แล้วขีดเส้นที่มาของ Context ทั้งหมดนี้ว่าเป็น Untrust ก็จะจัดการกรองอินพุตป้องกันอันตรายได้อย่างครอบคลุม รวมถึงกรองเอาต์พุตขาออกจากโมเดลก่อนสั่งไปยังทูลหรือ MCP Server อื่นๆ ไม่ให้ไปทำอันตรายได้ด้วย
3. Trust Boundary Violation การที่เราไม่ขีดเส้น Trust Boundary ให้ดี ไว้ใจองค์ประกอบภายในระบบของเราเองมากเกินไป ไม่ได้ใช้หลัก Zero Trust แม้จะเป็นระบบ AI เช่น Multi-Agent ที่ไปเชื่อถือการเชื่อมต่อจาก Agent ด้วยกันในฐานะคำสั่ง (Instruction) โดยตรง แทนที่จะมองเป็น Data หนึ่งที่มีสิทธิ์ถูกปนเปื้อน (Polluted หรือ Poisoned) ที่เราก็ต้องกรองอันตรายออกก่อนเช่นกัน ไม่ให้เกิดช่องโหว่เหมือน SSRF ระหว่างเว็บเซิร์ฟเวอร์กับเซิร์ฟเวอร์ภายในอื่นที่เราพบเห็นจากเว็บแอปพลิเคชั่นทั่วไป
ประเด็นสำคัญที่พบได้บ่อยในระบบ AI คือการปฏิบัติต่อผลลัพธ์ของโมเดลเสมือนเป็นคำสั่งที่เชื่อถือได้ ทั้งที่ในทางปฏิบัติควรถูกจัดการในฐานะข้อมูลที่ต้องผ่านกระบวนการตรวจสอบก่อนเสมอ เช่นเดียวกับข้อมูลจากผู้ใช้หรือระบบภายนอก การออกแบบที่ไม่แยกแยะประเด็นนี้อย่างชัดเจนมักนำไปสู่ช่องโหว่ที่มีความซับซ้อนและตรวจพบได้ยาก อีกทั้งยังอาจส่งผลกระทบในระดับธุรกิจโดยตรงหากระบบถูกนำไปใช้ในกระบวนการสำคัญ
เราเข้าใจดีว่า องค์กรมีทรัพยากรจำกัดในการจัดการความเสี่ยง แก้ไขช่องโหว่ แต่การวางแผนทำ Threat Modelling ให้ดี นอกจากช่วยลดโอกาสในการเจอช่องโหว่จำนวนมากตอนทำ Prentest ที่ต้องแก้ไขเพื่อ Release Change ก่อน Go Live แล้ว ยังช่วยจัดลำดับความรุนแรงของความเสี่ยง ให้เราทุ่มทรัพยากรกับการแก้ไขจุดที่มีความเสี่ยงสูงสุดลงมาตามลำดับ แล้วหา Compensation Mitigation Control มาทดแทนควบคุมความเสี่ยงในจุดที่ความเสี่ยงยังอยู่ในระดับที่ยอมรับได้ขององค์กร (Risk Acceptance) ได้ดีขึ้น เป็นที่ยอมรับของผู้ตรวจสอบ (Auditor หรือ 2nd Line Compliance) มากกว่าด้วยครับ
องค์กรที่ให้ความสำคัญกับ Threat Modeling ตั้งแต่ระยะออกแบบจะสามารถลดจำนวนช่องโหว่ระดับวิกฤตในช่วงท้ายของโครงการได้อย่างมีนัยสำคัญ ลดต้นทุนในการแก้ไขที่มักเพิ่มขึ้นแบบทวีคูณเมื่อเข้าสู่ระยะ Production และลดความขัดแย้งระหว่างทีมพัฒนา ทีมความปลอดภัย และฝ่ายธุรกิจ โดยเปลี่ยนบทบาทของการทดสอบเชิงรุกจากการค้นหาปัญหาในช่วงท้าย มาเป็นการยืนยันคุณภาพของการออกแบบที่ได้วางรากฐานไว้อย่างเหมาะสมตั้งแต่ต้น
WHITEHAT 8 ให้ความสำคัญกับการสร้างความปลอดภัยตั้งแต่ระดับ Design โดยให้บริการทั้งด้าน Threat Modeling ที่สามารถนำไปใช้ได้จริงในบริบทขององค์กร และการทดสอบเชิงลึกตามมาตรฐานสากล เพื่อให้มั่นใจว่าระบบไม่ได้เพียงปลอดภัยในเชิงทฤษฎี แต่สามารถรับมือกับสถานการณ์จริงได้อย่างมีประสิทธิภาพ แนวทางดังกล่าวช่วยให้องค์กรสามารถขับเคลื่อนการพัฒนาได้อย่างมั่นใจ โดยไม่ต้องเผชิญกับความเสี่ยงที่ซ่อนอยู่ในช่วงท้ายของโครงการ
Effective Security that’s ALWAYS ON ต้องเริ่มตั้งแต่การออกแบบ ไม่ใช่วันที่เริ่มทำการทดสอบครับผม
#WH8
#WHITEHAT8
#EffectiveSecurityThatsALWAYSON
