Time is Money, Part 4: Fixing Vulnerabilities
- Feb 06, 2019
- Steve Finegan
This is part four in a six-part series. You can find the previous posts below.
Time is Money, Part 1: Vulnerability Management Maturity Levels
Every process has a ‘hump’ or mountain to overcome. A fallen tree in the road. For Vulnerability Management, it could be argued that remediation is the most difficult part of the process to overcome. Whether remediation means convincing asset owners to patch or developers to stop working on business requests to fix vulnerabilities, pushback is likely.
Why pushback? Patching and updating existing code is risky and disruptive. From the eyes of a developer or IT administrator, availability and stability are always paramount. The worst possible outcome for them isn’t a breach, it’s downtime.
Due to the potential downsides of patching, many organizations limit how many vulnerabilities they patch. This is where NopSec can help. By prioritizing the most dangerous vulnerabilities (there are less than you’d think), we can save significant amounts of time and effort by narrowing the list of issues that need to be fixed
Saving time in the remediation process is not just about vulnerability prioritization, either. The biggest time savings come from automating the remediation process. Manual tasks that typically have to be done in spreadsheets, via email or through Internet research can be automated by NopSec’s flagship product, Unified VRM. The diagram below details how, when dealing with Windows patches, an eleven-step process can be reduced to three.
It is true, we often encounter organizations that only patch the bare necessities. However, for each organization that patches the bare minimum, we encounter organizations that automatically roll out the full patch set. How is this possible? They set up a system where patches go to a smaller subset of users before they’re rolled out enterprise-wide. If no one hits the emergency stop during this ‘trial period’, patches are automatically deployed to everyone.
These same ‘fearless’ enterprises also actively work to reduce the sorts of static dependencies that patches have a tendency to break, which reduces the chances of automated patches breaking production processes. This approach isn’t possible for all organizations and requires leadership willing to take some heat when things occasionally go badly. Unfortunately, there’s no award for avoiding ransomware.
It isn’t always possible to patch immediately. However, any time removed from the remediation process makes a difference. If we look at some of the most damaging and notorious attacks of the last few years, we see the timeframes to fix are not all that unreasonable.
|Attack/Vulnerability||Fix Available||Exploitation Started||Lead time to Patch|
Furthermore, a report commissioned from Ponemon by ServiceNow claims that 57% of breached organizations were compromised via an unpatched vulnerability the organization was already aware of. In the same report, companies that avoided breaches rated themselves 19% better on their ability to detect vulnerabilities and 41% better on their ability to fix them, when compared to companies that were breached.
There are many situations where this occurs – for example, if the device lives on one company’s network, but is owned and managed by another. Or perhaps a vendor won’t allow customers to install patches until they’ve had time to test them.
Whatever the case, there’s usually an opportunity to mitigate attacks when systems can’t be immediately patched. Generally, even if patching activities are planned, it pays to put mitigations in place anyway, even if the gap being mitigated is only a few hours long. Mitigations can take the form of IPS or WAF rules if the attack vector is network-based. Some endpoint products are also capable of mitigating client-side or privilege-escalation attacks. They do this by ‘shimming’ processes on endpoints and watching for patterns that indicate specific attacks or classes of attacks. Sometimes a mitigation is as simple as disabling an unused service! It always pays to consider and implement mitigations.
Next in the series, part five, will cover methods for validating fixes and why this is necessary.