Розробка 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

Як детектується 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 це було б непомітно.

Етапи та строки розробки

Що входить в розробку UEBA-системи?

Ми надаємо повний цикл: аудит джерел даних та інфраструктури, проектування архітектури та вибір стеку, розробка baseline-моделей та risk scoring, інтеграція з SIEM та SOAR, документація, навчання команди безпеки, пост-продакшн підтримка та донавчання моделей. Статистичну обробку та ML-моделювання виконуємо на стеку PyTorch та LangChain, використовуємо vLLM для інференсу. Наші сертифіковані ML-інженери гарантують відповідність моделей вашим даним.

Замовте розробку UEBA-системи — почніть захист від інсайдерів вже сьогодні. Зверніться до наших інженерів для аудиту вашої інфраструктури.