Oracle Database Security Assessment Sample Report

Highly Confidential

Assessment Date & Time

Date of Data CollectionDate of ReportReporter Version
Sun Apr 25 2021 00:12:00Sun Apr 25 2021 00:22:012.2.1 (May 2020) – f3a1

Database Identity

NameContainer (Type:ID)PlatformDatabase RoleLog ModeCreated
ORCLCDBPDB1 (PDB:4)Linux x86 64-bitPRIMARYNOARCHIVELOGMon Jan 13 2020 20:12:00

Summary

SectionPassEvaluateAdvisoryLow
Risk
Medium
Risk
High
Risk
Total
Findings
Basic Information0000011
User Accounts70222013
Privileges and Roles156100022
Authorization Control0020002
Fine-Grained Access Control0050005
Auditing08500013
Encryption0110002
Database Configuration92010113
Network Configuration0110103
Operating System2200105
Total33201734279

Basic Information

Database Version

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production
Security options used: (none)

Security Features Utilized

FeatureCurrently Used
USER AUTHENTICATION
Password AuthenticationYes
Global AuthenticationNo
External AuthenticationNo
AUTHORIZATION CONTROL
Database VaultNo
Privilege AnalysisNo
ENCRYPTION
Tablespace EncryptionNo
Column EncryptionNo
Network EncryptionNo
AUDITING
Unified AuditYes
Fine Grained AuditNo
Traditional AuditYes
FINE-GRAINED ACCESS CONTROL
Virtual Private DatabaseNo
Real Application SecurityNo
Label SecurityNo
Data RedactionNo
Transparent Sensitive Data ProtectionNo

Patch Check

INFO.PATCHSTIGCIS
StatusHigh Risk
SummaryLatest comprehensive patch not found.
DetailsLatest comprehensive patch: Apr 17 2019 (739 days ago) Binary Patch Inventory: Patch ID (Comprehensive): 22862832 (created April 2019) SQL Patch History: Action time: Mon Jan 13 2020 20:58:00 Action: APPLY Version: 19.3.0.0.0 Description: Database Release Update : 19.3.0.0.190416 (29517242)
RemarksIt 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.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 1.1
Oracle Database 12c STIG v1 r10: Rule SV-76029r2

User Accounts

Note: Predefined Oracle accounts which are locked are not included in this report. To include all user accounts, run the report with the -a option.

User Accounts

User NameStatusProfileTablespaceOracle DefinedAuth Type
ADMIN1OPENDEFAULTSYSTEMNoPASSWORD
C##AHMEDOPENDEFAULTSYSTEMNoPASSWORD
DBSATOPENDEFAULTSYSTEMNoPASSWORD
SYSTEMOPENDEFAULTSYSTEMYesPASSWORD

User Schemas in SYSTEM or SYSAUX Tablespace

USER.TBLSPACESTIG
StatusMedium Risk
SummaryFound 3 users using SYSTEM or SYSAUX tablespace.
DetailsTablespace SYSTEM: ADMIN1, C##AHMED, DBSAT Tablespace SYSAUX: (none)
RemarksThe 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 schemas should not use these tablespaces.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75949r2, SV-75951r3

Sample Schemas

USER.SAMPLESTIGCIS
StatusPass
SummaryNo sample schemas found.
RemarksSample 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.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 1.3
Oracle Database 12c STIG v1 r10: Rule SV-76167r3

Inactive Users

USER.INACTIVESTIG
StatusLow Risk
SummaryFound 2 user accounts that would remain open even if inactive. Found 1 unlocked user inactive for more than 30 days.
DetailsUsers with unlimited INACTIVE_ACCOUNT_TIME: ADMIN1, DBSAT Inactive users: ADMIN1
RemarksIf 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 to automatically lock accounts which have not logged in to the database instance in a specified number of days. It is also recommended to audit infrequently used accounts for unauthorized activities.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-76207r2

Users with Expired Passwords

USER.EXPIRED
StatusPass
SummaryNo unlocked users found with password expired for more than 30 days.
RemarksPassword 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.

Case-Sensitive Passwords

USER.CASECIS
StatusPass
SummaryCase-sensitive passwords are used.
DetailsSEC_CASE_SENSITIVE_LOGON=TRUE
RemarksCase-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 database initialization parameter SEC_CASE_SENSITIVE_LOGON to TRUE ensures that the database distinguishes between upper and lower-case letters in passwords.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 2.2.12

Users with Default Passwords

USER.DEFPWDSTIGCIS
StatusPass
SummaryNo unlocked user accounts are using default password.
RemarksDefault passwords for predefined Oracle accounts are well known and provide a trivial means of entry for attackers. Well-known passwords for locked accounts should be changed as well. If the database was created using a script and the SYS or SYSTEM user password has not been updated since the database creation, such a user is regarded to have a default password because the password used when the database was created may be at risk due to its presence within the script.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 1.2
Oracle Database 12c STIG v1 r10: Rule SV-76031r1, SV-76339r1

Minimum Client Authentication Version

USER.AUTHVERSSTIG
StatusAdvisory
SummaryMinimum client version is not configured correctly.
DetailsSQLNET.ALLOWED_LOGON_VERSION_SERVER is not set (default value = 12). Recommended value is 12a.
RemarksOver 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. Consider evaluating before setting ALLOWED_LOGON_VERSION_SERVER to 12a as it may prevent older clients from connecting the database instance.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-76025r2

Password Verifiers

USER.VERIFIER
StatusPass
SummaryAll user accounts are authenticated using the latest password verifier version. No user accounts have HTTP verifiers.
DetailsDatabase supports password versions up to 12C. Users authenticated using the prior weaker password verifiers: (none) Users with HTTP verifiers: (none)
RemarksFor 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

USER.PARAMSTIGCIS
StatusPass
SummaryExamined 2 initialization parameters. No issues found.
DetailsSEC_MAX_FAILED_LOGIN_ATTEMPTS=3 RESOURCE_LIMIT=TRUE
RemarksSEC_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. Not controlling failed login attempts before closing the connection and locking accounts after a number of failed logins, opens the door for successful brute-force login attacks and the occurrence of Denial-of-Service. RESOURCE_LIMIT should be set to TRUE to enable enforcement of any resource constraints set in user profiles.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 2.2.13, 2.2.19
Oracle Database 12c STIG v1 r10: Rule SV-76305r4

User Profiles

Profile NameParameterValue
DEFAULT(Number of Users)4
DEFAULTCONNECT_TIMEUNLIMITED
DEFAULTFAILED_LOGIN_ATTEMPTS10
DEFAULTIDLE_TIMEUNLIMITED
DEFAULTINACTIVE_ACCOUNT_TIMEUNLIMITED
DEFAULTPASSWORD_GRACE_TIME7 day(s)
DEFAULTPASSWORD_LIFE_TIME180 day(s)
DEFAULTPASSWORD_LOCK_TIME1 day(s)
DEFAULTPASSWORD_REUSE_MAXUNLIMITED
DEFAULTPASSWORD_REUSE_TIMEUNLIMITED
DEFAULTPASSWORD_VERIFY_FUNCTIONNULL
ORA_STIG_PROFILE(Number of Users)0
ORA_STIG_PROFILECONNECT_TIMEUNLIMITED (DEFAULT)
ORA_STIG_PROFILEFAILED_LOGIN_ATTEMPTS3
ORA_STIG_PROFILEIDLE_TIME15 minute(s)
ORA_STIG_PROFILEINACTIVE_ACCOUNT_TIME35 day(s)
ORA_STIG_PROFILEPASSWORD_GRACE_TIME5 day(s)
ORA_STIG_PROFILEPASSWORD_LIFE_TIME60 day(s)
ORA_STIG_PROFILEPASSWORD_LOCK_TIMEUNLIMITED
ORA_STIG_PROFILEPASSWORD_REUSE_MAX10
ORA_STIG_PROFILEPASSWORD_REUSE_TIME365 day(s)
ORA_STIG_PROFILEPASSWORD_VERIFY_FUNCTIONORA12C_STIG_VERIFY_FUNCTION

Users with Unlimited Password Lifetime

USER.NOEXPIRESTIGCIS
StatusAdvisory
SummaryPassword expiration is configured for all users. Found 2 users with no limits on password reuse. Found 2 users with no minimum time before password reuse. All user accounts will lock after password expiration.
DetailsPASSWORD_LIFE_TIME: Profiles with limited password lifetime: DEFAULT (180 days), ORA_STIG_PROFILE (60 days) Profiles with unlimited password lifetime: (none) Users with unlimited password lifetime: (none) PASSWORD_REUSE_MAX: Profiles with limits on password reuse: ORA_STIG_PROFILE (10 times) Profiles without limits on password reuse: DEFAULT Users without limits on password reuse: ADMIN1, DBSAT PASSWORD_REUSE_TIME: Profiles with minimum time before password reuse: ORA_STIG_PROFILE (365 days) Profiles without minimum time before password reuse: DEFAULT Users without minimum time before password reuse: ADMIN1, DBSAT PASSWORD_GRACE_TIME: Profiles with locking after password expiration: DEFAULT (7 days), ORA_STIG_PROFILE (5 days) Profiles without locking after password expiration: (none) Users without locking after password expiration: (none)
RemarksPassword 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.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 3.3, 3.4, 3.5, 3.6
Oracle Database 12c STIG v1 r10: Rule SV-76047r2, SV-76051r3, SV-76211r2, SV-76229r2

Account Locking after Failed Login Attempts

USER.NOLOCKSTIGCIS
StatusPass
SummaryUser accounts are configured to prevent brute force password attacks by locking the account after a number of failed login attempts. User accounts are configured to stay locked for a minimum duration after being locked due to failed login attempt.
DetailsFAILED_LOGIN_ATTEMPTS: Profiles with limited failed login attempts: DEFAULT (10), ORA_STIG_PROFILE (3) Profiles with unlimited failed login attempts: (none) Users with unlimited failed login attempts: (none) PASSWORD_LOCK_TIME: Profiles with minimum lock time: DEFAULT (1 day) Profiles without minimum lock time: ORA_STIG_PROFILE Users without minimum lock time: (none)
RemarksAttackers 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.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 3.1, 3.2
Oracle Database 12c STIG v1 r10: Rule SV-76047r2, SV-76093r2, SV-76095r2, SV-76097r2

Password Verification Functions

USER.PASSWDSTIGCIS
StatusMedium Risk
SummaryFound 2 users not using password verification function.
DetailsProfiles with password verification function: ORA_STIG_PROFILE (ORA12C_STIG_VERIFY_FUNCTION) Profiles without password verification function: DEFAULT Users without password verification function: ADMIN1, DBSAT
RemarksPassword 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.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 3.8
Oracle Database 12c STIG v1 r10: Rule SV-76209r1, SV-76213r1, SV-76215r1 , SV-76217r1, SV-76219r1, SV-76221r1, SV-76225r1

Users with Unlimited Concurrent Sessions

USER.SESSIONSCIS
StatusLow Risk
SummaryFound 2 users with ability to create unlimited concurrent sessions.
DetailsSESSIONS_PER_USER: Profiles with limited concurrent sessions: (none) Profiles without limited concurrent sessions: DEFAULT, ORA_STIG_PROFILE Users with unlimited concurrent sessions: ADMIN1, DBSAT
RemarksThe SESSIONS_PER_USER parameter determines the maximum number of sessions a user can create concurrently. A user’s ability to create unlimited sessions may result in memory resource exhaustion or Denial-of-Service attacks.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 3.9

Privileges and Roles

System Privilege Grants

PRIV.SYSTEMSTIGCIS
StatusEvaluate
Summary2 out of 4 users have been directly or indirectly granted system privileges via 3 grants. 1 user is granted 1 system privileges directly.
DetailsUsers directly or indirectly granted each system privilege: CREATE PLUGGABLE DATABASE: ADMIN1 CREATE SESSION: ADMIN1, DBSAT(D)
RemarksSystem 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. The Privilege Analysis feature may be helpful to determine the minimum set of privileges required by a user or role. In some cases, it may be possible to substitute a more limited object privilege grant in place of a system privilege grant that applies to all objects. System privileges should be granted with admin option only when the recipient needs the ability to grant the privilege to others.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.7
Oracle Database 12c STIG v1 r10: Rule SV-75923r3, SV-76065r1, SV-76081r3, SV-76299r3

All Roles

PRIV.ROLESCIS
StatusEvaluate
Summary2 out of 4 users have been directly or indirectly granted roles via 5 grants.
DetailsUsers directly or indirectly granted each role: AUDIT_VIEWER: DBSAT CAPTURE_ADMIN: DBSAT DV_SECANALYST: DBSAT PDB_DBA: ADMIN1 SELECT_CATALOG_ROLE: DBSAT
RemarksRoles 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. Privilege Analysis can be used to determine specific privileges that the recipient actually requires. Roles should be granted with admin option only when the recipient needs the ability to modify the role or grant it to others.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.4.1

Code Based Access Control

PRIV.CBAC
StatusEvaluate
SummaryCode Based Access Control (CBAC) enabled for 2 Program Units.
DetailsFollowing Program Units are granted CBAC Roles: SYS.DBMS_MDX_ODBO: DBMS_MDX_INTERNAL System privileges granted via CBAC role: (none) Users with execute privilege on SYS.DBMS_MDX_ODBO: PUBLIC GSMADMIN_INTERNAL.EXCHANGE: DATAPUMP_EXP_FULL_DATABASE, DATAPUMP_IMP_FULL_DATABASE System privileges granted via CBAC role: AUDIT SYSTEM, EXECUTE ANY OPERATOR, ALTER PROFILE, CREATE SESSION, GRANT ANY PRIVILEGE, GRANT ANY OBJECT PRIVILEGE, AUDIT ANY, CREATE PROFILE, ALTER RESOURCE COST, ALTER USER, ALTER DATABASE, GRANT ANY ROLE, CREATE TABLE, SELECT ANY TABLE, DELETE ANY TABLE Users with execute privilege on GSMADMIN_INTERNAL.EXCHANGE: (none) PUBLIC is granted Execute on Program Units via CBAC Role.
RemarksCode Based Access Control (CBAC) can be used to grant additional privileges on program units like PL/SQL functions, procedures, or packages. 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

PRIV.ACCTSTIG
StatusPass
SummaryNo user granted account management privileges No grants to PUBLIC.
RemarksAccount management privileges (ALTER USER, CREATE USER, DROP USER) can be used to create and modify other user accounts, including changing passwords. This ability can be abused to gain access to another user’s account, which may have greater privileges. Users with Account management privileges should be audited.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75935r2

Role and Privilege Management Privileges

PRIV.MGMTCIS
StatusPass
SummaryNo user granted role and privilege management privileges No grants to PUBLIC.
RemarksUsers with role and 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 roles and 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. The Privilege Analysis feature may be helpful to determine whether a user or role have used privilege management privileges.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.3.10, 4.3.11, 4.3.12

Database Management Privileges

PRIV.DBMGMTCIS
StatusPass
SummaryNo user granted database management privilege No grants to PUBLIC.
RemarksDatabase management privileges (ALTER DATABASE, ALTER SYSTEM, CREATE ANY LIBRARY, CREATE LIBRARY, DROP ANY LIBRARY) can be used to change the operation of the database and potentially bypass security protections. CREATE LIBRARY allows a user to create or replace a library. This ability should be granted only to trusted administrators and should be sufficiently audited.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.3.7, 4.3.8, 4.3.9

Audit Management Package

PRIV.AUDMGMTSTIG
StatusPass
SummaryNo user granted EXECUTE on Audit management packages No grants to PUBLIC.
RemarksThe DBMS_AUDIT_MGMT package is used to execute Audit Trail management procedures and functions. Users with the execute privilege can invoke subprograms like CLEAN_AUDIT_TRAIL that deletes audit trail records or files that have been archived. Access should be strictly limited and granted only to users with a legitimate need for this functionality.
ReferencesOracle Database 12c STIG v1 r10: SV-76149r1, SV-76151r1, SV-76153r1

Audit Management Privileges

PRIV.AUDITSTIGCIS
StatusPass
SummaryNo user granted privilege to manage audit policies No grants to PUBLIC.
RemarksAudit management privileges (AUDIT ANY, AUDIT SYSTEM) can be used to add, drop and modify the audit policies for the database. These privileges should be granted to highly trusted administrators, since they may be abused to hide malicious activity. The Privilege Analysis feature may be helpful to determine whether the audit management privileges have been used by a user or role. Users with these privileges should be sufficiently audited.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.3.3
Oracle Database 12c STIG v1 r10: Rule SV-76113r1

Broad Data Access Privileges

PRIV.DATACIS
StatusPass
SummaryNo user granted broad data access privileges No grants to PUBLIC.
RemarksUsers with broad data access privileges (SELECT ANY TABLE, READ ANY TABLE, INSERT ANY TABLE, DELETE ANY TABLE, ALTER ANY TABLE, UPDATE ANY TABLE, CREATE ANY TRIGGER, ALTER ANY TRIGGER, CREATE ANY INDEX, CREATE ANY PROCEDURE, SELECT ANY DICTIONARY) have 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. Users with direct object privileges on tables that hold sensitive data should also be reviewed. 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 stored in user schemas. The Privilege Analysis feature may be helpful to restrict the use of broad data access privileges required by a user or role. In some cases, it may be possible to substitute a more limited object privilege grant for a broad data access privilege. Broad data access privileges should be granted with admin option only when the recipient needs the ability to grant the privilege to others.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.3.1, 4.3.2

Access Control Exemption Privileges

PRIV.EXEMPTCIS
StatusPass
SummaryNo user granted access control exemption privileges No grants to PUBLIC.
RemarksUsers with access control 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, respectively. Most administrative tasks do not require access to the data itself, so these privileges should be granted rarely even to administrators. Users with these privileges should be sufficiently audited.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.3.4

Access to Password Verifier Tables

PRIV.PASSWDCIS
StatusPass
SummaryNo user granted read on dictionary tables containing password verifiers. No grants to PUBLIC.
RemarksUsers with READ, SELECT and UPDATE privileges on dictionary tables containing verifiers can access and modify user password verifiers. The verifiers can be used in offline attacks to discover user passwords.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.5.1, 4.5.2, 4.5.3, 4.5.4, 4.5.6

Write Access to Restricted Objects

PRIV.OBJSTIG
StatusPass
SummaryNo user granted object privileges on Oracle Database restricted objects No grants to PUBLIC.
RemarksUsers 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. PUBLIC must not be granted access to objects in SYS, DVSYS, AUDSYS and LBACSYS schemas. When running a Privilege Analysis Capture, be aware of privileges that have been granted to access objects in any Oracle-created schemas. Review the grants for relevance.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75929r3

Access to Audit Objects

PRIV.AUDOBJSTIG
StatusEvaluate
Summary1 out of 4 users have been directly or indirectly granted object privileges on audit objects via 3 grants. No grants to PUBLIC.
DetailsGrants of SELECT, DELETE, INSERT, UPDATE on AUDIT objects: DBSAT: SELECT on AUDSYS.AUD$UNIFIED DBSAT <- DV_SECANALYST: SELECT on DVSYS.AUDIT_TRAIL$ DBSAT <- SELECT_CATALOG_ROLE: SELECT on SYS.AUDTAB$TBS$FOR_EXPORT_TBL
RemarksUsers 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. Use Privilege Analysis to identify used and unused access to these privileges. Instead of granting a default role with many privileges such as DBA or SELECT_CATALOG_ROLE, create custom roles that only contain the necessary system and object privileges the user or role needs to perform the task.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-76143r2, SV-76145r1, SV-76147r1, SV-76159r1

User Impersonation Privilege

PRIV.USERCIS
StatusPass
SummaryNo user granted user impersonation privilege No grants to PUBLIC. No user granted EXECUTE on restricted packages that can be executed with the identity of some other user No grants to PUBLIC.
RemarksThe BECOME USER privilege and some PL/SQL packages (DBMS_AQADM_SYS, DBMS_AQADM_SYSCALLS, DBMS_IJOB, DBMS_PRVTAQIM, DBMS_REPCAT_SQL_UTL, 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. Use Privilege Analysis to identify used and unused access to these privileges. Users with BECOME USER privilege and EXECUTE privilege on above packages should be sufficiently audited.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.2.1, 4.2.3 – 4.2.13, 4.3.5

Data Exfiltration

PRIV.EXFILCIS
StatusPass
SummaryNo user granted EXECUTE on restricted packages that can be used for data exfiltration. No grants to PUBLIC.
RemarksSome PL/SQL packages (DBMS_BACKUP_RESTORE, UTL_DBWS, UTL_ORAMTS, DBMS_FILE_TRANSFER) 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. Use Privilege Analysis to identify if these privileges were used. If not, consider revoking.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.1.19, 4.1.20, 4.2.2, 4.2.14

System Privileges Granted to PUBLIC

PRIV.SYSPUBSTIG
StatusPass
SummaryNo grants to PUBLIC.
RemarksPrivileges 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.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75925r1

Roles Granted to PUBLIC

PRIV.ROLEPUBSTIG
StatusPass
SummaryPUBLIC has not been granted any role.
RemarksRoles granted to PUBLIC are available to all users. Most roles contain privileges that are not appropriate for all users. Use Privilege Analysis to identify if these privileges were used. If not, work with Oracle support and/or application provider to revoke them if possible.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75933r1

Column Privileges Granted to PUBLIC

PRIV.COLPUB
StatusPass
SummaryNo grants to PUBLIC.
RemarksPrivileges 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 Administrative SYS* Privileges

PRIV.ADMINSTIG
StatusAdvisory
SummaryNo user is granted administrative SYS* privileges.
DetailsSYSDBA (0): (none) SYSOPER (0): (none) SYSBACKUP (0): (none) SYSDG (0): (none) SYSKM (0): (none)
RemarksAdministrative SYS* 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 specific 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 named user account.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-76081r3

Users with DBA Role

PRIV.DBACIS
StatusPass
SummaryNo user granted highly sensitive DBA role
RemarksThe DBA is a powerful role and can be used to bypass many security controls. It should be granted to a small number of trusted administrators. As a best practice, it is recommended to create custom DBA-like roles with minimum set of privileges that users require to execute their tasks (least privilege principle) and do not grant the DBA role. Privilege Analysis can assist in the task of identifying used/unused privileges and roles. Having different roles with minimum required privileges based on types of operations DBAs execute also helps to achieve Separation of Duties. Furthermore, each trusted user should have an individual account for accountability reasons. It is recommended to audit users with the DBA roles to detect any unauthorized activity. Avoid granting the DBA or custom DBA-like powerful roles WITH ADMIN option unless absolutely necessary. Please note that Oracle may add or remove roles and privileges from the DBA role.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.4.4

Users with Powerful Roles

PRIV.BIGROLESSTIGCIS
StatusEvaluate
Summary1 out of 4 users have been directly or indirectly granted powerful roles via 1 grant.
DetailsGrants of AQ_ADMINISTRATOR_ROLE, EM_EXPRESS_ALL, EXP_FULL_DATABASE, IMP_FULL_DATABASE, SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE, DELETE_CATALOG_ROLE, OEM_MONITOR, DBA roles: DBSAT: SELECT_CATALOG_ROLE
RemarksDBA and other similarly powerful roles (AQ_ADMINISTRATOR_ROLE, EM_EXPRESS_ALL, EXP_FULL_DATABASE, IMP_FULL_DATABASE, SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE, DELETE_CATALOG_ROLE, OEM_MONITOR, DBA) contain powerful privileges that can be used to bypass security protections. They should be granted only to a small number of trusted administrators. It is recommended to audit users with these roles to detect any unauthorized activity. Use Privilege Analysis to identify if these privileges were used. If not, consider revoking.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 4.4.1, 4.4.2, 4.4.3
Oracle Database 12c STIG v1 r10: Rule SV-75927r3

Java Permissions

PRIV.JAVA
StatusEvaluate
SummaryFound 4 users or roles with Java permission.
DetailsGrantee: DBJAVASCRIPT GRANT, Name: oracle.DbmsJavaScriptUser, Type Schema: SYS, Type Name: java.lang.RuntimePermission Grantee: EJBCLIENT GRANT, Name: *, Type Schema: SYS, Type Name: java.net.SocketPermission, Action: connect,resolve GRANT, Name: createClassLoader, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: getClassLoader, Type Schema: SYS, Type Name: java.lang.RuntimePermission Grantee: JMXSERVER GRANT, Name: javax.net.ssl.*, Type Schema: SYS, Type Name: java.util.PropertyPermission, Action: read,write GRANT, Name: javavm/lib/management/*, Type Schema: SYS, Type Name: java.io.FilePermission, Action: read GRANT, Name: *, Type Schema: SYS, Type Name: java.net.SocketPermission, Action: accept,connect,listen,resolve GRANT, Name: control, Type Schema: SYS, Type Name: java.util.logging.LoggingPermission GRANT, Name: accessClassInPackage.sun.management.*, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: setContextClassLoader, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: createMBeanServer, Type Schema: SYS, Type Name: javax.management.MBeanServerPermission GRANT, Name: control, Type Schema: SYS, Type Name: java.lang.management.ManagementPermission GRANT, Name: createAccessControlContext, Type Schema: SYS, Type Name: java.security.SecurityPermission GRANT, Name: javavm/lib/management/management.properties, Type Schema: SYS, Type Name: java.io.FilePermission, Action: read GRANT, Name: javavm/lib/management/jmxremote.access, Type Schema: SYS, Type Name: java.io.FilePermission, Action: read GRANT, Name: https.proxyHost, Type Schema: SYS, Type Name: java.util.PropertyPermission, Action: read,write GRANT, Name: javax.net.debug, Type Schema: SYS, Type Name: java.util.PropertyPermission, Action: read,write GRANT, Name: java.rmi.server.randomIDs, Type Schema: SYS, Type Name: java.util.PropertyPermission, Action: read,write GRANT, Name: com.sun.jmx.*, Type Schema: SYS, Type Name: java.util.PropertyPermission, Action: read,write GRANT, Name: com.sun.management.*, Type Schema: SYS, Type Name: java.util.PropertyPermission, Action: read,write GRANT, Name: *, Type Schema: SYS, Type Name: javax.management.MBeanPermission, Action: * GRANT, Name: monitor, Type Schema: SYS, Type Name: java.lang.management.ManagementPermission Grantee: PUBLIC GRANT, Name: DUMMY, Type Schema: SYS, Type Name: oracle.aurora.security.JServerPermission GRANT, Name: LoadClassInPackage.*, Type Schema: SYS, Type Name: oracle.aurora.security.JServerPermission GRANT, Name: oracle.net.tns_admin, Type Schema: SYS, Type Name: java.util.PropertyPermission, Action: write GRANT, Name: getenv.ORACLE_HOME, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: getenv.TNS_ADMIN, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: preferences, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: modifyThreadGroup, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: modifyThread, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: createSecurityManager, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: exitVM, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: *, Type Schema: SYS, Type Name: java.util.PropertyPermission, Action: read GRANT, Name: user.language, Type Schema: SYS, Type Name: java.util.PropertyPermission, Action: write GRANT, Name: accessClassInPackage.com.sun.media.imageioimpl.stream, Type Schema: SYS, Type Name: java.lang.RuntimePermission GRANT, Name: accessClassInPackage.com.sun.media.imageioimpl.plugins.*, Type Schema: SYS, Type Name: java.lang.RuntimePermission RESTRICT, Name: LoadClassInPackage.oracle.jdbc.*, Type Schema: SYS, Type Name: oracle.aurora.security.JServerPermission RESTRICT, Name: LoadClassInPackage.oracle.aurora.*, Type Schema: SYS, Type Name: oracle.aurora.security.JServerPermission RESTRICT, Name: LoadClassInPackage.oracle.ord.*, Type Schema: SYS, Type Name: oracle.aurora.security.JServerPermission RESTRICT, Name: LoadClassInPackage.java.*, Type Schema: SYS, Type Name: oracle.aurora.security.JServerPermission RESTRICT, Name: loadLibrary.*, Type Schema: SYS, Type Name: java.lang.RuntimePermission RESTRICT, Name: 0:java.lang.RuntimePermission#loadLibrary.*, Type Schema: SYS, Type Name: oracle.aurora.rdbms.security.PolicyTablePermission
RemarksJava 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. Use Privilege Analysis to identify if these privileges were used. If not, consider revoking.

Authorization Control

Database Vault

AUTH.DVSTIGGDPR
StatusAdvisory
SummaryDatabase Vault is not enabled.
RemarksDatabase 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.
ReferencesEU GDPR 2016/679: Article 6, 25, 29, 32, 34, 89; Recital 28, 29, 78, 156
Oracle Database 12c STIG v1 r10: Rule SV-76065r1

Privilege Analysis

AUTH.PRIV
StatusAdvisory
SummaryNo Privilege Analysis policies found.
DetailsUsers who can start the privilege analysis capture process: DBSAT
RemarksPrivilege Analysis records the privileges used during areal 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.

Fine-Grained Access Control

Data Redaction

ACCESS.REDACTGDPR
StatusAdvisory
SummaryNo data is being dynamically redacted.
DetailsUsers exempted from Data Redaction Policies: (none) Users who can create or manage Data Redaction Policies: (none)
RemarksData Redaction automatically masks sensitive data found in the results of a database query. The data is masked immediately before it is returned as part of the result set, so it does not interfere with any conditions specified as part of the query. Access by users with the EXEMPT REDACTION POLICY privilege will not be affected by the redaction policy. Users who can execute the DBMS_REDACT package are able to create and modify redaction policies. Also consider the use of Oracle Data Masking and Subsetting to permanently mask sensitive data when making copies for test or development use.
ReferencesEU GDPR 2016/679: Article 6, 25, 32, 34, 89; Recital 28, 29, 78, 156

Virtual Private Database

ACCESS.VPDGDPR
StatusAdvisory
SummaryNo VPD policies found that automatically limit access to certain rows and/or columns based upon the user or the database environment.
DetailsUsers exempted from VPD Policies: (none) Users who can create or manage VPD Policies: (none)
RemarksVirtual Private Database (VPD) allows for fine-grained control over which rows and columns of a table are visible to a SQL statement. Access control using VPD limits each database session to only the specific data it should be able to access. Access by users with the EXEMPT ACCESS POLICY privilege will not be affected by VPD policies. Users who can execute the DBMS_RLS package are able to create and modify these policies.
ReferencesEU GDPR 2016/679: Article 29, 32

Real Application Security

ACCESS.RASGDPR
StatusAdvisory
SummaryNo RAS policies found.
DetailsUsers not impacted by RAS Policies: (none) Users who can create or manage RAS policies: DBSFWUSER
RemarksLike Virtual Private Database, Real Application Security (RAS) provides fine-grained control over the rows and columns of a table that are visible to a SQL statement. RAS data access policies use a declarative syntax based on access control lists. Access by users with the EXEMPT ACCESS POLICY privilege will not be affected by RAS access policies. Users with ADMIN_SEC_POLICY and APPLY_SEC_POLICY privileges are able to create and modify these policies.
ReferencesEU GDPR 2016/679: Article 6, 25, 32, 34, 89; Recital 28, 29, 64, 78, 156

Label Security

ACCESS.OLSGDPR
StatusAdvisory
SummaryLabel Security is not enabled.
RemarksOracle Label Security uses row level data classifications to enforce access controls restricting users to only the data they are allowed to access. Access to sensitive data is controlled by comparing the data label with the requesting user’s label or security clearance. A user label or security clearance can be thought of as an extension to standard database privileges and roles. Access by users with the EXEMPT ACCESS POLICY privilege will not be affected by the Label Security policies. Each policy has a corresponding role; users who have this role are able to administer the policy.
ReferencesEU GDPR 2016/679: Article 18, 29, 32; Recital 67

Transparent Sensitive Data Protection (TSDP)

ACCESS.TSDP
StatusAdvisory
SummaryNo data tagged with sensitive types found. Found 0 TSDP policy.
DetailsPolicies: (none) Users with EXECUTE on SYS.DBMS_TSDP_MANAGE: (none) Users with EXECUTE on SYS.DBMS_TSDP_PROTECT: (none)
RemarksTransparent Sensitive Data Protection (TSDP) allows a data type(such as Credit Card number) to be associated with each column that contains sensitive data. TSDP can then apply various data security features such as Data Redaction or Virtual Private Database to all instances of that particular type so that protection is uniform and consistent. Data from columns marked as sensitive is also automatically redacted in the database audit trail and trace logs. Users who can execute the DBMS_TSDP_MANAGE and DBMS_TSDP_PROTECT packages are able to manage sensitive data types and the protection actions that are applied to them.

Auditing

Audit Records

AUDIT.RECORDSSTIGGDPRCIS
StatusEvaluate
SummaryExamined 3 audit trails. Found records in 1 audit trail. No errors found in audit initialization parameters.
DetailsTraditional Audit Trail: No records found FGA Audit Trail: No records found Unified Audit Trail: In use, 97 records found (Jan 13 2020 – Mar 03 2021) AUDIT_FILE_DEST=/opt/oracle/admin/ORCLCDB/adump AUDIT_SYSLOG_LEVEL is not set. AUDIT_TRAIL=DB
RemarksAuditing is an essential component for monitoring the activities on any system including the activities of highly privileged users. Oracle Database 12c introduced Unified Auditing that centralizes audit logs in a single unified audit trail, and simplifies audit policy management, and is the recommended auditing mode moving forward. The AUDIT_FILE_DEST controls the OS directory to which the audit trail is written if using AUDIT_TRAIL=os, xml, or xml,extended. This directory should be prevented from any unauthorized access. Sending audit data to a remote system is recommended in order to prevent any possible local tampering with the audit records. The AUDIT_SYSLOG_LEVEL parameter can be set to send an abbreviated version of audit records to a remote syslog collector. A better solution is to use Oracle Audit Vault and Database Firewall to centrally collect full audit records from multiple databases.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 2.2.2
EU GDPR 2016/679: Article 30, 33, 34
Oracle Database 12c STIG v1 r10: Rule SV-75899r1, SV-76111r1, SV-76117r1, SV-76121r1, SV-76123r1, SV-76125r1, SV-76127r1, SV-76129r1, SV-76455r3

Unified Audit Policies

AUDIT.UNIFIEDSTIGGDPR
StatusEvaluate
SummaryFound 9 unified audit policies out of which 2 are enabled. 50 privileges, actions or roles are audited.
DetailsEnabled Policies: ORA_LOGON_FAILURES: Audits 1 privilege/action/role as follows: LOGON Users audited: ALL USERS ORA_SECURECONFIG: Audits 49 privileges/actions/roles as follows: ADMINISTER KEY MANAGEMENT, ALTER ANY PROCEDURE, ALTER ANY SQL TRANSLATION PROFILE, ALTER ANY TABLE, ALTER DATABASE, ALTER DATABASE DICTIONARY, ALTER DATABASE LINK, ALTER PLUGGABLE DATABASE, ALTER PROFILE, ALTER ROLE, ALTER SYSTEM, ALTER USER, AUDIT SYSTEM, BECOME USER, CREATE ANY JOB, CREATE ANY LIBRARY, CREATE ANY PROCEDURE, CREATE ANY SQL TRANSLATION PROFILE, CREATE ANY TABLE, CREATE DATABASE LINK, CREATE DIRECTORY, CREATE EXTERNAL JOB, CREATE PLUGGABLE DATABASE, CREATE PROFILE, CREATE PUBLIC SYNONYM, CREATE ROLE, CREATE SQL TRANSLATION PROFILE, CREATE USER, DROP ANY PROCEDURE, DROP ANY SQL TRANSLATION PROFILE, DROP ANY TABLE, DROP DATABASE LINK, DROP DIRECTORY, DROP PLUGGABLE DATABASE, DROP PROFILE, DROP PUBLIC SYNONYM, DROP ROLE, DROP USER, EXEMPT ACCESS POLICY, EXEMPT REDACTION POLICY, GRANT ANY OBJECT PRIVILEGE, GRANT ANY PRIVILEGE, GRANT ANY ROLE, LOGMINING, PURGE DBA_RECYCLEBIN, SET ROLE, TRANSLATE ANY SQL, EXECUTE ON SYS.DBMS_RLS, EXECUTE ON REMOTE_SCHEDULER_AGENT.ADD_AGENT_CERTIFICATE Users audited: ALL USERS Disabled Policies: ORA_ACCOUNT_MGMT: Audits 9 privileges/actions/roles ORA_CIS_RECOMMENDATIONS: Audits 35 privileges/actions/roles ORA_DATABASE_PARAMETER: Audits 3 privileges/actions/roles ORA_DV_AUDPOL: Audits 2180 privileges/actions/roles ORA_DV_AUDPOL2: Audits 19 privileges/actions/roles ORA_RAS_POLICY_MGMT: Audits 35 privileges/actions/roles ORA_RAS_SESSION_MGMT: Audits 14 privileges/actions/roles
RemarksUnified Audit captures audit activity in one single unified audit trail. It also introduces new syntax for specifying effective audit policies including the ability to build conditions and add exclusions. As part of Unified Auditing feature, Oracle Database provides pre-defined unified audit policies that cover commonly mandated security-relevant audit settings. You can enable the audit policies that fit your audit requirements, or you can create your own policies using the pre-defined policies as templates.
ReferencesEU GDPR 2016/679: Article 30, 33, 34
Oracle Database 12c STIG v1 r10: Rule SV-76361r1

Audit User Logon / Logoff

AUDIT.CONNSTIGCIS
StatusAdvisory
SummaryDatabase connection events are not fully audited.
DetailsAuditing not enabled: LOGOFF Traditional audit – disabled. Unified audit – auditing enabled: LOGON
RemarksSuccessful user connections to the database should be audited to assist with forensic analysis. Unsuccessful connection attempts can provide early warning of an attacker’s attempt to gain access to the database. Auditing the LOGOFF time helps understand how long the session was active, and is useful information for forensics. Auditing for LOGON and LOGOFF actions must be enabled for all the required users.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 5.1.22, 5.2.27
Oracle Database 12c STIG v1 r10: Rule SV-76043r1, SV-76141r1, SV-76165r1

Audit Administrative (SYS*) Users

AUDIT.ADMINSTIGCIS
StatusEvaluate
SummaryActions of the SYS user are audited.
DetailsTraditional Audit: AUDIT_SYS_OPERATIONS is set to TRUE. Unified Audit policies enabled for administrators: (none)
RemarksIt 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. Beginning with Oracle 12c, the same Unified Audit policies can be applied to SYS that are used to monitor other users.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 2.2.1
Oracle Database 12c STIG v1 r10: SV-75983r1, Rule SV-76009r1, SV-76085r2

Audit Database Management Activities

AUDIT.DBMGMTSTIGCIS
StatusAdvisory
SummaryActions related to database management are not audited.
DetailsAuditing not enabled: ALTER FUNCTION, ALTER PACKAGE, ALTER PROCEDURE, ALTER PUBLIC DATABASE LINK, ALTER TRIGGER, AUDIT ANY, CREATE ANY DIRECTORY, CREATE FUNCTION, CREATE LIBRARY, CREATE PACKAGE, CREATE PACKAGE BODY, CREATE PROCEDURE, CREATE PUBLIC DATABASE LINK, CREATE SPFILE, CREATE TRIGGER, DROP ANY DIRECTORY, DROP FUNCTION, DROP PACKAGE, DROP PROCEDURE, DROP PUBLIC DATABASE LINK, DROP TRIGGER, SYSTEM AUDIT Traditional audit – disabled. Unified audit – auditing enabled: ADMINISTER KEY MANAGEMENT, ALTER DATABASE, ALTER DATABASE LINK, ALTER PLUGGABLE DATABASE, ALTER SYSTEM, CREATE ANY LIBRARY, CREATE DATABASE LINK, CREATE EXTERNAL JOB, CREATE PLUGGABLE DATABASE, CREATE PUBLIC SYNONYM, DROP ANY PROCEDURE, DROP DATABASE LINK, DROP PLUGGABLE DATABASE, DROP PUBLIC SYNONYM, EXECUTE ON SYS.DBMS_RLS
RemarksActions that affect the management of database features should always be audited. Each action or privilege listed here should be included in at least one enabled audit policy.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 5.1.9, 5.1.10, 5.1.11, 5.1.17, 5.1.19 – 5.1.21, 5.2.12 – 5.2.14, 5.2.20 – 5.2.26
Oracle Database 12c STIG v1 r10: Rule SV-83467r1

Audit Account Management Activities

AUDIT.ACCTMGMTSTIGCIS
StatusEvaluate
SummaryActions related to account management are audited.
DetailsTraditional audit – disabled. Unified audit – auditing enabled: ALTER PROFILE, ALTER USER, CREATE PROFILE, CREATE USER, DROP PROFILE, DROP USER
RemarksCreation 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 here should be included in at least one enabled audit policy.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 5.1.1, 5.1.2, 5.1.3, 5.1.6, 5.1.7, 5.1.8, 5.2.1, 5.2.2, 5.2.3, 5.2.9, 5.2.10, 5.2.11
Oracle Database 12c STIG v1 r10: Rule SV-76055r2, SV-76059r2, SV-76061r4, SV-76063r2, SV-76141r1, SV-76287r2, SV-76289r2, SV-76291r2, SV-76293r2

Audit System Privileges

AUDIT.PRIVCIS
StatusEvaluate
SummaryAuditing enabled for 30 privileges.
DetailsUnified Audit (30): ADMINISTER KEY MANAGEMENT, ALTER ANY PROCEDURE, ALTER ANY SQL TRANSLATION PROFILE, ALTER ANY TABLE, ALTER DATABASE, ALTER SYSTEM, AUDIT SYSTEM, BECOME USER, CREATE ANY JOB, CREATE ANY LIBRARY, CREATE ANY PROCEDURE, CREATE ANY SQL TRANSLATION PROFILE, CREATE ANY TABLE, CREATE EXTERNAL JOB, CREATE PUBLIC SYNONYM, CREATE SQL TRANSLATION PROFILE, CREATE USER, DROP ANY PROCEDURE, DROP ANY SQL TRANSLATION PROFILE, DROP ANY TABLE, DROP PUBLIC SYNONYM, DROP USER, EXEMPT ACCESS POLICY, EXEMPT REDACTION POLICY, GRANT ANY OBJECT PRIVILEGE, GRANT ANY PRIVILEGE, GRANT ANY ROLE, LOGMINING, PURGE DBA_RECYCLEBIN, TRANSLATE ANY SQL
RemarksThis finding shows the system privileges that are audited by enabled audit policies. It is recommended that system privileges such as ALTER SYSTEM, ALTER DATABASE, SELECT ANY TABLE, GRANT ANY OBJECT PRIVILEGE, GRANT ANY PRIVILEGE and DROP ANY PROCEDURE are audited.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 5.1.15, 5.1.16, 5.1.17

Audit Roles with System Privileges

AUDIT.ROLE
StatusAdvisory
SummaryNo Audit Policy enabled on roles.
RemarksWhen you audit a role, Oracle Database audits all system privileges that are directly granted to the role. Users granted these roles will be audited for the system privileges granted to the role.

Audit Powerful Privileges

AUDIT.PRIVUSECIS
StatusAdvisory
SummaryUse of powerful system privileges is not fully audited.
DetailsAuditing not enabled: CREATE ANY TRIGGER, SELECT ANY DICTIONARY Traditional audit – disabled. Unified audit – auditing enabled: ALTER ANY SQL TRANSLATION PROFILE, BECOME USER, CREATE ANY JOB, CREATE ANY PROCEDURE, CREATE ANY SQL TRANSLATION PROFILE, EXEMPT ACCESS POLICY, EXEMPT REDACTION POLICY, LOGMINING, TRANSLATE ANY SQL
RemarksUse of powerful system privileges should always be audited. Each privilege listed here should be included in at least one enabled audit policy.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 5.1.14, 5.2.18

Audit Privilege Management

AUDIT.PRIVMGMTCIS
StatusEvaluate
SummaryPrivilege management actions are audited.
DetailsTraditional audit – disabled. Unified audit – auditing enabled: ALTER ROLE, CREATE ROLE, DROP ROLE, GRANT ANY OBJECT PRIVILEGE, GRANT ANY PRIVILEGE, GRANT ANY ROLE
RemarksGranting additional privileges to users or roles potentially affects most security protection and should be audited. Each action or privilege listed here should be included in at least one enabled audit policy.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 5.1.4, 5.1.5, 5.1.15, 5.1.16, 5.2.4 – 5.2.8

Audit SQL Statements

AUDIT.STMT
StatusEvaluate
SummaryAuditing enabled for 18 statements.
DetailsUnified Audit (18): ALTER DATABASE DICTIONARY, ALTER DATABASE LINK, ALTER PLUGGABLE DATABASE, ALTER PROFILE, ALTER ROLE, ALTER USER, CREATE DATABASE LINK, CREATE DIRECTORY, CREATE PLUGGABLE DATABASE, CREATE PROFILE, CREATE ROLE, DROP DATABASE LINK, DROP DIRECTORY, DROP PLUGGABLE DATABASE, DROP PROFILE, DROP ROLE, LOGON, SET ROLE
RemarksThis finding shows the SQL statements that are audited by enabled audit policies. It is recommended that SQL statements like GRANT DIRECTORY and LOCK TABLE are audited.

Audit Object Actions

AUDIT.OBJSTIG
StatusEvaluate
SummaryAuditing enabled for 21 objects.
DetailsTraditional Audit: Schema DVSYS (18): AUDIT_TRAIL$, CODE$, COMMAND_RULE$, FACTOR$, FACTOR_LINK$, FACTOR_TYPE$, IDENTITY$, IDENTITY_MAP$, MAC_POLICY$, MAC_POLICY_FACTOR$, POLICY_LABEL$, REALM$, REALM_AUTH$, REALM_OBJECT$, ROLE$, RULE$, RULE_SET$, RULE_SET_RULE$ Schema LBACSYS (1): OLS$PROPS Unified Audit: Schema REMOTE_SCHEDULER_AGENT (1): ADD_AGENT_CERTIFICATE Schema SYS (1): DBMS_RLS
RemarksThis finding shows the object accesses that are audited by enabled audit policies.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-76141r1

Fine Grained Audit

AUDIT.FGA
StatusAdvisory
SummaryNo fine grained audit policies found.
DetailsNo object found with fine grained auditing enabled. Users with EXECUTE on SYS.DBMS_FGA: (none)
RemarksFine Grained Audit policies can record specific activity, such as access to particular table with sensitive columns or access that occurs under specified conditions. This is an effective useful way to monitor unexpected data access while avoiding unnecessary audit records that correspond to normal activity.

Encryption

Transparent Data Encryption

CRYPT.TDESTIGGDPR
StatusAdvisory
SummaryFound 4 unencrypted tablespaces. No encrypted columns found. Examined 1 initialization parameter.
DetailsUnencrypted tablespaces: SYSAUX, SYSTEM, TEMP, UNDOTBS1 Encrypted tablespaces: (none) ENCRYPT_NEW_TABLESPACES=CLOUD_ONLY. Recommended value is ALWAYS in the Oracle Cloud or in an on-premise database.
RemarksEncryption 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 keys may be stored in wallets on the database server itself, or stored remotely in Oracle Key Vault for improved security. The ENCRYPT_NEW_TABLESPACES parameter ensures that TDE tablespace encryption is applied to all newly created tablespaces. Setting this parameter to ALWAYS is recommended in order to protect all data regardless of the options specified when the tablespace is created.
ReferencesEU GDPR 2016/679: Article 6, 32, 34; Recital 83
Oracle Database 12c STIG v1 r10: Rule SV-76157r2, SV-76245r2, SV-76251r1, SV-76261r2, SV-76263r3

Encryption Key Wallet

CRYPT.WALLETSTIGGDPR
StatusEvaluate
SummaryFound 1 wallet. No wallets are stored in the data file directory.
DetailsEncryption wallet location: Wallet type: FILE Status: NOT_AVAILABLE Keystore type: UNKNOWN Wallet order: SINGLE Data file directory: /opt/oracle/product/19c/dbhome_1/dbs
RemarksWallets 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.
ReferencesEU GDPR 2016/679: Article 6, 32, 34; Recital 83
Oracle Database 12c STIG v1 r10: Rule SV-76015r1, SV-76223r2, SV-76233r2

Database Configuration

Initialization Parameters for Security

NameValue
ADG_ACCOUNT_INFO_TRACKINGLOCAL
AUDIT_FILE_DEST/opt/oracle/admin/ORCLCDB/adump
AUDIT_SYSLOG_LEVEL
AUDIT_SYS_OPERATIONSTRUE
AUDIT_TRAILDB
COMPATIBLE19.0.0
CURSOR_BIND_CAPTURE_DESTINATIONmemory+disk
DBFIPS_140FALSE
DISPATCHERS(PROTOCOL=TCP) (SERVICE=ORCLCDBXDB)
ENCRYPT_NEW_TABLESPACESCLOUD_ONLY
GLOBAL_NAMESFALSE
LDAP_DIRECTORY_ACCESSNONE
LDAP_DIRECTORY_SYSAUTHno
O7_DICTIONARY_ACCESSIBILITY
OS_AUTHENT_PREFIXops$
OS_ROLESFALSE
OUTBOUND_DBLINK_PROTOCOLSALL
PDB_LOCKDOWN
PDB_OS_CREDENTIAL
REMOTE_DEPENDENCIES_MODETIMESTAMP
REMOTE_LISTENER
REMOTE_LOGIN_PASSWORDFILEEXCLUSIVE
REMOTE_OS_AUTHENTFALSE
REMOTE_OS_ROLESFALSE
RESOURCE_LIMITTRUE
SEC_CASE_SENSITIVE_LOGONTRUE
SEC_MAX_FAILED_LOGIN_ATTEMPTS3
SEC_PROTOCOL_ERROR_FURTHER_ACTION(DROP,3)
SEC_PROTOCOL_ERROR_TRACE_ACTIONTRACE
SEC_RETURN_SERVER_RELEASE_BANNERFALSE
SQL92_SECURITYTRUE
UNIFIED_AUDIT_SGA_QUEUE_SIZE1048576
UNIFIED_AUDIT_SYSTEMLOG
UTL_FILE_DIR
_TRACE_FILES_PUBLIC

Access to Dictionary Objects

CONF.SYSOBJSTIGCIS
StatusPass
SummaryAccess to dictionary objects is properly limited.
RemarksWhen O7_DICTIONARY_ACCESSIBILITY is set to FALSE, tables owned by SYS are not accessible through 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.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 2.2.5
Oracle Database 12c STIG v1 r10: Rule SV-76079r2

Inference of Table Data

CONF.INFERSTIGCIS
StatusPass
SummaryData inference attacks are properly blocked.
DetailsSQL92_SECURITY=TRUE
RemarksWhen 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.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 2.2.17
Oracle Database 12c STIG v1 r10: Rule SV-75919r1

Access to Password File

CONF.PWDFILESTIG
StatusPass
SummaryThe password file is configured correctly.
DetailsREMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
RemarksThe 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.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75921r2

Network Communication

CONF.NETCOMSTIGCIS
StatusPass
SummaryExamined 4 initialization parameters. No issues found.
DetailsREMOTE_LISTENER=(none) SEC_PROTOCOL_ERROR_FURTHER_ACTION=(DROP,3) SEC_PROTOCOL_ERROR_TRACE_ACTION=TRACE SEC_RETURN_SERVER_RELEASE_BANNER=FALSE
RemarksREMOTE_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 version number and thus the vulnerabilities.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 2.2.7, 2.2.14, 2.2.15, 2.2.16
Oracle Database 12c STIG v1 r10: Rule SV-76305r4

External OS Authorization

CONF.EXTAUTHSTIGCIS
StatusPass
SummaryExamined 3 initialization parameters. No issues found.
DetailsREMOTE_OS_AUTHENT=FALSE REMOTE_OS_ROLES=FALSE OS_ROLES=FALSE
RemarksThe 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.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 2.2.6, 2.2.9, 2.2.10
Oracle Database 12c STIG v1 r10: Rule SV-75915r1, SV-75917r1

Instance Name Check

CONF.INSTNMSTIG
StatusPass
SummaryInstance name does not contain database version number.
DetailsInstance Name = ORCLCDB Database Version = 19.3.0.0.0
RemarksInstance 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.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75903r1

Triggers

CONF.TRIG
StatusPass
SummaryNo logon triggers found. No disabled triggers found.
RemarksA trigger is code that executes whenever a specific event occurs, such as inserting data in a table or connecting to the database. Disabled Oracle provided triggers could be a potential cause for concern because whatever protection or monitoring they may be expected to provide is disabled.

Disabled Constraints

CONF.CONST
StatusLow Risk
SummaryFound 1 disabled constraint.
DetailsDisabled constraints: STS_CHUNKS on GSMADMIN_INTERNAL.SHARD_TS
RemarksConstraints 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.

Directory Objects

CONF.DIR
StatusPass
SummaryFound 13 directory objects. No directory objects allow access to restricted Oracle directory paths. No directory objects allow both write and execute access.
DetailsDirectory Name: DATA_PUMP_DIR Path = /opt/oracle/admin/ORCLCDB/dpdump/B9DD1D2DCC4245C0E0530402000AE142/ Users or roles with access: EXP_FULL_DATABASE(READ, WRITE), IMP_FULL_DATABASE(READ, WRITE) Directory Name: JAVA$JOX$CUJS$DIRECTORY$ Path = /opt/oracle/product/19c/dbhome_1/javavm/admin/ Users or roles with access: (none) Directory Name: OPATCH_INST_DIR Path = /opt/oracle/product/19c/dbhome_1/OPatch/ Users or roles with access: (none) Directory Name: OPATCH_LOG_DIR Path = /opt/oracle/product/19c/dbhome_1/rdbms/log/ Users or roles with access: (none) Directory Name: OPATCH_SCRIPT_DIR Path = /opt/oracle/product/19c/dbhome_1/QOpatch/ Users or roles with access: (none) Directory Name: ORACLE_BASE Path = /opt/oracle/ Users or roles with access: (none) Directory Name: ORACLE_HOME Path = /opt/oracle/product/19c/dbhome_1/ Users or roles with access: (none) Directory Name: ORACLE_OCM_CONFIG_DIR Path = /opt/oracle/product/19c/dbhome_1/ccr/state/ Users or roles with access: (none) Directory Name: ORACLE_OCM_CONFIG_DIR2 Path = /opt/oracle/product/19c/dbhome_1/ccr/state/ Users or roles with access: (none) Directory Name: SDO_DIR_ADMIN Path = /opt/oracle/product/19c/dbhome_1/md/admin/ Users or roles with access: (none) Directory Name: SDO_DIR_WORK Path = Users or roles with access: (none) Directory Name: XMLDIR Path = /opt/oracle/product/19c/dbhome_1/rdbms/xml/ Users or roles with access: (none) Directory Name: XSDDIR Path = /opt/oracle/product/19c/dbhome_1/rdbms/xml/schema/ Users or roles with access: (none)
RemarksDirectory 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

CONF.LINKSSTIGCIS
StatusEvaluate
SummaryFound 1 database link. Database link names may not be same as remote database connection they define.
DetailsGLOBAL_NAMES=FALSE Users with CREATE DATABASE LINK privilege: (none) Users with CREATE PUBLIC DATABASE LINK privilege: (none) Private links: SYS: SYS_HUB
RemarksDatabase 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.
ReferencesCIS Oracle Database 12c Benchmark v2.0.0: Recommendation 2.2.3
Oracle Database 12c STIG v1 r10: Rule SV-75941r1, SV-75997r1, SV_76019r1

Network Access Control

CONF.NETACL
StatusPass
SummaryFound 1 network ACL.
DetailsNETWORK_ACL_86B64B675CBB012EE053F706E80A06B7 (Host: *, Ports: Min – Max) Principal: GGSYS, Action: deny, Privilege: resolve Principal: GSMADMIN_INTERNAL, Action: deny, Privilege: resolve
RemarksNetwork 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

CONF.XMLACL
StatusEvaluate
SummaryFound 9 XML Database ACLs.
DetailsNamespace: {http://xmlns.oracle.com/xdb/acl.xsd} Description: Protected:Readable by PUBLIC and all privileges to OWNER Principal: dav:owner, Action: grant, Privileges: all Principal: XDBADMIN, Action: grant, Privileges: all Principal: PUBLIC, Action: grant, Privileges: read-properties, read- contents, read-acl, resolve Namespace: {http://xmlns.oracle.com/xdb/acl.xsd} Description: Public:All privileges to PUBLIC Principal: PUBLIC, Action: grant, Privileges: all Namespace: {http://xmlns.oracle.com/xdb/acl.xsd} Description: Private:All privileges to OWNER only and not accessible to others Principal: dav:owner, Action: grant, Privileges: all Namespace: {http://xmlns.oracle.com/xdb/acl.xsd} Description: Read-Only:Readable by all and writeable by none Principal: PUBLIC, Action: grant, Privileges: read-properties, read- contents, read-acl, resolve Namespace: {http://xmlns.oracle.com/xdb/acl.xsd} Description: Protected:Readable by PUBLIC and all privileges to OWNER Principal: dav:owner, Action: grant, Privileges: all Principal: XDBADMIN, Action: grant, Privileges: all Principal: PUBLIC, Action: grant, Privileges: read-properties, read- contents, read-acl, resolve Principal: OLAP_XS_ADMIN, Action: grant, Privileges: all Namespace: {http://xmlns.oracle.com/xdb/acl.xsd} Description: Protected:Readable by PUBLIC and all privileges to OWNER Principal: dav:owner, Action: grant, Privileges: all Principal: XDBADMIN, Action: grant, Privileges: all Principal: PUBLIC, Action: grant, Privileges: read-properties, read- contents, read-acl, resolve Principal: OLAP_XS_ADMIN, Action: grant, Privileges: all Namespace: {http://xmlns.oracle.com/xdb/acl.xsd} Description: Protected:Readable by PUBLIC and all privileges to OWNER Principal: dav:owner, Action: grant, Privileges: all Principal: XDBADMIN, Action: grant, Privileges: all Principal: PUBLIC, Action: grant, Privileges: read-properties, read- contents, read-acl, resolve Principal: OLAP_XS_ADMIN, Action: grant, Privileges: all Namespace: {http://xmlns.oracle.com/xdb/acl.xsd} Description: Protected:Readable by PUBLIC and all privileges to OWNER Principal: dav:owner, Action: grant, Privileges: all Principal: XDBADMIN, Action: grant, Privileges: all Principal: PUBLIC, Action: grant, Privileges: read-properties, read- contents, read-acl, resolve Principal: OLAP_XS_ADMIN, Action: grant, Privileges: all Namespace: {http://xmlns.oracle.com/xdb/acl.xsd} Description: Protected:Readable by PUBLIC and all privileges to OWNER Principal: dav:owner, Action: grant, Privileges: all Principal: XDBADMIN, Action: grant, Privileges: all Principal: PUBLIC, Action: grant, Privileges: read-properties, read- contents, read-acl, resolve Principal: OLAP_XS_ADMIN, Action: grant, Privileges: all
RemarksXML 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

CONF.BKUPSTIG
StatusHigh Risk
SummaryNo Backup Records found for the last 90 days.
RemarksDatabase 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 distributed environment.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-76179r1, SV-76183r1, SV-76185r1, SV-76187r1, SV-76189r1, SV-76191r1

Network Configuration

Network Encryption

NET.CRYPTSTIG
StatusAdvisory
SummaryNative encryption is accepted but not required. Integrity check using checksums is accepted but not required.
DetailsSQLNET.ENCRYPTION_SERVER is not set (default value = ACCEPTED). SQLNET.CRYPTO_CHECKSUM_SERVER is not set (default value = ACCEPTED). LISTENER.ORA not available. SSL_CERT_REVOCATION is not set (default value = NONE).
RemarksNetwork encryption protects the confidentiality and integrity of communication between the database server and its clients. Either Native Encryption or TLS should be configured to ensure that the connections from clients are encrypted. For Native Encryption, both ENCRYPTION_SERVER and CRYPTO_CHECKSUM_SERVER should be set to REQUIRED. For ease of deployment and compatibility, Oracle Database servers and clients are set to ACCEPT encrypted connections out of the box. This means that you can enable the desired encryption and integrity settings for a connection pair by configuring just one side of the connection, server-side or client-side. So, for example, if there are many Oracle clients connecting to an Oracle database instance, you can configure the required encryption and integrity settings for all these connections by making the appropriate sqlnet.ora changes at the server end. You do not need to implement configuration changes for each client separately. However, in this case, the risk of having plaintext data passed over the network still exists. Keep in mind that whether the security service is enabled or not it is based on a combination of client and server configuration parameters. If TLS is used, TCPS should be specified for all network ports and SSL_CERT_REVOCATION should be set to REQUIRED.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75937r2, SV-76035r5, SV-76165r1, SV-76193r2, SV-76195r2, SV-76203r4, SV-76205r4, SV-76231r3, SV-76233r2, SV-76239r1, SV-76241r1, SV-76305r4

Client Nodes

NET.CLIENTSSTIG
StatusMedium Risk
SummaryValid node check is not enabled, can accept connections from any client. Neither TCP.INVITED_NODES nor TCP.EXCLUDED_NODES is set.
DetailsTCP.VALIDNODE_CHECKING is not set (default value = NO). Recommended value is YES. TCP.INVITED_NODES is not set. TCP.EXCLUDED_NODES is not set.
RemarksTCP.VALIDNODE_CHECKING should be enabled to control which client nodes can connect to the database server. Either a whitelist of client nodes(IP Address/Hostname/Subnet) allowed to connect (TCP.INVITED_NODES) or a blacklist 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.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75985r1, SV-76005r2, SV-76305r4

SQLNET Banners

NET.BANNER
StatusEvaluate
SummaryConnect banners are not fully configured.
DetailsSEC_USER_AUDIT_ACTION_BANNER is not set. Should be set to a proper value. SEC_USER_UNAUTHORIZED_ACCESS_BANNER is not set. Should be set to a proper value.
RemarksThese banner messages are used to warn connecting users that unauthorized access is not permitted and that their activities may be audited.

Operating System

OS Authentication

OS.AUTHSTIG
StatusEvaluate
Summary4 OS users can connect to the database via OS authentication.
DetailsSYSDBA [dba group]: oracle, grid, badr, omar SYSOPER [oper group]: oracle SYSBACKUP [backupdba group]: oracle SYSKM [kmdba group]: oracle SYSDG [dgdba group]: oracle SYSRAC [racdba group]: oracle
RemarksOS authentication allows operating system users within the specified user group to connect to the database with administrative privileges without any further authentication. 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.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75977r1, SV-76027r1

Process Monitor Processes

OS.PMONSTIG
StatusPass
SummaryFound 1 PMON process. The owner of the PMON process matches the ORACLE_HOME owner.
DetailsPMON process: ora_pmon_ORCLCDB, Owner: oracle ORACLE_HOME owner: oracle
RemarksThe PMON process monitors user processes and frees resources when they terminate. This process should run with the user ID of the ORACLE_HOME owner.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-76069r1

Agent Processes

OS.AGENT
StatusPass
SummaryFound 6 Agent processes. Agent process owners do not overlap with Listener or PMON process owners.
DetailsOwner: oracle-+ Command: /usr/libexec/oracle-cloud-agent/agent Owner: oracle-+ Command: /usr/libexec/oracle-cloud-agent/plugins/gomon/gomon Owner: root Command: /usr/bin/sudo -n -u ocarun /usr/libexec/oracle-cloud- agent/plugins/runcommand/runcommand Owner: ocarun Command: /usr/libexec/oracle-cloud-agent/plugins/runcommand/runcommand Owner: oracle-+ Command: /usr/libexec/oracle-cloud-agent/updater/updater Owner: oracle-+ Command: /usr/libexec/oracle-cloud-agent/updater/updater
RemarksAgent processes are used by Oracle Enterprise Manager to monitor and manage the database. These processes should run with a user ID separate from the database and listener processes.

Listener Processes

OS.LISTENSTIG
StatusEvaluate
SummaryFound 1 Listener process. Some Listener processes are owned byAgent or PMON process owners.
DetailsOwner: oracle Command: /opt/oracle/product/19c/dbhome_1/bin/tnslsnr LISTENER -inherit
RemarksListener 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.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-75931r1

File Permissions in ORACLE_HOME

OS.FILESSTIG
StatusMedium Risk
SummaryExamined 594 files. Found 8 errors.
DetailsORACLE_HOME: /opt/oracle/product/19c/dbhome_1 ORACLE_HOME owner: oracle Directories: 5 (0 permission errors) Executables in $ORACLE_HOME/bin: 225 (0 permission errors) Configuration files in $TNS_ADMIN: 1 (0 permission errors) Data files in $ORACLE_HOME/dbs: 8 (1 permission errors) Libraries in $ORACLE_HOME/lib: 355 (7 permission errors) Files with permission errors: dbs/init.ora (rw-r–r– should be rw-r—–) lib/libdpsadapi19.a (rw-rw-r– should be rw-r–r–) lib/libdpsadrda19.a (rw-rw-r– should be rw-r–r–) lib/libdpsc19.a (rw-rw-r– should be rw-r–r–) lib/libdpsf19.a (rw-rw-r– should be rw-r–r–) lib/libdpsp19.a (rw-rw-r– should be rw-r–r–) lib/libdpss19.a (rw-rw-r– should be rw-r–r–) lib/libedtn19.a (rw-rw-r– should be rw-r–r–)
RemarksThe 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.
ReferencesOracle Database 12c STIG v1 r10: Rule SV-76001r1, SV-76277r1, SV-76359r1, SV-76365r1

This report provides information and recommendations that may be helpful in securing your Oracle database system. These recommendations reflect best practices for database security and should be part of any strategy for Data Protection by Design and by Default. These practices may help in addressing Articles 25 and 32 of the EU General Data Protection Regulation as well as other data privacy regulations. Technical controls alone are not sufficient for compliance. Passing all findings does not guarantee compliance.

Oracle Database Vault, Oracle Advanced Security, Oracle Label Security, Oracle Data Masking and Subsetting Pack are database licensed options. Oracle Key Vault and Oracle Audit Vault and Database Firewall require separate licensing as well.

The report provides a view on the current status. The results shown are provided for informational purposes only and should not be used as a substitute for a thorough analysis or interpreted to contain any legal or regulatory advice or guidance.

You are solely responsible for your system, and the data and information gathered during the production of this report. You are also solely responsible for the execution of software to produce this report, and for the effect and results of the execution of any mitigating actions identified herein.

Oracle provides this analysis on an “as is” basis without warranty of any kind and Oracle hereby disclaims all warranties and conditions whether express, implied or statutory.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s