Skip Headers
Oracle® Database Vault Administrator's Guide
11g Release 1 (11.1)

Part Number B31222-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

11 Oracle Database Vault Reports

This chapter explains how you can run reports on various activities in Oracle Database Vault. It includes the following sections:

11.1 Categories of Oracle Database Vault Reports

Oracle Database Vault provides a selection of reports that display security-related information from the database. These reports also show custom Oracle Database Vault audit event information. The reports are in two categories:

11.2 Who Can Run the Oracle Database Vault Reports?

You must log on using an account that has the DV_OWNER, DV_ADMIN, or DV_SECANALYST role before you can run the Oracle Database Vault reports. For more information about these roles, see the following sections:

11.3 How to Run Oracle Database Vault Reports

To run Oracle Database Vault reports:

  1. Log in to Database Vault Administrator.

    "Starting Oracle Database Vault Administrator" explains how to log in.

    Users who have the following roles can run the reports:

    • DV_OWNER

    • DV_ADMIN

    • DV_SECANALYST (least privileged)

  2. Select either Database Vault Reports or General Security Reports.

    These report categories are described in the following sections:

  3. Select a report and click Run Report to run the report.

    You can run many of the reports without any input parameters. For example, if you select the Audit Privileges Report, and click Run Report, then you can immediately see the report results. However, some of the available reports require at least one input parameter before the results can be displayed.

    The Report Results page displays the report content in a tabular fashion with the column headings shown at the top of the report. The page displays the report title as well as the date and time when the report was run. Click Return to Reports Menu to return to the Reports page, so that you can select and run a different report if you want.

    Some of the reports require at least one input parameter to be provided before they can be run. For example, when you select Object Dependencies Report and click Run Report, the Report Parameters page is displayed. The Owner box enables you to select the database account that owns the object. The Object Name field specifies the name of the object. You can use wildcard characters like the percentage sign (%), which defaults to all object names. The Result Set Size parameter determines the maximum number of result rows that are displayed. If you want all records to be displayed, then select All.The parameters that you enter on this page are passed directly to the SQL query that generates the report results. Click Run Report to display the report results based on the specified parameters.

11.4 Generating Oracle Database Vault Reports

To generate Oracle Database Vault reports, click the Database Vault Reports tab, and then select from the following categories of reports:

11.4.1 Oracle Database Vault Configuration Issues Reports

The configuration issues reports are:

11.4.1.1 Command Rule Configuration Issues Report

The Command Rule Configuration Issues Report displays command rules for which the following configuration issues exist:

  • Rule set for the command rule is disabled.

  • Rule set for the command rule is incomplete.

  • Object owner for the command rule does not exist. This can happen when the user account for the object has been dropped.

11.4.1.2 Factor Configuration Issues Report

The Factor Configuration Issues Report displays Oracle Database Vault factors for which the following configuration issues exist:

  • Rule set for factor assignment is disabled.

  • Rule set for factor assignment is incomplete.

  • Audit options for the factor are invalid.

  • No factor retrieval method or constant exists.

  • No subfactors (that is, child factors) are linked to a factor identity.

  • No subfactors (child factors) are linked to a label factor.

  • Oracle Label Security policy does not exist for the factor.

11.4.1.3 Factor Without Identities Report

The Factor Without Identities Report displays Oracle Database Vault factors that have no identities defined in the access control configuration. For some factors such as Background_Job_Id, this may not be a real problem, but the report can help you determine whether your access control configuration is complete and whether you have accounted for all factor configuration.

11.4.1.4 Identity Configuration Issues Report

The Identity Configuration Issues Report displays Oracle Database Vault factor identities where the following configuration issues exist:

  • Label identity for the Oracle Label Security label for this identity has been removed and no longer exists.

  • No map exists for the identity.

11.4.1.5 Realm Authorization Configuration Issues Report

The Realm Authorization Configuration Issues Report displays Oracle Database Vault realm information where the following configuration issues exist.

  • Rule set for a realm authorization is disabled.

  • Grantee does not exist for a realm authorization.

  • Owner does not exist for a realm-secured object. This can happen when the user account has been dropped.

In most cases, however, these types of issues are caught when you configure the realm and during validation.

11.4.1.6 Rule Set Configuration Issues Report

The Rule Set Configuration Issues Report displays Oracle Database Vault rule set information where the following configuration issue exists:

No rules are defined or enabled for a rule set.

11.4.1.7 Secure Application Configuration Issues Report

The Secure Application Configuration Issues Report displays Database Vault secure application role information where the following configuration issues exist:

  • Database role does not exist. This can happen when the database role has been dropped.

  • Rule set for role is disabled.

  • Rule set for role is incomplete.

11.4.2 Oracle Database Vault Auditing Reports

The auditing reports are:

11.4.2.1 Realm Audit Report

The Realm Audit Report shows audit records generated by the realm protection and realm authorization operations. You can manage realm authorizations by using rule sets, and then audit the rule set processing results. A realm violation occurs when the database account, performing an action on a realm-protected object, is not authorized to perform that action. Oracle Database Vault audits the violation even if you do not specify any rule sets attached to the realm. When you configure a realm, you can set it to audit instances of realm violations. You can use this information to investigate attempts to break security.

11.4.2.2 Command Rule Audit Report

The Command Rule Audit Report shows audit records generated by command rule processing operations. When you configure a command rule, you can set it to audit the rule set processing results.

11.4.2.3 Factor Audit Report

The Factor Audit Report shows factors that failed to evaluate or were set to create audit records under various conditions. It also shows failed attempts to set factors.

You can audit instances where a factor 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.

11.4.2.4 Label Security Integration Audit Report

The Label Security Integration Audit Report shows audit records generated by the session initialization operation and the session label assignment operation of label security. 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.

11.4.2.5 Core Database Vault Audit Trail Report

The Core Database Vault Audit Trail Report shows audit records generated by the core access security session initialization operation. You can audit instances where the access security session fails to initialize. It displays the following data:

Violation Attempt Instance Number
Timestamp Object Name
Return Code Rule Set
Account Command
User Host

11.4.2.6 Secure Application Role Audit Report

The Secure Application Role Audit Report shows the audit records generated by the secure application role-enabling operation for Oracle Database Vault.

11.5 Generating General Security Reports

To generate general security reports, click the General Security Reports tab, and then select from the following reports:

11.5.1 Object Privilege Reports

The object privilege reports are:

11.5.1.1 Object Access By PUBLIC Report

The Object Access By PUBLIC Report lists all objects whose access has been granted to PUBLIC. It details all the object access the database accounts that you specify on the Report Parameters page, through object grants to PUBLIC. On the Reports Parameters page, you can filter the results based on the privilege, the object owner, or the object name.

Note:

This report can be quite large if you choose the defaults.

11.5.1.2 Object Access Not By PUBLIC Report

The Object Access Not By PUBLIC Report describes all the object access the database accounts that you specify on the Report Parameters page, through grants to the account directly or through a role, but excluding the grants to PUBLIC. On the Reports Parameters page, you can filter the results based on the privilege, the object owner or the object name.

Note:

This report can be quite large if you choose the defaults.

11.5.1.3 Direct Object Privileges Report

The Direct Object Privileges Report shows the direct object privileges granted to nonsystem database accounts. The following database accounts are excluded from the report:

CTXSYS LBACSYS SYS WMSYS
DMSYS MDSYS SYSMAN
DVSYS ORDSYS SYSTEM
EXFSYS PUBLIC WKSYS

11.5.1.4 Object Dependencies Report

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. If a database object, such as a UTL_FILE package, has privileges granted to PUBLIC or some other global role, then you can use the Object Dependencies Report to determine an account that may depend on the object and to determine how the account uses the object. To run the report, enter the database account you are inspecting for dependency and the object it may be dependent on, in the Report Parameters page.

The Report Results page shows the dependent object and object type as well as the source object name and type. This report shows where the potentially sensitive object is being used. By looking at several accounts, you might be able to see patterns that can help you develop restricted roles. These restricted roles can replace PUBLIC grants on widely used sensitive objects.

11.5.2 Database Account System Privileges Reports

The database account system privileges reports are:

11.5.2.1 Direct System Privileges By Database Account Report

The Direct System Privileges By Database Account Report displays all system privileges that have been directly granted to the database account selected on the Report Parameters page. It also shows whether a privilege has been granted the WITH ADMIN option.

11.5.2.2 Direct and Indirect System Privileges By Database Account Report

The Direct and Indirect System Privileges By Database Account Report displays all the system privileges for the database account selected on the Report Parameters page. The system privileges may have been granted directly or granted through a database role that has the WITH ADMIN status.

11.5.2.3 Hierarchical System Privileges by Database Account Report

The Hierarchical System Privileges by Database Account Report displays a hierarchical breakdown of role-based system privileges and direct system privileges granted to the database account specified on the Report Parameters page.

11.5.2.4 ANY System Privileges for Database Accounts Report

The ANY System Privileges for Database Accounts Report shows all ANY system privileges granted to the specified database account or role. ANY system privileges are very powerful and should be judiciously assigned to accounts and roles.

11.5.2.5 System Privileges By Privilege Report

The System Privileges By Privilege Report displays the database accounts and roles that have the system privilege selected on the Report Parameters page.

11.5.3 Sensitive Objects Reports

The sensitive objects reports are:

11.5.3.1 Execute Privileges to Strong SYS Packages Report

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 resources or other powerful system packages. The following system packages are included:

DBMS_ALERT DBMS_RANDOM
DBMS_BACKUP_RESTORE DBMS_REPAIR
DBMS_CAPTURE_ADM DBMS_REPCAT
DBMS_DDL DBMS_REPCAT_ADMIN
DBMS_DISTRIBUTED_TRUST_ADMIN DBMS_RESOURCE_MANAGER
DBMS_FGA DBMS_RESOURCE_MANAGER_PRIVS
DBMS_JOB DBMS_RLS
DBMS_LDAP DBMS_SESSION
DBMS_LOB DEBUG_EXTPROC
DBMS_LOGMNR UTL_FILE
DBMS_LOGMNR_D UTL_HTTP
DBMS_OBFUSCATION_TOOLKIT UTL_SMTP
DBMS_ORACLE_TRACE_AGENT UTL_TCP
DBMS_PIPE

11.5.3.2 Access to Sensitive Objects Report

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 PROFILE$
ALL_USERS PROXY_ROLE_DATA$
APPROLE$ PROXY_ROLE_INFO$
AUD$ ROLE_ROLE_PRIVS
AUDIT_TRAIL$ SOURCE$
DBA_ROLE_PRIVS STATS$SQLTEXT
DBA_ROLES STATS$SQL_SUMMARY
DBA_TAB_PRIVS STREAMS$_PRIVILEGED_USER
DBMS_BACKUP_RESTORE SYSTEM_PRIVILEGE_MAP
DEFROLE$ TABLE_PRIVILEGE_MAP
FGA_LOG$ TRIGGER$
LINK$ USER$
OBJ$ USER_HISTORY$
OBJAUTH$ USER_TAB_PRIVS
OBJPRIV$ SYSTEM_PRIVILEGE_MAP

11.5.3.3 Public Execute Privilege To SYS PL/SQL Procedures Report

The Public Execute Privilege to SYS PL/SQL Procedures Report shows all database accounts and roles that have execute privileges on packages owned by SYS. This can be used to determine as to which privileges can be revoked from PUBLIC, or from other accounts and roles. This reduces vulnerabilities as part of an overall security policy implementation using the principle of least privilege.

11.5.3.4 Accounts with SYSDBA/SYSOPER Privilege Report

The Accounts with SYSDBA/SYSOPER Privilege Report displays database accounts that have SYS-privileged connection privileges. It also shows whether the accounts use an external password. However, note that this report does not include operating system users who can become SYSDBA.

11.5.4 Privilege Management - Summary Reports

The privilege management summary reports are:

11.5.4.1 Privileges Distribution By Grantee Report

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.

11.5.4.2 Privileges Distribution By Grantee, Owner Report

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. You can use this report if you suspect potential intruders or insider threats are looking for accounts that have powerful privileges as accounts to attack or compromise. If intruders can compromise the account, for example, by guessing the password, they can get more privileges than they already have.

11.5.4.3 Privileges Distribution By Grantee, Owner, Privilege Report

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.

11.5.5 Powerful Database Accounts and Roles Reports

The powerful database accounts and roles reports are:

11.5.5.1 WITH ADMIN Privilege Grants Report

The WITH ADMIN Privileges Grants Report shows all database accounts and roles that have been granted privileges with the WITH ADMIN clause. This privilege can be misused to give another account more system privileges than required.

11.5.5.2 Accounts With DBA Roles Report

The Accounts With DBA Roles Report shows all database accounts that have the DBA role granted to them. The DBA role is a privileged role that can be misused. It is often granted to a database account to save time and to avoid having to determine the least number of privileges an account really needs. This report can help you to start applying a policy using the principle of least privilege to an existing database.

For guidelines on deciding who should have privileged roles, see Appendix I, "Oracle Database Vault Security Guidelines".

11.5.5.3 Security Policy Exemption Report

The Security Policy Exemption Report shows database (but not Oracle 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. This is a powerful system privilege that should be granted only if absolutely necessary, as it presents a target to gain access to sensitive information in tables that are protected by Oracle Virtual Private Database or Oracle Label Security. You can use the auditing policies described in Appendix A, "Oracle Database Vault Auditing Policies" to audit the use of this privilege.

11.5.5.4 BECOME USER Report

The BECOME USER Report shows all database accounts roles that have the BECOME USER system privilege. This is a very powerful system privilege: it enables the IMPORT_FULL_DATABASE and EXPORT_FULL_DATABASE roles for use with Oracle Data Pump. Accounts that possess this privilege can be misused to get sensitive information or to compromise an application.

11.5.5.5 ALTER SYSTEM or ALTER SESSION Report

The ALTER SYSTEM or ALTER SESSION 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, for example, the SYS account and the DV_ADMIN role. The ALTER SYSTEM statement can be used to change the security-related database initialization parameters that are set to recommended values as part of the Oracle Database Vault security strengthening service. Both the ALTER SYSTEM and ALTER SESSION statements can be used to dump database trace files, potentially containing sensitive configuration information, to the operating system.

For guidelines on using the ALTER SYSTEM and ALTER SESSION privileges, see "Security Considerations for the ALTER SYSTEM and ALTER SESSION Privileges".

11.5.5.6 Password History Access Report

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. Access to this table can make guessing the existing password for an account easier for someone hacking the database.

11.5.5.7 WITH GRANT Privileges Report

The WITH GRANT Privileges Report shows all database accounts that have been granted privileges with the WITH GRANT clause. Remember that WITH GRANT is used for object-level privileges: An account that has been granted privileges using the WITH GRANT option can be misused to grant object privileges to another account.

11.5.5.8 Roles/Accounts That Have a Given Role Report

This report displays the database accounts and roles to which a role has been granted. This report is provided for dependency analysis.

11.5.5.9 Database Accounts With Catalog Roles Report

The Database Accounts With Catalog Roles Report displays all database accounts and roles that have the following roles granted to them:

  • DELETE_CATALOG_ROLE

  • EXECUTE_CATALOG_ROLE

  • RECOVERY_CATALOG_OWNER

  • SELECT_CATALOG_ROLE

These catalog-based roles have a very large number of powerful privileges. They should be granted with caution, much like the DBA role, which uses them.

11.5.5.10 AUDIT Privileges Report

The 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 a intruder who has compromised the system. The accounts that have this privilege could be targets for intruders.

11.5.5.11 OS Security Vulnerability Privileges Report

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.  

11.5.6 Initialization Parameters and Profiles Reports

The initialization parameters and profiles reports are:

11.5.6.1 Security Related Database Parameters Report

The Security Related Database Parameters 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.

11.5.6.2 Resource Profiles Report

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. You should review the profiles that might need a cap on the potential resource usage.

11.5.6.3 System Resource Limits Report

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. Resources that show large increases over a short period of time may point to a denial-of-service (DoS) attack. You might want to reduce the upper limit for the resource to prevent the condition in the future.

11.5.7 Database Account Password Reports

The database account password reports are:

11.5.7.1 Database Account Default Password Report

The Database Account Default Password Report lists the database accounts that have default passwords. Default passwords are provided during the Oracle Database installation.

You should change the passwords for accounts included in this report to nondefault, complex passwords to help secure the database.

11.5.7.2 Database Account Status Report

The Database Account Status Report provides a quick view of existing database accounts. The report shows the account status for each account, which helps you identify accounts that must be locked. Lock and expiry dates provide information that helps determine whether the account was locked as a result of password aging. If a special password and resource secure profile is used, then you can identify accounts that are not using them. Accounts not using organizationally defined default tablespaces also can be identified, and the temporary tablespace for accounts can be determined. This report also identifies accounts that use external passwords.

11.5.8 Security Audit Report: Core Database Audit Report

The Core Database Audit Report returns audit records for the audit policy defined in "About the Baseline Oracle Database Vault Auditing Policy", as well as any auditing records that are generated for audit statements you have defined.

This report only displays audit records that are captured if the database initialization parameter AUDIT_TRAIL has been set to DB. See "About the Baseline Oracle Database Vault Auditing Policy" for an example of how to set this parameter. For more information about the AUDIT_TRAIL parameter, see Oracle Database SQL Language Reference.

11.5.9 Other Security Vulnerability Reports

The other security vulnerability reports are:

11.5.9.1 Java Policy Grants Report

The Java Policy Grants Report shows the Java policy permissions stored in the database. It helps reveal violations to the principle of least privilege. Look for GRANT, READ, or WRITE privileges to PUBLIC or other accounts and roles that do not necessarily need the privilege. It is advisable to disable Java loading privileges from PUBLIC, if Java is not required in the database.

Note:

Oracle JVM, the Java virtual machine option provided with Oracle Database Vault, must be installed before you can run the Java Policy Grants Report.

11.5.9.2 OS Directory Objects Report

The OS Directory Objects Report shows all directory objects that exist in the database, whether or not 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. You should never use the root operating system directory on any storage device, for example, /, because it allows remote database sessions to look at all files on the device.

11.5.9.3 Objects Dependent on Dynamic SQL Report

The Objects Dependent on Dynamic SQL Report shows objects that leverage dynamic SQL. Potential intruders have a greater chance of using this channel if parameter checking or bind variables are not used. The report helps by narrowing the scope of where to look for problems by pointing out who is using dynamic SQL. Such objects can be a target for a SQL injection attack and must be secured to avoid this type of attack. After determining the objects that use dynamic SQL, do the following:

  • Check the privileges that client applications (for example, a Web application) have over the object.

  • Check the access granted for the object to PUBLIC or a wider account base.

  • Validate parameters.

  • Use bind variables where possible.

11.5.9.4 Unwrapped PL/SQL Package Bodies Report

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 helps reduce the ability of an intruder to circumvent data protection by eliminating the ability to read source code that manipulates data.

11.5.9.5 Username/Password Tables Report

The Username/Password Tables Report helps to identify application tables in the database that store user names and password strings. You should examine these tables to determine if the information is encrypted. (Search for column names such as %USER%NAME% or %PASSWORD%.) If it is not, modify the code and applications using these tables to protect them from being visible to database sessions.

11.5.9.6 Tablespace Quotas Report

The Tablespace Quotas Report shows all database accounts that have quotas on one or more tablespaces. These tablespaces can become potential targets for denial-of-service (DoS) attacks.

11.5.9.7 Non-Owner Object Trigger Report

The Non-Owner Object Trigger Report lists 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, then it can steal sensitive data, possibly from tables protected through Oracle Label Security or Virtual Private Database (VPD), and place it into an unprotected table for subsequent viewing or export.