When it comes to staying on top of security events, a good application that alerts on security events is better than none. It stands to reason then that two would be better than one, and so on.
More data can be a double-edged sword. You want to know when events happen across different systems and through disparate vectors. However alert fatigue is a real thing, so quality over quantity matters. The real power of having event data from multiple security applications comes when you can combine two or more sources to uncover new insights about your security posture.
For example, let’s take a look at what happens when we take threat intelligence data available in Cisco Vulnerability Management and use it to uncover trends in IPS telemetry from Cisco Secure Firewall.
This is something that you can do yourself if you have these Cisco products. Start by looking up the latest threat intelligence data in Cisco Vulnerability Management, and then gather Snort IPS rule data for vulnerabilities that have alerted on your Secure Firewall. Compare the two and you may be surprised with what you find.
Collect the vulnerability threat intelligence
It’s very easy to stay on top of a variety of vulnerability trends using the API Reference that is available in Cisco Vulnerability Management Premier tier. For this example, we’ll use a prebuilt API call, available in the API Reference.
This API call allows you to set a risk score and choose from a handful of filters that can indicate that a vulnerability is a higher risk:
- Active Internet Breach—The vulnerability has been used in breach activity in the wild.
- Easily Exploitable—It is not difficult to successfully exploit the vulnerability.
- Remote Code Execution—If exploited, the vulnerability allows for arbitrary code to be run on the compromised system from a remote location.
To obtain a list of high-risk CVEs, we’ll set the risk score to 100, enable these three filters, and then run a query.
With the output list in hand, let’s go see which of these are triggering IPS alerts on our Secure Firewall.
Obtaining IPS telemetry from Secure Firewall is easy and there are a several of ways that you can organize and export this data. (Setting up reporting is beyond the scope of this example, but is covered in the Cisco Secure Firewall Management Center Administration Guide.) In this case we will look at the total number of alerts seen for rules associated with CVEs.
Naturally, if you’re doing this within your own organization, you’ll be looking at alerts seen from firewalls that are part of your network. Our example here will be slightly different in that we’ll look across alerts from organizations that have opted in to share their Secure Firewall telemetry with us. The analysis is similar in either case, but the added bonus with our example is that we’re able to look at a larger swath of activity across the threat landscape.
Let’s filter the IPS telemetry by the CVEs pulled from the Cisco Vulnerability Management API. You can do this analysis with whatever data analytics tool you prefer. The result in this case is a top ten list of high-risk CVEs that Secure Firewall has alerted on.
| CVE | Description | |
| 1 | CVE-2021-44228 | Apache Log4j logging remote code execution attempt |
| 2 | CVE-2018-11776 | Apache Struts OGNL getRuntime.exec static method access attempt |
| 3 | CVE-2014-6271 | Bash CGI environment variable injection attempt |
| 4 | CVE-2022-26134 | Atlassian Confluence OGNL expression injection attempt |
| 5 | CVE-2022-22965 | Java ClassLoader access attempt |
| 6 | CVE-2014-0114 | Java ClassLoader access attempt |
| 7 | CVE-2017-9791 | Apache Struts remote code execution attempt (Struts 1 plugin) |
| 8 | CVE-2017-5638 | Apache Struts remote code execution attempt (Jakarta Multipart parser) |
| 9 | CVE-2017-12611 | Apache Struts remote code execution attempt (Freemaker tag) |
| 10 | CVE-2016-3081 | Apache Struts remote code execution attempt (Dynamic Method Invocation) |
What’s interesting here is that, while this is a list of ten unique CVEs, there are only five unique applications here. In particular, Apache Struts comprises 5 of the top 10.
By ensuring that these five applications are fully patched, you cover the top ten most frequently exploited vulnerabilities that have RCEs, are easily exploitable, and are known to be used in active internet breaches.
In many ways analysis like this can greatly simplify the process of deciding what to patch. Want to simplify the process even further? Here are a few things to help.
Check out the Cisco Vulnerability Management API for descriptions of various API calls and make sample code that you can use, written from your choice of programming languages.
Want to run the analysis outlined here? Some basic Python code that includes the API calls, plus a bit of code to save the results, is available here on Github. Information on the CVEs associated with various Snort rules can be found in the Snort Rule Documentation.
We hope this example is helpful. This is a fairly basic model, as it’s meant for illustrative purposes, so feel free to tune the model to best suit your needs. And hopefully combining these sources provides you with further insight into your security posture.
Methodology
This analysis looks at the standard text rules and Shared Object rules in Snort, both provided by Talos. We compared data sets using Tableau, looking at Snort signatures that only belong to the Connectivity over Security, Balanced, and Security over Connectivity base policies.
The IPS data we’re using comes from Snort IPS instances included with Cisco Secure Firewall. The data set covers June 1-30, 2023, and the Cisco Vulnerability Management API calls were performed in early July 2023.
Looking at the total number of alerts will show us which rules alert the most frequently. In-and-of-itself this isn’t a great indicator of severity, as some rules cause more alerts than others. This is also why we’ve looked at the percentage of organizations that see an alert in past analysis instead. However, this time we compared the total number of alerts against a list of vulnerabilities that we know are severe thanks to the risk score and other variables. This makes the total number of alerts more meaningful within this context.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Security on social!
Cisco Security Social Channels
Instagram
Facebook
Twitter
LinkedIn
CONNECT WITH US