Nobody’s perfect, but every system administrator at some point has undoubtedly asked themself just how much imperfection they are supposed to put up with.
Despite years of trying to improve software quality—and myriad new development methodologies—bugs remain endemic. Users of Microsoft applications face monthly updates, but it’s not only Redmond to blame. Recent reports of new Excel, PowerPoint and Internet Explorer vulnerabilities shared headline space with news of a quarterly Oracle update, including 65 different fixes, a serious buffer overflow problem in Adobe Acrobat, and three potentially serious problems with the open-source openoffice.org. Even Apple—which has built much of its anti-Microsoft rhetoric around its stability—was forced to patch.
Have vendors become blasé in their approach to security? Or, is the problem that controversy-minded hackers are working full-time to uncover exploits so obscure that even the best-managed development process can’t catch them?
In years past, many observers would have opted for the first answer. More recently, however, patching has become a cottage industry amongst hackers who used to test their skills by breaking copy protection on new games and applications the day they are released. Nowadays, publication of such “zero-day” exploits —often by well-respected security researchers—has become a common way of highlighting newly discovered security problems.
That approach puts vendors on the back foot, since the exploits are in the wild before they’ve had a chance to start fixing them. Malware authors count on this window of opportunity, which typically lasts several weeks: a recent exploit building on a security flaw in Windows’ DHCP client, for example, was patched on July 11 but new exploits were still being reported weeks later.
With a global, determined team of security testers constantly chiselling away at their armour, vendors trying to keep security problems at bay through patching are like the little boy trying to protect the village with his fingers in the dike. Just as one patch is being fixed, another exploit emerges—often using a similar but slightly different technique. It’s enough to drive system administrators around the bend. But Andrew Walls, principal security consultant with security consultancy Cybertrust, has a novel solution: resist the urge to patch completely.
Like any other software, he says, patches need to be evaluated, tested and assessed from a risk management point of view. Many patches, for example, fix problems in parts of the system (for example, multimedia capabilities) that are completely irrelevant for many company functions—so why rush to implement them? Others may seem like priorities, but be effectively irrelevant because of well-configured firewalls or other protective measures.
“Patching is just one of many security controls, and not a control that supersedes all others,” says Walls. “It needs to be managed as part of the portfolio of controls that manage the enterprise, and evaluated in terms of how much risk it exposes you to. If you do not have that security governance in place, you are leaving the decisions as to the appropriateness or criticality of patches in the hands of whoever happens to be the system administrator at the time—and the predictable operation of your system is lost.”
The worst offenders are typically medium-sized companies, he adds, where administrators often have the time to think about patching and think they’re doing themselves a service by applying new patches religiously.
By contrast, larger companies have the resources to test patches before deploying. Operating pressures on small companies mean they tend to hoard patches over time and apply them in large bunches; by the time they’re applied, problems with the patches should already have been identified and/or fixed.
Even where you’ve identified a patch that needs to be applied, it’s important to check with business units that may be affected before you actually stick it onto your applications. The last thing you want is for the business to start a payroll run an hour before you bring down the HR system for patching! It’s all part of what Walls calls the art of planned implementation, which can be downright counterintuitive for those of us accustomed to solving problems as fast as they come up. However, by keeping a cool head and measuring actual risk, it’s possible to ride the patching dragon without getting bitten.
—David Braue
Write to the Editor at Technology and Business
* All fields are mandatory.