164 Part II: Oracle Database Vault
The following table depicts a new DBV factor Connection_Type and its identities. We can
define these identities based on these notional environment conditions with the Authentication_
Method, Client_IP, and Session_User factors contributing to identify the Connection_Type factor.
Connection_Type Identity Authentication_Method Client_IP Session_User
LOCAL_DBA OS or PASSWORD NULL SYS, SYSTEM
CORPORATE_SSL SSL LIKE '192.168.0.%' %
CORPORATE_
PASSWORD
PASSWORD LIKE '192.168.0.%' %
OTHER % NOT LIKE
'192.168.0.%'
%
The approach to identifying factors based on the identity of other factors requires the
following steps:
1. Define the factor to be identified by other factors. The factor that is identified by other
factors is called the parent factor.
2. Define factor links between the parent and contributing factors. With the DVA web
application, this factor linking is done automatically with the underlying DBMS_
MACADM APIs.
3. Define the identities for the parent factor.
4. Define factors and identities for all factors that identify the parent factor. The factors that
identify the parent factor are called child factors.
5. Define the identity maps that map the identities of the child factors to the parent factor.
First we define the Connection_Type factor, which is our parent factor, with a get_expr
parameter set to an expression that will resolve to one of our identities for the factor. This is
simply a default expression before the other factors are resolved and it should default to our least
trusted identity.
BEGIN
dbms_macadm.create_factor(
factor_name => 'Connection_Type' ,

factor_type_name => 'Application',
description => 'Categorizes the connection security level.',
rule_set_name => NULL ,
get_expr => 'UPPER(''OTHER'')',
validate_expr => NULL,
identify_by => dbms_macutl.g_identify_by_factor,
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.
Chapter 5: Database Vault Fundamentals 165
Next we define factor links that identify all the child factors that could be used in our identity
maps (which we will define in a bit) to identify the parent factor. The PL/SQL API should be called
for each child factor you plan to use in at least one identity map.
dbvowner@aos> create a link for the Client IP address
dbvowner@aos> BEGIN
dbms_macadm.add_factor_link(
parent_factor_name =>'Connection_Type',
child_factor_name =>'Client_IP',
label_indicator => 'N');
END;
/
dbvowner@aos> create a link for the Authentication Method
dbvowner@aos> BEGIN
dbms_macadm.add_factor_link(
parent_factor_name =>'Connection_Type',
child_factor_name =>'Authentication_Method',

label_indicator => 'N');
END;
/
dbvowner@aos> create a link for the Session User
dbvowner@aos> BEGIN
dbms_macadm.add_factor_link(
parent_factor_name =>'Connection_Type',
child_factor_name =>'Session_User',
label_indicator => 'N');
END;
/
PL/SQL procedure successfully completed.
The label_indicator parameter is required for DBV’s integration capability with OLS and should
be set to ‘N’ (FALSE) by default.
Next we define the identities for the parent factor based on the preceding table. Four possible
classifications of the connection are shown next in order of the trust we have in the connection
(highest to lowest). The trust_level parameter is a number that can be defined at your discretion.
The level set for each identity should be indicative the trust you would place on a session that has
the identity set relative to sessions with other identities.
dbvowner@aos> BEGIN
create identity for LOCAL_DBA value
or connections on the database console
dbms_macadm.create_identity(factor_name=>'Connection_Type',
value=>'LOCAL_DBA',trust_level=>4);
create identity for CORPORATE_SSL value
or connections within the corporate network
using PKI/SSL authentication
dbms_macadm.create_identity(factor_name=>'Connection_Type',
value=>'CORPORATE_SSL',trust_level=>3);
create identity for CORPORATE_PASSWORD value

or connections within the corporate network
166 Part II: Oracle Database Vault
using username/password authentication
dbms_macadm.create_identity(factor_name=>'Connection_Type',
value=>'CORPORATE_PASSWORD',trust_level=>2);
create identity for OTHER value
or connections coming from outside the
corporate network, such as over a VPN connection
dbms_macadm.create_identity(factor_name=>'Connection_Type',
value=>'OTHER',trust_level=>1);
END;
/
PL/SQL procedure successfully completed.
Next we define the child factors whose identities will be used to resolve the parent factor. The
factors that are used in this example are all installed by DBV, so we’ve saved some time in this
case. The Client_IP factor will use the LIKE comparison operator in this example, so we do not
need to define identities for this factor. The DBV product installs all the possible identities for the
Authentication_Method factor as the following query shows:
dbvowner@aos> SELECT factor_name,value
FROM dvsys.dv$identity
WHERE factor_name = 'Authentication_Method'
ORDER BY factor_name
/
FACTOR_NAME VALUE

Authentication_Method DCE
Authentication_Method KERBEROS
Authentication_Method NONE
Authentication_Method OS
Authentication_Method PASSWORD

Authentication_Method RADIUS
Authentication_Method SSL
7 rows selected.
The only child factor identities that remain are the trusted accounts we want to define for the
database console, SYS and SYSTEM:
dbvowner@aos> BEGIN
dbms_macadm.create_identity(factor_name=>'Session_User',
value=>'SYS',trust_level=>10);
dbms_macadm.create_identity(factor_name=>'Session_User',
value=>'SYSTEM',trust_level=>10);
END;
/
PL/SQL procedure successfully completed.
The last set of steps requires us to define a set of identity conditions for the child factors that
will resolve each identity of our parent factor. These mappings of child factor identities to the
identity of the parent factor are called identity maps. For the LOCAL_DBA identity of the
Connection_Type factor, the following identity maps will consider the authentication method,
the database client’s IP address, and the name of the user:
Chapter 5: Database Vault Fundamentals 167
dbvowner@aos> BEGIN
WHEN authenticating by OS, such as / AS SYSDBA,
or by PASSWORD
dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'LOCAL_DBA'
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Authentication_Method'
, operation => '='
, operand1 => 'OS'
, operand2 => NULL );

dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'LOCAL_DBA'
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Authentication_Method'
, operation => '='
, operand1 => 'PASSWORD'
, operand2 => NULL );
AND the client IP address is NULL, as is the case
when logging into the database on the console
outside the control of the database listener, or
when the IP address is that of the database server
when coming through the listener.
dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'LOCAL_DBA'
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Client_IP'
, operation => 'IS NULL'
, operand1 => 'NULL'
, operand2 => NULL );
dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'LOCAL_DBA'
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Client_IP'
, operation => '='
, operand1 => '192.168.0.251'
, operand2 => NULL );
AND the user is SYS or SYSTEM

dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'LOCAL_DBA'
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Session_User'
, operation => '='
, operand1 => 'SYS'
, operand2 => NULL );
dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'LOCAL_DBA'
168 Part II: Oracle Database Vault
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Session_User'
, operation => '='
, operand1 => 'SYSTEM'
, operand2 => NULL );
END;
/
PL/SQL procedure successfully completed.
It is important that you understand the processing logic for a DBV identity map that makes
use of multiple child factors and more than one factor identity in the map configuration. The
preceding map has three child factors that will be evaluated with AND logic. For multiple
identities within each child factor, such as the case with the Authentication_Method, Client_IP,
and Session_User identities used, the evaluation will use an OR logic within each child factor. In
other words, the DBV identity map for the Connection_Type = 'LOCAL_DBA' will be TRUE when
the following occurs:
( Authentication_Method = 'OS' OR Authentication_Method = 'PASSWORD' )
AND ( Client_IP IS NULL OR Client_IP = '192.168.0.251' )
AND (Session_User = 'SYS' OR Session_User = 'SYSTEM')

For the CORPORATE_SSL identity, the following identity maps consider the authentication
method and the database client’s IP address:
dbvowner@aos> BEGIN
WHEN the authentication method is PKI/SSL (certificate)
dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'CORPORATE_SSL'
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Authentication_Method'
, operation => '='
, operand1 => 'SSL'
, operand2 => NULL );
AND the client's IP address is on the corporate network,
which we have defined as the 192.168.0 subnet
dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'CORPORATE_SSL'
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Client_IP'
, operation => 'LIKE'
, operand1 => '192.168.0%'
, operand2 => NULL );
END;
/
PL/SQL procedure successfully completed.
For the CORPORATE_PASSWORD identity, the following identity maps consider the
authentication method and the database client’s IP address:
Chapter 5: Database Vault Fundamentals 169
dbvowner@aos> BEGIN
WHEN the authentication method is PASSWORD

dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'CORPORATE_PASSWORD'
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Authentication_Method'
, operation => '='
, operand1 => 'PASSWORD'
, operand2 => NULL );
AND the client's IP address is on the corporate network,
which we have defined as the 192.168.0 subnet
dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'CORPORATE_PASSWORD'
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Client_IP'
, operation => 'LIKE'
, operand1 => '192.168.0%'
, operand2 => NULL );
END;
/
PL/SQL procedure successfully completed.
For the OTHER identity, the identity map is simply based on the database client’s IP address
not being on the 192.168.0 subnet and is coming from some other network:
dbvowner@aos> BEGIN
dbms_macadm.create_identity_map(
identity_factor_name => 'Connection_Type'
, identity_factor_value => 'OTHER'
, parent_factor_name => 'Connection_Type'
, child_factor_name =>'Client_IP'
, operation => 'NOT LIKE'

, operand1 => '192.169.0.%'
, operand2 => NULL );
END;
/
PL/SQL procedure successfully completed.
dbvowner@aos>COMMIT;
Commit completed.
Now that DBV identity maps are defined, we can test them under various scenarios to
understand how they work. If we log in as SYS on the database console, we should expect the
Connection_Type factor to resolve to LOCAL_DBA:
$ sqlplus / AS SYSDBA
SQL*Plus: Release 11.1.0.6.0 - Production on Sat Feb 21 17:18:04 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
170 Part II: Oracle Database Vault
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
sys@aos> SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type
, DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method
, DVSYS.GET_FACTOR('Client_IP') Client_IP
FROM DUAL;
CONNECTION AUTHENTICA CLIENT_IP

LOCAL_DBA OS
1 row selected.
If we log in as MARY on the corporate network using password authentication, for example,
we should expect the Connection_Type factor to resolve to CORPORATE_PASSWORD:
$ sqlplus mary@aos
SQL*Plus: Release 11.1.0.6.0 - Production on Sat Feb 21 17:14:42 2009

Copyright (c) 1982, 2007, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
mary@aos>SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type
, DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method
, DVSYS.GET_FACTOR('Client_IP') Client_IP
FROM DUAL;
CONNECTION_TYPE AUTHENTICATION_METHO CLIENT_IP

CORPORATE_PASSWORD PASSWORD 192.168.0.200
1 row selected.
If we log in as MARY over a VPN connection, with an access point external to the corporate
network, we should expect the Connection_Type factor to resolve to the value 'OTHER':
C:\> sqlplus mary@aos
SQL*Plus: Release 11.1.0.6.0 - Production on Sat Feb 21 17:14:42 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
mary@aos>SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type
, DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method
, DVSYS.GET_FACTOR('Client_IP') Client_IP
FROM DUAL;
Chapter 5: Database Vault Fundamentals 171
CONNECTION_TYPE AUTHENTICATION_METHO CLIENT_IP


OTHER PASSWORD 10.10.10.10
1 row selected.
This example demonstrates how to create a security-relevant factor whose foundation is based on
multiple (other) factors using a declarative method that required no PL/SQL programming. The
factors we used in this example are provided by the database kernel code, but your custom
factors could also be used with this approach. You can establish a multifactor security policy
when these factors are used DBV rule sets or in your own PL/SQL code.
Consider the DBV CONNECT command rule example presented earlier. In this example, two
DBV rules were used to authorize a connection to the database. The rules ‘Is Secure Authentication
Method’ and ‘Is Console Client’ examined the authentication method and database client’s IP
address in a manner similar to the way that the Connection_Type factor is identified. We can
replace these two DBV rules with a single DBV rule, ‘Is Trusted Client’, to achieve the same result
simply by checking for the factor Connection_Type not being ‘OTHER’, as shown in this example:
dbvowner@aos> BEGIN
dbms_macadm.create_rule(
rule_name => 'Is Trusted Client'
, rule_expr =>
'DVSYS.GET_FACTOR(''Connection_Type'') <> ''OTHER'''
);
END;
/
PL/SQL procedure successfully completed.
To demonstrate multifactor security within PL/SQL, we can create a VPD policy on the
CUSTOMERS table in the Sales History (SH) schema. In this policy, we will use the factor in the
VPD policy function to provide either column-level or row-level security on the table. First we
need to grant a named account the ability to manage VPD policy. The realm owner of the Sales
History realm, MARY, is authorized to perform not only administration on objects in the SH object
owner account, but she can also perform VPD policy administration on the objects. The only step
that is required to enable this VPD administration is to grant MARY execute privileges on the VPD

administration package, SYS.DBMS_RLS. This package is protected by the Oracle Database Vault
realm and requires the DV_OWNER role to grant the privilege.
dbvowner@aos> GRANT EXECUTE ON sys.dbms_rls TO mary;
MARY must first create the VPD policy function that will leverage our factor to provide row-level
security on the SH.CUSTOMERS table:
mary@aos>CREATE OR REPLACE FUNCTION sh.customer_policy_function(
schema_name IN VARCHAR2
, table_name IN VARCHAR2 ) RETURN VARCHAR2
AS
BEGIN
prevent access to sensitive customer data
outside of the corporate network
172 Part II: Oracle Database Vault
IF schema_name = 'SH'
AND table_name = 'CUSTOMERS' THEN
when the connection type factor is OTHER we know
the database client has not connection from
the corporate network
IF DVSYS.GET_FACTOR('CONNECTION_TYPE')
= 'OTHER' THEN
RETURN '1=0';
for all other connection types allow
access to all rows
ELSE
RETURN '1=1';
END IF;
END IF;
END;
/
Function created.

Next MARY can create a VPD policy using the DBMS_RLS package. In this example policy,
we will restrict just the ability to show sensitive columns such as date of birth, marital status, and
income outside of the corporate network:
mary@aos> BEGIN
dbms_rls.add_policy(
object_schema => 'SH'
,object_name => 'CUSTOMERS'
,policy_name => 'POLICY_CUSTOMERS'
,function_schema => 'SH'
,policy_function => 'CUSTOMER_POLICY_FUNCTION' ||
,sec_relevant_cols => 'CUST_GENDER,CUST_YEAR_OF_BIRTH' ||
',CUST_MARITAL_STATUS,CUST_INCOME_LEVEL,CUST_CREDIT_LIMIT'
,sec_relevant_cols_opt => dbms_rls.all_rows
);
END;
/
PL/SQL procedure successfully completed.
If MARY queries the SH.CUSTOMERS table from within the corporate network, the security
sensitive columns are visible:
mary@aos> show the Connection_Type factor and session context
mary@aos>SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type
, DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method
, DVSYS.GET_FACTOR('Client_IP') Client_IP
FROM DUAL;
CONNECTION_TYPE AUTHENTICATION_METHO CLIENT_IP

CORPORATE_PASSWORD PASSWORD 192.168.0.200
1 row selected.
Chapter 5: Database Vault Fundamentals 173
mary@aos> query the SH.CUSTOMERS table

mary@aos> SELECT
cust_last_name
, cust_year_of_birth
, cust_marital_status
, cust_income_level
FROM sh.customers
WHERE cust_state_province = 'TX'
AND ROWNUM < 10
ORDER BY cust_last_name
/
CUST_LAST_ CUST_YEAR_OF_BIRTH CUST_MARIT CUST_INCOME_LEVEL

Beiers 1982 single K: 250,000 - 299,999
Duval 1981 single H: 150,000 - 169,999
Greeley 1977 F: 110,000 - 129,999
Grover 1970 married D: 70,000 - 89,999
Hamilton 1961 single G: 130,000 - 149,999
Krider 1967 F: 110,000 - 129,999
Majors 1948 single G: 130,000 - 149,999
Rowley 1969 single H: 150,000 - 169,999
Stone 1978 single I: 170,000 - 189,999
9 rows selected.
If MARY queries the SH.CUSTOMERS table from outside the corporate network, the security
sensitive columns are not visible and VPD will set them to NULL in the result set returned:
mary@aos> show the Connection_Type factor and session context
mary@aos>SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type
, DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method
, DVSYS.GET_FACTOR('Client_IP') Client_IP
FROM DUAL;
CONNECTION_TYPE AUTHENTICATION_METHO CLIENT_IP


OTHER PASSWORD 10.10.10.10
1 row selected.
mary@aos> query the SH.CUSTOMERS table
mary@aos> SELECT
cust_last_name
, cust_year_of_birth
, cust_marital_status
, cust_income_level
FROM sh.customers
WHERE cust_state_province = 'TX'
AND ROWNUM < 10
ORDER BY cust_last_name
/