Hey Hey, people.
We’re introducing a new metadata tag to the ET ruleset, CISA_KEV. The purpose of this tag is to identify rules in the ETOPEN and ETPRO rulesets that serve to detect CVEs that have been identified as a part of CISA’s Known Exploited Vulnerabilties Catalog.
This tag is a part of our ongoing efforts to provide Suricata detection against threats identified in the Known Exploited Vulnerabilities catalog, as well as ongoing efforts to provide further metadata enrichment of the ET rulesets, as this was a significant ask at Suricon this year.
How do I identify CISA_KEV rules?
Using your favorite rule management tool, text editor, or expressions parser, search for the text, tag CISA_KEV.
How many rules will benefit from this new tag?
As of my last count, there are a little under 1200 rules, covering over a decade of CVEs. Eagle-eyed users will have noticed that yesterday’s rule update (2025-01-29) contained a small number of rules featuring this tag already, with the remaining bulk gaining the new tag with today’s rule release.
1200 rules is a lot. Do I need to enable all of them?
As with other rules in the ET ruleset, not all of these rules will be applicable to your environment. Some of the CVEs included in this new tag are very old. Others are for unusual, vertical-specific software. Pay attention to the CVE number, product names, and other metadata tags to help determine whether or not these rules are applicable for your Suricata or Snort deployments.
You may notice that there are a number of the newly tagged rules are in the ET_DELETED category. That is because some of these rules tagged were used as a part of (now defunct) exploit kits or other payload delivery mechanisms that are no longer being observed in the wild, but we’re still applying the tag retroactively.
Will this provide complete coverage against the CISA KEV Catalog?
CISA’s KEV catalog features a number of local privilege escalation vulnerabilities (LPE, PrivEsc). In most cases, there is no practical way for Suricata or Snort to provide detection against Local Privilege Escalation vulnerabilties, because there is no network component for Suricata or Snort to analyze in the exploit. If there is a way for us to detect a threat in the CISA KEV catalog and we have enough details (write-ups, proof of concept, pcaps, etc.) available, we aim to provide as much coverage as possible.
As always, if there is a vulnerability identified in the catalog that you notice is missing from the ET ruleset, and you would like to see coverage for it, we are always open to suggestions and requests for coverage. Be aware that sometimes a lack of coverage comes from a lack of details surrounding the vulnerability. The more details you can provide us in your requests for coverage means the greater likelihood for us to be able to provide coverage for the missing vulnerability in question.
How Often will the ruleset be reviewed for new CVEs added to the CISA KEV Catalog?
Provided we don’t get specific requests from the user community, or the rule isn’t newly created with the CISA_KEV tag already added, our current plan is to review the Emerging Threats rulesets once per quarter (e.g. every 3 months or so) to ensure that any CVEs that are newly added to the CISA KEV Catalog and have a corresponding Emerging Threats rule that already cover that CVE, have the CISA_KEV metadata tag applied in order to continue supplying relevant results.
We have an internal, automated ticket system that generates tickets for additions to the CISA KEV catalog. Usually we’re on top of checking our ruleset for existing coverage, and if there is no coverage, creating the necessary rules – if we have enough data available to do so.
In conclusion, while our current goal is ensure this work is reviewed every three months, gaps in proper metadata tagging should be few and far in between.
I hope this answers possible questions and concerns with this new tag. Good luck, and happy hunting.
- Tony Robinson