344 Part II: Oracle Database Vault However, an operational DBA can use EXPLAIN PLAN without being authorized in the realm to determine whether query or storage optimization techniques need to be applied to resolve performance issues. an operational DBA cannot query the realm protected data and analyze with AUTOTRACE ON jean_oper_dba@aos>SET AUTOTRACE ON jean_oper_dba@aos>SELECT COUNT(*) FROM app_object_owner.customers WHERE state_province = 'VA' ; 2 3 FROM app_object_owner.customers * ERROR at line 2: ORA-01031: insufficient privileges jean_oper_dba@aos>EXPLAIN PLAN FOR SELECT COUNT(*) FROM app_object_owner.customers WHERE state_province = 'VA' / Explained. query the EXPLAIN PLAN data to retrieve the diagnostic information SELECT plan_table_output FROM TABLE(dbms_xplan.display); PLAN_TABLE_OUTPUT Plan hash value: 296924608 | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | | 0 | SELECT STATEMENT | | 1 | 11 | 898 (1)| 00:00:11 | | 1 | SORT AGGREGATE | | 1 | 11 | | | |* 2 | TABLE ACCESS FULL| CUSTOMERS | 383 | 4213 | 898 (1)| 00:00:11 | Predicate Information (identified by operation id): PLAN_TABLE_OUTPUT 2 - filter("STATE_PROVINCE"='VA') 14 rows selected. Advanced Monitoring and Alerting with a DBV Database In this section, we present some exciting new features that are available in the latest version of the OEM GC product. These features offer centralized monitoring, audit reporting, and alerting for all DBV-enabled databases in your enterprise. They also enable the macro-level auditing type view Chapter 7: Applied Database Vault for Existing Applications 345 of the enterprise security posture that was first introduced in Chapter 2. We conclude the section with a simple example of how you can extend the DBV Rule Set component to integrate your existing monitoring and alerting systems with context-sensitive information regarding DBV policy violations that occur. Monitoring and Alerting on DBV with OEM GC Another useful feature added to OEM GC 10.2.0.5 is the ability to monitor and alert on DBV policy changes, DBV configuration issues, and DBV policy violations in the target databases it monitors. The product defines several metrics in these categories that are collected on an ongoing basis, as shown in Figure 7-8. When an alert is generated from one of these metrics, it is displayed on the target DBV database’s home page in OEM GC providing a real-time, comprehensive view of what may have occurred. This home page display is depicted in Figure 7-9. For each alert that is presented, the administrators of the systems can choose to acknowledge the alert and add comments related to the research and resolution of the issue. When the alert has been fully resolved, the primary administrator or compliance officer can choose to clear the alert. The alert tracking capability is shown in Figure 7-10. OEM GC allows you to log into each DBV-enabled database to view summary statistics, charts, and target-specific alerts for the database, as depicted in Figure 7-11. The target-centric interface also allows you to generate reports using a variety of filter controls to investigate the offending account, SQL commands, and time frame that caused a policy violation as you investigate an alert. This reporting interface is shown in Figure 7-12. FIGURE 7-8 DBV metric collection parameters in OEM GC 346 Part II: Oracle Database Vault FIGURE 7-9 Alerts for a DBV database in OEM GC FIGURE 7-10 Responding to DBV alerts in OEM GC Chapter 7: Applied Database Vault for Existing Applications 347 FIGURE 7-11 Database-specific DBV statistics in OEM GC FIGURE 7-12 Fine-grained reporting on DBV policy violations in OEM GC The monitoring and alerting of DBV policy changes, DBV configuration issues, and DBV policy violations in OEM GC provide real-time visibility into potential security issues in your databases. The ability to document the process of responding to these issues provides added value to your compliance reporting needs as OEM GC keeps track of the historical nature of this process. 348 Part II: Oracle Database Vault Extending the DBV Rule Set Custom Event Handler Chapter 5 presented a simple example of how you can develop custom PL/SQL handler routines that handle the event that a rule set returns false (or true!) when used as part of a DBV command rule. The DBV command rule allowed only UPDATE commands on the SH.SALES table when they came from the PL/SQL package procedure SH.SALES_TRANSACTION. In this example, we wrote a message to the table SH.ALERTS indicating that an event had occurred. An alerting mechanism also needs to have detailed information on the actual security-relevant event that occurred. We can use DBV rule set event functions and application context within the rule expressions used in DBV rule sets to provide this information. The rule will write the details of the security-relevant event based on the data returned from the DBV rule set event functions to an application context namespace as part of the initial evaluation of the rule. We can subsequently read this information from the application context in the rule set’s custom event handler procedure. The first thing we need to do is update our rule definition to pass the DBV rule set event function values into the function we use to authorize the command: diego_dbvmgr@aos> update the conditional rule that states diego_dbvmgr@aos> we are using the trusted application code diego_dbvmgr@aos> to pass the event functions, save them in diego_dbvmgr@aos> context so they are accessible from the diego_dbvmgr@aos> custom event handler diego_dbvmgr@aos>BEGIN dbms_macadm.update_rule( rule_name => 'Called From Sales Transaction Package' , rule_expr => 'sh.sales_rules.update_allowed( DVSYS.DV_SYSEVENT' || ',DVSYS.DV_LOGIN_USER' || ',DVSYS.DV_INSTANCE_NUM' || ',DVSYS.DV_DATABASE_NAME' || ',DVSYS.DV_DICT_OBJ_TYPE' || ',DVSYS.DV_DICT_OBJ_OWNER' || ',DVSYS.DV_DICT_OBJ_NAME' || ',DVSYS.DV_SQL_TEXT) > 0' ); END; / PL/SQL procedure successfully completed. The PL/SQL package DBVEXT.DBMS_MAC_EXTENSION that is part of the example source code provided with this book includes a procedure that can write this information to an application context with the namespace SQL_EVENT. The procedure has the following signature: PROCEDURE set_event_context( command IN VARCHAR2 , session_user IN VARCHAR2 , instance_num IN NUMBER , database_name IN VARCHAR2 , obj_type IN VARCHAR2 , obj_owner IN VARCHAR2 , obj_name IN VARCHAR2 , sql_text IN VARCHAR2 ) ; Chapter 7: Applied Database Vault for Existing Applications 349 DBVEXT must grant execute on this package to the SH for the object-owner account to use the SET_EVENT_CONTEXT procedure that is defined in the package: diego_dbvmgr@aos>CONNECT dbvext Enter password: Connected. dbvext@aos>GRANT EXECUTE ON dbvext.dbms_mac_extension TO sh; Grant succeeded. The next step is to update the function we use to authorize the command, SH.SALES_RULES. UPDATE_ALLOWED, to have these new parameters passed to it. We will use our Application Maintenance Administrator account from Chapter 6 for this task. dbvext@aos>CONNECT mark_maint_mgr Enter password: Connected. mark_maint_mgr@aos> create a rules package procedure mark_maint_mgr@aos> that accepts the event state and mark_maint_mgr@aos> execute rule-specific decisions in one expression mark_maint_mgr@aos>CREATE OR REPLACE PACKAGE sh.sales_rules AS FUNCTION update_allowed( command IN VARCHAR2 , session_user IN VARCHAR2 , instance_num IN NUMBER , database_name IN VARCHAR2 , obj_type IN VARCHAR2 , obj_owner IN VARCHAR2 , obj_name IN VARCHAR2 , sql_text IN VARCHAR2 ) RETURN NUMBER; END; / Package created. mark_maint_mgr@aos> create a rules package body mark_maint_mgr@aos> that uses the DBVEXT procedure mark_maint_mgr@aos> to save the event state to mark_maint_mgr@aos> the application context SQL_EVENT mark_maint_mgr@aos>CREATE OR REPLACE PACKAGE BODY sh.sales_rules AS FUNCTION update_allowed( command IN VARCHAR2 , session_user IN VARCHAR2 , instance_num IN NUMBER , database_name IN VARCHAR2 , obj_type IN VARCHAR2 , obj_owner IN VARCHAR2 , obj_name IN VARCHAR2 , sql_text IN VARCHAR2 ) RETURN NUMBER IS BEGIN validate and set event context 350 Part II: Oracle Database Vault dbvext.dbms_mac_extension.set_event_context( command => command , session_user => session_user , instance_num => instance_num , database_name => database_name , obj_type => obj_type , obj_owner => obj_owner , obj_name => obj_name ensure we have first 4K only , sql_text => SUBSTR(sql_text,1,4000) ); put the original business rules here RETURN INSTR(UPPER(DBMS_UTILITY.FORMAT_CALL_STACK), 'PACKAGE BODY SH.SALES_TRANSCTION'); EXCEPTION WHEN OTHERS THEN ITS A GOOD IDEA TO GIVEN ERROR CODE FOR ANY EXCEPTION THAT OCCURS RETURN -1 * ABS(SQLCODE); END; END; / Package body created. The next step is to update our rule set’s custom event handler to read the event details from application context and process them. In this example, we will keep it simple and just write them to the SH.ALERTS table: mark_maint_mgr@aos>CREATE OR REPLACE PACKAGE BODY sh.sales_alerts AS PROCEDURE sales_update_alert( ruleset_name IN VARCHAR2 , ruleset_result IN VARCHAR2) IS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN INSERT INTO sh.alerts (msg ) VALUES ('Alert for Rule Set:' || ruleset_name); INSERT INTO sh.alerts (msg ) VALUES ('result is ' || ruleset_result); INSERT INTO sh.alerts (msg ) VALUES ('event is ' || sys_context('SQL_EVENT','COMMAND')); INSERT INTO sh.alerts (msg ) VALUES ('user is ' || sys_context('SQL_EVENT','USER')); INSERT INTO sh.alerts (msg ) VALUES ('instance is ' || sys_context('SQL_EVENT','INSTANCE')); INSERT INTO sh.alerts (msg ) VALUES ('database is ' || sys_context('SQL_EVENT','DATABASE')); INSERT INTO sh.alerts (msg ) VALUES ('object type is ' || sys_context('SQL_EVENT','OBJECT_TYPE')); INSERT INTO sh.alerts (msg ) VALUES Chapter 7: Applied Database Vault for Existing Applications 351 ('owner is ' || sys_context('SQL_EVENT','OWNER')); INSERT INTO sh.alerts (msg ) VALUES ('object name is ' || sys_context('SQL_EVENT','OBJECT_NAME')); INSERT INTO sh.alerts (msg ) VALUES ('SQL text is "' || sys_context('SQL_EVENT','SQL_TEXT') || '"'); COMMIT; END; END; / Package body created. The final preparation step is to make sure we revalidate our DBV rule sets as follows: mark_maint_mgr@aos>CONNECT diego_dbvmgr Enter password: Connected. diego_dbvmgr@aos> verify the DBV Rule Sets are valid! diego_dbvmgr@aos> exec dbms_macadm.sync_rules; PL/SQL procedure successfully completed. We are now ready to test our solution using the realm’s Application Data Administrator from Chapter 6 as the trouble-maker! diego_dbvmgr@aos>CONNECT deb_data_mgr Enter password: Connected. deb_data_mgr@aos> force the Command Rule violation deb_data_mgr@aos> UPDATE sh.sales SET amount_sold = 200 WHERE cust_id = 305; 2 3 UPDATE sh.sales * ERROR at line 1: ORA-01031: insufficient privileges deb_data_mgr@aos> view the alert table deb_data_mgr@aos>SELECT msg FROM sh.alerts ORDER BY msgdate; MSG Alert for Rule Set:Using Financials Application result is FALSE event is UPDATE user is DEB_DATA_MGR SQL text is "UPDATE SH.SALES SET AMOUNT_SOLD = 200 WHERE CUST_ID = 305" database is ENSG.US.ORACLE.COM object type is TABLE owner is SH 352 Part II: Oracle Database Vault object name is SALES instance is 1 10 rows selected. We could perform just about any integration with this handler mechanism when we consider the use of the standard Oracle PL/SQL packages such as UTL_TCP, UTL_HTTP, and UTL_SMTP or features such as external stored procedures and Java stored procedures. DBV realm authorizations are binary (allow/disallow) control unless coupled with a DBV rule set. We can use the same approach of passing the DBV rule set event function values to a function to provide a fine-grained control of realm authorizations that are based on these values. In other words, we can define an application-specific function for use in a DBV realm authorization’s rule set rules as follows: FUNCTION authorize_in_app_realm( command IN VARCHAR2 , session_user IN VARCHAR2 , instance_num IN NUMBER , database_name IN VARCHAR2 , obj_type IN VARCHAR2 , obj_owner IN VARCHAR2 , obj_name IN VARCHAR2 , sql_text IN VARCHAR2 ) RETURN NUMBER; This allows us to build case-like statements or table-driven controls in this function that handle command-specific, owner-specific, object-specific, or exception criteria in existing applications once we protect data with a realm. Summary In this chapter, we presented techniques for developing DBV policies that can be applied to existing Oracle database applications. DBV policies can be transparently applied to all SQL commands submitted to the database, regardless of the technology used to build the application. This represents an opportunity for you to increase the security posture of your applications without rewriting code. The following might prompt you to add DBV protections to your applications: Your organization is striving to meet compliance regulations such as separation of duties or information privacy in the applications. Your organization is undergoing a database consolidation effort and security must be applied to achieve separation of control and to reduce the risk of insider threats or external attacks. The primary technique used in this chapter to identify the candidate DBV policy involves enabling core database auditing for all transactions and then exercising the applications to develop a transaction profile. Once the transaction profile has been created, we demonstrate how you can query it to uncover the candidate DBV policy. We augmented the queries on the transaction profile with additional queries on security-relevant database configuration views to refine the candidate DBV policy. ■ ■ Chapter 7: Applied Database Vault for Existing Applications 353 The transaction profile includes object-owner account names and object names that form the basis of DBV realm protections. You can validate the list of sensitive objects by examining existing audit policies and row-level security policies. Roles associated with a database account are listed as database clients, and the use of system ANY privileges provides insight into which database roles should be authorized in a DBV realm and which database roles should protected by a DBV realm. We included a technique to help you map existing database roles to the Application Administrator roles pattern we recommended in Chapter 6. You can even integrate these Application Administrator roles with an external resource such as OID using the Oracle EUS technology. The transaction profile can be used to develop the candidate Subject-Verb-Object-Conditions table that we recommended in Chapter 6. This table serves as the basis for candidate DBV command rules and DBV rule sets. Queries presented to develop this table gave you insight into the most sensitive transactions in your database. We’ve included an example of how to externalize the authorization of these sensitive transactions with a mechanism that was controlled outside of the database. We concluded the analysis techniques with queries on both the transaction profile and the security-relevant database configuration views to identify DBV factors based on identity management, operational context, time, and external events. Inspecting documentation from existing applications can assist in augmenting analysis, but we recommend that you review your candidate DBV policy with the technical experts of the applications and databases involved. These experts have the greatest knowledge about how a system works and what the impact(s) might be if you add layers of security to an existing application or a database. We have also demonstrated how the Oracle Real Application Testing feature can be used to validate that your applications continue operating normally under DBV policy control using real-world transactions and workloads. The use of the newly released OEM GC DBV policy provisioning capabilities will reduce the time and risk in deploying the new DBV policy to test and production environments. Your applications and database may be using any number of existing database features and administration tools, such as Oracle Text, Oracle Spatial, RMAN, and TDE. We included tips and techniques to ensure that these database features and the new Oracle DBV policy controls work together. Finally, we encourage you to consider the newly released monitoring and alerting features in the OEM GC product for DBV policy changes, DBV configuration issues, and DBV policy violations. These features are critical to tracking and reporting on security-relevant issues that could impact your ability to meet compliance regulations and protect against attacks. . techniques for developing DBV policies that can be applied to existing Oracle database applications. DBV policies can be transparently applied to all SQL commands submitted to the database, regardless. administration tools, such as Oracle Text, Oracle Spatial, RMAN, and TDE. We included tips and techniques to ensure that these database features and the new Oracle DBV policy controls work. reduce the time and risk in deploying the new DBV policy to test and production environments. Your applications and database may be using any number of existing database features and administration