לא רק סריקה, או איך לבנות תהליך ניהול פגיעות ב-9 שלבים

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

שלב מס' 1: קבע את רמת הבשלות של תהליכי ניהול הפגיעות שלך

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

נסו לענות על שאלות בסיסיות:

• האם יש לך תהליכים לסיווג מלאי וסיווג נכסים; 
• באיזו סדירות נסרקת תשתית ה-IT והאם כל התשתית מכוסה, האם אתה רואה את כל התמונה;
• האם משאבי ה-IT שלך מנוטרים?
• האם כל KPI מיושם בתהליכים שלך וכיצד אתה מבין שהם מתקיימים;
• האם כל התהליכים הללו מתועדים?

שלב מס' 2: הבטח כיסוי תשתית מלא

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

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

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

שלב מס' 3: סיווג נכסים

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

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

שלב מס' 4: ביצוע הערכת תשתית

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

שלב מס' 5: הגדר דיווח

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

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

שלב מס' 6: תעדוף

כאן אתה יכול לעשות את הפעולות הבאות:

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

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

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

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

שלב מס' 7: הסכימו על מדדי KPI

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

שלב מס' 8: אוטומציה

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

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

שלב מס' 9: התמקדו ביסודות

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

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

מקור: www.habr.com