Database Vault Welcome, today I’d like to present an overview of the latest security product from Oracle – Database Vault. We announced this new product in late April at the huge Oracle user group conference called Collaborate 06 in Nashville, TN. You may have seen some press releases for Oracle and our partners around this exciting new product.

Why Database Vault? Protecting Access to Application Data “Legal says our DBA should not be able to read financial records, but the DBA needs to access the database to do her job. What do we do?” “Our auditors require that we separate account creation from granting privileges to accounts.” “No user should be able to by-pass our application to access information in the database directly.” “New DBAs should not be able to make database changes without a senior DBA being present.”

Why Database Vault? Regulations such as Sarbanes-Oxley (SOX) and Graham-Leach Bliley Act (GLBA), and Basel II require Strong Internal Controls and Separation of Duty Internal threats are a much bigger concern today require enforcement of operational security policies - Who, When, Where can data be accessed? Database consolidation strategy requires preventive measures against access to application data by Powerful (DBA) users Database Vault is designed to address what customers have told us are some of their most pressing security related business problems. At Oracle Headquarters in California, we frequently get the opportunity to talk to customers from around the world and virtually every industry imaginable and these are business problems seem to resonate with virtually every customer. I’m sure you’ve all heard the phrase “regulatory compliance”, who hasn’t, it’s certainly being used a lot. I think one of the biggest benefits of regulatory compliance has been awareness, it’s really forced customers to take a long hard look at their business practices. Two of the common themes in many regulations are strong internal controls and separation of duty. Database Vault provides the technology to address these two security problems. In addition, customers are much more concerned about the internal threat today. I don’t mean to say that everyone’s DBA is up to no good, but rather customers are looking for preventative measures to put in place. They want the ability to enforce operational policies on who, when and where data can be accessed, Another common security problem is the powerful DBA. Most applications out there today were not designed with the principle of least privilege – meaning that the application owner only has the minimum privileges necessary. In fact, it’s exactly the opposite. Database Vault provides the ability to restrict the powerful application owners and DBA which reside in a consolidated database environment.

Common Security Problems On Financial Data I have requirements around SOX and PCI, how can I prevent my DBA from looking at the application data, including Credit Cards and Personal Information? How can I prevent un-authorized modifications to my application and database? Tool

Oracle Database Vault Feature Overview Controls on privileged users Restrict privileged users from accessing application data Enforces separation of duty Real time access controls Controls access based on IP address, authentication method, time of day,…. Transparency No changes to applications required

Database Vault True “Separation of Duty” Protect any database object from any users (realm) Function, job, package, synonym, trigger, view, table Prevent users from viewing application data Prevent DBA users from creating powerful users Any user from executing a command (command rule) Alter table, drop user, insert, create index, analyze Protect object from schema owner HR user cannot modify HR objects Leverage sys_context (multi-factor authorization) Only modify database structure from local IP Only accept DML statement based on date or time Leverage built-in or user defined factors Machine, User, Domain, Language, Protocol, etc. Oracle Database Vault provides 6 key pieces of security functionality. The concept of a REALM is the most important. You can think of a REALM as a protection boundary or firewall you define inside the database. Realms are easy to define and once in place, they prevent powerful users such as the DBA from getting at application data. Multi-Factor Authorization is another extremely important addition provided by Database Vault. Some of you may be familiar with the term multi-factor authentication. Multi-factor authorization is similar in that it enables a series of security checks prior to giving access to a database, application or application table. For example, you can tell Database Vault to check things like IP address and time of day prior before giving access to the database, application or a specific Realm, it’s very flexible. The security behind Database Vault is managed by a security account and not the Oracle DBA or SYSDBA, this provides separation of duty, meaning the DBA isn’t the one who controls the REALMS, FACTORS and so forth. Command rules are another important addition, this enables rules to be associated with database commands, the rule is evaluated prior to allowing the command to execute, a powerful feature. Oracle Database Vault also provides auditing, so that you can track when a REALM has blocked someone from attempting to access an application. In addition, over 3 dozen security related reports are provided out-of-the-box.

Command Rule Flexibility Alter Database Alter Database Alter Table Alter Function Audit Alter Tablespace Alter Package Body Alter Procedure Alter Profile Alter Session Alter System Alter Synonym Alter Table Alter Trigger Alter User Password Alter Tablespace Alter View Change Password Connect Comment Create Function Create Index Create Package Create Database Link Create Procedure Create Role Create Package Body Create User Create View Create Table Grant Insert Noaudit Rename Lock Table Create Tablespace Create Trigger Truncate Table Update Insert Delete Execute Select Earlier we showed how a command rule can be associated with the Alter System command. Here’s a list of some of the other commands which can have rules associated. As you can see the list is quite extensive.

Built-In Factors Authentication Method Session User Client IP Database Name Domain Machine Database Domain Database Instance Network Protocol Database IP Enterprise Identity Proxy Enterprise Identity Language Database Hostname Date Time Here’s a list of the built-in Database Vault factors that can be used in conjunction with Database Vault Realms and Command Rules. You can also add your own factors through the GUI. Authentication Method: Returns the method of authentication. Password-authenticated enterprise user, local database user, or SYSDBA or SYSOPER using Password File or proxy with username using password returns PASSWORD. Kerberos-authenticated enterprise or external user returns KERBEROS. SSL-authenticated enterprise or external user returns SSL. Radius-authenticated external user returns RADIUS. OS-authenticated external user or SYSDBA or SYSOPER returns OS. DCE-authenticated external user returns DCE. Proxy with certificate, DN, or username without using password returns NONE. You can use IDENTIFICATION_TYPE to distinguish between external and enterprise users when the authentication method is Password, Kerberos, or SSL. Session User:For enterprises users, returns the schema. Database user name by which the current user is authenticated. This value remains the same throughout the duration of the session. Database Domain: Domain of the database as specified in the DB_DOMAIN initialization parameter. Machine: Provides the machine name for the current session Enterprise Identity: The user's enterprise-wide identity. For enterprise users this returns the Oracle Internet Directory DN. For external this user returns the external identity (Kerberos principal name, Radius and DCE schema names, OS user name, Certificate DN). For local users and SYSDBA and SYSOPER logins returns NULL. The value of the attribute differs by proxy method. For a proxy with DN, the Oracle Internet Directory DN of the client. For a proxy with certificate, the certificate DN of the client for external users; the Oracle Internet Directory DN for global users. For a proxy with username, the Oracle Internet Directory DN if the client is an enterprise users; NULL if the client is a local database user. Proxy Enterprise Identity: Returns the Oracle Internet Directory DN when the proxy user is an enterprise user. * Additional factors can be defined

Web Based Administrative Interface Web Based Management Realms Rules Factors Reports Dashboard This is the web based administration console. Please note that the product name is “Database Vault” and not “Data Vault”. The screen shots were taken before the final product name was determined. From here you can manage Realms, Factors, Rule Sets, Command Rules as well as integration points with Oracle Label Security. You also have access two more than 3 dozen security related reports via the two report tabs. The monitor tab provides some graphs as well as direct access to some reports. This tab will be enhanced as we move forward with future releases.

Oracle Database Vault Reports Database Vault Reporting Over 3 dozen security reports for compliance Audit violation attempts Realm, Rule and Factor Reports System and Public Privileges Here’s a more detailed look at the Database Vault specific reports tab. You can see a Realm Audit report selection toward the bottom. This report will display audit records where the Realm has blocked an action.

Oracle Database Vault Realms Database DBA views HR data select * from HR.emp DBA Compliance and protection from insiders HR DBA HR HR Realm HR HR DBA views Fin. data Eliminates security risks from server consolidation Fin FIN DBA Let’s first take a look at Database Vault Realms. Here we have a database, let’s assume that this is a consolidated database. As you would expect you have the DBA as well as several other applications, here we’ve included an HR and Financial application. One of the problems faced in this type of situation is that the DBA can, if he or she wished to do so, use their powerful privileges to take a look at application data. Even the possibility of this happening can be prevented using Database Vault Realms. Simply place a Realm around the HR application and the DBA will no longer be able to use his powerful privileges to access the application. The other situation is one I eluded to earlier. Application owners tend to have very powerful privileges. In a consolidated environment, it’s very likely that you’ll have more than one application and thus several powerful users in the database above and beyond the DBA. In this example, it’s possible for the HR DBA to look at the Financial application data. Obviously this wouldn’t be a good situation, especially if it was during the financial reporting quite period. Using a Database Vault Realm, the Financial application can be protected from powerful application owners. Summary, Realms can be easily applied to existing applications and with minimal performance impact. Fin Realm Fin Realms can be easily applied to existing applications with minimal performance impact

Oracle Database Vault Rules & Multi-factor Authorization Database DBA attempts remote “alter system” alter system……. DBA Rule based on IP Address blocks action create … HR DBA performs unauthorized actions during production 3pm Monday HR Realm HR Rule based on Date and Time blocks action HR HR DBA In addition, to Realms, Database Vault also delivers Command Rules and Multi-Factor Authorization. Command Rules provide the ability to instruct the database to evaluate conditions prior to allowing a database command to execute. Combined with Multi-Factor authorization, this provides an extremely powerful tool to limit and restrict access to databases and applications. Let’s take another example. Here I’m showing a database with a single application and the DBA. One of the common problems customers have faced from a compliance perspective is unauthorized activity in the database. This may mean that additional database accounts or application tables have been created. This can raise alarms with auditors because it can point toward lax internal controls. Using a command rule, Database Vault gives the ability to control the conditions under which a command is allowed to execute. For example, a command rule can be associated with the database “Alter System….” command. Perhaps your policy states that all ‘alter system’ commands have to be executed from a connection originating from the server hosting the database. The command rule can check the IP address and reject the command. So the rule based on IP address blocks the action. Perhaps a powerful application DBA creates a new table, command rules combined with multi-factor authorization can block this action. In summary, command rules and multi-factor provide the flexibility to meet operational security requirements. Factors and Command Rules provide flexible and adaptable security controls

Oracle System User Blocked

Database Vault Rules and Factors Block(Remote Intranet Connection)

Oracle secured DB environment

Hands-on Resources Oracle Database Vault: http://www.oracle.com/technetwork/database/options/database-vault/index.html Oracle Security Overview: http://www.oracle.com/technology/deploy/security/database-security/index.html Lab3-1: Protect Application Data from DBA and Privileged Users (no submission) http://st-curriculum.oracle.com/obe/db/11g/r1/prod/security/datavault/datavault.htm Lab3-2: Restrict DBA commands based on IP address (no submission) http://st-curriculum.oracle.com/obe/db/11g/r1/prod/security/datavault/datavault2.htm

Oracle Database Vault Secured Installation Disallows connections with SYSDBA Will affect Oracle Data Guard and Data Guard Broker command line utilities Oracle Recovery Manager command line utility Oracle Real Application Clusters svrctl utility Oracle ASM command line utilities Custom DBA scripts Can be re-enabled with the orapwd utility Enables password file and Turns off OS authentication (e.g. sqlplus “/” as SYSDBA)

Oracle Database Vault Secured Installation Requires Oracle Label Security version 10.2.0.2 Requires one of the following: Enterprise Manager 10.2.0.2 10g Application Server Containers for J2EE (OC4J) Cannot be installed into an Oracle home that contains an ASM instance Best practice is to create a database vault owner and database vault manager Requires 270 MB of disk space for DB Vault software Requires 400 MB of /tmp disk space OS authentication is turned off for all databases in the Oracle home Database vault can be enabled for each database in the Oracle home (optional)