Re: Will CIS Oracle 11g security remediations break shrinkwrapped apps? Gotchas, lessons learned, and remediation methodologies

The original Oracle CIS version 1.0 was based on the Oracle security step-by-step guide which Alan Paller from SANS at the time told me happened and indeed version 1 of the CIS states this is the case in the introduction. Indeed in version 1 of the CIS i get a reference in the introduction also! The close similarities can be seen in structure and checks.

The SANS step-by-step was written by me before it went out for review to the SANS list and around 20-30 people sent back comments and changes and tips.

The revoke from ALL_% was added by me though to the SANS step-by-step before it went out for review, so its probably my fault that it ended up in the CIS although I had no input to the CIS due to other commitments at the time, I was asked to be involved but couldnt do it.

In the SANS step-by-step I added targets, Windows/Unix, OS versions, Oracle versions and severity level. These are copied into CIS version 1 and the same ALL_% check is 5.14 in there

In the SANS step-by-step i allocated a severity of 4 to this check - this was defined as "LOW SECURITY RISK" and "check at installation or design / development phase and apply changes if the application / product will allow it" - the CIS loses the granularity of severity used by me. They have 1 or 2 where 1 means should be part of a minium baseline and 2 needs an experienced DBA and it may break things.

The steps you show to revoke public on all_% objects singly is fine but its for static references but when the code is sent dynamically to the database the reference does not exist. If you have access to the complete code base then maybe you can still infer the reference with code analysis but its hard. An alternate solution could be to audit the object for access over a period of time and use the results to infer references but this is also fraught.

The biggest issue is that Oracle more for packages and public uses the packages themselves and often just revoking a public privilege can still leave the system open because annother set of packages owned by SYS also could have been granted to PUBLIC. Alright the actual child package may filter the access but its still an issue that should be considered. If you look at a SYS package, UTL_FILE for instance you will find there are other SYS packages granted to PUBLIC that use it and then some that use them ad infinitum. Then there are other default users granted access to the package that may not be the same as public but their objects may be granted to public and again the same filtered (or not) access may exist. Revoking public privileges is hard hence it was severity 4 and was recommended for design stage; i.e. the developer/designer should do the work to decide what access is needed. BUT there is always the issue that Oracle itself may rely on the public grant dynamically - we cannot assume it doesnt as that would not be thorough.

so you may decide to revoke public execute from SYS.SOMEPACKAGE and locate all static referneces and fix the users grants and even fix dynamic grants but you may have a heirachy:

SYS.THIRD PACKAGE=> PUBLIC

	uses
	SYS.SOMEOTHER PACKAGE => PUBLIC
		uses
		SYS.SOMEPACKAGE => PUBLIC => revoked

So the problem in part still exists even if you do reboke from PUBLIC.

The later Oracle CIS guides have other remediation issues; i have mentioned some in my blog in the past, 3.02 springs to mind, what would chmod 0755 $ORACLE_HOME/bin/* do when there are stronger permissions on files already in there? - there are plenty of other issueslike this in the later CIS Oracle guides.

One other area of the CIS i have mentioned in the past is that it was not designed for your systems/databases/applications and hence its a general hardening standard and does not talkj about securing "your" system or "your data". I always teach in my classes that securing Oracle is about three main areas.Patches (10%) - either apply or not, its your choice!, hardening (30%) follow CIS, all, some or Stig, ISACA, SANS, various books.... but the biggest area is securtity design that should have been done day one. Know where the data is and how its accessed, who should access it, who has access to the database and systems and how and remove, reduce, regulate all of this. remembed Oracle is like perl there are many ways to do things, just accessing a peice of data could be via the base table, a sweeping priv, the export file, the audit trail, a view on the table, the SGA, redo and many more...

Hope this helps a bit?

Kind regards

Pete

dnrg wrote:
> 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:
>
> 1) 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?
>
> 2) Some vendors seem to rely on PUBLIC grants to various stock Oracle packages (DBMS_%). And Oracle 11.2.0.3.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.
>
> 3) 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:
>
> * CPU_PER_SESSION
> * PRIVATE_SGA (shared server architecture only)
> * LOGICAL_READS_PER_SESSION
> * 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)
> * IDLE_TIME
>
> Oracle's official 11gR2 Security and Performance tuning guides don't provide much, if any, insight on what values to set. Neither do many of the 3rd party Oracle Security or Performance Tuning books I've searched. Presumably because one should be well acquainted with the apps one supports and test in one's environment. And/or have a priori instincts on which values to use. However, we support many apps--often many apps on the same instance--and I'm not intimately familiar with the usage profiles for each one. Suggestions on where to start would be appreciated. Real-world examples would help a lot. Would love to know of any resources that provide general guidance in setting values for various CIS items.
>
> 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?
>
> Thanks
>
> Dana
>
> GIS for DBAs. Database Concepts for GIS.
> http://SpatialDba.com
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 

Pete Finnigan
CEO and Founder
PeteFinnigan.com Limited

Specialists in database security.

Makers of PFCLScan the database security auditing tool.
Makers of PFCLObfuscate the tool to protect IPR in your PL/SQL

If you need help to audit or secure an Oracle database, please ask for
details of our training courses and consulting services

Phone: +44 (0)1904 791188
Fax  : +44 (0)1904 791188
Mob  : +44 (0)7759 277220
email: pete_at_petefinnigan.com
site : http://www.petefinnigan.com

Registered Office: 9 Beech Grove, Acomb, York, YO26 5LD, United Kingdom
Company No       : 4664901
VAT No.          : 940668114

Please note that this email communication is intended only for the
addressee and may contain confidential or privileged information. The
contents of this email may be circulated internally within your
organisation only and may not be communicated to third parties without
the prior written permission of PeteFinnigan.com Limited.  This email is
not intended nor should it be taken to create any legal relations,
contractual or otherwise.

--
http://www.freelists.org/webpage/oracle-l