Applied Oracle Security: Developing Secure Database and Middleware Environments- P32 pot

284 Part II: Oracle Database Vault If the operational DBA were to attempt to set one of these DBV SARs back on the database server, the DBV rule set would return false and the attempt would be blocked based on the lack of a valid certificate for the session and because jean_oper_dba is not a sales department manager. jean_oper_dba@aos>BEGIN dvsys.dbms_macsec_roles.set_role('SALES_WEB_SERVICE_APP_ROLE'); END; / BEGIN * ERROR at line 1: ORA-47305: Rule Set violation on SET ROLE (Can Set Sales Secure Application Role) ORA-06512: at "DVSYS.DBMS_MACUTL", line 38 ORA-06512: at "DVSYS.DBMS_MACUTL", line 381 ORA-06512: at "DVSYS.DBMS_MACSEC", line 242 ORA-06512: at "DVSYS.ROLE_IS_ENABLED", line 4 ORA-06512: at "DVSYS.DBMS_MACSEC_ROLES", line 24 ORA-06512: at line 2 One final note on the use of DBV SARs follows from this final test. It is important that you ensure that the roles, privileges, and transactions you are attempting to protect with a DBV SAR cannot be accessed through some other means. Summary In this chapter we examined the detailed requirements for a new database application to introduce techniques and patterns for determining DBV security controls that could be applied to the design of the new application. The goal of this chapter was to help you increase the overall security posture of a new application by applying these techniques and patterns during the early stages of the development lifecycle no matter which software methodology your organization employs. It is important for you to focus on the key drivers of security for your enterprise and understand the penalty for not applying security. There is a cost for security, there is a cost for not applying security, and there is cost of not applying enough security. Applying security is a risk management process that must evaluate the cost and effort versus the risk of a security incident occurring. The costs of not applying security (or enough of it) can include the following: Financial penalties Loss of credibility of the organization Personal liability Loss of stock holder trust Loss of customer loyalty You have seen some techniques and examples within this chapter on how to apply DBV to your application to meet compliance requirements and reduce your risks. The first technique involved decomposing the requirements to discover the application’s core data objects and users. This will help you identify DBV realm protections and the associated DBV realm authorizations. Once the objects were identified, we recommended patterns for designing audit policies and row- level security policies to complement the DBV realm protections. ■ ■ ■ ■ ■ Chapter 6: Applied Database Vault for Custom Applications 285 We presented a fine-grained pattern for defining the required database and application administrators that must be authorized in the DBV realms. We urged you to define areas of responsibilities for your application realm administrators and map the privilege sets defined by this fine-grained pattern to each area. The fine-grained pattern that was presented will enable you to meet separation of duty requirements that are part of compliance regulations or a consolidation effort. This pattern can also be collapsed into a more coarse-grained pattern depending on how stringent your compliance regulations are or how constrained you are from a personnel perspective in a consolidation effort. Decomposing the requirements also helps uncover business rules and conditions that form the basis for DBV command rules and DBV rule sets. We recommend a Subject-Verb-Object- Condition table technique similar to conventions used in the security evaluation of an IT product. This technique was demonstrated with a handful of notional use cases. However, you should consider all of your business application use cases and system use cases (such as upgrades and backup/recovery database administration tasks) when employing this technique. Use cases can be categorized as follows: Application transactions (business use cases) Application batch processes (business use cases) Application reporting (business use cases) Database administration (system use cases) Database connection rules (business use cases and system use cases) The business rules and conditions that were uncovered using this technique will also help you identify the DBV factors that can be created and shared among your applications. We presented a collection of patterns for DBV factors that can help you discover and categorize factors as they relate to conflict of interest, separation of duty, organization policy, identity management, operational context, time, and external events. We also presented examples of how you can incorporate these factors in your RLS controls (VPD, OLS, views), PL/SQL code, and FGA policies. We concluded this chapter with a recommendation to use DBV SARs when operations are highly sensitive or potentially risky but are not used frequently. DBV SARs are also recommended when a connection pool account is used to assert multiple database roles with different privileges based on the operational context of a web-based application. ■ ■ ■ ■ ■ This page intentionally left blank CHAPTER 7 Applied Database Vault for Existing Applications 287 288 Part II: Oracle Database Vault hapter 6 introduced you to techniques and patterns for designing DBV security controls as part of a custom application development effort. In this chapter, we present several techniques for analyzing existing applications that need additional security controls. This might be the case, for example, for an organization that must comply with regulations and is looking to products such as DBV to help in this effort. The ability to apply DBV security policy to existing applications is a powerful feature that many customers should consider. It is driven by the fact that DBV enforcement runs within the database kernel and is applied to all SQL commands that are submitted to the database, regardless of the programming language or development product used to write the application. The DBV enforcement engine and its underlying security policy configuration are external to the application and create a unique opportunity to secure applications without changing the underlying application code. Applying DBV to existing applications is an exercise that involves people, documentation, and technology. The technical experts for an existing application can quickly identify the sensitive mission-critical data managed in the database that would be a candidate for protection by DBV realms. Application experts can identify the accounts/roles used in the database to help determine which DBV realm authorizations and DBV Secure Application Roles (SARs) may be required. These experts can also identify many of the business rules that are embedded in application code or part of the procedures used to manage the system, which can be transformed into DBV command rules. Once business rules and DBV command rules are identified, you can make use of DBV factors for security-related attributes that are commonly used. If you have access to system engineering or design documentation, you can often shortcut the analysis to determine which object-owner accounts need to be considered for your protection profile. System documentation can be used to help validate the information supplied by the experts or to develop the initial drafts of a DBV policy that can be reviewed by the experts. This is especially helpful when experts have time constraints. Finally, you can leverage the audit technology and configuration data available in the Oracle database to develop an initial draft of the DBV policy. This chapter focuses on the details of the latter approach as we can provide a generalized mechanism/process of capturing this information that applies to any system. You must first profile usage of system privileges and object privileges using the native Oracle database auditing. You can do this by auditing all accounts in the database or a set of targeted accounts you have identified. Once you’ve completed interviews of application experts, reviewed system documentation, and profiled auditing in the database, you can perform the same type of analysis presented in Chapter 6. Specifically, you can develop a fine-grained security profile complete with Subject- Verb-Object-Condition tables for the various system use cases. Audit Capture Preparation Connect to the database as SYS and identify the location of the database AUDIT_TRAIL: sys@aos>SHOW PARAMETER audit_trail NAME TYPE VALUE audit_trail string DB C Chapter 7: Applied Database Vault for Existing Applications 289 If the location is DB, DB EXTENDED, XML, or XML,EXTENDED, you are ready to go. If the location is set to NONE, you need to enable auditing by issuing the following command, and then you need to restart the database: sys@aos>ALTER SYSTEM SET audit_trail = DB SCOPE = spfile; System altered. Once the audit location has been verified or configured, you can enable auditing for all database sessions by issuing the following command: sys@aos>AUDIT ALL BY ACCESS; Audit succeeded. If you know beforehand which accounts are object-owner accounts and which accounts are connection pool accounts, you can achieve more targeted results that limit the amount of audit data created using the same approach. For example, if you consider the examples presented in this book, you may specify the object-owner accounts SH, HR, and OE and the application server pool account, OPS$APPSERVER_1, in the AUDIT command as follows: sys@aos>AUDIT ALL BY sh, hr, oe, ops$appserver_1 BY ACCESS; Audit succeeded. Once the audit capture process is complete, you can return the audit policy configuration to the original state by issuing the following command when you’re auditing all database sessions: sys@aos>NOAUDIT ALL; Noaudit succeeded. You can return the audit policy configuration to the original state by issuing the following command when auditing only a subset of accounts: sys@aos>NOAUDIT ALL BY sh, hr, oe, ops$appserver_1; Noaudit succeeded. Capturing Audits The next step is to exercise all web applications, desktop applications, and batch programs that access the database. You should exercise all possible transactions in the system to ensure that a complete representation of the access paths to the data is captured in the audit trail. These types of tests would exercise the category of use cases known as “business use cases.” You should also exercise all system use cases that may include the following: Database account management and provisioning processes that include privilege management using GRANT and REVOKE commands Backup/recovery operations General database administration tasks such as storage management or performance tuning that occur periodically using tools such as SQL*Plus or Oracle Enterprise Manager Application patching or upgrades Database patching or upgrades ■ ■ ■ ■ ■ 290 Part II: Oracle Database Vault If your audit capture process includes the use Oracle Real Application Testing workload capture feature, you can replay the workload at a later point in time against your development and deployment systems. This process provides a higher level of assurance that the DBV policy developed does not adversely affect the database applications as the results for a replayed workload would differ from the baseline. We also recommend that you perform the complete testing with Oracle Real Application Testing technology and capture a workload baseline for each category of use cases. You should capture separate workload baselines for each type of use cases—for example, one baseline for web applications, one for batch programs, one for backup/ recovery operations, and so on. This improves your efficiency in validating the deployment of the DBV policy as you can just replay the baselines that are adversely affected. Analyzing the Audit Trail Now you have captured audit data while the complete transaction profile was run against the database. If your AUDIT_TRAIL initialization parameter is set to any of the following values, you can query the view DBA_COMMON_AUDIT_TRAIL for audit data that will help you identify parameters for your candidate DBV policy: DB DB, EXTENDED XML XML, EXTENDED Many queries will use join information from the DBA_COMMON_AUDIT_TRAIL view, the DBA_OBJECTS view, and the AUDIT_ACTIONS table. To simplify the complexity of the queries presented in this section, we’ve taken the liberty of including a view named AOS_COMMON_ AUDIT_TRAIL that already has the required joins. The view definition is as follows: sys@aos> CREATE OR REPLACE VIEW aos_common_audit_trail AS SELECT aud.audit_type , aud.session_id , aud.proxy_sessionid , aud.statementid , aud.entryid , aud.extended_timestamp , aud.global_uid , aud.db_user , aud.client_id , aud.econtext_id , aud.ext_name , aud.os_user , aud.userhost , aud.os_process , aud.terminal , aud.instance_number ■ ■ ■ ■ Chapter 7: Applied Database Vault for Existing Applications 291 , aud.object_schema , aud.object_name , aud.policy_name , aud.new_owner , aud.new_name , aud.action , aud.statement_type , aud.audit_option , aud.transactionid , aud.returncode , aud.scn , aud.comment_text , aud.sql_bind , aud.sql_text , aud.obj_privilege , aud.sys_privilege , aud.admin_option , aud.os_privilege , aud.grantee , aud.priv_used , aud.ses_actions , aud.logoff_time , aud.logoff_lread , aud.logoff_pread , aud.logoff_lwrite , aud.logoff_dlock , aud.session_cpu , aud.obj_edition_name , act.name action_name , obj.subobject_name , obj.object_id , obj.data_object_id , obj.object_type , obj.created , obj.last_ddl_time , obj.timestamp , obj.status , obj.temporary , obj.generated , obj.secondary , obj.namespace FROM dba_common_audit_trail aud , audit_actions act , dba_objects obj WHERE aud.action = act.action (+) AND aud.object_schema = obj.owner (+) AND aud.object_name = obj.object_name (+) / View created. 292 Part II: Oracle Database Vault DBV Realms from Object-Owner Accounts The following query will help you narrow the list of object-owner accounts that may own sensitive data that is accessed using a SELECT, DML, or EXECUTE command. The query filters out objects owned by system accounts such as SYS, DVSYS, and LBACSYS. sys@aos>SELECT DISTINCT object_schema FROM aos_common_audit_trail WHERE object_schema NOT IN ( 'SYS','SYSMAN','DVF','DVSYS','LBACSYS','WK_TEST') AND ( action_name IN ( 'SELECT' ,'UPDATE' ,'DELETE' ,'INSERT' ) OR action_name LIKE '%EXECUTE%') AND object_type NOT LIKE '%PARTITION%' AND extended_timestamp > sysdate - 1 ORDER BY object_schema; OBJECT_SCHEMA HR SH 2 rows selected. This query was run against the database we’ve been leveraging in the examples for the past two chapters and confirms that the query can be used to identify object-owner accounts, as we know both the Sales History (SH) and Human Resources (HR) schemas own objects with sensitive data. The results of the query provide a candidate list for the DBV realms we may need to create. DBV Realm Secured Objects We can now identify which objects in each object-owner account may need to be secured by a DBV realm by issuing the following query for the object-owner accounts: sys@aos> SELECT DISTINCT object_schema, object_type, object_name FROM aos_common_audit_trail WHERE object_schema IN ('SH', 'HR') AND ( action_name IN ( 'SELECT' ,'UPDATE' ,'DELETE' ,'INSERT' ) OR action_name LIKE '%EXECUTE%') AND object_type NOT LIKE '%PARTITION%' AND extended_timestamp > sysdate - 1 ORDER BY object_schema, object_type, object_name; OBJECT_SCHEMA OBJECT_TYPE OBJECT_NAME HR PACKAGE EMPLOYEE_UTILITY HR PACKAGE BODY EMPLOYEE_UTILITY SH PACKAGE SALES_TRANSCTION SH PACKAGE BODY SALES_TRANSCTION Chapter 7: Applied Database Vault for Existing Applications 293 SH TABLE CHANNELS SH TABLE COSTS SH TABLE CUSTOMERS SH TABLE PRODUCTS SH TABLE PROMOTIONS SH TABLE SALES 10 rows selected. The results of this query can be used to limit the objects that are protected by the candidate DBV realms, or you can choose to protect the entire object-owner schema (OBJECT_SCHEMA) and all the objects owned by the account. This decision depends on the number of objects that are returned for each OBJECT_SCHEMA and the knowledge you have of the other objects that are not returned from the query. If a large number of objects are returned from the query for a given object-owner account, you can protect the all the objects in the account to simplify maintenance of the DBV policy. Identify Realm Objects Based on Object-level Auditing We can identify sensitive data objects that should be protected by a DBV realm by examining the existing object-level auditing that is configured in the database. If the database designer or database engineer had the wherewithal to audit an application’s table or object, it must be sensitive enough to warrant auditing. The following query helps identify the objects that are being audited in the Oracle database. The query filters out those objects stored in off-the-shelf Oracle object-owner accounts that would not normally be audited by an application. In this example, you see results for the SH object-owner account based on the audit policy we recommended in Chapter 6. You can also examine the Oracle database configuration to determine whether any Oracle fine-grained auditing (FGA) policies are defined for object-owner accounts. The same argument used earlier to justify querying the core RDBMS object audit policy tables applies to FGA policies: sys@aos>SELECT DISTINCT owner , object_name , object_type FROM dba_obj_audit_opts WHERE owner NOT IN ( 'DVF','DVSYS','LBACSYS','SYS','SYSTEM') ORDER BY 1,2,3; OWNER OBJECT_NAME OBJECT_TYPE SH COSTS TABLE SH SALES TABLE 2 rows selected. In this example, you can see that an Oracle FGA policy exists on the OE.CUSTOMERS table, and this leads us to believe that the OE object-owner account also contains sensitive objects that require the protection of a DBV realm: sys@aos>SELECT DISTINCT object_schema , object_name FROM dba_audit_policies; . intentionally left blank CHAPTER 7 Applied Database Vault for Existing Applications 287 288 Part II: Oracle Database Vault hapter 6 introduced you to techniques and patterns for designing DBV security. driven by the fact that DBV enforcement runs within the database kernel and is applied to all SQL commands that are submitted to the database, regardless of the programming language or development. Preparation Connect to the database as SYS and identify the location of the database AUDIT_TRAIL: sys@aos>SHOW PARAMETER audit_trail NAME TYPE VALUE audit_trail string DB C Chapter 7: Applied Database Vault