ความปลอดภัยของ AI ไม่ได้พัง แต่เรากำลังป้องกันสิ่งที่ไม่ถูกต้อง

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

เข้าไปในห้องรีวิวความปลอดภัยขององค์กรใดๆ วันนี้ และคุณจะได้ยินลำดับความสำคัญเดียวกัน: การรักษาความปลอดภัยของโมเดล AI, การปกป้องข้อมูลการฝึกอบรม, การตรวจสอบเอาท์พุต และการนำ AI ที่มีพลังมาใช้ Vendors กำลังรีบขายเครื่องมือ “ความปลอดภัยของ AI” ที่มุ่งเน้นไปที่การควบคุมระดับโมเดลเท่านั้น เช่น การป้องกันการฉีดคำสั่งและการตรวจสอบโมเดล

แต่ผู้โจมตีกำลังใช้การผสมผสาน AI ของคุณเป็นทางหลวงเข้าสู่ทุกสิ่ง

พื้นที่โจมตีที่ไม่มีใครดู

รูปแบบหนึ่งที่เราเห็นอย่างต่อเนื่องในองค์กรต่างๆ บอกเล่าเรื่องราวที่น่าห่วงของทีมความปลอดภัยที่ลงทุนอย่างมากในการรักษาความปลอดภัยของสภาพแวดล้อมการพัฒนา AI: การควบคุมการเข้าถึงโมเดล, การจัดการข้อมูล, การรักษาความปลอดภัยของ MLOps ซึ่งให้ความมั่นใจเท็จว่า AI ของพวกเขานั้น “ล็อคแล้ว”

แต่เมื่อคุณทำการแมปพื้นที่โจมตีจริงๆ คุณจะเห็นว่า AI ชัตบอทมักจะถือโทเค็น OAuth ไปยังแพลตฟอร์ม SaaS หลายๆ แพลตฟอร์ม, คีย์ API ที่มีสิทธิ์การใช้งานคลาวด์ที่มากเกินไป และความสัมพันธ์ความไว้วางใจที่สามารถสร้างเส้นทางตรงจากการฉีดคำสั่งไปยังโครงสร้างพื้นฐานการผลิต โมเดลอาจมีความปลอดภัย แต่ระบบนิเวศที่พวกมันอยู่นั้น thườngเปิดกว้าง และสิ่งนี้ไม่ใช่กรณี ngoại lệ

องค์กรใช้แอปพลิเคชัน SaaS มากกว่า 130 รายการ โดยมีการผสมผสาน AI ที่ครอบคลุมผู้ให้บริการอัตลักษณ์, โครงสร้างพื้นฐานคลาวด์, ฐานข้อมูล และระบบธุรกิจที่สำคัญ การผสมผสานแต่ละครั้งเป็นเส้นทางโจมตีที่อาจเกิดขึ้น และการเชื่อมต่อ API แต่ละครั้งเป็นขอบเขตความไว้วางใจที่ผู้โจมตีกำลังตรวจสอบอย่างแข็งขัน

ปัญหาไม่ใช่ว่าเครื่องมือความปลอดภัยของ AI ของเราพัง แต่เรากำลังรักษาความปลอดภัยของส่วนประกอบแต่ละอย่าง ในขณะที่ผู้โจมตีกำลังใช้ประโยชน์จากความเชื่อมต่อระหว่างพวกมัน

ทำไมความปลอดภัยที่มุ่งเน้นโมเดลจึงพลาดเป้า

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

พิจารณาการใช้งาน AI ทั่วไปในองค์กร คุณมีเอเย่นต์ AI ที่มีการเข้าถึง Google Workspace มันเชื่อมต่อกับ Salesforce (CRM ) ผ่าน API มันผสมผสานกับ Slack สำหรับการแจ้งเตือน มันดึงข้อมูลจาก AWS S3 มันถูกยืนยันตัวตนผ่าน Okta หรือ Azure AD มันเรียกใช้การทำงานใน ServiceNow

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

การโจมตีไม่ได้เริ่มต้นหรือสิ้นสุดด้วยโมเดล AI โมเดลเป็นเพียงจุดเริ่มต้น

เส้นทางโจมตีไม่เคารพขอบเขตผลิตภัณฑ์

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

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

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

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

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

ความจำเป็นในการจัดการการเปิดเผย

สิ่งนี้ทำให้การอภิปรายต้องเปลี่ยนจาก “ความปลอดภัยของ AI” ไปเป็นการบริหารจัดการการเปิดเผยภัยคุกคามอย่างต่อเนื่องสำหรับสภาพแวดล้อมที่มีการผสมผสาน AI

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

โปรแกรมความปลอดภัยส่วนใหญ่ยังคงจัดลำดับความสำคัญของความเสี่ยงในแยกกัน โดยใช้คะแนน CVSS และรายการตรวจสอบการปฏิบัติตามข้อกำหนดที่เพิกเฉยต่อความเสี่ยงในการโจมตีจริงในระบบของคุณ

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

ความปลอดภัยที่ตระหนักถึงเส้นทางโจมตีเป็นอย่างไร

การรักษาความปลอดภัยของ AI ในการผลิตต้องใช้แนวทางที่แตกต่างอย่างพื้นฐาน และมันลงมาถึงการเปลี่ยนแปลงความคิดสี่ประการ

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

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

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

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

คำเตือนซึ่งเราไม่สามารถเพิกเฉยได้

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

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

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

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