Applied Oracle Security: Developing Secure Database and Middleware Environments- P24 ppsx

As we answer these questions, we categorize the conditions as follows: Conditions based on compliance that typically introduce security policy components for auditing, reporting, and ac

Actor(s) Product Sales Manager

Triggers The representative from the company’s Manufacturing, Marketing, and Partner

Management departments have all reported their respective monthly costs for the product

to the Sales Manager

Pre-conditions

o The Sales Manager has authenticated to the Sales Administration application

o The Sales Management system is not in the process of summarizing monthly sales data at the time the product costs are being entered

o The time the product costs are being entered is not within the weekly maintenance window of the Sales Management system

Scenario (Primary)

1 The user opens a browser and accesses the Sales Administration web page

2 The system prompts the user for his or her credentials

3 The user enters his or her credentials

4 The system validates the user’s credentials If the validation fails, the system audits this fact and repeats the prompt for the user’s credentials If the validation succeeds, the appropriate security privilege context based on the user is applied and the system presents the user with the main system menu

5 The user selects the Add Monthly Product Costs option

6 The system prompts the user to enter a month and year for the product cost

7 The user selects the month and year

8 The system reads the product list and prompts the user to select a product The system will present only the products for which the user is responsible

9 The user selects the product

10 The system reads the channel list and prompts the user to select a (partner) channel

11 The user selects the channel

12 The system reads the promotion list and prompts the user to select a (marketing) promotion

13 The user selects the promotion

14 The system prompts the user to enter the costs for the channel and promotion

15 The user enters the costs for the channel and promotion

16 The system prompts the user to enter another channel and promotion costs

17 If the user elects to add another cost, steps 8–16 are repeated

Or, if the user selects to finish the transaction, the system presents a summary screen for the cost information entered

■

■

■

■

■

■

■

18 If the user elects to cancel the transaction, the information entered is discarded and the system returns the user to the main system menu

19 If the user elects to save the cost information, the system will

a) store the information in the database;

b) audit the transaction;

c) send the required notifications related to the transaction

Business Rules

o Sales managers are the only staff members allowed to maintain overall product costs figures

o All product costs figures that are created or updated must be audited for Sarbanes Oxley (SOX) compliance regulations Company policy related to SOX compliance auditing require the audit record to include the date/time of the transaction, the named user executing the transaction, the system or application that was used to execute the transaction, and the full record of the transaction

o The appropriate corporate officers must be notified when product costs figures are created or updated

o All system outages, scheduled or accidental, must be recorded for SOX compliance reporting purposes

Post-conditions

o The monthly product costs have been stored in the Sales Management system’s database

o The monthly product costs transaction has been properly audited

o Notifications related to the monthly product costs transactions were generated Developing use cases for these types of transactions can be also applied to existing systems that can include a user interface or batch product cost upload routine Don’t be afraid to apply the analysis technique in any environment where you are required to apply additional security controls after the fact, as may be the case if you must meet compliance regulations Two pages’ worth of requirements are written into the preceding use case text, but when you apply the process of identifying a security profile to the use case, you will see that a lot more requirements lie “between the lines” when you start design activity

Identify Coarse-Grained Security Profile

The design technique for defining our database security profile can be applied to just about any requirements document and stems from one of the popular techniques used in object-oriented analysis and design The Verb Object technique involves identifying nouns (objects) and key verbs to construct an object-oriented class model for the application design needs This technique

is normally applied in designing Java or C++ classes (a domain model) used by the application

■

■

■

■

■

■

■

■

■

For the database security profile, we want to apply this technique with one slight variation: We first want to identify all “verb objects” facts from the requirements text, as this will be the first pass

at the profile itself Given the example use case from earlier in the chapter, we assert the

following “verb objects” facts:

This table of “verb object” assertions uncovers the basic database operations that will be

conducted on either an existing or a new set of tables or views (objects) in the database So an Add could be an implied INSERT, a Read would be implied SELECT, and so on This first step in the design process is not only important for defining these database operations (verbs that will

be commands), but it also defines the database objects that are involved in the context of the use case (requirements) The resulting value is that the requirements analysis exercise can be used as input the design of database security profiles as well as logical database design efforts

The actor here is the Sales Manager and is associated to the “subject” of our security profile syntax We want to state this subject explicitly because the security profile will not be final if

we consider each use case or group of requirements in isolation The process of developing the security will be iterative in nature, so as we examine each use case or group of requirements, we need the subject to be explicitly defined Note that much of the real code that will be developed (or is developed) operates as the “system” in our use case However the real “actor” as it relates

to the system is the Sales Manager To this end, we want to ensure that operations available to the session within the system do not overextend their operating privilege model beyond those available to the Sales Manager whenever possible

Another important component to add to our security profile are conditions that must be presented for each “verb object” pairing to be true We will uncover other conditions that may need to be added or combined as we work through each section of the requirements analysis These conditions are often explicitly stated in the scenario, pre-conditions, or business rules For example, in the scenario of the example use case, step 8 states, “The system reads the product list and prompts the user to select a product The system will present only the products for which the user is responsible.” This is an explicit operational condition based on ownership for the specific product lines the company offers for sale It may be dictated by the organization’s policy that strives to prevent one sales manager from overstepping his or her boundaries or duties

We should also be looking for opportunities to uncover hidden security requirements or introduce sound security design principles in the context of these conditions Here are some examples:

Should all database administrators be able to view (read) the entire product list? The product list may not be sensitive in nature is of less concern

■

Should all of our database administrators be allowed to update the product costs table directly, or should we enforce constraints that all product updates come through a specific application code block? The update operation may be disallowed outside of a trusted code block due to the complex update logic and the notifications required for compliance regulations

The following questions may help you uncover additional opportunities to improve the overall security profile:

What are the customer’s security standards or conventions? The IT department of your organization probably keeps documented security standards related to the development

of IT systems, so make sure you ask about any documentation because it would offer lots

of information related to important controls from the customer’s perspective

What are the customer’s privacy requirements? Many organizations are impacted by privacy requirements to protect personally identifiable information (PII), such as Social Security numbers or health care–related information for employees and/or patients In our example use case, does the “credential validation step” read the storage structures that contain Social Security numbers or salary data? If that is the case, we should limit the privileges or view to this information by the use case

Is the customer impacted by the financial compliance regulations such as Sarbanes-Oxley (SOX)? This regulation requires extensive auditing and reporting You can also uncover opportunities to define preventative security policies that reduce the probability

of accidents occurring or malicious intent succeeding

What information does the customer consider sensitive or proprietary? Does the system store credit card numbers, financial statements, or engineering documents related to product research efforts?

Does the customer have well-defined separation of duty requirements? For example, should financial or sales data be administered by a different group than the group that administers human resources data? This is especially important in IT consolidation environments or in highly secure environments in the public sector

As we answer these questions, we categorize the conditions as follows:

Conditions based on compliance that typically introduce security policy components for

auditing, reporting, and access control

Conditions based on conflict of interest, a kind of compliance that implies separation

of duty (access control) to avoid advanced insider knowledge, theft, or fraud Publicly traded companies typically use such requirements Even without these compliance-driven requirements, an enterprise can reduce the risk of accidental or intentional data loss by applying separation of duty controls to the database security policy

Conditions based on organizational policies that are introduced to reduce risk of loss

(data or financial), maintain ownership, or spread control to more than one group/ individual

Conditions based on identity management that typically examine an attribute of the

individual or his/her membership in a group

■

■

■

■

■

■

■

■

■

■

Conditions based on access path or the operational context that depend on the system

access path or method that operation is invoked in the database The conditions may inspect the network access path or the lack thereof when a client is on the database server’s console The conditions may consider the operational context such as the application call stack or the generic type of SQL command in a given transaction These types of conditions are typically introduced to prevent data access outside the normal scenario in the same way intrusion detection is applied to network packets

Time-based or Sequential conditions that can define conditions such as the inside

maintenance window, prior to month close, or prior to earnings statements that are designed to limit the timeframe in which a command can be executed or a timeframe

in which the command cannot be executed In a related way, we may want to ensure that sensitive transactions are performed only as part of a trusted sequence of events For example, if a specific type of DELETE transaction is expected only from a specific application, or the application runs a specific query (SELECT) before the DELETE, can we find evidence of the application authentication step or the SELECT statement being issued?

Conditions based on data or events stored externally ensures that data or conditions

stored in external systems are used in the decision-making process This approach can help enforce separation of duty and/or separation of control but is most beneficial when distributed systems must interoperate to ensure that an overarching business process is followed in the correct sequence

DBV is extremely valuable in enforcing these types of conditions in your security policy because it is the only declarative database product option that allows you to enforce rule-based decisions at both the statement and role levels The value comes in being able to codify business rules directly in your database security profile

Identify Fine-Grained Security Profile

Once we have uncovered the conditions using the process and guidance provided above, we are ready to define our fine-grained security profile Table 6-1 illustrates a fine-grained version of our security profile that includes the addition of the appropriate subject (actor) and the conditions, both explicitly stated and derived (these are explicitly spelled out as derived), for each “verb object” exercise that was discussed earlier

Obviously, this list would be substantial as we worked through every use case, but just working on this simple use case gives us plenty to work with We can build a candidate DBV security policy design for this use case by taking on the task in the following order:

1 Identify DBV factors based on business or system conditions.

2 Identify DBV realms and realm objects based on objects.

3 Identify accounts, roles, and DBV realm authorizations from use case actors.

4 Establish DBV command rules from conditions.

5 Establish DBV secure application roles from conditions.

The following sections describe the steps to take in each of these tasks We provide advice on how

to incorporate DBV security policy and general database security policy in each of these tasks

■

■

■

Subject Verb Object Conditions

Sales Manager Add Product Cost Add product cost operation can be executed

only by a Sales Manager (or higher position) within the sales organization

Must not be within the weekly maintenance window

Can be created or updated only by the Sales Management package code (derived compli-ance control)

Sales Manager Read User Credentials Credentials must adhere to organizational

password policy requirements (derived corporate IT standards control)

May not query employee SS number, salary, or commission data as part of the read operation (derived privacy control)

System Set Security Privilege

Context

Set only by system-controlled interface (derived compliance control to prevent privilege escalation)

Sales Manager Read Products May query only products for which the

manager is responsible Sales Manager Read Channels No conditions

Sales Manager Read Promotions No conditions

Sales Manager Audit Product Cost

Transaction

Audit trail cannot be updated or deleted by a database administrator (derived compliance control)

Audit trail cannot be read or written to by database clients outside the corporate intranet (derived compliance control)

Audit trail must be maintained for a period of seven years (derived compliance control) Sales Manager Notify Product Cost

Transaction

Communication of notification details must

be encrypted if it leaves the corporate intranet (corporate security policy on sensitive data)

A record of all notifications must be maintained (derived compliance control)

TABLE 6-1 Fine-grained Version of Our Security Profile

Identify DBV Factors Based on Business

or System Conditions

If we examine the conditions in a fine-grained security profile, we can identify a set of DBV factors we’ll need to develop by asking: How is each fact in the condition asserted or defined?

We can add an extra column to Table 6-1 for the factors we can derive from these conditions

For readability, we’ve included the Condition and Candidate DBV Factor(s) columns for a subset

of our Subject-Verb-Object-Condition security profile in Table 6-2

As you can see in Table 6-2 below, we can create factors using the same types of categories

we used to identify the conditions of our security policy:

Factors based on compliance

Factors based on conflict of interest or separation of duty

Factors based on organizational policy

■

■

■

Add product cost operation can

be executed only by a Sales

Manager (or higher position)

within the sales organization

Create factors based on command operational context:

“Product Cost Operation”

Create factors based on traditional identity management concepts such as user attributes or group membership to resolve concept of Sales Manager:

“Job Title”

“Department”

Must not be within the weekly

maintenance window

Create factors based on time:

“Day of Week”

“Time of Day”

Can be created or updated

only by the Sales Management

package code

Create factors based software operational context:

“Sales Management Package”

May not query employee SS

number, salary, or commission

data as part of the read

operation

Create factors based on command operational context:

“Read Operation”

Set only by system controlled

interface

Create factors based on software operational context:

“Security Management Package”

May query only products

for which the manager is

responsible

Create factors based on group membership:

“Department” or further refined “Specific Organization Within Sales” if products sales organizations are aligned by product type, for example

Create factors based on organizational policy:

“Product Category List”, a list of product categories for which the manager is responsible

Audit trail cannot be updated

or deleted by a database

administrator

Create factors based on separation of duty:

“Database Role(s)”

Audit trail must be maintained

for a period of seven years

Create factors based on compliance:

“Audit Retention Period”

TABLE 6-2 Condition and Candidate DVB Factors

Factors based on identity management

Factors based on access or operational context

Factors based on time or sequential conditions

Factors based on data or events stored externally

As we discussed in Chapter 5, DBV factors will support conditions when used as part of a DBV rule We will look at examples of factors for these categories to understand the methods used to create them so they can be applied to an overall enterprise security policy At a minimum,

we want to leverage a common security policy for applications that reside in the same database

To do this, we must have a central location for the PL/SQL routines that will be used for our factor retrieval methods

Centralizing PL/SQL Routines for DBV Factors and Rules

In Chapter 5, we developed PL/SQL routines that checked for a PL/SQL package on the call stack and routines that maintained the SQL command’s event context (SQL text, object owner, object, and so on) At the time, we stored this code in the SH schema to simplify the example and the explanation Now we find the need for more PL/SQL code to be used as part of our DBV factors This code will be used not only in DBV factors but in DBV rules as well, as DBV factors are not intended to replace DBV rules Once you have a scenario in which PL/SQL code needs to be used in both DBV rules and PL/SQL, you can use the PL/SQL code as a function in a DBV factor’s retrieval method This function can simply return a TRUE/FALSE expression such as 1/0

What we really need is a centralized object-owner account where we can place common security-related PL/SQL code The DVSYS schema is not the best location for this type of code given its system privileges, direct object privileges on its own security-relevant objects, and its ability to grant the DV-protected roles such as DV_ACCTMGR or DV_OWNER DBV is installed with another schema named DVF (for Database Vault Factors) that is used to maintain DBV factor functions, and the account is protected by the DBV realm

The account has only the CREATE PROCEDURE system privilege and no system ANY object privileges that would extend to other object-owner accounts, so it would be a more secure choice For supportability, we can model a DBV extension account named DBVEXT based on the way the DVF account is set up In fact, we will grant a few additional system privileges, such as CREATE TABLE, to the DBVEXT account to include custom configuration data and grant SELECT privileges

on security-relevant views in the database, such as DBA_ROLE_PRIVS to enable the custom logic All we need to do is create the DBVEXT account and authorize DBVEXT in the DBV realm to load the code or tables that provide the custom logic required We can then lock the account when we are done loading these objects

dbvacctmgr@aos> create the DBVEXT account and provide the

dbvacctmgr@aos> account with storage quotas for tables

dbvacctmgr@aos>CREATE USER dbvext

IDENTIFIED BY oracle

DEFAULT TABLESPACE SYSAUX;

User created.

dbvacctmgr@aos>ALTER USER dbvext QUOTA 10M ON SYSAUX;

User altered.

dbvacctmgr@aos>CONNECT dbvowner

■

■

■

■

Enter password:

Connected.

dbvowner@aos> authorize the DBVEXT account in the DBV Realm dbvowner@aos> so that the account can create PL/SQL programs dbvowner@aos> and grant EXECUTE privileges on these objects dbvowner@aos> to the DVSYS account

dbvowner@aos>BEGIN

dbms_macadm.add_auth_to_realm (

realm_name => 'Oracle Database Vault'

, grantee => 'DBVEXT'

, rule_set_name => NULL

, auth_options => dbms_macutl.g_realm_auth_owner

);

END;

/

PL/SQL procedure successfully completed.

dbvowner@aos> protect the DBVEXT account in the DBV Realm dbvowner@aos>BEGIN

dbms_macadm.add_object_to_realm (

realm_name => 'Oracle Database Vault'

,object_owner => 'DBVEXT'

,object_name => '%'

,object_type => '%'

);

END;

/

PL/SQL procedure successfully completed.

dbvowner@aos >CONNECT / AS SYSDBA

Connected.

sys@aos> this grant allows the DBVEXT account to

sys@aos> connect to the database

sys@aos>GRANT CREATE SESSION TO dbvext;

Grant succeeded.

sys@aos> this grant allows the DBVEXT account to

sys@aos> create tables in the database

sys@aos> we will use this privilege in later

sys@aos> examples that require configuration data

sys@aos>GRANT CREATE TABLE TO dbvext;

Grant succeeded.

sys@aos> this grant is required by the role check logic sys@aos> we will add to the DBVEXT account

sys@aos>GRANT SELECT ON sys.dba_role_privs TO dbvext;

Grant succeeded.

sys@aos> this grant is required by the privilege check logic sys@aos> we will add to the DBVEXT account

sys@aos>GRANT SELECT ON sys.dba_sys_privs TO dbvext;

Grant succeeded.

sys@aos> this grant enables the extended rule set

sys@aos> event handler demo for Chapter 7

sys@aos>GRANT CREATE ANY CONTEXT TO dbvext;

Grant succeeded.

Enter password:

Connected.

dbvext@aos> as you can see the DBVEXT account does not have

dbvext@aos> roles, e.g DV_ADMIN or system ANY privileges,

dbvext@aos> such as GRANT ANY ROLE, which would cause

dbvext@aos> concern for the DBVEXT account being authorized

dbvext@aos> as a realm owner in the DBV realm

dbvext@aos>SELECT * FROM session_roles;

ROLE

-DV_PUBLIC

dbvext@aos>SELECT * FROM session_privs ORDER BY 1;

PRIVILEGE

-CREATE ANY CONTEXT

CREATE PROCEDURE

CREATE SESSION

CREATE TABLE

4 rows selected.

dbvext@aos> create the DBV extension package and

dbvext@aos> grant execute on the package to DVSYS so that it

dbvext@aos> can be used in DBV Factor, Rules or Rule Set handlers

dbvext@aos>CREATE OR REPLACE PACKAGE dbvext.dbms_mac_extension AS

used to check software operating context to

determine if a specific PL/SQL package is being executed

FUNCTION instr_call_stack(object_name IN VARCHAR2

, object_type IN VARCHAR2 DEFAULT 'PACKAGE BODY') RETURN NUMBER;

used to check if the session user has a specific role

you can send a comma-separated list of roles in the role_name

parameter and if any are granted to the user, a 1 will be returned

FUNCTION user_has_role(role_name IN VARCHAR2

,user_name IN VARCHAR2 DEFAULT SYS_CONTEXT('USERENV','SESSION_USER')

) RETURN NUMBER;

used to check if the session user has a specific role

you can send a comma-separated list of privileges in the priv_name

parameter and if any are granted to the user, a 1 will be returned

FUNCTION user_has_priv(priv_name IN VARCHAR2

, user_name IN VARCHAR2 DEFAULT SYS_CONTEXT('USERENV','SESSION_USER')

) RETURN NUMBER;

used to assert a specific type of SQL command,

e.g SELECT, INSERT, EXECUTE

FUNCTION assert_command(

check_event IN VARCHAR2

, sql_event IN VARCHAR2

) RETURN NUMBER ;