כיצד בינה מלאכותית משנה את נוף איומי הסייבר

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

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

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

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

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

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

בינה מלאכותית מרחיבה מתקפות קיימות לפני שהיא יוצרת מתקפות חדשות

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

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

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

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

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

ההנדסה החברתית הופכת לאישית ומשכנעת יותר

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

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

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

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

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

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

ניצול חולשות מתרחש מהר יותר

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

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

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

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

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

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

נוזקות ופעילות חדירה הופכות לסתגלניות יותר

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

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

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

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

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

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

הזהות הופכת לנקודת הבקרה המרכזית

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

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

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

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

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

השאלה המרכזית כבר אינה רק "האם המשתמש הזה ביצע אימות?" אלא "האם יש לאפשר לזהות הזו, מהמכשיר הזה ובהקשר הזה, לבצע את הפעולה הזו?"

מערכות AI יוצרות משטח תקיפה חדש

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

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

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

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

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

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

Shadow AI חוזר על בעיית ה-Shadow IT

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

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

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

בקרות טכניות יכולות לתמוך במדיניות באמצעות Single Sign-On, חשבונות מנוהלים, מניעת דלף מידע, בקרות דפדפן, גילוי אפליקציות והגבלות על תוספים בסיכון גבוה. צוותי רכש ואבטחה צריכים לבדוק כיצד ספקים מגינים על מידע, מנהלים גישה, מטפלים בחולשות, שומרים לוגים ומודיעים ללקוחות על אירועים.

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

צוותי אבטחה יכולים להשתמש ב-AI – אך אוטומציה זקוקה לגבולות הגנה

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

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

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

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

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

בנו הגנות למתקפות הנעות במהירות מכונה

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

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

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

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

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

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

צ'קליסט מעשי למוכנות סייבר בעידן ה-AI

השתמשו בשאלות הבאות לבחינה פנימית מהירה:

• האם הארגון יכול לזהות כל כלי AI, מודל, סוכן, תוסף ואינטגרציה מאושרים הנמצאים בשימוש?
• האם קיימת הגבלה על הזנת מידע רגיש לשירותי AI אישיים או לא מאושרים?
• האם לכל מערכת AI יש בעלים ברורים, מטרה עסקית, סיווג מידע והערכת סיכונים?
• האם אפליקציות וסוכני AI מוגבלים למינימום המידע והפעולות הנדרשים?
• האם זהויות לא-אנושיות, מפתחות API, Tokens וחשבונות שירות נמצאים במצאי, מוגנים ומוחלפים באופן שוטף?
• האם מנהלי מערכת ומשתמשים אחרים בסיכון גבוה משתמשים בשיטות אימות עמידות בפני פישינג?
• האם שינויים בפרטי תשלום, איפוסי סיסמה, רישום ל-MFA ובקשות רגישות מחייבים אימות בלתי תלוי?
• האם הארגון יכול לזהות ולצמצם את הסיכון מחולשה קריטית החשופה לאינטרנט בתוך שעות ולא שבועות?
• האם לוגים מתחנות קצה, ממערכות זהות, מענן, מאפליקציות וממערכות AI מוזנים לתהליך מוגדר של ניטור ותגובה?
• האם צוותי האבטחה יכולים לבטל במהירות Sessions, להשבית זהויות, לבודד מכשירים ולחסום אינטגרציות זדוניות?
• האם קוד שנוצר באמצעות AI עובר ביקורת עמיתים, בדיקות אבטחה, סריקת תלויות וזיהוי סודות?
• האם החלטות אבטחה שהתקבלו בסיוע AI מתועדות, מאומתות וניתנות לביטול?
• האם העובדים הוכשרו להתמודד עם פישינג משופר באמצעות AI, התחזות קולית, מסמכים מזויפים ומתקפות איפוס MFA?
• האם הארגון בדק אירוע מציאותי הכולל הן תוקף הנעזר ב-AI והן מערכת עסקית התומכת ב-AI?

כל תשובה של "לא" או "לא בטוחים" מייצגת פער שצריך להיות לו אחראי, סדר עדיפות ומועד יעד לטיפול.

היערכו לאיומים מהירים יותר בלי לרדוף אחרי ההייפ

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

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

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