Manage your patches with simplicity and automation! Really?
15:20 CET on the 30th April 2014 Entry written 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:
have clear information about the criticality of patches to help risk assessment and prioritization of deployment
receive patch content that is correlated with the applications that are installed in each machine or server
have tools that make packaging less labour intensive
integrate with existing tools and processes to leverage knowledge and investment
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!
RE: Manage your patches with simplicity and automation! Really?
9th May, 2014 02:37
Score: 0 Posts: 1 User Since: 3rd Jul 2009 System Score: N/A Location: N/A Last edited on 9th May, 2014 02:37
Hi Marcelo. Great article! Congratulations.
I am glad to see that patch management is in your business agenda.
Indeed the major challenges faced by companies around the world when dealing with patch management is to start looking for patch deployment from the operation standpoint where we shared to see much more benefit in include the business in the company's vulnerability management program.
I wrote an article for ISSA couple of years ago where I conclude that the first patch management misconception is about ownership and then I go into details about the need for a framework the market is looking for.
I would be glad if you can read my article and share your thoughts. I don't have a "blog" but I made an exception to build one for your reading. I have an English version somewhere. If you find it worth to upload an English version I can share a file. Just drop me a message in Linkedin.