
Imagine a security guard working in a large office building.
The guard knows that most employees arrive between 8:00 and 9:00 in the morning, work in particular areas and leave at the end of the day.
One day, an employee arrives at 2:00 in the morning, enters an area they don’t normally visit, downloads a large amount of information and then attempts to access several restricted rooms.
None of these actions necessarily proves that the employee is malicious. But taken together, they are unusual.
The security guard might think:
“That’s not normal behaviour for this person. I should take a closer look.”
This is essentially the idea behind Entity and User Behaviour Analytics (EUBA).
EUBA looks at what users, devices and other entities normally do, establishes patterns of normal behaviour, and identifies activity that appears unusual or suspicious.
EUBA looks for behaviour that doesn’t fit the normal pattern.
It is therefore an important detective security control and can be particularly useful for identifying compromised accounts, insider threats and other activity that traditional security controls may miss.
What is EUBA?
EUBA stands for Entity and User Behaviour Analytics and builds on the older concept of User and Entity Behaviour Analytics (UEBA).
The important word however is Entity.
An entity could be:
- A user
- A computer
- A server
- A service account
- An application
- A device
- An IP address
- A cloud workload
So EUBA isn’t simply asking “Is this user behaving strangely?”
It can also ask “Is this device behaving strangely?”
or “Is this service account behaving strangely?”
Why Do We Need Behaviour Analytics?
Traditional security controls often look for specific things.
For example:
- A Firewall looks for connections in and out of the network
- Antimalware looks for signs of known malware activity
- An IDS looks for known attack patterns
These controls are valuable, but attackers don’t always use something that is obviously malicious. Sometimes the activity looks perfectly legitimate, and every individual action might be legitimate.
The combination and context may however, be suspicious.
This is where EUBA becomes useful.
The Basic Idea
EUBA establishes a picture of what normal behaviour looks like.
It then compares any new activity against that baseline.
The system isn’t necessarily saying “This is definitely an attack.”, it is saying “This behaviour is unusual enough to warrant attention.”
What Is Normal Behaviour?
Before EUBA can identify unusual behaviour, it needs some understanding of what normal behaviour looks like.
For example, suppose Alice normally:
08:30 Logs in
09:00 Uses CRM
10:00 Uses email
11:00 Accesses sales files
17:00 Logs out
This creates a behavioural pattern.
Now imagine:
02:17 Login
02:19 VPN connection
02:21 Accesses HR database
02:25 Downloads 20 GB
02:31 Attempts administrator access
This is significantly different from Alice’s normal behaviour and should be investigated further.
Anomalies
An anomaly is something that differs from an established pattern.
An anomaly doesn’t necessarily mean that Alice is malicious – There could be a perfectly reasonable explanation.
But it should probably be investigated.
Context Matters
Context is one of the most important concepts in EUBA.
A single event may mean very little without context.
For example a large file download could be normal if the user is a database administrator performing a scheduled backup.
But suspicious if the user normally accesses spreadsheets and suddenly downloads an entire customer database.
EUBA therefore considers the context surrounding the activity.
What Does EUBA Monitor?
EUBA can use information from many sources.
For example
- Authentication data
- Email activity
- VPN access
- File Access
- Application use
- Cloud Services
- Network Traffic
- EDR telemetry
The more useful information it has, the better it can understand behaviour.
Authentication Behaviour
Authentication is an important source of behavioural information.
EUBA may look at:
- Login time
- Login location
- Source IP
- Device used
- Authentication method
- Failed login attempts
- MFA activity
For example, a user normally logs in from a UK IP address via their company laptop between 08:00 – 18:00.
The next day though a login is seen from a German IP address, from an unknown device, at 03:20
This could represent a compromised account – but it could be possible the user has travelled to Germany between those login sessions.
Impossible Travel
One interesting example though is impossible travel.
Suppose a user’s account logs in from London at 10:00, and then New York at 10:30
It would be physically impossible for the user to travel between those locations in 30 minutes.
This could indicate:
- Stolen credentials
- VPN usage
- A proxy
- Shared credentials
- Incorrect geolocation
The event isn’t automatically proof of compromise, but it can be a useful anomaly.
Device Behaviour
EUBA can also establish normal behaviour for devices.
For example:
Laptop-27 normally connects to:
- CRM
- File server
It also Uses:
- Browser
- Office applications
- VPN
Suddenly though, Laptop-27 connects to:
- Database servers
- Administrative systems
- Multiple unknown IPs
This could be classed as suspicious.
Service Accounts
Service accounts are particularly interesting.
A service account typically is used for one type of activity (e.g. a backup account), so normal behaviour might look like:
- 02:00 – Backup service starts, Database accessed, Data passed to backup storage
If the same account suddenly:
- 22:30 – Accesses email, Logs into workstation, Accesses HR database
that would be highly unusual.
EUBA can help identify this type of abnormal behaviour.
Privileged Account Behaviour
Administrator accounts are especially important.
Suppose an administrator normally manages Servers, Firewalls, and User accounts, but suddenly accesses a customer database, creates new admin account, and disables security controls
The behaviour is significantly outside the normal pattern.
This could indicate either:
- A compromised administrator account
- Malicious insider activity
- Unusual legitimate activity
Either way, it deserves attention.
Insider Threats
One of the major applications of EUBA is detecting potential insider threats.
An insider already has legitimate access. This creates a challenge for traditional security controls.
The problem isn’t necessarily “Should this person be allowed to log in?” as they are allowed to log in.
The question is “Is this person behaving in a way that is unusual for them?”
EUBA and Zero Trust
EUBA is particularly relevant to Zero Trust.
Zero Trust doesn’t simply assume “The user authenticated, therefore everything is fine.”
Instead, zero trust makes access decisions based on context and risk.
The user’s behaviour becomes another piece of information used when evaluating risk.
Risk Scores
EUBA systems may assign a risk score to users or entities.
For example, normal behaviour may score as LOW (e.g. 0), an unusual login may score MEDIUM (e.g. 3), but an unusual login (3), + an unusual device (3), + access to sensitive data (6) results in a score of HIGH (10+)
The exact scoring mechanism varies between products, but the important idea is that multiple unusual events can increase confidence that something is wrong.
Behaviour Isn’t Binary
EUBA doesn’t necessarily work as “is this normal Yes or No?”
It can instead work with levels of risk
Low rick events can be classed as normal activity
Medium risk events, such as unusual activity can be flagged for further monitoring
High risk events should trigger an investigation and response
This allows security teams to respond proportionally.
EUBA and the SIEM
EUBA can work closely with a SIEM.
A SIEM collects events from many sources. EUBA can use those events to understand behaviour.
Data fed from:
- Firewalls
- VPNs
- Identity management
- EDR
- Applications
- Cloud
Can be fed into the SIEM, passed to the EUBA for analysis and compared against the risk matrix to determine what actions to take
In some products, behavioural analytics is built directly into the SIEM.
EUBA and EDR
Endpoint Detection and Response (EDR) provides detailed information about endpoint activity. EUBA can use this information as part of a broader behavioural picture.
EDR sees what is happening on the endpoint and EUBA considers whether that behaviour is normal for the user or entity.
EUBA and Logging
EUBA depends heavily on good logging. Without useful event data, EUBA has less information from which to establish behavioural patterns.
This is another reason why logging and auditing are fundamental security controls.
EUBA and SOAR
EUBA can also feed alerts into SOAR platforms. Depending on the severity of the risk score, the response could include:
- Requiring additional authentication
- Disabling an account
- Isolating a device
- Revoking sessions
- Creating an incident
- Alerting an analyst
Step-Up Authentication
An organisation might use behavioural risk to trigger step-up authentication.
This is where the EUBA flags activity as suspicious which prompts the system to require additional authentication from the entity in order to proceed.
This can provide a balance between security and usability. Users don’t necessarily have to endure the highest level of authentication for every action.
Baselines
The concept of a baseline is fundamental to EUBA.
A baseline describes normal behaviour. From this new activity can then be compared with the baseline to identify the anomalies
However, baselines can be dynamic – People don’t behave identically every day.
For example, maybe Alice normally works Monday–Friday – 08:00–18:00 – This is normal for Alice
A shift pattern of Saturday 10:00–14:00 was previously unusual, but Alice has taken on a new role which requires her to work these extra hours
A good behavioural system should be capable of adapting as legitimate behaviour changes.
Peer Groups
EUBA doesn’t always compare someone only against their own historical behaviour. It can also compare them against a peer group.
Alice is one of 20 staff who work in sales – the EUBA should monitor the sales group activity for anomalous activity – If Alice suddenly behaves very differently from other sales users, that may be significant.
Why Peer Groups Help
Imagine a new employee – There may not be enough historical data to establish their personal baseline, so a peer-group baseline can help in this situation until enough personal data is available to create an individual baseline for the employee.
EUBA Doesn’t Know Intent
This is an extremely important limitation.
EUBA can identify “This is unusual.”
It cannot necessarily determine “This person is malicious.”
Possible explanations include:
- Compromised account
- Employee travelling
- Emergency work
- New job responsibilities
- New device
- Legitimate administrator activity
A human may still need to investigate.
Because EUBA looks for unusual behaviour, false positives are inevitable.
For example a user who normally logs in between 09:00 – 17:00 suddenly logs in at 07:00
That might look suspicious at first glance. But perhaps the employee is preparing for an important presentation, or under pressure to get a report finished for an important meeting.
It’s unusual, but legitimate.
EUBA can also miss attacks. An attacker who carefully imitates normal behaviour may be difficult to detect. The attacker’s behaviour may not create a strong anomaly that is enough for the system to flag it for investigation.
This is why EUBA is another layer rather than a complete security solution.
Machine Learning
Because of the many, many factors which can affect EUBA decisions, many modern behavioural analytics systems use machine learning to establish patterns and identify anomalies.
The actual techniques used vary considerably between products, and marketing material sometimes makes behavioural analytics sound like magic artificial intelligence.
In reality, systems can use a combination of:
- Statistical analysis
- Rules
- Thresholds
- Historical baselines
- Peer-group comparisons
- Machine learning
- Threat intelligence
- Risk scoring
The important thing is the analysis of behaviour, not the technology used to perform it.
Privacy Considerations
Behaviour analytics inevitably involves monitoring people and their activity.
This creates important privacy considerations. For example, an organisation may collect information about:
- Login times
- Locations
- Applications used
- Files accessed
- Network activity
Organisations need to ensure that this monitoring is appropriate, proportionate and properly governed.
The goal should be to detect security problems – not unnecessarily monitor people’s personal lives.
Data Protection
Behavioural data may itself be quite sensitive.
Organisations should consider:
- What information is collected
- Why it is collected
- Who can access it
- How long it is retained
- How it is protected
- How false positives are handled
Security monitoring should itself be subject to appropriate security and governance.
EUBA as a Detective Control
The primary role of EUBA is detection.
It asks “Does this behaviour look unusual or risky?”
The response can then be handled by other controls or technologies.
In Summary
Entity and User Behaviour Analytics (EUBA) analyses how users and other entities normally behave and identifies activity that deviates from those patterns.
It can monitor:
- Users
- Computers
- Servers
- Service accounts
- Applications
- Cloud workloads
- Devices
It can look at:
- Login times
- Locations
- Devices
- Applications
- File access
- Network connections
- Data transfers
- Privileged activity
- Authentication
- Cloud activity
It can help identify:
- Compromised Accounts – A legitimate account being used in an unusual way.
- Insider Threats – Legitimate users performing suspicious or inappropriate activity.
- Account Takeover – Attackers using stolen credentials.
- Data Exfiltration – Unusual access or transfer of large amounts of information.
- Privilege Abuse – Users accessing systems or information outside their normal role.
- Anomalous Devices – Computers behaving differently from their established pattern.
EUBA works particularly well alongside:
- Logging and Auditing
- SIEM
- SOAR
- EDR
- MFA
- Access Controls
- Least Privilege
- Need to Know
- Zero Trust
- Defence in Depth
The most important thing to remember is that EUBA isn’t trying to prove that someone is an attacker. It is looking for behaviour that doesn’t fit the expected pattern.
A valid username, password and MFA token might tell you that “This person successfully authenticated.”
EUBA can ask a much more interesting question – “Is this person behaving like the person who normally uses this account?”
That additional context can be extremely valuable.
EUBA doesn’t just ask who accessed the system. It asks whether they are behaving as expected.