Suricata

Could be as a string to avoid vid collisions.

Several things were discussed at the 2020 brainstorm:
- vid in rulesets would still require some kind of central registrery
- vid in output would mean all post-processing would need updates
- could we just add it to 'metadata'? No solution for sid collisions
- Suricata-Update could also auto assign a vid, so sid collisions wouldn't happen. Doesn't solve the output issue
- suggestion was made to move away from sid/gid in favor of some kind of uuid. Rev would have to stay.

In conclusion: no decision. Needs more thought.

Based on the discussion in the Brainstorm Slack, no one was really in support of a new "vid" field. A new UUID field seemed to have a little more support.

But there seemed to be more support for using more of the existing fields to generate a unique identifier. At the most basic, this could be left to post-processing. Suricata could be modified to not enforce a unique sid, and as it already logs rule metadata, output processors could derive uniqueness from the sid, and some metadata like a "vendor_id" or "rule_source" in the metadata. However, existing processing tools that depend on uniqueness of the SID may fail in this case, or reporting tools that aggregate on sid will provide bad reports.

Another idea is to pre-process rules to provide a unique SID. Suricata-Update could dynamically create SID ranges for each rule_source. Then update the metadata in the rule with enough data to map back to the original rule (rule source, and original sid). This ensures all rules provided to Suricata via Suricata-Update would have a unique SID, and post-processing tools for the most part would not need to change. Tools that link back to the original sources of the SID would need to change though, as the SID may not be the same. This should be done as needed, not every ruleset should have its SIDs remapped.

This pre-processing approach would also work for generated IOCs, where I hear they just start at some low number, or use a date.

Related tickets:
- #4113 -- intel index: register sid ranges per rule source
- #3303 -- Add a documentation about the used sid and gid ranges