RE: Will CIS Oracle 11g security remediations break shrinkwrapped apps? Gotchas, lessons learned, and remediation methodologies
Date: Wed, 18 Apr 2012 12:04:39 -0500
Short answer: YES!
As one of the principals for the original 8i/9i CIS Oracle Benchmark, which has in large part been carried forward to this more recent version, I can perhaps shed a wee bit of light on the intent. Note that I do NOT speak for CIS! The following is my opinion only.
If you blindly follow all the "recommendations" in the document, you will likely break something in any system - probably a lot for any packaged apps. This document is the result of "design by committee", so not everyone involved agreed 100% with everything in it. You do not have to do everything it recommends. Local policy overrides are common, even in the most rigorous shops. The intent is to get you to think about it and know exactly why some recommendations cannot be implemented on some systems - rather than just accepting whatever comes out of the box (so to speak). If you have a serious security organization, you may have to document the exceptions and reasons for them.
- In my opinion, revoking permissions on all ALL_% objects is simply too much, at least as universal policy. For example, what you see in ALL_TABLES is only those tables on which you already have some permission.
- Revoking PUBLIC permissions on DBMS_% objects should be done carefully and judicously. However, many of them are problematic and should be granted only to appropriate users/roles. For example, does everyone really need access to DBMS_META? There have been significant security holes in it at times. In the distant past, I used to use it to demonstrate SQL injection. Some of the most sensitive objects are explicitly mentioned elsewhere also.
- I can't really say anything about this except that most third-party vendors (understandably) don't really want to actually review and remediate all the potential security-related issues for their software. There are tradeoffs between usablility and security, so many simply insist on over-privilege rather than suffer the increased support calls from people who are having usability issues. Just like Oracle support, not everything they insist on is actually best for the customer; some of it is simply to minimize their own workload or call volume.
As for resource limits, there are generally no "recommended values" for the ones you listed (the kernel limits). If there were, they would be wrong far more often than "right". You might want to set some of them, expecially for runamok users and such, yet leave them unlimited for others. Do you really want an 8-hour batch job to be aborted because it exceeded the CONNECT_TIME limit? What is an appropriate value for SESSIONS_PER_USER for the monolithic "everybody connects to the database as APPUSER" application?
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of dnrg Sent: Wednesday, April 18, 2012 7:11 AM
Subject: Will CIS Oracle 11g security remediations break shrinkwrapped apps? Gotchas, lessons learned, and remediation methodologies
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 - 12:04:39 CDT