Network Security
Vulnerability Management
Privileged Access Management
Endpoint Security
Threat Hunting
Unified Endpoint Management
Email & Collaboration Security
Contents:
Whilst the need for patching is irrefutable, more than often sysadmins are being confronted with the notion of ‘compliance’ and the chicken-or-the-egg dilemma that goes along with it – what comes first? Patching or compliance? Since patch compliance is a hot topic these days, in this article we’re going to go over the topic and discuss things like milestones, metrics, and how patching requirements can change depending on the level of compliance your organization wants to achieve. Enjoy, subscribe, and share!
Defining and Measuring Patch Compliance
Figuring out what patch compliance is – and what it’s not – may be a bit challenging. For instance, if we were to imagine a digital company environment running its own rules, regulations, protocols, and security baselines, we may be tempted into thinking that the term “patch compliance” refers to the fact that every improvement-carrying package developed, tested, and deployed within this environment must abide by the rules, the standards set by the organization.
Fair enough – but what about other compliance standards such as PCI-DSS, HIPAA, NIST, GDPR, etc.? Are they really that important or are more boxes that the company NEEDS to tick? Let’s get a better angle on this. Suppose that you define the concept of “patch compliance” as being some sort of middle ground between company-agreed praxis and existing formats. In this particular what-if scenario, how would we proceed – as sysadmins – if we were to discover that there’s an (unsolvable) discrepancy between the company’s (patch) security baselines and the compliance standards the company must obtain in order to (be allowed) operate on the market and serve its customers?
An interesting dilemma and one that is more common than one would think – for instance, the number one reason for delaying patches or systems upgrades is legacy. Some of the apps the company uses are, let’s say old, and, therefore, not entitled to any types of improvement-carrying packages, be they optional, security, or otherwise. And because every type of compliance standard out lists patching as a sine qua non requirement, most organizations would rather delay the patches than upset “the natural order of things” (i.e., workflows).
Anyway, patch compliance has many facets, but it all boils down to one thing: vulnerability and the management thereof. Compliance standards out there such as FFIEC, SOX, GLBA, and FERPA aren’t just there for display purposes only; by proving compliance with one, two, or all of them you, as an organization, would have proved to your customer that security, regardless of what form it may assume, is no laughing matter.
Metrics and KPIs
With the basics out of the way, we’re now free to talk about how we measure patch compliance within an organization. To understand these key metrics, we need to pay a visit to a very old friend – CVE. The system has been around for about two decades during which time it has shown us how the threat landscape has modified. Although it would be insane to go through 20 years worth of vulnerability data, if we were to analyze the YoY (year-over-year) trends, we would identify an emerging and worrisome trend called patching fatigue. In other words, after 20 decades of head-butting, patch management has gotten to a point where it can’t face the deluge.
In the last couple of years, the shift has focused from app vulnerability (management) to OS vulnerability management; basically, a ‘modern-day’ defender has to take into consideration that a threat actor will be more likely to exploit an OS-specific vulnerability than a software bug. And, on top of that, we also have the so-called patching gap – how long does it take an organization to address a discovered vulnerability? Well, according to the paper “An Empirical Analysis of Software Vendors’ Patching Behavior: Impact of Vulnerability Disclosure”, security patching can take anywhere from 55 to 75 days depending on factors such as the severity level of vulnerability, effects, vendor-side patching decision, source of disclosure, and more.
One final aspect to be considered is reporting. How does your company handle this aspect of vulnerability management? Do you use a special, 3rd party reporting tool or simply draft up an Excel on a yearly, quarterly, or monthly base? And, the most important question at hand – why should you care about any of these things? Vulnerability management is crucial because it shows how strong and resilient your organization is when confronted with cyber threats. A strong reporting tool (and hygiene) can aid in better understanding those proverbial chinks in the armor and how to address them.
So, if we are to consider A and B, and C, how would we go about measuring performance in vulnerability management? By taking a look at the data, of course – your KPIs (from now on) must be the average patching time (i.e., don’t forget to include historical data as well) and the number of unpatched vulnerabilities plus historical data. Don’t forget to include in your report the method or methods you’re using to monitor the unpatched/unpatchable vulnerabilities. And this, dear reader, is how any sysadmin department should work.
Up next, we’re going to do a little digging around to see how the definition of patch compliance changes depending on industry standards.
Patch compliance. Industry Standards
1. Payment Card Industry Data Security Standard (PCI-DSS)
PCI-DSS has 12 requirements. However, for the purpose of brevity, we will only focus on PCI-DSS Requirements 6.2 and 11.2. The two sub-sections outline the rules that govern patching and vulnerability management. So, according to Requirement 6.2:
(…) all system components and software are protected from known vulnerabilities by installing valid vendor-supplied security patches. You must also install critical security patches within one month of their release.
On vulnerability management, Requirement 11.2 dictates that the organization must perform external and internal network vulnerability assessments at least once per quart or if the infrastructure suffered any major modifications from the last assessment.
2. Health Insurance Portability and Accountability Act (HIPAA)
HIPPA proposes a patch management flow that includes patch evaluation, patch testing, approval or denial, deployment, and post-deployment verification and testing.
3. National Institute of Standards and Technology (NIST)
NIST’s SP 800-40r4 Guide to Enterprise Patch Management Planning showcases a lifecycle that covers everything from digital asset management to risk response. The lifecycle’s steps are:
Know when new software vulnerabilities affect your organization’s assets, including applications, operating systems, and firmware. Plan the risk response. Execute the risk response. This includes risk response preparation, risk response implementation, risk response verification, and monitoring.
4. Federal Financial Institutions Examination Council (FFIEC)
FFIEC’s patching lifecycle includes automatic communication with vendors (i.e., to inform them about new patches, software versions, etc.), documentation, patch impact assessment, prioritization, and setting up a rollback plan in case things take a turn for the worse.
Heimdal® Patch & Asset Management Software
- Schedule updates at your convenience;
- See any software assets in inventory;
- Global deployment and LAN P2P;
- And much more than we can fit in here...
Conclusion
Patch compliance can come in different sizes and shapes. Although the line may seem blurry at times, keeping in mind the requirements of the standard your company wishes to apply for will make things easier for you. Don’t forget that the centerpiece of patch compliance is vulnerability management – it makes no difference if you’re aiming for FFIEC, GDRP, SOX, PCI-DSS, or HIPAA; having a strong vulnerability management program in place will enable you to secure your company, your assets while providing the auditors with what their need.
Now, the easiest way to achieve patch compliance is to employ an automatic patch management solution with powerful asset and vulnerability management features. Heimdal™’s Patch & Asset Management is your go-to solution when it comes to automatic patch deployment, vulnerability assessment, software asset management, and more.
If you liked this article, follow us on LinkedIn, Twitter, Facebook, Youtube, and Instagram for more cybersecurity news and topics.
