ניהול פגיעויות והמציאות בשטח

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

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

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

• ממצאים עם בעיות ופערי אבטחה
• צוות תקיפה שמריץ פעולות ומציף בעיות
• חשיפות שמתגלות מידי יום במערכות

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

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

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

אם נקח את הרפרנס הבא לסביבות Active Directory של Administrative tools and logon types שהוא בסיסי אך עדיין חשוב, נוכל להבין כי ישנם מצבים נוספים שהרפרנס אינו מתייחס אליהם. לצד זה, האם הכלים, המערכות והאנליסטים ב SOC יכולים לזהות כל את הגישות הבסיסיות של תרחישי ניהול מרחוק וניצולם בשטח.

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

בדוגמה של Defender for Cloud מול סביבת Azure אנו מקבלים כמויות של מידע, בהם, ממצאים שאנו חייבים לסגור. האם אפשר לסגור את כלל הממצאים? באיזה טווח סגירה מדובר? קצר/ביניים/ארוך? מהי מידת ההשפעה על הארגון? האם זה יגרום לבעיה בסביבת הפיתוח? אפשר להמשיך עם סריה של שאלות.🤐

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

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

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

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

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

המודל הפגיע

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

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

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

ישנן מספר סיבות עיקריות לכך שמשהו שהוא פגיע תיאורטית אינו ניתן לניצול בפועל:

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

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

האם צריך תוכנית לניהול פגיעויות?

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

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

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

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

מהעובדות המוזכרות במאמר אנו הולכים ישירות אל אחת היכולות של Microsoft Defender Vulnerability Management והיא Event timeline שמסייע בהבנה של דירוג, הבנה, מה פגיע ועוד במרחב הטכנולוגי של הארגון.

המאמר הבא יתמקד באפשרויות של ניהול פגיעויות ודירוג עם Event timeline מתוך Microsoft Defender Vulnerability .Management