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.<\/p>\n\n\n\n
Some of those vulnerabilities will be found and fixed by vendors, who will provide patches and updates for their products.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Regular and efficient execution of the following vulnerability and patch management<\/a> stages can provide strong protection for organizations of all sizes:<\/p>\n\n\n\n Don’t want to handle it yourself? See also:<\/p>\n\n\n\n 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<\/a> to focus on detecting and managing vulnerabilities.<\/p>\n\n\n\n The first priority will be to collect the advertised vulnerabilities. Vendors will announce exploits and usually produce patches or mitigations for the vulnerability simultaneously.<\/p>\n\n\n\n Vulnerability detection teams need to monitor news feeds and vendor websites to act promptly because attackers move quickly. Mandiant\u2019s research determined<\/a> that: <\/p>\n\n\n\n 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<\/a>; the others are:<\/p>\n\n\n\n Using vulnerability scanning tools<\/a> or outsourcing to vulnerability management vendors<\/a> 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.<\/p>\n\n\n\n For example, the popular Heimdal Security<\/a> 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.<\/p>\n\n\n\n Additional vendors, consultants, or IT resources may be needed to thoroughly scan assets and connections to find vulnerabilities. Penetration testing<\/a> and breach and attack simulations<\/a> can also be used to actively locate vulnerabilities.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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<\/a>.<\/p>\n\n\n\n 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?<\/p>\n\n\n\n The Common Vulnerability Scoring System (CVSS)<\/a> 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:<\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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:<\/p>\n\n\n\n For example, consider a hospital with the following:<\/p>\n\n\n\n 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:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Many organizations automate patch management using patch management software and tools<\/a> or managed IT service providers (MSPs). Some software vendors (Microsoft, Firefox, etc.) also support automated patching and updating.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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<\/a> for applying manual patches include:<\/p>\n\n\n\n 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:<\/p>\n\n\n\n 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\u2019s discretion.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n For example, consider specific classifications and potential mitigations or fixes:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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\u2019s assets, so every organization must find the vulnerability management system that works for them.<\/p>\n\n\n\n To read more detailed information see also:<\/p>\n\n\n\n\n
\n
<\/a>How to Find Vulnerabilities<\/h2>\n\n\n\n
\n
\n
<\/a>How to Find Patches<\/h2>\n\n\n\n
<\/a>Prioritizing Vulnerabilities and Patches<\/h2>\n\n\n\n
\n
\n
Patching priority examples<\/h3>\n\n\n\n
\n
\n
\n
\n
\n
\n
How to Patch Vulnerabilities<\/a><\/h2>\n\n\n\n
\n
\n
<\/a>How to Mitigate Non-Patchable Vulnerabilities<\/h2>\n\n\n\n
\n
\n
\n
\n
\n
Bottom Line<\/h2>\n\n\n\n