Tools · Network IDS and detection as code · 05 / 24
Suricata: an eve.json alert row is a signature match
An eve.json row with event_type alert means one signature matched. signature_id names it. Category, severity, and action are labels from the rule, not a verdict.
event_type is the kind of row
eve.json is a stream of records. The field that tells you this record is a signature match is event_type, and the value is alert. That value does not mean the traffic was unwanted, confirmed, or even interesting. It means a loaded signature’s conditions were true for this flow at this time.
alert.signature_id is which signature, together with alert.gid and alert.rev. alert.signature is the message string the rule author wrote. Quote the id in the note. Treat the message as the rule’s name, not as a sentence you have verified.
{"timestamp":"2026-11-03T15:04:11.220+0000","event_type":"alert",
"src_ip":"10.8.0.40","dest_ip":"10.8.0.53","proto":"UDP",
"alert":{"action":"allowed","gid":1,"signature_id":1000204,"rev":3,
"signature":"HB local - NTP name looked up","category":"Misc activity","severity":3}}The other alert fields are labels
alert.category is the classtype text copied from the rule. alert.severity is the number the rule author picked. alert.action is what the rule was set to do, often allowed when the rule only alerts. None of those fields is an analyst’s decision, and none of them changes because the lookup was harmless.
A category that sounds serious is still just that string. If the finding needs a judgment, it has to come from a person who read the names, the hosts, and the reason this signature exists.
What the row can support
You may write the time, the source and destination addresses, the protocol, the signature id, the revision, and the message as printed. You may write that the rule’s action was allowed, if you are describing the rule. You may not write, from this row alone, that a host is compromised or that the queried name is forbidden.
Other event types in the same file are context. They are not fields of this alert row. If you use them, cite those records separately.
Worked case: a classtype read as a conclusion
The lab capture contains one alert for signature 1000204. A draft says “Misc activity confirms a policy breach” because category is non-empty and the message mentions NTP. The row shows a DNS lookup of the lab’s NTP name from a workstation to the lab resolver, and action allowed.
The corrected note quotes event_type, signature_id 1000204, rev 3, the two addresses, and the message. It says the category and severity are the rule’s labels. It does not call the lookup a breach. The signature exists so the lab can see that name; seeing it is the whole result.
Diagram
Fields on one alert row
Only the first two say a signature matched.
- event_type: alert
This record is a signature match, not a finished judgment.
- alert.signature_id
Which signature, with gid and rev. This is the id to quote.
- alert.signature
The rule author’s message. A name, not a verified description.
- category, severity, action
Labels and the rule’s action. They do not become a verdict.
Check yourself
1. Which field marks an eve.json record as a signature match?
2. What is alert.signature_id for?
3. alert.category says “Misc activity”. What may the note claim?