154 Part II: Oracle Database Vault
The DBV rules engine had created DBV rule that references this PL/SQL function. When the
function was dropped, the reference was broken along with the underlying GRANT EXECUTE
privilege on the function to DVSYS. We can see this problem by attempting to validate the correct
syntax of all the DBV rules that are configured. We can perform this validation by issuing the
following call as the DBV security administrator (DBVOWNER):
dbvowner@aos> exec dbms_macadm.sync_rules;
BEGIN dbms_macadm.sync_rules; END;
*
ERROR at line 1:
ORA-25448: rule DVSYS.DV$5045 has errors
ORA-00904: "SH"."CAN_PERFORM_SALES_SUMMARY": invalid identifier
ORA-06512: at "SYS.DBMS_RULE_ADM", line 188
ORA-06512: at "DVSYS.DBMS_MACADM", line 2794
ORA-06512: at line 1
In this example, you can see that one of our rules is invalid, probably because we forgot to
GRANT EXECUTE privilege on a function to DVSYS. You can isolate the offending rule by
querying the DVSYS.DV$RULE view as follows:
dbvowner@aos>SELECT name,rule_expr
from dvsys.dv$rule
WHERE id# = 5045;
NAME RULE_EXPR

Is Sales Summary Allowed sh.can_perform_sales_summary = 1
1 row selected.
In this example, the internal rule name is DVSYS.DV$5045. This corresponds to the ID# = 5045
in the view DVSYS.DV$RULE. The DBV security administrator can investigate views such as
DBA_TAB_PRIVS and DBA_OBJECTS to determine why the problem exists. In this case, if MARY
simply re-creates the function and GRANTs EXECUTE privilege on the function to DVSYS, the
DBV security administrator can then reexecute the DBMS_MACADM.SYNC_RULES procedure to
recompile the DBV rule.

DBV Rule Set Event Functions
The DBV product installs a collection of PL/SQL functions that can be used in DBV rule
expressions to retrieve detailed information about the database command that is being evaluated
for realm authorizations and command rules—such as UPDATE on SH.TABLE—as well as the
session context in which the command is operating. These PL/SQL functions are called the DBV
rule set event functions. Table 5-1 describes these functions.
We can use these event functions directly in our DBV Rule expressions—for example, testing
for a list of values:
dbvowner@aos> BEGIN
dbms_macadm.create_rule(
Chapter 5: Database Vault Fundamentals 155
rule_name => 'Trusted Sales Administrators'
, rule_expr => 'DVSYS.DV_LOGIN_USER IN (''ANTHONY'',''MARY'')'
);
END;
/
PL/SQL procedure successfully completed.
We can even use SQL subqueries and these event functions directly in our DBV rule
expressions. For example, if we want to test to see that the session user is a member of the
IT department as defined in the Human Resources schema, we’d use this:
dbvowner@aos> BEGIN
dbms_macadm.create_rule(
rule_name => 'Works In The IT Department'
, rule_expr => '(SELECT COUNT(*) FROM hr.employees where email =
|| ' DVSYS.DV_LOGIN_USER AND department = 60) > 0'
);
END;
/
PL/SQL procedure successfully completed.
Rule Set Function Description

DVSYS.DV_SYSEVENT Returns the system event firing the rule set, in VARCHAR2 data
type; the event name is the same as the syntax found in the SQL
statement that is issued, for example, INSERT, CREATE
DVSYS.DV_DICT_OBJ_TYPE Returns the type of the dictionary object on which the database
operation occurred, for example, table, procedure, view; the
return type is VARCHAR2
DVSYS.DV_DICT_OBJ_OWNER Returns the owner of the dictionary object on which the
database operation occurred; the return type is VARCHAR2
DVSYS.DV_DICT_OBJ_NAME Returns the name of the dictionary object on which the
database operation occurred; the return type is VARCHAR2
DVSYS.DV_SQL_TEXT Returns the first 4000 characters of SQL text of the database
statement used in the operation; the return type is VARCHAR2
DVSYS.DV_LOGIN_USER Returns the login user name, in VARCHAR2 data type; returns
the same value that SYS_CONTEXT(‘USERENV’, ‘SESSION_
USER’) returns
DVSYS.DV_INSTANCE_NUM Returns the database instance number, in NUMBER data type
DVSYS.DV_DATABASE_NAME Returns the database name, in VARCHAR2 data type
TABLE 5-1 DBV Rule Set Event Functions
156 Part II: Oracle Database Vault
DBV Factors Used in Rule Set Expressions
In the rule examples we’ve demonstrated so far, most of the logic for the security decisions we’ve
used is implemented in the Sales History schema (SH) for the sake of simplifying the examples.
While these are merely examples, we need to think about our rules from the enterprise perspective,
so that security controls are maintained outside of the application. This needs to be done not only
for security’s sake, but also to allow application developers to leverage corporate policies around
security. This is also important from the perspective of reuse, because developers and system
architects should not have to reinvent or recode the same controls for each application that is
being designed.
DBV rules should be based on conditions from a trusted source, whether that source is
internal to the database or in an external system. This is where DBV factors play a role. DBV

factors are available as PL/SQL functions that have independent access (from the application’s
perspective) to a method or data for security relevant information. For example, the DBV security
administrator can define DBV factors such as User Department and Connection Method. The
administrator can then use these factors to create additional factors, such as Sales Staff User or
Secure Connection. From a pseudo-code point of view, these may take the following form:
Factor Implementation
User department
SELECT department
FROM hr.employees
WHERE email =
SYS_CONTEXT('USERENV', 'SESSION_USER')
Sales staff user
If DVSYS.GET_FACTOR('User Department') IN
('Retail Sales', 'Government Sales')
Then 'Sales Staff User' is 'TRUE'
Else 'Sales Staff User' is 'FALSE'
Authentication method
SYS_CONTEXT('USERENV', 'AUTHENTICATION_METHOD')
Secure connection
If DVSYS.GET_FACTOR('Authentication Method')
IN ('SSL', 'KERBEROS')
AND DVSYS.GET_FACTOR('Client IP') LIKE
'192.168.0.%'
Then 'Secure Connection' is 'TRUE'
Else 'Secure Connection’ is 'FALSE'
Application developers do not always need to be concerned about the implementation of the
information used to establish the DBV factors. In some cases, you may not want them to know!
For example, the User Department could just as easily come from an external LDAP source, such
as Oracle Internet Directory (OID) or a web service. Each database application developer or
architect should not have to consider how the factor is resolved. They simply need to know what

the factor means and how it applies to their applications. The point here is that factors of security-
relevant attributes can be shared by more than one application and are maintained by the security
administrator, a third party with respect to the application developers and application DBAs.
These factors can form the building blocks in DBV rule sets that may be applied to more than
one application.
We’ve discussed how DBV factors provide many advantages to applications, including
security controls that can be shared across applications and logic that is maintained outside
of application development control. The ability to use them in DBV rule sets provides a more
Chapter 5: Database Vault Fundamentals 157
verifiable and readable security policy for compliance. In the next section, we will dig into the details
of DBV factor configuration and the component’s powerful features that offer information assurance.
Factors
DBV factors are security relevant attributes that help to establish the context for a session to
authorize database commands or actions, such as the following (shown in Figure 5-10):
Connecting to the database, or a session authorization, when used as part of a DBV
CONNECT command rule
Executing a (SQL) command statement on a database object or a statement level
authorization when used as part of a DBV command rule or realm authorization
Filtering data in SELECT and DML statements, or a row-level security (RLS) authorization,
when used in Oracle Virtual Private Database (VPD) policy or the Oracle DBV Oracle
Label Security (OLS) integration
Branching in application code, or logic authorizations, when using the DBV factor
function or the GET_FACTOR function in PL/SQL logic
DBV factors are typically defined and maintained outside of specific database applications.
Factors can use information that may be internal or external to the information stored in the database.
DBV factors are used primarily to establish the context of the “subject” (who) in your security policy
and the “conditions” in your security policy (when, how, where). The context of the subject may
include session information on roles granted, group/organizational membership, privileges granted,
and even identity management related attributes, such as job title. Conditional attributes may include
information such as time of day or month, authentication method used, database client location,

or access path (recall the trusted package example) to the enforcement point. The 11.0.6 DBV
installation will create 17 factors that may be useful for your organization’s security policy.
■
■
■
■
FIGURE 5-10 DBV factor usage
158 Part II: Oracle Database Vault
Creating Factors
The fundamental configuration of a DBV factor is the factor name and the PL/SQL expression
used to retrieve the factor’s value, or the factor’s identity as it is called. One factor that is installed
by DBV is Client IP, which is the database client’s IP address. The factor uses the PL/SQL
expression UPPER(SYS_CONTEXT(‘USERENV’,’IP_ADDRESS’)) to retrieve its identity. To define
your own retrieval-based custom factor you would follow these steps:
1. Define the factor’s retrieval method using a PL/SQL function.
2. Grant EXECUTE privileges on this PL/SQL function to the DVSYS account.
3. Define the factor definition as the DBV security administrator (DBVOWNER).
Factor Retrieval Method
The factor retrieval method is a PL/SQL expression or SQL SELECT statement that returns a single
VARCHAR2 value. PL/SQL expressions can be based on PL/SQL functions or SQL built-in functions
defined by the Oracle RDBMS, or they can be based on a custom PL/SQL function that you’ve
built. The key is that the function returns a VARCHAR2 value even if it is NULL, or it returns some
data type that can be cast to a VARCHAR2 by typical Oracle data type casting rules. The function’s
signature can be defined as follows:
FUNCTION some_factor RETURN VARCHAR2;
or FUNCTION another_factor(param1 IN data_type1 … paramN IN data_typeN)
RETURN VARCHAR2;
Note in the latter signature that it is possible to pass parameters to your factor function if you need
additional information not readily available to the PL/SQL logic inside the function or if you need
to integrate existing functions and cannot change the function’s signature. Consider the following

custom PL/SQL package that retrieves department information for users stored in the Human
Resources (HR) object owner account:
hr@aos> define the package specification
hr@aos> CREATE OR REPLACE PACKAGE hr.employee_utility IS
FUNCTION get_user_department_id ( user_name IN
VARCHAR2 DEFAULT SYS_CONTEXT('USERENV', 'SESSION_USER') ) RETURN NUMBER;
FUNCTION get_user_department_name ( user_name IN
VARCHAR2 DEFAULT SYS_CONTEXT('USERENV', 'SESSION_USER') ) RETURN VARCHAR2;
END;
/
Package created.
hr@aos> define the package body
hr@aos> CREATE OR REPLACE PACKAGE BODY hr.employee_utility IS
FUNCTION get_user_department_id ( user_name IN
VARCHAR2 ) RETURN NUMBER IS
l_email VARCHAR2(120);
l_dept_id hr.employees.department_id%TYPE;
BEGIN
input parameter checking
IF user_name IS NULL OR LENGTH(user_name) > 100 THEN
RAISE_APPLICATION_ERROR(-20001,
'Invalid parameter for "user_name"',FALSE);
Chapter 5: Database Vault Fundamentals 159
END IF;
database usernames and email names are similar
l_email := user_name;
query the employee's department assignment
SELECT department_id
INTO l_dept_id
FROM hr.employees

WHERE email = l_email;
RETURN l_dept_id;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN NULL;
END;
FUNCTION get_user_department_name ( user_name IN
VARCHAR2 ) RETURN VARCHAR2 IS
l_dept_id hr.employees.department_id%TYPE;
l_dept_name hr.departments.department_name%TYPE;
BEGIN
l_dept_id := get_user_department_id(user_name);
IF l_dept_id IS NULL THEN
RETURN NULL;
END IF;
SELECT department_name
INTO l_dept_name
FROM hr.departments
WHERE department_id = l_dept_id;
RETURN l_dept_name;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN NULL;
END;
END;
/
Package created.
In these PL/SQL examples, a table named HR.EMPLOYEES and the employees listed in this
table may also have database accounts. We can match the database account names to the EMAIL
column of the HR.EMPLOYEES table, without the @company suffix. The two functions in this

package can retrieve department assignment information, such as the department ID or department
name for the employee. To use custom-developed PL/SQL functions in DBV factors, your next
step is to GRANT EXECUTE privilege on the package or function to the DVSYS account as
follows:
hr@aos> GRANT EXECUTE ON hr.employee_utility TO dvsys;
Grant succeeded.
When custom-developed PL/SQL functions, such as those defined in the example package, are
used as the retrieval method for DBV factors, the function is typically defined with definer’s rights,
versus invoker’s rights. The factor retrieval method may involve the use privileges on database
objects or other PL/SQL code. The encapsulation of the factor retrieval methods in PL/SQL
packages and their internal functions avoids the need to maintain additional privilege grants to
160 Part II: Oracle Database Vault
the DVSYS account. With the GRANTS to DVSYS in place, the DBV security administrator can
define the factor definitions that make use of the PL/SQL package functions:
dbvowner@aos> user department identifier
dbvowner@aos> BEGIN
dbms_macadm.create_factor(
factor_name => 'User_Department_Id',
factor_type_name => 'User',
description =>
'The identifier of the department the current user works in.',
rule_set_name => NULL ,
get_expr => 'hr.employee_utility.get_user_department_id',
validate_expr => NULL,
identify_by => dbms_macutl.g_identify_by_method,
labeled_by => dbms_macutl.g_labeled_by_self,
eval_options => dbms_macutl.g_eval_on_access,
audit_options => dbms_macutl.g_audit_on_get_error,
fail_options => dbms_macutl.g_fail_with_message);
END;

/
PL/SQL procedure successfully completed.
dbvowner@aos> user department name
dbvowner@aos> BEGIN
dbms_macadm.create_factor(
factor_name => 'User_Department_Name' ,
factor_type_name => 'User',
description =>
'The name of the department the current user works in.',
rule_set_name => NULL ,
get_expr =>
'hr.employee_utility.get_user_department_name',
validate_expr => NULL,
identify_by => dbms_macutl.g_identify_by_method,
labeled_by => dbms_macutl.g_labeled_by_self,
eval_options => dbms_macutl.g_eval_on_access,
audit_options => dbms_macutl.g_audit_on_get_error,
fail_options => dbms_macutl.g_fail_with_message);
END;
/
PL/SQL procedure successfully completed.
The DBMS_MACADM package that is used for factor creation allows for the factor retrieval
method parameter, get_expr, to use a function that returns a VARCHAR2, as is the case with the
function HR.EMPLOYEE_UTILITY.GET_USER_DEPARTMENT_NAME or a function that can be
cast to a VARCHAR2 value, as is the case with the function HR.EMPLOYEE_UTILITY.GET_USER_
DEPARTMENT_ID.
The following example demonstrates how to use a SQL SELECT statement to retrieve a factor
value with a query on the V$DATABASE view for the OS platform on which the database is
running:
Chapter 5: Database Vault Fundamentals 161

dbvowner@aos> BEGIN
dbms_macadm.create_factor(
factor_name => 'Platform_Name' ,
factor_type_name => 'Instance',
description => 'Retrieves the OS Platform the
database is running on',
rule_set_name => NULL ,
get_expr => '(SELECT platform_name FROM v$database)',
validate_expr => null,
identify_by => dbms_macutl.g_identify_by_method,
labeled_by => dbms_macutl.g_labeled_by_self,
eval_options => dbms_macutl.g_eval_on_session,
audit_options => dbms_macutl.g_audit_on_get_error,
fail_options => dbms_macutl.g_fail_with_message);
END;
/
PL/SQL procedure successfully completed.
When using SQL SELECT statements, you must embed the SELECT statement in parentheses
and the DVSYS account must be granted SELECT privileges on the table or view being queried.
Naming Factors
It is important that you name your factors with identifiers that convey the attribute retrieved, in
human readable form, to improve the readability of your DBV policy where these factors are
used. In other words, using readable factor names such User_Department_Name, compared to
the names used for variables or columns, such as USR_DEPT, improves readability of the security
policy when a factor is used in a DBV rule set expression. Here’s an example:
dbvowner@aos> BEGIN
dbms_macadm.create_rule(
rule_name => 'Is An Employee of the IT Department'
, rule_expr =>
'DVSYS.GET_FACTOR(''User_Department_Name'') = ''IT'''

);
END;
PL/SQL procedure successfully completed.
Scope of Factor Retrieval Method
It is important that you test the factor function by executing it using the DVSYS account and several
test accounts to determine whether the factor retrieval method raises exceptions for any database
sessions. You must consider whether the session contextual information on which the factor
function may rely is defined for each account you test, and you should handle these cases in the
code that makes up the factor function. You should deal with these conditions because once factor
functions are defined, they are evaluated at session establishment for every session, even those
running as part of the Oracle RDBMS product, such as Enterprise Manager Database Control jobs.
DBV factors do not currently have a scoping mechanism to limit their evaluation to certain
accounts, roles, or session conditions, so if you want to prevent processing in the factor logic for
certain types of sessions, you will need to codify this in your PL/SQL factor function. With our
department example, Oracle database accounts such as SYS, SYSTEM, and SYSMAN, to name a
few, will not exist in the HR table records, so we simply return NULLS to handle these cases.
162 Part II: Oracle Database Vault
Factor Evaluation
The eval_options parameter in the DBMS_MACADM.CREATE_FACTOR
procedure controls when the identity of the factor should be resolved by calling the factor retrieval
method. A factor identity can be resolved just once, at the time the database session is started, using
the constant DBMS_MACUTL.G_EVAL_ON_SESSION. With this constant, the factor retrieval method
is called once when the database session is established and cached in the database session context
namespace MAC$FACTOR. Subsequent calls to resolve the identity are read from this read-only
memory area to improve performance. If the constant DBMS_MACUTL.G_EVAL_ON_ACCESS is
used for this parameter, each call to resolve the factor’s identity will call the factor’s retrieval method.
In our examples so far, factors such as AUTHENTICATION_METHOD or CLIENT_IP will not change
over the course of a database session, so identity resolution should be configured using DBMS_
MACUTL.G_EVAL_ON_SESSION. Factors such as User_Department_Name and User_Department_
Id could in fact change during the course of a database session (if the employee were reassigned, for

example), so the parameter DBMS_MACUTL.G_EVAL_ON_ACCESS should be used.
TIP
Use the evaluation on access for the factor retrieval method if the
values can change over the course of a database session.
Factor Auditing
It is possible that the PL/SQL expression used in the DBV factor’s retrieval method (the get_expr
parameter) can encounter some error in processing or return a NULL value. The DBV factor
can be configured to audit these outcomes using the audit_options parameter in the DBMS_
MACADM.CREATE_FACTOR procedure. The DVA web application allows the DBV security
administrator to query these audit records using a standard report that is provided with the
application.
Factor Functions
When a factor is created, the DBV product will create a PL/SQL function of the form, DVF.
F$<FactorName>, that can be used in DBV rule set expressions or your own PL/SQL code. When
we created the factor User_Department_Name, a function named DVF.F$USER_DEPARTMENT_
NAME was created. This PL/SQL function is publicly available to all database sessions. The
following demonstrates the usage of function for the User_Department_Name factor.
anthony@aos>select DVF.F$USER_DEPARTMENT_NAME FROM DUAL;
F$USER_DEPARTMENT_NAME

IT
1 row selected.
If the name of a the factor that must be used is dynamically resolved, the rule set or
application logic can use the function DVSYS.GET_FACTOR(‘FactorName’) to get the value
of the factor, as shown in the following example:
anthony@aos>select DVSYS.GET_FACTOR('USER_DEPARTMENT_NAME') FROM DUAL;
DVSYS.GET_FACTOR('USER_DEPARTMENT_NAME')

IT
1 row selected.

Chapter 5: Database Vault Fundamentals 163
Factor Identities
The term “identity” is typically defined as the unique identifier of a user stored in an identity
management repository. In DBV, the term is overloaded to mean the value of a factor. DBV can be
configured with many more security-relevant attributes than just the user when you’re defining a
security policy, so you have many identities to consider. We have identities (values) for the client
IP addresses, client machines, the time of day, user departments, and so on. As you have seen
with the examples so far, the DBV factor configuration supports the use of a simple PL/SQL
expression that uses publicly available PL/SQL functions—for example, SYS_CONTEXT or TO_
CHAR(SYSDATE)—and this can be custom PL/SQL code. When we define a factor in this way, we
use the constant DBMS_MACUTL.G_IDENTIFY_BY_METHOD for the parameter identify_by and
place the PL/SQL expression in the get_expr parameter in the call to the DBMS_MACADM.
CREATE_FACTOR procedure.
Factor Identity as a Constant
The PL/SQL expression used to establish the factor’s identity can also be a constant value. We
specify a constant identity using the constant DBMS_MACUTL.G_IDENTIFY_BY_CONSTANT for
the parameter identify_by and place the constant value in the get_expr parameter in the call to
the procedure DBMS_MACADM.CREATE_FACTOR. A factor with a constant identity can be
useful for IF/THEN/ELSE or CASE/SWITCH logic that you may include in your security policy. For
example, you may have a highly restrictive policy in a production database and a less restrictive
policy in a development database. We could define a factor such as IS_PRODUCTION to return
0 or 1, or a factor such as ENVIRONMENT_NAME to return a value such as ‘DEV’, ‘TEST’, or
‘PROD’ (separately) in each database to handle this type of scenario.
Factors Identified by Other Factors
We can also identify a factor based on the identity of other factors. Using this method, we can
assert the identity of a factor using a declarative DBV construct called identity maps. Identity maps
allow for a multifactored security capability to be defined in your database and does not require
special PL/SQL code. This method of factor resolution requires the use of the constant DBMS_
MACUTL.G_IDENTIFY_BY_FACTOR for the parameter identify_by in the call to the procedure
DBMS_MACADM.CREATE_FACTOR. Multifactored security is really one of the most interesting

and powerful security features of DBV. To illustrate this feature, consider the example discussed
with the DBV CONNECT command rule, where we placed a greater level of trust in database
clients that were either on the database server console itself, and those clients that authenticated to
the database using an Oracle Advanced Security Option (ASO) credential mechanism, such as PKI/
SSL or Kerberos, from within the corporate network. This example was an all-or-nothing type of
authorization that either allowed the database connection or did not allow it. The example did in
fact consider multiple factors, the authentication method, and the client’s IP address. We can
extend this example to use the multifactored approach to classify the database connection as a
DBV factor using DBV identity maps. This DBV factor for the connection classification can have
more than just TRUE/FALSE identity values that can be used for DBV command rules, DBV realm
authorizations, VPD or OLS policies, and even your own PL/SQL logic.
Let’s assume the following notional environment conditions:
We are using ASO’s PKI/SSL option for secure connections within the corporate network.
The corporate network (intranet) is defined by the subnet 192.168.0.
■
■