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

Use cases can be categorized as follows: Application transactions business use cases Application batch processes business use cases Application reporting business use cases Database admi

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

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

-

-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

■

■

■

■

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 (+)

/

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

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