<?xml version="1.0" encoding="UTF-8"?>
<!--
  - $Header: emdb/source/oracle/sysman/emdrep/rsc/db/compliance/dbSecureConfigCS.dlf /st_emdbsa_11.2/1 2010/06/09 19:19:31 jagopal Exp $
  -
  - Copyright (c) 2004 Oracle. All Rights Reserved.
  -
  - NAMEthis
  -   dbSecureConfigStd.dlf - Seed file for the MGMT_MESSAGES table
  -
  - DESCRIPTION
  -   This file contains seed data for the EM Messages table.
  -
  - NOTES
  -
  - MODIFIED   (MM/DD/YY)
  -  groyal     10/16/06 - Fix typo in AUDIT_TRAIL recommendation
  -  groyal     09/29/06 - Remove tabs.  See bug 5572246.
  -  groyal     09/03/06 - Fix UtlTcp_NAME
  -  groyal     08/09/06 - Created
  -->
<table xml:lang="en" name="MGMT_MESSAGES">

<!-- lookup-key indicates which columns are used by TransX to recognize a row as a duplicate -->
<lookup-key>
  <column name="MESSAGE_ID"/>
  <column name="SUBSYSTEM"/>
  <column name="LANGUAGE_CODE"/>
  <column name="COUNTRY_CODE"/>
</lookup-key>

<!-- columns indicates which columns will be loaded as part of processing the dataset and
       which should be translated by the Translation Group -->
<columns>
  <column name="MESSAGE_ID" type="string" maxsize="256"/>
  <column name="SUBSYSTEM" type="string" constant="CONFIG_STD"/>
  <column name="LANGUAGE_CODE" type="string" language="%l"/>
  <column name="COUNTRY_CODE" type="string" language="%Cs"/>
  <column name="MESSAGE" type="string" maxsize="1000" translate="yes"/>
</columns>

<!-- dataset specifies the data to be loaded into the repository -->
<dataset>

<!-- Secure Configuration for Oracle Database -->
<row>
    <col name="MESSAGE_ID">dbSecure_NAME</col>
    <col name="MESSAGE">Secure Configuration for Oracle Database</col>
</row>
<row>
    <col name="MESSAGE_ID">racSecure_NAME</col>
    <col name="MESSAGE">Secure Configuration for Oracle Real Application Cluster</col>
</row>
<row>
    <col name="MESSAGE_ID">dbSecure_DESC</col>
    <col name="MESSAGE">Ensures adherence with best-practice security configuration settings that help protect against database-related threats and attacks, providing a more secure operating environment for the Oracle database.</col>
</row>
<row>
    <col name="MESSAGE_ID">dbSecure_SecurityKEYWORD</col>
    <col name="MESSAGE">Security</col>
</row>

<!-- Folder: Post Installation -->
<row>
    <col name="MESSAGE_ID">PostInstallation_NAME</col>
    <col name="MESSAGE">Post Installation</col>
</row>
<row>
    <col name="MESSAGE_ID">PostInstallation_DESC</col>
    <col name="MESSAGE">Contains rules that ensure default database server accounts are secure. The most trivial method by which a database can be compromised is having a default database server account left open that uses its default password.</col>
</row>

<!-- Rule: Default Passwords Have Been Changed -->
<row>
    <col name="MESSAGE_ID">DefaultPwd_NAME</col>
    <col name="MESSAGE">Default Passwords Have Been Changed</col>
</row>
<row>
    <col name="MESSAGE_ID">DefaultPwd_DESC</col>
    <col name="MESSAGE">Ensures the default passwords of administrative accounts have been changed.</col>        
</row>
<row>
  <col name="MESSAGE_ID">DefaultPwd_RATIONALE</col>
  <col name="MESSAGE">Security is most easily broken when a default database user account still has a default password after installation.  In any Oracle environment, assign strong, secure passwords to administrative accounts immediately upon successful installation of the database server.</col>  
</row>
<row>
  <col name="MESSAGE_ID">DefaultPwd_FIX</col>
  <col name="MESSAGE">Change the default password of the administrative user.</col> 
</row>

<!-- Rule: Default Accounts are Locked and Expired -->
<row>
  <col name="MESSAGE_ID">DefaultAccountLockedAndExpired_NAME</col>
  <col name="MESSAGE">Default Accounts are Locked and Expired</col>
</row>
<row>
    <col name="MESSAGE_ID">DefaultAccountLockedAndExpired_DESC</col>
    <col name="MESSAGE">Ensures the default administrative accounts are locked and expired.</col>        
</row>
<row>
    <col name="MESSAGE_ID">DefaultAccountLockedAndExpired_RATIONALE</col>
    <col name="MESSAGE">Oracle Database installs with many default (present) database user accounts.  Upon the successful creation of a database server instance, default database user accounts should be locked and expired.  Left open in their default states, these user accounts can be exploited to gain unauthorized access to data or disrupt database operations.</col>
</row>
<row>
    <col name="MESSAGE_ID">DefaultAccountLockedAndExpired_FIX</col>
    <col name="MESSAGE">Lock and expire the default administrative account.</col> 
</row>
<!-- End Folder: Post Installation -->

<!-- Folder: Oracle Directory and File Permissions -->
<row>
    <col name="MESSAGE_ID">OracleDirAndFilePerms_NAME</col>
    <col name="MESSAGE">Oracle Directory and File Permissions</col>
</row>
<row>
    <col name="MESSAGE_ID">OracleDirAndFilePerms_DESC</col>
    <col name="MESSAGE">Contains rules that ensure the permissions on the directories and files containing the Oracle software are sufficient. Access should be restricted, making it more difficult for an operating system user to attack the database.</col>   
</row>

<!-- Folder: Unix Platform -->
<row>
    <col name="MESSAGE_ID">OracleDirAndFilePermsU_NAME</col>
    <col name="MESSAGE">Unix Platform</col>
</row>
<row>
    <col name="MESSAGE_ID">OracleDirAndFilePermsU_DESC</col>
    <col name="MESSAGE">Contains rules that ensure the permissions on the directories and files containing the Oracle software are sufficient.</col> 
</row>

<!-- Rule: Appropriate umask Value -->
<row>
    <col name="MESSAGE_ID">AppropriateUMaskValue_NAME</col>
    <col name="MESSAGE">Appropriate umask Value</col>
</row>
<row>
    <col name="MESSAGE_ID">AppropriateUMaskValue_DESC</col>
    <col name="MESSAGE">Ensures the owner of the Oracle software has an appropriate umask value of 022 set.</col>        
</row>
<row>
    <col name="MESSAGE_ID">AppropriateUMaskValue_RATIONALE</col>
    <col name="MESSAGE">If the umask value is not set to an appropriate value, such as 022, log and/or trace files might become generally accessible exposing sensitive information.</col> 
</row>
<row>
    <col name="MESSAGE_ID">AppropriateUMaskValue_FIX</col>
    <col name="MESSAGE">Set umask value to 022 for the owner of Oracle software.</col> 
</row>

<!-- Rule: Database Datafiles -->
<row>
    <col name="MESSAGE_ID">DbDatafilesU_NAME</col>
    <col name="MESSAGE">Database Datafiles</col>
</row>
<row>
    <col name="MESSAGE_ID">DbDatafilesU_DESC</col>
    <col name="MESSAGE">Ensures access to datafiles is restricted to the owner of the Oracle software and the DBA group.</col> 
</row>
<row>
    <col name="MESSAGE_ID">DbDatafilesU_RATIONALE</col>
    <col name="MESSAGE">Access to datafiles should be restricted in order to prevent accidental and/or deliberate unauthorized attempts to access or alter that data.</col>
</row>
<row>
    <col name="MESSAGE_ID">DbDatafilesU_FIX</col>
    <col name="MESSAGE">Restrict datafile permissions to the owner of the Oracle software and DBA group. Do not give world read and write permissions.</col> 
</row>

<!-- Rule: IFILE Referenced File (IFILE) -->
<row>
    <col name="MESSAGE_ID">IFileU_NAME</col>
    <col name="MESSAGE">IFILE Referenced File (IFILE)</col>
</row>
<row>
    <col name="MESSAGE_ID">IFileU_DESC</col>
    <col name="MESSAGE">Ensures access to files referenced by the IFILE database initialization parameter are restricted to the owner of the Oracle software and the DBA group.</col>
</row>
<row>
    <col name="MESSAGE_ID">IFileU_RATIONALE</col>
    <col name="MESSAGE">The IFILE database initialization parameter can be used to embed the contents of another initialization parameter file within the current initialization parameter file. Access to an initialization parameter file should be restricted in order to prevent exposing the security policies of the database as well as the weaknesses of the Oracle database configuration.</col>      
</row>
<row>
    <col name="MESSAGE_ID">IFileU_FIX</col>
    <col name="MESSAGE">Restrict permissions to the files referenced by the IFILE initialization parameter to the owner of the Oracle software and DBA group. Do not give world read or write permissions.</col> 
</row>

<!-- Rule: Audit File Destination (AUDIT_FILE_DEST) -->
<row>
    <col name="MESSAGE_ID">AuditFileDestU_NAME</col>
    <col name="MESSAGE">Audit File Destination (AUDIT_FILE_DEST)</col>
</row>
<row>
    <col name="MESSAGE_ID">AuditFileDestU_DESC</col>
    <col name="MESSAGE">Ensures access to directory referenced by the AUDIT_FILE_DEST database initialization parameter is restricted to the owner of the Oracle software and the DBA group.</col>
</row>
<row>
    <col name="MESSAGE_ID">AuditFileDestU_RATIONALE</col>
    <col name="MESSAGE">The AUDIT_FILE_DEST database initialization parameter specifies the operating system directory into which some audit data is written whether or not database auditing has been enabled.  Access to audit files should be restricted in order to prevent exposing sensitive information such as logging information related to database startup and shutdown, as well as privileged connections.</col>      
</row>
<row>
    <col name="MESSAGE_ID">AuditFileDestU_FIX</col>
    <col name="MESSAGE">Restrict permissions to the directory referenced by the AUDIT_FILE_DEST initialization parameter to the owner of the Oracle software and DBA group. Do not give world read or write permissions.</col>
</row>

<!-- Rule: User Dump Destination (USER_DUMP_DEST) -->
<row>
    <col name="MESSAGE_ID">UserDumpDestU_NAME</col>
    <col name="MESSAGE">User Dump Destination (USER_DUMP_DEST)</col>
</row>
<row>
    <col name="MESSAGE_ID">UserDumpDestU_DESC</col>
    <col name="MESSAGE">Ensures access to directory referenced by the USER_DUMP_DEST database initialization parameter is restricted to the owner of the Oracle software and the DBA group.</col>
</row>
<row>
    <col name="MESSAGE_ID">UserDumpDestU_RATIONALE</col>
    <col name="MESSAGE">The USER_DUMP_DEST database initialization parameter specifies the directory where the server will write debugging trace files on behalf of a user process. Access to these debugging trace files should be restricted in order to prevent exposing sensitive information regarding the database as well as the applications running on it.</col>           
</row>
<row>
    <col name="MESSAGE_ID">UserDumpDestU_FIX</col>
    <col name="MESSAGE">Restrict permissions to the directory referenced by the USER_DUMP_DEST initialization parameter to the owner of the Oracle software and DBA group. Do not give world read or write permissions.</col>  
</row>

<!-- Rule: Background Dump Destination (BACKGROUND_DUMP_DEST) -->
<row>
    <col name="MESSAGE_ID">BackgroundDumpDestU_NAME</col>
    <col name="MESSAGE">Background Dump Destination (BACKGROUND_DUMP_DEST)</col>
</row>
<row>
    <col name="MESSAGE_ID">BackgroundDumpDestU_DESC</col>
    <col name="MESSAGE">Ensures access to directory referenced by the BACKGROUND_DUMP_DEST database initialization parameter is restricted to the owner of the Oracle software and the DBA group.</col>
</row>
<row>
    <col name="MESSAGE_ID">BackgroundDumpDestU_RATIONALE</col>
    <col name="MESSAGE">The BACKGROUND_DUMP_DEST database initialization parameter specifies the directory where the server will write debugging trace files for the background processes (LGWR, DBWn, and so on) are written during Oracle operations. Access to these debugging trace files should be restricted in order to prevent exposing sensitive information regarding the database as well as the applications running on it.</col>           
</row>
<row>
    <col name="MESSAGE_ID">BackgroundDumpDestU_FIX</col>
    <col name="MESSAGE">Restrict permissions to the directory referenced by the BACKGROUND_DUMP_DEST initialization parameter to the owner of the Oracle software and DBA group. Do not give world read or write permissions.</col>
</row>

<!-- Rule: Core Dump Destination (CORE_DUMP_DEST) -->
<row>
    <col name="MESSAGE_ID">CoreDumpDestU_NAME</col>
    <col name="MESSAGE">Core Dump Destination (CORE_DUMP_DEST)</col>
</row>
<row>
    <col name="MESSAGE_ID">CoreDumpDestU_DESC</col>
    <col name="MESSAGE">Ensures access to directory referenced by the CORE_DUMP_DEST database initialization parameter is restricted to the owner of the Oracle software and the DBA group.</col>
</row>
<row>
    <col name="MESSAGE_ID">CoreDumpDestU_RATIONALE</col>
    <col name="MESSAGE">The CORE_DUMP_DEST database initialization parameter specifies the directory where the server will write core dump files. Access to these core dump files should be restricted in order to prevent exposing sensitive information regarding the database as well as the applications running on it.</col>           
</row>
<row>
    <col name="MESSAGE_ID">CoreDumpDestU_FIX</col>
    <col name="MESSAGE">Restrict permissions to the directory referenced by the CORE_DUMP_DEST initialization parameter to the owner of the Oracle software and DBA group. Do not give world read or write permissions.</col>
</row>

<!-- Rule: Control Files (CONTROL_FILES) -->
<row>
    <col name="MESSAGE_ID">ControlFilesU_NAME</col>
    <col name="MESSAGE">Control Files (CONTROL_FILES)</col>
</row>
<row>
    <col name="MESSAGE_ID">ControlFilesU_DESC</col>
    <col name="MESSAGE">Ensures access to directory referenced by the CONTROL_FILES database initialization parameter is restricted to the owner of the Oracle software and the DBA group.</col>
</row>
<row>
    <col name="MESSAGE_ID">ControlFilesU_RATIONALE</col>
    <col name="MESSAGE">Access to control files should be restricted in order to prevent exposing sensitive information regarding the database and its data.</col>       
</row>
<row>
    <col name="MESSAGE_ID">ControlFilesU_FIX</col>
    <col name="MESSAGE">Restrict permissions to the files referenced by the CONTROL_FILES initialization parameter to the owner of the Oracle software and DBA group. Do not give world read or write permissions.</col> 
</row>

<!-- Rule: Oracle Home Executables -->
<row>
    <col name="MESSAGE_ID">OHExecutablesU_NAME</col>
    <col name="MESSAGE">Oracle Home Executables</col>
</row>
<row>
    <col name="MESSAGE_ID">OHExecutablesU_DESC</col>
    <col name="MESSAGE">Ensures access to files in the ORACLE_HOME/bin directory is restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">OHExecutablesU_RATIONALE</col>
    <col name="MESSAGE">When access control permissions are too lax, opportunities for unauthorized exploitation as well as accidental or deliberate misuse arise.</col>
</row>
<row>
    <col name="MESSAGE_ID">OHExecutablesU_FIX</col>
    <col name="MESSAGE">Restrict permissions to all files in the ORACLE_HOME/bin directory to the owner of the Oracle software and DBA group. Do not give group or world write permission.  In other words, permissions should be set to 0755 or less.</col>
</row>

<!-- Rule: Oracle Home Non-Executables -->
<row>
    <col name="MESSAGE_ID">OHNonExecutablesU_NAME</col>
    <col name="MESSAGE">Oracle Home Non-Executables</col>
</row>
<row>
    <col name="MESSAGE_ID">OHNonExecutablesU_DESC</col>
    <col name="MESSAGE">Ensures access to files in the ORACLE_HOME directories, except for ORACLE_HOME/bin, is restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">OHNonExecutablesU_RATIONALE</col>
    <col name="MESSAGE">Access to these files should be restricted.  When access control permissions are too lax, opportunities for unauthorized exploitation as well as accidental or deliberate misuse arise.</col>
</row>
<row>
    <col name="MESSAGE_ID">OHNonExecutablesU_FIX</col>
    <col name="MESSAGE">Restrict permissions to all files in the ORACLE_HOME directories, except for ORACLE_HOME/bin, to the owner of the Oracle software and DBA group. Do not give group write permission nor world read, write or execute permission.  In other words, permissions should be set to 0750 or less.</col>
</row>
<!-- End Folder: Unix Platform -->

<!-- Folder: Windows Platform -->
<row>
    <col name="MESSAGE_ID">OracleDirAndFilePermsW_NAME</col>
    <col name="MESSAGE">Windows Platform</col>
</row>
<row>
    <col name="MESSAGE_ID">OracleDirAndFilePermsW_DESC</col>
    <col name="MESSAGE">Contains rules that ensure the permissions on the directories and files containing the Oracle software are sufficient.</col> 
</row>

<!-- Rule: Database Datafiles -->
<row>
    <col name="MESSAGE_ID">DbDatafilesW_NAME</col>
    <col name="MESSAGE">Database Datafiles</col>
</row>
<row>
    <col name="MESSAGE_ID">DbDatafilesW_DESC</col>
    <col name="MESSAGE">Ensures access to datafiles is restricted to the owner of the Oracle software.</col> 
</row>
<row>
    <col name="MESSAGE_ID">DbDatafilesW_RATIONALE</col>
    <col name="MESSAGE">Access to datafiles should be restricted in order to prevent accidental and/or deliberate unauthorized attempts to access or alter that data.</col>
</row>
<row>
    <col name="MESSAGE_ID">DbDatafilesW_FIX</col>
    <col name="MESSAGE">Restrict datafile permissions to the owner of the Oracle software and DBA group. Do not give any of the following permissions to any other users or user groups: DELETE, WRITE_DAC, WRITE_OWNER, CHANGE, ADD, or FULL.</col>
</row>

<!-- Rule: IFILE Referenced File (IFILE) -->
<row>
    <col name="MESSAGE_ID">IFileW_NAME</col>
    <col name="MESSAGE">IFILE Referenced File (IFILE)</col>
</row>
<row>
    <col name="MESSAGE_ID">IFileW_DESC</col>
    <col name="MESSAGE">Ensures access to files referenced by the IFILE database initialization parameter are restricted to the owner of the Oracle software.</col>
</row>
<row>
    <col name="MESSAGE_ID">IFileW_RATIONALE</col>
    <col name="MESSAGE">The IFILE database initialization parameter can be used to embed the contents of another initialization parameter file within the current initialization parameter file. Access to an initialization parameter file should be restricted in order to prevent exposing the security policies of the database as well as the weaknesses of the Oracle database configuration.</col>      
</row>
<row>
    <col name="MESSAGE_ID">IFileW_FIX</col>
    <col name="MESSAGE">Restrict permissions to the files referenced by the IFILE initialization parameter to the owner of the Oracle software and DBA group. Do not give any of the following permissions to any other users or user groups: DELETE, WRITE_DAC, WRITE_OWNER, CHANGE, ADD, or FULL.</col>
</row>

<!-- Rule: Audit File Destination (AUDIT_FILE_DEST) -->
<row>
    <col name="MESSAGE_ID">AuditFileDestW_NAME</col>
    <col name="MESSAGE">Audit File Destination (AUDIT_FILE_DEST)</col>
</row>
<row>
    <col name="MESSAGE_ID">AuditFileDestW_DESC</col>
    <col name="MESSAGE">Ensures access to directory referenced by the AUDIT_FILE_DEST database initialization parameter is restricted to the owner of the Oracle software.</col>
</row>
<row>
    <col name="MESSAGE_ID">AuditFileDestW_RATIONALE</col>
    <col name="MESSAGE">The AUDIT_FILE_DEST database initialization parameter specifies the operating system directory into which the audit trail is written when database auditing has been enabled.  Access to audit files should be restricted in order to prevent exposing sensitive information such as logging information related to database startup and shutdown as well as privileged connections.</col>      
</row>
<row>
    <col name="MESSAGE_ID">AuditFileDestW_FIX</col>
    <col name="MESSAGE">Restrict permissions to the directory referenced by the AUDIT_FILE_DEST initialization parameter to the owner of the Oracle software and DBA group. Do not give any of the following permissions to any other users or user groups: DELETE, WRITE_DAC, WRITE_OWNER, CHANGE, ADD, or FULL.</col>
</row>

<!-- Rule: User Dump Destination (USER_DUMP_DEST) -->
<row>
    <col name="MESSAGE_ID">UserDumpDestW_NAME</col>
    <col name="MESSAGE">User Dump Destination (USER_DUMP_DEST)</col>
</row>
<row>
    <col name="MESSAGE_ID">UserDumpDestW_DESC</col>
    <col name="MESSAGE">Ensures access to directory referenced by the USER_DUMP_DEST database initialization parameter is restricted to the owner of the Oracle software.</col>
</row>
<row>
    <col name="MESSAGE_ID">UserDumpDestW_RATIONALE</col>
    <col name="MESSAGE">The USER_DUMP_DEST database initialization parameter specifies the directory where the server will write debugging trace files on behalf of a user process. Access to these debugging trace files should be restricted in order to prevent exposing sensitive information regarding the database as well as the applications running on it.</col>           
</row>
<row>
    <col name="MESSAGE_ID">UserDumpDestW_FIX</col>
    <col name="MESSAGE">Restrict permissions to the directory referenced by the USER_DUMP_DEST initialization parameter to the owner of the Oracle software and DBA group. Do not give any of the following permissions to any other users or user groups: DELETE, WRITE_DAC, WRITE_OWNER, CHANGE, ADD, or FULL.</col>
</row>

<!-- Rule: Background Dump Destination (BACKGROUND_DUMP_DEST) -->
<row>
    <col name="MESSAGE_ID">BackgroundDumpDestW_NAME</col>
    <col name="MESSAGE">Background Dump Destination (BACKGROUND_DUMP_DEST)</col>
</row>
<row>
    <col name="MESSAGE_ID">BackgroundDumpDestW_DESC</col>
    <col name="MESSAGE">Ensures access to directory referenced by the BACKGROUND_DUMP_DEST database initialization parameter is restricted to the owner of the Oracle software.</col>
</row>
<row>
    <col name="MESSAGE_ID">BackgroundDumpDestW_RATIONALE</col>
    <col name="MESSAGE">The BACKGROUND_DUMP_DEST database initialization parameter specifies the directory where the server will write debugging trace files for the background processes (LGWR, DBWn, and so on) are written during Oracle operations. Access to these debugging trace files should be restricted in order to prevent exposing sensitive information regarding the database as well as the applications running on it.</col>           
</row>
<row>
    <col name="MESSAGE_ID">BackgroundDumpDestW_FIX</col>
    <col name="MESSAGE">Restrict permissions to the directory referenced by the BACKGROUND_DUMP_DEST initialization parameter to the owner of the Oracle software and DBA group. Do not give any of the following permissions to any other users or user groups: DELETE, WRITE_DAC, WRITE_OWNER, CHANGE, ADD, or FULL.</col> 
</row>

<!-- Rule: Core Dump Destination (CORE_DUMP_DEST) -->
<row>
    <col name="MESSAGE_ID">CoreDumpDestW_NAME</col>
    <col name="MESSAGE">Core Dump Destination (CORE_DUMP_DEST)</col>
</row>
<row>
    <col name="MESSAGE_ID">CoreDumpDestW_DESC</col>
    <col name="MESSAGE">Ensures access to directory referenced by the CORE_DUMP_DEST database initialization parameter is restricted to the owner of the Oracle software.</col>
</row>
<row>
    <col name="MESSAGE_ID">CoreDumpDestW_RATIONALE</col>
    <col name="MESSAGE">The CORE_DUMP_DEST database initialization parameter specifies the directory where the server will write core dump files. Access to these core dump files should be restricted in order to prevent exposing sensitive information regarding the database as well as the applications running on it.</col>           
</row>
<row>
    <col name="MESSAGE_ID">CoreDumpDestW_FIX</col>
    <col name="MESSAGE">Restrict permissions to the directory referenced by the CORE_DUMP_DEST initialization parameter to the owner of the Oracle software and DBA group. Do not give any of the following permissions to any other users or user groups: DELETE, WRITE_DAC, WRITE_OWNER, CHANGE, ADD, or FULL.</col>
</row>

<!-- Rule: Control Files (CONTROL_FILES) -->
<row>
    <col name="MESSAGE_ID">ControlFilesW_NAME</col>
    <col name="MESSAGE">Control Files (CONTROL_FILES)</col>
</row>
<row>
    <col name="MESSAGE_ID">ControlFilesW_DESC</col>
    <col name="MESSAGE">Ensures access to directory referenced by the CONTROL_FILES database initialization parameter is restricted to the owner of the Oracle software.</col>
</row>
<row>
    <col name="MESSAGE_ID">ControlFilesW_RATIONALE</col>
    <col name="MESSAGE">Access to control files should be restricted in order to prevent exposing sensitive information regarding the database and its data.</col>       
</row>
<row>
    <col name="MESSAGE_ID">ControlFilesW_FIX</col>
    <col name="MESSAGE">Restrict permissions to the files referenced by the CONTROL_FILES initialization parameter to the owner of the Oracle software and DBA group. Do not give any of the following permissions to any other users or user groups: DELETE, WRITE_DAC, WRITE_OWNER, CHANGE, ADD, or FULL.</col>
</row>

<!-- Rule: Oracle Home Executables -->
<row>
    <col name="MESSAGE_ID">OHExecutablesW_NAME</col>
    <col name="MESSAGE">Oracle Home Executables</col>
</row>
<row>
    <col name="MESSAGE_ID">OHExecutablesW_DESC</col>
    <col name="MESSAGE">Ensures access to files in the ORACLE_HOME/bin directory is restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">OHExecutablesW_RATIONALE</col>
    <col name="MESSAGE">Access to these executables should be restricted.  When access control permissions are too lax, opportunities for unauthorized exploitation as well as accidental or deliberate misuse arise.</col>
</row>
<row>
    <col name="MESSAGE_ID">OHExecutablesW_FIX</col>
    <col name="MESSAGE">Restrict permissions to all files in the ORACLE_HOME/bin directory to the owner of the Oracle software and DBA group. Do not give any of the following permissions to any other users or user groups: DELETE, WRITE_DAC, WRITE_OWNER, CHANGE, ADD, or FULL.</col>
</row>

<!-- Rule: Oracle Home Non-Executables -->
<row>
    <col name="MESSAGE_ID">OHNonExecutablesW_NAME</col>
    <col name="MESSAGE">Oracle Home Non-Executables</col>
</row>
<row>
    <col name="MESSAGE_ID">OHNonExecutablesW_DESC</col>
    <col name="MESSAGE">Ensures access to files in the ORACLE_HOME directories, except for ORACLE_HOME/bin, is restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">OHNonExecutablesW_RATIONALE</col>
    <col name="MESSAGE">Access to these files should be restricted.  When access control permissions are too lax, opportunities for unauthorized exploitation as well as accidental or deliberate misuse arise.</col>
</row>
<row>
    <col name="MESSAGE_ID">OHNonExecutablesW_FIX</col>
    <col name="MESSAGE">Restrict permissions to all files in the ORACLE_HOME directories, except for ORACLE_HOME/bin, to the owner of the Oracle software and DBA group. Do not give any of the following permissions to any other users or user groups: DELETE, WRITE_DAC, WRITE_OWNER, CHANGE, ADD, or FULL.</col>
</row>
<!-- End Folder: Windows Platform -->

<!-- Rule: Oracle Home Executable Files Owned by Oracle -->
<row>
    <col name="MESSAGE_ID">OHExecutablesOracleOwned_NAME</col>
    <col name="MESSAGE">Oracle Home Executable Files Owned by Oracle</col>
</row>
<row>
    <col name="MESSAGE_ID">OHExecutablesOracleOwned_DESC</col>
    <col name="MESSAGE">Ensures ownership of all files in the ORACLE_HOME/bin directory is the same as the owner of the Oracle software installation.</col>           
</row>
<row>
    <col name="MESSAGE_ID">OHExecutablesOracleOwned_RATIONALE</col>
    <col name="MESSAGE">Access to these executables should be restricted.  When access control permissions are too lax, opportunities for unauthorized exploitation as well as accidental or deliberate misuse arise.</col>
</row>
<row>
    <col name="MESSAGE_ID">OHExecutablesOracleOwned_FIX</col>
    <col name="MESSAGE">Change the owner of files in the ORACLE_HOME/bin directory to be the same as the owner of the Oracle software installation.</col>
</row>
<!-- End Folder: Oracle Directory and File Permissions -->

<!-- Folder: Oracle Parameter Settings -->
<row>
    <col name="MESSAGE_ID">OracleParamSettings_NAME</col>
    <col name="MESSAGE">Oracle Parameter Settings</col>
</row>
<row>
    <col name="MESSAGE_ID">OracleParamSettings_DESC</col>
    <col name="MESSAGE">Contains rules that ensure database initialization parameter settings are secure.</col>
</row>

<!-- Rule: Access to Trace Files Disabled (_TRACE_FILES_PUBLIC) -->
<row>
    <col name="MESSAGE_ID">AccessToTraceFileDisabled_NAME</col>
    <col name="MESSAGE">Access to Trace Files Disabled (_TRACE_FILES_PUBLIC)</col>
</row>
<row>
    <col name="MESSAGE_ID">AccessToTraceFileDisabled_DESC</col>
    <col name="MESSAGE">Ensures database trace files are not readable by users.</col>
</row>
<row>
    <col name="MESSAGE_ID">AccessToTraceFileDisabled_RATIONALE</col>
    <col name="MESSAGE">The _TRACE_FILES_PUBLIC parameter indicates whether or not debugging trace files generated by Oracle in the directory specified by the USER_DUMP_DEST parameter are readable to everyone.  Access to these debugging trace files should be restricted in order to prevent exposing sensitive information regarding the database as well as the applications running on it.</col>         
</row>
<row>
    <col name="MESSAGE_ID">AccessToTraceFileDisabled_FIX</col>
    <col name="MESSAGE">Set _TRACE_FILES_PUBLIC to FALSE.</col>
</row>

<!-- Rule: Remote OS Roles Disabled (REMOTE_OS_ROLES) -->
<row>
    <col name="MESSAGE_ID">RemoteOSRolesDisabled_NAME</col>
    <col name="MESSAGE">Remote OS Roles Disabled (REMOTE_OS_ROLES)</col>
</row>
<row>
    <col name="MESSAGE_ID">RemoteOSRolesDisabled_DESC</col>
    <col name="MESSAGE">Ensures remote OS roles are disabled; that is, the database has not been configured to enable roles based on remote operating system user group membership.</col>
</row>
<row>
    <col name="MESSAGE_ID">RemoteOSRolesDisabled_RATIONALE</col>
    <col name="MESSAGE">The REMOTE_OS_ROLES parameter specifies whether operating system roles are allowed for remote clients. If users connect to the database over Oracle Net, and their roles are not authenticated by Oracle, the remote user could impersonate another operating system user over a network connection. Allowing users to remotely authenticate is a bad security practice in itself. Adding the ability to assume operating system roles for these accounts makes the situation even more insecure.</col>   
</row>
<row>
    <col name="MESSAGE_ID">RemoteOSRolesDisabled_FIX</col>
    <col name="MESSAGE">Set REMOTE_OS_ROLES to FALSE to help enforce server-based authentication of clients connecting to the Oracle database.</col>
</row>

<!-- Rule: Remote OS Authentication Disabled (REMOTE_OS_AUTHENT) -->
<row>
    <col name="MESSAGE_ID">RemoteOSAuthenticationDisabled_NAME</col>
    <col name="MESSAGE">Remote OS Authentication Disabled (REMOTE_OS_AUTHENT)</col>
</row>
<row>
    <col name="MESSAGE_ID">RemoteOSAuthenticationDisabled_DESC</col>
    <col name="MESSAGE">Ensures remote OS authentication is disabled.</col>
</row>
<row>
    <col name="MESSAGE_ID">RemoteOSAuthenticationDisabled_RATIONALE</col>
    <col name="MESSAGE">Setting the REMOTE_OS_AUTHENT parameter to TRUE forces Oracle to accept a client operating system user name received over a non-secure connection and use it for account access.  Since clients, such as PCs, are not trusted to perform operating system authentication properly, it is a very poor security practice to turn on this feature.</col> 
</row>
<row>
    <col name="MESSAGE_ID">RemoteOSAuthenticationDisabled_FIX</col>
    <col name="MESSAGE">Set REMOTE_OS_AUTHENT to FALSE to help enforce server-based authentication of clients connecting to the Oracle database.</col>      
</row>

<!-- Rule: Use of Remote Listener Instances Disabled (REMOTE_LISTENER) -->
<row>
    <col name="MESSAGE_ID">RemoteLsnrInstancesDisabled_NAME</col>
    <col name="MESSAGE">Use of Remote Listener Instances Disabled (REMOTE_LISTENER)</col>
</row>
<row>
    <col name="MESSAGE_ID">RemoteLsnrInstancesDisabled_DESC</col>
    <col name="MESSAGE">Ensures the use of listener instances on a remote machine separate from the database instance is disabled.</col>
</row>
<row>
    <col name="MESSAGE_ID">RemoteLsnrInstancesDisabled_RATIONALE</col>
    <col name="MESSAGE">The REMOTE_LISTENER parameter can be used to allow a listener on a remote machine to access the database. You should prevent the use of a listener on a remote machine.</col>
</row>
<row>
    <col name="MESSAGE_ID">RemoteLsnrInstancesDisabled_FIX</col>
    <col name="MESSAGE">Set REMOTE_LISTENER to "" (null string).  Note, this parameter is not applicable in a multi-master replication or RAC environment where this setting provides a load balancing mechanism for the listener.</col>
</row>

<!-- Rule: Database Auditing Enabled (AUDIT_TRAIL) -->
<row>
    <col name="MESSAGE_ID">DbAuditingEnabled_NAME</col>
    <col name="MESSAGE">Database Auditing Enabled (AUDIT_TRAIL)</col>
</row>
<row>
    <col name="MESSAGE_ID">DbAuditingEnabled_DESC</col>
    <col name="MESSAGE">Ensures database auditing is enabled.</col>
</row>
<row>
    <col name="MESSAGE_ID">DbAuditingEnabled_RATIONALE</col>
    <col name="MESSAGE">The AUDIT_TRAIL parameter enables or disables database auditing.  Auditing is always about accountability, and is frequently done to protect and preserve privacy for the information stored in databases.  Auditing also enables system administrators to implement enhanced protections, early detection of suspicious activities, and finely-tuned security responses.</col> 
</row>
<row>
    <col name="MESSAGE_ID">DbAuditingEnabled_FIX</col>
    <col name="MESSAGE">Set AUDIT_TRAIL to either DB, default, or OS.  Database-stored audit records can be easier to review and manage than OS-stored audit records. However, audit records stored in operating system files can be protected from DBAs via appropriate file permissions, and will remain available even if the database is temporarily inaccessible.</col>
</row>
<row>
    <col name="MESSAGE_ID">DbAuditingEnabled_WARNING</col>
    <col name="MESSAGE">Although auditing is relatively inexpensive, limit the number of audited events as far as possible. Doing so minimizes the performance impact on the execution of audited statements and the size of the audit trail, making it easier to analyze and understand.</col>  
</row>

<!-- Rule: Secure OS Authentication Prefix (OS_AUTHENT_PREFIX) -->
<row>
    <col name="MESSAGE_ID">SecureOSAuthenticationPrefix_NAME</col>
    <col name="MESSAGE">Secure OS Authentication Prefix (OS_AUTHENT_PREFIX)</col>
</row>
<row>
    <col name="MESSAGE_ID">SecureOSAuthenticationPrefix_DESC</col>
    <col name="MESSAGE">Ensures that the OS authentication prefix is set to a value other than OPS$.</col>
</row>
<row>
    <col name="MESSAGE_ID">SecureOSAuthenticationPrefix_RATIONALE</col>
    <col name="MESSAGE">The OS_AUTHENT_PREFIX parameter specifies a prefix used to authenticate users attempting to connect to the server. When a connection request is attempted, Oracle compares the prefixed username with usernames in the database. Using the OPS$ prefix tends to result in an insecure configuration because an account can be authenticated either as an operating system user or with the password used in the IDENTIFIED BY clause. Attackers are aware of this and will attack these accounts.</col>
</row>
<row>
    <col name="MESSAGE_ID">SecureOSAuthenticationPrefix_FIX</col>
    <col name="MESSAGE">Set OS_AUTHENT_PREFIX to a value other than OPS$.</col>
</row>

<!-- Rule: Access to Data Dictionary Protected (07_DICTIONARY_ACCESSIBILITY) -->
<row>
    <col name="MESSAGE_ID">AccessToDataDictionaryProtected_NAME</col>
    <col name="MESSAGE">Access to Data Dictionary Protected (07_DICTIONARY_ACCESSIBILITY)</col>
</row>
<row>
    <col name="MESSAGE_ID">AccessToDataDictionaryProtected_DESC</col>
    <col name="MESSAGE">Ensures data dictionary protection is enabled.</col>
</row>
<row>
    <col name="MESSAGE_ID">AccessToDataDictionaryProtected_RATIONALE</col>
    <col name="MESSAGE">Setting the 07_DICTIONARY_ACCESSIBILITY to TRUE allows users with ANY system privileges to access the data dictionary.  As a result, these user accounts can be exploited to gain unauthorized access to data. Instead the data dictionary should be protected such that only those authorized users making DBA-privileged connections can use the ANY system privilege to access the data dictionary.</col>
</row>
<row>
    <col name="MESSAGE_ID">AccessToDataDictionaryProtected_FIX</col>
    <col name="MESSAGE">Set 07_DICTIONARY_ACCESSIBILITY to FALSE. If a user needs view access to the data dictionary, then it is permissible to grant that user the SELECT ANY DICTIONARY system privilege.</col>
</row>

<!-- Rule: Auditing of SYS Operations Enabled (AUDIT_SYS_OPERATIONS) -->
<row>
    <col name="MESSAGE_ID">AuditingSysOperationsEnabled_NAME</col>
    <col name="MESSAGE">Auditing of SYS Operations Enabled (AUDIT_SYS_OPERATIONS)</col>
</row>
<row>
    <col name="MESSAGE_ID">AuditingSysOperationsEnabled_DESC</col>
    <col name="MESSAGE">Ensures sessions for users who connect as SYS are fully audited.</col>
</row>
<row>
    <col name="MESSAGE_ID">AuditingSysOperationsEnabled_RATIONALE</col>
    <col name="MESSAGE">The AUDIT_SYS_OPERATIONS parameter enables or disables the auditing of operations issued by user SYS, and users connecting with SYSDBA or SYSOPER privileges. Since these are highly privileged users, auditing can be especially important.</col>
</row>
<row>
    <col name="MESSAGE_ID">AuditingSysOperationsEnabled_FIX</col>
    <col name="MESSAGE">Set AUDIT_SYS_OPERATIONS to TRUE.</col>
</row>
<row>
    <col name="MESSAGE_ID">AuditingSysOperationsEnabled_WARNING</col>
    <col name="MESSAGE">Some operations (e.g. export) may involve substantial actions by privileged users, resulting in substantial unnecessary audit data. You may choose to set this parameter to FALSE in these situations to avoid overload of the SYSTEM tablespace, which contains the audit records.</col>
</row>
<!-- End Folder: Oracle Parameter Settings -->

<!-- Folder: Database Password Profile Settings -->
<row>
    <col name="MESSAGE_ID">DbPwdProfileSettings_NAME</col>
    <col name="MESSAGE">Database Password Profile Settings</col>
</row>
<row>
    <col name="MESSAGE_ID">DbPwdProfileSettings_DESC</col>
    <col name="MESSAGE">Contains rules that ensure database profile settings correctly defined. Oracle password management is controlled through the use of user profiles which are then assigned to database users, enabling greater control over database security.</col>
</row>

<!-- Rule: Secure Failed Login Attempts Setting -->
<row>
    <col name="MESSAGE_ID">SecureFailedLoginAttemptsSetting_NAME</col>
    <col name="MESSAGE">Secure Failed Login Attempts Setting</col>
</row>
<row>
    <col name="MESSAGE_ID">SecureFailedLoginAttemptsSetting_DESC</col>
    <col name="MESSAGE">Ensures profiles have FAILED_LOGIN_ATTEMPTS set to a reasonable number of failed attempts.</col>
</row>
<row>
    <col name="MESSAGE_ID">SecureFailedLoginAttemptsSetting_RATIONALE</col>
    <col name="MESSAGE">The FAILED_LOGIN_ATTEMPTS parameter defines the number of successive failed login attempts that can be performed before an account's status is changed to locked. This protects against attackers attempting to guess a password for an account. If this parameter is set low enough, the effectiveness of password attacks on the database can be eliminated.</col> 
</row>
<row>
    <col name="MESSAGE_ID">SecureFailedLoginAttemptsSetting_FIX</col>
    <col name="MESSAGE">Set FAILED_LOGIN_ATTEMPTS a value less than or equal to 10.</col>
</row>

<!-- Rule: Secure Password Life Time Setting  -->
<row>
    <col name="MESSAGE_ID">SecurePwdLifeTimeSetting_NAME</col>
    <col name="MESSAGE">Secure Password Life Time Setting</col>
</row>
<row>
    <col name="MESSAGE_ID">SecurePwdLifeTimeSetting_DESC</col>
    <col name="MESSAGE">Ensures profiles have PASSWORD_LIFE_TIME set to a reasonable number of days.</col>     
</row>
<row>
    <col name="MESSAGE_ID">SecurePwdLifeTimeSetting_RATIONALE</col>
    <col name="MESSAGE">The PASSWORD_LIFE_TIME parameter defines the maximum lifetime for passwords. Changing passwords on a regular basis is an accepted security practice for mitigating the threat that a password may have been compromised. If this parameter is set too high or is not set at all, old passwords may be compromised and remain in use for an extended period of time.</col>                 
</row>
<row>
    <col name="MESSAGE_ID">SecurePwdLifeTimeSetting_FIX</col>
    <col name="MESSAGE">Set PASSWORD_LIFE_TIME to a value such as 180 days. This requires password to be changed frequently enough without overloading the users with having to pick new passwords frequently. If set too low, the user is forced to update their password so frequently that they need to choose low quality passwords in order to be able to remember them.</col>
</row>

<!-- Rule: Secure Password Lock Time Setting  -->
<row>
    <col name="MESSAGE_ID">SecurePwdLockTimeSetting_NAME</col>
    <col name="MESSAGE">Secure Password Lock Time Setting</col>
</row>
<row>
    <col name="MESSAGE_ID">SecurePwdLockTimeSetting_DESC</col>
    <col name="MESSAGE">Ensures profiles have PASSWORD_LOCK_TIME set to a reasonable number of days.</col>
</row>
<row>
    <col name="MESSAGE_ID">SecurePwdLockTimeSetting_RATIONALE</col>
    <col name="MESSAGE">The PASSWORD_LOCK_TIME parameter defines the number of days an account will remain locked after the maximum number of failed login attempts has been reached. Specifying a large value increases the likelihood of Denial of Service attacks.  Specifying a zero (0) removes any penalty for repeated bad password guesses.</col>
</row>
<row>
    <col name="MESSAGE_ID">SecurePwdLockTimeSetting_FIX</col>
    <col name="MESSAGE">Set PASSWORD_LOCK_TIME to a value greater than or equal to 1.</col>
</row>

<!-- Rule: Secure Password Grace Time Setting  -->
<row>
    <col name="MESSAGE_ID">SecurePwdGraceTimeSetting_NAME</col>
    <col name="MESSAGE">Secure Password Grace Time Setting</col>
</row>
<row>
    <col name="MESSAGE_ID">SecurePwdGraceTimeSetting_DESC</col>
    <col name="MESSAGE">Ensures profiles have PASSWORD_GRACE_TIME set to a reasonable number of days.</col>
</row>
<row>
    <col name="MESSAGE_ID">SecurePwdGraceTimeSetting_RATIONALE</col>
    <col name="MESSAGE">The PASSWORD_GRACE_TIME parameter defines the number of days after a password expires in which the user is not required to change the password. During the grace period, the user is prompted for a new password each time an attempt is made to access their accounts. If this parameter is set too high, password expiration can be ignored.</col>
</row>
<row>
    <col name="MESSAGE_ID">SecurePwdGraceTimeSetting_FIX</col>
    <col name="MESSAGE">Set PASSWORD_GRACE_TIME to a value less than or equal to 7.</col>
</row>

<!-- Rule: Password Complexity Checking Enabled  -->
<row>
    <col name="MESSAGE_ID">PwdComplexityCheckingEnabled_NAME</col>
    <col name="MESSAGE">Password Complexity Checking Enabled</col>
</row>
<row>
    <col name="MESSAGE_ID">PwdComplexityCheckingEnabled_DESC</col>
    <col name="MESSAGE">Ensures profiles have PASSWORD_VERIFY_FUNCTION defined.</col>
</row>
<row>
    <col name="MESSAGE_ID">PwdComplexityCheckingEnabled_RATIONALE</col>
    <col name="MESSAGE">The PASSWORD_VERIFY_FUNCTION defines the function that will be used to validate the strength of the password. By setting a function to validate password strength, you can ensure that strong passwords are being used.</col>
</row>
<row>
    <col name="MESSAGE_ID">PwdComplexityCheckingEnabled_FIX</col>
    <col name="MESSAGE">Specify a password verification function, by using the PASSWORD_VERIFY_FUNCTION parameter.</col>
</row>
<!-- End Folder: Database Password Profile Settings -->

<!-- Folder: Database Access Settings -->
<row>
    <col name="MESSAGE_ID">DbAccessSettings_NAME</col>
    <col name="MESSAGE">Database Access Settings</col>
</row>
<row>
    <col name="MESSAGE_ID">DbAccessSettings_DESC</col>
    <col name="MESSAGE">Contains rules that ensure data security.  That is, access to and use of the database at the object level is restricted such that users are only given those privileges that are actually required to efficiently perform their jobs.</col>
</row>

<!-- Folder: Views -->
<row>
    <col name="MESSAGE_ID">Views_NAME</col>
    <col name="MESSAGE">Views</col>
</row>
<row>
    <col name="MESSAGE_ID">Views_DESC</col>
    <col name="MESSAGE">Contains rules that ensure privileges on views are restricted.</col>
</row>

<!-- Rule: Restricted Access to DBA_ROLES -->
<row>
    <col name="MESSAGE_ID">DBARoles_NAME</col>
    <col name="MESSAGE">Restricted Access to DBA_ROLES</col>
</row>
<row>
    <col name="MESSAGE_ID">DBARoles_DESC</col>
    <col name="MESSAGE">Ensures restricted access to DBA_ROLES.</col>
</row>
<row>
    <col name="MESSAGE_ID">DBARoles_RATIONALE</col>
    <col name="MESSAGE">The DBA_ROLES view contains details of all roles in the database. Knowledge of the structure of roles in the database can be taken advantage of by a malicious user.  Access to DBA_ROLES should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">DBARoles_FIX</col>
    <col name="MESSAGE">Revoke access to DBA_ROLES from all users other than SYS or DBA accounts.</col>
</row>

<!-- Rule: Restricted Access to DBA_SYS_PRIVS -->
<row>
    <col name="MESSAGE_ID">DBASysPrivs_NAME</col>
    <col name="MESSAGE">Restricted Access to DBA_SYS_PRIVS</col>
</row>
<row>
    <col name="MESSAGE_ID">DBASysPrivs_DESC</col>
    <col name="MESSAGE">Ensures restricted access to DBA_SYS_PRIVS.</col>
</row>
<row>
    <col name="MESSAGE_ID">DBASysPrivs_RATIONALE</col>
    <col name="MESSAGE">The DBA_SYS_PRIVS view contains details of system privileges granted to roles and users. Knowledge of the system privileges can be taken advantage of by a malicious user.  Access to DBA_SYS_PRIVS should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">DBASysPrivs_FIX</col>
    <col name="MESSAGE">Revoke access to DBA_SYS_PRIVS from all users other than SYS or DBA accounts.</col>
</row>

<!-- Rule: Restricted Access to DBA_ROLE_PRIVS -->
<row>
    <col name="MESSAGE_ID">DBARolePrivs_NAME</col>
    <col name="MESSAGE">Restricted Access to DBA_ROLE_PRIVS</col>
</row>
<row>
    <col name="MESSAGE_ID">DBARolePrivs_DESC</col>
    <col name="MESSAGE">Ensures restricted access to DBA_ROLE_PRIVS.</col>
</row>
<row>
    <col name="MESSAGE_ID">DBARolePrivs_RATIONALE</col>
    <col name="MESSAGE">The DBA_ROLE_PRIVS view contains details of all roles granted to users and other roles. Knowledge of the structure of roles in the database can be taken advantage of by a malicious user. Access to DBA_ROLE_PRIVS should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">DBARolePrivs_FIX</col>
    <col name="MESSAGE">Revoke access to DBA_ROLE_PRIVS from all users other than SYS or DBA accounts.</col> 
</row>

<!-- Rule: Restricted Access to DBA_TAB_PRIVS -->
<row>
    <col name="MESSAGE_ID">DBATabPrivs_NAME</col>
    <col name="MESSAGE">Restricted Access to DBA_TAB_PRIVS</col>
</row>
<row>
    <col name="MESSAGE_ID">DBATabPrivs_DESC</col>
    <col name="MESSAGE">Ensures restricted access to DBA_TAB_PRIVS.</col>
</row>
<row>
    <col name="MESSAGE_ID">DBATabPrivs_RATIONALE</col>
    <col name="MESSAGE">The DBA_TAB_PRIVS view contains details of all grants on all objects in the database. Knowledge of who is granted what object privileges in the database can be taken advantage of by a malicious user.  Access to DBA_TAB_PRIVS should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">DBATabPrivs_FIX</col>
    <col name="MESSAGE">Revoke access to DBA_TAB_PRIVS from all users other than SYS or DBA accounts.</col> 
</row>

<!-- Rule: Restricted Access to DBA_USERS -->
<row>
    <col name="MESSAGE_ID">DBAUsers_NAME</col>
    <col name="MESSAGE">Restricted Access to DBA_USERS</col>
</row>
<row>
    <col name="MESSAGE_ID">DBAUsers_DESC</col>
    <col name="MESSAGE">Ensures restricted access to DBA_USERS.</col>
</row>
<row>
    <col name="MESSAGE_ID">DBAUsers_RATIONALE</col>
    <col name="MESSAGE">The DBA_USERS view describes all users in the database including password hashes and other account information. Knowledge of this type of information can be taken advantage of by a malicious user.  Access to DBA_USERS should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">DBAUsers_FIX</col>
    <col name="MESSAGE">Revoke access to DBA_USERS from all users other than SYS or DBA accounts.</col> 
</row>
<!-- End Folder: Views -->

<!-- Folder: Tables -->
<row>
    <col name="MESSAGE_ID">Tables_NAME</col>
    <col name="MESSAGE">Tables</col>
</row>
<row>
    <col name="MESSAGE_ID">Tables_DESC</col>
    <col name="MESSAGE">Contains rules that ensure privileges on tables are restricted.</col>
</row>

<!-- Rule: Restricted Access to SYS.AUD$ -->
<row>
    <col name="MESSAGE_ID">SYSAud_NAME</col>
    <col name="MESSAGE">Restricted Access to SYS.AUD$</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSAud_DESC</col>
    <col name="MESSAGE">Ensures restricted access to SYS.AUD$.</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSAud_RATIONALE</col>
    <col name="MESSAGE">When database auditing is enabled and is using a database audit trail (AUDIT_TRAIL set to DB), the database directs audit records to a single table named SYS.AUD$. When auditing for suspicious database activity, the audit trail must be protected so audit information cannot be added, changed or deleted without being audited. Access to SYS.AUD$ should be restricted in order to prevent accidental and/or deliberate unauthorized attempts to access or alter that data.</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSAud_FIX</col>
    <col name="MESSAGE">Revoke access to SYS.AUD$ from all users other than SYS or DBA accounts.</col> 
</row>

<!-- Rule: Restricted Access to SYS.USER_HISTORY$ -->
<row>
    <col name="MESSAGE_ID">SYSUserHistory_NAME</col>
    <col name="MESSAGE">Restricted Access to SYS.USER_HISTORY$</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSUserHistory_DESC</col>
    <col name="MESSAGE">Ensures restricted access to SYS.USER_HISTORY$.</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSUserHistory_RATIONALE</col>
    <col name="MESSAGE">The SYS.USER_HISTORY$ table stores hashed passwords that were previously used by each account. Access to this table can make guessing the existing password for an account easier for someone hacking the database.  Access to SYS.USER_HISTORY$ should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSUserHistory_FIX</col>
    <col name="MESSAGE">Revoke access to SYS.USER_HISTORY$ from all users other than SYS or DBA accounts.</col> 
</row>

<!-- Rule: Restricted Access to SYS.USER$ -->
<row>
    <col name="MESSAGE_ID">SYSUser_NAME</col>
    <col name="MESSAGE">Restricted Access to SYS.USER$</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSUser_DESC</col>
    <col name="MESSAGE">Ensures restricted access to SYS.USER$.</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSUser_RATIONALE</col>
    <col name="MESSAGE">The SYS.USER$ table stores usernames, hashed passwords and other database account information. Access to this table can make it easier for someone hacking the database.  Access to SYS.USER$ should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSUser_FIX</col>
    <col name="MESSAGE">Revoke access to SYS.USER$ from all users other than SYS or DBA accounts.</col> 
</row>

<!-- Rule: Restricted Access to SYS.SOURCE$ -->
<row>
    <col name="MESSAGE_ID">SYSSource_NAME</col>
    <col name="MESSAGE">Restricted Access to SYS.SOURCE$</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSSource_DESC</col>
    <col name="MESSAGE">Ensures restricted access to SYS.SOURCE$.</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSSource_RATIONALE</col>
    <col name="MESSAGE">The SYS.SOURCE$ table stores all source code stored in the database. Access to this table can make it easier for someone hacking the database.  Access to SYS.SOURCE$ should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">SYSSource_FIX</col>
    <col name="MESSAGE">Revoke access to SYS.SOURCE$ from all users other than SYS or DBA accounts.</col> 
</row>

<!-- Rule: Restricted Access to PERFSTAT.STATS$SQLTEXT -->
<row>
    <col name="MESSAGE_ID">PERFSTATStatsSqlText_NAME</col>
    <col name="MESSAGE">Restricted Access to PERFSTAT.STATS$SQLTEXT</col>
</row>
<row>
    <col name="MESSAGE_ID">PERFSTATStatsSqlText_DESC</col>
    <col name="MESSAGE">Ensures restricted access to PERFSTAT.STATS$SQLTEXT.</col>
</row>
<row>
    <col name="MESSAGE_ID">PERFSTATStatsSqlText_RATIONALE</col>
    <col name="MESSAGE">The PERFSTAT.STATS$SQLTEXT table provides full text for recently executed SQL statements. Access to this table can make it easier for someone hacking the database.  Access to PERFSTAT.STATS$SQLTEXT should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">PERFSTATStatsSqlText_FIX</col>
    <col name="MESSAGE">Revoke access to PERFSTAT.STATS$SQLTEXT from all users other than SYS or DBA accounts.</col> 
</row>

<!-- Rule: Restricted Access to PERFSTAT.STATS$SQL_SUMMARY -->
<row>
    <col name="MESSAGE_ID">PERFSTATStatsSqlSummary_NAME</col>
    <col name="MESSAGE">Restricted Access to PERFSTAT.STATS$SQL_SUMMARY</col>
</row>
<row>
    <col name="MESSAGE_ID">PERFSTATStatsSqlSummary_DESC</col>
    <col name="MESSAGE">Ensures restricted access to PERFSTAT.STATS$SQL_SUMMARY.</col>
</row>
<row>
    <col name="MESSAGE_ID">PERFSTATStatsSqlSummary_RATIONALE</col>
    <col name="MESSAGE">The PERFSTAT.STATS$SQL_SUMMARY table contains the first few lines of SQL text of the most resource intensive commands recently executed. Access to this table can make it easier for someone hacking the database.  Access to PERFSTAT.STATS$SQL_SUMMARY should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">PERFSTATStatsSqlSummary_FIX</col>
    <col name="MESSAGE">Revoke access to PERFSTAT.STATS$SQL_SUMMARY from all users other than SYS or DBA accounts.</col> 
</row>
<!-- End Folder: Tables -->

<!-- Folder: Packages -->
<row>
    <col name="MESSAGE_ID">Packages_NAME</col>
    <col name="MESSAGE">Packages</col>
</row>
<row>
    <col name="MESSAGE_ID">Packages_DESC</col>
    <col name="MESSAGE">Contains rules that ensure privileges on packages are restricted.</col>
</row>

<!-- Rule: Restricted Privilege to Execute UTL_FILE -->
<row>
    <col name="MESSAGE_ID">UtlFile_NAME</col>
    <col name="MESSAGE">Restricted Privilege to Execute UTL_FILE</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlFile_DESC</col>
    <col name="MESSAGE">
    Ensures permission to execute the UTL_FILE package has not been 
    granted to the PUBLIC role.</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlFile_RATIONALE</col>
    <col name="MESSAGE">The UTL_FILE package allows PL/SQL to read from and write to files on the operating system. This feature though very useful, can also be can be used to break into a database, gain elevated privileges, or corrupt a database.  Having access to this powerful package through the PUBLIC role is a security risk as any database user can exercise privileges granted to PUBLIC.  Access to this package should be restricted.</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlFile_FIX</col>
    <col name="MESSAGE">Grant privileges to execute the UTL_FILE package only to those specific accounts that need to execute the package.</col>
</row>

<!-- Rule: Restricted Privilege to Execute UTL_TCP -->
<row>
    <col name="MESSAGE_ID">UtlTcp_NAME</col>
    <col name="MESSAGE">Restricted Privilege to Execute UTL_TCP</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlTcp_DESC</col>
    <col name="MESSAGE">Ensures permission to execute the UTL_TCP package has not been granted to the PUBLIC role.</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlTcp_RATIONALE</col>
    <col name="MESSAGE">The UTL_TCP package permits outgoing network connections to be established by the database to any receiving network service.  Thus, arbitrary data may be sent between the database and any waiting network service.</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlTcp_FIX</col>
    <col name="MESSAGE">Grant privileges to execute the UTL_TCP package only to those specific accounts that need to execute the package.</col>
</row>

<!-- Rule: Restricted Privilege to Execute UTL_HTTP -->
<row>
    <col name="MESSAGE_ID">UtlHttp_NAME</col>
    <col name="MESSAGE">Restricted Privilege to Execute UTL_HTTP</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlHttp_DESC</col>
    <col name="MESSAGE">Ensures permission to execute the UTL_HTTP package has not been granted to the PUBLIC role.</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlHttp_RATIONALE</col>
    <col name="MESSAGE">The UTL_HTTP package allows HTTP requests and responses to be sent from within PL/SQL. Granting this package to PUBLIC may permit using HTML forms to send data to a malicious Web site.</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlHttp_FIX</col>
    <col name="MESSAGE">Grant privileges to execute the UTL_HTTP package only to those specific accounts that need to execute the package.</col>
</row>

<!-- Rule: Restricted Privilege to Execute UTL_SMTP -->
<row>
    <col name="MESSAGE_ID">UtlSmtp_NAME</col>
    <col name="MESSAGE">Restricted Privilege to Execute UTL_SMTP</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlSmtp_DESC</col>
    <col name="MESSAGE">Ensures permission to execute the UTL_SMTP package has not been granted to the PUBLIC role.</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlSmtp_RATIONALE</col>
    <col name="MESSAGE">The UTL_SMTP package allows a database user to send or receive email using PL/SQL. Granting this package to PUBLIC may permit unauthorized exchange of mail messages.</col>
</row>
<row>
    <col name="MESSAGE_ID">UtlSmtp_FIX</col>
    <col name="MESSAGE">Grant privileges to execute the UTL_SMTP package only to those specific accounts that need to execute the package.</col>
</row>

<!-- Rule: Restricted Privilege to Execute DBMS_JOB -->
<row>
    <col name="MESSAGE_ID">DbmsJob_NAME</col>
    <col name="MESSAGE">Restricted Privilege to Execute DBMS_JOB</col>
</row>
<row>
    <col name="MESSAGE_ID">DbmsJob_DESC</col>
    <col name="MESSAGE">
    Ensures permission to execute the DBMS_JOB package has not been 
    granted to the PUBLIC role.</col>
</row>
<row>
    <col name="MESSAGE_ID">DbmsJob_RATIONALE</col>
    <col name="MESSAGE">The DBMS_JOB package allows users to schedule administrative procedures to be performed at periodic intervals.  It is also the interface for the job queue.  While not strictly a security risk, there is no valid reason to grant execute on this package to PUBLIC.</col>  
</row>
<row>
    <col name="MESSAGE_ID">DbmsJob_FIX</col>
    <col name="MESSAGE">Grant privileges to execute the DBMS_JOB package only to those specific accounts that need to execute the package.</col>
</row>

<!-- Rule: Restricted Privilege to Execute DBMS_SYS_SQL -->
<row>
    <col name="MESSAGE_ID">DbmsSysSql_NAME</col>
    <col name="MESSAGE">Restricted Privilege to Execute DBMS_SYS_SQL</col>
</row>
<row>
    <col name="MESSAGE_ID">DbmsSysSql_DESC</col>
    <col name="MESSAGE">Ensures permission to execute the DBMS_SYS_SQL package has not been granted to the PUBLIC role.</col>
</row>
<row>
    <col name="MESSAGE_ID">DbmsSysSql_RATIONALE</col>
    <col name="MESSAGE">The undocumented DBMS_SYS_SQL package allows users to execute PL/SQL and SQL as the owner of the procedure rather than the caller. Access to this package should be restricted.</col> 
</row>
<row>
    <col name="MESSAGE_ID">DbmsSysSql_FIX</col>
    <col name="MESSAGE">Grant privileges to execute the DBMS_SYS_SQL package only to those specific accounts that need to execute the package.</col>
</row>
<!-- End Folder: Packages -->

<!-- End Folder: Database Access Settings -->

 </dataset>
</table>
