As an IT Security Administrator of your company, you are in charge of the monthly deployment of security patches for its countless servers and desktops. Now, an email coming from your boss tells you that you need to update specific machines running on certain OS due to a vulnerability that was identified by another team. Your initial reaction might be one of disbelief, exasperation, or both.
It’s an understandable reaction. Most, if not all, IT people normally consider patch management and vulnerability management as one and the same. Given the age-old IT practice of treating patching as a one-and-done activity, it is pretty much common to find “veteran” IT professionals who do not have any idea why there’s a need to separate the two IT processes.
Yes, patching management and vulnerability management are two distinct processes. It is important to repeat the last words: processes, not just systems.
Here’s a quick way to differentiate them.
Patch management is a process of updating or upgrading existing programs, operating systems, and applications of existing assets (read: IT hardware); this process also includes planning, testing, and actual deployment up to user acceptance of each patch.
Patch management is a subset of vulnerability management.
To elaborate: In traditional IT practices, patch management is a process where the company takes care of all the updates and upgrades of all software that are installed on each of the company’s hardware, which may include mobile devices that cover smartphones, laptops and tablets.
It also involves identifying, classifying, and prioritizing whatever patch is missing from a certain asset. Let’s put it this way. The updates are actually managed by each vendor but are not limited to program iterations and security fix. However, it is important to note that not all of these patches are able to completely fix all security issues on a certain software, be it an application or an operating system. This is where a more holistic process comes into place: The vulnerability management.
Vulnerability management is the process of identifying existing security loopholes, the patches that are supposed to fix these holes, and the part where a decision is made to roll out, skip or rollback these same security fixes.
What patch management has iis a process that is purely reactive. Meaning, it relies solely on the vendor’s policy when releasing security patches or KB fixes. For example, Microsoft used to have something called Patch Tuesday wherein they release Windows security and kb patches every second Tuesday of each month. The company doesn’t have any control on this. It’s the vendor, which in this case is Microsoft, who decides what fixes will be released on a scheduled date, which in this example is the second Tuesday of each month.
Vulnerability management, on the other hand, makes use of a company’s existing IT Security Policies and combines this with their existing patch management process to come up with an entirely holistic function of deciding whether to apply, skip, or rollback specific patches and software fixes depending on their risk assessment.
In a growing world of Internet of Things, having a dependable vulnerability management process is a big step in ensuring enterprise security.
Imagine this, every time a vendor releases a new version of their software product, black hat hackers literally race each other out in trying to discover and exploit vulnerabilities on every program iteration. Every program port, interrupts, memory buffers, or embedded codes are being scanned for possible backdoors that, if left unresolved or unpatched, can be used later on to initiate data theft that could cost the company millions of dollars.
A good vulnerability management process prevents this by identifying what assets need protection by doing a vulnerability scanning process; it then patches them when necessary, using any existing patch management system, then running a second vulnerability scan post-patching to ensure that the target exploit has been successfully closed out.