Most organizations I work with today are still having a very hard time getting their patching programs to evolve. Sure, everyone has a patching schedule of some sort. However, many teams patch the most exposed and critical flaws in the DMZ, and leave a lot of assets unpatched or under-patched within the rest of the environment. What’s more, we tend to really patch things up for audits and assessments, but many programs don’t continue to be patched after the audit is finished.
Recently, Verizon released their 2015 PCI Compliance Report (information required to view), and it includes some astonishing statistics. 80% of companies fail interim assessments during their compliance cycle. Less than a third (28.6%) of companies were found to be still fully compliant less than a year after successful validation. What’s even more horrifying are the numbers for breached organizations, especially the specific numbers per section of the PCI DSS. Section 6, which includes vulnerability management and patching, drops from 64% of companies compliant at the interim assessment to ZERO percent after a breach (when the follow-up investigation is done).
This means that every single breach Verizon investigated in companies taking payment cards had a failure of patching or vulnerability management programs overall. That is just insane - we can patch when it’s audit time, but aren’t able to maintain a control that is fundamental.
This surprises me, but only due to the overwhelming numbers. Most of the assessments and pen tests I do uncover a vast wealth of missing patches, and the crazy part is that everyone seems to know this already. Very few security and operations teams are actively working to reduce the organization’s number of unpatched vulnerabilities unless they’re high profile and deemed an immediate risk. This doesn't mean security teams don’t report on missing patches - far from it. Most groups running vulnerability scans get back a long list of systems missing patches from an average scan internally, and the same may be true for low impact or less critical flaws externally, too.
These assessments are usually shared with operations teams or reported in some other way, but they’re not getting remediated. The reasons for not patching are usually the same - too little time, too much hassle, things could break, not enough people to do the work… you get the idea.
Sometimes patching can
be tough, especially with legacy systems and applications. But we’re struggling with far more basic problems. First, there’s apathy around patching. Most in IT know it’s important, but we’re usually only given the resources to do the bare minimum. Second, we’re not doing a great job at inventory management for systems and applications throughout the environment. We can’t very well patch what we don’t know about. Third, we have SO many different things to patch that no one is really in charge of the specifics of vulnerability notification and patch release for all but the major vendors (Adobe, Microsoft, Red Hat, Apple, etc.).
In my upcoming webinar, Why You Still Suck at Patching...and How to Turn Your Life Around,
I’ll share some horror stories and “tales from trenches” about patching and patch management failures I’ve seen. I’ll also share some of the lessons learned by organizations that are working to improve patch management and vulnerability management remediation cycles today.
Live Webinar, Thursday, March 26, 2015 | 10am PT/1pm ET | Watch On-Demand