Anyone who’s been in or around IT is familiar with the age-old practice of patch management. Even non-IT professionals are familiar with it, as patches and updates are regularly delivered to their mobile and connected devices. While many of the concepts around patch management haven’t changed, the technology has. So, it warrants a revisit of patch management best practices.
That is exactly what NIST delivers in their latest draft of 800-40 rev. 4, “Guide to Enterprise Patch Management Planning: Preventative Maintenance for Technology.” The guidance starts off by emphasizing how the perimeter-based security approach of legacy IT is long gone. Many technologies have internet exposure, and in today’s dynamic threat landscape, it isn’t if an adversary will be inside your network, but when.
There’s also the well-known push and pull between business leadership and IT staff in needing to update systems while mitigating business disruption.
Recommendations for Enterprise Patch Management
While NIST’s guidance dives into both the software vulnerability management lifecycle and risk response execution activities, we will focus on some of the key recommendations for enterprise patch management planning. These include mitigating disruptions; inventorying your software assets (hello CIS Critical Control #2); defining your risk response scenarios, and more.
Everyone in cybersecurity is likely familiar with your options for risk—those being acceptance, mitigation, transfer, or avoidance. How you decide, or neglect, to implement patch management practices will have inherent implications for how you’re addressing risk to your enterprise.
In the vein of reducing patching-related disruptions, NIST makes several recommendations, some easier said than done. These include hardening your software by implementing industry and vendor guidance or security best practices. This is possible but also has dependencies on the design of the software in question.
The same goes for your ability to acquire software likely to have fewer vulnerabilities. Even the most notable and known software vendors regularly release updates and patches for their software. Some would argue that the more ubiquitous a software is, the more likely it is for vulnerabilities or functional gaps to be identified and need to be addressed. No software is flawless.
They also recommend working with software development partners that are likely to produce more secure code (e.g. remember our discussion on software security maturity?). NIST also recommends deploying applications in ways to minimize patch disruption. One such way is embracing a containerized application model, where you can update the container in a registry, then roll it out using scaling strategies and other methods to minimize the end user ever realizing an update is underway.
Inventory Software and Assets
Inventorying your software and assets is absolutely critical. It is and has been among the top security controls for many years. Without an accurate and well-kept inventory, it can be nearly impossible to identify where patches are needed or where software even exists in your enterprise. However, as NIST acknowledges, having a perfect inventory, especially in today’s dynamic technology environments can be incredibly difficult, albeit still absolutely necessary.
Once an inventory is created (and maintained in perpetuity), organizations can take steps such as determining which assets are the most critical to business operations, have legal or regulatory ramifications, or even restrictions on risk responses (e.g. can only be modified during specific windows). Organizations should also assign assets into groups with similar characteristics, making it easier to logistically manage the large amount of assets most organizations are dealing with. The recommendations also include defining risk responses for those assets, such as routine patching, emergency patch (e.g. log4j) and other options.
One of the more important and practical recommendations in the guidance involves choosing actionable enterprise-level patching metrics. If you’ve worked your way up through security, particularly on the defensive side, you’ve undoubtedly experienced the fatigue of chasing never ending patch/vulnerability metrics. However, context matters. How many vulnerabilities you’ve addressed isn’t as relevant if it doesn’t also provide insight into the criticality of the assets to which those patches apply. Security is in the business of risk management, or enabling the business to make risk-informed decisions. Blanket vulnerability metrics not tied to organizationally defined criteria, such as asset criticalities, are nearly useless.
Software Maintenance and SLAs
Patch management metrics should also take the audience into consideration, as the CIO or even the board will have a different interest or focus than say the system administrator. Audience-oriented actionable metrics are the goal.
Lastly, as organizations continue to work with a dizzying array of vendors, managed service providers, cloud, and more, software maintenance must be a consideration in acquisition activities. The organization should understand how the vendor will respond to vulnerabilities. What their development lifecycle looks like, service level agreements, and more can make all the difference between having a response software vendor or partner—or being left in the cold when the next “insert name here” zero day is discovered.
