מערכת מעקב בזמן אמת אחר CVE אינה דורשת תקציבי עתק או צוותים של 50 איש. באמצעות הזנת JSON של NVD, כלים בקוד פתוח כמו Nuclei או OpenVAS, ומתודולוגיית עדיפות חכמה (CVSS + EPSS), צוות קטן יכול לסנן את הרעש ולהתמקד במה שחיוני. להלן הארכיטקטורה המוכחת בה אנו משתמשים ב-CyberShield עבור עסקים קטנים ובינוניים באמריקה הלטינית, עם צינור התראות שאינו מציף את מרכז התפעול האבטחתי (SOC).

מדוע הזנת JSON של NVD היא הבסיס (ומה לא מספרים לכם עליה)?

ההזנת JSON של NVD היא הסטנדרט דה פקטו למעקב אחר פגיעויות, אך אימוצה הישיר טומן מלכודות נסתרות. ראשית, הנפח: בשנת 2023 פרסם NVD 28,902 CVE (מקור: NIST NVD Annual Report 2023), עלייה של 18% לעומת השנה הקודמת. שנית, העיכוב: אף שההזנה מתעדכנת כל שעתיים, הקצאת CVSS ו-CPE עשויה להימשך ימים (או שבועות) עבור פגיעויות מורכבות. שלישית, הגרנולריות: השדה configurations ב-JSON משתמש ב-CPE 2.3, שאינו תמיד מתאים באופן מדויק לנכסים האמיתיים של עסק קטן או בינוני.

הפתרון אינו לזנוח את NVD, אלא להשלימו. ב-CyberShield אנו משתמשים בהזנת JSON כמקור אמת, אך מעשירים אותה באמצעות:

צינור העבודה הבסיסי שאנו ממליצים עליו:

  1. הורדת הזנת JSON של NVD כל שעתיים באמצעות curl או משימת cron.
  2. סינון לפי CPE רלוונטיים באמצעות jq או סקריפט Python (דוגמה: jq '.CVE_Items[] | select(.configurations.nodes[].cpe_match[].cpe23Uri | contains("apache:tomcat"))').
  3. העשרה עם נתוני KEV ו-EPSS (עוד על כך בסעיף העדיפות).
  4. אחסון במסד נתונים קל משקל כמו SQLite או PostgreSQL לצורך שאילתות עתידיות.

עדיפות: CVSS + EPSS + הקשר מקומי (הנוסחה שמפחיתה את הרעש ב-80%)

CVSS שימושי, אך אינו מספיק. CVE עם ציון CVSS 10.0 בתוכנה מיושנת שאינך משתמש בה היא רעש. CVE עם ציון CVSS 7.5 במסד הנתונים הראשי שלך היא קריטית. כאן נכנס לתמונה EPSS (Exploit Prediction Scoring System), שפותח על ידי FIRST, המעריך את הסבירות ש-CVE תנוצל ב-30 הימים הקרובים.

הספרות הקיימת מציעה ששילוב CVSS ו-EPSS משפר את תהליך העדיפות. מחקר של Kenna Security (2021) מצא ש-80% מה-CVE עם EPSS > 0.8 נוצלו בטבע, בעוד שרק 5% מה-CVE עם EPSS < 0.2 נוצלו. ב-CyberShield אנו משתמשים במטריצת העדיפות הבאה:

CVSS \ EPSS EPSS < 0.2 0.2 ≤ EPSS < 0.5 EPSS ≥ 0.5
CVSS < 7.0 עדיפות נמוכה (בדיקה רבעונית) עדיפות בינונית (בדיקה חודשית) עדיפות גבוהה (בדיקה שבועית)
7.0 ≤ CVSS < 9.0 עדיפות בינונית (בדיקה חודשית) עדיפות גבוהה (בדיקה שבועית) קריטי (בדיקה מיידית)
CVSS ≥ 9.0 עדיפות גבוהה (בדיקה שבועית) קריטי (בדיקה מיידית) קריטי (בדיקה מיידית + תיקון תוך 24 שעות)

אך גם למטריצה זו יש מגבלות. לדוגמה, CVE עם ציון CVSS 9.8 ו-EPSS 0.9 בשרת החשוף לאינטרנט צריכה להיחשב כאירוע, ולא כהתראה נוספת. לכן הוספנו שתי שכבות נוספות:

  1. חשיפת נכסים: אנו משתמשים בכלים כמו nmap או masscan כדי למפות אילו נכסים חשופים לאינטרנט. CVE בנכס פנימי ללא גישה חיצונית יורדת אוטומטית ברמה במטריצה.
  2. ניצולים ציבוריים: אנו מתייעצים עם מסדי נתונים כמו Exploit-DB או GitHub Trickest CVE כדי לוודא אם קיימים ניצולים ציבוריים זמינים. אם קיימים, ה-CVE עולה ברמה.

התוצאה: אצל לקוח עם 50 נכסים, עברנו מ-1,200 התראות חודשיות ל-45, מתוכן רק 5 דרשו פעולה מיידית.

כלים בקוד פתוח לסריקה: Nuclei מול OpenVAS (ולמה בחרנו באחד)

לאחר קביעת העדיפות ל-CVE, השלב הבא הוא לוודא אם הן קיימות בתשתית שלך. כאן יש שני כלים דומיננטיים בקוד פתוח: OpenVAS (כיום חלק מ-Greenbone) וNuclei (של ProjectDiscovery). לשניהם יתרונות וחסרונות.

OpenVAS: הוותיק עם עומק (אך איטי)

OpenVAS הוא סורק פגיעויות בוגר, עם יותר מ-50,000 בדיקות במסד הנתונים שלו. יתרונותיו:

אך יש לו גם חסרונות:

Nuclei: הזריז עם תבניות הניתנות להתאמה אישית (אך כיסוי מוגבל)

Nuclei הוא סורק מבוסס תבניות YAML, שתוכנן להיות מהיר ומודולרי. יתרונותיו:

חסרונותיו:

הבחירה שלנו: Nuclei + סריקות סלקטיביות של OpenVAS

ב-CyberShield אנו משתמשים בגישה היברידית:

  1. Nuclei לסריקות יומיות: אנו מריצים את Nuclei כל לילה במצב "סריקה מהירה" כדי לזהות CVE קריטיות בנכסים החשופים לאינטרנט. התבניות מתעדכנות אוטומטית מהמאגר של ProjectDiscovery.
  2. OpenVAS לסריקות שבועיות עמוקות: פעם בשבוע אנו מריצים את OpenVAS במצב "סריקה עמוקה" בנכסים פנימיים או קריטיים. זה נותן לנו כיסוי עבור CVE ש-Nuclei עשוי היה לפספס.
  3. תבניות מותאמות אישית לנכסים קריטיים: עבור שרתי מסדי נתונים או יישומים ישנים, אנו כותבים תבניות מותאמות אישית ב-Nuclei כדי לזהות פגיעויות ספציפיות.

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

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

מערכת מעקב אחר CVE אינה מועילה אם ההתראות מציפות את הצוות. אצל לקוח עם 200 נכסים, עברנו מ-300 התראות יומיות ל-2-3, באמצעות הטכניקות הבאות:

1. קיבוץ לפי נכס וסוג פגיעות

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

2. הקשר בהתראות (לא רק "CVE-2023-1234 זוהתה")

התראה שימושית כוללת:

דוגמה להתראה אמיתית שאנו שולחים:

התראה קריטית: CVE-2023-46604 בשרת-web-01 (192.168.1.10)

CVE: CVE-2023-46604 (CVSS: 9.8, EPSS: 0.95)

חשיפה: חשוף לאינטרנט בפורט 8080 (Apache ActiveMQ).

ניצולים ציבוריים: כן (מודול Metasploit זמין).

המלצה: עדכון ל-ActiveMQ 5.15.16 או יישום תיקון זמני (ראה קישור).

פעולות שננקטו: השרת בודד מהרשת הפנימית כצעד זמני.

3. הסלמה אוטומטית לפי עדיפות

אנו משתמשים במערכת הסלמה בשלושה שלבים:

  1. עדיפות נמוכה/בינונית: נרשמות בלוח מחוונים (Grafana) ונבדקות בישיבת האבטחה השבועית.
  2. עדיפות גבוהה: נשלחת התראה ב-Slack/Teams לצוות האבטחה, עם SLA של 24 שעות לבדיקה.
  3. עדיפות קריטית: נשלחת התראה ב-Slack/Teams וגם SMS לאחראי התורן, עם SLA של שעה. בנוסף, נפתח אוטומטית כרטיס ב-Jira עם עדיפות "Highest".

4. אינטגרציה עם כלים לניהול כרטיסים ותגובה

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

מקרה אמיתי: כיצד זיהינו ותיקנו את CVE-2023-46604 תוך 3 שעות

ב-27 באוקטובר 2023, Apache הודיעה על CVE-2023-46604, פגיעות Remote Code Execution ב-ActiveMQ עם ציון CVSS 9.8. כך המערכת שלנו טיפלה בה:

1. זיהוי (שעה 0:00)

2. קביעת עדיפות (שעה 0:05)

3. אימות (שעה 0:30)

4. תיקון (שעה 1:30)

5. תיקון סופי (שעה 3:00)

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

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

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

1. הסתמכות רק על CVSS

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

2. אי עדכון מלאי הנכסים

מערכת מעקב אחר CVE טובה ככל שמלאי הנכסים שלה. אם אינך יודע אילו תוכנות יש לך, לא תוכל לסנן את ה-CVE הרלוונטיות. השתמש בכלים כמו osquery או inventory.sh כדי לשמור על מלאי מעודכן באופן אוטומטי.

3. סריקת הכל, כל הזמן

סריקות עמוקות כמו אלו של OpenVAS צורכות משאבים רבים ועלולות להשפיע על זמינות המערכות. התמקד בנכסים קריטיים והשתמש בסריקות קלות (כמו Nuclei) עבור השאר.

4. אי אינטגרציה עם זרימת העבודה של הצוות

אם ההתראות לא מגיעות לצוות הנכון בפורמט הנכון, הן לא יהיו שימושיות. ודא שאתה משלב את הצינור עם הכלים שהצוות כבר משתמש בהם (Slack, Jira וכו').

5. התעלמות מ-CVE "ישנות"

צוותים רבים מתמקדים רק ב-CVE חדשות, אך הישנות עדיין מנוצלות. לדוגמה, CVE-2017-5638 (Apache Struts) עדיין הייתה אחת הפגיעויות המנוצלות ביותר בשנת 2023 (מקור: CISA KEV). ודא שהמערכת שלך עוקבת גם אחרי CVE ישנות בנכסים שלך.

6. אי בדיקת התיקונים לפני יישומם

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

ב-CyberShield תיעדנו את הטעויות הללו (וכיצד להימנע מהן) בבסיס הידע הפנימי שלנו