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.<\/p>\n

More\u2026 Read more on Cisco Blogs<\/a><\/p>\n

\u200b<\/p>\n

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.<\/p>\n

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.<\/p>\n

For example, let\u2019s 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.<\/p>\n

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.<\/p>\n

Collect the vulnerability threat intelligence<\/strong><\/h2>\n

It\u2019s 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\u2019ll use a prebuilt API call, available in the API Reference<\/a>.<\/p>\n\n

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:<\/p>\n

Active Internet Breach\u2014The vulnerability has been used in breach activity in the wild.
\nEasily Exploitable\u2014It is not difficult to successfully exploit the vulnerability.
\nRemote Code Execution\u2014If exploited, the vulnerability allows for arbitrary code to be run on the compromised system from a remote location.<\/p>\n

To obtain a list of high-risk CVEs, we\u2019ll set the risk score to 100, enable these three filters, and then run a query.<\/p>\n\n

With the output list in hand, let\u2019s go see which of these are triggering IPS alerts on our Secure Firewall.<\/p>\n

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, \u00a0but is covered in the Cisco Secure Firewall Management Center Administration Guide<\/a>.) In this case we will look at the total number of alerts seen for rules associated with CVEs.<\/p>\n

Naturally, if you\u2019re doing this within your own organization, you\u2019ll be looking at alerts seen from firewalls that are part of your network. Our example here will be slightly different in that we\u2019ll 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\u2019re able to look at a larger swath of activity across the threat landscape.<\/p>\n

Let\u2019s 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.<\/p>\n

CVE<\/strong>
\nDescription<\/strong>
\n1
\nCVE-2021-44228
\nApache Log4j logging remote code execution attempt
\n2
\nCVE-2018-11776
\nApache Struts OGNL getRuntime.exec static method access attempt
\n3
\nCVE-2014-6271
\nBash CGI environment variable injection attempt
\n4
\nCVE-2022-26134
\nAtlassian Confluence OGNL expression injection attempt
\n5
\nCVE-2022-22965
\nJava ClassLoader access attempt
\n6
\nCVE-2014-0114
\nJava ClassLoader access attempt
\n7
\nCVE-2017-9791
\nApache Struts remote code execution attempt (Struts 1 plugin)
\n8
\nCVE-2017-5638
\nApache Struts remote code execution attempt (Jakarta Multipart parser)
\n9
\nCVE-2017-12611
\nApache Struts remote code execution attempt (Freemaker tag)
\n10
\nCVE-2016-3081
\nApache Struts remote code execution attempt (Dynamic Method Invocation)<\/p>\n

What\u2019s 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Check out the Cisco Vulnerability Management API<\/a> for descriptions of various API calls and make sample code that you can use, written from your choice of programming languages.<\/p>\n

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<\/a>. Information on the CVEs associated with various Snort rules can be found in the Snort Rule Documentation<\/a>.<\/p>\n

We hope this example is helpful. This is a fairly basic model, as it\u2019s 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.<\/p>\n

Methodology<\/strong><\/h2>\n

This analysis looks at the standard text rules and Shared Object rules<\/a> 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.<\/p>\n

The IPS data we\u2019re 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.<\/p>\n

Looking at the total number of alerts will show us which rules alert the most frequently. In-and-of-itself this isn\u2019t a great indicator of severity, as some rules cause more alerts than others. This is also why we\u2019ve looked at the percentage of organizations that see an alert in past analysis<\/a> 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.<\/p>\n

We\u2019d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!<\/em><\/p>\n

Cisco Secure Social Channels<\/strong><\/p>\n

Instagram<\/a><\/strong>Facebook<\/a><\/strong>Twitter<\/a><\/strong>LinkedIn<\/a><\/strong><\/p>\n

\n\t\tShare\n

\n

<\/div>\n<\/div>\n

\n

\n\t\t<\/a>\n\t<\/div>\n<\/div>\n

\n

\n\t\t<\/a>\n\t<\/div>\n<\/div>\n

\n

\n\t <\/a>\n\t<\/div>\n<\/div>\n<\/div>\n

Share:<\/div>\n

\n

\n

<\/div>\n<\/div>\n

\n

\n\t\t<\/a>\n\t<\/div>\n<\/div>\n

\n

\n\t\t<\/a>\n\t<\/div>\n<\/div>\n

\n

\n\t <\/a>\n\t<\/div>\n<\/div>\n<\/div>\n

\u00a0\u00a0Learn how to take threat intelligence data available in Cisco Vulnerability Management and use it to uncover trends in Cisco Secure Firewall, uncovering new insights.\u00a0\u00a0Read More<\/a>\u00a0Cisco Blogs\u00a0<\/p>","protected":false},"excerpt":{"rendered":"

<\/p>\n

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.<\/p>\n

More\u2026 Read more on Cisco Blogs<\/a><\/p>\n

\u200b<\/p>\n

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.<\/p>\n

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.<\/p>\n

For example, let\u2019s 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.<\/p>\n

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.<\/p>\n

Collect the vulnerability threat intelligence<\/strong><\/h2>\n

It\u2019s 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\u2019ll use a prebuilt API call, available in the API Reference<\/a>.<\/p>\n

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:<\/p>\n

Active Internet Breach\u2014The vulnerability has been used in breach activity in the wild.
\nEasily Exploitable\u2014It is not difficult to successfully exploit the vulnerability.
\nRemote Code Execution\u2014If exploited, the vulnerability allows for arbitrary code to be run on the compromised system from a remote location.<\/p>\n

To obtain a list of high-risk CVEs, we\u2019ll set the risk score to 100, enable these three filters, and then run a query.<\/p>\n

With the output list in hand, let\u2019s go see which of these are triggering IPS alerts on our Secure Firewall.<\/p>\n

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, \u00a0but is covered in the Cisco Secure Firewall Management Center Administration Guide<\/a>.) In this case we will look at the total number of alerts seen for rules associated with CVEs.<\/p>\n

Naturally, if you\u2019re doing this within your own organization, you\u2019ll be looking at alerts seen from firewalls that are part of your network. Our example here will be slightly different in that we\u2019ll 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\u2019re able to look at a larger swath of activity across the threat landscape.<\/p>\n

Let\u2019s 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.<\/p>\n

CVE<\/strong>
\nDescription<\/strong>
\n1
\nCVE-2021-44228
\nApache Log4j logging remote code execution attempt
\n2
\nCVE-2018-11776
\nApache Struts OGNL getRuntime.exec static method access attempt
\n3
\nCVE-2014-6271
\nBash CGI environment variable injection attempt
\n4
\nCVE-2022-26134
\nAtlassian Confluence OGNL expression injection attempt
\n5
\nCVE-2022-22965
\nJava ClassLoader access attempt
\n6
\nCVE-2014-0114
\nJava ClassLoader access attempt
\n7
\nCVE-2017-9791
\nApache Struts remote code execution attempt (Struts 1 plugin)
\n8
\nCVE-2017-5638
\nApache Struts remote code execution attempt (Jakarta Multipart parser)
\n9
\nCVE-2017-12611
\nApache Struts remote code execution attempt (Freemaker tag)
\n10
\nCVE-2016-3081
\nApache Struts remote code execution attempt (Dynamic Method Invocation)<\/p>\n

What\u2019s 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Check out the Cisco Vulnerability Management API<\/a> for descriptions of various API calls and make sample code that you can use, written from your choice of programming languages.<\/p>\n

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<\/a>. Information on the CVEs associated with various Snort rules can be found in the Snort Rule Documentation<\/a>.<\/p>\n

We hope this example is helpful. This is a fairly basic model, as it\u2019s 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.<\/p>\n

Methodology<\/strong><\/h2>\n

This analysis looks at the standard text rules and Shared Object rules<\/a> 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.<\/p>\n

The IPS data we\u2019re 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.<\/p>\n

Looking at the total number of alerts will show us which rules alert the most frequently. In-and-of-itself this isn\u2019t a great indicator of severity, as some rules cause more alerts than others. This is also why we\u2019ve looked at the percentage of organizations that see an alert in past analysis<\/a> 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.<\/p>\n

We\u2019d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!<\/em><\/p>\n

Cisco Secure Social Channels<\/strong><\/p>\n

Instagram<\/a><\/strong>Facebook<\/a><\/strong>Twitter<\/a><\/strong>LinkedIn<\/a><\/strong><\/p>\n

\n\t\tShare<\/p>\n

\n

<\/div>\n<\/div>\n

\n

\n\t\t<\/a>\n\t<\/div>\n<\/div>\n

\n

\n\t\t<\/a>\n\t<\/div>\n<\/div>\n

\n

\n\t <\/a>\n\t<\/div>\n<\/div>\n<\/div>\n

Share:<\/div>\n

\n

\n

<\/div>\n<\/div>\n

\n

\n\t\t<\/a>\n\t<\/div>\n<\/div>\n

\n

\n\t\t<\/a>\n\t<\/div>\n<\/div>\n

\n

\n\t <\/a>\n\t<\/div>\n<\/div>\n<\/div>\n

\u00a0\u00a0Learn how to take threat intelligence data available in Cisco Vulnerability Management and use it to uncover trends in Cisco Secure Firewall, uncovering new insights.\u00a0\u00a0Read More<\/a>\u00a0Cisco Blogs\u00a0<\/p>\n

<\/p>\n","protected":false},"author":0,"featured_media":1545,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[],"class_list":["post-1544","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cisco-learning"],"yoast_head":"\n