כך פיתחנו סוכן שסוגר חולשות אבטחה בלי להפיל את הפרודקשן

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

נוכחות של Package פגיע בדוח סריקה היא רק נקודת ההתחלה בעבודה של סוכן אבטחה (צילום: רעות דורון)

מאת רומן לבונסקי

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

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

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

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

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

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

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

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

מה הראיות באמת מוכיחות?

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

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

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

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

לבחור פעולה מצומצמת שאפשר לאכוף

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

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

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

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

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

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

גם החלטה נכונה עשויה לאבד תוקף

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

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