AI Threat Detection and UEBA in Romania

What UEBA catches that signatures miss

UEBA means analysing the behaviour of users and entities. Instead of hunting for a known file or signature, it measures the pattern: where an account signs in from, at what hours, how much data it reads, which processes a server starts and who it talks to on the network. Modern attacks use valid credentials and tools already installed, so no antivirus fires. The deviation is the only signal: same account, different pattern. That is why we combine UEBA with network detection and explicit rules.

• Baselines per account, host and service, not textbook thresholds
• Anomalies in sign-ins, data volumes read, processes and outbound traffic
• Sigma rules for known techniques, mapped to MITRE ATT&CK
• Honeytokens: decoy keys and files nobody has a reason to touch
• Correlation with WAF, VPN and application logs

AI on both sides: automated campaigns, automated triage

Attackers use models to write phishing without language mistakes, to generate payload variants until one passes the filter, and to chain reconnaissance and exploitation in agents that work alone. Volume rises, and a clumsy lure no longer gives the attack away. Defence uses AI for what it does well: learning the normal pattern from millions of events, grouping related alerts into cases and surfacing the few that carry risk context. Deterministic rules stay for what we know for certain, the model covers what we have not written yet, and isolating a system remains a human decision.

From alert to action without burying your team

A detection that raises hundreds of alerts a day is as useless as none. We calibrate over two to three weeks: legitimate patterns are excluded, alerts are grouped by case, and we decide what goes by e-mail, what goes to chat and what triggers the response runbook. Every alert arrives with the question it answers and the steps to check it. Noise that repeats without value is removed or becomes a rule with a clearer threshold, and we then measure how many alerts led to a real action.

How it links to the SIEM and where hours go

Detection sits on the same logs the SIEM collects, so the two are built together: collectors once, rules and models above them. You request the work from the DevOps Services section of the client panel with your own date. Monthly hours mostly go on calibration: thresholds, exceptions and new detections for services that appear later. The allowance is 1 h on cPanel from Advanced up, 1–8 h on VPS, 5–10 h on dedicated by plan and 10 h on GPU, with no carry-over; investigating a large incident is billed separately.

How we work

1. Request from the panel

   Request detection in DevOps Services, tell us which accounts and services are critical and who should receive alerts, and through which channel.

2. Building the baseline

   We collect two to three weeks of telemetry, build the normal pattern for accounts and hosts, and set the thresholds together with you.

3. Detection and tuning

   We switch on Sigma rules, anomaly models and honeytokens, then cut the noise until only the alerts that call for an action remain.

4. Handover with runbooks

   You receive dashboards, the catalogue of detections and a runbook per scenario, plus a verification exercise on a real case from your environment.

Use cases

Technology stack

• Wazuh
• Suricata
• Zeek
• Falco
• Sigma
• MISP
• OpenSearch
• Grafana

Frequently asked questions

• What is UEBA?

  User and entity behaviour analytics: the system learns what is normal for each account, server or service and flags deviations. It catches compromised accounts, insider abuse and lateral movement, which are exactly the attacks that use valid credentials and never trigger a signature.

• What is the difference between EDR, XDR and NDR?

  EDR sits on the host and sees processes, files and commands. NDR analyses network traffic without needing an agent. XDR gathers several sources (hosts, network, identity, e-mail) into one case. On hosted servers, a host agent plus network visibility and application logs is the useful combination.

• How do I reduce false alerts in a SIEM?

  Through baselines rather than fixed thresholds. You document the legitimate patterns, group alerts by case, add risk context for each asset and send only what needs a decision. AI-assisted triage helps with grouping and summaries, but the exceptions stay written down and reviewed.

• Can AI actually prevent attacks?

  It does not prevent them; it detects them sooner and puts them in context. Prevention comes from patching, least privilege, two-factor sign-in and segmentation. AI shortens the time between the first signal and the decision to isolate, which limits damage but never replaces basic hygiene.

• What are honeytokens?

  Fake keys, files or accounts placed where no legitimate user has any reason to look. Nobody touches them in normal work, so any access is an almost certain signal. They are cheap, produce no false alarms and catch an intruder who is already inside and exploring.

• Does the service contain threats on its own or only alert?

  It alerts and starts the response runbook agreed with you. Isolating a server or disabling an account is a human decision taken under that runbook, not a blind automatic action, so a false positive cannot silently take down a production system.