ניהול נקודות חולשה באמצעות 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 Pipeline אפשר לתת עדיפות לקוד פעיל ונגיש בסביבת הייצור, לקבוע את מאגר המקור של נקודות החולשה ולחזק את ההגדרות של התשתית כקוד (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) כששליחות (commit) קטנות ומבודדות.

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

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

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

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

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

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

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

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

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

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