Will CIS Oracle 11g security remediations break shrinkwrapped apps? Gotchas, lessons learned, and remediation methodologies
Date: Wed, 18 Apr 2012 05:10:44 -0700 (PDT)
I've been asked to remediate various Oracle security issues for dozens of instances. Here's the reference document provided with the scan results: Center for Internet Security Security Configuration Benchmark For Oracle Database Server 11g Version 1.0.1": http://www.nsa.gov/ia/_files/db/I733-043R-2008.pdf I'm not a security expert. So my comfort level is low. Great learning opportunity. But I don't want to inadvertently break apps in the process. Can anyone familiar with this doc please share any "gotchas" / "Lessons Learned" / constructive criticisms / preferred methodologies? Sorry if this seems too general a request. But I thought it would be cheaper to learn from others. Especially for any items where the remedy was (egregiously) worse than the "disease."
Here are some concerns:
- One remediation asks that ALL_% objects to PUBLIC be revoked. Yet many shrinkwrapped apps seem to rely on the presence of such grants. Without access to a vendor's source code, or asking a large vendor (who may be slow in responding) to disclose what they use, how will I know what will break without extensive testing? Testing that neither DBAs, app administrators, or customers may have time to conduct due to resource constraints. A side question: are vendors whose apps expect such privileges blameworthy security-wise? Or is the CIS document a tad too vigorous and overreaching in its recommendations?
- Some vendors seem to rely on PUBLIC grants to various stock Oracle packages (DBMS_%). And Oracle 188.8.131.52.1 on RHEL 5 itself, or its options, may have cross package dependencies. Even with "best effort" testing, one wonders if there will be downstream issues later on. Even after things have been running for a while in Production. The same vendors may be inordinately generous with PUBLIC grants to their own objects--but that's another issue.
- Sometimes we're asked to remediate instances out-of-cycle, e.g. on a higher stage where the remediation has not yet been done and tested on a lower stage. We have four stages: dev > test > qc > production (and some training / recovery ones).
The only approach I know to take without consulting app vendors is as follows:
- Perform one remediation at a time
- Before each remediation, check for all objects where STATUS <> 'VALID' (better than STATUS = 'INVALID')
- After each remediation recheck status for all objects
- Execute direct grants to those who require access to a package then recompile
Does this seem like a valid approach? Is there anything else I can do?
Here's another vexing question: when asked to set kernel resource limits, where should I look for guidance on what values to set (short of asking vendors, who may themselves not know what to advise due to lack of knowledge of a customer's particular load profile / use patterns)? App resource utilization has seasonality. With a new app, in the absence of vendor recommendations, it's often hard to know what values to use. Or to predict what the usage profile will be over time for a new app. I could imagine apps reaching a "plus one" threshold and breaking. How do you deal with that when you manage many apps and instances?
For example, items such as:
- PRIVATE_SGA (shared server architecture only)
- SESSIONS_PER_USER (concern here with session pooling)
- CONNECT_TIME (some apps are poorly written, and throwing more hardware resources at the problem does not solve the Root Cause)
This is my first post here. Given the subject matter (security), would it be ok to roll-up any offline responses without attribution? Perhaps anyone responding offline could let me know whether or not they wanted to be cited?
Finally, if I could read only one book on Oracle 11gR2 security to assist me with this task, what would people advise?
GIS for DBAs. Database Concepts for GIS. http://SpatialDba.comReceived on Wed Apr 18 2012 - 07:10:44 CDT