ความปลอดภัยของ 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 ผ่าน 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 ไม่ถูกต้อง พวกเขากำลังหวังว่ากำแพงที่พวกเขากำลังสร้างอยู่ในตำแหน่งที่ถูกต้อง