SIEM ו-SOAR בלי alert fatigue: גישת Detection Engineering

כמעט לכל SOC שאנחנו נכנסים אליו יש את אותו ערוץ Slack: 200 עד 600 התראות high-severity בשבוע, on-call rotation שהפסיק לקרוא אותן בקפידה, ודשבורד SIEM שהצוות בודק פעם אחת בתחילת כל משמרת. ההנהלה שואלת למה כיסוי הזיהוי נראה נמוך כש-SIEM מפיץ כל הזמן. התשובה היא הפער בין זיהוי לבין התראה, והפער הזה הוא מה ש-detection engineering סוגר.

זה מודל ההפעלה שאנחנו משתמשים בו כדי לקחת SOC מותש ל-SOC מדוד. הוא עובד כי הוא לוקח את הרעיונות הנכונים מהנדסת תוכנה (versioning, testing, deprecation) ומיישם אותם על תוכן זיהוי במקום על ה-stack כולו. החלקים הטכנולוגיים זהים לפני, מה שמשתנה זה משמעת ההפעלה.

מה detection engineering באמת אומר

Detection engineering מתייחס לכל alert rule, correlation, ו-SOAR automation כקטע קוד מתוחזק. לכל detection יש בעלים, התנהגות יריב מתועדת שהוא טוען לזהות, מקרה בדיקה שמדגים שה-detection מופעל, שיעור false-positive נמדד על פני חלונות זמן מתגלגלים, מדיניות deprecation, ותרומה מתועדת לאירועים.

בתוכנית בריאה מנהלים את זה כמעט כמו שמנהלים קוד של שירות תוכנה: pull requests לזיהויים חדשים, code review של ה-detection engineer הראשי, CI pipeline שמריץ כל detection מול corpus של אירועים סינתטיים, פריסה תחת version control, ודשבורדים שמדווחים על מדדי בריאות ברמת ה-detection לאורך זמן.

רוב ה-SOC-ים לא עובדים ככה. הם עובדים בצורה ששיווק ה-SIEM רמז עליה: כללים נוספים על-ידי אנליסטים בתגובה לאירועים או המלצות ספק, אף פעם לא נמחקים, אף פעם לא נמדדים על fidelity, ואף פעם לא נבדקים. התוצאה, אחרי 18 עד 36 חודשי הפעלה, היא בעיית נפח ההתראות.

למה נפח התראות גבוה הוא נדיר בעיה של כלי

הרפלקס כשנפח התראות גבוה הוא לחפש כלי שמסכם טוב יותר. UEBA, פיצ'רי SIEM מבוססי ML, triage בעזרת AI, כולם מבטיחים להוריד רעש. לפעמים הם עושים את זה, בשוליים. אבל הסיבה המבנית של alert fatigue כמעט לעולם לא היא ש-SIEM גרוע במתמטיקה. היא שתוכן הזיהוי לא מתוחזק.

SOC טיפוסי שאנחנו בודקים יש בו בין 200 ל-1,500 כללי זיהוי בפרודקשן. כשאנחנו דוגמים אותם, אנחנו בדרך כלל מוצאים:

• 30–45% מהכללים לא הפיקו התראות ב-90 הימים האחרונים
• 15–30% מהכללים הפיקו יותר מ-100 התראות ב-30 הימים האחרונים, מתוכן פחות מ-1% נחקרו
• 10–25% מהכללים הם כפולים עם לוגיקת פילטר מעט שונה, כולם מופעלים על אותם אירועי מקור
• 5–15% מהכללים מזהים טכניקות יריב שהסביבה לא חשופה אליהן בפועל (לדוגמה, דפוסי תקיפת AD on-prem בחנות 100% cloud-native)

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

מחזור החיים של detection

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

Proposed: טכניקת יריב קיימת ב-threat model, עוד אין כלל. ה-detection engineer כותב כלל ו-corpus בדיקה.

Tuning: הכלל בפרודקשן אבל פולט ל-stream שלא מתקשר ל-on-call. המהנדס מודד שיעור FP מול תעבורה אמיתית במשך שבועיים עד ארבעה. מכייל לוגיקת פילטר. מוסיף שדות הקשר שהאנליסט יצטרך.

Active: הכלל עומד בסף fidelity (בדרך כלל <5% FP, לפעמים יותר לכללי high-severity), קורא ל-on-call, יש לו runbook, יש לו בעלים. נספר במדדי כיסוי.

At-risk: הכלל התדרדר, או דרך עליית שיעור FP, ירידה בקצב הפעלה, או שינוי סביבתי. מפעיל review.

Deprecated: הכלל הוסר מפרודקשן עם סיבה רשומה. צריך להוות 10–30% מתחלופת הכללים שנתית בתוכנית בריאה.

SOC שלא יכול לומר באיזה שלב כל כלל נמצא, אין לו תוכנית זיהוי. יש לו ערימת כללים. ערימת הכללים מייצרת alert fatigue ללא קשר לכמה ה-SIEM שמתחת טוב.

SOAR הוא לא מה שרוב הצוותים חושבים שהוא

שוק ה-SOAR הבטיח במקור "אוטומציה ל-triage". בפועל, ההבטחה הזו תורגמה ל-playbooks שמעשירים התראות עם מידע reputation, מבצעים queries לכמה מקורות, ומציגים לאנליסט התראה מעט יותר מהודרת. זה לא כלום, אבל זה גם לא המינוף ש-SOAR יכול לתת.

איפה ש-SOAR מצדיק את עצמו זה בשני דפוסים צרים:

1. אוטומציה של containment לזיהויים בעלי ביטחון גבוה. כש-detection יש לו שיעור false-positive נמדד של פחות מ-2% במשך שישה חודשים, אפשר לעבור מהעשרה לפעולה. בידוד אוטומטי של endpoint שמפעיל זיהוי credential-theft, השעיה אוטומטית של זהות שמבצעת רצף ידוע-רע של פעולות ענן, סיבוב אוטומטי של credential שנמצא חשוף. הכלכלה של זה דורשת אמון ב-detection הבסיסי, מה שאומר שארבע משמעות מחזור החיים של ה-detection חייבות להתקיים קודם.

2. playbooks חקירה שמקודדים מומחיות אנליסט. במקום לאוטמט החלטות, אוטמטו את האיסוף. SOAR playbook ש-on alert של פישינג מושך את האימייל המקורי, היסטוריית האימות של המשתמש, מצב המכשיר, וכל התאמות email-cluster, מציג את זה כ-artefact יחיד. האנליסט עדיין מחליט. האנליסט חוסך 20 דקות של pivoting להתראה. על אלף התראות בחודש, זו קיבולת אמיתית.

SOAR בדרך כלל נפרס כדבר הראשון שצוותים קונים אחרי SIEM, לפני ששניהם מייצרים סיגנל אמין. זה הסדר השגוי. אוטמטו אחרי שתוכן הזיהוי בריא, לא לפני.

איך נראה SOC מדוד

מהניסיון שלנו, SOC שמריץ detection engineering היטב מציג חתימות כמותיות ספציפיות:

• ספירת זיהויים פעילים יציבה או גדלה לאט, עם deprecation סדיר
• שיעור false-positive ממוצע על פני זיהויים פעילים מתחת ל-10%
• חציון זמן ל-triage מתחת ל-20 דקות לזיהויים שקוראים ל-on-call
• 70%+ מההתראות שקוראות יש להן runbook שהאנליסט יכול לעקוב אחריו בלי escalation
• מדדי כיסוי קשורים ל-threat model, לא ל-MITRE heatmap של ספק
• כל אירוע גדול בשנתיים האחרונות הפיק לפחות זיהוי חדש אחד

אם SOC לא יכול להפיק את המספרים האלה, התשובה ל"למה כיסוי הזיהוי נמוך?" היא מכנית. העבודה היא במשמעת של תוכן הזיהוי, לא ברכישת כלי נוסף.

איפה אנחנו נכנסים

תחום SIEM ו-SOAR של פליקן-טק בונה את מודל ההפעלה של detection engineering למעלה על איזה SIEM שהלקוח כבר מריץ (Sentinel, Splunk, Elastic, Chronicle). אנחנו מתחילים עם מצאי זיהויים, מסווגים את ערימת הכללים מול מחזור החיים בן חמשת השלבים, מוחקים בעוצמה, ובונים מחדש את הסט הפעיל עם corpus בדיקות נכון ומעקב fidelity. אז אנחנו ממקמים SOAR לשני הדפוסים שבהם הוא באמת משלם את עצמו. אנחנו עובדים יחד עם צוות אבטחת הענן כשלוגי control-plane של ענן הם המקור הדומיננטי, ועם פרקטיקת ניהול הסיכונים שלנו כדי לכוון כיסוי ל-threat model במקום ל-heatmap של פריימוורק ספק.

אם ה-SOC שלכם מריץ 200+ התראות בשבוע ואנליסטים נראים מותשים, זו השיחה שצריך לעשות איתנו לפני רכישת כלי נוסף.