PeteFinnigan.com Limited Products, Services, Training and Information

Database Vault

Home/Database Vault

Oracle Database Vault in Real Life

This is my presentation to the UKOUG last December on Oracle Database Vault in Real Life

Slide 1 - Oracle Database Vault in Real Life

Slide 2 - Legal notice

Oracle Database Vault in Real Life

Published by
PeteFinnigan.com Limited
Tower Court
3 Oakdale Road
York
England, YO30 4XL

Copyright © 2025 by PeteFinnigan.com Limited

No part of this publication may be stored in a retrieval system, reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, scanning, recording, or otherwise except as permitted by local statutory law, without the prior written permission of the publisher. In particular this material may not be used to provide training of any type or method. This material may not be translated into any other language or used in any translated form to provide training. Requests for permission should be addressed to the above registered address of PeteFinnigan.com Limited in writing.

Limit of Liability / Disclaimer of warranty. This information contained in this course and this material is distributed on an “as-is” basis without warranty. Whilst every precaution has been taken in the preparation of this material, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions or guidance contained within this course.

TradeMarks. Many of the designations used by manufacturers and resellers to distinguish their products are claimed as trademarks. Linux is a trademark of Linus Torvalds, Oracle is a trademark of Oracle Corporation. All other trademarks are the property of their respective owners. All other product names or services identified throughout the course material are used in an editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this course.

Slide 3 - Background

Pete Finnigan – Background, Who Am I?

Oracle Security specialist and researcher
CEO and founder of PeteFinnigan.com Limited in February 2003
Writer of the longest running Oracle security blog
Author of the Oracle Security step-by-step guide and “Oracle Expert Practices”, “Oracle Incident Response and Forensics” books
Oracle ACE for security
Member of the OakTable, SYM 42
Speaker at various conferences UKOUG, PSOUG, BlackHat, more..
Published many times, see http://www.petefinnigan.com for links

Slide 4 - Agenda

Securing Oracle
Three elements to secure
Do you want to go further?
Do it the hard way
Use Database Vault to add better security
Report and verify

Slide 5 - Securing Oracle

Securing Oracle

Slide 6 - Secure Data

The focus for us is to secure data and not “Oracle Security”
We must use features of Oracle to secure our data BUT simply following a check list
Securing to a list does not work as we must secure based on OUR data and OUR use of that data
We will keep this talk fairly high level

Slide 7 - Three Elements to Secure

Three Elements to Secure

Slide 8 - Compartmentalise Data Security?

Compartmentalise Data Security?

Slide 9 - Splitting Up Data Security in Oracle

(1) - 10% - Patching
(2) - 30% - Hardening
(3) - 60% - Data Security design
Data design
(1) - Access controls
(2) - User security
(3) - Data access controls
Audit trails
Secure coding
Context based security
Either products from Oracle such as DV, OLS, VPD, TSDP,…
Home grown

Slide 10 - Context Based Security

Enhance other layers of security
Allows detailed level security
Allow pete to access credit cards from JDE and only from the office and on a PC in the accounts department
How?
Limit the database user, limit the application, limit the location, Limit by machine domain, limit by application roles of context / info / etc,

Slide 11 - Do you Want to go Further?

Do you Want to go Further?

Slide 12 - We Want to Achieve Better Security

We must use context
That context must be secure and trusted
Can do some things with VPD, …
Can do by hand with
PL/SQL code, triggers, secure application roles, views and more
Why is this an issue to do by hand?
Lots of code, Design the framework yourself
Can be bypassed as Oracle is complex

Slide 13 - Do it the Hard Way

Do it the Hard Way

Slide 14 - Context: View Based Security

We can create VIEW BASED security to limit access to read data
A PL/SQL function allows tests to be made to check whether access is allowed or not
We could also check in this PL/SQL whether the privilege used is SELECT ANY by checking the users actual rights
This can block some ANY privileges
BUT system ANY for select can access the base table. Solution:
Revoke system ANY except for sys
Block SYSDBA access – The first versions of DV did this

Slide 15 - Context: DML Based Security

We can apply the same “Realm” type ideas to block DML with triggers
This cannot be overridden as this is added to the base table and this is not view based
Again we could check for System ANY in the PL/SQL code by looking at the callers rights
We can also make a mandatory realm – in part at least with context based code

Slide 16 - Command Rule: Block SQL*Plus - Webserver

We can perfectly replicate the protection we have in DV with a logon trigger
We can also use valid node checking but this is not granular
In this example the httpd still works but SQL*Plus from the webserver is blocked

Slide 17 - Use Database Vault to Add Better Security

Use Database Vault to Add Better Security

Slide 18 - What Is Database Vault?

Declarative security framework to allow fine grained access to database objects (tables, views, procedures…) grouped into realms
Literally unlimited context based security rules can be added to control access to any (well almost any) database object or command
Default use is to protect against SYSTEM ANY privileges
Because it is “built-in” to the database kernel it is harder to bypass
Pre-built shipped settings protect risky parameter changes and the data dictionary and more
Separation of duties are added by default by creation of a security administrator, user account manager and vault owner
SYS, SYSTEM and DBA are restricted in value
Most components / features have protections that can be used

Slide 19 - The Main DV Components

Factors
Individual elements to use in rules (e.g. IP Address)
Rules
True/False questions for the database
Rule Sets
Groups of rules (Also results in True/False – with AND/OR)
Realms
Protect database objects (uses rules, factors)
Command Rules
Protect access to SQL commands (e.g. CONNECT) (uses rules, factors)
Secure Application Roles (SAR)
Protective access to enable a role (uses rules, factors)

Slide 20 - Hacking The Sample Database Before DV

As an un-athenticated web user

Slide 21 - Hacking The Sample Database After DV OOTB

As an un-athenticated web user

Same Hack as previous with no DV, same result

Slide 22 - DV Add A Realm – Hack Again

Create a realm to effectively add the ORABLOG schema objects to that realm and so that System ANY is not able to be used on ORABLOG objects by any other user.
Do the same hacks as before still work?
The applications (Orablog and BOF) still work correctly even with the realm in place

Slide 23 - Hacking The Sample Database With Realm

As an un-athenticated web user

Same Hack as previous tests, same result!!

Slide 24 - Add Mandatory Realm – Hack Again

Hmmm, the aps are now broken; we need to add ORABLOG to the realm but it defeats the object

Slide 25 - Add Mandatory Realm – Fix The Realm Auth

Add Mandatory Realm – Fix The Realm Auth

Slide 26 - Hacking The Sample Database With Mandatory Realm

As an un-athenticated web user

Same Hack as previous tests, same result!!

Slide 27 - DV Command Rule – Create the Rules

DV Command Rule – Create the Rules

Slide 28 - DV Command Rule – Code Continued

DV Command Rule – Code Continued

Slide 29 - DV Command Rule - Results

The rules are not perfect as we have implemented properly only for Orablog and not BOF but BOF has no client tools installed
The client_program_name is not set from the server so we have used instead Module – but it would be better to use the hash
Implementing factors, rules, rule sets and command rules or rule sets for realms is a large task when a lot of controls are needed

Slide 30 - Do Not Use DV

Don’t use Database Vault if you do not have normal database security
Even then
Use standard database security first
Achieve some of DV with standard features – i.e. do not use DBA, SYS and SYSTEM, revokes, %ANY% remove,…
Secure DV
Then use DV to enhance existing data security

Slide 31 - TDE Would Benefit from Database Vault

TDE can be used to protect data at rest
In a typical database data in datafiles is visible on the OS to “oracle” Unix user only
If TDE is used then it protects the datafiles at rest on tape or other media
The “oracle” user can connect “/ as sysdba” and see any TDE protected data
Database Vault can be used to protect the access to the TDE data when connected

Slide 32 - Choose the Correct DV Solution