The digital world is a blink-and-you’ll-miss-it environment, and organizations need to move aggressively to shrink the exploitable vulnerability window. Adversaries are breaching the security periphery through 0day exploits, social engineering, and phishing attacks, among other tactics. Based on current priorities, security teams tend to focus on known vulnerabilities that can be identified with established assessment practices and have prescribed remediation solutions.
However, for long-term risk reduction, simply relying on patch management isn’t enough. More important is finding the biggest areas of exposure and having the foresight to understand how critically they can affect operations in case of a compromise. For this, reliance on legacy manual approaches is inadequate – we need to move toward automation and leverage all of the available technologies to tackle the problem at hand.
By John Bock – Sr. Research Scientist, Research & Development, Optiv
SPONSORED CONTENT
Introduction
Automation itself is a deep discussion, but for the C-Suite it needs to be articulated in terms of strategy vs implementation. While organizations are well aware of the workload associated with patching vulnerabilities, the workload growth curve is usually expressed in trajectory graphs, not real numbers. The numbers are illuminating, though. Just looking at Microsoft patch volume since 2016, we have had some pretty dramatic growth in recent years:
|
Year |
Microsoft Patches* |
|
2016 |
5,528 |
|
2017 |
10,502 |
|
2018 |
11,314 |
|
2019 |
20,443 |
| 2020 |
30,480 |
In other words, if you’re struggling to keep pace with the patch volume now, the future is only going to be more difficult.
Looking at the future, you will have an increasing number of vulnerabilities to track, which also means you have predictable workload growth. If this isn’t a headache for your security team already, it will be soon. Automation combined with new remediation strategies, then, is your best way forward.
Understanding Your Remediation Pipeline
If you track the lifecycle of an individual vulnerability from its identification to its final fix, it generally traverses multiple systems with multiple stakeholders. Each step along the way can (and probably will) introduce delay deriving from both mechanical and policy concerns. Additionally, many organizations don’t have an integrated, comprehensive view of all the operations involved or the stakeholders and their respective responsibilities within the workflow. Security and IT teams, for example, work in silos when it comes to getting a vulnerability remediated.
Security teams can often feel they’re only responsible for notifying IT about a vulnerability; it’s then IT’s job to fix it. IT, on the other hand, may feel little urgency to act unless they’re prodded by Security. What’s needed to bring a shared vision between both teams is a comprehensive, complete and accurate workflow model that tracks each vulnerability management step as it weaves through the organization. This becomes the foundation for an automation roadmap that drives modernized change management policies.
Linking Vulnerability and Patch Management
How much integration can you foster between the platform that identified the vulnerability (e.g., Tenable, Rapid7, Qualys) and the solution that will deploy the remediation action (e.g., Microsoft SCCM, HCL BigFix)?
Recently, Tenable announced support for direct integration with BigFix, and there are other products on the market, like Vulcan.io, which translate between a CVE and an applicable patch. Without this link, you’ll have to run this function through an ITSM and rely on an analyst to manually review the vulnerabilities involved. Once that’s done, you need to find an appropriate patch for the target asset and then coordinate its deployment. These time-consuming manual tasks delay remediation, and the longer the delay the more opportunity an attacker has to exploit your network and compromise your systems.
Also read: Risk-based Vulnerability Management – Time to Move Away From the Whack-a-Mole Model
Managing Reliability Risk at Speed
One of the most common reasons organizations don’t deploy every patch shipped to them is that rarely do these patches cause stability problems and downtime. To mitigate that risk, a patch deployment cycle may be distributed to small groups at first, and absent complaints sent out to the wider population. While this can help lessen the risk of a bad patch causing major damage, it’s also not very scientific in terms of testing the patch compatibility, and it relies on time to obtain a result. The time that other systems will remain vulnerable wait to see how if the canary in the proverbial coal mine survives.
One of our alternatives is to leverage robotic process automation to build a set of automated test cases akin to what you would see in unit testing for application development. With RPA, you can build a target virtual machine image that is configured as a user workstation, with the appropriate set of applications installed. Then the RPA can be trained to perform user activities sufficient enough to validate that the patch in question wouldn’t disrupt normal operations. With this method, the patch rollout cycle becomes a testing loop with each update being pushed to the target images and after a successful RPA run the update can be cleared for wider distribution.
The big advantages here are that the entire process itself can be initiated as soon as a patch is received from a vendor, that a more intensive and auditable testing process will occur, and that specific issues related to the patch can be spotted without relying on the user’s noticing the behavior in the wild. With RPA being leveraged as the patch vetting mechanism, it enables the IT and Security team to spot issues such as a specific application not being able to perform a function with the patch in place, but now with the foreknowledge that allows IT to build a workaround or the CISO and CIO to have all the options when balancing the security risk vs. operational stability.
Alternative Remediation Strategies
The automation discussion presents the opportunity to ask another question: “Should we try to patch this, or just take down the asset?” Unmanaged or undermanaged hosts are a frequent entry point for breaches. Even when they’re discovered, getting a system updated that hasn’t been patched for say, five years, will take considerable effort. Ideally, Security and IT should collaborate on a process to continually assess whether a service or system needs to be on the network. Instead of keeping it as part of the patching workload, it should be disabled if not in use.
Continual attack surface pruning can be based on login events, user activity, network traffic, or any other available data indicating whether it’s being used. There are various mechanisms that can be used for “Weeding” network assets, the basic set being authentication and traffic logs, along with regular validation from the listed owners that it is still needed. When it comes to cloud environments like AWS or Azure this becomes easier since the resource can be tied to a dollar value, and statements along the lines of “This is costing us 10k a month and no one has used it in a year” tend to hasten the debate.
Conclusion
Even in a current context where more and more functions are being automated, vulnerability remediation holds onto manual processes in too many cases. Staying ahead of the curve requires the implementation and execution of an automation-first remediation lifecycle. Additionally, a review of change management policies and procedures that create remediation delays is overdue for modernization. Policy models that can trace their origin to an era of low attacker and vulnerability volume alongside monolithic computing don’t work in today’s landscape with a massive increase in the number of hostile actors and vulnerabilities, while at the same time computing has become more resilient than ever.
To learn more about vulnerability management and automation Download our free field guide or drop us a line if you have questions.
