We have also just added the dates for the class in Denver Collorado in June. I have also spent quite a lot of time on short consulting engagements around Oracle security reviews, audits and also recently quite a lot of design reviews and design work - again all around Oracle security. Things have been quite mad for me which is a pity for you guys as I have not had time to blog.....
Tomorrow 9th March at 10am UK time and also this coming Thursday, 11th March at 1pm EST (6pm UK time) I am giving a webinar hosted by Sentrigo. The talk is focused on the The right way to secure your data in an Oracle database; this is about starting at the right place and concentrating on the access models implemented in your database, relating these models to real people or job titles or processes and then to the actual data (all of it). If you would like to hear me talk about the methodologies I use to secure Oracle (and hear my voice if you are over the pond, as I don't speak in the US/Canada very often) or even ask me a question via the Q&A at the end then you can register at these two URL's:
Tuesday, March 9 10-11am GMT (England Time)
Thursday, March 11 01-02pm EST (NA Eastern Time)
On the subject of Sentrigo, I am also writing a short article about using Sentrigo's Hedgehog IDS/IPS product that will follow on from the detailed article i did in 2008 - "Sentrigo Hedgehog". This article is going to cover some example uses of the product. Watch out for it; coming soon!
I also came across Simon Fletchers blog a week or so ago whilst on the train when i was looking for something in google for a client and then today I noticed that Paul also mentioned Simons blog in his. Simon has started a blog about Oracle security called "Fifteen Twenty One". I have of course added his blog feed to my Oracle blogs aggregator. There are not many posts there yet (3 as i write this) but what is there is good so its going to be worth following.
I actually found one of his blog posts when searching but went for a look and found that his most recent post is about something I was dicussing recently with a client. This discussion was about the issue of the SQL92_SECURITY parameter and why it doesn't seem to work in some circumstances. OK, doesnt seem to work is unfair, it is not a bug but there is a couple of issues that you should be aware of if you think of using it.
I have been checking this parameter for many years and wrote a script in 2003 that tests for tables that have delete, update privileges and no select privilege so that I could advise clients to change this parameter as part of our security audits. I found that if you have sql92_security set to TRUE
Then if I have a table that has just DELETE privilege granted to it as follows:
As you can see the user SQL92 can DELETE but nothing else; then i cannot DELETE:
OK, so sql92_security does what it says on the tin but it does now stop DELETE grants from totally working, i.e. I can still delete but not specific records:
OK, if we now look at all the details for the sql92_security parameter via my check_parameter.sql is a one way to do it:
OK, so Oracle explains this in the comment, SELECT privileges are required only for searched update or delete. So being able to delete all rows is allowed. What Simon showed in his blog post to locate records via inference is not possible (which is the intended use of this parameter) but deleteing is not totally stopped. You should be aware of this.
A more subtle issue is the fact that sql92_security prohibits a DELETE or UPDATE from working if there is no read privileges .... what if there is a read privilege but via a different route....
The above output shows that the user SQL92 has the DELETE privilege against the view CB1 but also inherits the PUBLIC SELECT against the base table CREDIT_CARD.
Would you (as a designer of the application) want DELETE to then work instead of being blocked? As it stands its clearly not a bug as the parameter stops a DELETE without a READ on the SAME VIEW or TABLE it should work this way in my view. But if you have enforced this sql92_security parameter to TRUE expecting that it will stop deletes with no select - then fine - but if you expect reverse logic then beware.
For my sample view CB1 I have read privileges on the table its a CTAS on, so i can read the data but not read via the view and i have only DELETE privileges on the view. If I wanted to turn on SQL92_SECURITY and I checked the privileges I would find CB1 has only DELETE and would think about adding SELECT privileges to this view (increasing the privilege count), I would not find that I can see the data via ORABLOG.CREDIT_CARD (the base table) simply by searching for tables/views that do not have SELECT. I guess what I am getting at is maybe the solution isn't (in this example) to grant SELECT to SQL92 on ORABLOG.CB1 but maybe to remove SELECT on ORABLOG.CREDIT_CARD as well or maybe to add DELETE to ORABLOG.CREDIT_CARD for SQL92 and remove it from CB1 - bearing in mind we must know which columns are exposed and also how the tables and views are used in the application....
Finally there is the subtle problem of potential privilege. When I do an audit I also check for potential privileges and in the case of suggesting to a client to turn on sql92_security we must be also aware of the potential for issues in the future by analysing who may grant privileges that may break because of this parameter.