אבטחת AI אינה שבורה, אנחנו רק מגינים על הדברים הלא נכונים

תעשיית האבטחה הסייברית היא בעלת דפוס כאשר טכנולוגיה חדשה מופיעה, אנו מיד מתחילים לבנות חומות סביבה. עשינו זאת עם ענן, עשינו זאת עם קונטיינרים, ועכשיו, אנו עושים זאת עם AI, למעט שהפעם, החומות שאנו בונים נמצאות במקומות לגמרי לא נכונים.

צעדו לסקירת אבטחה של כל תאגיד היום, ותשמעו את אותם עדיפויות: הגנה על מודלי AI, הגנה על נתוני אימון, אימות פלטים, ופריסה של טייסים משותפים AI. ספקים ממריאים למכור “כלים לאבטחת AI” המתמקדים באופן בלעדי בבקרות ברמת המודל, כגון מעקות, הגנות על הזרקת פרומפטים, ופלטפורמות לניטור מודלים.

אבל התוקפים משתמשים באינטגרציות ה-AI שלכם ככבישים לכל דבר אחר.

פני התקפה אמיתיים שאיש אינו צופה

דפוס אחד שאנו צופים בו באופן עקבי בסביבות תאגידיות מספר סיפור מדאיג על צוותי אבטחה המשקיעים רבות באבטחת סביבות פיתוח ה-AI שלהם: בקרות גישה למודל, מסגרות ניהול נתונים, כלים לאבטחת MLOps. זה נותן ביטחון שווא ש-AI שלהם “נעול”.

אבל כאשר אתה ממפים את פני התקפה האמיתיים, אתה רואה שבוטים AI לעיתים קרובות מחזיקים את אותן טוקנים OAuth לעשרות פלטפורמות SaaS, מפתחות API עם הרשאות עודפות בענן, ויחסי אמון זהות שיכולים ליצור נתיבים ישרים מהזרקת פרומפט פשוטה לתשתית ייצור. המודלים עצמם עשויים להיות בטוחים, אבל המערכות שהם חיים בהן לעיתים קרובות פתוחות לגמרי, וזה לא מקרה קצה.

תאגידים כיום משתמשים בממוצע ב-130+ יישומי SaaS, עם אינטגרציות AI המשתרעות על ספקי זהות, תשתית ענן, בסיסי נתונים ומערכות עסקיות ביקריתיות. כל אינטגרציה היא נתיב התקפה פוטנציאלי, וכל חיבור API הוא גבול אמון שתוקפים בודקים באופן פעיל.

הבעיה אינה שכלינו לאבטחת AI שבורים. זה שאנו מגינים על רכיבים בודדים בעוד שתוקפים מנצלים את החיבורים ביניהם.

למה ביטחון מודל-מרכזי מחמיץ את הנקודה

הגישה הנוכחית לאבטחת AI פועלת על בסיס אי-הבנה בסיסית של איך תקיפות מודרניות עובדות. אנו מתייחסים ל-AI כאל נכס עצמאי שזקוק להגנה, בדומה לאיך אנו מגינים על בסיס נתונים או יישום וеб. אבל AI בייצור לא קיים בבידוד. הוא צומת בגרף מורכב של זהויות, הרשאות, API וזרימות נתונים.

תחשבו על פריסת AI טיפוסית של תאגיד. יש לכם סוכן AI עם גישה ל-Google Workspace שלכם. הוא מחובר ל-Salesforce דרך API. הוא משולב עם Slack להתראות. הוא מושך נתונים מ-ארגזי S3 של AWS. הוא מאומת דרך 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. הם רק מקווים שהחומות שהם בנו נמצאות במקומות הנכונים.