Rule States and Support Tiers

[bingohotdog]

UPDATES:

• Added updateCategory() event to reflect how rules change switch between RETIRED and DELETED categories.

This post explores the nuances behind a rule’s enabled or disabled state AND its implied support tier.

TLDR: Emerging Threats releases enabled and disabled rules. There are feedback loops that change a rule’s state and category. As an enabled or disabled rule get more nuanced categories (e.g. Retired or Deleted), so does its support tier.

.
.
.

Consider the following diagram that walks through a rule’s state and implied support levels.

Diagram: ET/ETPRO Suricata Rule State Diagram

Start

State: Unpublished

A rule writer creates a rule, but has not submitted it to Emerging Threats’ submission process.

State: Submitted

A rule writer queues an unpublished rule for submission.

Event: Performance Testing Before Released

A rule goes through performance testing or rule profiling before release.

• If it is determined performant (e.g. low ticks, low checks) , then it will be released as enabled.
• If not, it is publicly released as disabled. User may locally enable these disabled rules.

Note that once it’s released – it can not revert to an unpublished state! It stays forever published publicly.

State Changes within Released State

	Released, Enabled	Released, Disabled
Start	The rule is released. It will be actively maintained.	Same
Event: toDeprecate	The rule needs to switch from enabled to disabled.	The rule needs to switch from disabled to enabled.
Event: toRetire	The rule is identified as having diminished utility. Lower support from ET.	N/A
State: Retired	Rule now has category == RETIRED	N/A
Event: toDelete	N/A	The rule is identified as end of life and discouraged from being enabled locally. No support from ET.
State: Deleted	N/A	Rule now has category == DELETED

More on toDeprecate event

After the rule is released, its continued state is determined by deprecation feedback. Here are recognized deprecation reasons:

@rgonzalez

Deprecation Reason: -The reason why a rule has been disabled or changed state

• Duplicate - it’s been found this rule is a duplicate of a previous rule
• False Positive - Multiple customers have reported FPs for this rule
• Performance - This rule has been found to perform inadequately in production
• Age - The logic in this rule has been superseded by later rules
• Relevance - Investigation has found this rule’s targeted behavior is no longer relevant
• Moved to Open - this ETPRO rule has been moved to ET Open

And so, if a rule is deprecated, then it will later be released as disabled and visa versa.

More on toRetire Event

In an enabled state, there is an option to change the rule’s category to RETIRED. Emerging Threats describes this state here:

@trobinson667

We determined that a solution was needed, and came up with the “RETIRED” category. Rules placed into this category are a step between the “Actively Supported” of our primary rule categories, and the “No longer supported at all” of the DELETED category. Rules placed in “Retired” category are still enabled, and will still actively trigger alerts, but are supported on a “Best Effort” basis.

More on toDelete Event

In this disabled state, there is an option to change the rule’s category to DELETED. IT REMAINS PUBLISHED IN THE RULESET. The category change is a signal that this rule will no longer be supported.

More on updateCategory Event

Rules can transition between RETIRED and DELETED category, but it is a rare corner case event.

Conclusion

Emerging Threats considers rule performance and relevance criteria before enabling and disabling rules. The ET/ETPRO Suricata Rule State Diagram attempts to visualize how rule states change alongside their support tier. This work results in an effective ruleset for all users!