{"stig":{"title":"Oracle Database 12c Security Technical Implementation Guide","version":"2","release":"9"},"checks":[{"vulnId":"V-219824","ruleId":"SV-219824r879887_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\n select 'The number of replication objects defined is: '||\n count(*) from all_tables \n where 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\n select 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 ISSO or DBA if the replication account (the default is REPADMIN, but may be customized) is restricted to ISSO-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 ISSO.\n\nIf they are not, this is a finding.\n\nNote: Oracle Database Advanced Replication is deprecated in Oracle Database 12c. Use Oracle GoldenGate to replace all features of Advanced Replication, including multimaster replication, updatable materialized views, hierarchical materialized views, and deployment templates.","fixText":"Change the password for default and custom replication accounts and provide the password to ISSO-authorized users only.","ccis":["CCI-000366"]},{"vulnId":"V-219825","ruleId":"SV-219825r879887_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\n select instance_name from v$instance;\n select 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-219826","ruleId":"SV-219826r879887_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;\n\nIf no records are returned from the first SQL statement, this check is not a finding.\n\nConfirm the public and fixed user database links listed are documented in the System Security Plan, are authorized by the ISSO, 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\n drop database link [link name];\nOR\n drop 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-219827","ruleId":"SV-219827r879887_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\n select name from v$controlfile;\n\nDoD guidance recommends:\n\n2a. Each control file is to be located on separate, archived physical or virtual 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 the 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 the 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. 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 must 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\nConsult 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-219828","ruleId":"SV-219828r879887_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\n select 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\n select 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\n alter database add logfile group 2 \n ('diska:log2.log' ,\n '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\n alter database add logfile member 'diskc:log2.log'\n 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-219829","ruleId":"SV-219829r879887_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 must 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')\nand table_name not like 'SYS_PLSQL_%'\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.\n\nNote: Do not revoke the system-generated grants such as those found on The SYS_PLSQL_% objects. They are system generated object types (a.k.a ShadowTypes) which are created internally by Oracle when you use the Pipelined Table Functions. This can result in (incorrect) compilation failures and/or invalidations when the users who are supposed to have access to the shadow types find themselves without access.","ccis":["CCI-000366"]},{"vulnId":"V-219830","ruleId":"SV-219830r879887_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\n select 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\n alter 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-219831","ruleId":"SV-219831r903017_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\n select value from v$parameter where name = 'remote_os_roles';\n\nIf the value returned is FALSE, this is not a finding.\n\nIf the value returned is TRUE, confirm that the setting is justified and documented. If not, 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\n alter 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-219832","ruleId":"SV-219832r879887_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\n select 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\n alter 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-219833","ruleId":"SV-219833r879887_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 logons 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/database/121/ADMIN/dba.htm#ADMIN12478","ccis":["CCI-000366"]},{"vulnId":"V-219834","ruleId":"SV-219834r879887_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":"A default Oracle Database installation provides a set of predefined administrative accounts and non-administrative accounts. These are accounts that have special privileges required to administer areas of the database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE privileges on packages owned by the SYS schema. The default tablespace for administrative accounts is either SYSTEM or SYSAUX. Non-administrative user accounts only have the minimum privileges needed to perform their jobs. Their default tablespace is USERS.\n\nTo protect these accounts from unauthorized access, the installation process expires and locks most of these accounts, except where noted below. The database administrator is responsible for unlocking and resetting these accounts, as required.\n\nNon-Administrative Accounts - Expired and locked:\nAPEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\nAdministrative Accounts - Expired and Locked:\nANONYMOUS, CTXSYS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, ORACLE_OCM, ORDDATA, OWBSYS, ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, SPATIAL_CSW_ADMIN_USR, WK_TEST, WK_SYS, WKPROXY, WMSYS, XDB\n\nAdministrative Accounts - Open:\nDBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM, SYSKM\n\n* Subject to change based on version installed\n\nRun the SQL query:\n\nFrom SQL*Plus:\nselect grantee, privilege from dba_sys_privs \nwhere grantee not in ()\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\n revoke [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-219835","ruleId":"SV-219835r879887_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 should be 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 must never be granted to PUBLIC as this could allow users to compromise the database.","checkContent":"From SQL*Plus:\n\n select 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\n revoke [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-219836","ruleId":"SV-219836r879887_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 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":"A default Oracle Database installation provides a set of predefined administrative accounts and non-administrative accounts. These are accounts that have special privileges required to administer areas of the database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE privileges on packages owned by the SYS schema. The default tablespace for administrative accounts is either SYSTEM or SYSAUX. Non-administrative user accounts only have the minimum privileges needed to perform their jobs. Their default tablespace is USERS.\n\nTo protect these accounts from unauthorized access, the installation process expires and locks most of these accounts, except where noted below. The database administrator is responsible for unlocking and resetting these accounts, as required.\n\nNon-Administrative Accounts - Expired and locked:\nAPEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\nAdministrative Accounts - Expired and Locked:\nANONYMOUS, CTXSYS, EXFSYS, LBACSYS, MDSYS, OLAPSYS, ORACLE_OCM, ORDDATA, OWBSYS, ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, SPATIAL_CSW_ADMIN_USR, WK_TEST, WK_SYS, WKPROXY, WMSYS, XDB\n\nAdministrative Accounts - Open:\nDBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n* Subject to change based on version installed\n\nRun the SQL statement:\n\nselect grantee||': '||granted_role from dba_role_privs\nwhere grantee not in\n()\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\nSQL statements to remove the admin option from an unauthorized grantee:\n revoke from ;\n grant to ;\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-219837","ruleId":"SV-219837r879887_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 must 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 be revoked.","checkContent":"A default Oracle Database installation provides a set of predefined administrative accounts and non-administrative accounts. These are accounts that have special privileges required to administer areas of the database, such as the “CREATE ANY TABLE” or “ALTER SESSION” privilege, or “EXECUTE” privileges on packages owned by the SYS schema. The default tablespace for administrative accounts is either “SYSTEM” or “SYSAUX”. Non-administrative user accounts only have the minimum privileges needed to perform their jobs. Their default tablespace is “USERS”.\n\nTo protect these accounts from unauthorized access, the installation process expires and locks most of these accounts, except where noted below. The database administrator is responsible for unlocking and resetting these accounts, as required.\n\nNon-Administrative Accounts - Expired and locked:\nAPEX_PUBLIC_USER, DIP, FLOWS_040100*, FLOWS_FILES, MDDATA, SPATIAL_WFS_ADMIN_USR, XS$NULL\n\nAdministrative Accounts - Expired and Locked:\nANONYMOUS, CTXSYS, EXFSYS, LBACSYS, , GSMADMIN_INTERNAL, MDSYS, OLAPSYS, ORACLE_OCM, ORDDATA, OWBSYS, ORDPLUGINS, ORDSYS, OUTLN, SI_INFORMTN_SCHEMA, SPATIAL_CSW_ADMIN_USR, WK_TEST, WK_SYS, WKPROXY, WMSYS, XDB\n\nAdministrative Accounts - Open:\nDBSNMP, MGMT_VIEW, SYS, SYSMAN, SYSTEM\n\n* Subject to change based on version installed\n\nRun the SQL query:\n\nselect owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs\nwhere grantee = 'PUBLIC'\nand owner not in\n();\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 there are any records returned that are not Oracle product accounts, and 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-219838","ruleId":"SV-219838r879887_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, this check is 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:\n ps -ef | grep tnslsnr | grep -v grep\n\nThe alias for the listener follows tnslsnr in the command output.\n\nMust be logged on the host system using the account that owns the tnslsnr executable (UNIX). If the account is denied local logon, have the system SA assist in this task by adding 'su' to the listener account from the root account. On Windows platforms, log on using an account with administrator privileges to complete the check.\n\nFrom a system command prompt, execute the listener control utility:\n\n lsnrctl 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":"By default, Oracle Net Listener permits only local administration for security reasons. As a policy, the listener can be administered only by the user who started it. This is enforced through local operating system authentication. For example, if user1 starts the listener, then only user1 can administer it. Any other user trying to administer the listener gets an error. The super user is the only exception.\n\nRemote administration of the listener must 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.\n\nNote: In Oracle Database 12c Release 1 (12.1), the listener password feature is no longer supported. This does not cause a loss of security because authentication is enforced through local operating system authentication. Refer to Oracle Database Net Services Reference for additional information.","ccis":["CCI-000366"]},{"vulnId":"V-219839","ruleId":"SV-219839r879887_rule","severity":"medium","ruleTitle":"Application role permissions must not be assigned to the Oracle PUBLIC role.","description":"Permissions granted to PUBLIC are granted to all users of the database. Custom roles must 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\n select 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\n revoke [role name] from PUBLIC;","ccis":["CCI-000366"]},{"vulnId":"V-219840","ruleId":"SV-219840r879887_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, must 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\n select grantee, granted_role from dba_role_privs\n where default_role='YES'\n and granted_role in\n (select grantee from dba_sys_privs where upper(privilege) like '%USER%') \n and grantee not in\n ()\n and grantee not in (select distinct owner from dba_tables)\n and grantee not in\n (select distinct username from dba_users where upper(account_status) like\n '%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 ensures 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\n alter user [username] default role all except [role];\n\nIf the user has more than one application administration role assigned, then remove assigned roles from default assignment and assign individually the appropriate default roles.","ccis":["CCI-000366"]},{"vulnId":"V-219841","ruleId":"SV-219841r879887_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-219842","ruleId":"SV-219842r879887_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 must 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:\n select value from v$parameter where name = 'job_queue_processes';\n\nRun this query:\n select value from all_scheduler_global_attribute\n where ATTRIBUTE_NAME = 'MAX_JOB_SLAVE_PROCESSES';\n\nTo understand the relationship between these settings, review:\nhttps://docs.oracle.com/database/121/ADMIN/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:\n select 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-219843","ruleId":"SV-219843r879887_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 may be allowed. Only applications that have completed the configuration management process may be introduced by the application object owner account to the production system.","checkContent":"From SQL*Plus:\n select 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.\n\nNote: Oracle Database Advanced Replication is deprecated in Oracle Database 12c. Use Oracle GoldenGate to replace all features of Advanced Replication, including multimaster replication, updatable materialized views, hierarchical materialized views, and deployment templates.","ccis":["CCI-000366"]},{"vulnId":"V-219844","ruleId":"SV-219844r879887_rule","severity":"medium","ruleTitle":"Sensitive information from production database exports must be modified before import to 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-219847","ruleId":"SV-219847r879887_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', 'SYSKM', 'SYSDG', 'SYSBACKUP');\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 ;\nalter database default temporary tablespace ;\n\nalter user default tablespace temporary tablespace ;\n\nReplace with the named user account.\nReplace with the new default tablespace name.\nReplace with the new default temporary tablespace name (typically TEMP).\nRepeat the \"alter user\" for each affected user account.","ccis":["CCI-000366"]},{"vulnId":"V-219848","ruleId":"SV-219848r879887_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 must be stored separately from system and custom user-defined objects to facilitate administration and management of its data storage. The SYSTEM tablespace must 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()\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-219849","ruleId":"SV-219849r879887_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\n select log_mode from v$database;\n select value from v$parameter where name = 'log_archive_dest';\n select value from v$parameter where name = 'log_archive_duplex_dest';\n select name, value from v$parameter where name LIKE 'log_archive_dest_%';\n select value from v$parameter where name = 'db_recovery_file_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, and no value is returned for DB_RECOVERY_FILE_DEST, 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\n ls -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-219850","ruleId":"SV-219850r879887_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\n select 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\n shutdown immediate\n\nFrom SQL*Plus (create a pfile from spfile):\n\n create 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\n create spfile from pfile='[PATH]init[SID].ora';\n\nFrom SQL*Plus (start the database instance):\n\n startup\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-219851","ruleId":"SV-219851r879887_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 must 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 \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\n select 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 O121-C2-011000.\n\nAny other accounts listed are a finding.","fixText":"Disable any application object owner accounts.\n\nFrom SQL*Plus:\n alter user [username] account lock;\n\nEnable application object owner accounts only for installation and maintenance.\n\nDBAs 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-219852","ruleId":"SV-219852r879887_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 must 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 installation meets STIG guidance requirements at all levels or mitigate any conflicts in STIG guidance with the AO.","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. 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-219853","ruleId":"SV-219853r879887_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-219861","ruleId":"SV-219861r879887_rule","severity":"medium","ruleTitle":"The DBMS data files, transaction logs and audit files must be stored in dedicated directories or disk partitions separate from software or other application files.","description":"Protection of DBMS data, transaction and audit data files stored by the host operating system is dependent on OS controls. When different applications share the same database, resource contention and security controls are required to isolate and protect an application's data from other applications. In addition, it is an Oracle best practice to separate data, transaction logs, and audit logs into separate physical directories according to Oracle’s OFA (Optimal Flexible Architecture). And finally, DBMS software libraries and configuration files also require differing access control lists.","checkContent":"Review the disk/directory specification where database data, transaction log and audit files are stored.\n\nIf DBMS data, transaction log or audit data files are stored in the same directory, this is a finding.\n\nIf multiple applications are accessing the database and the database data files are stored in the same directory, this is a finding.\n\nIf multiple applications are accessing the database and database data is separated into separate physical directories according to application, this check is not a finding.","fixText":"Specify dedicated host system disk directories to store database data, transaction and audit files.\nExample directory structure:\n/*/app/oracle/oradata/db_name\n/*/app/oracle/admin/db_name/arch/*\n/*/app/oracle/oradata/db_name/audit\n/*/app/oracle/fast_recovery_area/db_name/\n\nSee Oracle Optimal Flexible Architecture:\nhttps://docs.oracle.com/database/121/LADBI/appendix_ofa.htm#LADBI7921\n\nWhen multiple applications are accessing a single database, configure DBMS default file storage according to application to use dedicated disk directories. \n\n/*/app/oracle/oradata/db_name/app_name\n\nSee Oracle Optimal Flexible Architecture:\nhttps://docs.oracle.com/database/121/LADBI/appendix_ofa.htm#LADBI7921","ccis":["CCI-000366"]},{"vulnId":"V-219862","ruleId":"SV-219862r879887_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":"If Standard Auditing is used:\n\nFrom 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]\n\nReplace [pathname] with the directory path listed from the above SQL command for audit_file_dest.\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\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 log. The location of the application event log is listed under Properties for the log under the Windows console. The default location is C:\\WINDOWS\\system32\\config\\EventLogs\\AppEvent.Evt.\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.\n\nIf Unified Auditing is used:\nAUDIT_FILE_DEST parameter is not used in Unified Auditing","fixText":"For file-based auditing, establish an audit file directory separate from the Oracle Home.\n\nAlter 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-219865","ruleId":"SV-219865r879887_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 on using the Oracle software owner account and enter the command:\n\n umask\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\n env | grep -i shell\n\nStartup files for each shell are as follows (located in users $HOME directory):\n\n C-Shell (CSH) = .cshrc\n Bourne Shell (SH) = .profile\n Korn Shell (KSH) = .kshrc\n TC Shell (TCS) = .tcshrc\n BASH Shell = .bash_profile or .bashrc\n\nEdit the shell startup file for the account and add or modify the line:\n\n umask 022\n\nLog off and logon, 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:\nRestrict access to the DBMS software libraries to the fewest accounts that clearly require access based on job function.\n\nDocument authorized access controls and justify any access grants that do not fall under DBA, DBMS process, ownership, or SA accounts.","ccis":["CCI-000366"]},{"vulnId":"V-219866","ruleId":"SV-219866r879887_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-219867","ruleId":"SV-219867r879887_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.\n\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_NAMES parameter is set:\n\nFrom SQL*PLUS:\n\nselect value from v$parameter where name = 'service_names';\n\nIf SERVICE_NAMES 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-219868","ruleId":"SV-219868r903020_rule","severity":"medium","ruleTitle":"Changes to configuration options must be audited.","description":"When standard auditing is in use, 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":"For Unified or mixed auditing, from SQL*Plus:\n\nselect count(*) from audit_unified_enabled_policies where entity_name = 'SYS';\n\nIf less than one row is returned, this is a finding.\n\nFor Standard auditing, from SQL*Plus:\n\n select value from v$parameter where name = 'audit_sys_operations';\n\nIf the value returned is FALSE, this is a finding.","fixText":"For Standard auditing, from SQL*Plus:\n\n alter 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.\n\nIf Unified Auditing is used:\nTo ensure auditable events are captured:\nLink the oracle binary with uniaud_on, and then restart the database. Oracle Database Upgrade Guide describes how to enable unified auditing.\n\nFor additional information on creating audit policies, refer to the Oracle Database Security Guide\nhttp://docs.oracle.com/database/121/DBSEG/audit_config.htm#CHDGBAAC","ccis":["CCI-000366"]},{"vulnId":"V-219871","ruleId":"SV-219871r879887_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 has been identified as being sensitive or classified in the system documentation, this is not a finding.\n\nIf security labeling is not required, this is not a finding.\n\nIf Standard Auditing is used, run the SQL query:\n\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.\n\nIf Unified Auditing is used:\nTo see if Oracle is configured to capture audit data including changes to security label assignment, enter the following SQL*Plus command:\nSELECT 'Changes to security label assignment is not being audited. ' \nFROM dual \nWHERE (SELECT Count(*)\n FROM (select policy_name , audit_option from audit_unified_policies\n WHERE audit_option = 'ALL'\n\t AND audit_option_type = 'OLS ACTION'\n AND policy_name in (select policy_name from audit_unified_enabled_policies where user_name='ALL USERS'))) = 0\n OR (SELECT value \n FROM v$option \n WHERE parameter = 'Unified Auditing') != 'TRUE'; \n\nIf Oracle returns \"no rows selected\", this is not a finding.\n\nTo confirm that Oracle audit is capturing sufficient information to establish that changes to classification labels are being audited, perform a successful auditable action and an auditable action that results in an SQL error, and then view the results in the SYS.UNIFIED_AUDIT_TRAIL view.\n\nIf no ACTION#, or the wrong value, is returned for the auditable actions, 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.\n\nIf using Standard Auditing:\nIf there is no Unified Auditing policy deployed to audit changes to security labels, the create one using the following syntax:\nSA_AUDIT_ADMIN.AUDIT (\n policy_name IN VARCHAR2,\n users IN VARCHAR2 DEFAULT NULL,\n audit_option IN VARCHAR2 DEFAULT NULL,\n audit_type IN VARCHAR2 DEFAULT NULL,\n success IN VARCHAR2 DEFAULT NULL);\n\nFor additional information on creating audit policies, refer to the Oracle Database Security Guide\nhttp://docs.oracle.com/database/121/OLSAG/packages.htm#i1011868\n\nIf Unified Auditing is used:\nTo ensure auditable events are captured:\nLink the oracle binary with uniaud_on, and then restart the database. Oracle Database Upgrade Guide describes how to enable unified auditing.\nReference V-61625 for information on how to configure a policy to audit changes to security label assignments.\n\nFor additional information on creating audit policies, refer to the Oracle Database Security Guide\nhttp://docs.oracle.com/database/121/DBSEG/audit_config.htm#CHDGBAAC","ccis":["CCI-000366"]},{"vulnId":"V-219872","ruleId":"SV-219872r879887_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\n select value from v$parameter where name = 'global_names';\n\nIf the value returned is FALSE, this is a finding.","fixText":"From SQL*Plus:\n\n alter 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-219873","ruleId":"SV-219873r879887_rule","severity":"medium","ruleTitle":"The /diag subdirectory under the directory assigned to the DIAGNOSTIC_DEST parameter must be protected from unauthorized access.","description":"/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 /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-219874","ruleId":"SV-219874r879887_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\n REMOTE_ADMIN = NO","ccis":["CCI-000366"]},{"vulnId":"V-219875","ruleId":"SV-219875r879887_rule","severity":"medium","ruleTitle":"Network client connections must be restricted to supported versions.","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":"Note: The SQLNET.ALLOWED_LOGON_VERSION parameter is deprecated in Oracle Database 12c. This parameter has been replaced with two new Oracle Net Services parameters:\n\nSQLNET.ALLOWED_LOGON_VERSION_SERVER\nSQLNET.ALLOWED_LOGON_VERSION_CLIENT\n\nView 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 entries:\n\nSQLNET.ALLOWED_LOGON_VERSION_SERVER = 12\nSQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12\n\nIf the parameters do not exist, this is a finding.\n\nIf the parameters are not set to a value of 12 or 12a, this is a finding.\n\nNote: Attempting to connect with a client version lower than specified in these parameters may result in a misleading error:\nORA-01017: invalid username/password: logon denied","fixText":"Edit the SQLNET.ORA file to add or edit the entries:\n\nSQLNET.ALLOWED_LOGON_VERSION_SERVER = 12\nSQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12\n\nSet the value to 12 or higher.\nValid values for SQLNET.ALLOWED_LOGON_VERSION_SERVER are: 12 and 12a\n\nValid values for SQLNET.ALLOWED_LOGON_VERSION_CLIENT are: 12 and 12a\n\nFor more information on sqlnet.ora parameters refer to the following document:\n\"Database Net Services Reference\"\nhttp://docs.oracle.com/database/121/NETRF/sqlnet.htm#NETRF006\n\nFor more information on configuring authentication refer to the following document:\n\"Oracle Database 12C Password Version Configuration Guidelines\"\nhttps://docs.oracle.com/database/121/DBSEG/authentication.htm#GUID-E6EE45DD-1E3B-4028-B8DE-65D6AA373821","ccis":["CCI-000366"]},{"vulnId":"V-220263","ruleId":"SV-220263r879613_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-220264","ruleId":"SV-220264r879511_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 site-specific 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 requirements. Assign users to the appropriate profile.\n\nThe user profile, ORA_STIG_PROFILE, has been provided (starting with Oracle 12.1.0.2) to satisfy the STIG requirements pertaining to the profile parameters. Oracle recommends that this profile be customized with any site-specific requirements and assigned to all users where applicable. Note: It remains necessary to create a customized replacement for the password validation function, ORA12C_STRONG_VERIFY_FUNCTION, if relying on this technique to verify password complexity.\n\nThe defaults for ORA_STIG_PROFILE are set as follows:\nResource Name Limit\n------------- ------\nCOMPOSITE_LIMIT DEFAULT\nSESSIONS_PER_USER DEFAULT\nCPU_PER_SESSION DEFAULT\nCPU_PER_CALL DEFAULT\nLOGICAL_READS_PER_SESSION DEFAULT\nLOGICAL_READS_PER_CALL DEFAULT\nIDLE_TIME 15\nCONNECT_TIME DEFAULT\nPRIVATE_SGA DEFAULT\nFAILED_LOGIN_ATTEMPTS 3 \nPASSWORD_LIFE_TIME 60\nPASSWORD_REUSE_TIME 365\nPASSWORD_REUSE_MAX 10\nPASSWORD_VERIFY_FUNCTION ORA12C_STRONG_VERIFY_FUNCTION\nPASSWORD_LOCK_TIME UNLIMITED\nPASSWORD_GRACE_TIME 5\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.\nALTER PROFILE ORA_STIG_PROFILE LIMIT SESSIONS_PER_USER ;\n\nTo assign the user to the profile do the following:\nALTER USER PROFILE ORA_STIG_PROFILE;","ccis":["CCI-000054"]},{"vulnId":"V-220265","ruleId":"SV-220265r879522_rule","severity":"high","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 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\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 is the site-defined definition of an acceptably small level of manual account-management activity. 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, etc.) 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.) The following are 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-220266","ruleId":"SV-220266r917644_rule","severity":"high","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\nSQL> SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault';\n\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:\nselect * from dba_role_privs where granted_role = ''\n\nList all roles given to a user:\nselect * from dba_role_privs where grantee = '';\n\nList all roles for all users:\n column grantee format a32\n column granted_role format a32\n break on grantee\n select grantee, granted_role from dba_role_privs;\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('')\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\nList which tables a certain role gives SELECT access to using the query:\nselect * from role_tab_privs where role='' and privilege = 'SELECT';\n\nList all tables a user can SELECT from using the query:\nselect * from dba_tab_privs where GRANTEE ='' 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 = ''\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 = '';","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.\n\nDo not assign privileges directly to users, except for those that Oracle does not permit to be assigned via roles.\n\nFor more information on the configuration of Database Vault, refer to the Database Vault Administrator's Guide:\nhttps://docs.oracle.com/database/121/DVADM/toc.htm","ccis":["CCI-000213"]},{"vulnId":"V-220267","ruleId":"SV-220267r879559_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 - marked here with an asterisk - cannot, and may require OS settings.\n- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g. classification levels).\n- Successful and unsuccessful logon attempts, privileged activities or other system level access\n- Starting and ending time for user access to the system, concurrent logons from different workstations.\n- Successful and unsuccessful accesses to objects.\n- All program initiations.\n- *All direct access to the information system.\n- All account creations, modifications, disabling, and terminations.\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\nIf Standard Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus 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.\n\nIf Unified Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\nSELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\nIf Oracle returns a value something other than \"TRUE\", this is a finding.\n\nTo confirm that Oracle audit is capturing information on the required events, review the contents of the SYS.UNIFIED_AUDIT_TRAIL view. 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\nIf Standard Auditing is used:\nUse this process to ensure auditable events are captured:\nALTER SYSTEM SET AUDIT_TRAIL= 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 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 below.\n\nIf Unified Auditing is used:\nUse this process to ensure auditable events are captured:\nLink the oracle binary with uniaud_on, and then restart the database. Oracle Database Upgrade Guide describes how to enable unified auditing.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide: \nhttp://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\nOracle Database Upgrade Guide:\nhttp://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\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.","ccis":["CCI-000169"]},{"vulnId":"V-220268","ruleId":"SV-220268r879560_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:\nIn 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\nTo audit objects in another schema, the user must have the AUDIT ANY system privilege.\nTo audit system privileges, the user must have the AUDIT SYSTEM privilege.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide:\nhttp://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241","ccis":["CCI-000171"]},{"vulnId":"V-220269","ruleId":"SV-220269r879561_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 - marked here with an asterisk - cannot, and may require OS settings.\n- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g. classification levels).\n- Successful and unsuccessful logon attempts, privileged activities or other system level access\n- Starting and ending time for user access to the system, concurrent logons from different workstations.\n- Successful and unsuccessful accesses to objects.\n- All program initiations.\n- *All direct access to the information system.\n- All account creations, modifications, disabling, and terminations.\n- *All kernel module loads, unloads, and restarts.","checkContent":"Check DBMS settings to determine if auditing is being performed on the events on the DoD-selected list of auditable events that lie within the scope of Oracle audit capabilities:\n- Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels).\n- Successful and unsuccessful logon attempts, privileged activities or other system-level access\n- Starting and ending time for user access to the system, concurrent logons from different workstations.\n- Successful and unsuccessful accesses to objects.\n- All program initiations.\n- All account creations, modifications, disabling, and terminations.\n\nIf auditing is not being performed for any of these events, this is a finding.\n\nNotes on Oracle audit capabilities follow.\n\nUnified Audit supports named audit policies, which are defined using the CREATE AUDIT POLICY statement. A policy specifies the actions that should be audited and the objects to which it should apply. If no specific objects are included in the policy definition, it applies to all objects.\n\nA named policy is enabled using the AUDIT POLICY statement. It can be enabled for all users, for specific users only, or for all except a specified list of users. The policy can audit successful actions, unsuccessful actions, or both.\n\nVerifying existing audit policy: existing Unified Audit policies are listed in the view AUDIT_UNIFIED_POLICIES. The AUDIT_OPTION column contains one of the actions specified in a CREATE AUDIT POLICY statement. The AUDIT_OPTION_TYPE column contains 'STANDARD ACTION' for a policy that applies to all objects or 'OBJECT ACTION' for a policy that audits actions on a specific object.\n\nselect POLICY_NAME from SYS.AUDIT_UNIFIED_POLICIES where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='STANDARD ACTION';\n\nTo find policies that audit privilege grants on specific objects:\n\nselect POLICY_NAME,OBJECT_SCHEMA,OBJECT_NAME from SYS.AUDIT_UNIFIED_POLICIES where AUDIT_OPTION='GRANT' and AUDIT_OPTION_TYPE='OBJECT ACTION';\n\nThe view AUDIT_UNIFIED_ENABLED_POLICIES shows which Unified Audit policies are enabled. The ENABLED_OPT and USER_NAME columns show the users for whom the policy is enabled or 'ALL USERS'. The SUCCESS and FAILURE columns indicate if the policy is enabled for successful or unsuccessful actions, respectively.\n\nselect POLICY_NAME,ENABLED_OPT,USER_NAME,SUCCESS,FAILURE from SYS.AUDIT_UNIFIED_ENABLED_POLICIES where POLICY_NAME='POLICY1';","fixText":"Configure the DBMS's auditing settings to include auditing of events on the DoD-selected list of auditable events.\n\n1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels)\n\nTo audit granting and revocation of any privilege:\ncreate audit policy policy1 actions grant;\ncreate audit policy policy2 actions revoke;\n\nTo audit grants of object privileges on a specific object:\ncreate audit policy policy3 actions grant on .;\n\nIf Oracle Label Security is enabled, this will audit all OLS administrative actions:\ncreate audit policy policy4 actions component = OLS all;\n\n2) Successful and unsuccessful logon attempts, privileged activities or other system-level access\n \nTo audit all user logon attempts:\ncreate audit policy policy5 actions logon;\n\nTo audit only logon attempts using administrative privileges (e.g. AS SYSDBA):\naudit policy policy5 by SYS, SYSOPER, SYSBACKUP, SYSDG, SYSKM;\n\n3) Starting and ending time for user access to the system, concurrent logons from different workstations\n\nThis policy will audit all logon and logoff events. An individual session is identified in the UNIFIED_AUDIT_TRAIL by the tuple (DBID, INSTANCE_ID, SESSIONID) and the start and end time will be indicated by the EVENT_TIMESTAMP of the logon and logoff events:\ncreate audit policy policy6 actions logon, logoff;\n\n4) Successful and unsuccessful accesses to objects\n\nTo audit all accesses to a specific table:\ncreate audit policy policy7 actions select, insert, delete, alter on .; \n\nDifferent actions are defined for other object types. To audit all supported actions on a specific object:\ncreate audit policy policy8 actions all on .;\n\n5) All program initiations\n\nTo audit execution of any PL/SQL program unit:\ncreate audit policy policy9 actions EXECUTE;\n\nTo audit execution of a specific function, procedure, or package:\ncreate audit policy policy10 actions EXECUTE on .;\n\n6) All direct access to the information system\n\n[Not applicable to Database audit. Monitor using OS auditing.]\n\n7) All account creations, modifications, disabling, and terminations\n\nTo audit all user administration actions:\ncreate audit policy policy11 actions create user, alter user, drop user, change password;\n\n8) All kernel module loads, unloads, and restarts\n\n[Not applicable to Database audit. Monitor using OS auditing.]\n\n9) All database parameter changes\n\nTo audit any database parameter changes, dynamic or static:\ncreate audit policy policy12 actions alter database, alter system, create spfile;\n\nApplying the Policy\n\nThe following command will enable the policy in all database sessions and audit both successful and unsuccessful actions:\naudit policy policy1;\n\nTo audit only unsuccessful actions, add the WHENEVER NOT SUCCESSFUL modifier:\naudit policy policy1 whenever not successful;\n\nEither command above can be limited to only database sessions started by a specific user as follows:\naudit policy policy1 by ;\naudit policy policy1 by whenever not successful;","ccis":["CCI-000172"]},{"vulnId":"V-220270","ruleId":"SV-220270r879563_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 is 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\nIf Standard Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSHOW PARAMETER AUDIT_TRAIL\n\nor the following SQL query:\n\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\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.\n\nIf no ACTION#, or the wrong value, is returned for the auditable actions just performed, this is a finding.\n\nIf Unified Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\nIf Oracle returns a value something other than \"TRUE\", 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.UNIFIED_AUDIT_TRAIL view.\n\nIf no ACTION_NAME, 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\nIf Standard Auditing is used:\nUse this process to ensure auditable events are captured:\n\nALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\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 Unified Auditing is used:\nTo ensure auditable events are captured:\nLink the oracle binary with uniaud_on, and then restart the database. \nOracle Database Upgrade Guide describes how to enable unified auditing.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide: \nhttp://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\nOracle Database Upgrade Guide:\nhttp://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810","ccis":["CCI-000130"]},{"vulnId":"V-220271","ruleId":"SV-220271r879564_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's 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\nIf Standard Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSHOW PARAMETER AUDIT_TRAIL\n\nor the following SQL query:\n\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\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.UNIFIED_AUDIT_TRAIL view.\n\nIf no timestamp, or the wrong value, is returned for the auditable actions just performed, this is a finding.\n\nIf Unified Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\nIf Oracle returns a value something other than \"TRUE\", 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.\n\nIf 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\nTo ensure auditable events are captured:\nLink the oracle binary with uniaud_on, and then restart the database.\nOracle Database Upgrade Guide describes how to enable unified auditing.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide:\nhttp://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\nOracle Database Upgrade Guide:\nhttp://docs.oracle.com/database/121/UPGRD","ccis":["CCI-000131"]},{"vulnId":"V-220272","ruleId":"SV-220272r879565_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\nIf Standard Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSHOW PARAMETER AUDIT_TRAIL\n\nor the following SQL query:\n\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\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.\n\nIf no DB ID or Object Creator (standard audit) or Object Schema (unified audit) or Object Name, or the wrong values, are returned for the auditable actions just performed, this is a finding.\n\nIf no DB ID or OBJ$CREATOR or the wrong values, are returned for the auditable actions just performed, this is a finding.\n\nIf correct values for USERHOST and TERMINAL are not returned when applicable, this is a finding.\n\nIf Unified Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\nIf Oracle returns a value something other than \"TRUE\", 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.UNIFIED_AUDIT_TRAIL view.\n\nIf no DBID or OBJECT_SCHEMA or OBJECT_NAME, or the wrong values, are returned for the auditable actions just performed, this is a finding.\n\nIf correct values for USERHOST and TERMINAL are not returned when applicable, this is a finding.\n\nFor Unified Auditing, the following view can be useful for reviewing its output:\n\nCREATE OR REPLACE FORCE VIEW SYS.UNIFIED_AUDIT_TRAIL\n(\nAUDIT_TYPE,\nSESSIONID,\nPROXY_SESSIONID,\nOS_USERNAME,\nUSERHOST,\nTERMINAL,\nINSTANCE_ID,\nDBID,\nAUTHENTICATION_TYPE,\nDBUSERNAME,\nDBPROXY_USERNAME,\nEXTERNAL_USERID,\nGLOBAL_USERID,\nCLIENT_PROGRAM_NAME,\nDBLINK_INFO,\nXS_USER_NAME,\nXS_SESSIONID,\nENTRY_ID,\nSTATEMENT_ID,\nEVENT_TIMESTAMP,\nACTION_NAME,\nRETURN_CODE,\nOS_PROCESS,\nTRANSACTION_ID,\nSCN,\nEXECUTION_ID,\nOBJECT_SCHEMA,\nOBJECT_NAME,\nSQL_TEXT,\nSQL_BINDS,\nAPPLICATION_CONTEXTS,\nCLIENT_IDENTIFIER,\nNEW_SCHEMA,\nNEW_NAME,\nOBJECT_EDITION,\nSYSTEM_PRIVILEGE_USED,\nSYSTEM_PRIVILEGE,\nAUDIT_OPTION,\nOBJECT_PRIVILEGES,\nROLE,\nTARGET_USER,\nEXCLUDED_USER,\nEXCLUDED_SCHEMA,\nEXCLUDED_OBJECT,\nADDITIONAL_INFO,\nUNIFIED_AUDIT_POLICIES,\nFGA_POLICY_NAME,\nXS_INACTIVITY_TIMEOUT,\nXS_ENTITY_TYPE,\nXS_TARGET_PRINCIPAL_NAME,\nXS_PROXY_USER_NAME,\nXS_DATASEC_POLICY_NAME,\nXS_SCHEMA_NAME,\nXS_CALLBACK_EVENT_TYPE,\nXS_PACKAGE_NAME,\nXS_PROCEDURE_NAME,\nXS_ENABLED_ROLE,\nXS_COOKIE,\nXS_NS_NAME,\nXS_NS_ATTRIBUTE,\nXS_NS_ATTRIBUTE_OLD_VAL,\nXS_NS_ATTRIBUTE_NEW_VAL,\nDV_ACTION_CODE,\nDV_ACTION_NAME,\nDV_EXTENDED_ACTION_CODE,\nDV_GRANTEE,\nDV_RETURN_CODE,\nDV_ACTION_OBJECT_NAME,\nDV_RULE_SET_NAME,\nDV_COMMENT,\nDV_FACTOR_CONTEXT,\nDV_OBJECT_STATUS,\nOLS_POLICY_NAME,\nOLS_GRANTEE,\nOLS_MAX_READ_LABEL,\nOLS_MAX_WRITE_LABEL,\nOLS_MIN_WRITE_LABEL,\nOLS_PRIVILEGES_GRANTED,\nOLS_PROGRAM_UNIT_NAME,\nOLS_PRIVILEGES_USED,\nOLS_STRING_LABEL,\nOLS_LABEL_COMPONENT_TYPE,\nOLS_LABEL_COMPONENT_NAME,\nOLS_PARENT_GROUP_NAME,\nOLS_OLD_VALUE,\nOLS_NEW_VALUE,\nRMAN_SESSION_RECID,\nRMAN_SESSION_STAMP,\nRMAN_OPERATION,\nRMAN_OBJECT_TYPE,\nRMAN_DEVICE_TYPE,\nDP_TEXT_PARAMETERS1,\nDP_BOOLEAN_PARAMETERS1,\nDIRECT_PATH_NUM_COLUMNS_LOADED\n)\nAS\nSELECT act.component,\nsessionid,\nproxy_sessionid,\nos_user,\nhost_name,\nterminal,\ninstance_id,\ndbid,\nauthentication_type,\nuserid,\nproxy_userid,\nexternal_userid,\nglobal_userid,\nclient_program_name,\ndblink_info,\nxs_user_name,\nxs_sessionid,\nentry_id,\nstatement_id,\nCAST (event_timestamp AS TIMESTAMP WITH LOCAL TIME ZONE),\nact.name,\nreturn_code,\nos_process,\ntransaction_id,\nscn,\nexecution_id,\nobj_owner,\nobj_name,\nsql_text,\nsql_binds,\napplication_contexts,\nclient_identifier,\nnew_owner,\nnew_name,\nobject_edition,\nsystem_privilege_used,\nspx.name,\naom.name,\nobject_privileges,\nrole,\ntarget_user,\nexcluded_user,\nexcluded_schema,\nexcluded_object,\nadditional_info,\nunified_audit_policies,\nfga_policy_name,\nxs_inactivity_timeout,\nxs_entity_type,\nxs_target_principal_name,\nxs_proxy_user_name,\nxs_datasec_policy_name,\nxs_schema_name,\nxs_callback_event_type,\nxs_package_name,\nxs_procedure_name,\nxs_enabled_role,\nxs_cookie,\nxs_ns_name,\nxs_ns_attribute,\nxs_ns_attribute_old_val,\nxs_ns_attribute_new_val,\ndv_action_code,\ndv_action_name,\ndv_extended_action_code,\ndv_grantee,\ndv_return_code,\ndv_action_object_name,\ndv_rule_set_name,\ndv_comment,\ndv_factor_context,\ndv_object_status,\nols_policy_name,\nols_grantee,\nols_max_read_label,\nols_max_write_label,\nols_min_write_label,\nols_privileges_granted,\nols_program_unit_name,\nols_privileges_used,\nols_string_label,\nols_label_component_type,\nols_label_component_name,\nols_parent_group_name,\nols_old_value,\nols_new_value,\nrman_session_recid,\nrman_session_stamp,\nrman_operation,\nrman_object_type,\nrman_device_type,\ndp_text_parameters1,\ndp_boolean_parameters1,\ndirect_path_num_columns_loaded\nFROM gv$unified_audit_trail uview,\nall_unified_audit_actions act,\nsystem_privilege_map spx,\nstmt_audit_option_map aom\nWHERE uview.action = act.action(+)\nAND -uview.system_privilege = spx.privilege(+)\nAND uview.audit_option = aom.option#(+)\nAND uview.audit_type = act.TYPE;","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\nIf Standard Auditing is used:\nUse this process to ensure auditable events are captured:\n\nALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\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 Unified Auditing is used:\nTo ensure auditable events are captured:\nLink the oracle binary with uniaud_on, and then restart the database. \n Oracle Database Upgrade Guide describes how to enable unified auditing.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide:\nhttp://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\nOracle Database Upgrade Guide:\nhttp://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810","ccis":["CCI-000132"]},{"vulnId":"V-220273","ruleId":"SV-220273r879566_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\nIf Standard Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSHOW PARAMETER AUDIT_TRAIL\n\nor the following SQL query:\n\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\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.\n\nIf correct values for User ID, User Host, and Terminal are not returned when applicable, this is a finding.\n\nIf Unified Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\nIf Oracle returns a value something other than \"TRUE\", 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.UNIFIED_AUDIT_TRAIL view.\n\nIf correct values for DBUSERNAME, USERHOST, 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\nIf Standard Auditing is used:\nUse this process to ensure auditable events are captured:\n\nALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\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 Unified Auditing is used:\nTo ensure auditable events are captured:\nLink the oracle binary with uniaud_on, and then restart the database. \nOracle Database Upgrade Guide describes how to enable unified auditing.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide:\nhttp://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\nOracle Database Upgrade Guide:\nhttp://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810","ccis":["CCI-000133"]},{"vulnId":"V-220274","ruleId":"SV-220274r879567_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\nIf Standard Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSHOW PARAMETER AUDIT_TRAIL\n\nor the following SQL query:\n\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\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.\n\nIf no return code or other outcome information is returned for the auditable action just performed, this is a finding.\n\nIf error is indicated for the successful action, this is a finding. If no error is indicated for the unsuccessful action, this is a finding.\n\nIf Unified Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\nIf Oracle returns a value something other than \"TRUE\", 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.UNIFIED_AUDIT_TRAIL view.\n\nIf no return code or other outcome information is returned for the auditable action just performed, this is a finding.\n\nIf error is indicated for the successful action, this is a finding.\n\nIf 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\nIf Standard Auditing is used:\nUse this process to ensure auditable events are captured:\n\nALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\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 unified Auditing is used:\nTo ensure auditable events are captured:\nLink the oracle binary with uniaud_on, and then restart the database. \nOracle Database Upgrade Guide describes how to enable unified auditing.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide: \nhttp://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\nOracle Database Upgrade Guide:\nhttp://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810","ccis":["CCI-000134"]},{"vulnId":"V-220275","ruleId":"SV-220275r879568_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\nIf Standard Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSHOW PARAMETER AUDIT_TRAIL\n\nor the following SQL query:\n\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\nIf Oracle returns a value something other than \"TRUE\", 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.\n\nIf no user ID, or the wrong value, is returned for the auditable actions just performed, this is a finding.\n\nIf Unified Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\nIf Oracle returns the value \"TRUE\", this is not 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.UNIFIED_AUDIT_TRAIL view, whichever is in use.\n\nIf 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\nIf Standard Auditing is used:\nUse this process to ensure auditable events are captured:\n\nALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\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 unified Auditing is used:\nTo ensure auditable events are captured:\nLink the oracle binary with uniaud_on, and then restart the database. \nOracle Database Upgrade Guide describes how to enable unified auditing.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide:\nhttp://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\nOracle Database Upgrade Guide:\nhttp://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810\nhttp://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810","ccis":["CCI-001487"]},{"vulnId":"V-220276","ruleId":"SV-220276r879569_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 shared 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\nIf Standard Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSHOW PARAMETER AUDIT_TRAIL\n\nor the following SQL query:\n\nSELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail';\n\nIf Oracle returns a value something other than \"TRUE\", this is a finding\n\nCompare the organization-defined auditable events with the Oracle documentation to determine whether standard auditing covers all the requirements.\n\nIf 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:\n\nSELECT * FROM SYS.DBA_FGA_AUDIT_TRAIL;\n\nIf any such auditable event is not covered by the existing FGA specifications, this is a finding.\n\nIf Unified Auditing is used:\nTo see if Oracle is configured to capture audit data, enter the following SQL*Plus command:\n\nSELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\nIf Oracle returns the value \"TRUE\", this is not a finding.\n\nCompare the organization-defined auditable events with the Oracle documentation to determine whether standard auditing covers all the requirements.\n\nIf it does, this is not a finding.\n\nCompare those organization-defined auditable events that are not covered by unified auditing with the existing Fine-Grained Auditing (FGA) specifications returned by the following query:\n\nSELECT * FROM SYS.UNIFIED_AUDIT_TRAIL WHERE AUDIT_TYPE = 'FineGrainedAudit';\n\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\nIf Standard Auditing is used:\nUse this process to ensure auditable events are captured:\n\nALTER SYSTEM SET AUDIT_TRAIL= SCOPE=SPFILE;\n\nAudit trail type can be \"OS\", \"DB\", \"DB,EXTENDED\", \"XML\" or \"XML,EXTENDED\".\n\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 below.\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 location below.\n\nIf Unified Auditing is used:\nUse this process to ensure auditable events are captured:\n\nSELECT * FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';\n\nIf Oracle returns the value \"TRUE\", this is not a finding.\n\nOtherwise,\nLink the oracle binary with uniaud_on, and then restart the database. Oracle Database Upgrade Guide describes how to enable unified auditing.\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 below.\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 location below.\n\nFor more information on the configuration of auditing, refer to the following documents:\n\"Auditing Database Activity\" in the Oracle Database 2 Day + Security Guide:\nhttp://docs.oracle.com/database/121/TDPSG/tdpsg_auditing.htm#TDPSG50000\n\"Monitoring Database Activity with Auditing\" in the Oracle Database Security Guide:\nhttp://docs.oracle.com/database/121/DBSEG/part_6.htm#CCHEHCGI\n\"DBMS_AUDIT_MGMT\" in the Oracle Database PL/SQL Packages and Types Reference:\nhttp://docs.oracle.com/database/121/ARPLS/d_audit_mgmt.htm#ARPLS241\nOracle Database Upgrade Guide:\nhttp://docs.oracle.com/database/121/UPGRD/afterup.htm#UPGRD52810","ccis":["CCI-000135"]},{"vulnId":"V-220277","ruleId":"SV-220277r879576_rule","severity":"medium","ruleTitle":"The system 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.\n\nIf appropriate controls and permissions do not exist, this is a finding.\n\n- - - - -\nIf Standard Auditing is used:\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)\nCOMMON VARCHAR2(3)\nTYPE VARCHAR2(24)\n\nsqlplus connect as sysdba;\n\nSQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\nIf Unified Auditing is used:\nDBA_TAB_PRIVS describes all object grants in the database. Check to see who has permissions on the AUDSYS tables.\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)\nCOMMON VARCHAR2(3)\nTYPE VARCHAR2(24)\n\nsqlplus connect as sysdba;\n\nSQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';","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.","ccis":["CCI-000162"]},{"vulnId":"V-220278","ruleId":"SV-220278r879577_rule","severity":"medium","ruleTitle":"The system 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.\n\nIf appropriate controls and permissions do not exist, this is a finding.\n\n- - - - -\nIf Standard Auditing is used:\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\n VARCHAR2(30) NOT NULL Owner of the object\nTABLE_NA 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)\nCOMMON VARCHAR2(3)\nTYPE VARCHAR2(24)\n\nsqlplus connect as sysdba;\n\nSQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\nIf Unified Auditing is used:\nDBA_TAB_PRIVS describes all object grants in the database. Check to see who has permissions on the AUDSYS tables. \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)\nCOMMON VARCHAR2(3)\nTYPE VARCHAR2(24)\n\nsqlplus connect as sysdba;\n\nSQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';","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\n- - - - -\nIf Standard Auditing is used:\nRevoke access to the AUD$ table to anyone who should not have access to it.\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 wanting to revoke that access, use the following command. The syntax that would be used for the REVOKE statement for tables is as follows:\n\nREVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees\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. 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\nCan 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: 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 is revoked, the object is automatically dropped. Derby does not try to determine if there are 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\nAll 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\nWhen 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\nWhen 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\nOnly 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\nWhen 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\nWhen 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\nIf Unified Auditing is used:\n\nApply the same process used in standard auditing to the tables with AUDSYS as the owner.","ccis":["CCI-000163"]},{"vulnId":"V-220279","ruleId":"SV-220279r879578_rule","severity":"medium","ruleTitle":"The system 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.\n\nIf appropriate controls and permissions do not exist, this is a finding.\n\n- - - - -\nIf Standard Auditing is used:\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.\n\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)\nCOMMON VARCHAR2(3)\nTYPE VARCHAR2(24)\n\nsqlplus connect as sysdba;\n\nSQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where table_name = 'AUD$';\n\nIf Unified Auditing is used:\nDBA_TAB_PRIVS describes all object grants in the database. Check to see who has permissions on the AUDSYS tables.\n\nRelated View\n\nDBA_TAB_PRIVS describes the object grants for which the current user is the object owner, grantor, or grantee.\n\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)\nCOMMON VARCHAR2(3)\nTYPE VARCHAR2(24)\n\nsqlplus connect as sysdba;\n\nSQL> SELECT GRANTEE, TABLE_NAME, PRIVILEGE\n FROM DBA_TAB_PRIVS where owner='AUDSYS';","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\n- - - - -\nIf Standard Auditing is used:\nRevoke access to the AUD$ table to anyone who should not have access to it.\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 wanting to revoke that access, use the following command. The syntax that would be used for the REVOKE statement for tables is as follows:\n\nREVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees\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. 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\nCan 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: 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 is revoked, the object is automatically dropped. Derby does not try to determine if there are 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\nAll 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\nWhen 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\nWhen 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\nOnly 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\nWhen 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\nWhen 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\nIf Unified Auditing is used:\n\nApply the same process used in standard auditing to the tables with AUDSYS as the owner.","ccis":["CCI-000164"]},{"vulnId":"V-220280","ruleId":"SV-220280r879579_rule","severity":"medium","ruleTitle":"The system 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.\n\nIf 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-220281","ruleId":"SV-220281r879580_rule","severity":"medium","ruleTitle":"The system 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.\n\nIf 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-220282","ruleId":"SV-220282r879581_rule","severity":"medium","ruleTitle":"The system 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.\n\nIf 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-220283","ruleId":"SV-220283r879586_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-220284","ruleId":"SV-220284r879587_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.\n\nConnect to Oracle as SYSDBA; run the following SQL to check for presence of Oracle Default Sample Schema User Accounts:\nselect distinct(username) from dba_users where username in\n('BI','HR','OE','PM','IX','SH','SCOTT');\n\nIf any of the users listed above is returned it means that there are demo programs installed, so this is a finding.","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-220285","ruleId":"SV-220285r879587_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','XDB')\nAND status <> 'OPTION OFF';\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 selection 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\nOne cannot remove components, either via Database Configuration Assistant (DBCA) or manually once the database has been created, either from a container or a non-container database.\n\nOne can, however, use DBCA to create a non-container database and remove components during the creation process, before the database is created.\n\nWhen using DBCA to create a custom non-container database, select\ncreation mode = advanced\nDatabase Template = Custom\nDatabase Options..Database Component.\n\nComponents that can be selected or de-selected are:\nOracle JVM, Oracle Text, Oracle Multimedia, Oracle OLAP, Oracle Spatial, Oracle Label Security, Oracle Application Express, Oracle Database Vault\n\nFor a container database (CDB), the CDB$ROOT must have all possible database components available. This is because, when a pluggable database (PDB) is plugged into the CDB, the CDB must have the same components installed as the PDB. Since we do not know what components the PDBS may have, the CDB must be able to support all possible PDB configurations.\n\nComponents installed in the CDB$ROOT do not need to be licensed. Components are only considered to be used if they are installed in the PDB.\n\nTo configure a PDB to only use specific components, do the following:\n\n1) Create a non-CDB 12.1 database and configure that database with the components desired.\n\n2) Plug the non-CDB database into a CDB database, creating a new PDB. If wanted, can then create additional clones from the new PDB.","ccis":["CCI-000381"]},{"vulnId":"V-220286","ruleId":"SV-220286r879587_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 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. 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 Extensions for .NET',\n'OLAP',\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 12.1, only the following components can be enabled/disabled:\n\nOracle Data Mining (dm)\nOracle Database Extensions for .NET (ode_net)\nOracle OLAP (olap)\nOracle Partitioning (partitioning)\nReal Application Testing (rat)\n\nUse the chopt utility (an Oracle-supplied operating system command that resides in the /bin directory) to disable each option that should not be available. The command format is \n\n chopt