ניהול נקודות חולשה באמצעות AI

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

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

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

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

איך יוצרים תוכנית להגנה מפני איומים מבוססת-AI

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

כדי לשנות את הגישה של הארגון לניהול נקודות חולשה, כדאי להביא בחשבון את העקרונות הבאים:

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

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

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

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

שלבים בתוכנית להגנה מפני איומים מבוססת-AI.

כדי לקבל עזרה ביצירה ובהטמעה של תוכנית להגנה מפני איומים, אפשר לפנות אל Mandiant Cybersecurity Consulting.

שלב 1: הכנה

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

סריקה לחשיפות חיצוניות

הנכסים שהכי פגיעים לאיומים שקשורים ל-AI הם נכסים שחשופים לאינטרנט, כמו:

  • מכונות וירטואליות של Compute Engine
  • פונקציות Cloud Run
  • אשכולות של Google Kubernetes Engine‏ (GKE)
  • קטגוריות של Cloud Storage

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

אחרי שמאתרים נכס, Wiz Red Agent יכול לדמות מתקפות מהעולם האמיתי כדי למצוא נקודות חולשה וליצור שרשראות של מתקפות. כש-Wiz Red Agent מוצא פגיעות, הוא שולח את הנתונים אל Wiz Security Graph. באמצעות Wiz Security Graph אפשר לראות לאילו נכסים פנימיים מתחבר הנכס שפונה לאינטרנט, וכך למפות את ההשפעה הפוטנציאלית של פריצה חיצונית.

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

בדוגמה הזו, Wiz Red Agent יכול למצוא את תת-הדומיין החדש *.run.app ולסמן את הנכס כנכס שפונה לאינטרנט באמצעות יכולת הגילוי הרציפה שלו. לאחר מכן, Wiz Red Agent יכול ליצור אינטראקציה עם אב הטיפוס של הצ'אטבוט כדי לקבוע שהצ'אטבוט מחובר לנקודת קצה ל-API. הכלי Wiz Red Agent מדמה מתקפות שונות, כמו מתקפת הזרקת הנחיה, כדי לזהות נקודות חולשה. המפתח לא הגדיר אבטחה מתאימה, ולכן Wiz Red Agent מוצא נקודת חולשה וקובע שאפשר לנוע לרוחב אל קטגוריה של Cloud Storage. הכלי Wiz Red Agent שולח את הנתונים אל Wiz Security Graph, שמסמן את נקודת החולשה הזו כבעלת עדיפות קריטית. התהליכים שלכם יכולים להשבית את אב הטיפוס הזה תוך דקות.

מתן עדיפות לנכסים בסריקת קוד מקיפה

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

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

  • הנגישות של קוד המקור או של קבצי ההפעלה (אם הם זמינים לכולם או פנימיים). אם הקבצים הבינאריים שלכם זמינים לציבור, אין הגנה אמיתית מפני הנדסה הפוכה שמבוססת על LLM.
  • שפת התכנות (בין אם הקוד שלכם כתוב בשפה בטוחה לזיכרון כמו Go,‏ Rust,‏ Java או Python).
  • ההרשאות שהקוד דורש כדי לפעול.
  • רמת הרגישות של הנכסים שהקוד צריך לגשת אליהם.

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

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

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

כדי לקבוע סדר עדיפויות לנכסים, אפשר להשתמש בתכונות של Wiz כמו:

  • ‫Wiz Service Catalog ו-Wiz inventory כדי לקבוע את החשיפה ואת הסיכונים שמשפיעים על הנכסים שלכם.

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

  • Wiz Security Graph ו-Wiz Workload Scanner כדי לזהות את מאגרי קוד המקור שמשמשים בסביבת ייצור פעילה.

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

  • ‫Wiz Code-to-Cloud Pipeline ממפה את שושלת הנתונים של נכס בסביבת הייצור.

    צינור עיבוד הנתונים של Wiz Code-to-Cloud יכול לתת עדיפות לקוד פעיל ונגיש בסביבת הייצור, לקבוע את מאגר המקור של נקודות החולשה ולחזק את ההגדרות של התשתית כקוד (IaC). צינור העיבוד Code-to-Cloud של Wiz מאפשר לקשר את מאגר המקורות של הקוד לשימוש בפועל.

שלב 2: סריקה ותעדוף

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

השלמת סריקה מעמיקה של בסיס הקוד

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

  • סריקות בסיסיות: סריקה רציפה של קוד בסביבת הפיתוח המשולבת (IDE) ובצינור עיבוד הנתונים של CI/CD כדי למצוא שגיאות נפוצות בכתיבת קוד, סודות שמוטמעים בקוד ותלויות פגיעות.
  • סריקות AI מעמיקות: ניתוח של בסיסי קוד קריטיים מאוד עם לוגיקה עסקית מורכבת, וזיהוי של נקודות חולשה משורשרות או נקודות חולשה מסוג zero-day שאולי לא יזוהו על ידי SAST.

כדי לבצע סריקת בסיס, אפשר להשתמש ב-Wiz Code כדי לסרוק סודות, למצוא טעויות בהגדרות של IaC, לבצע בדיקות אבטחה סטטיות של אפליקציות (SAST) ולזהות סיכוני אבטחה בתוכנות של צד שלישי באמצעות ניתוח הרכב התוכנה (SCA).

‫Wiz Code עוזר לאכוף את מדיניות האבטחה שלכם על ידי הערכת הקוד בבסיס CI/CD וחסימת כל בנייה שלא עומדת בתקנים שלכם. בעזרת Wiz Code אפשר לבדוק את המלאי כדי לזהות אילו פגיעויות אפשר לנצל בסביבת ייצור. כש-Wiz Code מוצא נקודת חולשה, Wiz Green Agent מנתח באופן אוטומטי את הקוד שמסביב ויוצר תיקון כדי לפתור את הבעיה. אם הבעיה נמצאת בסביבת הפיתוח המשולבת (IDE) של המפתח, Green Agent יכול לבצע רפקטורינג של הקוד לפני שהמפתח מבצע קומיט של השינוי לצינור. אם נמצאת בעיה בצינור CI/CD, ‏ Wiz Green Agent יכול ליצור באופן אוטומטי בקשת משיכה ב-GitHub או ב-GitLab עם תיקון הקוד.

כדי לבצע סריקת AI מעמיקה, אפשר לפרוס את CodeMender (בגרסת Preview) עם Gemini Enterprise Agent Platform. ‫CodeMender (שפותח על ידי Google DeepMind) הוא סוכן AI אוטונומי וייעודי להנדסת תוכנה, שמתמקד בניתוח מעמיק של קוד, באיתור באגים ובתיקון שלהם. ‫CodeMender פועל כמו מהנדס תוכנה בכיר ואוטונומי שמושך קוד לארגז חול, מריץ מגוון בדיקות ומתקן את הלוגיקה הבסיסית. הפעלות בדיקה עשויות לכלול ניתוח דינמי, בדיקת fuzz ובדיקת קומפילציה אוטומטית. ‫CodeMender יכול לתת עדיפות אוטונומית לבאגים על סמך ההשפעה המבנית שלהם, לתקן בעיות ולשכתב קוד באמצעות שיטה איטרטיבית.

מיון ותכנון של פעולות לתיקון

אחרי שמרכיבים רשימה של פגיעויות, אפשר להפנות את הממצאים מ-Wiz Code ומ-CodeMender למנועים כמו Wiz SAST Triage AI Engine כדי לשפר את הממצאים ולעזור לקבוע אם וקטורי המתקפה ניתנים לניצול. בנוסף, Wiz Security Graph יכול לעזור להעשיר את ההקשר באמצעות צינור עיבוד הנתונים של קוד ל-Cloud. ‫Wiz Red Agent יכול לבדוק את האתר הפעיל ולאמת את נתיב המתקפה.

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

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

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

שלב 3: תיקון

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

הכלי Wiz Green Agent יכול ליצור באופן אוטומטי תוכנית לתיקון הבעיה על סמך הנתונים הזמינים. הוא מפעיל את Wiz Workflows כדי להזהיר את צוותי SecOps באמצעות מערכת הכרטיסים שלכם, ושולח את תוכנית התיקון ל-CodeMender. ‫CodeMender יוצר את התיקון, בודק אותו בסביבת ארגז חול מאובטחת כדי למנוע רגרסיות, ויוצר את בקשת המשיכה לתיקון המערכת. מפתח יכול לבדוק את בקשת המשיכה וללחוץ כדי לפרוס את השינוי.

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

כדי לייעל את תהליך התיקון, מומלץ לפעול לפי השיטות הבאות:

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

מודרניזציה של התוכנה

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

  • פיתוח: מפתחים מעצבים ומבצעים אב טיפוס של אפליקציות באמצעות צ'אט בסביבת פיתוח משולבת (IDE) או הנחיות בשפה טבעית ב-CLI.
  • פיתוח: תהליכי AI עוזרים למפתחים ליצור קוד או לשנות קוד קיים באמצעות השלמות קוד.
  • בדיקה ותחזוקה: מפתחים וצוותי בקרת איכות משתמשים בבדיקות מבוססות-AI ובשינוי מבנה קוד אוטומטי.
  • בדיקה ופריסה: מפתחים משתמשים בביקורות קוד מבוססות-AI ובאמצעים לתמיכה בתשתית כקוד.
  • פתרון בעיות: מפתחים משתמשים בניתוח בעיות מבוסס-AI בכלי כמו Firebase Crashlytics כדי לנתח קריסות ושגיאות.
  • תפעול: מפתחים ומהנדסי תוכנה משתמשים בסוכני AI כדי להבין ולשנות אפליקציות קיימות.

במסגרת מודרניזציה של תוכנה, צמצום פערי האבטחה והחוב הטכני מועבר שמאלה לסוכנים אוטונומיים שמיועדים לבצע שינויים קטנים ואיטרטיביים בסביבה שלכם. מודרניזציה של תוכנה מתבססת על שרתים של Model Context Protocol‏ (MCP), שמאפשרים למודלים גישה ישירה בזמן אמת לכלים חיצוניים ולנתונים סביבתיים בזמן אמת.

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

כדי לעזור בתהליך המודרניזציה של התוכנה, כלים כמו Google Antigravity ו-Gemini Code Assist יכולים לתפקד כשותפים עצמאיים שמאתרים בעיות, בודקים אותן ומתקנים אותן לפני בדיקה אנושית או לפני בנייה של צינור מרכזי. ‫Google Antigravity מספק חוויית IDE ומנהל סוכנים מלא, ו-Gemini Code Assist ב-Gemini CLI מספק CLI של מסוף להפעלה ללא ראש. אתם יכולים להשתמש במגוון של כישורי סוכן ב-Wiz ובמוצרים אחרים של Google כדי לקבל עזרה בתהליך הפיתוח. פלטפורמת הסוכנים כוללת מודלים כמו Gemini 3.5 Pro ו-Flash, שמספקים חלונות הקשר ארוכים, יכולות ניתוח רב-שלביות וביצוע מובנה של כלים.

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

חיזוק בסיס האבטחה

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

  • הגדרת מדיניות ובקרת גישה מאפשרת לראות את רכיבי התוכנה, לזהות נקודות חולשה ולפתור בעיות לפני פריסת התוכנה בסביבת הייצור.
  • שימוש בתמונות בסיס מוקשחות עם מכונה וירטואלית מוגנת, Confidential Computing ו-WizOS כדי להגן על שכבת האפליקציה, שכבת מערכת ההפעלה ושכבת החומרה.
  • אפשר להשתמש ב-Wiz Runtime Sensor כדי לנטר תחנות עבודה של מפתחים ורצים של CI/CD build, לזהות מתקפות פעילות על צינורות עיבוד נתונים של CI/CD ולספק הקשר פעיל בזיכרון.
  • כדי לשמור על סביבה שתואמת למדיניות האבטחה שלכם, אתם יכולים למצוא ולתקן סטיות מהשירות שלכם לניהול מצב האבטחה.
  • הגדרת שער גישה מאובטח לשימוש בקוד פתוח כדי לאכוף את מדיניות האבטחה באמצעות Wiz Registry Connectors.
  • בידוד של סביבות הפיתוח, ה-Staging והייצור באמצעות פילוח רשת קפדני וכללי חומת אש.
  • אחסון כל היומנים של צינורות עיבוד הנתונים, הפריסות והגישה במיקום אחסון מרכזי ובלתי ניתן לשינוי לצורך מעקב רציף וניתוח משפטי.
  • כדי למנוע שיבושים ושינויים לא רצויים בהגדרות, כדאי להתייחס לצינור עיבוד הנתונים של CI/CD כאל תשתית בלתי ניתנת לשינוי. תשתית בלתי ניתנת לשינוי גם מחייבת שימוש ב-runners זמניים לטווח קצר שלא מאפשרים לתוקף להשיג דריסת רגל קבועה בתשתית שלכם.
  • אחסון כל השינויים באפליקציות ובאשכולות במאגרי קוד מקור שמאפשרים בקרת גרסאות ובדיקה לפני הפריסה.

מידע נוסף על שיטות מומלצות זמין במאמר בנושא Google Cloud פלטפורמה מאובטחת מינימלית.

הקשחת מחזור החיים של פיתוח התוכנה (SDLC)

Secure AI Framework (SAIF) מתאר את אמצעי הבקרה שצריך להטמיע כדי להבטיח שימוש מאובטח ב-AI בצינור SDLC. כשמוסיפים AI, חשוב לשים לב לדברים הבאים:

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

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

  • הגדרות של IDE ושל סביבת עבודה ששולטות בתוספי דפדפן, בכלי CLI ובתוספי IDE, כדי למנוע מכלים לא מאושרים של AI לסיוע בתכנות להעביר שורות של בסיס קוד קנייני לנקודות קצה של מודלים חיצוניים שלא נבדקו.
  • אמצעי בקרה קפדניים על הגישה כדי למנוע שינויים לא מורשים. אמצעי בקרה מחמירים לניהול זהויות והרשאות גישה (IAM) ולאימות עוזרים לוודא שאתם מעניקים לחשבונות שירות של צינורות, כולל חשבונות של סוכנים, רק את ההרשאות המינימליות הנדרשות, אוכפים אימות דו-שלבי לכל המשתמשים האנושיים ובודקים באופן קבוע את הגישה שיש למשתמשים ולסוכנים כדי לוודא שהיא עדיין רלוונטית.
  • אמצעי הגנה על קוד המקור וההגדרות כדי לוודא שקוד זדוני או קוד שנוצר בטעות לא יגיע לשלב ה-build. כמה נקודות שכדאי לזכור:
    • חשוב לוודא שענפים נבדקים ובקשות משיכה או מיזוג נבדקות על ידי עמיתים מורשים, במיוחד בודקים אנושיים.
    • לא לאפשר אפשרויות עקיפה למיזוג.
    • חשוב לוודא שכל הקומיטים חתומים כדי לאמת את האותנטיות של הקוד ולמנוע שינויים לא מורשים.
    • להגביל את היכולת ליצור עותק של קוד פנימי או להפוך בטעות מאגרי קוד פרטיים לציבוריים.
  • ניהול דינמי של סודות כדי למנוע חשיפה של פרטי הכניסה. כדי לטפל בסודות באופן דינמי, צריך להסיר סיסמאות, מפתחות API וטוקנים שמוצפנים בקוד המקור ובקובצי ההגדרות. כלי סריקה אוטומטיים של סודות בקובצי IaC והגדרות עוזרים למצוא סודות לפני שהתחייבויות מתקבלות. ‫Secret Manager מאפשר להחדיר פרטי כניסה באופן דינמי בזמן ריצה.
  • אוטומציה של בדיקות אבטחה בצינור כדי לזהות פגיעויות בשלב מוקדם. כדאי לשקול אסטרטגיית בדיקה שכוללת בדיקות SAST,‏ SCA ו-DAST, כדי שתוכלו למצוא נקודות חולשה במהלך הפיתוח, בספריות של צד שלישי ובזמן הפעלת האפליקציות.
  • חבילות אפליקציות מאובטחות כדי למנוע שיבוש. משתמשים בניהול גרסאות בלתי ניתן לשינוי לחבילות build, וסורקים קובצי אימג' של קונטיינרים וחבילות לפני שמעבירים אותם בדחיפה ל-Artifact Registry. קידום של אותם קובצי תמונות של קונטיינרים בכל הסביבות, כולל פיתוח, Staging וייצור.

שלב 4: מעקב

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

‫Wiz Defend משתלב עם Google Security Operations כדי לשפר את תהליכי העבודה של מרכז האבטחה באמצעות התראות והקשר מפלטפורמת Wiz. ‫Wiz Defend עוקב אחרי התנהגות בזמן ריצה, הגדרות ענן, זהויות ונקודות חולשה ישירות בתוך סביבת הענן. ‫Wiz Defend מארגן התראות בזמן אמת ומעבד ראיות פורנזיות לזיהויים ברמת מהימנות גבוהה ולאיומים מאוחדים. Wiz Blue Agent יכול לחקור את הנתונים כדי לקבוע אם האיום אמיתי. לאחר מכן, Wiz יכולה לשלוח התראות עם עדיפות ל-Google SecOps כדי לבצע פעולות תגובה נוספות.

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

Agentic Threat Intelligence יכול להשתמש בנתונים מ-Mandiant ומ-VirusTotal כדי לזרז את החקירות. התכונה 'מודיעין איומים מבוסס-סוכנים' מבצעת אוטומציה של משימות מורכבות שגוזלות זמן רב, כמו הנדסה הפוכה של קוד, ניתוח תוכנות זדוניות ויצירת תדריכי איומים בהתאמה אישית, וכך מאפשרת לצוותי האבטחה להתפנות לעבודה קריטית אחרת.

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

כלים למעקב אחרי איומים מבוססי-AI.

המאמרים הבאים