Assessment Time & Date

Displays the date on which the data was collected and the date on which the final Database Security Assessment report was generated. The DBSAT Reporter version is also displayed.

Database Identity

Displays the details of the database assessed by DBSAT.

Summary

Displays a high level summary of the resulting analysis.

Database Version

Displays the version of the database assessed by the Collector and Reporter.

Security Features

Displays the security features and indicates if they are in use.

Patch Check

INFO.PATCH

Displays information about the patches installed.

It is vital to keep the database software up-to-date with security fixes as they are released. Oracle issues comprehensive patches in the form of Release Updates, Patch Set Updates, and Bundle Patches on a regular quarterly schedule. These updates should be applied as soon as they are available.

User Accounts

Displays the user accounts and the following information about each account:

• User Name — Displays the name of the user.

• Status — Displays whether the account is Open, Locked, or Expired.

• Profile — Displays the profile type.

• Tablespace — Displays the tablespace used by the account.

• Oracle Defined — Displays whether the user account is oracle maintained or not.

• Authorization Type — Displays the type of authorization used.

User Schemas in SYSTEM or SYSAUX Tablespace

Displays information about the regular user accounts that use the reserved Oracle-supplied tablespaces.

The SYSTEM and SYSAUX tablespaces are reserved for Oracle-supplied user accounts. To avoid a possible denial of service caused by exhausting these resources, regular user accounts should not use these tablespaces. Prior to Oracle Database 12.2, the SYSTEM tablespace cannot be encrypted, and this is another reason to avoid user schemas in this tablespace.

Sample Schemas

Displays information about the user accounts that use sample schemas such as SCOTT, HR, OE, SH, PM, IX, ADAMS, BLAKE, CLARK, and BI.

Sample schemas are well-known accounts provided by Oracle to serve as simple examples for developers. They generally serve no purpose in a production database and should be removed because they unnecessarily increase the attack surface of the database.

Inactive Users

Displays information about the user accounts that are not in use and also accounts that are not configured to be locked when inactive.

If a user account is no longer in use, it increases the attack surface of the system unnecessarily while providing no corresponding benefit. Furthermore, unauthorized use is less likely to be noticed when no one is regularly using the account. Accounts that have been unused for more than 30 days should be investigated to determine whether they should remain active. A solution is to set INACTIVE_ACCOUNT_TIME in the profiles assigned to users.

Case-Sensitive Passwords

Displays whether case-sensitive passwords are enabled.

Case-sensitive passwords are recommended because including both upper and lower-case letters greatly increases the set of possible passwords that must be searched by an attacker who is attempting to guess a password by exhaustive search. Setting SEC_CASE_SENSITIVE_LOGON to TRUE ensures that the database distinguishes between upper and lower-case letters in passwords.

Users with Expired Passwords

Displays information about the user accounts with expired passwords.

Password expiration is used to ensure that users change their passwords on a regular basis. If a user's password has been expired for more than 30 days, it indicates that the user has not logged in for at least that long. Accounts that have been unused for an extended period of time should be investigated to determine whether they should remain active.

Users with Default Passwords

Displays information about the user accounts with default passwords.

Default account passwords for predefined Oracle accounts are well known. Active accounts with default passwords provide a trivial means of entry for attackers, but well-known passwords should be changed for locked accounts as well.

Displays information about the Gradual Password Rollover.

Gradual Password Rollover allows administrators to change database passwords for applications without having to schedule downtime. Prior to the advent of the gradual password rollover feature, the database administrator needed to take the application down while the database password was being rotated. This was because the password update required changes on both the database and the application side. With gradual database password rollover, the application can continue to use the older password until the new password is configured in the application. To accomplish this, the database administrator can associate a profile having a non-zero limit for the PASSWORD_ROLLOVER_TIME password profile parameter with an application schema. This allows the database password of the application user to be altered while allowing the older password to remain valid for the time specified by the PASSWORD_ROLLOVER_TIME limit. Try to limit the use of this feature to application schemas that need to undergo password maintenance and keep the rollover period to the minimum.

Minimum Client Authentication Version

Displays information about the user accounts that do not have minimum client version specified in the ALLOWED_LOGON_VERSION_SERVER parameter in the sqlnet.ora file.

Over time, Oracle releases have added support for increasingly secure versions of the algorithm used for password authentication of user accounts. In order to remain compatible with older client software, the database continues to support previous password versions as well. The sqlnet.ora parameter ALLOWED_LOGON_VERSION_SERVER determines the minimum password version that the database will accept. For maximum security, this parameter should be set to the highest value supported by the database once all client systems have been upgraded.

Password Verifiers

Displays information about the user accounts with obsolete password verifiers.

For each user account, the database may store multiple verifiers, which are hashes of the user password. Each verifier supports a different version of the password authentication algorithm. Every user account should include a verifier for the latest password version supported by the database so that the user can be authenticated using the latest algorithm supported by the client. When all clients have been updated, the security of user accounts can be improved by removing the obsolete verifiers. HTTP password verifiers are used for XML Database authentication. Use the ALTER USER command to remove these verifiers from user accounts that do not require this access.

User Parameters

Displays information about the user account initialization parameters.

SEC_MAX_FAILED_LOGIN_ATTEMPTS configures the maximum number of failed login attempts in a single session before the connection is closed. This is independent of the user profile parameter FAILED_LOGIN_ATTEMPTS, which controls locking the user account after multiple failed login attempts. RESOURCE_LIMIT should be set to TRUE to enable enforcement of any resource constraints set in user profiles.

User Profiles

Displays information about the user profiles.

Users with Unlimited Password Lifetime

Displays information about user profile password expiration enforcement.

Password expiration is used to ensure that users change their passwords on a regular basis. It also provides a mechanism to automatically disable temporary accounts. Passwords that never expire may remain unchanged for an extended period of time. When passwords do not have to be changed regularly, users are also more likely to use the same passwords for multiple accounts.

Account Locking after Failed Login Attempts

Displays information about user profile failed login attempt enforcement.

Attackers sometimes attempt to guess a user's password by simply trying all possibilities from a set of common passwords. To defend against this attack, it is advisable to use the FAILED_LOGIN_ATTEMPTS and PASSWORD_LOCK_TIME profile resources to lock user accounts for a specified time when there are multiple failed login attempts without a successful login.

Password Verification Functions

Displays information about profiles with and without a password complexity verification function. Users not subject to password complexity verification are also displayed.

Password verification functions are used to ensure that user passwords meet minimum requirements for complexity, which may include factors such as length, use of numbers or punctuation characters, difference from previous passwords, etc. Oracle supplies several predefined functions, or a custom PL/SQL function can be used. Every user profile should include a password verification function.

Users with Unlimited Concurrent Sessions

Displays all users that have a Profile Resource Limit for SESSIONS_PER_USER set to UNLIMITED. With SESSIONS_PER_USER = UNLIMITED users can have any number of concurrent sessions.

System Privilege Grants

Displays the system privileges granted to users.

System privileges provide the ability to access data or perform administrative operations for the entire database. Consistent with the principle of least privilege, these privileges should be granted sparingly. System privileges should be granted with admin option only when the recipient needs the ability to grant the privilege to others.

-g option reports all grants including common grants in a PDB. The report displays (*) for privileges being granted with admin option, (D) for privileges being granted directly, and (C) for privileges being granted commonly.

All Roles

Displays all roles granted to users.

Roles are a convenient way to manage groups of related privileges, especially when the privileges are required for a particular task or job function. Beware of broadly defined roles, which may confer more privileges than an individual recipient requires. Roles should be granted with admin option only when the recipient needs the ability to modify the role or grant it to others.

Code Based Access Control

Displays all program units granted CBAC roles.

Code Based Access Control(CBAC) can be used to grant additional privileges on program units. CBAC allows you to attach database roles to a PL/SQL function, procedure, or package. These database roles are enabled at run time, enabling the program unit to execute with the required privileges in the calling user's environment.

Account Management Privileges

Displays account management privileges granted to users.

User management privileges (ALTER USER, CREATE USER, DROP USER) can be used to create and modify other user accounts, including changing passwords. This power can be abused to gain access to another user's account, which may have greater privileges.

Role and Privilege Management Privileges

Displays privilege management privileges granted to users.

Users with privilege management privileges (ALTER ANY ROLE, CREATE ROLE, DROP ANY ROLE, GRANT ANY OBJECT PRIVILEGE, GRANT ANY PRIVILEGE, GRANT ANY ROLE) can change the set of privileges granted to themselves and other users. This ability should be granted sparingly, since it can be used to circumvent many security controls in the database.

Database Management Privileges

Displays database management privileges granted to users.

Database management privileges (ALTER DATABASE, ALTER SYSTEM, CREATE ANY LIBRARY, CREATE LIBRARY) can be used to change the operation of the database and potentially bypass security protections. This ability should be granted only to trusted administrators.

Audit Management Package

Displays audit management tool access granted to users.

The DBMS_AUDIT_MGMT package allow for execution of Audit management tools. Access should be strictly limited and granted only to users with a legitimate need for this functionality.

Audit Management Privileges

Displays audit management privileges granted to users.

Audit management privileges (AUDIT ANY, AUDIT SYSTEM) can be used to change the audit policies for the database. This ability should be granted sparingly, since it may be used to hide malicious activity.

Broad Data Access Privileges

Displays data access privileges granted to users.

Users with data access privileges (ALTER ANY TABLE, ALTER ANY TRIGGER, CREATE ANY INDEX, CREATE ANY PROCEDURE, CREATE ANY TRIGGER, DELETE ANY TABLE, INSERT ANY TABLE, READ ANY TABLE, SELECT ANY DICTIONARY, SELECT ANY TABLE, UPDATE ANY TABLE) have very broad access to data stored in any schema. Most administrative tasks do not require access to the data itself, so these privileges should be granted rarely even to administrators. In addition to minimizing grants of these privileges, consider the use of Database Vault realms to limit the use of these privileges to access sensitive data.

Access Control Exemption Privileges

Displays access control exemption privileges that are enforced.

Users with exemption privileges (EXEMPT ACCESS POLICY, EXEMPT REDACTION POLICY) can bypass the row and column access control policies enforced by Virtual Private Database and Data Redaction. Most administrative tasks do not require access to the data itself, so these privileges should be granted rarely even to administrators.

Access to Password Verifier Tables

Displays access to password verifier tables granted to users.

Users with these privileges can access objects that contain user password verifiers. The verifiers can be used in offline attacks to discover user passwords.

Write Access to Restricted Objects

Displays access to restricted objects granted to users.

Users with these privileges can directly modify objects in the SYS, DVSYS, AUDSYS or LBACSYS schemas. Manipulating these system objects may allow security protections to be circumvented or otherwise interfere with normal operation of the database. Object permissions granted to PUBLIC must be restricted for objects in the SYS, DVSYS, AUDSYS or LBACSYS schemas.

Access to Audit Objects

Displays access to audit objects granted to users.

Users with these privileges can directly access and modify objects containing audit information. Access to these objects may allow a malicious user deduce privilege settings for other users and to manipulate the audit information by replacing or deleting audit records.

User Impersonation Privilege

Displays the user accounts that have been granted rights to impersonate other users.

The BECOME USER privilege and these PL/SQL packages (DBMS_AQADM_SYS, DBMS_AQADM_SYSCALLS, DBMS_IJOB, DBMS_PRVTAQIM, DBMS_REPCAT_SQL_UTL, DBMS_SCHEDULER, DBMS_STREAMS_ADM_UTL, DBMS_STREAMS_RPC, DBMS_SYS_SQL, INITJVMAUX, LTADM, WWV_DBMS_SQL, WWV_EXECUTE_IMMEDIATE) allow for execution of SQL code or external jobs using the identity of a different user. Access should be strictly limited and granted only to users with a legitimate need for this functionality.

Data Exfiltration

Displays the user accounts that have been granted rights to access or copy any data from a client or server.

These PL/SQL packages (DBMS_BACKUP_RESTORE, UTL_DBWS, UTL_ORAMTS) can send data from the database using the network or file system. Access should be granted only to users with a legitimate need for this functionality.

System Privileges Granted to PUBLIC

Displays the system privileges granted to PUBLIC.

Privileges granted to PUBLIC are available to all users. This generally should include few, if any, system privileges since these will not be needed by ordinary users who are not administrators.

Roles Granted to PUBLIC

Displays the roles granted to PUBLIC.

Roles granted to PUBLIC are available to all users. Most roles contain privileges that are not appropriate for all users.

Column Privileges Granted to PUBLIC

Displays the column access privileges granted to PUBLIC.

Privileges granted to PUBLIC are available to all users. This should include column privileges only for data that is intended to be accessible to everyone.

Users with DBA Role

Displays the user accounts that have been granted the DBA or PDB_DBA role.

The DBA role is very powerful and can be used to bypass many security protections. It should be granted to only a small number of trusted administrators. Furthermore, each trusted user should have an individual account for accountability reasons. As with any powerful role, avoid granting the DBA role with admin option unless absolutely necessary.

Users with Powerful Roles

Displays the user accounts that have been granted roles with maximum data access privileges.

Like the DBA role, these roles (AQ_ADMINISTRATOR_ROLE, EM_EXPRESS_ALL, EXP_FULL_DATABASE, IMP_FULL_DATABASE, SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE, DELETE_CATALOG_ROLE, OEM_MONITOR) contain powerful privileges that can be used to bypass security protections. They should be granted only to a small number of trusted administrators.

Java Permissions

Displays the user accounts that have been granted privileges to execute Java classes within the database.

Java permission grants control the ability of database users to execute Java classes within the database server. A database user executing Java code must have both Java security permissions and database privileges to access resources within the database. These resources include database resources, such as tables and PL/SQL packages, operating system resources, such as files and sockets, Oracle JVM classes, and user-loaded classes. Make sure that these permissions are limited to the minimum required by each user.

Users with Administrative Privileges SYS* Privileges

Displays the administrative privileges granted to user accounts.

Administrative privileges allow a user to perform maintenance operations, including some that may occur while the database is not open. The SYSDBA privilege allows the user to run as SYS and perform virtually all privileged operations. Starting with Oracle Database 12.1, less powerful administrative privileges were introduced to allow users to perform common administrative tasks with less than full SYSDBA privileges. To achieve the benefit of this separation of duty, each of these administrative privileges should be granted to at least one user account.

Database Vault

Displays whether Oracle Database Vault is enabled and details existing protected objects, realms, command rules, and users granted Database Vault specific roles.

Database Vault provides for configurable policies to control the actions of database accounts with elevated privileges such as those accounts used by administrative users, applications and utilities. Attacks (originating from external as well as internal sources) leverage privileged account credentials to access sensitive information. Database Vault realms prevent unauthorized access to sensitive data objects, even by user accounts with system privileges. Database Vault Command rules limit the accidental or malicious execution of SQL commands. You can use Database Vault to enforce separation of duties to prevent a single all powerful user. Also it provides trusted paths to further restrict access to sensitive data using system factors such as IP address, program name, time of day and user name. Database Vault operations control can be used to restrict common users from accessing pluggable database (PDB) local data in autonomous, regular Cloud, or on-premises environments.

Privilege Analysis

Displays Privilege Analysis policies and users with privileges to start the capture proces.

Privilege Analysis records the privileges used during a real or simulated workload. After collecting data about the privileges that are actually used, this information can be used to revoke privilege grants that are no longer needed or to create roles with only the privileges that are used by the user or role. This helps implement Least Privilege Model and minimizes risk from intentional or accidental abuse of privileges.

Data Redaction

Displays information on Data Redaction policies, exempted users, and execute grants on the DBMS_REDACT package.

Data Redaction automatically masks sensitive data found in the results of a database query.

Virtual Private Database

Displays information on Virtual Private Database policies, exempted users, and execute grants on the DBMS_RLS package.

VPD allows for fine-grained control over the rows and columns of a table are visible to a SQL statement.

Real Application Security

Displays information on Real Application Security policies, exempted users, and users granted ADMIN_SEC_POLICY and APPLY_SEC_POLICY.

Real Application Security (RAS) is a more modern, advanced version of Virtual Private Database and provides fine-grained control over the rows and columns of a table that are visible to a SQL statement.

Label Security

Displays whether Oracle Label Security is enabled.

Oracle Label Security provides the ability to tag data with a data label or a data classification. Access to sensitive data is controlled by comparing the data label with the requesting user's label or security clearance.

Transparent Sensitive Data Protection

Displays information on Transparent Sensitive Data policies and the users that can manage it.

TSDP was introduced in Oracle Database 12.1, and allows a data type to be associated with each column that contains sensitive data. TSDP can then apply various data security features to all instances of a particular type so that protection is uniform and consistent.

Audit Records

Displays information about audit trails.

Auditing is an essential component for securing any system. The audit trail allows for monitoring the activities of highly privileged users.

Audit SQL Statements

Displays information about SQL statements audited by enabled audit policies.

Audit Object Actions

Displays information about the object access audited by enabled audit policies.

Audit System Privileges

Displays information about the privileges audited by enabled audit policies.

Audit Administrative (SYS*) Users

Displays whether the actions of the SYS user are audited by enabled audit policies.

It is important to audit administrative actions performed by the SYS user. Traditional audit policies do not apply to SYS, so the AUDIT_SYS_OPERATIONS parameter must be set to record SYS actions to a separate audit trail.

Audit Privilege Management

Displays whether the actions related to privilege management are audited by enabled audit policies.

Granting additional privileges to users or roles potentially affects most security protections and should be audited. Each action or privilege listed should be included in at least one enabled audit policy.

Audit Account Management Activities

Displays whether the actions related to account management are audited by enabled audit policies.

Creation of new user accounts or modification of existing accounts can be used to gain access to the privileges of those accounts and should be audited. Each action or privilege listed should be included in at least one enabled audit policy.

Database Management Audit

Displays whether the actions related to database management are audited by enabled audit policies.

Actions that affect the management of database features should always be audited. Each action or privilege listed should be included in at least one enabled audit policy.

Audit Powerful Privileges

Displays whether the use of powerful system privileges are audited by enabled audit policies.

The use of powerful system privileges should always be audited. Each privilege listed should be included in at least one enabled audit policy.

Audit User Logon / Logoff

Displays whether Database connections are audited by enabled audit policies.

Successful user connections to the database should be audited to assist with future forensic analysis. Unsuccessful connection attempts can provide early warning of an attacker's attempt to gain access to the database.

Fine Grained Audit

Displays whether fine grained audit policies are enabled.

Fine Grained Audit policies can record highly specific activity, such as access to particular table columns or access that occurs under specified conditions. This is a useful way to monitor unexpected data access while avoiding unnecessary audit records that correspond to normal activity.

Unified Audit Policies

Displays whether unified audit policies are enabled.

Unified Audit, available in Oracle Database 12.1 and later releases, combines multiple audit trails into a single unified view. It also introduces new syntax for specifying effective audit policies.

Transparent Data Encryption

Displays whether column or tablespace encryption is in use. Also, shows encrypted and unencrypted tablespaces along with the number of days since the master encryption key was last rotated.

Encryption of sensitive data is a requirement in most regulated environments. Transparent Data Encryption automatically encrypts data as it is stored and decrypts it upon retrieval. This protects sensitive data from attacks that bypass the database and read data files directly.

Encryption Key Wallet

Displays wallet information.

Wallets are encrypted files used to store encryption keys, passwords, and other sensitive data. Wallet files should not be stored in the same directory with database data files, to avoid accidentally creating backups that include both encrypted data files and the wallet containing the master key protecting those files. For maximum separation of keys and data, consider storing encryption keys in Oracle Key Vault instead of wallet files.

Displays information whether TDE and DBMS_CRYPTYO run in a FIPS-compliant mode.

Federal Information Processing Standard (140-2) is a U.S. government security standard that specifies security requirements. It is used to approve cryptographic modules. Setting parameter DBFIPS_140 = TRUE enables Transparent Data Encryption (TDE) and DBMS_CRYPTO PL/SQL package program units to run in a FIPS-compliant mode. FIPS mode is mostly used by departments and agencies of the United States federal government looking to meet FIPS and/or STIG compliance. Be aware that this setting and thus using the underlying FIPS-certified library incurs a slight amount of overhead when the library is first loaded. This is due to the verification of the library signature and the execution of the self-test.

Initialization Parameters for Security

Displays security related Database initialization parameters and their values.

Access to Dictionary Objects

Displays whether access to dictionary objects is properly limited.

When O7_DICTIONARY_ACCESSIBILITY is set to FALSE, tables owned by SYS are not affected by the ANY TABLE system privileges. This parameter should always be set to FALSE because tables owned by SYS control the overall state of the database and should not be subject to manipulation by users with ANY TABLE privileges.

Inference of Table Data

Displays whether data inference attacks are properly blocked.

When SQL92_SECURITY is set to TRUE, UPDATE and DELETE statements that refer to a column in their WHERE clauses will succeed only when the user has the privilege to SELECT from the same column. This parameter should be set to TRUE so that this requirement is enforced in order to prevent users from inferring the value of a column which they do not have the privilege to view.

Access to Password File

Displays whether the password file is configured correctly.

The REMOTE_LOGIN_PASSWORDFILE set to EXCLUSIVE allows the password file to contain distinct entries for each administrative user allowing them to be individually audited and tracked for their actions. It also allows passwords to be updated using the ALTER USER command.

Database link global names

Displays whether database link names are different from or the same as database names.

The GLOBAL_NAMES parameter is used to set the requirement for database link names to be the same name as the remote database whose connection they define. By using the same name for both, ambiguity is avoided and unauthorized or unintended connections to remote databases are less likely.

Network Communications

Displays information about initialization parameters that determine the database server response to malformed packets. Also, includes details on usage of a remote listener and if database server version information is hidden from unauthenticated client requests.

REMOTE_LISTENER allows a network listener running on another system to be used. This parameter should normally be unset to ensure that the local listener is used. The SEC_PROTOCOL_ERROR parameters control the database server's response when it receives malformed network packets from a client. Because these malformed packets may indicate an attempted attack by a malicious client, the parameters should be set to log the incident and terminate the connection.

SEC_RETURN_SERVER_RELEASE_BANNER should be set to FALSE to limit the information that is returned to an unauthenticated client, which could be used to help determine the server's vulnerability to a remote attack.

External Authorization

Displays whether the Oracle Database roles are defined and managed by the database itself or by the host operating system (for local and remote authorization).

The OS_ROLES parameter determines whether roles granted to users are controlled by GRANT statements in the database or by the database server's operating system. REMOTE_OS_AUTHENT and REMOTE_OS_ROLES allow the client operating system to set the database user and roles. All of these parameters should be set to FALSE so that the authorizations of database users are managed by the database itself.

Trace Files

Displays information about the initialization parameters for trace files.

The hidden parameter _TRACE_FILES_PUBLIC determines whether trace files generated by the database should be accessible to all OS users. Since these files may contain sensitive information, access should be limited by setting this parameter to FALSE.

Instance Name Check

Displays whether the instance name contains the Database version number.

Instance names should not contain Oracle version numbers. Service names may be discovered by unauthenticated users. If the service name includes version numbers or other database product information, a malicious user may use that information to develop a targeted attack.

Triggers

Displays information about logon triggers.

A trigger is code that executes whenever a specific event occurs, such as inserting data in a table or connecting to the database. Disabled triggers are a potential cause for concern because whatever protection or monitoring they may be expected to provide is not active.

Disabled Constraints

Displays information about disabled constraints.

Constraints are used to enforce and guarantee specific relationships between data items stored in the database. Disabled constraints are a potential cause for concern because the conditions they ensure are not enforced.

External Procedures

Displays information about external procedures and services.

External procedures allow code written in other languages to be executed from PL/SQL. Note that modifications to external code cannot be controlled by the database. Be careful to ensure that only trusted code libraries are available to be executed. Although the database can spawn its own process to execute the external procedure, it is advisable to configure a listener service for this purpose so that the external code can run as a less-privileged OS user. The listener configuration should set EXTPROC_DLLS to identify the specific shared library code that can be executed rather than using the default value ANY.

Directory Objects

Displays information about directory objects.

Directory objects allow access to the server's file system from PL/SQL code within the database. Access to files that are used by the database kernel itself should not be permitted, as this may alter the operation of the database and bypass its access controls.

Database Links

Displays information about database links.

Database links allow users to execute SQL statements that access tables in other databases. This allows for both querying and storing data on the remote database. It is advisable to set GLOBAL_NAMES to TRUE in order to ensure that link names match the databases they access.

Network Access Control

Displays information about Network Access Control Lists (ACLs).

Network ACLs control the external servers that database users can access using network packages such as UTL_TCP and UTL_HTTP. Specifically, a database user needs the connect privilege to an external network host computer if he or she is connecting using the UTL_TCP, UTL_HTTP, UTL_SMTP, and UTL_MAIL utility packages. To convert between a host name and its IP address using the UTL_INADDR package, the Resolve privilege is required. Make sure that these permissions are limited to the minimum required by each user.

XML Database Access Control

Displays information about XML Database Access Control Lists (ACLs).

XML ACLs control access to database resources using the XML DB feature. Every resource in the Oracle XML DB Repository hierarchy has an associated ACL. The ACL mechanism specifies a privilege-based access control for resources to principals, which are database users or roles. Whenever a resource is accessed, a security check is performed, and the ACL determines if the requesting user has sufficient privileges to access the resource. Make sure that these privileges are limited to the minimum required by each user.

Database Backup

Displays information about Database backup records.

Database should be backed up regularly to prevent loss of data in the event of a system failure. Oracle Recovery Manager (RMAN) allows performing backup and recovery tasks on your databases. Unencrypted backup data should not be transported on tape or disk to offsite storage for safekeeping. Oracle Secure Backup (OSB) may also be used for tape data protection in a distributed environment.

Network Encryption

Displays information about network encryption.

Network encryption protects the confidentiality and integrity of communication between the database server and its clients. Either Native Encryption or TLS should be enabled. For Native Encryption, both ENCRYPTION_SERVER and CRYPTO_CHECKSUM_SERVER should be set to REQUIRED. If TLS is used, TCPS should be specified for all network ports and SSL_CERT_REVOCATION should be set to REQUIRED.

Client Nodes

Displays whether the database accepts connections from any client.

TCP.VALIDNODE_CHECKING should be enabled to control which client nodes can connect to the database server. Either an allowlist of client nodes allowed to connect (TCP.INVITED_NODES) or a blocklist of nodes that are not allowed (TCP.EXCLUDED_NODES) may be specified. Configuring both lists is an error; only the invited node list will be used in this case.

SQLNET Banners

Displays whether SQLNET connect banner messages are configured.

These banner messages are used to warn connecting users that unauthorized access is not permitted and that their activities may be audited.

Network Listener Configuration

Displays information about network listener configuration.

These parameters are used to limit changes to the network listener configuration.

ADMIN_RESTRICTIONS should be enabled to prevent parameter changes to the running listener. One of the following restrictions on service registration should be implemented:

• Prevent changes by disabling DYNAMIC_REGISTRATION

• Limit the nodes that can make changes by enabling VALID_NODE_CHECKING_REGISTRATION

• Limit the network sources for changes using the COST parameters SECURE_PROTOCOL, SECURE_CONTROL, and SECURE_REGISTER. CONNECTION_RATE determines rate enforced across all the endpoints that are rate limited

Listener Logging Control

Displays information about network listener logging configuration.

The LOGGING_LISTENER parameter enables logging of listener activity. Log information can be useful for troubleshooting and to provide early warning of attempted attacks.

OS Authentication

Displays information about operating system group names and users that can exercise administrative privileges.

OS authentication allows operating system users within the specified user group to connect to the database with administrative privileges. This shows the OS group names and users that can exercise each administrative privilege. OS users with administrative privileges should be reviewed to prevent any unauthorized, malicious or unintentional access to the database.

Process Monitor Process

Displays whether Process Monitor (PMON) processes are running under the ORACLE_HOME owner account.

The PMON process monitors user processes and frees resources when they terminate. This process should run with the user ID of the ORACLE_HOME owner.

Agent Processes

Displays whether Agent processes owners overlap with Listener or Process Monitor (PMON) process owners.

Agent processes should run with a user ID separate from the database and listener processes. These processes should run under a user ID separate from the database and listener processes.

Listener Processes

Displays whether Listener process owners overlap with Agent or Process Monitor (PMON) process owners.

Listener processes accept incoming network connections and connect them to the appropriate database server process. These processes should run with a user ID separate from the database and agent processes. These processes should be administered only through local OS authentication.

File Permissions in ORACLE_HOME

Displays information about file permissions errors in the ORACLE_HOME.

The ORACLE_HOME directory and its subdirectories contain files that are critical to the correct operation of the database, including executable programs, libraries, data files, and configuration files. Operating system file permissions must not allow these files to be modified by users other than the ORACLE_HOME owner and must not allow other users to directly read the contents of Oracle data files.

<network service name location>

Location from where network service names needs to be read

<net_service_name>

Network Service name to be used to make connection

<SSL wallet location> | <SEPS wallet location>

Location of wallets for secured connections via SSL or SEPS (Secure External Password Store)

<hostname> | <ip_address>

Hostname or IP Address of the target database server

<portnumber>

The default is 1521.

Listener port number for the target database. If a port number is not specified, the default port 1521 is used.

<service_name>

Service name for the target database

TRUE | FALSE

The default is FALSE.

Specifies if SSL is enabled or disabled when connecting to the Database Server. This is an optional argument.

It is recommended that the SSL_ENABLED value is set to TRUE. Retain the default FALSE value if you do not require an SSL connection to the Database Server.

If SSL_ENABLED = TRUE, then SSL_TRUSTSTORE is mandatory.

<Absolute path to the TrustStore/TrustStore filename>

Example: /opt/oracle/wallets/truststore.jks

Specifies the absolute path to the TrustStore, and the TrustStore file name.

Mandatory if SSL_ENABLED = TRUE.

PKCS12 | JKS | SSO

Specifies the type of TrustStore.

Use PKCS12 if the Truststore is a Wallet.

Use JKS if the Truststore is a Java KeyStore.

Use SSO if the Truststore is an auto-login SSO Wallet.

<Absolute path to the KeyStore/KeyStore filename>

Example: /opt/oracle/wallets/keystore.jks

Specifies the absolute path to the KeyStore, and the KeyStore file name.

If SSL_KEYSTORE is not specified, the value specified in SSL_TRUSTSTORE is used.

Mandatory if the Database server requires client authentication.

PKCS12 | JKS | SSO

Specifies the type of KeyStore.

Use PKCS12 if the KeyStore is a Wallet.

Use JKS if the KeyStore is a Java KeyStore.

Use SSO if the KeyStore is an auto-login SSO Wallet.

<distinguished_name>

Distinguished Name (DN) of the target Database server.

Specify the DN if the server’s DN needs to be checked.

This is an optional argument.

1.0 | 1.1 | 1.2

The default is 1.2.

Specifies the version of the SSL protocol to use when connecting to the Database Server. This is an optional argument.

Use 1.0 for SSL version TLSv1.0.

Use 1.1 for SSL version TLSv1.1.

Use 1.2 for SSL version TLSv1.2.

<cipher_suite1>,<cipher_suite2>

Example: TLS_RSA_WITH_AES_256_CBC_SHA256 , SSL_RSA_WITH_RC4_128_MD5

Specifies the Cryptographic Algorithms to be used. Multiple entries can be specified as a comma-separated list.

This is an optional argument.

For information about supported cryptographic suites, see https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html.

<file_name> | <file_name1>, <file_name2>

The default is sensitive_en.ini.

Specifies the pattern files to be used. Multiple files can be specified as a comma-separated list. The limit is 10 files.

For more information about configuring the Sensitive Data Type pattern file, see Pattern File Configuration (Optional).

ALL | <schema1>,<schema2>

The default is ALL.

Specifies the schemas to be scanned. Multiple schemas can be specified as a comma-separated list.

<numerical value>

The default is 1.

Specifies the minimum number of rows in a table for that table to be scanned.

Tables with a number of rows less than what is specified in the minrows parameter are excluded from the scan.

<exclusion_list_filename>.ini

Specifies the file to be used to exclude schemas, tables, or columns from the scan.

For more information about configuring the Exclusion List file, see Configuring the Exclusion List File (Optional).

The [Sensitive Categories] section defines which Sensitive Categories are used. Valid risk levels are:

• Low Risk

• Medium Risk

• High Risk

The types of sensitive data are defined in the Sensitive Data Type pattern file. For more information about configuring the Sensitive Data Type pattern file, see Pattern File Configuration (Optional).

Matches one of the characters mentioned within square brackets.

Example: EMPLOYE[ER] matches EMPLOYEE and EMPLOYER.

Matches any character except the ones mentioned within square brackets.

Example: [^BC]AT matches RAT and HAT, but does not match BAT and CAT.

Matches any character in the range mentioned within square brackets. To specify a range, simply insert the dash metacharacter "-" between the first and last character to be matched; for example, [1-5] or [A-M]. You can also place different ranges beside each other within the class to further expand the match possibilities.

Example: [B-F]AT matches BAT, CAT, DAT, EAT, and FAT, but does not match AAT and GAT.

Matches zero or one occurrence of the specified character or group of characters.

Example: SSN_NUMBERS? matches strings SSN_NUMBER and SSN_NUMBERS.

Matches zero or more occurrences of the specified character or group of characters.

Example: TERM.*DATE matches strings like TERMDATE, TERM_DATE and LAST_TERMINATION_DATE.

Matches one or more occurrences of the specified character or group of characters.

Example: TERM.+DATE matches strings like TERM_DATE and TERMINATION_DATE, but not TERMDATE.

Matches the specified character or group of characters exactly n times.

Example: 9{3} matches 999, but not 99.

Matches the specified character or group of characters at least n times.

Example: 9{3,} matches 999, 9999, and 99999, but not 99.

Matches the specified character or group of characters at least n times but not more than m times.

Example: 9{3,4} matches 999 and 9999, but not 99.

Matches the specified character or group of characters at the beginning of a string (starts with search).

Example: ^VISA matches strings beginning with VISA.

Matches the specified character or group of characters at the end of a string (ends with search).

Example: NUMBER$ matches strings ending with NUMBER.

Marks a word boundary. Matches the character or group of characters specified between a pair of \b only if it is a separate word (as opposed to substring within a longer string).

Example: \bAGE\b matches strings like EMPLOYEE AGE and PATIENT AGE INFORMATION, but does not match strings like AGEING and EMPLOYEEAGE.

Sensitive Category

Displays the name of the Sensitive Category

# Sensitive Tables

Displays the number of tables detected that contain sensitive data

# Sensitive Columns

Displays the number of columns detected in the tables that contain sensitive data

# Sensitive Rows

Displays the number of rows detected in the tables that contain sensitive data

Risk Level

Displays the Risk Level

Summary

Displays a summary of the sensitive category data detected

Location

Displays the names of the tables that contain sensitive data

Schema

Displays the name of the schema

Table Name

Displays the name of the table

Columns

Displays the number of columns in the table

Sensitive Columns

Displays the number of columns detected that contain sensitive data

Rows

Displays the number of rows in the table

Sensitive Category

Displays the category of sensitive data detected in each column

Schema Name

Displays the name of the schema

Table Name

Displays the name of the table

Column Name

Displays the name of the column

Column Comment

Displays the column comment

Sensitive Category

Displays the category of sensitive data detected in each column

Sensitive Type

Displays the type of sensitive data detected in each column

Risk Level

Displays the risk level