194 Part II: Oracle Database Vault 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_name => 'SALES_ARCHIVE_ROLE' Chapter 5: Database Vault Fundamentals 195 ,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; Grant succeeded. 196 Part II: Oracle Database Vault 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. Chapter 5: Database Vault Fundamentals 197 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 198 Part II: Oracle Database Vault Summary 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. CHAPTER 6 Applied Database Vault for Custom Applications 199 200 Part II: Oracle Database Vault 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 Chapter 6: Applied Database Vault for Custom Applications 201 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 202 Part II: Oracle Database Vault 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. ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ Chapter 6: Applied Database Vault for Custom Applications 203 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. ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ . 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. the ■ ■ ■ ■ FIGURE 6-1 Notional database applications 202 Part II: Oracle Database Vault detailed requirements. From this requirement and analysis exercise and the artifacts this phase produces,. 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