Step 1: Remove Engine
September 13, 2019
At one of my first jobs in the late 90s, one of my co-workers, a former mechanic and clearly good with cars, purchased an old manual for his used Datsun – pretty sure it was a Datsun, but don’t hold me to that – as he was planning a weekend project to replace the clutch. He brought the manual in to show us, bookmarking (with a piece of paper no less – it was 1999) the “Replacing the Clutch” chapter, which offered a well-documented, by- the-numbers approach to the task. It read (no kidding): “Step 1: Remove Engine.”
Like the father yelling “hit a home run” from the stands to his at-bat son who likely hadn’t thought of that, I recalled that little story of impractical – really, absurd – advice while reading a Bloomberg BusinessWeek article from a few years ago on the WannaCry ransomware attack (“Your Money or Your Data”, May 22nd – May 28th Edition, Page15, 2017). In it, the authors noted how the software industry has parroted the same advice for years to prevent such attacks: “Just patch.” Makes sense. Unpatched systems and the resulting vulnerabilities are the result of poor IT systems management, laziness, scarce budgets, and there’s no excuse for it. And if these companies would just upgrade to the latest version of software rapidly, there’d be no problem. Right?
The article’s authors (Dune Lawrence and Jordan Robertson) did such a good job dispelling this notion, I’m resisting the futile urge to improve their take on it by paraphrasing. Thus, word-for-word from their article:
“Corporations and government agencies sometimes have good reason for not patching quickly. Complex computer networks, fragile custom code, and sheer bureaucratic inertia mean organizations spend a long time testing patches to ensure they don’t break anything and cause crippling network downtime. And computers do break from patches: Some users criticized Microsoft last year when the upgrade to Windows 10 “bricked” their PCs, turning the machines into useless lumps. The financial services industry – already among the biggest investors in cybersecurity – is so thorough and cautious in its process that it takes an average of 176 days, longer than almost any other industry, from identifying a vulnerability to fixing it….”
The bottom line is that patching is not only resource-intensive, but it incurs risk, so it needs to be executed judiciously, especially since there are so many vulnerability types. The key is to achieve overall risk reduction, and focus on the asset patches that will deliver the most bang for the buck. Put another way, it’s about prioritization. Some vulnerabilities expose the organization significantly for any number of reasons: the asset has multiple key services running on it, it’s exposed to the internet, and/or connected to other high value assets. Alternatively, other vulnerabilities can be lived with. Knowing which is which is the foundation of an intelligent, modern vulnerability remediation program.
One thing is undebatable, however. Patching and vulnerability management are complicated…apparently, much like replacing the clutch in ’78 Datsun.