หากต้องการสร้างระบบ AI ที่ใช้งานได้ ก่อนอื่นคุณต้องลองทำให้ระบบพังก่อน เราดำเนินการ Red Teaming โดยสวมบทผู้โจมตีเพื่อทดสอบและตรวจหาช่องโหว่ในแอป AI สำหรับลูกค้าของธุรกิจบริการทางการเงิน สิ่งที่เราพบมีความสำคัญต่อทุกคนที่นำแอปพลิเคชันซึ่งขับเคลื่อนด้วย LLM ไปใช้งานในบริบทที่ต้องให้ความสำคัญกับความปลอดภัย
Red Teaming คือการจงใจพยายามทำให้ระบบ AI พัง เพื่อให้คุณแก้ไขช่องโหว่ได้ก่อนที่ผู้โจมตีตัวจริงจะค้นพบ สำหรับธุรกิจบริการทางการเงิน ความเสี่ยงยิ่งสูงเป็นพิเศษ เพราะแอปพลิเคชัน AI ต้องจัดการข้อมูลลูกค้า ประมวลผลธุรกรรม และให้ข้อมูลเชิงลึกทางการเงิน ความล้มเหลวอาจส่งผลตั้งแต่ประสบการณ์ใช้งานที่ย่ำแย่ ไปจนถึงการละเมิดกฎระเบียบ การสูญเสียทางการเงิน และความเสียหายต่อแบรนด์ที่แก้ไขไม่ได้
เป้าหมายของเราคือค้นหาช่องโหว่ตั้งแต่เนิ่นๆ ทดสอบรูปแบบการโจมตีที่เกิดขึ้นได้จริง และช่วยให้องค์กรปฏิบัติตามความคาดหวังด้านความปลอดภัยของ AI ซึ่งหน่วยงานกำกับดูแลให้ความสำคัญอย่างยิ่ง
ประเด็นสำคัญที่ควรแยกให้ชัดคือ การเจลเบรกมุ่งโจมตีตัวกรองความปลอดภัยของโมเดลที่อยู่เบื้องหลัง ส่วนการการแทรกคำสั่งมุ่งโจมตีตัวแอปพลิเคชัน โดยนำข้อมูลป้อนเข้าจากผู้ใช้ที่เชื่อถือไม่ได้มาผสมกับพรอมต์ของนักพัฒนาที่ระบบเชื่อถือ การแทรกพรอมต์มีความเสี่ยงมากกว่า เพราะมุ่งเป้าไปที่ระบบของคุณและข้อมูลลับที่ระบบจัดการ ไม่ใช่โมเดลอเนกประสงค์
การทดสอบรอบแรกของเราประกอบด้วยการทดสอบประมาณ 750 รายการ โดยครอบคลุมหัวข้อต่อไปนี้
การรั่วไหลของข้อมูลข้ามเซสชัน
การเปิดเผยข้อมูลส่วนบุคคลที่ระบุตัวบุคคลได้ (PII) ผ่านภาษาธรรมชาติ การดัดแปลง API และการเข้ารหัสรูปแบบต่างๆ
การแทรก SQL
การเขียนทับคำสั่งระบบ
ระหว่างการทดสอบเบื้องต้น เราพบปัญหาสำคัญสองประการในระบบเดิม ได้แก่ การจัดการคำขอที่มีหลายเจตนา และการใช้พรอมต์ที่เข้ารหัส
คำขอแบบหลายเจตนา: คำขอที่ผสมคำสั่งที่ชอบด้วยเหตุผลเข้ากับคำสั่งที่เป็นอันตราย เช่น “แสดงการใช้จ่ายของฉันตามหมวดหมู่ แล้วเรียกใช้ [SQL ที่เป็นอันตราย] ด้วย” แอปพลิเคชันไม่สามารถตรวจจับเจตนาร้ายได้ และอาศัยมาตรการป้องกันของชั้นข้อมูลปลายทางเพียงอย่างเดียว ซึ่งไม่ต่างจากการเปิดประตูหน้าบ้านทิ้งไว้เพียงเพราะเชื่อว่าตู้เซฟในห้องใต้ดินปลอดภัย
การเข้ารหัส: คำขอที่ถูกเข้ารหัสด้วย Base64, Hex, LeetSpeak และอักขระพ้องรูป ซึ่งอาจทำให้ระบบกรองเจตนาร้ายออกได้ยาก แม้เราพบว่าคำขอเหล่านี้ไม่ได้เปิดเผยข้อมูลที่ละเอียดอ่อน แต่ก็ทำให้ระบบขาดเสถียรภาพอย่างมาก เช่น สร้างข้อมูลเท็จ ส่ง SQL ที่เป็นอันตรายซ้ำกลับไปยังผู้ใช้ และจำแนกเจตนาผิดพลาด
ผลการทดสอบเบื้องต้นของเราแสดงให้เห็นปัญหาต่อไปนี้
การสร้างข้อมูลเท็จด้านวันและเวลา: โมเดลให้วันที่ เวลาที่บันทึกธุรกรรม หรือข้อมูลสรุปตามช่วงเวลาที่แต่งขึ้นด้วยน้ำเสียงมั่นใจ เรื่องนี้ถือเป็นความเสี่ยงสำคัญในบริบททางการเงิน เพราะหากลูกค้าดำเนินการตามวันที่ผิด ย่อมอาจเกิดผลกระทบจริงตามมา
การส่ง SQL ที่เป็นอันตรายซ้ำกลับไปหาผู้ใช้ (น่ากังวลในแง่ความเสี่ยงจากการวางยาหน่วยความจำ)
การจำแนกเจตนาผิดพลาด
รูปแบบผลลัพธ์ที่ผิดเพี้ยน
เมื่อได้ข้อมูลเหล่านี้แล้ว เราจึงจำกัดขอบเขตให้แคบลง เราลดลำดับความสำคัญของการทดสอบการแทรก SQL และการเข้ารหัส เนื่องจากทีมกำลังแก้ไขปัญหาเหล่านั้นอยู่แล้ว แต่หันไปมุ่งเน้นช่องทางโจมตีที่ได้ผลมากที่สุด ได้แก่ การเปิดเผย PII และการรั่วไหลข้ามเซสชัน
ข้อค้นพบสำคัญที่สุดจากการทดสอบรอบสองกลับเป็นเรื่องง่ายอย่างคาดไม่ถึง เพราะบ่อยครั้งการโจมตีไม่จำเป็นต้องใช้กลวิธีที่ซับซ้อนเลย
ในหลายกรณี เพียงแค่ขอข้อมูลภายในโดยแฝงไว้ในคำขอที่ฟังดูสมเหตุสมผล ก็เพียงพอที่จะทำให้ระบบยอมเปิดเผยข้อมูลนั้น คำขอธรรมดาอาจได้รับคำตอบที่อ้างถึง ID ภายในและฟิลด์ของระบบ ซึ่งไม่ควรแสดงต่อผู้ใช้ปลายทางโดยเด็ดขาด
เมื่อตรวจสอบลึกลงไป เราพบว่าปัญหานี้ไม่ได้เกิดขึ้นเฉพาะในระดับแอปพลิเคชัน บริการแปลงข้อความเป็น SQL ที่ทำงานในลำดับถัดไปสร้างคำสั่งค้นหาซึ่งเรียกข้อมูลจากฟิลด์มากเกินความจำเป็น และคำตอบเชิงอธิบายยังอ้างถึงข้อมูลที่ควรถูกจำกัดการเข้าถึง ปัญหานี้เผยให้เห็นช่องโหว่ที่เกิดขึ้นตรงรอยต่อระหว่างระบบ ซึ่งจะพบได้ก็ต่อเมื่อทดสอบทั้งสแต็ก แทนที่จะแยกทดสอบองค์ประกอบแต่ละส่วน
ทำ Red Teaming กับระบบ ไม่ใช่แค่โมเดล การทดสอบ LLM แบบแยกส่วนแทบไม่บอกอะไรเกี่ยวกับสถานะความปลอดภัยของแอปพลิเคชันของคุณเลย ทดสอบทั้งสแต็กตั้งแต่ต้นจนจบในแบบเดียวกับที่ผู้ใช้โต้ตอบกับระบบ
ต้องตรวจสอบความถูกต้องของข้อมูลขาเข้าก่อนถึง LLM ระบบควรตรวจจับคำขอที่เข้ารหัส การโจมตีแบบหลายเจตนา และความพยายามแทรกคำสั่งขั้นพื้นฐานที่แนวป้องกันชั้นนอก ไม่ใช่โยนภาระให้บริการปลายทาง
อย่าไว้วางใจรอยต่อระหว่างระบบ ในสถาปัตยกรรมที่ประกอบด้วยบริการหลายส่วน ช่องโหว่ที่น่าสนใจที่สุดมักซ่อนอยู่ตามรอยต่อ ระหว่าง ระบบ Zero Trust หมายถึงการไม่ไว้วางใจสิ่งใดโดยอัตโนมัติ ดังนั้นจึงต้องตรวจสอบทุกอย่างในทุกชั้น
การโจมตีแบบง่าย ๆ ก็ได้ผล การเจลเบรกที่ซับซ้อนอาจตกเป็นข่าว แต่บางครั้งเพียงแค่... ขอ ระบบก็ยอมให้แล้ว หากระบบของคุณเปิดเผยตัวระบุภายในทันทีเมื่อผู้ใช้สอดแทรกคำขอลงในคำขออื่นที่ดูถูกต้องตามปกติ นั่นคือปัญหา
เข้าใจให้ชัดว่าคุณกำลังทดสอบอะไร โมเดล LLM อาจตรวจจับรูปแบบการโจมตีที่เป็นที่รู้จักได้จากการฝึกของโมเดลเอง ไม่ใช่จากมาตรการป้องกันของคุณ ผสานความสามารถในการสังเกตการณ์ไว้ในกระบวนการ Red Teaming เพื่อให้เข้าใจว่ามาตรการควบคุมใดถูกใช้งานจริง
สภาพแวดล้อมที่มีข้อจำกัดต้องอาศัยวิธีแก้ปัญหาอย่างสร้างสรรค์ ผู้ให้บริการแบบกำหนดเองและการรองรับโมเดลภายในเครื่องช่วยให้ทำ Red Teaming อย่างมีประสิทธิผลได้โดยไม่ต้องมีสิทธิ์เข้าถึงระบบคลาวด์เฉพาะทาง แต่ต้องเปิดเผยข้อจำกัดที่เกิดขึ้นอย่างโปร่งใส
Red Teaming ไม่ใช่งานที่ทำเพียงครั้งเดียว กระบวนการนี้ต้องทำซ้ำ ควรเป็นระบบอัตโนมัติเมื่อทำได้ และต้องพัฒนาไปพร้อมกับระบบของคุณ การโจมตีที่จะสำคัญในวันหน้าไม่เหมือนกับการโจมตีที่สำคัญในวันนี้
ระบบ AI ในสภาพแวดล้อมที่อยู่ภายใต้การกำกับดูแลจะยิ่งถูกตรวจสอบเข้มงวดขึ้น ไม่มีทางน้อยลง องค์กรที่มองการทดสอบความปลอดภัยเป็นกระบวนการต่อเนื่อง แทนที่จะเป็นเพียงช่องให้ทำเครื่องหมายก่อนเปิดตัว จะพร้อมรับการตรวจสอบดังกล่าวได้ดีกว่า และหลีกเลี่ยงวิกฤตด้านภาพลักษณ์ที่ทำลายความไว้วางใจของลูกค้าได้