Comments on: Many still holding off on Oracle database CPUs http://itknowledgeexchange.techtarget.com/eye-on-oracle/many-still-holding-off-on-oracle-database-cpus/ A SearchOracle.com blog Fri, 27 Nov 2009 04:37:14 +0000 http://wordpress.org/?v=2.6.2 By: Bfedorko http://itknowledgeexchange.techtarget.com/eye-on-oracle/many-still-holding-off-on-oracle-database-cpus/#comment-1386 Bfedorko Wed, 04 Mar 2009 18:38:42 +0000 http://itknowledgeexchange.techtarget.com/eye-on-oracle/?p=616#comment-1386 Database security is an all-too-often neglected facet of Database administration. We DBAs often feel a false sense of security, having the data stores locked behind a firewall, or somewhere on an internal network. However, the more I read about organizations neglecting to take even the most basic steps at shoring up their data store's security posture, the more odd, out-of-step excuses I seem to run into: - "We're on our own server, behind a firewall - No one can get in" Oddly, this article mentions the Forrester Research report detailing "database attacks are at an all-time high". - "We can't afford the downtime" But you can't afford a DR failover site? That would also allow you to roll out the CPUs without downtime. - "We can't risk introducing a bug" You don't have a testbed? Of any sort? How do you test your Recovery? Nothing in your architecture ever changes? Really? - "We do not have any specific requirements for the application of vendor supplied security patches" So unless you are mandated by an outside agency or organization to protect your data, you simply refuse to? I also do not buy the 'Risk Analysis' excuse. Although some CPUs admittedly don't patch critical security holes, about 50% do. What type of mitigation is needed during Risk Analysis to not patch security holes that allow privileged user access without credentials? It would have to be incredibly compelling. As a DBA, I have never been in an organization that did not value efforts to harden their data stores, so I am going to place this responsibility on our doorstep. As a DBA, you are the subject matter expert for the DBMS - If security is lacking in this area, we should step up or be prepared to be accountable for the results. Brian Fedorko Database security is an all-too-often neglected facet of Database administration. We DBAs often feel a false sense of security, having the data stores locked behind a firewall, or somewhere on an internal network. However, the more I read about organizations neglecting to take even the most basic steps at shoring up their data store’s security posture, the more odd, out-of-step excuses I seem to run into:

- “We’re on our own server, behind a firewall - No one can get in”
Oddly, this article mentions the Forrester Research report detailing “database attacks are at an all-time high”.

- “We can’t afford the downtime”
But you can’t afford a DR failover site? That would also allow you to roll out the CPUs without downtime.

- “We can’t risk introducing a bug”
You don’t have a testbed? Of any sort? How do you test your Recovery? Nothing in your architecture ever changes? Really?

- “We do not have any specific requirements for the application of vendor supplied security patches”
So unless you are mandated by an outside agency or organization to protect your data, you simply refuse to?

I also do not buy the ‘Risk Analysis’ excuse. Although some CPUs admittedly don’t patch critical security holes, about 50% do. What type of mitigation is needed during Risk Analysis to not patch security holes that allow privileged user access without credentials? It would have to be incredibly compelling.

As a DBA, I have never been in an organization that did not value efforts to harden their data stores, so I am going to place this responsibility on our doorstep. As a DBA, you are the subject matter expert for the DBMS - If security is lacking in this area, we should step up or be prepared to be accountable for the results.

Brian Fedorko

]]>