The Object Access By PUBLIC Report lists all objects whose access has been granted to PUBLIC.

This report 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.

The Object Access Not By PUBLIC Report describes the object access used by the database accounts on the Report Parameters page.

It checks the 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.

The Direct Object Privileges Report shows the direct object privileges granted to nonsystem database accounts.

The following database accounts are excluded from the report:

The Object Dependencies Report describes dependencies in the database between procedures, packages, functions, package bodies, and triggers.

The report includes dependencies on views created without any database links.

This report 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 and 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.

The Direct System Privileges By Database Account Report lists system privileges directly granted to the database account selected on the Report Parameters page.

This report also shows whether a privilege has been granted the WITH ADMIN option.

The Direct and Indirect System Privileges By Database Account Report displays 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.

The Hierarchical System Privileges by Database Account Report shows a hierarchical breakdown of role-based system privileges and direct system privileges.

These privileges are granted to the database account specified on the Report Parameters page.

The ANY System Privileges for Database Accounts Report shows 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.

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

Another way to control privileges is to create privilege analysis policies to analyze privilege use.

The Execute Privileges to Strong SYS Packages Report shows database accounts and roles with the EXECUTE privilege on powerful system packages.

For example, these types of packages can be used to access operating system resources.

The following system PL/SQL packages are included:

The Access to Sensitive Objects Report shows database accounts and roles that have object privileges on system tables or views that have sensitive information.

This report includes the following system tables and views:

The Public Execute Privilege to SYS PL/SQL Procedures Report shows database accounts and roles that have EXECUTE privileges on that SYS owns.

This report 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 security policy implementation using the principle of least privilege.

The Accounts with SYSDBA/SYSOPER Privilege Report displays database accounts that have SYS-privileged connection privileges.

This report also shows whether the accounts use an external password. However, note that this report does not include operating system users who can become SYSDBA.

The Privileges Distribution By Grantee Report displays the count of privileges granted to a database account or role.

This report 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 report 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.

The Privileges Distribution By Grantee, Owner, Privilege Report displays a count of privileges based on the privilege, the grantee, and the object owner.

This report provides insight into the accounts or roles that may have powerful privileges.

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.

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.

The Security Policy Exemption Report shows database (but not Oracle Database Vault) accounts and roles that have the EXEMPT ACCESS POLICY system privilege.

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 Auditing Oracle Database Vault, to audit the use of this privilege.

The BECOME USER Report shows database accounts roles that have the BECOME USER system privilege.

The BECOME USER privilege is a very powerful system privilege: it enables the IMP_FULL_DATABASE and EXP_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.

The ALTER SYSTEM or ALTER SESSION Report shows 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.

The Password History Access Report shows database accounts that have access to the USER_HISTORY$ table.

This table 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.

The WITH GRANT Privileges Report shows database accounts that are 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.

This report displays the database accounts and roles to which a role has been granted.

This report is provided for dependency analysis.

The Database Accounts With Catalog Roles Report displays all database accounts and roles that have the catalog-related roles granted to them.

These roles are as follows:

• 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.

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.

The OS Security Vulnerability Privileges Report lists database accounts and roles that have privileges to export sensitive information to the operating system.

This report can reveal important vulnerabilities related to the operating system.

The Security Related Database Parameters Report lists database parameters that can cause security vulnerabilities if they not set correctly.

This report can be used to compare the recommended settings with the current state of the database parameter values.

The Resource Profiles Report lists resource profiles that may be allowing unlimited resource consumption.

Examples of resource profiles are CPU_PER_SESSION and IDLE_TIME. You should review the profiles that might need a cap on the potential resource usage.

The System Resource Limits Report provides insight into the current system resource usage by the database.

This report 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 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.

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.

The Database Account Status Report lists existing database accounts.

This 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.

The Java Policy Grants Report shows the Java policy permissions stored in the database.

This report 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.

The OS Directory Objects Report shows directory objects in the database, their privileges, and whether they are available to PUBLIC.

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.

The Objects Dependent on Dynamic SQL Report lists objects that use 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.

The Unwrapped PL/SQL Package Bodies Report lists 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 or from the data dictionary views. This helps reduce the ability of an intruder to circumvent data protection by eliminating the ability to read source code that manipulates data.

The Username/Password Tables Report identifies 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.

The Tablespace Quotas Report lists database accounts that have quotas on one or more tablespaces.

These tablespaces can become potential targets for denial-of-service (DoS) attacks.

The Non-Owner Object Trigger Report lists non-owner triggers.

These are 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.