Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/classes.php on line 576

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/classes.php on line 576

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/classes.php on line 576

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/classes.php on line 576

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/classes.php on line 593

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/classes.php on line 687

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/classes.php on line 687

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/classes.php on line 687

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/classes.php on line 687

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/classes.php on line 710

Strict Standards: Redefining already defined constructor for class wpdb in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/wp-db.php on line 58

Deprecated: Assigning the return value of new by reference is deprecated in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/cache.php on line 99

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/cache.php on line 404

Deprecated: Assigning the return value of new by reference is deprecated in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/query.php on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /homepages/15/d244775686/htdocs/TDBASHome/BlogHome/BFBlog/wp-includes/theme.php on line 576
To CPU or not to CPU? - There is No Question
The Seven Habits of a Highly Effective DBAs - Habit Three: Speak the Native Language LOB Oddity
Feb 10

Safe and SecureReading through the online blogs, I came across a discussion of whether Oracle’s Critical Product Updates are worth the ‘trouble’ of applying.  Of course, I’m always very interested to see what DBAs have to say in regards to Information Assurance and database security in general - and I wasn’t disappointed.  Quite a few DBAs had some great, common-sense guidelines for approaching Oracle’s Critical Product Updates!  A thorough system of analyzing the risk and impact, coupled with thorough testing.  It may take a little discipline to keep that process going, but many were thoughtful and solid.

Surpisingly (to me, at least) I had to take umbrage with Don Burleson.  His advice:

You DON’T have to apply patches, and sometimes patches can CAUSE unplanned issues.  The best practices are always to conduct a full stress in a TEST environment before applying the patches in production… I wait for major releases and re-install at-once, and I only look at patches to fix specific issues.”  - Courtesy of TechTarget

I have personally applied dozens of CPUs on (literally) hundreds of systems of all flavors.  I have yet to see a problem on our production servers that was caused by a CPU.  Of course, I have seen a few weeded out through thorough and careful testing beforehand.

The problem with simply not assessing and applying these CPUs due to FUD (Fear, Uncertainty, and Doubt) comes when things go badly, or when you need to meet SOX, HIPAA, PCI DSS, FDCC, FISMA,etc. compliance.

Even on a closed system, if an insider is able to view/modify/delete sensitive information by exploiting a vulnerability fixed by a CPU, your company will be in a very unenviable legal position, as ignoring security patches is not adequately performing ‘due care’.  Also, when operating under various compliance standards or on a DoD system, there is rarely an option to avoid applying a CPU, unless you can document a specific problem the application will induce and your plan to mitigate or eliminate the risk.  This is where a strong  process, when well-documented would be an excellent solution.

If a DBA has a stringent standard of apathy towards Oracle CPUs, it may be an indicator of systemic security problems in their data stores as well, and may warrent some pointed questions:

  • Are you auditing, at the very least, privilege escalation and access to sensitive objects?
  • Are you making sure that glogin and the system executables are not being tampered with?
  • Do you have a benchmark of defined roles and privileges documented?
  • Are you logging who is connecting and accessing the data, when and from where?

If the answers to these are ‘no’, we wouldn’t be aware of a security breach even if it had happened!

Turning the key of your database and letting it go can be a very perilous practice despite what the remote database administration service vendors may tell you.  If data is the lifeblood of your company, it really should be maintained AND protected as such.  No company wants the bad press that follows a data theft.

Brian Fedorko

One Response to “To CPU or not to CPU? - There is No Question”

  1. get rich download Says:

    Well written writing=) Will definitely visit again.

Leave a Reply