Patching Up Configuration Management

Configuration management is a many-headed beast, but the biggest beast with the sharpest teeth is the patch monster.  Every day, a new vulnerability, a new patch – and an old decision:  patch and maybe break something (I’m looking at you, Spectre and Meltdown), or stay online and be vulnerable.  This model – “panic patching” -- is in wide practice, but not sustainable.  For now, an efficient and reliable system is essential; for the long term, we need an entirely new model.

What are the features of a viable patch management system?  To begin, it has to have a reliable inventory system:  you cannot patch it if you do not know it is there.  It must then automatically find and download the relevant patches and updates from all software vendors. Once it has downloaded the requisite updates, the system must provide numerous and flexible deployment options.  A typical approach is to deploy to a lab or test environment, then to a small group of test subjects, and only then to the general user population.  To minimize disruption to users, deployment options should allow for scheduling, and for users to defer or refuse a reboot.  Murphy’s Law never disappears, though, so an option to rollback a patch or update should always be available.

Someday, however, OS patching may not be necessary, or can at least be less stressful, for vulnerabilities.  This may sound like a pipe dream, but there is a very promising, and commercially available, approach:  polymorphic defense systems.  These systems, about which I have written earlier this month, can create unique versions of an operating system for every system.  With this approach, an exploit that works on standard operating systems will not automatically work on polymorphic instances of the same OS.  Patching will still be advisable to fix bugs and optimize performance, but the panic associated with updating could well disappear when polymorphic defense becomes the industry norm.