When you buy through affiliate links in our content, we may earn a commission at no extra cost to you. Learn 
By February 2011, Anup Ghosh, a security expert and founder of Invincea, had had enough.
Patching, the decades-old process by which computer programs, line-item software source code and supporting data and hardware are updated, had to change.
Ghosh was tired of what he called a reactive, versus a proactive, approach to patching. He was sick of the media coverage of the computing flaws of various software vendors and the banality of updating systems that hackers and the ordinary wear-and-tear of IT operations would render inoperable, unsafe…or both. (For more on keeping your network safe, see Top Must-Know Network Security Tricks.)
So it was then – in what was mostly a minor blip to those outside the enterprise system administrators community – that Ghosh chose to air his grievances.
“We are in fact caught in a self-perpetuating Security Insanity Cycle where we keep repeating the same processes – patch/update, detect, repair – with the same results, but somehow expecting a different outcome,” Ghosh wrote.
While he wasn’t alone in his assertions, the status quo of patching – administrators waiting for updates from vendors and then installing and rebooting – remains mostly the same with little chance of evolving, at least for now.
But to understand Ghosh’s frustration about where patching is headed, one must first understand how far the process has come.
Patching: The Back Story
Patching, as standard IT practice, began in the IBM mainframe days, with perforated paper tape and punch cards that look more at home in a voting booth than in a computing environment.
It was in the heady days of the 1970s and early 80s – a time marked by black screens with big green letters, hyphens, hash tags and binary numbers – when software developers mailed pieces of paper tape or cards with new type-written code placed or patched over old code for updates. In the late 1980s and early 1990s, magnetic tape designed for reels emerged. It was patched in much the same way that movie film is cut and replaced with old segments, while old scenes are left on the proverbial cutting-room floor.
Later, there were floppy disks, then hard floppy disks, followed by CD-ROMs with new and coded updates to be installed. Today, there is not a single computer program in the world that doesn’t require a patch.
Patch Tuesday: Patch Releases Become an Event
The turning point for the widespread patch process has its roots in 2003, when Microsoft introduced Patch Tuesday. It was then that software engineers at Microsoft decided that a comprehensive update of Windows 98 operating system environments was needed to create uniformity for administrators and reduce operational flaws between workstations.
Since that time, Oracle, Apple, Adobe Systems and even Google have ramped up regular patch releases in earnest.
But by 2007, Patch Tuesday, still the flagship event in enterprise update culture, had become, to some critics, merely the day before “Exploit Wednesday,” as hackers increasingly learned how to use the patch schedule to determine the points at which systems were most vulnerable. (Hackers aren’t always bad – see 5 Reasons You Should Be Thankful For Hackers.)
Just three years after the inception of Patch Tuesday, it began to appear that while hackers were getting wise to the design, structure and nature of system patches, the patches themselves were too slow to be released, tested and deployed in IT environments that increasingly depended on processing speed.
Needless to say, a lot had changed since 2004, when Microsoft was the top-of-the-heap enterprise software concern. Back then, periodic updates of out-of-the-box software made sense and were (for the most part) efficient. With other vendors following suit, administrators could just pick and choose what to patch and when to patch it. But as computing increasingly moves to the cloud and becomes more mobile, the speed and soundness of patching has become more of an issue. This presents a new challenge.
The New Challenge in Software Patching
Invincea’s Anup Ghosh is just one of many in the IT community that take issue with patches and the typical process of regular updates.
In a February 2011 post, Ghosh intoned that there had to be a way to get ahead of a patching process:
“Security gurus will speak to the implications of the latest wave of potentially fatal flaws left in the millions of lines of code for the world’s most ubiquitously deployed software. While for network managers, it becomes a race to close the window of exposure in their networks before cyber foes exploit these holes.”
Patch management is still a multibillion-dollar, necessary evil for hundreds of enterprises, consultants, small IT shops and companies trying to maintain functionality and security for the critical systems and programs that parse, process and store mission-critical information.
While patch system supporters say there are a few people simply looking to cash in on non-manual patching (and this is true), the indisputable reality is that computers, applications and self-replicating software now update faster than the speed of thought.
Patching the Future
Just as tapes, cards, floppies and CD-ROMs all became passé, so will be the downloadable and installable patch programs that have long been standard practice.
We are now entering an era in computing where patching will become obsolete, according to Andrew Storms, Director of Security at San Francisco-based nCircle. Storms said that updates will increasingly happen automatically “without end user awareness or involvement.”
He cites the advance of real-time browsers, such as Google Chrome, where the update process is adding automation, and updates are likely to become entirely hands-off.
“Patches, like passwords, are just a hindrance for users,” Storms said. “Users don’t care about patches; they just want to do their job, and they just want their stuff to be secure and operational.”
So what’s next? One word: automation.
Automating IT
There are already non-manual patch programs, such as such as JUpdater, StableUpdate or Visual Patch.
But the key challenge is less about technology and more about the culture of information technology professionals, of which many have spent their entire careers waiting to install patches and then monitoring system changes.
All in all, given the evolution of patching and patch management, the IT ecosystem is ripe for change. And IT pros had better get ready. It will happen whether they like it or not.
