Developing UEBA Systems for User and Entity Behavior Analytics

We design and deploy artificial intelligence systems: from prototype to production-ready solutions. Our team combines expertise in machine learning, data engineering and MLOps to make AI work not in the lab, but in real business.
Showing 1 of 1All 1566 services
Developing UEBA Systems for User and Entity Behavior Analytics
Complex
~2-4 weeks
Frequently Asked Questions

AI Development Areas

AI Solution Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1317
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1226
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    925
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1156
  • image_logo-advance_0.webp
    B2B Advance company logo design
    620
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    894

In our practice, we frequently encounter insider threats and compromised accounts—attacks that use legitimate credentials. Signature-based malware detection doesn't help here. That's why we build UEBA (User and Entity Behavior Analytics) on a different principle: not "this is a known threat," but "this is anomalous behavior for a specific subject." According to NIST, up to 70% of security incidents remain undetected by traditional tools—UEBA fills this gap. More about the technology on Wikipedia.

What exactly does UEBA analyze?

User behavior—patterns of a specific employee: work hours, systems accessed, data volume moved, devices/locations used. A login at 3 AM from Dublin when the employee works in Moscow and has never been to Ireland—that's an anomaly. A login outside working hours the day after receiving a termination notice—high-priority.

Entity behavior—behavior of non-human subjects: servers, IoT devices, service accounts, API keys. An application server that suddenly starts scanning the internal network—compromised.

Peer group analysis—comparing user behavior with their "peer group" (colleagues in the same department, same role). Access to 500 files per day when the group norm is 30—anomaly, even if the absolute number doesn't trigger a rule.

How is the behavioral baseline built?

A baseline is not a simple "30-day average." We must account for seasonality (accountants process more during reporting periods), day of week (activity on Friday evening is lower), role (DevOps regularly accesses production, managers don't), and evolution (new employees learn systems in the first 2-3 months).

Technically: ARIMA + Seasonal Decomposition for time series. Separate baselines for each user and each activity type. Exponentially weighted moving average to adapt to pattern changes.

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 (weekly period)
        decomposition = seasonal_decompose(
            events, model='additive', period=7, extrapolate_trend='freq'
        )
        # Robust statistics for outlier resilience
        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)  # normalization to [0, 1]

Risk scoring and prioritization

A single anomaly is noise. A real incident is a pattern. UEBA aggregates anomaly scores across multiple dimensions into a single risk score:

  • Anomalous file access activity: +0.3
  • Anomalous outbound traffic volume: +0.4
  • Login from new device: +0.2
  • Access to HR data (new category for this user): +0.5
  • Composite risk score: 0.87 → HIGH priority alert

Importantly, the risk score accounts for context. The same employee during new hire onboarding (HR process)—baseline risk lower for HR access.

The table shows that ML models are 1.9 times more accurate than rule-based: precision 0.85 vs 0.45.

Method Precision Recall F1
Rule-based 0.45 0.60 0.51
ML (our UEBA) 0.85 0.82 0.83

How is data exfiltration detected?

One of the key use cases for insider threats. Signs of impending departure with data theft:

  • Sharp increase in files uploaded to USB/cloud in 1-4 weeks before resignation
  • Access to data outside normal work scope (client databases when in a technical role)
  • Search for keywords like "confidential," "secret," "customer list"
  • Mass downloads outside working hours

The technical stack for exfiltration includes DLP agents with OCR, network traffic analysis, proxy logs, and detection of DNS tunneling and base64-encoded requests. Integration with CASB and cloud providers.

Practical case: how we prevented client data theft

Our client—a law firm, 200 employees, sensitive client matters. Problem: a partner left, taking data on 40 clients. Discovered after 3 weeks.

We deployed UEBA 2 months after the incident. 4 months after deployment:

  • The system detected an employee who, 2 weeks before tendering resignation, uploaded 8 GB to a personal Dropbox (norm 200 MB/month)
  • Risk score over the week: 0.91 (max)
  • Immediate CISO notification
  • Data never left the company—USB blocked, Dropbox sync stopped pending investigation

Key insight: behavior started changing 3 weeks before formal resignation notice. Without UEBA, this would have gone unnoticed.

Phases and timeline

Typically, the project goes through the following phases. The average savings from preventing a single incident can range from 1 to 5 million rubles per year. Cost is calculated individually after assessment.

Phase Duration
Audit of data sources and infrastructure 1 week
Architecture design and stack selection 1 week
Development of baseline models and risk scoring 3-4 weeks
Integration with SIEM and SOAR 2 weeks
Documentation and training 1 week

What's included in UEBA system development?

We provide the full cycle: audit of data sources and infrastructure, architecture design and stack selection, development of baseline models and risk scoring, integration with SIEM and SOAR, documentation, security team training, post-production support, and model retraining. Statistical processing and ML modeling are performed on the PyTorch and LangChain stack, using vLLM for inference. Our certified ML engineers ensure models match your data.

Order UEBA system development—start protecting against insiders today. Contact our engineers for an audit of your infrastructure.