{"stig":{"title":"Oracle Database 11.2g Security Technical Implementation Guide","version":"2","release":"5"},"checks":[{"vulnId":"V-219695","ruleId":"SV-219695r961863_rule","severity":"medium","ruleTitle":"Access to default accounts used to support replication must be restricted to authorized DBAs.","description":"Replication database accounts are used for database connections between databases. Replication requires the configuration of these accounts using the same username and password on all databases participating in the replication. Replication connections use fixed user database links. This means that access to the replication account on one server provides access to the other servers participating in the replication. Granting unauthorized access to the replication account provides unauthorized and privileged access to all databases participating in the replication group.","checkContent":"From SQL*Plus:\n\nselect 'The number of replication objects defined is: '||\ncount(*) from all_tables\nwhere table_name like 'REPCAT%';\n\nIf the count returned is 0, then Oracle Replication is not installed and this check is Not a Finding.\n\nOtherwise:\n\nFrom SQL*Plus:\n\nselect count(*) from sys.dba_repcatlog;\n\nIf the count returned is 0, then Oracle Replication is not in use and this check is Not a Finding.\n\nIf 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.\n\nIf it is not, this is a Finding.\n\nIf there are multiple replication accounts, confirm that all are justified and documented with the IAO.\n\nIf they are not, this is a Finding.","fixText":"Change the password for default and custom replication accounts and provide the password to IAO-authorized users only.","ccis":["CCI-000366"]},{"vulnId":"V-219696","ruleId":"SV-219696r961863_rule","severity":"medium","ruleTitle":"Oracle instance names must not contain Oracle version numbers.","description":"Service names may be discovered by unauthenticated users. If the service name includes version numbers or other database product information, a malicious user may use that information to develop a targeted attack.","checkContent":"From SQL*Plus:\n\nselect instance_name from v$instance;\nselect version from v$instance;\n\nIf the instance name returned references the Oracle release number, this is a Finding.\n\nNumbers used that include version numbers by coincidence are not a Finding.\n\nThe DBA should be able to relate the significance of the presence of a digit in the SID.","fixText":"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.","ccis":["CCI-000366"]},{"vulnId":"V-219697","ruleId":"SV-219697r961863_rule","severity":"medium","ruleTitle":"Fixed user and public database links must be authorized for use.","description":"Database links define connections that may be used by the local database to access remote Oracle databases. These links provide a means for a compromise to the local database to spread to remote databases in the distributed database environment. Limiting or eliminating use of database links where they are not required to support the operational system can help isolate compromises to the local or a limited number of databases.","checkContent":"From SQL*Plus:\n\nselect owner||': '||db_link from dba_db_links;\nselect count(*) from sys.dba_repcatlog;\n\nIf no records are returned from the first SQL statement, this check is Not a Finding.\n\nIf the value of the count returned is 0 for the second SQL statement, none of the database links listed above, if any, is used for replication.\n\nConfirm the public and fixed user database links listed are documented in the System Security Plan, are authorized by the IAO and are used for replication or operational system requirements.\n\nIf any are not, this is a Finding.","fixText":"Document all authorized connections from the database to remote databases in the System Security Plan.\n\nRemove all unauthorized remote database connection definitions from the database.\n\nFrom SQL*Plus:\n\ndrop database link [link name];\nOR\ndrop public database link [link name];\n\nReview remote database connection definitions periodically and confirm their use is still required and authorized.","ccis":["CCI-000366"]},{"vulnId":"V-219698","ruleId":"SV-219698r961863_rule","severity":"low","ruleTitle":"A minimum of two Oracle control files must be defined and configured to be stored on separate, archived disks (physical or virtual) or archived partitions on a RAID device.","description":"Oracle control files are used to store information critical to Oracle database integrity. Oracle uses these files to maintain time synchronization of database files as well as at system startup to verify the validity of system data and log files. Loss of access to the control files can affect database availability, integrity and recovery.","checkContent":"From SQL*Plus:\n\nselect name from v$controlfile;\n\nDoD guidance recommends:\n\n1. A minimum of two distinct control files for each Oracle Database Instance.\n\n2a. Each control file is to be located on separate, archived physical or logical storage devices\n\nOR\n\n2b. Each control file is to be located on separate, archived directories within one or more RAID devices \n\n3. The Logical Paths for each control file should differ at the highest level supported by your configuration, for example:\n\nUNIX\n/ora03/app/oracle/{SID}/control/control01.ctl\n/ora04/app/oracle/{SID}/control/control02.ctl\n\nWindows\nD:/oracle/{SID}/control/control01.ctl\nE:/oracle/{SID}/control/control02.ctl\n\nIf this minimum listed above is not met, this is a Finding.\n\nConsult 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.\n\nNOTE: Distinct does not equal dedicated. You may share directory space with other Oracle database instances if present.","fixText":"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.\n\nAdding or moving a control file requires careful planning and execution.\n\nPlease consult and follow the instructions for creating control files in the Oracle Database Administrator's Guide, under Steps for Creating New Control Files.","ccis":["CCI-000366"]},{"vulnId":"V-219699","ruleId":"SV-219699r961863_rule","severity":"medium","ruleTitle":"A minimum of two Oracle redo log groups/files must be defined and configured to be stored on separate, archived physical disks or archived directories on a RAID device.","description":"The Oracle redo log files store the detailed information on changes made to the database. This information is critical to database recovery in case of a database failure.","checkContent":"From SQL*Plus:\n\nselect count(*) from V$LOG;\n\nIf the value of the count returned is less than 2, this is a Finding.\n\nFrom SQL*Plus:\n\nselect count(*) from V$LOG where members > 1;\n\nIf the value of the count returned is less than 2 and a RAID storage device is not being used, this is a Finding.","fixText":"To define additional redo log file groups:\n\nFrom SQL*Plus (Example):\n\nalter database add logfile group 2\n('diska:log2.log', 'diskb:log2.log') size 50K; \n\nTo add additional redo log file [members] to an existing redo log file group:\n\nFrom SQL*Plus (Example):\n\nalter database add logfile member 'diskc:log2.log' to group 2;\n\nReplace diska, diskb, diskc with valid, different disk drive specifications.\n\nReplace log#.log file with valid or custom names for the log files.","ccis":["CCI-000366"]},{"vulnId":"V-219700","ruleId":"SV-219700r961863_rule","severity":"medium","ruleTitle":"The Oracle WITH GRANT OPTION privilege must not be granted to non-DBA or non-Application administrator user accounts.","description":"An account permission to grant privileges within the database is an administrative function. Minimizing the number and privileges of administrative accounts reduces the chances of privileged account exploitation. Application user accounts should never require WITH GRANT OPTION privileges since, by definition, they require only privileges to execute procedures or view / edit data.","checkContent":"Execute the query:\n\nselect grantee||': '||owner||'.'||table_name\nfrom dba_tab_privs \nwhere grantable = 'YES' \nand grantee not in (select distinct owner from dba_objects)\nand grantee not in (select grantee from dba_role_privs where granted_role = 'DBA')\norder by grantee;\n\nIf any accounts are listed, this is a finding.","fixText":"Revoke privileges granted the WITH GRANT OPTION from non-DBA and accounts that do not own application objects.\n\nRe-grant privileges without specifying WITH GRANT OPTION.","ccis":["CCI-000366"]},{"vulnId":"V-219701","ruleId":"SV-219701r961863_rule","severity":"medium","ruleTitle":"Execute permission must be revoked from PUBLIC for restricted Oracle packages.","description":"Access to the following packages should be restricted to authorized accounts only.\n\nUTL_FILE: allows Oracle accounts to read and write files on the host operating system.\nUTL_SMTP: allows messages to be sent from an arbitrary user.\nUTL_TCP: allows arbitrary data to be sent from the database server.\nUTL_HTTP: allows the database server to send and receive data via HTTP.\nDBMS_RANDOM: allows encrypting of data without requiring safe management of encryption keys.\nDBMS_LOB: allows users access to files stored outside the database.\nDBMS_SQL: allows users to write dynamic SQL procedures.\nDBMS_SYS_SQL: allows users to execute SQL with DBA privileges.\nDBMS_JOB: allows users to submit jobs to the database job queue.\nDBMS_BACKUP_RESTORE:  allows users to backup and restore database data.\nDBMS_OBFUSCATION_TOOLKIT:  allows users access to encryption and decryption functions.","checkContent":"From SQL*Plus:\nselect table_name from dba_tab_privs\nwhere grantee='PUBLIC' \nand privilege ='EXECUTE'\nand table_name in\n('UTL_FILE', 'UTL_SMTP', 'UTL_TCP', 'UTL_HTTP',\n'DBMS_RANDOM', 'DBMS_LOB', 'DBMS_SQL',\n'DBMS_SYS_SQL', 'DBMS_JOB',\n'DBMS_BACKUP_RESTORE',\n'DBMS_OBFUSCATION_TOOLKIT');\n\nIf any records are returned, this is a Finding.","fixText":"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. \n\nTo 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.\n\nAt a minimum, revoke the following:\n\nFrom SQL*Plus:\nrevoke execute on UTL_FILE from PUBLIC;\nrevoke execute on UTL_SMTP from PUBLIC;\nrevoke execute on UTL_TCP from PUBLIC;\nrevoke execute on UTL_HTTP from PUBLIC;\nrevoke execute on DBMS_RANDOM from PUBLIC;\nrevoke execute on DBMS_LOB from PUBLIC;\nrevoke execute on DBMS_SQL from PUBLIC;\nrevoke execute on DBMS_SYS_SQL from PUBLIC;\nrevoke execute on DBMS_JOB from PUBLIC;\nrevoke execute on DBMS_BACKUP_RESTORE from PUBLIC;\nrevoke execute on DBMS_OBFUSCATION_TOOLKIT from PUBLIC;","ccis":["CCI-000366"]},{"vulnId":"V-219702","ruleId":"SV-219702r961863_rule","severity":"high","ruleTitle":"The Oracle REMOTE_OS_AUTHENT parameter must be set to FALSE.","description":"Setting this value to TRUE allows operating system authentication over an unsecured connection. Trusting remote operating systems can allow a user to impersonate another operating system user and connect to the database without having to supply a password. If REMOTE_OS_AUTHENT is set to true, the only information a remote user needs to connect to the database is the name of any user whose account is setup to be authenticated by the operating system.","checkContent":"From SQL*Plus:\n\nselect value from v$parameter where name = 'remote_os_authent';\n\nIf the value returned does not equal FALSE, this is a Finding.","fixText":"Document remote OS authentication in the System Security Plan.\n\nIf not required or not mitigated to an acceptable level, disable remote OS authentication.\n\nFrom SQL*Plus:\n\nalter system set remote_os_authent = FALSE scope = spfile;\n\nThe above SQL*Plus command will set the parameter to take effect at next system startup.","ccis":["CCI-000366"]},{"vulnId":"V-219703","ruleId":"SV-219703r961863_rule","severity":"high","ruleTitle":"The Oracle REMOTE_OS_ROLES parameter must be set to FALSE.","description":"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.","checkContent":"From SQL*Plus:\n\nselect value from v$parameter where name = 'remote_os_roles';\n\nIf the returned value is not FALSE or not documented in the System Security Plan as required, this is a Finding.","fixText":"Document remote OS roles in the System Security Plan.\n\nIf not required, disable use of remote OS roles.\n\nFrom SQL*Plus:\n\nalter system set remote_os_roles = FALSE scope = spfile;\n\nThe above SQL*Plus command will set the parameter to take effect at next system startup.","ccis":["CCI-000366"]},{"vulnId":"V-219704","ruleId":"SV-219704r961863_rule","severity":"medium","ruleTitle":"The Oracle SQL92_SECURITY parameter must be set to TRUE.","description":"The configuration option SQL92_SECURITY specifies whether table-level SELECT privileges are required to execute an update or delete that references table column values. If this option is disabled (set to FALSE), the UPDATE privilege can be used to determine values that should require SELECT privileges.\n\nThe SQL92_SECURITY setting of TRUE prevents the exploitation of user credentials with only DELETE or UPDATE privileges on a table from being able to derive column values in that table by performing a series of update/delete statements using a where clause, and rolling back the change. In the following example, with SQL92_SECURITY set to FALSE, a user with only delete privilege on the scott.emp table is able to derive that there is one employee with a salary greater than 3000. With SQL92_SECURITY set to TRUE, that user is prevented from attempting to derive a value.\n\nSQL92_SECURITY = FALSE\nSQL> delete from scott.emp where sal > 3000;\n1 row deleted\nSQL> rollback;\nRollback complete\n\nSQL92_SECURITY = TRUE\nSQL> delete from scott.emp where sal > 3000;\ndelete from scott.emp where sal > 3000\n                  *\nERROR at line 1:\nORA-01031: insufficient privileges","checkContent":"From SQL*Plus:\n\nselect value from v$parameter where name = 'sql92_security';\n\nIf the value returned is set to FALSE, this is a Finding.\n\nIf the parameter is set to TRUE or does not exist, this is Not a Finding.","fixText":"Enable SQL92 security.\n\nFrom SQL*Plus:\n\nalter system set sql92_security = TRUE scope = spfile;\n\nThe above SQL*Plus command will set the parameter to take effect at next system startup.","ccis":["CCI-000366"]},{"vulnId":"V-219705","ruleId":"SV-219705r961863_rule","severity":"medium","ruleTitle":"The Oracle password file ownership and permissions should be limited and the REMOTE_LOGIN_PASSWORDFILE parameter must be set to EXCLUSIVE or NONE.","description":"It is critically important to the security of your system that you protect your password file and the environment variables that identify the location of the password file. Any user with access to these could potentially compromise the security of the connection. \nThe REMOTE_LOGIN_PASSWORDFILE setting of \"NONE\" disallows remote administration of the database. The REMOTE_LOGIN_PASSWORDFILE setting of \"EXCLUSIVE\" allows for auditing of individual DBA logins to the SYS account. If not set to \"EXCLUSIVE,” remote connections to the database as \"internal\" or \"as SYSDBA\" are not logged to an individual account.","checkContent":"From SQL*Plus: \n\nselect value from v$parameter where upper(name) = 'REMOTE_LOGIN_PASSWORDFILE';\n\nIf the value returned does not equal 'EXCLUSIVE' or 'NONE', this is a Finding.\n\nOn UNIX Systems:\n\nls -ld $ORACLE_HOME/dbs/orapw${ORACLE_SID}\n\nSubstitute ${ORACLE_SID} with the name of the ORACLE_SID for the database.\n\nIf permissions are granted for world access, this is a finding.\n\nOn Windows Systems (From Windows Explorer):\n\nBrowse to the %ORACLE_HOME\\database\\directory.\n\nSelect and right-click on the PWD%ORACLE_SID%.ora file, select Properties, select the Security tab.\nSubstitute %ORACLE_SID% with the name of the ORACLE_SID for the database.\n\nIf permissions are granted to everyone, this is a finding.\nIf any account other than the DBMS software installation account is listed, this is a finding.","fixText":"Disable use of the remote_login_passwordfile where remote administration is not authorized by specifying a value of NONE.\n\nIf authorized, restrict use of a password file to exclusive use by each database by specifying a value of EXCLUSIVE.\n\nFrom SQL*Plus:\n\nalter system set remote_login_passwordfile = 'EXCLUSIVE' scope = spfile;\n\nOR\n\nalter system set remote_login_passwordfile = 'NONE' scope = spfile;\n\nThe above SQL*Plus command will set the parameter to take effect at next system startup.\n\nRestrict ownership and permissions on the Oracle password file to exclude world (Unix) or everyone (Windows).\n\nMore information regarding the ORAPWD file and the REMOTE_LOGIN_PASSWORDFILE parameter, can be found here:\nhttps://docs.oracle.com/cd/E11882_01/server.112/e25494/dba.htm#ADMIN10241","ccis":["CCI-000366"]},{"vulnId":"V-219706","ruleId":"SV-219706r961863_rule","severity":"medium","ruleTitle":"System privileges granted using the WITH ADMIN OPTION must not be granted to unauthorized user accounts.","description":"The WITH ADMIN OPTION allows the grantee to grant a privilege to another database account. Best security practice restricts the privilege of assigning privileges to authorized personnel. Authorized personnel include DBAs, object owners, and, where designed and included in the application's functions, application administrators. Restricting privilege-granting functions to authorized accounts can help decrease mismanagement of privileges and wrongful assignments to unauthorized accounts.","checkContent":"Run the SQL query:\n\nselect grantee, privilege from dba_sys_privs\nwhere grantee not in\n(<list of non-applicable accounts>)\nand admin_option = 'YES'\nand grantee not in\n(select grantee from dba_role_privs where granted_role = 'DBA');\n\n(With respect to the list of special accounts that are excluded from this requirement, it is expected that the DBA will maintain the list to suit local circumstances, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.)\n\nIf any accounts that are not authorized to have the ADMIN OPTION are listed, this is a Finding.","fixText":"Revoke assignment of privileges with the WITH ADMIN OPTION from unauthorized users and re-grant them without the option.\n\nFrom SQL*Plus:\n\nrevoke [privilege name] from user [username];\n\nReplace [privilege name] with the named privilege and [username] with the named user.\n\nRestrict use of the WITH ADMIN OPTION to authorized administrators.\n\nDocument authorized privilege assignments with the WITH ADMIN OPTION in the System Security Plan.","ccis":["CCI-000366"]},{"vulnId":"V-219707","ruleId":"SV-219707r961863_rule","severity":"medium","ruleTitle":"System Privileges must not be granted to PUBLIC.","description":"System privileges can be granted to users and roles and to the user group PUBLIC. All privileges granted to PUBLIC are accessible to every user in the database. Many of these privileges convey considerable authority over the database and are granted only to those persons responsible for administering the database. In general, these privileges should be granted to roles and then the appropriate roles should be granted to users. System privileges should never be granted to PUBLIC as this could allow users to compromise the database.","checkContent":"From SQL*Plus:\n\nselect privilege from dba_sys_privs where grantee = 'PUBLIC';\n\nIf any records are returned, this is a Finding.","fixText":"Revoke any system privileges assigned to PUBLIC:\n\nFrom SQL*Plus:\n\nrevoke [system privilege] from PUBLIC;\n\nReplace [system privilege] with the named system privilege.\n\nNOTE:  System privileges are not granted to PUBLIC by default and would indicate a custom action.","ccis":["CCI-000366"]},{"vulnId":"V-219708","ruleId":"SV-219708r961863_rule","severity":"medium","ruleTitle":"Oracle roles granted using the WITH ADMIN OPTION must not be granted to unauthorized accounts.","description":"The WITH ADMIN OPTION allows the grantee to grant a role to another database account. Best security practice restricts the privilege of assigning privileges to authorized personnel. Authorized personnel include DBA's, object owners, and, where designed and included in the application's functions, application administrators. Restricting privilege-granting functions to authorized accounts can help decrease mismanagement of privileges and wrongful assignments to unauthorized accounts.","checkContent":"Run the SQL query:\n\nselect grantee||': '||granted_role from dba_role_privs\nwhere grantee not in\n(<list of non-applicable accounts>)\nand admin_option = 'YES' \nand grantee not in\n(select distinct owner from dba_objects)\nand grantee not in\n(select grantee from dba_role_privs\nwhere granted_role = 'DBA')\norder by grantee;\n\n(With respect to the list of special accounts that are excluded from this requirement, it is expected that the DBA will maintain the list to suit local circumstances, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.)\n\nReview the System Security Plan to confirm any grantees listed are ISSO-authorized DBA accounts or application administration roles.\n\nIf any grantees listed are not authorized and documented, this is a Finding.","fixText":"Revoke assignment of roles with the WITH ADMIN OPTION from unauthorized grantees and re-grant them without the option if required.\n\nFrom SQL*Plus:\n\nrevoke [role name] from [grantee];\ngrant [role name] to [grantee];\n\nRestrict use of the WITH ADMIN OPTION to authorized administrators.\n\nDocument authorized role assignments with the WITH ADMIN OPTION in the System Security Plan.","ccis":["CCI-000366"]},{"vulnId":"V-219709","ruleId":"SV-219709r961863_rule","severity":"medium","ruleTitle":"Object permissions granted to PUBLIC must be restricted.","description":"Permissions on objects may be granted to the user group PUBLIC. Because every database user is a member of the PUBLIC group, granting object permissions to PUBLIC gives all users in the database access to that object. In a secure environment, granting object permissions to PUBLIC should be restricted to those objects that all users are allowed to access. The policy does not require object permissions assigned to PUBLIC by the installation of Oracle Database server components to be revoked (with the exception of the packages listed in O112-BP-021800).","checkContent":"Run the SQL query:\n\nselect owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\nwhere grantee = 'PUBLIC'\nand owner not in\n(<list of non-applicable accounts>);\n\n(With respect to the list of special accounts that are excluded from this requirement, it is expected that the DBA will maintain the list to suit local circumstances, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.)\n\nIf any records that are not Oracle product accounts are returned, are not documented and authorized, this is a Finding.\n\nNOTE:  This check may return false positives where other Oracle product accounts are not included in the exclusion list.","fixText":"Revoke any privileges granted to PUBLIC for objects that are not owned by Oracle product accounts.\n\nFrom SQL*Plus:\n\nrevoke [privilege name] from [user name] on [object name];\n\nAssign permissions to custom application user roles based on job functions:\n\nFrom SQL*Plus:\n\ngrant [privilege name] to [user role] on [object name];","ccis":["CCI-000366"]},{"vulnId":"V-219710","ruleId":"SV-219710r961863_rule","severity":"high","ruleTitle":"The Oracle Listener must be configured to require administration authentication.","description":"Oracle listener authentication helps prevent unauthorized administration of the Oracle listener. Unauthorized administration of the listener could lead to DoS exploits; loss of connection audit data, unauthorized reconfiguration or other unauthorized access. This is a Category I finding because privileged access to the listener is not restricted to authorized users. Unauthorized access can result in stopping of the listener (DoS) and overwriting of listener audit logs.","checkContent":"If a listener is not running on the local database host server, this check is Not a Finding.\n\nNOTE:  This check needs to be done only once per host system and once per listener. Multiple listeners may be defined on a single host system. They must all be reviewed, but only once per database home review.\n\nFor subsequent database home reviews on the same host system, mark this check as Not a Finding.\n\nDetermine all Listeners running on the host.\n\nFor Windows hosts, view all Windows services with TNSListener embedded in the service name\n- The service name format is:\n  Oracle[ORACLE_HOME_NAME]TNSListener\n\nFor UNIX hosts, the Oracle Listener process will indicate the TNSLSNR executable.\n\nAt a command prompt, issue the command:\nps -ef | grep tnslsnr | grep -v grep\n\nThe alias for the listener follows tnslsnr in the command output.\n\nYou must be logged on the host system using the account that owns the tnslsnr executable (UNIX). If the account is denied local login, have the system SA assist you in this task by 'su' to the listener account from the root account. On Windows platforms, log in using an account with administrator privileges to complete the check.\n\nFrom a system command prompt, execute the listener control utility:\n\nlsnrctl status [LISTENER NAME]\n\nReview the results for the value of Security.\n\nIf Security = OFF is displayed, this is a Finding.\n\nIf Security = ON: Local OS Authentication is displayed, this is not a Finding.\n\nIf Security = ON: Password or Local OS Authentication, this is a Finding (do not set a password on Oracle versions 10.1 and higher. Instead, use Local OS Authentication).\n\nRepeat the execution of the lsnrctl utility for all active listeners.","fixText":"Configure the listener to use Local OS Authentication. This setting prevents remote administration of the listener, restricts management to the Oracle listener owner account (UNIX) and accounts with administrator privileges (WIN).\n\nRemote administration of the listener should not be permitted. If listener administration from a remote system is required, granting secure remote access to the Oracle DBMS server and performing local administration is preferred. Authorize and document this requirement in the System Security Plan.","ccis":["CCI-000366"]},{"vulnId":"V-219711","ruleId":"SV-219711r961863_rule","severity":"medium","ruleTitle":"Application role permissions must not be assigned to the Oracle PUBLIC role.","description":"Application roles have been granted to PUBLIC. Permissions granted to PUBLIC are granted to all users of the database. Custom roles should be used to assign application permissions to functional groups of application users. The installation of Oracle does not assign role permissions to PUBLIC.","checkContent":"From SQL*Plus:\n\nselect granted_role from dba_role_privs where grantee = 'PUBLIC';\n\nIf any roles are listed, this is a Finding.","fixText":"Revoke role grants from PUBLIC.\n\nDo not assign role privileges to PUBLIC.\n\nFrom SQL*Plus:\n\nrevoke [role name] from PUBLIC;","ccis":["CCI-000366"]},{"vulnId":"V-219712","ruleId":"SV-219712r961863_rule","severity":"medium","ruleTitle":"Oracle application administration roles must be disabled if not required and authorized.","description":"Application administration roles, which are assigned system or elevated application object privileges, should be protected from default activation. Application administration roles are determined by system privilege assignment (create / alter / drop user) and application user role ADMIN OPTION privileges.","checkContent":"Run the SQL query:\n\nselect grantee, granted_role from dba_role_privs\nwhere default_role='YES'\nand granted_role in\n(select grantee from dba_sys_privs where upper(privilege) like '%USER%') \nand grantee not in\n(<list of non-applicable accounts>)\nand grantee not in (select distinct owner from dba_tables)\nand grantee not in\n(select distinct username from dba_users where upper(account_status) like '%LOCKED%');\n\n(With respect to the list of special accounts that are excluded from this requirement, it is expected that the DBA will maintain the list to suit local circumstances, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.)\n\nReview the list of accounts reported for this check and ensure that they are authorized application administration roles.\n\nIf any are not authorized application administration roles, this is a Finding.","fixText":"For each role assignment returned, issue:\n\nFrom SQL*Plus:\n\nalter user [username] default role all except [role];\n\nIf 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.","ccis":["CCI-000366"]},{"vulnId":"V-219713","ruleId":"SV-219713r961863_rule","severity":"medium","ruleTitle":"Connections by mid-tier web and application systems to the Oracle DBMS from a DMZ or external network must be encrypted.","description":"Multi-tier systems may be configured with the database and connecting middle-tier system located on an internal network, with the database located on an internal network behind a firewall and the middle-tier system located in a DMZ. In cases where either or both systems are located in the DMZ (or on networks external to DoD), network communications between the systems must be encrypted.","checkContent":"Review the System Security Plan for remote applications that access and use the database.\n\nFor each remote application or application server, determine whether communications between it and the DBMS are encrypted. If any are not encrypted, this is a finding.","fixText":"Configure communications between the DBMS and remote applications/application servers to use DoD-approved encryption.","ccis":["CCI-000366"]},{"vulnId":"V-219714","ruleId":"SV-219714r961863_rule","severity":"medium","ruleTitle":"Database job/batch queues must be reviewed regularly to detect unauthorized database job submissions.","description":"Unauthorized users may bypass security mechanisms by submitting jobs to job queues managed by the database to be run under a more privileged security context of the database or host system. These queues should be monitored regularly to detect any such unauthorized job submissions.","checkContent":"The DBMS_JOB PL/SQL package has been replaced by DBMS_SCHEDULER in Oracle versions 10.1 and higher, though it continues to be supported for backward compatibility.\n\nRun this query:\nselect value from v$parameter where name = 'job_queue_processes';\n\nRun this query:\nselect value from all_scheduler_global_attribute\nwhere ATTRIBUTE_NAME = 'MAX_JOB_SLAVE_PROCESSES';\n\nTo understand the relationship between these settings, review:\nhttps://docs.oracle.com/cd/E11882_01/server.112/e25494/appendix_a.htm#ADMIN11002\n\nReview documented and implemented procedures for monitoring the Oracle DBMS job/batch queues for unauthorized submissions. If procedures for job queue review are not defined, documented or evidence of implementation does not exist, this is a Finding.\n\nJob queue information is available from the DBA_JOBS view. The following command lists jobs submitted to the queue. DBMS_JOB does not generate a 'history' of previous job executions.\n\nRun this query:\nselect job, next_date, next_sec, failures, broken from dba_jobs;\n\nScheduler queue information is available from the DBA_SCHEDULER_JOBS view. The following command lists jobs submitted to the queue.\n\nRun this query:\nselect owner, job_name, state, job_class, job_type, job_action\nfrom dba_scheduler_jobs;","fixText":"Develop, document and implement procedures to monitor the database job queues for unauthorized job submissions.\n\nDevelop, document and implement a formal migration plan to convert jobs using DBMS_JOB to use DBMS_SCHEDULER instead for Oracle versions 10.1 and higher.  (This does not apply to DBMS_JOB jobs generated by Oracle itself, such as those for refreshing materialized views.)\n\nSet the value of the job_queue_processes parameter to a low value to restrict concurrent DBMS_JOB executions.\n\nUse auditing to capture use of the DBMS_JOB package in the audit trail. Review the audit trail for unauthorized use of the DBMS_JOB package.","ccis":["CCI-000366"]},{"vulnId":"V-219715","ruleId":"SV-219715r961863_rule","severity":"medium","ruleTitle":"Unauthorized database links must not be defined and active.","description":"DBMS links provide a communication and data transfer path definition between two databases that may be used by malicious users to discover and obtain unauthorized access to remote systems. Database links between production and development DBMSs provide a means for developers to access production data not authorized for their access or to introduce untested or unauthorized applications to the production database. Only protected, controlled, and authorized downloads of any production data to use for development should be allowed. Only applications that have completed the configuration management process should be introduced by the application object owner account to the production system.","checkContent":"From SQL*Plus:\nselect db_link||': '||host from dba_db_links;\n\nIf no links are returned, this check is Not a Finding.\n\nReview documentation for definitions of authorized database links to external interfaces.\n\nThe documentation should include:\n\n- Any remote access to the database\n- The purpose or function of the remote connection\n- Any access to data or procedures stored externally to the local DBMS\n- Any network ports or protocols used by remote connections, whether the remote connection is to a production, test, or development system\n- Any security accounts used by DBMS to access remote resources or objects\n\nIf any unauthorized database links are defined or the definitions do not match the documentation, this is a Finding.\n\nNOTE: Findings for production-development links under this check are assigned to the production database only.\n\nIf any database links are defined between the production database and any test or development databases, this is a Finding.\n\nIf remote interface documentation does not exist or is incomplete, this is a Finding.","fixText":"Document all remote or external interfaces used by the DBMS to connect to or allow connections from remote or external sources.\n\nInclude with the documentation as appropriate, any network ports or protocols, security accounts, and the sensitivity of any data exchanged.\n\nDo not define or configure database links between production databases and test or development databases.","ccis":["CCI-000366"]},{"vulnId":"V-219716","ruleId":"SV-219716r961863_rule","severity":"medium","ruleTitle":"Sensitive information from production database exports must be modified before being imported into a development database.","description":"Data export from production databases may include sensitive data. Application developers do not have a need to know to sensitive data. Any access they may have to production data would be considered unauthorized access and subject the sensitive data to unlawful or unauthorized disclosure. See DODD 8500.1 for a definition of Sensitive Information.","checkContent":"If the database being reviewed is a production database, this check is Not a Finding.\n\nReview policy, procedures and restrictions for data imports of production data containing sensitive information into development databases.\n\nIf data imports of production data are allowed, review procedures for protecting any sensitive data included in production exports.\n\nIf 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.","fixText":"Develop, document and implement policy, procedures and restrictions for production data import.\n\nRequire any users assigned privileges that allow the export of production data from the database to acknowledge understanding of import policies, procedures and restrictions.\n\nRestrict permissions of development personnel requiring use or access to production data imported into development databases containing sensitive information to authorized users.\n\nImplement policy and procedures to modify or remove sensitive information in production exports prior to import into development databases.","ccis":["CCI-000366"]},{"vulnId":"V-219719","ruleId":"SV-219719r961863_rule","severity":"medium","ruleTitle":"Only authorized system accounts must have the SYSTEM tablespace specified as the default tablespace.","description":"The Oracle SYSTEM tablespace is used by the database to store all DBMS system objects. Other use of the system tablespace may compromise system availability and the effectiveness of host system access controls to the tablespace files.","checkContent":"Run the query:\n\nselect property_name, property_value\nfrom database_properties\nwhere property_name in\n('DEFAULT_PERMANENT_TABLESPACE','DEFAULT_TEMP_TABLESPACE');\n\nIf either value is set to SYSTEM, this is a finding.\n\nRun the query:\n\nselect username from dba_users \nwhere (default_tablespace = 'SYSTEM' or temporary_tablespace = 'SYSTEM')\nand username not in\n('LBACSYS','OUTLN','SYS','SYSTEM');\n\nIf any non-default account records are returned, this is a finding.","fixText":"Create and dedicate tablespaces to support only one application.\n\nDo not share tablespaces between applications.\n\nDo not grant quotas to application object owners on tablespaces not dedicated to their associated application.\n\nRun the queries:\n\nalter database default tablespace <tablespace_name>;\nalter database default temporary tablespace <temporary_tablespace_name>;\n\nalter user <username> default tablespace <tablespace_name> temporary tablespace <temporary_tablespace_name>;\n\nReplace <username> with the named user account.\nReplace <tablespace_name> with the new default tablespace name.\nReplace <temporary_tablespace_name> with the new default temporary tablespace name (typically TEMP).\nRepeat the \"alter user\" for each affected user account.","ccis":["CCI-000366"]},{"vulnId":"V-219720","ruleId":"SV-219720r961863_rule","severity":"medium","ruleTitle":"Application owner accounts must have a dedicated application tablespace.","description":"Separation of tablespaces by application helps to protect the application from resource contention and unauthorized access that could result from storage space reuses or host system access controls. Application data should be stored separately from system and custom user-defined objects to facilitate administration and management of its data storage. The SYSTEM tablespace should never be used for application data storage in order to prevent resource contention and performance degradation.","checkContent":"Run the SQL query:\n\nselect distinct owner, tablespace_name\nfrom dba_SEGMENTS \nwhere owner not in\n(<list of non-applicable accounts>)\norder by tablespace_name;\n\n(With respect to the list of special accounts that are excluded from this requirement, it is expected that the DBA will maintain the list to suit local circumstances, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.)\n\nReview the list of returned table owners with the tablespace used.\n\nIf any of the owners listed are not default Oracle accounts and use the SYSTEM or any other tablespace not dedicated for the application’s use, this is a Finding.\n\nLook for multiple applications that may share a tablespace.\n\nIf no records were returned, ask the DBA if any applications use this database.\n\nIf no applications use the database, this is not a Finding.\n\nIf there are applications that do use the database or if the application uses the SYS or other default account and SYSTEM tablespace to store its objects, this is a Finding.","fixText":"Create and assign dedicated tablespaces for the storage of data by each application using the CREATE TABLESPACE command.","ccis":["CCI-000366"]},{"vulnId":"V-219721","ruleId":"SV-219721r961863_rule","severity":"medium","ruleTitle":"The directories assigned to the LOG_ARCHIVE_DEST* parameters must be protected from unauthorized access.","description":"The LOG_ARCHIVE_DEST parameter is used to specify the directory to which Oracle archive logs are written. Where the DBMS availability and recovery to a specific point in time is critical, the protection of archive log files is critical. Archive log files may also contain unencrypted sensitive data. If written to an inadequately protected or invalidated directory, the archive log files may be accessed by unauthorized persons or processes.","checkContent":"From SQL*Plus:\n\nselect log_mode from v$database;\nselect value from v$parameter where name = 'log_archive_dest';\nselect value from v$parameter where name = 'log_archive_duplex_dest';\nselect name, value from v$parameter where name LIKE 'log_archive_dest_%';\n\nIf the value returned for LOG_MODE is NOARCHIVELOG, this check is Not a Finding.\n\nIf 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.\n\nNOTE: 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.\n\nOn UNIX Systems:\n\nls -ld [pathname]\n\nSubstitute [pathname] with the directory paths listed from the above SQL statements for log_archive_dest and log_archive_duplex_dest.\n\nIf permissions are granted for world access, this is a Finding.\n\nOn Windows Systems (From Windows Explorer):\n\nBrowse to the directory specified.\n\nSelect and right-click on the directory, select Properties, select the Security tab.\n\nIf permissions are granted to everyone, this is a Finding.\n\nIf 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.","fixText":"Specify a valid and protected directory for archive log files.\n\nRestrict access to the Oracle process and software owner accounts, DBAs, and backup operator accounts.","ccis":["CCI-000366"]},{"vulnId":"V-219722","ruleId":"SV-219722r961863_rule","severity":"medium","ruleTitle":"The Oracle _TRACE_FILES_PUBLIC parameter if present must be set to FALSE.","description":"The _TRACE_FILES_PUBLIC parameter is used to make trace files used for debugging database applications and events available to all database users. Use of this capability precludes the discrete assignment of privileges based on job function. Additionally, its use may provide access to external files and data to unauthorized users.","checkContent":"From SQL*Plus:\n\nselect value from v$parameter where name = '_trace_files_public';\n\nIf the value returned is TRUE, this is a Finding.\n\nIf the parameter does not exist or is set to FALSE, this is Not a Finding.","fixText":"From SQL*Plus (shutdown database instance):\n\nshutdown immediate\n\nFrom SQL*Plus (create a pfile from spfile):\n\ncreate pfile='[PATH]init[SID].ora' from spfile;\n\nEdit the init[SID].ora file and remove the following line:\n\n*._trace_files_public=TRUE\n\nFrom SQL*Plus (update the spfile using the pfile):\n\ncreate spfile from pfile='[PATH]init[SID].ora';\n\nFrom SQL*Plus (start the database instance):\n\nstartup\n\nNOTE: [PATH] depends on the platform (Windows or UNIX).\n\nEnsure the file is directed to a writable location.\n\n[SID] is equal to the oracle SID or database instance ID.","ccis":["CCI-000366"]},{"vulnId":"V-219723","ruleId":"SV-219723r961863_rule","severity":"medium","ruleTitle":"Application object owner accounts must be disabled when not performing installation or maintenance actions.","description":"Object ownership provides all database object permissions to the owned object. Access to the application object owner accounts requires special protection to prevent unauthorized access and use of the object ownership privileges. In addition to the high privileges to application objects assigned to this account, it is also an account that, by definition, is not accessed interactively except for application installation and maintenance. This reduced access to the account means that unauthorized access to the account could go undetected. To help protect the account, it should be enabled only when access is required.","checkContent":"Run the SQL query:\n\nselect distinct o.owner from dba_objects o, dba_users u\n where o.owner not in\n(\n <list of non-applicable accounts>\n)\n and o.object_type <> 'SYNONYM'\n and o.owner = username\n and upper(account_status) not like '%LOCKED%';\n\n(With respect to the list of special accounts that are excluded from this requirement, it is expected that the DBA will maintain the list to suit local circumstances, adding special accounts as necessary and removing any that are not supposed to be in use in the Oracle deployment that is under review.)\n\nTo obtain a list of users assigned DBA privileges, run the query:\n\nselect grantee from dba_role_privs where granted_role = ’DBA’;\n\nIf any records are returned, then verify the account is an authorized application object owner account or a default account installed to support an Oracle product.  \n\nVerify that any objects owned by custom DBA accounts are for the personal use of that DBA.\n\nIf any objects are used to support applications or any functions other than DBA functions, this is a Finding.\n\nAny unauthorized object owner accounts are not a finding under this check as they are noted as findings under check O112-C2-011000.  \n\nAny other accounts listed are a Finding.","fixText":"Disable any application object owner accounts.\n\nFrom SQL*Plus:\nalter user [username] account lock;\n\nEnable application object owner accounts only for installation and maintenance.\n\nDBA are special purpose accounts and do not require disabling although they may own objects.\n\nFor 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.","ccis":["CCI-000366"]},{"vulnId":"V-219724","ruleId":"SV-219724r961863_rule","severity":"medium","ruleTitle":"DBMS production application and data directories must be protected from developers on shared production/development DBMS host systems.","description":"Developer roles should not be assigned DBMS administrative privileges to production DBMS application and data directories. The separation of production DBA and developer roles helps protect the production system from unauthorized, malicious or unintentional interruption due to development activities.","checkContent":"If the DBMS or DBMS host is not shared by production and development activities, this check is Not a Finding.\n\nReview OS DBA group membership.\n\nIf any developer accounts as identified in the System Security Plan have been assigned DBA privileges, this is a Finding.\n\nNOTE: Though shared production/non-production DBMS installations was allowed under previous database STIG guidance, doing so may place it in violation of OS, Application, Network or Enclave STIG guidance. Ensure that any shared production/non-production DBMS installations meets STIG guidance requirements at all levels or mitigate any conflicts in STIG guidance with your DAA.","fixText":"Create separate DBMS host OS groups for developer and production DBAs.\n\nDo not assign production DBA OS group membership to accounts used for development.\n\nRemove development accounts from production DBA OS group membership.\n\nRecommend establishing a dedicated DBMS host for production DBMS installations (See Checks O112-BP-025000 and O112-BP-025300). 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.","ccis":["CCI-000366"]},{"vulnId":"V-219725","ruleId":"SV-219725r961863_rule","severity":"medium","ruleTitle":"Use of the DBMS installation account must be logged.","description":"The DBMS installation account may be used by any authorized user to perform DBMS installation or maintenance. Without logging, accountability for actions attributed to the account is lost.","checkContent":"Review documented and implemented procedures for monitoring the use of the DBMS software installation account in the System Security Plan.\n\nIf use of this account is not monitored or procedures for monitoring its use do not exist or are incomplete, this is a Finding.\n \nNOTE: On Windows systems, The Oracle DBMS software is installed using an account with administrator privileges. Ownership should be reassigned to a dedicated OS account used to operate the DBMS software. If monitoring does not include all accounts with administrator privileges on the DBMS host, this is a Finding.","fixText":"Develop, document and implement a logging procedure for use of the DBMS software installation account that provides accountability to individuals for any actions taken by the account.\n\nHost system audit logs should be included in the DBMS account usage log along with an indication of the person who accessed the account and an explanation for the access.\n\nEnsure all accounts with administrator privileges are monitored for DBMS host on Windows OS platforms.","ccis":["CCI-000366"]},{"vulnId":"V-219733","ruleId":"SV-219733r961863_rule","severity":"medium","ruleTitle":"The directory assigned to the AUDIT_FILE_DEST parameter must be protected from unauthorized access and must be stored in a dedicated directory or disk partition separate from software or other application files.","description":"The AUDIT_FILE_DEST parameter specifies the directory where the database audit trail file is stored (when AUDIT_TRAIL parameter is set to ‘OS’, ‘xml’ or ‘xml, extended’ where supported by the DBMS). Unauthorized access or loss of integrity of the audit trail could result in loss of accountability or the ability to detect suspicious\nactivity. This directory also contains the audit trail of the SYS and SYSTEM accounts that captures privileged database events when the database is not running (when AUDIT_SYS_OPERATIONS parameter is set to TRUE).","checkContent":"From SQL*Plus:\n\nselect value from v$parameter where name = 'audit_trail';\nselect value from v$parameter where name = 'audit_file_dest';\n\nIf audit_trail is NOT set to OS, XML, or XML EXTENDED, this is not applicable (NA).\n\nIf audit_trail is set to OS, but the audit records are routed directly to a separate log server without writing to the local file system, this is not a finding.\n\nOn UNIX Systems:\n\nls -ld [pathname]\nReplace [pathname] with the directory path listed from the above SQL command for audit_file_dest.\nIf permissions are granted for world access, this is a finding.\nIf 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.\n\nCompare path to $ORACLE_HOME. If audit_file_dest is a subdirectory of $ORACLE_HOME, this is a finding.\n\nOn Windows Systems (From Windows Explorer):\n\nBrowse 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\nlog. 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.\n\nIf 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.\n\nCompare path to %ORACLE_HOME%. If audit_file_dest is a subdirectory of %ORACLE_HOME%, this is a finding.","fixText":"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.\n\nAuthorize and document user access requirements to the directory outside of the Oracle, DBA, and SA account list in the System Security Plan.","ccis":["CCI-000366"]},{"vulnId":"V-219736","ruleId":"SV-219736r961863_rule","severity":"medium","ruleTitle":"Access to DBMS software files and directories must not be granted to unauthorized users.","description":"The DBMS software libraries contain the executables used by the DBMS to operate. Unauthorized access to the libraries can result in malicious alteration or planting of operational executables. This may in turn jeopardize data stored in the DBMS and/or operation of the host system.","checkContent":"For UNIX Systems:\n\nLog in using the Oracle software owner account and enter the command:\n\numask\n\nIf the value returned is 022 or more restrictive, this is not a Finding.\n\nIf the value returned is less restrictive than 022, this is a Finding.\n\nThe first number sets the mask for user/owner file permissions. The second number sets the mask for group file permissions. The third number sets file permission mask for other users. The list below shows the available settings:\n\n0 = read/write/execute\n1 = read/write\n2 = read/execute\n3 = read\n4 = write/execute\n5 = write\n6 = execute\n7 = no permissions\n\nSetting the umask to 022 effectively sets files for user/owner to read/write, group to read and other to read. Directories are set for user/owner to read/write/execute, group to read/execute and other to read/execute.\n\nFor Windows Systems:\nReview the permissions that control access to the Oracle installation software directories (e.g. \\Program Files\\Oracle\\).\n\nDBA accounts, the DBMS process account, the DBMS software installation/maintenance account, SA accounts if access by them is required for some operational level of support such as backups, and the host system itself require access.\n\nCompare the access control employed with that documented in the System Security Plan.\n\nIf access controls do not match the documented requirement, this is a Finding.\n\nIf access controls appear excessive without justification, this is a Finding.","fixText":"For UNIX Systems:\n\nSet the umask of the Oracle software owner account to 022. Determine the shell being used for the Oracle software owner account:\n\nenv | grep -i shell\n\nStartup files for each shell are as follows (located in users $HOME directory):\n\nC-Shell (CSH) = .cshrc\nBourne Shell (SH) = .profile\nKorn Shell (KSH) = .kshrc\nTC Shell (TCS) = .tcshrc\nBASH Shell = .bash_profile or .bashrc\n\nEdit the shell startup file for the account and add or modify the line:\n\numask 022\n\nLog off and login, then enter the umask command to confirm the setting.\n\nNOTE: To effect this change for all Oracle processes, a reboot of the DBMS server may be required.\n\nFor Windows Systems:\nProduct-specific fix is pending development. Use Generic Fix listed below:\n\nRestrict access to the DBMS software libraries to the fewest accounts that clearly require access based on job function.\n\nDocument authorized access control and justify any access grants that do not fall under DBA, DBMS process, ownership, or SA accounts.","ccis":["CCI-000366"]},{"vulnId":"V-219737","ruleId":"SV-219737r961863_rule","severity":"medium","ruleTitle":"Replication accounts must not be granted DBA privileges.","description":"Replication accounts may be used to access databases defined for the replication architecture. An exploit of a replication on one database could lead to the compromise of any database participating in the replication that uses the same account name and credentials. If the replication account is compromised and it has DBA privileges, the database is at additional risk to unauthorized or malicious action.","checkContent":"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.\n\nIf any replication accounts are assigned DBA roles or roles with DBA privileges, this is a Finding.","fixText":"Restrict privileges assigned to replication accounts to the fewest possible privileges.\n\nRemove DBA roles from replication accounts.\n\nCreate and use custom replication accounts assigned least privileges for supporting replication operations.","ccis":["CCI-000366"]},{"vulnId":"V-219738","ruleId":"SV-219738r961863_rule","severity":"medium","ruleTitle":"Network access to the DBMS must be restricted to authorized personnel.","description":"Restricting remote access to specific, trusted systems helps prevent access by unauthorized and potentially malicious users.","checkContent":"IP address restriction may be defined for the database listener, by use of the Oracle Connection Manager or by an external network device.\n\nIdentify the method used to enforce address restriction (interview or System Security Plan review).\n\nIf enforced by the database listener, then review the SQLNET.ORA file located in the ORACLE_HOME/network/admin directory (note: this assumes that a single sqlnet.ora file, in the default location, is in use; please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files) or the directory indicated by the TNS_ADMIN environment variable or registry setting.\n\nIf the following entries do not exist, then restriction by IP address is not configured and is a Finding.\ntcp.validnode_checking=YES\ntcp.invited_nodes=(IP1, IP2, IP3)\n\nIf enforced by an Oracle Connection Manager, then review the CMAN.ORA file for the Connection Manager (located in the TNS_ADMIN or ORACLE_HOME/network/admin directory for the connection manager).\n\nIf a RULE entry allows all addresses (\"/32\") or does not match the address range specified in the System Security Plan, this is a Finding.\n\n(rule=(src=[IP]/27)(dst=[IP])(srv=*)(act=accept))\n\nNOTE: an IP address with a \"/\" indicates acceptance by subnet mask where the number after the \"/\" is the left most number of bits in the address that must match for the rule to apply.\n\nIf this rule is database-specific, then determine if the SERVICE_NAME parameter is set:\n\nFrom SQL*PLUS:\n\nselect value from v$parameter where name = 'service_names';\n\nIf SERVICE_NAME is set in the initialization file for the database instance, use (srv=[service name]), else, use (srv=*) if not set or rule applies to all databases on the DBMS server.\n\nIf network access restriction is performed by an external device, validate ACLs are in place to prohibit unauthorized access to the DBMS.  To do this, find the IP address of the database server (destination address) and source address (authorized IPs) in the System Security Plan.  Confirm only authorized IPs from the System Security Plan are allowed access to the DBMS.","fixText":"Configure the database listener to restrict access by IP address or set up an external device to restrict network access to the DBMS.","ccis":["CCI-000366"]},{"vulnId":"V-219739","ruleId":"SV-219739r961863_rule","severity":"medium","ruleTitle":"Changes to configuration options must be audited.","description":"The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of actions taken by the user SYS. The SYS user account is a shared account by definition and holds all privileges in the Oracle database. It is the account accessed by users connecting to the database with SYSDBA or SYSOPER privileges.","checkContent":"From SQL*Plus:\n\nselect value from v$parameter where name = 'audit_sys_operations';\n\nIf the value returned is FALSE, this is a Finding.","fixText":"From SQL*Plus:\n\nalter system set audit_sys_operations = TRUE scope = spfile;\n\nThe above SQL*Plus command will set the parameter to take effect at next system startup.","ccis":["CCI-000366"]},{"vulnId":"V-219742","ruleId":"SV-219742r961863_rule","severity":"medium","ruleTitle":"Changes to DBMS security labels must be audited.","description":"Some DBMS systems provide the feature to assign security labels to data elements. If labeling is required, implementation options include the Oracle Label Security package, or a third-party product, or custom-developed functionality.  The confidentiality and integrity of the data depends upon the security label assignment where this feature is in use. Changes to security label assignment may indicate suspicious activity.","checkContent":"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 is not a finding.\n\nIf security labeling is not required, this is not a finding.\n\nIf no sensitive or classified data is identified by the Information Owner as requiring labeling in the System Security Plan and/or AIS Functional Architecture documentation, this is not a finding.\n\nRun the SQL statement:\nselect * from dba_sa_audit_options;\n\nIf 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.","fixText":"Define the policy for auditing changes to security labels defined for the data.\n\nDocument the audit requirements in the System Security Plan and configure database auditing in accordance with the policy.","ccis":["CCI-000366"]},{"vulnId":"V-219743","ruleId":"SV-219743r961863_rule","severity":"medium","ruleTitle":"Remote database or other external access must use fully-qualified names.","description":"The Oracle GLOBAL_NAMES parameter is used to set the requirement for database link names to be the same name as the remote database whose connection they define. By using the same name for both, ambiguity is avoided and unauthorized or unintended connections to remote databases are less likely.","checkContent":"From SQL*Plus:\n\nselect value from v$parameter where name = 'global_names';\n\nIf the value returned is FALSE, this is a Finding.","fixText":"From SQL*Plus:\n\nalter system set global_names = TRUE scope = spfile;\n\nNOTE: This parameter, if changed, will affect all currently defined Oracle database links.\n\nThe above SQL*Plus command will set the parameter to take effect at next system startup.","ccis":["CCI-000366"]},{"vulnId":"V-219744","ruleId":"SV-219744r961863_rule","severity":"medium","ruleTitle":"The /diag subdirectory under the directory assigned to the DIAGNOSTIC_DEST parameter must be protected from unauthorized access.","description":"<DIAGNOSTIC_DEST>/diag indicates the directory where trace, alert, core and incident directories and files are located. The files may contain sensitive data or information that could prove useful to potential attackers.","checkContent":"From SQL*Plus:\n\nselect value from v$parameter where name='diagnostic_dest';\n\nOn UNIX Systems:\n\nls -ld [pathname]/diag\n\nSubstitute [pathname] with the directory path listed from the above SQL command, and append \"/diag\" to it, as shown.\n\nIf permissions are granted for world access, this is a Finding.\n\nIf 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.\n\nOn Windows Systems (From Windows Explorer):\n\nBrowse to the \\diag directory under the directory specified.\n\nSelect and right-click on the directory, select Properties, select the Security tab.\n\nIf permissions are granted to everyone, this is a Finding.\n\nIf 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.","fixText":"Alter host system permissions to the <DIAGNOSTIC_DEST>/diag 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.\n\nAuthorize and document user access requirements to the directory outside of the Oracle, DBA and SA account list.","ccis":["CCI-000366"]},{"vulnId":"V-219745","ruleId":"SV-219745r961863_rule","severity":"medium","ruleTitle":"Remote administration must be disabled for the Oracle connection manager.","description":"Remote administration provides a potential opportunity for malicious users to make unauthorized changes to the Connection Manager configuration or interrupt its service.","checkContent":"View the cman.ora file in the ORACLE_HOME/network/admin directory.\n\nIf the file does not exist, the database is not accessed via Oracle Connection Manager and this check is Not a Finding.\n\nIf the entry and value for REMOTE_ADMIN is not listed or is not set to a value of NO (REMOTE_ADMIN = NO), this is a Finding.","fixText":"View the cman.ora file in the ORACLE_HOME/network/admin directory of the Connection Manager.\n\nInclude the following line in the file:\n\nREMOTE_ADMIN = NO","ccis":["CCI-000366"]},{"vulnId":"V-219746","ruleId":"SV-219746r961863_rule","severity":"medium","ruleTitle":"The SQLNet SQLNET.ALLOWED_LOGON_VERSION parameter must be set to a value of 12 or higher.","description":"Unsupported Oracle network client installations may introduce vulnerabilities to the database. Restriction to use of supported versions helps to protect the database and helps to enforce newer, more robust security controls.","checkContent":"View the SQLNET.ORA file in the ORACLE_HOME/network/admin directory or the directory specified in the TNS_ADMIN environment variable. (Please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files.)\n\nLocate the following entry:\n\nSQLNET.ALLOWED_LOGON_VERSION = 12\n\nIf the parameter does not exist, this is a finding.\nDetermine whether the Oracle DBMS software is at version 11.2.0.4 with the January 2014 CPU (or above). If it is not, this is a finding.\n\nIf the parameter is not set to a value of 12 or higher, this is a finding.","fixText":": Deploy Oracle 11.2.0.4 with the January 2014 CPU patch.\n\nEdit the SQLNET.ORA file to add or edit the entry:\n\nSQLNET.ALLOWED_LOGON_VERSION = 12\n\nSet the value to 12 or higher.\n\nFor more information on sqlnet.ora parameters refer to the following document:\n\"Database Net Services Reference\"\nhttps://docs.oracle.com/cd/E11882_01/network.112/e10835/sqlnet.htm#NETRF006","ccis":["CCI-000366"]},{"vulnId":"V-219747","ruleId":"SV-219747r961041_rule","severity":"high","ruleTitle":"The DBMS, when using PKI-based authentication, must enforce authorized access to the corresponding private key.","description":"The cornerstone of the PKI is the private key used to encrypt or digitally sign information.\n\nIf the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI, because the attacker can use the private key to digitally sign documents and can pretend to be the authorized user.\n\nBoth the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.\n\nAll access to the private key of the DBMS must be restricted to authorized and authenticated users. If unauthorized users have access to the DBMS's private key, an attacker could gain access to the primary key and use it to impersonate the database on the network.\n\nTransport 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.","checkContent":"Review DBMS configuration to determine whether appropriate access controls exist to protect the DBMS’s private key. If strong access controls do not exist to enforce authorized access to the private key, this is a finding.\n\nThe database supports authentication by using digital certificates over TLS in addition to the native encryption and data integrity capabilities of these protocols.\n\nAn Oracle Wallet is a container that is used to store authentication and signing credentials, including private keys, certificates, and trusted certificates needed by TLS. In an Oracle environment, every entity that communicates over TLS must have a wallet containing an X.509 version 3 certificate, private key, and list of trusted certificates, with the exception of Diffie-Hellman.\n\nIf the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries,  TLS is installed. (Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files.)\n\nWALLET_LOCATION = (SOURCE=\n                          (METHOD = FILE) \n                          (METHOD_DATA = \n                           DIRECTORY=/wallet) \n\nSSL_CIPHER_SUITES=(SSL_cipher_suiteExample) \nSSL_VERSION = 1.2\nSSL_CLIENT_AUTHENTICATION=FALSE/TRUE","fixText":"Implement strong access and authentication controls to protect the database’s private key.\n\nConfigure the database to support Transport Layer Security (TLS) protocols and the Oracle Wallet to store authentication and signing credentials including private keys.","ccis":["CCI-000186"]},{"vulnId":"V-219748","ruleId":"SV-219748r960735_rule","severity":"medium","ruleTitle":"The DBMS must limit the number of concurrent sessions for each system account to an organization-defined number of sessions.","description":"Application management includes the ability to control the number of users and user sessions utilizing an application. Limiting the number of allowed users, and sessions per user, is helpful in limiting risks related to Denial of Service attacks.\n\nThis requirement addresses concurrent session control for a single information system account and does not address concurrent sessions by a single user via multiple system accounts. \n\nUnlimited concurrent connections to the DBMS could allow a successful Denial of Service (DoS) attack by exhausting connection resources.\n\nThe organization will need to define the maximum number of concurrent sessions by account type, by account, or a combination thereof.  In deciding on the appropriate number, it is important to take into account the work requirements of the various types of user.  For example, 2 might be an acceptable limit for general users accessing the database via an application; but 10 might be too few for a database administrator using a database management GUI tool, where each query tab and navigation pane may count as a separate session.","checkContent":"Retrieve the settings for concurrent sessions for each profile with the query:\nSELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'SESSIONS_PER_USER';\n\nIf the DBMS settings for concurrent sessions for each profile are greater than the organizationally defined maximum number of sessions, this is a finding.","fixText":"Limit concurrent connections for each system account to a number less than or equal to the organization-defined number of sessions using the following SQL.  Create profiles that conform to the DoD requirements.  Assign users to the appropriate profile.  \n\nChange the value of SESSIONS_PER_USER (along with the other parameters, where relevant) from UNLIMITED to DoD-compliant, site-specific requirements and then assign users to the profile (the name PPPPP is an example; use a name appropriate to your circumstance):\n\nCREATE PROFILE \"PPPPPP\" LIMIT CPU_PER_SESSION UNLIMITED\nCPU_PER_CALL UNLIMITED\nCONNECT_TIME UNLIMITED\nIDLE_TIME UNLIMITED\nSESSIONS_PER_USER UNLIMITED\nLOGICAL_READS_PER_SESSION UNLIMITED\nLOGICAL_READS_PER_CALL UNLIMITED\nPRIVATE_SGA UNLIMITED\nCOMPOSITE_LIMIT UNLIMITED\nPASSWORD_LIFE_TIME 180\nPASSWORD_GRACE_TIME 7\nPASSWORD_REUSE_MAX UNLIMITED\nPASSWORD_REUSE_TIME UNLIMITED\nPASSWORD_LOCK_TIME 1\nFAILED_LOGIN_ATTEMPTS 10\nPASSWORD_VERIFY_FUNCTION NULL\n\nTo assign the user to the profile do the following:\nALTER USER user1 PROFILE PPPPPP;","ccis":["CCI-000054"]},{"vulnId":"V-219749","ruleId":"SV-219749r960768_rule","severity":"medium","ruleTitle":"The system must employ automated mechanisms for supporting Oracle user account management.","description":"A comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in non-centralized account stores, such as multiple servers.\n\nEnterprise environments make application user account management challenging and complex.  A user management process requiring administrators to manually address account management functions adds risk of potential oversight.\n\nAutomated mechanisms may be comprised of differing technologies that when placed together contain an overall automated mechanism supporting an organization's automated account management requirements.\n\nDatabases can have large numbers of users in disparate locations and job functions.  Automatic account management can help mitigate the risk of human error found in manually managing database access.\n\nNote that user authentication and account management should 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.","checkContent":"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.\n\nIf an Oracle feature/product, an OS feature, a third-party product, or custom code is used to automate account management, this is not a finding.\n\nDetermine what the site-defined definition of an acceptably small level of manual account-management activity is.  If the site has established the definition, documented it, and obtained ISSO-ISSM-AO approval, use that definition.  If not, use the following rule of thumb as the definition:  no more than 12 such accounts exist or are expected to exist; no more than 100 manual account-management actions (account creation, modification, locking, unlocking, removal and the like) are expected to occur in the course of a year.\n\nIf the amount of account management activity is small, as defined in the preceding paragraph, this is not a finding.\n\nOtherwise, this is a finding.","fixText":"Utilize an Oracle feature/product, an OS feature, a third-party product, or custom code to automate some or all account maintenance functionality.\n\n- - - - -\n\nRoles and Profiles are two Oracle features that should be employed in account management. (Indeed, other requirements mandate the use of Roles.) Following are some notes from Oracle on the use of Profiles.\n\nA profile is a named set of resource limits and password parameters that restrict database usage and instance resources for a user. You can assign a profile to each user, and a default profile to all others. Each user can have only one profile, and creating a new one supersedes any earlier one.\n\nProfile resource limits are enforced only when you enable resource limitation for the associated database. Enabling such limitation can occur either before starting up the database (the RESOURCE_LIMIT initialization parameter) or while it is open (using an ALTER SYSTEM statement).\n\nWhile password parameters reside in profiles, they are unaffected by RESOURCE_LIMIT or ALTER SYSTEM and password management is always enabled.","ccis":["CCI-000015"]},{"vulnId":"V-219750","ruleId":"SV-219750r960792_rule","severity":"medium","ruleTitle":"The DBMS must enforce approved authorizations for logical access to the system in accordance with applicable policy.","description":"Strong access controls are critical to securing application data. Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) must be employed by applications, when applicable, to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the information system. \n\nConsideration should be given to the implementation of an audited, explicit override of automated mechanisms in the event of emergencies or other serious events.\n\nIf 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 may be in conflict with applicable policy.","checkContent":"Check DBMS settings to determine whether users are restricted from accessing objects and data they are not authorized to access. If appropriate access controls are not implemented to restrict access to authorized users and to restrict the access of those users to objects and data they are authorized to see, this is a finding.\n\nThe easiest way to isolate access is by using the Oracle Database Vault.  To check to see if the Oracle Database Vault is installed issue the following query:\n        SQL> SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';\nIf Oracle Database Vault is installed, review its settings for appropriateness and completeness of the access it permits and denies to each type of user.  If appropriate and complete, this is not a finding.\n\nIf Oracle Database Vault is not installed, review the roles and profiles in the database and the assignment of users to these, for appropriateness and completeness of the access permitted and denied each type of user.  If appropriate and complete, this is not a finding.\n\nIf the access permitted and denied each type of user is inappropriate or incomplete, this is a finding.\n\nFollowing are code examples for reviewing roles, profiles, etc.\n\nFind out what role the users have:\n        select * from dba_role_privs where granted_role = '@role'\n\nList all roles given to a user:\n        select * from dba_role_privs where grantee = '@username';\n\nUse the following query to list all privileges given to a user:\n        select\n          lpad(' ', 2*level) || granted_role \"User roles and privileges\"\n        from\n          (\n          /* THE USERS */\n            select \n              null     grantee, \n              username granted_role\n            from \n              dba_users\n            where\n              username like upper('&enter_username')\n          /* THE ROLES TO ROLES RELATIONS */ \n          union\n            select \n              grantee,\n              granted_role\n            from\n              dba_role_privs\n          /* THE ROLES TO PRIVILEGE RELATIONS */ \n          union\n            select\n              grantee,\n              privilege\n            from\n              dba_sys_privs\n          )\n        start with grantee is null\n        connect by grantee = prior granted_role;\n\n\nList which tables a certain role gives SELECT access to using the query:\n        select * from role_tab_privs where role='@role' and privilege = 'SELECT';\n\nList all tables a user can SELECT from using the query:\n        select * from dba_tab_privs \n        where GRANTEE ='@username' and privilege = 'SELECT';\n\nList all users who can SELECT on a particular table (either through being given a relevant role or through a direct grant - e.g., grant select on a table to Joe). The result of this query should also show through which role the user has this access or whether it was a direct grant.\n\n        select \n                Grantee,'Granted Through Role' as Grant_Type, \n                role, \n                table_name\n        from role_tab_privs rtp, dba_role_privs drp\n        where rtp.role = drp.granted_role\n        and table_name = '@TABLENAME' \n        union\n        select \n                Grantee,\n                'Direct Grant' as Grant_type,\n                null as role, \n                table_name\n        from dba_tab_privs\n        where table_name = '@TABLENAME' ;","fixText":"If Oracle Database Vault is in use, use it to configure the correct access privileges for each type of user.\n\nIf Oracle Database Vault is not in use, configure the correct access privileges for each type of user using Roles and Profiles.","ccis":["CCI-000213"]},{"vulnId":"V-219751","ruleId":"SV-219751r960879_rule","severity":"medium","ruleTitle":"The DBMS must provide audit record generation capability for organization-defined auditable events within the database.","description":"Audit records can be generated from various components within the information system. (e.g., network interface, hard disk, modem, etc.). From an application perspective, certain specific application functionalities may be audited as well.\n\nThe 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 (i.e., auditable events, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked).\n\nOrganizations define which application components shall provide auditable events. \n\nThe DBMS must provide auditing for the list of events defined by the organization or risk negatively impacting forensic investigations into malicious behavior in the information system. Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, certain specific application functionalities may be audited, as well.\n\nThe 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 (i.e., auditable events, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked).\n\nOrganizations may define the organizational personnel accountable for determining which application components shall provide auditable events.\n\nAuditing provides accountability for changes made to the DBMS configuration or its objects and data. It provides a means to discover suspicious activity and unauthorized changes. Without auditing, a compromise may go undetected and without a means to determine accountability.\n\nThe Department of Defense has established the following as the minimum set of auditable events.  Most can be audited via Oracle settings; some may require OS settings.\n\n- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g. classification levels). \n\n- Successful and unsuccessful logon attempts, privileged activities or other system level access\n\n- Starting and ending time for user access to the system, concurrent logons from different workstations.\n\n- Successful and unsuccessful accesses to objects.\n\n- All program initiations.\n\n- All direct access to the information system.\n\n- All account creations, modifications, disabling, and terminations. \n\n- All kernel module loads, unloads, and restarts.","checkContent":"Verify, using vendor and system documentation if necessary, that the DBMS is configured to use Oracle's auditing features, or that a third-party product or custom code is deployed and configured to satisfy this requirement.\n\nIf a third-party product or custom code is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding.\n\nThe remainder of this Check is applicable specifically where Oracle auditing is in use.\n\nTo see if Oracle is configured to capture audit data, enter the following SQLPlus command:\nSHOW PARAMETER AUDIT_TRAIL\nor the following SQL query:\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\nIf Oracle returns the value 'NONE', this is a finding.\n\nTo confirm that 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.","fixText":"Configure the DBMS's auditing to audit organization-defined auditable events. If preferred, use a third-party tool. The tool must provide the minimum capability to audit the required events.\n\nIf using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows.\n\nUse this query to ensure auditable events are captured:\nALTER SYSTEM SET AUDIT_TRAIL=<audit trail type> SCOPE=SPFILE;\nAudit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nFor more information on the configuration of auditing, please refer to \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand \"Verifying Security Access with Auditing\" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand \"27 DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm\n\nIf the organization-defined audit requirements are not covered by the default audit options, deploy and configure Fine-Grained Auditing. For details, refer to Oracle documentation, at the locations above.","ccis":["CCI-000169"]},{"vulnId":"V-219752","ruleId":"SV-219752r960882_rule","severity":"medium","ruleTitle":"The DBMS must allow designated organizational personnel to select which auditable events are to be audited by the database.","description":"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 (i.e., auditable events, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked).\n\nIf the list of auditable events is not configurable, events that should be caught by auditing may be missed.  This may allow malicious activity to be overlooked.","checkContent":"Check DBMS settings and documentation to determine whether designated personnel are able to select which auditable events are being audited.  If designated personnel are not able to configure auditable events, this is a finding.","fixText":"Configure the DBMS's settings to allow designated personnel to select which auditable events are audited.\n\nNote the following:\n    In Oracle, any user can configure auditing for the objects in his or her own schema by using the AUDIT statement. To undo the audit configuration for an object, the user can use the NOAUDIT statement. No additional privileges are needed to perform this task.\n    To audit objects in another schema, the user must have the AUDIT ANY system privilege.\n    To audit system privileges, the user must have the AUDIT SYSTEM privilege.\n\nFor more information on the configuration of auditing, please refer to \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand \"Verifying Security Access with Auditing\" in the Oracle Database Security Guide:  http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand \"27 DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm","ccis":["CCI-000171"]},{"vulnId":"V-219753","ruleId":"SV-219753r960885_rule","severity":"medium","ruleTitle":"The DBMS must generate audit records for the DoD-selected list of auditable events, to the extent such information is available.","description":"Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, certain specific application functionalities may be audited, as well.\n\nThe 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 (i.e., auditable events, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked).\n\nOrganizations may define the organizational personnel accountable for determining which application components shall provide auditable events.\n\nAuditing provides accountability for changes made to the DBMS configuration or its objects and data. It provides a means to discover suspicious activity and unauthorized changes. Without auditing, a compromise may go undetected and without a means to determine accountability.\n\nThe Department of Defense has established the following as the minimum set of auditable events.  Most can be audited via Oracle settings; some may require OS settings.\n\n- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g. classification levels). \n\n- Successful and unsuccessful logon attempts, privileged activities or other system level access\n\n- Starting and ending time for user access to the system, concurrent logons from different workstations.\n\n- Successful and unsuccessful accesses to objects.\n\n- All program initiations.\n\n- All direct access to the information system.\n\n- All account creations, modifications, disabling, and terminations. \n\n- All kernel module loads, unloads, and restarts.","checkContent":"Check DBMS and OS settings to determine if auditing is being performed on the events on the DoD-selected list of auditable events.  If auditing is not being performed for any of the events on the DoD-selected list of auditable events, this is a finding.","fixText":"Configure the DBMS's auditing settings to include auditing of events on the DoD-selected list of auditable events.\n\nFor more information on the configuration of auditing in the DBMS, please refer to \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand \"Verifying Security Access with Auditing\" in the Oracle Database Security Guide:  http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand \"27 DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm","ccis":["CCI-000172"]},{"vulnId":"V-219754","ruleId":"SV-219754r960891_rule","severity":"medium","ruleTitle":"The DBMS must produce audit records containing sufficient information to establish what type of events occurred.","description":"Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes:  timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. \n\nDatabase software is capable of a range of actions on data stored within the database. It's important, for accurate forensic analysis, to know exactly what actions were performed. This requires specific information regarding the event type an audit record is referring to. If event type information is not recorded and stored with the audit record, the record itself is of very limited use.","checkContent":"Verify, using vendor and system documentation if necessary, that the DBMS is configured to use Oracle's auditing features, or that a third-party product or custom code is deployed and configured to satisfy this requirement.\n\nIf a third-party product or custom code is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding.\n\nThe remainder of this Check is applicable specifically where Oracle auditing is in use.\n\nTo see if Oracle is configured to capture audit data, enter the following SQLPlus command:\nSHOW PARAMETER AUDIT_TRAIL\nor the following SQL query:\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\nIf Oracle returns the value \"NONE\", this is a finding.\n\nTo confirm that Oracle audit is capturing sufficient information to establish the identity of the user/subject or process, perform a successful auditable action and an auditable action that results in an SQL error, and then view the results in the SYS.AUD$ table or the audit file, whichever is in use.  If no ACTION#, or the wrong value, is returned for the auditable actions just performed, this is a finding.","fixText":"Configure the DBMS's auditing to audit standard and organization-defined auditable events, the audit record to include what type of event occurred. If preferred, use a third-party or custom tool. \n\nIf using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows.\n\nUse this query to ensure auditable events are captured:\nALTER SYSTEM SET AUDIT_TRAIL=<audit trail type> SCOPE=SPFILE;\nAudit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nFor more information on the configuration of auditing, please refer to 'Auditing Database Activity' in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand 'Verifying Security Access with Auditing' in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand '27 DBMS_AUDIT_MGMT' in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm","ccis":["CCI-000130"]},{"vulnId":"V-219755","ruleId":"SV-219755r960894_rule","severity":"medium","ruleTitle":"The DBMS must produce audit records containing sufficient information to establish when (date and time) the events occurred.","description":"Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes:  timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nDatabase software is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly when specific actions were performed. This requires the date and time an audit record is referring to. If date and time information is not recorded and stored with the audit record, the record itself is of very limited use.","checkContent":"Verify, using vendor and system documentation if necessary, that the DBMS is configured to use Oracle's auditing features, or that a third-party product or custom code is deployed and configured to satisfy this requirement.\n\nIf a third-party product or custom code is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding.\n\nThe remainder of this Check is applicable specifically where Oracle auditing is in use.\n\nTo see if Oracle is configured to capture audit data, enter the following SQLPlus command:\nSHOW PARAMETER AUDIT_TRAIL\nor the following SQL query:\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\nIf Oracle returns the value 'NONE', this is a finding.\n\nTo confirm that Oracle audit is capturing sufficient information to establish when events occurred, perform a successful auditable action and an auditable action that results in an SQL error, and then view the results in the SYS.AUD$ table or the audit file, whichever is in use.  If no timestamp, or the wrong value, is returned for the auditable actions just performed, this is a finding.","fixText":"Configure the DBMS's auditing to audit standard and organization-defined auditable events, the audit record to include the date and time of any user/subject or process associated with the event. If preferred, use a third-party or custom tool. \n\nIf using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows.\n\nUse this query to ensure auditable events are captured:\nALTER SYSTEM SET AUDIT_TRAIL=<audit trail type> SCOPE=SPFILE;\nAudit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nFor more information on the configuration of auditing, please refer to \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand \"Verifying Security Access with Auditing\" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand \"27 DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm","ccis":["CCI-000131"]},{"vulnId":"V-219756","ruleId":"SV-219756r960897_rule","severity":"medium","ruleTitle":"The DBMS must produce audit records containing sufficient information to establish where the events occurred.","description":"Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes:  timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. \n\nWithout sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered.","checkContent":"Verify, using vendor and system documentation if necessary, that the DBMS is configured to use Oracle's auditing features, or that a third-party product or custom code is deployed and configured to satisfy this requirement.\n\nIf a third-party product or custom code is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding.\n\nThe remainder of this Check is applicable specifically where Oracle auditing is in use.\n\nTo see if Oracle is configured to capture audit data, enter the following SQLPlus command:\nSHOW PARAMETER AUDIT_TRAIL\nor the following SQL query:\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\nIf Oracle returns the value 'NONE', this is a finding.\n\nTo confirm that Oracle audit is capturing sufficient information to establish where events occurred, perform a successful auditable action and an auditable action that results in an SQL error, and then view the results in the SYS.AUD$ table or the audit file, whichever is in use.  If no DB ID or Object Creator or Object Name, or the wrong values, are returned for the auditable actions just performed, this is a finding.  If correct values for User Host and Terminal are not returned when applicable, this is a finding.","fixText":"Configure the DBMS's auditing to audit standard and organization-defined auditable events, the audit record to include where the event occurred. If preferred, use a third-party or custom tool.\n\nIf using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows.\n\nUse this query to ensure auditable events are captured:\nALTER SYSTEM SET AUDIT_TRAIL=<audit trail type> SCOPE=SPFILE;\nAudit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nFor more information on the configuration of auditing, please refer to \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand \"Verifying Security Access with Auditing\" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand \"27 DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm","ccis":["CCI-000132"]},{"vulnId":"V-219757","ruleId":"SV-219757r960900_rule","severity":"medium","ruleTitle":"The DBMS must produce audit records containing sufficient information to establish the sources (origins) of the events.","description":"Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes, but is not limited to:  timestamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, file names involved, access control or flow control rules invoked. \n\nWithout information establishing the source of activity, the value of audit records from a forensics perspective is questionable.","checkContent":"Verify, using vendor and system documentation if necessary, that the DBMS is configured to use Oracle's auditing features, or that a third-party product or custom code is deployed and configured to satisfy this requirement.\n\nIf a third-party product or custom code is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding.\n\nThe remainder of this Check is applicable specifically where Oracle auditing is in use.\n\nTo see if Oracle is configured to capture audit data, enter the following SQLPlus command:\nSHOW PARAMETER AUDIT_TRAIL\nor the following SQL query:\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\nIf Oracle returns the value 'NONE', this is a finding.\n\nTo confirm that Oracle audit is capturing sufficient information to establish the source of events, perform a successful auditable action and an auditable action that results in an SQL error, and then view the results in the SYS.AUD$ table or the audit file, whichever is in use.  If correct values for User ID, User Host, and Terminal are not returned when applicable, this is a finding.","fixText":"Configure the DBMS's auditing to audit standard and organization-defined auditable events, the audit record to include the source of the event. If preferred, use a third-party or custom tool.\n\nIf using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows.\n\nUse this query to ensure auditable events are captured:\nALTER SYSTEM SET AUDIT_TRAIL=<audit trail type> SCOPE=SPFILE;\nAudit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nFor more information on the configuration of auditing, please refer to \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand \"Verifying Security Access with Auditing\" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand \"27 DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm","ccis":["CCI-000133"]},{"vulnId":"V-219758","ruleId":"SV-219758r960903_rule","severity":"medium","ruleTitle":"The DBMS must produce audit records containing sufficient information to establish the outcome (success or failure) of the events.","description":"Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes, but is not limited to: timestamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, file names involved, access control, or flow control rules invoked. \n\nSuccess and failure indicators ascertain the outcome of a particular event. As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. Without knowing the outcome of audit events, it is very difficult to accurately recreate the series of events during forensic analysis.","checkContent":"Verify, using vendor and system documentation if necessary, that the DBMS is configured to use Oracle's auditing features, or that a third-party product or custom code is deployed and configured to satisfy this requirement.\n\nIf a third-party product or custom code is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding.\n\nThe remainder of this Check is applicable specifically where Oracle auditing is in use.\n\nTo see if Oracle is configured to capture audit data, enter the following SQLPlus command:\nSHOW PARAMETER AUDIT_TRAIL\nor the following SQL query:\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\nIf Oracle returns the value 'NONE', this is a finding.\n\nTo confirm that Oracle audit is capturing sufficient information to establish outcomes, perform a successful auditable action and an auditable action that results in an SQL error, and then view the results in the SYS.AUD$ table or the audit file, whichever is in use.  If no return code or other outcome information is returned for the auditable action just performed, this is a finding. If error is indicated for the successful action, this is a finding. If no error is indicated for the unsuccessful action, this is a finding.","fixText":"Configure the DBMS's auditing to audit standard and organization-defined auditable events, the audit record to include the outcome. If preferred, use a third-party or custom tool.\n\nIf using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows.\n\nUse this query to ensure auditable events are captured:\nALTER SYSTEM SET AUDIT_TRAIL=<audit trail type> SCOPE=SPFILE;\nAudit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nFor more information on the configuration of auditing, please refer to \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand \"Verifying Security Access with Auditing\" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand \"27 DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm","ccis":["CCI-000134"]},{"vulnId":"V-219759","ruleId":"SV-219759r960906_rule","severity":"medium","ruleTitle":"The DBMS must produce audit records containing sufficient information to establish the identity of any user/subject or process associated with the event.","description":"Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes:  timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. \n\nDatabase software is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly who performed a given action.  If user identification information is not recorded and stored with the audit record, the record itself is of very limited use.","checkContent":"Verify, using vendor and system documentation if necessary, that the DBMS is configured to use Oracle's auditing features, or that a third-party product or custom code is deployed and configured to satisfy this requirement.\n\nIf a third-party product or custom code is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding.\n\nThe remainder of this Check is applicable specifically where Oracle auditing is in use.\n\nTo see if Oracle is configured to capture audit data, enter the following SQLPlus command:\nSHOW PARAMETER AUDIT_TRAIL\nor the following SQL query:\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\nIf Oracle returns the value \"NONE\", this is a finding.\n\nTo confirm that Oracle audit is capturing sufficient information to establish the identity of the user/subject or process, perform a successful auditable action and an auditable action that results in an SQL error, and then view the results in the SYS.AUD$ table or the audit file, whichever is in use.  If no user ID, or the wrong value, is returned for the auditable actions just performed, this is a finding.","fixText":"Configure the DBMS's auditing to audit standard and organization-defined auditable events, the audit record to include the identity of any user/subject or process associated with the event. If preferred, use a third-party or custom tool. \n\nIf using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows.\n\nUse this query to ensure auditable events are captured:\nALTER SYSTEM SET AUDIT_TRAIL=<audit trail type> SCOPE=SPFILE;\nAudit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nFor more information on the configuration of auditing, please refer to \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand \"Verifying Security Access with Auditing\" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand \"27 DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm","ccis":["CCI-001487"]},{"vulnId":"V-219760","ruleId":"SV-219760r960909_rule","severity":"medium","ruleTitle":"The DBMS must include organization-defined additional, more detailed information in the audit records for audit events identified by type, location, or subject.","description":"Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes:  timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked.\n\nIn addition, the application must have the capability to include organization-defined additional, more detailed information in the audit records for audit events. These events may be identified by type, location, or subject. \n\nAn example of detailed information the organization may require in audit records is full-text recording of privileged commands or the individual identities of group account users.\n\nSome organizations may determine that more detailed information is required for specific database event types.  If this information is not available, it could negatively impact forensic investigations into user actions or other malicious events.","checkContent":"Verify, using vendor and system documentation if necessary, that the DBMS is configured to use Oracle's auditing features, or that a third-party product or custom code is deployed and configured to satisfy this requirement.\n\nIf a third-party product or custom code is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding.\n\nThe remainder of this Check is applicable specifically where Oracle auditing is in use.\n\nTo see if Oracle is configured to capture audit data, enter the following SQLPlus command:\nSHOW PARAMETER AUDIT_TRAIL\nor the following SQL query:\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\nIf Oracle returns the value \"NONE\", this is a finding.\n\nCompare the organization-defined auditable events with the Oracle documentation to determine whether standard auditing covers all the requirements. If it does, this is not a finding.\n\nCompare those organization-defined auditable events that are not covered by the standard auditing, with the existing Fine-Grained Auditing (FGA) specifications returned by the following query:\nSELECT * FROM SYS.DBA_FGA_AUDIT_TRAIL;\nIf any such auditable event is not covered by the existing FGA specifications, this is a finding.","fixText":"Either configure the DBMS's auditing to audit organization-defined auditable events; or if preferred, use a third-party or custom tool. The tool must provide the minimum capability to audit the required events.\n\nIf using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows.\n\nUse this query to ensure auditable events are captured:\nALTER SYSTEM SET AUDIT_TRAIL=<audit trail type> SCOPE=SPFILE;\nAudit trail type can be \"OS\", \"DB\", \"DB,EXTENDED\", \"XML\" or \"XML,EXTENDED\".\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nIf the organization-defined additional audit requirements are not covered by the default audit options, deploy and configure Fine-Grained Auditing. For details, refer to Oracle documentation, at the location above.  \n\nFor more information on the configuration of auditing, please refer to \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand \"Verifying Security Access with Auditing\" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand \"27 DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm","ccis":["CCI-000135"]},{"vulnId":"V-219761","ruleId":"SV-219761r960930_rule","severity":"medium","ruleTitle":"The DBMS must protect audit information from any type of unauthorized access.","description":"If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult, if not impossible, to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc.\n\nThis requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions utilizing file system protections and limiting log data location. \n\nAdditionally, applications with user interfaces to audit records must not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.","checkContent":"Review locations of audit logs, both internal to the database and database audit logs located at the operating system-level. Verify there are appropriate controls and permissions to protect the audit information from unauthorized access. If appropriate controls and permissions do not exist, this is a finding.\n\n- - - - -\n\nDBA_TAB_PRIVS describes all object grants in the database.  Check to see who has permissions on the AUD$ table.  \n\nRelated View\n\nDBA_TAB_PRIVS describes the object grants for which the current user is the object owner, grantor, or grantee.\nColumn      Datatype      NULL      Description\nGRANTEE  VARCHAR2(30)  NOT NULL  Name of the user to whom access was granted\nOWNER      VARCHAR2(30)  NOT NULL  Owner of the object\nTABLE_NAME  VARCHAR2(30)  NOT NULL  Name of the object\nGRANTOR  VARCHAR2(30)  NOT NULL  Name of the user who performed the grant\nPRIVILEGE  VARCHAR2(40)  NOT NULL  Privilege on the object\nGRANTABLE  VARCHAR2(3)             Indicates whether the privilege was granted with the GRANT OPTION (YES) or not (NO)\nHIERARCHY  VARCHAR2(3)             Indicates whether the privilege was granted with the HIERARCHY OPTION (YES) or not (NO)\n\nsqlplus connect as sysdba;\nSQL>  SELECT * FROM DBA_TAB_PRIVS where table_name = 'AUD$';\nSQL>  SELECT * FROM DBA_COL_PRIVS where table_name = 'AUD$';","fixText":"Add controls and modify permissions to protect database audit log data from unauthorized access, whether stored in the database itself or at the OS level.\n\nRevoke access to the AUD$ table to anyone who should not have access to it.","ccis":["CCI-000162"]},{"vulnId":"V-219762","ruleId":"SV-219762r960933_rule","severity":"medium","ruleTitle":"The DBMS must protect audit information from unauthorized modification.","description":"If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. \n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification.  \n\nThis requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions and limiting log data locations.  \n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. \n\nModification of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.","checkContent":"Review locations of audit logs, both internal to the database and database audit logs located at the operating system-level. Verify there are appropriate controls and permissions to protect the audit information from unauthorized modification. If appropriate controls and permissions do not exist, this is a finding.\n- - - - - -\nDBA_TAB_PRIVS describes all object grants in the database.  Check to see who has permissions on the AUD$ table.  \n\nRelated View\n\nDBA_TAB_PRIVS describes the object grants for which the current user is the object owner, grantor, or grantee.\nColumn      Datatype      NULL      Description\nGRANTEE  VARCHAR2(30)  NOT NULL  Name of the user to whom access was granted\nOWNER      VARCHAR2(30)  NOT NULL  Owner of the object\nTABLE_NAME  VARCHAR2(30)  NOT NULL  Name of the object\nGRANTOR  VARCHAR2(30)  NOT NULL  Name of the user who performed the grant\nPRIVILEGE  VARCHAR2(40)  NOT NULL  Privilege on the object\nGRANTABLE  VARCHAR2(3)             Indicates whether the privilege was granted with the GRANT OPTION (YES) or not (NO)\nHIERARCHY  VARCHAR2(3)             Indicates whether the privilege was granted with the HIERARCHY OPTION (YES) or not (NO)\n\nsqlplus connect as sysdba;\n\nSQL>  SELECT GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE\n      FROM DBA_COL_PRIVS where table_name = 'AUD$';","fixText":"Add controls and modify permissions to protect database audit log data from unauthorized modification, whether stored in the database itself or at the OS level.\n- - - - -\nRevoke access to the AUD$ table to anyone who you do not want to have access to the AUD$ table.\n\nIn the check we looked for all users who had access to the AUD$ table. To fix this, use the REVOKE command to revoke access to users who should not have access to the audit data.\n\nREVOKE statement\n\nUse the REVOKE statement to remove permissions from a specific user or from all users to perform actions on database objects.\nThe following types of permissions can be revoked:\n    Delete data from a specific table.\n    Insert data into a specific table.\n    Create a foreign key reference to the named table or to a subset of columns from a table.\n    Select data from a table, view, or a subset of columns in a table.\n    Create a trigger on a table.\n    Update data in a table or in a subset of columns in a table.\n    Run a specified routine (function or procedure).\n\nIf a user named FRED had access to the AUD$ table and you want to revoke that access, use the following command. The syntax that you use for the REVOKE statement for tables is as follows:\n\nREVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees\n\n\nSQL>REVOKE SELECT ON TABLE AUD$ FROM FRED; \n\nRevoking a privilege without specifying a column list revokes the privilege for all of the columns in the table.\nSyntax for routines\n\ntable-privileges include\n\n  DELETE |\n  INSERT |\n  REFERENCES [column list] |\n  SELECT [column list] |\n  TRIGGER |\n  UPDATE [column list] \n\ncolumn list\n\n  ( column-identifier {, column-identifier}* ) \n\nUse the ALL PRIVILEGES privilege type to revoke all of the permissions from the user for the specified table. You can also revoke one or more table privileges by specifying a privilege-list.\n\nUse the DELETE privilege type to revoke permission to delete rows from the specified table.\n\nUse the INSERT privilege type to revoke permission to insert rows into the specified table.\n\nUse the REFERENCES privilege type to revoke permission to create a foreign key reference to the specified table. If a column list is specified with the REFERENCES privilege, the permission is revoked on only the foreign key reference to the specified columns.\n\nUse the SELECT privilege type to revoke permission to perform SELECT statements on a table or view. If a column list is specified with the SELECT privilege, the permission is revoked on only those columns. If no column list is specified, then the privilege is valid on all of the columns in the table.\n\nUse the TRIGGER privilege type to revoke permission to create a trigger on the specified table.\n\nUse the UPDATE privilege type to revoke permission to use the UPDATE statement on the specified table. If a column list is specified, the permission is revoked only on the specified columns.\ngrantees\n\n  { authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] *\n\nYou can revoke the privileges from specific users or from all users. Use the keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and from individual users are independent privileges. For example, a SELECT privilege on table t is granted to both PUBLIC and to the authorization ID harry. The SELECT privilege is later revoked from the authorization ID 'Harry', but the authorization ID 'Harry' can access the table through the PUBLIC privilege.\n\nRestriction: You cannot revoke the privileges of the owner of an object.\nroutine-designator\n\n  {\n   qualified-name [ signature ]\n  }\n\nCascading object dependencies\n\nFor views, triggers, and constraints, if the privilege on which the object depends on is revoked, the object is automatically dropped. Derby does not try to determine if you have other privileges that can replace the privileges that are being revoked. For more information, see \"SQL standard authorization\" in the Java DB Developer's Guide.\nLimitations\n\nThe following limitations apply to the REVOKE statement:\n\nTable-level privileges\n    All of the table-level privilege types for a specified grantee and table ID are stored in one row in the SYSTABLEPERMS system table. For example, when user2 is granted the SELECT and DELETE privileges on table user1.t1, a row is added to the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The remaining privilege type fields are set to N.\n\n    When a grantee creates an object that relies on one of the privilege types, the Derby engine tracks the dependency of the object on the specific row in the SYSTABLEPERMS table. For example, user2 creates the view v1 by using the statement SELECT * FROM user1.t1; the dependency manager tracks the dependency of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1). The dependency manager knows only that the view is dependent on a privilege type in that specific row but does not track exactly which privilege type the view is dependent on.\n\n    When a REVOKE statement for a table-level privilege is issued for a grantee and table ID, all of the objects that are dependent on the grantee and table ID are dropped. For example, if user1 revokes the DELETE privilege on table t1 from user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1, and the view is dropped, even though the view is not dependent on the DELETE privilege for GRANTEE(user2), TABLEID(user1.t1).\n\nColumn-level privileges\n    Only one type of privilege for a specified grantee and table ID are stored in one row in the SYSCOLPERMS system table. For example, when user2 is granted the SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13.\n\n    When a grantee creates an object that relies on the privilege type and the subset of columns in a table ID, the Derby engine tracks the dependency of the object on the specific row in the SYSCOLPERMS table. For example, user2 creates the view v1 by using the statement SELECT c11 FROM user1.t1; the dependency manager tracks the dependency of view v1 on the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that the view is dependent on the SELECT privilege type but does not track exactly which columns the view is dependent on.\n\n    When a REVOKE statement for a column-level privilege is issued for a grantee, table ID, and type, all of the objects that are dependent on the grantee, table ID, and type are dropped. For example, if user1 revokes the SELECT privilege on column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1, and the view is dropped, even though the view is not dependent on the column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S).\n\nRevoke examples\nTo revoke the SELECT privilege on table t from the authorization IDs 'Maria' and 'Harry', use the following syntax:\n\nSQL>REVOKE SELECT ON TABLE t FROM maria,harry \n\nTo revoke the UPDATE and TRIGGER privileges on table t from the authorization IDs 'Anita' and 'Zhi', use the following syntax:\n\nSQL>REVOKE UPDATE, TRIGGER ON TABLE t FROM anita,zhi \n\nTo revoke the SELECT privilege on table s.v from all users, use the following syntax:\n\nSQL>REVOKE SELECT ON TABLE s.v FROM PUBLIC\n\nTo revoke the UPDATE privilege on columns c1 and c2 of table s.v from all users, use the following syntax:\n\nSQL>REVOKE UPDATE (c1,c2) ON TABLE s.v FROM PUBLIC\n\nTo revoke the EXECUTE privilege on procedure p from the authorization ID 'George', use the following syntax:\nSQL>REVOKE EXECUTE ON PROCEDURE p FROM george RESTRICT","ccis":["CCI-000163"]},{"vulnId":"V-219763","ruleId":"SV-219763r960936_rule","severity":"medium","ruleTitle":"The DBMS must protect audit information from unauthorized deletion.","description":"If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. \n\nTo ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods which will depend upon system architecture and design.  \n\nSome commonly employed methods include:  ensuring log files enjoy the proper file system permissions utilizing file system protections; restricting access; and backing up log data to ensure log data is retained.  \n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. \n\nDeletion of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.","checkContent":"Review locations of audit logs, both internal to the database and database audit logs located at the operating system-level. Verify there are appropriate controls and permissions to protect the audit information from unauthorized deletion. If appropriate controls and permissions do not exist, this is a finding.\n- - - - -\nDBA_TAB_PRIVS describes all object grants in the database.  Check to see who has permissions on the AUD$ table.  \n\nRelated View\n\nDBA_TAB_PRIVS describes the object grants for which the current user is the object owner, grantor, or grantee.\nColumn      Datatype      NULL      Description\nGRANTEE  VARCHAR2(30)  NOT NULL  Name of the user to whom access was granted\nOWNER      VARCHAR2(30)  NOT NULL  Owner of the object\nTABLE_NAME  VARCHAR2(30)  NOT NULL  Name of the object\nGRANTOR  VARCHAR2(30)  NOT NULL  Name of the user who performed the grant\nPRIVILEGE  VARCHAR2(40)  NOT NULL  Privilege on the object\nGRANTABLE  VARCHAR2(3)             Indicates whether the privilege was granted with the GRANT OPTION (YES) or not (NO)\nHIERARCHY  VARCHAR2(3)             Indicates whether the privilege was granted with the HIERARCHY OPTION (YES) or not (NO)\n\nsqlplus connect as sysdba;\n\nSQL>  SELECT GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE\n      FROM DBA_COL_PRIVS where table_name = 'AUD$';","fixText":"Add controls and modify permissions to protect database audit log data from unauthorized deletion, whether stored in the database itself or at the OS level.\n- - - - -\nRevoke access to the AUD$ table to anyone who you do not want to have access to the AUD$ table.\n\nIn the check we looked for all users who had access to the AUD$ table. To fix this, use the REVOKE command to revoke access to users who should not have access to the audit data.\n\nREVOKE statement\n\nUse the REVOKE statement to remove permissions from a specific user or from all users to perform actions on database objects.\nThe following types of permissions can be revoked:\n\n    Delete data from a specific table.\n    Insert data into a specific table.\n    Create a foreign key reference to the named table or to a subset of columns from a table.\n    Select data from a table, view, or a subset of columns in a table.\n    Create a trigger on a table.\n    Update data in a table or in a subset of columns in a table.\n    Run a specified routine (function or procedure).\n\nIf a user named FRED had access to the AUD$ table and you want to revoke that access use the following command. The syntax that you use for the REVOKE statement for tables is as follows:\n\nREVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees\n\n\nSQL>REVOKE SELECT ON TABLE AUD$ FROM FRED; \n\nRevoking a privilege without specifying a column list revokes the privilege for all of the columns in the table.\nSyntax for routines\n\ntable-privileges include\n\n  DELETE |\n  INSERT |\n  REFERENCES [column list] |\n  SELECT [column list] |\n  TRIGGER |\n  UPDATE [column list] \n\ncolumn list\n\n  ( column-identifier {, column-identifier}* ) \n\nUse the ALL PRIVILEGES privilege type to revoke all of the permissions from the user for the specified table. You can also revoke one or more table privileges by specifying a privilege-list.\n\nUse the DELETE privilege type to revoke permission to delete rows from the specified table.\n\nUse the INSERT privilege type to revoke permission to insert rows into the specified table.\n\nUse the REFERENCES privilege type to revoke permission to create a foreign key reference to the specified table. If a column list is specified with the REFERENCES privilege, the permission is revoked on only the foreign key reference to the specified columns.\n\nUse the SELECT privilege type to revoke permission to perform SELECT statements on a table or view. If a column list is specified with the SELECT privilege, the permission is revoked on only those columns. If no column list is specified, then the privilege is valid on all of the columns in the table.\n\nUse the TRIGGER privilege type to revoke permission to create a trigger on the specified table.\n\nUse the UPDATE privilege type to revoke permission to use the UPDATE statement on the specified table. If a column list is specified, the permission is revoked only on the specified columns.\ngrantees\n\n  { authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] *\n\nYou can revoke the privileges from specific users or from all users. Use the keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and from individual users are independent privileges. For example, a SELECT privilege on table t is granted to both PUBLIC and to the authorization ID harry. The SELECT privilege is later revoked from the authorization ID 'Harry', but the authorization ID 'Harry' can access the table through the PUBLIC privilege.\n\nRestriction: You cannot revoke the privileges of the owner of an object.\nroutine-designator\n\n  {\n   qualified-name [ signature ]\n  }\n\nCascading object dependencies\n\nFor views, triggers, and constraints, if the privilege on which the object depends on is revoked, the object is automatically dropped. Derby does not try to determine if you have other privileges that can replace the privileges that are being revoked. For more information, see \"SQL standard authorization\" in the Java DB Developer's Guide.\nLimitations\n\nThe following limitations apply to the REVOKE statement:\n\nTable-level privileges\n    All of the table-level privilege types for a specified grantee and table ID are stored in one row in the SYSTABLEPERMS system table. For example, when user2 is granted the SELECT and DELETE privileges on table user1.t1, a row is added to the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The remaining privilege type fields are set to N.\n\n    When a grantee creates an object that relies on one of the privilege types, the Derby engine tracks the dependency of the object on the specific row in the SYSTABLEPERMS table. For example, user2 creates the view v1 by using the statement SELECT * FROM user1.t1; the dependency manager tracks the dependency of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1). The dependency manager knows only that the view is dependent on a privilege type in that specific row but does not track exactly which privilege type the view is dependent on.\n\n    When a REVOKE statement for a table-level privilege is issued for a grantee and table ID, all of the objects that are dependent on the grantee and table ID are dropped. For example, if user1 revokes the DELETE privilege on table t1 from user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1, and the view is dropped, even though the view is not dependent on the DELETE privilege for GRANTEE(user2), TABLEID(user1.t1).\n\nColumn-level privileges\n    Only one type of privilege for a specified grantee and table ID are stored in one row in the SYSCOLPERMS system table. For example, when user2 is granted the SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13.\n\n    When a grantee creates an object that relies on the privilege type and the subset of columns in a table ID, the Derby engine tracks the dependency of the object on the specific row in the SYSCOLPERMS table. For example, user2 creates the view v1 by using the statement SELECT c11 FROM user1.t; the dependency manager tracks the dependency of view v1 on the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that the view is dependent on the SELECT privilege type but does not track exactly which columns the view is dependent on.\n\n    When a REVOKE statement for a column-level privilege is issued for a grantee, table ID, and type, all of the objects that are dependent on the grantee, table ID, and type are dropped. For example, if user1 revokes the SELECT privilege on column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1, and the view is dropped, even though the view is not dependent on the column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S).\n\nRevoke examples\nTo revoke the SELECT privilege on table t from the authorization IDs 'Maria' and 'Harry', use the following syntax:\n\nSQL>REVOKE SELECT ON TABLE t FROM maria,harry \n\nTo revoke the UPDATE and TRIGGER privileges on table t from the authorization IDs 'Anita' and 'Zhi', use the following syntax:\n\nSQL>REVOKE UPDATE, TRIGGER ON TABLE t FROM anita,zhi \n\nTo revoke the SELECT privilege on table s.v from all users, use the following syntax:\n\nSQL>REVOKE SELECT ON TABLE s.v FROM PUBLIC\n\nTo revoke the UPDATE privilege on columns c1 and c2 of table s.v from all users, use the following syntax:\n\nSQL>REVOKE UPDATE (c1,c2) ON TABLE s.v FROM PUBLIC\n\nTo revoke the EXECUTE privilege on procedure p from the authorization ID 'George', use the following syntax:\nSQL>REVOKE EXECUTE ON PROCEDURE p FROM george RESTRICT","ccis":["CCI-000164"]},{"vulnId":"V-219764","ruleId":"SV-219764r960939_rule","severity":"medium","ruleTitle":"The DBMS must protect audit tools from unauthorized access.","description":"Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access.  \n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools.\n\nAudit tools include, but are not limited to, OS-provided audit tools, vendor-provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. \n\nIf an attacker were to gain access to audit tools, he could analyze audit logs for system weaknesses or weaknesses in the auditing itself.  An attacker could also manipulate logs to hide evidence of malicious activity.","checkContent":"Review access permissions to tools used to view or modify audit log data. These tools may include the DBMS itself or tools external to the database. If appropriate permissions and access controls to prevent unauthorized access are not applied to these tools, this is a finding.","fixText":"Add or modify access controls and permissions to tools used to view or modify audit log data. Tools must be accessible by authorized personnel only.","ccis":["CCI-001493"]},{"vulnId":"V-219765","ruleId":"SV-219765r960942_rule","severity":"medium","ruleTitle":"The DBMS must protect audit tools from unauthorized modification.","description":"Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data.  \n\nIf the tools are compromised it could provide attackers with the capability to manipulate log data. It is, therefore, imperative that audit tools be controlled and protected from unauthorized modification. \n\nAudit tools include, but are not limited to, OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. \n\nIf an attacker were to gain access to audit tools he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.","checkContent":"Review access permissions to tools used to view or modify audit log data. These tools may include the DBMS itself or tools external to the database. If appropriate permissions and access controls are not applied to prevent unauthorized modification of these tools, this is a finding.","fixText":"Add or modify access controls and permissions to tools used to view or modify audit log data. Tools must be modifiable by authorized personnel only.","ccis":["CCI-001494"]},{"vulnId":"V-219766","ruleId":"SV-219766r960945_rule","severity":"medium","ruleTitle":"The DBMS must protect audit tools from unauthorized deletion.","description":"Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. \n\nIt is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access.  \n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools.\n\nAudit tools include, but are not limited to, OS-provided audit tools, vendor-provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. \n\nIf an attacker were to gain access to audit tools, he could analyze audit logs for system weaknesses or weaknesses in the auditing itself.  An attacker could also manipulate logs to hide evidence of malicious activity.","checkContent":"Review access permissions to tools used to view or modify audit log data. These tools may include the DBMS itself or tools external to the database. If appropriate permissions and access controls are not applied to prevent unauthorized deletion of these tools, this is a finding.","fixText":"Add or modify access controls and permissions to tools used to view or modify audit log data. Only authorized personnel must be able to delete these tools.","ccis":["CCI-001495"]},{"vulnId":"V-219767","ruleId":"SV-219767r960960_rule","severity":"medium","ruleTitle":"Database objects must be owned by accounts authorized for ownership.","description":"Within the database, object ownership implies full privileges to the owned object including the privilege to assign access to the owned objects to other subjects. Unmanaged or uncontrolled ownership of objects can lead to unauthorized object grants and alterations, and unauthorized modifications to data. \n\nIf critical tables or other objects rely on unauthorized owner accounts, these objects can be lost when an account is removed.\n\nIt may be the case that there are accounts that are authorized to own synonyms, but no other objects. If this is so, it should be documented.","checkContent":"Review system documentation to identify accounts authorized to own database objects. Review accounts in DBMS that own objects.\n\nIf any database objects are found to be owned by users not authorized to own database objects, this is a finding.\n\n\nQuery the object DBA_OBJECTS to show the users who own objects in the database.  The query below will return all of the users who own objects.    \n\nsqlplus connect as sysdba\n\nSQL>select owner, object_type, count(*) from dba_objects\ngroup by owner, object_type\norder by owner, object_type;\n\nIf these owners are not authorized owners, select all of the objects these owners have generated and decide who they should belong to.  To make a list of  all of the objects, the unauthorized owner has to perform the following query.\n\nSQL>select * from dba_objects where owner =&unauthorized_owner;","fixText":"Update system documentation to include list of accounts authorized for object ownership.\n\nRe-assign ownership of authorized objects to authorized object owner accounts.","ccis":["CCI-001499"]},{"vulnId":"V-219768","ruleId":"SV-219768r960963_rule","severity":"medium","ruleTitle":"Default demonstration and sample databases, database objects, and applications must be removed.","description":"Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).\n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plugins not related to requirements or providing a wide array of functionality not required for the mission.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDemonstration and sample database objects and applications present publicly known attack points for malicious users. These demonstration and sample objects are meant to provide simple examples of coding specific functions and are not developed to prevent vulnerabilities from being introduced to the DBMS and host system.","checkContent":"If Oracle is hosted on a server that does not support production systems, and is designated for the deployment of samples and demonstrations, this is not applicable (NA).\n\nReview documentation and websites from Oracle and any other relevant vendors for vendor-provided demonstration or sample databases, database applications, schemas, objects, and files.\n\nReview the Oracle DBMS to determine if any of the demonstration and sample databases, schemas, database applications, or files are installed in the database or are included with the DBMS application. If any are present in the database or are included with the DBMS application, this is a finding.\n\nThe Oracle Default Sample Schema User Accounts are:\n\nBI\nOwns the Business Intelligence schema included in the Oracle Sample Schemas.\n\nHR\nManages the Human Resources schema. Schema stores information about the employees and the facilities of the company.\n\nOE\nManages the Order Entry schema. Schema stores product inventories and sales of the company's products through various channels.\n\nPM\nManages the Product Media schema. Schema contains descriptions and detailed information about each product sold by the company.\n\nIX\nManages the Information Exchange schema. Schema manages shipping through business-to-business (B2B) applications database.\n\nSH\nManages the Sales schema. Schema stores statistics to facilitate business decisions.\n\nSCOTT\nA demonstration account with a simple schema.","fixText":"Remove any demonstration and sample databases, database applications, objects, and files from the DBMS.\n\nTo remove an account and all objects owned by that account (using BI as an example):\nDROP USER BI CASCADE;\n\nTo remove objects without removing their owner, use the appropriate DROP statement (DROP TABLE, DROP VIEW, etc.).","ccis":["CCI-000381"]},{"vulnId":"V-219769","ruleId":"SV-219769r960963_rule","severity":"medium","ruleTitle":"Unused database components, DBMS software, and database objects must be removed.","description":"Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).  \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plug-ins not related to requirements or providing a wide array of functionality not required for the mission.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDemonstration and sample database objects and applications present publicly known attack points for malicious users. These demonstration and sample objects are meant to provide simple examples of coding specific functions and are not developed to prevent vulnerabilities from being introduced to the DBMS and host system.\n\nUnused and unnecessary DBMS components increase the attack vector for the DBMS by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced.","checkContent":"Run this query to produce a list of components and features installed with the database:\n\nSELECT comp_id, comp_name, version, status from dba_registry\nwhere comp_id not in ('CATALOG','CATPROC');\n\nReview the list.  If unused components are installed and are not documented and authorized, this is a finding.\n\nStarting with releases 11.1.0.7.x and above all products are installed by default and the option to customize the product/component \n\nselection is no longer possible with the exception of those listed here:\n\nOracle JVM,\nOracle Text,\nOracle Multimedia,\nOracle OLAP,\nOracle Spatial,\nOracle Label Security,\nOracle Application Express,\nOracle Database Vault","fixText":"If any components are required for operation of applications that will be accessing the DBMS, include them in the system documentation.\n\nYou cannot remove components, either via Database Configuration Assistant (DBCA) or manually once the database has been created.\n\nYou can, however, use DBCA to create a database and remove components during the creation process, before you create the database.  \n\nWhen using DBCA to create a custom database, select Database Template = Custom/Database Components.\nComponents that can be selected or de-selected are:\n\nOracle Text, \nOracle OLAP, \nOracle Spatial, \nOracle Label Security, \nSample Schemas, \nEnterprise Manager Repository, \nOracle Warehouse Builder, \nOracle Database Vault","ccis":["CCI-000381"]},{"vulnId":"V-219770","ruleId":"SV-219770r960963_rule","severity":"medium","ruleTitle":"Unused database components that are integrated in the DBMS and cannot be uninstalled must be disabled.","description":"Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).  \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plug-ins not related to requirements or providing a wide array of functionality not required for the mission.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nUnused, unnecessary DBMS components increase the attack surface of the DBMS by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced. Components of the system that are unused and cannot be uninstalled must be disabled.","checkContent":"Run this query to check to see what integrated components are installed in the database:\n\nSELECT parameter, value\nfrom v$option\nwhere parameter in \n(\n'Data Mining',\n'Oracle Database Vault',\n'OLAP',\n'Oracle Label Security',\n'Oracle Database Extensions for .NET',\n'Partitioning',\n'Real Application Testing'\n);\n\nThis will return all of the relevant database options and their status. TRUE means that the option is installed. If the option is not installed, the option will be set to FALSE.\n\nReview the options and check the system documentation to see what is required.  If all listed components are authorized to be in use, this is not a finding.\n\nIf any unused components or features are listed by the query as TRUE, this is a finding.","fixText":"In the system documentation list the integrated components required for operation of applications that will be accessing the DBMS.\n\nFor Oracle Database 11g Release 2, only the following components can be enabled/disabled:\n\nOracle Data Mining (dm)\nOracle Database Vault (dv)\nOracle OLAP (olap)\nOracle Label Security (lbac)\nOracle Database Extensions for .NET (ode_net_2)\nOracle Partitioning (partitioning)\nReal Application Testing (rat)\n\nUse the chopt utility (an Oracle-supplied operating system command that resides in the <Oracle Home path>/bin directory) to disable each option that should not be available.  The command format is \n\n            chopt <enable|disable> <option>\n\nwhere <option> is any of the abbreviatons in parentheses in the list above.  For example, to disable Real Application Testing, issue the following command at an OS prompt:\n\n            chopt disable rat\n\nRestart the Oracle service.\n\n(See My Oracle Support Document 948061.1 for more on the chopt command.)","ccis":["CCI-000381"]},{"vulnId":"V-219771","ruleId":"SV-219771r960963_rule","severity":"medium","ruleTitle":"Use of external executables must be  authorized.","description":"Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).  \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plugins not related to requirements or providing a wide array of functionality not required for the mission.\n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDBMS's may spawn additional external processes to execute procedures that are defined in the DBMS, but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than the DBMS and provide unauthorized access to the host system.","checkContent":"Review the database for definitions of application executable objects stored external to the database.\n\nDetermine if there are methods to disable use or access, or to remove definitions for external executable objects.\n\nVerify any application executable objects listed are authorized by the ISSO.\n\nIf any are not, this is a finding.\nIf the external executables or libraries are owned by ''SYS'' this is not a finding.\n\n\nTo check for external procedures, execute the following query, which will provide the libraries containing external procedures, the owners of those libraries, users that have been granted access to those libraries, and the privileges they have been granted. If there are owners other than the owners that Oracle provides, there may be executable objects stored either in the database or external to the database that are called by objects in the database. Check to see that those owners are authorized to access those libraries. If there are users that have been granted access to libraries provided by Oracle, check to see that they are authorized to access those libraries.\n\n(connect as sysdba)\nset linesize 130\ncolumn library_name format a25\ncolumn name format a15\ncolumn owner format a15\ncolumn grantee format a15\ncolumn privilege format a15\nselect library_name,owner, '' grantee, '' privilege\nfrom dba_libraries where file_spec is not null\nminus\n(\nselect library_name,o.name owner, '' grantee, '' privilege\nfrom dba_libraries l,\nsys.user$ o,\nsys.user$ ge,\nsys.obj$ obj,\nsys.objauth$ oa\nwhere l.owner=o.name\nand obj.owner#=o.user#\nand obj.name=l.library_name\nand oa.obj#=obj.obj#\nand ge.user#=oa.grantee#\nand l.file_spec is not null\n)\nunion all\nselect library_name,o.name owner, --obj.obj#,oa.privilege#,\nge.name grantee,\ntpm.name privilege\nfrom dba_libraries l,\nsys.user$ o,\nsys.user$ ge,\nsys.obj$ obj,\nsys.objauth$ oa,\nsys.table_privilege_map tpm\nwhere l.owner=o.name\nand obj.owner#=o.user#\nand obj.name=l.library_name\nand oa.obj#=obj.obj#\nand ge.user#=oa.grantee#\nand tpm.privilege=oa.privilege#\nand l.file_spec is not null\n/","fixText":"Disable use of or remove any external application executable object definitions that are not authorized.   \n\nDisable access to operating system commands from within the DBMS, or document the need for this capability.","ccis":["CCI-000381"]},{"vulnId":"V-219772","ruleId":"SV-219772r960963_rule","severity":"medium","ruleTitle":"Access to external executables must be disabled or restricted.","description":"The Oracle external procedure capability provides use of the Oracle process account outside the operation of the DBMS process. You can use it to submit and execute applications stored externally from the database under operating system controls. The external procedure process is the subject of frequent and successful attacks as it allows unauthenticated use of the Oracle process account on the operating system. As of Oracle version 11.1, the external procedure agent may be run directly from the database and not require use of the Oracle listener. This reduces the risk of unauthorized access to the procedure from outside of the database process.","checkContent":"Review the System Security Plan to determine if the use of the external procedure agent is authorized.\n\nReview the ORACLE_HOME/bin directory or search the ORACLE_BASE path for the executable extproc (UNIX) or extproc.exe (Windows).\n\nIf external procedure agent is not authorized for use in the System Security Plan and the executable file does not exist or is restricted, this is not a finding.\n\nIf external procedure agent is not authorized for use in the System Security Plan and the executable file exists and is not restricted, this is a finding.\n\nIf use of the external procedure agent is authorized, ensure extproc is restricted to execution of authorized applications.\n\nExternal jobs are run using the account nobody by default.\n\nReview the contents of the file ORACLE_HOME/rdbms/admin/externaljob.ora for the lines run_user= and run_group=.\n\nIf the user assigned to these parameters is not \"nobody\", this is a finding.\n\nFor versions 11.1 and later, the external procedure agent (extproc executable) is available directly from the database and does not require definition in the listener.ora file for use.\n\nReview the contents of the file ORACLE_HOME/hs/admin/extproc.ora.\n\nIf external processes are allowed, but the file does not exist, this is a finding.\n\nIf the following entry does not appear in the file, this is a finding:\n\nEXTPROC_DLLS=ONLY:[dll full file name1]:[dll full file name2]:..\n\n[dll full file name] represents a full path and file name.\n\nThis list of file names is separated by \":\".\n\nIf \"ONLY\" is specified, then the list is restricted to allow execution of only the DLLs specified in the list and is not a finding.\n\nIf \"ANY\" is specified, then there are no restrictions for execution except what is controlled by operating system permissions and is a finding.\n\nIf no specification is made, any files located in the %ORACLE_HOME%\\bin directory on Windows systems or $ORACLE_HOME/lib directory on UNIX systems can be executed (the default) and is a finding.\n\nEnsure that EXTPROC is not accessible from the listener.\n\nReview the listener.ora file. If any entries reference \"extproc\", this is a finding.\n\nDetermine if the external procedure agent is in use per Oracle 10.x conventions.\n\nReview the listener.ora file.\n\nIf any entries reference \"extproc\", then the agent is in use.\n\nIf external procedure agent is not authorized for use in the System Security Plan and references to \"extproc\" exist, this is a finding.\n\nSample listener.ora entries with extproc included:\n\nLISTENER =\n(DESCRIPTION =\n(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))\n)\nEXTLSNR =\n(DESCRIPTION =\n(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))\n)\nSID_LIST_LISTENER =\n(SID_LIST =\n(SID_DESC =\n(GLOBAL_DBNAME = ORCL)\n(ORACLE_HOME = /home/oracle/app/oracle/product/11.1.0/db_1)\n(SID_NAME = ORCL)\n)\n)\nSID_LIST_EXTLSNR =\n(SID_LIST =\n(SID_DESC =\n(PROGRAM = extproc)\n(SID_NAME = PLSExtProc)\n(ORACLE_HOME = /home/oracle/app/oracle/product/11.1.0/db_1)\n(ENVS=\"EXTPROC_DLLS=ONLY:/home/app1/app1lib.so:/home/app2/app2lib.so,\nLD_LIBRARY_PATH=/private/app2/lib:/private/app1,\nMYPATH=/usr/fso:/usr/local/packages\")\n)\n)\n\nSample tnsnames.ora entries with extproc included:\n\nORCL =\n(DESCRIPTION =\n(ADDRESS_LIST =\n(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))\n)\n(CONNECT_DATA =\n(SERVICE_NAME = ORCL)\n)\n)\nEXTPROC_CONNECTION_DATA =\n(DESCRIPTION =\n(ADDRESS_LIST =\n(ADDRESS = (PROTOCOL = IPC)(KEY = extproc))\n)\n(CONNECT_DATA =\n(SERVER = DEDICATED)\n(SERVICE_NAME = PLSExtProc)\n)\n)\n\nIf EXTPROC is in use, confirm that a listener is dedicated to serving the external procedure agent (as shown above).\n\nView the protocols configured for the listener.\n\nFor the listener to be dedicated, the only entries will be to specify extproc.\n\nIf there is not a dedicated listener in use for the external procedure agent, this is a finding.\n\nIf the PROTOCOL= specified is other than IPC, this is a finding.\n\nVerify and ensure extproc is restricted executing authorized external applications only and extproc is restricted to execution of authorized applications.\n\nReview the listener.ora file.\n\nIf the following entry does not exist, this is a finding:\n\nEXTPROC_DLLS=ONLY:[dll full file name1]:[dll full file name2]:...\n\n[dll full file name] represents a full path and file name. This list of file names is separated by \":\".\n\nIf \"ONLY\" is specified, then the list is restricted to allow execution of only the DLLs specified in the list and is not a finding.\n\nIf \"ANY\" is specified, then there are no restrictions for execution except what is controlled by operating system permissions and is a finding.\n\nIf no specification is made, any files located in the %ORACLE_HOME%\\bin directory on Windows systems or $ORACLE_HOME/lib directory on UNIX systems can be executed (the default) and is a finding.\n\nView the listener.ora file (usually in ORACLE_HOME/network/admin or directory specified by the TNS_ADMIN environment variable).\n\nIf multiple listener processes are running, then the listener.ora file for each must be viewed.\n\nFor each process, determine the directory specified in the ORACLE_HOME or TNS_ADMIN environment variable defined for the process account to locate the listener.ora file.","fixText":"If the use of external procedure agent is required, then authorize and document the requirement in the System Security Plan.\n\nIf the external procedure agent must be accessible to the Oracle listener, then specify this and authorize it in the System Security Plan.\n\nIf use of the Oracle External Procedure agent is not required:\n\n- Stop the Oracle Listener process\n- Remove all references to extproc in the listener.ora and tnsnames.ora files\n- Alter the permissions on the executable files:\n\nUNIX - Remove read/write/execute permissions from owner, group and world\nWindows - Remove Groups/Users from the executable (except groups SYSTEM and ADMINISTRATORS) and allow READ [only] for SYSTEM and ADMINISTRATORS groups\n\nIf required:\n\n- Restrict extproc execution to only authorized applications.\n- Specify EXTPROC_DLLS=ONLY: [list of authorized DLLS] in the extproc.ora and the listener.ora files\n- Create a separate, dedicated listener for use by the external procedure agent\n\nPlease see the Oracle Net Services Administrators Guides, External Procedures section for detailed configuration information.","ccis":["CCI-000381"]},{"vulnId":"V-219773","ruleId":"SV-219773r960966_rule","severity":"medium","ruleTitle":"The DBMS must support the organizational requirements to specifically prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services.","description":"Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). \n\nAdditionally, it is sometimes convenient to provide multiple services from a single component of an information system (e.g., email and web services), but doing so increases risk by constraining the ability to restrict the use of functions, ports, protocols, and/or services.   \n\nTo support the requirements and principles of least functionality, the application must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.\n\nDatabase Management Systems using ports, protocols, and services deemed unsafe are open to attack through those ports, protocols, and services. This can allow unauthorized access to the database and through the database to other components of the information system.","checkContent":"Review the DBMS settings for functions, ports, protocols, and services that are not approved. If any are found, this is a finding.\n\n(For definitive information on Ports, Protocols and Services Management (PPSM), refer to http://iase.disa.mil/ppsm/index.html.)\n\n- - - - -\n\nIn the Oracle database, the communications with the database and incoming requests are performed by the Oracle Listener.  The Oracle Listener listens on a specific port or ports for connections to a specific database.  The Oracle Listener has configuration files located in the $ORACLE_HOME/network/admin directory.  To check the ports and  protocols in use, go to  that directory and review the SQLNET.ora, LISTENER.ora, and the TNSNAMES.ora.  If protocols or ports are in use that are not authorized, this is a finding.","fixText":"Disable functions, ports, protocols, and services that are not approved.\n\n- - - - -\n\nChange the SQLNET.ora, LISTENER.ora, and TNSNAMES.ora files to reflect the proper use of ports, protocols and services that are approved at the site.  \n\nIf changes to the Listener are made, the files associated with the Listener must be reloaded.  Do that by issuing the following commands at the Unix/Linux or Windows prompt.\nFirst - issue the command to see what the current status is\n$ lsnrctl stat\nThen load the new file that was corrected to reflect site-specific requirements.\n$ lsnrctl reload\nThen check the status again to see that the changes have taken place\n$ lsnrctl stat","ccis":["CCI-000382"]},{"vulnId":"V-219774","ruleId":"SV-219774r981949_rule","severity":"medium","ruleTitle":"The DBMS must support organizational requirements to enforce password encryption for storage.","description":"Applications must enforce password encryption when storing passwords. Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised.\n\nDatabase 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.","checkContent":"(Oracle stores and displays its passwords in encrypted form.  Nevertheless, this should be verified by reviewing the relevant system views, along with the other items to be checked here.)\n\nAsk the DBA to review the list of DBMS database objects, database configuration files, associated scripts, and applications defined within and external to the DBMS that access the database. The list should also include files, tables or settings used to configure the operational environment for the DBMS and for interactive DBMS user accounts.\n\nAsk the DBA and/or IAO to determine if any DBMS database objects, database configuration files, associated scripts, and applications defined within or external to the DBMS that access the database, and DBMS/user environment files/settings/tables, contain database passwords. If any do, confirm that DBMS passwords stored internally or externally to the DBMS are encoded or encrypted. If any passwords are stored in clear text, this is a finding.\n\nAsk the DBA/SA/Application Support staff if they have created an external password store for applications, batch jobs, and scripts to use.  Verify that all passwords stored there are encrypted.  If a password store is used and any password is not encrypted, this is a finding.\n\n\nThe following are notes on implementing a Secure External Password Store using Oracle Wallet:\n\nYou can store password credentials for connecting to databases by using a client-side Oracle wallet. An Oracle wallet is a secure software container that stores authentication and signing credentials.\n\nThis wallet usage can simplify large-scale deployments that rely on password credentials for connecting to databases. When this feature is configured, application code, batch jobs, and scripts  no longer need embedded user names and passwords. This reduces risk because the passwords are no longer exposed, and password management policies are more easily enforced without changing application code whenever user names or passwords change.\n  \nThe external password store of the wallet is separate from the area where public key infrastructure (PKI) credentials are stored. Consequently, you cannot use Oracle Wallet Manager to manage credentials in the external password store of the wallet. Instead, use the command-line utility mkstore to manage these credentials.\n  \nHow Does the External Password Store Work?\n\nTypically, users (and applications, batch jobs, and scripts) connect to databases by using a standard CONNECT statement that specifies a database connection string. This string can include a user name and password, and an Oracle Net service name identifying the database on an Oracle Database network. If the password is omitted, the connection prompts the user for the password.\n\nFor example, the service name could be the URL that identifies that database, or a TNS alias you entered in the tnsnames.ora file in the database. Another possibility is a host:port:sid string.\n  \nThe following examples are standard CONNECT statements that could be used for a client that is not configured to use the external password store:\n\n  CONNECT salesapp@sales_db.us.example.com\n  Enter password: password\n\n  CONNECT salesapp@orasales\n  Enter password: password\n\n  CONNECT salesapp@ourhost37:1527:DB17\n  Enter password: password\n\nIn these examples, salesapp is the user name, with the unique connection string for the database shown as specified in three different ways. You could use its URL sales_db.us.example.com, or its TNS alias, orasales, from the tnsnames.ora file, or its host:port:sid string.\n\nHowever, when clients are configured to use the secure external password store, applications can connect to a database with the following CONNECT statement syntax, without specifying database logon credentials:\n\n  CONNECT /@db_connect_string\n\n  CONNECT /@db_connect_string AS SYSDBA\n\n  CONNECT /@db_connect_string AS SYSOPER\n  \nIn this specification, db_connect_string is a valid connection string to access the intended database, such as the service name, URL, or alias as shown in the earlier examples. Each user account must have its own unique connection string; you cannot create one connection string for multiple users.\n\nIn this case, the database credentials, user name and password, are securely stored in an Oracle wallet created for this purpose. The autologin feature of this wallet is turned on, so the system does not need a password to open the wallet. From the wallet, it gets the credentials to access the database for the user they represent.","fixText":"Develop, document, and maintain a list of DBMS database objects, database configuration files, associated scripts, and applications defined within or external to the DBMS that access the database, and DBMS/user environment files/settings in the System Security Plan.\n\nRecord whether they do or do not contain DBMS passwords. If passwords are present, ensure they are encoded or encrypted and protected by host system security.\n\n\nThe following are notes on implementing a Secure External Password Store using Oracle Wallet:\n\nOracle provides the capability to provide for a secure external password facility.  Use the Oracle mkstore to create a secure storage area for passwords for applications, batch jobs, and scripts to use, or deploy a site-authorized facility to perform this function.\n\nCheck to see what has been stored in the Oracle External Password Store.\n\nTo view all contents of a client wallet external password store, check specific credentials by viewing them. Listing the external password store contents provides information you can use to decide whether to add or delete credentials from the store.  To list the contents of the external password store, enter the following command at the command line:\n\n$ mkstore -wrl wallet_location -listCredential\nFor example:\n$ mkstore -wrl c:\\oracle\\product\\11.2.0\\db_1\\wallets -listCredential\n\nThe wallet_location specifies the path to the directory where the wallet, whose external password store contents you want to view, is located. This command lists all of the credential database service names (aliases) and the corresponding user name (schema) for that database. Passwords are not listed.\n\nConfiguring Clients to use the External Password Store:\n\nIf your client is already configured to use external authentication, such as Windows native authentication or Transport Layer Security (TLS), then Oracle Database uses that authentication method. The same credentials used for this type of authentication are typically also used to log in to the database.\n\nFor clients not using such authentication methods or wanting to override them for database authentication, you can set the SQLNET.WALLET_OVERRIDE parameter in sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE, allowing standard use of authentication credentials as before.\n\nIf you want a client to use the secure external password store feature, then perform the following configuration task:\n\n1. Create a wallet on the client by using the following syntax at the command line:\n\nmkstore -wrl wallet_location -create\n\nFor example:\n\nmkstore -wrl c:\\oracle\\product\\11.2.0\\db_1\\wallets -create\n\nEnter password: password\n\nThe wallet_location is the path to the directory where you want to create and store the wallet. This command creates an Oracle wallet with the autologin feature enabled at the location you specify. The autologin feature enables the client to access the wallet contents without supplying a password. \n \nThe mkstore utility -create option uses password complexity verification.\n \n2. Create database connection credentials in the wallet by using the following syntax at the command line:\n\nmkstore -wrl wallet_location -createCredential db_connect_string username\n\nEnter password: password\n\nFor example:\nmkstore -wrl c:\\oracle\\product\\11.2.0\\db_1\\wallets -createCredential oracle system\n\nEnter password: password\n\nIn this specification the wallet_location is the path to the directory where you created the wallet.  The db_connect_string used in the CONNECT /@db_connect_string statement must be identical to the db_connect_string specified in the -createCredential command.  The db_connect_string is the TNS alias you use to specify the database in the tnsnames.ora file or any service name you use to identify the database on an Oracle network. By default, tnsnames.ora is located in the $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME\\network\\admin on Windows.  The username is the database logon credential. When prompted, enter the password for this user.\n \n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set it to the directory location of the wallet you created in Step 1.  For example, if you created the wallet in $ORACLE_HOME/network/admin and your Oracle home is set to /private/ora11, then you need to enter the following into your client sqlnet.ora file:\n\n    WALLET_LOCATION =\n           (SOURCE =\n             (METHOD = FILE)\n             (METHOD_DATA =\n           (DIRECTORY = /private/ora11/network/admin)\n           )\n          )\n \n4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter and set it to TRUE as follows:\n\nSQLNET.WALLET_OVERRIDE = TRUE\n\nThis setting causes all CONNECT /@db_connect_string statements to use the information in the wallet at the specified location to authenticate to databases.\n\nWhen external authentication is in use, an authenticated user with such a wallet can use the CONNECT /@db_connect_string syntax to access the previously specified databases without providing a user name and password. However, if a user fails that external authentication, then these connect statements also fail.\n\nBelow is a sample sqlnet.ora file with the WALLET_LOCATION and the SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n        WALLET_LOCATION =\n            (SOURCE =\n              (METHOD = FILE)\n              (METHOD_DATA =\n            (DIRECTORY = /private/ora11/network/admin)\n              )\n             )\n        SQLNET.WALLET_OVERRIDE = TRUE\n        SSL_CLIENT_AUTHENTICATION = FALSE\n        SSL_VERSION = 1.2\n\n(Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files.)","ccis":["CCI-004062"]},{"vulnId":"V-219775","ruleId":"SV-219775r961038_rule","severity":"medium","ruleTitle":"The DBMS, when utilizing PKI-based authentication, must validate certificates by constructing a certification path with status information to an accepted trust anchor.","description":"A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. \n\nWhen there is a chain of trust, usually the top entity to be trusted becomes the trust anchor. For example, it can be a Certification Authority (CA). A certification path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA.\n\nPath validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted.\n\nStatus information for certification paths includes certificate revocation lists or online certificate status protocol responses.\n\nDatabase Management Systems that do not validate certificates to a trust anchor are in danger of accepting certificates that are invalid and/or counterfeit. This could allow unauthorized access to the database.","checkContent":"Review DBMS configuration to verify the certificates being accepted by the DBMS have a valid certification path with status information to an accepted trust anchor. If certification paths are not being validated back to a trust anchor, this is a finding.\n\nThe database supports PKI-based authentication by using digital certificates over TLS in addition to the native encryption and data integrity capabilities of these protocols.\n\nOracle provides a complete PKI that is based on RSA Security, Inc., Public-Key Cryptography Standards, and which interoperates with Oracle servers and clients. The database uses a wallet which is a container that is used to store authentication and signing credentials, including private keys, certificates, and trusted certificates needed by TLS. In an Oracle environment, every entity that communicates over TLS must have a wallet containing an X.509 version 3 certificate, private key, and list of trusted certificates. \n\nIf the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries, TLS is installed. \n\nWALLET_LOCATION = (SOURCE=\n(METHOD = FILE) \n(METHOD_DATA = \nDIRECTORY=/wallet) \n\nSSL_CIPHER_SUITES=(SSL_cipher_suiteExample) \nSSL_VERSION = 1.2\nSSL_CLIENT_AUTHENTICATION=TRUE\n\n(Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files.)","fixText":"Configure the DBMS to validate certificates by constructing a certification path with status information to an accepted trust anchor.\n\nConfigure the database to support Transport Layer Security (TLS) protocols and the Oracle Wallet to store authentication and signing credentials including private keys.","ccis":["CCI-000185"]},{"vulnId":"V-219776","ruleId":"SV-219776r961044_rule","severity":"medium","ruleTitle":"The DBMS must ensure that PKI-based authentication maps the authenticated identity to the user account.","description":"The cornerstone of the PKI is the private key used to encrypt or digitally sign information. The key by itself is a cryptographic value that does not contain specific user information.\n\nWhen including the DBMS in the Private Key Infrastructure, the authenticated user must map directly to a user account in the DBMS. If the user account is not directly tied to the authenticated identity, there is no way to know which, if any, database user account has been authorized.","checkContent":"Review DBMS configuration to verify DBMS user accounts are being mapped directly to authenticated identity information being passed via the PKI. If user accounts are not being mapped to authenticated identity information being passed via the PKI, this is a finding.\n\nThe database supports PKI-based authentication by using digital certificates over TLS in addition to the native encryption and data integrity capabilities of these protocols.\n\nOracle provides a complete PKI that is based on RSA Security, Inc., Public-Key Cryptography Standards, and which interoperates with Oracle servers and clients.  The database uses a wallet which is a container that is used to store authentication and signing credentials, including private keys, certificates, and trusted certificates needed by TLS. In an Oracle environment, every entity that communicates over TLS must have a wallet containing an X.509 version 3 certificate, private key, and list of trusted certificates.  Security administrators use Oracle Wallet Manager to manage security credentials on the server.\n\nIf the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries, TLS is installed.\n(Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files.)\n\nWALLET_LOCATION = (SOURCE=\n                          (METHOD = FILE) \n                          (METHOD_DATA = \n                           DIRECTORY=/wallet) \n\nSSL_CIPHER_SUITES=(SSL_cipher_suiteExample) \nSSL_VERSION = 1.2\nSSL_CLIENT_AUTHENTICATION=FALSE/TRUE","fixText":"Configure the DBMS to map the authenticated identity directly to the DBMS user account.","ccis":["CCI-000187"]},{"vulnId":"V-219777","ruleId":"SV-219777r961044_rule","severity":"medium","ruleTitle":"Processes (services, applications, etc.) that connect to the DBMS independently of individual users, must use valid, current DoD-issued PKI certificates for authentication to the DBMS.","description":"Just as individual users must be authenticated, and just as they must use PKI-based authentication, so must any processes that connect to the DBMS.\n\nThe DoD standard for authentication of a process or device communicating with another process or device is the presentation of a valid, current, DoD-issued Public Key Infrastructure (PKI) certificate that has previously been verified as Trusted by an administrator of the other process or device.\n\nThis applies both to processes that run on the same server as the DBMS and to processes running on other computers.\n\nThe Oracle-supplied super-user account, SYS, is an exception.  It cannot currently use certificate-based authentication.  For this reason among others, use of SYS should be restricted to where it is truly needed.","checkContent":"Review configuration to confirm that accounts used by processes to connect to the DBMS are authenticated using valid, current DoD-issued PKI certificates.\n\nIf any such account, other than SYS, is not certificate-based, this is a finding.","fixText":"For each such account, use DoD certificate-based authentication.","ccis":["CCI-000187"]},{"vulnId":"V-219778","ruleId":"SV-219778r961050_rule","severity":"medium","ruleTitle":"The DBMS must use  NIST-validated FIPS 140-2-compliant cryptography for authentication mechanisms.","description":"Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified and cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised due to weak algorithms. \n\nApplications utilizing encryption are required to use approved encryption modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.  \n\nFIPS 140-2 is the current standard for validating cryptographic modules, and NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified hardware-based encryption modules.\n\nAuthentication modules with weak encryption could allow an attacker to gain access to data stored in the database and to the administration settings of the DBMS.","checkContent":"Check the following settings to see if FIPS 140-2 authentication/encryption is configured. If encryption is required but not configured, check with the DBA and SYSTEM Administrator to see if other mechanisms or third-party cryptography products are deployed for authentication.\n\nTo see if Oracle is configured for FIPS 140-2 SSL/TLS authentication and/or Encryption:\n\nOpen the fips.ora file in a browser or editor.  (The default location for fips.ora is $ORACLE_HOME/ldap/admin/ but alternate locations are possible. An alternate location, if it is in use, is specified in the FIPS_HOME environment variable.)\n\nIf the line \"SSLFIPS_140=TRUE\" is not found in fips.ora, or the file does not exist, this is a finding.","fixText":"Utilize NIST-validated FIPS 140-2-compliant cryptography for all authentication mechanisms.\n\nThe strength requirements are dependent upon data classification.  \n\nFor unclassified data, where cryptography is required:\n\nAES 128 for encryption\nSHA 256 for hashing  \n\nNSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows:\n\nAES 128 for Secret\nAES 256 for Top Secret\nSHA 256 for Secret  \nSHA 384 for Top Secret\n\nNational Security System is defined as:\n\n(OMB Circular A-130) Any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications).\n\nThere is more information on this topic in the Oracle Database 11.2g Advanced Security Administrator's Guide, which may be found at  https://docs.oracle.com/database/112/DBSEG/E48135-11.pdf. \n\nNote: because of changes in Oracle's licensing policy, it is no longer necessary to purchase Oracle Advanced Security to use network encryption and advanced authentication.\n\nFIPS 140-2 documentation can be downloaded from http://csrc.nist.gov/publications/PubsFIPS.html#140-2","ccis":["CCI-000803"]},{"vulnId":"V-219779","ruleId":"SV-219779r961113_rule","severity":"medium","ruleTitle":"The DBMS must terminate user sessions upon user logout or any other organization or policy-defined session termination events, such as idle time limit exceeded.","description":"This requirement focuses on communications protection at the application session, versus network packet, level. \n\nSession IDs are tokens generated by web applications to uniquely identify an application user's session.   Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs, which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attackers are unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that particular user session.\n\nDatabase sessions must be terminated when no longer in use in order to prevent session hijacking.","checkContent":"Review DBMS settings and vendor documentation to verify user sessions are terminated upon user logout. If they are not, this is a finding.\n\nReview system documentation and organization policy to identify other events that should result in session terminations. If other session termination events are defined, review DBMS settings to verify occurrences of these events would cause session termination. If occurrences of defined session-terminating events do not cause session terminations, this is a finding.\n\nWhen a user logs out of an Oracle session gracefully or has the session terminated for an idle timeout or any other reason, the session is terminated, and the resources are returned to the system.  Check with the DBA to see what mechanism is used to disconnect the session and what events the site uses to determine if a connection needs to be terminated.  \n\nTo test for timeout, open a connection and leave it idle for a period greater than the defined idle timeout setting enforced by the system.  Then try to use the connection.  If the connection is no longer active, then the mechanism deployed to terminate the connection is active and working.","fixText":"Configure DBMS settings to terminate sessions upon user logout.  Configure DBMS settings to terminate sessions upon the occurrence of any organization or policy-defined session termination event.\n- - - - -\nTo configure specific session termination processes we need to define the organization or policy-defined session termination event.  Below are some examples.\n\nOracle has several ways to disconnect idle sessions, both from within SQL*Plus via resources profiles (connect_time, idle_time) and with the SQL*net expire time parameter.\n\nYou can use profiles to set the connect time and idle time with \"alter profile\" statements:\n\nalter profile senior_claim_analyst limit\n   connect_time 180000\n   sessions_per_user 2\n   ldle_time 1800;\n\nProfiles comprise a named set of resource limits. By default, when you create users, they are given the default profile, which provides unlimited use of all resources.\n\nThe syntax to create a profile follows:\n\nCREATE PROFILE  LIMIT resource_parameters|password_parameters;\nResource_parameters: \n [SESSIONS_PER_USER n|UNLIMITED|DEFAULT]\n [CPU_PER_SESSION   n|UNLIMITED|DEFAULT]    \n [CPU_PER_CALL      n|UNLIMITED|DEFAULT]           \n [CONNECT_TIME      n|UNLIMITED|DEFAULT]\n [IDLE_TIME         n|UNLIMITED|DEFAULT]\n\nBy setting resource limits, you can prevent users from performing operations that will tie up the system and prevent other users from performing operations. You can use resource limits for security, to ensure that users log off the system, so as not to leave the session connected for long periods of time.\n\nThe system resource limits can be enforced at the session-level, the call level, or both. The session-level is calculated from the time the user logs in to the database until the user exits. The call level applies to each SQL command issued. Session-level limits are enforced for each connection. When a session-level limit is exceeded, only the last SQL command issued is rolled back; no further work can be performed until a commit, rollback, or exit is performed.\n\nUsing SQLNET.EXPIRE_TIME\n\nThe sqlnet.expire_time parameter is used to set a time interval, in minutes, to determine how often a probe should be sent verifying that client/server connections are active. If you need to ensure that connections are not left open indefinitely (or up to the time set by operating system-specific parameters), you should set a value that is greater than 0. This protects the system from connections left open due to an abnormal client termination.\n\nWhen the probe detects a terminated connection or a connection no longer in use, it signals an error, causing the server process to exit. This setting is intended for use on the database server side of the connection, which usually handles multiple connections at any one time. Limitations on using this terminated (dead) connection detection feature are:\n\nsqlnet.expire_time cannot be used on bequeathed connections.     \n\nThe SQL*Net expire_time probe packet will generate additional network traffic that may downgrade the network's performance, depending on the number of connections.\n\nDepending on the operating system that is in use, additional server processing may need to be performed to distinguish the connection probe from other events that occur. This overhead for detection of probe events can result in downgraded network performance.\n\nTurning-on expire_time\n\nTo set up these advanced features, simply edit your sqlnet.ora file.  If you are a beginner, follow this procedure:\n\nStart the Oracle Network Manager GUI.\n\nIn the GUI navigator pane, expand the icons Local > Profile.\n     \nFrom the list on the right hand pane, select General.\n\nClick on the Advanced tab.\n     \nNext, enter the values for the fields or options you want to set.  \n\nWhen you are finished, choose File > Save Network Configuration to write your changes to the sqlnet.ora file.\n\n(Note: This assumes that a single sqlnet.ora file, in the default location, is in use.  Please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files.)\n\nThe sqlnet.ora inbound_connect_timeout parameter\n\nThe sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set in seconds, for a client to connect with the database server and provide the required authentication information.\n\nAlso see sqlnet.inbound_connect_timeout tips.\n\nTo limit consumption of Oracle resources by unauthorized users and enable an audit trail, you should set time-limit values for the sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter does not have default values.)  Failure resulting from sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed out error.","ccis":["CCI-001185"]},{"vulnId":"V-219780","ruleId":"SV-219780r961125_rule","severity":"medium","ruleTitle":"The DBMS must preserve any organization-defined system state information in the event of a system failure.","description":"Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system.\n\nPreserving information system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes.","checkContent":"If the database is used solely for transient data (such as one dedicated to Extract-Transform-Load (ETL)), and a clear plan exists for the recovery of the database by means other than archiving, this not a finding.\n\nIf it has been determined that up-to-the second recovery is not necessary and this fact is recorded in the system documentation, with appropriate approval, this is not a finding.\n\nCheck DBMS settings to determine whether system state information is being preserved in the event of a system failure.\n\nThe necessary state information is defined as \"information necessary to determine cause of failure and to return to operations with least disruption to mission/business processes\".\n\nOracle creates what is known as archive logs. Archive logs contain information required to replay a transaction should something happen. The redo logs are also used to copy transactions or pieces of transactions.\n\nIssue the following commands to check the status of archive log mode:\n\n$ sqlplus connect as sysdba --Check current archivelog mode in database\n\nSQL> archive log list\nDatabase log mode Archive Mode\nAutomatic archival Enabled\nArchive destination /home/oracle/app/oracle/arc2/ORCL\nOldest online log sequence 433\nNext log sequence to archive 435\nCurrent log sequence 435\n\nIf archive log mode is not enabled, this is a finding.","fixText":"Configure DBMS settings to preserve all required system state information in the event of a system failure. \n\nIf the database is not in archive log mode, issue the following commands to put the database in archive log mode. The database must be normally shutdown and restarted before it can be placed in archive log mode. \n\n$ sqlplus connect as sysdba -- stop and dismount database and shutdown instance.\nSQL> shutdown immediate;\n\nDatabase closed.\nDatabase dismounted.\nORACLE instance shut down.\n\nSQL> startup mount;\t-- Restart instance.\n\nORACLE instance started.\nTotal System Global Area 1653518336 bytes\nFixed Size 2228904 bytes\nVariable Size 1325403480 bytes\nDatabase Buffers 318767104 bytes\nRedo Buffers 7118848 bytes\nDatabase mounted.\n\nSQL> alter database archivelog;\t-- Enable ArchiveLog\nDatabase altered.\n\nSQL> alter database open; -- Re-open database\nDatabase altered.\n\nIssue the following command to see the new status:\nSQL> select log_mode from v$database;\n\nLOG_MODE\n------------\nARCHIVELOG\n\nSQL> archive log list;\n\nDatabase log mode Archive Mode\nAutomatic archival Enabled\nArchive destination USE_DB_RECOVERY_FILE_DEST\nOldest online log sequence 294\nNext log sequence to archive 296\nCurrent log sequence 296\n\nThe database is now in archive log mode, and transactions are either being recorded to transport to another database or being re-applied if the database becomes corrupt and needs to be restored from the last backup. Use the redo logs to replay transactions not captured in the backup.","ccis":["CCI-001665"]},{"vulnId":"V-219781","ruleId":"SV-219781r961128_rule","severity":"medium","ruleTitle":"The DBMS must take needed steps to protect data at rest and ensure confidentiality and integrity of application data.","description":"This control is intended to address the confidentiality and integrity of information at rest in non-mobile 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.  \n\nUser-generated data and application specific configuration data both need to 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. \n\nIf the confidentiality and integrity of application data is not protected, the data will be open to compromise and unauthorized modification.","checkContent":"If the application owner and Authorizing Official have determined that encryption of data at rest is NOT required, this is not a finding.\n\nReview DBMS settings to determine whether controls exist to protect the confidentiality and integrity of data at rest in the database. If controls do not exist or are not enabled, this is a finding.\n\nTo ensure that the appropriate controls are in place, discuss the precautions taken with the site Database Administrators and System Administrators and try to modify data at rest.\n\nOracle recommends using Transparent Data Encryption to protect data. \n\nIn order to check to see if the data is encrypted, for example, upon an auditor's request, Oracle provides views that document the encryption status of your database. For TDE column encryption, please 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, encrypted, data files. Issue the following commands to check to see if the data at rest is encrypted.\n\n$ sqlplus connect as sysdba\n\nSQL> SELECT t.name \"TSName\", \ne.encryptionalg \"Algorithm\", \nd.file_name \"File Name\" \nFROM v$tablespace t, \nv$encrypted_tablespaces e, \ndba_data_files d \nWHERE t.ts# = e.ts# \nand t.name = d.tablespace_name;\n\nThe next SQL statement lists the table owner, tables within encrypted tablespaces, and the encryption algorithm:\n\nSQL> SELECT a.owner \"Owner\", \na.table_name \"Table Name\", \ne.encryptionalg \"Algorithm\", \nFROM dba_tables a, \nv$encrypted_tablespaces e \nWHERE a.tablespace_name in (select t.name from v$tablespace t, v$encrypted_tablespaces e where t.ts# = e.ts#);","fixText":"Apply appropriate controls to protect the confidentiality and integrity of data at rest in the database.\n\nIf no site-specific precautions are in place, use Oracle Advanced Security Option to encrypt data at rest.\n\nIf ASO is not an option, use site-specific procedures to secure data at rest.","ccis":["CCI-001199"]},{"vulnId":"V-219782","ruleId":"SV-219782r961131_rule","severity":"medium","ruleTitle":"The DBMS must isolate security functions from non-security functions by means of separate security domains.","description":"Security functions are defined as \"the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based\".\n\nDevelopers and implementers can increase the assurance in security functions by employing well-defined security policy models, structured, disciplined, and rigorous hardware and software development techniques, and sound system/security engineering principles.\n\nDatabase Management Systems typically separate security functionality from non-security functionality via separate databases or schemas. Database objects or code implementing security functionality should not be commingled with objects or code implementing application logic. When security and non-security functionality is commingled, users who have access to non-security functionality may be able to access security functionality.","checkContent":"Check DBMS settings to determine whether objects or code implementing security functionality are located in a separate security domain, such as a separate database or schema created specifically for security functionality. If security-related database objects or code are not kept separate, this is a finding.\n\nThe Oracle elements of security functionality such as the roles, permissions and profiles along with password complexity requirements are stored in separate schemas in the database.  Review any site-specific applications security modules built into the database and determine what schema they are located in and take appropriate action.  The Oracle objects will be in the Oracle Data Dictionary.","fixText":"Locate security-related database objects and code in a separate database, schema, or other separate security domain from database objects and code implementing application logic.  (This is the default behavior for Oracle.)  Review any site-specific applications security modules built into the database:   determine what schema they are located in and take appropriate action.","ccis":["CCI-001084"]},{"vulnId":"V-219783","ruleId":"SV-219783r961149_rule","severity":"medium","ruleTitle":"The DBMS must prevent unauthorized and unintended information transfer via shared system resources.","description":"The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse.\n\nData used for the development and testing of applications often involves copying data from production.  It is important that specific procedures exist for this process, so copies of sensitive data are not misplaced or left in a temporary location without the proper controls.","checkContent":"Verify there are proper procedures in place for the refreshing of development/test data from production.  Review any scripts or code that exists for the movement of production data to development/test and verify copies of production data are not left in unprotected locations. \n\nIf there is no documented procedure for data movement from production to development/test, this is a finding.\n\nIf the code that exists for data movement does not remove any copies of production data from unprotected locations, this is a finding.","fixText":"Create and document a process for moving data from production to development/test systems, and follow the process. \n\nModify any code used for moving data from production to development/test systems to ensure copies of production data are not left in non-secured locations.\n\nMoving data is only a part of the challenge of protecting the data.  When the data is moved, it should also be changed so sensitive information is not made available in development environments.  \n\nWith the Oracle Data Masking Pack for Oracle Enterprise Manager, organizations can comply with data privacy and protection mandates that restrict the use of actual customer data. With Oracle Data Masking Pack, sensitive information such as credit card or social security numbers can be replaced with realistic values, allowing production data to be safely used for development, testing, or sharing with out-source or off-shore partners for other nonproduction purposes.  When used in conjunction with Oracle Enterprise Manager, it is easy to develop a secure process which is capable of obfuscating the data during the movement process.\n\nIf the Oracle Data Masking Pack and Enterprise Manager are not available, develop site-specific procedures to manage and obfuscate sensitive data.","ccis":["CCI-001090"]},{"vulnId":"V-219784","ruleId":"SV-219784r961158_rule","severity":"medium","ruleTitle":"The DBMS must check the validity of data inputs.","description":"Invalid user input occurs when a user inserts data or characters into an application's data entry fields and the application is unprepared to process that data. This results in unanticipated application behavior, potentially leading to an application or information system compromise. Invalid user input is one of the primary methods employed when attempting to compromise an application.\n\nAll applications need to validate the data users attempt to input to the application for processing. Rules for checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, acceptable values) are in place to verify inputs match specified definitions for format and content. Inputs passed to interpreters are prescreened to prevent the content from being unintentionally interpreted as commands.\n\nThis calls for inspection of application source code, which will require 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.","checkContent":"Review DBMS code, settings, field definitions, constraints and triggers to determine whether or not data being input into the database is validated. If code exists that allows invalid data to be acted upon or input into the database, this is a finding.\n\nIf field definitions do not exist in the database, this is a finding.  If fields do not contain enabled constraints where required, this is a finding.\n- - - - -\nOracle provides built-in processes to keep data and its integrity intact by using constraints.\n\nIntegrity Constraint States\nYou can specify that a constraint is enabled (ENABLE) or disabled (DISABLE). If a constraint is enabled, data is checked as it is entered or updated in the database, and data that does not conform to the constraint is prevented from being entered. If a constraint is disabled, then data that does not conform can be allowed to enter the database.\n\nAdditionally, you can specify that existing data in the table must conform to the constraint (VALIDATE). Conversely, if you specify NOVALIDATE, you are not ensured that existing data conforms.\n\nAn integrity constraint defined on a table can be in one of the following states:\n    ENABLE, VALIDATE\n    ENABLE, NOVALIDATE\n    DISABLE, VALIDATE\n    DISABLE, NOVALIDATE\n\nFor details about the meaning of these states and an understanding of their consequences, see the Oracle Database SQL Language Reference. Some of these consequences are discussed here.\n\nDisabling Constraints\nTo enforce the rules defined by integrity constraints, the constraints should always be enabled. However, consider temporarily disabling the integrity constraints of a table for the following performance reasons:\n\n-    When loading large amounts of data into a table\n\n-    When performing batch operations that make massive changes to a table (for example, changing every employee's number by adding 1000 to the existing number)\n\n-    When importing or exporting one table at a time\n\nIn all three cases, temporarily disabling integrity constraints can improve the performance of the operation, especially in data warehouse configurations.\n\nIt is possible to enter data that violates a constraint while that constraint is disabled. Thus, you should always enable the constraint after completing any of the operations listed in the preceding bullet list.\n\nEnabling Constraints\nWhile a constraint is enabled, no row violating the constraint can be inserted into the table. However, while the constraint is disabled, such a row can be inserted. This row is known as an exception to the constraint. If the constraint is in the enable nonvalidated state, violations resulting from data entered while the constraint was disabled remain. The rows that violate the constraint must be either updated or deleted in order for the constraint to be put in the validated state.\n\nYou can identify exceptions to a specific integrity constraint while attempting to enable the constraint. See \"Reporting Constraint Exceptions\". All rows violating constraints are noted in an EXCEPTIONS table, which you can examine.\n\nEnable Nonvalidate Constraint State\nWhen a constraint is in the enable nonvalidate state, all subsequent statements are checked for conformity to the constraint. However, any existing data in the table is not checked. A table with enable nonvalidated constraints can contain invalid data, but it is not possible to add new invalid data to it. Enabling constraints in the nonvalidated state is most useful in data warehouse configurations that are uploading valid OLTP data.\n\nEnabling a constraint does not require validation. Enabling a constraint nonvalidate is much faster than enabling and validating a constraint. Also, validating a constraint that is already enabled does not require any DML locks during validation (unlike validating a previously disabled constraint). Enforcement guarantees that no violations are introduced during the validation. Hence, enabling without validating enables you to reduce the downtime typically associated with enabling a constraint.\n\nEfficient Use of Integrity Constraints: A Procedure\n\nUsing integrity constraint states in the following order can ensure the best benefits:\n    Disable state.\n    Perform the operation (load, export, import).\n    Enable nonvalidate state.\n    Enable state.\n\nSome benefits of using constraints in this order are:\n    No locks are held.\n    All constraints can go to enable state concurrently.\n    Constraint enabling is done in parallel.\n    Concurrent activity on table is permitted.\n\nSetting Integrity Constraints Upon Definition\nWhen an integrity constraint is defined in a CREATE TABLE or ALTER TABLE statement, it can be enabled, disabled, or validated or not validated as determined by your specification of the ENABLE/DISABLE clause. If the ENABLE/DISABLE clause is not specified in a constraint definition, the database automatically enables and validates the constraint.\n\nDisabling Constraints Upon Definition\nThe following CREATE TABLE and ALTER TABLE statements both define and disable integrity constraints:\n\nCREATE TABLE emp (\n    empno NUMBER(5) PRIMARY KEY DISABLE,   . . . ;\n\nALTER TABLE emp\n   ADD PRIMARY KEY (empno) DISABLE;\n\nAn ALTER TABLE statement that defines and disables an integrity constraint never fails because of rows in the table that violate the integrity constraint. The definition of the constraint is allowed because its rule is not enforced.\nEnabling Constraints Upon Definition\n\nThe following CREATE TABLE and ALTER TABLE statements both define and enable integrity constraints:\n\nCREATE TABLE emp (\n    empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY,   . . . ;\n\nALTER TABLE emp\n    ADD CONSTRAINT emp.pk PRIMARY KEY (empno);\n\nAn ALTER TABLE statement that defines and attempts to enable an integrity constraint can fail because rows of the table violate the integrity constraint. If this case, the statement is rolled back, and the constraint definition is not stored and not enabled.\n\nWhen you enable a UNIQUE or PRIMARY KEY constraint an associated index is created.","fixText":"Modify database code to properly validate data before it is put into the database or acted upon by the database.\n\nModify database to contain field definitions for each field in the database.\n\nModify database to contain constraints on database columns and tables that require them for data validity.\n\nReview the application schemas implemented on the system.  Check the DDL for the tables that are created for the applications to see if constraints have been enabled.\n\n- - - - -\n\nEnabling Constraints Upon Definition\nThe following CREATE TABLE and ALTER TABLE statements both define and enable integrity constraints:\nCREATE TABLE emp (\n    empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY,   . . . ) ;\nALTER TABLE emp\n    ADD CONSTRAINT emp.pk PRIMARY KEY (empno);\n\nAn ALTER TABLE statement that defines and attempts to enable an integrity constraint can fail because existing rows of the table violate the integrity constraint. In this case, the statement is rolled back, and the constraint definition is not stored and not enabled.\n\nWhen you enable a UNIQUE or PRIMARY KEY constraint, an associated index is created.","ccis":["CCI-001310"]},{"vulnId":"V-219785","ruleId":"SV-219785r961167_rule","severity":"medium","ruleTitle":"The DBMS must only generate error messages that provide information necessary for corrective actions without revealing organization-defined sensitive or potentially harmful information in error logs and administrative messages that could be exploited.","description":"Any application providing too much information in error logs and in administrative messages to the screen risks compromising the data and security of the application and system. The structure and content of error messages needs to be carefully considered by the organization and development team.\n\nThe extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. Sensitive information includes account numbers, social security numbers, and credit card numbers.\n\nDatabases can inadvertently provide a wealth of information to an attacker through improperly handled error messages. In addition to sensitive business or personal information, database errors can provide host names, IP addresses, user names, and other system information not required for troubleshooting but very useful to someone targeting the system.\n\nThis calls for inspection of application source code, which will require 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.","checkContent":"Check DBMS settings and custom database and application code to verify error messages do not contain information beyond what is needed for troubleshooting the issue. If database errors contain PII data, sensitive business data, or information useful for identifying the host system, this is a finding.\n\n(Notes on Oracle's approach to this issue:  Out of the box, Oracle covers this. For example, if a user does not have access to a table, the error is just that the table or view does not exist. The Oracle database is not going to display a Social Security Number in an error code unless an application is programmed to do so.  Oracle applications will not expose the actual transactional data to a screen.  The only way Oracle will capture this information is to enable specific logging levels.  Custom code would require a review to ensure compliance.)","fixText":"Configure DBMS and custom database and application code not to divulge sensitive information or information useful for system identification in error information.","ccis":["CCI-001312"]},{"vulnId":"V-219786","ruleId":"SV-219786r961170_rule","severity":"medium","ruleTitle":"The DBMS must restrict error messages, so only authorized personnel may view them.","description":"If the application provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.\n\nSome default DBMS error messages can contain information that could aid an attacker in, among others things, identifying the database type, host address, or state of the database. Custom errors may contain sensitive customer information. It is important that error messages are displayed only to those who are authorized to view them.\n\nThis calls for inspection of application source code, which will require 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.","checkContent":"Check DBMS settings and custom database code to determine if error messages are ever displayed to unauthorized individuals: \n\ni)  Review all end-user-facing applications that use the database, to determine whether they display any DBMS-generated error messages to general users.  If they do, this is a finding.\n\nii)  Review whether the database is accessible to users who are not authorized system administrators or database administrators, via the  following types of software:   \niia) Oracle SQL*Plus\niib) Reporting and analysis tools\niic) Database management and/or development tools, such as, but not limited to, Toad.\niid) Application development tools, such as, but not limited to, Oracle JDeveloper, Microsoft Visual Studio, PowerBuilder, or Eclipse.\n\nIf the answer to the preceding question (ii through iid) is Yes, inquire whether, for each role or individual with respect to each tool, this access is required to enable the user(s) to perform authorized job duties.  If No, this is a finding.  If Yes, continue:\n\nFor each tool in use, determine whether it is capable of suppressing DBMS-generated error messages, and if it is, whether it is configured to do so.\n\nDetermine whether the role or individual, with respect to each tool, needs to see detailed DBMS-generated error messages.  If No, and if the tool is not configured to suppress such messages, this is a finding.  If Yes, determine whether the role/user's need to see such messages is documented in the System Security Plan.  If so, this is not a finding.  If not, this is a finding.","fixText":"i)  For each end-user-facing application that displays DBMS-generated error messages, configure or recode it to suppress these messages.\n\n(If the application is coded in Oracle PL/SQL, the EXCEPTION block can be used to suppress or divert error messages.  Most other programming languages provide comparable facilities, such as TRY ... CATCH.)\n\nii)  For each unauthorized user of each tool, remove the ability to access it.  For each tool where access to DBMS error messages is not required and can be configured, suppress the messages.  For each role/user that needs access to the error messages, or needs a tool where the messages cannot be suppressed, document the need in the system security plan.","ccis":["CCI-001314"]},{"vulnId":"V-219787","ruleId":"SV-219787r961047_rule","severity":"high","ruleTitle":"Applications must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.","description":"To prevent the compromise of authentication information, such as passwords, during the authentication process, the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism.  \n\nObfuscation of user-provided information when typed into the system is a method used in addressing this risk. \n\nFor example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information.\n\nDatabase applications may allow for entry of the account name and password as a visible parameter of the application execution command. This practice should be prohibited and disabled to prevent shoulder surfing.\n\n\nThis calls for inspection of application source code, which will require 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.","checkContent":"Interview the DBA to determine if any applications that access the database allow for entry of the account name and password on the command line. If any do, determine whether these applications obfuscate authentication data.  If they do not, this is a finding.","fixText":"Configure or modify applications to prohibit display of passwords in clear text on the command line.","ccis":["CCI-000206"]},{"vulnId":"V-219788","ruleId":"SV-219788r961047_rule","severity":"high","ruleTitle":"When using command-line tools such as Oracle SQL*Plus, which can accept a plain-text password, users must use an alternative login method that does not expose the password.","description":"The SRG states:  \"To prevent the compromise of authentication information, such as passwords, during the authentication process, the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism.\"\n\n\"Obfuscation of user-provided information when typed into the system is a method used in addressing this risk.\"\n\n\"For example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information.\"\n\n\"Database applications may allow for entry of the account name and password as a visible parameter of the application execution command. This practice should be prohibited and disabled to prevent shoulder surfing.\"\n\nSQL*Plus is an essential part of any Oracle installation.  SQL*Plus cannot be configured not to accept a plain-text password.  Since the typical SQL*Plus user is a database administrator, the consequences of password compromise are particularly serious.  Therefore, the use of plain-text passwords must be prohibited, as a matter of practice and procedure.","checkContent":"For Oracle SQL*Plus, which cannot be configured not to accept a plain-text password, and any other essential tool with the same limitation, verify that the system documentation explains the need for the tool, who uses it, and any relevant mitigations; and that AO approval has been obtained.  If not, this is a finding.\n\nRequest evidence that all users of the tool are trained in the importance of not using the plain-text password option, and in how to keep the password hidden; and that they adhere to this practice.  If not, this is a finding.","fixText":"For Oracle SQL*Plus, which cannot be configured not to accept a plain-text password, and any other essential tool with the same limitation:\n\n1) Document the need for it, who uses it, and any relevant mitigations, and obtain AO approval.\n2) Train all users of the tool in the importance of not using the plain-text password option, and in how to keep the password hidden.\n\n- - - - -\n\nConsider wrapping the startup command with a shell or wrapper and using an Oracle external password store.\n\nOracle provides the capability to provide for a secure external password facility.  Use the Oracle mkstore to create a secure storage area for passwords for applications, batch jobs and scripts to use or deploy a site-authorized facility to perform this function.\n\nCheck to see what has been stored in the Oracle External Password Store.\n\n  To view all contents of a client wallet external password store, check specific credentials by viewing them. Listing the external password store contents provides information you can use to decide whether to add or delete credentials from the store.\n\nTo list the contents of the external password store, enter the following command at the command line:\n\n  $ mkstore -wrl wallet_location -listCredential\n\n  For example:\n\n  $ mkstore -wrl c:\\oracle\\product\\11.2.0\\db_1\\wallets -listCredential\n\n  The wallet_location specifies the path to the directory where the wallet, whose external password store contents you want to view, is located. This command lists all of the credential database service names (aliases) and the corresponding user name (schema) for that database. Passwords are not listed.\n\nConfiguring Clients to Use the External Password Store:\n\n  If your client is already configured to use external authentication, such as Windows native authentication or Transport Layer Security (TLS), then Oracle Database uses that authentication method. The same credentials used for this type of authentication are typically also used to log in to the database.\n\n  For clients not using such authentication methods or wanting to override them for database authentication, you can set the SQLNET.WALLET_OVERRIDE parameter in sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE, allowing standard use of authentication credentials as before.\n\n  If you want a client to use the secure external password store feature, then perform the following configuration task:\n\n    1. Create a wallet on the client by using the following syntax at the command line:\n \n mkstore -wrl wallet_location -create\n\n    For example:\n\n    mkstore -wrl c:\\oracle\\product\\12.1.0\\db_1\\wallets -create\n    Enter password: password\n\n    The wallet_location is the path to the directory where you want to create and store the wallet. This command creates an Oracle wallet with the autologin feature enabled at the location you specify. The autologin feature enables the client to access the wallet contents without supplying a password. \n \n The mkstore utility -create option uses password complexity verification.\n \n 2. Create database connection credentials in the wallet by using the following syntax at the command line:\n\n    mkstore -wrl wallet_location -createCredential db_connect_string username\n    Enter password: password\n\n    For example:\n\n    mkstore -wrl c:\\oracle\\product\\11.2.0\\db_1\\wallets -createCredential oracle system\n    Enter password: password\n\n    In this specification:\n\n    The wallet_location is the path to the directory where you created the wallet.  The db_connect_string used in the CONNECT /@db_connect_string statement must be identical to the db_connect_string specified in the -createCredential command.\n \n The db_connect_string is the TNS alias you use to specify the database in the tnsnames.ora file or any service name you use to identify the database on an Oracle network. By default, tnsnames.ora is located in the $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME\\network\\admin on Windows.\n \n The username is the database logon credential. When prompted, enter the password for this user.\n \n 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set it to the directory location of the wallet you created in Step 1.  For example, if you created the wallet in \n       $ORACLE_HOME/network/admin and your Oracle home is set to /private/ora11, then you need to enter the following into your client sqlnet.ora file:\n    \n    WALLET_LOCATION =\n           (SOURCE =\n             (METHOD = FILE)\n             (METHOD_DATA =\n           (DIRECTORY = /private/ora11/network/admin)\n           )\n          )\n \n 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter and set it to TRUE as follows:\n\n       SQLNET.WALLET_OVERRIDE = TRUE\n\n       This setting causes all CONNECT /@db_connect_string statements to use the information in the wallet at the specified location to authenticate to databases.\n\n       When external authentication is in use, an authenticated user with such a wallet can use the CONNECT /@db_connect_string syntax to access the previously specified databases without providing a user name and password. However, if a user fails that external authentication, then these connect statements also fail.\n\n    Below is a sample sqlnet.ora file with the WALLET_LOCATION and the SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n        Below is a sample SQLNET.ORA File with Wallet Parameters set:\n\n        WALLET_LOCATION =\n            (SOURCE =\n              (METHOD = FILE)\n              (METHOD_DATA =\n            (DIRECTORY = /private/ora12/network/admin)\n              )\n             )\n\n        SQLNET.WALLET_OVERRIDE = TRUE\n        SSL_CLIENT_AUTHENTICATION = FALSE\n        SSL_VERSION =1.2\n\n(Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files.)","ccis":["CCI-000206"]},{"vulnId":"V-219789","ruleId":"SV-219789r960915_rule","severity":"medium","ruleTitle":"Disk space used by audit trail(s) must be monitored; audit records must be regularly or continuously offloaded to a centralized log management system.","description":"It is critical when a system is at risk of failing to process audit logs as required; it detects and takes action to mitigate the failure. Audit processing failures include:  software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Applications are required to be capable of either directly performing or calling system-level functionality performing defined actions upon detection of an application audit log processing failure.\n\nThe Security Requirements Guide says, \"A failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. The database must be capable of taking organization-defined actions to avoid either a complete halt to processing or processing transactions in an unaudited manner.\"\n\nThis STIG requirement mandates the implementation of a method to mitigate Oracle's inability to automatically reuse audit trail space on a first-in, first-out basis.","checkContent":"Interview the database administrator: review the procedures, manual and/or automated, for monitoring the space used by audit trail(s), and for offloading audit records to a centralized log management system.\n\nIf the procedures do not exist, this is a finding.\n\nIf the procedures exist, request evidence that they are followed.  If the evidence indicates that the procedures are not followed, this is a finding.\n\n If the procedures exist, inquire if the system has ever run out of audit trail space in the last two years or since the last system upgrade, whichever is more recent.  If it has run out of space in this period, and the procedures have not been updated to compensate, this is a finding.","fixText":"Institute procedures, manual and/or automated, for monitoring the space used by audit trail(s), and for offloading audit records to a centralized log management system.","ccis":["CCI-000140"]},{"vulnId":"V-219790","ruleId":"SV-219790r960960_rule","severity":"medium","ruleTitle":"Database software, applications, and configuration files must be monitored to discover unauthorized changes.","description":"Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system.\n\nIf the system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.","checkContent":"Review monitoring procedures and implementation evidence to verify that monitoring of changes to database software libraries, related applications, and configuration files is done.\n\nVerify that the list of files and directories being monitored is complete. If monitoring does not occur or is not complete, this is a finding.","fixText":"Implement procedures to monitor for unauthorized changes to DBMS software libraries, related software application libraries, and configuration files. If a third-party automated tool is not employed, an automated job that reports file information on the directories and files of interest and compares them to the baseline report for the same will meet the requirement.\n\nFile hashes or checksums should be used for comparisons since file dates may be manipulated by malicious users.","ccis":["CCI-001499"]},{"vulnId":"V-219791","ruleId":"SV-219791r960960_rule","severity":"medium","ruleTitle":"Logic modules within the database (to include packages, procedures, functions and triggers) must be monitored to discover unauthorized changes.","description":"Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system.  This includes the logic modules implemented within the database, such as packages, procedures, functions and triggers.\n\nIf the DBMS were to allow any user to make changes to these, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database logic modules can lead to unauthorized or compromised installations.","checkContent":"Review monitoring procedures and implementation evidence to verify that monitoring of changes to database logic modules is done.\n\nVerify the list of objects (packages, procedures, functions, and triggers) being monitored is complete.\n\nIf monitoring does not occur or is not complete, this is a finding.","fixText":"Implement procedures to monitor for unauthorized changes to database logic modules. If a third-party automated tool is not employed, an automated job that reports on the objects of interest and compares them to the baseline report for the same will meet the requirement.","ccis":["CCI-001499"]},{"vulnId":"V-219792","ruleId":"SV-219792r960960_rule","severity":"medium","ruleTitle":"The DBMS software installation account must be restricted to authorized users.","description":"When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. \n\nIf the application were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nThis requirement is contingent upon the language in which the application is programmed, as many application architectures in use today incorporate their software libraries into, and make them inseparable from, their compiled distributions, rendering them static and version-dependent. However, this requirement does apply to applications with software libraries accessible and configurable, as in the case of interpreted languages.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nDBA and other privileged administrative or application owner accounts are granted privileges that allow actions that can have a greater impact on database security and operation. It is especially important to grant access to privileged accounts to only those persons who are qualified and authorized to use them.","checkContent":"Review procedures for controlling and granting access to use of the DBMS software installation account. If access or use of this account is not restricted to the minimum number of personnel required, or if unauthorized access to the account has been granted, this is a finding.","fixText":"Develop, document, and implement procedures to restrict use of the DBMS software installation account.","ccis":["CCI-001499"]},{"vulnId":"V-219793","ruleId":"SV-219793r960960_rule","severity":"medium","ruleTitle":"Database software directories, including DBMS configuration files, must be stored in dedicated directories, or DASD pools, separate from the host OS and other applications.","description":"When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. \n\nMultiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to host system directories can most likely lead to a compromise of all applications hosted by the same system. Database software not installed using dedicated directories both threatens and is threatened by other hosted applications. Access controls defined for one application may by default provide access to the other application's database objects or directories. Any method that provides any level of separation of security context assists in the protection between applications.","checkContent":"Review the DBMS software library directory and note other root directories located on the same disk directory or any subdirectories. If any non-DBMS software directories exist on the disk directory, examine or investigate their use. If any of the directories are used by other applications, including third-party applications that use the DBMS, this is a finding.\n\nOnly applications that are required for the functioning and administration, not use, of the DBMS should be located on the same disk directory as the DBMS software libraries.\n\nFor databases located on mainframes, confirm that the database and its configuration files are isolated in their own DASD pools. If database software and database configuration files share DASD with other applications, this is a finding.","fixText":"Install all applications on directories, or pools, separate from the DBMS software library directory. Re-locate any directories or re-install other application software that currently shares the DBMS software library directory to separate directories.\n\nFor mainframe-based databases, locate database software and configuration files in separate DASD pools from other mainframe applications.","ccis":["CCI-001499"]},{"vulnId":"V-219794","ruleId":"SV-219794r960969_rule","severity":"medium","ruleTitle":"The DBMS must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).","description":"To assure accountability and prevent unauthorized access, organizational users shall be identified and authenticated. \n\nOrganizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). \n\nUsers (and any processes acting on behalf of users) are uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization which outlines specific user actions that can be performed on the information system without identification or authentication.","checkContent":"Review DBMS settings, OS settings, and/or enterprise-level authentication/access mechanism settings, and site practices, to determine whether organizational users are uniquely identified and authenticated when logging onto the system. If organizational users are not uniquely identified and authenticated, this is a finding.","fixText":"Configure DBMS, OS and/or enterprise-level authentication/access mechanism to uniquely identify and authenticate all organizational users who log onto the system.  Ensure that each user has a separate account from all other users.\n\n(This is the default behavior of Oracle.)","ccis":["CCI-000764"]},{"vulnId":"V-219795","ruleId":"SV-219795r961053_rule","severity":"medium","ruleTitle":"The DBMS must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).","description":"Non-organizational users include all information system users other than organizational users which include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations).\n\nNon-organizational users shall be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access, such as accessing a web server.\n\nAccordingly, a risk assessment is used in determining the authentication needs of the organization.\n\nScalability, practicality, and security are simultaneously considered in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals, other organizations, and the Nation.","checkContent":"Review DBMS settings to determine whether non-organizational users are uniquely identified and authenticated when logging onto the system. If non-organizational users are not uniquely identified and authenticated, this is a finding.","fixText":"Configure DBMS settings to uniquely identify and authenticate all non-organizational users who log onto the system.","ccis":["CCI-000804"]},{"vulnId":"V-219796","ruleId":"SV-219796r961095_rule","severity":"medium","ruleTitle":"The DBMS must separate user functionality (including user interface services) from database management functionality.","description":"Information system management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. \n\nThe separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate. \n\nAn example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. \n\nThis may include isolating the administrative interface on a different domain and with additional access controls.\n\nIf administrative functionality or information regarding DBMS management is presented on an interface available for users, information on DBMS settings may be inadvertently made available to the user.","checkContent":"Check DBMS settings and vendor documentation to verify administrative functionality is separate from user functionality. If administrator and general user functionality is not separated either physically or logically, this is a finding.","fixText":"Configure DBMS settings to separate database administration and general user functionality. Provide those who have both administrative and general-user responsibilities with separate accounts for these separate functions.","ccis":["CCI-001082"]},{"vulnId":"V-219797","ruleId":"SV-219797r960864_rule","severity":"low","ruleTitle":"The DBMS must protect against an individual using a group account from falsely denying having performed a particular action.","description":"Non-repudiation of actions taken is required in order to maintain application integrity. Examples of particular actions taken by individuals include creating information, sending a message, approving information (e.g., indicating concurrence or signing a contract), and receiving a message. \n\nNon-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. \n\nGroup authentication does not provide individual accountability for actions taken on the DBMS or data. Whenever a single database account is used to connect to the database, a secondary authentication method that provides individual accountability is required. This scenario most frequently occurs when an externally hosted application authenticates individual users to the application and the application uses a single account to retrieve or update database information on behalf of the individual users.\n\nWhen group accounts are utilized without another means of identifying individual users, users may deny having performed a particular action.\n\n\nThis calls for inspection of application source code, which will require 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.","checkContent":"If there are no group accounts available to more than one user, this is not a finding.\n\nIf a group account is used by an application to interact with the database, review the System Security Plan, the tables in the database, and the application source code/documentation to determine whether the application captures the individual user's identity and stores that identity along with all data inserted and updated (also with all records of reads and/or deletions, if these are required to be logged).  If there are gaps in the application's ability to do this, and the gaps and the risk are not defined in the system documentation and accepted by the AO, this is a finding.\n\nIf users are sharing a group account to log on to Oracle tools or third-party products that access the database, this is a finding.\n\nTo ensure that user activities other than SELECT, INSERT, UPDATE and DELETE are also monitored and attributed to individuals, verify that Oracle auditing is enabled. To see if Oracle is configured to capture audit data, enter the following SQLPlus command:\nSHOW PARAMETER AUDIT_TRAIL\nor the following SQL query:\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\nIf Oracle returns the value 'NONE', this is a finding.","fixText":"Use accounts assigned to individual users where feasible. Configure DBMS to provide individual accountability at the DBMS level, and in audit logs, for actions performed under a shared database account.\n\nModify applications and data tables that are not capturing individual user identity to do so.\n\nCreate and enforce the use of individual user IDs for logging on to Oracle tools and third-party products.\n\nIf Oracle (or third-party) auditing is not already enabled, enable it.  For Oracle auditing, use this query:\nALTER SYSTEM SET AUDIT_TRAIL=<audit trail type> SCOPE=SPFILE;\nAudit trail type can be 'OS', 'DB', 'DB,EXTENDED', 'XML' or 'XML,EXTENDED'.\nAfter executing this statement, it may be necessary to shut down and restart the Oracle database.\n\nFor more information on the configuration of auditing, please refer to \"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm\nand \"Verifying Security Access with Auditing\" in the Oracle Database Security Guide:  http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006\nand \"27 DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm\n\nIf the site-specific audit requirements are not covered by the default audit options, deploy and configure Fine-Grained Auditing.  For details, refer to Oracle documentation, at the locations above.\n\nIf this level of auditing does not meet site-specific requirements, consider deploying the Oracle Audit Vault.  The Audit Vault is a highly configurable option from Oracle made specifically for performing the audit functions.  It has reporting capabilities as well as user-defined rules that provide additional flexibility for complex auditing requirements.","ccis":["CCI-000166"]},{"vulnId":"V-238431","ruleId":"SV-238431r961863_rule","severity":"high","ruleTitle":"DBA OS accounts must be granted only those host system privileges necessary for the administration of the DBMS.","description":"This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account.  \n\nDBAs, if assigned excessive OS privileges, could perform actions that could endanger the information system or hide evidence of malicious activity.","checkContent":"Review host system privileges assigned to the Oracle DBA group and all individual Oracle DBA accounts.\n\nNote: Do not include the Oracle software installation account in any results for this check.\n\nFor UNIX systems (as root):\ncat /etc/group | grep -i dba\ngroups root\n\nIf \"root\" is returned in the first list, this is a finding.\n\nIf any accounts listed in the first list are also listed in the second list, this is a finding.\n\nInvestigate any user account group memberships other than DBA or root groups that are returned by the following command (also as root):\n\ngroups [dba user account]\n\nReplace [dba user account] with the user account name of each DBA account.\n\nIf individual DBA accounts are assigned to groups that grant access or privileges for purposes other than DBA responsibilities, this is a finding.\n\nFor Windows Systems (click or select):\nStart >> Settings >> Control Panel >> Administrative Tools >> Computer Management >> Local Users and Groups >> Groups >> ORA_DBA\nStart >> Settings >> Control Panel >> Administrative Tools >> Computer Management >> Local Users and Groups >> Groups >> ORA_[SID]_DBA (if present)\n\nNote: Users assigned DBA privileges on a Windows host are granted membership in the ORA_DBA and/or ORA_[SID]_DBA groups. The ORA_DBA group grants DBA privileges to any database on the system. The ORA_[SID]_DBA groups grant DBA privileges to specific Oracle instances only.\n\nMake a note of each user listed. For each user (click or select):\nStart >> Settings >> Control Panel >> Administrative Tools >> Computer Management >> Local Users and Groups >> Users >> [DBA user name] >> Member of\n\nIf DBA users belong to any groups other than DBA groups and the Windows Users group, this is a finding.\n\nExamine User Rights assigned to DBA groups or group members:\nStart >> Settings >> Control Panel >> Administrative Tools >> Local Security Policy >> Security Settings >> Local Policies >> User Rights Assignments\n\nIf any User Rights are assigned directly to the DBA group(s) or DBA user accounts, this is a finding.","fixText":"Revoke all host system privileges from the DBA group accounts and DBA user accounts not required for DBMS administration.\n\nRevoke all OS group memberships that assign excessive privileges to the DBA group accounts and DBA user accounts.\n\nRemove any directly applied permissions or user rights from the DBA group accounts and DBA user accounts.\n\nDocument all DBA group accounts and individual DBA account assigned privileges in the System Security Plan.","ccis":["CCI-000366"]},{"vulnId":"V-238432","ruleId":"SV-238432r961683_rule","severity":"high","ruleTitle":"Vendor-supported software must be evaluated and patched against newly found vulnerabilities.","description":"Security faults with software applications and operating systems are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be  addressed expeditiously. \n\nAnytime new software code is introduced to a system there is the potential for unintended consequences. There have been documented instances where the application of a patch has caused problems with system integrity or availability.  Due to information system integrity and availability concerns, organizations must give careful consideration to the methodology used to carry out automatic updates.  \n\nUnsupported software versions are not patched by vendors to address newly discovered security versions. An unpatched version is vulnerable to attack.","checkContent":"Follow the vendor instruction for determining the product version number. View the vendor-provided list of supported versions. To be considered supported, the vendor must report that the version is supported by security patches to reported vulnerabilities. If the security patch support for the installed version cannot be determined or the version is not shown as supported, this is a finding.\n\nIf the software does not contain the latest security patches, this is a finding.\n\nOracle produces security patches on a quarterly basis on or about the fifteenth of the month. The first patch of a calendar year is delivered in January and then April, July and October respectively. There is an automated notice that is available to anyone with access to My Oracle Support. Check to see if the DBA or Administrator of the Oracle account at My Oracle Support is registered to receive the Oracle Security Patch notice. This notice is available to anyone with a valid My Oracle Support. The security notification contains information on the current security update and also the platforms and versions that will be supported by the next patch. For complete information on the availability of the security patch for your specific system, please refer to the Oracle Lifetime Support Policy. Check My Oracle Support for the latest Oracle Quarterly Patch Update patch number, and then check the inventory of the instance you are reviewing and see if the latest security patch is installed using the following command.\n\nIssue the following command:\n\n$ <ORACLE_HOME>/OPatch/opatch lsinventory -detail -oh <ORACLE_HOME>\n\nCheck to see if the latest available patch is installed. \n\nIf the latest available patch is not installed, this is a finding.","fixText":"Upgrade the DBMS to a vendor-supported version.\n\nApply the latest DBMS patches.","ccis":["CCI-002605"]},{"vulnId":"V-238433","ruleId":"SV-238433r961863_rule","severity":"high","ruleTitle":"DBMS default accounts must be assigned custom passwords.","description":"Password maximum lifetime is  the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it.\n\nPasswords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked.\n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.\n\nDBMS default passwords provide a commonly known and exploited means for unauthorized access to database installations.","checkContent":"Use this query to identify the Oracle-supplied accounts that still have their default passwords:\n\nSELECT * FROM SYS.DBA_USERS_WITH_DEFPWD;\n\nIf any accounts other than XS$NULL are listed, this is a finding.\n\n(XS$NULL is an internal account that represents the absence of a user in a session. Because XS$NULL is not a user, this  account can only be accessed by the Oracle Database instance. XS$NULL has no privileges and no one can authenticate as XS$NULL, nor can authentication credentials ever be assigned to XS$NULL.)","fixText":"Change passwords for DBMS accounts to non-default values. Where necessary, unlock or enable accounts to change the password, and then return the account to disabled or locked status.","ccis":["CCI-000366"]},{"vulnId":"V-238434","ruleId":"SV-238434r961638_rule","severity":"high","ruleTitle":"The DBMS must employ cryptographic mechanisms preventing the unauthorized disclosure of information during transmission unless the transmitted data is otherwise protected by alternative physical measures.","description":"Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel.\n\nAlternative 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.\n\nInformation in transmission is particularly vulnerable to attack. If the DBMS does not employ cryptographic mechanisms preventing unauthorized disclosure of information during transit, the information may be compromised.","checkContent":"Check DBMS settings to determine whether cryptographic mechanisms are used to prevent the unauthorized disclosure of information during transmission. \n\nDetermine whether physical measures are being used instead of cryptographic mechanisms. \n\nIf neither cryptographic nor physical measures are being utilized, this is a finding.\n\nTo check that network encryption is enabled and using site-specified encryption procedures, look in SQLNET.ORA located at: $ORACLE_HOME/network/admin/sqlnet.ora.\n\n(Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files.)\n\nIf encryption is set, entries like the following will be present:\n\nSQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (SHA-1)\nSQLNET.ENCRYPTION_TYPES_SERVER= (AES256)\nSQLNET.CRYPTO_CHECKSUM_SERVER = required\n\nSQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT= (SHA-1)\nSQLNET.ENCRYPTION_TYPES_CLIENT= (AES256)\nSQLNET.CRYPTO_CHECKSUM_CLIENT = requested\n\n(The values assigned to the parameters may be different, the combination of parameters may be different, and not all of the example parameters will necessarily exist in the file.)","fixText":"Configure DBMS and/or operating system to use cryptographic mechanisms to prevent unauthorized disclosure of information during transmission where physical measures are not being utilized.","ccis":["CCI-002420"]},{"vulnId":"V-238435","ruleId":"SV-238435r960966_rule","severity":"medium","ruleTitle":"The DBMS must support the disabling of network protocols deemed by the organization to be non-secure.","description":"This requirement is related to remote access, but more specifically to the networking protocols allowing systems to communicate. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization  controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless.  \n\nSome networking protocols allowing remote access may not meet security requirements to protect data and components. Bluetooth and peer-to-peer networking are examples of less than secure networking protocols.  \n\nThe DoD Ports, Protocols, and Services Management (PPSM) program provides implementation guidance on the use of IP protocols and application and data services traversing the DoD Networks in a manner supporting net-centric operations.  \n\nApplications implementing or utilizing remote access network protocols need to ensure the application is developed and implemented in accordance with the PPSM requirements. In situations where it has been determined that specific operational requirements outweigh the risks of enabling an insecure network protocol, the organization may pursue a risk acceptance.\n\nUsing protocols deemed non-secure would compromise the ability of the DBMS to operate in a secure fashion. The database must be able to disable network protocols deemed non-secure.","checkContent":"Review the PPSM Technical Assurance List to acquire an up-to-date list of network protocols deemed non-secure.\n(For definitive information on Ports, Protocols and Services Management (PPSM), refer to http://iase.disa.mil/ppsm/index.html.)\n\nReview DBMS settings to determine if the database is utilizing any network protocols deemed non-secure.  If the DBMS is not using any network protocols deemed non-secure, this is not a finding..\n\nIf the database is utilizing protocols specified as non-secure in the PPSM, verify the protocols are explicitly identified in the System Security Plan and that they are in support of specific operational requirements. If they are not identified in the SSP or are not supporting specific operational requirements, this is a finding. \n\nIf non-secure network protocols are not being used but are not disabled in the DBMS's configuration, this is a finding.\n\nAfter determining the site-specific operational requirements and which protocols are explicitly defined in the System Security Plan, check the $TNS_ADMIN setting for the location of the Oracle listener.ora file.  The listener.ora file is a configuration file for Oracle Net Listener that identifies the following:\n  A unique name for the listener, typically LISTENER\n  A protocol address that it is accepting connection requests on, and \n  A service it is listening for.\n  \nIf the listener.ora file shows a PROTOCOL= statement and the PROTOCOL is deemed non-secure, that is a finding.\n\nLISTENER=\n  (DESCRIPTION=\n    (ADDRESS_LIST=\n      (ADDRESS=(PROTOCOL=tcp)(HOST=sale-server)(PORT=1521))\n      (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))\nSID_LIST_LISTENER=\n  (SID_LIST=\n    (SID_DESC=\n      (GLOBAL_DBNAME=sales.us.example.com)\n      (ORACLE_HOME=/oracle11g)\n      (SID_NAME=sales))\n    (SID_DESC=\n      (SID_NAME=plsextproc)\n      (ORACLE_HOME=/oracle11g)\n      (PROGRAM=extproc)))\n\nProtocol Parameters\n\nThe Oracle Listener and the Oracle Connection Manager are identified by protocol addresses. The information below contains the \"Protocol-Specific Parameters\" used by the Oracle protocol support.\n\nProtocol-Specific Parameters\n\nProtocol: IPC     Parameter: PROTOCOL  Notes: Specify ipc as the value.\nProtocol: IPC     Parameter: KEY       Notes: Specify a unique name for the service. Oracle recommends using the service name or SID of the service.\n                                                 Example: (PROTOCOL=ipc)(KEY=sales)\n \nProtocol: Named Pipes  Parameter: PROTOCOL  Notes: Specify nmp as the value.\nProtocol: Named Pipes  Parameter: SERVER    Notes: Specify the name of the Oracle server.\nProtocol: Named Pipes  Parameter: PIPE      Notes: Specify the pipe name used to connect to the database server. \n                                               This is the same PIPE keyword specified on the server with Named Pipes.  This name can be any name.\n                                               Example: (Protocol=nmp) (SERVER=USDOD) (PIPE=dbpipe01)\n            \nProtocol: SDP     Parameter: PROTOCOL  Notes: Specify sdp as the value.\nProtocol: SDP     Parameter: HOST      Notes: Specify the host name or IP address of the computer.\nProtocol: SDP     Parameter: PORT      Notes: Specify the listening port number.\n                                                 Example:\n                                                        (PROTOCOL=sdp)(HOST=sales-server)(PORT=1521)\n                                                        (PROTOCOL=sdp)(HOST=192.168.2.204)(PORT=1521)\n \nProtocol: TCP/IP  Parameter: PROTOCOL  Notes: Specify TCP as the value.\nProtocol: TCP/IP  Parameter: HOST      Notes: Specify the host name or IP address of the computer.\nProtocol: TCP/IP  Parameter: PORT      Notes: Specify the listening port number.\n                                                Example:\n                                                        (PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)\n                                                        (PROTOCOL=tcp)(HOST=192.168.2.204)(PORT=1521)\n \nProtocol: TCP/IP with SSL  Parameter: PROTOCOL  Notes: Specify tcps as the value.\nProtocol: TCP/IP with SSL  Parameter: HOST      Notes: Specify the host name or IP address of the computer.\nProtocol: TCP/IP with SSL  Parameter: PORT      Notes: Specify the listening port number.\n                                                        Example:\n                                                                (PROTOCOL=tcps)(HOST=sales-server) (PORT=2484)\n                                                                (PROTOCOL=tcps)(HOST=192.168.2.204)(PORT=2484)","fixText":"Disable any network protocol listed as non-secure in the PPSM documentation.\n\nTo disable the protocol deemed not secure, stop the listener by issuing the following command as the Oracle Software owner, typically Oracle.\n          $ lsnrctl stop\nThis will stop the listener.  Edit the LISTENER.ORA file and remove the protocols deemed not secure and restart the listener.  \n\nFor example, if TCP was deemed as not secure and the listener.ora would need to be changed and the tcp entry would need to be removed.  That would only allow the listener to listen for an IPC connection.   \n\nLISTENER=\n  (DESCRIPTION=\n    (ADDRESS_LIST=\n      (ADDRESS=(PROTOCOL=tcp)(HOST=sale-server)(PORT=1521)) - remove this line and properly balance the parentheses -\n      (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))\nSID_LIST_LISTENER=\n  (SID_LIST=\n    (SID_DESC=\n      (GLOBAL_DBNAME=sales.us.example.com)\n      (ORACLE_HOME=/oracle11g)\n      (SID_NAME=sales))\n    (SID_DESC=\n      (SID_NAME=plsextproc)\n      (ORACLE_HOME=/oracle11g)\n      (PROGRAM=extproc)))\n\nRevise the client side TNSNAMES.ORA to align the PROTOCOL value in the PROTOCOL portion of the connect string.  For example, if TCP was deemed as not secure and the listener.ora was changed to listen for an IPC connection the code below would be required:\n\nnet_service_name=\n(DESCRIPTION=\n(ADDRESS=(PROTOCOL=tcp)(HOST=sales1-svr)(PORT=1521))\n(ADDRESS=(PROTOCOL=tcp)(HOST=sales2-svr)(PORT=1521))\n(CONNECT_DATA=\n(SERVICE_NAME=sales.us.example.com)))","ccis":["CCI-000382"]},{"vulnId":"V-238436","ruleId":"SV-238436r961863_rule","severity":"medium","ruleTitle":"The DBMS must provide a mechanism to automatically identify accounts designated as temporary or emergency accounts.","description":"Temporary application accounts could be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support-related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left.  \n\nTo address this, in the event temporary application accounts are required, the application must ensure accounts designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period.  Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised. \n\nNote: User authentication and account management should 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.\n\nTemporary database accounts must be identified in order for the system to recognize and terminate them after a given time period. The DBMS and any administrators must have a means to recognize any temporary accounts for special handling.","checkContent":"If the organization has a policy, consistently enforced, forbidding the creation of emergency or temporary accounts, this is not a finding.\n\nIf all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding.\n\nIf using database mechanisms to satisfy this requirement, look for a profile for use with temporary accounts.\n\nTo obtain a list of profiles:\n\nSELECT PROFILE#, NAME FROM SYS.PROFNAME$;\n\nTo obtain a list of users assigned a given profile (TEMPORARY_USERS, in this example):\n\nSELECT USERNAME, PROFILE FROM SYS.DBA_USERS\nWHERE PROFILE = 'TEMPORARY_USERS'\nORDER BY USERNAME;\n\nTo obtain a list of users that have NOT been assigned the DEFAULT (the resulting list of profiles can be quickly scanned for any profile like TEMPORARY, in this example):\n\nSELECT USERNAME, PROFILE FROM SYS.DBA_USERS\nWHERE PROFILE <> 'DEFAULT'\nORDER BY PROFILE;\n\nIf no profile for temporary accounts can be identified, this is not a finding.","fixText":"Use a profile with a distinctive name (for example, TEMPORARY_USERS), so that temporary users can be easily identified. Whenever a temporary user account is created, assign it to this profile.\n\nSet values in the profile as needed for temporary users - see below for further information. The values here are examples; set them to values appropriate to the situation:\n\nCREATE PROFILE TEMPORARY_USERS\nLIMIT\nSESSIONS_PER_USER <limit>\nCPU_PER_SESSION <limit>\nCPU_PER_CALL <limit>\nCONNECT_TIME <limit>\nLOGICAL_READS_PER_SESSION <limit>\nLOGICAL_READS_PER_CALL <limit>\nPRIVATE_SGA <limit>\nCOMPOSITE_LIMIT <limit>\nFAILED_LOGIN_ATTEMPTS 3\nPASSWORD_LIFE_TIME 7\nPASSWORD_REUSE_TIME 60\nPASSWORD_REUSE_MAX 5\nPASSWORD_VERIFY_FUNCTION <verify_function>\nPASSWORD_LOCK_TIME UNLIMITED\nPASSWORD_GRACE_TIME 3;\nCREATE USER TEMP001 IDENTIFIED BY PassWord#TEMP01 PROFILE TEMPORARY_USERS;\n\nResource Parameters:\n\nSESSIONS_PER_USER - Specify the number of concurrent sessions to which you want to limit the user.\n\nCPU_PER_SESSION - Specify the CPU time limit for a session, expressed in hundredths of seconds.\n\nCPU_PER_CALL - Specify the CPU time limit for a call (a parse, execute, or fetch), expressed in hundredths of seconds.\n\nCONNECT_TIME - Specify the total elapsed time limit for a session, expressed in minutes.\n\nIDLE_TIME - Specify the permitted periods of continuous inactive time during a session, expressed in minutes. Long-running queries and other operations are not subject to this limit.\n\nLOGICAL_READS_PER_SESSION - Specify the permitted number of data blocks read in a session, including blocks read from memory and disk.\n\nLOGICAL_READS_PER_CALL - Specify the permitted number of data blocks read for a call to process a SQL statement (a parse, execute, or fetch).\n\nPRIVATE_SGA - Specify the amount of private space a session can allocate in the shared pool of the system global area (SGA). Refer to size_clause for information on that clause.\n\nCOMPOSITE_LIMIT - See Oracle documentation for more details.\n\nPassword Parameters:\n\nUse the following clauses to set password parameters. Parameters that set lengths of time are interpreted in number of days. For testing purposes you can specify minutes (n/1440) or even seconds (n/86400).\n\nFAILED_LOGIN_ATTEMPTS - Specify the number of failed attempts to log in to the user account before the account is locked.\n\nPASSWORD_LIFE_TIME - Specify the number of days the same password can be used for authentication. If you also set a value for PASSWORD_GRACE_TIME, then the password expires if it is not changed within the grace period, and further connections are rejected. If you omit this clause, then the default is 180 days.\n\nPASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX - These two parameters must be set in conjunction with each other. PASSWORD_REUSE_TIME specifies the number of days before which a password cannot be reused. PASSWORD_REUSE_MAX specifies the number of password changes required before the current password can be reused. For these parameters to have any effect, you must specify an integer for both of them.\n\nIf you specify an integer for both of these parameters, then the user cannot reuse a password until the password has been changed the number of times specified for PASSWORD_REUSE_MAX during the number of days specified for PASSWORD_REUSE_TIME.\n\nFor example, if you specify PASSWORD_REUSE_TIME to 30 and PASSWORD_REUSE_MAX to 10, then the user can reuse the password after 30 days if the password has already been changed 10 times.\n\nIf you specify an integer for either of these parameters and specify UNLIMITED for the other, then the user can never reuse a password.\n\nIf you specify DEFAULT for either parameter, then Oracle Database uses the value defined in the DEFAULT profile. By default, all parameters are set to UNLIMITED in the DEFAULT profile. If you have not changed the default setting of UNLIMITED in the DEFAULT profile, then the database treats the value for that parameter as UNLIMITED.\n\nIf you set both of these parameters to UNLIMITED, then the database ignores both of them. This is the default if you omit both parameters.\n\nPASSWORD_LOCK_TIME - Specify the number of days an account will be locked after the specified number of consecutive failed logon attempts. If you omit this clause, then the default is 1 day.\n\nPASSWORD_GRACE_TIME - Specify the number of days after the grace period begins during which a warning is issued and logon is allowed. If you omit this clause, then the default is 7 days.\n\nPASSWORD_VERIFY_FUNCTION - lets a PL/SQL password complexity verification script be passed as an argument to the CREATE PROFILE statement. Oracle Database provides a default script, but you can create your own routine or use third-party software instead.","ccis":["CCI-000366"]},{"vulnId":"V-238437","ruleId":"SV-238437r961863_rule","severity":"medium","ruleTitle":"The DBMS must provide a mechanism to automatically terminate accounts designated as temporary or emergency accounts after an organization-defined time period.","description":"Temporary application accounts could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left.  \n\nTo address this, in the event temporary application accounts are required, the application must ensure accounts designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period. Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised. \n\nUser authentication and account management should 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.\n\nTemporary database accounts must be automatically terminated after an organization-defined time period in order to mitigate the risk of the account being used beyond its original purpose or timeframe.","checkContent":"If the organization has a policy, consistently enforced, forbidding the creation of emergency or temporary accounts, this is not a finding.\n\nIf all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding.\n\nCheck DBMS settings, OS settings, and/or enterprise-level authentication/access mechanisms settings to determine if the site utilizes a mechanism whereby temporary or emergency accounts can be terminated after an organization-defined time period. If not, this is a finding.\n\nCheck the profiles to see what the password_life_time is set to in the table dba_profiles. The password_life_time is a value stored in the LIMIT column, and identified by the value PASSWORD_LIFE_TIME in the RESOURCE_NAME column.\n\nSQL>select\nprofile,\nresource_name,\nresource_type,\nlimit\nfrom dba_profiles\nwhere upper(resource_name) like 'PASSWORD_LIFE_TIME';\n\nVerify that the user in question is assigned to a profile with the PASSWORD_LIFE_TIME set to the amount of time the user is expected to be using the password.  If not, this is a finding.","fixText":"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.\n\nIf using database mechanisms to satisfy this requirement, use a profile with a distinctive name (for example, TEMPORARY_USERS), so that temporary users can be easily identified.  Whenever a temporary user account is created, assign it to this profile.\n\nCreate a job to lock accounts under this profile that are more than n days old, where n is the organization-defined time period.","ccis":["CCI-000366"]},{"vulnId":"V-238438","ruleId":"SV-238438r961317_rule","severity":"medium","ruleTitle":"The DBMS must enforce Discretionary Access Control (DAC) policy allowing users to specify and control sharing by named individuals, groups of individuals, or by both, limiting propagation of access rights and includes or excludes access to the granularity of a single user.","description":"Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains). \n\nDAC is a type of access control methodology serving as a means of restricting access to objects and data based on the identity of subjects and/or groups to which they belong. It is discretionary in the sense that application users with the appropriate permissions to access an application resource or data have the discretion to pass that permission on to another user either directly or indirectly.\n\nData protection requirements may result in a DAC policy being specified as part of the application design. Discretionary access controls would be employed at the application level to restrict and control access to application objects and data thereby providing increased information security for the organization.  \n\nWhen DAC controls are employed, those controls must limit sharing to named application users, groups of users, or both. The application DAC controls must also limit the propagation of access rights and have the ability to exclude access to data down to the granularity of a single user.\n\nDatabases using DAC must have the ability for the owner of an object or information to assign or revoke rights to view or modify the object or information.  If the owner of an object or information does not have rights to exclude access to an object or information at a user level, users may gain access to objects and information they are not authorized to view/modify.","checkContent":"Check DBMS settings to determine if users are able to assign and revoke rights to the objects and information that they own. If users cannot assign or revoke rights to the objects and information that they own to groups, roles, or individual users, this is a finding.","fixText":"Modify DBMS settings to allow users to assign or revoke access rights to objects and information owned by the user. The ability to grant or revoke rights must include the ability to grant or revoke those rights down to the granularity of a single user.\n\n(Note:  in most cases no fix will be necessary.  This is default functionality for Oracle.)","ccis":["CCI-002165"]},{"vulnId":"V-238439","ruleId":"SV-238439r960792_rule","severity":"medium","ruleTitle":"The DBMS must restrict grants to sensitive information to authorized user roles.","description":"Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nUnauthorized access to sensitive data may compromise the confidentiality of personnel privacy, threaten national security, or compromise a variety of other sensitive operations. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user.","checkContent":"Obtain a list of privileges assigned to user accounts. If access to sensitive information is granted to roles not authorized to access sensitive information, this is a finding.\n\nIf access to sensitive information is granted to individual accounts rather than to a role, this is a finding.","fixText":"Define application user roles based on privilege and job function requirements. \n\nAssign the required privileges to the role and assign the role to authorized application user accounts.\n\nRevoke any privileges to sensitive information directly assigned to application user accounts.","ccis":["CCI-000213"]},{"vulnId":"V-238440","ruleId":"SV-238440r961863_rule","severity":"medium","ruleTitle":"A single database connection configuration file must not be used to configure all database clients.","description":"Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nMany sites distribute a single client database connection configuration file to all site database users that contains network access information for all databases on the site. Such a file provides information to access databases not required by all users that may assist in unauthorized access attempts.","checkContent":"Review procedures for providing database connection information to users/user workstations. If procedures do not indicate or implement restrictions to connections required by the particular user, this is a finding.\n\nNote: This check is specific for the DBMS host system and not directed at client systems (client systems are included in the Application STIG/Checklist); however, detection of unauthorized client connections to the DBMS host system obtained through log files should be performed regularly and documented where authorized.","fixText":"Implement procedures to supply database connection information to only those databases authorized for the user.","ccis":["CCI-000366"]},{"vulnId":"V-238441","ruleId":"SV-238441r960960_rule","severity":"medium","ruleTitle":"The DBMS must be protected from unauthorized access by developers.","description":"Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nDevelopers granted elevated database and/or operating system privileges on production databases can affect the operation and/or security of the database system. Operating system and database privileges assigned to developers on production systems must not be allowed.","checkContent":"Check the production system to ensure no developer accounts have rights to modify the production database structure or alter production data.   \n\nIf developer accounts with these rights exist, ask for documentation that shows these accounts have formal approval and risk acceptance. If this documentation does not exist, this is a finding.\n\nIf developer accounts exist with the right to create and maintain tables (or other database objects) in production tablespaces, this is a finding.","fixText":"Restrict developer privileges to production objects to only objects and data where those privileges are required and authorized.  Document the approval and risk acceptance.\n\nConsider using separate accounts for a person's developer duties and production duties.  At a minimum, use separate roles for developer privileges and production privileges.\n\nIf developers need the ability to create and maintain tables (or other database objects) as part of their development activities, provide dedicated tablespaces, and revoke any rights that allowed them to use production tablespaces for this purpose.","ccis":["CCI-001499"]},{"vulnId":"V-238442","ruleId":"SV-238442r961863_rule","severity":"medium","ruleTitle":"The DBMS must be protected from unauthorized access by developers on shared production/development host systems.","description":"Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nDevelopers granted elevated database and/or operating system privileges on systems that support both development and production databases can affect the operation and/or security of the production database system. Operating system and database privileges assigned to developers on shared development and production systems must be restricted.","checkContent":"Identify whether any hosts contain both development and production databases. If no hosts contain both production and development databases, this is NA.\n\nFor any host containing both a development and a production database, determine if developers have been granted elevated privileges on the production database or on the OS.  If they have, ask for documentation that shows these accounts have formal approval and risk acceptance. If this documentation does not exist, this is a finding.\n\nIf developer accounts exist with the right to create and maintain tables (or other database objects) in production tablespaces, this is a finding.\n\n(Where applicable, to check the number of instances on the host machine, check the /etc/oratab.  The /etc/oratab file is updated by the Oracle Installer when the database is installed when the root.sh file is executed.  Each line in the represents an ORACLE_SID:ORACLE_HOME:Y or N.  The ORACLE_SID and ORACLE_HOME are self-explanatory.  The Y or N signals the DBSTART program to automatically start or not start that specific instance when the machine is restarted.  Check with the system owner and application development team to see what each entry represents.  If a system is deemed to be a production system review the system for development users.)","fixText":"Restrict developer privileges to production objects to only objects and data where those privileges are required and authorized.  Document the approval and risk acceptance.\n\nConsider using separate accounts for a person's developer duties and production duties.  At a minimum, use separate roles for developer privileges and production privileges.\n\nIf developers need the ability to create and maintain tables (or other database objects) as part of their development activities, provide dedicated tablespaces, and revoke any rights that allowed them to use production tablespaces for this purpose.","ccis":["CCI-000366"]},{"vulnId":"V-238443","ruleId":"SV-238443r961149_rule","severity":"medium","ruleTitle":"The DBMS must restrict access to system tables and other configuration information or metadata to DBAs or other authorized users.","description":"Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nAdministrative data includes DBMS metadata and other configuration and management data.  Unauthorized access to this data could result in unauthorized changes to database objects, access controls, or DBMS configuration.","checkContent":"Review user privileges to system tables and configuration data stored in the Oracle database. If non-DBA users are assigned privileges to access system tables and tables containing configuration data, this is a finding.\n\nTo obtain a list of users and roles that have been granted access to any dictionary table, run the query:\nSELECT unique grantee from dba_tab_privs where table_name in\n(select table_name from dictionary)\norder by grantee;\n\nTo obtain a list of dictionary tables and assigned privileges granted to a specific user or role, run the query:\n\nSELECT grantee, table_name, privilege from dba_tab_privs where table_name in\n\n(select table_name from dictionary)\nand grantee = '<applicable account>';","fixText":"Restrict accessibility of Oracle system tables and other configuration information or metadata to DBAs or other authorized users.","ccis":["CCI-001090"]},{"vulnId":"V-238444","ruleId":"SV-238444r960960_rule","severity":"medium","ruleTitle":"Administrative privileges must be assigned to database accounts via database roles.","description":"Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems.\n\nPrivileges granted outside the context of the application user job function are more likely to go unmanaged or without oversight for authorization. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment.","checkContent":"Review accounts for direct assignment of administrative privilege.  Connected as SYSDBA, run the query:\n\nSELECT grantee, privilege\nFROM   dba_sys_privs\nWHERE  grantee IN \n(\nSELECT username\nFROM   dba_users\nWHERE  username NOT IN \n(\n'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n'DVSYS', 'DVF', 'SYSMAN_RO',\n'SYSMAN_BIPLATFORM', 'SYSMAN_MDS',\n'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n'SYSMAN', 'APEX_040200', 'WMSYS',\n'SYSDG', 'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n'SPATIAL_CSW_ADMIN_US', 'GSMCATUSER',\n'OLAPSYS', 'SI_INFORMTN_SCHEMA',\n'OUTLN', 'ORDSYS', 'ORDDATA', 'OJVMSYS',\n'ORACLE_OCM', 'MDSYS', 'ORDPLUGINS',\n'GSMADMIN_INTERNAL', 'MDDATA', 'FLOWS_FILES',\n'DIP', 'CTXSYS', 'AUDSYS',\n'APPQOSSYS', 'APEX_PUBLIC_USER', 'ANONYMOUS',\n'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n'SYSMAN_TYPES', 'MGMT_VIEW',\n'EUS_ENGINE_USER', 'EXFSYS', 'SYSMAN_APM'\n)\n)\nAND privilege NOT IN ('UNLIMITED TABLESPACE')\nORDER  BY 1, 2;\n\nIf any administrative privileges have been assigned directly to a database account, this is a finding.\n\n(The list of special accounts that are excluded from this requirement may not be complete.  It is expected that the DBA will edit the list to suit local circumstances, adding other special accounts as necessary, and removing any that are not supposed to be in use in the Oracle deployment that is under review.)","fixText":"Create roles for administrative function assignments. Assign the necessary privileges for the administrative functions to a role.","ccis":["CCI-001499"]},{"vulnId":"V-238445","ruleId":"SV-238445r961131_rule","severity":"medium","ruleTitle":"Administrators must utilize a separate, distinct administrative account when performing administrative activities, accessing database security functions, or accessing security-relevant information.","description":"This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. \n\nTo limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.\n\nWhen privileged activities are not separated from non-privileged activities, the database can be subject to unauthorized changes to settings and data that a standard user would not normally have access to, outside of an authorized maintenance session.","checkContent":"Review permissions for objects owned by DBA or other administrative accounts.\n\nIf any objects owned by administrative accounts can be accessed by non-DBA/non-administrative users, either directly or indirectly, this is a finding.\n\nVerify DBAs have separate administrative accounts.\n\nIf DBAs do not have a separate account for database administration purposes, this is a finding.\n\nTo list all objects owned by an administrative account that have had access granted to another account, run the query:\n\nSELECT grantee, table_name, grantor, privilege from dba_tab_privs where owner= '<applicable account>';","fixText":"Revoke DBA privileges, and privileges to administer DBA-owned objects, from non-DBA accounts.\n\nProvide separate accounts to DBA for database administration.","ccis":["CCI-001084"]},{"vulnId":"V-238446","ruleId":"SV-238446r961863_rule","severity":"medium","ruleTitle":"The DBA role must not be assigned excessive or unauthorized privileges.","description":"This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. \n\nAudit of privileged activity may require physical separation employing information systems on which the user does not have privileged access.\n\nTo limit exposure and provide forensic history of activity when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.\n\nIf feasible, applications must provide access logging that ensures users who are granted a privileged role (or roles) have their privileged activity logged.\n\nDBAs, if assigned excessive privileges, could perform actions that endanger the information system or hide evidence of malicious activity.","checkContent":"Review access permissions for objects owned by application owners or other non-administrative users.\n\nIf DBA or administrative accounts have unauthorized application roles or permissions beyond those needed for administration, this is a finding.\n\nTo obtain a list of privileges assigned to the DBMS user accounts, run the query:\nSELECT * from dba_sys_privs where grantee='DBA' order by privilege;\n\nTo check to see what roles are assigned to a user, run the query:\nSELECT * from dba_role_privs where grantee = '<applicable account>';\n\nTo check to see what privileges are assigned to a role, run the query:\nSELECT * from role_sys_privs;\n\nTo show privileges by object, run the query:\nSELECT table_name, grantee,\nMAX(DECODE(privilege, 'SELECT', 'SELECT')) AS select_priv,\nMAX(DECODE(privilege, 'DELETE', 'DELETE')) AS delete_priv,\nMAX(DECODE(privilege, 'UPDATE', 'UPDATE')) AS update_priv,\nMAX(DECODE(privilege, 'INSERT', 'INSERT')) AS insert_priv\nFROM dba_tab_privs\nWHERE grantee IN (SELECT role FROM dba_roles)\nGROUP BY table_name, grantee\nORDER BY table_name, grantee;\n\nThis query will list the system privileges assigned to a specific user:\nSELECT LPAD(' ', 2*level) || granted_role \"USER PRIVS\"\nFROM \n(\nSELECT NULL grantee, username granted_role\nFROM dba_users\nWHERE username LIKE UPPER('%&uname%')\nUNION\nSELECT grantee, granted_role\nFROM dba_role_privs\nUNION\nSELECT grantee, privilege\nFROM dba_sys_privs\n)\nSTART WITH grantee IS NULL\nCONNECT BY grantee = prior granted_role;\n\nTo list all administrative privileges granted to users via roles, run the query:\nSELECT \nusername,\nrp.granted_role,\nprivilege\nFROM\ndba_users u,\ndba_role_privs rp,\ndba_sys_privs sp\nWHERE username = rp.grantee\nAND rp.granted_role = sp.grantee\nAND privilege NOT IN \n(\n'CREATE SEQUENCE', 'CREATE TRIGGER',\n'SET CONTAINER', 'CREATE CLUSTER',\n'CREATE PROCEDURE', 'CREATE TYPE',\n'CREATE SESSION', 'CREATE OPERATOR',\n'CREATE TABLE', 'CREATE INDEXTYPE' \n)\nAND username NOT IN \n(\n'XDB', 'SYSTEM', 'SYS', 'LBACSYS',\n'DVSYS', 'DVF', 'SYSMAN_RO', 'SYSMAN_BIPLATFORM',\n'SYSMAN_MDS', 'SYSMAN_OPSS', 'SYSMAN_STB', 'DBSNMP',\n'SYSMAN', 'APEX_040200', 'WMSYS', 'SYSDG',\n'SYSBACKUP', 'SPATIAL_WFS_ADMIN_USR',\n'SPATIAL_CSW_ADMIN_US','GSMCATUSER',\n'OLAPSYS', 'SI_INFORMTN_SCHEMA', 'OUTLN', 'ORDSYS',\n'ORDDATA', 'OJVMSYS', 'ORACLE_OCM', 'MDSYS',\n'ORDPLUGINS', 'GSMADMIN_INTERNAL', 'MDDATA',\n'FLOWS_FILES', 'DIP', 'CTXSYS', 'AUDSYS', 'APPQOSSYS',\n'APEX_PUBLIC_USER', 'ANONYMOUS',\n'SPATIAL_CSW_ADMIN_USR', 'SYSKM',\n'SYSMAN_TYPES', 'MGMT_VIEW', 'EUS_ENGINE_USER',\n'EXFSYS', 'SYSMAN_APM','IX','OWBSYS'\n) \nORDER by 1, 2, 3;\n\n(The list of special accounts that are excluded from this requirement may not be complete. It is expected that the DBA will edit the list to suit local circumstances, adding other special accounts as necessary, and removing any that are not supposed to be in use in the Oracle deployment that is under review. Similarly, the list of privileges excluded from the list may be modified according to circumstances.)\n\nData Dictionary Objects Related To System Privileges:\nall_sys_privs\nsession_privs\nuser_sys_privs\ndba_sys_privs\nsystem_privilege_map","fixText":"Remove permissions from DBAs and other administrative users beyond those required for administrative functions.","ccis":["CCI-000366"]},{"vulnId":"V-238447","ruleId":"SV-238447r960963_rule","severity":"medium","ruleTitle":"OS accounts utilized to run external procedures called by the DBMS must have limited privileges.","description":"This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC) is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. \n\nTo limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.\n\nUse of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts if used for non-administration application development or application maintenance can lead to miss-assignment of privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in and provided by applications.\n\nExternal applications called or spawned by the DBMS process may be executed under OS accounts with unnecessary privileges. This can lead to unauthorized access to OS resources and compromise of the OS, the DBMS or any other services provided by the host platform.","checkContent":"Determine which OS accounts are used by the DBMS to run external procedures. Validate that these OS accounts have only the privileges necessary to perform the required functionality. If any OS accounts, utilized by the database for running external procedures, have privileges beyond those required for running the external procedures, this is a finding.\n\nSystem views providing privilege information are:\nDBA_SYS_PRIVS\nDBA_TAB_PRIVS\nDBA_ROLE_PRIVS","fixText":"Limit privileges to DBMS-related OS accounts to those required to perform their DBMS specific functionality.","ccis":["CCI-000381"]},{"vulnId":"V-238448","ruleId":"SV-238448r961863_rule","severity":"medium","ruleTitle":"The DBMS must specify an account lockout duration that is greater than or equal to the organization-approved minimum.","description":"Anytime an authentication method is exposed, to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access.\n\nTo defeat these attempts, organizations define the number of times a user account may consecutively fail a logon attempt. The organization also defines the period of time in which these consecutive failed attempts may occur.\n\nBy limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.\n\nUser 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.","checkContent":"The account lockout duration is defined in the profile assigned to a user.\n\nTo see what profile is assigned to a user, enter the query:\n\nSELECT profile FROM dba_users WHERE username = '&USERNAME'\n\nThis will return the profile name assigned to that user.\n\nNow check the values assigned to the profile returned from the query above:\n\nSELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE LIKE '&PROFILE_NAME'  \n\nCheck the settings for password_lock_time - this specifies how long to lock the account after the number of consecutive failed logon attempts reaches the limit. If the value is not UNLIMITED, this is a finding.","fixText":"Configure the DBMS settings to specify indefinite lockout duration:\n\nALTER PROFILE '&PROFILE_NAME' LIMIT PASSWORD_LOCK_TIME UNLIMITED;","ccis":["CCI-000366"]},{"vulnId":"V-238449","ruleId":"SV-238449r961863_rule","severity":"medium","ruleTitle":"The DBMS must have the capability to limit the number of failed login attempts based upon an organization-defined number of consecutive invalid attempts occurring within an organization-defined time period.","description":"Anytime an authentication method is exposed,  to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. \n\nTo defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. \n\nBy limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. \n\nMore recent brute force attacks make attempts over long periods of time to circumvent intrusion detection systems and system account lockouts based entirely on the number of failed logins that are typically reset after a successful login.\n\nNote 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.\n\nNote also that a policy that places no limit on the length of the timeframe (for counting consecutive invalid attempts) does satisfy this requirement.","checkContent":"(This addresses both O112-C2-005000 and O112-C2-005200.)\n\nThe limit on the number of consecutive failed logon attempts is defined in the profile assigned to a user.\n\nTo see what profile is assigned to a user, enter the following query:\nSQL>SELECT profile FROM dba_users WHERE username = '&USERNAME'\nThis will return the profile name assigned to that user.\n\nNow check the values assigned to the profile returned from the query above:\nSQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE LIKE '&PROFILE_NAME'  \n\nCheck the settings for failed_login_attempts - this is the number of consecutive failed login attempts before locking the Oracle user account. If the value is greater than 3, this is a finding.","fixText":"(This addresses both O112-C2-005000 and O112-C2-005200.)\n\nConfigure the DBMS settings to specify the maximum number of consecutive failed login attempts to 3 (or less):\nALTER PROFILE '&PROFILE_NAME' LIMIT FAILED_LOGON_ATTEMPTS 3;","ccis":["CCI-000366"]},{"vulnId":"V-238450","ruleId":"SV-238450r961317_rule","severity":"medium","ruleTitle":"Databases utilizing Discretionary Access Control (DAC) must enforce a policy that limits propagation of access rights.","description":"Discretionary Access Control (DAC) is based on the premise that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment.\n\nDAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. DAC models have the potential for the access controls to propagate without limit, resulting in unauthorized access to said objects.\n\nWhen applications provide a discretionary access control mechanism, the application must be able to limit the propagation of those access rights.\n\nThe DBMS must ensure the recipient of permissions possesses only the access intended. The database must enforce the ability to limit rights propagation if that is the intent of the grantor. If the propagation of access rights is not limited, users with rights to objects they do not own can continue to grant rights to those objects to other users without limit.\n\nThis is default for behavior for Oracle.","checkContent":"Verify the DBMS has the ability to grant permissions without the grantee receiving the right to grant those same permissions to another user.\n\nReview organization policies regarding access propagation. If an access propagation policy limiting the propagation of rights does not exist, this is a finding.\n\nReview DBMS configuration to verify access propagation policies are enforced by the DBMS as configured. If the DBMS does not enforce the access propagation policy, this is a finding.","fixText":"Create and document an access propagation policy that limits the propagation of rights.\n\nConfigure the DBMS to enforce the access propagation policy.\n\nWhen a user is granted access to an object they have access to the object.  When a used is granted access to an object with the ADMIN option, then they can provide permissions to others.  Without the ADMIN option, a user cannot grant access to an object.  No configuration is required.","ccis":["CCI-002165"]},{"vulnId":"V-238451","ruleId":"SV-238451r961317_rule","severity":"medium","ruleTitle":"A DBMS utilizing Discretionary Access Control (DAC) must enforce a policy that includes or excludes access to the granularity of a single user.","description":"DAC is based on the notion that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment.\n\nDAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions.\n\nIncluding or excluding access to the granularity of a single user means providing the capability to either allow or deny access to objects (e.g., files, folders) on a per single user basis.\n\nDatabases using DAC must have the ability for the owner of an object or information to assign or revoke rights to view or modify the object or information.  If the owner of an object or information does not have rights to exclude access to an object or information at a user level, users may gain access to objects and information they are not authorized to view/modify.","checkContent":"Check DBMS settings and documentation to determine if users are able to assign and revoke rights to the objects and information they own. If users cannot assign or revoke rights to the objects and information they own to the granularity of a single user, this is a finding.\n\n(This is default Oracle behavior.)","fixText":"Modify DBMS settings to allow users to assign or revoke access rights to objects and information owned by the user. The ability to grant or revoke rights must include the ability to grant or revoke those rights down to the granularity of a single user. \n\n(This is default Oracle behavior.)","ccis":["CCI-002165"]},{"vulnId":"V-238452","ruleId":"SV-238452r961398_rule","severity":"medium","ruleTitle":"The DBMS itself, or the logging or alerting mechanism the application utilizes, must provide a warning when allocated audit record storage volume reaches an organization-defined percentage of maximum audit record storage capacity.","description":"It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include:  software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. \n\nIf audit log capacity were to be exceeded, then events subsequently occurring would not be recorded. Organizations shall define a maximum allowable percentage of storage capacity serving as an alarming threshold (e.g., application has exceeded 80% of log storage capacity allocated) at which time the application or the logging mechanism the application utilizes will provide a warning to the appropriate personnel.\n\nA failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. When audit processing fails, appropriate personnel must be alerted immediately to avoid further downtime or unaudited transactions.  This can be an alert provided by the database, a log repository, or the OS when a designated log directory is nearing capacity.","checkContent":"Review DBMS, OS, or third-party logging application settings to determine whether a warning will be provided when a specific percentage of log storage capacity is reached. If no warning will be provided, this is a finding.","fixText":"Modify DBMS, OS, or third-party logging application settings to alert appropriate personnel when a specific percentage of log storage capacity is reached.\n\nFor ease of management, it is recommended that the audit tables be kept in a dedicated tablespace.\n\nIf Oracle Enterprise Manager is in use, the capability to issue such an alert is built in and configurable via the console so an email can be sent to a designated administrator.\n\nIf Enterprise Manager is unavailable, the following script can be used to monitor storage space; this can be combined with additional code to email the appropriate administrator so they can take action.\n\nsqlplus connect as sysdba\n\nSQL> set pagesize 300  \nSQL> set linesize 120  \nSQL> column sumb format 9,999,999,999,999  \nSQL> column extents format 999999  \nSQL> column bytes format 9,999,999,999,999  \nSQL> column largest format 9,999,999,999,999  \nSQL> column Tot_Size format 9,999,999,999,999  \nSQL> column Tot_Free format 9,999,999,999,999  \nSQL> column Pct_Free format 9,999,999,999,999  \nSQL> column Chunks_Free format 9,999,999,999,999   \nSQL> column Max_Free format 9,999,999,999,999  \nSQL> set echo off  \nSQL> spool TSINFO.txt  \nSQL> PROMPT  SPACE AVAILABLE IN TABLESPACES   \nSQL> select a.tablespace_name,sum(a.tots) Tot_Size,   \nSQL> sum(a.sumb) Tot_Free,  \nSQL> sum(a.sumb)*100/sum(a.tots) Pct_Free,   \nSQL> sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free   \nSQL> from   \nSQL> (  \nSQL> select tablespace_name,0 tots,sum(bytes) sumb,   \nSQL> max(bytes) largest,count(*) chunks  \nSQL> from dba_free_space a  \nSQL> group by tablespace_name  \nSQL> union  \nSQL> select tablespace_name,sum(bytes) tots,0,0,0 from  \nSQL> dba_data_files  \nSQL> group by tablespace_name) a  \nSQL> group by a.tablespace_name;  \n \n Sample Output\n \nSPACE AVAILABLE IN TABLESPACES \n \n TABLESPACE_NAME                     TOT_SIZE     TOT_FREE     PCT_FREE     MAX_FREE     CHUNKS_FREE\n ------------------------------      ------------ ------------ ------------ ------------ ------------ \nDES2                                 41,943,040   30,935,040       74       30,935,040        1 \nDES2_I                               31,457,280   23,396,352       74       23,396,352        1 \nRBS                                  60,817,408   57,085,952       94       52,426,752       16 \nSYSTEM                               94,371,840    5,386,240        6        5,013,504        3 \nTEMP                                    563,200      561,152      100          133,120        5 \nTOOLS                               120,586,240   89,407,488       74       78,190,592       12 \nUSERS                                 1,048,576       26,624        3           26,624        1","ccis":["CCI-001855"]},{"vulnId":"V-238453","ruleId":"SV-238453r961401_rule","severity":"medium","ruleTitle":"The DBMS must provide a real-time alert when organization-defined audit failure events occur.","description":"It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include:  software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. \n\nIf audit log capacity were to be exceeded, then events subsequently occurring would not be recorded. Organizations shall define a maximum allowable percentage of storage capacity serving as an alarming threshold (e.g., application has exceeded 80% of log storage capacity allocated) at which time the application or the logging mechanism the application utilizes will provide a warning to the appropriate personnel. \n\nA failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. When audit processing fails, appropriate personnel must be alerted immediately to avoid further downtime or unaudited transactions.  This can be an alert provided by the database, a log repository, or the OS when a designated log directory is nearing capacity.\n\nIf Oracle Enterprise Manager is in use, the capability to issue such an alert is built in and configurable via the console so an alert can be sent to a designated administrator.","checkContent":"Review Oracle Corp., OS, or third-party logging software settings to determine whether a real-time alert will be sent to the appropriate personnel when auditing fails for any reason.\n\nIf real-time alerts are not sent upon auditing failure, this is a finding.","fixText":"Configure logging software to send a real-time alert to appropriate personnel when auditing fails for any reason.\n\n(Oracle recommends the use of Oracle Enterprise Manager.)","ccis":["CCI-001858"]},{"vulnId":"V-238454","ruleId":"SV-238454r961461_rule","severity":"medium","ruleTitle":"The DBMS must support enforcement of logical access restrictions associated with changes to the DBMS configuration and to the database itself.","description":"When dealing with access restrictions pertaining to change control, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can have significant effects on the overall security of the system. \n\nAccordingly, only qualified and authorized individuals must be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications. \n\nModifications to the DBMS settings, the database files, database configuration files, or the underlying database application files themselves could have catastrophic consequences to the database.  Modification to DBMS settings could include turning off access controls to the database, the halting of archiving, the halting of auditing, and any number of other malicious actions.","checkContent":"Review DBMS settings and vendor documentation to ensure the database supports and does not interfere with enforcement of logical access restrictions associated with changes to the DBMS configuration and to the database itself. If the DBMS software in any way restricts the implementation of logical access controls implemented to protect its integrity or availability, this is a finding.","fixText":"Configure the DBMS to allow implementation of logical access restrictions aimed at protecting the DBMS from unauthorized changes to its configuration and to the database itself.\n\n- - - - -\n\nWhen the Oracle Database is installed on a Unix-like operating system, the required umask is 022, and the file permissions are set so that any modifications to the startup files can only be performed by the owner of the software, a member of the group DBA  or the root user. Changing the umask has caused problems when patching the environment.  If changes are to be made, they should be reverted to the status they were in before the modification for patching and upgrades.","ccis":["CCI-001813"]},{"vulnId":"V-238455","ruleId":"SV-238455r961863_rule","severity":"medium","ruleTitle":"Database backup procedures must be defined, documented, and implemented.","description":"Information system backup is a critical step in maintaining data assurance and availability. \n\nUser-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media.\n\nApplications performing backups must be capable of backing up user-level information per the DoD-defined frequency.\n\nDatabase backups provide the required means to restore databases after compromise or loss. Backups help reduce the vulnerability to unauthorized access or hardware loss.","checkContent":"Review the database backup procedures and implementation evidence. Evidence of implementation includes records of backup events and physical review of backup media.\n\nEvidence should match the backup plan as recorded in the system documentation. If backup procedures do not exist or are not implemented in accordance with the procedures, this is a finding.\n\n- - - - -\n\nThe Oracle recommended process for backup and recovery is Oracle RMAN.  If Oracle RMAN is deployed, execute the following commands to ensure that the evidence of the implementation of the backup policy includes validating that the files are restorable:\n\nValidating Database Files with BACKUP VALIDATE\n --You can use the BACKUP VALIDATE command to do the following:\n    --     Check datafiles for physical and logical block corruption\n    --     Confirm that all database files exist and are in the correct locations\n --When you run BACKUP VALIDATE, RMAN reads the files to be backed up in their entirety, as it would during a real backup. RMAN does not, however, actually produce any backup sets or image copies.\n--You cannot use the BACKUPSET, MAXCORRUPT, or PROXY parameters with BACKUP VALIDATE. \n--To validate files with the BACKUP VALIDATE command:\n     1. Start RMAN and connect to a target database and recovery catalog (if used).\n     2. Run the BACKUP VALIDATE command.\n        For example, you can validate that all database files and archived logs can be backed up by running a command as shown in the following example. This command checks for physical corruptions only.\n        BACKUP VALIDATE\n          DATABASE\n          ARCHIVELOG ALL;\n      To check for logical corruptions in addition to physical corruptions, run the  following variation of the preceding command:\n        BACKUP VALIDATE\n          CHECK LOGICAL\n          DATABASE\n          ARCHIVELOG ALL;\n   In the preceding examples, the RMAN client displays the same output that it would if it were really backing up the files. If RMAN cannot back up one or more of the files, then it issues an error message. \nValidating Backups Before Restoring Them\n   \n   You can run RESTORE ... VALIDATE to test whether RMAN can restore a specific file or set of files from a backup. RMAN chooses which backups to use. The database must be mounted or open for this command. You do not have to take datafiles offline when validating the restore of datafiles, because validation of backups of the datafiles only reads the backups and does not affect the production datafiles. When validating files on disk or tape, RMAN reads all blocks in the backup piece or image copy. RMAN also validates offsite backups. The validation is identical to a real restore operation except that RMAN does not write output files.\n   \n   To validate backups with the RESTORE command:\n     1. Run the RESTORE command with the VALIDATE option.\n        This following example illustrates validating the restore of the database and all archived redo logs:\n        RESTORE DATABASE VALIDATE;\n          RESTORE ARCHIVELOG ALL VALIDATE;\n\n  If you do not see an RMAN error stack, then skip the subsequent steps. The lack of error messages means that RMAN had confirmed that it can use these backups successfully during a real restore and recovery.\n\n 2. If you see error messages in the output and the RMAN-06026 message, then investigate the cause of the problem. If possible, correct the problem that is preventing RMAN from validating the backups and retry the validation. The following error means that RMAN cannot restore one or more of the specified files from your available backups:\n\n    RMAN-06026: some targets not found - aborting restore\n       The following sample output shows that RMAN encountered a problem reading the specified backup:\n       RMAN-03009: failure of restore command on c1 channel at 12-DEC-06 23:22:30\n       ORA-19505: failed to identify file \"oracle/dbs/1fafv9gl_1_1\"\n       ORA-27037: unable to obtain file status\n       SVR4 Error: 2: No such file or directory\n       Additional information: 3","fixText":"Develop, document, and implement database backup procedures.","ccis":["CCI-000366"]},{"vulnId":"V-238456","ruleId":"SV-238456r961863_rule","severity":"medium","ruleTitle":"Database recovery procedures must be developed, documented, implemented, and periodically tested.","description":"Information system backup is a critical step in maintaining data assurance and availability. \n\nUser-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency.  This includes data stored on file systems, within databases or within any other storage media.\n\nApplications performing backups must be capable of backing up user-level information per the DoD-defined frequency.\n\nProblems with backup procedures or backup media may not be discovered until after a recovery is needed. Testing and verification of procedures provides the opportunity to discover oversights, conflicts, or other issues in the backup procedures or use of media designed to be used.","checkContent":"Review the testing and verification procedures documented in the system documentation. Review evidence of implementation of testing and verification procedures by reviewing logs from backup and recovery implementation. Logs may be in electronic form or hardcopy and may include email or other notification. If testing and verification of backup and recovery procedures is not documented in the system documentation, this is a finding.\n\nIf evidence of testing and verification of backup and recovery procedures does not exist, this is a finding.","fixText":"Develop, document, and implement testing and verification procedures for database backup and recovery. Include requirements for documenting database backup and recovery testing and verification activities in the procedures.","ccis":["CCI-000366"]},{"vulnId":"V-238457","ruleId":"SV-238457r961149_rule","severity":"medium","ruleTitle":"DBMS backup and restoration files must be protected from unauthorized access.","description":"Information system backup is a critical step in maintaining data assurance and availability. \n\nUser-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media.\n\nApplications performing backups must be capable of backing up user-level information per the DoD-defined frequency.\n\nLost or compromised DBMS backup and restoration files may lead to not only the loss of data, but also the unauthorized access to sensitive data. Backup files need the same protections against unauthorized access when stored on backup media as when online and actively in use by the database system. In addition, the backup media needs to be protected against physical loss. Most DBMS's maintain online copies of critical control files to provide transparent or easy recovery from hard disk loss or other interruptions to database operation.","checkContent":"Review file protections assigned to online backup and restoration files. Review access protections and procedures for offline backup and restoration files. If backup or restoration files are subject to unauthorized access, this is a finding.\n\nIt may be necessary to review backup and restoration procedures to determine ownership and access during all phases of backup and recovery.","fixText":"Implement protection for backup and restoration files. Document personnel and the level of access authorized for each to the backup and restoration files in the system documentation.","ccis":["CCI-001090"]},{"vulnId":"V-238458","ruleId":"SV-238458r960768_rule","severity":"high","ruleTitle":"The DBMS must use multifactor authentication for access to user accounts.","description":"Multifactor authentication is defined as using two or more factors to achieve authentication.\n\nFactors include: \n(i) Something a user knows (e.g., password/PIN); \n(ii) Something a user has (e.g., cryptographic identification device, token); or\n(iii) Something a user is (e.g., biometric).\n\nThe DBMS must be configured to automatically utilize organization-level account management functions, and these functions must immediately enforce the organization's current account policy. \n\n\nThe lack of multifactor authentication makes it much easier for an attacker to gain unauthorized access to a system.\n\nTransport 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.\nUse authentication to prove the identities of users who are attempting to log on to the database. Oracle Database enables strong authentication with Oracle authentication adapters that support various third-party authentication services, including TLS with digital certificates, as well as Smart Cards (CAC, PIV).","checkContent":"If all user accounts are authenticated by the organization-level authentication/access mechanism and not by the DBMS, this is not a finding.\nReview DBMS settings, OS settings, and/or enterprise-level authentication/access mechanism settings to determine whether user accounts are required to use multifactor authentication.\n\nIf user accounts are not required to use multifactor authentication, this is a finding.\n\n\n\nIf the $ORACLE_HOME/network/admin/sqlnet.ora contains entries similar to the following, TLS is enabled. (Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files.)\n\nSQLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS)\nSSL_VERSION = 1.2\nSSL_CLIENT_AUTHENTICATION = TRUE\nWALLET_LOCATION =\n(SOURCE =\n(METHOD = FILE)\n(METHOD_DATA =\n(DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/owm/wallets)\n)\n)\n\nSSL_CIPHER_SUITES= (SSL_RSA_WITH_AES_256_CBC_SHA384)\nADR_BASE = /u01/app/oracle","fixText":"Configure DBMS, OS and/or enterprise-level authentication/access mechanism to require multifactor authentication for user accounts.\n\nIf appropriate, enable support for Transport Layer Security (TLS) protocols and multifactor authentication through the use of Smart Cards (CAC/PIV).\nOracle Database is capable of being configured to integrate users with an enterprise-level authentication/access mechanism.\n \nThe directions are in the Oracle Database Security Guide, Section 6\n\nhttps://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/database-security-guide.pdf#page=318\n\nThis section will give detailed step-by-step directions to configure authentication using PKI Certificates for centrally managed users by configuring Secure Sockets Layer in the Oracle database and integrating with LDAP.","ccis":["CCI-000765","CCI-000766","CCI-000767","CCI-000768"]},{"vulnId":"V-238459","ruleId":"SV-238459r960969_rule","severity":"medium","ruleTitle":"The DBMS must ensure users are authenticated with an individual authenticator prior to using a group authenticator.","description":"To assure individual accountability and prevent unauthorized access, application users (and any processes acting on behalf of users) must be individually identified and authenticated.  \n\nA group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users. An example of a group authenticator is the UNIX OS 'root' user account, a Windows 'administrator' account, an 'SA' account, or a 'helpdesk' account.\n\nFor example, the UNIX and Windows operating systems offer a 'switch user' capability allowing users to authenticate with their individual credentials and, when needed, 'switch' to the administrator role. This method provides for unique individual authentication prior to using a group authenticator.\n\nSome applications may not have the need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply.\n\nThere may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server which contains publicly releasable information. These types of accesses are allowed but must be explicitly identified and documented by the organization.\n\nWhen group accounts are utilized without another means of identifying individual users, users may deny having performed a particular action.","checkContent":"Review DBMS settings, OS settings, and/or enterprise-level authentication/access mechanism settings to determine whether group accounts exist. If group accounts do not exist, this is NA. \n\nReview DBMS settings to determine if individual authentication is required before group authentication. If group authentication does not require prior individual authentication, this is a finding.\n\n(Oracle Access Manager may be helpful in meeting this requirement. Notes on Oracle Access Manager follow.)\n\nOracle Access Manager is used when there is a need for multifactor authentication of applications front-ending Oracle Datasets that may use group accounts. Oracle Access Manager supports using PKI-based smart cards (CAC, PIV) for multifactor authentication. When a user authenticates to a smart card application, the smart card engine produces a certificate-based authentication token. You can configure a certificate-based authentication scheme in Oracle Access Manager that uses information from the smart card certificate. Certificate-based authentication works with any smart card or similar device that presents an X.509 certificate.\n\nCheck:\n\nFirst, check that the Authentication Module is set up properly:\n1)  Go to Oracle Access Manager Home Screen and click the Policy Configuration tab.  Select the X509Scheme.\n2)  Make sure the Authentication Module option is set to X509Plugin.\n\nSecond, check your Authentication policy is using the x509Scheme:\n1)  Go to Oracle Access Manager Home Screen and click the Policy Configuration tab.\n2)  Select Application Domains.  Select Search.\n3)  Select the application domain protecting the Oracle Database.\n4)  Select the Authentication Polices tab and Click Protected Resource Policy.\n5)  Make sure the Authentication Scheme is set to x509Scheme.","fixText":"Configure DBMS, OS and/or enterprise-level authentication/access mechanism to require individual authentication prior to authentication for group account access.\n\nIf appropriate, install Oracle Access Manager to provide multifactor authentication of applications front-ending Oracle Databases and using group accounts.  After installation, use x509 Authentication modules provided out of the box.","ccis":["CCI-000764"]},{"vulnId":"V-238460","ruleId":"SV-238460r961863_rule","severity":"medium","ruleTitle":"The DBMS must disable user accounts after 35 days of inactivity.","description":"Attackers that are able to exploit an inactive DBMS account can potentially obtain and maintain undetected access to the database. \n\nOwners of inactive DBMS accounts will not notice if unauthorized access to their user account has been obtained. All DBMS need to track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be hijacked, leading to a data compromise.\n \nTo address access requirements, some database administrators choose to integrate their databases with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the database administrator to off-load those access control functions and focus on core application features and functionality. \n\nThis policy does not apply to either emergency accounts or infrequently used accounts. Infrequently used accounts are local logon administrator accounts used by system administrators when network or normal logon/access is not available. Emergency accounts are administrator accounts created in response to crisis situations.\n\nNote 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","checkContent":"If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding.\n\nFor accounts managed by Oracle, check DBMS settings to determine if accounts can be automatically disabled by the system after 35 days of inactivity. Also, ask the DBA if an alternative method, such as a stored procedure run daily, to disable Oracle-managed accounts inactive for more than 35 days, has been deployed. \n\nIf the ability to disable accounts after 35 days of inactivity, by either of these means, does not exist, this is a finding.","fixText":"For accounts managed by Oracle, create a script or store procedure that runs once a day.\n\nWrite a SQL statement to determine accounts that have not logged in within 35 days:\n \nExample:\nselect username from dba_audit_trail where  action_name = 'LOGON'\ngroup  by username having max(timestamp) < sysdate - 36\n\nAnd then disable all accounts that have not logged in within 35 days.","ccis":["CCI-000366"]},{"vulnId":"V-238461","ruleId":"SV-238461r981946_rule","severity":"medium","ruleTitle":"The DBMS must support organizational requirements to enforce minimum password length.","description":"Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nTo meet password policy requirements, passwords need to be changed at specific policy-based intervals.  \n\nIf the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. \n\nWeak passwords are a primary target for attack to gain unauthorized access to databases and other systems. Where username/password is used for identification and authentication to the database, requiring the use of strong passwords can help prevent simple and more sophisticated methods for guessing at passwords.\n\nNote 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.","checkContent":"If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here:  this is not a finding against the DBMS.\n\nFor each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use:\n\nSELECT * FROM SYS.DBA_PROFILES \nWHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n[AND PROFILE NOT IN (<list of non-applicable profiles>)]\nORDER BY PROFILE;\nBearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile.\n\nIf, for any profile, the function name is null, this is a finding.  \n\nFor each password verification function, examine its source code.  If it does not enforce the DoD-defined minimum length (15 unless otherwise specified), this is a finding.","fixText":"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.\n\nIf any user accounts are managed by Oracle:  Develop, test and implement a password verification function that enforces DoD requirements.\n\n(Oracle supplies a sample function called verify_function_11G, in the script file \n<oracle_home>/RDBMS/ADMIN/utlpwdmg.sql.  This can be used as the starting point for a customized function.)","ccis":["CCI-000192"]},{"vulnId":"V-238462","ruleId":"SV-238462r981946_rule","severity":"medium","ruleTitle":"The DBMS must support organizational requirements to prohibit password reuse for the organization-defined number of generations.","description":"Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nTo meet password policy requirements, passwords need to be changed at specific policy-based intervals.  \n\nIf the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. \n\nPassword reuse restrictions protect against bypass of password expiration requirements and help protect accounts from password guessing attempts.\n\nNote 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.","checkContent":"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.\n\nFor each profile that can be applied to accounts where authentication is under Oracle's control, determine the password reuse rule, if any, that is in effect:\nSELECT * FROM SYS.DBA_PROFILES \nWHERE RESOURCE_NAME IN ('PASSWORD_REUSE_MAX', 'PASSWORD_REUSE_TIME')\n[AND PROFILE NOT IN (<list of non-applicable profiles>)]\nORDER BY PROFILE, RESOURCE_NAME;\nBearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the value of the PASSWORD_REUSE_MAX effective for each profile.\n\nIf, for any profile, the PASSWORD_REUSE_MAX value does not enforce the DoD-defined minimum number of password changes before a password may be repeated (5 or greater), this is a finding.  PASSWORD_REUSE_MAX is effective if and only if PASSWORD_REUSE_TIME is specified, so if both are UNLIMITED, this is a finding.","fixText":"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.\n\nIf any user accounts are managed by Oracle:  For each profile, set the PASSWORD_REUSE_MAX to enforce the DoD-defined minimum number of password changes before a password may be repeated (5 or greater).  \n\nPASSWORD_REUSE_MAX is effective if and only if PASSWORD_REUSE_TIME is specified, so ensure also that it has a meaningful value.  Since the minimum password lifetime is 1 day, the smallest meaningful value is the same as the PASSWORD_REUSE_MAX value.\n\nUsing PPPPPP as an example, the statement to do this is:\nALTER PROFILE PPPPPP LIMIT PASSWORD_REUSE_MAX 5 PASSWORD_REUSE_TIME 5;","ccis":["CCI-000192"]},{"vulnId":"V-238463","ruleId":"SV-238463r981946_rule","severity":"medium","ruleTitle":"The DBMS must support organizational requirements to enforce password complexity by the number of upper-case characters used.","description":"Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password.\n\nNote 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.","checkContent":"If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here:  this is not a finding against the DBMS.\n\nFor each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use:\n\nSELECT * FROM SYS.DBA_PROFILES \nWHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n[AND PROFILE NOT IN (<list of non-applicable profiles>)]\nORDER BY PROFILE;\nBearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile.\n\nIf, for any profile, the function name is null, this is a finding.  \n\nFor each password verification function, examine its source code.  If it does not enforce the organization-defined minimum number of upper-case characters (1 unless otherwise specified), this is a finding.","fixText":"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.\n\nIf any user accounts are managed by Oracle:  Develop, test and implement a password verification function that enforces DoD requirements.\n\n(Oracle supplies a sample function called verify_function_11G, in the script file \n<oracle_home>/RDBMS/ADMIN/utlpwdmg.sql.  This can be used as the starting point for a customized function.)","ccis":["CCI-000192"]},{"vulnId":"V-238464","ruleId":"SV-238464r981946_rule","severity":"medium","ruleTitle":"The DBMS must support organizational requirements to enforce password complexity by the number of lower-case characters used.","description":"Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password.\n\nNote 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.","checkContent":"If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here:  this is not a finding against the DBMS.\n\nFor each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use:\n\nSELECT * FROM SYS.DBA_PROFILES \nWHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n[AND PROFILE NOT IN (<list of non-applicable profiles>)]\nORDER BY PROFILE;\nBearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile.\n\nIf, for any profile, the function name is null, this is a finding.  \n\nFor each password verification function, examine its source code.  If it does not enforce the organization-defined minimum number of lower-case characters (1 unless otherwise specified), this is a finding.","fixText":"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.\n\nIf any user accounts are managed by Oracle:  Develop, test and implement a password verification function that enforces DoD requirements.\n\n(Oracle supplies a sample function called verify_function_11G, in the script file \n<oracle_home>/RDBMS/ADMIN/utlpwdmg.sql.  This can be used as the starting point for a customized function.)","ccis":["CCI-000192"]},{"vulnId":"V-238465","ruleId":"SV-238465r981946_rule","severity":"medium","ruleTitle":"The DBMS must support organizational requirements to enforce password complexity by the number of numeric characters used.","description":"Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password.\n\nNote 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.","checkContent":"If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here:  this is not a finding against the DBMS.\n\nFor each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use:\n\nSELECT * FROM SYS.DBA_PROFILES \nWHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n[AND PROFILE NOT IN (<list of non-applicable profiles>)]\nORDER BY PROFILE;\nBearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile.\n\nIf, for any profile, the function name is null, this is a finding.  \n\nFor each password verification function, examine its source code.  If it does not enforce the organization-defined minimum number of numeric characters (1 unless otherwise specified), this is a finding.","fixText":"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.\n\nIf any user accounts are managed by Oracle:  Develop, test and implement a password verification function that enforces DoD requirements.\n\n(Oracle supplies a sample function called verify_function_11G, in the script file \n<oracle_home>/RDBMS/ADMIN/utlpwdmg.sql.  This can be used as the starting point for a customized function.)","ccis":["CCI-000192"]},{"vulnId":"V-238466","ruleId":"SV-238466r981946_rule","severity":"medium","ruleTitle":"The DBMS must support organizational requirements to enforce password complexity by the number of special characters used.","description":"Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password.\n\nNote 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.","checkContent":"If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here:  this is not a finding against the DBMS.\n\nFor each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use:\n\nSELECT * FROM SYS.DBA_PROFILES \nWHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n[AND PROFILE NOT IN (<list of non-applicable profiles>)]\nORDER BY PROFILE;\nBearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile.\n\nIf, for any profile, the function name is null, this is a finding.  \n\nFor each password verification function, examine its source code.  If it does not enforce the organization-defined minimum number of special characters (1 unless otherwise specified), this is a finding.","fixText":"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.\n\nIf any user accounts are managed by Oracle:  Develop, test and implement a password verification function that enforces DoD requirements.\n\n(Oracle supplies a sample function called verify_function_11G, in the script file \n<oracle_home>/RDBMS/ADMIN/utlpwdmg.sql.  This can be used as the starting point for a customized function.)","ccis":["CCI-000192"]},{"vulnId":"V-238467","ruleId":"SV-238467r981946_rule","severity":"medium","ruleTitle":"The DBMS must support organizational requirements to enforce the number of characters that get changed when passwords are changed.","description":"Passwords need to be changed at specific policy-based intervals.\n\nIf the information system or application allows the user to consecutively reuse extensive portions of their password when they change their password, the end result is a password that has not had enough elements changed to meet the policy requirements.\n\nChanging passwords frequently can thwart password-guessing attempts or re-establish protection of a compromised DBMS account. Minor changes to passwords may not accomplish this since password guessing may be able to continue to build on previous guesses, or the new password may be easily guessed using the old password.\n\nNote 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.","checkContent":"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.\n\nFor each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use:\n\nSELECT * FROM SYS.DBA_PROFILES \nWHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION'\n[AND PROFILE NOT IN (<list of non-applicable profiles>)]\nORDER BY PROFILE;\nBearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile.\n\nIf, for any profile, the function name is null, this is a finding.  \n\nFor each password verification function, examine its source code.  If it does not enforce the organization-defined minimum number of characters by which the password must differ from the previous password (eight of the characters unless otherwise specified), this is a finding.","fixText":"If any user accounts are managed by Oracle:  Develop, test and implement a password verification function that enforces DoD requirements.\n\n(Oracle supplies a sample function called verify_function_11G, in the script file \n<oracle_home>/RDBMS/ADMIN/utlpwdmg.sql.  This can be used as the starting point for a customized function.)","ccis":["CCI-000192"]},{"vulnId":"V-238468","ruleId":"SV-238468r981946_rule","severity":"medium","ruleTitle":"Procedures for establishing temporary passwords that meet DoD password requirements for new accounts must be defined, documented, and implemented.","description":"Password maximum lifetime is  the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it.\n\nPasswords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked.\n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.\n\nNew accounts authenticated by passwords that are created without a password or with an easily guessed password are vulnerable to unauthorized access. Procedures for creating new accounts with passwords should include the required assignment of a temporary password to be modified by the user upon first use.\n\nNote 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  With respect to Oracle, this requirement applies to cases where it is necessary to have accounts directly managed by Oracle.","checkContent":"If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here:  this is not a finding against the DBMS.\n\nWhere 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 DoD password requirements, this is a finding.","fixText":"Implement procedures for assigning temporary passwords to user accounts.\n\nProcedures should include instructions to meet current DoD password length and complexity requirements and provide a secure method to relay the temporary password to the user.","ccis":["CCI-000192"]},{"vulnId":"V-238469","ruleId":"SV-238469r961863_rule","severity":"medium","ruleTitle":"DBMS passwords must not be stored in compiled, encoded, or encrypted batch jobs or compiled, encoded, or encrypted application source code.","description":"Password maximum lifetime is  the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it.\n\nPasswords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked.\n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.\n\nThe storage of passwords in application source or batch job code that is compiled, encoded, or encrypted prevents compliance with password expiration and other management requirements, as well as provides another means for potential discovery.\n\nThis requirement applies equally to those accounts managed by Oracle and those managed and authenticated by the OS or an enterprise-wide mechanism.\n\nThis requirement should not be construed as prohibiting or discouraging the encryption of source code, which remains an advisable precaution.\n\nThis calls for inspection of application source code, which will require 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.","checkContent":"Review application source code required to be encoded or encrypted for database accounts used by applications or batch jobs to access the database.\n\nReview 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.\n\nDetermine if the compiled, encoded, or encrypted application source code or batch jobs contain passwords used for authentication to the database.\n\nIf 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.\n\n\nThe check would depend on the information provided by the DBA.  In a default Oracle installation, all passwords are stored in an encrypted manner.  Ask the DBA if they have created an External Password Store for applications, batch jobs, and scripts to use.\n\nSecure External Password Store:\n\nYou can store password credentials for connecting to databases by using a client-side Oracle wallet. An Oracle wallet is a secure software container that stores authentication and signing credentials.\n\nThis wallet usage can simplify large-scale deployments that rely on password credentials for connecting to databases. When this feature is configured, application code, batch jobs, and scripts no longer need embedded user names and passwords. This reduces risk because the passwords are no longer exposed, and password management policies are more easily enforced without changing application code whenever user names or passwords change.\n  \nThe external password store of the wallet is separate from the area where public key infrastructure (PKI) credentials are stored. Consequently, you cannot use Oracle Wallet Manager to manage credentials in the external password store of the wallet. Instead, use the command-line utility mkstore to manage these credentials.\n  \nHow Does the External Password Store Work?\n\nTypically, users (and as applications, batch jobs, and scripts) connect to databases by using a standard CONNECT statement that specifies a database connection string. This string can include a user name and password, and an Oracle Net service name identifying the database on an Oracle Database network. If the password is omitted, the connection prompts the user for the password.\n\nFor example, the service name could be the URL that identifies that database, or a TNS alias you entered in the tnsnames.ora file in the database. Another possibility is a host:port:sid string.\n  \nThe following examples are standard CONNECT statements that could be used for a client that is not configured to use the external password store:\n\n  CONNECT salesapp@sales_db.us.example.com\n  Enter password: password\n\n  CONNECT salesapp@orasales\n  Enter password: password\n\n  CONNECT salesapp@ourhost37:1527:DB17\n  Enter password: password\n\nIn these examples, salesapp is the user name, with the unique connection string for the database shown as specified in three different ways. You could use its URL sales_db.us.example.com, or its TNS alias, orasales, from the tnsnames.ora file, or its host:port:sid string.\n\nHowever, when clients are configured to use the secure external password store, applications can connect to a database with the following CONNECT statement syntax, without specifying database logon credentials:\n\n  CONNECT /@db_connect_string\n\n  CONNECT /@db_connect_string AS SYSDBA\n\n  CONNECT /@db_connect_string AS SYSOPER\n  \nIn this specification, db_connect_string is a valid connection string to access the intended database, such as the service name, URL, or alias as shown in the earlier examples. Each user account must have its own unique connection string; you cannot create one connection string for multiple users.\n\nIn this case, the database credentials, user name and password, are securely stored in an Oracle wallet created for this purpose. The autologin feature of this wallet is turned on, so the system does not need a password to open the wallet. From the wallet, it gets the credentials to access the database for the user they represent.","fixText":"Design DBMS application code and batch job code that is compiled, encoded or encrypted, to NOT contain passwords.\n\n\nOracle provides the capability to provide for a secure external password facility.  Use the Oracle mkstore to create a secure storage area for passwords for applications, batch jobs, and scripts to use or deploy a site-authorized facility to perform this function.\n\nCheck to see what has been stored in the Oracle External Password Store.\n\nTo view all contents of a client wallet external password store, check specific credentials by viewing them. Listing the external password store contents provides information you can use to decide whether to add or delete credentials from the store.  To list the contents of the external password store, enter the following command at the command line:\n\n  $ mkstore -wrl wallet_location -listCredential\n\n  For example:\n\n  $ mkstore -wrl c:\\oracle\\product\\11.2.0\\db_1\\wallets -listCredential\n\nThe wallet_location specifies the path to the directory where the wallet, whose external password store contents you want to view, is located. This command lists all of the credential database service names (aliases) and the corresponding user name (schema) for that database. Passwords are not listed.\n\nConfiguring Clients to use the External Password Store:\n\nIf your client is already configured to use external authentication, such as Windows native authentication or Transport Layer Security (TLS), then Oracle Database uses that authentication method. The same credentials used for this type of authentication are typically also used to log in to the database.\n\nFor clients not using such authentication methods or wanting to override them for database authentication, you can set the SQLNET.WALLET_OVERRIDE parameter in sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE, allowing standard use of authentication credentials as before.\n\nIf you want a client to use the secure external password store feature, then perform the following configuration task:\n\n1. Create a wallet on the client by using the following syntax at the command line:\n \n    mkstore -wrl wallet_location -create\n\n    For example:\n\n    mkstore -wrl c:\\oracle\\product\\11.2.0\\db_1\\wallets -create\n    Enter password: password\n\nThe wallet_location is the path to the directory where you want to create and store the wallet. This command creates an Oracle wallet with the autologin feature enabled at the location you specify. The autologin feature enables the client to access the wallet contents without supplying a password. \n \n The mkstore utility -create option uses password complexity verification.\n \n2. Create database connection credentials in the wallet by using the following syntax at the command line:\n\n    mkstore -wrl wallet_location -createCredential db_connect_string username\n    Enter password: password\n\n    For example:\n\n    mkstore -wrl c:\\oracle\\product\\11.2.0\\db_1\\wallets -createCredential oracle system\n    Enter password: password\n\n    In this specification:\n\nThe wallet_location is the path to the directory where you created the wallet.  The db_connect_string used in the CONNECT /@db_connect_string statement must be identical to the db_connect_string specified in the -createCredential command.\n \nThe db_connect_string is the TNS alias you use to specify the database in the tnsnames.ora file or any service name you use to identify the database on an Oracle network. By default, tnsnames.ora is located in the $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME\\network\\admin on Windows.\n \nThe username is the database logon credential. When prompted, enter the password for this user.\n \n3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set it to the directory location of the wallet you created in Step 1.  For example, if you created the wallet in $ORACLE_HOME/network/admin and your Oracle home is set to /private/ora11, then you need to enter the following into your client sqlnet.ora file:\n    \n    WALLET_LOCATION =\n           (SOURCE =\n             (METHOD = FILE)\n             (METHOD_DATA =\n           (DIRECTORY = /private/ora11/network/admin)\n           )\n          )\n \n4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter and set it to TRUE as follows:\n\n       SQLNET.WALLET_OVERRIDE = TRUE\n\nThis setting causes all CONNECT /@db_connect_string statements to use the information in the wallet at the specified location to authenticate to databases.\n\n       When external authentication is in use, an authenticated user with such a wallet can use the CONNECT /@db_connect_string syntax to access the previously specified databases without providing a user name and password. However, if a user fails that external authentication, then these connect statements also fail.\n \nBelow is a sample sqlnet.ora file with the WALLET_LOCATION and the SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4.\n\n        WALLET_LOCATION =\n            (SOURCE =\n              (METHOD = FILE)\n              (METHOD_DATA =\n            (DIRECTORY = /private/ora12/network/admin)\n              )\n             )\n\n        SQLNET.WALLET_OVERRIDE = TRUE\n        SSL_CLIENT_AUTHENTICATION = FALSE\n        SSL_VERSION = 1.2\n\n(Note: This assumes that a single sqlnet.ora file, in the default location, is in use. Please see the supplemental file \"Non-default sqlnet.ora configurations.pdf\" for how to find multiple and/or differently located sqlnet.ora files.)","ccis":["CCI-000366"]},{"vulnId":"V-238470","ruleId":"SV-238470r981946_rule","severity":"medium","ruleTitle":"The DBMS must enforce password maximum lifetime restrictions.","description":"Password maximum lifetime is the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it.\n\nPasswords need to be changed at specific policy-based intervals as per policy. Any password, no matter how complex, can eventually be cracked.\n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.\n\nThe PASSWORD_LIFE_TIME parameter defines the number of days a password remains valid. This can, but must not be, set to UNLIMITED. Further, the PASSWORD_GRACE_TIME parameter, if set to UNLIMITED, can nullify the PASSWORD_LIFE_TIME. PASSWORD_GRACE_TIME must be set to 0 days (or another small integer).\n\nNote 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. With respect to Oracle, this requirement applies to cases where it is necessary to have accounts directly managed by Oracle.","checkContent":"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.\n\nReview DBMS settings to determine if passwords must be changed periodically. If not, this is a finding:\n\nSELECT p1.profile,\nCASE p1.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\nCASE p2.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\nCASE p3.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\nCASE p4.limit WHEN 'UNLIMITED' THEN 'UNLIMITED' ELSE\nTO_CHAR(DECODE(p1.limit, 'DEFAULT', p3.limit, p1.limit) + DECODE(p2.limit, 'DEFAULT', p4.limit, p2.limit))\nEND\nEND\nEND\nEND effective_life_time\nFROM dba_profiles p1, dba_profiles p2, dba_profiles p3, dba_profiles p4\nWHERE p1.profile=p2.profile\nAND p3.profile='DEFAULT'\nAND p4.profile='DEFAULT'\nAND p1.resource_name='PASSWORD_LIFE_TIME'\nAND p2.resource_name='PASSWORD_GRACE_TIME'\nAND p3.resource_name='PASSWORD_LIFE_TIME' -- from DEFAULT profile\nAND p4.resource_name='PASSWORD_GRACE_TIME' -- from DEFAULT profile\norder by 1;\n\nIf the \"effective_life_time\" is greater than 60 for any profile applied to user accounts, and the need for this has not been documented and approved by the ISSO, this is a finding.\n\nIf the value is greater than 35 for any profile applied to user accounts, and the DBMS is configured to use Password Lifetime to disable inactive accounts (see requirement SRG-APP-000025-DB-000004), this is a finding.","fixText":"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:\nALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35 PASSWORD_GRACE_TIME 0;\nDo this for each profile applied to user accounts.\n\n(Note that 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, as required by SRG-APP-000025-DB-000004. But if 35 is not a practical or acceptable limit for password lifetime, set it to the standard DoD value of 60, and use another method to satisfy SRG-APP-000025-DB-000004.)\n\nWhere a password lifetime longer than 60 is needed, document the reasons and obtain ISSO approval.","ccis":["CCI-000192"]},{"vulnId":"V-238471","ruleId":"SV-238471r961863_rule","severity":"medium","ruleTitle":"The DBMS must employ cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications.","description":"Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n\nThe act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. \n\nWhen applications provide a remote management capability inherent to the application, the application needs to ensure the communication channels used to remotely access the system are adequately protected.  If the communication channel is not adequately protected authentication information, application data, and configuration information could be compromised.","checkContent":"Review DBMS configuration to determine if cryptographic mechanisms are being utilized to protect the integrity and confidentiality of non-local maintenance and diagnostic communications. If not, this is a finding.","fixText":"Configure DBMS to utilize cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications.","ccis":["CCI-000366"]},{"vulnId":"V-238472","ruleId":"SV-238472r961863_rule","severity":"medium","ruleTitle":"The DBMS must employ strong identification and authentication techniques when establishing non-local maintenance and diagnostic sessions.","description":"Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n\nThe act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. \n\nWhen applications provide a remote management capability inherent to the application, the application needs to ensure the identification and authentication techniques used to remotely access the system are strong enough to protect the system. If the communication channel is not adequately protected, authentication information, application data, and configuration information could be compromised.","checkContent":"Review DBMS settings to determine whether strong identification and authentication techniques are required for non-local maintenance and diagnostic sessions. If strong identification and authentication techniques are not required, this is a finding.","fixText":"Configure DBMS settings to use strong identification and authentication techniques for non-local maintenance and diagnostic sessions.","ccis":["CCI-000366"]},{"vulnId":"V-238473","ruleId":"SV-238473r961221_rule","severity":"medium","ruleTitle":"The DBMS must terminate the network connection associated with a communications session at the end of the session or after 15 minutes of inactivity.","description":"Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network.\n\nThe act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data.\n\nWhen applications provide a remote management capability inherent to the application, the application needs to ensure all sessions and network connections are terminated when non-local maintenance is completed.\n\nWhen network connections are left open after the database session has closed, the network session is open to session hijacking.\n\nThe Oracle Listener inherently meets most of this SRG requirement.  When a user logs off, or times out, or encounters an unrecoverable network fault, the Oracle Listener terminates all sessions and network connections.  The remaining aspect of the requirement, the timeout because of inactivity, is configurable.","checkContent":"Review DBMS settings, OS settings, and vendor documentation to verify network connections are terminated when a database communications session is ended or after a DoD-defined period of inactivity. If the network connection is not terminated, this is a finding.\n\nThe defined duration for these timeouts is 15 minutes, except to fulfill documented and validated mission requirements.","fixText":"Configure DBMS and/or OS settings to disconnect network sessions when database communication sessions have ended or after the DoD-defined period of inactivity.\n\nTo configure this in Oracle, modify each relevant profile.  The resource name is IDLE_TIME, which is expressed in minutes.  Using PPPPPP as an example of a profile, set the timeout to 15 minutes with:\nALTER PROFILE PPPPPP LIMIT IDLE_TIME 15;","ccis":["CCI-002361"]},{"vulnId":"V-238474","ruleId":"SV-238474r961050_rule","severity":"medium","ruleTitle":"The DBMS must implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.","description":"Use of cryptography to provide confidentiality and non-repudiation is not effective unless strong methods are employed. Many earlier encryption methods and modules have been broken and/or overtaken by increasing computing power. The NIST FIPS 140-2 cryptographic standards provide proven methods and strengths to employ cryptography effectively.\n\nDetailed information on the NIST Cryptographic Module Validation Program (CMVP) is available at http://csrc.nist.gov/groups/STM/cmvp/index.html.\n\nNote:  this does not require that all databases be encrypted.  It specifies that if encryption is required, then the implementation of the encryption must satisfy the prevailing standards.","checkContent":"If encryption is not required for the database, this is not a finding.\n\nIf the DBMS has not implemented federally required cryptographic protections for the level of classification of the data it contains, this is a finding.\n\nDetermine whether the Oracle DBMS software is at version 11.2.0.4 with the January 2014 CPU (or above).  If it is not, this is a finding.","fixText":"Implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nDeploy Oracle 11.2.0.4, with the January 2014 CPU patch, or a later version.  Configure cryptographic functions to use FIPS 140-2 compliant algorithms and hashing functions.\n\nThe strength requirements are dependent upon data classification.  \n\nFor unclassified data, where cryptography is required:\nAES 128 for encryption\nSHA 256 for hashing  \n\nNSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows:\nAES 128 for Secret\nAES 256 for Top Secret\nSHA 256 for Secret  \nSHA 384 for Top Secret\n\nNational Security System is defined as:\n(OMB Circular A-130) Any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications).\n\nThere is more information on this topic in the Oracle Database 11.2g Advanced Security Administrator's Guide, which may be found at  http://docs.oracle.com/cd/E11882_01/network.112/e40393.pdf.\n\nFIPS 140-2 can be downloaded from http://csrc.nist.gov/publications/PubsFIPS.html#140-2","ccis":["CCI-000803"]},{"vulnId":"V-238475","ruleId":"SV-238475r961863_rule","severity":"medium","ruleTitle":"Database data files containing sensitive information must be encrypted.","description":"Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. \n\nUse of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. \n\nData files that are not encrypted are vulnerable to theft. When data files are not encrypted they can be copied and opened on a separate system. The data can be compromised without the information owner's knowledge that the theft has even taken place.","checkContent":"Review the system documentation to determine whether the database handles classified information. If the database handles classified information, upgrade the severity Category Code to I.\n\nReview the system documentation to discover sensitive or classified data identified by the Information Owner that requires encryption. If no sensitive or classified data is identified as requiring encryption by the Information Owner, this is not a finding.\n\nHave the DBA use select statements in the database to review sensitive data stored in tables as identified in the system documentation.\n\nIf all sensitive data identified is encrypted within the database objects, encryption of the DBMS data files is optional and not a finding.\n\nIf all sensitive data is not encrypted within database objects, review encryption applied to the DBMS host data files. If no encryption is applied, this is a finding.","fixText":"Obtain and utilize native or third-party NIST-validated FIPS 140-2-compliant cryptography solution for the DBMS.  Configure cryptographic functions to use FIPS 140-2-compliant algorithms and hashing functions.\n\nDeploy Oracle 11.2.0.4 with the January 2014 CPU patch.\n\nThe strength requirements are dependent upon data classification.  \n\nFor unclassified data, where cryptography is required:\nAES 128 for encryption\nSHA 256 for hashing  \n\nNSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows.\nAES 128 for Secret\nAES 256 for Top Secret\nSHA 256 for Secret  \nSHA 384 for Top Secret\n\nNational Security System is defined as:\n(OMB Circular A-130) Any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications).\n\nThere is more information on this topic in the Oracle Database 11.2g Advanced Security Administrator's Guide, which may be found at  http://docs.oracle.com/cd/E11882_01/network.112/e40393.pdf\n\nFIPS 140-2 can be downloaded from http://csrc.nist.gov/publications/PubsFIPS.html#140-2","ccis":["CCI-000366"]},{"vulnId":"V-238476","ruleId":"SV-238476r961863_rule","severity":"medium","ruleTitle":"The DBMS must automatically terminate emergency accounts after an organization-defined time period for each type of account.","description":"Emergency application accounts are typically created due to an unforeseen operational event or could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support-related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left.\n\nIn the event emergency application accounts are required, the application must ensure accounts that are designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period.  Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or application data compromised.\n\nNote: 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.\n\nIf it is possible for any temporary emergency accounts to be created and managed by Oracle, then the DBMS or application must provide or utilize a mechanism to automatically terminate such accounts after an organization-defined time period.\n\nEmergency database accounts must be automatically terminated after an organization-defined time period in order to mitigate the risk of the account being misused.","checkContent":"If the organization has a policy, consistently enforced, forbidding the creation of emergency or temporary accounts, this is not a finding.\n\nCheck DBMS settings, OS settings, and/or enterprise-level authentication/access mechanisms settings to determine if emergency accounts are being automatically terminated by the system after an organization-defined time period. Check also for custom code (scheduled jobs, procedures, triggers, etc.) for achieving this.  If emergency accounts are not being terminated after an organization-defined time period, this is a finding.","fixText":"Create a profile specifically for emergency or temporary accounts.  When creating the accounts, assign them to this profile.  Configure DBMS, OS, and/or enterprise-level authentication/access mechanisms, or implement custom code, to terminate  accounts with this profile after an organization-defined time period.","ccis":["CCI-000366"]},{"vulnId":"V-238477","ruleId":"SV-238477r960735_rule","severity":"medium","ruleTitle":"The DBMS must protect against or limit the effects of the organization-defined types of Denial of Service (DoS) attacks.","description":"A variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices on an organization's internal network from being directly affected by DoS attacks.\n\nEmploying increased capacity and bandwidth combined with service redundancy may reduce the susceptibility to some DoS attacks.\n\nSome of the ways databases can limit their exposure to DoS attacks are through limiting the number of connections that can be opened by a single user and database clustering.","checkContent":"Review DBMS settings to verify the DBMS implements measures to limit the effects of the organization-defined types of Denial of Service (DoS) attacks. If measures have not been implemented, this is a finding.\n\nCheck the $ORACLE_HOME/network/admin/listener.ora to see if a Rate Limit has been established.  A rate limit is used to prevent denial of service (DOS) attacks on a database or to control a login storm such as may be caused by an application server reboot.\n- - - - -\nExample of a listener configuration with rate limiting in effect:\n\nCONNECTION_RATE_LISTENER=10\n\nLISTENER=\n  (ADDRESS_LIST=\n    (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes))\n    (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=yes))\n    (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526))\n  )\nLISTENER=\n  (ADDRESS_LIST=\n    (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=8))\n    (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=12))\n    (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526))\n  )","fixText":"Implement measures to limit the effects of organization-defined types of Denial of Service attacks.\n\nModify the $ORACLE_HOME/network/admin/listener.ora to establish a Rate Limit.","ccis":["CCI-000054"]},{"vulnId":"V-238478","ruleId":"SV-238478r960960_rule","severity":"medium","ruleTitle":"The DBMS must verify there have not been unauthorized changes to the DBMS software and information.","description":"Organizations are required to employ integrity verification applications on information systems to look for evidence of information tampering, errors, and omissions. The organization is also required to employ good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and cryptographic hashes), and to use tools to automatically monitor the integrity of the information system and the applications it hosts.\n\nThe DBMS opens data files and reads configuration files at system startup, system shutdown, and during abort recovery efforts. If the DBMS does not verify the trustworthiness of these files, it is vulnerable to malicious alterations of its configuration or unauthorized replacement of data.","checkContent":"Verify the DBMS system initialization and shutdowns are configured to ensure the DBMS system and data files remain in a secure state. If the DBMS does not support this, verify third-party software or custom scripting at the OS level performs this function.  If neither the DBMS, a third-party application, nor the OS is performing integrity verification of DBMS system files, this is a finding.","fixText":"Utilize a DBMS, OS, or third-party product to perform file verification of DBMS system file integrity at startup and shutdown.\n\n(Using Oracle Configuration Manager with Enterprise Manager, configured to perform this verification, is one possible way of satisfying this requirement.)","ccis":["CCI-001499"]},{"vulnId":"V-238479","ruleId":"SV-238479r961863_rule","severity":"medium","ruleTitle":"The DBMS must support taking organization-defined list of least disruptive actions to terminate suspicious events.","description":"System availability is a key tenet of system security. Organizations need to have the flexibility to be able to define the automated actions taken in response to an identified incident. This includes being able to define a least disruptive action the application takes to terminate suspicious events. A least disruptive action may include initiating a request for human response rather than blocking traffic or disrupting system operation.\n\nIn order to preserve availability, it is important for the DBMS to terminate suspicious events with the least disruptive action possible.  If suspicious events are not terminated, an attacker may gain entry into the system; however, if the system overreacts to a suspicious event and takes an overly disruptive action, a Denial of Service (DoS) may occur.","checkContent":"Obtain the CC/S/A/FA's list of suspicious event types and the actions to be taken in response, ordered from least disruptive to last resort.  If the list does not exist, this is a finding.\n\nFor each event type in the list, review the measures in place in the DBMS/database configuration that are designed to detect and/or counter the event.  (Alerting an administrator or operator to the problem is a valid measure.)  \n\nIf, for any event type defined in the list, no means of detecting the event exists, this is a finding.\n\nFor each event type where an automatic countermeasure is defined, verify that its implementation is congruent with the list of defined actions.  If not, this is a finding.\n\nVerify that administrators/operators are familiar with the list and the notification mechanism and are equipped to follow the instructions in the list.  If not, this is a finding.","fixText":"If the list does not exist, create it.\n\nFor any event type defined in the list where no means of detecting the event exists, either create the means of detection or modify the list.\n\nFor each event type where an automatic countermeasure is defined but its implementation differs from its description in the list, either modify the countermeasure or amend the list.\n\nIf any administrators/operators are unfamiliar with the list or the notification mechanism, train them.\n\nIf any administrators/operators are not equipped to follow the instructions in the list, provide them with the means to do so.\n\nEnsure the list is incorporated into, or referenced by, the System Security Plan.\n\nNote that Oracle Audit Vault and Oracle Database Vault are optional products that can be of considerable use in implementing active protection measures of this kind.","ccis":["CCI-000366"]},{"vulnId":"V-238480","ruleId":"SV-238480r960960_rule","severity":"medium","ruleTitle":"Use of the DBMS software installation account must be restricted.","description":"This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. \n\nTo limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined lists of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.\n\nUse of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts if used for non-administration application development or application maintenance can lead to miss-assignment of privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in and provided by applications.\n\nThe DBMS software installation account may require privileges not required for database administration or other functions. Use of accounts configured with excess privileges may result in the loss or compromise of data or system settings due to elevated privileges that bypass controls designed to protect them.","checkContent":"Review system documentation to identify the installation account.\n\nVerify whether the account is used for anything involving interactive activity beyond DBMS software installation, upgrade, and maintenance actions.\n\nIf the account is used for anything involving interactive activity beyond DBMS software installation, upgrade, and maintenance actions, this is a finding.","fixText":"Restrict interactive use of the DBMS software installation account to DBMS software installation, upgrade, and maintenance actions only.\n\nIf possible, disable the installation accounts when authorized actions are not being performed. Otherwise, disable the use of the account(s) for interactive activity.","ccis":["CCI-001499"]},{"vulnId":"V-238481","ruleId":"SV-238481r960960_rule","severity":"medium","ruleTitle":"The OS must limit privileges to change the DBMS software resident within software libraries (including privileged programs).","description":"When dealing with change control issues, it should be noted, any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system.\n\nIf the application were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nThis requirement is contingent upon the language in which the application is programmed, as many application architectures in use today incorporate their software libraries into, and make them inseparable from, their compiled distributions, rendering them static and version-dependent.  However, this requirement does apply to applications with software libraries accessible and configurable as in the case of interpreted languages.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nThe DBMS software libraries contain the executables used by the DBMS to operate. Unauthorized access to the libraries can result in malicious alteration. This may in turn jeopardize data stored in the DBMS and/or operation of the host system.","checkContent":"Review permissions that control access to the DBMS software libraries. The software library location may be determined from vendor documentation or service/process executable paths.\n\nDBA accounts, the DBMS process account, the DBMS software installation/maintenance account, SA accounts, if access by them is required for some operational level of support such as backups, and the host system itself require access. Any others should be scrutinized and a reason for access provided by the DBA. If accounts that are not required and authorized to have access to the software library location do have access, this is a finding.\n\nCheck to see which users have been granted DBA.  Work from a basis of least privilege.  Provide the least amount of privilege required to accomplish the job.\n\nSQL> select * from dba_role_privs where granted_role = 'DBA';","fixText":"Restrict access to the DBMS software libraries to accounts that require access based on job function.","ccis":["CCI-001499"]},{"vulnId":"V-265878","ruleId":"SV-265878r999540_rule","severity":"high","ruleTitle":"Oracle database products must be a version supported by the vendor.","description":"Unsupported commercial and database systems should not be used because fixes to newly identified bugs will not be implemented by the vendor. The lack of support can result in potential vulnerabilities. Systems at unsupported servicing levels or releases will not receive security updates for new vulnerabilities, which leaves them subject to exploitation.\n\nWhen maintenance updates and patches are no longer available, the database software is no longer considered supported and should be upgraded or decommissioned.","checkContent":"Review the version and release information.\nFrom SQL*Plus:\n\nSelect version from v$instance;\n\nOracle Database version 11.2 is no longer supported by the vendor. If the system is running Oracle Database version 11.2, this is a finding.","fixText":"Remove or decommission all unsupported software products.\n\nUpgrade unsupported DBMS or unsupported components to a supported version of the product.","ccis":["CCI-003376"]}]}