Nadradený pojem:
Podradené pojmy:
Defender Behaviour
Description
Vulnerabilities on the Decline in 2016
In the second half of 2016, vendor-disclosed vulnerabilities dropped significantly from 2015, according to our research (Figure 37). The National Vulnerability Database shows a similar decline. The reasons for the drop in disclosed vulnerability advisories are not entirely clear.
It should be noted that 2015 was an unusually active year for vulnerabilities, so the 2016 numbers may reflect a normal pace of vulnerability advisories. From January to October 2015, total alerts reached 7602. During the same time period in 2016, total alerts reached 6380; during this period in 2014, total alerts were 6272.
The high number of vulnerability reports in 2015 may indicate that vendors were looking more closely at existing products and code, more carefully implementing secure development lifecycle (SDL) practices, and identifying vulnerabilities and subsequently fixing them. The decline in reported vulnerabilities may indicate that these efforts are paying off. That is, vendors are now focusing on identifying vulnerabilities and correcting them before products reach the market.
In 2016, Apple was the vendor showing the most dramatic decline in vulnerabilities: The company reported 705 vulnerabilities in 2015, and 324 vulnerabilities in 2016 (a 54 percent decline). Similarly, Cisco reported 488 vulnerabilities in 2015, and 310 in 2016 (a 36 percent decline).
A concern among security researchers is that “vulnerability fatigue” may be setting in among security professionals. In recent months, there has not been a major vulnerability announcement that sent shock waves through the industry, as Heartbleed did in 2014. In fact, the hype around “named” vulnerabilities such as Heartbleed and the increase in 2015 likely contributed to the level of fatigue— or, at least, to less interest in reporting vulnerabilities.
In the Cisco 2017 Security Capabilities Benchmark Study (page 49), security professionals indicated a slight decrease in their agreement about security operationalization. This decrease may be connected to “fatigue” about the need to continually implement upgrades and patches. For example, in 2016, 53 percent of security professionals said they strongly agreed that they review and improve security practices regularly, formally, and strategically; in 2014 and 2015, 56 percent strongly agreed.
Of course, a decline in vulnerabilities should not lead to overconfidence about the threat landscape: No one should adopt the mindset that attention to threats can lapse, even in the absence of high-profile vulnerabilities.
As we’ve advised in past reports, security professionals should make a concerted effort to prioritize patches. If a lack of staffing and other resources prevents the timely installation of all available patches, evaluate which ones are most critical to network safety, and place those at the top of the to-do list.
Server and Client Vulnerabilities
As discussed in the Cisco 2016 Midyear Cybersecurity Report, adversaries are finding space and time to operate within server-side solutions. By launching attacks within server software, they can potentially gain control of more network resources, or move laterally among other critical solutions.
Cisco researchers have tracked client and server vulnerabilities by vendor (Figure 40).
Middleware: Adversaries See Opportunity in Unpatched Software
In the Cisco 2016 Midyear Cybersecurity Report, we shared data about attacks against server-side systems. In 2017, middleware, which connects platforms or applications, is poised to attract attackers seeking places to operate where defenders are slow to react or recognize a threat.
Cisco researchers, while looking for vulnerabilities in third-party software, discovered an average of 14 new vulnerabilities in software per month. Most of those vulnerabilities (62) were attributable to the use of middleware. Of those 62 vulnerabilities, 20 were found within code that handles PDFs; 12 were found in code that handles images; 10 were found in code for common office productivity solutions; nine were found in code for compression; and 11 were found in other libraries (Figure 41).
Vulnerabilities in middleware pose a unique security threat because their libraries are not usually updated as rapidly as software that is more client-facing—that is, software that users interact with directly on a day-to-day basis, such as productivity solutions. Middleware libraries may be left out of software audits, so vulnerabilities remain in place.
Organizations may gamble on middleware being safe and may place greater attention on updating high-profile solutions. But they can lose the bet that adversaries won’t seek entry to networks through these low-profile pathways. Middleware thus becomes a security blind spot for defenders and an opportunity for attackers.
The challenge of updating middleware libraries closely relates to the open-source software problem (discussed in the Cisco 2015 Midyear Security Report), since many middleware solutions come from open-source developers. (However, the problem at hand can affect both open-source and proprietary middleware developers.) Therefore, middleware libraries may rely on many developers to keep them updated. On the list of tasks that an overtaxed IT or security team needs to manage, middleware library updates may not be a top priority, but they should be given greater attention.
What is the potential impact of a middleware vulnerability that is exploited by adversaries? Given the connections between middleware and other crucial systems, such as email or messaging, an attacker could move laterally into these systems and send phishing messages or spam. Or attackers could masquerade as authorized users and abuse trust relationships between users to gain further access.
To avoid becoming the victim of an attack launched through a middleware vulnerability, you should:
In short: Delays in patching increase the operational space for attackers and allow them more time to gain control of critical systems. In the next section, we discuss this impact and trends in the patching of common productivity solutions such as web browsers.
Time to Patch: Closing the Recovery Time Frame
Many users do not download and install patches in a timely manner. Adversaries can use these unpatched vulnerabilities to gain entry to networks. In our latest research, we find that the key to encouraging users to download and install patches may rest in the cadence of software updates from vendors.
A security patch release is a clear indication to attackers that there is a vulnerability worth exploiting. Although sophisticated attackers have likely been exploiting the vulnerabilities for some time, the notification of a patch tells many others that it’s open season on the earlier versions.
When software vendors release new versions on a regular schedule, users become conditioned to downloading and installing updates. Conversely, when vendor upgrade releases are erratic, users are less likely to install them. They will continue to operate outdated solutions that may contain exploitable vulnerabilities.
Other behaviors that affect the upgrade cycle include:
There are varying windows of time in which users are likely to install an upgrade when it is released by the vendor. Our researchers looked at the installations of software on the endpoints used by our customers. Their software fell into three categories:
As an example, if a software vendor released version 28 on January 1, 2017, version 28 would be new; version 26 would be recent; and version 23 would be old. (The figures on the next page contain callouts of the weekly time periods where one or more versions of the software were released.)
In examining users of Adobe Flash (Figure 42), we found that, within the first week of an update release, nearly 80 percent of users install the software’s latest version. In other words, it takes only about one week for the user population to get up to speed with the latest version. This one-week “recovery” period represents hackers’ window of opportunity.
In looking at late Q4 2015 in the Adobe Flash graphic, we see a sharp drop in the number of users on the newest version of the solution. In the time period we examined, Adobe released five versions of Flash in quick succession, representing a mix of functionality additions, bug fixes, and security updates. Such a flurry of updates may confuse users. They may question whether they need to download so many updates; they can become fatigued by the number of upgrade notifications; and they may think they’ve already downloaded a crucial update and can ignore new notifications. No matter what drives their lack of interest in installing an update, it’s bad news for defenders.
In examining upgrades for the Google Chrome web browser, we see a different pattern. It reflects a regular cadence of upgrades, as well as a strong opt-out policy that makes it difficult for users to ignore update notifications. As seen in Figure 42, endpoints running the newest version stay relatively steady over the course of many weeks.
The Chrome data shows that users recover relatively quickly. In the case of regular updates, one week is roughly the recovery timeline. In one span of 9 weeks running through Q2 and Q3 of 2016, however, there were seven updates. During this time the population recovered, but upgrade fatigue began to set in. The percentage of users staying with an older version steadily climbs despite the majority of the population recovering.
Mozilla’s Firefox browser also offers updates on a regular schedule, but the recovery period after an update is released appears to take as long as a month. That is, users do not download and install updates as frequently as Chrome users do. One reason may be that some users might not use the browser regularly and therefore aren’t seeing and downloading updates. (See Figure 43 on next page.)
We found that Firefox updated its versions about every other week, with the frequency of updates increasing over the course of the observation period. This increase in frequency is reflected in the growth of old Firefox versions within the population. The recovery time is roughly 1.5 weeks, but the times overlap. The population that tries to stay current drops to as little as 30 percent of the user base. At some point, two-thirds of the users have resorted to simply running the browser more than four versions behind the most current one. So, although Firefox is rapidly addressing issues and fixing bugs, the user base is not updating and restarting on the same frequency.
For software, the level of use seems to also be an indicator of its vulnerability. When users do not access software often and therefore aren’t aware of the need to patch and upgrade it, the ignored software provides space and time for attackers to operate.
We can see this in the research on Microsoft Silverlight, which shows a recovery period of as long as 2 months for users to install upgrades after a release. At one point, there were two releases within 5 weeks, which affected the user population for more than 3 months, as can be seen between Q4 of 2015 and Q1 of 2016.
Microsoft announced the end of life of Silverlight in 2012, although patches and bug fixes are still being released. However, it poses the same problem that Internet Explorer does: Outdated and unpatched software invites attackers to easily exploit it.
The recovery period for Java users shows that most are running versions of the software that are one to three versions behind the most recent release. The time to recovery is about 3 weeks. An unusual pattern with Java is that the dominant populations are those that use recent versions. The Java update cycle is from 1 to 2 months. The overall lesson from time-to-patch cycles is that upgrade release patterns are a contributing factor in user security posture, which can place networks at risk.
In the second half of 2016, vendor-disclosed vulnerabilities dropped significantly from 2015, according to our research (Figure 37). The National Vulnerability Database shows a similar decline. The reasons for the drop in disclosed vulnerability advisories are not entirely clear.
It should be noted that 2015 was an unusually active year for vulnerabilities, so the 2016 numbers may reflect a normal pace of vulnerability advisories. From January to October 2015, total alerts reached 7602. During the same time period in 2016, total alerts reached 6380; during this period in 2014, total alerts were 6272.
The high number of vulnerability reports in 2015 may indicate that vendors were looking more closely at existing products and code, more carefully implementing secure development lifecycle (SDL) practices, and identifying vulnerabilities and subsequently fixing them. The decline in reported vulnerabilities may indicate that these efforts are paying off. That is, vendors are now focusing on identifying vulnerabilities and correcting them before products reach the market.
In 2016, Apple was the vendor showing the most dramatic decline in vulnerabilities: The company reported 705 vulnerabilities in 2015, and 324 vulnerabilities in 2016 (a 54 percent decline). Similarly, Cisco reported 488 vulnerabilities in 2015, and 310 in 2016 (a 36 percent decline).
A concern among security researchers is that “vulnerability fatigue” may be setting in among security professionals. In recent months, there has not been a major vulnerability announcement that sent shock waves through the industry, as Heartbleed did in 2014. In fact, the hype around “named” vulnerabilities such as Heartbleed and the increase in 2015 likely contributed to the level of fatigue— or, at least, to less interest in reporting vulnerabilities.
In the Cisco 2017 Security Capabilities Benchmark Study (page 49), security professionals indicated a slight decrease in their agreement about security operationalization. This decrease may be connected to “fatigue” about the need to continually implement upgrades and patches. For example, in 2016, 53 percent of security professionals said they strongly agreed that they review and improve security practices regularly, formally, and strategically; in 2014 and 2015, 56 percent strongly agreed.
Of course, a decline in vulnerabilities should not lead to overconfidence about the threat landscape: No one should adopt the mindset that attention to threats can lapse, even in the absence of high-profile vulnerabilities.
As we’ve advised in past reports, security professionals should make a concerted effort to prioritize patches. If a lack of staffing and other resources prevents the timely installation of all available patches, evaluate which ones are most critical to network safety, and place those at the top of the to-do list.
Server and Client Vulnerabilities
As discussed in the Cisco 2016 Midyear Cybersecurity Report, adversaries are finding space and time to operate within server-side solutions. By launching attacks within server software, they can potentially gain control of more network resources, or move laterally among other critical solutions.
Cisco researchers have tracked client and server vulnerabilities by vendor (Figure 40).
Middleware: Adversaries See Opportunity in Unpatched Software
In the Cisco 2016 Midyear Cybersecurity Report, we shared data about attacks against server-side systems. In 2017, middleware, which connects platforms or applications, is poised to attract attackers seeking places to operate where defenders are slow to react or recognize a threat.
Cisco researchers, while looking for vulnerabilities in third-party software, discovered an average of 14 new vulnerabilities in software per month. Most of those vulnerabilities (62) were attributable to the use of middleware. Of those 62 vulnerabilities, 20 were found within code that handles PDFs; 12 were found in code that handles images; 10 were found in code for common office productivity solutions; nine were found in code for compression; and 11 were found in other libraries (Figure 41).
Vulnerabilities in middleware pose a unique security threat because their libraries are not usually updated as rapidly as software that is more client-facing—that is, software that users interact with directly on a day-to-day basis, such as productivity solutions. Middleware libraries may be left out of software audits, so vulnerabilities remain in place.
Organizations may gamble on middleware being safe and may place greater attention on updating high-profile solutions. But they can lose the bet that adversaries won’t seek entry to networks through these low-profile pathways. Middleware thus becomes a security blind spot for defenders and an opportunity for attackers.
The challenge of updating middleware libraries closely relates to the open-source software problem (discussed in the Cisco 2015 Midyear Security Report), since many middleware solutions come from open-source developers. (However, the problem at hand can affect both open-source and proprietary middleware developers.) Therefore, middleware libraries may rely on many developers to keep them updated. On the list of tasks that an overtaxed IT or security team needs to manage, middleware library updates may not be a top priority, but they should be given greater attention.
What is the potential impact of a middleware vulnerability that is exploited by adversaries? Given the connections between middleware and other crucial systems, such as email or messaging, an attacker could move laterally into these systems and send phishing messages or spam. Or attackers could masquerade as authorized users and abuse trust relationships between users to gain further access.
To avoid becoming the victim of an attack launched through a middleware vulnerability, you should:
- Actively maintain a list of known dependencies and libraries in the applications you use
- Actively monitor the security of these applications, and mitigate risks as much as possible
- Insert a service-level agreement in contracts with software vendors for providing patches in a timely manner
- Routinely audit and review software dependencies and library use
- Ask software vendors for details on how they maintain and test their products
In short: Delays in patching increase the operational space for attackers and allow them more time to gain control of critical systems. In the next section, we discuss this impact and trends in the patching of common productivity solutions such as web browsers.
Time to Patch: Closing the Recovery Time Frame
Many users do not download and install patches in a timely manner. Adversaries can use these unpatched vulnerabilities to gain entry to networks. In our latest research, we find that the key to encouraging users to download and install patches may rest in the cadence of software updates from vendors.
A security patch release is a clear indication to attackers that there is a vulnerability worth exploiting. Although sophisticated attackers have likely been exploiting the vulnerabilities for some time, the notification of a patch tells many others that it’s open season on the earlier versions.
When software vendors release new versions on a regular schedule, users become conditioned to downloading and installing updates. Conversely, when vendor upgrade releases are erratic, users are less likely to install them. They will continue to operate outdated solutions that may contain exploitable vulnerabilities.
Other behaviors that affect the upgrade cycle include:
- How disruptive the reminder experience is
- How easy it is to opt out
- How often the software is used
There are varying windows of time in which users are likely to install an upgrade when it is released by the vendor. Our researchers looked at the installations of software on the endpoints used by our customers. Their software fell into three categories:
- New versions: The endpoint ran the newest available version of the software
- Recent versions: The endpoint ran one of the previous three versions of the software, but not the newest
- Old versions: The endpoint ran software that was more than three versions behind the current release
As an example, if a software vendor released version 28 on January 1, 2017, version 28 would be new; version 26 would be recent; and version 23 would be old. (The figures on the next page contain callouts of the weekly time periods where one or more versions of the software were released.)
In examining users of Adobe Flash (Figure 42), we found that, within the first week of an update release, nearly 80 percent of users install the software’s latest version. In other words, it takes only about one week for the user population to get up to speed with the latest version. This one-week “recovery” period represents hackers’ window of opportunity.
In looking at late Q4 2015 in the Adobe Flash graphic, we see a sharp drop in the number of users on the newest version of the solution. In the time period we examined, Adobe released five versions of Flash in quick succession, representing a mix of functionality additions, bug fixes, and security updates. Such a flurry of updates may confuse users. They may question whether they need to download so many updates; they can become fatigued by the number of upgrade notifications; and they may think they’ve already downloaded a crucial update and can ignore new notifications. No matter what drives their lack of interest in installing an update, it’s bad news for defenders.
In examining upgrades for the Google Chrome web browser, we see a different pattern. It reflects a regular cadence of upgrades, as well as a strong opt-out policy that makes it difficult for users to ignore update notifications. As seen in Figure 42, endpoints running the newest version stay relatively steady over the course of many weeks.
The Chrome data shows that users recover relatively quickly. In the case of regular updates, one week is roughly the recovery timeline. In one span of 9 weeks running through Q2 and Q3 of 2016, however, there were seven updates. During this time the population recovered, but upgrade fatigue began to set in. The percentage of users staying with an older version steadily climbs despite the majority of the population recovering.
Mozilla’s Firefox browser also offers updates on a regular schedule, but the recovery period after an update is released appears to take as long as a month. That is, users do not download and install updates as frequently as Chrome users do. One reason may be that some users might not use the browser regularly and therefore aren’t seeing and downloading updates. (See Figure 43 on next page.)
We found that Firefox updated its versions about every other week, with the frequency of updates increasing over the course of the observation period. This increase in frequency is reflected in the growth of old Firefox versions within the population. The recovery time is roughly 1.5 weeks, but the times overlap. The population that tries to stay current drops to as little as 30 percent of the user base. At some point, two-thirds of the users have resorted to simply running the browser more than four versions behind the most current one. So, although Firefox is rapidly addressing issues and fixing bugs, the user base is not updating and restarting on the same frequency.
For software, the level of use seems to also be an indicator of its vulnerability. When users do not access software often and therefore aren’t aware of the need to patch and upgrade it, the ignored software provides space and time for attackers to operate.
We can see this in the research on Microsoft Silverlight, which shows a recovery period of as long as 2 months for users to install upgrades after a release. At one point, there were two releases within 5 weeks, which affected the user population for more than 3 months, as can be seen between Q4 of 2015 and Q1 of 2016.
Microsoft announced the end of life of Silverlight in 2012, although patches and bug fixes are still being released. However, it poses the same problem that Internet Explorer does: Outdated and unpatched software invites attackers to easily exploit it.
The recovery period for Java users shows that most are running versions of the software that are one to three versions behind the most recent release. The time to recovery is about 3 weeks. An unusual pattern with Java is that the dominant populations are those that use recent versions. The Java update cycle is from 1 to 2 months. The overall lesson from time-to-patch cycles is that upgrade release patterns are a contributing factor in user security posture, which can place networks at risk.
Importance
High