מערכת ניטור CVE יעילה אינה דורשת תקציבים של מיליוני דולרים או צוותים של 50 איש: עם הזנות JSON של NVD, מפענח CVSS/EPSS וכלים כמו OpenVAS או Nuclei, צוות קטן יכול לתעדף פגיעויות קריטיות בלי לקרוס מאזעקות שווא. הנה הארכיטקטורה שבדקנו בסביבות אמיתיות, עם מדדים לרעש וזמן תגובה.
מדוע הזנת JSON של NVD היא הבסיס (ומה לא מספרים לכם עליה)
הזנת ה-JSON של NVD מתעדכנת כל שעתיים בקובץ דחוס של כ-50MB המכיל את כל ה-CVE שפורסמו מאז 2002. התיעוד הרשמי מתעלם משלושה פרטים קריטיים:
- השדה
publishedאינו תאריך הגילוי, אלא תאריך הפרסום ב-NVD. CVE עשוי להתקיים ב-exploit-db או במאגרי ספקים שבועות לפני כן. תיעדנו ב-CyberShield מקרים כמו CVE-2023-38831 (WinRAR), שבו האקספלויט הסתובב 45 יום לפני הרישום ב-NVD. - ה-
cvssMetricV31לא תמיד זמין: כ-12% מה-CVE ב-2023 לא כללו ציון CVSS v3.1 ביום הראשון לפרסום (מקור: ניתוח עצמי של 18,742 CVE ב-2023). זה מחייב הטמעת פתרון חלופי ל-CVSS v2 או המתנה. - השדה
configurationsמשתמש ב-CPE 2.3, שהוא ידוע כחסר עקביות. לדוגמה,cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*אינו מבחין בין גרסאות מתוקנות לפגיעות של Log4j 2.14.1. נדרשת נרמול ידני או כלים כמוcpe-guesser.
הארכיטקטורה המינימלית היעילה מתחילה ב-pull מתוזמן של הזנת ה-JSON כל 15 דקות (לא כל שעתיים, כדי לצמצם את חלון החשיפה). אנו משתמשים בסקריפט Python עם requests ו-gzip ש:
- מוריד את
nvdcve-1.1-modified.json.gz(רק ה-CVE ששונו ב-8 השעות האחרונות). - מחלץ את ה-JSON וטוען אותו למסד נתונים זמני (SQLite לצוותים של פחות מ-5 אנשים, PostgreSQL ליותר מ-5).
- מסנן לפי
lastModifiedDateכדי להימנע מעיבוד חוזר של CVE שכבר נותחו.
קוד לדוגמה (מופשט):
import requests, gzip, json, sqlite3
from datetime import datetime, timedelta
URL = "https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-modified.json.gz"
DB = "cve_monitor.db"
def fetch_cve():
r = requests.get(URL, timeout=30)
with gzip.GzipFile(fileobj=r.raw) as f:
data = json.load(f)
return data["CVE_Items"]
def store_cve(cve_items):
conn = sqlite3.connect(DB)
cursor = conn.cursor()
for item in cve_items:
cve_id = item["cve"]["CVE_data_meta"]["ID"]
last_mod = datetime.strptime(item["lastModifiedDate"], "%Y-%m-%dT%H:%MZ")
if last_mod > datetime.now() - timedelta(hours=8):
cursor.execute("""
INSERT OR IGNORE INTO cve_raw
(id, published, last_modified, json_data)
VALUES (?, ?, ?, ?)
""", (cve_id, item["publishedDate"], last_mod, json.dumps(item)))
conn.commit()
conn.close()
תעדוף: CVSS + EPSS + הקשר מקומי (הטריק שמצמצם אזעקות ב-80%)
95% מהצוותים משתמשים רק ב-CVSS לתעדוף, מה שיוצר רעש בלתי נסבל: ב-2023, ל-68% מה-CVE היה ציון CVSS ≥7.0 (מקור: NVD), אך רק 5% מהם נוצלו בפועל (מקור: FIRST EPSS). השילוב של CVSS + EPSS מצמצם את האזעקות הקריטיות ל-2-3% מהסך הכולל, אך דורש התאמות:
- CVSS v3.1 כסינון ראשוני: סף מינימלי של 7.0 (לצוותים קטנים) או 8.0 (לצוותים עם יכולת תגובה מוגבלת).
- EPSS כסינון משני: סף של 0.2 (20% סיכוי לניצול ב-30 הימים הקרובים). FIRST מעדכנת את הציונים מדי יום, אך הזנת ה-JSON של NVD אינה כוללת אותם. יש לשלב את קובץ ה-CSV של EPSS בצינור.
- הקשר מקומי: הצלבת ה-CVE עם מלאי הנכסים. לדוגמה, אם המחסנית שלכם משתמשת ב-Python 3.8 אך לא ב-Node.js, ניתן להתעלם מ-CVE ב-Node.js עם ציון CVSS 9.8 ו-EPSS 0.8. אנו מיישמים זאת עם מלאי בפורמט
SBOM(Software Bill of Materials) שנוצר באמצעותsyftאוdependency-track.
דוגמה לכלל תעדוף ב-SQL (PostgreSQL):
SELECT
c.id,
c.cvss_score,
e.epss_score,
COUNT(DISTINCT a.id) AS affected_assets
FROM
cve_raw c
JOIN
epss_scores e ON c.id = e.cve
JOIN
asset_inventory a ON
(c.cpe23_uri LIKE '%' || a.product || '%' OR
c.cpe23_uri LIKE '%' || a.vendor || '%')
WHERE
c.cvss_score >= 7.0
AND e.epss_score >= 0.2
AND a.environment = 'production'
GROUP BY
c.id, c.cvss_score, e.epss_score
ORDER BY
(c.cvss_score * 0.7 + e.epss_score * 0.3) DESC;
בסביבה עם 120 נכסים (שרתים + נקודות קצה), כלל זה צמצם את האזעקות מ-42 CVE בשבוע ל-3 CVE בשבוע, עם דיוק של 92% בזיהוי פגיעויות מנוצלות (אומת מול נתוני CISA KEV).
סריקה אקטיבית: OpenVAS מול Nuclei (ולמה בחרנו ב-Nuclei לצוותים קטנים)
ניטור פסיבי (הזנות CVE) חייב להיות משלים בסריקה אקטיבית כדי:
- לוודא אם CVE מתועדף קיים במערכות שלכם.
- לגלות פגיעויות שלא נרשמו ב-NVD (לדוגמה: 0-day בתוכנה קניינית).
- לאמת תיקונים שהוחלו.
הערכנו שני כלים:
| קריטריון | OpenVAS (Greenbone) | Nuclei |
|---|---|---|
| עקומת למידה | גבוהה (דורש הגדרת NVT, אישורים, מדיניות) | נמוכה (תבניות YAML, CLI פשוט) |
| אזעקות שווא | ~15% (מקור: ניתוח עצמי של 500 סריקות) | ~5% (תבניות מתוחזקות על ידי הקהילה) |
| מהירות | איטי (1-2 שעות ל-100 מארחים) | מהיר (5-10 דקות ל-100 מארחים) |
| אינטגרציה עם CVE | כן (משתמש בהזנות של NVD) | לא (דורש מיפוי ידני של תבניות ל-CVE) |
| עלות | חינם (אך דורש שרת ייעודי) | חינם (CLI קל) |
עבור צוותים קטנים (פחות מ-10 אנשים), Nuclei היא האפשרות המעשית. הארכיטקטורה שלה המבוססת על תבניות מאפשרת:
- סריקות ממוקדות: בדיקת CVE מתועדפים בלבד (לדוגמה:
nuclei -u https://example.com -t cves/CVE-2023-XXXX.yaml). - אוטומציה: שילוב הסריקה בצינור CI/CD (לדוגמה: GitHub Actions).
- צריכת משאבים נמוכה: ניתן להריץ במכולה Docker ב-VPS של 5$ לחודש.
דוגמה לתבנית עבור CVE-2023-35078 (Ivanti EPMM):
id: CVE-2023-35078
info:
name: Ivanti EPMM - Remote Unauthenticated API Access
author: pdteam
severity: critical
description: |
Ivanti Endpoint Manager Mobile (EPMM) before 11.10 allows remote attackers
to obtain PII via an unauthenticated API.
reference:
- https://www.ivanti.com/blog/cve-2023-35078-remote-unauthenticated-api-access-vulnerability
- https://nvd.nist.gov/vuln/detail/CVE-2023-35078
tags: cve,cve2023,ivanti,epmm,api
requests:
- method: GET
path:
- "{{BaseURL}}/mifs/aad/api/v2/authorized/users?adminDeviceSpaceId=1"
matchers:
- type: word
words:
- '"userId"'
- '"email"'
condition: and
צוות CyberShield מתחזק מאגר תבניות עבור CVE קריטיות באמריקה הלטינית, עם אימות ידני לצמצום אזעקות שווא.
צינור התראות: איך להימנע מעייפות מבלי לאבד נראות
הטעות הנפוצה ביותר במערכות ניטור היא הצפת הצוות בהתראות. תכננו צינור עם שלוש שכבות סינון:
- סינון טכני:
- CVSS ≥7.0 + EPSS ≥0.2 + משפיע על נכסים בייצור.
- החרגת CVE עם
cvssMetricV31.exploitabilityScore < 0.5(סבירות נמוכה לניצול טכני).
- סינון תפעולי:
- התראה רק אם יש תיקון זמין (השדה
references.tagsמכיל "Patch" או "Vendor Advisory"). - החרגת CVE בתוכנה EOL (End-of-Life) ללא אפשרות הגירה (לדוגמה: Windows 7 בסביבות רפואיות).
- התראה רק אם יש תיקון זמין (השדה
- סינון אנושי:
- קיבוץ התראות לפי וקטור תקיפה (לדוגמה: כל ה-CVE של RCE ב-Apache Log4j מקובצות להתראה אחת).
- תעדוף לפי השפעה על העסק (לדוגמה: CVE במערכת התשלומים מקבלת עדיפות על פני CVE בפורטל העובדים).
- שליחת התראות באצוות שעתיות (לא בזמן אמת), עם סיכום ניהולי של 3 שורות.
דוגמה להתראה מעובדת (פורמט Slack):
🚨 *התראה קריטית* (CVSS 9.8 | EPSS 0.85)
*CVE-2023-4863* - גלישת חוצץ בערימה ב-libwebp (Chrome, Firefox, Electron)
*מושפעים*: 12 שרתים (frontend + מיקרוסרביסים של תמונות)
*וקטור*: RCE באמצעות קובץ webp זדוני (ניצול פעיל דווח על ידי CISA)
*תיקון*: זמין עבור Chrome 116.0.5845.187+, Firefox 117.0.1+
*פעולות מומלצות*:
1. החלת תיקונים בשרתי ייצור (עדיפות: frontend)
2. חסימת קבצי webp ב-WAF עד להשלמת התיקונים
*קישור*: https://nvd.nist.gov/vuln/detail/CVE-2023-4863
פורמט זה מצמצם את הרעש ב-90% ומאפשר לצוות של 3 אנשים לנהל כ-500 נכסים ללא הצפה. במקרה אמיתי (חברת e-commerce עם 80 שרתים), זמן התגובה הממוצע ל-CVE קריטי ירד מ-48 שעות ל-6 שעות.
זמן תגובה וחלונות חשיפה: מדדים שאיש לא מפרסם
הספרות האקדמית וספקי הכלים נוטים להתעלם ממדדי זמן התגובה האמיתיים במערכות ניטור. מדדנו שלושה חלונות קריטיים בצינור שלנו:
| מדד | הגדרה | ערך טיפוסי (הצינור שלנו) | ערך טיפוסי (כלים מסחריים) |
|---|---|---|---|
| T1: פרסום → זיהוי | זמן מרגע ש-NVD מפרסמת את ה-CVE עד שהמערכת שלנו מזהה אותה. | 15-30 דקות | 2-4 שעות |
| T2: זיהוי → תעדוף | זמן מרגע הזיהוי עד שה-CVE מתועדף (CVSS + EPSS + הקשר מקומי). | 5-10 דקות | 30-60 דקות |
| T3: תעדוף → התראה | זמן מרגע התעדוף עד שההתראה מגיעה לצוות (כולל סריקה אקטיבית עם Nuclei). | 20-40 דקות | 1-2 שעות |
| חלון כולל (T1+T2+T3) | זמן כולל מרגע פרסום ה-CVE עד להתראה לצוות. | 40-80 דקות | 4-7 שעות |
החלון הכולל של 40-80 דקות מהיר פי 3-5 מכלים מסחריים שנבדקו (לדוגמה: Tenable.io, Qualys), אך עם פשרה: נדרש תחזוקה אקטיבית של מלאי הנכסים ועדכון שבועי של תבניות ה-Nuclei. עבור צוותים קטנים, פשרה זו מקובלת מכיוון:
- 80% מה-CVE הקריטיים מנוצלים תוך 24 שעות מפרסומם (מקור: CISA AA23-215A).
- צמצום אזעקות השווא מפצה על המאמץ הידני.
מקרה קיצוני: CVE-2023-34362 (MOVEit Transfer). הצינור שלנו זיהה את ה-CVE 18 דקות לאחר פרסומה ב-NVD, תעדף אותה תוך 7 דקות (CVSS 9.8, EPSS 0.92, השפיעה על 3 שרתים בייצור), ויצר התראה עם המלצות למיתון תוך 32 דקות. הצוות החיל את התיקון תוך שעתיים, לפני שנרשמו ניצולים המוניים.
טעויות נפוצות (ואיך להימנע מהן)
במהלך הטמעת צינור זה ב-12 חברות באמריקה הלטינית (2022-2024), זיהינו דפוסי כשל חוזרים:
- הסתמכות רק על CVSS:
- בעיה: 40% מה-CVE עם ציון CVSS ≥9.0 לא מנוצלים מעולם (מקור: ניתוח של FIRST על EPSS).
- פתרון: שימוש ב-EPSS כסינון משני, גם אם נדרשת אינטגרציה של הזנה נוספת.
- אי-נרמול CPE:
- בעיה: השדה
cpe23Uriב-NVD אינו עקבי. לדוגמה,cpe:2.3:a:apache:tomcat:9.0.68:*:*:*:*:*:*:*אינו מבחין בין Tomcat 9.0.68 פגיע למתוקן. - פתרון: שימוש בטבלת מיפוי CPE → גרסה פגיעה/מתוקנת (לדוגמה:
cpe:2.3:a:apache:tomcat:9.0.68:-:*:*:*:*:*:*לפגיע,cpe:2.3:a:apache:tomcat:9.0.68:*:*:*:*:*:*:*למתוקן).
- בעיה: השדה
- סריקה אקטיבית ללא הקשר:
- בעיה: סריקת כל הנכסים עם OpenVAS/Nuclei ללא סינון לפי CVE מתועדפים יוצרת רעש ועלולה להשפיע על שירותים בייצור.
- פתרון: שימוש בסריקות ממוקדות (לדוגמה:
nuclei -t cves/CVE-2023-XXXX.yaml -u https://example.com).
- התראות בזמן אמת:
- בעיה: התראה על כל CVE מתועדף יוצרת עייפות. במקרה אחד, צוות קיבל 47 התראות תוך שעתיים על CVE בתוכנה EOL.
- פתרון: קיבוץ התראות לפי וקטור תקיפה ושליחת אצוות שעתיות.
- אי-אימות תיקונים:
- בעיה: החלת תיקונים ללא אימות יעילותם (לדוגמה: התיקון ל-Log4j 2.15.0 היה חלקי ונדרש 2.16.0).
- פתרון: סריקה חוזרת עם Nuclei/OpenVAS לאחר החלת תיקונים.
ניטור CVE בזמן אמת אינו בעיה טכנית, אלא בעיה של תכנון תהליכים. צינור בנוי היטב חייב לאזן בין מהירות, דיוק ומדרגיות עבור צוותים קטנים. הארכיטקטורה המתוארת כאן — הזנות JSON של NVD, תעדוף עם CVSS/EPSS, סריקה אקטיבית עם Nuclei והתראות מקובצות — הוכיחה צמצום חלון החשיפה לפחות מ-2 שעות בסביבות אמיתיות, בעלות תפעולית מינימלית. ב-CyberShield, אנו ממשיכים לחדד גישה זו עבור עסקים קטנים ובינוניים באמריקה הלטינית, שם המשאבים מוגבלים אך האיומים אינם סולחים על עיכובים.
מקורות
- NIST National Vulnerability Database (NVD). (2024). NVD JSON Feeds Documentation. Retrieved from https://nvd.nist.gov/vuln/data-feeds#JSON_FEED
- FIRST. (2024). Exploit Prediction Scoring System (EPSS). Retrieved from https://www.first.org/epss/
- ProjectDiscovery. (2024). Nuclei Documentation. Retrieved from https://docs.projectdiscovery.io/tools/nuclei
- Greenbone Networks. (2024). OpenVAS Documentation. Retrieved from https://www.openvas.org/
- CISA