Building Host Behavior Fingerprints from EVE JSON
Suricata is usually considered primarily an IDS/IPS: it analyzes network traffic, applies detection rules, and generates alerts about potentially malicious activity.
But if we look at EVE JSON data from a broader perspective, another question arises:
Can Suricata be used not only to detect individual events, but also to understand the normal behavior of devices on a network?
Suricata already collects a significant part of the information required for this kind of analysis. Flows, DNS queries, TLS connections, HTTP activity, protocols, destination ports, and alerts together can provide a fairly detailed picture of a host’s network behavior.
While working on Suri Oculus, I started experimenting with this approach. The result is a mechanism called HBF — Host Behavior Fingerprint.
The idea behind HBF is relatively simple: instead of analyzing every Suricata event in isolation, the system continuously aggregates events around a specific device.
From Events to Behavior
A typical Suricata event stream may look something like this:
flow
dns
flow
tls
dns
http
flow
alert
flow
...
Each event contains useful information on its own.
For example, a flow event describes a network connection, dns shows access to a domain name, tls may contain SNI information, and an alert indicates that a detection rule has matched.
But when these events are considered independently, a higher level of information is lost.
Suppose there is a device on the network:
192.168.1.25
Over time, Suricata may generate thousands of events associated with this device. Instead of keeping only the sequence of individual events, we can simultaneously build an aggregated representation:
Host: 192.168.1.25
First seen: 2026-08-10 12:14:21
Last seen: 2026-08-18 09:42:03
Events: 18421
Flows: 6842
DNS: 2134
TLS: 1951
HTTP: 317
Alerts: 4
TCP: 5721
UDP: 1098
ICMP: 23
However, simple counters are not enough.
It is much more interesting to know where and how the device normally communicates.
For example:
Top destination ports
443 3812
53 2014
80 421
123 96
22 14
or:
Top DNS names
api.example.com
updates.example.com
time.cloudflare.com
github.com
...
and:
Top TLS SNI
github.com
api.github.com
cloudflare.com
...
Together, these data points begin to describe not an individual network event, but the overall characteristics of a device’s network activity.
This representation is what I call a Host Behavior Fingerprint.
What Is Included in an HBF?
The current HBF implementation in Suri Oculus uses several groups of data.
The first group is device identification:
IP address
MAC address
hostname
network interface
The second group describes general activity:
first_seen
last_seen
event_count
flow_count
http_count
tls_count
dns_count
alert_count
The third group represents transport protocol activity:
tcp_count
udp_count
icmp_count
Finally, there are aggregated behavioral characteristics:
Top Destination Ports
Top DNS Names
Top TLS SNI
The result is a relatively compact structure that still describes a significant part of the device’s network activity.
It is important to note that HBF is not intended to replace the original Suricata events.
It is an additional representation layer:
┌── Individual Events
│
Suricata EVE ─────┤
│
└── Host Behavior Fingerprint
The first level answers the question:
What happened?
The second begins to answer a different question:
How does this device normally behave?
Why Suricata Is Well Suited for This
At first glance, behavioral analysis may seem like a task for a separate monitoring system.
However, Suricata already performs the most difficult part of the work: it analyzes network traffic and converts it into structured events.
EVE JSON provides a unified stream containing different event types:
flow
dns
tls
http
alert
anomaly
fileinfo
...
These events also share common attributes such as IP addresses, timestamps, flow identifiers, and other information that makes it possible to correlate them.
This means that an additional analytical layer can be built on top of EVE without modifying Suricata itself.
The HBF architecture in Suri Oculus looks roughly like this:
Network traffic
│
▼
Suricata
│
▼
EVE JSON
│
▼
Redis / Valkey
│
▼
C++ event processor
│
┌─────────────┴─────────────┐
│ │
▼ ▼
Event storage HBF aggregation
│
▼
Host profiles
│
▼
REST API
│
▼
Web UI
When a new event is processed, the system identifies the relevant local host and updates its fingerprint.
As a result, HBF construction happens almost simultaneously with EVE stream processing.
Why Aggregation Is Performed in Advance
In theory, a device profile could be calculated every time a user requests it.
For example, the system could retrieve all events associated with a particular IP address over the last 24 hours and perform operations similar to:
GROUP BY event_type
GROUP BY destination_port
GROUP BY dns.rrname
GROUP BY tls.sni
But as the number of events grows, this approach quickly becomes expensive.
HBF uses a different principle.
Aggregation is performed while events are being processed.
For each device, the system maintains counters and small collections of the most frequently observed values.
For example:
hbf:device:192.168.1.25
may contain the primary counters, while separate structures store the most frequently used destination ports, DNS names, and TLS SNI values.
As a result, retrieving a device card does not require reprocessing thousands or millions of EVE events.
The backend receives an already prepared profile.
This is particularly important for small servers and resource-constrained devices.
HBF Is Not Yet an Anomaly Detection System
An important distinction needs to be made here.
A Host Behavior Fingerprint by itself does not mean automatic detection of suspicious behavior.
At the current stage, HBF primarily answers the question:
What is characteristic of this device?
For example, we may observe that a host normally:
uses TCP;
communicates primarily over ports 443 and 53;
generates a relatively stable set of DNS queries;
establishes TLS connections with a relatively stable set of SNI values;
rarely generates alerts.
This information is already useful to an analyst.
But the next step is considerably more interesting.
From Fingerprint to Baseline
If HBF data is retained over a sufficiently long period, the current behavior of a device can be compared with its historical profile.
Suppose a device has primarily used these ports for several weeks:
443
53
123
Then suddenly the following ports appear:
22
445
3389
8080
This does not necessarily indicate an attack.
But it is a change in behavior.
The same applies to DNS.
A device may communicate with approximately the same set of domains for months and then suddenly begin generating large numbers of requests to previously unseen names.
Or a new TLS SNI may appear that has never been observed for that device before.
A possible future model could look like this:
Current HBF
│
▼
Historical Baseline
│
▼
Difference
│
▼
Behavior Score
At this point, we move from simple event aggregation toward behavioral analytics.
Why This May Be Particularly Useful for IoT
This approach may be especially interesting for IoT devices.
A user’s workstation normally has highly diverse network activity.
Today the user runs a browser, tomorrow installs a new application, later connects through a VPN, or starts using a new cloud service.
The behavior of such a device changes constantly.
IoT devices are often very different.
A surveillance camera, television, printer, network sensor, or another specialized device typically performs a limited set of functions.
Its network fingerprint may therefore be relatively stable:
Device
│
├── DNS → small set of domains
│
├── TLS → several SNI values
│
├── Ports → 443, 53, 123
│
└── Protocols → TCP/UDP
A sudden change in such a profile may therefore be a much stronger signal than the same change on a general-purpose workstation.
For example:
IoT device
Normal behavior:
53
123
443
New behavior:
445
23
2323
This is still not proof that the device has been compromised.
But it is certainly a reason to investigate the device more closely.
Alerts and Behavior Provide Different Information
There is another interesting aspect.
Suricata alerts and behavioral analysis answer different questions.
A Suricata rule primarily asks:
Does this traffic match a known condition?
Behavioral analysis asks something different:
Is this normal for this host?
These approaches do not compete with each other.
On the contrary, they can complement each other.
For example:
Network activity
│
┌─────────────┴─────────────┐
│ │
▼ ▼
Suricata Rules HBF Analysis
│ │
▼ ▼
Known patterns Behavior changes
│ │
└─────────────┬─────────────┘
▼
Security context
An alert becomes much more interesting if we also know that the associated activity has never previously been characteristic of that device.
Conversely, a behavioral change without any alert may still deserve attention.
The Time Dimension
The current approach has an obvious limitation.
A fingerprint built only from recent events represents more of a current state than a long-term behavioral model.
To move toward a true baseline, a time dimension needs to be introduced.
For example:
Host
├── current
├── last_24h
├── last_7d
├── last_30d
└── historical
Another approach is to store periodic snapshots:
HBF(t1)
HBF(t2)
HBF(t3)
...
HBF(tN)
This makes it possible to analyze not only the current state but also changes over time:
ΔHBF = HBF(now) - HBF(previous)
At this point, long-term storage becomes necessary.
Redis or Valkey works well as an operational layer, while historical fingerprints are better suited for persistent database storage.
This is one of the directions in which this idea can be developed further.
The Next Step: A Numerical Fingerprint
Many HBF parameters can be transformed into numerical features.
For example:
flow_rate
dns_rate
tls_rate
alert_rate
tcp_ratio
udp_ratio
icmp_ratio
unique_ports
unique_dns_names
unique_tls_sni
new_ports
new_dns_names
new_tls_sni
The device profile can then be represented as a feature vector:
Host → [f1, f2, f3, ... fn]
This opens the door to various statistical and machine-learning methods.
Instead of using a rigid rule such as:
if new_ports > 5:
suspicious
the system could estimate how far the current feature vector deviates from the historical behavior of that particular device.
This can then be used to calculate an anomaly score.
The model does not necessarily have to be complex.
Relatively lightweight algorithms may be sufficient for this task, making the approach practical even on systems with limited computational resources.
An Important Limitation: Behavioral Change Does Not Mean an Attack
This is a fundamental point.
If a device starts behaving differently, it does not automatically mean that it has been compromised.
There may be perfectly legitimate reasons:
- software updates;
- configuration changes;
- installation of a new application;
- connection to a new cloud service;
- infrastructure changes;
- DNS changes;
- changes in user behavior.
For this reason, HBF should not become yet another source of a large number of alerts.
A more useful approach, in my opinion, is to represent the result as a degree of behavioral change:
Stable
Minor changes
Significant changes
Unusual behavior
The analyst can then investigate the reason behind that change.
Visualization
A dedicated HBF tab has been added to Suri Oculus for this purpose.
It displays detected local devices and allows the user to open a detailed profile for each one.
The device card contains identification data and the main activity metrics.
The most frequently observed destination ports, DNS names, and TLS SNI values are displayed separately.
At the current stage, this is primarily a tool for exploring the data.
However, even now this representation can sometimes reveal the characteristics of a device much faster than browsing through a large list of individual EVE events.
Where This Model Could Go Next
The current HBF implementation is only the first version of the model.
Some obvious directions for further development include:
- storing historical fingerprints;
- comparing the current state with a baseline;
- detecting previously unseen destination ports;
- detecting new DNS names;
- detecting new TLS SNI values;
- measuring changes in event rates;
- building numerical feature vectors;
- anomaly scoring;
- comparing the behavior of similar devices;
- classifying devices based on network activity;
- correlating behavioral changes with Suricata alerts.
Another interesting possibility is maintaining different baselines for the same device.
For example:
working hours
night
weekday
weekend
or:
normal operation
software update
maintenance
This could significantly reduce the number of false behavioral anomalies.
Conclusion
Suricata already provides significantly more information than is required solely for generating alerts.
EVE JSON is effectively a rich source of network telemetry.
By aggregating this telemetry around individual devices, it becomes possible to move from viewing a sequence of events toward understanding host behavior.
This is the basic idea behind Host Behavior Fingerprint:
Suricata Events
│
▼
Aggregation
│
▼
Host Behavior Fingerprint
│
▼
Historical Baseline
│
▼
Behavior Change Detection
At the moment, HBF in Suri Oculus implements the first stage of this model: the system builds and visualizes the current profile of a device.
The next stages are historical fingerprints, behavioral baselines, and automatic detection of changes in device behavior.
I would be particularly interested in hearing the Suricata community’s opinion about the feature set itself.
Which EVE JSON data would you use to build a behavioral fingerprint of a device?
Flow, DNS, and TLS provide a good foundation, but there are likely additional Suricata fields or event types that could significantly improve such a profile.
And a second question:
How useful do you think this approach could be for IoT and other devices with relatively stable network behavior?