מערכת ניטור CVE אפקטיבית לא מתחילה בעדכוני NVD, אלא במסנן שמתעדף פגיעויות לפי סיכון אמיתי לסטאק שלך. כאן נסביר איך לבנות ארכיטקטורה עם NVD JSON, OpenVAS ו-EPSS שתצמצם את הרעש ב-80% ותספק רק את מה שניתן לפעולה — בלי צורך ב-SOC של 20 איש.

למה עדכוני NVD גולמיים חסרי תועלת לצוותים קטנים?

ה-JSON feed של NVD מפרסם כ-2,500 CVE חדשות בחודש (ממוצע 2023, לפי נתוני NIST). צוות של 3 אנשים לא יכול לעבד את הכמות הזו, אבל גם לא יכול להתעלם ממנה: 60% מהניצולים המוצלחים ב-2023 השתמשו בפגיעויות עם CVE מוקצה (דוח DBIR 2024). הבעיה אינה הכמות, אלא חוסר ההקשר.

עדכוני הגולמיים מספקים:

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

ארכיטקטורה מינימלית בת-קיימא: 4 רכיבים שמצמצמים את הרעש

צינור אפקטיבי זקוק לבלוקים הבאים, בסדר הזה:

  1. סינון לפי מלאי: "האם אנחנו משתמשים בתוכנה הזו?".
  2. תעדוף לפי סיכון אמיתי: CVSS + EPSS + ניצולים ציבוריים.
  3. אימות אוטומטי: "האם הפגיעות הזו ניתנת לניצול בתצורה שלנו?".
  4. התראות שניתנות לפעולה: רק מה שדורש פעולה מיידית.

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

1. סינון לפי מלאי: מיפוי CPEs לסטאק האמיתי שלך

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

דוגמה מעשית: אם אתה משתמש ב-nginx 1.25.1 בייצור, ה-CPE שלו הוא cpe:2.3:a:nginx:nginx:1.25.1:*:*:*:*:*:*:*. כאשר NVD מפרסמת CVE עבור nginx, ה-JSON כולל את ה-CPE הזה בשדה configurations.nodes.cpe_match.

כלים לאוטומציה:

curl -s https://services.nvd.nist.gov/rest/json/cves/2.0 | \
jq '.vulnerabilities[] | select(.cve.configurations[].nodes[].cpeMatch[].criteria |
  contains("cpe:2.3:a:nginx:nginx"))'

ב-CyberShield, אנו משתמשים ב-Dependency-Track עבור לקוחות עם סטאקים מורכבים (למשל, Kubernetes + מיקרוסרביסים) ובסקריפטים מותאמים אישית עבור עסקים קטנים ובינוניים עם סביבות סטטיות. המפתח הוא שהסינון הזה יצמצם את נפח ה-CVE ב-90-95%.

2. תעדוף: CVSS לא מספיק, השתמש ב-EPSS

ה-CVSS (Common Vulnerability Scoring System) מודד חומרה טכנית, אך לא הסתברות ניצול. CVE עם CVSS 9.8 ("קריטי") עשויה שלא להיות מנוצלת לעולם, בעוד CVE עם CVSS 7.5 ("גבוה") עשויה להיות מנוצלת באופן נרחב בשטח.

כאן נכנס EPSS (Exploit Prediction Scoring System), מודל של FIRST שמנבא את ההסתברות ש-CVE תנוצל ב-30 הימים הקרובים. EPSS נע בין 0 ל-1 (למשל, 0.8 = הסתברות של 80%).

איך לשלב CVSS ו-EPSS:

דוגמה אמיתית: במרץ 2024, NVD פרסמה את CVE-2024-21887 (Ivanti Connect Secure RCE) עם CVSS 9.1. EPSS הקצה לה 0.97 (הסתברות ניצול של 97%). ב-CyberShield, סוג כזה של CVE עולה לראש תור ההתראות, גם אם הלקוח לא משתמש ב-Ivanti, מכיוון שזהו אינדיקטור לכך שתוקפים מתמקדים בווקטור הזה.

איפה להשיג EPSS:

3. אימות אוטומטי: האם ה-CVE הזו ניתנת לניצול בסביבה שלך?

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

דוגמת זרימת עבודה:

  1. אתה מקבל התראה על CVE-2024-1234 (CVSS 8.8, EPSS 0.75).
  2. הסקריפט שלך מסנן לפי מלאי ומאשר שהיא משפיעה על postgresql 12.5 (שאתה משתמש בו).
  3. אתה מפעיל סריקה עם OpenVAS או Nuclei כדי לאמת אם פורט 5432 חשוף ואם הגרסה פגיעה.
  4. אם הסריקה מאשרת את הפגיעות, ההתראה עוברת ל"ניתנת לפעולה". אם לא, היא מאורכת.

תצורת מינימום של OpenVAS לכך:

openvas-start
omp -u admin -w password -h localhost -p 9390 --xml="<create_task>
  <name>CVE-2024-1234 Validation</name>
  <target><hosts>192.168.1.100</hosts></target>
  <config id='daba56c8-73ec-11df-a475-002264764cea'/> <!-- Full and fast -->
</create_task>"

ב-CyberShield, אנו משלבים את OpenVAS עם הסוכן של נקודת הקצה שלנו כדי לאמת CVE בזמן אמת. אם הסריקה מאשרת את הפגיעות, הסוכן מייצר התראה בלוח הבקרה שלנו עם הקשר: "CVE-2024-1234 ב-postgresql 12.5 (שרת DB-01). ניתנת לניצול: כן. EPSS: 0.75. המלצה: עדכון לגרסה 12.15".

4. התראות שניתנות לפעולה: פחות זה יותר

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

כלים ליישום זה:

import requests

def send_slack_alert(cve_id, epss, affected_host, recommendation):
    webhook_url = "https://hooks.slack.com/services/..."
    message = {
        "text": f":rotating_light: *התראת CVE קריטית* :rotating_light:",
        "attachments": [{
            "color": "#ff0000",
            "fields": [
                {"title": "CVE", "value": cve_id, "short": True},
                {"title": "EPSS", "value": epss, "short": True},
                {"title": "מארח מושפע", "value": affected_host, "short": True},
                {"title": "המלצה", "value": recommendation, "short": False}
            ]
        }]
    }
    requests.post(webhook_url, json=message)

מקרה אמיתי: צינור התראות לעסק קטן ובינוני באמריקה הלטינית

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

תוצאות לאחר 3 חודשים:

דוגמה להתראה אמיתית שגרמה לפעולה:

CVE-2023-4863 (גלישת חוצץ בערימה ב-libwebp).
CVSS: 8.8.
EPSS: 0.92 (הסתברות ניצול של 92%).
משפיעה על: Node.js 18 (בשימוש במיקרוסרביס האימות).
ניתנת לניצול: כן (OpenVAS אישר שפורט 3000 חשוף).
המלצה: עדכון ל-Node.js 18.18.2 או יישום תיקון זמני.
פעולה שננקטה: תיקון יושם תוך 4 שעות.

ללא הצינור הזה, ההתראה הייתה הולכת לאיבוד ברעש של 7,200 CVE חודשיות. איתו, הצוות פעל לפני שהפגיעות נוצלה בשטח (מה שקרה 5 ימים לאחר מכן, לפי דוחות של CISA).

טעויות נפוצות ואיך להימנע מהן

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

  1. מלאי לא מעודכן:
    • בעיה: אם המלאי שלך לא משקף שינויים אחרונים (למשל, מיקרוסרביס חדש ב-Go), הסינון לפי CPE ייכשל.
    • פתרון: אוטומציה של עדכון המלאי עם כלים כמו:
      • Ansible: לשרתים (ansible-inventory --list).
      • Kubernetes: kubectl get pods --all-namespaces -o json.
      • נקודות קצה: סוכנים כמו osquery או הסטאק שלנו ב-CyberShield, המדווחים על תוכנות מותקנות בזמן אמת.
  2. תלות יתר ב-CVSS:
    • בעיה: CVE עם CVSS 10.0 אך EPSS 0.01 (הסתברות ניצול של 1%) אינה עדיפות.
    • פתרון: השתמש ב-EPSS כמסנן עיקרי לאחר CVSS. ב-CyberShield, אנו מסננים CVE עם EPSS < 0.05 גם אם ה-CVSS שלהן הוא 9.0+.
  3. אי-אימות עם סורקים:
    • בעיה: הנחה ש-CVE ניתנת לניצול רק בגלל שהיא משפיעה על התוכנה שלך מובילה לאזעקות שווא.
    • פתרון: תמיד אמת עם OpenVAS/Nuclei לפני שליחת התראה. דוגמה: CVE-2023-3824 (PHP RCE) משפיעה על PHP 8.0-8.2, אך רק אם phar.readonly = Off. סריקה עם Nuclei יכולה לאשר אם התצורה הזו פעילה.
  4. התראות ללא הקשר:
    • בעיה: שליחת "CVE-2024-1234 זוהתה" בלבד מייצרת יותר שאלות מתשובות.
    • פתרון: כלול בהתראה:
      • CVSS ו-EPSS.
      • מארח/שירות מושפע.
      • האם ניתנת לניצול? (תוצאה מהסריקה).
      • תיקון או הפחתה זמינים.
      • קישור ל-CVE ב-NVD.

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

הארכיטקטורה המתוארת כאן מצמצמת את הרעש ב-99% ומספקת רק מה שניתן לפעולה. היא אינה דורשת SOC ייעודי או כלים יקרים: עם NVD JSON, OpenVAS, EPSS וקצת סקריפטים, כל צוות יכול ליישם אותה תוך שבוע. מה שכן נדרש הוא משמעת כדי לשמור על המלאי מעודכן ולהתנגד לפיתוי לשלוח התראה על כל CVE חדשה.

ניטור CVE בזמן אמת אינו עוסק בידיעה על כל מה שקורה, אלא בידיעה על מה שחשוב. בסביבה שבה 80% מהתקיפות משתמשות בפגיעויות ידועות (דוח DBIR 2024), התעלמות מהמערכת הזו דומה לשייט בספינה עם עיניים עצומות. אך עם הגישה הנכונה, ניתן לשוט עם מפה ברורה: רק האיומים שבאמת משפיעים עליך, בסדר שבו עליך לפעול.

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

מקורות

  1. NIST National Vulnerability Database (NVD). (2024). NVD JSON Feeds Documentation. https://nvd.nist.gov/vuln/data-feeds
  2. FIRST. (2024). Exploit Prediction Scoring System (EPSS). https://www.first.org/epss/
  3. Greenbone Networks. (2024). OpenVAS Documentation. https://www.openvas.org/
  4. ProjectDiscovery. (2024). Nuclei Documentation. https://nuclei.projectdiscovery.io/
  5. Verizon. (2024). Data Breach Investigations Report (DBIR). https://www.verizon.com/business/resources/reports/dbir/
  6. CISA. (2024). Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  7. NIST. (2023). NVD Statistics 2023. https://nvd.nist.gov/general/statistics
  8. OWASP. (2023). Dependency-Track Documentation. https://dependency