New CIS Oracle database benchmark
As you will see a simple registration is required and all three versions of the banchmark are available. You can of course get the scoring tool (available for Windows, Linux and Solaris platforms) and still run it on 11g or 9i/10g. The checks were never complete anyway as quite a lot were in the form of questions but a lot of the checks still work for the later versions of the database.
The 11g guide does not seem a massive change in terms of checks over the 9i/10g. The 9i/10g benchmark really added a lot of advanced security option checks that in my experience most sites are not using anyway (the Oracle ASO add on that is).
The 11g guides style seems better than the previous ones. The lineage / history is still strongy there though. The original benchmark (8i) was based on the book I wrote for SANS, the Oracle Security step by step guide, that is no longer available. For instance compare the SANS SCORE document with the CIS benchmark. The 11g benchmark includes a few 11g specifics such as case sensitive passwords and other 11g settings, as I said the style is better than the earlier versions, I like it.
I think that its great that there is an update to this important check list as there are not many available checklists anyway for the Oracle database. There is the SANS Step-by-step, the SANS SCORE (written by me and updated by Paul) that is essentially the checklist from the SANS step-by-step and obviously very similar to the CIS benchmark as they have the same starting points. There is the DoD STIG, some NSA document, the great, little IT Governance Institute book; there is Oracle's own checklist that gets updated from time to time but is not as detailed as the SANS SCORE or the CIS benchmark. So its great that a resource like this exists as I said there is not many check lists for Oracle databases.
I want to make two comments about checklists; they are good and bad at the same time. They are good because when we audit an Oracle database we need to have something to work to, some standards, some list of things to check. This is important, I obviously use my own checklists that are much much more detailed than any of the above lists, I check for some ten times more settings / parameters / privileges / configurations and more than these lists. My lists are internal and will stay that way, i update them probably on average on a daily basis. I have tens of thousands of lines of code implementing checks. If you want to perform an audit for yourself then you need a place to start and the lists like the CIS / SANS SCORE / SANS step-by-step are good starting points BUT (the bad bit) what we don't want to do is create the same issue as compulsive tuning disorder for security, i.e. we don't want to simply try things from a list (tip?) and see if it works, then move onto the next good thing to try. What we need is a methodology, in fact I have one, this is what I have done for years as part of my security audit service for an Oracle database. I have a methodology that allows due dilligence and repeatability but is not based on working through a set of checks. I am not going to go into great detail suffice to say that the methodology is based around understanding the data, understanding the data flow (into and out of the database), the business use of the data and then to correllate that with what is actually going on with the data and how its managed and accessed and what the privilege models are for all classes of users. Of course I also look at all the other perifery issues such as OS access. My methodology allows repeatability whilst being actually different checks for each database; well because each database is different.
So whilst i use checklists; in terms of having written extensive tools over the years i do not work through a checklist as such as each system has different requirements and security issues, each "check" can have a different risk level based on what else is going on. One site that has an Oracle database that serves up maps of the company car park that allows developer access but essentially has static data and can be rebuilt in minutes is different to a database that holds tens of thousands of credit card details where that data is held in many alternate locations because of replication to test and dev, because of mutiple storage places within the database, because of reporst that hold the credit cards, because of.......
Checklists are good BUT you also need context and brain power and probably experience to understand the core issues. As I have said many times to people, the issue is securing is about "securing the data" not necessarily about "securing Oracle". There is a subtle difference that matters!
I guess what i am saying is that they (checklists) are good, nay great in the case of the CIS benchmark, but dont just simply work though them, think about your own data, its use, its access needs, access paths to the data, who can access the data and why? base it on the data, base it on people, real people not just settings.
There has been 2 Comments posted on this article
October 25th, 2008 at 09:16 am
Pete Finnigan says:
Yes, exactly, that's what i was trying to say, perhaps not clearly enough..:-)
You are right its well out of date BUT it is a good starting point for anyone who is new to trying to secure an Oracle database. As I said above i check around 10 times more things than this guide. The first version of this guide was based on my lists but it has not progressed as far as i have in the years since it was first produced.
BUT, for me, yes its a good starting point, in fact a very good starting point, BUT for me the key issue is to consider the actual data, access to it, permissions, use of the data, how the data flows into and out of the database. In other words by all means use a check list but dont forget WHY you are auditing, it is personal to the system you are looking at not impersonal like a checklist. If a checklist is "part" of an audit thats fine, but don't lose the target!
October 25th, 2008 at 09:07 am
Pete Finnigan says:
It's a good starting point. Bad nothing more than this: A good starting point.
They missed many common problems, default configuration settings and normal misconfigurations that must be checked in order to have a "hardened" Oracle installation.
In example, the check lists for the TNS Listener are outdated and inaccurates.