Pete Finnigan's Oracle Security Weblog

Lindsay passed me a link to an article about the recent Oracle Firewall public release and also the recent partnering with F5.

The part that interests me most is the Oracle firewall and the fact that Oracle has stated:

"..which together it claims will supersede the database activity monitoring (DAM) market..."

Of course the vendors of DAM products completely disagree with this statement and to be honest so do I. A firewall is not activity monitoring and as stated in the article most of the DAM product players support IDS/IPS and also audit trail facilities. So a database firewall is only part of a DAM product and a DAM product provides a better all round solution than just a firewall. Its a subset; Are they (Oracle) suggesting that only a firewall is needed? and that IDS and Audit are not needed (maybe outside of the database? - or maybe they feel audit vault or core audit features satisfies that part of the DAM solution), I don't know of course I can only speculate.

The Secerno product had a different USP than the other main players (Imperva, Guardium, Sentrigo and AppSec) of this market in that they categorise SQL and PL/SQL into good or bad. This was not a new idea as the Chakra product from OR Solutions (I think now Warevalley) did something along the same lines nearly ten years ago.

The problem with network based solutions is that they miss what doesnt happen over the network and also in some cases what does. Imagine you are specifically interested to understand access to your credit card details and you want to trap all access. If the access is naked SQL then its seen; if the access is through a package then its hidden. the argument would be that if good access is always through packages so this is logged and OK and if an additonal direct access occurs it would be captured because its not normal or indeed a different PL/SQL access. If the package is manipulated at the code level to do something different AND the package call looks exactly the same then it would class bad as good. I accept that the "manipulation" itself could be captured but what if its not..... or its not correllated....

The second part of this would be if "good SQL" is used for "bad SQL" purposes. Imagine Mrs Smith loads new loan requests in the system all day every day and Mrs Jones authorises them from her queue. The firewall would learn good and bad SQL. What about when Mrs Smith loads a fraudulent loan application (is it good or bad - the SQL looks the same) and even authorises it as Mrs Jones (either with her knowledge or without if she accesses her terminal). Bad would look like good....

Seems like i am picking on Secerno's product but all of the products in this space have issues which I think is inherent in the network based solution. Some of the players have also implemented agents or direct database connections to bridge the gap between network and direct database access. As the article also agrees another flaw is that direct super user or indeed any other non network based connection will not be captured. Sentrigo's Hedgehog is unique in that it attaches to the database server outside of the database so captures net derived traffic, recursive traffic and also local traffic. The main net based players try to resolve the same issue with agents as stated.

Is classifying SQL a good idea? not sure, its different and not signature based or just based one exploits so its a valid idea and does indeed help in assessing the "customer" portion of the design. The issues around the security of a database can be grouped into three main groups; 1) Security bugs - apply patches, generally exploits are published for these. 2) hardening, review and take advice from hardening guides such as CIS, SANS Step-by-Step, SCORE, Dod Stig, ISACA.., there are also a number of exploits published for exploiting insecure configurations and 3) customer design, i.e. design access, security, DBA/privilege access, SoD, CoI, preferences, settings etc and more, generally not many exploits published here over the years but these are the easiest to exploit as hacker techniques are not needed, just abuse the design implemented via SQL, application and more.

Data security is about securing the "data" not the software; we need to use the software along with actual process and management and procedure to secure the data BUT the start point is the data. A firewall is still a valid solution; indeed most companies do not place a firewall between their database and the user community but do so to protect from the outside world, which obviously doesnt stop the user community. The general DMZ/Firewall solution is not valid as the bigger risk is access to the data from inside the organisation. Start with the data; if you let the data outside of the database then no database security will ever work!

Also factor in identity as we must know "who" did it and when. The values used in the database to identifty the session can almost exclusively not be relied upon. If you take Mrs Smith and Mrs Jones above then Mrs Smith could be Mrs Jones or vice versa from their own terminals or anywhere using a spoofing tool:

C:\>java DBC 1 0

SQL*Client : Version 0.1 Very Alpha

Copyright (c) 2010 PeteFinnigan.com Limited All Rights Reserved

PFCL> set program "My Client" ;
PFCL> set osuser "Oracle" ;
PFCL> connect orascan/orascan@127.0.0.1:1521:ora11g;
...
PFCL> exec print_table('select osuser,module,program from v$session where audsid=1856376');
OSUSER : Oracle
MODULE : My Client
PROGRAM : My Client
-----------------

....

I have said previously use a firewall to prevent access to the database in the first place (other than authorised users), fix the weak guessable passwords, add password management, include auditing for accountability. All of these are very valid and a firewall is a good idea; an Oracle specific firewall seems also like it is a good idea.

The argument in the article seems to be the supposition that an Oracle firewall will replace the need for DAM products. I don't think this is valid because the DAM products provide the same services if operated as an IPS which all the competition can do. Also the DAM products additionally provide audit trails and privileged user access audit and blocking/detection. The core database can of course also be used to provide accountability and auditing. In summary its a complex area and its good that some controversy has been added. This may drive awareness and bring more people to the point of needing and implementing data security or buying third party products or Oracle's own. I read some time ago that the DAM market was not massive; given that two big players are now involved Oracle and IBM then its a good thing overall and should drive awareness and the increasing adoption. Companies do need to be realising that data security is necessary to protect their data from being another statistic in someone elses news channel. Is it controvery or marketing?