Suricata

Could also be addressed by adding a new (final) "verdict" field.

Following the discussion, I tend to prefer the verdict field, too.
Would this be part of the "packet" event?

To address this, I'm working on (possibly) adding a new field to events such as `drop` and
`alert`, which indicates what was the final verdict by Suri for the packet that
triggered the `drop`/`alert`. It is currently called `verdict`, and is
structured as (json resumed):

{
  "pcap_cnt": 10,
  "event_type": "drop",
  "direction": "to_server",
  "drop": {
  ...
    "reason": "flow drop" 
  },
  "verdict": "drop" 
}

and

{
  "pcap_cnt": 4,
  "event_type": "alert",
  "proto": "TCP",
  "pkt_src": "wire/pcap",
  "alert": {
    ...
  },
  "verdict": "reject" 
}

Currently, the possible values are "accept", "drop" or "reject".

We'd like to get feedback on this new output field: field values, field name etc. That's because once something is introduced to our output, it's much harder to get rid of it, so we wanna be sure(r).

Would it make sense to use a value of "pass" instead of "accept" in order to be consistent with the terminology of the rule actions? Both "drop" and "reject" are consistent with those.

It's unfortunate that the field name "action" in the output is already taken because that would be consistent with what the rules format calls that value: https://suricata.readthedocs.io/en/suricata-6.0.0/rules/intro.html#action

I feel pass would actually be confusing, as it has a different meaning than issuing a IPS verdict. Pass in detection means the packet is processed but not inspected against rules. Accept/drop/reject are more per packet verdicts indicating what happened to that packet wrt the IPS policy engine. For example, iptables uses ACCEPT/DROP/REJECT as well.

To add: Have verdict as an optional new eve field but also as part of the alert event.

Jamie Lavigne wrote in #note-8:

Would it make sense to use a value of "pass" instead of "accept" in order to be consistent with the terminology of the rule actions? Both "drop" and "reject" are consistent with those.

It's unfortunate that the field name "action" in the output is already taken because that would be consistent with what the rules format calls that value: https://suricata.readthedocs.io/en/suricata-6.0.0/rules/intro.html#action

Took longer than expected, but I believe we have something very close to merge state, now, in case you want to have a look at how we're approaching this. :)
https://github.com/OISF/suricata/pull/9162