When I lived in the Bay Area, each Spring we had the same news repeat. Like clockwork, every year, year after year, and often by the same reporter. The story was the huge, looming danger of forest or grass fires. And the basis for the story was either because the rainfall totals were above normal and had created lots of fuel, or that the below-average rainfall had dried everything out. For Northern California, there really are no other outcomes. Pretty much they were saying you’re screwed no matter what. And no one on their editorial staff considered this contradiction because there it was, every spring, and I guess they had nothing else all that interesting to report.
I am reminded of this every time I read posts about how Oracle databases remain un-patched for one, or *gasp* two whole patch cycles. Every few months I read this story, and every few months I shake my head. Sure, as a security practitioner I know it’s important to patch, and bad things may happen if I don’t. But any DBA who has been around for more than a couple years has gone through the experience of applying a patch and causing the database to crash hard. Now you get to spend the next 24-48 sleepless hours rolling back the patches, restoring the data, and trying to get the entire system working again. And it only cost you a few days of your time, a few thousand lost hours of employee productivity, and professional ridicule.
Try telling a database admin how urgent it is to apply a security patch when they have gone through that personal hell! A dead database tells no tales, and patching it becomes a moot point. And yet the story every year is the same: you’re really in danger if you don’t patch your databases. But practitioners know they could be just as screwed if they do patch. Most don’t need tools to tell them how screwed they are – they know. Dead databases are a real, live (well, not so ‘live’), noisy threat, whereas hackers and data theft are considerably more abstract concepts.
DBA’s and IT will demand that database patches, urgent or otherwise, are tested prior to deployment. That means a one or two cycle lag in most cases. If the company is really worried about security, they will implement DAM or firewalls; not because it is necessarily the right choice, but so they don’t have to change the patching cycles and increase the risk of IT instability. It’s not that we will never see a change in the patch process, but in all likelihood we will continue to see this story every year, year after year, ad nauseum.