Розробка UEBA-системи аналітики поведінки користувачів
У своїй практиці ми стикаємося з інсайдерськими загрозами та скомпрометованими акаунтами — атаками, які використовують легітимні облікові дані. Підписи шкідливого ПЗ тут не допомагають. Тому ми будуємо UEBA (User and Entity Behavior Analytics) на іншому принципі: не «це відома загроза», а «це аномальна поведінка для конкретного суб'єкта». Згідно з NIST, до 70% інцидентів безпеки залишаються непоміченими традиційними засобами — UEBA закриває цю прогалину. Детальніше про технологію — у Wikipedia.
Що саме аналізує UEBA?
User behavior — паттерни роботи конкретного співробітника: в який час працює, до яких систем звертається, який обсяг даних переміщує, з яких пристроїв/локацій. Логін о 3 годині ночі з Дубліна при тому, що людина працює в Києві і ніколи не бувала в Ірландії — це аномалія. Логін у неробочий час наступного дня після отримання повідомлення про звільнення — високопріоритетний.
Entity behavior — поведінка не-людських суб'єктів: серверів, IoT-пристроїв, сервісних акаунтів, API-ключів. Сервер застосунків, який раптово починає сканувати внутрішню мережу — скомпрометований.
Peer group analysis — порівняння поведінки користувача з його «групою однолітків» (колеги в тому ж відділі, тій же посаді). Доступ до 500 файлів на день при нормі в групі 30 — аномалія, навіть якщо абсолютна цифра не тригерить правило.
Як будується поведінковий baseline?
Baseline — це не просте «середнє за останні 30 днів». Потрібно враховувати сезонність (бухгалтер обробляє більший обсяг у період звітності), день тижня (активність у п'ятницю ввечері нижча), роль (DevOps регулярно звертається до production, менеджер — ні) та еволюцію (новий співробітник освоює системи перші 2-3 місяці).
Технічно: ARIMA + Seasonal Decomposition для часових рядів. Окремі baseline'и за кожним користувачем і кожним типом активності. Exponentially weighted moving average для адаптації до змін патернів.
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]
Risk scoring та пріоритизація
Одинична аномалія — шум. Реальний інцидент — патерн. UEBA агрегує anomaly scores за кількома вимірами в єдиний risk score:
- Аномальна активність по доступу до файлів: +0.3
- Аномальний обсяг вихідного трафіку: +0.4
- Логін з нового пристрою: +0.2
- Доступ до HR-даних (нова категорія для цього користувача): +0.5
- Composite risk score: 0.87 → HIGH priority alert
Важливо: риск-скор враховує контекст. Той самий співробітник у період онбордингу нового співробітника (HR-процес) — базовий ризик нижчий для HR-доступу.
Порівняння точності ML та rule-based
| Метод | Точність (Precision) | Recall | F1 |
|---|---|---|---|
| Rule-based | 0.45 | 0.60 | 0.51 |
| ML (наша UEBA) | 0.85 | 0.82 | 0.83 |
Як детектується data exfiltration?
Один із ключових use cases для insider threats. Ознаки майбутнього звільнення з крадіжкою даних:
- Різке зростання обсягу завантажуваних на USB/хмару файлів за 1-4 тижні до звільнення
- Доступ до даних поза звичайним робочим scope (клієнтські бази при роботі в технічній ролі)
- Пошук за ключовими словами типу «confidential», «secret», «customer list»
- Масове завантаження в неробочий час
Технічний стек для ексфільтрації включає DLP-агенти з OCR, аналіз мережевого трафіку, проксі-логи, а також детектування DNS-тунелювання та base64-закодованих запитів. Інтеграція з CASB та хмарними провайдерами.
Практичний кейс: як ми запобігли крадіжці клієнтських даних
Наш клієнт — юридична фірма, 200 співробітників, чутливі клієнтські справи. Проблема: звільнився партнер, виніс дані по 40 клієнтам. Виявили через 3 тижні.
UEBA впровадили через 2 місяці після інциденту. Через 4 місяці після впровадження:
- Система детектувала співробітника, який за 2 тижні до подачі заяви про звільнення завантажив 8 GB на особистий Dropbox (при нормі 200 MB/місяць)
- Ризик-скор за тиждень: 0.91 (max)
- Негайне повідомлення CISO
- Дані не покинули компанію — USB заблоковано, Dropbox sync зупинено до розслідування
Ключовий інсайт: поведінка почала змінюватися за 3 тижні до формального повідомлення про звільнення. Без UEBA це було б непомітно.
Етапи та строки розробки
| Етап | Тривалість |
|---|---|
| Аудит джерел даних та інфраструктури | 1 тиждень |
| Проектування архітектури та вибір стеку | 1 тиждень |
| Розробка baseline-моделей та risk scoring | 3-4 тижні |
| Інтеграція з SIEM та SOAR | 2 тижні |
| Документація та навчання | 1 тиждень |
Що входить у розробку UEBA-системи?
Ми надаємо повний цикл: аудит джерел даних та інфраструктури, проектування архітектури та вибір стеку, розробка baseline-моделей та risk scoring, інтеграція з SIEM та SOAR, документація, навчання команди безпеки, пост-продакшн підтримка та донавчання моделей. Статистичну обробку та ML-моделювання виконуємо на стеку PyTorch та LangChain, використовуємо vLLM для інференсу. Наші сертифіковані ML-інженери гарантують відповідність моделей вашим даним.
Замовте розробку UEBA-системи — почніть захист від інсайдерів вже сьогодні. Зверніться до наших інженерів для аудиту вашої інфраструктури.
