Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Ask the DBA to describe/demonstrate any software modification detection procedures in place and request documents of these procedures for review. Verify by reviewing reports for inclusion of the DBMS executable and configuration files. If documented procedures and proof of implementation does not exist that includes review of the database software directories and database application directories, this is a Finding.
Develop, document and implement procedures to monitor changes made to the DBMS software. Identify all database files and directories to be included in the host system or database backups and provide these to the person responsible for backups. For Windows systems, you can use the dir /s > filename.txt run weekly to store and compare file modification/creation dates and file sizes using the DOS fc command. For UNIX systems, you can use the ls –as >filename.txt command to store and compare (diff command) file statistics for comparison. These are not as comprehensive as some tools available, but may be enhanced by including checks for checksums or file hashes.
Review documented and implemented procedures for controlling and granting access to the Oracle DBMS software installation account. If access or use of this account is not restricted to the minimum number of personnel required, or unauthorized access to the account has been granted, this is a Finding. On UNIX systems: If the account is not disabled when not in use, and not configured to prevent direct logon, this is a Finding. On Windows systems: The Oracle DBMS software is usually installed using an account with administrator privileges. Ownership is assigned to the account used to install the DBMS software. The creation of a dedicated Oracle OS account and change of ownership of all files in the %ORACLE_HOME% and %ORACLE_BASE% directories and subdirectories should be performed prior to placing the DBMS system into production. See checks DG0019, DO0120 and DG0102 for details on establishing a dedicated OS account for Oracle services on Windows platforms.
Develop, document and implement procedures to restrict use of the Oracle DBMS software installation account. Unix environments: Ensure that the Oracle DBMS software installation account is disabled when not in use, except in cases where this would interfere with required functionality. In such cases, prevent direct logon as the Oracle DBMS software installation account by locking its password; authorize the appropriate administrative users to operate as the Oracle DBMS software installation account via the "su" or "sudo" command. Other environments: Ensure that the Oracle DBMS software installation account is disabled when not in use.
Review documented software and configuration monitoring procedures and implementation evidence to verify that monitoring of changes to database software libraries, related applications and configuration files is being performed weekly or more often. Verify that a list of files and directories being monitored is complete. If monitoring is not being performed weekly or more often, this is a Finding. If implementation evidence is not complete, this is a Finding.
Develop, document and implement procedures to monitor for unauthorized changes to DBMS software libraries, related software application libraries and configuration files. If a third-party automated tool is not employed, an automated job that reports file information on the directories and files of interest and compares them to the baseline report for the same will meet the requirement. File hashes or checksums should be used for comparisons as file dates may be manipulated by malicious users.
If a listener is not running on the local database host server, this check is Not a Finding. NOTE: 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. For subsequent database home reviews on the same host system, mark this check as Not a Finding. Determine all Listeners running on the host. For Windows hosts, view all Windows services with TNSListener embedded in the service name - The service name format is: Oracle[ORACLE_HOME_NAME]TNSListener For UNIX hosts, the Oracle Listener process will indicate the TNSLSNR executable. At a command prompt, issue the command: ps -ef | grep tnslsnr | grep –v grep The alias for the listener follows tnslsnr in the command output. You must be logged on the host system using the account that owns the tnslsnr executable (UNIX). If the account is denied local login, have the system SA assist you in this task by 'su' to the listener account from the root account. On Windows platforms, log in using an account with administrator privileges to complete the check. From a system command prompt, execute the listener control utility: lsnrctl status [LISTENER NAME] Review the results for the value of Security. If Security = OFF is displayed, this is a Finding. If Security = ON: Local OS Authentication is displayed, this is not a Finding. If 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). Repeat the execution of the lsnrctl utility for all active listeners.
Configure the listener to use Local OS Authentication. This setting prevents remote administration of the listener, restricts management to the Oracle listener owner account (UNIX) and accounts with administrator privileges (WIN). Remote administration of the listener should not be permitted. If listener administration from a remote system is required, granting secure remote access to the Oracle DBMS server and performing local administration is preferred. Authorize and document this requirement in the System Security Plan.
Locate the Listener and SQLNet log files. View the contents of the sqlnet.ora and listener.ora configuration files located in the ORACLE_HOME/network/admin directory or the directory specified by the TNS_ADMIN environment variable (if set) for the listener process/service account: If the sqlnet.ora parameter TRACE_LEVEL_SERVER is not defined or is set to OFF OR 0, SQLNet logging is not enabled and the check for these parameters below is Not a Finding, otherwise, verify the directories specified in the following parameters of the sqlnet.ora file exist: LOG_FILE_SERVER = sqlnet [filename is sqlnet.log] LOG_DIRECTORY_SERVER = [directory on a volume with enough free space] Verify the directories and files specified in the following parameters of the listener.ora exist: NOTE: If you are using Automatic Diagnostic Repository (ADR) logging (DIAG_ADR_ENABLED_[listener name] = ON in listener.ora), the following parameters are Not Applicable. Setting DIAG_ADR_ENABLED_[listener name] = OFF reverts to traditional listener tracing/logging and the following parameters are in effect. For more information on Automatic Diagnostic Repository (ADR), refer to Oracle MetaLink Note 454927.1. LOG_DIRECTORY_[listener name] = [directory on a volume with enough free space] LOG_FILE_[listener name] = listener TRACE_DIRECTORY_[listener name] = [directory on a volume with enough free space] Default log file locations (by Oracle Version): - DIAG_ADR_ENABLED_[listener name] = OFF: -- listener log directory and file: ORACLE_HOME/network/log/listener.log -- listener trace directory and files: ORACLE_HOME/network/trace/listener.trc -- sqlnet log file: ORACLE_HOME/network/log/sqlnet.log -- sqlnet trace file: ORACLE_HOME/network/trace/sqlnet.trc - DIAG_ADR_ENABLED_[listener name] = ON: NOTE: The ADR_HOME is defined from the ADR_BASE parameter. If ADR_BASE is not defined, then ADR_BASE is set to the value of the DIAGNOSTIC_DEST initialization parameter, or if DIAGNOSTIC_DEST is not defined, then the value of the ORACLE_BASE environment variable is used. See Oracle MetaLink Note 453125.1 for more information on ADR file locations. -- listener log directory and file: [ADR_HOME]/alert/log.xml -- listener trace log directory and files: [ADR_HOME]/trace/alert_[SID].log and [ADR_HOME]/trace/*.trc -- sqlnet log file: [ADR_BASE]/diag/clients/[database name]/[SID]/trace/sqlnet.log and [listener name].log -- sqlnet trace file: [ADR_BASE]/diag/clients/[database name]/[SID]/trace/*.trc The listener log file location may also be determined using the lsnrctl utility, STATUS command, and viewing the value displayed for listener log file. Review access permissions assigned to the files and directories: - For UNIX, verify that the permissions on the directory and log files are restricted to the Oracle software owner and OS DBA and/or Listener process group. - For Windows, verify that the file permissions on the listener.log and sqlnet.log files restrict access to the Oracle software owner and OS DBA and/or Listener process group. If access to the files is not restricted as listed above, this is a Finding.
Restrict access to the listener and sqlnet log files. Restrict access to the tnslsnr service account to DBAs, SAs and auditors where they are required by assigned responsibilities.
Review the System Security Plan for remote applications that access and use the database. If none of the applications accessing the database uses a single account for access by multiple persons or processes, this check is Not a Finding. Verify that the application account uses PKI authentication: From SQL*Plus: select name, ext_username from user$ where ext_username is not null; If the ext_username indicates a directory name, then verify that the directory name is authenticated using PKI. You may require the DBA or directory server administrator to display the username definition in the directory service to you. If the ext_username does not specify a certificate or PKI-authenticated user account, this is a Finding.
Configure PKI authentication to help protect access to the shared account. PKI authentication may be accomplished using Oracle Advanced Security on most platforms. On a Windows host, user authentication using PKI may be used with Active Directory or NTS authentication using the DoD CAC. On UNIX and other hosts, Oracle Advanced Security may be used to authenticate via LDAP or SSL. The application may require storage of the authentication certificate in the Oracle Wallet or on a hardware security module (HSM) to authenticate. Please see the Oracle Security Guides and the Oracle Advanced Security Guides for instructions on configuring PKI authentication.
If a listener is not running on the local database host server, this check is Not a Finding. Use the LSNRCTL utility and issue the STATUS [listener-name] command to locate the listener.ora file. Open the listener.ora file in a text editor or viewer. Locate the line with ADMIN_RESTRICTIONS_[listener-name] = ON where listener-name is the alias of the listener supplied by the DBA. If no such line is found, this is a Finding. Repeat for each listener listed in the LISTENER.ORA file.
Edit the listener.ora file and add the following line for each listener in use on the system: ADMIN_RESTRICTIONS_[listener-name] = ON Restart the listener to activate the setting.
Interview the IAO and review documentation to determine if a configuration management (CM) process is implemented for the DBMS system that includes requirements for: (1) Formally documented CM roles, responsibilities, and procedures to include the management of IA information and documentation; (2) A configuration control board that implements procedures to ensure a security review and approval of all proposed DoD information system changes, to include interconnections to other DoD information systems; (3) A testing process to verify proposed configuration changes prior to implementation in the operational environment; and (4) A verification process to provide additional assurance that the CM process is working effectively and that changes outside the CM process are technically or procedurally not permitted. If documented evidence for procedures or processes outlined above are not present or are incomplete, this is a Finding.
Develop, document and implement configuration management procedures or processes. Ensure the 4 major requirements listed in the check are documented at a minimum. Assign responsibilities for oversight and approval for any and all changes made to DBMS software and configuration.
Use the Oracle Universal Installer or OPATCH utility to display the list of installed products. Review the list of installed products with the DBA and verify any installed products listed below are required and licensed. If any are installed and are not required or not licensed, this is a Finding. From Command Prompt: $ORACLE_HOME/OPatch/opatch lsinventory –detail | more (UNIX) %ORACLE_HOME%/OPatch/opatch lsinventory –detail | more (Windows) Requires additional License on Enterprise Edition: Oracle Active Data Guard Oracle Total Recall Oracle Real Application Clusters Oracle In-Memory Database Cache Oracle Advanced Security Oracle Label Security Oracle Database Vault Oracle Change Management Pack Oracle Configuration Management Pack Oracle Diagnostic Pack Oracle Tuning Pack Oracle Provisioning and Patch Automation Pack Oracle Real Application Testing Oracle Partitioning Oracle OLAP Oracle Data Mining Oracle Data Quality and Profiling Oracle Data Watch and Repair Connector Oracle Advanced Compression Oracle Spatial Oracle Content Database Suite Requires additional License: Oracle Database Gateways Confirm requirements for these products: Database Workspace Manager Enterprise Manager Agent iSQL*Plus LDAP Oracle Data Guard Oracle Fail Safe (Windows only) Oracle HTTP Server Oracle interMedia Oracle Internet Directory Oracle Advanced Replication Oracle Starter Database Oracle Text Oracle Virtual Private Database Oracle Wallet Manager (Requires Advanced Security when using PKI and transparent encryption) Oracle XML Development Sample Schema NOTE: This list does not take into account product dependencies that, when selected for de-install, remove required database software. A custom installation without selection of unnecessary components is required to ensure a clean install of only required and licensed products. The list of product dependencies may be subject to change by Oracle and is not addressed here.
Review the list of installed products available for the DBMS install. If any are required and licensed for operation of applications that will be accessing the DBMS, include them in the application design specification and list them in the System Security Plan. If any are not, but have been installed, uninstall them and remove any database schemas, objects, applications and security principals that exclusively support them. Verify correct operation of the required Oracle components in a test environment before aplying these changes to a production system.
Review the System Security Plan and interview the DBA and IAO to determine if the DBMS host contains production and non-production DBMS installations. If the DBMS host contains both production and non-production DBMS installations or the production DBMS installation is being used for non-production efforts, determine if this allowance is documented in the System Security Plan and authorized by the IAO. If not documented and authorized, this is a Finding. NOTE: Though shared production/non-production DBMS installations was allowed under previous database STIG guidance, doing so may place it in violation of OS, Application, Network or Enclave STIG guidance. Ensure that any shared production/non-production DBMS installations meets STIG guidance requirements at all levels or mitigate any conflicts in STIG guidance with your DAA.
Recommend establishing a dedicated DBMS host for production DBMS installations (See Checks DG0109 and DG0110). A dedicated host system in this case refers to an instance of the operating system at a minimum. The operating system may reside on a virtual host machine where supported by the DBMS vendor.
Ask the DBA/SA to demonstrate file and group ownership of the Oracle DBMS software and files and directories. On Windows systems: Launch a Windows Explorer window. In the Right Pane, Right-Click on one of the display headers and select Owner from the list. Move the Owner column after the Name column. Size the Owner column to fit the current contents. NOTE: This will show the owner column for this folder only. If you want to see the owner column in all folders, select Tools -> Options -> View tab and click on the Apply to All Folders button. The Oracle DBMS software is usually installed using an account with administrator privileges and ownership is assigned either to the account used to install the DBMS software or to the Administrators group. For DBMS systems with multiple Oracle Homes using a common Oracle Base, ensure an ownership review for files and directories in the %ORACLE_BASE% that are not addressed above is performed. If any files or directories belonging to an Oracle DBMS software installation are not owned by a dedicated Oracle OS owner account, this is a Finding. On UNIX systems: find $ORACLE_HOME /var/opt/oracle /etc/ora* /usr/local/bin/*ora* usr/local/bin/db* ! -user oracle -o ! -group oinstall | xargs ls -lR -d Where "oracle" is the known Oracle Owner account name and "oinstall" is the known Oracle Group account name. Review the resulting output and note the file/directory ownership. For DBMS systems with multiple Oracle Homes using a common Oracle Base, ensure an ownership review for files and directories in the %ORACLE_BASE% that are not addressed above is performed. If any files or directories belonging to an Oracle DBMS software installation are not owned by a dedicated Oracle OS owner account, this is a Finding. The owner and group ownership as well as file permissions for the following files (if present) should not be changed: extjob jssu nmb nmhs nmo oradism externaljob.ora coraenv dbhome oraenv
Assign DBMS file and directory ownership to a dedicated Oracle OS owner account. Document the locations of Oracle DBMS files and directories in the System Security Plan. On Windows systems: The creation of a dedicated Oracle OS account and change of ownership of all files in the %ORACLE_HOME% directories and subdirectories should be performed prior to placing the DBMS system into production. See checks DO0120 and DG0102 for details on establishing a dedicated OS account for Oracle services on Windows platforms. Using the dedicated Oracle OS owner account to install and maintain the DBMS software libraries and configuration files will help maintain file and directory ownership. On UNIX systems: Assign DBMS file and directory ownership to a dedicated Oracle host OS software installation and maintenance account. The owner and group ownership as well as file permissions for the following files (if present) should not be changed: extjob jssu nmb nmhs nmo oradism externaljob.ora coraenv dbhome oraenv Using the dedicated Oracle host OS software installation and maintenance account to install and maintain the DBMS software libraries and configuration files will help maintain file and directory ownership.
Review DBMS software baseline procedures and implementation evidence. Review the list of files, directories and details included in the current baseline for completeness. If DBMS software configuration baseline procedures do not exist, evidence of implementation does not exist, or baseline is not documented and current, this is a Finding.
Develop, document and implement DBMS software baseline procedures that include all DBMS software files and directories under the ORACLE_BASE and ORACLE_HOME environment variables and any custom and platform-specific directories. Generate a list of files, directories and details for the DBMS software configuration baseline. Update the configuration baseline after new installations, upgrades/updates or maintenance activities that include changes to the baseline software.
Review the DBMS audit trail to determine if the names [or unique identifiers] of applications used to connect to the database are included. If an alternate method other than DBMS logging is authorized and implemented, review the audit trail to determine if the names [or unique identifiers] of applications used to connect to the database are included. If application access to the DBMS is not being audited, this is a Finding. If auditing does not capture the name [or unique identifier] of applications accessing the DBMS at a minimum, this is a Finding.
Modify auditing to ensure audit records include identification of applications used to access the DBMS. Ensure auditing captures the name [or unique identifier] of applications accessing the DBMS at a minimum. Develop or procure a 3rd-party solution where native DBMS logging is not employed or does not capture required information.
Review documented and implemented procedures contained or noted in the System Security Plan for providing database client connection information to users and user workstations. Oracle client connection information is stored in the file: $ORACLE_HOME/network/admin/tnsnames.ora (UNIX) %ORACLE_HOME%\network\admin\tnsnames.ora (Windows) If procedures do not indicate and implement restrictions in distribution of connection definitions to personnel/machines authorized to connect to the database, this is a Finding.
Develop, document and implement procedures to distribute client connection definitions or definition files that contain only connection definitions authorized for that user or user workstation. Include or note these procedures in the System Security Plan.
If all database accounts are configured to authenticate using certificates or other credentials besides passwords, this check is Not a Finding. Review documented procedures and evidence of implementation for assignment of temporary passwords for password-authenticated accounts. Confirm temporary passwords meet DoD password requirements. Review documented procedures for distribution of temporary passwords to users. Have the DBA demonstrate that the DBMS or applications accessing the database are configured to require a change of password by the user upon first use. If documented procedures and evidence do not exist or are not complete, temporary passwords do not meet DoD password requirements, or the DBMS or applications accessing the database are not configured to require a change of password by the user upon first use, this is a Finding.
Develop, document and implement procedures for assigning, distributing and changing of temporary passwords for new database user accounts. Procedures should include instruction that meet current DoD password length and complexity requirements and provide a secure method to relay the temporary password to the user. Temporary passwords should also be short-lived and require immediate update by the user upon first use. Consider using account authentication using certificates or other credentials in place of password authentication.
This check applies specifically to the Oracle DBMS installation and its associated files, scripts and environments. This check does not apply to compiled, encoded or encrypted application source code and batch job code covered in Check DG0130. Ask the DBA to review the list of DBMS database objects, database configuration files, associated scripts and applications defined within and external to the DBMS that access the database. The list should also include files or settings used to configure the operational environment for the DBMS and for interactive DBMS user accounts. Ask the DBA and/or IAO to determine if any DBMS database objects, database configuration files, associated scripts and applications defined within or external to the DBMS that access the database, and DBMS / user environment files/settings contain database passwords. If any do, confirm that DBMS passwords stored internally or externally to the DBMS are encoded or encrypted. If any passwords are stored in clear text, this is a Finding. If a list of DBMS database objects, database configuration files, associated scripts and applications defined within or external to the DBMS that access the database, and DBMS / user environment files/settings is not maintained in the System Security Plan, this is a Finding.
Develop, document and maintain a list of DBMS database objects, database configuration files, associated scripts and applications defined within or external to the DBMS that access the database, and DBMS / user environment files/settings in the System Security Plan. Record whether they do or do not contain DBMS passwords. If passwords are present, ensure they are encoded or encrypted and protected by host system security. Consider using vendor or 3rd party tools to support external authentication (i.e. Oracle Database Vault).
Review policy and instructions included or noted in the System Security Plan used to inform users and administrators not to enter database passwords at the command line. Review documented and implemented procedures used to monitor the DBMS system for such activity. If policy or instructions do not exist, proof of users and administrators being briefed does not exist or monitoring for compliance is not being performed to dissuade the practice of entering database passwords on the command line, this is a Finding.
Review policy and instructions included or noted in the System Security Plan used to inform users and administrators not to enter database passwords at the command line. Review documented and implemented procedures used to monitor the DBMS system for such activity. If policy or instructions do not exist, proof of users and administrators being briefed does not exist or monitoring for compliance is not being performed to dissuade the practice of entering database passwords on the command line, this is a Finding.
Ask the DBA if the DBMS is accessed remotely for administration purposes. If it is not, this check is Not a Finding. If it is, ask the DBA if the remote access to DBA accounts is made using remote access to the DBMS host or made directly to the database from a remote database client. If administration is performed using remote access to the DBMS host, review policy and procedures documented or noted in the System Security Plan, along with evidence that remote administration of the DBMS is performed only via an encrypted connection protocol such as SSH or IPSec. If it is not, this is a Finding. If administration is performed from a remote database client, confirm that a dedicated database listener that encrypts communications exists for remote administrative communications. If a DBMS listener that encrypts traffic is not configured, this is a Finding. If any listeners on the DBMS host are configured to accept unencrypted traffic, review documented policy, procedures and evidence of training DBAs not to use the unencrypted listener for remote access to DBA accounts. If no such policy exists or the DBAs have not been instructed not to use the unencrypted connections, this is a Finding. Note: Out-Of-Band (OOB) is allowed for remote administration, however, OOB alone does not maintain encryption of network traffic from source to destination and is a Finding for this check. Ensure unclassified, sensitive data transmitted through a commercial or wireless network are encrypted using NIST-certified cryptography.
Where remote access to DBA accounts is not allowed, develop, document and implement policies and train DBAs that remote access to DBA accounts is prohibited. Where remote access to DBA accounts is allowed, the remote connection must be encrypted. Ensure unclassified, sensitive data transmitted through a commercial or wireless network are encrypted using NIST-certified cryptography. If remote access is established via the database listener, then install a dedicated listener configured to encrypt all traffic for use by DBAs for remote access. This requires use of Oracle Advanced Security and Oracle Wallet Manager. See the Oracle Advanced Security Guide, Configuring Network Data Encryption and Integrity for Oracle Servers and Clients for details. Configure the listener to require SSL for the DBA connections by specifying the TCPS as the network protocol. Sample listener.ora entries: DBALSNR = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS) (HOST = [IP]) (PORT = 1575)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = [SID]) ) ) Configure the server's FIPS.ORA file to use FIPS 140-2 compliant settings to encrypt the traffic and ensure integrity of the transmission. In the FIPS.ORA file in the $ORACLE_HOME/ldap/admin directory or the directory specified in the FIPS_HOME environment variable for the dedicated listener on the server, add the following line: SSLFIPS_140=TRUE Monitor the listener log files for evidence of any unencrypted remote access to DBA accounts.
If the database being reviewed is not a production database, this check is Not a Finding. Review policy and procedures documented or noted in the System Security plan as well as evidence of implementation for daily audit trail monitoring. If policy and procedures are not documented or evidence of implementation is not available, this is a Finding.
Develop, document and implement policy and procedures to monitor audit trail data daily.
Review the Oracle process/owner account. For UNIX Systems: Log into the Oracle installation account and from a system prompt enter: groups If root is returned in the list, this is a Finding. For Windows Systems: Log in using an account with administrator privileges. Open the Services snap-in. If the Oracle services are not assigned a dedicated OS account (view the Log on As tab), this is a Finding. If the account is assigned group membership to other than the local administrator account and Oracle DBA groups, this is a Finding. View user rights assigned to the service accounts. If Deny Logon Locally is not assigned to the Oracle service account, this is a Finding. If the service account is a domain rather than local user account, confirm with the DBA that domain resources are required and that the account is not assigned to any domain groups not required for Oracle operation (e.g. the domain users or domain administrators groups). If the service account is a domain account and the account is assigned to domain groups not required for Oracle operations, this is a Finding.
Remove root privileges from the Oracle software owner account on UNIX systems. Create and assign a dedicated OS account for all Oracle processes (Windows). Grant the dedicated OS account Oracle DBA privileges and assign the Deny Logon Locally user right to the dedicated OS account.
Review the membership for the Oracle DBA host system OS group. On UNIX systems: cat /etc/group | grep -i dba [where dba is the default group name from Oracle] To display the group name if dba is not the default, use the command: cat $ORACLE_HOME/rdbms/lib/config.[cs] | grep SS_DBA_GRP On Windows Systems: Open Computer Management, expand System Tools, expand Local Users and Groups, select the Group folder. Double-click on the ORA_DBA group to view group members. Compare the list of members with the list of authorized DBA accounts documented in the System Security Plan with the IAO. If any users are assigned to the group that are not authorized by the IAO and documented in the System Security Plan for the system, this is a Finding.
Document user accounts that are authorized by the IAO to be assigned DBA privileges in the System Security Plan. Remove any accounts assigned membership in the operating system DBA group that has not been authorized by the IAO. Develop, document and implement procedures for periodic review of accounts assigned membership to the DBA group.
Review the listener.ora file and the sqlnet.ora file. If the INBOUND_CONNECT_TIMEOUT_[listener-name] parameter does not exist for each listener found in the listener.ora and contain a value greater than 0, this is a Finding. If the SQLNET.INBOUND_CONNECT_TIMEOUT parameter does not exist in the sqlnet.ora and contain a value greater than 0, this is a Finding. NOTE: although the default value may provide adequate protection, assuming the default could lead to unanticipated changes in future product updates. Specify a value to manage the setting.
Using a text editor or administrative tool, modify the listener.ora file to include a limit for connection request timeouts for the listener. Example entry (value unit is in seconds): INBOUND_CONNECT_TIMEOUT_LISTENER = 2 Modify the sqlnet.ora file to include a limit for connection request timeouts for the listener. Example entry (value unit is in seconds): SQLNET.INBOUND_CONNECT_TIMEOUT = 3 Review the Oracle Net Services Administrator's Guide for information about configuring these parameters.
View the SQLNET.ORA file to verify if a SQLNET.EXPIRE_TIME has been set to the value greater than 0. If the parameter does not exist or is set to 0, this is a Finding.
Using a text editor or administrative tool, modify the SQLNET.ORA file on the database host server to include a limit for connection request timeouts for the listener. Example entry (value unit is in minutes): SQLNET.EXPIRE_TIME = 3 NOTE: Use the lowest number possible that does not generate so much network traffic that performance becomes unacceptable. The lower the number, the less likely an exhaustion of resources will occur. Set the value to the lowest number greater than 0 that is supported by the target system environment.
Determine if the Oracle Management Agent is installed: From SQL*Plus: select account_status from dba_users where upper(username) = 'DBSNMP'; If no rows are returned, this is not a Finding. If the DBSNMP account exists and the account_status is OPEN, then verify in the System Security Plan that operation and use of the Oracle Enterprise Manager Management Agent or another SNMP management program is documented and authorized. If it is not documented in the System Security Plan as being required, this is a Finding. If the DBSNMP account exists and the account_status is not OPEN, schedule the FIX action below then mark as not a Finding. Despite any justification or authorization, if a Management Agent is installed on a DBMS server that is in a DMZ and Internet facing, this is a Finding.
Use the ORACLE_HOME/rdbms/admin/catnsnmp.sql script to remove all Oracle SNMP management agent objects in the database. Delete the executable file ORACLE_HOME/bin/dbsnmp or dbsnmp.exe if it exists from any Oracle Home not authorized for SNMP management. Uninstall any SNMP management agents installed on Oracle database servers installed in a DMZ that serve applications to Internet users. Uninstall any SNMP management agents that have not been authorized and documented in the System Security Plan. Document any authorized use of the SNMP management agent on database servers that do not support Internet applications in a DMZ in the System Security Plan. NOTE: Removal of SNMP management objects will prevent the ability to generate database statistics within Oracle Enterprise Manager.
For UNIX Systems: ls $ORACLE_BASE ls $ORACLE_HOME If the ORACLE_BASE directory contains subdirectories other than ORACLE_HOME directories, a flash_recovery_area directory and an admin directory, verify they are used by the DBMS. If they are not part of the Oracle DBMS software product, this is a Finding. NOTE: Oracle DBMS data file storage may be placed on a separate, dedicated disk partition and linked to ORACLE_BASE. Refer to check DG0112. For Windows Systems: echo %ORACLE_BASE% echo %ORACLE_HOME% ORACLE_BASE, if defined, is usually set to C:\Program Files\Oracle. If ORACLE_HOME is not in a dedicated directory separate from the OS software and other applications where supported by the DBMS, this is a Finding. All Systems: Recommend dedicating a separate partition for the DBMS software libraries where supported by the DBMS on all platforms.
Install Oracle DBMS software using directories separate from the OS and other application software library directories. Re-locate any directories or re-install other application software that currently shares the DBMS software library directory to separate directories. Recommend dedicating a separate partition for the DBMS software libraries where supported by the DBMS.
From SQL*Plus: select banner from v$version where banner like 'Oracle%'; The currently supported Oracle 11g version as of 07/2015 is: 11.2 - Premier Support for 11.2 ended 31 Jan 2015; Extended Support is free for one year thereafter. Extended Support for 11.2 ends 31 Jan 2018. Sustaining Support for 11.2 available after 31 Jan 2018. If the Oracle 11 (or earlier) version is not in the list above or is not supported with a purchased extended support contract, this is a finding. Note: Sustaining Support does not include security updates. Any product in Sustaining Support is a finding. A patchset is an 'amended code set', consisting of a number of bug fixes, which is subjected to a rigorous QA and certification process. Oracle patch sets update the Oracle version number (e.g. 10.2.0.3 to 10.2.0.4) and are usually bundled together to support a product family (for example, Oracle DBMS includes Enterprise, Standard, Personal and Client Editions). The only supported patched version as of 08/28/2015 is 11.2.0.4. If the Oracle patchset level is less than 11.2.0.4, this is a finding. Note: a separate STIG exists for Oracle Database 11.2g.
Upgrade to a supported Oracle version. Purchase an Oracle Extended Support Contract where required. See http://www.oracle.com/technology/support/patches.htm for a definitive list of version patch sets for Oracle DBMS software. See http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf for Oracle support policies and timelines.
Oracle provides patches in service patchsets, Critical Patch Updates (CPU) as well as providing patch set exceptions for installed DBMS products. A patchset is an 'amended code set', consisting of a number of bug fixes, which is subjected to a rigorous QA and certification process. Oracle patch sets update the Oracle version number (e.g. 11.1.0.6 to 11.1.0.7) and are usually bundled together to support a product family (for example, Oracle DBMS includes Enterprise, Standard, Personal and Client Editions). This is covered in Check DG0001. Oracle security patches are published quarterly in January, April, July and October as Critical Patch Updates (CPU). CPUs may be viewed at: http://www.oracle.com/technology/deploy/security/alerts.htm Most Oracle CPU patches are also listed in DoD IAVM alerts. Patch set exceptions are fixes per a particular DBMS product based on reported bugs and do not undergo the rigorous QA and certification process that patchsets do. These are installed as needed to correct reported or observed bugs in Oracle DBMS products. This check applies to the application of the CPU patches only. You must comply with Check DG0001 prior to applying Oracle Critical Patch Updates. For Oracle Critical Patch Updates (CPU): 1. Go to the website http://www.oracle.com/technology/deploy/security/alerts.htm. 2. Click on the latest Critical Patch Update link. 3. Click on the [Database] link in the Supported Products and Components Affected section. 4. Enter your Oracle MetaLink credentials. 5. Locate the Critical Patch Update Availability table. 6. Identify your OS Platform and Oracle version to see if there is a CPU release. 7. If there is none, this check is Not a Finding. If there is one, note the patch number for the steps below. View the installed patch numbers for the database using the Oracle opatch utility. On UNIX systems: $ORACLE_HOME/OPatch/opatch lsinventory –detail | grep [PATCHNUM] On Windows systems (From Windows Command Prompt): %ORACLE_HOME%\OPatch\opatch lsinventory –detail | findstr [PATCHNUM] Replace [PATCHNUM] with the Patch number noted above. If the output shows the installed patch is present, this check is Not a Finding. No output indicates that the patch has not been applied and is a Finding.
Apply the most current Oracle Critical Patch update to the database software when available. Follow vendor-provided patch installation instructions.
Review host system privileges assigned to the Oracle DBA group and all individual Oracle DBA accounts. NOTE: do not include the Oracle software installation account in any results for this check. For UNIX systems (as root): cat /etc/group | grep -i dba groups root If "root" is returned in the first list, this is a Finding. If any accounts listed in the first list are also listed in the second list, this is a Finding. Investigate any user account group memberships other than DBA or root groups that are returned by the following command (also as root): groups [dba user account] Replace [dba user account] with the user account name of each DBA account. If individual DBA accounts are assigned to groups that grant access or privileges for purposes other than DBA responsibilities, this is a Finding. For Windows Systems (click or select): Start / Settings / Control Panel / Administrative Tools / Computer Management / Local Users and Groups / Groups / ORA_DBA Start / Settings / Control Panel / Administrative Tools / Computer Management / Local Users and Groups / Groups / ORA_[SID]_DBA (if present) NOTE: Users assigned DBA privileges on a Windows host are granted membership in the ORA_DBA and/or ORA_[SID]_DBA groups. The ORA_DBA group grants DBA privileges to any database on the system. The ORA_[SID]_DBA groups grant DBA privileges to specific Oracle instances only. Make a note of each user listed. For each user (click or select): Start / Settings / Control Panel / Administrative Tools / Computer Management / Local Users and Groups / Users / [DBA user name] / Member of If DBA users belong to any groups other than DBA groups and the Windows Users group, this is a Finding. Examine User Rights assigned to DBA groups or group members: Start / Settings / Control Panel / Administrative Tools / Local Security Policy / Security Settings / Local Policies / User Rights Assignments If any User Rights are assigned directly to the DBA group(s) or DBA user accounts, this is a Finding.
Revoke all host system privileges from the DBA group accounts and DBA user accounts not required for DBMS administration. Revoke all OS group memberships that assign excessive privileges to the DBA group accounts and DBA user accounts. Remove any directly applied permissions or user rights from the DBA group accounts and DBA user accounts. You should document all DBA group accounts and individual DBA account assigned privileges in the System Security Plan.
Review security and administration documentation maintained for the DBMS system for indications that security guidance has been applied to the DBMS system. If DoD security guidance is not available, the following are acceptable in descending order as available: (1) Commercially accepted practices (e.g., SANS); (2) Independent testing results (e.g., ICSA); or (3) Vendor literature If the DBMS system has not been secured using available security guidance as listed above, this is a Finding.
Apply available security guidance to the DBMS system. If DoD security guidance is not available, the following are acceptable in descending order as available: (1) Commercially accepted practices (e.g., SANS); (2) Independent testing results (e.g., ICSA); or (3) Vendor literature
If the database being reviewed is not a production database, this check is Not a Finding. Interview the auditor or IAO to determine if an automated tool or procedure is used to report audit trail data. If an automated tool or procedure is not used, this is a Finding.
Develop, document and implement database or host system procedures to report audit trail data in a form usable to detect unauthorized access to or usage of DBMS privileges, procedures or data. You may also want to consider procuring a third-party auditing tool like Oracle Audit Vault with support for Oracle and other DBMS products within your environment. NOTE: Audit data may contain sensitive information. The use of a single repository for audit data should be protected at the highest level based on the sensitivity of the databases being audited.
Review evidence or operation of an automated, continuous on-line monitoring and audit trail creation capability for the DBMS is deployed with the capability to immediately alert personnel of any unusual or inappropriate activity with potential IA implications, and with a user-configurable capability to automatically disable the system if serious IA violations are detected. If the requirements listed above are not fully met, this is a Finding.
Develop or procure, document and implement an automated, continuous on-line monitoring and audit trail creation capability for the DBMS is deployed with the capability to immediately alert personnel of any unusual or inappropriate activity with potential IA implications, and with a user-configurable capability to automatically disable the system if serious IA violations are detected.
If no data is identified as being sensitive or classified by the Information Owner, in the System Security Plan or in the AIS Functional Architecture documentation, this check is Not a Finding. If no identified sensitive or classified data requires encryption by the Information Owner in the System Security Plan and/or AIS Functional Architecture documentation, this check is Not a Finding. If encryption requirements are listed and specify configuration at the host system or network device level, then review evidence that the configuration meets the specification. It may be necessary to review network device configuration evidence or host communications configuration evidence. If the evidence review does not meet the requirement or specification as listed in the System Security Plan, this is a Finding.
Configure encryption of sensitive data served by the DBMS in accordance with the specifications provided in the System Security Plan and AIS Functional Architecture documentation. Document acceptance of risk by the Information Owner where sensitive or classified data is not encrypted. Have the IAO document assurance that the unencrypted sensitive or classified information is otherwise inaccessible to those who do not have Need-to-Know access to the data.
Review definitions and access restrictions to objects stored outside of DBMS control. View object application data types defined in the database, but stored outside of the DBMS. View data objects that include host file and directory references in their definitions. If any external objects exist that are not referenced and authorized in the System Security Plan, this is a Finding.
Evaluate the associated risk in allowing access to external objects. Consider the security context under which the object is accessed or whether the privileges required to access the object are available for assignment based on job function. Where feasible, modify the application to use only objects stored internally to the database. Where not feasible, note the risk assessment and acceptance in the System Security Plan for access to external objects.
Review documented procedures and implementation evidence of DBA role privilege monitoring. If procedures are not documented or noted in the System Security Plan or are not complete, this is a Finding. If evidence of implementation for monitoring does not exist, this is a Finding. If monitoring does not occur monthly (~30 days) or more often, this is a Finding.
Design, document and implement procedures for monitoring DBA role privilege assignments. Grant the DBA role the minimum privileges required to perform administrative functions. Establish monitoring of DBA role privileges monthly or more often.
Review DBMS accounts with elevated permissions (accounts granted ROLE permissions, DBA accounts, SCHEMA accounts, etc.). If any accounts are not documented and authorized for RESTORE permissions, this is a Finding.
Utilize DBMS roles that are authorized for database restore functions. Restrict assignment of restore privileges. Assign DBMS restoration roles only to authorized DBMS accounts. Document assignments in the System Security Plan.
If the DBMS or DBMS host is not shared by production and development activities, this check is Not a Finding. Review policy and procedures documented or noted in the System Security Plan and evidence of monitoring of developer privileges on shared development and production DBMS and DBMS host systems. If developer privileges are not monitored every three months or more frequently, this is a Finding. NOTE: Though shared production/non-production DBMS installations was allowed under previous database STIG guidance, doing so may place it in violation of OS, Application, Network or Enclave STIG guidance. Ensure that any shared production/non-production DBMS installations meets STIG guidance requirements at all levels or mitigate any conflicts in STIG guidance with your DAA.
Develop, document and implement procedures to monitor DBMS and DBMS host privileges assigned to developers on shared production and development systems to detect unauthorized assignments every three months or more often. Recommend establishing a dedicated DBMS host for production DBMS installations (See Checks DG0109 and DG0110). A dedicated host system in this case refers to an instance of the operating system at a minimum. The operating system may reside on a virtual host machine where supported by the DBMS vendor.
If the DBMS or DBMS host is not shared by production and development activities, this check is Not a Finding. Review OS DBA group membership. If any developer accounts as identified in the System Security Plan have been assigned DBA privileges, this is a Finding. NOTE: Though shared production/non-production DBMS installations was allowed under previous database STIG guidance, doing so may place it in violation of OS, Application, Network or Enclave STIG guidance. Ensure that any shared production/non-production DBMS installations meets STIG guidance requirements at all levels or mitigate any conflicts in STIG guidance with your DAA.
Create separate DBMS host OS groups for developer and production DBAs. Do not assign production DBA OS group membership to accounts used for development. Remove development accounts from production DBA OS group membership. Recommend establishing a dedicated DBMS host for production DBMS installations (See Checks DG0109 and DG0110). A dedicated host system in this case refers to an instance of the operating system at a minimum. The operating system may reside on a virtual host machine where supported by the DBMS vendor.
Review documented and implemented procedures for monitoring the use of the DBMS software installation account in the System Security Plan. If use of this account is not monitored or procedures for monitoring its use do not exist or are incomplete, this is a Finding. NOTE: 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.
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. Host 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. Ensure all accounts with administrator privileges are monitored for DBMS host on Windows OS platforms.
Review the DBMS account usage log for use of the Oracle DBMS software installation account. Interview personnel authorized to access the DBMS software installation account to ask how the account is used. If any usage of the account is to support daily operations or general DBA responsibilities, this is a Finding. NOTE: 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. Except where a change in ownership is made to files/directories during a software update, any check results are not a Finding.
Develop, document, implement procedures, and train authorized users to restrict usage of the DBMS software installation account for DBMS software installation, upgrade and maintenance only where applicable. For Windows systems, reapplication of the fix for Check DG0019 may be necessary to reestablish correct file/directory ownership.
Review procedures and evidence of implementation for DBMS IA and vulnerability management compliance. This should include periodic, unannounced, in-depth monitoring and provide for specific penetration testing to ensure compliance with all vulnerability mitigation procedures such as the DoD IAVA or other DoD IA practices is planned, scheduled and conducted. Testing is intended to ensure that the system's IA capabilities continue to provide adequate assurance against constantly evolving threats and vulnerabilities. The results for Classified systems are required to be independently validated. If the requirments listed above are not being met, this is a Finding.
Develop, document and implement procedures for periodic testing of the DBMS for current vulnerability management and security configuration compliance as stated in the check. Coordinate 3rd-party validation testing for Classified systems.
If the DBMS host being reviewed is not a production DBMS host, this check is Not a Finding. Review evidence of security hardening and auditing of the DBMS host platform with the IAO. If the DBMS host platform has not been hardened and received a security audit, this is a Finding. Review evidence of security hardening and auditing for all application(s) that store data in the database and all other separately configured components that access the database including web servers, application servers, report servers, etc. If any have not been hardened and received a security audit, this is a Finding. Review evidence of security hardening and auditing for all application(s) installed on the local DBMS host where security hardening and auditing guidance exists. If any have not been hardened and received a security audit, this is a Finding.
Configure all related application components and the DBMS host platform in accordance with the applicable DoD STIG. Regularly audit the security configuration of related applications and the host platform to confirm continued compliance with security requirements.
Oracle audit events are logged to error logs, trace files, host system logs and may be stored in database tables. For each Oracle database on the host, determine the location of the database audit trail. From SQL*Plus: select value from v$parameter where name = 'audit_trail'; If the audit trail is directed to database tables (DB*), ensure the audit table data is included in the database backups. Backups of host system log files are covered in host system security reviews and are not covered here. Other Oracle log files include: - Listener trace file (specified in the listener.ora file) - SQLNet trace file (specified in the sqlnet.ora file) - Oracle database alert and trace files (specified in Oracle parameters): -- audit_file_dest -- db_recovery_file_dest -- diagnostic_dest – 11.1 and higher -- log_archive_dest -- log_archive_dest_n If evidence of inclusion of all audit log files in regular DBMS or host backups does not exist, this is a Finding.
Document and implement locations of trace, log and alert locations in the System Security Plan. Include all trace, log and alert files in regular backups.
If remote administrative access to the database is prohibited and is disabled (See Check DG0093), this check is Not a Finding. Review policy, procedure and evidence of implementation for monitoring of remote administrative access to the database. If monitoring procedures for remote administrative access are not documented or implemented, this is a Finding.
Develop, document and implement policy and procedures to monitor remote administrative access to the DBMS. The automated generation of a log report with automatic dissemination to the IAO/IAM may be used. Require and store an acknowledgement of receipt and confirmation of review for the log report.
Review documented backup and restoration procedures to determine ownership and access during all phases of backup and recovery. Review file protections assigned to online backup and restoration files and tools. Review access, physical security protections and documented procedures for offline backup and restoration files and tools. If implementation evidence indicates that backup or restoration files are subject to corruption, unauthorized access or physical loss, this is a Finding.
Develop, document and implement protection for backup and restoration files. Document personnel and the level of access authorized for each to backup and restoration files and tools. In addition to physical and host system protections, consider other methods including password protection of the files.
Review evidence of Oracle database and dependent application files and directories. For UNIX Systems: These files are found in the directories $ORACLE_BASE and $ORACLE_HOME. For Windows Systems: The Oracle software directory is specified on a Windows host in the registry value HKLM\SOFTWARE\Oracle\KEY_[ORACLE_HOME_NAME]\ORACLE_HOME. Other Oracle software including, but not limited to Oracle tools and utilities, are usually found on Windows platforms in the C:\Program Files\Oracle directory and subdirectories. Third-party applications may be located in other directory structures. Review the System Security Plan for a list of all DBMS application software libraries to be included in software library backups. If any software library files are not included in regular backups, this is a Finding.
Configure backups to include all ORACLE home directories and subdirectories and any other Oracle application and third-party database application software libraries.
Review the System Security Plan to determine if the DBMS serves data to users or applications outside the local enclave. If the DBMS is not accessed outside of the local enclave, this check is Not a Finding. If the DBMS serves applications available from a public network (e.g. the Internet), then confirm that the application servers are located in a DMZ. If the DBMS is located inside the local enclave and is directly accessible to public users, this is a Finding. If the DBMS serves public-facing applications and is not protected from direct client connections and unauthorized networks, this is a Finding. If the DBMS serves public-facing applications and contains sensitive or classified information, this is a Finding.
Do not allow direct connections from users originating from the Internet or other public network to the DBMS. Include in the System Security Plan for the system whether the DBMS serves public-facing applications or applications serving users from other untrusted networks. Do not store sensitive or classified data on a DBMS server that serves public-facing applications.
Review the database backup procedures and implementation evidence. Evidence of implementation includes records of backup events and physical review of backup media. Evidence should match the backup plan as recorded in the System Security Plan. If backup procedures do not exist or not implemented in accordance with the procedures, this is a Finding. If backups are not performed weekly or more often, this is a Finding.
Develop, document and implement database backup procedures. Include weekly backup procedures and offline backup data storage.
Review policy and procedures documented or noted in the System Security Plan as well as evidence of implementation for monitoring changes to DBA role assignments and procedures for notifying the IAM of the changes for review. If policy, procedures or implementation evidence do not exist, this is a Finding.
Develop, document and implement procedures to monitor changes to DBA role assignments. Develop, document and implement procedures to notify the IAM of changes to DBA role assignments. Include in the procedures methods that provide evidence of monitoring and notification.
Review documented backup testing and recovery verification procedures noted or documented in the System Security Plan. Review evidence of implementation of testing and verification procedures by reviewing logs from backup and recovery implementation. Logs may be in electronic or hardcopy and may include email or other notification. If backup testing and recovery verification are not documented or noted in the System Security Plan, this is a Finding. If evidence of backup testing and recovery verification does not exist, this is a Finding.
Design, document and implement backup testing and recovery verification procedures for the DBMS host and all individual database instances and either include or note the name, location, version and current revision date of any external documentation in the System Security Plan. Include any requirements for documenting database backup and recovery testing and verification activities in the procedures.
If no data is identified as being sensitive or classified by the Information Owner, in the System Security Plan or in the AIS Functional Architecture documentation, this check is Not a Finding. If no identified sensitive or classified data requires encryption by the Information Owner in the System Security Plan and/or AIS Functional Architecture documentation, this check is Not a Finding. Review sensitive data stored in the database as identified in the System Security Plan using select statements. Note in the System Security Plan if the data is encrypted by column or by transparent encryption. Transparent data encryption is available only in Oracle versions 10.2 and later using Oracle Advanced Security. If transparent data encryption is specified, then verify it is enabled. By data columns: From SQL*Plus: select owner, table_name, column_name from dba_encrypted_columns; By tablespace: From SQL*Plus: select tablespace_name from dba_tablespaces where encrypted='YES'; If columns within tables, tables and/or tablespaces listed in the System Security Plan are required to be encrypted transparently are not listed above, this is a Finding. If the DBMS products are used to encrypt data, view the sensitive data fields required to be encrypted using select statements. If any data is displayed in human-readable format, this is a Finding. If encryption is required by the information owner, NIST-certified cryptography is used to encrypt stored sensitive information. If encryption is required by the information owner, NIST-certified cryptography is used to encrypt stored classified non-sources and methods intelligence information. If a classified enclave contains sources and methods intelligence data and is accessed by individuals lacking an appropriate clearance for sources and methods intelligence, then NSA-approved cryptography is used to encrypt all sources and methods intelligence stored within the enclave. NOTE: This check result may be marked not a Finding and the requirement of encryption in the database waived where the database has only database administrative accounts and application accounts that have a need-to-know to the data. This waiver does not preclude any requirement for encryption of the associated database data file (see DG0092).
Identify all sensitive data and the method to be used to encrypt specified sensitive data in the System Security Plan. Use only NIST-certified or NSA-approved cryptography to provide encryption. Oracle transparent data encryption (available in Oracle version 10.2 and later) requires Oracle Advanced Security. See the chapter on Transparent Data Encryption in the Oracle Database Advanced Security Guide Administrator's Guide for details on using and configuring transparent data encryption. Document acceptance of risk by the Information Owner where sensitive or classified data is not encrypted. Have the Information Owner document assurance that the unencrypted sensitive or classified information is otherwise inaccessible to those without need-to-know access to the data. Developers should consider using a record-specific encryption method to protect individual records. For example, by employing the session username or other individualized element as part of the encryption key, then decryption of a data element is only possible by that user or other data accessible only by that user. Consider applying additional auditing of access to any unencrypted sensitive or classified data when accessed by unauthorized users (without need-to-know).
Review the System Security Plan and/or the AIS Functional Architecture documentation to discover sensitive or classified data identified by the Information Owner that requires encryption. If no sensitive or classified data is identified as requiring encryption by the Information Owner, this check is Not a Finding. Have the DBA use select statements in the database to review sensitive data stored in tables as identified in the System Security Plan and/or AIS Functional Architecture documentation. If all sensitive data as identified is encrypted within the database objects, encryption of the DBMS data files is optional and Not a Finding. If all sensitive data is not encrypted within database objects, review encryption applied to the DBMS host data files. If no encryption is applied, this is a Finding. If encryption is required by the information owner, NIST-certified cryptography is used to encrypt stored sensitive information. If encryption is required by the information owner, NIST-certified cryptography is used to encrypt stored classified non-sources and methods intelligence information. If a classified enclave contains sources and methods intelligence data and is accessed by individuals lacking an appropriate clearance for sources and methods intelligence, then NSA-approved cryptography is used to encrypt all sources and methods intelligence stored within the enclave. Determine which DBMS data files contain sensitive data. Not all DBMS data files will require encryption.
Use third-party tools or native DBMS features to encrypt sensitive or classified data stored in the database. Use only NIST-certified or NSA-approved cryptography to provide encryption. Document acceptance of risk by the Information Owner where sensitive or classified data is not encrypted. Have the IAO document assurance that the unencrypted sensitive or classified information is otherwise inaccessible to those who do not have Need-to-Know access to the data. To lessen the impact on system performance, separate sensitive data where file encryption is required into dedicated DBMS data files. Consider applying additional auditing of access to any unencrypted sensitive or classified data when accessed by users (with and/or without Need-to-Know).
Review documented policy and procedures included or noted in the System Security Plan as well as evidence of implementation for annual reviews of DBMS IA policy and procedures. If policy and procedures do not exist, are incomplete, or are not implemented and followed annually or more frequently, this is a Finding.
Develop, document and implement procedures to review DBMS IA policies and procedures.
Review policy and procedures documented or noted in the System Security Plan and evidence of implementation for testing DBMS installations, upgrades and patches prior to production deployment. If policy and procedures do not exist or evidence of implementation does not exist, this is a Finding.
Develop, document and implement procedures for testing DBMS installations, upgrades and patches prior to deployment on production systems.
If the database being reviewed is not a production database or does not contain sensitive data, this check is Not a Finding. Review documented policy, procedures and proof of implementation for restrictions placed on data exports from the production database. Policy and procedures should include that only authorized users have access to DBMS export utilities and that export data is properly sanitized prior to import to a development database. Policy and procedures may also include that developers be granted the necessary clearance and need-to-know prior to import of production data. If documented policy, procedures and proof of implementation are not present or complete, this is a Finding. If methods to sanitize sensitive data are required and not documented or followed, this is a Finding.
Develop, document and implement policy and procedures that provide restrictions for production data export. Require users and administrators assigned privileges that allow the export of production data from a production database to acknowledge understanding of export restrictions. Restrict permissions allowing use or access to database export procedures or functions to authorized users. Ensure sensitive data from production is sanitized prior to import to a development database (See check DG0076). Grant access and need-to-know to developers where allowed by policy.
Review the System Security Plan and note sensitive data identified by the Information Owner as requiring encryption using DBMS features administered by the DBA. If no sensitive data is present or encryption of sensitive data is not required by the Information Owner, this check is Not a Finding. Review the encryption configuration against the System Security Plan specification. If the specified encryption is not configured, this is a Finding.
Configure DBMS encryption features and functions as required by the System Security Plan. Discrepancies between what features are and are not available should be resolved with the Information Owner, Application Developer and DBA as overseen by the IAO.
If no sensitive or classified data is stored in the database, listed in the System Security Plan and listed in the AIS Functional Architecture documentation, this check is Not a Finding. Review AIS Functional Architecture documentation for the DBMS and note any sensitive data that is identified. Review database table column data or descriptions that indicate sensitive data. For example, a data column labeled "SSN" could indicate social security numbers are stored in the column. Question the IAO or DBA where any questions arise. General categories of sensitive data requiring identification include any personal data (health, financial, social security number and date of birth), proprietary or financially sensitive business data or data that might be classified. If any data is considered sensitive and is not documented in the AISFA, this is a Finding.
Include identification of any sensitive data in the AIS Functional Architecture and the System Security Plan. Include data that appear to be sensitive with a discussion as to why it is not marked as such.
Review the System Security Plan to discover the restoration priority assigned to the DBMS. If a restoration priority is not assigned, this is a Finding.
Review the mission criticality of the DBMS in relation to the overall mission of the organization and assign it a restoration priority.
Review a list of Windows service or UNIX processes running on the DBMS host. For Windows, review the Services snap-in. Investigate with the DBA/SA any unknown services. For UNIX, issue the ps -ef command. Investigate with the DBA/SA any unknown processes. If web, application, ftp, domain, print or other non-DBMS services or processes are identified as supporting other optional applications or functions not authorized in the System Security Plan, this is a Finding. NOTE: Only applications that are technically required to share the same host system may be authorized to do so. Applications that share the same host for administrative, financial or other non-technical reasons may not be authorized and are a Finding.
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. Remove any unauthorized processes or services and install on a separate host system. Where separation is not supported, update the System Security Plan to provide the technical requirement for having the application share a host with the DBMS.
If Oracle Listener, JAVA Listener, Oracle Names and Connection Manager are not running on the local database host server, this check is Not a Finding. Review the listener.ora file located by default in the ORACLE_HOME\network\admin directory or in the directory specified in the environment variable TNS_ADMIN defined for the listener process or service. View the "PORT=" parameter for any protocols defined. If any do not match an entry in the following list, then confirm that it is not a default or registered port for the service. View the cman.ora file in the ORACLE_HOME/network/admin directory. If the file does not exist, the database is not accessed via Oracle Connection Manager and this part of the check is Not a Finding. View the "PORT=" parameter for any protocols defined. If any do not match an entry in the following list, then confirm that it is not a default or registered port for the service. If any non-default or non-registered ports are listed, this is a Finding. Default Oracle Listener Ports: 1521, 2483, 2484 Default Java Listener Ports: 2481, 2482 Default Oracle Names Listener Port: 1575 Default Connection Manager Ports: 1521, 1830 Registered ports MAY be listed at http://www.iana.org/assignments/port-numbers or in the DoD Ports, Protocols, and Services Category Assurance List (CAL).
Specify a default or registered port for TCP/IP protocols in the listener.ora and cman.ora files in the PORT= parameter of the address specification.
Review the System Security Plan for the DBMS. Review coverage of the following in the System Security Plan: - Technical, administrative and procedural IA program and policies that govern the DBMS - Identification of all IA personnel (IAM, IAO, DBA, SA) assigned responsibility to the DBMS - Specific IA requirements and objectives (e.g., requirements for data handling or dissemination (to include identification of sensitive data stored in the database, database application user job functions/roles and privileges), system redundancy and backup, or emergency response) If a System Security Plan does not exist or does not identify or reference all relevant security controls, this is a Finding.
Develop, document and implement a System Security Plan for the DBMS. Include IA documentation related to the DBMS in the System Security Plan for the system that the DBMS supports. Review section 3.4 - System Security Plan Overview in the ORACLE DATABASE SECURITY CHECKLIST for more information.
Review the services and processes active on the DBMS host system. If the host system is a Windows domain controller, this is a Finding. If the host system is supporting any other security or directory services that do not use the DBMS to store information, this is a Finding. NOTE: This does not include client security applications like firewall and antivirus software.
Either move the DBMS installation to a dedicated host system or move the directory or security services to another host system. 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.
For UNIX Systems: Log in using the Oracle software owner account and enter the command: umask If the value returned is 022 or more restrictive, this is not a Finding. If the value returned is less restrictive than 022, this is a Finding. The 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: 0 = read/write/execute 1 = read/write 2 = read/execute 3 = read 4 = write/execute 5 = write 6 = execute 7 = no permissions Setting 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. For Windows Systems: Review the permissions that control access to the Oracle installation software directories (e.g. \Program Files\Oracle\). DBA 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. Compare the access control employed with that documented in the System Security Plan. If access controls do not match the documented requirement, this is a Finding. If access controls appear excessive without justification, this is a Finding.
For UNIX Systems: Set the umask of the Oracle software owner account to 022. Determine the shell being used for the Oracle software owner account: env | grep -i shell Startup files for each shell are as follows (located in users $HOME directory): C-Shell (CSH) = .cshrc Bourne Shell (SH) = .profile Korn Shell (KSH) = .kshrc TC Shell (TCS) = .tcshrc BASH Shell = .bash_profile or .bashrc Edit the shell startup file for the account and add or modify the line: umask 022 Log off and login, then enter the umask command to confirm the setting. NOTE: To effect this change for all Oracle processes, a reboot of the DBMS server may be required. For Windows Systems: Product-specific fix pending development. Use Generic Fix listed below: Restrict access to the DBMS software libraries to the fewest accounts that clearly require access based on job function. Document authorized access control and justify any access grants that do not fall under DBA, DBMS process, ownership, or SA accounts.
If application access audit data is not available due to the lack of a local listener process or alternate method of auditing database access, this check is Not a Finding (see check DG0052). Review the list of applications authorized to connect to the Oracle database as listed or noted in the System Security Plan. If no list exists, this is a Finding. Review evidence of audit log monitoring to detect use of unauthorized applications to access the database. If no evidence exists or is incomplete, this is a Finding.
Document applications authorized to access the DBMS in the System Security Plan. Develop, document and implement a process to review log and trace files or the results from any alternate methods used to support database access auditing to detect connections from unauthorized applications. Include in this process a method to generate and provide evidence of monitoring. This may include automated or manual processes acknowledged by the auditor or IAO.
Review the System Security Plan to determine if the use of the external procedure agent is authorized. Review the ORACLE_HOME/bin directory or search the ORACLE_BASE path for the executable extproc (UNIX) or extproc.exe (Windows). If external procedure agent is not authorized for use in the System Security Plan and the executable file exists and is not restricted, this is a Finding. If use of the external procedure agent is authorized, ensure extproc is restricted to execution of authorized applications. External jobs are run using the account nobody by default. Review the contents of the file ORACLE_HOME/rdbms/admin/externaljob.ora for the lines run_user= and run_group=. If the user assigned to these parameters is not "nobody", this is a Finding. For versions 11.1 and later, the external procedure agent (extproc executable) is available directly from the database and does not require definition in the listener.ora file for use. Review the contents of the file ORACLE_HOME/hs/admin/extproc.ora. If the file does not exist, this is a Finding. If the following entry does not appear in the file, this is a Finding: EXTPROC_DLLS=ONLY:[dll full file name1]:[dll full file name2]:.. [dll full file name] represents a full path and file name. This list of file names is separated by ":". NOTE: If "ONLY" is specified, then the list is restricted to allow execution of only the DLLs specified in the list and is not a Finding. If "ANY" is specified, then there are no restrictions for execution except what is controlled by operating system permissions and is a Finding. If no specification is made, any files located in the %ORACLE_HOME%\bin directory on Windows systems or $ORACLE_HOME/lib directory on UNIX systems can be executed (the default) and is a Finding. Ensure that EXTPROC is not accessible from the listener. Review the listener.ora file. If any entries reference "extproc", this is a Finding. NOTE: Bug 7560049 may cause external procedures in 11g not to work on certain platforms. Fix will be in Oracle 11g Release 2. If external procedures are required and you are experiencing this bug, then follow instructions for configuring external procedures for versions earlier than 11.1 and document as authorized in the System Security Plan. Determine if the external procedure agent is in use per Oracle 10.x conventions. Review the listener.ora file. If any entries reference "extproc", then the agent is in use. If external procedure agent is not authorized for use in the System Security Plan and references to "extproc" exist, this is a Finding. Sample listener.ora entries with extproc included: LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521)) ) EXTLSNR = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC)) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = ORCL) (ORACLE_HOME = /home/oracle/app/oracle/product/11.1.0/db_1) (SID_NAME = ORCL) ) ) SID_LIST_EXTLSNR = (SID_LIST = (SID_DESC = (PROGRAM = extproc) (SID_NAME = PLSExtProc) (ORACLE_HOME = /home/oracle/app/oracle/product/11.1.0/db_1) (ENVS="EXTPROC_DLLS=ONLY:/home/app1/app1lib.so:/home/app2/app2lib.so, LD_LIBRARY_PATH=/private/app2/lib:/private/app1, MYPATH=/usr/fso:/usr/local/packages") ) ) Sample tnsnames.ora entries with extproc included: ORCL = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = ORCL) ) ) EXTPROC_CONNECTION_DATA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = extproc)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = PLSExtProc) ) ) If EXTPROC is in use, confirm that a listener is dedicated to serving the external procedure agent (as shown above). View the protocols configured for the listener. For the listener to be dedicated, the only entries will be to specify extproc. If there is not a dedicated listener in use for the external procedure agent, this is a Finding. If the PROTOCOL= specified is other than IPC, this is a Finding. Verify and ensure extproc is restricted executing authorized external applications only and extproc is restricted to execution of authorized applications. Review the listener.ora file. If the following entry does not exist, this is a Finding: EXTPROC_DLLS=ONLY:[dll full file name1]:[dll full file name2]:... NOTE: [dll full file name] represents a full path and file name. This list of file names is separated by ":". NOTE: If "ONLY" is specified, then the list is restricted to allow execution of only the DLLs specified in the list and is not a Finding. If "ANY" is specified, then there are no restrictions for execution except what is controlled by operating system permissions and is a Finding. If no specification is made, any files located in the %ORACLE_HOME%\bin directory on Windows systems or $ORACLE_HOME/lib directory on UNIX systems can be executed (the default) and is a Finding. View the listener.ora file (usually in ORACLE_HOME/network/admin or directory specified by the TNS_ADMIN environment variable). If multiple listener processes are running, then the listener.ora file for each must be viewed. For each process, determine the directory specified in the ORACLE_HOME or TNS_ADMIN environment variable defined for the process account to locate the listener.ora file.
If the use of external procedure agent is required, then authorize and document the requirement in the System Security Plan. If the external procedure agent must be accessible to the Oracle listener, then specify this and authorize it in the System Security Plan. If use of the Oracle External Procedure agent is not required: - Stop the Oracle Listener process - Remove all references to extproc in the listener.ora and tnsnames.ora files - Alter the permissions on the executable files: UNIX - Remove read/write/execute permissions from owner, group and world Windows - Remove Groups/Users from the executable (except groups SYSTEM and ADMINISTRATORS) and allow READ [only] for SYSTEM and ADMINISTRATORS groups If required: - Restrict extproc execution to only authorized applications. - Specify EXTPROC_DLLS=ONLY: [list of authorized DLLS] in the extproc.ora and the listener.ora files - Create a separate, dedicated listener for use by the external procedure agent Please see the Oracle Net Services Administrators Guides, External Procedures section for detailed configuration information.
Determine which OS accounts external DBMS executables are run. Review the privileges assigned to these accounts and compare them to the System Security Plan and the function of the applications. If assigned privileges exceed those necessary to operate as designed or the privileges do not match the list of required privileges for the application in the System Security Plan, this is a Finding.
Configure OS accounts used by DBMS external procedures to have the minimum privileges necessary for operation. Document DBMS external procedures and OS privileges need to execute the procedures in the System Security Plan.
IP address restriction may be defined for the database listener, by use of the Oracle Connection Manager or by an external network device. Identify the method used to enforce address restriction (interview or System Security Plan review). If enforced by the database listener, then review the SQLNET.ORA file located in the ORACLE_HOME/network/admin directory or the directory indicated by the TNS_ADMIN environment variable or registry setting. If the following entries do not exist, then restriction by IP address is not configured and is a Finding. tcp.validnode_checking=YES tcp.invited_nodes=(IP1, IP2, IP3) If 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). If a RULE entry allows all addresses ("/32") or does not match the address range specified in the System Security Plan, this is a Finding. (rule=(src=[IP]/27)(dst=[IP])(srv=*)(act=accept)) NOTE: 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. If this rule is database-specific, then determine if the SERVICE_NAME parameter is set: From SQL*PLUS: select value from v$parameter where name = 'service_names'; If SERVICE_NAME is set in the initialization file for the database instance, use (srv=[service name]), else, use (srv=*) if not set or rule applies to all databases on the DBMS server. If 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.
Configure the database listener to restrict access by IP address or set up an external device to restrict network access to the DBMS.
Review the Oracle instance names on the DBMS host: On UNIX platforms: Solaris: cat /var/opt/oracle/oratab Other UNIX: cat /etc/oratab The format of lines in the oratab file is: sid:oracle_home_directory:Y or N The instance name is the sid. On Windows platforms: Go to Start / Administrative Tools / Services View service names that begin with "OracleService". The remainder of the service name is the instance name. Example: OracleServicesalesDB -- where salesDB is the instance name If instance names are listed and do not clearly identify the use of the instance or clearly differentiate individual instances, this is a Finding. An example of instance naming that meets the requirement: prdinv01 (Production Inventory Database #1), dvsales02 (Development Sales Database #2), orfindb1 (Oracle Financials Database #1). Examples of instance naming that do not meet the requirement: Instance1, MyInstance, orcl, 10gdb1 Interview the DBA to get an understanding of the naming scheme used to determine if the names are clear differentiations.
Follow the instructions in Oracle Doc ID: 15390.1 to change the SID without re-creating the database. Set the value so that it does not identify the Oracle version and clearly identifies its purpose.
Review DBMS recovery procedures or technical system features to determine if mechanisms exist and are in place to specify use of trusted files during DBMS recovery. If recovery procedures do not exist or are not sufficient to ensure recovery is done in a secure and verifiable manner, this is a Finding. If system features exist and are not employed or not employed sufficiently, this is a Finding. If circumstances that can inhibit a trusted recovery are not documented and appropriate mitigating procedures have not been put in place, this is a Finding.
Develop, document and implement DBMS recovery procedures and employ technical system features where supported by the DBMS to specify trusted files during DBMS recovery. Ensure circumstances that can inhibit a trusted recovery are documented and appropriate mitigating procedures have been put in place.
Oracle natively encrypts passwords in transit when using Oracle connection protocols and products (i.e. Oracle Client). Where other connection products and protocols are used, review configuration options for encrypting passwords during login events across the network. If passwords are not encrypted, this is a Finding. Where only Oracle connection protocols and products are used and password encryption is not purposely disabled and enabled where applicable, this is Not a Finding. If determined that passwords are passed unencrypted at any point along the transmission path between the source and destination, this is a Finding.
Utilize Oracle connection protocols and products (i.e. Oracle Client) where possible. Where other connection products and protocols are used, ensure configuration options for encrypting passwords during login events across the network are used. If the database does not provide encryption for login events natively, employ encryption at the OS or network level. Ensure passwords remain encrypted from source to destination.
Determine the locations of DBMS audit, configuration, credential and other security data. Review audit settings for these files or data objects. If access to the security data is not audited, this is a Finding. If no access is audited, consider the operational impact and appropriateness for access that is not audited. If the risk for incomplete auditing of the security files is reasonable and documented in the System Security Plan, then do not include this as a Finding.
Determine all locations for storage of DBMS security and configuration data. Enable auditing for access to any security data. If auditing results in an unacceptable adverse impact on application operation, reduce the amount of auditing to a reasonable and acceptable level. Document any incomplete audit with acceptance of the risk of incomplete audit in the System Security Plan.
Ask the DBA and/or IAO to demonstrate that the DBMS system initialization, shutdown, and aborts are configured to ensure that the DBMS system remains in a secure state. If the DBA and/or IAO has documented proof from the DBMS vendor demonstrating that the DBMS does not support this either natively or programmatically, this check is a Finding, but can be downgraded to a CAT 3 severity. If the DBMS does support this either natively or programmatically and the configuration does not meet the requirements listed above, this is a Finding. For all MAC 1, all MAC 2 and Classified MAC 3 systems where the DBMS supports the requirements, review documented procedures and evidence of periodic testing to ensure DBMS system state integrity. If documented procedures do not exist or no evidence of implementation is provided, this is a Finding.
Configure DBMS system initialization, shutdown and aborts to ensure DBMS system remains in a secure state. For applicable DBMS systems as listed in the check, periodically test configuration to ensure DBMS system state integrity. Where DBMS system state integrity is not supported by the DBMS vendor, obtain and apply mitigation strategies to bring risk to a DAA-acceptable level.
Review the System Security Plan for authorization, assignments and usage procedures for remote DBMS administration. If remote administration of the DBMS is not documented or poorly documented, this is a Finding. If remote administration of the DBMS is not authorized and not disabled, this is a Finding.
Disable remote administration of the DBMS where not required. Where remote administration of the DBMS is required, develop, document and implement policy and procedures on its use. Assign remote administration privileges to IAO-authorized personnel only. Document assignments in the System Security Plan.
Review settings for actions taken during remote administration sessions. If auditing of remote administration sessions and actions is not enabled, this is a Finding. If audit logs do not include all actions taken by database administrators during remote sessions, this is a Finding. Actions should be tied to a specific user.
Develop, document and implement policy and procedures for remote administration auditing. Configure the DBMS to provide an audit trail for remote administrative sessions. Include all actions taken by database administrators during remote sessions. Actions should be tied to a specific user.
Review database links or other connections defined for the database to access or be accessed by remote databases or other applications as defined in the AIS Functional Architecture documentation or the System Security Plan. If any interconnections show differences in the DBMS and remote system classification levels, this is a Finding.
Disassociate or remove connection definitions to remote systems of differing classification levels.
Review the System Security Plan to discover any external storage of passwords used by applications, batch jobs or users to connect to the database. If no database passwords or credentials are stored outside of the database including use of Oracle Wallets and the Oracle password file (pwd*.ora or orapwd*.ora), this check is Not a Finding. View the sqlnet.ora file to determine if Oracle Wallets are used for authentication. If the "WALLET_LOCATION" entry exists in the file, then view permissions on the directory and contents. If access to this directory and these files is not restricted to the Oracle database and listener services, DBA's, and other authorized system and administrative accounts this is a Finding. From SQL*Plus: select value from v$parameter where name = 'remote_login_passwordfile'; If the command returns the value NONE, this is not a Finding. If it returns the value SHARED, this is a Finding. If it returns the value EXCLUSIVE, view access permissions to the Oracle password file. The default name for Windows is pwd[SID].ora and is located in the ORACLE_HOME\database directory. On UNIX hosts, the file is named orapw[SID] and stored in the $ORACLE_HOME/dbs directory. If access to this file is not restricted to the Oracle database, DBA's, and other authorized system and administrative accounts, this is a Finding. For other password or credential stores, interview the DBA to ask what restrictions to the storage location of passwords have been assigned. If accounts other than those that require access to the storage location have been granted permissions, this is a Finding.
Consider alternate methods for database connections to avoid custom storage of local connection credentials. Develop and document use of locally stored credentials and their authorized use and access in the System Security Plan. Restrict access and use of the credentials to authorized users using host file permissions and any other available method to restrict access.
Ask the DBA if the DBMS is accessed remotely for administration purposes. If it is not, this check is Not a Finding. Check DG0093 specifies remote administration encryption for confidentiality. This check should confirm the use of dedicated and encrypted network addresses and ports. Review configured network access interfaces for remote DBMS administration. These may be host-based encryptions such as IPSec or may be configured for the DBMS as part of the network communications and/or in the DBMS listening process. For DBMS listeners, verify that encrypted ports exist and are restricted to specific network addresses to access the DBMS. View the System Security Plan to review the authorized procedures and access for remote administration. If the configuration does not match the specifications in the System Security Plan, this is a Finding. Note: Out-Of-Band (OOB) is allowed for remote administration, however, OOB alone does not maintain encryption of network traffic from source to destination and is a Finding for this check.
Disable remote administration where it is not required. Consider restricting administrative access to local connections only. Where necessary, configure the DBMS network communications to provide an encrypted, dedicated port for remote administration access. Develop and provide procedures for remote administrative access to DBAs that have been authorized for remote administration. Verify during audit reviews that DBAs do not access the database remotely except through the dedicated and encrypted port.
If a listener is not running on the local database host server, this check is Not a Finding. Review all listener.ora files for the HOST =. Verify the HOST = value specifies an IP address for all occurrences of the HOST = setting. Sample: (ADDRESS= (PROTOCOL=TCP) (HOST= [host IP address]) (PORT=1521)) If any addresses specify a host name in place of an IP or other network address, this is a Finding. NOTE: If a host name is used, ensure it can be locally resolved to an IP address on the DBMS system using a host table, however, if a hostname is used, it is still a Finding.
Edit the listener.ora file and replace any HOST= [hostname or domain name] to use static IP addresses for the host. The listener.ora file is by default located in the ORACLE_HOME/network/admin directory or the directory specified in the TNS_ADMIN environment variable for the listener service or process owner account.
View the cman.ora file in the ORACLE_HOME/network/admin directory. If the file does not exist, the database is not accessed via Oracle Connection Manager and this check is Not a Finding. If 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.
View the cman.ora file in the ORACLE_HOME/network/admin directory of the Connection Manager. Include the following line in the file: REMOTE_ADMIN = NO
From SQL*Plus: select value from v$parameter where name = 'sec_protocol_error_trace_action'; If the value returned is NONE, this is a Finding. If the value returned is TRACE, LOG or ALERT, this is Not a Finding.
Set the value for the sec_protocol_error_trace_action initialization parameter to ALERT or LOG. TRACE may be appropriate for testing or development, but provides more detail than may be useful. Consider using ALERT for MAC 1 systems. From SQL*Plus: alter system set sec_protocol_error_trace_action = 'ALERT' scope = spfile; OR alter system set sec_protocol_error_trace_action = 'LOG' scope = spfile; The above SQL*Plus command will set the parameter to take effect at next system startup.
From SQL*Plus: select count(*) from dba_users where username like 'FLOWS_%'; If the value returned is not 0 and the database is a production system, this is a Finding.
Remove Application Express using the instruction found in Oracle MetaLink Note 558340.1 from production DBMS systems. For new installations, select custom installation and de-select Application Express from the selectable options if available.
NOTE: The collection does not include application or custom data within the database. If released to unauthorized persons, system configuration data may be used by malicious persons to gain additional unauthorized access to the database or other systems. On UNIX Systems: ls $ORACLE_HOME/ccr On Windows Systems (From Windows Explorer): Browse to the %ORACLE_HOME% directory. If the directory ORACLE_HOME\ccr does not exist, this is not a Finding. If the ccr directory exists, confirm if any of the Oracle databases have been configured for OCM: From SQL*Plus: select username from dba_users where username = 'ORACLE_OCM'; If the account exists, OCM has been installed (on this database) and is a Finding.
Remove Oracle Configuration Manager. Details for removal are provided in Oracle MetaLink Note 369111.1 or in MetaLink Note 728989.1 for a link to the OCM Installation and Administration Guide.
View the SQLNET.ORA file in the ORACLE_HOME/network/admin directory or the directory specified in the TNS_ADMIN environment variable. Locate the following entry: SQLNET.ALLOWED_LOGON_VERSION = 11 If the parameter does not exist, this is a Finding. If the parameter is not set to a value of 11 or higher, this is a Finding.
Edit the SQLNET.ORA file to add or edit the entry: SQLNET.ALLOWED_LOGON_VERSION = 11 Set the value to 11 or higher.
Verify organizational requirements for encryption based on the system's data classification. If DBMS encryption is not required, this check is not a finding. If DBMS encryption is required and cryptography is either not being used or is not NIST FIPS 140-2 certified, this is a Finding. Maintain a copy of the FIPS 140-2 Validation Certificate for the cryptographic modules in use as proof of certification. Detailed information on the NIST Cryptographic Module Validation Program (CMVP) is available at the following website: http://csrc.nist.gov/groups/STM/cmvp/index.html -- Review the DBMS documentation to determine where cryptography may be used and/or configured. Review network communication encryption options, data object encryption (both tables and application code objects), and encryption key management. For UNIX systems: $ORACLE_HOME/OPatch/opatch lsinventory –detail | grep “Oracle Advanced Security” For Windows Systems: %ORACLE_HOME%/OPatch/opatch lsinventory –detail | find “Oracle Advanced Security” If DBMS data/network encryption is required and Oracle Advanced Security is not installed, this is a Finding. View the SQLNET.ORA file. If SQLNET.SSLFIPS_140 = TRUE is not set, this is a Finding. If SSL_CIPHER_SUITES is not defined, this is a Finding. If any cipher suites listed in SSL_CIPHER_SUITES value list is not included in the cipher suite list included below (and in this order), this is a Finding. FIPS 140-2 validated cipher suites for the Oracle SSL Libraries in the order of strongest to weakest: SSL_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_AES_128_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_DES_CBC_SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_RC4_128_MD5 SSL_DH_anon_WITH_DES_CBC_SHA Detailed information on the FIPS 140-2 standard is available at the following website: http://csrc.nist.gov/groups/SMA/index.html
Obtain and utilize native or third-party NIST FIPS 140-2 validated cryptography solution for the DBMS. Installation of Oracle Advanced Security product (which may require additional Oracle licensing consideration) is required to use native Oracle encryption. Please see the Oracle Advanced Security Administrator's Guide for configuration and use of encryption in the database. The Oracle Advanced Security Administrator's Guide provides references to the encryption features provided by Oracle Advanced Security. Instructions for the configuration of FIPS 140-2 compliance for encryption of network communications are provided in a dedicated appendix of the Oracle Advanced Security Administrator's Guide. All cipher suites listed above include FIPS 140-2 validated algorithms available for data encryption. Encryption of data stored within the database is available only in Oracle versions 11.1 and later. View Data Encryption and Integrity in the Oracle Advanced Security Administration Guide for configuration details. Note: FIPS 140-2 compliance or non-compliance for the host and network is outside the purview of the Database STIG. FIPS 140-2 non-compliance at the host/network level does not negate this requirement.
From SQL*Plus: select value from v$parameter where name = 'audit_trail'; select value from v$parameter where name = 'audit_file_dest'; If audit_trail is NOT set to TRUE, OS, XML, or XML, EXTENDED per MetaLink Note 30690.1, this is not a finding. On UNIX Systems: ls -ld [pathname] Replace [pathname] with the directory path listed from the above SQL command for audit_file_dest. If permissions are granted for world access, this is a finding. If any groups that include members other than the Oracle process and software owner accounts, DBAs, auditors, or backup accounts are listed, this is a finding. Compare path to $ORACLE_HOME. If audit_file_dest is a subdirectory of $ORACLE_HOME, this is a finding. On Windows Systems (from Windows Explorer): Browse to the directory specified. Select and right-click on the directory, select Properties, select the Security tab. On Windows hosts, records are also written to the Windows application event log. The location of the application event log is listed under Properties for the log under the Windows console. The default location is C:\WINDOWS\system32\config\EventLogs\AppEvent.Evt. If permissions are granted to everyone, this is a Finding. If any accounts other than the Administrators, DBAs, System group, auditors, or backup operators are listed, this is a finding. Compare path to %ORACLE_HOME%. If audit_file_dest is a subdirectory of %ORACLE_HOME%, this is a finding.
Alter host system permissions to the AUDIT_FILE_DEST directory to the Oracle process and software owner accounts, DBAs, backup accounts, SAs (if required), and auditors. Authorize and document user access requirements to the directory outside of the Oracle, DBA, and SA account list in the System Security Plan.
From SQL*Plus: select name from v$controlfile; DoD guidance recommends: 1. A minimum of two distinct control files for each Oracle Database Instance. 2. Each control file located on separate, archived physical or virtual storage devices. 3. Different Logical Paths for each control file at the highest level supported by your configuration; for example: UNIX: /ora03/app/oracle/{SID}/control/control01.ctl /ora04/app/oracle/{SID}/control/control02.ctl Windows: D:/oracle/{SID}/control/control01.ctl E:/oracle/{SID}/control/control02.ctl If this minimum is not met, this is a finding. Verify that the mount points or partitions referenced in the file paths indicate separate physical disks. If not, this is a finding. (This includes RAID devices and ASM storage. In the case of SAN storage and where possible, different storage pools must be used for control file locations. This ensures not only that different physical disks are used but that separate higher level storage components are used.)
Establish at least two Oracle control files. Specify a separate, dedicated disk/directory location for each control file.
From SQL*Plus: select count(*) from V$LOG; If the value of the count returned is less than 2, this is a finding. From SQL*Plus: select count(*) from V$LOG where members > 1; If the value of the count returned is less than 2 and a RAID storage device is not being used, this is a finding.
To define additional redo log file groups: From SQL*Plus (Example): alter database add logfile group 2 ('diska:log2.log', 'diskb:log2.log') size 50K; To add additional redo log file [members] to an existing redo log file group: From SQL*Plus (Example): alter database add logfile member 'diskc:log2.log' to group 2; Replace diska, diskb, diskc with valid, different disk drive specifications. Replace log#.log file with valid names for the log files.