HackBlue

Tools · Network IDS and detection as code · 07 / 24

When the same rule’s counts disagree, compare the question

If Suricata and a converted query report different counts, write both with their units. Compare the window, the field, the rule revision, and any filter one side applied.

12 min read · practice only with authorization

Keep both numbers

A disagreement is data. Suricata counted alert rows for a signature id. The SIEM counted events for a query someone generated from a Sigma rule. Those can be the same detection only after you show they asked the same question. Until then, write both figures and do not average them, and do not delete the smaller one to make a dashboard tidy.

Each figure needs a unit. “14” is not a count of hosts, flows, and rows at once. Say “14 eve.json alert rows” or “31 SIEM events” so the next reader cannot mix them.

What you line up

Compare the clock: both windows in UTC, including whether the end is inclusive. Compare identity: signature_id and revision against the Sigma rule id and the exact query text that ran, not the title. Compare the field that was tested, such as a DNS query name versus a free-text search. Compare filters that exist on only one side, including a threshold entry that dropped rows before they were logged.

If any line differs, you are not looking at one count with noise. You are looking at two questions. Say that, then decide which question the finding is allowed to cite.

Do not force the units to match

One tool may emit a row per match and another a row per host per hour. Dividing until the numbers look alike hides the unit change. Pick the unit the finding needs, recompute both sides in that unit, and show the arithmetic. If you cannot recompute, the finding quotes both original units and does not pretend they are equal.

Worked case: 14 alert rows and 31 events

Between 09:00 and 10:00 UTC, eve.json has 14 rows with signature_id 1000302 and rev 4, each a lookup of status.hackblue-lab.org. The Splunk query titled the same way shows 31 events. The draft averages them to “about 22”.

The comparison note finds two differences. The SIEM window was 09:00 to 10:00 in the site’s local zone, not UTC. The printed query searches a message field for the hostname, so it also counts a script that prints the name. After the window is UTC and the query tests the DNS query-name field, both sides show 14. The finding cites 14 alert rows and mentions the 31 only as the count of the earlier, wider query.

Snippet
eve.json     14 alert rows   sid 1000302 rev 4   09:00-10:00 UTC   dns query name
first query  31 events       text search         09:00-10:00 local message field
aligned      14 events       query-name field    09:00-10:00 UTC   same sid's rule

Diagram

Line the two counts up before you cite either

  1. Units

    Name what was counted on each side.

    Note
    alert rows, not “hits”
  2. Window

    Put both bounds in one zone.

    Clock
    09:00-10:00 UTC
  3. Identity

    Signature id and rev, or the printed query.

    Rule
    sid 1000302 rev 4
  4. Field

    The test each side actually ran.

    Check
    query name, not message text

Check yourself

1. Suricata reports 14 and the SIEM reports 31 for “the same rule”. What should you record first?

2. The SIEM window was local time and Suricata’s was UTC. What follows?

3. One side counted rows and the other counted hosts. What is a fair finding?