Patch Management – How To Do It Correctly

Hello everybody,

For a long time already, lots of our existing customers and prospects have been looking for integrated Patch Management capabilities in SysAid. Recently we decided to accept the challenge and look deeper into it.

That’s where I come in. As SysAid Product Manager, I’m leading the required research and making sure that the requirements sent to R&D cover all our customer needs in regards to Patch Management within SysAid.

It’s obvious that patch management is a critical issue. What is also clear is the main objective of a patch management program: to create a consistently configured environment that is secure against known vulnerabilities in operating system and application software.

I found interesting that according to Project Quant Patch Management Survey, most organizations are not happy with their patching processes: 38% rely at least in part on user complaints to validate successful patch deployments; 68% are unable to measure time to deploy patches; 30% of Windows-based computers had not been patched a full three months after Microsoft published a security bulletin.

Last month I posted a poll in the SysAid Community to check how you keep your IT infrastructure up-to-date with the latest important security patches and software updates. From the poll results I was able to deduce some very noteworthy points. Firstly, the good news is that most of our customers (94%) are attaching importance to the Patch Management process and dealing with it, this way or another. However, most of our customers (93%) don’t have a dedicated tool that provides a comprehensive solution for Patch Management. A significant portion of our customers (60%) use WSUS, which covers Microsoft only and does not provide a comprehensive solution. Talking about browsers for example, then IE has a market share of 26% only, while Chrome (37%), FireFox (23%), and Safari (7%) hold most of the market.

We see that the vast majority of our customers understand how critical patch management is to their corporate IT services, and so do I, as one who worked for over a decade as IT manager in a large international enterprise with hundreds of servers and thousands of users.

But what about the risk we take in applying patches to avoid the risk in not applying them? Sounds confusing, but I’m sure that most of you know what I’m talking about. Applying a patch is installing software—pure and simple. Just like we are careful in new software installations, we also hesitate to apply patches. In some organizations the patch deployment process, mainly to servers, is followed by a well-defined documented process of testing, approval, risk analysis, backup, and so on. So, it’s not by chance that the Patch Management process is defined by ITIL as mainly based on the Change process.

Change management is vital to every stage of the patch management process. As with all system modifications, patches and updates must be performed and tracked through the change management system. It is highly unlikely that an enterprise-scale patch management program can be successful without proper integration with the change management system and organization.

So while planning the Patch Management integration into SysAid, I took into account not only the technological aspects but also the operational needs. Obviously, the Patch Management solution’s main purpose is to keep servers, workstations, and remote computers up-to-date—automatically—with the latest important security patches and software updates. With that said, I also want to allow our customers, who will be interested, to benefit from the automatic patch deployment using integrated Change Management workflows, to ensure they perform the process properly.

For example, let’s say you’re interested in applying all critical security patches automatically on workstations, but in the case of servers you want SysAid to create a Change Record for each server asset with special (out-of-the-box) predefined Patch Management process. By following this process eventually you’d apply the patch on the server, AND you’d have all processes documented too! You’d have the chance to test the patch in a lab, and/or make sure you have a backup in case something goes wrong. You’d plan the downtime and send notifications if necessary. How does that sound?

I’ll be hosting a Roundtable next week, on Feb. 5th, to discuss these issues. Would love for you to join us.

Please feel free to comment, share ideas, and ask questions. All your inputs are highly appreciated.

-Oleg

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.