A “vulnerability” is a weakness in the computational logic (e.g., code) found in software and some hardware components (e.g., firmware) that, when exploited, results in a negative impact to confidentiality, integrity, OR availability. Mitigation of the vulnerabilities in this context typically involves coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety). – CVE.MITRE.org
Patch management is the process of ensuring vendor patches are installed and current. While this is a critical aspect of ensuring your organization’s security posture, it does not provide the full picture or spectrum of protection needed for security purposes. I often view patch management more from an IT operations perspective. In an enterprise, it is important to have software that is patched and no longer affected by known bugs which could cause an operational outage.
There are times when the lines are blurred and patches do provide some protection from a security viewpoint. Many vendor patches not only resolve software bugs that could cause an operational outage, but also contain security fixes which could leave your organization exposed to known vulnerabilities if not patched quickly. Another factor that often blurs the lines between patch management and vulnerability management is the fact that many software vendors are now combining the two processes into their commercial offerings. This is not, in my opinion, a bad move as it helps to facilitate the understanding and action of both processes.
Many solutions exist today for managing and automating patches. As with all IT and security processes, it is best to look for ways to automate everything we do. It is also important to keep in mind that all software is buggy. There may be software for which the vendor or third-parties have not identified known bugs, but it is rare to have software that literally is flawless, especially with the deadlines and software release cycles within many companies. Patch management helps to ensure that the organization stays on top of these potential issues.
Vulnerability management does focus on software bugs, but it also focuses on other types of vulnerabilities in and around systems. For instance, a system with hypothetically flawless software could still be vulnerable if it was running insecure services or a service intended to be used locally that was accessible remotely due to local firewall policies. Asset discovery, local security policy, and network controls all play a part in vulnerability management. Let’s take a look at asset discovery and how it is important.
It is simply impossible to understand vulnerabilities in the enterprise until we know which systems exist on our network and provide some mechanism for scanning those devices. Many organizations track these assets in spreadsheets, but that does not allow for assigning risk through an understanding of the configuration and services supported by these assets. An asset discovery system with a CMDB, or configuration management database would allow for much more granular tracking and understanding of the importance of a particular asset, or configuration item.
The discovery mechanism should provide for manual scans of defined networks as well as rogue asset discovery. Rogue assets are those assets not known to the organization that make their way onto the network by way of improperly managed access points or poorly configured switch ports without the appropriate security measures. Those devices need to be found quickly and segmented from the network until they can be physically located and permanently removed or properly added to the network. These rogue devices could be wireless or wired and in either case bring potential risk to the organization.
While knowing your assets comes before an understanding of your vulnerability exposure, another factor to consider is prioritization for remediation. In a perfect world, we would want to resolve any and all vulnerabilities as soon as possible. Possible roadblocks to this process could be critical services, lack of necessary staffing, and lack of automation to name a few. There could be many other reasons for remediation to be pushed off to a later time. Coordination is required between the vulnerability response team and IT to ensure assets are patched and secured within an acceptable timeframe.
What is the acceptable timeframe for remediation? This is different in every organization. The more important question is where to begin. Prioritizing your remediation efforts by understanding where you have the most risk will provide the biggest bang for the buck. Which vulnerabilities are the easiest to exploit and have known exploits in the wild? Which systems with vulnerabilities are tied to the mission or business-critical assets? The organization needs a way to collect and use this information. This is once again a great use case for the CMDB where this type of information can be added to configuration items.
Understanding the difference between patch management and vulnerability management will not only help to ensure that systems are patched and stable, but also secured against known threats. Systems can be vulnerable due to configuration, network settings, and poor perimeter defenses. It is important to ensure you are staffing your organization with personnel who understand the various ways your systems could be attacked. Patching is important not only for stability and operational stability, but also in order to protect systems from a security perspective.
As always, I welcome your commentary in the comments below. Since every security professional has different experiences and backgrounds, it is helpful to share and help grow the community’s knowledge. Please share your thoughts and constructive criticism and help sharpen our community.