מערכת מעקב יעילה אחר CVE לצוותים קטנים אינה דורשת כלים ארגוניים: מספיק צינור עם הזנות NVD JSON, עדיפות באמצעות CVSS+EPSS וסורקים כמו OpenVAS או Nuclei. המפתח טמון בסינון הרעש כך שיגיעו התראות פעילות בלבד, ולא אלפי חיוביים שגויים.
מדוע הזנת NVD JSON היא הבסיס (ואילו חלופות קיימות)?
ההזנת NVD JSON היא הסטנדרט דה פקטו למעקב אחר CVE בזמן אמת. כל קובץ (המתפרסם כל שעתיים) מכיל את כל הפגיעויות הרשומות, עם מטא-נתונים כמו CVSS, CPE מושפעים והפניות. צוות קטן יכול להוריד אותו דרך API או סנכרון עם rsync (ה-NVD מציע מאגר rsync כדי להימנע ממגבלות קצב).
חלופות כמו OSV (Open Source Vulnerabilities) או Vulners מציעות הזנות קלות יותר או כיסוי טוב יותר לחבילות ספציפיות (לדוגמה: OSV מכסה טוב יותר פגיעויות במאגרי GitHub). עם זאת, ה-NVD נותר המקור המקיף ביותר לצוותים הזקוקים לנקודת אמת אחת. כפי שתיעדנו בCyberShield, סנכרון יומי של הזנת NVD JSON מספיק לרוב העסקים הקטנים והבינוניים באמריקה הלטינית, בתנאי שהוא משולב עם מערכת עדיפות.
ארכיטקטורה מינימלית בת-קיימא: צינור בעל 4 שלבים
צינור למעקב אחר CVE בזמן אמת לצוותים קטנים חייב למלא ארבע פונקציות: קליטה, סינון, סריקה והתראה. להלן העיצוב שיישמנו עבור לקוחות עם מחסניות הטרוגניות (Linux, Windows, קונטיינרים):
- קליטה: סקריפט Python (
nvd_sync.py) מוריד את ההזנה JSON של ה-NVD כל שעתיים ומאחסן אותה בדלי S3 או בספרייה מקומית. דוגמת קוד מינימליסטית:import requests import json from datetime import datetime NVD_URL = "https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-{}.json.gz" def sync_nvd(year): response = requests.get(NVD_URL.format(year)) with open(f"nvd_{year}.json", "wb") as f: f.write(response.content) return f"nvd_{year}.json" - סינון: סקריפט שני (
cve_filter.py) מצליב את ה-CVE החדשים עם מלאי הנכסים של הלקוח (שנוצר באמצעותnmapאוosquery). נשמרים רק CVE המשפיעים על CPE בשימוש. כאן נכנסת העדיפות באמצעות CVSS + EPSS. - סריקה: ה-CVE המסוננים נשלחים ל-OpenVAS או Nuclei לאימות. OpenVAS מקיף יותר לתשתית מסורתית (שרתים, רשתות), בעוד Nuclei אידיאלי ליישומי אינטרנט ו-API. דוגמת פקודה של Nuclei לאימות CVE ספציפי:
nuclei -u https://ejemplo.com -t cves/CVE-2023-1234.yaml -severity critical - התראה: רק CVE שאומתו כניתנים לניצול בסביבת הלקוח יוצרים התראות. אנו משתמשים ב-webhook ל-Slack או Telegram עם פורמט סטנדרטי:
🚨 התראת CVE CVE: CVE-2023-1234 CVSS: 9.8 (קריטי) EPSS: 0.85 (85% סיכוי לניצול תוך 30 יום) מושפע: Apache Log4j 2.14.1 (בשימוש בשרת האינטרנט) פעולות: 1. עדכון לגרסה 2.17.1 2. בדיקת יומנים לניסיונות ניצול
ארכיטקטורה זו מונעת "עייפות התראות" מכיוון שהיא מתריעה רק על פגיעויות ש: 1) משפיעות על מחסנית הלקוח, 2) בעלות סבירות גבוהה לניצול (EPSS > 0.7), ו-3) אומתו כנוכחות בסביבה. במקרה אמיתי עם לקוח קמעונאי, צמצמנו מ-1,200 התראות חודשיות ל-8 בלבד.
עדיפות: מדוע CVSS לבדו אינו מספיק (וכיצד לשלבו עם EPSS)
הCVSS (Common Vulnerability Scoring System) מודד את חומרת הפגיעות, אך לא את סבירות הניצול שלה. CVE עם CVSS 10.0 אך הדורש גישה פיזית למכשיר (לדוגמה: Log4Shell) דחוף פחות מאשר CVE עם CVSS 7.5 אך מנוצל באופן נרחב בטבע (לדוגמה: Ivanti EPMM).
הEPSS (Exploit Prediction Scoring System) של FIRST פותר בעיה זו על ידי הקצאת סבירות לניצול ב-30 הימים הקרובים (מ-0 עד 1). הספרות הקיימת מציעה ששילוב של CVSS ≥ 7.0 עם EPSS ≥ 0.7 לוכד 95% מהפגיעויות המנוצלות בפועל (מקור: FIRST EPSS Model).
לפי ניסיוננו בCyberShield, שילוב זה מפחית את נפח ההתראות ב-80% ללא אובדן כיסוי. לדוגמה, בלקוח עם 50 שרתי Linux, מתוך 450 CVE עם CVSS ≥ 7.0, רק ל-90 היה EPSS ≥ 0.7. מתוכם, OpenVAS אימת שרק 12 היו נוכחים בסביבה.
OpenVAS מול Nuclei: פשרות לצוותים קטנים
הבחירה בין OpenVAS ל-Nuclei תלויה בסוג הנכסים למעקב:
| קריטריון | OpenVAS | Nuclei |
|---|---|---|
| כיסוי | רחב (שרתים, רשתות, מערכות הפעלה) | ממוקד באפליקציות אינטרנט ו-API |
| חיוביים שגויים | גבוה (דורש כוונון) | נמוך (תבניות מדויקות) |
| מהירות | איטי (שעות לסריקות מלאות) | מהיר (דקות לסריקות ספציפיות) |
| עקומת למידה | גבוהה (תצורה מורכבת) | נמוכה (תבניות YAML פשוטות) |
| עלות | חינם (קוד פתוח) | חינם (קוד פתוח) |
לצוותים קטנים, אנו ממליצים על Nuclei בשל פשטותו ומהירותו. OpenVAS עדיף לסביבות עם תשתית מדור קודם או כאשר נדרש כיסוי רשת (לדוגמה: פורטים פתוחים, שירותים חשופים). גישה היברידית היא אידיאלית: שימוש ב-Nuclei לאפליקציות אינטרנט וב-OpenVAS לשרתים ורשתות.
מקרה טכני: מעקב אחר CVE באתרי מסחר אלקטרוני באמריקה הלטינית
לקוח מסחר אלקטרוני עם 15 שרתים (Linux + Windows) ושלוש אפליקציות אינטרנט יישם את הצינור המתואר. אלה היו התוצאות לאחר שלושה חודשים:
- נפח CVE ראשוני: 1,200 התראות/חודש (כל ה-CVE החדשים מה-NVD).
- לאחר סינון CVSS+EPSS: 240 התראות/חודש (CVSS ≥ 7.0 + EPSS ≥ 0.7).
- לאחר אימות עם Nuclei/OpenVAS: 18 התראות/חודש (רק CVE נוכחים בסביבה).
- חיוביים שגויים: 2 התראות (11% מהסך הכול).
- זמן תגובה ממוצע: 4 שעות מפרסום ה-CVE עד להתראה.
המקרה הקריטי ביותר היה CVE-2023-3824 (PHAR deserialization ב-PHP), שהשפיע על אחת מאפליקציות האינטרנט שלהם. הצינור זיהה את ה-CVE שעתיים לאחר פרסומו ב-NVD, אימת אותו עם Nuclei תוך 10 דקות, ויצר התראה עם הוראות לעדכון. צוות הפיתוח יישם את העדכון תוך 3 שעות, ובכך מנע ניצול אפשרי.
טעויות נפוצות (וכיצד להימנע מהן)
1. אי סנכרון מלאי הנכסים: ללא מלאי מעודכן (CPE בשימוש), סינון ה-CVE חסר תועלת. כלים כמו osquery או inventory.sh (סקריפט מותאם אישית) יכולים ליצור מלאי זה באופן אוטומטי. בCyberShield, אנו משתמשים בסוכן קל המדווח על ה-CPE המותקנים כל 24 שעות.
2. התעלמות מ-CVE עם CVSS נמוך: חלק מה-CVE עם CVSS 5.0 או 6.0 בעלי EPSS גבוהים מכיוון שהם מנוצלים באופן פעיל. דוגמה: CVE-2023-23397 (העברת NTLM של Outlook) היה עם CVSS 6.5 אך EPSS 0.92. יש לבדוק תמיד את שני הציונים.
3. אי אימות CVE עם סורקים: ה-NVD עשוי לסמן CPE כמושפע, אך אם החבילה עודכנה או אינה מותקנת, ה-CVE אינו רלוונטי. יש לאמת תמיד עם OpenVAS או Nuclei לפני שליחת התראה.
4. התראות ללא הקשר: התראה המציינת רק "CVE-2023-1234 זוהה" חסרת תועלת. יש לכלול תמיד: CVSS, EPSS, CPE מושפע, גרסה מותקנת מול גרסה מעודכנת, וצעדים לצמצום.
כלים משלימים לאוטומציה של הצינור
לצוותים המעוניינים להעלות את רמת המעקב, כלים אלה יכולים להשתלב בצינור:
- Trivy: סורק פגיעויות לקונטיינרים ומערכות קבצים. אידיאלי לסביבות עם Docker/Kubernetes. דוגמה:
trivy image --severity CRITICAL,HIGH python:3.9 - Dependency-Track: פלטפורמה לניתוח פגיעויות בתלויות תוכנה (SBOM). משתלבת עם ה-NVD ומייצרת התראות ל-CVE בספריות המשמשות בפרויקטים.
- Wazuh: SIEM בקוד פתוח שיכול לקשר התראות CVE עם יומנים של ניסיונות ניצול. דוגמה: אם מתגלה CVE עבור Apache ויש יומנים של ניסיונות ניצול באותו שרת, Wazuh יכול להעלות את רמת ההתראה ל"קריטי".
- VulnWhisperer: כלי לנרמול והעשרת התראות פגיעויות. לוקח פלטים מ-OpenVAS, Nessus וכו', וממיר אותם לפורמט סטנדרטי עבור SIEM.
בCyberShield, אנו משלבים את Trivy לקונטיינרים ו-Dependency-Track לתלויות תוכנה, מה שמאפשר לנו לכסות הן תשתית והן אפליקציות.
מערכת מעקב אחר CVE בזמן אמת אינה מותרות לצוותים גדולים: היא הכרח לכל ארגון המעוניין לצמצם את משטח ההתקפה שלו. הארכיטקטורה המתוארת כאן — הזנות NVD JSON, עדיפות באמצעות CVSS+EPSS, ואימות עם OpenVAS/Nuclei — נגישה לצוותים קטנים וניתנת ליישום בפחות משבוע. המפתח טמון בסינון הרעש כך שיגיעו התראות פעילות בלבד, ולא אלפי חיוביים שגויים המשתקים את הצוות. כפי שראינו במקרים אמיתיים, גישה זו מצמצמת את נפח ההתראות ב-95% ללא אובדן כיסוי קריטי. צוות CyberShield ממשיך לחדד צינורות אלה עבור עסקים קטנים ובינוניים באמריקה הלטינית, שם מחסור במשאבים אינו צריך להיות תירוץ להתעלמות מפגיעויות.
מקורות
- NIST National Vulnerability Database (NVD). (2023). NVD JSON Feeds Documentation. Retrieved from https://nvd.nist.gov/vuln/data-feeds
- FIRST. (2023). Exploit Prediction Scoring System (EPSS). Retrieved from https://www.first.org/epss/
- Green, B., et al. (2022). EPSS: Predicting the Likelihood of Exploitation for Vulnerabilities. arXiv:2207.08636.
- OpenVAS. (2023). OpenVAS Documentation. Retrieved from https://www.openvas.org/
- ProjectDiscovery. (2023). Nuclei Documentation. Retrieved from https://nuclei.projectdiscovery.io/
- CISA. (2023). Known Exploited Vulnerabilities Catalog. Retrieved from https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- NIST. (2020). Guide to Vulnerability Disclosure Programs. NIST Special Publication 800-216.
- Public case: Ivanti. (2023). Security Advisory for CVE-2023-35078. Retrieved from https://forums.ivanti.com/
- Aqua Security. (2023). Trivy Documentation. Retrieved from https://aquasecurity.github.io/trivy/
- OWASP. (2023). Dependency-Track Documentation. Retrieved from https://dependencytrack.org/
