Which IPS Rules does Cisco Enabled on your Firepower System? Think you know? Part II

In the late 1990’s Dale Carnegie wrote what would become one of the most famous and popular business books ever to be written: “How to Win Friends & Influence People”. I am pretty sure that Cisco Talos has Fed Ex’d me a copy by now…

In one of my current blog posts titled (4/13/19): “Which IPS Rules does Cisco Enable on your Firepower System? Think you know?” which is now Part I of this series, I showed that by opening the Rule Accordion, clicking on Rule Content, and lastly, opening Rule Overhead in an IPS policy, you can easily tell which rules are enabled and disabled by default. There’s your answer. No wiggle room here, except for speculation, and that is what this blog will discuss.

In that post I showed you how each Cisco base policy rules are enabled in each overhead listing. However, I’m pretty sure that everyone would know or guess that Cisco certainly may use overhead in some situations for some rules, but there was probably another method they used; however, no one knew what it was, or if they did they couldn’t prove it as plainly as shown above. Also, in that post, I used the Advanced tab slider bar in the Firepower Recommendation section to show how those rules are enabled as well (this is important to remember for this post):

To be clear, most advanced and experinced Sourcefire/Firepower people do not believe that you should use Firepower Recommended Rules (RR) because you probably can’t get enough good Firepower data to make your network secure or more secure, but that’s another blog post…just keep this in mind.

So how does Cisco Choose the rules to enable for each IPS base policy?

There are almost 7 Billion people in the world now, and probably less than a dozen people in the world (within Talos) actually knew the answer to how and why rules were enabled in the Cisco Firepower System, and they weren’t talking. Sure, there were some old  documents from the Sourcefire days that discussed (the last updated document was in 2014!) CVSS scores, categories, date of rule, etc, but nothing recent or anything that made sense on why they are listing everything as enabled by Rule Overhead.

My post received a lot of traction, mostly good because I wasn’t attacking Cisco on the rule set, but because I was telling a story on how changing from the default IPS policy of Balance Security and Connectivity to a higher policy can be useful to find problems, and the post provided an excellent example of how I used a Security over Connectivity policy to be successful at a large customer.

However, there was going to be some pushback expected, and the end result was that Cisco did respond, and will be fixing/clarifying some of the issues that I brought up in that earlier post, and to clarify they said: “inaccurate, albeit understandable, assumptions”… with that said, Cisco did end their email with “TALOS team will be looking into the misunderstanding seen in the blog, as well as the remediations they’re planning on making to ensure the behavior of the product is more intuitive & clear in this area.”

Personal note:

Now you might be thinking that this was an ego trip, etc, on my part to find and amplify these questions regarding the IPS policy and get a lot of hits on a blog post, but my goal and reasoning is always and only always my business bottom line – period. Meaning that if I cannot fix a Firepower issue at a customer (or teach) because of lack of documentation or understanding, that this is going to affect both my customers as well as my own bottom line (I can easily include cisco’s in here as well).

My intentions are only to make sure that my customers are working to the best of my ability. Since this may include confronting Cisco on some issues, this direction may upset people at Talos at times, and I understand that, but they aren’t paying me, my customers are. Same with you; either the company you’re employed at, and/or your customers, are your bottom line, not Cisco feelings, which is why you always call and yell at Cisco TAC. Yes, I know you do.

Quick Summary Answer if you don’t want to read the rest of this blog post (You’re welcome):

Bottom line is that Cisco responded regarding my blog, and I will summarize their response for you: “The Rule Overhead was meant to only be used with the Cisco Firepower Recommendation (RR) Slider bar, and should not have been in the Rule Accordion, so they will be deleting that Rule Overhead section from that location in the IPS policy.” With all that said, does this solve the issue? No, not really, now they are just going to make it harder for us to find this information; yes, that was their solution. Why do I say this? Because if you have SoC, weather or not you enable Firepower RR, the listed high overhead rules will still never be enabled. Again, they are just taking this view away from us, that’s all.

So now we’ll have to look elsewhere to find how they enable the rules in each Cisco provided IPS policy. Where? Well, that won’t be quite as easy, but look no further than the metadata in a Snort rule as such:

alert udp $HOME_NET any -> any 53 (msg:”APP-DETECT DNS request for Dynamic Internet Technology domain dongtaiwang.net”; flow:to_server; byte_test:1,!&,0xF8,2; content:”|0B|dongtaiwang|03|net|00|”; fast_pattern:only; metadata:policy max-detect-ips drop, policy security-ips drop, service dns; reference:url,wikipedia.org/wiki/Freegate; classtype:misc-activity; sid:27997; rev:2; gid:1; )

Looking at the metadata section, we can see that this rule 27997 is enabled in the Maximum Detection and Security over Connectivity polices.

You can also see all the rules enabled in the IPS policy by typing “metadata:policy” in the filter bar as such to get the enabled rules for each policy:

Your four metadata filters are: metadata:connectivty, metadata:balanced, matadata:security, and metadata:max

I’ll be fleshing out the changes when they come out with 6.5 code…

For those that want to know more:

Here is the full email for your reading pleasure, then I’ll finish this post by listing how Talos says the rules are chosen for each Cisco policy.

The “Rule Overhead” available values of Low, Medium, High, and Very High were intended to provide customers a way of limiting the the rulesets enabled when using Recommended Rules so RR would not enable rules in more security conscientious base Intrusion Policies. These rulesets resulting from these filters are determined programmatically by the FMC at the time the SRU is imported, and are not pre-built by Talos.

Low —> Set of rules from ‘Connectivity over Security’

Medium —> Set of rules from ‘Balanced Security and Connectivity,’ excluding rules included in the ruleset resulting from using the ‘Low’ filter

High —> Set of rules from ’Security over Connectivity,’ excluding rules included in the ruleset resulting from using the ‘Medium’ filter

Very High —> Set of all rules, excluding rules included in the ruleset resulting from using the ‘High’ filter

It appears this functionality, which was originally intended to be applicable for Recommended Rules, was also included in the Rule Selection Editor in the Intrusion Policy. This is an error, as constraining the rulesets based upon Talos-provided base Intrusion Policies are already provided via the ‘Base Policy’ selector when the Intrusion Policy is first created.

Additionally, “Rule Overhead” is an inaccurate way of describing the functionality in the first place, as it gives the impression Talos has some universal metric used to quantify the performance impact of a given rule. This is not the case. The base Intrusion Policies any given snort rule is enabled by default in are determined by a combination of the CVSS score (where applicable) of the vulnerability the rule is designed to protect against exploitation of, as well as constrain the rulesets based upon how old, or how prevalent threats are. Published details can be found here https://www.snort.org/faq/why-are-rules-commented-out-by-default.

Finally, there appears to be a small, albeit present, discrepancy between the rulesets enabled in each base Intrusion Policy Talos ships and the rulesets resulting from the various Low/Medium/High/VeryHigh filters from Recommended Rules. TALOS will be working internally to identify the source of that discrepancy & remediate it.

To this end, Talos will work on the following issue internally:

1: Update the Slider Bar in Recommended Rules to reference the base policies, instead of “Rule Overhead” (update Oct 2019: This never happened)

2: Update the Rule Selection Editor in the Intrusion Policy to remove the “Rule Overhead” as a method of filtering for rules (update Oct 2019: This never happened)

3: Update the product documentation to more accurately reflect how the slider bar in Recommended Rules leverages base policies to constrain the rulesets that the product will automatically enable. (update Oct 2019: This never happened)

Hopefully, this makes it clear that the blog post referenced makes a set of conclusions based upon inaccurate, albeit understandable, assumptions about how the product & Talos select rules to be enabled in the various base Intrusion Policies. TALOS team will be looking into the misunderstanding seen in the blog, as well as the remediations they’re planning on making to ensure the behavior of the product is more intuitive & clear in this area.

All Our Love, 

Talos

(I might have embellished the signature section a little…)

 

Lastly, here is the newest information on how the four Cisco authored polices enable and disable rules, as said so by God, err.. I mean Cisco Talos:

1. Connectivity over Security
   1. This policy is specifically designed to favor device performance over the security controls in the policy. It should allow a customer to deploy one of our devices with minimal false positives and full rated performance of the box in most network deployments. In addition, this policy should detect the most common and most prevalent threats our customers will experience.
   2. Criteria:
      1. CVSS Score = 10
      2. CVE year is current – 2 (So, for example, 2019, 2018, 2017)
2. Balanced
   1. This policy is the default policy that is recommended for initial deployments. This policy attempts to balance security needs and performance characteristics. Customers should be able to start with this policy and get a very good block rate with public evaluation tools, and relatively high performance rate with evaluation and testing tools. It is the default shipping state of the Snort Subscriber Ruleset for Open-Source Snort.
   2. Criteria:
      1. CVSS Score >= 9
      2. CVE year is current – 2 (For example, 2019, 2018, 2017)
      3. MALWARE-CNC rules
      4. EXPLOIT-KIT rules
      5. SQL Injection rules
      6. Blacklist rules
      7. Includes the rules in the Connectivity over Security policy.
3. Security over Connectivity
   1. This policy is designed for the small segment of our customer base that is exceptionally concerned about organizational security (translation: people that care enough to look into network analysis on their IPS events) Customers deploy this policy in protected networks, that have a lower bandwidth requirements, but much higher security requirements. Additionally, customers care less about false positives and noisy signatures. Application control, and locked down network usage are also concerns to customers deploying this policy. It should provide maximum protection, and application control, but should not bring the network down.
   2. Criteria:
      1. CVSS Score >= 8
      2. CVE year is current -3 (For example, 2019, 2018, 2017, 2016)
      3. MALWARE-CNC rules
      4. EXPLOIT-KIT rules
      5. SQL Injection rules
      6. Blacklist rules
      7. App-detect rules
      8. Includes the rules in the Connectivity over Security and Balanced policies.
4. Maximum Detection
   1. This ruleset is meant to be used in testing environments and as such is not optimized for performance. False Positives for many of the rules in this policy are tolerated and/or expected and FP investigations will normally not be undertaken.
   2. Criteria:
      1. The coverage is required for in field testing
      2. Includes rules in the Security, Balanced, and Connectivity rule sets.
      3. Includes all active rules above Sid:10000, unless otherwise specified. (holy crap! First, it’s unlikely many of you are reading this far, but read #3 again if you’re still with me. That’s why this policy has about 28k rules enabled; since there are about 38k rules now…)

 

…So what does this all mean? How can I tell what is enabled by default? Not sure completely yet, only time will tell now, and I’m sure I’ll add a part III to this soon.

I think I hear the doorbell, oh its Fed Ex…