Get Up to Speed on...
Get the latest headlines and
company-specific news in our
expanded GUTS section.
One problem is that being proactive often gets confused with being fully automated. This is risky, because they're two very different concepts.
While there is much to recommend with regards to automating portions of the patch process, there are also compelling reasons to support manual intervention as a component of the work flow. There's no doubt that administrators are drowning in a flood of daily threat warnings and patch updates and have valid reasons for not applying every patch immediately.
Too many have been burned by server farms going dark with a collective "blue screen of death" after applying a buggy service pack and are, quite reasonably, skittish about automatically slapping the latest patches on their production servers. Complicating matters are the vendors themselves. Many release vulnerability warnings concurrently with the patch fixes, escalating the urgency of the patch cycle. Yet the patches themselves are often not fully tested and can result in more problems--such as patches that delete critical third-party agents--rather than fewer.
The reality remains that a majority of security fixes are done retroactively, after an incident has occurred.
The result is that the industry is between a rock and a hard place on the patch issue. Case in point: Six months before SQL Slammer hit companies such as Bank of America and Washington Mutual and brought portions of their automatic teller machine networks to their knees, Microsoft had released a vulnerability warning and a patch. Why hadn't those organizations applied the patch? Were their administrators asleep at the wheel? Far from it. What they need is focused intelligence about which patches to apply--and when.And the need for disseminating this intelligence quickly, supported by recommended action steps, or automation where possible, is a must. Slammer had a six-month lead time, but Slammer, which affected Air Canada and the New York Times, among others, had only a 28-day lead time. It is not fear mongering to think ahead to exploits that can wreak havoc on systems that are discovered only six hours, or even 28 minutes, before the attacks ensue.
Certainly, being proactive is one of the components of the solution. Yes, we do, as an industry, need to take the time to "floss." What does that mean though, in practice? First and foremost, it means taking preventative measures that surround and support the patch management efforts.
Patches alone are not the ultimate solution. Harden servers where needed; turn off unnecessary services; build access control into the network, servers and applications themselves. For patch management, services and tools that fit into the overall system and network management solution--not just that stay siloed in security--work more effectively.
Part of the reason the industry is in reactive mode so much of the time is that security is not seen as critical to the overall business profitability.
Finally, as Mel Brooks said, "Hope for the best, expect the worst," and have a recovery plan in place. Sometimes reacting after the fact is essential, none of us are soothsayers, and even the most well protected and patched systems may ultimately be attacked. So be ready with a plan for when that happens; the ability to recover from a critical failure is a part of the overall security posture. The truth is that patching and protecting proactively will reduce vulnerability, but being prepared for the inevitable reactive patching and recovery is essential as well.
Part of the reason the industry is in reactive mode so much of the time is that security is not seen as critical to the overall business profitability. This is a dangerous approach and leads to vulnerability. Arguably, no business can run if it's not secure. But until upper management buys into this viewpoint, security will remain a secondary consideration.