Oracle Database Firewall - What is it?

It all started with acquisition of Secerno, a database firewall vendor, in 2010. Secerno's product “DataWall” helped analyze how databases are accessed so that DBA’s can set up policies to control the access.

The database firewall has the ability to analyze SQL statements sent from database clients and determine whether to pass, block, log, alert, or substitute SQL statements, based on a defined policy. Users can set whitelist and blacklist policies to control the firewall. It can detect injected SQL’s and block them.  According to Oracle, the database firewall can do the following -

• Monitors and blocks SQL traffic on the network with white list, black list and exception list policies
• Protects against application bypass, SQL injection and similar threats
• Reports on database activity for SOX, PCI, HIPAA and other regulations, choosing from dozens of out-of-the-box reports
• Supports other Databases as well - MS SQL Server, IBM DB2 , and Sybase

The Database Firewall joins other database-security products offered by Oracle such as Oracle Advanced Security, Audit Vault, Database Vault, Secure backup etc.

Oracle Database firewall comes in 2 components:-

Database Firewall:

• Record and analyze SQL transaction requests and responses from one or more Oracle, Microsoft SQL Server, or Sybase databases, and Sybase SQL Anywhere.
• Categorizes SQL transactions
• Enforces data policies
• Enables real-time alerting and event propagation

Database Firewall Management Server:

• Aggregates SQL data from one or more Database Firewalls
• Serves as a reporting platform for business reports
• Centralizes the distribution of data control policies, but still enables the use of different policies for specific databases
• Stores and manages log files, including archiving and restoring the log files
• Remotely manages all Database Firewalls to which it connects
• Integrates with third-party applications, such as Crystal Reports

However there are some key issues that it does not address and hence would need use of other security options such as Audit Vault, VPD etc. For example, Privileged users can login to the OS directly and make local connections to the database. This bypasses the database firewall.

Pricing

The two components are priced separately.  The Database Firewall comes at a cost of $5,000 per processor and Database Firewall Management Server component is priced at $57,500 per processor. 

Oracle Critical Patch Update - October 2008

Oracle released critical patch update for October 2008 yesterday; this is the last CPU for 2008. There have been 36 new fixes across all products including 15 new security fixes for database products. Please review the following URL to see if the product you are using requires this patch or not.
http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpuoct2008.html

You can also refer to MetaLink Note 735216.1 for more details on database fixes.

11g New Features - Tablespace Encryption

You might have heard about Transparent Data Encryption or TDE in 10g; In Oracle 11g, it has been taken to a next level with "tablespace encryption". So TDE which started at column level is available at tablespace level.

How does it help?
Now instead of encrypting the columns one-by-one in a table or for a set of tables, you can simply put all tables which need to be encrypted in a single tablespace and encrypt it.

How to do it?
- Create and open the wallet
- Create tablespace with encryption property

CREATE TABLESPACE encrypt_tbsp
DATAFILE '/oradata/encrypt_tbsp01.dbf'
SIZE 100M
ENCRYPTION
DEFAULT STORAGE(ENCRYPT);

- Create tables in the encrypted tablespace

How to find if tablespace is encrypted or not?
- A new column "ENCRYPTED" has been added to DBA_TABLESPACES which will indicate if the tablespace is encrypted or not.
- Query a new dynamic performance view V$ENCRYPTED_TABLESPACES for encrypted tablespaces.

Do I need to do anything special to access data from a encrypted tablespace?
Not really, you continue to access data as usual BUT the wallet must be open. No modification whatsoever is required for the code/SQL to access data from encrypted tablespace.

What is supported and not supported with encrypted tablespaces?
Supported
- Move table back and forth between encrypted tablespace and non-encrypted tablespace
- Datapump is supported to export/import encrypted content/tablespaces
- Transportable tablespace is supported using datapump

Not Supported
- Tablespace encryption cannot be used for SYSTEM, SYSAUX, UNDO and TEMP tablespaces
- Existing tablespace cannot be encrypted
- Traditional export/import utilities for encrypted content

Though I have not been able to create an encrypted tablespace but still wanted to share this information. I will try to post my learnings from the exercise later. Hope this is useful. NJoy! encrypting and do let me know if I have missed out any key messaging herein.

References:- Oracle® Database Advanced Security Administrator's Guide 11g Release 1 (11.1) Part Number B28530-02

11g New Features - Case-sensitive passwords

Probably a long overdue feature...though one could have implemented the same using password verify function in earlier releases but it was necessitated to be in compliance with industry wide Data security standards. Starting 11g case sensitive passwords automatically enforced.

Here is how to implement case-sensitive passwords feature :-

SIPRAS@11glab> create user TESTUSR identified by TESTUSR;

User created.

SIPRAS@11glab> grant create session to TESTUSR;

Grant succeeded.

SIPRAS@11glab> conn testusr/testusr@11glab
ERROR:
ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.
@> conn testusr/TESTUSR@11glab
Connected.
TESTUSR@11glab>

See the difference - since the user was created with an upper case password, it did not allow lower case password while connecting to "TESTUSR". Had it been 10g, you would easily got connected. So now, "TESTUSR", "testusr" and "TestUsr" are different passwords.

However, Oracle has also provided an initialization parameter to disable case-sensitive passwords i.e. going back to old way of 10g and prior versions.

SIPRAS@11glab> show parameter SEC_CASE_SENSITIVE_LOGON

NAME TYPE VALUE
------------------------------------ ----------- ---------
sec_case_sensitive_logon boolean TRUE

SIPRAS@11glab> ALTER SYSTEM set SEC_CASE_SENSITIVE_LOGON=FALSE scope=both;

System altered.

SIPRAS@11glab> show parameter SEC_CASE_SENSITIVE_LOGON

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
sec_case_sensitive_logon boolean FALSE

And now see the difference...

SIPRAS@11glab> conn testusr/testusr@11glab
Connected.

TESTUSR@11glab> conn testusr/TESTUSR@11glab
Connected.
TESTUSR@11glab>

So it would connect irrespective of case. A new column "PASSWORD_VERSIONS" has been added to "DBA_USERS" view to indicate database version in which the password was created or changed.

SIPRAS@11glab> select username,PASSWORD_VERSIONS from dba_users;

USERNAME PASSWORD
------------------------------ --------
.....
SCOTT 10G 11G
TESTUSR 10G 11G

However, I am not able to find answer as to why a user created in 11g has both "10G" and "11G" in PASSWORD_VERSIONS column. According to the documentation if a database was migrated from 10g then it would have both "10G", "11G" in it which is not true in my case..

One can also enforce case-sensitive passwords for SYSDBA users. Use "ignorecase" argument while creating password files using "ORAPWD" utility. Default values for "ignorecase" is "n", and you can set it to "y" to enable case-sensitive passwords.

e.g. $orapwd file=orapw entries=5 ignorecase=y

So if you plan to upgrade to 11g then make sure you change passwords to adhere to case-sensitivity and ensure that you change your scripts which have inconsistent password cases too.

Reference : Oracle® Database Security Guide 11g Release 1 (11.1) Part Number B28531-04