Every IT environment and cybersecurity strategy has vulnerabilities. To avoid damage or loss, organizations need to find and eliminate those vulnerabilities before attackers can exploit them.
Some of those vulnerabilities will be found and fixed by vendors, who will provide patches and updates for their products.
Other vulnerabilities cannot be patched and will require coordination between IT, cybersecurity, and app developers to protect those exposed vulnerabilities with additional resources that mitigate, or reduce, the risk of exploitation.
Regular and efficient execution of the following vulnerability and patch management stages can provide strong protection for organizations of all sizes:
- Finding vulnerabilities
- Finding Patches
- Prioritizing Vulnerabilities and Patches
- Patching Vulnerabilities
- Mitigation of Non-Patchable Vulnerabilities
Don’t want to handle it yourself? See also:
How to Find Vulnerabilities
Some vulnerabilities will be announced and other vulnerabilities need to be found through testing. However, every IT and cybersecurity team should designate specific people and processes to focus on detecting and managing vulnerabilities.
The first priority will be to collect the advertised vulnerabilities. Vendors will announce exploits and usually produce patches or mitigations for the vulnerability simultaneously.
Vulnerability detection teams need to monitor news feeds and vendor websites to act promptly because attackers move quickly. Mandiant’s research determined that:
- 42% of exploits occurred after a patch was issued
- 12% of exploits occurred within the week after the patch availability date
- 15% of exploits occurred within the month, but after the first week the patch was available
Of course, these will not be the only vulnerabilities that exist in the IT environment. Outdated or unpatched software is just one of the top seven types of vulnerabilities noted by Crowdstrike; the others are:
- Misconfigurations – Incorrect security settings can expose data or systems
- Unsecured Application Programming Interfaces (APIs) – attackers can use unsecured APIs to pull data, introduce code, and other types of attacks
- Zero-day Vulnerabilities – Extremely hard to detect; usually found by researchers
- Weak or Stolen User Credentials – compromised users, either from phishing attacks, reused credentials, or data breaches allow attackers to gain access under the guise of a legitimate user’s identity
- Overly Broad Access Control – Users often will be given access to more resources than they need to do their jobs
- Misunderstanding the Shared Responsibility Model of Cloud computing – Misunderstandings leave gaps in the security stack for attackers to exploit
Using vulnerability scanning tools or outsourcing to vulnerability management vendors can provide a great starting point for locating most vulnerabilities in the organization. However, vulnerability management teams need to be clear about their assets and the limitations of their vulnerability management or detection solutions.
For example, the popular Heimdal Security provides patch and asset management for Microsoft and Linux systems for more than 120 third-party applications as well as any application that can support silent installation commands. While this eliminates many headaches, it does not scan for misconfigurations and may not support other critical updates such as IT infrastructure (routers, firewalls, etc.), firmware (hard drives, drivers, etc.), Internet-of-Things (IoT) devices (security cameras, heart monitors, etc.), Kubernetes instances, websites, applications, and more.
Additional vendors, consultants, or IT resources may be needed to thoroughly scan assets and connections to find vulnerabilities. Penetration testing and breach and attack simulations can also be used to actively locate vulnerabilities.
How to Find Patches
Vendors often will be the first to announce a vulnerability as they publish the patches and updates to address them. However, news sites, community forums, and email alerts can also be good sources for learning about and locating patches.
However, the vulnerability management team should ensure that the patches and updates are legitimate. Attackers constantly send phishing emails, publish fake websites, or push fake browser alerts that contain software updates laden with malware.
Prioritizing Vulnerabilities and Patches
Sometimes, a number of patches will become available simultaneously or the organization may find a number of vulnerabilities that need to be mitigated. How should the organization prioritize the fixes with limited resources?
The Common Vulnerability Scoring System (CVSS) score of the patched vulnerability provides a commonly used reference to determine the potential danger of the vulnerability. The CVSS assigns vulnerabilities a score between 1 and 10. The CVSS version 3.0 ratings correspond to:
- 9.0 – 10.0 = Critical Severity
- 7.0 – 8.9 = High Severity
- 4.0 – 6.9 = Medium Severity
- 0.1 – 3.9 = Low Severity
- 0.0 = No Severity (Informational)
These scores suggest a level of how much an attacker can affect a system or how little effort may be required by the attacker to exploit the vulnerability.
While these scores might provide a sense of urgency, it does not reflect the likelihood of exploitation or the value to the organization. To create a true priority, the organization must also factor in:
- The value of the asset to the organization. This is often measured and tracked in a Risk Register or through a Risk Management program.
- The likelihood of exploitation in the context of the organization
Patching priority examples
For example, consider a hospital with the following:
- A router with
- a remote code execution vulnerability rated 9.4
- Connecting the imaging department and machines to an internal network (high-value systems)
- The internal network is isolated in its own network segment and no internet connections are permitted, enforced through local firewall port settings and strict control of installed software on devices in the network segment
- A common PC model with
- An authentication bypass bug in the firmware rated 7.2 because it requires physical access to machines (although it bypasses sign-on passwords)
- Present on all PCs for all executives and nursing terminals (medium value assets)
- No special IT architecture or security measures are in place
- A router with Wi-Fi capabilities that
- Is enabled for Wi-Fi and accepts Wired Equivalent Privacy (WEP) protocol encryption
- This is the weakest Wi-Fi encryption protocol and should not be enabled
- This is a configuration vulnerability and thus has no CVSS rating
- Is located in the critical care unit and is used to connect the various heart monitors, breathing apparatus, and other devices that might need remote monitoring to the network
- No equipment in the unit uses Wi-Fi connectivity, all are wired connections
- Is enabled for Wi-Fi and accepts Wired Equivalent Privacy (WEP) protocol encryption
If we strictly evaluate these vulnerabilities by their CVSS numbers, the router in the imaging center would need to be addressed first. However, the isolation of the network makes exploitation of the router flaw very unlikely in comparison to:
- A large number of PCs with easy physical access due to the number in use and that some devices may be used in semi-public areas
- A wi-fi connection that could be accessed by anyone in its broadcast range with little skill or effort
Then the value to the organization must be considered. While a large number of PCs can be affected in any number of ways, physical access risks detection and the initial damage might be a data breach for quick financial gain.
Meanwhile, the core function of the hospital is patient health, so any potential threat with access to vulnerable patients in critical condition could lead to serious complications or death. The combination of highest value and greatest risk is thus the vulnerability with no CVSS rating at all.
How to Patch Vulnerabilities
Many organizations automate patch management using patch management software and tools or managed IT service providers (MSPs). Some software vendors (Microsoft, Firefox, etc.) also support automated patching and updating.
Automated patching will always be recommended when it can reduce the burden on IT teams and reduce the time to apply patches and vulnerabilities. However, some patches, particularly for infrastructure, firmware, or less common software may not be automatable.
Additionally, some critical business operations cannot be interrupted without impact and will need to be scheduled for downtime. For organizations that manually apply patches, the basic steps will mimic the automated process with more formal checks at each stage. Patch management best practices for applying manual patches include:
- Testing of patches: Larger organizations can use digital twins to verify that patches and updates will not affect other business systems.
- Patch deployment: Most software, firmware, and appliances support automated patch updates, but may require restarts and downtime that needs to be coordinated to minimize business disruption.
- Installation verification: reports, logs, and additional vulnerability testing can verify that the patches effectively removed the security threat of the exposed vulnerability.
When outsourcing to a service provider or using a patching tool, some patching will be performed automatically and no patching priority may be necessary for those devices. Patching priority will be used to prioritize updates and patches that:
- Require resource shut-down for maintenance
- Conflict with other patches and updates for resources or in a technical sense
- Cause problems with other systems or business processes
Patches, updates, and vulnerability mitigations that have not been executed need to be tracked and fixed based on their priority. This patching queue may contain older, less urgent patches so as new patches are released for the same asset, they should replace outdated patches in the queue. The replacement patch can take the same priority as the old patch or be re-prioritized at the IT Department’s discretion.
How to Mitigate Non-Patchable Vulnerabilities
Any vulnerability that cannot be patched will need to be considered for mitigation. While the number of potential mitigations exceeds the already high number of possible vulnerabilities, we can consider types of mitigations based upon the classification of vulnerability.
For example, consider specific classifications and potential mitigations or fixes:
- Misconfigurations – Once detected, misconfigurations often can be simply corrected by changing settings on the devices.
- Unsecured APIs – Once detected, APIs can be secured with tools, adjusting security settings, web application firewalls, etc.
- Zero-day Vulnerabilities – Zero-day vulnerabilities typically will not be detected by the common organization and thus will not be specifically mitigated. Instead, the organization must develop layers of security so that a single undetected zero-day vulnerability in any single layer will have limited impact.
- Weak or Stolen User Credentials – Organizations typically protect against weak or stolen user credentials by:
- Increasing the complexity of required passwords
- Enabling multi-factor authentication (MFA)
- Performing password cracking internally to locate passwords that must be changed
- Using password managers to assist users in maintaining complex and unique passwords
- Overly Broad Access Control – Organizations improve access control and the principle of least privileged access by:
- Using privileged access management (PAM) software or identity access management (IAM) tools
- Adding more granular controls to active directory with user groups, network segmentation, temporary administrator passwords, etc.
- Misunderstanding the Shared Responsibility Model of Cloud computing – organizations adjust their settings, add cloud security tools, or engage service providers to close the security gaps.
- Obsolete or End-of-Life assets and patches that would disrupt business too severely: These devices cannot be fixed therefore organizations:
- Replace the asset with a supported equivalent
- Add additional security to protect the asset such as
- Web Application Firewall (WAF) added to an unpatchable web application
- Microsegmentation used to isolate a PC running an obsolete operating system (usually to manage operational technology (OT))
- Port knocking or whitelisted IP addresses added to a Server hosting the obsolete File Transport Protocol (FTP) services
Bottom Line
No IT system or cybersecurity strategy is foolproof. The goal must be to deploy reasonable security given the resources of the organization so that the cybersecurity risks can be kept to an acceptable level.
Fortunately, between automation, tools, and outsourcing even a large number of vulnerabilities can be handled with reasonable resources. Staying ahead of attackers is critical to protect the organization’s assets, so every organization must find the vulnerability management system that works for them.
To read more detailed information see also:
