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

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

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

זהו התפקיד של ניהול פגיעויות – Vulnerability Management.

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

מהי פגיעות אבטחת מידע וסייבר?

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

הפגיעות יכולה לנבוע, בין היתר, מ:

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

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

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

ניהול פגיעויות מתחיל במלאי נכסים

אי אפשר לנהל פגיעויות במערכות שהארגון אינו יודע שהן קיימות.

לפני הסריקה הראשונה נדרש מיפוי אמין של הנכסים:

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

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

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

סריקת חולשות היא רק שלב אחד

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

אבל הסריקה אינה סוף התהליך.

היא יכולה להפיק מאות או אלפי ממצאים, ובהם:

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

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

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

ההבדל בין סקר פגיעויות לניהול פגיעויות

סקר פגיעויות הוא צילום מצב.

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

ניהול פגיעויות, לעומת זאת, הוא תהליך רציף הכולל:

1. מיפוי נכסים.
2. סריקה וגילוי.
3. ניתוח הממצאים.
4. תעדוף לפי סיכון.
5. הקצאת אחריות.
6. תיקון או יישום בקרה מפצה.
7. סריקה חוזרת ואימות.
8. תיעוד חריגים.
9. מעקב ומדידה לאורך זמן.

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

במילים אחרות: סריקה מגלה את הבעיה; ניהול פגיעויות דואג שמישהו יטפל בה.

מדוע אי אפשר לתקן הכול מיד?

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

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

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

תעדוף נכון צריך להביא בחשבון:

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

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

CVSS הוא נקודת פתיחה – לא החלטה סופית

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

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

לכן אסור לבסס את סדר הטיפול רק על ציון CVSS.

ארגון צריך לשלב חומרה טכנית עם הקשר עסקי ומודיעין איומים. זהו המעבר מניהול פגיעויות מבוסס חומרה ל־Risk-Based Vulnerability Management.

חולשות שמנוצלות בפועל צריכות לקבל קדימות

אחד ממקורות המידע החשובים לתעדוף הוא קטלוג KEV של CISA – Known Exploited Vulnerabilities.

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

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

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

מהו EPSS ואיך הוא מסייע לתעדוף?

EPSS – Exploit Prediction Scoring System – הוא מודל הסתברותי שמעריך את הסיכוי שחולשת CVE מסוימת תנוצל בפועל במהלך 30 הימים הבאים. המודל מתעדכן מדי יום ומתבסס על נתונים ומאפיינים הקשורים לפגיעות ולפעילות ניצול.

EPSS אינו מודד את חומרת הנזק האפשרי, אלא את הסתברות הניצול.

לכן ניתן להשתמש ב־CVSS וב־EPSS יחד:

• CVSS: עד כמה החולשה חמורה מבחינה טכנית.
• EPSS: מה ההסתברות שתנוצל בטווח הקרוב.
• KEV: האם קיימות ראיות שהיא כבר מנוצלת בפועל.
• Asset Criticality: מה חשיבות המערכת לארגון.
• Business Impact: מה יקרה אם הנכס ייפגע.

FIRST מדגישה שכאשר חולשה מופיעה ב-CISA KEV, נכון להתייחס אליה כמנוצלת בפועל ולתעדף אותה בהתאם, ללא תלות בציון EPSS שלה.

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

Patch Management וניהול פגיעויות אינם אותו דבר

שני התהליכים קשורים זה בזה, אך אינם זהים.

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

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

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

לא לכל פגיעות קיים Patch. לעיתים הטיפול דורש:

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

לכן Patch Management הוא מנגנון טיפול מרכזי, אבל הוא רק חלק מתוכנית ניהול הפגיעויות.

איך נראה תהליך ניהול פגיעויות אפקטיבי?

1. הגדרת מדיניות ואחריות

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

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

2. מיפוי נכסים ובעלים

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

3. סריקות מותאמות לסביבה

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

4. ניתוח וניקוי הממצאים

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

5. תעדוף מבוסס סיכון

משלבים חומרה, KEV, EPSS, חשיפה חיצונית, קריטיות נכס והשפעה עסקית.

6. הקצאת משימות ו-SLA

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

7. תיקון או Mitigation

מבצעים Patch, שינוי תצורה, צמצום הרשאה או בקרה מפצה בהתאם לממצא.

8. אימות

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

9. חריגים וקבלת סיכון

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

10. מדידה ושיפור

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

אילו מדדים כדאי להציג להנהלה?

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

מדדים שימושיים יותר כוללים:

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

הדגש צריך להיות על מגמה ועל סיכון, לא על הצגת מספר גדול ללא הקשר.

טעויות נפוצות בניהול פגיעויות

סריקה ללא בעלות

מפיקים דוח, אך לא ברור מי אמור לטפל בכל מערכת.

תעדוף לפי CVSS בלבד

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

היעדר כיסוי מלא

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

טיפול ללא אימות

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

חריגים ללא תאריך תפוגה

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

התמקדות ב־Patch בלבד

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

ניתוק מהעסק

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

ניהול פגיעויות בענן

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

למשל:

• Storage ציבורי.
• Security Group רחב מדי.
• ממשק ניהול נגיש מהאינטרנט.
• Secret גלוי.
• Identity בעלת הרשאות עודפות.
• Image מיושן.
• Workload ללא Agent או ניטור.
• שירות שהוקם מחוץ לתהליך הארגוני.

לכן ניהול פגיעויות בענן צריך להתחבר ל-Cloud Security Posture Management, לניהול זהויות ולתהליכי DevSecOps. סריקת CVEs בלבד לא תזהה את כל החשיפות.

ניהול פגיעויות באפליקציות

אפליקציה יכולה להכיל חולשות בקוד שנכתב בארגון, בספריות צד שלישי, ב־APIs ובתצורה של סביבת ההרצה.

ניהול הפגיעויות צריך לכלול, לפי הצורך:

• SAST.
• DAST.
• Software Composition Analysis.
• סריקת Containers.
• סריקת Secrets.
• בדיקות חדירות.
• מעקב אחר רכיבי Open Source.
• תיקון כחלק מתהליך הפיתוח.

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

הקשר בין ניהול פגיעויות ל-CTEM

ניהול פגיעויות הוא הבסיס לזיהוי חולשות טכניות. CTEM – Continuous Threat Exposure Management – מרחיב את התהליך ומחבר אליו נכסים, זהויות, הרשאות, תצורות, חשיפות ענן ונתיבי תקיפה.

ניהול פגיעויות שואל:

אילו חולשות קיימות ואיך מתקנים אותן?

CTEM שואל:

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

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

ניהול פגיעויות הוא התשתית; CTEM מוסיף לה הקשר רחב יותר.

מה המשמעות עבור הארגון?

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

היא צריכה לענות באופן רציף על שאלות כמו:

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

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

איך אינפוגארד יכולה לסייע?

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

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

המטרה אינה להוסיף עוד רשימת חולשות לתיקייה, אלא לבנות תהליך מעשי שמגדיר:

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

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

סריקה מגלה את החולשה. ניהול פגיעויות מבטיח שהיא לא נשארת פתוחה.

המידע המוצג במאמר זה נועד למטרות מידע והעשרה בלבד ואינו מהווה ייעוץ מקצועי, רגולטורי, משפטי או טכנולוגי. כל ארגון נדרש לבחון את צרכיו, הסיכונים והדרישות החלות עליו באמצעות אנשי מקצוע מתאימים.
המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך על ידי ROY KISCH, חובב אבטחת מידע, סייבר ומנהל השיווק של קבוצת חברות עידור (Messagent, Infoguard, Idornext).