1. Database Vault Marco Alamanni
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.

2. Why Database Vault? Compliance to regulations such as Sarbanes-Oxley
(SOX), European Data Protection Directive
(95/46/EC) and Health Insurance Portability and
Accountability Act (HIPAA) 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.

3. Common Security Problems
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?
No protection from users with DBA privileges
DBA role with full access to user and business data
Only few apps built with least-privilege model:
various utilities require powerful administrator privileges
Cannot meet new compliance requirements:
separation of duty not enforced
Cannot control user creation, role assignment, etc.

4. Oracle Database Vault Goals
Integrated security framework to provide full control:
Network, users, DBA, data, roles, SQL Multi-factor Authorization and Policies across various checks
Compliance requirements:
Built-in Separation of Duty
Prevent misuse of powerful privileges
Support Database consolidation

5. Database Vault Versus VPD and OLS
Virtual Private Database (VPD):
Restricts access to certain rows for a user by modifying the WHERE clause
Oracle Label Security (OLS):
Mediates access to a given row, based on the label on the row and the security level of the user
VPD and OLS restrict access at the row level, whereas Database Vault restricts access at the object and command levels.
DBV is integrable with both VPD and OLS

6. DBV Administration Model
DV Administrative roles:
DV_SECANALYST: Reporting only
DV_ACCTMGR: Maintain db accounts/profiles (but no roles)
DV_OWNER: Big boss but cannot grant any direct access rights
DV Realm Roles:
DV_REALM_OWNER: Manages realm and associated roles
Security:
Provide separation of duties with different admin roles sys, system, sysdba and sysoper cannot grant DV_OWNER, DV_ADMIN roles

7. Separation of Duty

8. Key Components Realms Command Rules Rule sets Factors
Secure application roles

9. Realms Collections of schemas, objects and roles to be secured
Controls SELECT, DML, DDL, EXECUTE on protected objects
Prevents super user (ANY) access to security sensitive data
Does not impact direct object privileges
Realm owner determines:
Who can access the realm using system privileges
Grants/revokes applicable roles
Authorization enforced at every data object access during SQL execution

10. Default Realms
Database Vault Account Management: Protects user accounts/profiles and account management role
Data Dictionary: Protects all DBMS meta-data
Enterprise Manager: Protects all objects required by Enterprise Manager
Database Vault:
Protects all Database Vault meta-data
All object owned by Database Vault schemas
All objects owned by LBACSYS
All Security Administration Roles

11. Benefits of Data Protection with Realms
Ability to restrict access to privileged users based upon a collection of objects
Separation of Duty regarding user administration, and role management
Ability to define additional realm authorization rules based upon requirements
Limit damage even if privileges escalate to DBA
Minimize risks associated with an army of DBAs for 7 * 24 operation whether in-house, outsourced
No changes required to applications

13. Command rules

14. Command Rules Mechanics
Works very similar to DDL event triggers
Built into the SQL engine for optimization and security
Cover all basic DDL and DML commands

15. 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.

16. Rules and Rule Set

17. Factors A factor: Is an attribute of a database session
Can have a value, which can be labeled as an identity
Can easily be referenced in other Database Vault components to discern access
Can be combined with other factors to provide for multifactored authentication

18. Factor’s Identity An identity: Is a value Is associated to a factor
Has a trust level
Can have a label
Can be resolved from other factors
Can be retrieved with PL/SQL functions associated with the factor

19. Built-In Factors User Factors: Name Authentication type Session User
Network Factors: Machine name Client IP Network Protocols
Database Factors: Database IP Database Instance DatabaseHostname
Runtime Factors: Language Date Time

20. Examples of Security Policies
IP address based policy:
Allow access from intranet IP addresses
Allow access only from application servers
DBA policies:
Allow updates to the database structure only on the weekend
Allow DBA access only with PKI/Kerberos authentication
Allow DDL but only with strong authentication
Permit DDL (CREATE INDEX) but not SELECT
Implement a different set of policies for different types of DBAs
Time/date based policies
Disallow access from ad-hoc tools (SQL*plus)

21. 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

22. Deployment Flow

23. Database Vault Access Algorithm

24. Integration with OLS and VPD
Oracle Label Security: Association of factors identities with OLS labels to enforce row-level security policies
Virtual Private Database: Factors can be used in PL/SQL functions that implement VPD policies

25. PL/SQL API to Database Vault
PL/SQL interface for scriptable administration and tools
API includes:
Create, modify, and delete Database Vault components
Allow a session to define their security environment
Query the state and values of components
Administer and configure system-wide Database Vault parameters

26. Oracle Database Vault Summary
Integrated security framework to provide full control:
Control access based upon Network, users, DBA, data, roles, SQL access
Multi-factor Authorization and Policies across various checks
Baked-in Security controls
Compliance requirements:
Built-in Separation of Duty (Users mgmt, data mgmt, apps mgmt)
Prevent misuse of powerful privileges
Operational requirements:
No application changes required
Minimal Performance impact
Easy-to-use PLUS customization flexibility
Support Database consolidation

27. Credits and references
Oracle Database Vault – Under the covers, Vipin Samar, Oracle
Dividing the Keys to the Kingdom - Separation of Duties with Oracle 10g Database Vault, Eric Siglin, Oracle
Patricia Huey, Oracle Database Vault Administrator’s Guide 11g Release 2 (11.2),
Oracle, 2010