Written by Wen Sin LIM.
A useful tip is to stay abreast of security vulnerabilities whether or not they pertain to your immediate security. To misquote John Donne, No organisation is a lone island.
Patch management is typically an involved process that ranks high on the to-do list of system administrators.
To quote NIST, patch management is the “systematic notification, identification, deployment, installation, and verification of operating system and application software code revisions”. At best, it can be an extremely labor-intensive process. If done incorrectly, however, organizations find themselves vulnerable to data breaches and cyber-attacks and staring down the barrel of copious fines, among other undesirable outcomes.
Thing is, there is no fixed formula to patch management. It ought to be a process that is unique to each organization, based on its risk appetite. This is also because no two organizations share the exact same operating systems, versions, storage locations, and device users – these factors inform your patch management policy.
In addition to these variables which present significant challenges as is, patching has an added time sensitivity element. Some of the most high-profile cyberattacks such as NotPetya and WannaCry saw success, as a good number of organizations failed to address the EternalBlue vulnerability in a timely fashion (Not a year after !).
There is a running joke that “Exploit Wednesday” follows “Patch Tuesday” (the day that Microsoft, Adobe, Oracle and many other tech companies release a host of patches for their software) because cyberattackers are quick to reverse engineer the patches to reveal the underlying vulnerability they address and execute attacks on affected yet unpatched systems.
Proper patch management is an iterative process that can be consolidated into 5 steps.
1. Asset Inventory
The patch management lifecycle starts with identifying which of the 15274 CVEs (as of August 2022) apply to your organization and which systems need to be updated. A CVE is a security flaw that can be exploited by cyber attackers. You need to know what systems you have, what versions they are running, and where they are located.
To this end, it helps to maintain an inventory of the devices, operating systems, and third-party applications that you have as it is likely that you have more than you think, and neglected or forgotten systems tend to be prime targets. Include also details of your systems’ configuration, information like the version of operating systems that are currently in use, number of users, etc.
If you have a large organization with a complex network infrastructure, this can be easier said than done. You might want to consider using an automated asset discovery tool.
After which, you may begin scanning all the items in your inventory for missing software updates, and vulnerabilities or CVEs. You can do this manually or use a vulnerability scanner.
This type of scan is most frequently referred to as a vulnerability assessment. A VA – for which there are multiple tools you can use to perform – will generate a list of unpatched systems with vulnerabilities and hopefully include a recommendation of any number of patches to mitigate each one.
Critical to this is familiarising yourself with vendor patch-release schedules. The number and types of operating systems, applications, and endpoint firmware vary significantly, as does the timing of the patches available for them.
2. Evaluation
At this stage, rookies would already be rushing to deploy the patches. That would be a fatal mistake, however, as not only is it nearly impossible to patch all vulnerabilities within a reasonable timeframe, but also installing all the latest patches en masse is not exactly an effective risk mitigation strategy.
No matter how well thought out the patches are, there is always the possibility of incompatibilities between a patch and other software. You need to decide which software versions to standardise on and which patches should be installed on which devices.
Patch management is not just about distributing and applying updates; it is equally about applying them in the correct order. Patching the high-risk vulnerabilities most critical to your operations should be top priority.
After performing a risk analysis of your identified vulnerabilities, categorize them by criticality.
Four commonly used categories are as follows.
Critical: A vulnerability whose exploitation is usually straightforward and could allow code execution without user interaction, possibly resulting in root-level compromise of servers or infrastructure devices.
Important: A vulnerability whose exploitation is difficult to execute and could allow attackers to take control of the system, possibly resulting in significant data loss and/or downtime.
Moderate: A vulnerability whose exploitation requires user privileges and provides attackers only very limited access.
Low: A vulnerability whose exploitation requires local or physical system access and could allow attackers to gain information about a system.
Criticality is determined by the following:
- The CVSS (Common Vulnerability Scoring System) Severity rating of the CVE
- The likelihood that the CVE. will be exploited
- The impact of a successful exploit
- How easy it is to patch the CVE
- The type of system affected
- The business value of the system
The CVSS severity rating is an objective score that can be used to determine which vulnerabilities should be fixed first. The CVSS produces a score between 0.0 and 10.0, with 10.0 being the most severe.
However, the CVSS does not take into account the likelihood that a CVE will be exploited. For this, you need to look at other factors such as the nature of the flaw, whether there are known exploits, and how easy it would be to write an exploit.
The impact of a successful exploit is also an important consideration. Some CVEs may be rated as high severity but if the systems they affect are not mission-critical, then they may not need to be patched immediately.
Ease of patching is another important factor as some systems may be difficult or impossible to patch without significant downtime.
Last but not least, consider the type of system affected by the CVE. Some systems may be more valuable to the business than others and so should be given higher priority.
Deploying patches takes time and the process results in downtime, which might represent a financial loss for the business. If a system downtime cannot be avoided when applying patches, it is necessary to factor in the time it takes for the deployment.
Deployment of a given patch can take anywhere between a week and a month. The general consensus is, that the larger the organization, the longer the time it takes to deploy the patches.
Knowing when not to patch can be just as important to ensure minimal disruption to business.
This typically takes place during the wee hours of the night when demand for the usage of the software is at its lowest.
However, the longer the wait to deploy, the greater the chance that cyberattackers will find a way in. Therefore, determining a reasonable time frame is a balancing act.
3. Testing
At this stage, you can expect all sorts of issues to arise, ranging from something as small as a non-functioning feature to a server failing to reboot. Error output is well within reason when you have to manage patches from various vendors.
Safe deployment of patches requires you to validate the successful deployment of the downloaded patches in a testing environment – say, a handful of computers set up on a separate server preferably – and check for incompatibilities and/or performance issues before applying them to the entire network.
Proper testing takes time.
Nonetheless, it is necessary in many cases. Taking care with this step limits the damage a failed patch can potentially inflict upon your organization’s infrastructure.
4. Rollout
When you have resolved all the issues that occur during the pilot or testing phase, you can deploy the patches to all devices.
Again, we recommend resisting the urge to deploy the patches everywhere all at once. Instead, execute the rollout in stages. Dedicate the initial phase to less critical systems to make sure that everything is working as it should. If there are no hiccups, continue the rollout until every system is updated.
Automating the deployment process with patch management software at this stage is great because of its ability to distribute thoroughly tested patches to thousands of machines in minutes, thereby improving work efficiency by leaps and bounds. This frees up time for you to coordinate with other departments, engage your stakeholders and help upskill your workforce (consisting of end users, administrators, support and testing teams and more) to adapt to the new and improved system(s).
Important to note here is that the rollout is only complete when all of the patches have been successfully installed. If you have even one unpatched system left, that is still an entry point for cyber attackers.
In theory, patches should not affect the data stored on your devices. But if you wish to play it extra safe, you may choose to also back up your files before the rollout as a precaution.
5. Documentation
Patch management is a never-ending process.
Post-deployment, you would need to then create detailed documentation and generate progress and error reports about patch download, testing, and installation for auditing and compliance. In the unfortunate event of a cyber incident, these reports will come in handy for making your cyber insurance claims.
These documentations will also help ease and optimize subsequent patching exercises.
Let IMMUNE Help
The easiest way to stay abreast of your vulnerabilities is by employing a solution that religiously monitors your cybersecurity posture and promptly notifies you when new vulnerabilities surface and when their corresponding patch becomes available.
IMMUNE will help you with this and more. Check us out: