בפרקטיקה שלנו, אנו נתקלים לעתים קרובות באיומים פנימיים ובחשבונות שנפרצו—מתקפות המשתמשות באישורים לגיטימיים. זיהוי תוכנות זדוניות מבוסס-חתימות לא עוזר כאן. לכן אנו בונים UEBA (ניתוח התנהגות משתמשים וישויות) על עיקרון שונה: לא "זה איום ידוע," אלא "זו התנהגות חריגה עבור נושא ספציפי." לפי NIST, עד 70% מתקריות האבטחה נותרות בלתי מזוהות על ידי כלים מסורתיים—UEBA ממלא את הפער הזה. מידע נוסף על הטכנולוגיה בויקיפדיה.
מה בדיוק UEBA מנתח?
התנהגות משתמש—דפוסים של עובד ספציפי: שעות עבודה, מערכות שאליהן ניגש, נפח נתונים שהועבר, מכשירים/מיקומים שבהם השתמש. התחברות ב-3 לפנות בוקר מדבלין כאשר העובד עובד במוסקבה ומעולם לא היה באירלנד—זו חריגה. התחברות מחוץ לשעות העבודה ביום שלאחר קבלת הודעת פיטורים—בעדיפות גבוהה.
התנהגות ישות—התנהגות של נושאים לא-אנושיים: שרתים, מכשירי IoT, חשבונות שירות, מפתחות API. שרת יישומים שמתחיל פתאום לסרוק את הרשת הפנימית—נפרץ.
ניתוח קבוצת עמיתים—השוואת התנהגות המשתמש עם "קבוצת העמיתים" שלו (קולגות באותו מחלקה, באותו תפקיד). גישה ל-500 קבצים ביום כאשר נורמת הקבוצה היא 30—חריגה, גם אם המספר המוחלט לא מפעיל כלל.
כיצד נבנה קו הבסיס ההתנהגותי?
קו בסיס אינו "ממוצע של 30 יום" פשוט. עלינו להתחשב בעונתיות (רואי חשבון מעבדים יותר בתקופות דיווח), ביום בשבוע (הפעילות ביום שישי בערב נמוכה יותר), בתפקיד (DevOps ניגשים לייצור באופן קבוע, מנהלים לא), ובאבולוציה (עובדים חדשים לומדים מערכות ב-2-3 החודשים הראשונים).
מבחינה טכנית: ARIMA + פירוק עונתי עבור סדרות זמן. קווי בסיס נפרדים לכל משתמש ולכל סוג פעילות. ממוצע נע משוקלל אקספוננציאלית כדי להתאים לשינויים בדפוסים.
class UserBehaviorBaseline:
def __init__(self, lookback_days=90, min_data_points=30):
self.models = {}
self.lookback = lookback_days
def build_baseline(self, user_id: str, activity_type: str, events: pd.Series) -> None:
# Seasonal decomposition (недельный период)
decomposition = seasonal_decompose(
events,
model='additive',
period=7,
extrapolate_trend='freq'
)
# Robust statistics для устойчивости к выбросам
mad = median_abs_deviation(decomposition.resid.dropna())
self.models[(user_id, activity_type)] = {
'trend': decomposition.trend,
'seasonal': decomposition.seasonal,
'mad': mad,
'median_resid': np.median(decomposition.resid.dropna())
}
def anomaly_score(self, user_id: str, activity_type: str, value: float, timestamp: datetime) -> float:
baseline = self.models.get((user_id, activity_type))
if not baseline:
return 0.5 # unknown user — medium risk
expected = baseline['trend'].iloc[-1] + self._seasonal_component(baseline, timestamp)
deviation = abs(value - expected) / (baseline['mad'] + 1e-8)
return min(1.0, deviation / 10.0) # нормализация в [0, 1]
ניקוד סיכון ותיעדוף
חריגה בודדת היא רעש. תקרית אמיתית היא דפוס. UEBA מצרף ציוני חריגות בממדים מרובים לציון סיכון אחד:
- פעילות גישה לקבצים חריגה: +0.3
- נפח תעבורה יוצאת חריג: +0.4
- התחברות ממכשיר חדש: +0.2
- גישה לנתוני HR (קטגוריה חדשה למשתמש זה): +0.5
- ציון סיכון מורכב: 0.87 → התראת עדיפות גבוהה
חשוב לציין, ציון הסיכון מתחשב בהקשר. אותו עובד במהלך קליטת עובד חדש (תהליך HR)—סיכון הבסיס לגישת HR נמוך יותר.
הטבלה מראה שמודלי ML מדויקים פי 1.9 ממודלים מבוססי-כללים: דיוק 0.85 לעומת 0.45.
| שיטה | דיוק | Recall | F1 |
|---|---|---|---|
| מבוסס-כללים | 0.45 | 0.60 | 0.51 |
| ML (ה-UEBA שלנו) | 0.85 | 0.82 | 0.83 |
כיצד מזוהה הוצאת נתונים?
אחד ממקרי השימוש המרכזיים לאיומים פנימיים. סימנים לעזיבה קרובה עם גניבת נתונים:
- עלייה חדה בקבצים שהועלו ל-USB/ענן ב-1-4 שבועות לפני התפטרות
- גישה לנתונים מחוץ לתחום העבודה הרגיל (מאגרי לקוחות בתפקיד טכני)
- חיפוש מילות מפתח כמו "סודי," "חסוי," "רשימת לקוחות"
- הורדות המוניות מחוץ לשעות העבודה
המחסן הטכני להוצאת נתונים כולל סוכני DLP עם OCR, ניתוח תעבורת רשת, לוגי פרוקסי, וזיהוי DNS tunneling ובקשות מקודדות base64. אינטגרציה עם CASB וספקי ענן.
מקרה מעשי: כיצד מנענו גניבת נתוני לקוחות
הלקוח שלנו—משרד עורכי דין, 200 עובדים, ענייני לקוחות רגישים. בעיה: שותף עזב, ולקח נתונים על 40 לקוחות. התגלה לאחר 3 שבועות.
פרסנו UEBA חודשיים לאחר התקרית. 4 חודשים לאחר הפריסה:
- המערכת זיהתה עובד שבועיים לפני שהגיש התפטרות, העלה 8 GB ל-Dropbox אישי (נורמה 200 MB לחודש)
- ציון סיכון במהלך השבוע: 0.91 (מקסימלי)
- הודעה מיידית ל-CISO
- הנתונים מעולם לא עזבו את החברה—USB נחסם, סנכרון Dropbox הופסק עד לסיום החקירה
תובנה מרכזית: ההתנהגות החלה להשתנות 3 שבועות לפני הודעת ההתפטרות הרשמית. ללא UEBA, זה היה נעלם מעיניים.
שלבים ולוח זמנים
בדרך כלל, הפרויקט עובר את השלבים הבאים. החיסכון הממוצע ממניעת תקרית אחת יכול לנוע בין $10k–50k לשנה. העלות מחושבת באופן פרטני לאחר הערכה.
| שלב | משך |
|---|---|
| ביקורת מקורות נתונים ותשתית | שבוע אחד |
| עיצוב ארכיטקטורה ובחירת מחסן טכנולוגי | שבוע אחד |
| פיתוח מודלי בסיס וניקוד סיכון | 3-4 שבועות |
| אינטגרציה עם SIEM ו-SOAR | שבועיים |
| תיעוד והדרכה | שבוע אחד |
מה כולל פיתוח מערכת UEBA?
אנו מספקים מחזור מלא: ביקורת מקורות נתונים ותשתית, עיצוב ארכיטקטורה ובחירת מחסן טכנולוגי, פיתוח מודלי בסיס וניקוד סיכון, אינטגרציה עם SIEM ו-SOAR, תיעוד, הדרכת צוות אבטחה, תמיכה לאחר ייצור, ואימון מחדש של מודלים. עיבוד סטטיסטי ומודלי ML מבוצעים על המחסן הטכנולוגי של PyTorch ו-LangChain, תוך שימוש ב-vLLM להסקה. מהנדסי ה-ML המוסמכים שלנו מבטיחים שהמודלים תואמים לנתונים שלך.
הזמינו פיתוח מערכת UEBA—התחילו להגן מפני איומים פנימיים היום. צרו קשר עם המהנדסים שלנו לביקורת על התשתית שלכם.







