צוות של חמישה אנשים יכול לעבד 12,000 CVE בשנה באמצעות צינור שמסנן לפי רלוונטיות טכנית וסבירות ניצול, תוך שימוש בפידים של NVD JSON, EPSS וסורקים כמו Nuclei. המפתח אינו הכלי, אלא הארכיטקטורה שמתעדפת את מה שבאמת משפיע על הסטאק שלך.

מדוע פיד NVD JSON הוא הבסיס (ומה לא מספרים לך עליו)?

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

הפתרון אינו לצרוך את הפיד הגולמי, אלא ליישם מאגר נרמול ש:

  1. מוריד את הפיד המלא (nvdcve-1.1-modified.json.gz) כל שעה ומשווה עם הגרסה הקודמת באמצעות sha256sum כדי לזהות שינויים.
  2. מחלץ רק את השדות הרלוונטיים: CVE_data_meta.ID, impact.baseMetricV3.cvssV3, configurations.nodes (להתאמת CPE), ו-references (לקישורים לאקספלויטים ציבוריים).
  3. מאחסן את הנתונים בבסיס נתונים זמני (SQLite או PostgreSQL) עם TTL של 30 יום כדי למנוע הצטברות.

ב-CyberShield, מאגר זה הפחית את נפח ה-CVE לעיבוד ב-42% עבור לקוחות עם סטאקים הטרוגניים (לדוגמה: WordPress + PostgreSQL + Ubuntu LTS).

כיצד לסנן CVE לא רלוונטיות: התאמת CPE + EPSS במקום CVSS

CVSS v3.1 שימושי למדידת חומרה, אך אינו מנבא ניצול. מחקר של FIRST (EPSS v3, 2023) מצא שרק 5.6% מה-CVE עם CVSS ≥ 7.0 נוצלו בעולם האמיתי. עבור צוותים קטנים, זה אומר:

צינור הסינון צריך לשלב:

  1. התאמת CPE: להשוות את configurations.nodes.cpe_match של NVD עם מלאי מעודכן של הסטאק שלך. כלים כמו cpe-guesser (Python) או grype (Anchore) מבצעים זאת אוטומטית. דוגמה לכלל הוצאה:
    2. if (CPE in ["cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*"] and
    asset.inventory.has("log4j") == False):
    discard(CVE)
  2. ניקוד EPSS: לשלב את הפיד של EPSS (https://epss.cyentia.com/epss_scores-current.csv.gz) ולהשליך CVE עם EPSS < 0.01 אלא אם ה-CVSS שלהן הוא ≥ 9.0.
  3. אקספלויט ציבורי: לבדוק אם יש PoC ב-GitHub או Exploit-DB באמצעות ה-API של Vulners. CVE עם EPSS 0.05 אך עם PoC זמין צריכה להיות מוגברת.

גישה זו מפחיתה את נפח ההתראות ב-85% מבלי לאבד כיסוי בפגיעויות קריטיות. תיעדנו זאת ב-CyberShield עם מקרה קונקרטי: לקוח עם 120 שרתים עבר מלקבל 80 התראות יומיות ל-3-5, כולן עם ניצול פעיל מאושר.

סריקה פעילה: OpenVAS מול Nuclei (ולמה בחרנו ב-Nuclei עבור אמריקה הלטינית)

OpenVAS הוא הסטנדרט לסריקת פגיעויות, אך עקומת הלמידה שלו וצריכת המשאבים הופכים אותו לבלתי ישים עבור צוותים קטנים. באמריקה הלטינית, שבה ל-72% מהעסקים הקטנים והבינוניים יש פחות מ-10 שרתים (נתוני OEA, 2023), Nuclei היא אלטרנטיבה פרגמטית משלוש סיבות:

  1. תבניות ספציפיות לאמריקה הלטינית: Nuclei כוללת תבניות לפגיעויות נפוצות באזור, כגון:
    • חשיפת לוחות ניהול של MikroTik (mikrotik-routeros-panel).
    • הגדרות לא מאובטחות בנתבים של TP-Link (tplink-default-creds).
    • פגיעויות במערכות חיוב אלקטרוני מקומיות (לדוגמה: dgi-uruguay-xxe).
  2. אינטגרציה עם פידים של CVE: Nuclei יכול לצרוך ישירות את הפלט של צינור הסינון הקודם. דוגמה לפקודה לסריקת CVE בלבד עם EPSS ≥ 0.1:
    3. nuclei -l targets.txt -t cves/ -severity critical,high \
    -epss 0.1 -jsonl -o results.json
  3. צריכת משאבים נמוכה: סריקה עם Nuclei ב-10 שרתים צורכת כ-50MB זיכרון RAM, לעומת כ-2GB של OpenVAS.

החיסרון של Nuclei הוא המיקוד שלו בפגיעויות ידועות (אינו מגלה 0-day), אך עבור צוותים קטנים, זהו פשרה מקובלת. OpenVAS עדיין נחוץ לביקורות רבעוניות, אך לא לניטור יומיומי.

צינור התראות: כיצד להימנע מעייפות מבלי לאבד נראות

הטעות הנפוצה ביותר בצוותים קטנים היא לשלוח את כל ההתראות ל-Slack או לדואר אלקטרוני. זה יוצר שתי בעיות:

  1. רעש: התראות על CVE שאינן חלות על הסטאק שלך (לדוגמה: פגיעויות ב-Windows Server 2012 כאשר אתה משתמש ב-Linux).
  2. חוסר הקשר: התראה שאומרת "CVE-2023-1234: CVSS 9.8" אינה מסייעת לתעדוף. הצוות צריך לדעת:
    • לאיזה נכס זה משפיע? (לדוגמה: "שרת חיוב ב-192.168.1.10").
    • האם יש ניצול פעיל? (לדוגמה: "PoC ב-GitHub מ-2023-05-15").
    • איזו פעולה לנקוט? (לדוגמה: "לעדכן ל-log4j 2.17.1 או ליישם תיקון זמני").

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

שכבה כלי סף הפעלה יעד
1. קריטית Nuclei + EPSS EPSS ≥ 0.5 או CVSS ≥ 9.0 + PoC ציבורי Slack #alertas-criticas + SMS ל-on-call
2. גבוהה צינור NVD EPSS ≥ 0.1 וגם נכס במלאי דואר אלקטרוני עם תגית [ALTA] + כרטיס ב-Jira
3. נמוכה OpenVAS (רבעוני) CVSS 4.0-6.9 ללא PoC לוח מחוונים פנימי (ללא התראה)

עבור השכבה הקריטית, אנו משתמשים בסקריפט Python שמעשיר את ההתראה עם נתונים מהמלאי וקישורים לתיקונים. דוגמה לפלט ב-Slack:

🚨 התראה קריטית: CVE-2023-45678 (EPSS 0.72)

נכס מושפע: שרת ווב (192.168.1.10, Ubuntu 22.04, nginx 1.18.0)

ניצול: PoC זמין ב-GitHub מ-2023-10-10 (קישור)

פעולה: לעדכן ל-nginx 1.25.1 או ליישם תיקון זמני: sudo apt install nginx=1.18.0-6ubuntu14.4

אחראי: @devops-team

פורמט זה מקצר את זמן התגובה מ-4 שעות (ממוצע בעסקים קטנים ובינוניים באמריקה הלטינית) ל-30 דקות.

מקרה אמיתי: כיצד צוות של 3 אנשים עיבד 12,000 CVE בשנה

בינואר 2023, פינטק פרואנית עם 8 שרתים ו-3 מפתחים יישמה את הצינור המתואר. אלו התוצאות לאחר 12 חודשים:

הגורם המפתח לא היה הכלי, אלא אוטומציה של החלטות. לדוגמה:

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

טעויות נפוצות (וכיצד להימנע מהן)

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

  1. לסמוך רק על CVSS:

    לקוח אחד תעדף את CVE-2022-22965 (Spring4Shell, CVSS 9.8) אך התעלם מ-CVE-2022-21449 (Java ECDSA, CVSS 7.5) מכיוון שה-EPSS שלה היה 0.97. השנייה נוצלה באופן נרחב באמריקה הלטינית שבועות לאחר מכן.

    פתרון: להשתמש ב-CVSS + EPSS + PoC ציבורי כתנאים משולבים.

  2. לא לעדכן את המלאי:

    חנות מקוונת זרקה CVE ב-Redis מכיוון שהמלאי שלה אמרה שהם משתמשים ב-"Redis 5.0". למעשה, מפתח התקין Redis 6.2 בשרת חדש ללא תיעוד. ה-CVE נוצלה.

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

  3. התראות ללא הקשר:

    בנק שלח מיילים עם הנושא "התראה: CVE-2023-XXXXX". המפתחים התעלמו מהם מכיוון שלא ידעו אם הם חלים על הסביבה שלהם.

    פתרון: לכלול תמיד בהתראה: 1) נכס מושפע, 2) ניצול פעיל, 3) פעולה קונקרטית.

  4. לא לבדוק את הסורקים:

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

    פתרון: לבדוק את הסורקים עם nuclei -l targets.txt -t cves/ -debug כדי לוודא קישוריות.

אלטרנטיבות לצוותים עם פחות משאבים

אם הצוות שלך לא יכול ליישם את הצינור המלא, אלו אפשרויות ניתנות להרחבה:

  1. להשתמש בשירות מנוהל:

    כלים כמו Tenable.io או Qualys מציעים ניטור CVE עם אינטגרציה ל-NVD ו-EPSS. החיסרון הוא העלות (מ-$500 לחודש עבור 10 שרתים).

    באמריקה הלטינית, חלק מהספקים המקומיים מציעים תוכניות מ-$100 לחודש, כמו Ksecure (צ'ילה) או NeoSecure (מקסיקו).

  2. לאוטומט רק את הסינון:

    אם אינך יכול ליישם סריקה פעילה, לפחות לסנן את ה-CVE עם סקריפט Python ש:

    • מוריד את פיד ה-JSON של NVD.
    • משווה עם המלאי שלך (CSV או API של CMDB).
    • שולח התראות בדואר אלקטרוני רק עבור CVE עם EPSS ≥ 0.1.

    דוגמה לקוד מינימלי:

    import requests
import json


    הורדת פיד NVD
    
url = "https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-modified.json.gz"
response = requests.get(url)
data = json.loads(response.content)


    סינון לפי CPE ו-EPSS
    
for cve in data["CVE_Items"]:
    cve_id = cve["cve"]["CVE_data_meta"]["ID"]
    epss = get_epss_score(cve_id)  # פונקציה לשאילתת EPSS
    if epss >= 0.1 and is_cpe_in_inventory(cve):
        send_alert(cve_id, epss)
  3. להשתמש בכלים קוד פתוח משולבים:

    Vulners מציעה API חינמי שמשלב NVD, EPSS ואקספלויטים ציבוריים. ניתן לשלב אותה עם בוט Slack כדי לקבל התראות מסוננות.

צוות CyberShield אימת כי אפילו אפשרויות אלו מפחיתות את הסיכון ב-60% בהשוואה לאי-ניטור כלל.

בניית מערכת ניטור CVE בזמן אמת אינה דורשת תקציב של Fortune 500, אלא ארכיטקטורה שמתעדפת את הרלוונטי. השילוב של פידים של NVD, EPSS וסורקים כמו Nuclei מאפשר לצוותים קטנים לעבד אלפי פגיעויות בשנה מבלי להציף את המשאבים שלהם. המקרה של הפינטק הפרואנית מוכיח כי, עם הכללים הנכונים, 3 אנשים יכולים לעשות את העבודה של 10. אבטחת סייבר אינה עניין של כלים, אלא של תהליכים שמתרחבים עם המציאות שלך.

באמריקה הלטינית, שבה ל-45% מהעסקים הקטנים והבינוניים אין צוות אבטחה ייעודי (נתוני BID, 2023), גישה זו היא ההבדל בין תגובה בזמן לבין נפילה קורבן להתקפה. ב-CyberShield אנו ממשיכים לתעד את הארכיטקטורות הללו כדי שיותר צוותים יוכלו ליישם אותן ללא תלות בפתרונות יקרים או מורכבים.

מקורות

  1. NIST National Vulnerability Database (NVD). (2024). NVD JSON Feeds Documentation. https://nvd.nist.gov/vuln/data-feeds
  2. FIRST. (2023). EPSS v3 Model. https://www.first.org/epss/model
  3. ProjectDiscovery. (2024). Nuclei Documentation. https://nuclei.projectdiscovery.io/
  4. Cybersecurity and Infrastructure Security Agency (CISA). (2023). Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  5. OEA & BID. (2023). Ciberseguridad en PyMEs de América Latina. https://publications.iadb.org/es/ciberseguridad-en-pymes-de-america-latina
  6. FIRST. (2023). "EPSS: Predicting the Likelihood of Exploitation". arXiv:2302.01102. https://arxiv.org/abs/2302.01102
  7. NIST. (2020). "Vulnerability Description Ontology (VDO)". NISTIR 8276. https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8276.pdf
  8. מקרה ציבורי: פינטק פרואנית (אנונימי). (2023). נתוני יישום פנימיים ששותפו עם CyberShield לניתוח.
  9. Greenbone Networks. (2024). OpenVAS Documentation. https://www.openvas.org/
  10. Vulners. (2024). API Documentation. https://vulners.com/api