204 Part II: Oracle Database Vault 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. ■ ■ ■ ■ ■ ■ ■ Chapter 6: Applied Database Vault for Custom Applications 205 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. ■ ■ ■ ■ ■ ■ ■ ■ ■ 206 Part II: Oracle Database Vault 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: Verb Object Add Product Cost Read User Credentials Set Security Privilege Context Read Products Read Channels Read Promotions Audit Product Cost Transaction Notify Product Cost Transaction 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. ■ Chapter 6: Applied Database Vault for Custom Applications 207 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. ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ 208 Part II: Oracle Database Vault 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. ■ ■ ■ Chapter 6: Applied Database Vault for Custom Applications 209 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. 210 Part II: Oracle Database Vault 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 ■ ■ ■ Condition Candidate DBV Factor(s) 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 Chapter 6: Applied Database Vault for Custom Applications 211 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 ■ ■ ■ ■ 212 Part II: Oracle Database Vault 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. sys@aos>CONNECT dbvext Chapter 6: Applied Database Vault for Custom Applications 213 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 ; used to assert a specific type of SQL command, . 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. 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. provide advice on how to incorporate DBV security policy and general database security policy in each of these tasks. ■ ■ ■ Chapter 6: Applied Database Vault for Custom Applications 209 Subject Verb