Oracle 10 Database Instance STIG

Checks: C-29158r1_chk

From SQL*Plus: select username from dba_users order by username; Review the list of database account names to determine usage of all non-standard account names or account names that do not appear to be assigned to individuals. For example, accounts named BATCHJOB, FMAPP, FMAPP-ADMIN do not have the appearance of assignment to an individual interactive user. An account name like JDOE appears to be assigned to an individual. Review the list of account names against those listed in the System Security Plan or authorized user list. Consult the IAO or DBA to make a final determination on whether accounts are shared accounts or not. If shared accounts are not documented as such and are not approved, this is a Finding.

Fix: F-26169r1_fix

Use accounts assigned to individual users where feasible. Design applications to provide individual accountability (audit logs) for actions performed under a single database account. Implement other DBMS automated procedures that provide individual accountability. Where appropriate, implement manual procedures to use manual logs and monitor entries against account usage to ensure procedures are followed.

Checks: C-943r1_chk

Review and verify the implementation of an audit trail retention policy. Verify that audit data is maintained for a minimum of one year. If audit data is not maintained for a minimum of one year, this is a Finding.

Fix: F-23728r1_fix

Develop, document and implement an audit retention policy and procedures. It is recommended that the most recent thirty days of audit logs remain available online. After thirty days, the audit logs may be maintained offline. Online maintenance provides for a more timely capability and inclination to investigate suspicious activity.

Checks: C-29170r1_chk

Review procedures for ensuring authorization of new or re-assigned DBMS user accounts. Requests for user account access to the DBMS should include documented approval by an authorized requestor. Procedures should also include notification for a change in status, particularly cause for revocation of account access, to any DBMS accounts. Review the user accounts listed either in the script report or manually against the authorized user list. From SQL*Plus: select username from dba_users order by username; If procedures for DBMS user account authorization are incomplete or not implemented, this is a Finding. If any accounts listed are not clearly authorized, this is a Finding.

Fix: F-26182r1_fix

Develop, document and implement procedures for authorizing creation, changes and deletions of user accounts. Monitor user accounts to verify that they remain authorized.

Checks: C-29408r1_chk

Review the policy and procedures for use of the Oracle default accounts including direct use of the Oracle SYS and SYSTEM accounts with the IAO and DBA. If a policy does not exist for their use, this is a Finding. If procedures, automated or manual, for logging default account use are not defined or implemented, this is a Finding. If monitoring use of default accounts do not exist or is not implemented, this is a Finding.

Fix: F-26435r1_fix

Design, document and implement policy and procedures for use, logging and monitoring of Oracle default accounts in the System Security Plan. Ensure those granted access to the accounts are aware of the accounts and the policies and procedures for them.

Checks:

Fix: F-26443r1_fix

Change the owner of the $AUD table to SYS or SYSTEM account. OR Recreate the audit table while logged in as SYS or SYSTEM.

Checks: C-29419r1_chk

From SQL*Plus: select 'The number of replication objects defined is: '|| count(*) from all_tables where table_name like 'REPCAT%'; If the count returned is 0, then Oracle Replication is not installed and this check is Not a Finding. Otherwise: From SQL*Plus: select count(*) from sys.dba_repcatlog; If the count returned is 0, then Oracle Replication is not in use and this check is Not a Finding. If any results are returned, ask the IAO or DBA if the replication account (the default is REPADMIN, but may be customized) is restricted to IAO-authorized personnel only. If it is not, this is a Finding. If there are multiple replication accounts, confirm that all are justified and documented with the IAO. If they are not, this is a Finding.

Fix: F-26446r1_fix

Change the password for default and custom replication accounts and provide the password to IAO-authorized users only.

Checks: C-29421r1_chk

From SQL*Plus: select instance_name from v$instance; select version from v$instance; If the instance name returned references the Oracle release number, this is a Finding. Numbers used that include version numbers by coincidence are not a Finding. The DBA should be able to relate the significance of the presence of a digit in the SID.

Fix: F-26448r1_fix

Follow the instructions in Oracle MetaLink Note 15390.1 (and related documents) to change the SID for the database without re-creating the database to a value that does not identify the Oracle version.

Checks:

Fix: F-26493r1_fix

Document all authorized connections from the database to remote databases in the System Security Plan. Remove all unauthorized remote database connection definitions from the database. From SQL*Plus: drop database link [link name]; OR drop public database link [link name]; Review remote database connection definitions periodically and confirm their use is still required and authorized.

Checks: C-29438r1_chk

From SQL*Plus: select name from v$controlfile; DoD guidance recommends: 1. A minimum of two distinct control files for each Oracle Database Instance. 2a. Each control file is to be located on separate, archived physical storage devices OR 2b. Each control file is to be located on separate, archived directories within one or more RAID devices 3. The Logical Paths for each control file should differ at the highest level supported by your configuration, for example: UNIX /ora03/app/oracle/{SID}/control/control01.ctl /ora04/app/oracle/{SID}/control/control02.ctl Windows D:/oracle/{SID}/control/control01.ctl E:/oracle/{SID}/control/control02.ctl If this minimum listed above is not met, this is a Finding. Consult with the SA or DBA to determine that 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. You may share directory space with other Oracle database instances if present.

Fix: F-26496r1_fix

To prevent loss of service during disk failure, multiple copies of Oracle control files should be maintained on separate disks in archived directories or on separate, archived directories within one or more RAID devices. Adding or moving a control file requires careful planning and execution. Please consult and follow the instructions for creating control files in the Oracle Database Administrator's Guide, under Steps for Creating New Control Files.

Checks:

Fix: F-26499r1_fix

To define additional redo log file groups: From SQL*Plus (Example): alter database add logfile group 2 ('diska:log2.log' , 'diskb:log2.log') size 50K; To add additional redo log file [members] to an existing redo log file group: From SQL*Plus (Example): alter database add logfile member 'diskc:log2.log' to group 2; Replace diska, diskb, diskc with valid, different disk drive specifications. Replace log#.log file with valid or custom names for the log files.

Checks:

Fix: F-26520r1_fix

Authorize and document all DBA role authorizations in the System Security Plan. Revoke DBA role membership from unauthorized accounts. Revoke DBA role membership from any accounts assigned to a developer job function on a shared production / development database.

Checks:

Fix: F-26524r1_fix

Revoke privileges granted the WITH GRANT OPTION from non-DBA and accounts that do not own application objects. Re-grant privileges without specifying WITH GRANT OPTION.

Checks:

Fix: F-22840r1_fix

Revoking all default installation privilege assignments from PUBLIC is not required at this time. However, execute permissions to the specified packages is required to be revoked from PUBLIC. Removal of these privileges from PUBLIC may result in invalid packages in version 10.1 and later of Oracle and an inability to execute default Oracle applications and utilities. To correct this problem, grant execute privileges on these packages directly to the SYSMAN, WKSYS, MDSYS and SYSTEM accounts as well as any other default Oracle database and custom application object owner accounts as necessary to support execution of applications/utilities installed with an Oracle Database Server. At a minimum, revoke the following: From SQL*Plus: revoke execute on UTL_FILE from PUBLIC; revoke execute on UTL_SMTP from PUBLIC; revoke execute on UTL_TCP from PUBLIC; revoke execute on UTL_HTTP from PUBLIC; revoke execute on DBMS_RANDOM from PUBLIC; revoke execute on DBMS_LOB from PUBLIC; revoke execute on DBMS_SQL from PUBLIC; revoke execute on DBMS_SYS_SQL from PUBLIC; revoke execute on DBMS_JOB from PUBLIC; revoke execute on DBMS_BACKUP_RESTORE from PUBLIC; revoke execute on DBMS_OBFUSCATION_TOOLKIT from PUBLIC;

Checks:

Fix: F-26528r1_fix

Modify profiles to meet the idle time requirement. From SQL*Plus: alter profile default limit idle_time 15; alter profile [profile name] limit idle_time [IAO-approved value]; Authorize and document any profiles that require idle times greater than 15 minutes in the System Security Plan.

Checks:

Fix: F-26534r1_fix

Enable SQL92 security. From SQL*Plus: alter system set sql92_security = TRUE scope = spfile; The above SQL*Plus command will set the parameter to take effect at next system startup.

Checks:

Fix: F-26536r1_fix

Disable use of the remote_login_passwordfile where remote administration is not authorized by specifying a value of NONE. If authorized, restrict use of a password file to exclusive use by each database by specifying a value of EXCLUSIVE. From SQL*Plus: alter system set remote_login_passwordfile = 'EXCLUSIVE' scope = spfile; OR alter system set remote_login_passwordfile = 'NONE' scope = spfile; The above SQL*Plus command will set the parameter to take effect at next system startup.

Checks:

Fix: F-26539r1_fix

Revoke assignment of privileges with the WITH ADMIN OPTION from unauthorized users and re-grant 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. Restrict use of the WITH ADMIN OPTION to authorized administrators. Document authorized privilege assignments with the WITH ADMIN OPTION in the System Security Plan.

Checks:

Fix: F-27119r1_fix

The only application objects auditing required is for use of the RENAME privilege on database objects. Configure auditing on RENAME privilege use by default for newly created objects. From SQL*Plus: audit rename on default by access; If application objects have already been created, the audit rename on object statement should be issued for all application objects. From SQL*Plus: audit rename on [application object name] by access; Enable auditing of access and activity on audit trail data stored in the database. From SQL*Plus: audit update, delete on AUD$ by access; NOTE: The audit table is by default in the SYSTEM schema, but may have been moved to another schema.

Checks:

Fix: F-26542r1_fix

Revoke any system privileges assigned to PUBLIC: From SQL*Plus: revoke [system privilege] from 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.

Checks:

Fix: F-26546r1_fix

Revoke assignment of roles with the WITH ADMIN OPTION from unauthorized grantees and re-grant them without the option if required. From SQL*Plus: revoke [role name] from [grantee]; grant [role name] to [grantee]; Restrict use of the WITH ADMIN OPTION to authorized administrators. Document authorized role assignments with the WITH ADMIN OPTION in the System Security Plan.

Checks:

Fix: F-26550r1_fix

Revoke any privileges granted to PUBLIC for objects that are not owned by Oracle product accounts. From SQL*Plus: revoke [privilege name] from [user name] on [object name]; Assign permissions to custom application user roles based on job functions: From SQL*Plus: grant [privilege name] to [user role] on [object name];

Checks:

Fix: F-26552r1_fix

Enable resource limit checking on the database. From SQL*Plus: alter system set resource_limit = TRUE scope = both; The above SQL*Plus command will set the parameter to take effect immediately and permanently at next system startup.

Checks:

Fix: F-26509r1_fix

Revoke role grants from PUBLIC. Do not assign role privileges to PUBLIC. From SQL*Plus: revoke [role name] from PUBLIC;

Checks:

Fix: F-26512r1_fix

For each role assignment returned, issue: From SQL*Plus: alter user [username] default role all except [role]; If the user has more than one application administration role assigned, then you will have to remove assigned roles from default assignment and assign individually the appropriate default roles.

Checks:

Fix: F-26514r1_fix

Document and justify system privileges assigned to users/roles in the System Security Plan and authorize with the IAO. Remove unauthorized or unjustified system privileges from user accounts or roles. From SQL*Plus: revoke [privilege] from [user or role name]; Replace [privilege] with the named privilege and [user or role name] with the identified user or role.

Checks: C-26709r1_chk

If user access to the DBMS is via a portal or mid-tier system or product and PKI-authentication occurs at the portal/mid-tier, this check is Not a Finding. Review the list of all DBMS accounts and their authentication methods. This list is usually available from a system view or table and is easily gained from a simple SQL query. If any accounts are listed with an authentication method other than a PKI certificate, this is a Finding. For MAC 3 systems, if identification and authentication is not accomplished using the DoD PKI Class 3 certificate and hardware security token (when available) at minimum, this is a Finding. For MAC 1 and 2 systems, if identification and authentication is not accomplished using the DoD PKI Class 3 or 4 certificate and hardware security token (when available) or an NSA-certified product at minimum, this is a Finding.

Fix: F-22885r1_fix

Implement PKI authentication for all accounts defined within the database where applicable. Applications may use host system (server) certificates to authenticate. For MAC 3 systems, use of the DoD PKI Class 3 certificate and hardware security token (when available) at minimum is required. For MAC 1 and 2 systems, use of the DoD PKI Class 3 or 4 certificate and hardware security token (when available) or an NSA-certified product at minimum is required.

Checks:

Fix: F-25980r1_fix

Define and apply a password_verify_function for all profiles where passwords are used to authenticate accounts. See Fix information for DG0079 to create a password_verify_function that meets STIG requirements.

Checks:

Fix: F-26185r1_fix

Modify profiles to meet the failed login attempt requirement limit. From SQL*Plus: alter profile default limit failed_login_attempts 3; alter profile [profile name] limit failed_login_attempts [IAO-approved value]; Replace [profile name] with any existing, non-default profile names. Document in the System Security Plan all profiles and settings.

Checks:

Fix: F-2565r1_fix

Document all remote or external interfaces used by the DBMS to connect to or allow connections from remote or external sources. Include with the documentation as appropriate, any network ports or protocols, security accounts, and the sensitivity of any data exchanged. Do not define or configure database links between production databases and test or development databases.

Checks: C-28651r1_chk

If the database being reviewed is not a production database, this check is Not a Finding. Review policy, procedures and restrictions for data imports of production data containing sensitive information into development databases. If data imports of production data are allowed, review procedures for protecting any sensitive data included in production exports. If sensitive data is included in the exports and no procedures are in place to remove or modify the data to render it not sensitive prior to import into a development database or policy and procedures are not in place to ensure authorization of development personnel to access sensitive information contained in production data, this is a Finding.

Fix: F-25678r1_fix

Develop, document and implement policy, procedures and restrictions for production data import. Require any users assigned privileges that allow the export of production data from the database to acknowledge understanding of import policies, procedures and restrictions. Restrict permissions of development personnel requiring use or access to production data imported into development databases containing sensitive information to authorized users. Implement policy and procedures to modify or remove sensitive information in production exports prior to import into development databases.

Checks:

Fix: F-25684r1_fix

Develop, document and implement procedures to review and maintain privileges granted to developers on shared production and development host systems and databases. Recommend establishing a dedicated DBMS host for production DBMS installations (See Checks DG0109 and DG0110). A dedicated host system in this case refers to an instance of the operating system at a minimum. The operating system may reside on a virtual host machine where supported by the DBMS vendor.

Checks: C-1184r1_chk

Review policy, procedures and implementation evidence to determine if periodic reviews of user privileges by the IAO are being performed. Evidence may consist of email or other correspondence that acknowledges receipt of periodic reports and notification of review between the DBA and IAO or other auditors as assigned. If policy and procedures are incomplete or no evidence of implementation exists, this is a Finding.

Fix: F-2582r1_fix

Develop, document and implement policy and procedures for periodic review of database user accounts and privilege assignments. Include methods to provide evidence of review in the procedures to verify reviews occur in accordance with the procedures.

Checks:

Fix: F-26439r1_fix

Create and dedicate tablespaces to support only one application. Do not share tablespaces between applications. Do not grant quotas to application object owners on tablespaces not dedicated to their associated application. From SQL*Plus: alter user [username] default tablespace [tablespace_name] temporary tablespace TEMP; Replace [username] with the named user account. Replace [tablespace_name] with the new default tablespace name.

Checks:

Fix: F-26452r1_fix

Create and assign dedicated tablespaces for the storage of data by each application using the CREATE TABLESPACE command.

Checks: C-26537r1_chk

From SQL*Plus: select value from v$parameter where name = 'audit_trail'; select value from v$parameter where name = 'audit_file_dest'; If audit_trail is NOT set to TRUE, OS, XML or XML, EXTENDED per MetaLink Note 30690.1, this check is Not a Finding. On UNIX Systems: ls -ld [pathname] Substitute [pathname] with the directory path listed from the above SQL command for audit_file_dest. If permissions are granted for world access, this is a Finding. If any groups that include members other than the Oracle process and software owner accounts, DBAs, auditors, or backup accounts are listed, this is a Finding. On Windows Systems (From Windows Explorer): Browse to the directory specified. Select and right-click on the directory, select Properties, select the Security tab. On Windows hosts, records are also written to the Windows application event log. The location of the application event log is listed under Properties for the log under the Windows console. The default location is C:\WINDOWS\system32\config\EventLogs\AppEvent.Evt. If permissions are granted to everyone, this is a Finding. If any accounts other than the Administrators, DBAs, System group, auditors or backup operators are listed, this is a Finding.

Fix: F-26454r1_fix

Alter host system permissions to the AUDIT_FILE_DEST directory to the Oracle process and software owner accounts, DBAs, backup accounts, SAs (if required) and auditors. Authorize and document user access requirements to the directory outside of the Oracle, DBA and SA account list in the System Security Plan.

Checks: C-29427r1_chk

From SQL*Plus: select value from v$parameter where name='user_dump_dest'; On UNIX systems: ls -ld [pathname] Substitute [pathname] with the directory path listed from the above SQL command. If permissions are granted for world access, this is a Finding. On Windows Systems (From Windows Explorer): Browse to the directory specified. Select and right-click on the directory, select Properties, select the Security tab. If permissions are granted to everyone, this is a Finding. If any account other than the Oracle process and software owner accounts, Administrators, DBAs, System group or developers authorized to write and debug applications on this database are listed, this is a Finding.

Fix: F-26456r1_fix

Alter host system permissions to the USER_DUMP_DEST directory to the Oracle process and software owner accounts, DBAs, SAs if required, and developers or other users that may specifically require access for debugging or other purposes. Authorize and document user access requirements to the directory outside of the Oracle, DBA and SA account list in the System Security Plan.

Checks: C-29428r1_chk

From SQL*Plus: select value from v$parameter where name = 'background_dump_dest'; On UNIX Systems: ls -ld [pathname] Substitute [pathname] with the directory path listed from the above SQL command. If permissions are granted for world access, this is a Finding. On Windows Systems (From Windows Explorer): Browse to the directory specified. Select and right-click on the directory, select Properties, select the Security tab. If permissions are granted to everyone, this is a Finding. If any account other than the Oracle process and software owner accounts, Administrators, DBAs, System group or developers authorized to write and debug applications on this database are listed, this is a Finding.

Fix: F-26457r1_fix

Alter host system permissions to the BACKGROUND_DUMP_DEST directory to the Oracle process and software owner accounts DBAs, SAs if required, and developers or other users that may specifically require access for debugging or other purposes. Authorize and document user access requirements to the directory outside of the Oracle, DBA and SA account list in the System Security Plan.

Checks: C-29429r1_chk

From SQL*Plus: select value from v$parameter where name = 'core_dump_dest'; If no value is listed, then Oracle defaults to the $ORACLE_HOME/dbs directory (UNIX) or %ORACLE_HOME%\database directory (Windows) for storing core dumps. On UNIX Systems: ls -ld [pathname] Substitute [pathname] with the directory path listed from the above SQL command. If permissions are granted for world access, this is a Finding. On Windows Systems (From Windows Explorer): Browse to the directory specified. Select and right-click on the directory, select Properties, select the Security tab. If permissions are granted to everyone, this is a Finding. If any account other than the Oracle process and software owner accounts, Administrators, DBAs, System group or developers authorized to write and debug applications on this database are listed, this is a Finding.

Fix: F-26458r1_fix

Alter host system permissions to the CORE_DUMP_DEST directory to the Oracle process and software owner accounts, DBAs, SAs (if required) and developers or other users that may specifically require access for debugging or other purposes. Authorize and document user access requirements to the directory outside of the Oracle, DBA and SA account list in the System Security Plan.

Checks: C-29430r1_chk

From SQL*Plus: select log_mode from v$database; select value from v$parameter where name = 'log_archive_dest'; select value from v$parameter where name = 'log_archive_duplex_dest'; select name, value from v$parameter where name LIKE 'log_archive_dest_%'; If the value returned for LOG_MODE is NOARCHIVELOG, this check is Not a Finding. If a value is not returned for LOG_ARCHIVE_DEST and no values are returned for any of the LOG_ARCHIVE_DEST_[1-10] parameters, this is a Finding. NOTE: LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST are incompatible with the LOG_ARCHIVE_DEST_n parameters, and must be defined as the null string (' ') when any LOG_ARCHIVE_DEST_n parameter has a value other than a null string. On UNIX Systems: ls -ld [pathname] Substitute [pathname] with the directory paths listed from the above SQL statements for log_archive_dest and log_archive_duplex_dest. If permissions are granted for world access, this is a Finding. On Windows Systems (From Windows Explorer): Browse to the directory specified. Select and right-click on the directory, select Properties, select the Security tab. If permissions are granted to everyone, this is a Finding. If any account other than the Oracle process and software owner accounts, Administrators, DBAs, System group or developers authorized to write and debug applications on this database are listed, this is a Finding.

Fix: F-26459r1_fix

Specify a valid and protected directory for archive log files. Restrict access to the Oracle process and software owner accounts, DBAs, and backup operator accounts.

Checks:

Fix: F-26466r1_fix

From SQL*Plus (shutdown database instance): shutdown immediate From SQL*Plus (create a pfile from spfile): create pfile='[PATH]init[SID].ora' from spfile; Edit the init[SID].ora file and remove the following line: *._trace_files_public=TRUE From SQL*Plus (update the spfile using the pfile): create spfile from pfile='[PATH]init[SID].ora'; From SQL*Plus (start the database instance): startup NOTE: [PATH] depends on the platform (Windows or UNIX). Ensure the file is directed to a writable location. [SID] is equal to the oracle SID or database instance ID.

Checks:

Fix: F-2539r1_fix

Disable any application object owner accounts. From SQL*Plus: alter user [username] account lock; Enable application object owner accounts only for installation and maintenance. DBA are special purpose accounts and do not require disabling although they may own objects. For application objects that require routine maintenance, e.g. index objects, to maintain performance, consider allowing a special purpose account to own the index or enable the application owner account for the duration of the routine maintenance function only.

Checks:

Fix: F-22676r1_fix

Enable database auditing. Select the desired audit trail format (external file or internal database table). From SQL*Plus: alter system set audit_trail= [audit trail format] scope=spfile; Compliant selections for [audit trail format] are (per MetaLink Note 30690.1): Oracle 10.1 – 10.2 = 'true', 'os' & 'db' (true = os for backward compatibility) Oracle 10.1 = 'db_extended' Oracle 10.2 = 'db, extended', 'xml' & 'xml, extended' The above SQL*Plus command will set the parameter to take effect at next system startup.

Checks:

Fix: F-2551r1_fix

Document and authorize accounts granted access to the AUD$ table in the System Security Plan. Revoke access permissions granted to the AUD$ table from unauthorized users.

Checks: C-1089r1_chk

Compare privileges assigned to database application user roles to those defined in the System Security Plan. If the assigned privileges do not match the authorized list of privileges, this is a Finding.

Fix: F-2557r1_fix

Use the grant and revoke commands to assign the authorized privileges as listed in the System Security Plan to custom database application or application user roles.

Checks: C-29175r1_chk

Review procedures and implementation for monitoring the DBMS for account expiration and account inactivity. Verify implemented procedures are in place to address expired/locked accounts not required for system/application operation are authorized to remain and are documented. Verify implemented procedures are in place to address accounts that are unlocked and have been inactive in excess of 30 days are authorized to remain unlocked. Verify implemented procedures are in place to address unauthorized, inactive accounts after 30 days are expired and locked. Verify implemented procedures are in place to address expired/locked accounts that are not authorized to remain are dropped/removed/deleted. A finding for this check would be based on insufficient documentation and implemented procedures for monitoring DBMS accounts.

Fix: F-26186r1_fix

Develop, document and implement procedures to monitor database accounts for inactivity and account expiration. Investigate and re-authorize or delete [if appropriate] any accounts that are expired or have been inactive for more than 30 days. Where appropriate, protect authorized expired or inactive accounts by disabling them or applying some other similar protection. NOTE: Password and account requirements have changed for DoD since this STIG requirement was published.

Checks: C-1128r1_chk

If the application does not require auditing using DBMS features, this check is Not Applicable. Review the application System Security Plan for requirements for database configuration for auditing changes to application data. If the application requires DBMS auditing for changes to data, review the database audit configuration against the application requirement. If the auditing does not comply with the requirement, this is a Finding. Review policy and procedures for reviewing access and changes to data. If policy and procedures are not in place, this is a Finding. If access and changes to data are not periodically reviewed or immediately reviewed on system security events, this is a Finding. If mechanisms are not in place to notify users of time and date of the last change in data content, this is a Finding.

Fix: F-2547r1_fix

Configure database data auditing to comply with the requirements of the application. Document auditing requirements in the System Security Plan. Develop, document and implement policy and procedures for reviewing access and changes to data periodically or immediately upon system security events. Develop, document and implement mechanisms to notify users of time and date of the last change in data content.

Checks: C-29382r1_chk

If Asymmetric keys are present and Oracle Advanced Security is not installed and operational on the DBMS host, this is a Finding. For each asymmetric key identified as being used to encrypt sensitive data, verify the key owner is an application object owner or other non-DBA account. If the key owner listed is a DBA, this is a Finding. If any key owner is not the application object owner account or an account specific to the application as documented in the System Security Plan, this is a Finding. If any asymmetric keys whose private key is not encrypted exist in the database, this is a Finding. Review the access permissions to asymmetric keys. Verify that any permission granted is authorized in the System Security Plan for access to the key. Examine evidence that an audit record is created whenever the asymmetric key is accessed by other than authorized users. In particular, view evidence that access by a DBA or other system privileged account results in the generation of an audit record. This is required because system privileges that allow access to encryption keys may be used to access sensitive data where the privileged user does not have a job function need-to-know the data. If an audit record is not generated for unauthorized access to the asymmetric key, this is a Finding.

Fix: F-26407r1_fix

Use DoD code-signing certificates to create asymmetric keys stored in the database that are used to encrypt sensitive data stored in the database. Assign the application object owner account as the owner of asymmetric keys used by the application. Create audit events for access to the key by other than the application owner account or approved application objects. Revoke any privileges assigned to the asymmetric key to other than the application object owner account and authorized users. Protect the private key by encrypting it with the database system master key where available. Where available, store encryption keys and certificates on hardware security modules (HSM). Oracle Advanced Security is required to provide asymmetric key management features.

Checks:

Fix: F-26192r1_fix

Create or use a password verify function that enforces password complexity. See a sample below that meets DoD requirements. Modify profiles to specify the password verify function created. From SQL*Plus: Rem This script was modified from the Oracle utlpwdmg.sql default script. Rem -- This script sets the default password resource parameters. -- This script needs to be run to enable the password features. -- However, the default resource parameters can be changed based on the need. -- A default password complexity function is also provided. -- This function makes the minimum complexity checks like the minimum -- length of the password, password not same as the username, etc. The user may -- enhance this function according to the need. -- This function must be created in SYS schema: -- connect sys/<password> as sysdba before running the script CREATE OR REPLACE FUNCTION verify_password_dod (username varchar2, password varchar2, old_password varchar2) RETURN boolean IS n boolean; m integer; differ integer; isdigit boolean; numdigit integer; ispunct boolean; numpunct integer; islowchar boolean; numlowchar integer; isupchar boolean; numupchar integer; digitarray varchar2(10); punctarray varchar2(25); lowchararray varchar2(26); upchararray varchar2(26); pw_change_time date; BEGIN digitarray:='0123456789'; lowchararray:='abcdefghijklmnopqrstuvwxyz'; upchararray:='ABCDEFGHIJKLMNOPQRSTUVWXYZ'; punctarray:='@!"#$%&()``*+,-/:;<=>?_'; -- Check if the password is same as the username if nls_lower(password)=nls_lower(username) then raise_application_error(-20001, 'Password same as or similar to user'); end if; -- Check for the minimum length of the password if length(password) < 15 then raise_application_error(-20002, 'Password length less than 15'); end if; -- Check if the password is too simple. A dictionary of words may be maintained -- and a check may be made so as not to allow the words that are too simple for -- the password. if nls_lower(password) in ('welcome','database','account','user','password','oracle','computer','abcdefgh', '12345') then raise_application_error(-20002, 'Password too simple'); end if; -- Check if the password contains at least two each of the following: -- uppercase characters, lowercase characters, digits and special characters. -- 1. Check for the digits isdigit:=FALSE; numdigit:=0; m:=length(password); for i in 1..10 loop for j in 1..m loop if substr(password,j,1)=substr(digitarray,i,1) then numdigit:=numdigit + 1; end if; if numdigit > 1 then isdigit:=TRUE; goto findlowchar; end if; end loop; end loop; if isdigit=FALSE then raise_application_error(-20003, 'Password should contain at least two digits'); end if; -- 2. Check for the lowercase characters <<findlowchar>> islowchar:=FALSE; numlowchar:=0; m:=length(password); for i in 1..length(lowchararray) loop for j in 1..m loop if substr(password,j,1)=substr(lowchararray,i,1) then numlowchar:=numlowchar + 1; end if; if numlowchar > 1 then islowchar:=TRUE; goto findupchar; end if; end loop; end loop; if islowchar=FALSE then raise_application_error(-20003, 'Password should contain at least two lowercase characters'); end if; -- 3. Check for the UPPERCASE characters <<findupchar>> isupchar:=FALSE; numupchar:=0; m:=length(password); for i in 1..length(upchararray) loop for j in 1..m loop if substr(password,j,1)=substr(upchararray,i,1) then numupchar:=numupchar + 1; end if; if numupchar > 1 then isupchar:=TRUE; goto findpunct; end if; end loop; end loop; if isupchar=FALSE then raise_application_error(-20003, 'Password should contain at least two uppercase characters'); end if; -- 4. Check for the punctuation <<findpunct>> ispunct:=FALSE; numpunct:=0; m:=length(password); for i in 1..length(punctarray) loop for j in 1..m loop if substr(password,j,1)=substr(punctarray,i,1) then numpunct:=numpunct + 1; end if; if numpunct > 1 then ispunct:=TRUE; goto endsearch; end if; end loop; end loop; if ispunct=FALSE then raise_application_error(-20003, 'Password should contain at least two punctuation characters'); end if; -- Check if the password differs from the previous password -- by more than 4 characters <<endsearch>> if old_password is not null then differ:=length(old_password) - length(password); if abs(differ) < 4 then if length(password) < length(old_password) then m:=length(password); else m:=length(old_password); end if; differ:=abs(differ); for i in 1..m loop if substr(password,i,1) != substr(old_password,i,1) then differ:=differ + 1; end if; end loop; if differ < 4 then raise_application_error(-20004, 'Password should differ by more than 4 characters'); end if; end if; end if; -- Everything is fine. return TRUE RETURN(TRUE); EXCEPTION WHEN OTHERS THEN raise_application_error(-20000,'verify_password_dod: Unexpected error: '||SQLERRM,TRUE); END; / alter profile default limit password_verify_function verify_password_dod; NOTE: Password and account requirements have changed for DoD since the STIG requirement listed in the table for this check was published.

Checks:

Fix: F-26381r1_fix

Assign a password lifetime of 60 days or less to the default database profile. Assign a password lifetime of 60 days or less to non-default profiles assigned to interactive database accounts. Assign as password lifetime of 365 days or less to non-default profiles assigned to non-interactive database accounts that do not support frequent password changes. Include a list of all database accounts and their profile assignments in the System Security Plan. Modify profiles to assign a password lifetime. From SQL*Plus: alter profile default limit password_life_time 60; alter profile [profile name] limit password_life_time [60 to 365]; Replace [profile name] with any existing, non-default profile name and [60 to 365] with a value between 60 and 365 (days) inclusive.

Checks: C-939r1_chk

Review the list of defined database links generated from the DBMS. Compare to the list in the System Security Plan with the DBA. If no database links are listed in the database and in the System Security Plan, this check is Not a Finding. If any database links are defined in the DBMS, verify the authorization for the definition in the System Security Plan. If any database links exist that are not authorized or not listed in the System Security Plan, this is a Finding.

Fix: F-21332r1_fix

Grant access to database links to authorized users or applications only. Document all database links access authorizations in the System Security Plan.

Checks:

Fix: F-2543r1_fix

Document all authorized application object owner accounts. Use only authorized application object owner accounts to install and maintain application database objects. Revoke privileges to create, drop, replace or alter application objects from unauthorized application object owners.

Checks:

Fix: F-2544r1_fix

For the sample applications and schemas with the Oracle database installation, use the provided SQL scripts (if present) to remove the application objects and drop the demo users and schemas: From SQL*Plus: -- Human Resources application: @?/demo/schema/human_resources.hr_drop.sql -- Order Entry application: @?/demo/schema/order_entry/oe_drop.sql and oc_drop.sql -- Product Media application: @?/demo/schema/product_media/pm_drop.sql -- Information Exchange application: @?/demo/schema/information_exchange/ix_drop.sql -- Sales History application: @?/demo/schema/sales_history/sh_drop.sql For other demo applications, deinstall using the SQL command: drop user [demo username] cascade;

Checks: C-1071r1_chk

Review DBMS account names against the list of authorized DBMS accounts in the System Security Plan. If any accounts indicate use by mulitiple persons that are not mapped to a specific person, this is a Finding. If any applications or processes share an account that could be assigned an individual account or are not specified as requiring a shared account, this is a Finding. Note: Privileged installation accounts may be required to be accessed by DBA or other administrators for system maintenance. In these cases, each use of the account must be logged in some manner to assign accountability for any actions taken during the use of the account.

Fix: F-2542r1_fix

Create individual accounts for each user, application, or other process that requires a database connection. Document any accounts that are shared where separation is not supported by the application or for maintenance support. Design, develop and implement a method to log use of any account to which more than one person has access. Restrict interactive access to shared accounts to the fewest persons possible.

Checks:

Fix: F-2584r1_fix

If a REMOTE_LOGIN_PASSWORDFILE is in use (='EXCLUSIVE'), list database accounts assigned SYSDBA and SYSOPER database privileges and review for appropriate authorization. Document authorized SYSDBA and SYSOPER users in the System Security Plan. From SQL*Plus: select * from v$pwfile_users; To revoke SYSDBA or SYSOPER from accounts: From SQL*Plus: revoke sysdba from [username]; revoke sysoper from [username];

Checks: C-914r1_chk

From SQL*Plus: select value from v$parameter where name='utl_file_dir'; If the returned value contains '*', this is a Finding.

Fix: F-2592r1_fix

Where its use is authorized, restrict access by a database session to external host files. From SQL*Plus: alter system set utl_file_dir=[authorized directory] scope=spfile; Replace [authorized directory] with the directory path where file access and storage is authorized. Review Oracle MetaLink Note 39037.1 if you need to define multiple authorized directories. The above SQL*Plus command will set the parameter to take effect at next system startup.

Checks: C-24308r1_chk

If a review of the System Security Plan confirms the use of replication is not required, not permitted and the database is not configured for replication, this check is Not a Finding. If any replication accounts are assigned DBA roles or roles with DBA privileges, this is a Finding.

Fix: F-20461r1_fix

Restrict privileges assigned to replication accounts to the fewest possible privileges. Remove DBA roles from replication accounts. Create and use custom replication accounts assigned least privileges for supporting replication operations.

Checks: C-946r1_chk

From SQL*Plus: select file_name from dba_data_files where tablespace_name='SYSTEM'; NOTE: Data files for a given database instance may include data files (*.dbf), REDO log files (redo*.log) and CONTROL files (*.ctl). Review the files in the directory shown above. Allowable files are instance database files (*.dbf), REDO log files (redo*.log) and CONTROL files (*.ctl). If any files other than these exist in the directory, this is a Finding. A good best practice (not consistently endorsed by the Oracle community) is on database creation, using separate subdirectories for data, redo and control files [under the instance name directory] instead of using a single directory to contain all Oracle data, redo and control instance files.

Fix: F-2621r1_fix

Create a dedicated directory or dedicated subdirectories to store database instance files. Reconfigure the Oracle instance to point to the files in the new locations. Where feasible, locate database instance files on a dedicated disk partition and/or RAID device to provide additional protection.

Checks: C-1114r1_chk

Review application database tables and their database file assignments. If application database tables from unrelated applications are stored in the same database data files, this is a Finding.

Fix: F-2571r1_fix

Relocate application database tables to distinct database data files where supported by the DBMS.

Checks:

Fix: F-3781r1_fix

Create custom roles for each discrete application user / administrator function required for your database and assign the minimum privileges necessary to perform the function. Assign custom roles to accounts. Revoke assignment of predefined roles from accounts where not documented in the System Security Plan and authorized by the IAO.

Checks:

Fix: F-3785r1_fix

Revoke assigned administrative privileges from database accounts and assign to accounts via roles. Document roles and assignments in the System Security Plan.

Checks:

Fix: F-3787r1_fix

Revoke ALTER, REFERENCES, and INDEX privileges from application user roles. From SQL*Plus: revoke [privilege] from [application user role]; Replace [privilege] with the identified ALTER, REFERENCES or INDEX privilege and [application user role] with the identified application role.

Checks:

Fix: F-3791r1_fix

Revoke privileges assigned directly to database accounts and assign them to roles based on job functions. Assign users who are assigned responsibility for the job function to the defined role. From SQL*Plus: revoke [privilege] on [object name] from [user name]; grant [privilege] on [object name] to [role name];

Checks: C-1003r1_chk

Review file permissions defined for critical files. Review the file permissions on the Binary initialization parameter file (the default name is spfile[SID].ora). Binary initialization parameter files are by default located in the $ORACLE_HOME/dbs directory (UNIX) or %ORACLE_HOME%\database directory (Windows). From SQL*Plus: select value from v$parameter where name = 'spfile'; select member from v$logfile; select name from v$datafile; select name from v$controlfile; Check directory and file permissions for the files returned by the SQL commands above, for the files located in the $ORACLE_HOME/network/admin directory (UNIX) or %ORACLE_HOME%\network\admin directory (Windows) and the directory specified by the TNS_ADMIN environment variable, if defined. On UNIX systems: ls –ld [pathname] If permissions are granted for world access, this is a Finding. If any groups that include members other than the Oracle process and software owner accounts, DBAs, auditors, or backup accounts are listed, this is a Finding. On Windows Systems (From Windows Explorer): Browse to the directory specified. Select and right-click on the directory, select Properties, select the Security tab. If permissions are granted to everyone, this is a Finding. If any accounts other than the Oracle process and software owner accounts, Administrators, DBAs, System groups, auditors, or backup accounts are listed, this is a Finding.

Fix: F-3793r1_fix

Set UNIX permissions on critical files to 640 or more restrictive. Check group membership of the group assigned access permissions to the database software to verify all members are authorized to have the assigned access. Set Windows permissions to Full Control assigned to the Administrators, the Oracle service account and DBAs. Remove any unauthorized account access.

Checks:

Fix: F-26379r1_fix

Revoke unauthorized access to system tables and data. From SQL*Plus: revoke [object privilege] on [system object name] from [account name or role];

Checks: C-1189r1_chk

Review objects owned by custom DBA user accounts. If any objects owned by DBA accounts are accessed by non-DBA users either directly or indirectly by other applications, this is a Finding. Review documentation or instructions provided to DBAs to communicate proper and improper use of DBA accounts. If such documentation does not exist or if DBAs do not indicate an understanding of this requirement, this is a Finding.

Fix: F-2620r1_fix

Develop, document and implement policy and procedures for outlining the proper and improper use of DBA accounts. The documentation should clearly state that DBA accounts are used to administer and maintain the database only. DBA accounts are not to be used to create or alter application objects. Application maintenance should always be performed by the application object owner or application administrator accounts. Request acknowledgement of receipt of these restrictions by all users granted DBA responsibilities.

Checks:

Fix: F-26383r1_fix

Configure the DBMS to prevent password reuse by modifying Oracle profiles: From SQL*Plus: alter profile default limit password_reuse_max 10 password_reuse_time UNLIMITED; alter profile [profile name] limit password_reuse_max default password_reuse_time default; Replace [profile name] with any existing, non-default profile names. Where Host Authentication is used, configure the OS to prevent password reuse. Consider configuring the DBMS to use alternate authentication methods other than password authentication where supported by the DBMS.

Checks: C-29359r1_chk

If no DBMS accounts authenticate using passwords (rare), this check is Not a Finding. Confirm that database profiles specify a password verify function. From SQL*Plus: select distinct limit from dba_profiles where resource_name= 'PASSWORD_VERIFY_FUNCTION' order by limit; Review the code for the password verify function or have the DBA demonstrate a password change to ensure that the function does not accept passwords that are the same as the username, the name of the database or instance name. If reviewing code, logic similar to the following should be discovered: -- Check if the password is too simple. A dictionary of words may be -- maintained and a check may be made so as not to allow the words -- that are too simple for the password. if nls_lower(password) in ('welcome','database','account','user','password','oracle','computer','abcdefgh', '12345') then raise_application_error(-20002, 'Password too simple'); end if; If any password_verify_function routines do not check for simple passwords, this is a Finding. Check also to ensure all password-authenticated accounts specify a password_verify_function. From SQL*Plus: select distinct profile from dba_profiles where resource_name='PASSWORD_VERIFY_FUNCTION' and (limit is NULL or limit = NULL); If any profiles are returned that are used by password-authenticated accounts, this is a Finding. To view the names of password-authenticated accounts: From SQL*Plus: select name from user$ where password is not NULL;

Fix: F-26385r1_fix

Define and apply a Password Verify Function for all profiles where passwords are used to authenticate accounts. See Fix information for DG0079 to create a Password Verify Function that meets STIG requirements.

Checks: C-29502r1_chk

Ask the DBA to review application source code that is required by Check DG0091 to be encoded or encrypted for database accounts used by applications or batch jobs to access the database. Ask the DBA to review source batch job code prior to compiling, encoding or encrypting for database accounts used by applications or the batch jobs themselves to access the database. Ask the DBA and/or IAO to determine if the compiled, encoded or encrypted application source code or batch jobs contain passwords used for authentication to the database. If none of the identified compiled, encoded or encrypted application source code or batch job code contain passwords used for authentication, this check is Not a Finding. If any of the identified compiled, encoded or encrypted application source code or batch job code do contain passwords used for authentication to the database, this is a Finding. NOTE: This check only applies to application source code or batch job code that is compiled, encoded or encrypted in a production environment. Application source code or batch job code that is not compiled, encoded or encrypted would fall under Check DG0067 for determination of compliance.

Fix: F-2637r1_fix

Design DBMS application code and batch job code that is compiled, encoded or encrypted to NOT contain passwords. Consider alternatives to using password authentication for compiled, encoded or encrypted batch jobs and DBMS application code.

Checks:

Fix: F-26389r1_fix

Set the password_lock_time on all defined profiles to unlimited. This will require the DBA manually to re-enable every locked account after the failed login limit has been reached. From SQL*Plus: alter profile default limit password_lock_time unlimited; alter profile [profile name] limit password_lock_time default; Replace [profile name] with an existing, non-default profile name.

Checks: C-29499r1_chk

If the database does not store or process classified data, or user accounts are prohibited from accessing the database interactively, this check is Not a Finding. NOTE: Per the STIG, The definition of an Interactive Database User can be considered an end-user who accesses the database interactively using tools like SQL*Plus, TOAD, etc. and not through a mid-tier application. Your DAA has the option to consider administration accounts (SYSDBA, SYSOPER, SCHEMA accounts and accounts assigned DBA privileges) as Interactive Database User accounts for the purposes of this check. The definition of an Interactive Database User should be documented in the System Security Plan. Have the DBA perform an interactive logon test (via SQL*Plus) using a non-privileged account (and a privileged account if privileged accounts meet this requirement) to verify display of user access and account usage. If the last successful and number of unsuccessful attempts since the last successful attempt are not reported, this is a Finding.

Fix: F-26570r1_fix

Develop, document and implement an automated method to display at interactive logon the time and date of the last successful login and the number of failed login attempts since the last successful login for users that access the database interactively. This may require a custom-developed logon trigger or procedure to accomplish. NOTE: This may cause interaction/functionality problems with COTS applications not designed for this kind of interaction.

Checks: C-29368r1_chk

If no data is identified as being sensitive or classified by the Information Owner, in the System Security Plan or in the AIS Functional Architecture documentation, this check is Not a Finding. if no identified sensitive or classified data requires encryption by the Information Owner in the System Security Plan and/or AIS Functional Architecture documentation, this check is Not a Finding. Review data access requirements for sensitive data as identified and assigned by the Information Owner in the System Security Plan. Review the access controls for sensitive data configured in the database. If the configured access controls do not match those defined in the System Security Plan, this is a Finding.

Fix: F-26392r1_fix

Define, document and implement all sensitive data access controls based on job function in the System Security Plan.

Checks:

Fix: F-22790r1_fix

There are three (3) types of auditable events: 1) Use of system privileges, 2) Use of object privileges, and 3) Issuance of statements. Activating some auditing options sometimes activates others. For example, the use of a system privilege requires the issuance of a system command. Auditing for use of the privilege also audits for the statement. Configure auditing for Oracle as follows: From SQL*Plus: audit all by access; audit all privileges by access; audit alter java class by access; audit alter java resource by access; audit alter java source by access; audit alter sequence by access; audit alter table by access; audit comment table by access; audit create java class by access; audit create java resource by access; audit create java source by access; audit debug procedure by access; audit drop java class by access; audit drop java resource by access; audit drop java source by access; audit exempt access policy by access; audit exempt identity policy by access; audit grant directory by access; audit grant procedure by access; audit grant sequence by access; audit grant table by access; audit grant type by access; audit sysdba by access; audit sysoper by access; The following SQL statements will disable audits set by the commands above that are not required: noaudit execute library; audit rename on default by access; If application objects have already been created, then the audit rename on object statement should be issued for all application objects. From SQL*Plus: audit rename on [application object name] by access;

Checks:

Fix: F-26395r1_fix

From SQL*Plus: alter system set audit_sys_operations = TRUE scope = spfile; The above SQL*Plus command will set the parameter to take effect at next system startup.

Checks: C-1716r1_chk

Review samples of the DBMS audit logs. Compare to the required elements listed below: - User ID. - Successful and unsuccessful attempts to access security files - Date and time of the event. - Type of event. If the elements listed above are not included in the audit logs at at minimum, this is a Finding.

Fix: F-18329r1_fix

Configure audit settings to include the following list of elements in the audit logs at a minimum: - User ID. - Successful and unsuccessful attempts to access security files - Date and time of the event. - Type of event.

Checks: C-1789r1_chk

Review audit settings for disabling or locking account events based on event failures. If the settings are not configured to include the cause of the lock or disabling, this is a Finding.

Fix: F-3419r1_fix

Determine and implement audit settings that will collect and store the cause of any DBMS account or connection lock or disabling actions taken by the DBMS.

Checks: C-29380r1_chk

If Symmetric keys are present and Oracle Advanced Security is not installed and operational on the DBMS host, this is a Finding. If the symmetric key management procedures and configuration settings for the DBMS are not specified in the System Security Plan, this is a Finding. If the procedures are not followed with evidence for audit, this is a Finding. NOTE: This check does not include a review of the key management procedures for validity. Specific key management requirements may be covered under separate checks.

Fix: F-26405r1_fix

Symmetric and other encryption keys require the following: - protection from unauthorized access in transit and in storage - utilization of accepted algorithms - generation in accordance with required standards for the key's use - expiration date - continuity - key backup and recovery - key change - archival key storage (as necessary) Details for key management requirements are provided by FIPS 140-2 key management standards available from NIST. Oracle Advanced Security is required to provide symmetric key management features.

Checks: C-29501r1_chk

If no data is identified as being sensitive or classified by the Information Owner, in the System Security Plan or in the AIS Functional Architecture documentation, this check is Not a Finding. If no identified sensitive or classified data requires encryption by the Information Owner in the System Security Plan and/or AIS Functional Architecture documentation, this check is Not a Finding. From SQL*Plus: select * from dba_sa_audit_options; If no records are returned or if output from the SQL statement above does not show classification labels being audited as required in the System Security Plan, this is a Finding.

Fix: F-26411r1_fix

Define the policy for auditing changes to security labels defined for the data. Document the audit requirements in the System Security Plan and configure database auditing in accordance with the policy.

Checks:

Fix: F-26423r1_fix

From SQL*Plus: alter system set global_names = TRUE scope = spfile; NOTE: This parameter, if changed, will affect all currently defined Oracle database links. The above SQL*Plus command will set the parameter to take effect at next system startup.