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