Applied Oracle Security: Developing Secure Database and Middleware Environments- P23 pdf

DBV Secure Application Roles Oracle SARs are database roles that can be enabled only from within a PL/SQL program.. mary@aos> -- grant the require object privileges mary@aos> -- to the D

It is easy to see that DBV factor assignment provides additional access control and validation capabilities when used as a wrapper for traditional methods of asserting client information that use the DBMS_SESSION or DBMS_APPLICATION_INFO packages The feature provides the same benefits when used in lieu of custom Oracle application context objects and reduces the number

of objects that must be maintained The feature extends the overall auditing capability for these traditional mechanisms while preserving the existing audit capabilities on which applications may rely

DBV Secure Application Roles

Oracle SARs are database roles that can be enabled only from within a PL/SQL program The PL/SQL program will typically perform a series of checks to determine whether the conditions are correct for the role to be enabled DBV provides an integration capability with Oracle SARs that allow you define these conditions using a DBV rule set

To help illustrate how DBV Secure Application Roles work, consider the DBV Is System Maintenance Allowed rule set presented earlier in the chapter This rule set allowed system maintenance routines on Fridays from 5 to 11 P.M We can reuse this rule set to control the ability

to set a role that has DELETE privileges on tables protected by the Sales History DBV realm for the purpose of archiving and deleting records that no longer need to be maintained in the table Privileges that allow for the update or deletion of data are typically considered security-sensitive operations and are perfect candidates for DBV SARs

TIP

Use DBV SARs for security-sensitive privilege sets.

The first step in creating this type of capability requires that the DBV security administrator (DBVOWNER) create the DBV SARs using the DBMS_MACADM.CREATE_ROLE PL/SQL

procedure To secure the role from being granted or revoked outside the control of the Sales History realm administrator, MARY, we should also protect the role in the Sales History realm

dbvowner@aos> create the DBV Secure Application Role

dbvowner@aos> BEGIN

dbms_macadm.create_role(

role_name => 'SALES_ARCHIVE_ROLE'

, enabled => 'Y'

, rule_set_name => 'Is System Maintenance Allowed'

);

END;

/

PL/SQL procedure successfully completed.

dbvowner@aos> protect the role in the Sales History realm

dbvowner@aos> BEGIN

dbms_macadm.add_object_to_realm (

realm_name => 'Sales History'

,object_owner => 'SH'

,object_type => 'ROLE'

);

END;

/

PL/SQL procedure successfully completed.

The created role is a normal Oracle SAR, visible from the DBA_APPLICATION_ROLES view, but the PL/SQL program that can enable the role is defined by DBV itself:

sys@aos>SELECT *

FROM dba_application_roles

WHERE role = 'SALES_ARCHIVE_ROLE';

ROLE SCHEMA PACKAGE

- -

-SALES_ARCHIVE_ROLE DVSYS DBMS_MACSEC_ROLES

1 row selected.

DBV provides a single PL/SQL package procedure named DVSYS.DBMS_MACSEC_ROLES SET_ROLE that is used to enable the role being protected This procedure has the invoker’s rights definition required for Oracle SARs and will perform the DBV rule set evaluation to determine whether the role should be set This procedure eliminates the need to create a separate PL/SQL program for each SAR required for your application and offers an increased level of reuse of the DBV rule sets you develop

The next step is to grant the privileges required by the role to serve its intended purpose In our example, the SALES_ARCHIVE_ROLE requires DELETE privileges on the tables owned by the

SH account We can also grant this role to a named user account, such as the user SCOTT The DBV realm administrator, MARY, of the Sales History realm, can perform these steps

mary@aos> grant the require object privileges

mary@aos> to the DBV Secure Application Role

mary@aos> GRANT DELETE ON sh.channels TO sales_archive_role;

Grant succeeded.

mary@aos> GRANT DELETE ON sh.costs TO sales_archive_role;

Grant succeeded.

mary@aos> GRANT DELETE ON sh.countries TO sales_archive_role;

Grant succeeded.

mary@aos> GRANT DELETE ON sh.customers TO sales_archive_role;

Grant succeeded.

mary@aos> GRANT DELETE ON sh.products TO sales_archive_role;

Grant succeeded.

mary@aos> GRANT DELETE ON sh.promotions TO sales_archive_role;

Grant succeeded.

mary@aos> GRANT DELETE ON sh.sales TO sales_archive_role;

Grant succeeded.

mary@aos> grant the DBV Secure Application Role

mary@aos> to the account SCOTT

mary@aos> GRANT sales_archive_role TO scott;

We now test the use of these privileges and the DBV SAR as the user SCOTT to demonstrate how the configuration works when operating outside of the authorized system maintenance timeframe:

scott@aos> show the date and time of day factors that affect

scott@aos> the DBV Rule Set that controls the role enablement

scott@aos>SELECT TO_CHAR(SYSDATE,'DAY') "DAY_OF_WEEK",

TO_CHAR(SYSDATE,'HH24') "HOUR_OF_DAY"

FROM DUAL;

DAY_OF_WEEK HO

MONDAY 10

1 row selected.

scott@aos> attempt to use the privileges granted to the

scott@aos> role to demonstrate the privileges are not enabled

scott@aos> by default as with a normal Oracle role.

scott@aos> We will test deleting records greater than 10 years old

scott@aos>DELETE sh.sales WHERE time_id < (SYSDATE-(365*10));

DELETE sh.sales WHERE time_id < (SYSDATE-(365*10))

*

ERROR at line 1:

ORA-01031: insufficient privileges

scott@aos> attempt to enable the role outside of the

scott@aos> authorized system maintenance timeframe

scott@aos>EXEC dvsys.dbms_macsec_roles.set_role('SALES_ARCHIVE_ROLE');

BEGIN dvsys.dbms_macsec_roles.set_role('SALES_ARCHIVE_ROLE'); END;

*

ERROR at line 1:

ORA-47305: Rule Set violation on SET ROLE (Is System Maintenance Allowed) 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 1

The rule set violation that occurs is audited in the same manner as its usage within any other DBV components The audit trail records (Figure 5-13) that are created for DBV SAR violations can be queried from the DVA web application as well

If we fast forward to Friday at 5 P.M., we can demonstrate the success scenario for enabling the DBV SAR and leveraging the privileges the role provides:

scott@aos> show the date and time of day factors that affect

scott@aos> the DBV Rule Set that controls the role enablement

scott@aos>SELECT TO_CHAR(SYSDATE,'DAY') "DAY_OF_WEEK",

TO_CHAR(SYSDATE,'HH24') "HOUR_OF_DAY"

FROM DUAL;

DAY_OF_WEEK HO

FRIDAY 17

1 row selected.

scott@aos> attempt to enable the role, which will succeed

scott@aos>EXEC dvsys.dbms_macsec_roles.set_Role('SALES_ARCHIVE_ROLE');

PL/SQL procedure successfully completed.

scott@aos> attempt to use the privileges granted to the

scott@aos> role by deleting records greater than 10 years old

scott@aos>DELETE sh.sales WHERE time_id < (SYSDATE-(365*10));

221651 rows deleted.

FIGURE 5-13 Secure Application Role Audit report

This chapter presented numerous examples of how to configure the core DBV components to protect an example object-owner account These examples illustrate the effectiveness of the new DBV security features Product features such as DBV realms, DBV command rules, and DBV SARs are critical for addressing many of the issues we face today around consolidation, compliance, and separation of duties These features serve as effective defensive measure for cyber security

by limiting the extent to which statements and privileges can be exploited by an attacker

We demonstrated how DBV realms filled in a gap in the ability to place boundaries around the use of system ANY privileges and how simply defining this realm boundary offers immediate protection against inadvertent access to the objects being protected by the realm We examined how command rules allow us to implement security policies based on the real business rules we may have defined in our organization We also demonstrated how DBV SARs can restrict an administrator’s or an application’s ability to enable sensitive privilege sets This feature reduces the threat of a privilege set being used outside of the context in which the usage was intended Database administrators should consider updating their production databases to DBV to meet current and future security threats and challenges The declarative policy configuration of the product’s security rules, based on multiple factors, helps ensure the appropriateness of an

organization’s defense against these threats and challenges as they change over time Once DBV policy is deployed, database security administrators should consider the serious nature of what a violation could mean and question the legitimacy of it We examined the ability to control policy evaluation semantics, auditing configuration, and custom event handling that allow these

administrators to refine policies or respond to these violations when they occur

Applied Database Vault for Custom Applications

199

his chapter introduces design techniques and patterns for DBV security controls that will be incorporated into the process of creating a new application We first introduce a notional database application environment that is used to describe design techniques for analyzing the applications in this environment The analysis will uncover opportunities for you to apply DBV security controls The design techniques include documentation components, rules, and patterns that will be applied during the design phase of new database application

We encourage you to think about database security at the beginning of the application design phase and understand the importance of considering a DBV security policy at that point This approach is easier than trying to tack on a security policy at the end of a project development cycle when schedules are tight, budgets are reduced, and code is frozen Up-front security design allows security policy to be shared among applications covering the same or similar problem domains, such as sales and finance, or those that reside in the same database under an IT

consolidation effort

Much has been written on the subjects of software development methodologies and the software development lifecycle There is no shortage of words in the IT industry on the steps involved, the artifacts to deliver, or the most efficient processes for developing software Each software development methodology, be it Agile-based methods, UML-based methods, or classical methods such as Waterfall, share a common set of activities:

Functional requirements and analysis

Designs/specifications

Implementation/coding

Testing

Deployment, documentation, and training

Operations and maintenance

These methodologies differ in ways that dictate how document-centric or prototype-centric each activity should be These methodologies differ in terms of when each activity is conducted with respect to the overall schedule and who (from a project role perspective) is involved in each activity We do not present arguments in this chapter on which software development methods are best for you or your organization; instead, we present a generic methodology (practices and procedures) to help you analyze and design your application to take advantage DBV security controls The goal is to help you increase your application’s overall security posture by applying techniques within early stages of the methodology you already use

Notional Database Applications Environment

A notional sales management database application environment is used to illustrate the

security methodology For this application, the following high-level database applications and functionality are required:

A web service allows external product reseller applications to query sales history

information for the channels in which they participate

■

■

■

■

■

■

■

T

A web service allows for internal line of business applications to query sales history information from the products they manage

A web application allows for the sales managers to administer products, channels, promotions, sales, customers, and the costs of product sales for product lines they manage

Batch programs generate sales history information on a scheduled basis

Database administrators must be able to back up application data, conduct performance tuning, and perform general database administration functions such as patching and applying upgrades

Our example of the notional architecture is somewhat contrived because we are aiming to make use of the Oracle Database sample schemas used throughout this book, but it is simple enough to help describe the methodology and has enough variety to help us demonstrate the practices and procedures from more than one example Figure 6-1 shows a Unified Modeling Language (UML) component diagram that depicts the notional software architecture that is being constructed

Like a lot of software implementations in the past, the idea for the system probably started on

a whiteboard, the back of napkin, or a scrap of paper in a conversation between two executives

or a line of business managers It was much cruder than the illustration in Figure 6-1, but the executives were more concerned about organizational efficiency, return on investment, and other important business matters than security The next day (or month), they obtained the approvals for

a budget and gathered all their functional analysts and technical personnel to begin laying out the

■

■

■

■

FIGURE 6-1 Notional database applications

detailed requirements From this requirement and analysis exercise and the artifacts this phase produces, we can expose the core elements we will need to develop a security profile for the database applications

From Requirements to Security Profile Design

The following is a brief outline of the process we will follow to examine the system requirements and build our database security profile This process is iterative in that we can start with each group of requirements, examine it, move onto the next group of requirements, and revisit completed requirements for more refinement:

Define or locate requirements documentation, such as use cases

Identify coarse-grained “verb object” assertions for the database security profile

Identify fine-grained database security profile to include actors and conditions

Establish DBV factors based on business or system conditions

Identify DBV realms and realm objects from objects

Identify accounts, roles, and DBV realm authorizations from actors

Establish DBV command rules from conditions

Establish DBV Secure Application Roles (SARs) from conditions

This chapter details requirements analysis techniques that uncover both application security and hidden security requirements that must be considered These techniques will help you understand the application and its sensitive transactions and privileged operations Stay focused

on the key drivers, such as compliance, cyber security, insider threats, and corporate policy to help you justify these requirements and apply adequate security measures

Requirements Technique: Use Cases and Scenarios

A popular requirements and analysis technique in use today is the development of use cases and

scenarios Use cases are named descriptions of the interaction of an actor (a person or other

computer system) within a business process (named business use cases) or with an IT system (named system use cases) System use cases comprise a sequence of steps that outline how the actor achieves a goal using the IT system For example, “Add Monthly Product Costs” might be

a use case with the actor being a sales manager Scenarios are the detailed variations on the

sequence of steps or actions that describe how an actor reaches the goal using the primary and alternative paths Using our example, we may include a path for adding monthly costs for electronic products, including entering the costs of raw materials and manufacturing, and an alternative path for software products, which has inputs of more detailed labor costs When a use case is formally defined it can include the following sections:

Name A short identifier for the use cause typically of the form verb noun, where the

verb is a summary of the tasks and the noun is the object being acted upon

Goal The desired outcome of the use case.

■

■

■

■

■

■

■

■

■

■

Actor(s) Who is involved in the interaction, typically an end user or another system Triggers Events that cause the use case to be initiated.

Pre-conditions Conditions that must be met before the use case can be initiated Scenario(s) Primary and alternatives paths through the use case.

Business rules Formal or informal rules associated with an organization and its policies

that govern either the pre-conditions, post-conditions, or detailed steps (scenarios) of the use case

Post-conditions Conditions that are true or state changes in the system once the use

case is completed

While this explanation of use cases and scenarios is intended as an overview, if you look at the context of a use case, it has the components of the security profile language used in security evaluations Security evaluation conventions related to the evaluation of IT products express rules for testing in the form:

<subject> <verb> <object> <condition(s)>

With use cases, all of the same components are specified:

Subjects The actors

Verbs In the syntax of the name and the actions in scenarios

Objects Expressed in the syntax of the name, goal, and scenarios

Conditions Expressed in the preconditions and post-conditions

Using these similarities, we will demonstrate that we can examine the use cases for a system, or any requirements analysis document for that matter, to identify these components (subjects, verbs, objects, and conditions)

The process of identifying these components allows us to design a security profile for a system

if we define the security protection profile within the context of each group of requirements For the purposes of this book, we try to limit the discussion of the security profile to be applicable to Oracle Database security It just so happens that with use cases, we can overlay each use case with the appropriate level of detail regarding the security protection profile as it applies to each use case because the syntax/vernacular of both a security protection profile and a use case are similar This gives us an advantage because we can define a database security policy that will allow operations within the (modeled and documented) context of the intended usage of database objects (the use cases) and prevent unauthorized use of database objects

Analyzing Requirements: Example Use Case

First let’s look at example use case for the notional database applications:

Use Case Name Add Monthly Product Costs

Goal The direct and indirect costs for a given month related to a product the company

sells are available to all business processes

■

■

■

■

■

■

■

■

■

■

■

■