Applied Oracle Security: Developing Secure Database and Middleware Environments- P35 pptx

USERNAME EVENT OWNER OBJECT STATUS--- --- --- --- ---MARY DELETE SH % 1 1 row selected dvf@aos>-- create a helper package for DBV Rule Sets that dvf@aos>-- can query the OET dvf@aos> CR

ORGANIZATION EXTERNAL

(TYPE ORACLE_LOADER

DEFAULT DIRECTORY dbv_dir_log

ACCESS PARAMETERS

(

RECORDS DELIMITED BY NEWLINE

BADFILE 'dbv_auth.bad'

DISCARDFILE 'dbv_auth.dis'

LOGFILE 'dbv_auth.log'

FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"'

(

username CHAR(30)

, event CHAR(30)

, owner CHAR(30)

, object CHAR(130)

, status INTEGER EXTERNAL(6)

)

)

LOCATION (DBV_DIR:'external_authorize.conf')

)

REJECT LIMIT UNLIMITED

/

Table created.

The decision concept around the OET is that we can model the Subject-Verb-Object portion of

a security profile directly in the OET using the USERNAME/EVENT/OWNER and OBJECT columns and use the STATUS column as an indicator of TRUE(1) or FALSE(0) to allow the command The conditional aspect of our profile is satisfied by the file owner (root, in this example) controlling when the commands are authorized on any given object The table is empty at this point, but if we populate the underlying comma-separated-values (CSV) file as the root OS account we will see the data in the table

[root@node1 ~] #echo "MARY,DELETE,SH,%,1" > /etc/dbv/external_authorize.conf

In this example we model the concept that the USERNAME MARY is allowed (STATUS=1) to execute a DELETE (EVENT) on any (OBJECT) whose OWNER is SH If we attempt to update this file with the Oracle OS account, the OS file’s permissions prevent the attempt:

[oracle@node1 ~]$ echo "ANTHONY,DELETE,SH,%,1" > /etc/dbv/external_authorize.conf -bash: /etc/dbv/external_authorize.conf: Permission denied

This is a simple example that makes use of the root and Oracle OS accounts Note that technologies such as fine-grained OS access control lists, based on IEEE’s POSIX 1003 standards, would offer a solution that uses a non-root account as the file owner, but for brevity we simply used the root account

With this file populated, we can now query the external table as the DBVEXT object-owner account and create a PL/SQL package that can be used in DBV rule sets:

dvf@aos> query the populated OET

dvf@aos>SELECT * FROM dbvext.external_authorize;

USERNAME EVENT OWNER OBJECT STATUS

- - - -

-MARY DELETE SH % 1

1 row selected

dvf@aos> create a helper package for DBV Rule Sets that

dvf@aos> can query the OET

dvf@aos> CREATE OR REPLACE PACKAGE external_rule AS

FUNCTION authorized(

user_name IN VARCHAR2

, event_name IN VARCHAR2

, owner_name IN VARCHAR2 DEFAULT '%'

, object_name IN VARCHAR2 DEFAULT '%'

) RETURN NUMBER;

END;

/

Package created.

dvf@aos>CREATE OR REPLACE PACKAGE BODY external_rule AS

FUNCTION authorized(

user_name IN VARCHAR2

, event_name IN VARCHAR2

, owner_name IN VARCHAR2

, object_name IN VARCHAR2

) RETURN NUMBER

IS

BEGIN

FOR c_rules IN (

SELECT username

FROM external_authorize

WHERE UPPER(event) = UPPER(event_name)

AND UPPER(owner) = UPPER(owner_name)

AND UPPER(object) = UPPER(object_name)

AND status = 1

) LOOP

IF UPPER(c_rules.username) = UPPER(user_name) THEN

RETURN 1;

END IF;

note that we could event use the package procedure

DBVEXT.DBMS_MAC_EXTENSION.USER_HAS_ROLE here to base

the authorization on role names store in CSV file

END LOOP;

RETURN 0;

EXCEPTION

WHEN OTHERS THEN

RAISE_APPLICATION_ERROR(-20001, 'external_rule (error):' ||

SUBSTR(SQLERRM, 1 , 2000) );

RETURN 0;

END;

/

Package body created.

dvf@aos> grant EXECUTE privilege on the package to DVSYS as always

dvf@aos>GRANT EXECUTE ON dbvext.external_rule TO dvsys;

Grant succeeded.

Finally, we create the DBV rule set and an example DBV command rule that uses our OET-based package function

dvf@aos>CONNECT diego_dbvmgr

Enter password:

Connected.

diego_dbvmgr@aos> create the DBV Rule for DELETE on an SH objects

diego_dbvmgr@aos>BEGIN

dbms_macadm.create_rule(

rule_name => 'Externally Controlled DELETE for Sales History'

,rule_expr =>

'DBVEXT.EXTERNAL_RULE.AUTHORIZED(DVSYS.DV_LOGIN_USER,'

|| '''DELETE'',''SH'',''%'') = 1'

);

END;

/

PL/SQL procedure successfully completed.

diego_dbvmgr@aos> create the DBV Rule Set and

diego_dbvmgr@aos> associate our DBV Rule to it

diego_dbvmgr@aos>BEGIN

dbms_macadm.create_rule_set(

rule_set_name =>'Sales History DELETE Controls',

description =>'Authorizes deletes against the

Sales History tables.',

enabled =>dbms_macutl.g_yes,

eval_options =>dbms_macutl.g_ruleset_eval_all,

audit_options =>dbms_macutl.g_ruleset_audit_fail,

fail_options =>dbms_macutl.g_ruleset_fail_show,

fail_message =>NULL,

fail_code =>NULL,

handler_options =>dbms_macutl.g_ruleset_handler_off,

handler =>NULL);

END;

/

PL/SQL procedure successfully completed.

diego_dbvmgr@aos>BEGIN

dbms_macadm.add_rule_to_rule_set (

rule_set_name => 'Sales History DELETE Controls'

, rule_name => 'Externally Controlled DELETE for Sales History'

);

END;

/

PL/SQL procedure successfully completed.

dbms_macadm.create_command_rule (

command => 'DELETE'

,rule_set_name => 'Sales History DELETE Controls'

,object_owner => 'SH'

,object_name => '%'

,enabled => 'Y'

);

END;

/

PL/SQL procedure successfully completed.

We can test the control using the realm administrator account MARY to verify that the DELETE command is allowed We can also verify that the DELETE command is not allowed for an

EUS-based realm administrator such as JOE, who was authorized to do this EUS-based on the earlier realm authorization example

diego_dbvmgr@aos>CONNECT mary

Enter password:

Connected.

mary@aos>DELETE SH.COSTS WHERE ROWNUM < 2;

1 row deleted.

If we change the status

mary@aos>CONNECT joe

Enter password:

Connected.

global_oid_tree1@aos>DELETE SH.COSTS WHERE ROWNUM < 2;

DELETE SH.COSTS WHERE ROWNUM < 2

*

ERROR at line 1:

ORA-01031: insufficient privileges

We can also disable the ability for MARY to perform the sensitive transaction using the root

OS account as follows:

[root@node1 ~]# echo "MARY,DELETE,SH,%,0" > /etc/dbv/external_authorize.conf When MARY attempts the same DELETE statement at this point, her attempt is not authorized based on the updated contents of the file:

global_oid_tree1@aos>CONNECT mary

Enter password:

Connected.

mary@aos>DELETE SH.COSTS WHERE ROWNUM < 2;

DELETE SH.COSTS WHERE ROWNUM < 2

*

ERROR at line 1:

ORA-01031: insufficient privileges

This example demonstrates how you can create an externally controlled decision point using DBV command rules for sensitive transactions using basic OS and Oracle features This type of external control is also useful when coupled with the DBV CONNECT command rule to restrict

the ability for privileged accounts to log into the database Privileged accounts such as LBACSYS

or object-owner accounts such as SH that house sensitive data can be restricted from login in the foreground Make sure you account for any database jobs the account may have by adding a

check to the PL/SQL package function DBVEXT.EXTERNAL_RULE.AUTHORIZED for the value

returned from the function

SYS_CONTEXT('USERENV', 'BG_JOB_ID')

being NOT NULL to authorize these job sessions

Identifying DBV Factors Based on Business

or System Conditions

The DBV rules we develop based on business rules or system conditions can leverage DBV factors as we had demonstrated in Chapter 6 Some types of factors you will develop can be based on the results of the queries we ran previously on the audit and database configuration You can attempt to have some questions answered by application experts to help uncover these factors

Factors Based on Compliance

Compliance-related factors are often simple constants that drive system behavior (either in code or

in DBV rules) as demonstrated with the audit retention period example in Chapter 6 In addition

to time-based constants that have units such as Number of Days, you may seek input from application experts on event-driven controls that can be controlled with a DBV factor For

example, the concept of a “quiet period” may be useful in application controls and depicts a compliance-sensitive stage or event in the context of the business itself, versus the particular application

Factors Based on Conflict of Interest or Separation of Duty

As you examine the initial Subject-Verb-Object-Condition results created from the preceding sensitive transactions query, you should be asking application experts if a single role or group of accounts is allowed to perform each type of transaction In our example for creating product costs through the SH.SALES_TRANSACTIONS package, we defined a rule “Is Sales Department

Manager” that is a perfect example of a separation of duty control Once you’ve identified the roles or accounts for each transaction, you can create factors to support these rules that enforce separation of duty on the transactions In the examples of Chapter 6, we created factors such as User_Department_Name and Is_Department_Manager to serve this purpose

Factors Based on Organizational Policy

To understand which organizational policy affects the security in a database application, you need to interview application experts The types of questions that you need to ask will be related

to data ownership, reporting requirements, and timing of key business events In the example presented in Chapter 6, we looked at the product category to determine the manager who could control sales costs or read detailed product data Similar data ownership rules may exist within your organization The controls that enforce these ownership rules can take many forms, such

as VPD policy, OLS policy, WHERE conditions in views, PL/SQL application code, and in

application code that is external to the database, such as code found in Java or ASP programs

Factors Based on Time

Factors that are based on time are useful in situations where you want to control the timeframe (WHEN) in which a sensitive transaction can take place We can examine both the database audit trail’s timestamp and schedule for database batch processing (jobs) to derive time-based factors The following query demonstrates how the audit trail can be examined for time-based factors that could be developed for a sensitive transaction

sys@aos>SELECT db_user subject, action_name verb,

object_schema || '.'|| object_name object,

TO_CHAR ( extended_timestamp, 'DAY HH24:MI') "DAY_TIME",

COUNT(*)

FROM aos_common_audit_trail

WHERE action_name = 'DELETE'

AND object_schema = 'SH'

AND object_type NOT LIKE '%PARTITION%'

GROUP BY db_user , action_name ,

object_schema || '.'|| object_name,

TO_CHAR ( extended_timestamp, 'DAY HH24:MI')

ORDER BY db_user , action_name ,

object_schema || '.'|| object_name

;

SUBJECT VERB OBJECT DAY_TIME COUNT(*)

- -

-ALAN_ANALYST DELETE SH.COSTS TUESDAY 10:50 1

DEB_DATA_MGR DELETE SH.COSTS TUESDAY 14:39 1

MARY DELETE SH.COSTS SATURDAY 15:36 1

MARY DELETE SH.SALES SATURDAY 15:33 1

OPS$APPSERVER_1 DELETE SH.SALES WEDNESDAY 14:07 1

5 rows selected.

The DELETE transactions that occurred on TUESDAY and WEDNESDAY may be out of the normal or expected time frame for this type of transaction This may point to a need to create a factor and rule for the specific time window in which a DELETE is authorized This type of control

is similar to the one we demonstrated with the SYSTEM.AUD$ table in Chapter 6

We can also identify additional areas for time-based factors by looking at the intervals

in which database jobs are executing The PL/SQL programs that are executing are typically associated with the business events that an application supports, such as the close of a month’s financial process The following query will help you identify the time frame the job intervals in which these types of PL/SQL programs are run:

sys@aos>SET SERVEROUTPUT ON

sys@aos>BEGIN

FOR c_jobs IN (

SELECT

cowner owner

, 'Job #:' || TO_CHAR(job) job_name

, interval# repeat_interval

, what program

FROM job$

UNION

SELECT

j.owner

, job_name

, decode(j.repeat_interval, NULL,

decode(s.repeat_interval, NULL,

w.window_group_name, s.repeat_interval)

,j.repeat_interval) "repeat_interval"

, decode(j.program_name,NULL

,j.job_action,p.owner || '.' || p.program_action) "program"

FROM dba_scheduler_jobs j

, dba_scheduler_programs p

, dba_scheduler_schedules s

, dba_scheduler_window_groups w

WHERE

j.program_owner = p.owner (+)

AND j.program_name = p.program_name (+)

AND j.schedule_owner = s.owner (+)

AND j.schedule_name = s.schedule_name (+)

AND j.schedule_owner = s.owner (+)

AND j.schedule_name = w.window_group_name (+)

ORDER BY 1

) LOOP

DBMS_OUTPUT.PUT_LINE(' -');

DBMS_OUTPUT.PUT_LINE('Job: ' || c_jobs.owner

|| '.' || c_jobs.job_name );

DBMS_OUTPUT.PUT_LINE('Interval: ' || c_jobs.repeat_interval );

DBMS_OUTPUT.PUT_LINE('Program: ' || c_jobs.program );

END LOOP;

END;

/

-Job: EXFSYS.RLM$EVTCLEANUP

Interval: FREQ = HOURLY; INTERVAL = 1

Program: begin dbms_rlmgr_dr.cleanup_events; end;

-Job: EXFSYS.RLM$SCHDNEGACTION

Program: FREQ=MINUTELY;INTERVAL=60

What: begin dbms_rlmgr_dr.execschdactions('RLM$SCHDNEGACTION'); end;

-Job: FLOWS_030000.Job #:4001

Interval: sysdate + 8/24

Program: wwv_flow_cache.purge_sessions(p_purge_sess_older_then_hrs => 24);

-Job: FLOWS_030000.Job #:4002

Interval: sysdate + 10/1440

Program: wwv_flow_mail.push_queue(wwv_flow_platform.get_preference('SMTP_HOST_ ADDRESS'),wwv_flow_platform.get_preference('SMTP_HOST_PORT'));

-Job: ORACLE_OCM.MGMT_CONFIG_JOB

Interval: MAINTENANCE_WINDOW_GROUP

Program: ORACLE_OCM.MGMT_CONFIG.collect_config

<output truncated for brevity>

Factors Based on Identity Management

You can verify whether a database is using Oracle EUS for authentication by issuing the following query:

sys@aos>SHOW PARAMETER ldap

NAME TYPE VALUE

-

ldap_directory_access string PASSWORD

ldap_directory_sysauth string no

In this example output, the database is configured to use EUS If the LDAP_DIRECTORY_ACCESS parameter were set to SSL, the database would also be configured to use EUS If the LDAP_ DIRECTORY_ACCESS parameter were set to NONE, the database is not configured to use EUS.

The more difficult question to answer is how a database application is using identity

management attributes available in the SYS_LDAP_USER_DEFAULT context namespace that EUS maintains The difficulty is because SYS_CONTEXT usage is not tracked in the DBA_

DEPENDENCIES view and there is no tracking of the namespace usage in an Oracle dictionary view You can make an educated guess that the application makes use of the techniques outline in Oracle Metalink note 242156.1 “An Example of Using Application Context’s Initialized Globally”

by querying the DBA_CONTEXT view, as shown next:

sys@aos>SELECT namespace

FROM dba_context

WHERE TYPE = 'INITIALIZED GLOBALLY';

NAMESPACE

-DBV_POLICY_EXAMPLE

1 row selected.

If any namespaces are returned and EUS is configured, there is a good chance that identity management information from EUS is being used within the databases

Finally, you can attempt to examine PL/SQL source code for usage of the default or custom namespaces to determine where identity management information for EUS is being used The following query shows how to examine this PL/SQL source code but will work only on source code that has not been wrapped:

sys@aos>SELECT DISTINCT owner, name, type

FROM all_source

WHERE

INSTR (UPPER(text),'SYS_LDAP_USER_DEFAULT') > 0

OR INSTR (UPPER(text),'<custom namespace from above>') > 0

;

OWNER NAME TYPE

- -

-SYS TESTEUS PROCEDURE 1 row selected. Factors Based on Access Path to the Database We can determine the network access path used for a given type of transaction by including the USERHOST column in a query against the captured audit trail The following query shows the access path taken for DELETE transactions on the tables owned by the SH object-owner account The results of this type of query can help you determine to which database client IP address you’d want to restrict certain sensitive transactions Convert the hostnames to the appropriate IP address values and use a DBV factor such as Client_IP in your DBV rules sys@aos>SELECT db_user subject, action_name verb, object_schema || '.'|| object_name object, userhost, COUNT(*) FROM aos_common_audit_trail WHERE object_schema = 'SH' AND action_name = 'DELETE' AND object_type NOT LIKE '%PARTITION%' GROUP BY db_user , action_name , object_schema || '.'|| object_name, userhost ORDER BY db_user , action_name , object_schema || '.'|| object_name, userhost ; SUBJECT VERB OBJECT USERHOST COUNT(*) -

-ALAN_ANALYST DELETE SH.COSTS node1.mycompany.com 1

DEB_DATA_MGR DELETE SH.COSTS node1.mycompany.com 1

MARY DELETE SH.COSTS node1.mycompany.com 1

MARY DELETE SH.SALES node1.mycompany.com 1

OPS$APPSERVER_1 DELETE SH.SALES appserver1.mycompany.com 1

5 rows selected.

Many database environments use the invited nodes feature of Oracle networking to control which IP addresses can connect to the database If this feature is enabled for your database listener, you will see the following entries in the file $ORACLE_HOME/network/admin/sqlnet.ora: TCP.VALIDNODE_CHECKING=YES

TCP.INVITED_NODES=(192.168.0.251, 192.168.0.252, 192.168.0.200)

This list can supplement the queries performed on the captured audit trail as it is a definitive list of the IP addresses for database clients that can actually connect to the database remotely With this list in hand, you can discuss the requirements for each IP address from the perspective

of the database applications that are used and which transactions should be allowed

Factors Based on Operational Context

The sensitive transactions query results also include several records for EXECUTE transactions on the SH.SALES_TRANSACTION PL/SQL package We expected this result based on the examples we’ve created in the past two chapters As you examine the query results for your own applications, you should ask the application experts whether the PL/SQL programs are the only interfaces (paths)

for other more fundament commands such as INSERT, UPDATE, and DELETE If you find that certain PL/SQL programs fit this classification, you can create command rules for the INSERT, UPDATE, and DELETE commands that enforce the use of the PL/SQL program similar to the examples we

created that depend on the DBMS_UTILITY package being part of the PL/SQL call stack

Factors Based on Transactional Sequence

Another form of operational context that you can mine from your audit trail is related to the sequence of statements that are issued to the database as part of a transaction If we consider the notional use case presented in Chapter 6 named Add Monthly Product Cost, portions of the audit trail records may look similar to the following:

sys@aos>SELECT transactionid

,action_name

,object_schema

,object_name

FROM aos_common_audit_trail

WHERE object_schema = 'SH'

AND action_name IN (

'SELECT'

,'INSERT'

,'UPDATE'

,'DELETE'

)

AND object_type = 'TABLE'

AND extended_timestamp > sysdate - 1

ORDER BY extended_timestamp, transactionid;

TRANSACTIONID ACTION_NAME OBJECT_SCHEMA OBJECT_NAME

- - -

SELECT SH PRODUCTS

SELECT SH CHANNELS

SELECT SH PROMOTIONS

040015004E960000 INSERT SH COSTS

040015004E960000 UPDATE SH MONTHLY_COST_SUMMARY

SELECT SH PRODUCTS

SELECT SH CHANNELS

SELECT SH PROMOTIONS

0A0014001F950000 INSERT SH COSTS

0A0014001F950000 UPDATE SH MONTHLY_COST_SUMMARY

SELECT SH PRODUCTS

SELECT SH CHANNELS

SELECT SH PROMOTIONS

03000800FE940000 INSERT SH COSTS

03000800FE940000 UPDATE SH MONTHLY_COST_SUMMARY