Many people are familiar with 0-day (Zero-Day) vulnerabilities. It’s one of my favorite interview questions. However, what if the vendor is working on a patch but hasn’t released it yet? What’s that period of limbo called? That’s called a 1-day, and for products that use open-source components, it can be a big problem.
Overview
However, it’s a manageable problem. Managing it depends on understanding the development cycle and balancing it with IT maintenance cycles and the way attackers prefer to work.
The Open Source Approach
To a developer, a vulnerability is just a bug. It may be a bug with some urgency attached to it, but it’s a bug. The developer fixes the bug, submits the change, and in an open source project, it’s there for all to see. Bad actors can look through these proposed changes to find vulnerabilities, and then write exploits that use them. These vulnerabilities give attackers two windows of vulnerability: that gap between the time of discovery and the time the patch drops, and the time between release and the target organization deploying the update.
Some people argue this makes open source software less secure than closed source proprietary software. However, in some product categories, there is no closed source software anymore. After Microsoft finishes moving its Edge browser to the Chromium engine, the only truly closed source web browser left in the world is Internet Explorer.
Your smartphone is another example. Apple iOS isn’t fully open source, but it contains large amounts of open source components. Android contains even more.
Avoiding open source software isn’t a sustainable approach. We have to learn how to manage it.
Patch Tuesday, and What It Has to do with Open Source
I’m old enough to remember Microsoft releasing updates whenever it deemed them ready. Moreover, as the least-senior guy on my team at the time, I was the one who had to deal with deploying them. It was chaos. That was one reason Microsoft decided to release its updates on the second Tuesday of every month. The predictable schedule meant that infrastructure teams could plan deployments. Adobe wisely chose Microsoft’s schedule with its updates.
Sometimes Chrome and Firefox updates fall near Microsoft’s schedule, but frequently they do not. Their regular update cycle doesn’t follow Microsoft’s schedule, and they tend to release out-of-band updates more frequently to deal with emergencies. Security professionals like the rapid release cycle, but infrastructure teams don’t.
Dealing with 1-day Vulnerabilities
By definition, there’s not a lot you can do while you wait for a vendor to release a patch. The best you can do is use an anti-exploit mitigation product, whether it’s one built into newer operating systems, part of a next-generation endpoint protection product, or a dedicated anti-exploit product. When an attacker attempts to exploit a vulnerability protected in this way, the application still crashes, but at least the attacker doesn’t gain access to the machine.
However, the application crash window provides the user with a warning. If you see attackers attempting to exploit your devices, that can be a signal to you that you need to get the patch down as quickly as you can. However, at least you’re dealing with a denial of service at that point, and not an incident.
In my experience, most companies shoehorn open source updates into the Microsoft cycle. If a Chrome or Firefox update drops the same week as Microsoft’s updates, they go out that week. If it drops after, they go out with the next round of Microsoft updates. It’s not ideal, but it’s a way for overburdened infrastructure teams to deal with the workload.
Also, let’s be honest with ourselves. Attackers aren’t going to burn 0-days if they find a network that still has old unpatched vulnerabilities in it. Moreover, they aren’t going to favor 1-days in that situation either. There’s no reason to use unproven exploits for 1-day vulnerabilities if they find lots of unpatched older vulnerabilities with time-tested, reliable exploits available.
Managing Risk
If an update drops for something nasty, use the same procedure you’d use for an out-of-band update from Microsoft or Adobe. A risk-based approach to vulnerability management pays off here. If active exploitation of the vulnerability exists in the wild, deploy the update. If it isn’t, it can wait until next month’s maintenance window. That allows security professionals to avoid comparisons to “The Boy Who Cried Wolf.”
The key is remembering that the goal is an acceptable risk level, not invincibility. Invincibility isn’t sustainable, but keeping risk at an acceptable level is.
At Deepwatch, we’ve found that a risk-based approach, combined with other mitigations integrated into our Analytics solutions, makes the burden of creating an effective security program much more manageable. That doesn’t mean it’s easy.
If you fix some manageable quantity of vulnerabilities every month and do that every month for a year or two, the result is a highly-functional program. It won’t be perfect, but no one transforms a vulnerability management program from nonfunctional to perfection in a month. Vulnerability management has dozens of moving parts that take years to master.
Typically a good security analyst can find the biggest problem in a vulnerability scan in a few minutes. Unless all the findings in a scan are minor and debatable, the biggest problem in any given network probably isn’t a 0-day or 1-day.
Supporting Information
- https://www.chromium.org/developers/calendar
- https://wiki.mozilla.org/Release_Management/Calendar
- https://opensource.com/business/13/12/using-open-source-software
- https://www.rand.org/content/dam/rand/pubs/research_reports/RR1700/RR1751/RAND_RR1751.pdf
Share