Applied Oracle Security: Developing Secure Database and Middleware Environments- P15 doc

114 Part II: Oracle Database Vault
executed by the SYS account or enabling OS authentication, changing the database dump
destinations. A complete list of security sensitive database initialization parameters that are
protected follows:
■ 07_DICTIONARY_ACCESSIBILITY
■ _dynamic_rls_policies
■ _system_trig_enabled
■ audit_file_dest
■ audit_sys_operations
■ audit_syslog_level
■ audit_trail
■ background_core_dump
■ background_dump_dest
■ background_dump_dest
■ control_files
■ core_dump_dest
■ core_dump_dest
■ db_create_file_dest
■ db_create_online_log_dest_1
■ db_create_online_log_dest_2
■ db_create_online_log_dest_3
■ db_create_online_log_dest_4
■ db_create_online_log_dest_5
■ db_recovery_file_dest
■ job_queue_processes
■ max_dump_file_size
■ optimizer_secure_view_merging
■ os_roles
■ plsql_debug
■ recyclebin
■ remote_os_roles

■ shadow_core_dump
■ sql92_security
■ user_dump_dest
■ user_dump_dest
■ utl_file_dir
Another control that is installed by DBV is the restriction that a database superuser account
cannot modify the DBV policy using the DBMS_MACADM PL/SQL package or even grant the
account the roles DV_OWNER or DV_ADMIN to use this package.
system@aos> attempt to use the DBV administration package
system@aos> using SYSTEM, the default Oracle DBA
system@aos> to remove the DBV Realm for the database itself
system@aos>BEGIN
dvsys.dbms_macadm.delete_realm_cascade('Oracle Data Dictionary');
END;
/
dvsys.dbms_macadm.delete_realm_cascade('Oracle Data Dictionary');
*
ERROR at line 2:
ORA-06550: line 2, column 8:
PLS-00904: insufficient privilege to access object DVSYS.DBMS_MACADM
ORA-06550: line 2, column 2:
PL/SQL: Statement ignored
system@aos> attempt to grant the DBV owner role to SYSTEM which
system@aos> would offer control over the DBV policy configuration
system@aos>GRANT dv_owner TO system;
GRANT dv_owner TO system
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-47401: Realm violation for grant role privilege on DV_OWNER.

ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55
ORA-06512: at line 31
With this triad of database administrators (security, account, and DBA) and the separation of
duty that is created with the DBV installation, an enterprise can immediately operate with checks
and balances to help meet whatever compliance regulations are required.
Chapter 4: Database Vault Introduction 115
Default Audit Policy
The Oracle DBV installation includes a comprehensive database audit policy designed to audit
commands and activity related to DBV’s DVSYS and DVF accounts and the OLS product account
LBACSYS. This policy ensures that any changes (or attempts to change) to the configuration data
for these two products is captured. Any subversive commands such as NOAUDIT, REVOKE,
and RENAME against these object-owning accounts are also capture by this audit policy. The
installation also includes a comprehensive audit policy for the database as a whole that audits
the following categories of database activity:
Session login and logoff
Privilege management, such as GRANT and REVOKE commands
Database Account Management, such as CREATE, ALTER, and DROP USER commands
Audit Policy, such as AUDIT and NOAUDIT commands
Structural Changes, such as tablespace management and object management with
command syntax such as CREATE <object>, ALTER <object>, and DROP <object>
Use of privileged commands including
o ADMINISTER DATABASE TRIGGER
o ALTER SESSION
o ALTER SYSTEM
o BECOME USER
o Flashback
o FORCE ANY TRANSACTION
o Restricted database sessions
o Use of system *ANY privileges
o Table truncation

This audit policy was developed from research conducted by leading government and commercial
authorities on computer security that continuously publish up-to-date recommendations on this
subject. The protection of the DBV and OLS configuration was then added to this policy to audit these
security-relevant features by default.
Default Security-relevant DBV Factors
The DBV installation creates a number of DBV factors that an enterprise may find useful for
developing custom DBV rule sets to control DBV command rules, DBV realm authorizations,
and DBV secure application roles. The installed factors can be categorized as follows:
Database and instance information
Database client network protocol
Database client language
Enterprise user information
Session authentication information
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■

■
■
■
116 Part II: Oracle Database Vault
Summary: Database Vault Is Differentiating Security
In our efforts to create a richer summary section, we thought it would be good to place the
summary in a discussion context. As with some security capabilities in the past, people will often
believe that they have created a security approach that is equal to DBV but that is implemented
through some other clever set of (database) technologies. Also similar to historical truth, they are
misguided, and it’s important to understand this so that you, too, don’t try to build your own
database vault. To some degree, this is a buy-versus-build discussion. In the next few paragraphs,
we’ll tell you why DBV is not only unique in what it does, but unique in how it does it. You
cannot build an equivalent database vault—even if you could, the costs in doing so would far
outweigh the costs of purchasing DBV from Oracle.
One of the early ideas for creating a DBV used triggers. DML triggers, and in particular DDL
triggers, can be set to fire for a large number of commands. Conceptually, this is similar to the
concept of command rules. The big difference, however, is that DBV is protected from nefarious
or unwitting actions even by administrators. Triggers were not designed or intended to be used as
security mechanisms. Changing trigger code, disabling a trigger, and dropping a trigger can be
performed by any user with the ALTER ANY TRIGGER or ALTER ANY TABLE system privilege.
Although DBV “uses DBV to secure DBV,” the security starts before you get to the database
tables and PL/SQL code. The security starts in the database kernel, as the DBV exists as a code
linked into the Oracle binaries. The importance of binary execution is that, unlike triggers that are
implemented in PL/SQL, you are unlikely to see the source code or be able to modify it. The code
that is linked into the Oracle binaries supports the numerous commands you will find in the
“Oracle SQL Language Reference” and has undergone countless hours of regression testing with
each database release. This gives you higher assurance that it has not been tampered with. As you
saw when reviewing the installation of DBV, the core DBV controls are in a protected schema.
Even SYS is unable to tamper with DBV.
The other differentiators for DBV come with its approach to implementation. The declarative

framework is at its core. The invaluable security validation and verification capabilities are
possible through the use of the framework. This has been an absolute necessity for getting the
security implemented and approved for operational production systems in very secure environments.
Transparency has also enabled DBV to succeed. In Chapter 1, you learned about the
importance of transparency, and DBV has enabled this by tapping into the DB kernel. The result
is that you can almost always enable DBV for an application and get things working in a more
secure manner than ever before. Simply add your objects of interest to a realm, add the right users
as realm participants or realm administrators, and you are on the right track. This is simple to do
and definitely increases your security with very little or no effort.
Perhaps the most impressive statement about DBV is that it addresses security by taking an
innovative approach to governing who gets access to what, where, when, and how. Conditional
security can be based on factors chained together in reusable rule sets and allows you to create
a myriad of realistic and useful security controls. The factors are based on things you know or
can validate. They allow you to ensure that security is happening the way it’s supposed to be
happening. The ability to use multiple factors significantly increases the security of your access
decisions. The adaptive nature of the framework and the rules not only allow extensibility to your
security, but they allow it to grow and shrink based on values that can be determined at runtime.
In the next two chapters, you will see several examples of how to apply DBV to applications.
You’ll not only see how to get it set up and working, but you’ll learn how to blend design patterns.
This will not only give you a jump start on using the technology, but it will also help you solidify
DBV concepts and your understanding of when and how to use it.
CHAPTER
5
Database Vault
Fundamentals
117
118 Part II: Oracle Database Vault
his chapter presents a collection of examples that demonstrate the fundamentals
behind how DBV components are configured using the DBMS_MACADM API. The
examples are built around the Sales History (SH) object-owner account included

with Oracle Database’s sample schemas. These examples cover the following
component configurations and demonstrate how these components’ configurations
impact sessions trying to access objects owned by the SH accounts:
Realms Provide boundaries around the use of system ANY privileges that administrators
typically have been granted. Realms examples demonstrate how you can meet your
organization’s compliance and consolidation requirements.
Command rules Protect the use of more than 100 commands in the “Oracle SQL
Reference Guide.” Command rules allow you to implement security policies based
on the business rules maintained by your organization.
Rule sets Serve as the library rules for your security policy engine. We examine
the impact of rule evaluation semantics, auditing and how custom event handler
mechanisms can be enabled in response to DBV enforcement events.
Factors Fundamental security policy attributes you define that form the building blocks
for DBV rule expressions and result in a multifactored security policy. Example of factors
linked into policies for Oracle Label Security (OLS) and Oracle Virtual Private Database
(VPD) are also presented.
Secure application roles Allow you to control the enablement of the more sensitive
privilege sets using business or application rules defined by your organization.
Realms
A realm is a new security layer that provides containment and eliminates inadvertent access
based on system ANY privileges. System ANY privileges are required for many application and
administration scenarios. These privileges are heavily used in operating a database, but the
privileges have no boundaries and therefore must be restricted. The security gap exists between
the database objects controlled by object privileges and the system controlled by system ANY
privileges. Realms were designed as a security mechanism that establishes boundaries around
a set of objects that limit the use of system ANY privileges to authorized realm users or roles.
Therefore, any attempt to access a realm protected object by an unauthorized user with system
ANY privileges will be blocked and raise a realm violation. Access based on object-level
privileges are not considered inadvertent and therefore are not enforced by the realm. Object-
level privileges are explicit permissions on individual objects that can be verified through

database dictionary views.
Realms are a simple and critical security measure that address many of the issues we face
today regarding compliance and separation of duties for different job responsibilities. They also
serve as an affective defensive measure for cyber security by limiting the extent to which system
privileges can be exploited by an attacker. Therefore, realms not only provide another layer of
security, but they add another level of defense. DBAs who are responsible for the health and
well-being of production databases should consider the serious nature of realm violations, either
legitimate or not. For example, an application needing additional accesses is legitimate and a
malicious attempt to access data within the database is not.
■
■
■
■
■
T
Chapter 5: Database Vault Fundamentals 119
In Chapter 4, we suggested that realms could be used to protect the security mechanisms that
are protecting your application. We know many customers have leveraged the existing database
security technologies and other database mechanisms, such as triggers, views, and PL/SQL, to
implement application security within the database. Perhaps you have read David Knox’s
Effective Oracle 10g Database Security by Design that serves as one of the best foundations for
implementing good security practices in an Oracle database. Security threats and challenges
continue to surface every day and require that you update our security design and implementation
on an ongoing basis. Therefore, simply maintaining an existing security approach can lure you
into a false sense of security, which effectively decreases your security posture and increases your
risk over time.
TIP
Realm access = DB ANY privilege + Realm authorization.
Applying realms to existing security approaches increases your security posture and reduces
your risk if you perform these simple steps:

1. Protect the data tables by adding them to a realm.
2. Protect security relevant objects by adding them to a realm. This includes PL/SQL
procedures for VPD, PL/SQL procedures that perform trusted transactions, and
application database roles.
Also consider the intent of any realm violation you encounter. A realm violation will occur if
A new login session is created or an existing one is highjacked;
Key privileges are available or new privileges are gained;
Attempted access of a realm-protected object is determined to be unauthorized.
Without DBV, the attempted access cannot be easily detected or blocked. Realms allow
application access paths and profiles to be contained and controlled. It also allows for a system
administrator or administrators to be better governed using both a context-based and a data
content security model. Realms allow you to govern security by the data semantics themselves.
Database administrators should consider the use of realms in production systems to update their
database security to meet today’s security challenges.
A good example of a need for security is personally identifiable information (PII). Within DBV
realms, you can establish boundaries and controls over PII at a either the database schema level
or an object level. Likewise, you can segment data as financials, personal health information,
Sarbanes Oxley Act (SOX), and so forth across database schemas, so that your realm covers many
objects over several database schemas.
With realms for consolidation of IT resources and data, you can meet security for compliance
and insider threat concerns, along with data integration for consolidation objectives. Security
should not be the primary excuse for not consolidating data into a fewer common databases.
Consolidation will clearly add more value to the processing of data that is usually transacted and
queried together. Consolidation will reduce operations and maintenance costs associated with
multiple systems and offers these primary benefits:
Increased data availability with a reduction in the labor, power, and storage requirements
to increase this availability
■
■
■

■
120 Part II: Oracle Database Vault
Enhanced and centralized enterprise security that accounts for regulatory compliance
controls
Universal access to data across the enterprise, without inefficient data movement
Reduced inconsistencies due to fewer instances of data duplication
Simplification of the security management of your Oracle database and applications as
centralized policies are not coded into each application. To demonstrate how we meet these
objectives for consolidation, consider the sample schemas that are available with Oracle
Database. The samples include the following schemas (a partial list):
Human Resources (HR)
Order Entry (OE)
Sales History (SH)
In many enterprises, this type of data is kept in separate databases and on separate servers.
This data as shown Figure 5-1.
■
■
■
■
■
■
FIGURE 5-1 Preconsolidation databases
Chapter 5: Database Vault Fundamentals 121
When viewed this way, it is easy to see the costs associated with maintaining these databases
with respect to the power consumption, hardware costs, labor costs, software license costs, and
recurring maintenance fees.
With consolidation efforts in an enterprise, you can reduce the costs by hosting the databases
on a shared server platform with a smaller number of administrators, as shown in Figure 5-2.
The challenge in this consolidated database architecture then becomes how to keep database
administrators of the Human Resources (HR) data from accessing or manipulating the Sales

History (SH) data, or vice versa. To demonstrate, log into the database using the SYSTEM account,
a well-known Oracle database account. The SYSTEM account has been granted the powerful
DBA role and that role is granted many ANY privileges for TABLE objects:
system@aos> Display the system (ANY) privileges the account has
system@aos>select privilege name
from session_privs where privilege like '%TABLE%' or
privilege like '%GRANT%' order by 1;
NAME

ALTER ANY TABLE
ALTER TABLESPACE
BACKUP ANY TABLE
COMMENT ANY TABLE
CREATE ANY TABLE
CREATE TABLE
CREATE TABLESPACE
DELETE ANY TABLE
DROP ANY TABLE
DROP TABLESPACE
FLASHBACK ANY TABLE
GRANT ANY ROLE
GRANT ANY PRIVILEGE
FIGURE 5-2 Consolidated databases
122 Part II: Oracle Database Vault
GRANT ANY OBJECT PRIVILEGE
INSERT ANY TABLE
LOCK ANY TABLE
MANAGE TABLESPACE
SELECT ANY TABLE
UNDER ANY TABLE

UNLIMITED TABLESPACE
UPDATE ANY TABLE
18 rows selected.
system@aos> Attempt to query the sales data using
system@aos> the SELECT ANY TABLE privilege
system@aos>select cust_id, amount_sold from sh.sales;
CUST_ID AMOUNT_SOLD

1258 23.75
1714 23.75
1842 23.75

system@aos> Grant object privileges on the table
system@aos> to another account
system@aos>grant select on sh.sales to scott;
Grant succeeded.
system@aos> Attempt to query the sales data using direct object
system@aos> privileges granted to the account SCOTT
system@aos>connect scott
Enter password:
Connected.
scott@aos>select cust_id, amount_sold from sh.sales;
CUST_ID AMOUNT_SOLD

1258 23.75
1714 23.75
1842 23.75

As you can see, the SYSTEM account has privileges not only to read or write the Sales History
data using privileges such as SELECT ANY TABLE and UPDATE ANY TABLE, but the account can

modify the structures in which the data is stored using a privilege such as ALTER ANY TABLE.
The same types of system ANY privileges are usually granted to named database administrator
accounts, providing the same unbounded access to application data. We must introduce a DBV
realm around the SH and HR schemas to enforce the separation of duty and mitigate compliance
concerns over unprotected access to PII or the integrity of financial numbers used in an audit.
Realm Protection Patterns
A DBV realm can be defined as a boundary around all the objects in a database schema, a subset
of objects in a database schema, or a collection of objects in multiple schemas. These example
usages are shown in Figure 5-3.
Chapter 5: Database Vault Fundamentals 123
In Figure 5-3, a realm may be defined for objects in several schemas to support the concept
of an order management application. The application may use a privileged account to access
sensitive customer purchasing information and PII information for employees.
In Figure 5-4, you can see a realm was created for a subset of the HR schema, where tables
such as EMPLOYEES and EMP_DETAILS_VIEW can contain PII information and tables such as
JOBS and JOB_HISTORY can include personal information such as an employee’s salary.
In Figure 5-5, an entire Sales History schema is protected and may contain sensitive
information used for SOX compliance and auditing.
FIGURE 5-3 Order Management realm (subset of object owner’s objects)
FIGURE 5-4 Human Resources realm (multiple objects, multiple object owners)