To log in to Cloud Control, a user must be granted the DV_OWNER, the DV_ADMIN, or the DV_SECANALYST role. To create a security officer account that has privileges to view reports, but does not have the rights to change the Database Vault configuration, perform the following:
1. As the Database Vault Account Manager, create the security officer user:
CONNECT bea_dvacctmgr/[password] CREATE USER sec_rep IDENTIFIED BY [password]; GRANT CONNECT TO sec_rep;
2. As the Database Vault owner, grant the DV_SECANALYST role to the security user:
CONNECT leo_dvowner/[password] GRANT DV_SECANALYST TO sec_rep;
Using Database Vault Reports
In any system that has security requirements, reports are needed to support the evaluation of the security measures that have been implemented. Database Vault provides a selection of reports that display security-related information from the database. These reports also show custom Database Vault audit event information. If you have unified auditing enabled, then the reports capture the results of your unified audit policies.
The reports are in two categories:
- Database Vault Reports: These reports allow you to check configuration issues with realms, command rules, factors, factor identities, rule sets, and secure application roles. These reports also reveal realm violations, auditing results, and so on. They are grouped in Cloud Control.
- General Security Reports: These reports allow you to check the status of object privileges, database account system privileges, sensitive objects, privilege management, powerful database accounts and roles, initialization parameters, profiles, account passwords, security audits, and other security vulnerability reports.
Security Analysis in Cloud Control
To analyze potential security issues and to demonstrate legal compliance, you can use predefined displays in Cloud Control:
1. The Database Vault home page gives a general security status, highlights attempted security violations, and lists alerts that administrators can define in Enterprise Manager Cloud Control. You can change the data view by selecting a different time series: Last 1 hour, Last 24 hours, Last 7 days, or Last 31 days.
2. Clicking detail links leads you quickly to the most critical information.
- The Top 5 Attempted Violations displays a pie chart that depicts the top five attempted violations in percentage for the database.
- The Top 5 Attempted Violators displays a pie chart that depicts the top five violators in percentage—that is, the users who have performed the most attempted violations, for the database.
- Before you can view these events, if you have not migrated your database to unified auditing, then you must ensure that the AUDIT_TRAIL initialization parameter is set to DB or DB, EXTENDED. If you have migrated your database to use unified auditing, you do not need to configure any additional settings.
3. In Cloud Control the available reports are in the left navigation panel. You can use the Search fields to filter the results of the reports and then click Search to view the report. You can also export the report to a spreadsheet at a specified location or you can view it immediately.
Database Vault Audit Integration with the Unified Audit
In Oracle Database 12c, the Oracle Database Vault audit is now integrated with the unified audit. The elimination of duplicated information stored in both audit logs results in a more streamlined mechanism for auditing. Oracle Database 12c has a secure method for cleaning up the Database Vault audit logs without disabling Oracle Database Vault. This secure method makes the audit maintenance much easier for DBAs and the audit information more readable for auditors.
The SYS.UNIFIED_AUDIT_TRAIL view contains new DV_* columns:
DV_ACTION_CODE DV_ACTION_NAME DV_EXTENDED_ACTION_CODE DV_GRANTEE DV_RETURN_CODE DV_ACTION_OBJECT_NAME DV_RULE_SET_NAME DV_COMMENT DV_FACTOR_CONTEXT DV_OBJECT_STATUS
The existing implementation of Oracle Database Vault auditing continues to be supported and maintained. You can use the old version by using the DVSYS.AUDIT_TRAIL$ table.
Database Vault Audit Views
In a unified auditing environment that relies on the SYS.UNIFIED_AUDIT_TRAIL view or in a standard Oracle Database Vault auditing that relies on DVSYS.AUDIT_TRAIL$, the two following views belong, respectively, to either SYS or DVSYS:
- The DV$CONFIGURATION_AUDIT view captures Database Vault audit records that are related to successful and unsuccessful configuration changes made to realms, rules, rule sets, factors, and other Oracle Database Vault policy configuration activities. Unsuccessful changes are not recorded in a unified audit environment.
- The DV$ENFORCEMENT_AUDIT data dictionary view provides audit information when users violate Oracle Database Vault policies. In a non-unified auditing environment, violations of Oracle Database Vault components are systematically audited and recorded in DVSYS.DV$ENFORCEMENT_AUDIT. Inaunifiedauditingenvironment,violationsare recorded only when audit policies are created against Oracle Database Vault components and enabled.
The column names differ between SYS.DV$CONFIGURATION_AUDIT and DVSYS.DV$CONFIGURATION_AUDIT and between SYS.DV$ENFORCEMENT_AUDIT and DVSYS.DV$ENFORCEMENT_AUDIT.
Paying Attention to Configuration Changes
A potential security breach can be detected by unauthorized configuration changes. It is important for security officers and auditors to pay special attention to Database Vault configuration changes. In addition, there are legal requirements to show that security requirements have been enforced (and no arbitrary changes have taken place).
- The All Database Vault Configuration Changes report displays audit records corresponding to changes made to the configuration of Database Vault components.
- The Realm Configuration Changes report displays audit records corresponding to changes made to the realm configuration. (If you repeated some of the practices several times, you may have many records and this report will take a while to display the results.)
- The Command Rule Configuration Changes report displays audit records corresponding to changes made to the command rule configuration.
- The Rule Set Configuration Changes report displays audit records corresponding to changes made to the rule set configuration.
- The Rule Configuration Changes report displays audit records corresponding to changes made to the rule configuration.
- The Secure Application Role Configuration Changes report displays audit records corresponding to changes made to the secure application role configuration.
- The Factor Configuration Changes report displays audit records corresponding to changes made to the factor configuration.
- The Factor Type Configuration Changes report displays audit records corresponding to changes made to the factor type configuration.
Mandatory Auditing of Configuration Changes
All Oracle Database Vault configuration changes are now audited in Oracle Database 12c. Configuration audits are generated when the Oracle Database Vault administrator executes the procedures of the DVSYS.DBMS_MACADM package, and you can see the configuration changes in the SYS.DV$CONFIGURATION_AUDIT or UNIFIED_AUDIT_TRAIL data dictionary view. Examples of configuration audits include create_realm, update_realm, add_object_to_realm, update_rule_set, rename_rule, create_command_rule, delete_factor, authorize_datapump_user, create_identity, and create_policy_label.
Audit Views: Configuration Changes
Database Vault Audit Views in a Non-Unified Auditing Environment
The DVSYS.DV$CONFIGURATION_AUDIT data dictionary view captures DVSYS.AUDIT_TRAIL$ audit trail records for successful and unsuccessful configuration changes made to realms, rules, rule sets, factors, and other Oracle Database Vault policy configuration activities.
SQL> SELECT USERNAME, ACTION_NAME, RETURNCODE FROM DVSYS.DV$CONFIGURATION_AUDIT ; USERNAME ACTION_NAME RETURNCODE -------------- ----------------------------- ---------- SYSTEM Disable Event Audit 1031 SEC_ADMIN Add Realm Object Audit 0 SEC_ADMIN Realm Update Audit 0 SEC_ADMIN Delete Realm Auth Audit 0 SEC_ADMIN Add Realm Auth Audit 0
In above example, the first row shows that an attempt to disable Oracle Database Vault was unsuccessful because SYSTEM does not have the appropriate DV_OWNER role. The second row shows that an object was successfully added to the list of protected objects in a realm. The third row shows that a realm was successfully updated, such as changing the type from regular to mandatory. The fourth row shows that a participant or owner was successfully removed from a realm, the fifth row shows that a participant or an owner was successfully added to a realm, and the row from the second view shows that a realm object was successfully added.
Database Vault Audit Views in a Unified Audit Environment
The SYS.DV$CONFIGURATION_AUDIT data dictionary view provides rows from the SYS.V$UNIFIED_AUDIT_TRAIL view for successful configuration changes made to realms, rules, rule sets, factors, and other Oracle Database Vault policy configuration activities. They are visible in the SYS.UNIFIED_AUDIT_TRAIL view (for example, when users violate Oracle Database Vault policies).
SQL> select userid, OBJ_NAME, DV_ACTION_NAME, SQL_TEXT, DV_RETURN_CODE from SYS.DV$ENFORCEMENT_AUDIT; US OBJ_NAME DV_ACTION_NAME SQL_TEXT DV_RETURN_CODE -- --------- --------------------- --------------------------- -------------- HR EMPLOYEES Realm Violation Audit SELECT * FROM HR.EMPLOYEES 1031
The row in the DV$ENFORCEMENT_AUDIT data dictionary view shows that the HR user failed to perform SELECT on HR.EMPLOYEES and violated the Oracle Database Vault realm that protects the object. The realm is mandatory. Although HR is the owner of the object, it is not a participant of the realm.
Oracle Database Vault Audit Policy
In a unified auditing:
1. Create an audit policy on the Database Vault realm object:
SQL> CREATE AUDIT POLICY audpol1 ACTIONS COMPONENT = dv realm violation on "HR Application"; Audit policy created.
2. Enable the audit policy:
SQL> AUDIT POLICY audpol1; Audit succeeded.
3. View audit results:
SQL> select userid, OBJ_NAME, DV_ACTION_NAME, SQL_TEXT, DV_RETURN_CODE from SYS.DV$ENFORCEMENT_AUDIT ; US OBJ_NAME DV_ACTION_NAME SQL_TEXT DV_RETURN_CODE -- --------- --------------------- --------------------------- -------------- HR EMPLOYEES Realm Violation Audit SELECT * FROM HR.EMPLOYEES 1031
The violations are recorded only if:
1. An audit policy was created to audit the Oracle Database Vault component.
SQL> CONNECT system/password SQL> CREATE AUDIT POLICY audpol1 ACTIONS COMPONENT = dv realm violation on "HR Application";
2. The audit policy is enabled.
SQL> audit policy audpol1;
Checking for Configuration Issues
Helpful Database Vault Reports:
- The Command Rule Configuration Issues report displays command rules for which a rule set is disabled, a rule set is incomplete, or an object owner does not exist.
- The Rule Set Configuration Issues report displays rule sets for which no rules are defined or enabled.
- The Realm Authorization Configuration Issues report displays information about a rule set for which a realm authorization is disabled, a grantee for a realm authorization does not exist, or an owner for a realm-secured object does not exist.
- The Factor Configuration Issues report displays the factors that have any of the following issues:
- Rule set is disabled or incomplete.
- Audit options are invalid.
- No factor retrieval method/constant exists.
- No subfactors are linked to a factor identity.
- No subfactors are linked.
- Oracle Label Security policy does not exist.
- The Identity Configuration Issues report displays Database Vault factor identities for which no map exists or for which Label identity for the Oracle Label Security label has been removed and no longer exists.
Reviewing Database Vault Configuration
The Database Vault configuration reports show where the configuration recommendations are not being followed. Incomplete configuration yields incomplete security. There are times when the reports may show items as incompletely configured, which may be unavoidable. This leads you to follow other best practices:
- Create a repository rule set. This rule set is not used, except as a container for rules that are in development. These rules can be kept and not be part of any active rule set.
- Remove factors that are not used, including predefined factors. Factors that are not used can take additional unnecessary auditing effort.
Database Vault Enforcement Audit Reports
In general, audit reports are required to monitor authorized actions and attempted unauthorized actions. They are also useful for troubleshooting configuration problems.
- The Realm Audit report shows audit records generated by the realm protection and realm authorization operations. A rule set performs realm authorization. This report displays the audit of the rule set processing results. This is helpful in troubleshooting rule sets and monitoring failed authorization attempts. Realm violations are also displayed in this report. This report would show when a database account attempts to perform an action on a realm object on which it is not authorized to perform that action. When you configure a realm, you set the audit options for the realm operations.
- The Command Rule Audit report shows audit records that are generated by the command rule processing operations. Command rules allow or disallow SQL commands on the basis of rule sets. When you configure a command rule, you can set it to audit the rule set processing results.
- The Factor Audit report shows audit records generated as a result of factor evaluation and factor assignment operations. You can audit instances where a factor’s identity cannot be resolved and assigned (such as “no data found” or “too many rows”). A factor can have an associated rule set that assigns an identity to the factor at run time. When you configure a factor, you can set it to audit the rule set processing results.
- The Label Security Integration Audit report shows audit records related to the label security integration operations: the session initialization operation and the session label assignment operation. You can audit instances where the label security session fails to initialize and where the label security component prevents a session from setting a label that exceeds the maximum session label.
- The Core Database Vault Audit Trail report shows audit records generated by the core access security session initialization operation.
- The Secure Application Role Audit report shows the audit records generated by the secure application role–enabling operation. You can set secure application roles based on rule sets.
Reviewing Database Vault Audit Reports
Audit records are useless without a regular review. They just take up space. When you review these audit records, you can detect unauthorized activities if the auditing options have been set to record these activities. Normally, auditing is set for “On Failure” to reduce the number of audit records and prevent performance problems, but certain activities should be audited for both success and failure.
- Audit the Database Vault realm for failure and success. This causes auditing of the DV_OWNER modifications of any rule sets, realms, and so on (such as adding oneself or disabling the component).
- When you need to temporarily open a privilege, use the security manager (secadmin) login ID. Open the privilege, turn on (more) auditing, and then close it when the DBA has finished the task.
- Turning on auditing for success and failure can be helpful in the diagnosis of configuration problems.
General Security Reports
These reports enable you to check the status of object privileges, database account system privileges, sensitive objects, privilege management, powerful database accounts and roles, initialization parameters and profiles, account passwords, security audits, and other security vulnerability reports. You are required to use Cloud Control, SQL*Plus, or a SQL-based command-line tool to correct many of the issues shown by the general security reports.
The groups of reports are listed below:
- Database Account Password Reports
- Privileged Database Accounts and Roles Reports
- Initialization Parameter and Operating System Directory Permission Reports
- General Database Privilege and Resource Profile Reports
- Database Audit and Privilege Reports
- Object Privilege Reports
- Sensitive Objects Reports
- Unified Audit Trail
- Other Security Reports
Database Account Password Reports
This group of reports focuses on password issues. Most of these issues are prevented by implementing a reasonable password policy. Database Vault provides a password policy by default.
- The Database Account Default Password Report lists the database accounts that have default passwords. Default passwords are provided during the Oracle Database installation.
- The Database Account Status Report provides a quick view of the account status for each account, which helps you identify accounts that must be locked or accounts not using organizationally defined default tablespaces or accounts that use external passwords or accounts that are not using a special password and resource secure profile (if defined).
Privileged Database Accounts and Roles Reports
- The Database Accounts With The EXEMPT ACCESS POLICY Privilege report shows database (but not Database Vault) accounts and roles that have the EXEMPT ACCESS POLICY system privilege granted to them. Accounts that have this privilege can bypass all Virtual Private Database (VPD) policy filters and any Oracle Label Security policies that use Oracle Virtual Private Database indirectly.
- The Database Accounts With BECOME USER Privilege report shows all database accounts roles that have the BECOME USER system privilege.
- The Database Accounts With ALTER SYSTEM OR ALTER SESSION Privileges report shows all database accounts and roles that have the ALTER SYSTEM or ALTER SESSION privilege. Oracle recommends that you restrict these privileges only to those accounts and roles that truly need them.
- The Database Accounts With CATALOG Roles report displays all database accounts and roles that have the %CATALOG% roles granted to them.
- The Database Accounts With Privileged Roles report shows the Database Accounts With Password File Authentication. These are the accounts with special system privileges like SYSDBA/SYSOPER and are authenticated using a password file. Note: Operating system authentication takes precedence over password file authentication if you are a member of the OSDBA or OSOPER group.
- The Database Accounts With ANY System Privilege report shows all ANY system privileges granted to the specified database account or role.
Initialization Parameter and Operating System Directory Permission Reports
The Security Related Database Parameter Settings In init(sid).ora File report displays database parameters that can cause security vulnerabilities, if not set correctly. This report can be used to compare the recommended settings with the current state of the database parameter values.
The Permissions On Operating System Directory Objects report shows all directory objects that exist in the database, whether they are available to PUBLIC, and what their privileges are. Directory objects should exist only for secured operating system (OS) directories, and access to them within the database should be protected.
General Database Privilege and Resource Profile Reports
The following reports display the count of privileges granted to a database account or role with various groupings. These can provide an insight into accounts and roles that may have powerful privileges.
- The Privileges Distribution By Grantee report displays the count of privileges granted to a database account or role. This provides insight into accounts and roles that may have powerful privileges.
- The Privileges Distribution By Grantee, Owner report displays a count of privileges based on the grantee and the owner of the object. This provides insight into accounts or roles that may have powerful privileges.
- The Privileges Distribution By Grantee, Owner, Privilege report displays a count of privileges based on the privilege, the grantee, and the owner of the object. This provides insight into the accounts or roles that may have powerful privileges.
- The Roles and Accounts That Have A Given Role report displays the database accounts and roles to which a role has been granted. This report is provided for dependency analysis.
- The Resource Profiles report provides a view of resource profiles, such as CPU_PER_SESSION and IDLE_TIME, that may be allowing unlimited resource consumption.
- The System Resource Limits report provides insight into the current system resource usage by the database. This helps determine whether any of these resources are approaching their limits under the existing application load.
Database Audit and Privilege Reports
The Database Report On Core Database Audit Trail report returns audit records for the audit policy defined and any auditing records that are generated for audit statements that you have defined. This report only displays audit records that are captured if the database initialization parameter AUDIT_TRAIL has been set to DB.
The Database Accounts With AUDIT Privileges report displays all database accounts and roles that have the AUDIT ANY or AUDIT SYSTEM privilege. This privilege can be used to disable auditing, which could be used to eliminate the audit trail record of an intruder who has compromised the system.
Object Privilege Reports
These reports enable you to monitor the source of user privileges and provide information for the design of roles.
- The Object Access By PUBLIC report lists all objects granted to PUBLIC. The report details all the object access privileges that the database account has through grants to PUBLIC. On the Reports Parameters page, you can filter the results based on the privilege, object owner, or object name. This report is useful for tracking the privileges that a particular user has through PUBLIC.
- The Object Access Not By PUBLIC report details all the object privileges that a database account has through direct grants to the account or through a role, but not through PUBLIC. You specify a single database account on the Report Parameters page, and you can filter the results based on the privilege, object owner, or object name.
- The Direct Object Privileges report shows the direct object privileges granted to nonsystem database accounts. It is provided as a tool to help determine where password- protected roles can be implemented.
- The Object Dependencies report describes all dependencies in the database between procedures, packages, functions, package bodies, and triggers, including dependencies on views created without any database links. It can help you develop a security policy using the principle of least privilege for existing applications.
Sensitive Objects Reports
1. The System Privileges by Privilege report displays the database accounts and roles that have the system privilege selected on the Report Parameters page.
2. The Execute Privileges to Strong SYS Packages report shows the database accounts and roles that have execute privileges on system packages that can be used to access operating system (OS) resources or other powerful system packages. The following system packages are included:
DBMS_ALERT UTL_FILE DBMS_CAPTURE_ADM DBMS_DDL UTL_HTTP DBMS_DISTRIBUTED_TRUST_ADMIN DBMS_FGA UTL_SMTP DBMS_RESOURCE_MANAGER DBMS_JOB UTL_TCP DBMS_BACKUP_RESTORE DBMS_LDAP DBMS_LOGMNR DBMS_ORACLE_TRACE_AGENT DBMS_LOB DBMS_LOGMNR_D DBMS_RESOURCE_MANAGER_PRIVS DBMS_RLS DBMS_REPAIR DBMS_OBFUSCATION_TOOLKIT DBMS_PIPE DBMS_REPCAT DBMS_REPCAT_ADMIN DBMS_RANDOM DBMS_SESSION DEBUG_EXTPROC
3. The Access to Sensitive Objects report shows the database accounts and roles that have object privileges on system tables or views that contain sensitive information. It includes the following system tables and views:
ALL_SOURCE LINK$ DBMS_BACKUP_RESTORE ALL_USERS OBJ$ STATS$SQL_SUMMARY APPROLE$ OBJAUTH$ STATS$SQLTEXT AUD$ OBJPRIV$ STREAMS$_PRIVILEGED_USER AUDIT_TRAIL$ PROFILE$ SYSTEM_PRIVILEGE_MAP DBA_ROLE_PRIVS SOURCE$ TABLE_PRIVILEGE_MAP DBA_ROLES TRIGGER$ PROXY_ROLE_DATA$ DBA_TAB_PRIVS USER$ PROXY_ROLE_INFO$ DEFROLE$ FGA_LOG$ ROLE_ROLE_PRIVS USER_HISTORY$ USER$ USER_TAB_PRIVS
4. The Public Execute Privilege to SYS PL/SQL Procedures report shows all the database accounts and roles that have execute privileges on packages owned by SYS. This can be used to determine which privileges can be revoked from PUBLIC or from other accounts and roles. This reduces vulnerabilities as part of an overall least-privileges security policy implementation.
Unified Audit Trail
- The Unified Audit Trail Generic report displays the first 2000 audit records from the unified audit trail. If there are more audit records, it prompts you to use “Search” to refine the result list.
- The Audit Configuration Changes report displays audit records corresponding to the changes made to the audit configuration.
- The Failed Login Attempts report displays audit records corresponding to the failed login attempts.
- The DDL Audit Actions report displays audit records corresponding to the DDL actions.
- The DML Audit Actions report displays audit records corresponding to the DML actions.
- The Oracle Label Security Actions report displays the audit trail for OLS actions.
- The User Account Actions Report displays audit records corresponding to the user account actions.
- The Data Pump report displays audit records corresponding to the Data Pump actions.
- The RMAN Actions report displays audit records corresponding to the RMAN actions.
- The Privileges Exercised report displays audit records showing various privileges exercised.
Other Security Vulnerability Reports
Each of these reports focuses on a possible security vulnerability:
- The OS Security Vulnerability Privileges report shows the database accounts and roles that have the required system privileges to export sensitive or otherwise protected information to the operating system.
- The Java Policy Grants report shows the Java policy permissions stored in the database. It helps to reveal violations to the least privilege principle. Look for GRANT, READ, or WRITE privileges to PUBLIC or other accounts and roles that do not necessarily need the privileges. It is advisable to disable Java loading privileges from PUBLIC, if Java is not required in the database.
- The Objects Dependent on Dynamic SQL report shows objects that use dynamic SQL. Such objects can be the target for a SQL injection attack. After determining the objects that use dynamic SQL, you need to check the privileges that client applications (for example, a Web application) have over the object. You also need to check the access granted for the object to PUBLIC or a wider account base. These actions can limit the scope of an attack.
- The Unwrapped PL/SQL Package Bodies report displays PL/SQL package procedures that are not wrapped. Oracle provides a wrap utility that obfuscates code to the point where it cannot be read in the data dictionary. This prevents a hacker from reading source code and determining how to circumvent data protection.
- The User Name or Password Tables report helps to identify application tables in the database that store usernames and password strings by displaying tables with column_names with the strings USER%NAME or PASSWORD embedded. These tables should be examined to determine whether the information is encrypted, and if not, the code and applications using them should be modified to protect them from being visible to database sessions.
- The Tablespace Quotas report shows database accounts that have unlimited quotas on one or more tablespaces. These tablespaces can become potential targets for DoS attacks.
- The Non-Owner Object Trigger report helps to reveal triggers that are owned by a database account that is different from the account that owns the database object on which the trigger acts. If the trigger is not part of a trusted database application, it can steal sensitive data, possibly from the tables protected through Oracle Label Security (OLS) or Virtual Private Database (VPD), and place it into an unprotected table for subsequent viewing or export. This kind of trigger requires that the owner of the trigger have privileges granted directly on the object that the trigger accesses.
- The Password History Access report shows database accounts that have access to the USER_HISTORY$ table that stores hashed passwords that were previously used by each account.
- The WITH GRANT Privileges report shows all database accounts that have been granted privileges with the WITH GRANT clause.