Call: +44 (0)1904 557620 Call

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "Techa Kucha In York"] [Next entry: "Oracle Security Training in the UK"]

Oracle Database Firewall Controversy

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 Limited All Rights Reserved

PFCL> set program "My Client" ;
PFCL> set osuser "Oracle" ;
PFCL> connect orascan/orascan@;
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?

There has been 7 Comments posted on this article

February 21st, 2011 at 04:36 pm

Pete Finnigan says:

Hi! Pete I'm Agree with you, I think DB's Firewalls does not replace DAM, but it seems that Oracle has also benefits DAM, will have to investigate more about this new product - Regards.

February 21st, 2011 at 07:45 pm

Pete Finnigan says:

Hi Pete

I tuned in to the ISSA webinar entitled "Databases Under Attack!" which was delivered on Feb 8 by
Roxana Bradescu, Sr. Director, Database Security Product Marketing, Oracle

The talk was an introduction to how all the various Oracle products and add-ons can be used to secure the database and it included their new Oracle Database Firewall product.

From my recollection of the talk, Roxana's analogy was that the new Database Firewall can act as the "guard outside the door" to monitor / block the traffic coming into the database. Oracle Audit Vault is the "camera inside the door" that monitors and records what goes on inside the database.
Oracle Total Recall (11g) can be used to track changes to sensitive data and is good for forensics and recovery. Oracle Database Vault will give preventative control, access control and separation of duties on database. Roxana then went on to briefly mentioned label security, Oracle Advanced Security and Oracle Configuration Management

I would agree with you and the other DAM vendors that the Oracle Database Firewall is not a replacement for DAM. It can only monitor the traffic that comes in to the database over the network and at that cannot function if the network traffic is encrypted ( So if you are already using Oracle Advanced Security network encryption then Oracle Database Firewall will not be of any use to you.

All in all, it seems to me like a standalone DAM tool is neater solution that deploying the Oracle Database Firewall and then having to deploy a number of other Oracle products and add-ons to compensate for its shortcomings.

February 21st, 2011 at 07:55 pm

Pete Finnigan says:

Thanks for your comments guys.

@Michael: Thanks for the more detail. I assumed that was Oracle's stance, that other products provided the other features such as controls, identity, audit, encryption.

Good point on the encrypted traffic. I have not read anything about Oracle's version of Secerno to see if they have solved this issue.

February 22nd, 2011 at 06:37 pm

Pete Finnigan says:

Hi Pete

Correct, the impression I got from the webcast was that different Oracle product can be combined to give different levels of protection against various levels of attack.

In regard to encrypted traffic, the Oracle Database Firewall FAQ says that "Future releases of Oracle Database Firewall will fully support Oracle Advanced Security Option for in transit encrypted data."


February 22nd, 2011 at 06:43 pm

Pete Finnigan says:

The Oracle® Database Firewall Security Management Guide Release 5.0 Part Number E18696-02 has following in chapter 3 "Auditing Stored Procedures and Roles":

You can audit and approve changes to stored procedures and user roles in the databases on a specified database server. Oracle Database Firewall connects to the database server at scheduled intervals and determines which changes or additions (if any) have been made to stored procedures. Stored procedure auditing and user role auditing are supported for Oracle, Microsoft SQL Server, Sybase ASE, Sybase SQL Anywhere, and IBM DB2 SQL (Linux, UNIX, and Microsoft Windows) databases. Before you can audit stored procedures and roles, you must configure the Database Firewall-protected database to enable stored procedure and role auditing.

Setting Stored Procedure Auditing User Permissions on Oracle Databases:
To set up the user account for Oracle databases (all releases later than Oracle Database 8i):

1.From the Oracle Database Firewall Product CD (Oracle Database Firewall Utilities 5.0), copy the database directory to the server where you plan to run the scripts.

2.On this server, go to the database/spa directory and uncompress the oracle compressed file, preferably into a directory called oracle.

3.Go to this oracle directory and review the uncompressed files so you will understand the privileges the users in these scripts will have.

4.Log in to Oracle Database as a user who has privileges to create users and set user permissions.

For example:

sqlplus sys/as sysdba
Enter password: password
If the database has been enabled with Oracle Database Vault, then log in as a user who has been granted the DV_ACCTMGR role.

5.Run the spa_setup script.

For example:

SQL> @spa_setup.sql
The script creates a user account for stored procedure auditing and grants the following privileges to the account:


•SELECT on sys.dba_objects and sys.dba_source

There's a similar chapter on auditing Roles. So Oracle does attempt to prevent un-noticed tampering with stored procedures. But I am still investigating..

February 22nd, 2011 at 07:04 pm

Pete Finnigan says:

..and then enable Stored Procedure Auditing on the Database Firewall in the standalone Database Firewall or Management Server Administration Console..

February 23rd, 2011 at 09:43 am

Pete Finnigan says:

Thanks for the comment Andre; its assessing change presumably in a similar manner to Guardium and Imperva but my main point was about actual activity. If a package were manipulated and it now does extra work in accessing tables (data) it should not access. then that access would be missed as the call to the procedure that does the access is the same before and after the change. If Secerno accesses the database on a scheduled basis to see what objects have changed then there are holes in the security from the time of change to the next scheduled check.