V1R6 changes
Oracle Database 19c STIG V1R6 (2026-09-30) replaced V1R5 (2026-04-01): 21 checks updated. It has 96 checks, against 96 in V1R5.
V1R6 checklistV1R5 checklist Compare V1R5 and V1R6 in STIG Compare
- 0 added
- 0 removed
- 21 updated
Updated fields: Discussion 11Check text 10Fix text 10Title 4Severity 1
Updated in V1R6 (21)
V-270500CAT IOracle Database must enforce approved authorizations for logical access to the system in accordance with applicable policy.Discussion
Discussion
Authentication with a DODDoW-approved public key infrastructure (PKI) certificate does not necessarily imply authorization to access the database management system (DBMS). To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DODDoW-approved PKIs, all DODDoW systems, including databases, must be properly configured to implement access control policies.
Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement.
Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.
This requirement is applicable to access control enforcement applications, a category that includes database management systems. If the DBMS does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy.
Satisfies: SRG-APP-000033-DB-000084, SRG-APP-000340-DB-000304
V-270502CAT IIOracle Database must provide audit record generation capability for organization-defined auditable events within the database.Discussion
Discussion
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Audit records can be generated from various components within the database management system (DBMS) (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.
DODDoW has defined the list of events for which the DBMS will provide an audit record generation capability as the following:
(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);
(ii) Access actions, such as successful and unsuccessful login attempts, privileged activities, or other system-level access, starting and ending time for user access to the system, concurrent logins from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and
(iii) All account creation, modification, disabling, and termination actions.
Organizations may define additional events requiring continuous or ad hoc auditing.
V-270504CAT IIOracle Database must generate audit records for the DoW-selected list of auditable events, when successfully accessed, added, modified, or deleted, to the extent such information is available.Title, Check text, Fix text
Title
Oracle Database must generate audit records for the DODDoW-selected list of auditable events, when successfully accessed, added, modified, or deleted, to the extent such information is available.
Check text
Check Oracle Database settings to determine if auditing is being performed on the DODDoW-required list of auditable events supplied in the discussion.
If Standard Auditing is used:
To verify Oracle is configured to capture audit data, enter the following SQL*Plus command:
SHOW PARAMETER AUDIT_TRAIL
Or the following SQL query:
col display_value format a10
col default_value format a10
SELECT inst_id, con_id, display_value, default_value, isdefault
FROM sys.gv_$parameter WHERE name = 'audit_trail';
If Oracle returns the value "NONE", this is a finding.
To confirm Oracle audit is capturing information on the required events, review the contents of the SYS.AUD$ table or the audit file, whichever is in use. If auditable events are not listed, this is a finding.
If Unified Auditing is used:
To verify Oracle is configured to capture audit data, enter the following SQL*Plus command:
col value format a10
SELECT inst_id, con_id, value
FROM sys.gv_$option
WHERE parameter = 'Unified Auditing';
If Oracle returns a value something other than "TRUE", this is a finding.
Unified Audit supports named audit policies, which are defined using the CREATE AUDIT POLICY statement. A policy specifies the actions that should be audited and the objects to which it should apply. If no specific objects are included in the policy definition, it applies to all objects.
A named policy is enabled using the AUDIT POLICY statement. It can be enabled for all users, for specific users only, or for all except a specified list of users. The policy can audit successful actions, unsuccessful actions, or both.
Verifying existing audit policy: existing Unified Audit policies are listed in the view AUDIT_UNIFIED_POLICIES. The AUDIT_OPTION column contains one of the actions specified in a CREATE AUDIT POLICY statement. The AUDIT_OPTION_TYPE column contains "STANDARD ACTION" for a policy that applies to all objects or "OBJECT ACTION" for a policy that audits actions on a specific object.
SELECT policy_name
FROM sys.audit_unified_policies
WHERE audit_option = 'GRANT'
AND audit_option_type= 'STANDARD ACTION';
To find policies that audit privilege grants on specific objects:
col policy_name format a20
col object_schema format a20
col object_name format a30
SELECT policy_name, object_schema, object_name
FROM sys.audit_unified_policies
WHERE audit_option = 'GRANT'
AND audit_option_type = 'OBJECT ACTION';
The view AUDIT_UNIFIED_ENABLED_POLICIES shows which Unified Audit policies are enabled. The ENABLED_OPT and USER_NAME columns show the users for whom the policy is enabled or "ALL USERS". The SUCCESS and FAILURE columns indicate if the policy is enabled for successful or unsuccessful actions, respectively.
col entity_name format a30
SELECT policy_name, enabled_option, entity_name, success, failure
FROM sys.audit_unified_enabled_policies;
If auditing is not being performed for all the events listed above, this is a finding.
Fix text
Both Standard and Unified Auditing are allowed in Oracle Database 19c.
The default is mixed auditing mode.
The predefined policy ORA_SECURECONFIG is enabled by default in mixed mode.
Configure the DBMS's auditing settings to include auditing of events on the DODDoW-selected list of auditable events.
1. Successful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels).
To audit granting and revocation of any privilege:
CREATE AUDIT POLICY <policy_name> ACTIONS GRANT;
CREATE AUDIT POLICY <policy_name> ACTIONS REVOKE;
To audit grants of object privileges on a specific object:
CREATE AUDIT POLICY <policy_name> ACTIONS GRANT ON <schema>.<object>;
If Oracle Label Security is enabled, this will audit all OLS administrative actions:
CREATE AUDIT POLICY <policy_name> ACTIONS COMPONENT = OLS ALL;
2. Successful and unsuccessful logon attempts, privileged activities or other system-level access.
To audit all user logon attempts:
CREATE AUDIT POLICY <policy_name> ACTIONS LOGON;
To audit only logon attempts using administrative privileges (e.g., AS SYSDBA):
AUDIT POLICY <policy_name> BY sys, sysoper, sysbackup, sysdg, syskm;
3. Starting and ending time for user access to the system, concurrent logons from different workstations.
This policy will audit all logon and logoff events. An individual session is identified in the UNIFIED_AUDIT_TRAIL by the tuple (DBID, INSTANCE_ID, SESSIONID) and the start and end time will be indicated by the EVENT_TIMESTAMP of the logon and logoff events:
CREATE AUDIT POLICY <policy_name> ACTIONS logon, logoff;
4. Successful and unsuccessful accesses to objects.
To audit all accesses to a specific table:
CREATE AUDIT POLICY <policy_name> ACTIONS select, insert, delete, alter ON <schema>.<object>;
Different actions are defined for other object types. To audit all supported actions on a specific object:
CREATE AUDIT POLICY <policy_name> ACTIONS all ON <schema>.<object>;
5. All program initiations.
To audit execution of any PL/SQL program unit:
CREATE AUDIT POLICY <policy_name> ACTIONS execute;
To audit execution of a specific function, procedure, or package:
CREATE AUDIT POLICY <policy_name> ACTIONS execute ON <schema>.<object>;
6. All direct access to the information system.
[Not applicable to Database audit. Monitor using OS auditing.]
7. All account creations, modifications, disabling, and terminations.
To audit all user administration actions:
CREATE AUDIT POLICY <policy_name> actions create user, alter user, drop user, change password;
8. All kernel module loads, unloads, and restarts.
[Not applicable to Database audit. Monitor using OS auditing.]
9. All database parameter changes.
To audit any database parameter changes, dynamic or static:
CREATE AUDIT POLICY <policy_name> ACTIONS alter database, alter system, create spfile;
Applying the Policy:
The following command will enable the policy in all database sessions and audit both successful and unsuccessful actions:
AUDIT POLICY <policy_name>;
To audit only unsuccessful actions, add the WHENEVER NOT SUCCESSFUL modifier:
AUDIT POLICY <policy_name> WHENEVER NOT SUCCESSFUL;
Either command above can be limited to only database sessions started by a specific user as follows:
AUDIT POLICY <policy_name> BY <user>;
AUDIT POLICY <policy_name> BY <user> WHENEVER NOT SUCCESSFUL;
V-270520CAT IIOracle Database must be configured in accordance with the security configuration settings based on DoW security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs.Title, Discussion
Title
Oracle Database must be configured in accordance with the security configuration settings based on DODDoW security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs.
Discussion
Configuring the database management system (DBMS) to implement organizationwide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DODDoW that reflects the most restrictive security posture consistent with operational requirements. In addition to this SRG, sources of guidance on security and information assurance exist. These include NSA configuration guides, CTOs, DTMs, and IAVMs. Oracle Database must be configured in compliance with guidance from all such relevant sources, with specific emphasis on the database security standards of each organization.
V-270524CAT IIThe Oracle REMOTE_OS_ROLES parameter must be set to FALSE.Check text, Fix text, Discussion
Check text
To verify the current status of the remote_os_roles parameter use the SQL statement:
Ifsqlplus usingconnect aas non-CDB database:sysdba
From SQL*Plus:
COLUMN name format a20
COLUMN parameter_value format a20
SELECT namegp.inst_id, gp.con_id, gp.value AS PARAMETER_VALUE
FROM sys.v_gv_$parameter gp
WHERE vpgp.name = 'remote_os_roles'
ORDER BY 1;
IfFor theevery PARAMETER_VALUEstandalone isinstance notor FALSE,container that is a finding.
If using a CDB database:
From SQL*Plus (in the CDB database):
COLUMN name format a20
COLUMN parameter_value format a20
SELECT name, inst_id, con_id, value AS PARAMETER_VALUE
FROM sys.gv_$parameter
WHERE vp.name = 'remote_os_roles'
ORDER BY 1;
In the CDB database, if the PARAMETER_VALUE is not FALSE, that is a finding.
Fix text
Set the parameter to FALSE for all instances. If using Oracle Multitenant, set the value to FALSE for the container database and all pluggable databases will be set to FALSE as well.
sqlplus connect as sysdba
ALTER SYSTEM SET remote_os_roles = FALSE scopeSCOPE=spfile SID='*';
SHUTDOWN IMMEDIATE;
STARTUP;
sid
SID='container_name*' is optionalrequired
Restartif the database foris a RAC database.
If the changeparameter tovalue takeis effectdifferent in different containers it cannot be brought into compliance using ALTER SYSTEM: Open a Service Request with Oracle Support.
Discussion
Setting REMOTE_OS_ROLES to TRUE allows operating system groups to control Oracle roles. The default value of FALSE causes roles to be identified and managed by the database. If REMOTE_OS_ROLES is set to TRUE, a remote user could impersonate another operating system user over a network connection.
DODDoW requires the REMOTE_OS_ROLES to be set to FALSE.
V-270525CAT IIThe Oracle SQL92_SECURITY parameter must be set to TRUE.Check text, Fix text
Check text
To verifydetermine the current statussetting ofrun the SQL92_SECURITY parameter use the SQL statement:
IfConnect using a non-CDB the database:
Fromsqlplus SQL*Plus:
selectconnect valueas from v$parameter where name = 'sql92_security';sysdba
If using a CDB database:
From SQL*Plus:
column name format a20
column parameter_value format a20
SELECT name, inst_id, con_id, value AS PARAMETER_VALUE
FROM sys.gv_$parameter
WHERE name = 'sql92_security'
ORDER BY 1;
CheckIf Result:
Thethe CDBvalue databasefor andany allinstance PDBsor mustcontainer be checked.
If the value returned is set to FALSE, this is a finding.
If the parametervalue isfor setany toinstance or container is TRUE or does not exist (NULL), this is not a finding.
In any instance or container, if the PARAMETER_VALUE is not TRUE, that is a finding.
Fix text
Enable SQL92 security.
FromConnect SQL*Plusto the database:
sqlplus connect as sysdba
alter
ALTER systemSYSTEM setSET sql92_security = TRUE scopeSCOPE=spfile SID='*';
SHUTDOWN spfileIMMEDIATE;
STARTUP;
The above SQL
SID='*Plus' commandis willrequired setif the parameterdatabase tois takea effectRAC at next system startupdatabase.
V-270527CAT IISystem privileges granted using the WITH ADMIN OPTION must not be granted to unauthorized user accounts.Check text, Fix text
Check text
AUse defaultthe Oraclefollowing Databasequery installation provides a set of predefined administrative accounts and nonadministrative accounts. These are accounts that have special privileges required to administeridentify areasusers ofwith the database,ADMIN such as the CREATE ANY TABLE or ALTER SESSION privilege or EXECUTE privileges on packages owned by the SYS schemaoption. The default tablespace for administrative accounts is either SYSTEM or SYSAUX. Nonadministrative user accounts only have the minimum privileges needed to perform their jobs. Their default tablespace is USERS.
Tosqlplus protectconnect these accounts from unauthorized access, the installation process expires and locks most of these accounts, except where noted below. The database administrator is responsible for unlocking and resetting these accounts, as required.sysdba
NonadministrativeSELECT Accounts - Expired and locked:
APEX_PUBLIC_USERcon_id, DIPgrantee, FLOWS_040100*,privilege
FROM FLOWS_FILES,sys.cdb_sys_privs MDDATA, SPATIAL_WFS_ADMIN_USR, XS$NULL
AdministrativeWHERE Accountsadmin_option -= Expired and Locked:'YES'
ANONYMOUS,AND CTXSYS(con_id, EXFSYS,grantee) LBACSYS,NOT MDSYS,IN OLAPSYS, ORACLE_OCM, ORDDATA, OWBSYS, ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, SPATIAL_CSW_ADMIN_USR, WK_TEST, WK_SYS, WKPROXY, WMSYS, XDB(
Administrative SELECT Accounts - Open:
DBSNMPcon_id, MGMT_VIEW,username SYS, SYSMAN, SYSTEM, SYSKM
*Subject FROM to change based on version installedsys.
Runcdb_users theWHERE SQLoracle_maintained query:
From= SQL*Plus:'Y')
selectAND grantee, privilege from dba_sys_privs
where grantee not in (<list'DV_ACCTMGR', of nonapplicable accounts>)
and admin_option = 'YESSCHEDULER_ADMIN'
and, grantee not in
(select grantee from dba_role_privs where granted_role = 'DBAAQ_ADMINISTRATOR_ROLE');
(WithORDER respectBY to the list of special accounts that are excluded from this requirement1, it is expected that the DBA will maintain the list to suit local circumstances2, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.)3;
If any accounts that are not authorized to have the ADMIN OPTION are listed, this is a finding.
Fix text
Revoke assignment of privileges with the WITH ADMIN OPTION from unauthorized users and regrant them without the option. From SQL*Plus: revoke [privilege name] from user [username]; Replace [privilege name] with the named privilege and [username] with the named user. Re-grant the revoked privileges without specifying WITH ADMIN OPTION if they are otherwise authorized to have the privilege but are not authorized as administrators to administer the privilege. Restrict use of the WITH ADMIN OPTION to authorized administrators. Document authorized privilege assignments with the WITH ADMIN OPTION in the system documentation.
V-270528CAT IISystem Privileges must not be granted to PUBLIC.Check text, Fix text
Check text
FromTo determine the current setting run the SQL*Plus statement:
Selectsqlplus privilegeconnect fromas dba_sys_privssysdba
SELECT wherecon_id, privilege
FROM sys.cdb_sys_privs
WHERE grantee = 'PUBLIC'
ORDER BY 1,2;
System privileges are not granted to PUBLIC by default and would indicate a custom action.
If any records are returned, this is a finding.
Fix text
Revoke any system privileges assigned to PUBLIC: in any containers in which they are found.
Fromsqlplus SQL*Plus:connect as sysdba
revokeREVOKE [system privilegesystem_privilege] fromFROM PUBLIC;
Replace [system privilege] with the named system privilege.
Note: System privileges are not granted to PUBLIC by default and would indicate a custom action.
V-270529CAT IIOracle roles granted using the WITH ADMIN OPTION must not be granted to unauthorized accounts.Check text, Fix text
Check text
AUse defaultthe Oraclefollowing Databasequery installation provides a set of predefined administrative accounts and nonadministrative accounts. These are accounts that have special privileges required to administeridentify areasusers ofwith the database,ADMIN such as the CREATE ANY TABLE or ALTER SESSION privilege or EXECUTE privileges on packages owned by the SYS schemaoption. The default tablespace for administrative accounts is either SYSTEM or SYSAUX. Nonadministrative user accounts only have the minimum privileges needed to perform their jobs. Their default tablespace is USERS.
Tosqlplus protectconnect these accounts from unauthorized access, the installation process expires and locks most of these accounts, except where noted below. The database administrator is responsible for unlocking and resetting these accounts, as required.sysdba
Non-AdministrativeSELECT Accounts - Expired and locked:
APEX_PUBLIC_USERcon_id, DIPgrantee, FLOWS_040100*,granted_role
FROM FLOWS_FILES,sys.cdb_role_privs MDDATA, SPATIAL_WFS_ADMIN_USR, XS$NULL
AdministrativeWHERE Accountsadmin_option -= Expired and Locked:'YES'
ANONYMOUS,AND CTXSYS(con_id, EXFSYS,grantee) LBACSYS,NOT MDSYS,IN OLAPSYS, ORACLE_OCM, ORDDATA, OWBSYS, ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, SPATIAL_CSW_ADMIN_USR, WK_TEST, WK_SYS, WKPROXY, WMSYS, XDB(
Administrative SELECT Accounts - Open:
DBSNMPcon_id, MGMT_VIEW,username SYS, SYSMAN, SYSTEM
*Subject FROM tosys.cdb_users changeWHERE basedoracle_maintained on= version installed.'Y')
RunAND the(con_id, SQL statement:
select grantee||':) '||granted_roleNOT fromIN dba_role_privs(
where SELECT granteecon_id, not inrole
(<list FROM ofsys.cdb_roles nonapplicableWHERE accounts>)
andoracle_maintained admin_option = 'YESY' )
andAND grantee not in
(select distinct owner from dba_objectsgrantee)
and grantee not in
(select grantee from dba_role_privs
where granted_role = ('DBAPDBUSER')
orderORDER byBY grantee;
(With respect to the list of special accounts that are excluded from this requirement1, it is expected that the DBA will maintain the list to suit local circumstances2, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.)3;
Review the system documentation to confirm any grantees listed are information system security officer (ISSO)-authorized DBA accounts or application administration roles.
If any grantees listed are not authorized and documented, this is a finding.
Fix text
Revoke assignment of roles with the WITH ADMIN OPTION from unauthorized grantees and regrant them without the option if required.
SQL statements to remove the admin option from an unauthorized grantee:
revokeREVOKE <role[privilege name>] fromFROM <grantee>[grantee];
Re-grant <rolethe name>revoked privileges without specifying WITH ADMIN OPTION if they are otherwise authorized to <grantee>;have the privilege but are not authorized as administrators to administer the privilege.
Restrict use of the WITH ADMIN OPTION to authorized administrators.
Document authorized role assignments with the WITH ADMIN OPTION in the system documentation.
V-270561CAT IIOracle Database must enforce the DoW standards for password complexity.Title, Fix text, Discussion
Title
Oracle Database must enforce the DODoW standards for password complexity.
Fix text
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required.
If any user accounts are managed by Oracle, develop, test, and implement a password verification function that enforces DODDoW requirements.
Oracle supplies a sample function called ORA12C_STIG_VERIFY_FUNCTION. This can be used as the starting point for a customized function. The script file is found in the following location on the server depending on OS:
Windows:
%ORACLE_HOME%1RDBMS1ADMIN1catpvf.sql
Unix/Linux:
$ORACLE_HOME/rdbms/admin/catpvf.sql
Discussion
OS/enterprise authentication and identification must be used (SRG-APP-000023-DB-000001). Native database management system (DBMS) authentication may be used only when circumstances make it unavoidable; and must be documented and authorizing official (AO)-approved.
The DODDoW standard for authentication is DODDoW-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate and requires AO approval.
In such cases, the DODDoW standards for password complexity and lifetime must be implemented. DBMS products that can inherit the rules for these from the operating system or access control program (e.g., Microsoft Active Directory) must be configured to do so. For other DBMSs, the rules must be enforced using available configuration parameters or custom code.
Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP. This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.
V-270562CAT IIProcedures for establishing temporary passwords that meet DoW password requirements for new accounts must be defined, documented, and implemented.Title, Check text, Fix text
Title
Procedures for establishing temporary passwords that meet DODoW password requirements for new accounts must be defined, documented, and implemented.
Check text
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding.
Where accounts are authenticated using passwords, review procedures and implementation evidence for creation of temporary passwords.
If the procedures or evidence do not exist or do not enforce passwords to meet DODDoW password requirements, this is a finding.
Fix text
Implement procedures for assigning temporary passwords to user accounts.
Procedures should include instructions to meet current DODDoW password length and complexity requirements and provide a secure method to relay the temporary password to the user.
V-270563CAT IIOracle Database must enforce password maximum lifetime restrictions.Check text, Fix text
Check text
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding.
Review database management system (DBMS) settings to determine if passwords must be changed periodically. Run the following script:
SELECT p1.profile,
CASE DECODE(p1.limit, 'DEFAULT', p3.limit, p1.limit) WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE
CASE DECODE(p2.limit, 'DEFAULT', p4.limit, p2.limit) WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE
TO_CHAR(DECODE(p1.limit, 'DEFAULT', p3.limit, p1.limit) + DECODE(p2.limit, 'DEFAULT', p4.limit, p2.limit))
END
END effective_life_time
FROM dba_profiles p1, dba_profiles p2, dba_profiles p3, dba_profiles p4
WHERE p1.profile=p2.profile
AND p3.profile='DEFAULT'
AND p4.profile='DEFAULT'
AND p1.resource_name='PASSWORD_LIFE_TIME'
AND p2.resource_name='PASSWORD_GRACE_TIME'
AND p3.resource_name='PASSWORD_LIFE_TIME' -- from DEFAULT profile
AND p4.resource_name='PASSWORD_GRACE_TIME' -- from DEFAULT profile
order by 1;
If the EFFECTIVE_LIFE_TIME is greater than 60180 for any profile applied to user accounts, and the need for this has not been documented and approved, this is a finding.
If PASSWORD_LIFE_TIME or PASSWORD_GRACE_TIME is set to "UNLIMITED", this is a finding.
Fix text
For user accounts managed by Oracle, modify DBMS settings to force users to periodically change their passwords. For example, using "PPPPPP" to stand for a profile name:
ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35180 PASSWORD_GRACE_TIME 0;
Do this for each profile applied to user accounts.
Note: Although the DOD requirement is for a password change every 60 days, using a value of 35 facilitates the use of PASSWORD_LIFE_TIME as a means of locking accounts inactive for 35 days. But if 35 is not a practical or acceptable limit for password lifetime, set it to the standard DOD value of 60.
Where a password lifetime longer than 60180 is needed, document the reasons and obtain information system security officer (ISSO) approval.
V-270564CAT IOracle Database must, for password-based authentication, store passwords using an approved salted key derivation function, preferably using a keyed hash.Discussion
Discussion
The DODDoW standard for authentication is DODDoW-approved public key infrastructure (PKI) certificates.
Authentication based on user ID and password may be used only when it is not possible to employ a PKI certificate and requires authorizing official (AO) approval.
In such cases, database passwords stored in clear text, using reversible encryption, or using unsalted hashes would be vulnerable to unauthorized disclosure. Database passwords must always be in the form of one-way, salted hashes when stored internally or externally to the database management system (DBMS).
Database passwords stored in clear text are vulnerable to unauthorized disclosure. Database passwords must always be encoded or encrypted when stored internally or externally to the DBMS.
Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names that include "SSL", such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
V-270565CAT IIIf passwords are used for authentication, the Oracle Database must transmit only encrypted representations of passwords.Discussion
Discussion
The DODDoW standard for authentication is DODDoW-approved public key infrastructure (PKI) certificates.
Authentication based on user ID and password may be used only when it is not possible to employ a PKI certificate, and requires authorizing official (AO) approval.
In such cases, passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission.
Database management system (DBMS) passwords sent in clear text format across the network are vulnerable to discovery by unauthorized users. Disclosure of passwords may easily lead to unauthorized access to the database.
Transport Layer Security (TLS) is the successor protocol to Secure Sockets Layer (SSL). Although the Oracle configuration parameters have names including "SSL", such as SSL_VERSION and SSL_CIPHER_SUITES, they refer to TLS.
V-270567CAT IIOracle Database must map the authenticated identity to the user account using public key infrastructure (PKI)-based authentication.Discussion
Discussion
The DODDoW standard for authentication is DODDoW-approved PKI certificates. Once a PKI certificate has been validated, it must be mapped to a database management system (DBMS) user account for the authenticated identity to be meaningful to the DBMS and useful for authorization decisions.
V-270568CAT IWhen using command-line tools such as Oracle SQL*Plus, which can accept a plain-text password, users must use an alternative logon method that does not expose the password.Discussion
Discussion
The DODDoW standard for authentication is DODDoW-approved public key infrastructure (PKI) certificates.
Normally, with PKI authentication, the interaction with the user for authentication will be handled by a software component separate from the database management system (DBMS), such as ActivIdentity ActivClient. However, in cases where the DBMS controls the interaction, this requirement applies.
To prevent the compromise of authentication information such as passwords and PINs during the authentication process, the feedback from the system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism.
Obfuscation of user-provided authentication secrets when typed into the system is a method used in addressing this risk.
Displaying asterisks when a user types in a password or a smart card PIN is an example of obscuring feedback of authentication secrets.
This requires reviewing applications, which will involve collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.
V-270574CAT IOracle Database must take steps to protect data at rest and ensure confidentiality and integrity of application data.Check text, Discussion
Check text
Review system documentation to determine whether the system handles classified information. If the system does not handle classified information, the severity of this check is downgraded to CAT II.
If the application owner and authorizing official (AO) have determined that encryption of data at rest is required, verify the data on secondary devices is encrypted.
If full-disk encryption is being used, this is not a finding.
If data encryption is required, verify that the data is encrypted before being put on the secondary device. To ensure that the appropriate controls are in place, discuss the precautions taken with the site database administrators (DBAs) and system administrators (SAs) and try to modify data at rest.
OracleThe recommends using Transparent Data Encryption, which is part of Oracle Advanced Security Option, to protect data.
To verify the data is encrypted, upon an auditor's request, Oracle provides views that document the encryption status of the database. For TDE column encryption, use the view "dba_encrypted_columns", which lists the owner, table name, column name, encryption algorithm, and salt for all encrypted columns. For TDE tablespace encryption, the following SQL statement lists all encrypted tablespaces with their encryption algorithm and corresponding,whether encrypted,not datathey files.are Issue the following commands to verify the data at rest is encrypted.:
$ sqlplus connect as sysdba
SQL> SELECT t.name "TSName"TABLESPACE_NAME,
e.encryptionalg "Algorithm",ENCRYPTED
d.file_name "File Name"
FROM v$tablespace t,DBA_TABLESPACES
v$encrypted_tablespaces e,
dba_data_files d
WHERE t.ts#CONTENTS =NOT e.ts#
andIN t.name = d.tablespace_name;
The next SQL statement lists the table owner('TEMPORARY', tables within encrypted tablespaces, and the encryption algorithm:'UNDO')
SQL>AND SELECTTABLESPACE_NAME a.ownerNOT "Owner",
a.table_nameIN "Table Name",
e.encryptionalg "Algorithm"
FROM dba_tables a,
v$encrypted_tablespaces e
WHERE a.tablespace_name in (select t.name from v$tablespace t'SYSTEM', v$encrypted_tablespaces e where t.ts# = e.ts#'SYSAUX');
For each databasetablespace where encryption is required, verify that encryption is in effect. If it is not, this is a finding.
Discussion
This control is intended to address the confidentiality and integrity of information at rest in nonmobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Applications and application users generate information throughout the course of their application use. User-generated data and application-specific configuration data must be protected. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention systems, and filtering routers and authenticator content are examples of system information likely requiring protection. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate. If the confidentiality and integrity of application data is not protected, the data will be open to compromise and unauthorized modification. Oracle recommends using Transparent Data Encryption, which is part of Oracle Advanced Security Option, to protect data.
V-270575CAT IOracle Database must implement cryptographic mechanisms to prevent unauthorized modification of organization-defined information at rest (to include, at a minimum, PII and classified information) on organization-defined information system components.Severity
V-270579CAT IOracle Database must employ cryptographic mechanisms preventing the unauthorized disclosure of information during transmission unless the transmitted data is otherwise protected by alternative physical measures.Discussion
Discussion
Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism to protect the information during transmission. This is usually achieved using Transport Layer Security (TLS), secure sockets layer (SSL) virtual private network (VPN), or IPsec tunnel.
Alternative physical protection measures include Protected Distribution Systems (PDS). PDS are used to transmit unencrypted classified NSI through an area of lesser classification or control. Inasmuch as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic, and physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for additional details on a PDS.
Information in transmission is particularly vulnerable to attack. If the database management system (DBMS) does not employ cryptographic mechanisms preventing unauthorized disclosure of information during transit, the information may be compromised.
SHA-1 is in the process of being removed from service within the DODDoW and its use is to be limited during the transition to SHA-2. Use of SHA-1 for digital signature generation is prohibited. Allowable uses during the transition include CHECKSUM usage and verification of legacy certificate signatures. SHA-1 is considered a temporary solution during legacy application transitionary periods and should not be engineered into new applications. SHA-2 is the path forward for DODDoW.
V-270587CAT IIOracle Database must, for password-based authentication, verify that when users create or update passwords, the passwords are not found on the list of commonly used, expected, or compromised passwords in IA-5 (1) (a).Fix text
Fix text
If any user accounts are managed by Oracle, develop, test, and implement a password verification function that enforces DODDoW requirements.
Configure the password verify function to verify when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5 (1) (a).
Oracle supplies a sample function called ORA12C_STIG_VERIFY_FUNCTION. This can be used as the starting point for a customized function. The script file is found in the following location on the server depending on OS:
Windows:
%ORACLE_HOME%1RDBMS1ADMIN1catpvf.sql
Unix/Linux:
$ORACLE_HOME/rdbms/admin/catpvf.sql
V-275999CAT IIA minimum of three Oracle Control Files must be created and each stored on a separate physical and logical device.Check text
Check text
Use the SQL statement below to obtain information on each currently existing Control File:
SELECT name
FROM sys.v$controlfile
ORDER BY 1;
Oracle Best Practice:
Oracle recommends a minimum of three Oracle Control Files and each stored on a separate physical and logical device (RAID 1 + 0).
DODDoW guidance recommends:
Each control file must be located on a separate physical and logical (virtual) storage device.
Consult with the storage administrator, system administrator, or database administrator to determine whether the mount points or partitions referenced in the file paths indicate separate physical disks or directories on RAID devices.
Note: Distinct does not equal dedicated. May share directory space with other Oracle database instances if present.
If the minimum of three control files is not met, this is a finding.
How these changes are found
Checks are matched across the two releases by V-number. A check counts as updated when DISA gave it a new rule revision (the r number in its SV-…_rule id) and its title, severity, check text, fix text, discussion, CCIs or other fields changed — the same comparison STIG Compare makes. Added checks are new V-numbers; removed checks are V-numbers V1R6 no longer has.
Comparing other releases, or this one against an older release? Pick any two in STIG Compare.