Despite the known risks of software vulnerabilities, most companies have unpatched security flaws in their infrastructure.
In its 2017 State of Software Security report, software testing firm Veracode found that only 14 percent of high-severity vulnerabilities are patched in the first month after discovery. More than three-quarters of all applications tested by the firm has at least one vulnerability when initially tested.
Companies need to focus on tracking the software used in their environment and keep up-to-date on the security risks found in that software, said Chris Eng, vice president of research for Veracode.
“Software is being built with whatever version is available at the time, and that is not patched until an emergency happens,” he said. “There are always going to be unknowns, but we are not even dealing well with the vulnerabilities we know.”
Failure to patch significant vulnerabilities has led to major breaches, including the mid-May breach of Equifax that led to the compromise of sensitive personal and financial information on more than 145 million Americans. The company failed to detect and patch servers vulnerable to a software flaw in Apache Struts 2 that had been disclosed two months earlier.
While there is little data on which flaws companies are having the most problems patching, there are common situations among all companies that hobble their efforts to patch.
Here are five areas to which organizations need to pay more attention.
1. Carefully Inventory Your Software
In the massive 2017 breach, Equifax knew about the vulnerability in Apache Struts 2, but did not know where the software was running in the organization and missed finding the flaw in resulting scans, the former CEO said in published remarks.
The problem is common, especially because developers often use the current version of a library in their applications and then never update the component. In the Struts 2 case, almost 50 different versions of that library — 58 percent of which were vulnerable — were being used at the time of the vulnerability’s disclosure in March 2017, according to Veracode’s SoSS report.
Until companies regularly— and thoroughly—scan for vulnerabilities to identify what they need to fix, known flaws will continue to be a problem.
“An organization may know about the Struts vulnerability, but it is not doing the proper scans to drive deployment,” said Jimmy Graham, director of vulnerability management for Qualys. “Companies likely are not scanning all their networks, and—we don’t know what we don’t know—so fixing those vulnerabilities is not possible.”
2. Track down non-traditional technology
One place where many companies fail to search for vulnerabilities is into non-traditional information technology. The great variety of internet-of-things devices—from routers used by home offices to the digital video recorders used for conference calls—are often not monitored.
Last year, for example, an internet-of-things botnet known as Satori exploited a vulnerability (CVE-2017-17215 ) in Huawei routers that allowed it to turn the devices into a massive botnet. More than half of all companies do not have a patching process for internet-of-things devices, according to a recent report conducted by Osterman Research and funded by security-services firm Trustwave.
“Because updating IoT devices by nature is more challenging, many remain vulnerable even after patches are issued, and often patches are not even developed,” Lawrence Munro, vice president of SpiderLabs at Trustwave, said in a statement. “Organizations need to properly document and test each internet-connected device on their network or face introducing potentially thousands of new attack vectors easily exploitable by cyber-criminals.”
Industrial control systems, such as supervisory control and data acquisition (SCADA) systems, are often overlooked as well. Patches are not released for 150 days on average for vulnerabilities found in such systems, according to a report from security-software firm Trend Micro. While that is slower than software makers with strong security processes—such as Microsoft and Adobe—it is faster than other large enterprise firms, Trend Micro said.
3. Find ways to mitigate vulnerabilities with consequence
Companies are also understandably slow to patch vulnerabilities that can impact their information technology. Fixes for the Spectre and Meltdown issues that affects many modern computer CPUs, for example, were delayed in January when Intel’s patch caused instability in two of its architectures. The vulnerabilities allow attackers to harvest information from systems running on the processors, according to two teams of researchers that discovered the flaws.
Even if the patches work correctly, the fix will hobble an efficiency measure known as out-of-order execution. In a recent test, the patched slowed certain tasks by up to 14 percent. Such operational impact can make companies reticent to patch.
While some mitigations for cryptographic attacks—adding more rounds—have similar performance considerations, the problem generally is exceptional, Veracode’s Eng said.
“This is a once in a decade issue,” he said. “While some companies are approaching this issue slowly, no one is really saying, ‘We won’t patch this because of the performance issues.’ By and large, this is a major deal and you don’t want to be caught exposed to this.”
4. Manage dependencies and third-party components
Developers often do not closely manage the components that are incorporated into their software. Only 11 percent of open-source maintainers audit their code for flaws on at least a quarterly basis, with the plurality—43 percent—never auditing their code, according to the State of Open-Source Security report published by application-security firm Snyk (pronounced “sneak”).
Overall, three-quarters of vulnerabilities are not found by the maintainer, so regular audits are important, the company stated.
In its analysis of 433,000 sites, Snyk found that 77 percent had at least one vulnerability in the front-end JavaScript library.
“The difference between a healthy development company and an unhealthy one is the practice of making sure that you check for known security vulnerabilities in your dependencies,” Danny Grander, CISO and co-founder, Snyk, told eWEEK. “If I pull ten libraries into my code, and those each pull ten others, it becomes very hard to know what vulnerabilities impact my software.”
5. Secure your legacy apps with known vulnerabilities
Finally, some software has a high probability of having critically severe vulnerabilities, but the software may be a business dependency for many companies. In the past decade, Internet Explorer 6 posed this problem for many companies—even though it had significant and frequent vulnerabilities, many companies relied on the browser to run essential business applications.
Known-vulnerable versions of Java are often required for applications businesses rely on. Adobe Flash, a program required to run graphics and video on many web sites and intranets, has long had significant and easily exploitable vulnerabilities.
When he worked at a bank, Qualys’s Graham often ran into this problem. The solution was to find ways to create ‘virtual patches’—ways of mitigating the problem without patching.
“We were required to run some outdated software,” he said. “So we had to spend effort on creating compensating controls, rather than patching.”
Companies need to be more proactive about identifying their business applications and monitoring the health of the software. Companies typically wait until an attack is in the wild before patching. For example, the vulnerability exploited by the WannaCry ransomware attack was initially patched in March, but remediation activity nearly doubled 45 days later when the Wannacry attack started targeting the vulnerability, Qualys’ Graham wrote in a blog post.
“We all know it’s impossible to patch every single vulnerability,” Graham stated in the blog post. “Thousands are disclosed every year, and patching systems can be complicated, time-consuming and inconvenient.”
“But InfoSec teams agree that fixing the most dangerous bugs on a timely basis is not only doable but also necessary.”
