easy-accordion-free domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114zoho-flow domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114wordpress-seo domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114Modern-day vulnerability management tends to follow a straightforward procedure. From a high level, this can be summed up in the following steps:<\/p>\n
Identify the vulnerabilities in your\u2026 Read more on Cisco Blogs<\/a><\/p>\n \u200b<\/p>\n Modern-day vulnerability management tends to follow a straightforward procedure. From a high level, this can be summed up in the following steps:<\/p>\n Identify the vulnerabilities in your environment When high-profile vulnerabilities are disclosed, they tend to be prioritized due to concerns that your organization will be hammered with exploit attempts. The general impression is that this malicious activity is highest shortly after disclosure, then decreases as workarounds and patches are applied. The idea is that we eventually reach a critical mass, where enough systems are patched that the exploit is no longer worth attempting.<\/p>\n In this scenario, if we were to graph malicious activity and time, we end up with what is often referred to as a long-tail distribution<\/a>. Most of the activity occurs early on, then drops off over time to form a long tail. This looks something like the following:<\/p>\n\n A long tail distribution of exploit attempts sounds reasonable in theory. The window of usefulness for an exploit is widest right after disclosure, then closes over time until bad actors move on to other, more recent vulnerabilities.<\/p>\n But is this how exploitation attempts really play out? Do attackers abandon exploits after a certain stage, moving on to newer and more fruitful vulnerabilities? And if not, how do attackers approach vulnerability exploitation?<\/p>\n To answer these questions, we\u2019ll look at Snort data from Cisco Secure Firewall. Many Snort rules protect against the exploitation of vulnerabilities, making this a good data set to examine as we attempt to answer these questions.<\/p>\n We\u2019ll group Snort rules by the CVEs mentioned in the rule documentation<\/a>, and then look at CVEs that see frequent exploit attempts. Since CVEs are disclosed on different dates, and we\u2019re looking at alerts over time, the specific time frame will vary. In some cases, the disclosure date is earlier than the range our data set covers. While we won\u2019t be able to examine the initial disclosure period for these, we\u2019ll look at a few of these as well for signs of a long tail.<\/p>\n Finally, looking at a count of rule triggers can be misleading\u2014a few organizations can see many alerts for one rule in a short time frame, making the numbers look larger than they are across all orgs. Instead, we\u2019ll look at the percentage of organizations that saw an alert. We\u2019ll then break this out on a month-to-month basis.<\/p>\n The Log4J vulnerability<\/a> has dominated our vulnerability metrics since it was disclosed in December 2021. However, looking at the percentage of exploit attempts each month since, there was neither a spike in use right after disclosure, nor a long tail afterwards.<\/p>\n\n That first month, 27 percent of organizations saw alerts for Log4J. Since then, alerts have neither dropped off nor skyrocketed from one month to the next. The percent of organizations seeing alerts range from 25-34 percent through June 2023, averaging out at 28 percent per month.<\/p>\n Perhaps Log4J is an exception to the rule. It\u2019s an extremely common software component and a very popular target. A better approach might be to look at a lesser-known vulnerability to see how the curve looks.<\/p>\n Spring4Shell<\/a> was disclosed at the end of March 2022. This was a vulnerability in the Spring Java framework that managed to resurrect an older vulnerability in JDK9, which had initially been discovered and patched in 2010. At the time of Spring4Shell\u2019s disclosure there was speculation that this could be the next Log4J<\/a>, hence the similarity in naming. Such predictions failed to materialize.<\/p>\n\n We did see a decent amount of Spring4Shell activity immediately after the disclosure, where 23 percent of organizations saw alerts. After this honeymoon period, the percentage did decline. But instead of exhibiting the curve of a long tail, the percentages have remained between 14-19 percent a month.<\/p>\n Keen readers will notice the activity in the graph above that occurs prior to disclosure. These alerts are for rules covering the initial, more-than-a-decade-old Java vulnerability, CVE-2010-1622. This is interesting in two ways:<\/p>\n The fact that these rules were still triggering monthly on a 13-year-old vulnerability prior to Spring4Shell\u2019s disclosure provides the first signs of a potential long tail. Unfortunately, the time frame of our alert data isn\u2019t long enough to say what the initial disclosure phase for CVE-2010-1622 looked like. So since we don\u2019t have enough information here to draw a conclusion, what about other older vulnerabilities that we know were in heavy rotation?<\/p>\n It\u2019s hard to believe, but the ShellShock vulnerability<\/a> recently turned nine. By software development standards this qualifies it for senior citizen status, making it a perfect candidate to examine. While we don\u2019t have the initial disclosure phase, activity remains high to this day.<\/p>\n\n Our data set begins approximately seven years after disclosure, but the percentage of organizations seeing alerts ranges from 12-23 percent. On average across this timeframe, about one in five organizations see ShellShock alerts in a month.<\/p>\n While we\u2019ve showcased 3-4 examples here, a pattern does emerge when looking at other vulnerabilities, both old and new. For example, here is CVE-2022-26134, a vulnerability discovered in Atlassian Confluence in June 2022.<\/p>\n\n Here is ProxyShell, which was initially discovered in August 2021, followed by two more related vulnerabilities in September 2022.<\/p>\n\n And here is another older, commonly targeted vulnerability in PHPUnit, originally disclosed in June 2017.<\/p>\n\n What emerges from looking at vulnerability alerts over time is that, while there is sometimes an initial spike in usage, they don\u2019t appear to decline to a negligible level. Instead, vulnerabilities stick around for years after their initial disclosure.<\/p>\n So why do old vulnerabilities remain in use? One reason is that many of these exploitation attempts are automated attacks. Bad actors routinely leverage scripts and applications that allow them to quickly run exploit code against a large swaths of IP addresses in the hopes of finding vulnerable machines.<\/p>\n This is further evidenced by looking at the concentration of alerts by organization. In many cases we see sudden spikes in the total number of alerts seen each month. If we break these months down by organization, we regularly see that alerts at one or two organizations are responsible for the spikes.<\/p>\n For example, take a look at the total number of Snort alerts for an arbitrary vulnerability. In this example, December was in line with the months that preceded it. Then in January, the total number of alerts began to grow, peaking in February, before declining back to average levels.<\/p>\n\n The cause of the sudden spike, highlighted in light blue, is one organization that was hammered by alerts for this vulnerability. The organization saw little-to-no alerts in December before a wave hit that lasted from January through March. It then completely disappeared by April.<\/p>\n This is a common phenomenon seen in overall counts (and why we don\u2019t draw trends from this data alone). This could be the result of automated scans by bad actors. These attackers may have found one such vulnerable system at this organization, then proceeded to hammer it with exploit attempts in the months that followed.<\/p>\n So is the long tail a myth when it comes to vulnerabilities? It certainly appears so\u2014at least when it comes to the types of attacks that target the perimeter of an organization. The public facing applications that reside here present a large attack surface. Public proof-of-concept exploits are often readily available and are relatively easy to fold into attacker\u2019s existing automated exploitation frameworks. There\u2019s little risk for an attacker involved in automated exploit attempts, leaving little incentive to remove exploits once they\u2019ve been added to an attack toolkit.<\/p>\n What is left to explore is whether long-tail vulnerabilities exist in other attack surfaces. The fact is that there are different classes of vulnerabilities that can be leveraged in different ways. We\u2019ll explore more of these facets in the future.<\/p>\n Finding that one vulnerable, public-facing system at an organization is a needle-in-a-haystack operation for attackers, requiring regular scanning to find it. But all it takes is one new system without the latest patches applied to give the attackers an opportunity to gain a foothold.<\/p>\n The silver lining here is that a firewall with an intrusion prevention system, like Cisco Secure Firewall, is designed specifically to prevent successful attacks.\u00a0 Beyond IPS prevention of these attacks, the recently introduced Cisco Secure Firewall 4200 appliance and 7.4 OS bring enterprise-class performance and a host of new features including SD-WAN, ZTNA, and the ability to detect apps and threats in encrypted traffic without decryption.<\/p>\n Also, if you\u2019re looking for a solution to assist you with vulnerability management, Cisco Vulnerability Management has you covered. Cisco Vulnerability Management equips you with the contextual insight and threat intelligence needed to intercept the next exploit and respond with precision.<\/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 \u00a0\u00a0A long tail distribution of exploit attempts sounds reasonable. But is this how exploitation attempts really play out? Do attackers abandon exploits after a certain stage? To answer these questions, we\u2019ll look at Snort data from Cisco Secure Firewall.\u00a0\u00a0Read More<\/a>\u00a0Cisco Blogs\u00a0<\/p>","protected":false},"excerpt":{"rendered":" <\/p>\n Modern-day vulnerability management tends to follow a straightforward procedure. From a high level, this can be summed up in the following steps:<\/p>\n Identify the vulnerabilities in your\u2026 Read more on Cisco Blogs<\/a><\/p>\n \u200b<\/p>\n Modern-day vulnerability management tends to follow a straightforward procedure. From a high level, this can be summed up in the following steps:<\/p>\n Identify the vulnerabilities in your environment When high-profile vulnerabilities are disclosed, they tend to be prioritized due to concerns that your organization will be hammered with exploit attempts. The general impression is that this malicious activity is highest shortly after disclosure, then decreases as workarounds and patches are applied. The idea is that we eventually reach a critical mass, where enough systems are patched that the exploit is no longer worth attempting.<\/p>\n In this scenario, if we were to graph malicious activity and time, we end up with what is often referred to as a long-tail distribution<\/a>. Most of the activity occurs early on, then drops off over time to form a long tail. This looks something like the following:<\/p>\n A long tail distribution of exploit attempts sounds reasonable in theory. The window of usefulness for an exploit is widest right after disclosure, then closes over time until bad actors move on to other, more recent vulnerabilities.<\/p>\n But is this how exploitation attempts really play out? Do attackers abandon exploits after a certain stage, moving on to newer and more fruitful vulnerabilities? And if not, how do attackers approach vulnerability exploitation?<\/p>\n To answer these questions, we\u2019ll look at Snort data from Cisco Secure Firewall. Many Snort rules protect against the exploitation of vulnerabilities, making this a good data set to examine as we attempt to answer these questions.<\/p>\n We\u2019ll group Snort rules by the CVEs mentioned in the rule documentation<\/a>, and then look at CVEs that see frequent exploit attempts. Since CVEs are disclosed on different dates, and we\u2019re looking at alerts over time, the specific time frame will vary. In some cases, the disclosure date is earlier than the range our data set covers. While we won\u2019t be able to examine the initial disclosure period for these, we\u2019ll look at a few of these as well for signs of a long tail.<\/p>\n Finally, looking at a count of rule triggers can be misleading\u2014a few organizations can see many alerts for one rule in a short time frame, making the numbers look larger than they are across all orgs. Instead, we\u2019ll look at the percentage of organizations that saw an alert. We\u2019ll then break this out on a month-to-month basis.<\/p>\n The Log4J vulnerability<\/a> has dominated our vulnerability metrics since it was disclosed in December 2021. However, looking at the percentage of exploit attempts each month since, there was neither a spike in use right after disclosure, nor a long tail afterwards.<\/p>\n That first month, 27 percent of organizations saw alerts for Log4J. Since then, alerts have neither dropped off nor skyrocketed from one month to the next. The percent of organizations seeing alerts range from 25-34 percent through June 2023, averaging out at 28 percent per month.<\/p>\n Perhaps Log4J is an exception to the rule. It\u2019s an extremely common software component and a very popular target. A better approach might be to look at a lesser-known vulnerability to see how the curve looks.<\/p>\n Spring4Shell<\/a> was disclosed at the end of March 2022. This was a vulnerability in the Spring Java framework that managed to resurrect an older vulnerability in JDK9, which had initially been discovered and patched in 2010. At the time of Spring4Shell\u2019s disclosure there was speculation that this could be the next Log4J<\/a>, hence the similarity in naming. Such predictions failed to materialize.<\/p>\n We did see a decent amount of Spring4Shell activity immediately after the disclosure, where 23 percent of organizations saw alerts. After this honeymoon period, the percentage did decline. But instead of exhibiting the curve of a long tail, the percentages have remained between 14-19 percent a month.<\/p>\n Keen readers will notice the activity in the graph above that occurs prior to disclosure. These alerts are for rules covering the initial, more-than-a-decade-old Java vulnerability, CVE-2010-1622. This is interesting in two ways:<\/p>\n The fact that these rules were still triggering monthly on a 13-year-old vulnerability prior to Spring4Shell\u2019s disclosure provides the first signs of a potential long tail. Unfortunately, the time frame of our alert data isn\u2019t long enough to say what the initial disclosure phase for CVE-2010-1622 looked like. So since we don\u2019t have enough information here to draw a conclusion, what about other older vulnerabilities that we know were in heavy rotation?<\/p>\n It\u2019s hard to believe, but the ShellShock vulnerability<\/a> recently turned nine. By software development standards this qualifies it for senior citizen status, making it a perfect candidate to examine. While we don\u2019t have the initial disclosure phase, activity remains high to this day.<\/p>\n Our data set begins approximately seven years after disclosure, but the percentage of organizations seeing alerts ranges from 12-23 percent. On average across this timeframe, about one in five organizations see ShellShock alerts in a month.<\/p>\n While we\u2019ve showcased 3-4 examples here, a pattern does emerge when looking at other vulnerabilities, both old and new. For example, here is CVE-2022-26134, a vulnerability discovered in Atlassian Confluence in June 2022.<\/p>\n Here is ProxyShell, which was initially discovered in August 2021, followed by two more related vulnerabilities in September 2022.<\/p>\n And here is another older, commonly targeted vulnerability in PHPUnit, originally disclosed in June 2017.<\/p>\n What emerges from looking at vulnerability alerts over time is that, while there is sometimes an initial spike in usage, they don\u2019t appear to decline to a negligible level. Instead, vulnerabilities stick around for years after their initial disclosure.<\/p>\n So why do old vulnerabilities remain in use? One reason is that many of these exploitation attempts are automated attacks. Bad actors routinely leverage scripts and applications that allow them to quickly run exploit code against a large swaths of IP addresses in the hopes of finding vulnerable machines.<\/p>\n This is further evidenced by looking at the concentration of alerts by organization. In many cases we see sudden spikes in the total number of alerts seen each month. If we break these months down by organization, we regularly see that alerts at one or two organizations are responsible for the spikes.<\/p>\n For example, take a look at the total number of Snort alerts for an arbitrary vulnerability. In this example, December was in line with the months that preceded it. Then in January, the total number of alerts began to grow, peaking in February, before declining back to average levels.<\/p>\n The cause of the sudden spike, highlighted in light blue, is one organization that was hammered by alerts for this vulnerability. The organization saw little-to-no alerts in December before a wave hit that lasted from January through March. It then completely disappeared by April.<\/p>\n This is a common phenomenon seen in overall counts (and why we don\u2019t draw trends from this data alone). This could be the result of automated scans by bad actors. These attackers may have found one such vulnerable system at this organization, then proceeded to hammer it with exploit attempts in the months that followed.<\/p>\n So is the long tail a myth when it comes to vulnerabilities? It certainly appears so\u2014at least when it comes to the types of attacks that target the perimeter of an organization. The public facing applications that reside here present a large attack surface. Public proof-of-concept exploits are often readily available and are relatively easy to fold into attacker\u2019s existing automated exploitation frameworks. There\u2019s little risk for an attacker involved in automated exploit attempts, leaving little incentive to remove exploits once they\u2019ve been added to an attack toolkit.<\/p>\n What is left to explore is whether long-tail vulnerabilities exist in other attack surfaces. The fact is that there are different classes of vulnerabilities that can be leveraged in different ways. We\u2019ll explore more of these facets in the future.<\/p>\n Finding that one vulnerable, public-facing system at an organization is a needle-in-a-haystack operation for attackers, requiring regular scanning to find it. But all it takes is one new system without the latest patches applied to give the attackers an opportunity to gain a foothold.<\/p>\n The silver lining here is that a firewall with an intrusion prevention system, like Cisco Secure Firewall, is designed specifically to prevent successful attacks.\u00a0 Beyond IPS prevention of these attacks, the recently introduced Cisco Secure Firewall 4200 appliance and 7.4 OS bring enterprise-class performance and a host of new features including SD-WAN, ZTNA, and the ability to detect apps and threats in encrypted traffic without decryption.<\/p>\n Also, if you\u2019re looking for a solution to assist you with vulnerability management, Cisco Vulnerability Management has you covered. Cisco Vulnerability Management equips you with the contextual insight and threat intelligence needed to intercept the next exploit and respond with precision.<\/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
\nPrioritize which vulnerabilities to address
\nRemediate the vulnerabilities<\/p>\nOur approach<\/strong><\/h2>\n
Log4J: The 800-pound gorilla<\/strong><\/h2>\n
Spring4Shell: The Log4J that wasn\u2019t<\/strong><\/h2>\n
\nIt turns out that Spring4Shell was so similar to the previous vulnerability that the older Snort rules alerted on it.<\/p>\nShellShock: A classic<\/strong><\/h2>\n
A pattern emerges<\/strong><\/h2>\n
Is the long tail wagging the dog?<\/strong><\/h2>\n
It only takes one<\/strong><\/h2>\n
\nPrioritize which vulnerabilities to address
\nRemediate the vulnerabilities<\/p>\nOur approach<\/strong><\/h2>\n
Log4J: The 800-pound gorilla<\/strong><\/h2>\n
Spring4Shell: The Log4J that wasn\u2019t<\/strong><\/h2>\n
\nIt turns out that Spring4Shell was so similar to the previous vulnerability that the older Snort rules alerted on it.<\/p>\nShellShock: A classic<\/strong><\/h2>\n
A pattern emerges<\/strong><\/h2>\n
Is the long tail wagging the dog?<\/strong><\/h2>\n
It only takes one<\/strong><\/h2>\n