Project

General

Profile

Actions

Feature #2755

open

vendor id / vid keyword to give rulesets unique sid ranges

Added by Victor Julien over 2 years ago. Updated 10 months ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

Since more and more rulesets are added to the rule index, risk of sid space collisions increase. It's been suggested that 'gid' should be used to separate them, but the gid field already has other uses in the real world.

So the idea is to add a 'vid' keyword to keep rulesets apart. The rule index should probably also be the master of the vid id's.


Related issues

Related to Task #2685: SuriCon 2018 brainstormNewVictor JulienActions
Related to Task #4097: Suricon 2020 brainstormNewVictor JulienActions
Related to Documentation #3303: Add a documentation about the used sid and gid rangesNewOISF DevActions
Actions #1

Updated by Victor Julien over 2 years ago

  • Related to Task #2685: SuriCon 2018 brainstorm added
Actions #2

Updated by Andreas Herz over 2 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions #3

Updated by Victor Julien 10 months ago

Could be as a string to avoid vid collisions.

Actions #4

Updated by Jason Ish 10 months ago

  • Related to Task #4097: Suricon 2020 brainstorm added
Actions #5

Updated by Victor Julien 10 months ago

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.

Actions #6

Updated by Jason Ish 10 months ago

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

Actions #7

Updated by Jason Ish 10 months ago

Actions

Also available in: Atom PDF