How to patch your open source software vulnerabilities
No matter how big your software vulnerabilities backlog has grown, here's how you can tackle it, and get on the path to continuous security monitoring.
Software vulnerabilities are a fact of life. Researchers -- if not hackers -- constantly discover new ways to compromise popular software libraries. It's up to enterprises to quickly deploy patches to secure software before hackers get in.
Consider the Equifax breach, in which a hacker exposed the data of more than 145 million users, resulting in $575 million in fines for the credit rating agency. A U.S. Senate investigation identified a backlog of over 8,500 unpatched vulnerabilities at Equifax -- the hacker gained access through just one of those unpatched systems.
Vulnerability backlogs are especially prevalent within enterprises that rely on open source components. Nearly all applications make use of some open source components that take the place of either mundane or arcane coding tasks. An open source project often has an active community to maintain and augment it, but that's not always the case. Ultimately, open source software requires a leap of faith from the user that what they're adopting is secure and effective.
Organizations must take a systemic approach to understand their open source software vulnerabilities, including the patching process and the gaps within it. Then, they should develop a strategy to address such weaknesses, such as continuous security monitoring.
Identify vulnerability backlog causes
Every organization has bottlenecks particular to its people and processes, and their causes vary. However, there are some common factors to watch out for, said Matt Wilgus, a principal who leads the threat and vulnerability assessment offerings at Schellman & Company, an IT audit and certification firm. Wilgus pointed to unpatchable systems, personnel changes and lackadaisical culture as three common root causes of unaddressed open source software vulnerabilities.
"Getting through a mountain of vulnerabilities starts with understanding the core issues at hand causing the backlog," Wilgus said.
A single unauthenticated remote code execution vulnerability can pose more risk to an IT environment than hundreds of privilege escalations or denial of service vulnerabilities.
In many cases, organizations cannot patch a given device, which in turn can register hundreds of unique cybersecurity vulnerabilities. Investigate what controls can help mitigate the scope of the vulnerability -- and its impact. Look into secure alternatives to unpatchable systems, even if it means the arduous task of migrating to a different technology. If that's not an option, find a way to shield a host system from the most critical vulnerabilities. For example, a single unauthenticated remote code execution vulnerability can pose more risk to an IT environment than hundreds of privilege escalations or denial of service vulnerabilities, Wilgus said.
When all the open source software vulnerabilities in your organization are relatively recent -- roughly less than 90 days old -- the problem might stem from a personnel change. If the person responsible for patches departs, someone else must fill the role, or the organization can contract with a third party.
The third danger is denial. When the team thinks, "It won't happen here," that attitude can cause vulnerabilities to pile up. Some workers think hackers won't exploit cybersecurity vulnerabilities and, thus, do not pose a real risk. Senior leadership must address this fundamental problem. Have the CIO, CTO or even the CEO mandate patching, Wilgus said, especially when security flaws inhibit a new initiative or onboarding a customer.
Audit the patch management program
Patch management programs help organizations establish procedures and standards that often prioritize the most critical issues and assets.
Organizations should follow an established set of processes as part of a patch management program to address open source software vulnerabilities efficiently and safely, said Mieng Lim, senior director of product management at Digital Defense, a vulnerability management and threat detection platform provider.
Within legacy systems and applications, not all vulnerabilities can be remediated. In these instances, organizations should mitigate the risk by isolating the vulnerability or putting in access controls to protect the asset.
Buy time for patches
Set up a strategy to minimize the effects of open source software vulnerabilities between discovery and fix. Organizations should ask a variety of questions as part of their patch management process, Lim said, to triage remediation efforts and limit the potential damage.
Can we easily limit access or exposure to create time to remediate?
Are there any dependencies on the asset that a patch would negatively affect?
How easy is it to fix the vulnerability on the asset?
Does a vendor or third-party resource need to provide assistance?
How many instances of the vulnerability exist?
How important is the vulnerable asset?
Factors like resource availability, testing and patch management procedures will help teams prioritize cybersecurity vulnerabilities, as well as whether team members should remediate them manually or via automation.
Effective patch and vulnerability management programs often take advantage of additional protection technologies or modifications to the network architecture to limit asset access -- even though these efforts might require additional time. Organizations that have too many vulnerabilities to patch with in-house staff can supplement their remediation efforts via outsourcing.
Apply continuous security monitoring
Continuous security monitoring helps teams both spot changes to vulnerable software assets and streamline the patch management process. With continuous security monitoring, security teams deploy vulnerability scanners and other tools in concert with manual techniques to regularly evaluate weaknesses.
"The organizations that typically have the least headaches with patch management are often the ones that assess their environment the most," Wilgus said.
Not every organization can go continuous. In that case, monthly scanning is better than quarterly. However, if possible, run daily scans, which IT professionals can often conduct using agents. More frequent scans provide more time for support teams to test and deploy fixes.
A continuous security monitoring program also provides visibility into whether a remediation effort was effective. Most mature organizations require that security teams remediate high-severity issues within seven days, and moderate issues within 21 days, Wilgus said. The monitoring program helps organizations track and align that work with their goals.
