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