This approach is basically an abdication of DBAs roles in defense in depth. It boils down to "if someone attacks my database, it is someone else's fault." The firewall wasn't configured properly, the IPS didn't flag the attack, etc. Why should DBAs have to wrestle with reading CPU docs, determining if they are relevant and then, God forbid, have to patch the database. I've worked on databases for years and don't recall ever working with any DBAs that possessed such a warped sense of entitlement that database security was not their responsibility but judging from Cobb's article, they are out there.

Another problem is that application level attacks, like SQL injection attacks, are an obvious way to get to the database. Network defenses won't help here. We can't be lulled into a false sense of security because we keep control of privileged accounts, some injection attacks can be launched without elevate privileges. Look at some of David Litchfield's work, he's been a thorn in the side of Oracle for years calling the vendor on security problems with the RDBMS. You'd be surprised what kind of problems you can find with a fuzzer and a list of APIs.

No, I'm not saying we need to apply every patch, every time but we do need to know how to tell the required from the optional and above all we can't go around sticking our head in the sand claiming security is someone else's problem.