15:20 CET, 30th April 2014 By Marcelo Pereira, Business Developer.
In my profession I read a lot of what is published about vulnerability management and patch management.
In general, I find it difficult to extract new and relevant information in the clutter of so much repetition and misconception. When it comes to the different areas of vulnerability management, it’s clear to me that patch management is the one where the lack of clarity is most prevalent.
That is because, despite the growing awareness about the criticality of applying security patches, patch management continues to be seen and treated as the routine of applying updates to applications. As such, it is often treated as a less significant activity which most organizations just want to get over and done with.
Based on this misapprehension, most patch management vendors market their solutions with promises of "simplicity and automation"...
Are those qualities apt in the context of patch management, though?
Before I continue let me just be clear: I do not work in operations and I don’t have to source and deploy patches. I work with patch management from a strategic standpoint. That doesn’t make me unaware of the challenges related to performing the work, however. On the contrary, it reinforces my view of how critical it is to rethink the way we perceive and execute patch management: A starting point is to understand that the main objective of patch management is to improve security by reducing the surface for cyber-attacks. And of course, patches are to be implemented with considerations to business continuity and performance.
In that light I can’t help thinking: When it comes to patch management, is it fair to suggest it can be simple and automated?
And what is simplicity? Is it searching a catalogue and deploying whatever content is there? Is it choosing to remediate a fixed set of applications based on their share? Is it patching Java, Adobe and web browsers because we all know that they are the most vulnerable applications?
From where I stand, simplicity is to have a clear and complete overview of the applications installed in each machine or server and the assessment of the patch levels for each of those. Simplicity is to:
And what is automation? Is it allowing an (additional) local agent to fetch packages from a catalogue and deploy whenever a new version is released? Is it scheduling actions to be performed with no or limited supervision?
Anyone with knowledge about patch packaging and deployment knows that it cannot be that straightforward. And security professionals know that is not good enough by any standards!
So the next time you hear a vendor offering simplicity and automation, you might want to ask what they mean by that …
A biased thought:
Why, instead of aiming at simplicity and automation, don’t we strive for a targeted approach and prioritization? That will add simplicity without neglecting security, and allow us to plan automation whenever it makes sense and we find it secure!
Attend Secunia’s webinars to learn more about Patch Management
Subject: Manage your patches with simplicity and automation! Really?