Oracle Database 11.2g Security Technical Implementation Guide
Pick two releases to diff their requirements.
Open a previous version of this STIG.
- RMF Control
- AC-6
- Severity
- H
- CCI
- CCI-000040
- Version
- O112-C1-004500
- Vuln IDs
-
- V-52125
- Rule IDs
-
- SV-66341r1_rule
Checks: C-54181r1_chk
Review OS privileges for DBA and other database administrative accounts. If DBA or administrative accounts have unauthorized roles or permissions beyond those needed for database administration, this is a finding.
Fix: F-56939r1_fix
Remove OS permissions from DBAs and other administrative users beyond those required for database administrative functions.
- RMF Control
- SC-14
- Severity
- M
- CCI
- CCI-001149
- Version
- O112-C2-017100
- Vuln IDs
-
- V-52133
- Rule IDs
-
- SV-66349r1_rule
Checks: C-54189r1_chk
Determine whether the database houses and distributes information to the public. Review DBMS settings to determine whether controls exist to protect the integrity of publicly available information. If not, this is a finding. - - - - - All of the permissions and policies we would employ to protect information would be in play, like access control mechanisms, auditing, and password protection. For data that is for display or download to the public for their informational needs, it may be appropriate to place the data in a read-only tablespace. This will provide the DBA with the ability to modify content as needed by modifying the tablespace from read-only to read-write in the event the content needs to be modified. Check with the Application Developer to see what tables are used to store the data and/or content that is displayed to the public. Then find the tablespace name the data objects are stored in. $ sqlplus connect as sysdba SQL> SELECT table_name, tablespace_name from dba_tables where upper(table_name) like &tablename_from_developer; For better performance while accessing data in a read-only tablespace, you can issue a query that accesses all of the blocks of the tables in the tablespace just before making it read-only. A simple query, such as SELECT COUNT (*), executed against each table ensures that the data blocks in the tablespace can be subsequently accessed most efficiently. This eliminates the need for the database to check the status of the transactions that most recently modified the blocks. The following statement makes the flights tablespace read-only: ALTER TABLESPACE flights READ ONLY; You can issue the ALTER TABLESPACE...READ ONLY statement while the database is processing transactions. After the statement is issued, the tablespace is put into a transitional read-only state. No transactions are allowed to make further changes (using DML statements) to the tablespace. If a transaction attempts further changes, it is terminated and rolled back. However, transactions that already made changes and that attempt no further changes are allowed to commit or roll back. The ALTER TABLESPACE...READ ONLY statement waits for the following transactions to either commit or roll back before returning: transactions that have pending or uncommitted changes to the tablespace and that were started before you issued the statement. If a transaction started before the statement remains active, but rolls back to a savepoint, rolling back its changes to the tablespace, then the statement no longer waits for this active transaction.
Fix: F-56947r1_fix
Apply appropriate controls to protect the integrity of publicly available information. - - - - - If the appropriate controls include placing the data in a read-only tablespace, proceed as follows. After we figure out the tablespace the data object is stored in: $ sqlplus connect as sysdba SQL> SELECT table_name, tablespace_name from dba_tables where upper(table_name) like &tablename_from_developer; Once we get the name of the tablespace where all of the important data is stored, alter the tablespace to be read-only. SQL> ALTER TABLESPACE &tablespace_where_data_is READ ONLY; For better performance while accessing data in a read-only tablespace, you can issue a query that accesses all of the blocks of the tables in the tablespace just before making it read-only. A simple query, such as SELECT COUNT (*), executed against each table ensures that the data blocks in the tablespace can be subsequently accessed most efficiently. This eliminates the need for the database to check the status of the transactions that most recently modified the blocks. You can issue the ALTER TABLESPACE...READ ONLY statement while the database is processing transactions. After the statement is issued, the tablespace is put into a transitional read-only state. No transactions are allowed to make further changes (using DML statements) to the tablespace. If a transaction attempts further changes, it is terminated and rolled back. However, transactions that already made changes and that attempt no further changes are allowed to commit or roll back. If a transaction started before the statement remains active, but rolls back to a savepoint, rolling back its changes to the tablespace, then the statement no longer waits for this active transaction.
- RMF Control
- SC-23
- Severity
- M
- CCI
- CCI-001185
- Version
- O112-C2-017600
- Vuln IDs
-
- V-52135
- Rule IDs
-
- SV-66351r1_rule
Checks: C-54191r1_chk
Review DBMS settings and vendor documentation to verify user sessions are terminated upon user logout. If they are not, this is a finding. Review system documentation and organization policy to identify other events that should result in session terminations. If other session termination events are defined, review DBMS settings to verify occurrences of these events would cause session termination. If occurrences of defined session-terminating events do not cause session terminations, this is a finding. When a user logs out of an Oracle session gracefully or has the session terminated for an idle timeout or any other reason, the session is terminated, and the resources are returned to the system. Check with the DBA to see what mechanism is used to disconnect the session and what events the site uses to determine if a connection needs to be terminated. To test for timeout, open a connection and leave it idle for a period greater than the defined idle timeout setting enforced by the system. Then try to use the connection. If the connection is no longer active, then the mechanism deployed to terminate the connection is active and working.
Fix: F-56949r2_fix
Configure DBMS settings to terminate sessions upon user logout. Configure DBMS settings to terminate sessions upon the occurrence of any organization or policy-defined session termination event. - - - - - To configure specific session termination processes we need to define the organization or policy-defined session termination event. Below are some examples. Oracle has several ways to disconnect idle sessions, both from within SQL*Plus via resources profiles (connect_time, idle_time) and with the SQL*net expire time parameter. You can use profiles to set the connect time and idle time with "alter profile" statements: alter profile senior_claim_analyst limit connect_time 180000 sessions_per_user 2 ldle_time 1800; Profiles comprise a named set of resource limits. By default, when you create users, they are given the default profile, which provides unlimited use of all resources. The syntax to create a profile follows: CREATE PROFILE LIMIT resource_parameters|password_parameters; Resource_parameters: [SESSIONS_PER_USER n|UNLIMITED|DEFAULT] [CPU_PER_SESSION n|UNLIMITED|DEFAULT] [CPU_PER_CALL n|UNLIMITED|DEFAULT] [CONNECT_TIME n|UNLIMITED|DEFAULT] [IDLE_TIME n|UNLIMITED|DEFAULT] By setting resource limits, you can prevent users from performing operations that will tie up the system and prevent other users from performing operations. You can use resource limits for security, to ensure that users log off the system, so as not to leave the session connected for long periods of time. The system resource limits can be enforced at the session-level, the call level, or both. The session-level is calculated from the time the user logs in to the database until the user exits. The call level applies to each SQL command issued. Session-level limits are enforced for each connection. When a session-level limit is exceeded, only the last SQL command issued is rolled back; no further work can be performed until a commit, rollback, or exit is performed. Using SQLNET.EXPIRE_TIME The sqlnet.expire_time parameter is used to set a time interval, in minutes, to determine how often a probe should be sent verifying that client/server connections are active. If you need to ensure that connections are not left open indefinitely (or up to the time set by operating system-specific parameters), you should set a value that is greater than 0. This protects the system from connections left open due to an abnormal client termination. When the probe detects a terminated connection or a connection no longer in use, it signals an error, causing the server process to exit. This setting is intended for use on the database server side of the connection, which usually handles multiple connections at any one time. Limitations on using this terminated (dead) connection detection feature are: sqlnet.expire_time cannot be used on bequeathed connections. The SQL*Net expire_time probe packet will generate additional network traffic that may downgrade the network's performance, depending on the number of connections. Depending on the operating system that is in use, additional server processing may need to be performed to distinguish the connection probe from other events that occur. This overhead for detection of probe events can result in downgraded network performance. Turning-on expire_time To set up these advanced features, simply edit your sqlnet.ora file. If you are a beginner, follow this procedure: Start the Oracle Network Manager GUI. In the GUI navigator pane, expand the icons Local > Profile. From the list on the right hand pane, select General. Click on the Advanced tab. Next, enter the values for the fields or options you want to set. When you are finished, choose File > Save Network Configuration to write your changes to the sqlnet.ora file. The sqlnet.ora inbound_connect_timeout parameter The sqlnet.ora inbound_connect_timeout parameter is used to limit the time, set in seconds, for a client to connect with the database server and provide the required authentication information. Also see sqlnet.inbound_connect_timeout tips. To limit consumption of Oracle resources by unauthorized users and enable an audit trail, you should set time-limit values for the sqlnet.inbound_connect_timeout parameter in wall-clock seconds. (This parameter does not have default values.) Failure resulting from sqlnet.inbound_connect_timeout will throw an ORA-03136 inbound connection timed out error.
- RMF Control
- SC-23
- Severity
- M
- CCI
- CCI-001186
- Version
- O112-C2-017700
- Vuln IDs
-
- V-52137
- Rule IDs
-
- SV-66353r1_rule
Checks: C-54193r1_chk
Review DBMS settings and vendor documentation to verify users have the capability to log out of the system manually. If the DBMS does not provide functionality for the user to manually log out of the system, this is a finding. If the DBMS does provide the functionality for the user to manually log out of the system but the functionality is not enabled, this is a finding. If any application using the database can be closed, or logged out of, by the user, yet does not close the user's session in the DBMS, this is a finding. - - - - - - This is default behavior for the Oracle database. To test this functionality, create a user named testuser1 as SYSDBA and grant connect to testuser1. The V$SESSION is the place where all of the sessions that are established with the database are tracked, so we can count the number of active sessions by counting the rows in that table. Initiate session one sqlplus connect sysdba SQL>select count(*) from v$session count (*) --------- 26 Then connect as a different user in a second terminal session and after successfully connecting, issue the select count(*) command again and the number should increase by one, then have user1 exit the session. If you have the SYSDBA do another select count(*) from v$session, you will see the session count will go down by 1. When a session no longer exists, the resources are de-allocated. sqlplus connect as user1 SQL>exit
Fix: F-56951r1_fix
Utilize a DBMS product that allows users to manually log out of the system. Configure DBMS settings to allow users to manually log out of the system. Code applications to close database sessions when the user logs out or closes the application.
- RMF Control
- SC-24
- Severity
- M
- CCI
- CCI-001190
- Version
- O112-C2-018100
- Vuln IDs
-
- V-52139
- Rule IDs
-
- SV-66355r1_rule
Checks: C-54195r1_chk
Check DBMS settings and vendor documentation to verify the DBMS properly handles transactions in the event of a system failure. If open transactions are not rolled back to a consistent state during system failure, this is a finding. Oracle creates what is known as archive logs. Archive logs contain information required to replay a transaction should something happen. The redo logs are also used to copy transactions or pieces of transactions. Check to see if the database is in archive log mode and if archive log mode is not enabled, this is a finding. Issue the following commands to check the status of archive log mode: $ sqlplus connect as sysdba --Check current archivelog mode in database SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination /home/oracle/app/oracle/arc2/ORCL Oldest online log sequence 433 Next log sequence to archive 435 Current log sequence 435
Fix: F-56953r1_fix
Configure DBMS settings to properly handle transactions in the event of a system failure. DBMS failures must not leave transactions in an inconsistent state. If the database is not in archive log mode, issue the following commands to put the database in archive log mode. The database must be normally shutdown and restarted before the database can be placed in archive log mode. Issue the following commands to place the database in archive log mode: $ sqlplus connect as sysdba -- stop and dismount database and shutdown instance. SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. Restart instance. SQL> startup mount; ORACLE instance started. Total System Global Area 1653518336 bytes Fixed Size 2228904 bytes Variable Size 1325403480 bytes Database Buffers 318767104 bytes Redo Buffers 7118848 bytes Database mounted. Enable ArchiveLog SQL> alter database archivelog; Database altered. -- Re-open database SQL> alter database open; Database altered. Issue the following command to see the new status: SQL> select log_mode from v$database; LOG_MODE ------------ ARCHIVELOG SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 294 Next log sequence to archive 296 Current log sequence 296 The database is now in archive log mode, and transactions are being recorded to either transport to another database or being re-applied if the database becomes corrupt and needs to be restored from the last backup. Use the redo logs to replay transactions not captured in the backup.
- RMF Control
- SC-24
- Severity
- M
- CCI
- CCI-001665
- Version
- O112-C2-018200
- Vuln IDs
-
- V-52141
- Rule IDs
-
- SV-66357r1_rule
Checks: C-54197r1_chk
Check DBMS settings to determine whether system state information is being preserved in the event of a system failure. If system state information is not being preserved, this is a finding. The necessary state information is defined as "information necessary to determine cause of failure and to return to operations with least disruption to mission/ business processes".
Fix: F-56955r1_fix
Configure DBMS settings to preserve all required system state information in the event of a system failure.
- RMF Control
- SC-28
- Severity
- M
- CCI
- CCI-001199
- Version
- O112-C2-018300
- Vuln IDs
-
- V-52143
- Rule IDs
-
- SV-66359r1_rule
Checks: C-54199r1_chk
Review DBMS settings to determine whether controls exist to protect the confidentiality and integrity of data at rest in the database. If controls do not exist or are not enabled, this is a finding. To ensure that the appropriate controls are in place, discuss the precautions taken with the site Database Administrators and System Administrators and try to modify data at rest. Oracle recommends using Transparent Data Encryption to protect data. In order to check to see if the data is encrypted, for example, upon an auditor's request, Oracle provides views that document the encryption status of your database. For TDE column encryption, please use the view 'dba_encrypted_columns', which lists the owner, table name, column name, encryption algorithm, and salt, for all encrypted columns. For TDE tablespace encryption, the following SQL statement lists all encrypted tablespaces with their encryption algorithm and corresponding, encrypted, data files. Issue the following commands to check to see if the data at rest is encrypted. $ sqlplus connect as sysdba SQL> SELECT t.name "TSName", e.encryptionalg "Algorithm", d.file_name "File Name" FROM v$tablespace t, v$encrypted_tablespaces e, dba_data_files d WHERE t.ts# = e.ts# and t.name = d.tablespace_name; The next SQL statement lists the table owner, tables within encrypted tablespaces, and the encryption algorithm: SQL> SELECT a.owner "Owner", a.table_name "Table Name", e.encryptionalg "Algorithm", FROM dba_tables a, v$encrypted_tablespaces e WHERE a.tablespace_name in (select t.name from v$tablespace t, v$encrypted_tablespaces e where t.ts# = e.ts#);
Fix: F-56957r1_fix
Apply appropriate controls to protect the confidentiality and integrity of data at rest in the database. If no site-specific precautions are in place, use Oracle Advanced Security Option to encrypt data at rest. If ASO is not an option, use site-specific procedures to secure data at rest.
- RMF Control
- SC-28
- Severity
- M
- CCI
- CCI-001200
- Version
- O112-C2-018400
- Vuln IDs
-
- V-52145
- Rule IDs
-
- SV-66361r1_rule
Checks: C-54201r1_chk
Check DBMS settings to determine whether cryptographic mechanisms are used to prevent the unauthorized disclosure of information at rest. Determine whether physical measures are being used instead of cryptographic mechanisms. If neither cryptographic nor physical measures are being utilized, this is a finding. Oracle recommends using Transparent Data Encryption to protect data at rest. In order to check to see if the data is encrypted, for example, upon an auditor's request, Oracle provides views that document the encryption status of your database. For TDE column encryption, please use the view 'dba_encrypted_columns', which lists the owner, table name, column name, encryption algorithm, and salt, for all encrypted columns. For TDE tablespace encryption, the following SQL statement lists all encrypted tablespaces with their encryption algorithm and corresponding, encrypted, data files. Issue the following commands to check to see if the data at rest is encrypted. $ sqlplus connect as sysdba SQL> SELECT t.name "TSName", e.encryptionalg "Algorithm", d.file_name "File Name" FROM v$tablespace t, v$encrypted_tablespaces e, dba_data_files d WHERE t.ts# = e.ts# and t.name = d.tablespace_name; The next SQL statement lists the table owner, tables within encrypted tablespaces, and the encryption algorithm: SQL> SELECT a.owner "Owner", a.table_name "Table Name", e.encryptionalg "Algorithm", FROM dba_tables a, v$encrypted_tablespaces e WHERE a.tablespace_name in (select t.name from v$tablespace t, v$encrypted_tablespaces e where t.ts# = e.ts#);
Fix: F-56959r1_fix
Configure DBMS to use cryptographic mechanisms to prevent unauthorized disclosure of information at rest where physical measures are not being utilized. Deploy Oracle Advanced Security option, a locally developed encryption system, or a third-party product to encrypt data at rest. If ASO is not an option, use site-specific procedures to secure data at rest.
- RMF Control
- SC-3
- Severity
- M
- CCI
- CCI-001084
- Version
- O112-C2-018500
- Vuln IDs
-
- V-52147
- Rule IDs
-
- SV-66363r1_rule
Checks: C-54203r1_chk
Check DBMS settings to determine whether objects or code implementing security functionality are located in a separate security domain, such as a separate database or schema created specifically for security functionality. If security-related database objects or code are not kept separate, this is a finding. The Oracle elements of security functionality such as the roles, permissions and profiles along with password complexity requirements are stored in separate schemas in the database. Review any site-specific applications security modules built into the database and determine what schema they are located in and take appropriate action. The Oracle objects will be in the Oracle Data Dictionary.
Fix: F-56961r1_fix
Locate security-related database objects and code in a separate database, schema, or other separate security domain from database objects and code implementing application logic. (This is the default behavior for Oracle.) Review any site-specific applications security modules built into the database: determine what schema they are located in and take appropriate action.
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-001682
- Version
- O112-C2-018600
- Vuln IDs
-
- V-52149
- Rule IDs
-
- SV-66365r1_rule
Checks: C-54205r1_chk
Check DBMS settings, OS settings, and/or enterprise-level authentication/access mechanisms settings to determine if emergency accounts are being automatically terminated by the system after an organization-defined time period. Check also for custom code (scheduled jobs, procedures, triggers, etc.) for achieving this. If emergency accounts are not being terminated after an organization-defined time period, this is a finding.
Fix: F-56965r1_fix
Create a profile specifically for emergency or temporary accounts. When creating the accounts, assign them to this profile. Configure DBMS, OS, and/or enterprise-level authentication/access mechanisms, or implement custom code, to terminate accounts with this profile after an organization-defined time period.
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-001487
- Version
- O112-C2-007900
- Vuln IDs
-
- V-52151
- Rule IDs
-
- SV-66367r1_rule
Checks: C-54207r1_chk
Verify, using vendor and system documentation if required, that the DBMS is configured to use Oracle's auditing features, or that a third-party product is deployed and configured to satisfy this requirement. If a third-party product is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding. The remainder of this Check deals specifically with Oracle auditing. To see if Oracle is configured to capture audit data, enter the following SQLPlus command: SHOW PARAMETER AUDIT_TRAIL or the following SQL query: SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail'; If Oracle does not return the value "DB_EXTENDED" or "DB, EXTENDED", and a third-party product is not deployed and configured to satisfy this requirement, this is a finding. If it does return "DB_EXTENDED" or "DB, EXTENDED", continue. To confirm that Oracle audit is capturing sufficient information to establish outcomes, perform a successful auditable action and an auditable action that results in an SQL error, and then issue the SQL statement: SELECT USERID FROM SYS.AUD$; If no data, or the wrong value, is returned for the auditable action just performed, this is a finding.
Fix: F-56967r1_fix
Configure the DBMS's auditing to audit organization-defined auditable events. If preferred, use a third-party tool. The tool must provide the minimum capability to audit the required events. Either use Oracle's built-in auditing capabilities, or use a third-party product that supports session auditing. If using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows. Use this query to ensure auditable events are captured: ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE; After executing this statement, it may be necessary to shutdown and restart the Oracle instance. If the query SELECT USERID FROM SYS.AUD$; does not return valid data for auditable actions, modify the audit settings to capture this information. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm
- RMF Control
- SI-4
- Severity
- M
- CCI
- CCI-001274
- Version
- O112-C2-018800
- Vuln IDs
-
- V-52153
- Rule IDs
-
- SV-66369r1_rule
Checks: C-54209r1_chk
Check DBMS settings to determine whether security personnel are alerted automatically when unusual or security-related activities (threats identified by authoritative sources (e.g. CTOs) and IAW with CJCSM 6510.01A) are detected on the database. If security personnel are not automatically alerted, this is a finding.
Fix: F-56969r1_fix
Configure database to automatically alert security personnel of inappropriate or unusual activities with security implications. Oracle provides this capability with the Audit Vault. Install and configure Oracle Audit Vault if it is available. If Audit Vault is not available, implement custom code or deploy a third-party product to satisfy this requirement.
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000135
- Version
- O112-C2-008000
- Vuln IDs
-
- V-52155
- Rule IDs
-
- SV-66371r1_rule
Checks: C-54211r1_chk
Verify, using vendor and system documentation if required, that the DBMS is configured to use Oracle's auditing features, or that a third-party product is deployed and configured to satisfy this requirement. If a third-party product is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding. The remainder of this Check deals specifically with Oracle auditing. To see if Oracle is configured to capture audit data, enter the following SQLPlus command: SHOW PARAMETER AUDIT_TRAIL or the following SQL query: SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail'; If Oracle does not return the value "DB_EXTENDED" or "DB, EXTENDED", and a third-party product is not deployed and configured to satisfy this requirement, this is a finding. If it does return "DB_EXTENDED" or "DB, EXTENDED", continue. Compare the organization-defined auditable events with the Oracle documentation to determine whether standard DB_EXTENDED auditing covers all the requirements. If it does, this is not a finding. If it does not, continue. Compare those organization-defined auditable events that are not covered by the standard DB_EXTENDED auditing, with the existing Fine-Grained Auditing (FGA) specifications returned by the following query: SELECT * FROM SYS.DBA_FGA_AUDIT_TRAIL; If any such auditable event is not covered by the existing FGA specifications, this is a finding.
Fix: F-56971r1_fix
Configure the DBMS's auditing to audit organization-defined auditable events. If preferred, use a third-party tool. The tool must provide the minimum capability to audit the required events. Either use Oracle's built-in auditing capabilities, or use a third-party product that supports session auditing. If using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows. Use this query to ensure auditable events are captured: ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE; After executing this statement, it may be necessary to shutdown and restart the Oracle instance. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm If the site-specific audit requirements are not covered by the default audit options, deploy and configure Fine-Grained Auditing. For details, refer to Oracle documentation, at the location above.
- RMF Control
- SC-4
- Severity
- M
- CCI
- CCI-001090
- Version
- O112-C2-018900
- Vuln IDs
-
- V-52157
- Rule IDs
-
- SV-66373r1_rule
Checks: C-54213r1_chk
Verify there are proper procedures in place for the refreshing of development/test data from production. Review any scripts or code that exists for the movement of production data to development/test and verify copies of production data are not left in unprotected locations. If there is no documented procedure for data movement from production to development/test, this is a finding. If the code that exists for data movement does not remove any copies of production data from unprotected locations, this is a finding.
Fix: F-56973r1_fix
Create and document a process for moving data from production to development/test systems, and follow the process. Modify any code used for moving data from production to development/test systems to ensure copies of production data are not left in non-secured locations. Moving data is only a part of the challenge of protecting the data. When the data is moved, it should also be changed so sensitive information is not made available in development environments. With the Oracle Data Masking Pack for Oracle Enterprise Manager, organizations can comply with data privacy and protection mandates that restrict the use of actual customer data. With Oracle Data Masking Pack, sensitive information such as credit card or social security numbers can be replaced with realistic values, allowing production data to be safely used for development, testing, or sharing with out-source or off-shore partners for other nonproduction purposes. When used in conjunction with Oracle Enterprise Manager, it is easy to develop a secure process which is capable of obfuscating the data during the movement process. If the Oracle Data Masking Pack and Enterprise Manager are not available, develop site-specific procedures to manage and obfuscate sensitive data.
- RMF Control
- AU-5
- Severity
- M
- CCI
- CCI-000143
- Version
- O112-C2-008200
- Vuln IDs
-
- V-52159
- Rule IDs
-
- SV-66375r1_rule
Checks: C-54215r1_chk
Review DBMS, OS, or third-party logging application settings to determine whether a warning will be provided when a specific percentage of log storage capacity is reached. If no warning will be provided, this is a finding.
Fix: F-56975r1_fix
Modify DBMS, OS, or third-party logging application settings to alert appropriate personnel when a specific percentage of log storage capacity is reached. For ease of management, it is recommended that the audit tables be kept in a dedicated tablespace. If Oracle Enterprise Manager is in use, the capability to issue such an alert is built in and configurable via the console so an email can be sent to a designated administrator. If Enterprise Manager is unavailable, the following script can be used to monitor storage space; this can be combined with additional code to email the appropriate administrator so they can take action. sqlplus connect as sysdba SQL> set pagesize 300 SQL> set linesize 120 SQL> column sumb format 9,999,999,999,999 SQL> column extents format 999999 SQL> column bytes format 9,999,999,999,999 SQL> column largest format 9,999,999,999,999 SQL> column Tot_Size format 9,999,999,999,999 SQL> column Tot_Free format 9,999,999,999,999 SQL> column Pct_Free format 9,999,999,999,999 SQL> column Chunks_Free format 9,999,999,999,999 SQL> column Max_Free format 9,999,999,999,999 SQL> set echo off SQL> spool TSINFO.txt SQL> PROMPT SPACE AVAILABLE IN TABLESPACES SQL> select a.tablespace_name,sum(a.tots) Tot_Size, SQL> sum(a.sumb) Tot_Free, SQL> sum(a.sumb)*100/sum(a.tots) Pct_Free, SQL> sum(a.largest) Max_Free,sum(a.chunks) Chunks_Free SQL> from SQL> ( SQL> select tablespace_name,0 tots,sum(bytes) sumb, SQL> max(bytes) largest,count(*) chunks SQL> from dba_free_space a SQL> group by tablespace_name SQL> union SQL> select tablespace_name,sum(bytes) tots,0,0,0 from SQL> dba_data_files SQL> group by tablespace_name) a SQL> group by a.tablespace_name; Sample Output SPACE AVAILABLE IN TABLESPACES TABLESPACE_NAME TOT_SIZE TOT_FREE PCT_FREE MAX_FREE CHUNKS_FREE ------------------------------ ------------ ------------ ------------ ------------ ------------ DES2 41,943,040 30,935,040 74 30,935,040 1 DES2_I 31,457,280 23,396,352 74 23,396,352 1 RBS 60,817,408 57,085,952 94 52,426,752 16 SYSTEM 94,371,840 5,386,240 6 5,013,504 3 TEMP 563,200 561,152 100 133,120 5 TOOLS 120,586,240 89,407,488 74 78,190,592 12 USERS 1,048,576 26,624 3 26,624 1
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-001092
- Version
- O112-C2-019100
- Vuln IDs
-
- V-52161
- Rule IDs
-
- SV-66377r1_rule
Checks: C-54217r1_chk
Review DBMS settings to verify the DBMS implements measures to limit the effects of the organization-defined types of Denial of Service (DoS) attacks. If measures have not been implemented, this is a finding. Check the $ORACLE_HOME/network/admin/listener.ora to see if a Rate Limit has been established. A rate limit is used to prevent denial of service (DOS) attacks on a database or to control a login storm such as may be caused by an application server reboot. - - - - - Example of a listener configuration with rate limiting in effect: CONNECTION_RATE_LISTENER=10 LISTENER= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=yes)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526)) ) LISTENER= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=8)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=12)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526)) )
Fix: F-56977r1_fix
Implement measures to limit the effects of organization-defined types of Denial of Service attacks. Modify the $ORACLE_HOME/network/admin/listener.ora to establish a Rate Limit.
- RMF Control
- AU-5
- Severity
- M
- CCI
- CCI-000144
- Version
- O112-C2-008300
- Vuln IDs
-
- V-52163
- Rule IDs
-
- SV-66379r1_rule
Checks: C-54219r1_chk
Review DBMS, OS, or third-party logging application settings to determine whether a real-time alert will be sent to the appropriate personnel when auditing fails for any reason. If real-time alerts are not sent upon auditing failure, this is a finding.
Fix: F-56979r1_fix
Modify DBMS, OS, or third-party logging application settings to send a real-time alert to appropriate personnel when auditing fails for any reason.
- RMF Control
- SI-10
- Severity
- M
- CCI
- CCI-001310
- Version
- O112-C2-019500
- Vuln IDs
-
- V-52165
- Rule IDs
-
- SV-66381r1_rule
Checks: C-54221r1_chk
Review DBMS code, settings, field definitions, constraints and triggers to determine whether or not data being input into the database is validated. If code exists that allows invalid data to be acted upon or input into the database, this is a finding. If field definitions do not exist in the database, this is a finding. If fields do not contain enabled constraints where required, this is a finding. - - - - - Oracle provides built-in processes to keep data and its integrity intact by using constraints. Integrity Constraint States You can specify that a constraint is enabled (ENABLE) or disabled (DISABLE). If a constraint is enabled, data is checked as it is entered or updated in the database, and data that does not conform to the constraint is prevented from being entered. If a constraint is disabled, then data that does not conform can be allowed to enter the database. Additionally, you can specify that existing data in the table must conform to the constraint (VALIDATE). Conversely, if you specify NOVALIDATE, you are not ensured that existing data conforms. An integrity constraint defined on a table can be in one of the following states: ENABLE, VALIDATE ENABLE, NOVALIDATE DISABLE, VALIDATE DISABLE, NOVALIDATE For details about the meaning of these states and an understanding of their consequences, see the Oracle Database SQL Language Reference. Some of these consequences are discussed here. Disabling Constraints To enforce the rules defined by integrity constraints, the constraints should always be enabled. However, consider temporarily disabling the integrity constraints of a table for the following performance reasons: - When loading large amounts of data into a table - When performing batch operations that make massive changes to a table (for example, changing every employee's number by adding 1000 to the existing number) - When importing or exporting one table at a time In all three cases, temporarily disabling integrity constraints can improve the performance of the operation, especially in data warehouse configurations. It is possible to enter data that violates a constraint while that constraint is disabled. Thus, you should always enable the constraint after completing any of the operations listed in the preceding bullet list. Enabling Constraints While a constraint is enabled, no row violating the constraint can be inserted into the table. However, while the constraint is disabled, such a row can be inserted. This row is known as an exception to the constraint. If the constraint is in the enable nonvalidated state, violations resulting from data entered while the constraint was disabled remain. The rows that violate the constraint must be either updated or deleted in order for the constraint to be put in the validated state. You can identify exceptions to a specific integrity constraint while attempting to enable the constraint. See "Reporting Constraint Exceptions". All rows violating constraints are noted in an EXCEPTIONS table, which you can examine. Enable Nonvalidate Constraint State When a constraint is in the enable nonvalidate state, all subsequent statements are checked for conformity to the constraint. However, any existing data in the table is not checked. A table with enable nonvalidated constraints can contain invalid data, but it is not possible to add new invalid data to it. Enabling constraints in the nonvalidated state is most useful in data warehouse configurations that are uploading valid OLTP data. Enabling a constraint does not require validation. Enabling a constraint nonvalidate is much faster than enabling and validating a constraint. Also, validating a constraint that is already enabled does not require any DML locks during validation (unlike validating a previously disabled constraint). Enforcement guarantees that no violations are introduced during the validation. Hence, enabling without validating enables you to reduce the downtime typically associated with enabling a constraint. Efficient Use of Integrity Constraints: A Procedure Using integrity constraint states in the following order can ensure the best benefits: Disable state. Perform the operation (load, export, import). Enable nonvalidate state. Enable state. Some benefits of using constraints in this order are: No locks are held. All constraints can go to enable state concurrently. Constraint enabling is done in parallel. Concurrent activity on table is permitted. Setting Integrity Constraints Upon Definition When an integrity constraint is defined in a CREATE TABLE or ALTER TABLE statement, it can be enabled, disabled, or validated or not validated as determined by your specification of the ENABLE/DISABLE clause. If the ENABLE/DISABLE clause is not specified in a constraint definition, the database automatically enables and validates the constraint. Disabling Constraints Upon Definition The following CREATE TABLE and ALTER TABLE statements both define and disable integrity constraints: CREATE TABLE emp ( empno NUMBER(5) PRIMARY KEY DISABLE, . . . ; ALTER TABLE emp ADD PRIMARY KEY (empno) DISABLE; An ALTER TABLE statement that defines and disables an integrity constraint never fails because of rows in the table that violate the integrity constraint. The definition of the constraint is allowed because its rule is not enforced. Enabling Constraints Upon Definition The following CREATE TABLE and ALTER TABLE statements both define and enable integrity constraints: CREATE TABLE emp ( empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY, . . . ; ALTER TABLE emp ADD CONSTRAINT emp.pk PRIMARY KEY (empno); An ALTER TABLE statement that defines and attempts to enable an integrity constraint can fail because rows of the table violate the integrity constraint. If this case, the statement is rolled back, and the constraint definition is not stored and not enabled. When you enable a UNIQUE or PRIMARY KEY constraint an associated index is created.
Fix: F-56983r1_fix
Modify database code to properly validate data before it is put into the database or acted upon by the database. Modify database to contain field definitions for each field in the database. Modify database to contain constraints on database columns and tables that require them for data validity. Review the application schemas implemented on the system. Check the DDL for the tables that are created for the applications to see if constraints have been enabled. - - - - - Enabling Constraints Upon Definition The following CREATE TABLE and ALTER TABLE statements both define and enable integrity constraints: CREATE TABLE emp ( empno NUMBER(5) CONSTRAINT emp.pk PRIMARY KEY, . . . ) ; ALTER TABLE emp ADD CONSTRAINT emp.pk PRIMARY KEY (empno); An ALTER TABLE statement that defines and attempts to enable an integrity constraint can fail because existing rows of the table violate the integrity constraint. In this case, the statement is rolled back, and the constraint definition is not stored and not enabled. When you enable a UNIQUE or PRIMARY KEY constraint, an associated index is created.
- RMF Control
- AU-5
- Severity
- M
- CCI
- CCI-000139
- Version
- O112-C2-008500
- Vuln IDs
-
- V-52167
- Rule IDs
-
- SV-66383r1_rule
Checks: C-54223r1_chk
Review DBMS, OS, or third-party logging application settings to determine whether an alert will be sent to the designated organizational personnel when auditing fails for any reason. If no alert will be sent, this is a finding.
Fix: F-56981r1_fix
Modify DBMS, OS, or third-party logging application settings to alert designated organizational personnel when auditing fails for any reason.
- RMF Control
- SI-7
- Severity
- M
- CCI
- CCI-001297
- Version
- O112-C2-019600
- Vuln IDs
-
- V-52169
- Rule IDs
-
- SV-66385r1_rule
Checks: C-54227r1_chk
Verify the DBMS system initialization and shutdowns are configured to ensure the DBMS system and data files remain in a secure state. If the DBMS does not support this, verify third-party software or custom scripting at the OS level performs this function. If neither the DBMS, a third-party application, nor the OS is performing integrity verification of DBMS system files, this is a finding.
Fix: F-56987r1_fix
Utilize a DBMS, OS, or third-party product to perform file verification of DBMS system file integrity at startup and shutdown. (Using Oracle Configuration Manager with Enterprise Manager, configured to perform this verification, is one possible way of satisfying this requirement.)
- RMF Control
- AU-7
- Severity
- M
- CCI
- CCI-000158
- Version
- O112-C2-008900
- Vuln IDs
-
- V-52171
- Rule IDs
-
- SV-66387r1_rule
Checks: C-54225r1_chk
Review DBMS to determine whether it provides the ability to automatically process audit records for events based on selectable event criteria. If the DBMS does not provide these abilities, they may be handled by a separate application. If the ability to automatically process audit records for events based on selectable event criteria does not exist in either the DBMS or a separate application, this is a finding.
Fix: F-56985r1_fix
Utilize a DBMS or separate application that provides the ability to automatically process audit records for events based on selectable event criteria. (Since the data is already in a table, the ability to process audit records for events based on selectable criteria is built in. With Oracle, you could use any tool or custom code you would like to use to retrieve data, just as for any Oracle table.)
- RMF Control
- SI-11
- Severity
- M
- CCI
- CCI-001311
- Version
- O112-C2-019800
- Vuln IDs
-
- V-52173
- Rule IDs
-
- SV-66389r1_rule
Checks: C-54231r1_chk
Check DBMS settings to determine whether security-related error conditions are monitored for, and whether appropriate personnel are notified. If security-related error conditions are not being monitored for, this is a finding. If appropriate personnel are not alerted when a security-related error condition is found, this is a finding.
Fix: F-56991r1_fix
Configure DBMS to monitor for security-related error conditions. Configure DBMS to alert appropriate personnel when security-related error conditions are found. This can be accomplished by using Oracle Audit Vault and/or Oracle Enterprise Manager. If neither of these products is deployed then develop a site-specific solution. - - - - - Notes to assist in developing a site-specific solution: The AUD$ table has a column called RETURNCODE. That column provides the return code, so, for example, if the security-related condition is someone trying to select data from a table that is not there, it would show up in the AUD$ table as an ORA-00942 - table or view does not exist. Since the RETURNCODE column is only numeric, only the 00942 would be stored. If the query for the information returned a row, the process would then need to form and send an email message. Oracle recommends the use of Oracle Audit Vault to fill this requirement without creating a custom solution. It is possible to set up notifications and alerts in Enterprise Manager as well, and if either of these alternatives is not available, a custom solution will be necessary.
- RMF Control
- AU-7
- Severity
- M
- CCI
- CCI-000158
- Version
- O112-C2-009000
- Vuln IDs
-
- V-52175
- Rule IDs
-
- SV-66391r1_rule
Checks: C-54229r1_chk
Review any audit settings for: - Unsuccessful login attempts; - Account locking events; - Account disabling from a specific source location; - Failed database object attempts or attempts to access objects that do not exist; and - Other activities that may produce unexpected failures or trigger DBMS lockdown actions. If any of the above events as applicable to the DBMS are not audited, this is a finding. - - - - - - Check the current users in the database to see what profile they are assigned. The login attempts past a site-defined allowable number, along with account locking, is best performed using a profile that defines the limits on these activities as designed by the DBA at a specific site. Failed database object access or attempt to access objects is monitored by auditing. Checking other activities that may produce unexpected failures or trigger database lockdown procedures is possible, but the check for the existence of those procedures is not possible unless they are defined. Check to see what profiles exist for the different users of the database. SQL>col name format a20 col username format a21 col profile format a10 col "tmp tba" format a10 select u.username, u.default_tablespace, u.temporary_tablespace "TMP TBS", u.profile, r.granted_role, r.admin_option, r.default_role from sys.dba_users u, sys.dba_role_privs r where u.username = r.grantee (+) group by u.username, u.default_tablespace, u.temporary tablespace, u.profile, r.granted_role, r.admin_option, r.default_role; View existing profiles and see what their settings are. SQL> select profile, resource_name, limit from dba_profiles order by profile, resource_name; This is the audit table. Specific actions are logged in this table. SQL> desc aud$; Name Null? Type ----------------------------------------- -------- ----------------------- SESSIONID NOT NULL NUMBER ENTRYID NOT NULL NUMBER STATEMENT NOT NULL NUMBER TIMESTAMP# DATE USERID VARCHAR2(30) USERHOST VARCHAR2(128) TERMINAL VARCHAR2(255) ACTION# NOT NULL NUMBER RETURNCODE NOT NULL NUMBER OBJ$CREATOR VARCHAR2(30) OBJ$NAME VARCHAR2(128) AUTH$PRIVILEGES VARCHAR2(16) AUTH$GRANTEE VARCHAR2(30) NEW$OWNER VARCHAR2(30) NEW$NAME VARCHAR2(128) SES$ACTIONS VARCHAR2(19) SES$TID NUMBER LOGOFF$LREAD NUMBER LOGOFF$PREAD NUMBER LOGOFF$LWRITE NUMBER LOGOFF$DEAD NUMBER LOGOFF$TIME DATE COMMENT$TEXT VARCHAR2(4000) CLIENTID VARCHAR2(64) SPARE1 VARCHAR2(255) SPARE2 NUMBER OBJ$LABEL RAW(255) SES$LABEL RAW(255) PRIV$USED NUMBER SESSIONCPU NUMBER NTIMESTAMP# TIMESTAMP(6) PROXY$SID NUMBER USER$GUID VARCHAR2(32) INSTANCE# NUMBER PROCESS# VARCHAR2(16) XID RAW(8) AUDITID VARCHAR2(64) SCN NUMBER DBID NUMBER SQLBIND CLOB SQLTEXT CLOB OBJ$EDITION VARCHAR2(30)
Fix: F-56989r1_fix
Configure auditing to capture the events listed below where available in the DBMS: - Unsuccessful login attempts - Account locking events - Account disabling from a specific source location - Failed database object attempts or attempts to access objects that do not exist - Other activities that may produce unexpected failures or trigger DBMS lockdown actions - - - - - Oracle provides the $ORACLE_HOME/rdbms/admin/secconf.sql script. If any of the site-specific requirements are not met with this script, check the Oracle(R) Database SQL Language Reference, 11g Release 2 (11.2), part number E41084-02, for additional audit options. The secconf.sql script has many options already deployed, but there are additional options that can be invoked.
- RMF Control
- SI-11
- Severity
- M
- CCI
- CCI-001312
- Version
- O112-C2-019900
- Vuln IDs
-
- V-52177
- Rule IDs
-
- SV-66393r1_rule
Checks: C-54235r1_chk
Check DBMS settings and custom database and application code to verify error messages do not contain information beyond what is needed for troubleshooting the issue. If database errors contain PII data, sensitive business data, or information useful for identifying the host system, this is a finding. (Notes on Oracle's approach to this issue: Out of the box, Oracle covers this. For example, if a user does not have access to a table, the error is just that the table or view does not exist. The Oracle database is not going to display a Social Security Number in an error code unless an application is programmed to do so. Oracle applications will not expose the actual transactional data to a screen. The only way Oracle will capture this information is to enable specific logging levels. Custom code would require a review to ensure compliance.)
Fix: F-56995r1_fix
Configure DBMS and custom database and application code not to divulge sensitive information or information useful for system identification in error information.
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-000162
- Version
- O112-C2-009300
- Vuln IDs
-
- V-52179
- Rule IDs
-
- SV-66395r1_rule
Checks: C-54233r1_chk
Review locations of audit logs, both internal to the database and database audit logs located at the operating system-level. Verify there are appropriate controls and permissions to protect the audit information from unauthorized access. If appropriate controls and permissions do not exist, this is a finding. - - - - - DBA_TAB_PRIVS describes all object grants in the database. Check to see who has permissions on the AUD$ table. Related View DBA_TAB_PRIVS describes the object grants for which the current user is the object owner, grantor, or grantee. Column Datatype NULL Description GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted OWNER VARCHAR2(30) NOT NULL Owner of the object TABLE_NAME VARCHAR2(30) NOT NULL Name of the object GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted with the GRANT OPTION (YES) or not (NO) HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with the HIERARCHY OPTION (YES) or not (NO) sqlplus connect as sysdba; SQL> SELECT GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE FROM DBA_COL_PRIVS where table_name
Fix: F-56993r1_fix
Add controls and modify permissions to protect database audit log data from unauthorized access, whether stored in the database itself or at the OS level. - - - - - Revoke access to the AUD$ table to anyone who should not have access to it. In the check we looked for all users who had access to the AUD$ table. To fix this, use the REVOKE command to revoke access to users who should not have access to the audit data. REVOKE statement Use the REVOKE statement to remove permissions from a specific user or from all users to perform actions on database objects. The following types of permissions can be revoked: Delete data from a specific table. Insert data into a specific table. Create a foreign key reference to the named table or to a subset of columns from a table. Select data from a table, view, or a subset of columns in a table. Create a trigger on a table. Update data in a table or in a subset of columns in a table. Run a specified routine (function or procedure). If a user named FRED had access to the AUD$ table and you want to revoke that access, use the following command. The syntax that you use for the REVOKE statement for tables is as follows: REVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees SQL>REVOKE SELECT ON TABLE AUD$ FROM FRED; Revoking a privilege without specifying a column list revokes the privilege for all of the columns in the table. Syntax for routines table-privileges include DELETE | INSERT | REFERENCES [column list] | SELECT [column list] | TRIGGER | UPDATE [column list] column list ( column-identifier {, column-identifier}* ) Use the ALL PRIVILEGES privilege type to revoke all of the permissions from the user for the specified table. You can also revoke one or more table privileges by specifying a privilege-list. Use the DELETE privilege type to revoke permission to delete rows from the specified table. Use the INSERT privilege type to revoke permission to insert rows into the specified table. Use the REFERENCES privilege type to revoke permission to create a foreign key reference to the specified table. If a column list is specified with the REFERENCES privilege, the permission is revoked on only the foreign key reference to the specified columns. Use the SELECT privilege type to revoke permission to perform SELECT statements on a table or view. If a column list is specified with the SELECT privilege, the permission is revoked on only those columns. If no column list is specified, then the privilege is valid on all of the columns in the table. Use the TRIGGER privilege type to revoke permission to create a trigger on the specified table. Use the UPDATE privilege type to revoke permission to use the UPDATE statement on the specified table. If a column list is specified, the permission is revoked only on the specified columns. grantees { authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] * You can revoke the privileges from specific users or from all users. Use the keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and from individual users are independent privileges. For example, a SELECT privilege on table t is granted to both PUBLIC and to the authorization ID harry. The SELECT privilege is later revoked from the authorization ID 'Harry', but the authorization ID 'Harry' can access the table through the PUBLIC privilege. Restriction: You cannot revoke the privileges of the owner of an object. routine-designator { qualified-name [ signature ] } Cascading object dependencies For views, triggers, and constraints, if the privilege on which the object depends is revoked, the object is automatically dropped. Derby does not try to determine if you have other privileges that can replace the privileges that are being revoked. For more information, see "SQL standard authorization" in the Java DB Developer's Guide. Limitations The following limitations apply to the REVOKE statement: Table-level privileges All of the table-level privilege types for a specified grantee and table ID are stored in one row in the SYSTABLEPERMS system table. For example, when user2 is granted the SELECT and DELETE privileges on table user1.t1, a row is added to the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The remaining privilege type fields are set to N. When a grantee creates an object that relies on one of the privilege types, the Derby engine tracks the dependency of the object on the specific row in the SYSTABLEPERMS table. For example, user2 creates the view v1 by using the statement SELECT * FROM user1.t1; the dependency manager tracks the dependency of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1). The dependency manager knows only that the view is dependent on a privilege type in that specific row but does not track exactly which privilege type the view is dependent on. When a REVOKE statement for a table-level privilege is issued for a grantee and table ID, all of the objects that are dependent on the grantee and table ID are dropped. For example, if user1 revokes the DELETE privilege on table t1 from user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1, and the view is dropped, even though the view is not dependent on the DELETE privilege for GRANTEE(user2), TABLEID(user1.t1). Column-level privileges Only one type of privilege for a specified grantee and table ID are stored in one row in the SYSCOLPERMS system table. For example, when user2 is granted the SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13. When a grantee creates an object that relies on the privilege type and the subset of columns in a table ID, the Derby engine tracks the dependency of the object on the specific row in the SYSCOLPERMS table. For example, user2 creates the view v1 by using the statement SELECT c11 FROM user1.t1; the dependency manager tracks the dependency of view v1 on the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that the view is dependent on the SELECT privilege type but does not track exactly which columns the view is dependent on. When a REVOKE statement for a column-level privilege is issued for a grantee, table ID, and type, all of the objects that are dependent on the grantee, table ID, and type are dropped. For example, if user1 revokes the SELECT privilege on column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1, and the view is dropped, even though the view is not dependent on the column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S). Revoke examples To revoke the SELECT privilege on table t from the authorization IDs 'Maria' and 'Harry', use the following syntax: SQL>REVOKE SELECT ON TABLE t FROM maria,harry To revoke the UPDATE and TRIGGER privileges on table t from the authorization IDs 'Anita' and 'Zhi', use the following syntax: SQL>REVOKE UPDATE, TRIGGER ON TABLE t FROM anita,zhi To revoke the SELECT privilege on table s.v from all users, use the following syntax: SQL>REVOKE SELECT ON TABLE s.v FROM PUBLIC To revoke the UPDATE privilege on columns c1 and c2 of table s.v from all users, use the following syntax: SQL>REVOKE UPDATE (c1,c2) ON TABLE s.v FROM PUBLIC To revoke the EXECUTE privilege on procedure p from the authorization ID 'George', use the following syntax: SQL>REVOKE EXECUTE ON PROCEDURE p FROM george RESTRICT
- RMF Control
- SI-11
- Severity
- M
- CCI
- CCI-001314
- Version
- O112-C2-020000
- Vuln IDs
-
- V-52181
- Rule IDs
-
- SV-66397r1_rule
Checks: C-54237r1_chk
Check DBMS settings and custom database code to determine if error messages are ever displayed to unauthorized individuals: i) Review all end-user-facing applications that use the database, to determine whether they display any DBMS-generated error messages to general users. If they do, this is a finding. ii) Review whether the database is accessible to users who are not authorized system administrators or database administrators, via the following types of software: iia) Oracle SQL*Plus iib) Reporting and analysis tools iic) Database management and/or development tools, such as, but not limited to, Toad. iid) Application development tools, such as, but not limited to, Oracle JDeveloper, Microsoft Visual Studio, PowerBuilder, or Eclipse. If the answer to the preceding question (ii through iid) is Yes, inquire whether, for each role or individual with respect to each tool, this access is required to enable the user(s) to perform authorized job duties. If No, this is a finding. If Yes, continue: For each tool in use, determine whether it is capable of suppressing DBMS-generated error messages, and if it is, whether it is configured to do so. Determine whether the role or individual, with respect to each tool, needs to see detailed DBMS-generated error messages. If No, and if the tool is not configured to suppress such messages, this is a finding. If Yes, determine whether the role/user's need to see such messages is documented in the System Security Plan. If so, this is not a finding. If not, this is a finding.
Fix: F-56997r2_fix
i) For each end-user-facing application that displays DBMS-generated error messages, configure or recode it to suppress these messages. (If the application is coded in Oracle PL/SQL, the EXCEPTION block can be used to suppress or divert error messages. Most other programming languages provide comparable facilities, such as TRY ... CATCH.) ii) For each unauthorized user of each tool, remove the ability to access it. For each tool where access to DBMS error messages is not required and can be configured, suppress the messages. For each role/user that needs access to the error messages, or needs a tool where the messages cannot be suppressed, document the need in the system security plan.
- RMF Control
- SI-4
- Severity
- M
- CCI
- CCI-001670
- Version
- O112-C2-020300
- Vuln IDs
-
- V-52183
- Rule IDs
-
- SV-66399r1_rule
Checks: C-54241r1_chk
Obtain the CC/S/A/FA's list of suspicious event types and the actions to be taken in response, ordered from least disruptive to last resort. If the list does not exist, this is a finding. For each event type in the list, review the measures in place in the DBMS/database configuration that are designed to detect and/or counter the event. (Alerting an administrator or operator to the problem is a valid measure.) If, for any event type defined in the list, no means of detecting the event exists, this is a finding. For each event type where an automatic countermeasure is defined, verify that its implementation is congruent with the list of defined actions. If not, this is a finding. Verify that administrators/operators are familiar with the list and the notification mechanism and are equipped to follow the instructions in the list. If not, this is a finding.
Fix: F-57001r1_fix
If the list does not exist, create it. For any event type defined in the list where no means of detecting the event exists, either create the means of detection or modify the list. For each event type where an automatic countermeasure is defined but its implementation differs from its description in the list, either modify the countermeasure or amend the list. If any administrators/operators are unfamiliar with the list or the notification mechanism, train them. If any administrators/operators are not equipped to follow the instructions in the list, provide them with the means to do so. Ensure the list is incorporated into, or referenced by, the System Security Plan. Note that Oracle Audit Vault and Oracle Database Vault are optional products that can be of considerable use in implementing active protection measures of this kind.
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-000163
- Version
- O112-C2-009400
- Vuln IDs
-
- V-52185
- Rule IDs
-
- SV-66401r1_rule
Checks: C-54239r1_chk
Review locations of audit logs, both internal to the database and database audit logs located at the operating system-level. Verify there are appropriate controls and permissions to protect the audit information from unauthorized modification. If appropriate controls and permissions do not exist, this is a finding. - - - - - - DBA_TAB_PRIVS describes all object grants in the database. Check to see who has permissions on the AUD$ table. Related View DBA_TAB_PRIVS describes the object grants for which the current user is the object owner, grantor, or grantee. Column Datatype NULL Description GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted OWNER VARCHAR2(30) NOT NULL Owner of the object TABLE_NAME VARCHAR2(30) NOT NULL Name of the object GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted with the GRANT OPTION (YES) or not (NO) HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with the HIERARCHY OPTION (YES) or not (NO) sqlplus connect as sysdba; SQL> SELECT GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE FROM DBA_COL_PRIVS where table_name = 'AUD$';
Fix: F-56999r1_fix
Add controls and modify permissions to protect database audit log data from unauthorized modification, whether stored in the database itself or at the OS level. - - - - - Revoke access to the AUD$ table to anyone who you do not want to have access to the AUD$ table. In the check we looked for all users who had access to the AUD$ table. To fix this, use the REVOKE command to revoke access to users who should not have access to the audit data. REVOKE statement Use the REVOKE statement to remove permissions from a specific user or from all users to perform actions on database objects. The following types of permissions can be revoked: Delete data from a specific table. Insert data into a specific table. Create a foreign key reference to the named table or to a subset of columns from a table. Select data from a table, view, or a subset of columns in a table. Create a trigger on a table. Update data in a table or in a subset of columns in a table. Run a specified routine (function or procedure). If a user named FRED had access to the AUD$ table and you want to revoke that access, use the following command. The syntax that you use for the REVOKE statement for tables is as follows: REVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees SQL>REVOKE SELECT ON TABLE AUD$ FROM FRED; Revoking a privilege without specifying a column list revokes the privilege for all of the columns in the table. Syntax for routines table-privileges include DELETE | INSERT | REFERENCES [column list] | SELECT [column list] | TRIGGER | UPDATE [column list] column list ( column-identifier {, column-identifier}* ) Use the ALL PRIVILEGES privilege type to revoke all of the permissions from the user for the specified table. You can also revoke one or more table privileges by specifying a privilege-list. Use the DELETE privilege type to revoke permission to delete rows from the specified table. Use the INSERT privilege type to revoke permission to insert rows into the specified table. Use the REFERENCES privilege type to revoke permission to create a foreign key reference to the specified table. If a column list is specified with the REFERENCES privilege, the permission is revoked on only the foreign key reference to the specified columns. Use the SELECT privilege type to revoke permission to perform SELECT statements on a table or view. If a column list is specified with the SELECT privilege, the permission is revoked on only those columns. If no column list is specified, then the privilege is valid on all of the columns in the table. Use the TRIGGER privilege type to revoke permission to create a trigger on the specified table. Use the UPDATE privilege type to revoke permission to use the UPDATE statement on the specified table. If a column list is specified, the permission is revoked only on the specified columns. grantees { authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] * You can revoke the privileges from specific users or from all users. Use the keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and from individual users are independent privileges. For example, a SELECT privilege on table t is granted to both PUBLIC and to the authorization ID harry. The SELECT privilege is later revoked from the authorization ID 'Harry', but the authorization ID 'Harry' can access the table through the PUBLIC privilege. Restriction: You cannot revoke the privileges of the owner of an object. routine-designator { qualified-name [ signature ] } Cascading object dependencies For views, triggers, and constraints, if the privilege on which the object depends on is revoked, the object is automatically dropped. Derby does not try to determine if you have other privileges that can replace the privileges that are being revoked. For more information, see "SQL standard authorization" in the Java DB Developer's Guide. Limitations The following limitations apply to the REVOKE statement: Table-level privileges All of the table-level privilege types for a specified grantee and table ID are stored in one row in the SYSTABLEPERMS system table. For example, when user2 is granted the SELECT and DELETE privileges on table user1.t1, a row is added to the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The remaining privilege type fields are set to N. When a grantee creates an object that relies on one of the privilege types, the Derby engine tracks the dependency of the object on the specific row in the SYSTABLEPERMS table. For example, user2 creates the view v1 by using the statement SELECT * FROM user1.t1; the dependency manager tracks the dependency of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1). The dependency manager knows only that the view is dependent on a privilege type in that specific row but does not track exactly which privilege type the view is dependent on. When a REVOKE statement for a table-level privilege is issued for a grantee and table ID, all of the objects that are dependent on the grantee and table ID are dropped. For example, if user1 revokes the DELETE privilege on table t1 from user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1, and the view is dropped, even though the view is not dependent on the DELETE privilege for GRANTEE(user2), TABLEID(user1.t1). Column-level privileges Only one type of privilege for a specified grantee and table ID are stored in one row in the SYSCOLPERMS system table. For example, when user2 is granted the SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13. When a grantee creates an object that relies on the privilege type and the subset of columns in a table ID, the Derby engine tracks the dependency of the object on the specific row in the SYSCOLPERMS table. For example, user2 creates the view v1 by using the statement SELECT c11 FROM user1.t1; the dependency manager tracks the dependency of view v1 on the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that the view is dependent on the SELECT privilege type but does not track exactly which columns the view is dependent on. When a REVOKE statement for a column-level privilege is issued for a grantee, table ID, and type, all of the objects that are dependent on the grantee, table ID, and type are dropped. For example, if user1 revokes the SELECT privilege on column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1, and the view is dropped, even though the view is not dependent on the column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S). Revoke examples To revoke the SELECT privilege on table t from the authorization IDs 'Maria' and 'Harry', use the following syntax: SQL>REVOKE SELECT ON TABLE t FROM maria,harry To revoke the UPDATE and TRIGGER privileges on table t from the authorization IDs 'Anita' and 'Zhi', use the following syntax: SQL>REVOKE UPDATE, TRIGGER ON TABLE t FROM anita,zhi To revoke the SELECT privilege on table s.v from all users, use the following syntax: SQL>REVOKE SELECT ON TABLE s.v FROM PUBLIC To revoke the UPDATE privilege on columns c1 and c2 of table s.v from all users, use the following syntax: SQL>REVOKE UPDATE (c1,c2) ON TABLE s.v FROM PUBLIC To revoke the EXECUTE privilege on procedure p from the authorization ID 'George', use the following syntax: SQL>REVOKE EXECUTE ON PROCEDURE p FROM george RESTRICT
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-001683
- Version
- O112-C2-020400
- Vuln IDs
-
- V-52187
- Rule IDs
-
- SV-66403r1_rule
Checks: C-54243r1_chk
Check DBMS settings to determine whether it will notify appropriate individuals when accounts are created. If the DBMS does not notify appropriate individuals when accounts are created, this is a finding.
Fix: F-57003r1_fix
Working with the DBA and site management, determine the appropriate individuals (by job role) to be notified. If Oracle Audit Vault is available, configure it to notify the appropriate individuals when accounts are created. If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing feature to record account-creation activity. Create and deploy a mechanism, such as a frequently-run job, to monitor the SYS.AUD$ table for these records and notify the appropriate individuals.
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-000164
- Version
- O112-C2-009500
- Vuln IDs
-
- V-52189
- Rule IDs
-
- SV-66405r1_rule
Checks: C-54245r1_chk
Review locations of audit logs, both internal to the database and database audit logs located at the operating system-level. Verify there are appropriate controls and permissions to protect the audit information from unauthorized deletion. If appropriate controls and permissions do not exist, this is a finding. - - - - - DBA_TAB_PRIVS describes all object grants in the database. Check to see who has permissions on the AUD$ table. Related View DBA_TAB_PRIVS describes the object grants for which the current user is the object owner, grantor, or grantee. Column Datatype NULL Description GRANTEE VARCHAR2(30) NOT NULL Name of the user to whom access was granted OWNER VARCHAR2(30) NOT NULL Owner of the object TABLE_NAME VARCHAR2(30) NOT NULL Name of the object GRANTOR VARCHAR2(30) NOT NULL Name of the user who performed the grant PRIVILEGE VARCHAR2(40) NOT NULL Privilege on the object GRANTABLE VARCHAR2(3) Indicates whether the privilege was granted with the GRANT OPTION (YES) or not (NO) HIERARCHY VARCHAR2(3) Indicates whether the privilege was granted with the HIERARCHY OPTION (YES) or not (NO) sqlplus connect as sysdba; SQL> SELECT GRANTEE, TABLE_NAME, COLUMN_NAME, PRIVILEGE FROM DBA_COL_PRIVS where table_name = 'AUD$';
Fix: F-57005r1_fix
Add controls and modify permissions to protect database audit log data from unauthorized deletion, whether stored in the database itself or at the OS level. - - - - - Revoke access to the AUD$ table to anyone who you do not want to have access to the AUD$ table. In the check we looked for all users who had access to the AUD$ table. To fix this, use the REVOKE command to revoke access to users who should not have access to the audit data. REVOKE statement Use the REVOKE statement to remove permissions from a specific user or from all users to perform actions on database objects. The following types of permissions can be revoked: Delete data from a specific table. Insert data into a specific table. Create a foreign key reference to the named table or to a subset of columns from a table. Select data from a table, view, or a subset of columns in a table. Create a trigger on a table. Update data in a table or in a subset of columns in a table. Run a specified routine (function or procedure). If a user named FRED had access to the AUD$ table and you want to revoke that access use the following command. The syntax that you use for the REVOKE statement for tables is as follows: REVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees SQL>REVOKE SELECT ON TABLE AUD$ FROM FRED; Revoking a privilege without specifying a column list revokes the privilege for all of the columns in the table. Syntax for routines table-privileges include DELETE | INSERT | REFERENCES [column list] | SELECT [column list] | TRIGGER | UPDATE [column list] column list ( column-identifier {, column-identifier}* ) Use the ALL PRIVILEGES privilege type to revoke all of the permissions from the user for the specified table. You can also revoke one or more table privileges by specifying a privilege-list. Use the DELETE privilege type to revoke permission to delete rows from the specified table. Use the INSERT privilege type to revoke permission to insert rows into the specified table. Use the REFERENCES privilege type to revoke permission to create a foreign key reference to the specified table. If a column list is specified with the REFERENCES privilege, the permission is revoked on only the foreign key reference to the specified columns. Use the SELECT privilege type to revoke permission to perform SELECT statements on a table or view. If a column list is specified with the SELECT privilege, the permission is revoked on only those columns. If no column list is specified, then the privilege is valid on all of the columns in the table. Use the TRIGGER privilege type to revoke permission to create a trigger on the specified table. Use the UPDATE privilege type to revoke permission to use the UPDATE statement on the specified table. If a column list is specified, the permission is revoked only on the specified columns. grantees { authorization ID | PUBLIC } [,{ authorization ID | PUBLIC } ] * You can revoke the privileges from specific users or from all users. Use the keyword PUBLIC to specify all users. The privileges revoked from PUBLIC and from individual users are independent privileges. For example, a SELECT privilege on table t is granted to both PUBLIC and to the authorization ID harry. The SELECT privilege is later revoked from the authorization ID 'Harry', but the authorization ID 'Harry' can access the table through the PUBLIC privilege. Restriction: You cannot revoke the privileges of the owner of an object. routine-designator { qualified-name [ signature ] } Cascading object dependencies For views, triggers, and constraints, if the privilege on which the object depends on is revoked, the object is automatically dropped. Derby does not try to determine if you have other privileges that can replace the privileges that are being revoked. For more information, see "SQL standard authorization" in the Java DB Developer's Guide. Limitations The following limitations apply to the REVOKE statement: Table-level privileges All of the table-level privilege types for a specified grantee and table ID are stored in one row in the SYSTABLEPERMS system table. For example, when user2 is granted the SELECT and DELETE privileges on table user1.t1, a row is added to the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The remaining privilege type fields are set to N. When a grantee creates an object that relies on one of the privilege types, the Derby engine tracks the dependency of the object on the specific row in the SYSTABLEPERMS table. For example, user2 creates the view v1 by using the statement SELECT * FROM user1.t1; the dependency manager tracks the dependency of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1). The dependency manager knows only that the view is dependent on a privilege type in that specific row but does not track exactly which privilege type the view is dependent on. When a REVOKE statement for a table-level privilege is issued for a grantee and table ID, all of the objects that are dependent on the grantee and table ID are dropped. For example, if user1 revokes the DELETE privilege on table t1 from user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1, and the view is dropped, even though the view is not dependent on the DELETE privilege for GRANTEE(user2), TABLEID(user1.t1). Column-level privileges Only one type of privilege for a specified grantee and table ID are stored in one row in the SYSCOLPERMS system table. For example, when user2 is granted the SELECT privilege on table user1.t1 for columns c12 and c13, a row is added to the SYSCOLPERMS. The GRANTEE field contains user2, the TABLEID contains user1.t1, the TYPE field contains S, and the COLUMNS field contains c12, c13. When a grantee creates an object that relies on the privilege type and the subset of columns in a table ID, the Derby engine tracks the dependency of the object on the specific row in the SYSCOLPERMS table. For example, user2 creates the view v1 by using the statement SELECT c11 FROM user1.t; the dependency manager tracks the dependency of view v1 on the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S). The dependency manager knows that the view is dependent on the SELECT privilege type but does not track exactly which columns the view is dependent on. When a REVOKE statement for a column-level privilege is issued for a grantee, table ID, and type, all of the objects that are dependent on the grantee, table ID, and type are dropped. For example, if user1 revokes the SELECT privilege on column c12 on table user1.t1 from user2, the row in SYSCOLPERMS for GRANTEE(user2), TABLEID(user1.t1), TYPE(S) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1, and the view is dropped, even though the view is not dependent on the column c12 for GRANTEE(user2), TABLEID(user1.t1), TYPE(S). Revoke examples To revoke the SELECT privilege on table t from the authorization IDs 'Maria' and 'Harry', use the following syntax: SQL>REVOKE SELECT ON TABLE t FROM maria,harry To revoke the UPDATE and TRIGGER privileges on table t from the authorization IDs 'Anita' and 'Zhi', use the following syntax: SQL>REVOKE UPDATE, TRIGGER ON TABLE t FROM anita,zhi To revoke the SELECT privilege on table s.v from all users, use the following syntax: SQL>REVOKE SELECT ON TABLE s.v FROM PUBLIC To revoke the UPDATE privilege on columns c1 and c2 of table s.v from all users, use the following syntax: SQL>REVOKE UPDATE (c1,c2) ON TABLE s.v FROM PUBLIC To revoke the EXECUTE privilege on procedure p from the authorization ID 'George', use the following syntax: SQL>REVOKE EXECUTE ON PROCEDURE p FROM george RESTRICT
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-001684
- Version
- O112-C2-020500
- Vuln IDs
-
- V-52191
- Rule IDs
-
- SV-66407r1_rule
Checks: C-54249r1_chk
Check DBMS settings to determine whether it will notify appropriate individuals when accounts are modified. If the DBMS does not notify appropriate individuals when accounts are modified, this is a finding.
Fix: F-57009r1_fix
Working with the DBA and site management, determine the appropriate individuals (by job role) to be notified. If Oracle Audit Vault is available, configure it to notify the appropriate individuals when accounts are modified. If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing feature to record account-modification activity. Create and deploy a mechanism, such as a frequently-run job, to monitor the SYS.AUD$ table for these records and to notify the appropriate individuals.
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-001493
- Version
- O112-C2-009600
- Vuln IDs
-
- V-52193
- Rule IDs
-
- SV-66409r1_rule
Checks: C-54247r1_chk
Review access permissions to tools used to view or modify audit log data. These tools may include the DBMS itself or tools external to the database. If appropriate permissions and access controls to prevent unauthorized access are not applied to these tools, this is a finding.
Fix: F-57007r1_fix
Add or modify access controls and permissions to tools used to view or modify audit log data. Tools must be accessible by authorized personnel only.
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-001685
- Version
- O112-C2-020600
- Vuln IDs
-
- V-52195
- Rule IDs
-
- SV-66411r1_rule
Checks: C-54253r1_chk
Check DBMS settings to determine whether it will notify appropriate individuals when account disabling actions are taken. If the DBMS does not notify appropriate individuals when account disabling actions are taken, this is a finding.
Fix: F-57013r1_fix
Working with the DBA and site management, determine the appropriate individuals (by job role) to be notified. If Oracle Audit Vault is available, configure it to notify the appropriate individuals when accounts are disabled. If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing feature to record account-disabling activity. Create and deploy a mechanism, such as a frequently-run job, to monitor the SYS.AUD$ table for these records and to notify the appropriate individuals.
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-001494
- Version
- O112-C2-009700
- Vuln IDs
-
- V-52197
- Rule IDs
-
- SV-66413r1_rule
Checks: C-54251r1_chk
Review access permissions to tools used to view or modify audit log data. These tools may include the DBMS itself or tools external to the database. If appropriate permissions and access controls are not applied to prevent unauthorized modification of these tools, this is a finding.
Fix: F-57011r1_fix
Add or modify access controls and permissions to tools used to view or modify audit log data. Tools must be modifiable by authorized personnel only.
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-001686
- Version
- O112-C2-020700
- Vuln IDs
-
- V-52199
- Rule IDs
-
- SV-66415r1_rule
Checks: C-54257r1_chk
Check DBMS settings to determine whether it will notify appropriate individuals when accounts are terminated. If the DBMS does not notify appropriate individuals when accounts are terminated, this is a finding.
Fix: F-57017r1_fix
Working with the DBA and site management, determine the appropriate individuals (by job role) to be notified. If Oracle Audit Vault is available, configure it to notify the appropriate individuals when accounts are terminated. If Oracle Audit Vault is not available, configure the Oracle DBMS's auditing feature to record account-termination activity. Create and deploy a mechanism, such as a frequently-run job, to monitor the SYS.AUD$ table for these records and to notify the appropriate individuals.
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-001495
- Version
- O112-C2-009800
- Vuln IDs
-
- V-52201
- Rule IDs
-
- SV-66417r1_rule
Checks: C-54255r1_chk
Review access permissions to tools used to view or modify audit log data. These tools may include the DBMS itself or tools external to the database. If appropriate permissions and access controls are not applied to prevent unauthorized deletion of these tools, this is a finding.
Fix: F-57015r1_fix
Add or modify access controls and permissions to tools used to view or modify audit log data. Only authorized personnel must be able to delete these tools.
- RMF Control
- AC-5
- Severity
- L
- CCI
- CCI-000037
- Version
- O112-C3-003300
- Vuln IDs
-
- V-52203
- Rule IDs
-
- SV-66419r1_rule
Checks: C-54261r1_chk
Obtain a list of privileges assigned to the DBMS user accounts. If any direct privilege assignments exist that can be assigned to a role, this is a finding. Obtain a list of privileges assigned to the DBMS user accounts: SQL>select * from dba_sys_privs where grantee='DBA' order by privilege; Check to see what roles are assigned to a user: SQL>select * from user_role_privs; Check to see what privileges are assigned to a role: SQL>select * from role_sys_privs; Show privileges by object: set linesize 121 col select_priv format a10 col insert_priv format a10 col update_priv format a10 col delete_priv format a10 SELECT table_name, grantee, MAX(DECODE(privilege, 'SELECT', 'SELECT')) AS select_priv, MAX(DECODE(privilege, 'DELETE', 'DELETE')) AS delete_priv, MAX(DECODE(privilege, 'UPDATE', 'UPDATE')) AS update_priv, MAX(DECODE(privilege, 'INSERT', 'INSERT')) AS insert_priv FROM dba_tab_privs WHERE grantee IN ( SELECT role FROM dba_roles) GROUP BY table_name, grantee; This query will list the system privileges assigned to a specific user: SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS" FROM ( SELECT NULL grantee, username granted_role FROM dba_users WHERE username LIKE UPPER('%&uname%') UNION SELECT grantee, granted_role FROM dba_role_privs UNION SELECT grantee, privilege FROM dba_sys_privs) START WITH grantee IS NULL CONNECT BY grantee = prior granted_role; Data Dictionary Objects Related To System Privileges} all_sys_privs session_privs user_sys_privs dba_sys_privs system_privilege_map
Fix: F-57019r1_fix
Define DBMS user roles based on privilege and job function requirements. Assign the required privileges to the role and assign the role to authorized DBMS user accounts. Revoke any privileges directly assigned to DBMS user accounts and assign them to a role the DBMS user already has assigned.
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-001348
- Version
- O112-C2-010000
- Vuln IDs
-
- V-52205
- Rule IDs
-
- SV-66421r1_rule
Checks: C-54259r1_chk
Check with the database administrator, storage administrator or system administrator, as applicable at the site, to verify that Oracle is configured EITHER to perform backups of the audit data specifically, OR, with appropriate permissions granted, to permit a third-party tool to do so. Test the backup process. Test the restore process (using a non-production system as the target). If Oracle is not so configured, this is a finding. If the test run of the backup and restore fails, this is a finding.
Fix: F-57021r1_fix
Utilize DBMS features or other software that supports the ability to back up audit data and records onto a system or media different from the system being audited on an organization-defined frequency. EITHER use Oracle features (such as Backup or Data Pump) to perform backups of the audit data specifically, OR grant appropriate permissions to permit a third-party tool to do so.
- RMF Control
- AC-8
- Severity
- L
- CCI
- CCI-000048
- Version
- O112-C3-005300
- Vuln IDs
-
- V-52207
- Rule IDs
-
- SV-66423r1_rule
Checks: C-54263r1_chk
If all applications using the database (and having an interactive user interface) display a login banner with the prescribed wording, and the operating system hosting the database displays a login banner with the prescribed wording, stop here: this is not a finding against the DBMS. Open the SQLNET.ORA file in a text editor. If the SEC_USER_UNAUTHORIZED_ACCESS_BANNER parameter is not present, this is a finding. If the SEC_USER_UNAUTHORIZED_ACCESS_BANNER parameter exists but does not refer to an accessible file, this is a finding. If the SEC_USER_UNAUTHORIZED_ACCESS_BANNER parameter refers to an accessible file, but the file does not contain the prescribed wording, this is a finding. If the SEC_USER_AUDIT_ACTION_BANNER parameter is not present, this is a finding. If the SEC_USER_AUDIT_ACTION_BANNER parameter exists but does not refer to an accessible file, this is a finding. If the SEC_USER_AUDIT_ACTION_BANNER parameter refers to an accessible file, but the file does not contain the prescribed wording, this is a finding.
Fix: F-57023r1_fix
If necessary, take the following steps: Create a text file containing the prescribed wording. Ensure the file is accessible by the database owner. Open the SQLNET.ORA file in a text editor. If the SEC_USER_UNAUTHORIZED_ACCESS_BANNER parameter is not present, create it. If the SEC_USER_AUDIT_ACTION_BANNER parameter is not present, create it. Set both parameter values equal to the complete path of the banner file. Example: SEC_USER_UNAUTHORIZED_ACCESS_BANNER=/opt/oracle/admin/data/unauthwarning.txt Configure all applications that use the database and have an interactive user interface to display the banner upon login.
- RMF Control
- AU-7
- Severity
- L
- CCI
- CCI-000156
- Version
- O112-C3-008700
- Vuln IDs
-
- V-52209
- Rule IDs
-
- SV-66425r1_rule
Checks: C-54267r1_chk
Verify that audit reduction capabilities are in place for the Oracle audit tables. Since Oracle has no reduction capability per se, a third-party tool or in-house-developed software must be in place to provide this functionality. If this capability has not been implemented, this is a finding.
Fix: F-57027r1_fix
Deploy software capable of performing audit table reduction.
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-001350
- Version
- O112-C2-010100
- Vuln IDs
-
- V-52211
- Rule IDs
-
- SV-66427r1_rule
Checks: C-54265r1_chk
Review DBMS settings to determine whether the DBMS is using cryptographic mechanisms to protect audit data records and integrity. If cryptographic mechanisms are not used, this is a finding. - - - - - First check to see if auditing is turned on. If auditing is not turned on, the value will be NONE. sqlplus connect as sysdba SQL> show parameter audit_trail NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_trail string DB,EXTENDED SQL> show parameter audit_trail NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_trail string NONE Now we know if auditing is enabled. Next we need to see what tablespace the AUD$ table is in. SQL> SELECT table_name, tablespace_name FROM dba_tables WHERE table_name ='AUD$'; TABLE_NAME TABLESPACE_NAME -------------- ------------------------------ AUD$ SYSTEM Now we know what auditing is set to and the tablespace auditing is deployed in. Now we can check to see if the tablespace the AUD$ table is located in is encrypted by querying DBA_TABLESPACES. When prompted, use the tablespace name listed above. SQL> set linesize 121 SQL> col tablespace_name format a20 SQL> col encrypted format a3 SQL> select tablespace_name, encrypted from dba_tablespaces where tablespace_name = '&tablespace_name'; The following data dictionary views maintain information about the encryption status of a tablespace. You can query these views to verify that a tablespace has been encrypted. If the tablespace containing the AUD$ table is not encrypted, this is a finding.
Fix: F-57025r2_fix
The DBMS must use cryptographic mechanisms to protect audit data records and integrity. - - - - - If the check revealed that auditing is enabled and the tablespace holding the audit table is encrypted, there is no fix required. If auditing is not enabled, use the following steps to enable auditing. sqlplus connect as sysdba Turn on Oracle audit a. If the database uses an spfile SQL> alter system set audit_trail=DB,EXTENDED scope=spfile ; System altered. b. if database uses pfile, modify init<Sid>.ora directly. For these changes to take place, the database must be restarted. Next we create an encrypted tablespace. Before you can encrypt or decrypt tablespaces, you must generate or set a master encryption key. The tablespace master encryption key is stored in an external security module and is used to encrypt the TDE tablespace encryption keys. Check to ensure that the ENCRYPTION_WALLET_LOCATION (or WALLET_LOCATION) parameter in the sqlnet.ora file points to the correct software wallet location. For example: ENCRYPTION_WALLET_LOCATION= (SOURCE=(METHOD=FILE)(METHOD_DATA= (DIRECTORY=/app/wallet))) Oracle Database 11g Release 2 (11.2) uses the same master encryption key for both TDE column encryption and TDE tablespace encryption. When you issue the ALTER SYSTEM SET ENCRYPTION KEY command, a unified master encryption key is created for both TDE column encryption and TDE tablespace encryption. Resetting the Tablespace Master Encryption Key Oracle Database 11g Release 2 (11.2) uses a unified master encryption key for both TDE column encryption and TDE tablespace encryption. When you reset (rekey) the master encryption key for TDE column encryption, the master encryption key for TDE tablespace encryption also gets reset. The ALTER SYSTEM SET ENCRYPTION KEY command resets the tablespace master encryption key. Before you can create an encrypted tablespace, the Oracle wallet containing the tablespace master encryption key must be open. The wallet must also be open before you can access data in an encrypted tablespace. The security administrator needs to open the Oracle wallet after starting the Oracle instance. A restart of the Oracle instance requires the security administrator to open the wallet again. The security administrator also needs to open the wallet before performing database recovery operations. This is because background processes may require access to encrypted redo and undo logs. When performing database recovery, the wallet must be opened before opening the database. This is illustrated in the following statements: SQL> STARTUP MOUNT; SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "password"; SQL> ALTER DATABASE OPEN; You can also choose to use auto login wallets, if your environment does not require the extra security provided by a wallet that needs to be explicitly opened. However, this is not the recommended practice. Creating an Encrypted Tablespace The CREATE TABLESPACE command enables you to create an encrypted tablespace. The permanent_tablespace_clause enables you to choose the encryption algorithm and the key length for encryption. The ENCRYPT keyword in the storage_clause encrypts the tablespace. The following syntax illustrates this: CREATE [ BIGFILE | SMALLFILE ] { permanent_tablespace_clause | temporary_tablespace_clause | undo_tablespace_clause } ; Where, permanent_tablespace_clause=TABLESPACE , ENCRYPTION [USING algorithm] storage_clause Where, storage_clause=[ENCRYPT] where: The encryption algorithm can have one of the following values: 3DES168 AES128 AES192 AES256 The key lengths are included in the names of the algorithms themselves. If no encryption algorithm is specified, the default encryption algorithm is used. The default encryption algorithm is AES128. Note: The ENCRYPTION keyword in the permanent_tablespace_clause is used to specify the encryption algorithm. The ENCRYPT keyword in the storage_clause actually encrypts the tablespace. For security reasons, a tablespace cannot be encrypted with the NO SALT option. Commands to create Encrypted Tablespace CREATE TABLESPACE securespace DATAFILE '/home/user/oradata/secure01.dbf' SIZE 150M ENCRYPTION USING '3DES168' DEFAULT STORAGE(ENCRYPT); This creates a tablespace called securespace2 using an algorithm of 3DES168. You cannot encrypt an existing tablespace. However, you can import data into an encrypted tablespace using the Oracle Data Pump utility. You can also use SQL commands like CREATE TABLE...AS SELECT...or ALTER TABLE...MOVE... to move data into an encrypted tablespace. The CREATE TABLE...AS SELECT... command enables you to create a table from an existing table. The ALTER TABLE...MOVE... command enables you to move a table into the encrypted tablespace. Then we move the sys.aud$ from system tablespace to securespace tablespace. SQL> exec DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD, audit_trail_location_value => 'securespace'); PL/SQL procedure successfully completed. Then check the tablespace the table is stored in. SQL> SELECT table_name, tablespace_name FROM dba_tables WHERE table_name ='AUD$'; TABLE_NAME TABLESPACE_NAME ------------------------------ ------------------------------ AUD$ SECURESPACE
- RMF Control
- AU-7
- Severity
- L
- CCI
- CCI-000157
- Version
- O112-C3-008800
- Vuln IDs
-
- V-52213
- Rule IDs
-
- SV-66429r1_rule
Checks: C-54269r1_chk
Verify that audit reduction capabilities are in place for the Oracle audit tables. Since Oracle has no reduction capability per se, a third-party tool or in-house-developed software must be in place to provide this functionality. This must include the ability to report on the excluded audit data. If this capability has not been implemented, this is a finding.
Fix: F-57029r1_fix
Deploy software capable of performing audit table reduction and of reporting on the excluded audit data.
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-001352
- Version
- O112-C2-010200
- Vuln IDs
-
- V-52215
- Rule IDs
-
- SV-66431r1_rule
Checks: C-54271r1_chk
Review locations of audit logs generated as a result of remote accesses to privileged accounts and the execution of privileged functions. Verify there are appropriate controls and permissions to protect the audit information from unauthorized access. If appropriate controls and permissions do not exist, this is a finding. - - - - - The recommended log level of DB EXTENDED will place rows in an audit table. If audit logs are generated change the settings to produce audit records in the AUD$ Table. Check to see if auditing is turned on at the level required to generate audit records in a table and not log files written to a directory. Enter the show parameter command and see what is returned. If the AUDIT_TRAIL is not DB or DB, EXTENDED this is a finding. With DB and/or DB, EXTENDED all of the audit records are written to a database table. sqlplus as connect as sysdba SQL> show parameter audit_trail NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_trail string DB,EXTENDED
Fix: F-57031r1_fix
Add controls and modify permissions to protect database audit log data generated, as a result of remote accesses to privileged accounts and the execution of privileged functions. - - - - - If auditing is not enabled at the DB, EXTENDED level, use the following steps to enable auditing at the DB, EXTENDED level. sqlplus connect as sysdba Turn on Oracle audit a. If the database uses an spfile SQL> alter system set audit_trail=DB,EXTENDED scope=spfile ; System altered. Note: You must restart the database for the change to take place. b. if database use pfile, modify init<Sid>.ora directly. For these changes to take place, the database must be restarted.
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-001094
- Version
- O112-C3-019200
- Vuln IDs
-
- V-52217
- Rule IDs
-
- SV-66433r1_rule
Checks: C-54273r1_chk
Review DBMS settings and custom database code to determine whether the DBMS or database application code could be used to launch DoS attacks. If the DBMS or custom database code would facilitate DoS-style attacks against other information systems, this is a finding. - - - - - The Listener is the key for a denial of service attack. The idea is to flood the database with connection requests so no more connections can be served and ultimately bring down the listener. Check to see how many of these steps to secure the Oracle Listener are in place at your site. (Please refer to the Fix for more detail on implementing these protections.) 1. DISABLING THE DEFAULT LISTENER 2. SET THE LISTENER PASSWORD 3. TURN ON LISTENER LOGGING 4. SET ADMIN_RESTRICTIONS IN THE LISTENER.ORA 5. SET LOCAL_OS_AUTHENTICATION IN THE LISTENER.ORA 6. SET PROTECTION AGAINS CRAFTED NETWORK PACKETS ON DATABASE LEVEL IN 11G. 7. APPLY LISTENER SECURITY PATCHES 8. BLOCK SQL*NET ON FIREWALLS 9. SECURE THE $TNS_ADMIN DIRECTORY 10. SECURE TNSLSNR AND LSNRCTL EXECUTABLES 11. REMOVE UNUSED SERVICES 12. CHANGE THE TNS PORT NUMBER DEFAULT 13. SETUP VALID NODE CHECKING 14. MONITOR THE LOGFILE 15. SET CONNECTION RATE
Fix: F-57033r2_fix
Configure DBMS settings to restrict functionality that could be used to initiate DoS attacks. Modify custom database code to prevent its being used to initiate DoS attacks. Secure the Oracle Listener in 15 steps: 1. DISABLING THE DEFAULT LISTENER 2. SET THE LISTENER PASSWORD 3. TURN ON LISTENER LOGGING 4. SET ADMIN_RESTRICTIONS IN THE LISTENER.ORA 5. SET LOCAL_OS_AUTHENTICATION IN THE LISTENER.ORA 6. SET PROTECTION AGAINST CRAFTED NETWORK PACKETS ON DATABASE LEVEL IN 11G. 7. APPLY LISTENER SECURITY PATCHES 8. BLOCK SQL*NET ON FIREWALLS 9. SECURE THE $TNS_ADMIN DIRECTORY 10. SECURE TNSLSNR AND LSNRCTL EXECUTABLES 11. REMOVE UNUSED SERVICES 12. CHANGE THE TNS PORT NUMBER DEFAULT 13. SETUP VALID NODE CHECKING 14. MONITOR THE LOGFILE 15. SET CONNECTION RATE Step 1 - Disable the Default Listener All listeners have a name instead of the name LISTENER and have a startup protection. LISTENER=(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST=)(PORT = 0))) This configuration prevents the default listener from starting. The error serves as a reminder to set TNS_ADMIN, if necessary, and to supply the correct listener name to the lsnrctl command. $ lsnrctl start ... Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=0))) TNS-01103: Protocol specific component of the address is incorrectly specified TNS-12533: TNS:illegal ADDRESS parameters TNS-12560: TNS:protocol adapter error TNS-00503: Illegal ADDRESS parameters Step 2 - Set the Listener Password Set the Listener password to stop most attacks and security issues. Setting the password manually in listener.ora using the PASSWORDS_ parameter will result in the password being stored in cleartext. LSNRCTL> set current_listener LSNRCTL> change_password Old password: New password: Reenter new password: LSNRCTL> set password : LSNRCTL> save_config Check the listener.ora Step 3 - Turn on Logging Turn on logging for all listeners in order to capture Listener commands and brute force password attacks. LSNRCTL> set current_listener LSNRCTL> set password : LSNRCTL> set log_directory /network/admin LSNRCTL> set log_file .log LSNRCTL> set log_status on LSNRCTL> save_config Step 4 - Set ADMIN_RESTRICTIONS in the listener.ora With ADMIN_RESTRICTIONS_listener=on, the listener rejects SET commands that might have been sent from an intruder on a remote system. It only allows changes through lsnrctl reload on the local system LISTENER.ORA. ADMIN_RESTRICTIONS_ = ON Step 5 - Set LOCAL_OS_AUTHENTICATION in the listener.ora By default, the Listener cannot be remotely managed and can only be managed locally by the owner of the tnslsnr process (usually oracle) since Oracle 10G. LOCAL_OS_AUTHENTICATION_ = ON Step 6 - Set Protection against crafted network packets on database level in 11g. SEC_PROTOCOL_ERROR_TRACE_ACTION: SEC_PROTOCOL_ERROR_TRACE_ACTION specifies the action that the database should take when bad packets are received from a possibly malicious client. SEC_PROTOCOL_ERROR_TRACE_ACTION = { NONE | TRACE | LOG | ALERT } NONE: The database server ignores the bad packets and does not generate any trace files or log messages. TRACE: A detailed trace file is generated when bad packets are received, which can be used to debug any problems in client/server communication. LOG: A minimal log message is printed in the alert logfile and in the server trace file. A minimal amount of disk space is used. ALERT: An alert message is sent to a DBA or monitoring console. SEC_PROTOCOL_ERROR_FURTHER_ACTION SEC_PROTOCOL_ERROR_FURTHER_ACTION specifies the further execution of a server process when receiving bad packets from a possibly malicious client. SEC_PROTOCOL_ERROR_FURTHER_ACTION = { CONTINUE | (DELAY,integer) | (DROP,integer) } CONTINUE: The server process continues execution. The database server may be subject to a Denial of Service (DoS) if bad packets continue to be sent by a malicious client. (DELAY,integer):The client experiences a delay of integer seconds before the server process accepts the next request from the same client connection. Malicious clients are prevented from excessive consumption of server resources while legitimate clients experience degradation in performance but can continue to function. (DROP,integer): The server forcefully terminates the client connection after integer bad packets. The server protects itself at the expense of the client (for example, a client transaction may be lost). The client may reconnect and attempt the same operation. SEC_MAX_FAILED_LOGIN_ATTEMPTS SEC_MAX_FAILED_LOGIN_ATTEMPTS specifies the number of authentication attempts that can be made by a client on a connection to the server process. After the specified number of failure attempts, the connection will be automatically dropped by the server process. SEC_MAX_FAILED_LOGIN_ATTEMPTS = n (10 is the default) Values ranges 1 to unlimited Step 7 - Apply Listener Security Patches Critical Patch Updates are cumulative, therefore, the latest patch will contain all previous security patches for the Listener. Step 8 - Block SQL*Net on Firewalls Firewall filters should be designed to only allow SQL*Net traffic from known application and web servers. SQL*Net traffic from application servers in the DMZ should be permitted only to access specific database servers. Step 9 - Secure the $TNS_ADMIN Directory Place the listener.ora, sqlnet.ora, and protocol.ora files in the $TNS_ADMIN directory. It should be read/write/execute for only the primary oracle account and no permissions for any other account (for UNIX and Linux 0600). The tnsnames.ora file permissions should be set to 0644 on UNIX and Linux. Step 10 - Secure TNSLSNR and LSNRCTL executables The executables tnslsnr and lsnrctl in the $ORACLE_HOME/bin should be protected. Set the file permissions to 0751 on UNIX and Linux as recommended by Oracle. It is possible to change the file permissions to 0700 which would be more secure, although this should be thoroughly tested in your environment. Step 11 - Remove Unused Services Default installations have a listener entry for PL/SQL External Procedures (ExtProc or PLSExtProc) and databases with default services. Remove the Unused services from database or listener. Step 12 - Change the TNS Port Number Default (1521) Stop automated attacks and detection of the Listener in networks; the default NTS port number should be changed from 1521 to a port outside of the 1521-1550 and 1600-1699 ranges. The database initialization parameter LOCAL_LISTENER must be set so that the database is able to dynamically register with the Listener. See Metalink Note ID 359277.1 Step 13 - Setup Valid Node Checking Valid node checking is an interesting security feature that protects DBMS instances from malevolent or errant Oracle Net connections over TCP/IP, without the need for a firewall or IP address filtering at the operating system-level. The feature is controlled by the three parameters tcp.validnode_checking, tcp.invited_nodes, and tcp.excluded_nodes. Valid node checking could be enabled dynamically in Oracle10g and Oracle11g. This works only if the configuration file sqlnet.ora was present when the TNS Listener was started. There's no sense in setting both tcp.invited_nodes and tcp.excluded_nodes at the same time, since even nodes not mentioned explicitly as excluded nodes will still be excluded when tcp.invited_nodes is set. tcp.validnode_checking Turns valid node checking on or off tcp.invited_nodes List of nodes that may connect to the TNS Listener. A comma separated list of host names and/or IP addresses on a single line tcp.excluded_nodes List of nodes that are denied a connection to the TNS Listener. A comma-separated list of host names and/or IP addresses on a single line. Step 14 - Monitor the logfile The logfile may contain TNS-01169, TNS-01189, TNS-01190, or TNS-12508 errors, which may signify attacks or inappropriate activity, monitor the logfile and generate an alert whenever these errors are encountered. Step 15 - Set Connect Rate CONNECTION_RATE_LISTENER=10 LISTENER= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=yes)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=yes)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526)) ) LISTENER= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=8)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=12)) (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1526)) ) For more information see: Oracle Support Note ID 92602.1 "How to Password Protect the Listener" Oracle Support Note ID 124742.1 "Vulnerability in the Oracle Listener Program" Oracle Support Note ID 260986.1 "Setting Listener Passwords With an Oracle 10g Listener" Oracle Support Note ID 359277.1 "Changing Default Listener Port Number" Oracle Support Note ID 332785.1 "How To Disable Local Os Authentication For Lsnrctl Utility"
- RMF Control
- CM-5
- Severity
- M
- CCI
- CCI-000345
- Version
- O112-C2-010300
- Vuln IDs
-
- V-52219
- Rule IDs
-
- SV-66435r1_rule
Checks: C-54275r1_chk
Review DBMS settings and vendor documentation to ensure the database supports and does not interfere with enforcement of logical access restrictions associated with changes to the DBMS configuration and to the database itself. If the DBMS software in any way restricts the implementation of logical access controls implemented to protect its integrity or availability, this is a finding.
Fix: F-57035r1_fix
Configure the DBMS to allow implementation of logical access restrictions aimed at protecting the DBMS from unauthorized changes to its configuration and to the database itself. - - - - - When the Oracle Database is installed on a Unix-like operating system, the required umask is 022, and the file permissions are set so that any modifications to the startup files can only be performed by the owner of the software, a member of the group DBA or the root user. Changing the umask has caused problems when patching the environment. If changes are to be made, they should be reverted to the status they were in before the modification for patching and upgrades.
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-001095
- Version
- O112-C3-019300
- Vuln IDs
-
- V-52221
- Rule IDs
-
- SV-66437r1_rule
Checks: C-54277r1_chk
Review DBMS configuration to determine whether DBMS settings to identify long-running SQL queries and alert appropriate personnel are enabled. If DBMS does not identify long-running SQL queries and alert appropriate personnel, this is a finding. Use the following commands to determine the established profiles and the users and resource limits assigned to them. $ sqlplus connect as sysdba SQL> set linesize 121 SQL> col username format a20 SQL> col profile format a30 SQL> col resource_name format a 32 SQL> col resource_type format a14 SQL> col limit format a20 SQL> select a.username, a.profile, b.resource_name, b.resource_type, b.limit from dba_users a, dba_profiles b where a.profile = b.profile and resource_type='KERNEL' order by a.profile;
Fix: F-57037r1_fix
Configure DBMS settings to identify long-running SQL queries and alert appropriate personnel. Create a user profile and assign users to the profile. In the profile itself, set resource limits on CPU per session, CPU per call, Number of rows returned or any of the following resources. If a user session exceeds the predefined session limits, a message is provided to the user and also in the audit log. Creation of PROFILES - Profiles are a named set of resource limits. By default, when you create a user, they are given the default profile. The default profile provides unlimited use of all resources. The syntax to create a profile follows: SQL> CREATE PROFILE LIMIT resource_parameters|password_parameters--;-> Resource_parameters (you can specify multiple parameters per command): [SESSIONS_PER_USER n|UNLIMITED|DEFAULT] [CPU_PER_SESSION n|UNLIMITED|DEFAULT] [CPU_PER_CALL n|UNLIMITED|DEFAULT] [CONNECT_TIME n|UNLIMITED|DEFAULT] [IDLE_TIME n|UNLIMITED|DEFAULT] [LOGICAL_READS_PER_SESSION n|UNLIMITED|DEFAULT] [LOGICAL_READS_PER_CALL n|UNLIMITED|DEFAULT] [COMPOSITE_LIMIT n|UNLIMITED|DEFAULT] [PRIVATE_SGA n [K|M]|UNLIMITED|DEFAULT] CREATE PROFILE enduser LIMIT CPU_PER_SESSION 60000 LOGICAL_READS_PER_SESSION 1000 CONNECT_TIME 30 PRIVATE_SGA 102400 CPU_PER_CALL UNLIMITED COMPOSITE LIMIT 60000000 FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LIFE_TIME 90 PASSWORD_REUSE_TIME 180 PASSWORD_LOCK_TIME 3 PASSWORD_GRACE_TIME 3 Verify_function_11G; You can assign a profile to a user when you create the user or by altering the user. The syntax to alter the profile for a user is: SQL> ALTER USER PROFILE ; For example: SQL>ALTER USER scott PROFILE appuser; You must have the CREATE PROFILE system privilege to create a profile. To alter a profile, you must be the creator of the profile or have the ALTER PROFILE system privilege. To assign a profile to a user, you must have the CREATE USER or ALTER USER system privilege. Profiles and Resource Limits The default cost assigned to a resource is unlimited. By setting resource limits, you can prevent users from performing operations that will tie up the system and prevent other users from performing operations. You can use resource limits for security to ensure that users log off the system and do not leave the session connected for long periods of time. You can also assign a composite cost to each profile . The system resource limits can be enforced at the session-level, the call level, or both. The session-level is from the time the user logs into the database until the user exits. The call level is for each SQL command issued. Session-level limits are enforced for each connection. When a session-level limit is exceeded, only the last SQL command issued is rolled back, and no further work can be performed until a commit, rollback or exit is performed. Table 7.15 lists the system resources which can be regulated at the session-level. Note: if you use parallel query option (PQO), the resources are applied to each new session, not accumulated over all of the sessions that a parallel operation uses. RESOURCES REGULATED AT THE session-level SYSTEM RESOURCE DEFINITION ---------------- ----------- CPU_PER_SESSION total CPU time in hundredths of seconds SESSIONS_PER_USER number of concurrent sessions for a user CONNECT_TIME allowed connection time in minutes IDLE_TIME inactive time on the server in minutes LOGICAL_READS_PER_SESSION number of data blocks read including both physical and logical reads from memory and disk PRIVATE_SGA bytes of SGA used in a database with the multithreaded server (in K or M) You can combine the CPU_PER_SESSION, LOGICAL_READS_PER_SESSION, CONNECT_TIME, and PRIVATE_SGA to create a COMPOSITE LIMIT. Call-level limits are enforced during the execution of each SQL statement. When a call-level limit is exceeded, the last SQL command issued is rolled back. All the previous statements issued are still valid, and the user can continue to execute other SQL statements. The following system resources can be regulated at the call level: * CPU_PER_CALL for the CPU time for the SQL statement * LOGICAL_READS_PER_CALL for the number of data blocks read for the SQL statement The assignment of a cost to a resource can be performed with the ALTER RESOURCE COST command. Resource limits that you set explicitly for a user take precedence over the resource costs in an assigned profile. The command line syntax for this command is: >-ALTER RESOURCE COST ---------------------------------------------------;--> |-[CPU_PER_SESSION n|UNLIMITED|DEFAULT]-----------| |-[CONNECT_TIME n|UNLIMITED|DEFAULT]--------------| |-[LOGICAL_READS_PER_SESSION n|UNLIMITED|DEFAULT]-| |-[PRIVATE_SGA n [K|M]|UNLIMITED|DEFAULT]--------| For example, ALTER RESOURCE COST CONNECT_TIME 100; Use of resource limits is set in the database initialization parameter RESOURCE_LIMIT=TRUE. By default this parameter is set to false. This parameter can be changed interactively with an ALTER SYSTEM command. The DBA_PROFILES view provides information on all the profiles and the resource limits for each profile. The RESOURCE_COST view shows the unit cost associated with each resource. Each user can find information on his resources and limits in the USER_RESOURCE_LIMITS view. Below is a description of these data dictionary views. DBA_PROFILES Column Definition ----------- ------------ Profile the name given to the profile Resource_name the name of the resource assigned to the profile Limit the limit placed on the profile RESOURCE_COST Column Definition ------------ ------------ Resource_name name of the resource Unit_cost cost assigned USER_RESOURCE_LIMITS Column Definition ------------- ------------- Resource_name the name of the resource Limit the limit placed on the user
- RMF Control
- CM-5
- Severity
- M
- CCI
- CCI-001499
- Version
- O112-C2-011000
- Vuln IDs
-
- V-52223
- Rule IDs
-
- SV-66439r1_rule
Checks: C-54279r1_chk
Review system documentation to identify accounts authorized to own database objects. Review accounts in DBMS that own objects. If any database objects are found to be owned by users not authorized to own database objects, this is a finding. - - - - - Query the object DBA_OBJECTS to show the users who own objects in the database. The query below will return all of the users who own objects. sqlplus connect as sysdba SQL>select distinct(owner) from dba_objects; If these owners are not authorized owners, select all of the objects these owners have generated and decide who they should belong to. To make a list of all of the objects, the unauthorized owner has to perform the following query. SQL>select * from dba_objects where owner =&unauthorized_owner;
Fix: F-57039r1_fix
Update system documentation to include list of accounts authorized for object ownership. Re-assign ownership of authorized objects to authorized object owner accounts.
- RMF Control
- SC-6
- Severity
- L
- CCI
- CCI-001096
- Version
- O112-C3-019400
- Vuln IDs
-
- V-52225
- Rule IDs
-
- SV-66441r1_rule
Checks: C-54281r1_chk
Review DBMS settings and documentation to determine if the DBMS restricts resource usage by priority. If the DBMS does not restrict resource usage by priority, this is a finding. - - - - - This capability is available in Oracle at both the user and database level. At the user level, we create resource profiles for users of the database. Resource Parameters SESSIONS_PER_USER Specify the number of concurrent sessions to which you want to limit the user. CPU_PER_SESSION Specify the CPU time limit for a session, expressed in hundredths of seconds. CPU_PER_CALL Specify the CPU time limit for a call (a parse, execute, or fetch), expressed in hundredths of seconds. CONNECT_TIME Specify the total elapsed time limit for a session, expressed in minutes. IDLE_TIME Specify the permitted periods of continuous inactive time during a session, expressed in minutes. Long-running queries and other operations are not subject to this limit. LOGICAL_READS_PER_SESSION Specify the permitted number of data blocks read in a session, including blocks read from memory and disk. LOGICAL_READS_PER_CALL Specify the permitted number of data blocks read for a call to process a SQL statement (a parse, execute, or fetch). PRIVATE_SGA Specify the amount of private space a session can allocate in the shared pool of the system global area (SGA). COMPOSITE_LIMIT Specify the total resource cost for a session, expressed in service units. To check the resource controls assigned to a user query the DBA_PROFILES and DBA_USERS tables in the following manner. $ sqlplus connect as sysdba SQL> select a.username, a.profile, b.resource_name, b.limit from dba_users a, dba_profiles b where b.resource_type is not null and a.profile = b.profile; The output should look like the output below and display the users and the contents of their profiles. USERNAME PROFILE RESOURCE NAME LIMIT -------- ------- ------------- ----- SCOTT DEFAULT SESSIONS_PER_USER UNLIMITED SCOTT DEFAULT CPU_PER_SESSION UNLIMITED At the Oracle Database layer, the QoS Management helps manage the resources that are shared by applications in a cluster. Oracle Database QoS Management can help identify and resolve performance bottlenecks. Oracle Database QoS Management does not diagnose or tune application or database performance issues. When tuning the performance of your applications, the goal is to achieve optimal performance. Oracle Database QoS Management does not seek to make your applications run faster, but instead works to remove obstacles that prevent your applications from running at their optimal performance levels. Use the console to see if you can access the Oracle Database QoS Management Dashboard To access the Dashboard, perform the following steps: 1. Log in to Oracle Enterprise Manager Database Control as the CRS Administrator user. Click the Cluster tab, if not selected. 2. Go to the Administration page, then click the Dashboard link under the heading Quality of Service Management to open the login screen for Oracle Database QoS Management. 3. A login screen appears, prompting you for the Oracle Database QoS Management administrator (QoSAdmin) credentials. After typing in the username and password, click Login. 4. The Quality of Service Management Dashboard page is displayed after the correct credentials are entered.
Fix: F-57041r1_fix
Implement measures to restrict the usage of resources by priority. - - - - - To implement security at the user level, assign users a profile that limits their resources: Example $ sqlplus connect as sysdba CREATE PROFILE app_user LIMIT SESSIONS_PER_USER 1 IDLE_TIME 30 CPU_PER_SESSION 100 CPU_PER_CALL 100 CONNECT_TIME 600 IDLE_TIME 100; CONNECT_TIME 600; QoS Management Support for Oracle RAC Enterprise Edition Oracle Database Quality of Service (QoS) Management allows system administrators to directly measure application service levels hosted on Oracle RAC Enterprise Edition databases. Using a policy-based architecture, QoS Management correlates accurate run-time performance and resource metrics based on user-defined workload classes. QoS Management then presents them in an integrated Enterprise Manager dashboard to review real-time performance of consolidated applications. In conjunction with Cluster Health Monitor (CHM), QoS Management's memory guard detects nodes that are at risk of failure due to the overcommitment of memory. QoS Management responds by automatically preventing new connections thus preserving existing workloads, and restores connectivity once sufficient memory is available again. Enable Oracle QoS Management at the Database Level 1. Log in to Oracle Enterprise Manager Database Control as the database administrator. If not selected, click the Database tab. 2. Go to the Availability page. 3. Under the heading Services, select Enable/Disable Quality Of Service Management. Enter the Cluster and Database credentials, then click Login. The Enable/Disable QoS Management screen is displayed. 4. You are prompted to enter a password for the APPQOSSYS user. Choose a password and enter it in the Password and Confirm Password fields, click OK. When you provide a password, the following actions take place: The APPQOSSYS account, which enables the Oracle Database QoS Management server to connect to the database, is unlocked and the new password is set. The credentials are written to an Oracle Wallet stored in the Oracle Cluster Repository to enable Oracle Database QoS Management to log in to the database. APPQOS_PLAN is set as the active Oracle Database Resource Manager plan so that Oracle Database QoS Management can adjust CPU access for Performance Classes. By default, the APPQOS_PLAN is replaced during the Oracle Scheduler maintenance window. Oracle recommends that you use the APPQOS_PLAN as the plan during those daily windows because this plan incorporates the consumer groups from the DEFAULT_MAINTENANCE_PLAN plan.
- RMF Control
- SI-2
- Severity
- L
- CCI
- CCI-001237
- Version
- O112-C3-020200
- Vuln IDs
-
- V-52227
- Rule IDs
-
- SV-66443r1_rule
Checks: C-54285r1_chk
Review DBMS vendor documentation to determine whether the DBMS supports automated patch management. If the DBMS does not provide this functionality, determine whether a third-party product is being used for automated patch management. If the DBMS does not support automated patch management, and a third-party product is not utilized to provide this functionality, this is a finding. Use the Oracle-provided OPATCH command to check current patch levels on the database. As the Oracle user, issue the following commands: Unix/Linux: $ cd $ORACLE_HOME $ opatch lsinventory -d Windows: > cd <ORACLE_HOME>\opatch > opatch lsinventory -detail This will generate the patch levels for the home and any specific patches that have been applied to it.
Fix: F-57045r1_fix
Utilize a DBMS product that supports automated patch management, or implement a third-party product to provide this functionality. When the Quarterly CPU is released, check the CPU Notice and note the specific patch number for your system. Follow the process below to apply the security patch. Login to My Oracle Support. Select patches and download your specific patch number and corresponding MD5 checksum. Once the patch is downloaded to the server, check the MD5 checksum to make sure the patch is valid. To check the MD5 Checksum in Linux/Unix, the command is: $md5sum absolute_path_of_file_name - file_name is the complete location of the downloaded file. $md5sum /home/oracle/test.zip a34d8cd98f00cf24e9800998ecf823e4 /home/oracle/test.zip Once the checksum is validated, apply the patch.: $ cd $ORACLE_HOME $ opatch apply Check that the patch was applied and the inventory was updated with the following command (Unix/Linux): $ opatch lsinventory -d Windows: > opatch lsinventory -detail
- RMF Control
- AC-17
- Severity
- M
- CCI
- CCI-000066
- Version
- O112-C2-011400
- Vuln IDs
-
- V-52229
- Rule IDs
-
- SV-66445r1_rule
Checks: C-54283r1_chk
Review organization's access control policies and procedures addressing remote access to the information system. If remote connections are not allowed by the organization, this is NA. (Note that "remote" means "from outside the DoD Information Network (DoDIN)", and that connections via approved Virtual Private Networks (VPNs) are considered to be inside the DoDIN.) Review the DBMS, OS and/or enterprise account management settings to verify access controls and auditing settings exist and they enforce the requirements for remote access defined by the organization. If access controls and auditing do not exist or do not fully enforce the requirements defined in the organization's policies and procedures, this is a finding. Checking to see what Oracle auditing is set to: SQL> show parameter audit_trail NAME TYPE VALUE ------------------------ -------- ------------------------------ audit_trail string NONE If auditing is set to NONE, then this is a finding.
Fix: F-57043r1_fix
Configure DBMS settings to ensure access control and auditing requirements for remote connections are enforced by the DBMS. Once Oracle auditing is enabled, set auditing to DB, EXTENDED. SQL> alter system set audit_trail='DB','EXTENDED' scope=spfile; System altered. SQL> shutdown immediate ORACLE instance shut down. SQL> startup - - - - - Once auditing is initiated, and an audit record is generated, the USERHOST is recorded so remote connections are audited the same as local connections. Oracle's auditing is the same for remote users as for local users.. SQL> desc aud$; Name Null? Type ------------------------------------- --------------- SESSIONID NOT NULL NUMBER ENTRYID NOT NULL NUMBER STATEMENT NOT NULL NUMBER TIMESTAMP# DATE USERID VARCHAR2(30) USERHOST VARCHAR2(128) TERMINAL VARCHAR2(255) ACTION# NOT NULL NUMBER RETURNCODE NOT NULL NUMBER OBJ$CREATOR VARCHAR2(30) OBJ$NAME VARCHAR2(128) AUTH$PRIVILEGES VARCHAR2(16) AUTH$GRANTEE VARCHAR2(30) NEW$OWNER VARCHAR2(30) NEW$NAME VARCHAR2(128) SES$ACTIONS VARCHAR2(19) SES$TID NUMBER LOGOFF$LREAD NUMBER LOGOFF$PREAD NUMBER LOGOFF$LWRITE NUMBER LOGOFF$DEAD NUMBER LOGOFF$TIME DATE COMMENT$TEXT VARCHAR2(4000) CLIENTID VARCHAR2(64) SPARE1 VARCHAR2(255) SPARE2 NUMBER OBJ$LABEL RAW(255) SES$LABEL RAW(255) PRIV$USED NUMBER SESSIONCPU NUMBER NTIMESTAMP# TIMESTAMP(6) PROXY$SID NUMBER USER$GUID VARCHAR2(32) INSTANCE# NUMBER PROCESS# VARCHAR2(16) XID RAW(8) AUDITID VARCHAR2(64) SCN NUMBER DBID NUMBER SQLBIND CLOB SQLTEXT CLOB OBJ$EDITION VARCHAR2(30)
- RMF Control
- CM-7
- Severity
- M
- CCI
- CCI-000381
- Version
- O112-C2-011500
- Vuln IDs
-
- V-52231
- Rule IDs
-
- SV-66447r1_rule
Checks: C-54287r1_chk
Review vendor documentation and vendor websites for vendor-provided demonstration or sample databases, database applications, objects, and files. Review the DBMS to determine if any of the demonstration and sample databases, database applications, or files are installed in the database or are included with the DBMS application. If any are present in the database or are included with the DBMS application, this is a finding. Check for the existence Oracle 11.2.0.3 Default Sample Schema User Accounts: User Account Description Status after Installation --------------- --------------------------------------------------------------------------------- -------------------------- BI Owns the BI (Business Intelligence) schema included in the Oracle Sample Schemas. Expired and locked HR Used to manage the HR (Human Resources) schema. Schema stores information about the Expired and locked employees and the facilities of the company. OE Used to manage the OE (Order Entry) schema. Schema stores product inventories and Expired and locked sales of the company's products through various channels. PM Used to manage the PM (Product Media) schema. Schema contains descriptions and Expired and locked detailed information about each product sold by the company IX Used to manage the IX (Information Exchange) schema. Schema manages shipping through Expired and locked business-to-business (B2B) applications database. SH Used to manage the SH (Sales) schema. Schema stores statistics to facilitate Expired and locked business decisions. SCOTT A demonstration account with a simple schema sqlplus connect as sysdba SQL>select distinct(username) from dba_users; If any of the users listed above are returned it means that there are demo programs installed, so this is a finding.
Fix: F-57047r1_fix
Remove any demonstration and sample databases, database applications, objects, and files from the DBMS. To remove an account and all objects owned by that account (using BI as an example): DROP USER BI CASCADE; To remove objects without removing their owner, use the appropriate DROP statement (DROP TABLE, DROP VIEW, etc.).
- RMF Control
- CM-7
- Severity
- M
- CCI
- CCI-000381
- Version
- O112-C2-011600
- Vuln IDs
-
- V-52233
- Rule IDs
-
- SV-66449r1_rule
Checks: C-54289r1_chk
Review the list of components and features installed with the database. Use the DBMS product installation tool, if supported, and review the product installation documentation. If unused components or features are installed and are not documented and authorized, this is a finding. - - - - - SQL*PLUS can also be used to check to see what is installed in the database: sqlplus connect as sysdba SQL>set linesize 121 SQL>col parameter format a35 SQL>col value format a35 SQL>select * from v$option; This will return all of the database options and their status. TRUE means that the option is installed. If the option is not installed, the option will be set to FALSE.
Fix: F-57049r1_fix
If any components or features are required for operation of applications that will be accessing the DBMS, include them in the system documentation. If any unused components or features are installed and can be uninstalled, uninstall them and remove any database objects and applications that are installed to support them.
- RMF Control
- CM-7
- Severity
- M
- CCI
- CCI-000381
- Version
- O112-C2-011700
- Vuln IDs
-
- V-52235
- Rule IDs
-
- SV-66451r1_rule
Checks: C-54291r1_chk
Review the DBMS for unused components of the system that cannot be uninstalled. If unused components or features are present on the system and are not disabled, this is a finding. - - - - - SQL*PLUS can be used to check to see what is installed in the database: sqlplus connect as sysdba SQL>set linesize 121 SQL>col parameter format a35 SQL>col value format a35 SQL>select * from v$option; This will return all of the database options and their status. TRUE means that the option is installed. If the option is not installed, the option will be set to FALSE. Review the options and check to see what is required.
Fix: F-57051r1_fix
If any components or features are required for operation of applications that will be accessing the DBMS, include them in the system documentation. Disable any unused components or features that cannot be uninstalled.
- RMF Control
- CM-7
- Severity
- M
- CCI
- CCI-000381
- Version
- O112-C2-011800
- Vuln IDs
-
- V-52237
- Rule IDs
-
- SV-66453r1_rule
Checks: C-54293r1_chk
Review the database for definitions of application executable objects stored external to the database. Determine if there are methods to disable use or access, or to remove definitions for external executable objects. Verify any application executable objects listed are authorized by the IAO. If any are not, this is a finding. - - - - - To check for application objects, not delivered by Oracle, execute the following query, which will provide the usernames registered in the database that did not come from the Oracle Installation process.. If there are owners other than these owners that Oracle provides, then there may be executable objects stored either in the database or external to the database, that are called by objects in the database. Check to see what object owners exist in the database and if they call or schedule anything stored externally to the database. (connect as sysdba) SELECT owner, object_name, subobject_name FROM dba_objects WHERE owner NOT IN ( 'ANONYMOUS', 'APEX_030200', 'APEX_PUBLIC_USER', 'APPQOSSYS', 'BI', 'CTXSYS', 'DBSNMP', 'DBVAULTMGR', 'DBVAULTOWNER', 'DIP', 'DVF', 'DVSYS', 'EXFSYS', 'FLOWS_FILES', 'HR', 'IX', 'LBACSYS', 'MDDATA', 'MDSYS', 'MGMT_VIEW', 'OE', 'OLAPSYS', 'ORACLE_OCM', 'ORDDATA', 'ORDPLUGINS', 'ORDSYS', 'OUTLN', 'OWBSYS', 'OWBSYS_AUDIT', 'PM', 'SCOTT', 'SH', 'SI_INFORMTN_SCHEMA', 'SPATIAL_CSW_ADMIN_USR', 'SPATIAL_WFS_ADMIN_USR', 'SYS', 'SYSMAN', 'SYSTEM', 'WMSYS', 'XDB', 'XS$NULL' ) ORDER BY 1, 2, 3; For a summary version: SELECT owner, count(*) FROM dba_objects WHERE owner NOT IN ( 'ANONYMOUS', 'APEX_030200', 'APEX_PUBLIC_USER', 'APPQOSSYS', 'BI', 'CTXSYS', 'DBSNMP', 'DBVAULTMGR', 'DBVAULTOWNER', 'DIP', 'DVF', 'DVSYS', 'EXFSYS', 'FLOWS_FILES', 'HR', 'IX', 'LBACSYS', 'MDDATA', 'MDSYS', 'MGMT_VIEW', 'OE', 'OLAPSYS', 'ORACLE_OCM', 'ORDDATA', 'ORDPLUGINS', 'ORDSYS', 'OUTLN', 'OWBSYS', 'OWBSYS_AUDIT', 'PM', 'SCOTT', 'SH', 'SI_INFORMTN_SCHEMA', 'SPATIAL_CSW_ADMIN_USR', 'SPATIAL_WFS_ADMIN_USR', 'SYS', 'SYSMAN', 'SYSTEM', 'WMSYS', 'XDB', 'XS$NULL' ) GROUP BY owner ORDER BY owner;
Fix: F-57053r1_fix
Disable use of or remove any external application executable object definitions that are not authorized. Disable access to operating system commands from within the DBMS, or document the need for this capability.
- RMF Control
- CM-7
- Severity
- M
- CCI
- CCI-000382
- Version
- O112-C2-011900
- Vuln IDs
-
- V-52239
- Rule IDs
-
- SV-66455r1_rule
Checks: C-54295r1_chk
Review the DBMS settings for functions, ports, protocols, and services that are not approved. If any are found, this is a finding. (For definitive information on Ports, Protocols and Services Management (PPSM), refer to http://iase.disa.mil/ppsm/index.html.) - - - - - In the Oracle database, the communications with the database and incoming requests are performed by the Oracle Listener. The Oracle Listener listens on a specific port or ports for connections to a specific database. The Oracle Listener has configuration files located in the $ORACLE_HOME/network/admin directory. To check the ports and protocols in use, go to that directory and review the SQLNET.ora, LISTENER.ora, and the TNSNAMES.ora. If protocols or ports are in use that are not authorized, this is a finding.
Fix: F-57055r1_fix
Disable functions, ports, protocols, and services that are not approved. - - - - - Change the SQLNET.ora, LISTENER.ora, and TNSNAMES.ora files to reflect the proper use of ports, protocols and services that are approved at the site. If changes to the Listener are made, the files associated with the Listener must be reloaded. Do that by issuing the following commands at the Unix/Linux or Windows prompt. First - issue the command to see what the current status is $ lsnrctl stat Then load the new file that was corrected to reflect site-specific requirements. $ lsnrctl reload Then check the status again to see that the changes have taken place $ lsnrctl stat
- RMF Control
- CP-10
- Severity
- M
- CCI
- CCI-000553
- Version
- O112-C2-012000
- Vuln IDs
-
- V-52241
- Rule IDs
-
- SV-66457r1_rule
Checks: C-54297r1_chk
Review DBMS recovery procedures and 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. Review the database backup strategy with the system administrator. Consider using Oracle RMAN with an encrypted backup to insure you have files that can be trusted not to be compromised.
Fix: F-57057r1_fix
Implement DBMS recovery procedures and employ technical system features to specify trusted files during DBMS recovery. Test the solution and review the site-specific criteria to ensure that the backup and recovery process uses trusted files. Ensure circumstances that can inhibit a trusted recovery are documented and appropriate mitigating procedures have been put in place. Oracle recommends using RMAN Backup and encrypting backup files. With encrypted files stored on a mount point with limited access, the integrity of the files can be trusted. - - - - - Notes on Oracle Backup and Recovery Solutions When implementing a backup and recovery strategy, you have the following solutions available: -- Recovery Manager (RMAN) Recovery Manager is fully integrated with the Oracle database to perform a range of backup and recovery activities, including maintaining an RMAN repository of historical data about backups. You can access RMAN through the command line or through Oracle Enterprise Manager. -- User-managed backup and recovery In this solution, you perform backup and recovery with a mixture of host operating system commands and SQL*Plus recovery commands. You are responsible for determining all aspects of when and how backups and recovery are done. -- Media management If you do not want to use RMAN with an encrypted backup, consider configuring RMAN to make backups to a media manager. On most platforms, to back up to and restore from sequential media such as tape, you must integrate a media manager with your Oracle database. You can use Oracle Secure Backup, which supports both database and file system backups to tape, as your media manager. See Oracle Secure Backup Administrator's Guide to learn how to set up RMAN for use specifically with Oracle Secure Backup. These solutions are supported by Oracle and are fully documented, but RMAN is the preferred solution for database backup and recovery. RMAN provides a common interface for backup tasks across different host operating systems, and offers several backup techniques not available through user-managed methods. -- Incremental backups: An incremental backup stores only blocks changed since a previous backup. Thus, they provide more compact backups and faster recovery, thereby reducing the need to apply redo during data file media recovery. If you enable block change tracking, then you can improve performance by avoiding full scans of every input data file. You use the BACKUP INCREMENTAL command to perform incremental backups. -- Block media recovery You can repair a data file with only a small number of corrupt data blocks without taking it offline or restoring it from backup. You use the RECOVER BLOCK command to perform block media recovery. -- Binary compression A binary compression mechanism integrated into Oracle Database reduces the size of backups. -- Encrypted backups -- RMAN uses backup encryption capabilities integrated into Oracle Database to store backup sets in an encrypted format. To create encrypted backups on disk, the database must use the Advanced Security Option. To create encrypted backups directly on tape, RMAN must use the Oracle Secure Backup SBT interface but does not require the Advanced Security Option. -- Automated database duplication Easily creates a copy of your database, supporting various storage configurations, including direct duplication between ASM databases. -- Cross-platform data conversion Whether you use RMAN or user-managed methods, you can supplement physical backups with logical backups of schema objects made with Data Pump Export utility. You can later use Data Pump Import to re-create data after restore and recovery. Logical backups are mostly beyond the scope of the backup and recovery documentation.
- RMF Control
- CP-10
- Severity
- M
- CCI
- CCI-000553
- Version
- O112-C2-012100
- Vuln IDs
-
- V-52243
- Rule IDs
-
- SV-66459r1_rule
Checks: C-54299r1_chk
Review DBMS settings that enable or disable transaction journaling. If the DBMS is not capable of transaction journaling or if journaling is disabled, this is a finding. - - - - - Check to see what the current settings are in the database for creating a transaction journal, called the Oracle archive log. $ sqlplus / as sysdba --If you issue this command and the database log mode is "No Archive Mode", transaction journaling is not enabled and this is a finding. SQL> archive log list Database log mode No Archive Mode Automatic archival Disabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 427 Current log sequence 429
Fix: F-57059r1_fix
Enable transaction journaling for the database. - - - - - Check to see what the current settings are in the database for creating a transaction journal, called the Oracle archive log. $ sqlplus / as sysdba --If you issue this command and the database log mode is "No Archive Mode", transaction journaling is not enabled, and this is a finding. Complete the following steps to make sure Oracle transaction journaling is enabled. SQL> archive log list Database log mode No Archive Mode Automatic archival Disabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 427 Current log sequence 429 --Force a checkpoint to help and speed the database shutdown SQL> alter system checkpoint; System altered. --Shut down the database SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. --Start the database in mount mode SQL> startup mount ORACLE instance started. Total System Global Area 456146944 bytes Fixed Size 1344840 bytes Variable Size 373295800 bytes Database Buffers 75497472 bytes Redo Buffers 6008832 bytes Database mounted. --Enable archivelog in the database SQL> alter database archivelog; Database altered. --Open the database SQL> alter database open; Database altered. --Check the current archivelog mode in the database SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 427 Next log sequence to archive 429 Current log sequence 429
- RMF Control
- CP-9
- Severity
- M
- CCI
- CCI-000535
- Version
- O112-C2-012200
- Vuln IDs
-
- V-52245
- Rule IDs
-
- SV-66461r1_rule
Checks: C-54301r1_chk
Review DBMS settings and site documentation to determine whether Oracle is configured to back up user-level data according to a defined frequency. If it is not, this is a finding.
Fix: F-57061r1_fix
Configure the Oracle DBMS to back up user-level data on a defined frequency.
- RMF Control
- CP-9
- Severity
- M
- CCI
- CCI-000535
- Version
- O112-C2-012300
- Vuln IDs
-
- V-52247
- Rule IDs
-
- SV-66463r1_rule
Checks: C-54303r1_chk
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 documentation. If backup procedures do not exist or are not implemented in accordance with the procedures, this is a finding. - - - - - The Oracle recommended process for backup and recovery is Oracle RMAN. If Oracle RMAN is deployed, execute the following commands to ensure that the evidence of the implementation of the backup policy includes validating that the files are restorable: Validating Database Files with BACKUP VALIDATE --You can use the BACKUP VALIDATE command to do the following: -- Check datafiles for physical and logical block corruption -- Confirm that all database files exist and are in the correct locations --When you run BACKUP VALIDATE, RMAN reads the files to be backed up in their entirety, as it would during a real backup. RMAN does not, however, actually produce any backup sets or image copies. --You cannot use the BACKUPSET, MAXCORRUPT, or PROXY parameters with BACKUP VALIDATE. --To validate files with the BACKUP VALIDATE command: 1. Start RMAN and connect to a target database and recovery catalog (if used). 2. Run the BACKUP VALIDATE command. For example, you can validate that all database files and archived logs can be backed up by running a command as shown in the following example. This command checks for physical corruptions only. BACKUP VALIDATE DATABASE ARCHIVELOG ALL; To check for logical corruptions in addition to physical corruptions, run the following variation of the preceding command: BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL; In the preceding examples, the RMAN client displays the same output that it would if it were really backing up the files. If RMAN cannot back up one or more of the files, then it issues an error message. Validating Backups Before Restoring Them You can run RESTORE ... VALIDATE to test whether RMAN can restore a specific file or set of files from a backup. RMAN chooses which backups to use. The database must be mounted or open for this command. You do not have to take datafiles offline when validating the restore of datafiles, because validation of backups of the datafiles only reads the backups and does not affect the production datafiles. When validating files on disk or tape, RMAN reads all blocks in the backup piece or image copy. RMAN also validates offsite backups. The validation is identical to a real restore operation except that RMAN does not write output files. To validate backups with the RESTORE command: 1. Run the RESTORE command with the VALIDATE option. This following example illustrates validating the restore of the database and all archived redo logs: RESTORE DATABASE VALIDATE; RESTORE ARCHIVELOG ALL VALIDATE; If you do not see an RMAN error stack, then skip the subsequent steps. The lack of error messages means that RMAN had confirmed that it can use these backups successfully during a real restore and recovery. 2. If you see error messages in the output and the RMAN-06026 message, then investigate the cause of the problem. If possible, correct the problem that is preventing RMAN from validating the backups and retry the validation. The following error means that RMAN cannot restore one or more of the specified files from your available backups: RMAN-06026: some targets not found - aborting restore The following sample output shows that RMAN encountered a problem reading the specified backup: RMAN-03009: failure of restore command on c1 channel at 12-DEC-06 23:22:30 ORA-19505: failed to identify file "oracle/dbs/1fafv9gl_1_1" ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3
Fix: F-57063r1_fix
Develop, document, and implement database backup procedures.
- RMF Control
- CP-9
- Severity
- M
- CCI
- CCI-000535
- Version
- O112-C2-012400
- Vuln IDs
-
- V-52249
- Rule IDs
-
- SV-66465r1_rule
Checks: C-54305r1_chk
Review the testing and verification procedures documented in the system documentation. Review evidence of implementation of testing and verification procedures by reviewing logs from backup and recovery implementation. Logs may be in electronic form or hardcopy and may include email or other notification. If testing and verification of backup and recovery procedures is not documented in the system documentation, this is a finding. If evidence of testing and verification of backup and recovery procedures does not exist, this is a finding.
Fix: F-57065r1_fix
Develop, document, and implement testing and verification procedures for database backup and recovery. Include requirements for documenting database backup and recovery testing and verification activities in the procedures.
- RMF Control
- CP-9
- Severity
- M
- CCI
- CCI-000535
- Version
- O112-C2-012500
- Vuln IDs
-
- V-52251
- Rule IDs
-
- SV-66467r1_rule
Checks: C-54307r1_chk
Review file protections assigned to online backup and restoration files. Review access protections and procedures for offline backup and restoration files. If backup or restoration files are subject to unauthorized access, this is a finding. It may be necessary to review backup and restoration procedures to determine ownership and access during all phases of backup and recovery.
Fix: F-57067r1_fix
Implement protection for backup and restoration files. Document personnel and the level of access authorized for each to the backup and restoration files in the system documentation.
- RMF Control
- CP-9
- Severity
- M
- CCI
- CCI-000537
- Version
- O112-C2-012600
- Vuln IDs
-
- V-52253
- Rule IDs
-
- SV-66469r1_rule
Checks: C-54309r1_chk
Review DBMS and OS backup configuration to determine that system-level data is backed up in according with organization-defined frequency. If the system-level data of the DBMS is not backed up to the organization-defined frequency, this is a finding.
Fix: F-57069r1_fix
Utilize DBMS, OS or third-party product(s), to meet the requirement of backing up system data according to the organization-defined frequency.
- RMF Control
- IA-2
- Severity
- M
- CCI
- CCI-000765
- Version
- O112-C2-012900
- Vuln IDs
-
- V-52255
- Rule IDs
-
- SV-66471r1_rule
Checks: C-54311r1_chk
Review DBMS settings, OS settings, and/or enterprise-level authentication/access mechanism settings to determine whether users logging into privileged accounts via a network are required to use multifactor authentication. If users logging into privileged accounts via a network are not required to use multifactor authentication, this is a finding. (Oracle Advanced Security Option (ASO) may be helpful in meeting this requirement. Notes on ASO Data Integrity follow.) Authentication is used to prove the identity of the user. Authenticating user identity is imperative in distributed environments, without which there can be little confidence in network security. Passwords are the most common means of authentication. Oracle Advanced Security enables strong multifactor authentication with Oracle authentication adapters that support various third-party authentication services, including SSL with digital certificates as well as Smart Cards (CAC, PIV). Oracle Advanced Security provides multifactor authentication to the database. With Oracle Advanced Security, customers can require their users to plug-in a Smart Card (CAC, PIV) as part of their SSL-based authentication to the Oracle Database. Unix and Windows platforms can be checked by selecting installed products in the Oracle Universal Installer (OUI). Select the Oracle home, and, from Contents tab, drill down to Enterprise Edition Options. On Unix you can also run the adapters command $ adapters Installed Oracle Advanced Security options are: RC4 40-bit encryption RC4 56-bit encryption RC4 128-bit encryption RC4 256-bit encryption DES40 40-bit encryption DES 56-bit encryption 3DES 112-bit encryption 3DES 168-bit encryption AES 128-bit encryption AES 192-bit encryption AES 256-bit encryption MD5 crypto-checksumming SHA-1 crypto-checksumming Kerberos v5 authentication RADIUS authentication If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries, ASO with SSL is installed. The following entries in the sqlnet.ora will be generated when SSL is installed. #SSL WALLET_LOCATION = (SOURCE= (METHOD = FILE) (METHOD_DATA = DIRECTORY=/wallet) SSL_CIPHER_SUITES=(SSL_cipher_suiteExample) SSL_VERSION= 3 SSL_CLIENT_AUTHENTICATION=FALSE/TRUE
Fix: F-57071r1_fix
Configure DBMS, OS and/or enterprise-level authentication/access mechanism to require multifactor authentication for network users logging into privileged accounts. If appropriate, install Oracle Advanced Security Option to support Secure Sockets Layer (SSL) protocols and multifactor authentication through the use of Smart Cards (CAC/PIV).
- RMF Control
- IA-2
- Severity
- M
- CCI
- CCI-000766
- Version
- O112-C2-013000
- Vuln IDs
-
- V-52257
- Rule IDs
-
- SV-66473r1_rule
Checks: C-54313r1_chk
Review DBMS settings, OS settings, and/or enterprise-level authentication/access mechanism settings to determine whether users logging into non-privileged accounts via a network are required to use multifactor authentication. If users logging into non-privileged accounts via a network are not required to use multifactor authentication, this is a finding. (Oracle Advanced Security Option (ASO) may be helpful in meeting this requirement. Notes on ASO Data Integrity follow.) Authentication is used to prove the identity of the user. Authenticating user identity is imperative in distributed environments, without which there can be little confidence in network security. Passwords are the most common means of authentication. Oracle Advanced Security enables strong multifactor authentication with Oracle authentication adapters that support various third-party authentication services, including SSL with digital certificates as well as Smart Cards (CAC, PIV). Oracle Advanced Security provides multifactor authentication to the database. With Oracle Advanced Security, customers can require their users to plug-in a Smart Card (CAC, PIV) as part of their SSL-based authentication to the Oracle Database. Unix and Windows platforms can be checked, by selecting installed products in the Oracle Universal Installer (OUI). Select the Oracle home, and, from Contents tab, drill down to Enterprise Edition Options. On Unix you can also run the adapters command $ adapters Installed Oracle Advanced Security options are: RC4 40-bit encryption RC4 56-bit encryption RC4 128-bit encryption RC4 256-bit encryption DES40 40-bit encryption DES 56-bit encryption 3DES 112-bit encryption 3DES 168-bit encryption AES 128-bit encryption AES 192-bit encryption AES 256-bit encryption MD5 crypto-checksumming SHA-1 crypto-checksumming Kerberos v5 authentication RADIUS authentication If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries, ASO with SSL is installed. The following entries in the sqlnet.ora will be generated when SSL is installed. #SSL WALLET_LOCATION = (SOURCE= (METHOD = FILE) (METHOD_DATA = DIRECTORY=/wallet) SSL_CIPHER_SUITES=(SSL_cipher_suiteExample) SSL_VERSION= 3 SSL_CLIENT_AUTHENTICATION=FALSE/TRUE
Fix: F-57073r1_fix
Configure DBMS, OS and/or enterprise-level authentication/access mechanism to require multifactor authentication for network users logging into non-privileged accounts. If appropriate, install Oracle Advanced Security Option to support Secure Sockets Layer (SSL) protocols and multifactor authentication through the use of Smart Cards (CAC/PIV).
- RMF Control
- IA-2
- Severity
- M
- CCI
- CCI-000767
- Version
- O112-C2-013100
- Vuln IDs
-
- V-52259
- Rule IDs
-
- SV-66475r1_rule
Checks: C-54315r1_chk
Review DBMS settings, OS settings, and/or enterprise-level authentication/access mechanism settings to determine whether users logging into privileged accounts locally are required to use multifactor authentication. If users logging into privileged accounts locally are not required to use multifactor authentication, this is a finding. (Oracle Advanced Security Option (ASO) may be helpful in meeting this requirement. Notes on ASO Data Integrity follow.) Authentication is used to prove the identity of the user. Authenticating user identity is imperative in distributed environments, without which there can be little confidence in network security. Passwords are the most common means of authentication. Oracle Advanced Security enables strong multifactor authentication with Oracle authentication adapters that support various third-party authentication services, including SSL with digital certificates as well as Smart Cards (CAC, PIV). Oracle Advanced Security provides multifactor authentication to the database. With Oracle Advanced Security, customers can require their users to plug-in a Smart Card (CAC, PIV) as part of their SSL-based authentication to the Oracle Database. Unix and Windows platforms can be checked by selecting installed products in the Oracle Universal Installer (OUI). Select the Oracle home, and, from Contents tab, drill down to Enterprise Edition Options. On Unix you can also run the adapters command $ adapters Installed Oracle Advanced Security options are: RC4 40-bit encryption RC4 56-bit encryption RC4 128-bit encryption RC4 256-bit encryption DES40 40-bit encryption DES 56-bit encryption 3DES 112-bit encryption 3DES 168-bit encryption AES 128-bit encryption AES 192-bit encryption AES 256-bit encryption MD5 crypto-checksumming SHA-1 crypto-checksumming Kerberos v5 authentication RADIUS authentication If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries, ASO with SSL is installed. The following entries in the sqlnet.ora will be generated when SSL is installed. #SSL WALLET_LOCATION = (SOURCE= (METHOD = FILE) (METHOD_DATA = DIRECTORY=/wallet) SSL_CIPHER_SUITES=(SSL_cipher_suiteExample) SSL_VERSION= 3 SSL_CLIENT_AUTHENTICATION=FALSE/TRUE
Fix: F-57075r1_fix
Configure DBMS, OS and/or enterprise-level authentication/access mechanism to require multifactor authentication for local users logging into privileged accounts. If appropriate, install Oracle Advanced Security Option to support Secure Sockets Layer (SSL) protocols and multifactor authentication through the use of Smart Cards (CAC/PIV).
- RMF Control
- IA-2
- Severity
- M
- CCI
- CCI-000768
- Version
- O112-C2-013200
- Vuln IDs
-
- V-52261
- Rule IDs
-
- SV-66477r1_rule
Checks: C-54317r1_chk
Review DBMS settings, OS settings, and/or enterprise-level authentication/access mechanism settings to determine whether users logging into non-privileged accounts locally are required to use multifactor authentication. If users logging into non-privileged accounts locally are not required to use multifactor authentication, this is a finding. (Oracle Advanced Security Option (ASO) may be helpful in meeting this requirement. Notes on ASO Data Integrity follow.) Authentication is used to prove the identity of the user. Authenticating user identity is imperative in distributed environments, without which there can be little confidence in network security. Passwords are the most common means of authentication. Oracle Advanced Security enables strong multifactor authentication with Oracle authentication adapters that support various third-party authentication services, including SSL with digital certificates as well as Smart Cards (CAC, PIV). Oracle Advanced Security provides multifactor authentication to the database. With Oracle Advanced Security, customers can require their users to plug-in a Smart Card (CAC, PIV) as part of their SSL-based authentication to the Oracle Database. Unix and Windows platforms can be checked, by selecting installed products in the Oracle Universal Installer (OUI). Select the Oracle home, and, from Contents tab, drill down to Enterprise Edition Options. On Unix you can also run the adapters command $ adapters Installed Oracle Advanced Security options are: RC4 40-bit encryption RC4 56-bit encryption RC4 128-bit encryption RC4 256-bit encryption DES40 40-bit encryption DES 56-bit encryption 3DES 112-bit encryption 3DES 168-bit encryption AES 128-bit encryption AES 192-bit encryption AES 256-bit encryption MD5 crypto-checksumming SHA-1 crypto-checksumming Kerberos v5 authentication RADIUS authentication If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries, ASO with SSL is installed. The following entries in the sqlnet.ora will be generated when SSL is installed. #SSL WALLET_LOCATION = (SOURCE= (METHOD = FILE) (METHOD_DATA = DIRECTORY=/wallet) SSL_CIPHER_SUITES=(SSL_cipher_suiteExample) SSL_VERSION= 3 SSL_CLIENT_AUTHENTICATION=FALSE/TRUE
Fix: F-57077r1_fix
Configure DBMS, OS and/or enterprise-level authentication/access mechanism to require multifactor authentication for local users logging into non-privileged accounts. If appropriate, install Oracle Advanced Security Option to support Secure Sockets Layer (SSL) protocols and multifactor authentication through the use of Smart Cards (CAC/PIV).
- RMF Control
- IA-2
- Severity
- M
- CCI
- CCI-000770
- Version
- O112-C2-013300
- Vuln IDs
-
- V-52263
- Rule IDs
-
- SV-66479r1_rule
Checks: C-54319r1_chk
Review DBMS settings, OS settings, and/or enterprise-level authentication/access mechanism settings to determine whether group accounts exist. If group accounts do not exist, this is NA. Review DBMS settings to determine if individual authentication is required before group authentication. If group authentication does not require prior individual authentication, this is a finding. (Oracle Access Manager may be helpful in meeting this requirement. Notes on Oracle Access Manager follow.) Oracle Access Manager is used when there is a need for multifactor authentication of applications front-ending Oracle Datasets that may use group accounts. Oracle Access Manager supports using PKI-based smart cards (CAC, PIV) for multifactor authentication. When a user authenticates to a smart card application, the smart card engine produces a certificate-based authentication token. You can configure a certificate-based authentication scheme in Oracle Access Manager that uses information from the smart card certificate. Certificate-based authentication works with any smart card or similar device that presents an X.509 certificate. Check: First, check that the Authentication Module is set up properly: 1) Go to Oracle Access Manager Home Screen and click the Policy Configuration tab. Select the X509Scheme. 2) Make sure the Authentication Module option is set to X509Plugin. Second, check your Authentication policy is using the x509Scheme: 1) Go to Oracle Access Manager Home Screen and click the Policy Configuration tab. 2) Select Application Domains. Select Search. 3) Select the application domain protecting the Oracle Database. 4) Select the Authentication Polices tab and Click Protected Resource Policy. 5) Make sure the Authentication Scheme is set to x509Scheme.
Fix: F-57079r1_fix
Configure DBMS, OS and/or enterprise-level authentication/access mechanism to require individual authentication prior to authentication for group account access. If appropriate, install Oracle Access Manager to provide multifactor authentication of applications front-ending Oracle Databases and using group accounts. After installation, use x509 Authentication modules provided out of the box.
- RMF Control
- IA-2
- Severity
- M
- CCI
- CCI-000774
- Version
- O112-C2-013600
- Vuln IDs
-
- V-52265
- Rule IDs
-
- SV-66481r1_rule
Checks: C-54321r1_chk
Review DBMS settings, OS settings, and/or enterprise-level authentication/access mechanism settings to determine whether organization-defined replay-resistant authentication mechanisms for network access to privileged accounts exist. If these mechanisms do not exist, this is a finding. (Oracle Advanced Security Option (ASO) may be helpful in meeting this requirement. Notes on ASO Data Integrity follow.) Oracle Advanced Security comes into play on every connection when it is enabled. There is no distinction between privileged and non-privileged accounts. Encryption of network data provides data privacy so that unauthorized parties are not able to view plaintext data as it passes over the network. Oracle Advanced Security also provides protection against two forms of active attack Data modification attack An unauthorized party intercepting data in transit, altering it, and retransmitting it is a data modification attack. For example, intercepting a $100 bank deposit, changing the amount to $10,000, and retransmitting the higher amount is a data modification attack. Replay attack Repetitively retransmitting an entire set of valid data is a replay attack, such as intercepting a $100 bank withdrawal and retransmitting it ten times, thereby receiving $1,000. With Oracle Advanced Security we use Cipher Block Chaining (CBC). Cipher Block Chaining Is an encryption method that protects against block replay attacks by making the encryption of a cipher block dependent on all blocks that precede it; it is designed to make unauthorized decryption incrementally more difficult. Oracle Advanced Security employs outer cipher block chaining because it is more secure than inner cipher block chaining, with no material performance penalty. If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries you are protected as ASO is installed. The following entries in the sqlnet.ora will be generated when ASO is installed. Oracle Advanced Security Network Data Integrity - #ASO Checksum sqlnet.crypto_checksum_server=requested sqlnet.crypto_checksum_client=requested sqlnet.crypto_checksum_types_server = (MD5) sqlnet.crypto_checksum_types_client = (MD5)
Fix: F-57081r1_fix
Configure DBMS, OS and/or enterprise-level authentication/access mechanism to utilize replay-resistant authentication mechanisms such as nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. If appropriate, install Oracle Advanced Security Option to protect against replay mechanisms.
- RMF Control
- IA-2
- Severity
- M
- CCI
- CCI-000776
- Version
- O112-C2-013700
- Vuln IDs
-
- V-52267
- Rule IDs
-
- SV-66483r1_rule
Checks: C-54323r1_chk
Review DBMS settings to determine whether organization-defined replay-resistant authentication mechanisms for network access to non-privileged accounts exist. If these mechanisms do not exist, this is a finding. (Oracle Advanced Security Option (ASO) may be helpful in meeting this requirement. Notes on ASO Data Integrity follow.) Oracle Advanced Security comes into play on every connection when it is enabled. There is no distinction between privileged and non-privileged accounts. Encryption of network data provides data privacy so that unauthorized parties are not able to view plaintext data as it passes over the network. Oracle Advanced Security also provides protection against two forms of active attack Data modification attack An unauthorized party intercepting data in transit, altering it, and retransmitting it is a data modification attack. For example, intercepting a $100 bank deposit, changing the amount to $10,000, and retransmitting the higher amount is a data modification attack. Replay attack Repetitively retransmitting an entire set of valid data is a replay attack, such as intercepting a $100 bank withdrawal and retransmitting it ten times, thereby receiving $1,000. With Oracle Advanced Security we use Cipher Block Chaining (CBC). Cipher Block Chaining Is an encryption method that protects against block replay attacks by making the encryption of a cipher block dependent on all blocks that precede it; it is designed to make unauthorized decryption incrementally more difficult. Oracle Advanced Security employs outer cipher block chaining because it is more secure than inner cipher block chaining, with no material performance penalty. If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries, you are protected as ASO is installed. The following entries in the sqlnet.ora will be generated when ASO is installed. Oracle Advanced Security Network Data Integrity - #ASO Checksum sqlnet.crypto_checksum_server=requested sqlnet.crypto_checksum_client=requested sqlnet.crypto_checksum_types_server = (MD5) sqlnet.crypto_checksum_types_client = (MD5)"
Fix: F-57083r1_fix
Configure DBMS, OS and/or enterprise-level authentication/access mechanism to require organization-defined replay-resistant authentication mechanisms for network access to non-privileged accounts. If appropriate, install the Oracle Advanced Security Option. This option will prevent replay attacks for all users, privileged and non-privileged. If ASO is not available, use a site-specific solution.
- RMF Control
- IA-4
- Severity
- M
- CCI
- CCI-000795
- Version
- O112-C2-013800
- Vuln IDs
-
- V-52269
- Rule IDs
-
- SV-66485r1_rule
Checks: C-54325r1_chk
If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For accounts managed by Oracle, check DBMS settings to determine if accounts can be automatically disabled by the system after 35 days of inactivity. Also, ask the DBA if an alternative method, such as a stored procedure run daily, to disable Oracle-managed accounts inactive for more than 35 days, has been deployed. If the ability to disable accounts after 35 days of inactivity, by either of these means, does not exist, this is a finding. - - - - - Check to see what profile a user is associated with, if any, with this query: SQL> select username, profile from dba_users where username = '&Enter_Username'; Then check the profile to see what the password_life_time is set to in the table dba_profiles; The password_life_time is a value stored in the column named resource_name. SQL>select profile, resource_name, resource_type, limit from dba_profiles where upper(resource_name) = 'PASSWORD_LIFE_TIME'; - - - - - The following are notes on a method suggested by Oracle. In SRG-APP-000075-DB-000029 - The DBMS must, upon successful login, display to the user the date and time of the user's last login advocated using a custom trigger for this event. One could query the audit table and get similar results, but that is a much busier table with a lot more data. In SRG-APP-000075-DB-000029, we advocated to use a new table called sys.login_audit_info_all and trap login information with a login trigger. Check for the existence of the sys.login_audit_info_all and count the number of rows to ensure that the table is being used. Obviously, the table will have maintenance performed on it to shrink the contents, so the number of rows may vary. If the table itself exists, it is a good indication it is being used. Connect to the database, check for the existence of the table, and count the rows, as this will help us understand if the fix for SRG-APP-000075-DB-000029 was implemented and will help us remediate this issue. $ sqlplus connect as sysdba SQL> select count(*) from SYS.LOGIN_AUDIT_INFO_ALL; If the count is greater than zero, then the table exists and data is being inserted.
Fix: F-57085r1_fix
If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. For accounts managed by Oracle, determine if it is practical and acceptable to require a password change every 35 days or fewer, rather than the standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue the statement: ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35; (See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for examples.) If password changes every 35 days or fewer are unacceptable or impractical, implement an alternative method, such as a stored procedure run daily, to disable accounts inactive for more than 35 days. - - - - - The following are notes on a method suggested by Oracle. Check either the login_audit_info_all or the dba_audit_session to see what users have not logged in for the site-defined number of days. If the login_audit_info_all exists, execute the following query to get a report of the users who have exceeded the site-specific guidelines and lock those accounts. Generate a report to see what users have not logged in in the last 30 days or whatever the site-specified expiration days requirement is. sqlplus connect as sysdba - If sys.login_audit_info_all exists and contains rows, use the following query to see if there are any users who have not logged in for a period of time that is defined as the amount of time required to generate a locked account. SQL>set linesize 121 SQL>col user_id format a30 SQL>col logoff_day format a20 Sal>select user_id, logoff_day from sys.login_audit_info_all where sysdate - logoff_day > &site_specified_expiration_days; sqlplus connect as sysdba - If sys.login_audit_info_all does not exist or contains no rows, use the following query to see if there are any users who have not logged in for a period of time that is defined as the amount of time required to generate a locked account. SQL>set linesize 121 SQL>col username format a30 SQL>col timestamp format a20 SQL> select username, timestamp from dba_audit_session where action_name = 'login' and sysdate - timestamp > &site_specified_expiration_days; Take the user returned from this report and expire the account. SQL> alter user &username account lock;
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000205
- Version
- O112-C2-013900
- Vuln IDs
-
- V-52271
- Rule IDs
-
- SV-66487r1_rule
Checks: C-54327r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use: SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION' [AND PROFILE NOT IN (<list of non-applicable profiles>)] ORDER BY PROFILE; Bearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile. If, for any profile, the function name is null, this is a finding. For each password verification function, examine its source code. If it does not enforce the DoD-defined minimum length (15 unless otherwise specified), this is a finding.
Fix: F-57087r1_fix
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. If any user accounts are managed by Oracle: Develop, test and implement a password verification function that enforces DoD requirements. (Oracle supplies a sample function called verify_function_11G, in the script file <oracle_home>/RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point for a customized function.)
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000200
- Version
- O112-C2-014000
- Vuln IDs
-
- V-52273
- Rule IDs
-
- SV-66489r1_rule
Checks: C-54329r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For each profile that can be applied to accounts where authentication is under Oracle's control, determine the password reuse rule, if any, that is in effect: SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME IN ('PASSWORD_REUSE_MAX', 'PASSWORD_REUSE_TIME') [AND PROFILE NOT IN (<list of non-applicable profiles>)] ORDER BY PROFILE, RESOURCE_NAME; Bearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the value of the PASSWORD_REUSE_MAX effective for each profile. If, for any profile, the PASSWORD_REUSE_MAX value does not enforce the DoD-defined minimum number of password changes before a password may be repeated (5 or greater), this is a finding. PASSWORD_REUSE_MAX is effective if and only if PASSWORD_REUSE_TIME is specified, so if PASSWORD_REUSE_TIME is null or UNLIMITED, this is a finding.
Fix: F-57089r1_fix
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. If any user accounts are managed by Oracle: For each profile, set the PASSWORD_REUSE_MAX to enforce the DoD-defined minimum number of password changes before a password may be repeated (5 or greater). PASSWORD_REUSE_MAX is effective if and only if PASSWORD_REUSE_TIME is specified, so ensure also that it has a meaningful value. Since the minimum password lifetime is 1 day, the smallest meaningful value is the same as the PASSWORD_REUSE_MAX value. Using PPPPPP as an example, the statement to do this is: ALTER PROFILE PPPPPP LIMIT PASSWORD_REUSE_MAX 5 PASSWORD_REUSE_TIME 5;
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000192
- Version
- O112-C2-014100
- Vuln IDs
-
- V-52275
- Rule IDs
-
- SV-66491r1_rule
Checks: C-54331r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use: SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION' [AND PROFILE NOT IN (<list of non-applicable profiles>)] ORDER BY PROFILE; Bearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile. If, for any profile, the function name is null, this is a finding. For each password verification function, examine its source code. If it does not enforce the organization-defined minimum number of upper-case characters (1 unless otherwise specified), this is a finding.
Fix: F-57091r1_fix
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. If any user accounts are managed by Oracle: Develop, test and implement a password verification function that enforces DoD requirements. (Oracle supplies a sample function called verify_function_11G, in the script file <oracle_home>/RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point for a customized function.)
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000193
- Version
- O112-C2-014200
- Vuln IDs
-
- V-52277
- Rule IDs
-
- SV-66493r1_rule
Checks: C-54333r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use: SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION' [AND PROFILE NOT IN (<list of non-applicable profiles>)] ORDER BY PROFILE; Bearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile. If, for any profile, the function name is null, this is a finding. For each password verification function, examine its source code. If it does not enforce the organization-defined minimum number of lower-case characters (1 unless otherwise specified), this is a finding.
Fix: F-57093r1_fix
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. If any user accounts are managed by Oracle: Develop, test and implement a password verification function that enforces DoD requirements. (Oracle supplies a sample function called verify_function_11G, in the script file <oracle_home>/RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point for a customized function.)
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000194
- Version
- O112-C2-014300
- Vuln IDs
-
- V-52279
- Rule IDs
-
- SV-66495r1_rule
Checks: C-54335r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use: SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION' [AND PROFILE NOT IN (<list of non-applicable profiles>)] ORDER BY PROFILE; Bearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile. If, for any profile, the function name is null, this is a finding. For each password verification function, examine its source code. If it does not enforce the organization-defined minimum number of numeric characters (1 unless otherwise specified), this is a finding.
Fix: F-57095r1_fix
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. If any user accounts are managed by Oracle: Develop, test and implement a password verification function that enforces DoD requirements. (Oracle supplies a sample function called verify_function_11G, in the script file <oracle_home>/RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point for a customized function.)
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-001619
- Version
- O112-C2-014400
- Vuln IDs
-
- V-52281
- Rule IDs
-
- SV-66497r1_rule
Checks: C-54337r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use: SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION' [AND PROFILE NOT IN (<list of non-applicable profiles>)] ORDER BY PROFILE; Bearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile. If, for any profile, the function name is null, this is a finding. For each password verification function, examine its source code. If it does not enforce the organization-defined minimum number of special characters (1 unless otherwise specified), this is a finding.
Fix: F-57097r1_fix
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. If any user accounts are managed by Oracle: Develop, test and implement a password verification function that enforces DoD requirements. (Oracle supplies a sample function called verify_function_11G, in the script file <oracle_home>/RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point for a customized function.)
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000195
- Version
- O112-C2-014500
- Vuln IDs
-
- V-52283
- Rule IDs
-
- SV-66499r1_rule
Checks: C-54339r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For each profile that can be applied to accounts where authentication is under Oracle's control, determine the password verification function, if any, that is in use: SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'PASSWORD_VERIFY_FUNCTION' [AND PROFILE NOT IN (<list of non-applicable profiles>)] ORDER BY PROFILE; Bearing in mind that a profile can inherit from another profile, and the root profile is called DEFAULT, determine the name of the password verification function effective for each profile. If, for any profile, the function name is null, this is a finding. For each password verification function, examine its source code. If it does not enforce the organization-defined minimum number of characters by which the password must differ from the previous password (one half of the characters unless otherwise specified), this is a finding.
Fix: F-57099r1_fix
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. If any user accounts are managed by Oracle: Develop, test and implement a password verification function that enforces DoD requirements. (Oracle supplies a sample function called verify_function_11G, in the script file <oracle_home>/RDBMS/ADMIN/utlpwdmg.sql. This can be used as the starting point for a customized function.)
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000196
- Version
- O112-C2-014600
- Vuln IDs
-
- V-52285
- Rule IDs
-
- SV-66501r1_rule
Checks: C-54341r1_chk
(Oracle stores and displays its passwords in encrypted form. Nevertheless, this should be verified by reviewing the relevant system views, along with the other items to be checked here.) 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, tables 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/tables, contain database passwords. If any do, confirm that DBMS passwords stored internally or externally to the DBMS are encoded or encrypted. If any passwords are stored in clear text, this is a finding. Ask the DBA/SA/Application Support staff if they have created an external password store for applications, batch jobs, and scripts to use. Verify that all passwords stored there are encrypted. If a password store is used and any password is not encrypted, this is a finding. - - - - - The following are notes on implementing a Secure External Password Store using Oracle Wallet. You can store password credentials for connecting to databases by using a client-side Oracle wallet. An Oracle wallet is a secure software container that stores authentication and signing credentials. This wallet usage can simplify large-scale deployments that rely on password credentials for connecting to databases. When this feature is configured, application code, batch jobs, and scripts no longer need embedded user names and passwords. This reduces risk because the passwords are no longer exposed, and password management policies are more easily enforced without changing application code whenever user names or passwords change. The external password store of the wallet is separate from the area where public key infrastructure (PKI) credentials are stored. Consequently, you cannot use Oracle Wallet Manager to manage credentials in the external password store of the wallet. Instead, use the command-line utility mkstore to manage these credentials. How Does the External Password Store Work? Typically, users (and applications, batch jobs, and scripts) connect to databases by using a standard CONNECT statement that specifies a database connection string. This string can include a user name and password, and an Oracle Net service name identifying the database on an Oracle Database network. If the password is omitted, the connection prompts the user for the password. For example, the service name could be the URL that identifies that database, or a TNS alias you entered in the tnsnames.ora file in the database. Another possibility is a host:port:sid string. The following examples are standard CONNECT statements that could be used for a client that is not configured to use the external password store: CONNECT salesapp@sales_db.us.example.com Enter password: password CONNECT salesapp@orasales Enter password: password CONNECT salesapp@ourhost37:1527:DB17 Enter password: password In these examples, salesapp is the user name, with the unique connection string for the database shown as specified in three different ways. You could use its URL sales_db.us.example.com, or its TNS alias, orasales, from the tnsnames.ora file, or its host:port:sid string. However, when clients are configured to use the secure external password store, applications can connect to a database with the following CONNECT statement syntax, without specifying database login credentials: CONNECT /@db_connect_string CONNECT /@db_connect_string AS SYSDBA CONNECT /@db_connect_string AS SYSOPER In this specification, db_connect_string is a valid connection string to access the intended database, such as the service name, URL, or alias as shown in the earlier examples. Each user account must have its own unique connection string; you cannot create one connection string for multiple users. In this case, the database credentials, user name and password, are securely stored in an Oracle wallet created for this purpose. The autologin feature of this wallet is turned on, so the system does not need a password to open the wallet. From the wallet, it gets the credentials to access the database for the user they represent.
Fix: F-57101r1_fix
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. - - - - - The following are notes on implementing a Secure External Password Store using Oracle Wallet. Oracle provides the capability to provide for a secure external password facility. Use the Oracle mkstore to create a secure storage area for passwords for applications, batch jobs, and scripts to use, or deploy a site-authorized facility to perform this function. Check to see what has been stored in the Oracle External Password Store To view all contents of a client wallet external password store, check specific credentials by viewing them. Listing the external password store contents provides information you can use to decide whether to add or delete credentials from the store. To list the contents of the external password store, enter the following command at the command line: $ mkstore -wrl wallet_location -listCredential For example: $ mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -listCredential The wallet_location specifies the path to the directory where the wallet, whose external password store contents you want to view, is located. This command lists all of the credential database service names (aliases) and the corresponding user name (schema) for that database. Passwords are not listed. Configuring Clients to Use the External Password Store If your client is already configured to use external authentication, such as Windows native authentication or Secure Sockets Layer (SSL), then Oracle Database uses that authentication method. The same credentials used for this type of authentication are typically also used to log in to the database. For clients not using such authentication methods or wanting to override them for database authentication, you can set the SQLNET.WALLET_OVERRIDE parameter in sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE, allowing standard use of authentication credentials as before. If you want a client to use the secure external password store feature, then perform the following configuration task: 1. Create a wallet on the client by using the following syntax at the command line: mkstore -wrl wallet_location -create For example: mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -create Enter password: password The wallet_location is the path to the directory where you want to create and store the wallet. This command creates an Oracle wallet with the autologin feature enabled at the location you specify. The autologin feature enables the client to access the wallet contents without supplying a password. The mkstore utility -create option uses password complexity verification. 2. Create database connection credentials in the wallet by using the following syntax at the command line: mkstore -wrl wallet_location -createCredential db_connect_string username Enter password: password For example: mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -createCredential oracle system Enter password: password In this specification the wallet_location is the path to the directory where you created the wallet. The db_connect_string used in the CONNECT /@db_connect_string statement must be identical to the db_connect_string specified in the -createCredential command. The db_connect_string is the TNS alias you use to specify the database in the tnsnames.ora file or any service name you use to identify the database on an Oracle network. By default, tnsnames.ora is located in the $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME\network\admin on Windows. The username is the database login credential. When prompted, enter the password for this user. 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set it to the directory location of the wallet you created in Step 1. For example, if you created the wallet in $ORACLE_HOME/network/admin and your Oracle home is set to /private/ora11, then you need to enter the following into your client sqlnet.ora file: WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /private/ora11/network/admin) ) ) 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter and set it to TRUE as follows: SQLNET.WALLET_OVERRIDE = TRUE This setting causes all CONNECT /@db_connect_string statements to use the information in the wallet at the specified location to authenticate to databases. When external authentication is in use, an authenticated user with such a wallet can use the CONNECT /@db_connect_string syntax to access the previously specified databases without providing a user name and password. However, if a user fails that external authentication, then these connect statements also fail. If an application uses SSL for encryption, then the sqlnet.ora parameter, SQLNET.AUTHENTICATION_SERVICES, specifies SSL, and an SSL wallet is created. If this application wants to use secret store credentials to authenticate to databases (instead of the SSL certificate), then those credentials must be stored in the SSL wallet. After SSL authentication, if SQLNET.WALLET_OVERRIDE = TRUE, then the user names and passwords from the wallet are used to authenticate to databases. If SQLNET.WALLET_OVERRIDE = FALSE, then the SSL certificate is used. Below is a sample sqlnet.ora file with the WALLET_LOCATION and the SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4. WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /private/ora11/network/admin) ) ) SQLNET.WALLET_OVERRIDE = TRUE SSL_CLIENT_AUTHENTICATION = FALSE SSL_VERSION = 0
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000199
- Version
- O112-C2-014900
- Vuln IDs
-
- V-52287
- Rule IDs
-
- SV-66503r1_rule
Checks: C-54343r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. Where accounts are authenticated using passwords, review procedures and implementation evidence for creation of temporary passwords. If the procedures or evidence do not exist or do not enforce passwords to meet DoD password requirements, this is a finding.
Fix: F-57103r3_fix
Implement procedures for assigning temporary passwords to user accounts. Procedures should include instructions to meet current DoD password length and complexity requirements and provide a secure method to relay the temporary password to the user.
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000199
- Version
- O112-C2-015100
- Vuln IDs
-
- V-52289
- Rule IDs
-
- SV-66505r1_rule
Checks: C-54345r1_chk
Review application source code required to be encoded or encrypted for database accounts used by applications or batch jobs to access the database. Review source batch job code prior to compiling, encoding, or encrypting for database accounts used by applications or the batch jobs themselves to access the database. Determine if the compiled, encoded, or encrypted application source code or batch jobs contain passwords used for authentication to the database. If any of the identified compiled, encoded, or encrypted application source code or batch job code do contain passwords used for authentication to the database, this is a finding. - - - - - The check would depend on the information provided by the DBA. In a default Oracle installation, all passwords are stored in an encrypted manner. Ask the DBA if they have created an External Password Store for applications, batch jobs, and scripts to use. Secure External Password Store You can store password credentials for connecting to databases by using a client-side Oracle wallet. An Oracle wallet is a secure software container that stores authentication and signing credentials. This wallet usage can simplify large-scale deployments that rely on password credentials for connecting to databases. When this feature is configured, application code, batch jobs, and scripts no longer need embedded user names and passwords. This reduces risk because the passwords are no longer exposed, and password management policies are more easily enforced without changing application code whenever user names or passwords change. The external password store of the wallet is separate from the area where public key infrastructure (PKI) credentials are stored. Consequently, you cannot use Oracle Wallet Manager to manage credentials in the external password store of the wallet. Instead, use the command-line utility mkstore to manage these credentials. How Does the External Password Store Work? Typically, users (and as applications, batch jobs, and scripts) connect to databases by using a standard CONNECT statement that specifies a database connection string. This string can include a user name and password, and an Oracle Net service name identifying the database on an Oracle Database network. If the password is omitted, the connection prompts the user for the password. For example, the service name could be the URL that identifies that database, or a TNS alias you entered in the tnsnames.ora file in the database. Another possibility is a host:port:sid string. The following examples are standard CONNECT statements that could be used for a client that is not configured to use the external password store: CONNECT salesapp@sales_db.us.example.com Enter password: password CONNECT salesapp@orasales Enter password: password CONNECT salesapp@ourhost37:1527:DB17 Enter password: password In these examples, salesapp is the user name, with the unique connection string for the database shown as specified in three different ways. You could use its URL sales_db.us.example.com, or its TNS alias, orasales, from the tnsnames.ora file, or its host:port:sid string. However, when clients are configured to use the secure external password store, applications can connect to a database with the following CONNECT statement syntax, without specifying database login credentials: CONNECT /@db_connect_string CONNECT /@db_connect_string AS SYSDBA CONNECT /@db_connect_string AS SYSOPER In this specification, db_connect_string is a valid connection string to access the intended database, such as the service name, URL, or alias as shown in the earlier examples. Each user account must have its own unique connection string; you cannot create one connection string for multiple users. In this case, the database credentials, user name and password, are securely stored in an Oracle wallet created for this purpose. The autologin feature of this wallet is turned on, so the system does not need a password to open the wallet. From the wallet, it gets the credentials to access the database for the user they represent.
Fix: F-57105r1_fix
Design DBMS application code and batch job code that is compiled, encoded or encrypted, to NOT contain passwords. - - - - - Oracle provides the capability to provide for a secure external password facility. Use the Oracle mkstore to create a secure storage area for passwords for applications, batch jobs, and scripts to use or deploy a site-authorized facility to perform this function. Check to see what has been stored in the Oracle3 External Password Store To view all contents of a client wallet external password store, check specific credentials by viewing them. Listing the external password store contents provides information you can use to decide whether to add or delete credentials from the store. To list the contents of the external password store, enter the following command at the command line: $ mkstore -wrl wallet_location -listCredential For example: $ mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -listCredential The wallet_location specifies the path to the directory where the wallet, whose external password store contents you want to view, is located. This command lists all of the credential database service names (aliases) and the corresponding user name (schema) for that database. Passwords are not listed. Configuring Clients to Use the External Password Store If your client is already configured to use external authentication, such as Windows native authentication or Secure Sockets Layer (SSL), then Oracle Database uses that authentication method. The same credentials used for this type of authentication are typically also used to log in to the database. For clients not using such authentication methods or wanting to override them for database authentication, you can set the SQLNET.WALLET_OVERRIDE parameter in sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE, allowing standard use of authentication credentials as before. If you want a client to use the secure external password store feature, then perform the following configuration task: 1. Create a wallet on the client by using the following syntax at the command line: mkstore -wrl wallet_location -create For example: mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -create Enter password: password The wallet_location is the path to the directory where you want to create and store the wallet. This command creates an Oracle wallet with the autologin feature enabled at the location you specify. The autologin feature enables the client to access the wallet contents without supplying a password. The mkstore utility -create option uses password complexity verification. 2. Create database connection credentials in the wallet by using the following syntax at the command line: mkstore -wrl wallet_location -createCredential db_connect_string username Enter password: password For example: mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -createCredential oracle system Enter password: password In this specification: The wallet_location is the path to the directory where you created the wallet. The db_connect_string used in the CONNECT /@db_connect_string statement must be identical to the db_connect_string specified in the -createCredential command. The db_connect_string is the TNS alias you use to specify the database in the tnsnames.ora file or any service name you use to identify the database on an Oracle network. By default, tnsnames.ora is located in the $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME\network\admin on Windows. The username is the database login credential. When prompted, enter the password for this user. 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set it to the directory location of the wallet you created in Step 1. For example, if you created the wallet in $ORACLE_HOME/network/admin and your Oracle home is set to /private/ora11, then you need to enter the following into your client sqlnet.ora file: WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /private/ora11/network/admin) ) ) 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter and set it to TRUE as follows: SQLNET.WALLET_OVERRIDE = TRUE setting causes all CONNECT /@db_connect_string statements to use the information in the wallet at the specified location to authenticate to databases. When external authentication is in use, an authenticated user with such a wallet can use the CONNECT /@db_connect_string syntax to access the previously specified databases without providing a user name and password. However, if a user fails that external authentication, then these connect statements also fail. If an application uses SSL for encryption, then the sqlnet.ora parameter, SQLNET.AUTHENTICATION_SERVICES, specifies SSL, and an SSL wallet is created. If this application wants to use secret store credentials to authenticate to databases (instead of the SSL certificate), then those credentials must be stored in the SSL wallet. After SSL authentication, if SQLNET.WALLET_OVERRIDE = TRUE, then the user names and passwords from the wallet are used to authenticate to databases. If SQLNET.WALLET_OVERRIDE = FALSE, then the SSL certificate is used. Below is a sample sqlnet.ora file with the WALLET_LOCATION and the SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4. Below is a sample SQLNET.ORA File with Wallet Parameters Set WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /private/ora11/network/admin) ) ) SQLNET.WALLET_OVERRIDE = TRUE SSL_CLIENT_AUTHENTICATION = FALSE SSL_VERSION = 0
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000199
- Version
- O112-C2-015200
- Vuln IDs
-
- V-52291
- Rule IDs
-
- SV-66507r1_rule
Checks: C-54347r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. Review DBMS settings to determine if passwords must be changed periodically. If not, this is a finding: SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'PASSWORD_LIFE_TIME'; If the value is greater than 60 for any profile applied to user accounts, this is a finding. If the value is greater than 35 for any profile applied to user accounts, and the DBMS is configured to use Password Lifetime to disable inactive accounts (see requirement SRG-APP-000025-DB-000004), this is a finding.
Fix: F-57107r1_fix
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. If any user accounts are managed by Oracle: Modify DBMS settings to force users to periodically change their passwords. For example, using PPPPPP to stand for a profile name: ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35; Do this for each profile applied to user accounts. (Note that although the DoD requirement is for a password change every 60 days, using a value of 35 facilitates the use of PASSWORD_LIFE_TIME as a means of locking accounts inactive for 35 days, as required by SRG-APP-000025-DB-000004. But if 35 is not a practical or acceptable limit for password lifetime, set it to the standard DoD value of 60, and use another method to satisfy SRG-APP-000025-DB-000004.)
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000185
- Version
- O112-C2-015300
- Vuln IDs
-
- V-52293
- Rule IDs
-
- SV-66509r1_rule
Checks: C-54349r1_chk
Review DBMS configuration to verify the certificates being accepted by the DBMS have a valid certification path with status information to an accepted trust anchor. If certification paths are not being validated back to a trust anchor, this is a finding. - - - - - Oracle Advanced Security (ASO) Data Integrity: Oracle Advanced Security supports PKI-based authentication by using digital certificates over SSL in addition to the native encryption and data integrity capabilities of these protocols. Oracle provides a complete PKI that is based on RSA Security, Inc., Public-Key Cryptography Standards, and which interoperates with Oracle servers and clients. Oracle Advanced Security uses a wallet which is a container that is used to store authentication and signing credentials, including private keys, certificates, and trusted certificates needed by SSL. In an Oracle environment, every entity that communicates over SSL must have a wallet containing an X.509 version 3 certificate, private key, and list of trusted certificates. Security administrators use Oracle Wallet Manager to manage security credentials on the server. Unix and Windows platforms can be checked by selecting installed products in the Oracle Universal Installer (OUI). Select the Oracle home, and, from Contents tab, drill down to Enterprise Edition Options. On Unix you can also run the adapters command $ adapters Installed Oracle Advanced Security options are: RC4 40-bit encryption RC4 56-bit encryption RC4 128-bit encryption RC4 256-bit encryption DES40 40-bit encryption DES 56-bit encryption 3DES 112-bit encryption 3DES 168-bit encryption AES 128-bit encryption AES 192-bit encryption AES 256-bit encryption MD5 crypto-checksumming SHA-1 crypto-checksumming Kerberos v5 authentication RADIUS authentication If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries, ASO with SSL is installed. The following entries in the sqlnet.ora will be generated when SSL is installed. #SSL WALLET_LOCATION = (SOURCE= (METHOD = FILE) (METHOD_DATA = DIRECTORY=/wallet) SSL_CIPHER_SUITES=(SSL_cipher_suiteExample) SSL_VERSION= 3 SSL_CLIENT_AUTHENTICATION=FALSE/TRUE
Fix: F-57109r1_fix
Configure the DBMS to validate certificates by constructing a certification path with status information to an accepted trust anchor. Install Oracle Advanced Security Option to support Secure Sockets Layer (SSL) protocols and the Oracle Wallet to store authentication and signing credentials including private keys.
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000187
- Version
- O112-C2-015500
- Vuln IDs
-
- V-52295
- Rule IDs
-
- SV-66511r1_rule
Checks: C-54351r1_chk
Review DBMS configuration to verify DBMS user accounts are being mapped directly to authenticated identity information being passed via the PKI. If user accounts are not being mapped to authenticated identity information being passed via the PKI, this is a finding. - - - - - Oracle Advanced Security (ASO) Data Integrity: Oracle Advanced Security supports PKI-based authentication by using digital certificates over SSL in addition to the native encryption and data integrity capabilities of these protocols. Oracle provides a complete PKI that is based on RSA Security, Inc., Public-Key Cryptography Standards, and which interoperates with Oracle servers and clients. Oracle Advanced Security uses a wallet which is a container that is used to store authentication and signing credentials, including private keys, certificates, and trusted certificates needed by SSL. In an Oracle environment, every entity that communicates over SSL must have a wallet containing an X.509 version 3 certificate, private key, and list of trusted certificates. Security administrators use Oracle Wallet Manager to manage security credentials on the server. Unix and Windows platforms can be checked by selecting installed products in the Oracle Universal Installer (OUI). Select the Oracle home, and, from Contents tab, drill down to Enterprise Edition Options. On Unix you can also run the adapters command $ adapters Installed Oracle Advanced Security options are: RC4 40-bit encryption RC4 56-bit encryption RC4 128-bit encryption RC4 256-bit encryption DES40 40-bit encryption DES 56-bit encryption 3DES 112-bit encryption 3DES 168-bit encryption AES 128-bit encryption AES 192-bit encryption AES 256-bit encryption MD5 crypto-checksumming SHA-1 crypto-checksumming Kerberos v5 authentication RADIUS authentication If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries, ASO with SSL is installed. The following entries in the sqlnet.ora will be generated when SSL is installed. #SSL WALLET_LOCATION = (SOURCE= (METHOD = FILE) (METHOD_DATA = DIRECTORY=/wallet) SSL_CIPHER_SUITES=(SSL_cipher_suiteExample) SSL_VERSION= 3 SSL_CLIENT_AUTHENTICATION=FALSE/TRUE
Fix: F-57111r1_fix
Configure the DBMS to map the authenticated identity directly to the DBMS user account.
- RMF Control
- IA-7
- Severity
- M
- CCI
- CCI-000803
- Version
- O112-C2-015700
- Vuln IDs
-
- V-52297
- Rule IDs
-
- SV-66513r1_rule
Checks: C-54353r1_chk
Review DBMS configuration to verify the DBMS is using NIST-validated FIPS 140-2-compliant cryptography for all authentication mechanisms. If NIST-validated FIPS 140-2-compliant cryptography is not being used for all authenticated mechanisms, this is a finding. - - - - - Check the Oracle SQLNET.ORA file for the following settings to see if Oracle Advanced Security option is installed. If Oracle Advanced Security Option is not installed, check with the DBA and SYSTEM Administrator to see if other mechanisms or third-party products are deployed to encrypt data during the transmission. The SQLNET.ORA is located in the $ORACLE_HOME/network/admin directory by default. Check the environment variable TNS_ADMIN to see exactly where the files are located. Use the following command to check the location in your environment. $ echo $TNS_ADMIN Oracle Advanced Security Network Encryption Settings #ASO Encryption sqlnet.encryption_server=accepted sqlnet.encryption_client=requested sqlnet.encryption_types_server=(AES_256) sqlnet.encryption_types_client=(AES_256) Oracle Advanced Security Network Data Integrity Settings #ASO Checksum sqlnet.crypto_checksum_server=requested sqlnet.crypto_checksum_client=requested sqlnet.crypto_checksum_types_server = (SHA1) sqlnet.crypto_checksum_types_client = (SHA1)
Fix: F-57113r6_fix
Utilize NIST-validated FIPS 140-2-compliant cryptography for all authentication mechanisms. The strength requirements are dependent upon data classification. For unclassified data, where cryptography is required: AES 128 for encryption SHA 256 for hashing NSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows. AES 128 for Secret AES 256 for Top Secret SHA 256 for Secret SHA 384 for Top Secret National Security System is defined as: (OMB Circular A-130) Any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). There is more information on this topic in the Oracle Database 11.2g Advanced Security Administrator's Guide, which may be found at http://docs.oracle.com/cd/E11882_01/network.112/e40393.pdf FIPS 140-2 can be downloaded from http://csrc.nist.gov/publications/PubsFIPS.html#140-2
- RMF Control
- MA-4
- Severity
- M
- CCI
- CCI-000888
- Version
- O112-C2-016000
- Vuln IDs
-
- V-52299
- Rule IDs
-
- SV-66515r1_rule
Checks: C-54355r1_chk
Review DBMS configuration to determine if cryptographic mechanisms are being utilized to protect the integrity and confidentiality of non-local maintenance and diagnostic communications. If not, this is a finding.
Fix: F-57115r1_fix
Configure DBMS to utilize cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications.
- RMF Control
- MA-4
- Severity
- M
- CCI
- CCI-000877
- Version
- O112-C2-016100
- Vuln IDs
-
- V-52301
- Rule IDs
-
- SV-66517r1_rule
Checks: C-54357r1_chk
Review DBMS settings to determine whether strong identification and authentication techniques are required for non-local maintenance and diagnostic sessions. If strong identification and authentication techniques are not required, this is a finding.
Fix: F-57117r1_fix
Configure DBMS settings to use strong identification and authentication techniques for non-local maintenance and diagnostic sessions.
- RMF Control
- MP-2
- Severity
- M
- CCI
- CCI-001009
- Version
- O112-C2-016300
- Vuln IDs
-
- V-52303
- Rule IDs
-
- SV-66519r1_rule
Checks: C-54359r1_chk
If data is written to portable media, the data must be protected and access restricted via cryptographic mechanisms. Review system documentation and interview DBA to determine whether data is ever written directly from Oracle to portable media. If this is the case, and cryptographic mechanisms are not used to protect data written to portable media, this is a finding. If all data writing from Oracle to portable media is done via intermediate files, pipes, or other non-portable resources under the control of the operating system, then this is not a finding with respect to Oracle. (Note, however, that if encryption is not in use, it may be a finding with respect to the OS or the application that is used to perform the data transfer.)
Fix: F-57119r1_fix
Reconfigure processes that write to portable digital media so that they use cryptographic mechanisms to restrict access and protect the information.
- RMF Control
- MP-4
- Severity
- M
- CCI
- CCI-001019
- Version
- O112-C2-016400
- Vuln IDs
-
- V-52305
- Rule IDs
-
- SV-66521r1_rule
Checks: C-54361r1_chk
Review DBMS settings to determine whether data stored on the database is encrypted according to organizational requirements. If not, this is a finding. Determine whether the Oracle DBMS software is at version 11.2.0.4 with the January 2014 CPU (or above). If it is not, this is a finding.
Fix: F-57121r7_fix
Deploy Oracle 11.2.0.4 with the January 2014 CPU patch. Configure cryptographic functions to use FIPS 140-2-compliant algorithms and hashing functions. Configure the DBMS to encrypt data at rest according to the requirements of the organization. The strength requirements are dependent upon data classification. For unclassified data, where cryptography is required: AES 128 for encryption SHA 256 for hashing NSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows. AES 128 for Secret AES 256 for Top Secret SHA 256 for Secret SHA 384 for Top Secret National Security System is defined as: (OMB Circular A-130) Any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). There is more information on this topic in the Oracle Database 11.2g Advanced Security Administrator's Guide, which may be found at http://docs.oracle.com/cd/E11882_01/network.112/e40393.pdf FIPS 140-2 can be downloaded from http://csrc.nist.gov/publications/PubsFIPS.html#140-2
- RMF Control
- SC-10
- Severity
- M
- CCI
- CCI-001133
- Version
- O112-C2-016500
- Vuln IDs
-
- V-52307
- Rule IDs
-
- SV-66523r1_rule
Checks: C-54363r1_chk
Review DBMS settings, OS settings, and vendor documentation to verify network connections are terminated when a database communications session is ended or after a DoD-defined period of inactivity. If the network connection is not terminated, this is a finding. The defined duration for these timeouts is 10 minutes for in-band management and 15 minutes for user sessions, except to fulfill documented and validated mission requirements.
Fix: F-57123r1_fix
Configure DBMS and/or OS settings to disconnect network sessions when database communication sessions have ended or after the DoD-defined period of inactivity. To configure this in Oracle, modify each relevant profile. The resource name is IDLE_TIME, which is expressed in minutes. Using PPPPPP as an example of a profile, set the timeout to 10 minutes with: ALTER PROFILE PPPPPP LIMIT IDLE_TIME 10;
- RMF Control
- SC-13
- Severity
- M
- CCI
- CCI-001144
- Version
- O112-C2-016600
- Vuln IDs
-
- V-52309
- Rule IDs
-
- SV-66525r1_rule
Checks: C-54365r1_chk
If the DBMS has not implemented federally required cryptographic protections for the level of classification of the data it contains, this is a finding. Determine whether the Oracle DBMS software is at version 11.2.0.4 with the January 2014 CPU (or above). If it is not, this is a finding.
Fix: F-57125r6_fix
Implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. Deploy Oracle 11.2.0.4 with the January 2014 CPU patch. Configure cryptographic functions to use FIPS 140-2 compliant algorithms and hashing functions. The strength requirements are dependent upon data classification. For unclassified data, where cryptography is required: AES 128 for encryption SHA 256 for hashing NSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows. AES 128 for Secret AES 256 for Top Secret SHA 256 for Secret SHA 384 for Top Secret National Security System is defined as: (OMB Circular A-130) Any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). There is more information on this topic in the Oracle Database 11.2g Advanced Security Administrator's Guide, which may be found at http://docs.oracle.com/cd/E11882_01/network.112/e40393.pdf FIPS 140-2 can be downloaded from http://csrc.nist.gov/publications/PubsFIPS.html#140-2
- RMF Control
- SC-13
- Severity
- M
- CCI
- CCI-001144
- Version
- O112-C2-016700
- Vuln IDs
-
- V-52311
- Rule IDs
-
- SV-66527r1_rule
Checks: C-54367r1_chk
Review the system documentation to determine whether the database handles classified information. If the database handles classified information, upgrade the severity Category Code to I. Review the system documentation to discover sensitive or classified data identified by the Information Owner that requires encryption. If no sensitive or classified data is identified as requiring encryption by the Information Owner, this is not a finding. Have the DBA use select statements in the database to review sensitive data stored in tables as identified in the system documentation. If all sensitive data 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.
Fix: F-57127r5_fix
Obtain and utilize native or third-party NIST-validated FIPS 140-2-compliant cryptography solution for the DBMS. Configure cryptographic functions to use FIPS 140-2-compliant algorithms and hashing functions. Deploy Oracle 11.2.0.4 with the January 2014 CPU patch. The strength requirements are dependent upon data classification. For unclassified data, where cryptography is required: AES 128 for encryption SHA 256 for hashing NSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows. AES 128 for Secret AES 256 for Top Secret SHA 256 for Secret SHA 384 for Top Secret National Security System is defined as: (OMB Circular A-130) Any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). There is more information on this topic in the Oracle Database 11.2g Advanced Security Administrator's Guide, which may be found at http://docs.oracle.com/cd/E11882_01/network.112/e40393.pdf FIPS 140-2 can be downloaded from http://csrc.nist.gov/publications/PubsFIPS.html#140-2
- RMF Control
- CM-5
- Severity
- H
- CCI
- CCI-001499
- Version
- O112-C1-011100
- Vuln IDs
-
- V-52327
- Rule IDs
-
- SV-66543r1_rule
Checks: C-54369r1_chk
Follow the vendor instruction for determining the product version number. View the vendor-provided list of supported versions. To be considered supported, the vendor must report that the version is supported by security patches to reported vulnerabilities. If the security patch support for the installed version cannot be determined or the version is not shown as supported, this is a finding. If the software does not contain the latest security patches, this is a finding. - - - - - Oracle produces security patches on a quarterly basis on or about the fifteenth of the month. The first patch of a calendar year is delivered in January and then April, July and October respectively. There is an automated notice that is available to anyone with access to My Oracle Support. Check to see if the DBA or Administrator of the Oracle account at My Oracle Support is registered to receive the Oracle Security Patch notice. This notice is available to anyone with a valid My Oracle Support. The security notification contains information on the current security update and also the platforms and versions that will be supported by the next patch. For complete information on the availability of the security patch for your specific system, please refer to the Oracle Lifetime Support Policy. Check My Oracle Support for the latest Oracle Quarterly Patch Update patch number, and then check the inventory of the instance you are reviewing and see if the latest security patch is installed using the following command. As the Oracle user issue the following command. $ <ORACLE_HOME>/OPatch/opatch lsinventory -detail -oh <ORACLE_HOME> Check to see if the latest available patch is installed.
Fix: F-57145r1_fix
Upgrade the DBMS to a vendor-supported version. Apply latest DBMS patches.
- RMF Control
- IA-5
- Severity
- H
- CCI
- CCI-000199
- Version
- O112-C1-015000
- Vuln IDs
-
- V-52329
- Rule IDs
-
- SV-66545r1_rule
Checks: C-54371r1_chk
Use this query to identify the Oracle-supplied accounts that still have their default passwords: SELECT * FROM SYS.DBA_USERS_WITH_DEFPWD; If any accounts are listed, this is a finding.
Fix: F-57147r1_fix
Change passwords for DBMS accounts to non-default values. Where necessary, unlock or enable accounts to change the password, and then return the account to disabled or locked status.
- RMF Control
- IA-5
- Severity
- H
- CCI
- CCI-000186
- Version
- O112-C1-015400
- Vuln IDs
-
- V-52331
- Rule IDs
-
- SV-66547r1_rule
Checks: C-54373r2_chk
Review DBMS configuration to determine whether appropriate access controls exist to protect the DBMS's private key. If strong access controls do not exist to enforce authorized access to the private key, this is a finding. - - - - - Oracle Advanced Security supports authentication by using digital certificates over SSL in addition to the native encryption and data integrity capabilities of these protocols. An Oracle Wallet is a container that is used to store authentication and signing credentials, including private keys, certificates, and trusted certificates needed by SSL. In an Oracle environment, every entity that communicates over SSL must have a wallet containing an X.509 version 3 certificate, private key, and list of trusted certificates, with the exception of Diffie-Hellman. Security administrators use Oracle Wallet Manager to manage security credentials on the server. Wallet owners use it to manage security credentials on clients. Specifically, you use Oracle Wallet Manager to do the following: Unix and Windows platforms can be checked, by selecting installed products in the Oracle Universal Installer (OUI). Select the Oracle home, and, from Contents tab, drill down to Enterprise Edition Options. On Unix you can also run the adapters command $ adapters Installed Oracle Advanced Security options are: RC4 40-bit encryption RC4 56-bit encryption RC4 128-bit encryption RC4 256-bit encryption DES40 40-bit encryption DES 56-bit encryption 3DES 112-bit encryption 3DES 168-bit encryption AES 128-bit encryption AES 192-bit encryption AES 256-bit encryption MD5 crypto-checksumming SHA-1 crypto-checksumming Kerberos v5 authentication RADIUS authentication If the $ORACLE_HOME/network/admin/sqlnet.ora contains the following entries, ASO with SSL is installed. The following entries in the sqlnet.ora will be generated when SSL is installed. #SSL WALLET_LOCATION = (SOURCE=(METHOD = FILE) (METHOD_DATA = DIRECTORY=/wallet) SSL_CIPHER_SUITES=(SSL_cipher_suiteExample) SSL_VERSION= 3 SSL_CLIENT_AUTHENTICATION=FALSE/TRUE
Fix: F-57149r2_fix
Implement strong access and authentication controls to protect the database's private key. Install Oracle Advanced Security Option to support Secure Sockets Layer (SSL) protocols and the Oracle Wallet to store authentication and signing credentials including private keys.
- RMF Control
- SC-9
- Severity
- H
- CCI
- CCI-001131
- Version
- O112-C1-019700
- Vuln IDs
-
- V-52333
- Rule IDs
-
- SV-66549r1_rule
Checks: C-54375r1_chk
Check DBMS settings to determine whether cryptographic mechanisms are used to prevent the unauthorized disclosure of information during transmission. Determine whether physical measures are being used instead of cryptographic mechanisms. If neither cryptographic nor physical measures are being utilized, this is a finding. Check the Oracle SQLNET.ORA for the following settings to see if Oracle Advanced Security option is installed. If Oracle Advanced Security Option is not installed, check with the DBA and System Administrator to see if other mechanisms or third-party products are deployed to encrypt data during the transmission. The SQLNET.ORA is located in the $ORACLE_HOME/network/admin directory by default. Check the environment variable TNS_ADMIN to see exactly where the files are located. Use the following command to check the location in your environment. $ echo $TNS_ADMIN Oracle Advanced Security Network Encryption Settings #ASO Encryption sqlnet.encryption_server=accepted sqlnet.encryption_client=requested sqlnet.encryption_types_server=(AES_256) sqlnet.encryption_types_client=(AES_256) Oracle Advanced Security Network Data Integrity Settings #ASO Checksum sqlnet.crypto_checksum_server=requested sqlnet.crypto_checksum_client=requested sqlnet.crypto_checksum_types_server = (SHA1) sqlnet.crypto_checksum_types_client = (SHA1)
Fix: F-57153r1_fix
Configure DBMS and/or operating system to use cryptographic mechanisms to prevent unauthorized disclosure of information during transmission where physical measures are not being utilized.
- RMF Control
- AC-10
- Severity
- M
- CCI
- CCI-000054
- Version
- O112-C2-000100
- Vuln IDs
-
- V-52337
- Rule IDs
-
- SV-66553r1_rule
Checks: C-54377r1_chk
Retrieve the settings for concurrent sessions for each profile with the query: SELECT * FROM SYS.DBA_PROFILES WHERE RESOURCE_NAME = 'SESSIONS_PER_USER'; If the DBMS settings for concurrent sessions for each profile are greater than the DoD-defined maximum number of sessions (2 for non-privileged accounts; 3 for privileged accounts), this is a finding.
Fix: F-57155r1_fix
Limit concurrent connections for each system account to a number less than or equal to the organization-defined number of sessions using the following SQL. Create profiles that conform to the DoD requirements. Assign users to the appropriate profile. Change the value of SESSIONS_PER_USER (along with the other parameters, where relevant) from UNLIMITED to DoD-compliant, site-specific requirements and then assign users to the profile (the name PPPPP is an example; use a name appropriate to your circumstance): CREATE PROFILE "PPPPPP" LIMIT CPU_PER_SESSION UNLIMITED CPU_PER_CALL UNLIMITED CONNECT_TIME UNLIMITED IDLE_TIME UNLIMITED SESSIONS_PER_USER UNLIMITED LOGICAL_READS_PER_SESSION UNLIMITED LOGICAL_READS_PER_CALL UNLIMITED PRIVATE_SGA UNLIMITED COMPOSITE_LIMIT UNLIMITED PASSWORD_LIFE_TIME 180 PASSWORD_GRACE_TIME 7 PASSWORD_REUSE_MAX UNLIMITED PASSWORD_REUSE_TIME UNLIMITED PASSWORD_LOCK_TIME 1 FAILED_LOGIN_ATTEMPTS 10 PASSWORD_VERIFY_FUNCTION NULL To assign the user to the profile do the following: ALTER USER user1 PROFILE PPPPPP;
- RMF Control
- AC-17
- Severity
- M
- CCI
- CCI-000068
- Version
- O112-C2-001200
- Vuln IDs
-
- V-52339
- Rule IDs
-
- SV-66555r1_rule
Checks: C-54379r1_chk
Review settings to determine if DBMS is configured to accept remote connections. (Note that "remote" means "from outside the DoD Information Network (DoDIN)", and connections via approved Virtual Private Networks (VPNs) are considered to be inside the DoDIN.) If the DBMS is not configured to accept remote connections, this is not a finding. Check DBMS settings to determine whether the authentication data for remote connections is being encrypted with approved cryptography. If authentication data for remote connections is not being encrypted with approved cryptography, this is a finding. To check that the Oracle Advanced Security Option is enabled and using site-specified encryption procedures, look in SQLNET.ORA located at $ORACLE_HOME/network/admin/sqlnet.ora. If encryption is set in the Advanced Security Option, entries like the following will be present. #ASO Encryption sqlnet.encryption_server=accepted sqlnet.encryption_client=requested sqlnet.crypto_seed = 'uolPTYz\(!)713@' sqlnet.encryption_types_server=(SHA-1) sqlnet.encryption_types_client=(SHA-1) To list the supported encryption algorithms, crypto-checksums, and authentication methods provided by OAS, execute the adapters command: $adapters ................................................................................ Installed Oracle Advanced Security options are: RC4 40-bit encryption RC4 56-bit encryption RC4 128-bit encryption RC4 256-bit encryption DES40 40-bit encryption DES 56-bit encryption 3DES 112-bit encryption 3DES 168-bit encryption AES 128-bit encryption AES 192-bit encryption AES 256-bit encryption MD5 crypto-checksumming SHA-1 crypto-checksumming Kerberos v5 authentication RADIUS authentication From this listing, RC4, AES, and DES families are symmetric key algorithms, and also named ciphers. A symmetric key cipher will use the same key for both encryption and decryption. RC4 ciphers are stream-based ciphers; AES and DES are block-based ciphers. Stream ciphers encrypt every bit individually by adding a key stream bit to a plain text bit. Depending on implementation there could be synchronous stream ciphers (the key stream depends only on the key) and asynchronous stream ciphers (the key stream also depends on the ciphertext). These types of ciphers have the advantage of being very fast compared to block ciphers but are more vulnerable to attacks. RC4 has a demonstrated weakness related to key setup, hence you should use the high key length variant (RC4 256) whenever possible. The stream ciphers provided by Oracle OAS are RC4 40, RC4 56, RC4 128, and RC4 256 bits, where 40, 56, 128, and 256 represent the key length. Block-based ciphers encrypt an entire block of bits at a time using the same key. This means that every bit from a block depends on every bit on the same block. AES is the abbreviation for Advanced Encryption Standard, and should be favored based on its solidity and good performance. It is a derivation of the Rijndael cipher where the block size is restricted to 128 bits. It was designed to replace the DES algorithm. DES is the abbreviation for Data Encryption Standard. The original DES, based on the 56 bit key, is rarely used nowadays and is considered insecure. 3DES112 is a variant of 3DES, also called Triple DES, with two keys derived from the fact that it is using two keys, each being 56 bits in size or two phases of encryption. 3DES168 is a variant of 3DES using three 56 bits key or phases for encryption. It is strong but slow in software-based implementations. Based on the fact that symmetric encryption is used, there must be a mechanism that allows exchanging the encryption keys between the parties involved in communication. The key exchange phase uses the Diffie-Hellman key exchange algorithm. In the Diffie-Hellman key exchange the two parties have to agree on a random generated number known only to them. Based on this random number, after a series of transformations, an encryption key is generated (for RSA Laboratories - 3.6.1 What is Diffie-Hellman? go to http://www.rsa.com/rsalabs/node.asp?id=2248) and used for data encryption. The encryption seed is used and strongly correlated with the generation of the random numbers. OAS network encryption uses CBC as the cipher mode of operation. For the desired encryption behavior you can specify four parameters, both on the server and on client side: REJECTED, ACCEPTED, REQUESTED, and REQUIRED. The following table summarizes the combinations of parameters for desired behavior on client and server: Desired behavior - Client Desired behavior - Server Encryption ------------------------- ------------------------- ---------------- ACCEPTED REJECTED OFF REQUESTED REJECTED OFF REQUIRED REJECTED Connection fails REJECTED ACCEPTED OFF ACCEPTED ACCEPTED OFF REQUESTED ACCEPTED ON REQUIRED ACCEPTED ON REJECTED REQUESTED OFF ACCEPTED REQUESTED ON REQUESTED REQUESTED ON REQUIRED REQUESTED ON REJECTED REQUIRED Connection fails ACCEPTED REQUIRED ON REQUESTED REQUIRED ON REQUIRED REQUIRED ON
Fix: F-57157r5_fix
If the database accepts remote connections, but is not authenticating using approved cryptography, modify SQLNET.ORA to enable encryption, using an approved algorithm. The strength requirements are dependent upon data classification. For unclassified data, where cryptography is required: AES 128 for encryption SHA 256 for hashing NSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows. AES 128 for Secret AES 256 for Top Secret SHA 256 for Secret SHA 384 for Top Secret National Security System is defined as: (OMB Circular A-130) Any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications).
- RMF Control
- AC-17
- Severity
- M
- CCI
- CCI-000068
- Version
- O112-C2-001300
- Vuln IDs
-
- V-52341
- Rule IDs
-
- SV-66557r1_rule
Checks: C-54381r1_chk
Review settings to determine if DBMS is configured to accept remote connections. (Note that "remote" means "from outside the DoD Information Network (DoDIN)", and connections via approved Virtual Private Networks (VPNs) are considered to be inside the DoDIN.) If the DBMS is not configured to accept remote connections, this is not a finding. Check DBMS settings to determine whether the authentication data for remote connections is being encrypted with approved cryptography. If authentication data for remote connections is not being encrypted with approved cryptography, this is a finding. To check that the Oracle Advanced Security Option is enabled and using site-specified encryption procedures, look in SQLNET.ORA located at $ORACLE_HOME/network/admin/sqlnet.ora. If encryption is set in the Advanced Security Option, entries like the following will be present. #ASO Encryption sqlnet.encryption_server=accepted sqlnet.encryption_client=requested sqlnet.crypto_seed = 'uolPTYz\(!)713@' sqlnet.encryption_types_server=(SHA-1) sqlnet.encryption_types_client=(SHA-1) To list the supported encryption algorithms, crypto-checksums, and authentication methods provided by OAS, execute the adapters command: $adapters ................................................................................ Installed Oracle Advanced Security options are: RC4 40-bit encryption RC4 56-bit encryption RC4 128-bit encryption RC4 256-bit encryption DES40 40-bit encryption DES 56-bit encryption 3DES 112-bit encryption 3DES 168-bit encryption AES 128-bit encryption AES 192-bit encryption AES 256-bit encryption MD5 crypto-checksumming SHA-1 crypto-checksumming Kerberos v5 authentication RADIUS authentication From this listing, RC4, AES, and DES families are symmetric key algorithms, and also named ciphers. A symmetric key cipher will use the same key for both encryption and decryption. RC4 ciphers are stream-based ciphers; AES and DES are block-based ciphers. Stream ciphers encrypt every bit individually by adding a key stream bit to a plain text bit. Depending on implementation there could be synchronous stream ciphers (the key stream depends only on the key) and asynchronous stream ciphers (the key stream also depends on the ciphertext). These types of ciphers have the advantage to be very fast compared to block ciphers but are more vulnerable to attacks. RC4 has a demonstrated weakness related to key setup hence you should use the high key length variant (RC4 256) whenever possible. The stream ciphers provided by Oracle OAS are RC4 40, RC4 56, RC4 128, and RC4 256 bits, where 40, 56, 128, and 256 represent the key length. Block-based ciphers encrypt an entire block of bits at a time using the same key. This means that every bit from a block depends on every bit on the same block. AES is the abbreviation for Advanced Encryption Standard, and should be favored based on its solidity and good performance. It is a derivation of the Rijndael cipher where the block size is restricted to 128 bits. It was designed to replace the DES algorithm. DES is the abbreviation for Data Encryption Standard. The original DES, based on the 56 bit key, is rarely used nowadays and is considered insecure. 3DES112 is a variant of 3DES, also called Triple DES, with two keys derived from the fact that it is using two keys each being 56 bits in size or two phases of encryption. 3DES168 is a variant of 3DES using three 56 bits key or phases for encryption. It is strong but slow in software-based implementations. Based on the fact that symmetric encryption is used, there must be a mechanism that allows exchanging the encryption keys between the parties involved in communication. The key exchange phase uses the Diffie-Hellman key exchange algorithm. In the Diffie-Hellman key exchange the two parties have to agree on a random generated number known only to them. Based on this random number, after a series of transformations an encryption key is generated (for RSA Laboratories - 3.6.1 What is Diffie-Hellman? go to http://www.rsa.com/rsalabs/node.asp?id=2248) and used for data encryption. The encryption seed is used and strongly correlated with the generation of the random numbers. OAS network encryption uses CBC as the cipher mode of operation. For the desired encryption behavior you can specify four parameters both on the server and on client side: REJECTED, ACCEPTED, REQUESTED, and REQUIRED. The following table summarizes the combinations of parameters for desired behavior on client and server: Desired behavior - Client Desired behavior - Server Encryption ------------------------- ------------------------- ---------------- ACCEPTED REJECTED OFF REQUESTED REJECTED OFF REQUIRED REJECTED Connection fails REJECTED ACCEPTED OFF ACCEPTED ACCEPTED OFF REQUESTED ACCEPTED ON REQUIRED ACCEPTED ON REJECTED REQUESTED OFF ACCEPTED REQUESTED ON REQUESTED REQUESTED ON REQUIRED REQUESTED ON REJECTED REQUIRED Connection fails ACCEPTED REQUIRED ON REQUESTED REQUIRED ON REQUIRED REQUIRED ON
Fix: F-57159r5_fix
If the database accepts remote connections, but is not using approved cryptography for data transmission, modify SQLNET.ORA to enable encryption, using an approved algorithm. The strength requirements are dependent upon data classification. For unclassified data, where cryptography is required: AES 128 for encryption SHA 256 for hashing NSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows. AES 128 for Secret AES 256 for Top Secret SHA 256 for Secret SHA 384 for Top Secret National Security System is defined as: (OMB Circular A-130) Any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). The following table summarizes the combinations of parameters for desired behavior on client and server: Desired behavior - Client Desired behavior - Server Encryption -------------------------- ------------------------- ----------- ACCEPTED REJECTED OFF REQUESTED REJECTED OFF REQUIRED REJECTED Connection fails REJECTED ACCEPTED OFF ACCEPTED ACCEPTED OFF REQUESTED ACCEPTED ON REQUIRED ACCEPTED ON REJECTED REQUESTED OFF ACCEPTED REQUESTED ON REQUESTED REQUESTED ON REQUIRED REQUESTED ON REJECTED REQUIRED Connection fails ACCEPTED REQUIRED ON REQUESTED REQUIRED ON REQUIRED REQUIRED ON Set the SQLNET.ORA to the site-specific requirements: #ASO Encryption sqlnet.encryption_server=accepted sqlnet.encryption_client=requested sqlnet.crypto_seed = 'uolPTYz\(!)713@' sqlnet.encryption_types_server=(SHA-1) sqlnet.encryption_types_client=(SHA-1) "
- RMF Control
- AC-17
- Severity
- M
- CCI
- CCI-001453
- Version
- O112-C2-001400
- Vuln IDs
-
- V-52343
- Rule IDs
-
- SV-66559r1_rule
Checks: C-54383r1_chk
Review settings to determine if DBMS is configured to accept remote connections. (Note that "remote" means "from outside the DoD Information Network (DoDIN)", and connections via approved Virtual Private Networks (VPNs) are considered to be inside the DoDIN.) If the DBMS is not configured to accept remote connections, this is not a finding. Check DBMS settings to determine whether the authentication data for remote connections is being encrypted with approved cryptography. If authentication data for remote connections is not being encrypted with approved cryptography, this is a finding. To check that the Oracle Advanced Security Option is enabled and using site-specified encryption procedures, look in SQLNET.ORA located at $ORACLE_HOME/network/admin/sqlnet.ora. If encryption is set in the Advanced Security Option, entries like the following will be present. #ASO Encryption sqlnet.encryption_server=accepted sqlnet.encryption_client=requested sqlnet.crypto_seed = 'uolPTYz\(!)713@' sqlnet.encryption_types_server=(SHA-1) sqlnet.encryption_types_client=(SHA-1) To list the supported encryption algorithms, crypto-checksums, and authentication methods provided by OAS, execute the adapters command: $adapters ................................................................................ Installed Oracle Advanced Security options are: RC4 40-bit encryption RC4 56-bit encryption RC4 128-bit encryption RC4 256-bit encryption DES40 40-bit encryption DES 56-bit encryption 3DES 112-bit encryption 3DES 168-bit encryption AES 128-bit encryption AES 192-bit encryption AES 256-bit encryption MD5 crypto-checksumming SHA-1 crypto-checksumming Kerberos v5 authentication RADIUS authentication From this listing, RC4, AES, and DES families are symmetric key algorithms, and also named ciphers. A symmetric key cipher will use the same key for both encryption and decryption. RC4 ciphers are stream-based ciphers, AES and DES are block-based ciphers. Stream ciphers encrypt every bit individually by adding a key stream bit to a plain text bit. Depending on implementation, there could be synchronous stream ciphers (the key stream depends only on the key) and asynchronous stream ciphers (the key stream also depends on the ciphertext). These types of ciphers have the advantage of being very fast compared to block ciphers but are more vulnerable to attacks. RC4 has a demonstrated weakness related to key setup, hence you should use the high key length variant (RC4 256) whenever possible. The stream ciphers provided by Oracle OAS are RC4 40, RC4 56, RC4 128, and RC4 256 bits, where 40, 56, 128, and 256 represent the key length. Block-based ciphers encrypt an entire block of bits at a time using the same key. This means that every bit from a block depends on every bit on the same block. AES is the abbreviation for Advanced Encryption Standard , and should be favored based on its solidity and good performance. It is a derivation of the Rijndael cipher where the block size is restricted to 128 bits. It was designed to replace the DES algorithm. DES is the abbreviation for Data Encryption Standard. The original DES, based on the 56 bit key, is rarely used nowadays and is considered insecure. 3DES112 is a variant of 3DES, also called Triple DES, with two keys derived from the fact that it is using two keys, each being 56 bits in size or two phases of encryption. 3DES168 is a variant of 3DES using three 56 bits key or phases for encryption. It is strong but slow in software-based implementations. Based on the fact that symmetric encryption is used, there must be a mechanism that allows exchanging the encryption keys between the parties involved in communication. The key exchange phase uses the Diffie-Hellman key exchange algorithm. In the Diffie-Hellman key exchange the two parties have to agree on a random generated number known only to them. Based on this random number, after a series of transformations an encryption key is generated (for RSA Laboratories - 3.6.1 What is Diffie-Hellman? go to http://www.rsa.com/rsalabs/node.asp?id=2248) and used for data encryption. The encryption seed is used and strongly correlated with the generation of the random numbers. OAS network encryption uses CBC as the cipher mode of operation. For the desired encryption behavior you can specify four parameters both on the server and on client side: REJECTED, ACCEPTED, REQUESTED, and REQUIRED. The following table summarizes the combinations of parameters for desired behavior on client and server: Desired behavior - Client Desired behavior - Server Encryption ------------------------- ------------------------- ---------------- ACCEPTED REJECTED OFF REQUESTED REJECTED OFF REQUIRED REJECTED Connection fails REJECTED ACCEPTED OFF ACCEPTED ACCEPTED OFF REQUESTED ACCEPTED ON REQUIRED ACCEPTED ON REJECTED REQUESTED OFF ACCEPTED REQUESTED ON REQUESTED REQUESTED ON REQUIRED REQUESTED ON REJECTED REQUIRED Connection fails ACCEPTED REQUIRED ON REQUESTED REQUIRED ON REQUIRED REQUIRED ON
Fix: F-57161r4_fix
If the database accepts remote connections, but is not using approved cryptography, modify SQLNET.ORA to enable encryption, using an approved algorithm. The strength requirements are dependent upon data classification. For unclassified data, where cryptography is required: AES 128 for encryption SHA 256 for hashing NSA has established the suite B encryption requirements for protecting National Security Systems (NSS) as follows. AES 128 for Secret AES 256 for Top Secret SHA 256 for Secret SHA 384 for Top Secret National Security System is defined as: (OMB Circular A-130) Any telecommunications or information system operated by the United States Government, the function, operation, or use of which (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) is critical to the direct fulfillment of military or intelligence missions, but excluding any system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). The following table summarizes the combinations of parameters for desired behavior on client and server: Desired behavior - Client Desired behavior - Server Encryption -------------------------- ------------------------- ----------- ACCEPTED REJECTED OFF REQUESTED REJECTED OFF REQUIRED REJECTED Connection fails REJECTED ACCEPTED OFF ACCEPTED ACCEPTED OFF REQUESTED ACCEPTED ON REQUIRED ACCEPTED ON REJECTED REQUESTED OFF ACCEPTED REQUESTED ON REQUESTED REQUESTED ON REQUIRED REQUESTED ON REJECTED REQUIRED Connection fails ACCEPTED REQUIRED ON REQUESTED REQUIRED ON REQUIRED REQUIRED ON Set the SQLNET.ORA to the site-specific requirements: #ASO Encryption sqlnet.encryption_server=accepted sqlnet.encryption_client=requested sqlnet.crypto_seed = 'uolPTYz\(!)713@' sqlnet.encryption_types_server=(SHA-1) sqlnet.encryption_types_client=(SHA-1)
- RMF Control
- AC-17
- Severity
- M
- CCI
- CCI-001454
- Version
- O112-C2-001600
- Vuln IDs
-
- V-52345
- Rule IDs
-
- SV-66561r1_rule
Checks: C-54385r1_chk
Review settings to determine if DBMS is configured to accept remote connections. (Note that "remote" means "from outside the DoD Information Network (DoDIN)", and connections via approved Virtual Private Networks (VPNs) are considered to be inside the DoDIN.) If the DBMS is not configured to accept remote connections, this is not a finding. Review DBMS settings and verify whether the auditing of security features accessed via remote database access is enabled. If auditing of security feature access is not enabled, this is a finding. - - - - - - - About the Default Auditing Settings When you use Database Configuration Assistant (DBCA) to create a new database, Oracle Database configures the database to audit the most commonly used security-relevant SQL statements and privileges. It also sets the AUDIT_TRAIL initialization parameter to DB EXTENDED. If you decide to use a different audit trail type (for example, OS if you want to write the audit trail records to operating system files), then you can do that, and Oracle Database continues to audit the privileges that are audited by default. If you disable auditing by setting the AUDIT_TRAIL parameter to NONE, then no auditing takes place. The reason we really need to use DB EXTENDED is because that will write audit records directly to a table. This query will list the system privileges assigned to a user SELECT LPAD(' ', 2*level) || granted_role "USER PRIVS" FROM ( SELECT NULL grantee, username, granted_role FROM dba_users WHERE username LIKE UPPER('%&uname%') UNION SELECT grantee, granted_role FROM dba_role_privs UNION SELECT grantee, privilege FROM dba_sys_privs) START WITH grantee IS NULL CONNECT BY grantee = prior granted_role; or SELECT path FROM ( SELECT grantee, sys_connect_by_path(privilege, ':')||':'||grantee path FROM ( SELECT grantee, privilege, 0 role FROM dba_sys_privs UNION ALL SELECT grantee, granted_role, 1 role FROM dba_role_privs) CONNECT BY privilege=prior grantee START WITH role = 0) WHERE grantee IN ( SELECT username FROM dba_users WHERE lock_date IS NULL AND password != 'EXTERNAL' AND username != 'SYS') OR grantee='PUBLIC'
Fix: F-57163r1_fix
Enable auditing of security feature access via remote connections. Satisfy the auditing requirement by enabling, deploying and configuring the Oracle Audit Vault, or by running the SECCONF.SQL script - delivered in $ORACLE_HOME/rdbms/admin/secconf.sql. See the script for details, and customize according to site-specific requirements.
- RMF Control
- AC-17
- Severity
- M
- CCI
- CCI-001436
- Version
- O112-C2-001700
- Vuln IDs
-
- V-52347
- Rule IDs
-
- SV-66563r1_rule
Checks: C-54387r1_chk
Review the PPSM Technical Assurance List to acquire an up-to-date list of network protocols deemed non-secure. (For definitive information on Ports, Protocols and Services Management (PPSM), refer to http://iase.disa.mil/ppsm/index.html.) Review DBMS settings to determine if the database is utilizing any network protocols deemed non-secure. If the DBMS is not using any network protocols deemed non-secure, this is not a finding.. If the database is utilizing protocols specified as non-secure in the PPSM, verify the protocols are explicitly identified in the System Security Plan and that they are in support of specific operational requirements. If they are not identified in the SSP or are not supporting specific operational requirements, this is a finding. If non-secure network protocols are not being used but are not disabled in the DBMS's configuration, this is a finding. After determining the site-specific operational requirements and which protocols are explicitly defined in the System Security Plan, check the $TNS_ADMIN setting for the location of the Oracle listener.ora file. The listener.ora file is a configuration file for Oracle Net Listener that identifies the following: A unique name for the listener, typically LISTENER A protocol address that it is accepting connection requests on, and A service it is listening for. If the listener.ora file shows a PROTOCOL= statement and the PROTOCOL is deemed non-secure, that is a finding. LISTENER= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=sale-server)(PORT=1521)) (ADDRESS=(PROTOCOL=ipc)(KEY=extproc)))) SID_LIST_LISTENER= (SID_LIST= (SID_DESC= (GLOBAL_DBNAME=sales.us.example.com) (ORACLE_HOME=/oracle11g) (SID_NAME=sales)) (SID_DESC= (SID_NAME=plsextproc) (ORACLE_HOME=/oracle11g) (PROGRAM=extproc))) Protocol Parameters The Oracle Listener and the Oracle Connection Manager are identified by protocol addresses. The information below contains the "Protocol-Specific Parameters" used by the Oracle protocol support. Protocol-Specific Parameters Protocol: IPC Parameter: PROTOCOL Notes: Specify ipc as the value. Protocol: IPC Parameter: KEY Notes: Specify a unique name for the service. Oracle recommends using the service name or SID of the service. Example: (PROTOCOL=ipc)(KEY=sales) Protocol: Named Pipes Parameter: PROTOCOL Notes: Specify nmp as the value. Protocol: Named Pipes Parameter: SERVER Notes: Specify the name of the Oracle server. Protocol: Named Pipes Parameter: PIPE Notes: Specify the pipe name used to connect to the database server. This is the same PIPE keyword specified on the server with Named Pipes. This name can be any name. Example: (Protocol=nmp) (SERVER=USDOD) (PIPE=dbpipe01) Protocol: SDP Parameter: PROTOCOL Notes: Specify sdp as the value. Protocol: SDP Parameter: HOST Notes: Specify the host name or IP address of the computer. Protocol: SDP Parameter: PORT Notes: Specify the listening port number. Example: (PROTOCOL=sdp)(HOST=sales-server)(PORT=1521) (PROTOCOL=sdp)(HOST=192.168.2.204)(PORT=1521) Protocol: TCP/IP Parameter: PROTOCOL Notes: Specify TCP as the value. Protocol: TCP/IP Parameter: HOST Notes: Specify the host name or IP address of the computer. Protocol: TCP/IP Parameter: PORT Notes: Specify the listening port number. Example: (PROTOCOL=tcp)(HOST=sales-server)(PORT=1521) (PROTOCOL=tcp)(HOST=192.168.2.204)(PORT=1521) Protocol: TCP/IP with SSL Parameter: PROTOCOL Notes: Specify tcps as the value. Protocol: TCP/IP with SSL Parameter: HOST Notes: Specify the host name or IP address of the computer. Protocol: TCP/IP with SSL Parameter: PORT Notes: Specify the listening port number. Example: (PROTOCOL=tcps)(HOST=sales-server) (PORT=2484) (PROTOCOL=tcps)(HOST=192.168.2.204)(PORT=2484)
Fix: F-57165r1_fix
Disable any network protocol listed as non-secure in the PPSM documentation. To disable the protocol deemed not secure, stop the listener by issuing the following command as the Oracle Software owner, typically Oracle. $ lsnrctl stop This will stop the listener. Edit the LISTENER.ORA file and remove the protocols deemed not secure and restart the listener. For example, if TCP was deemed as not secure and the listener.ora would need to be changed and the tcp entry would need to be removed. That would only allow the listener to listen for an IPC connection. LISTENER= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=sale-server)(PORT=1521)) - remove this line and properly balance the parentheses - (ADDRESS=(PROTOCOL=ipc)(KEY=extproc)))) SID_LIST_LISTENER= (SID_LIST= (SID_DESC= (GLOBAL_DBNAME=sales.us.example.com) (ORACLE_HOME=/oracle11g) (SID_NAME=sales)) (SID_DESC= (SID_NAME=plsextproc) (ORACLE_HOME=/oracle11g) (PROGRAM=extproc))) Revise the client side TNSNAMES.ORA to align the PROTOCOL value in the PROTOCOL portion of the connect string. For example, if TCP was deemed as not secure and the listener.ora was changed to listen for an IPC connection the code below would be required: net_service_name= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-svr)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-svr)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.example.com)))
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-000015
- Version
- O112-C2-001800
- Vuln IDs
-
- V-52349
- Rule IDs
-
- SV-66565r1_rule
Checks: C-54389r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. If there are some user accounts managed by Oracle, but the amount of account management activity is small, stop here: this is not a finding against the DBMS. Otherwise, this is a finding.
Fix: F-57167r1_fix
If all (or almost all) user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. Utilize a DBMS (Oracle), OS, or third-party product that can automate some or all account maintenance functionality. Roles and Profiles are two Oracle features that should be employed in account management. (Indeed, other requirements mandate the use of Roles.) Following are some notes from Oracle on the use of Profiles. A profile is a named set of resource limits and password parameters that restrict database usage and instance resources for a user. You can assign a profile to each user, and a default profile to all others. Each user can have only one profile, and creating a new one supersedes any earlier one. Profile resource limits are enforced only when you enable resource limitation for the associated database. Enabling such limitation can occur either before starting up the database (the RESOURCE_LIMIT initialization parameter) or while it is open (using an ALTER SYSTEM statement). While password parameters reside in profiles, they are unaffected by RESOURCE_LIMIT or ALTER SYSTEM and password management is always enabled. In Oracle Database 10g Release 2 (10.2), resource allocations and restrictions are primarily handled through the Database Resource Manager.
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-000016
- Version
- O112-C2-001900
- Vuln IDs
-
- V-52351
- Rule IDs
-
- SV-66567r1_rule
Checks: C-54391r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. If using database mechanisms to satisfy this requirement, look for a profile for use with temporary accounts. To obtain a list of profiles: SELECT PROFILE#, NAME FROM SYS.PROFNAME$; To obtain a list of users assigned a given profile (TEMPORARY_USERS, in this example): SELECT USERNAME, PROFILE FROM SYS.DBA_USERS WHERE PROFILE = 'TEMPORARY_USERS' ORDER BY USERNAME;
Fix: F-57169r4_fix
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. If using database mechanisms to satisfy this requirement, use a profile with a distinctive name (for example, TEMPORARY_USERS), so that temporary users can be easily identified. Whenever a temporary user account is created, assign it to this profile. Set values in the profile as needed for temporary users - see below for specific details. CREATE PROFILE TEMPORARY_USERS LIMIT SESSIONS_PER_USER UNLIMITED CPU_PER_SESSION UNLIMITED CPU_PER_CALL 3000 CONNECT_TIME 45 LOGICAL_READS_PER_SESSION DEFAULT LOGICAL_READS_PER_CALL 1000 PRIVATE_SGA 15K COMPOSITE_LIMIT 5000000 FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LIFE_TIME 7 PASSWORD_REUSE_TIME 60 PASSWORD_REUSE_MAX 5 PASSWORD_VERIFY_FUNCTION verify_function PASSWORD_LOCK_TIME 1/24 PASSWORD_GRACE_TIME 10; CREATE USER TEMP001 IDENTIFIED BY PassWord#TEMP01 PROFILE TEMPORARY_USERS; Resource Parameters: SESSIONS_PER_USER Specify the number of concurrent sessions to which you want to limit the user. CPU_PER_SESSION Specify the CPU time limit for a session, expressed in hundredths of seconds. CPU_PER_CALL Specify the CPU time limit for a call (a parse, execute, or fetch), expressed in hundredths of seconds. CONNECT_TIME Specify the total elapsed time limit for a session, expressed in minutes. IDLE_TIME Specify the permitted periods of continuous inactive time during a session, expressed in minutes. Long-running queries and other operations are not subject to this limit. LOGICAL_READS_PER_SESSION Specify the permitted number of data blocks read in a session, including blocks read from memory and disk. LOGICAL_READS_PER_CALL Specify the permitted number of data blocks read for a call to process a SQL statement (a parse, execute, or fetch). PRIVATE_SGA Specify the amount of private space a session can allocate in the shared pool of the system global area (SGA). Refer to size_clause for information on that clause. Password Parameters Use the following clauses to set password parameters. Parameters that set lengths of time are interpreted in number of days. For testing purposes you can specify minutes (n/1440) or even seconds (n/86400). FAILED_LOGIN_ATTEMPTS Specify the number of failed attempts to log in to the user account before the account is locked. PASSWORD_LIFE_TIME Specify the number of days the same password can be used for authentication. If you also set a value for PASSWORD_GRACE_TIME, then the password expires if it is not changed within the grace period, and further connections are rejected. If you omit this clause, then the default is 180 days. PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX These two parameters must be set in conjunction with each other. PASSWORD_REUSE_TIME specifies the number of days before which a password cannot be reused. PASSWORD_REUSE_MAX specifies the number of password changes required before the current password can be reused. For these parameters to have any effect, you must specify an integer for both of them. If you specify an integer for both of these parameters, then the user cannot reuse a password until the password has been changed the number of times specified for PASSWORD_REUSE_MAX during the number of days specified for PASSWORD_REUSE_TIME. For example, if you specify PASSWORD_REUSE_TIME to 30 and PASSWORD_REUSE_MAX to 10, then the user can reuse the password after 30 days if the password has already been changed 10 times. If you specify an integer for either of these parameters and specify UNLIMITED for the other, then the user can never reuse a password. If you specify DEFAULT for either parameter, then Oracle Database uses the value defined in the DEFAULT profile. By default, all parameters are set to UNLIMITED in the DEFAULT profile. If you have not changed the default setting of UNLIMITED in the DEFAULT profile, then the database treats the value for that parameter as UNLIMITED. If you set both of these parameters to UNLIMITED, then the database ignores both of them. This is the default if you omit both parameters. PASSWORD_LOCK_TIME Specify the number of days an account will be locked after the specified number of consecutive failed login attempts. If you omit this clause, then the default is 1 day. PASSWORD_GRACE_TIME Specify the number of days after the grace period begins during which a warning is issued and login is allowed. If you omit this clause, then the default is 7 days. PASSWORD_VERIFY_FUNCTION The PASSWORD_VERIFY_FUNCTION clause lets a PL/SQL password complexity verification script be passed as an argument to the CREATE PROFILE statement. Oracle Database provides a default script, but you can create your own routine or use third-party software instead.
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-000016
- Version
- O112-C2-002000
- Vuln IDs
-
- V-52353
- Rule IDs
-
- SV-66569r1_rule
Checks: C-54393r1_chk
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. Check DBMS settings, OS settings, and/or enterprise-level authentication/access mechanisms settings to determine if the site utilizes a mechanism whereby temporary or emergency accounts can be terminated after an organization-defined time period. If not, this is a finding. Check the profiles to see what the password_life_time is set to in the table dba_profiles. The password_life_time is a value stored in the column named resource_name. Set password life time to expire after the required amount of time. SQL>select profile, resource_name, resource_type, limit from dba_profiles where upper(resource_name) like 'PASSWORD_LIFE_TIME'; Make sure that the user in question is assigned to a profile with the PASSWORD_LIFE_TIME set to the amount of time the user is expected to be using the password.
Fix: F-57171r1_fix
If all user accounts are authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. If using database mechanisms to satisfy this requirement, use a profile with a distinctive name (for example, TEMPORARY_USERS), so that temporary users can be easily identified. Whenever a temporary user account is created, assign it to this profile. Create a job to lock accounts under this profile that are more than n days old, where n is the organization-defined time period.
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-000017
- Version
- O112-C2-002100
- Vuln IDs
-
- V-52355
- Rule IDs
-
- SV-66571r1_rule
Checks: C-54395r1_chk
If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For accounts managed by Oracle, check DBMS settings to determine if accounts can be automatically disabled by the system after 35 days of inactivity. Also, ask the DBA if an alternative method, such as a stored procedure run daily, to disable Oracle-managed accounts inactive for more than 35 days, has been deployed. If the ability to disable accounts after 35 days of inactivity, by either of these means, does not exist, this is a finding. - - - - - Check to see what profile a user is associated with, if any, with this query: SQL> select username, profile from dba_users where username = '&Enter_Username'; Then check the profile to see what the password_life_time is set to in the table dba_profiles; The password_life_time is a value stored in the column named resource_name. SQL>select profile, resource_name, resource_type, limit from dba_profiles where upper(resource_name) = 'PASSWORD_LIFE_TIME'; - - - - - The following are notes on a method suggested by Oracle. In SRG-APP-000075-DB-000029 - The DBMS must, upon successful login, display to the user the date and time of the user's last login advocated using a custom trigger for this event. One could query the audit table and get similar results, but that is a much busier table with a lot more data. In SRG-APP-000075-DB-000029, we advocated to use a new table called sys.login_audit_info_all and trap login information with a login trigger. Check for the existence of the sys.login_audit_info_all and count the number of rows to ensure that the table is being used. Obviously, the table will have maintenance performed on it to shrink the contents, so the number of rows may vary. If the table itself exists, it is a good indication it is being used. Connect to the database, check for the existence of the table, and count the rows, as this will help us understand if the fix for SRG-APP-000075-DB-000029 was implemented and will help us remediate this issue. $ sqlplus connect as sysdba SQL> select count(*) from SYS.LOGIN_AUDIT_INFO_ALL; If the count is greater than zero, then the table exists and data is being inserted.
Fix: F-57173r1_fix
If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. For accounts managed by Oracle, determine if it is practical and acceptable to require a password change every 35 days or fewer, rather than the standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue the statement: ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35; (See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for examples.) If password changes every 35 days or fewer are unacceptable or impractical, implement an alternative method, such as a stored procedure run daily, to disable accounts inactive for more than 35 days. - - - - - The following are notes on a method suggested by Oracle. Check either the login_audit_info_all or the dba_audit_session to see what users have not logged in for the site-defined number of days. If the login_audit_info_all exists, execute the following query to get a report of the users who have exceeded the site-specific guidelines and lock those accounts. Generate a report to see what users have not logged in in the last 30 days or whatever the site-specified expiration days requirement is. sqlplus connect as sysdba - If sys.login_audit_info_all exists and contains rows, use the following query to see if there are any users who have not logged in for a period of time that is defined as the amount of time required to generate a locked account. SQL>set linesize 121 SQL>col user_id format a30 SQL>col logoff_day format a20 Sal>select user_id, logoff_day from sys.login_audit_info_all where sysdate - logoff_day > &site_specified_expiration_days; sqlplus connect as sysdba - If sys.login_audit_info_all does not exist or contains no rows, use the following query to see if there are any users who have not logged in for a period of time that is defined as the amount of time required to generate a locked account. SQL>set linesize 121 SQL>col username format a30 SQL>col timestamp format a20 SQL> select username, timestamp from dba_audit_session where action_name = 'login' and sysdate - timestamp > &site_specified_expiration_days; Take the user returned from this report and expire the account. SQL> alter user &username account lock;
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-000018
- Version
- O112-C2-002200
- Vuln IDs
-
- V-52357
- Rule IDs
-
- SV-66573r1_rule
Checks: C-54397r1_chk
Check DBMS settings, OS settings, and/or enterprise-level authentication/access mechanisms settings to determine if account creation is being audited. If account creation is not being audited, this is a finding. To check Oracle's audit trail settings, use the following command: SQL> show parameter audit_trail NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_trail string DB,EXTENDED If VALUE does NOT contain 'DB,EXTENDED' or 'DB_EXTENDED', this is a finding.
Fix: F-57175r4_fix
Configure DBMS, OS, and/or enterprise-level authentication/access mechanisms to audit account creation activities. If the audit_trail is not set, use the following command to set it. SQL> alter system set audit_trail='DB','EXTENDED' scope=spfile; System altered. SQL> shutdown immediate The ORACLE instance shuts down and when the system is restarted the change will be in effect. SQL> startup ORACLE instance started. [...additional startup messages...] Database mounted. Database opened. SQL> grant dba to adam identified by adam; Grant succeeded. SQL> connect adam/adam Connected. SQL> AUDIT CREATE USER BY ACCESS; System altered. SQL> CREATE USER TEST identified by TEST; SQL> select username,sql_text from dba_audit_trail where sql_text like '%CREATE USER%'; USERNAME SQL_TEXT ---------- ---------------------------------------------------------------------- ADAM CREATE USER TEST identified by TEST NOTE: the use of command options displaying passwords in plain text is for the sake of example only. In actual use, passwords MUST NOT be displayed, stored or transmitted in plain text.
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-001403
- Version
- O112-C2-002300
- Vuln IDs
-
- V-52359
- Rule IDs
-
- SV-66575r1_rule
Checks: C-54399r1_chk
Check DBMS settings, OS settings, and/or enterprise-level authentication/access mechanisms settings to determine if account modification is being audited. If account modification is not being audited, this is a finding. To check Oracle's audit trail settings, use the following command: SQL> show parameter audit_trail NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_trail string DB,EXTENDED If VALUE does NOT contain 'DB,EXTENDED' or 'DB_EXTENDED', this is a finding.
Fix: F-57177r4_fix
Configure DBMS, OS, and/or enterprise-level authentication/access mechanisms to audit account modification activities. If the audit_trail is not set, use the following command to set it. SQL> alter system set audit_trail='DB','EXTENDED' scope=spfile; System altered. SQL> shutdown immediate The ORACLE instance shuts down and when the system is restarted the change will be in effect. SQL> startup ORACLE instance started. [...additional startup messages...] Database mounted. Database opened. SQL> grant dba to adam identified by adam; Grant succeeded. SQL> connect adam/adam Connected. SQL> AUDIT CREATE USER BY ACCESS; System altered. SQL> CREATE USER TEST identified by TEST; SQL> ALTER USER TEST ACCOUNT LOCK; SQL> select username,sql_text from dba_audit_trail where sql_text like '%CREATE USER%' or sql_text like '%ALTER USER%'; USERNAME SQL_TEXT ---------- ---------------------------------------------------------------------- ADAM CREATE USER TEST identified by TEST ADAM ALTER USER TEST ACCOUNT LOCK NOTE: the use of command options displaying passwords in plain text is for the sake of example only. In actual use, passwords MUST NOT be displayed, stored or transmitted in plain text.
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-001404
- Version
- O112-C2-002400
- Vuln IDs
-
- V-52361
- Rule IDs
-
- SV-66577r1_rule
Checks: C-54401r1_chk
Check DBMS settings, OS settings, and/or enterprise-level authentication/access mechanisms settings to determine if database account disabling actions are being audited. If database account disabling actions are not being audited, this is a finding. To check Oracle's audit trail settings, use the following command: SQL> show parameter audit_trail NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_trail string DB,EXTENDED If VALUE does NOT contain 'DB,EXTENDED' or 'DB_EXTENDED', this is a finding.
Fix: F-57179r3_fix
Configure DBMS, OS, and/or enterprise-level authentication/access mechanisms to audit database account disabling activities. If the audit_trail is not set, use the following command to set it. SQL> alter system set audit_trail='DB','EXTENDED' scope=spfile; System altered. SQL> shutdown immediate The ORACLE instance shuts down and when the system is restarted the change will be in effect. SQL> startup ORACLE instance started. [...additional startup messages...] Database mounted. Database opened. SQL> grant dba to adam identified by adam; Grant succeeded. SQL> connect adam/adam Connected. SQL> AUDIT CREATE USER BY ACCESS; System altered. SQL> CREATE USER TEST identified by TEST; SQL> ALTER USER TEST ACCOUNT LOCK; SQL> select username,sql_text from dba_audit_trail where sql_text like '%CREATE USER%' or sql_text like '%ALTER USER%'; USERNAME SQL_TEXT ---------- ---------------------------------------------------------------------- ADAM CREATE USER TEST identified by TEST ADAM ALTER USER TEST ACCOUNT LOCK NOTE: the use of command options displaying passwords in plain text is for the sake of example only. In actual use, passwords MUST NOT be displayed, stored or transmitted in plain text.
- RMF Control
- AC-2
- Severity
- M
- CCI
- CCI-001405
- Version
- O112-C2-002500
- Vuln IDs
-
- V-52363
- Rule IDs
-
- SV-66579r1_rule
Checks: C-54403r1_chk
Check DBMS settings, OS settings, and/or enterprise-level authentication/access mechanisms settings to determine if database account termination actions are being audited. If database account termination actions are not being audited, this is a finding. To check Oracle's audit trail settings, use the following command: SQL> show parameter audit_trail NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ audit_trail string DB,EXTENDED If VALUE does NOT contain 'DB,EXTENDED' or 'DB_EXTENDED', this is a finding.
Fix: F-57181r3_fix
Configure DBMS, OS, and/or enterprise-level authentication/access mechanisms to audit database account termination activities. If the audit_trail is not set, use the following command to set it. SQL> alter system set audit_trail='DB','EXTENDED' scope=spfile; System altered. SQL> shutdown immediate The ORACLE instance shuts down and when the system is restarted the change will be in effect. SQL> startup ORACLE instance started. [...additional startup messages...] Database mounted. Database opened. SQL> grant dba to adam identified by adam; Grant succeeded. SQL> connect adam/adam Connected. SQL> AUDIT CREATE USER BY ACCESS; System altered. SQL> CREATE USER TEST identified by TEST; SQL> ALTER USER TEST ACCOUNT LOCK; SQL> select username,sql_text from dba_audit_trail where sql_text like '%CREATE USER%' or sql_text like '%ALTER USER%' or sql_text like '%DROP USER%'; USERNAME SQL_TEXT ---------- ---------------------------------------------------------------------- ADAM CREATE USER TEST identified by TEST ADAM ALTER USER TEST ACCOUNT LOCK ADAM DROP USER TEST NOTE: the use of command options displaying passwords in plain text is for the sake of example only. In actual use, passwords MUST NOT be displayed, stored or transmitted in plain text.
- RMF Control
- AC-3
- Severity
- M
- CCI
- CCI-000213
- Version
- O112-C2-002700
- Vuln IDs
-
- V-52365
- Rule IDs
-
- SV-66581r1_rule
Checks: C-54405r1_chk
Check DBMS settings to determine whether users are restricted from accessing objects and data they are not authorized to access. If appropriate access controls are not implemented to restrict access to authorized users and to restrict the access of those users to objects and data they are authorized to see, this is a finding. The easiest way to isolate access is by using the Oracle Database Vault. To check to see if the Oracle Database Vault is installed issue the following query: SQL> SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault'; If Oracle Database Vault is installed, review its settings for appropriateness and completeness of the access it permits and denies to each type of user. If appropriate and complete, this is not a finding. If Oracle Database Vault is not installed, review the roles and profiles in the database and the assignment of users to these, for appropriateness and completeness of the access permitted and denied each type of user. If appropriate and complete, this is not a finding. If the access permitted and denied each type of user is inappropriate or incomplete, this is a finding. Following are code examples for reviewing roles, profiles, etc. Find out what role the users have: select * from dba_role_privs where granted_role = '@role' List all roles given to a user: select * from dba_role_privs where grantee = '@username'; Use the following query to list all privileges given to a user: select lpad(' ', 2*level) || granted_role "User roles and privileges" from ( /* THE USERS */ select null grantee, username granted_role from dba_users where username like upper('&enter_username') /* THE ROLES TO ROLES RELATIONS */ union select grantee, granted_role from dba_role_privs /* THE ROLES TO PRIVILEGE RELATIONS */ union select grantee, privilege from dba_sys_privs ) start with grantee is null connect by grantee = prior granted_role; List which tables a certain role gives SELECT access to using the query: select * from role_tab_privs where role='@role' and privilege = 'SELECT'; List all tables a user can SELECT from using the query: select * from dba_tab_privs where GRANTEE ='@username' and privilege = 'SELECT'; List all users who can SELECT on a particular table (either through being given a relevant role or through a direct grant - e.g., grant select on a table to Joe). The result of this query should also show through which role the user has this access or whether it was a direct grant. select Grantee,'Granted Through Role' as Grant_Type, role, table_name from role_tab_privs rtp, dba_role_privs drp where rtp.role = drp.granted_role and table_name = '@TABLENAME' union select Grantee, 'Direct Grant' as Grant_type, null as role, table_name from dba_tab_privs where table_name = '@TABLENAME' ;
Fix: F-57183r1_fix
If Oracle Database Vault is in use, use it to configure the correct access privileges for each type of user. If Oracle Database Vault is not in use, configure the correct access privileges for each type of user using Roles and Profiles.
- RMF Control
- AC-3
- Severity
- M
- CCI
- CCI-001362
- Version
- O112-C2-003000
- Vuln IDs
-
- V-52367
- Rule IDs
-
- SV-66583r1_rule
Checks: C-54407r1_chk
Check DBMS settings to determine if users are able to assign and revoke rights to the objects and information that they own. If users cannot assign or revoke rights to the objects and information that they own to groups, roles, or individual users, this is a finding.
Fix: F-57185r1_fix
Modify DBMS settings to allow users to assign or revoke access rights to objects and information owned by the user. The ability to grant or revoke rights must include the ability to grant or revoke those rights down to the granularity of a single user. (Note: in most cases no fix will be necessary. This is default functionality for Oracle.)
- RMF Control
- AC-5
- Severity
- M
- CCI
- CCI-000037
- Version
- O112-C2-003400
- Vuln IDs
-
- V-52369
- Rule IDs
-
- SV-66585r1_rule
Checks: C-54409r1_chk
Check OS settings to determine whether DBMS processes are running under a dedicated OS account. If the DBMS processes are running under shared accounts, this is a finding. This is done by the default installation. The installation documentation recommends that a user account named ORACLE is created and is identified as the software owner. If you log into the system as the software owner, typically ORACLE, the $ORACLE_HOME environment variable will point to the Oracle software. If you enter the following commands you can see if ORACLE is the software owner: $ cd $ORACLE_HOME $ ls -l (shows the directories - oracle is the owner and oinstall is the group) $drwxr-xr-x. 8 oracle oinstall 4096 Aug 9 08:08 apex drwxr-xr-x. 8 oracle oinstall 4096 Aug 9 08:05 assistants drwxr-xr-x. 2 oracle oinstall 12288 Aug 12 09:48 bin drwxr-xr-x. 7 oracle oinstall 4096 Aug 9 08:09 ccr drwxr-xr-x. 3 oracle oinstall 4096 Aug 9 08:09 cdata drwx------. 4 oracle oinstall 4096 Aug 9 08:37 cfgtoollogs drwxr-xr-x. 4 oracle oinstall 4096 Aug 9 08:08 clone drwxr-xr-x. 2 oracle oinstall 4096 Aug 9 08:09 config drwxr-xr-x. 6 oracle oinstall 4096 Aug 9 08:05 crs drwxr-xr-x. 3 oracle oinstall 4096 Aug 9 08:05 csmig drwxr-xr-x. 6 oracle oinstall 4096 Aug 9 08:09 css drwxr-xr-x. 10 oracle oinstall 4096 Aug 9 08:09 ctx drwxr-xr-x. 7 oracle oinstall 4096 Aug 9 08:05 cv drwxr-xr-x. 2 oracle oinstall 4096 Aug 17 23:33 dbs drwxr-xr-x. 2 oracle oinstall 4096 Aug 9 08:08 dc_ocm drwxr-xr-x. 4 oracle oinstall 4096 Aug 9 08:11 deinstall drwxr-xr-x. 3 oracle oinstall 4096 Aug 9 08:05 demo $ ps -ef | grep ora_ (shows all of the oracle processes owned by the oracle user) oracle 7914 1 0 01:02 ? 00:00:13 ora_pmon_mype02 oracle 7916 1 0 01:02 ? 00:00:11 ora_psp0_mype02 oracle 7918 1 0 01:02 ? 00:00:09 ora_vktm_mype02 oracle 7922 1 0 01:02 ? 00:00:02 ora_gen0_mype02 oracle 7924 1 0 01:02 ? 00:00:02 ora_diag_mype02 oracle 7926 1 0 01:02 ? 00:00:02 ora_dbrm_mype02 oracle 7928 1 0 01:02 ? 00:00:40 ora_dia0_mype02 oracle 7930 1 0 01:02 ? 00:00:03 ora_mman_mype02 oracle 7932 1 0 01:02 ? 00:00:09 ora_dbw0_mype02 oracle 7934 1 0 01:02 ? 00:00:11 ora_lgwr_mype02 oracle 7936 1 0 01:02 ? 00:00:17 ora_ckpt_mype02 oracle 7938 1 0 01:02 ? 00:00:08 ora_smon_mype02 oracle 7940 1 0 01:02 ? 00:00:00 ora_reco_mype02 oracle 7942 1 0 01:02 ? 00:00:25 ora_mmon_mype02 oracle 7944 1 0 01:02 ? 00:00:41 ora_mmnl_mype02 oracle 7946 1 0 01:02 ? 00:00:00 ora_d000_mype02 oracle 7948 1 0 01:02 ? 00:00:00 ora_s000_mype02 oracle 7992 1 0 01:02 ? 00:00:00 ora_qmnc_mype02 oracle 8029 1 0 01:02 ? 00:00:16 ora_cjq0_mype02 oracle 8030 2611 0 09:37 pts/3 00:00:00 bash oracle 8090 1 0 01:02 ? 00:00:00 ora_q000_mype02 oracle 8092 1 0 01:02 ? 00:00:00 ora_q001_mype02 oracle 8098 1 0 01:02 ? 00:00:02 ora_smco_mype02
Fix: F-57187r1_fix
Create an OS account dedicated to Oracle DBMS processes and allow only Oracle DBMS processes to run under the account.
- RMF Control
- AC-5
- Severity
- M
- CCI
- CCI-000037
- Version
- O112-C2-003500
- Vuln IDs
-
- V-52371
- Rule IDs
-
- SV-66587r1_rule
Checks: C-54411r1_chk
Obtain a list of privileges assigned to user accounts. If access to sensitive information is granted to roles not authorized to access sensitive information, this is a finding. If access to sensitive information is granted to individual accounts rather than to a role, this is a finding.
Fix: F-57189r1_fix
Define application user roles based on privilege and job function requirements. Assign the required privileges to the role and assign the role to authorized application user accounts. Revoke any privileges to sensitive information directly assigned to application user accounts.
- RMF Control
- AC-5
- Severity
- M
- CCI
- CCI-000037
- Version
- O112-C2-003600
- Vuln IDs
-
- V-52373
- Rule IDs
-
- SV-66589r1_rule
Checks: C-54413r1_chk
Review procedures for providing database connection information to users/user workstations. If procedures do not indicate or implement restrictions to connections required by the particular user, this is a finding. Note: This check is specific for the DBMS host system and not directed at client systems (client systems are included in the Application STIG/Checklist); however, detection of unauthorized client connections to the DBMS host system obtained through log files should be performed regularly and documented where authorized.
Fix: F-57191r1_fix
Implement procedures to supply database connection information to only those databases authorized for the user.
- RMF Control
- AC-5
- Severity
- M
- CCI
- CCI-000037
- Version
- O112-C2-003700
- Vuln IDs
-
- V-52375
- Rule IDs
-
- SV-66591r1_rule
Checks: C-54415r1_chk
Check the production system to ensure no developer accounts have rights to modify the production database structure or alter production data. If developer accounts with these rights exist, ask for documentation that shows these accounts have formal approval and risk acceptance. If this documentation does not exist, this is a finding. If developer accounts exist with the right to create and maintain tables (or other database objects) in production tablespaces, this is a finding.
Fix: F-57193r1_fix
Restrict developer privileges to production objects to only objects and data where those privileges are required and authorized. Document the approval and risk acceptance. Consider using separate accounts for a person's developer duties and production duties. At a minimum, use separate roles for developer privileges and production privileges. If developers need the ability to create and maintain tables (or other database objects) as part of their development activities, provide dedicated tablespaces, and revoke any rights that allowed them to use production tablespaces for this purpose.
- RMF Control
- AC-5
- Severity
- M
- CCI
- CCI-000037
- Version
- O112-C2-003800
- Vuln IDs
-
- V-52377
- Rule IDs
-
- SV-66593r1_rule
Checks: C-54417r1_chk
Identify whether any hosts contain both development and production databases. If no hosts contain both production and development databases, this is NA. For any host containing both a development and a production database, determine if developers have been granted elevated privileges on the production database or on the OS. If they have, ask for documentation that shows these accounts have formal approval and risk acceptance. If this documentation does not exist, this is a finding. If developer accounts exist with the right to create and maintain tables (or other database objects) in production tablespaces, this is a finding. (Where applicable, to check the number of instances on the host machine, check the /etc/oratab. The /etc/oratab file is updated by the Oracle Installer when the database is installed when the root.sh file is executed. Each line in the represents an ORACLE_SID:ORACLE_HOME:Y or N. The ORACLE_SID and ORACLE_HOME are self-explanatory. The Y or N signals the DBSTART program to automatically start or not start that specific instance when the machine is restarted. Check with the system owner and application development team to see what each entry represents. If a system is deemed to be a production system review the system for development users.)
Fix: F-57195r1_fix
Restrict developer privileges to production objects to only objects and data where those privileges are required and authorized. Document the approval and risk acceptance. Consider using separate accounts for a person's developer duties and production duties. At a minimum, use separate roles for developer privileges and production privileges. If developers need the ability to create and maintain tables (or other database objects) as part of their development activities, provide dedicated tablespaces, and revoke any rights that allowed them to use production tablespaces for this purpose.
- RMF Control
- AC-5
- Severity
- M
- CCI
- CCI-000037
- Version
- O112-C2-003900
- Vuln IDs
-
- V-52379
- Rule IDs
-
- SV-66595r1_rule
Checks: C-54419r1_chk
Review user privileges to system tables and configuration data stored in the database. If non-DBA users are assigned privileges to access system tables and tables containing configuration data, this is a finding. This is default behavior for Oracle. Users other than the SYSDBA, SYS and SYSTEM must be granted access even to connect to the system. By default, any other user will only have access to the objects they own. To test this, do the following: Login in as sysdba $sqlplus connect as sysdba SQL> CREATE USER USER1 2 IDENTIFIED BY WELCOME#1 3 DEFAULT TABLESPACE USERS 4 TEMPORARY TABLESPACE TEMP 5 QUOTA 100K ON TEMP SQL>/ SQL> GRANT CONNECT TO USER1; SQL> COMMIT; SQL> DESC SYS.DBA_USERS; NAME NULL? TYPE ------------------------ ---------- --------- USERNAME NOT NULL VARCHAR2(30) USER_ID NOT NULL NUMBER PASSWORD VARCHAR2(30) ACCOUNT_STATUS NOT NULL VARCHAR2(32) LOCK_DATE DATE EXPIRY_DATE DATE DEFAULT_TABLESPACE NOT NULL VARCHAR2(30) TEMPORARY_TABLESPACE NOT NULL VARCHAR2(30) CREATED NOT NULL DATE PROFILE NOT NULL VARCHAR2(30) INITIAL_RSRC_CONSUMER_GROUP VARCHAR2(30) EXTERNAL_NAME VARCHAR2(4000) PASSWORD_VERSIONS VARCHAR2(8) EDITIONS_ENABLED VARCHAR2(1) AUTHENTICATION_TYPE VARCHAR2(8) SQL> CONNECT USER1 SQL> DESC SYS.DBA_USERS; ERROR: ORA-04043: object sys.dba_objects foes not exist SQL> SELECT COUNT(*) FROM SYS.DBA_USERS; ERROR: ORA-04043: object sys.dba_objects does not exist
Fix: F-57199r1_fix
Restrict DBMS system tables and other configuration information or metadata to DBAs or other authorized users. This is the default behavior of the database. If a user needs access to an object, it must be specifically granted. In the example below, use the user created in the check and grant select to the sys.dba_users table and then try the same process of describing and counting the number of rows in the sys.dba_users table. Once the select privilege is granted, the user USER1 can describe and select from the table. sqlplus connect as sysdba SQL>grant select on sys.dba_users to USER1; SQL>commit; SQL>connect USER1; SQL> DESC SYS.DBA_USERS; NAME NULL? TYPE ------------------------ ---------- --------- USERNAME NOT NULL VARCHAR2(30) USER_ID NOT NULL NUMBER PASSWORD VARCHAR2(30) ACCOUNT_STATUS NOT NULL VARCHAR2(32) LOCK_DATE DATE EXPIRY_DATE DATE DEFAULT_TABLESPACE NOT NULL VARCHAR2(30) TEMPORARY_TABLESPACE NOT NULL VARCHAR2(30) CREATED NOT NULL DATE PROFILE NOT NULL VARCHAR2(30) INITIAL_RSRC_CONSUMER_GROUP VARCHAR2(30) EXTERNAL_NAME VARCHAR2(4000) PASSWORD_VERSIONS VARCHAR2(8) EDITIONS_ENABLED VARCHAR2(1) AUTHENTICATION_TYPE VARCHAR2(8) SQL> SELECT COUNT(*) FROM SYS.DBA_USERS; COUNT(*) -------- 40
- RMF Control
- AC-5
- Severity
- M
- CCI
- CCI-000037
- Version
- O112-C2-004000
- Vuln IDs
-
- V-52383
- Rule IDs
-
- SV-66599r1_rule
Checks: C-54421r1_chk
Review administrative accounts for direct privilege assignment. If any administrative privileges have been assigned directly to a database account, this is a finding.
Fix: F-57203r1_fix
Create roles for administrative function assignments. Assign the necessary privileges for the administrative functions to a role.
- RMF Control
- AC-6
- Severity
- M
- CCI
- CCI-000040
- Version
- O112-C2-004100
- Vuln IDs
-
- V-52387
- Rule IDs
-
- SV-66603r1_rule
Checks: C-54423r1_chk
Review permissions for objects owned by DBA or other administrative accounts. If any objects owned by administrative accounts can be accessed by non-DBA/non-administrative users, either directly or indirectly, this is a finding. Verify DBAs have separate administrative accounts. If DBAs do not have a separate account for database administration purposes, this is a finding.
Fix: F-57205r1_fix
Revoke DBA privileges, and privileges to administer DBA-owned objects, from non-DBA accounts. Provide separate accounts to DBA for database administration.
- RMF Control
- AC-6
- Severity
- M
- CCI
- CCI-000040
- Version
- O112-C2-004200
- Vuln IDs
-
- V-52389
- Rule IDs
-
- SV-66605r1_rule
Checks: C-54425r1_chk
Review access logs for objects owned by application owners or other non-administrative users. If any objects owned by an application owner have been accessed by DBA/administrative users, either directly or indirectly, this is a finding.
Fix: F-57211r1_fix
Require that DBAs and other administrative users perform non-administrative functions using non-administrative accounts.
- RMF Control
- AC-6
- Severity
- M
- CCI
- CCI-000040
- Version
- O112-C2-004300
- Vuln IDs
-
- V-52393
- Rule IDs
-
- SV-66609r1_rule
Checks: C-54427r1_chk
Review access permissions for objects owned by application owners or other non-administrative users. If DBA or administrative accounts have unauthorized application roles or permissions beyond those needed for administration, this is a finding.
Fix: F-57213r1_fix
Remove permissions from DBAs and other administrative users beyond those required for administrative functions.
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- O112-N1-015601
- Vuln IDs
-
- V-52395
- Rule IDs
-
- SV-66611r1_rule
Checks: C-54429r1_chk
Interview the DBA to determine if any applications that access the database allow for entry of the account name and password on the command line. If any do, determine whether these applications obfuscate authentication data. If they do not, this is a finding.
Fix: F-57215r1_fix
Configure or modify applications to prohibit display of passwords in clear text on the command line.
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- O112-N1-015602
- Vuln IDs
-
- V-52397
- Rule IDs
-
- SV-66613r1_rule
Checks: C-54431r1_chk
For Oracle SQL Plus, which cannot be configured not to accept a plain-text password, and any other essential tool with the same limitation, verify that the system documentation explains the need for the tool, who uses it, and any relevant mitigations; and that AO approval has been obtained. If not, this is a finding. Request evidence that all users of the tool are trained in the importance of not using the plain-text password option, and in how to keep the password hidden; and that they adhere to this practice. If not, this is a finding.
Fix: F-57219r1_fix
For Oracle SQL Plus, which cannot be configured not to accept a plain-text password, and any other essential tool with the same limitation: 1) Document the need for it, who uses it, and any relevant mitigations, and obtain AO approval. 2) Train all users of the tool in the importance of not using the plain-text password option, and in how to keep the password hidden. - - - - - Consider wrapping the startup command with a shell or wrapper and using an Oracle external password store. Oracle provides the capability to provide for a secure external password facility. Use the Oracle mkstore to create a secure storage area for passwords for applications, batch jobs and scripts to use or deploy a site-authorized facility to perform this function. Check to see what has been stored in the Oracle3 External Password Store. To view all contents of a client wallet external password store, check specific credentials by viewing them. Listing the external password store contents provides information you can use to decide whether to add or delete credentials from the store. To list the contents of the external password store, enter the following command at the command line: $ mkstore -wrl wallet_location -listCredential For example: $ mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -listCredential The wallet_location specifies the path to the directory where the wallet, whose external password store contents you want to view, is located. This command lists all of the credential database service names (aliases) and the corresponding user name (schema) for that database. Passwords are not listed. Configuring Clients to Use the External Password Store If your client is already configured to use external authentication, such as Windows native authentication or Secure Sockets Layer (SSL), then Oracle Database uses that authentication method. The same credentials used for this type of authentication are typically also used to log in to the database. For clients not using such authentication methods or wanting to override them for database authentication, you can set the SQLNET.WALLET_OVERRIDE parameter in sqlnet.ora to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE, allowing standard use of authentication credentials as before. If you want a client to use the secure external password store feature, then perform the following configuration task: 1. Create a wallet on the client by using the following syntax at the command line: mkstore -wrl wallet_location -create For example: mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -create Enter password: password The wallet_location is the path to the directory where you want to create and store the wallet. This command creates an Oracle wallet with the autologin feature enabled at the location you specify. The autologin feature enables the client to access the wallet contents without supplying a password. The mkstore utility -create option uses password complexity verification. 2. Create database connection credentials in the wallet by using the following syntax at the command line: mkstore -wrl wallet_location -createCredential db_connect_string username Enter password: password For example: mkstore -wrl c:\oracle\product\11.2.0\db_1\wallets -createCredential oracle system Enter password: password In this specification: The wallet_location is the path to the directory where you created the wallet. The db_connect_string used in the CONNECT /@db_connect_string statement must be identical to the db_connect_string specified in the -createCredential command. The db_connect_string is the TNS alias you use to specify the database in the tnsnames.ora file or any service name you use to identify the database on an Oracle network. By default, tnsnames.ora is located in the $ORACLE_HOME/network/admin directory on UNIX systems and in ORACLE_HOME\network\admin on Windows. The username is the database login credential. When prompted, enter the password for this user. 3. In the client sqlnet.ora file, enter the WALLET_LOCATION parameter and set it to the directory location of the wallet you created in Step 1. For example, if you created the wallet in $ORACLE_HOME/network/admin and your Oracle home is set to /private/ora11, then you need to enter the following into your client sqlnet.ora file: WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /private/ora11/network/admin) ) ) 4. In the client sqlnet.ora file, enter the SQLNET.WALLET_OVERRIDE parameter and set it to TRUE as follows: SQLNET.WALLET_OVERRIDE = TRUE This setting causes all CONNECT /@db_connect_string statements to use the information in the wallet at the specified location to authenticate to databases. When external authentication is in use, an authenticated user with such a wallet can use the CONNECT /@db_connect_string syntax to access the previously specified databases without providing a user name and password. However, if a user fails that external authentication, then these connect statements also fail. If an application uses SSL for encryption, then the sqlnet.ora parameter, SQLNET.AUTHENTICATION_SERVICES, specifies SSL and an SSL wallet is created. If this application wants to use secret store credentials to authenticate to databases (instead of the SSL certificate), then those credentials must be stored in the SSL wallet. After SSL authentication, if SQLNET.WALLET_OVERRIDE = TRUE, then the user names and passwords from the wallet are used to authenticate to databases. If SQLNET.WALLET_OVERRIDE = FALSE, then the SSL certificate is used. Below is a sample sqlnet.ora file with the WALLET_LOCATION and the SQLNET.WALLET_OVERRIDE parameters set as described in Steps 3 and 4. Below is a sample SQLNET.ORA File with Wallet Parameters Set WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /private/ora11/network/admin) ) ) SQLNET.WALLET_OVERRIDE = TRUE SSL_CLIENT_AUTHENTICATION = FALSE SSL_VERSION = 0
- RMF Control
- AC-6
- Severity
- M
- CCI
- CCI-000040
- Version
- O112-C2-004400
- Vuln IDs
-
- V-52399
- Rule IDs
-
- SV-66615r1_rule
Checks: C-54433r1_chk
Determine which OS accounts are used by the DBMS to run external procedures. Validate that these OS accounts have only the privileges necessary to perform the required functionality. If any OS accounts, utilized by the database for running external procedures, have privileges beyond those required for running the external procedures, this is a finding.
Fix: F-57221r1_fix
Limit privileges to DBMS-related OS accounts to those required to perform their DBMS specific functionality.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-N2-004701
- Vuln IDs
-
- V-52405
- Rule IDs
-
- SV-66621r1_rule
Checks: C-54435r1_chk
Review the use of the essential system accounts with the DBA(s). Request evidence that administrators have individual administrative accounts, and that they use these rather than SYS, SYSTEM, SYSMAN, etc., in carrying out their duties. If the evidence indicates otherwise, this is a finding. Review the status of the essential system accounts, in the view DBA_USERS. If any of these accounts is not locked, this is a finding.
Fix: F-57223r1_fix
Ensure that all individuals with DBA responsibilities always log in under their individual administrative accounts. Ensure that the passwords for essential system accounts such as SYS are available only to authorized administrators, and tightly guarded to avoid misuse. Ensure that these accounts are kept locked except when it is specifically necessary to use them.
- RMF Control
- AC-7
- Severity
- M
- CCI
- CCI-000044
- Version
- O112-C2-004900
- Vuln IDs
-
- V-52407
- Rule IDs
-
- SV-66623r1_rule
Checks: C-54437r1_chk
The account lockout duration is defined in the profile assigned to a user. To see what profile is assigned to a user, enter the query: SQL>SELECT profile FROM dba_users WHERE username = '&USERNAME' This will return the profile name assigned to that user. Now check the values assigned to the profile returned from the query above: SQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE LIKE '&PROFILE_NAME' Check the settings for password_lock_time - this specifies how long to lock the account after the number of consecutive failed login attempts reaches the limit. If the value is not UNLIMITED, this is a finding.
Fix: F-57225r1_fix
Configure the DBMS settings to specify indefinite lockout duration: ALTER PROFILE '&PROFILE_NAME' LIMIT PASSWORD_LOCK_TIME UNLIMITED;
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-N2-008601
- Vuln IDs
-
- V-52409
- Rule IDs
-
- SV-66625r1_rule
Checks: C-54439r1_chk
Interview the database administrator: review the procedures, manual and/or automated, for monitoring the space used by audit trail(s), and for offloading audit records to a centralized log management system. If the procedures do not exist, this is a finding. If the procedures exist, request evidence that they are followed. If the evidence indicates that the procedures are not followed, this is a finding. If the procedures exist, inquire if the system has ever run out of audit trail space in the last two years or since the last system upgrade, whichever is more recent. If it has run out of space in this period, and the procedures have not been updated to compensate, this is a finding.
Fix: F-57227r1_fix
Institute procedures, manual and/or automated, for monitoring the space used by audit trail(s), and for offloading audit records to a centralized log management system.
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- O112-N3-005801
- Vuln IDs
-
- V-52411
- Rule IDs
-
- SV-66627r1_rule
Checks: C-54441r1_chk
Run the query: SELECT * FROM DBA_USERS WHERE PASSWORD IS NULL OR PASSWORD NOT IN ('EXTERNAL', 'GLOBAL'); If the names of any interactive accounts are returned, this is a finding.
Fix: F-57229r1_fix
Use the Oracle option of integration with enterprise-level account management (such as Active Directory or LDAP), for all accounts, including administrative accounts.
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- O112-N3-005802
- Vuln IDs
-
- V-52413
- Rule IDs
-
- SV-66629r1_rule
Checks: C-54443r1_chk
This requirement applies to interactive accounts only. Log on to each operating system where interactive Oracle users will communicate with the DBMS. If each OS displays the date and time of the user's last login, this is not a finding. Log on to each interactive application that accesses the DBMS. If each application displays the date and time of the user's last login, this is not a finding.
Fix: F-57231r1_fix
Modify OS logon behavior and/or application behavior to display the required data.
- RMF Control
- AC-6
- Severity
- M
- CCI
- CCI-000040
- Version
- O112-OS-004600
- Vuln IDs
-
- V-52425
- Rule IDs
-
- SV-66641r1_rule
Checks: C-54453r1_chk
Review system documentation to identify the installation account. Verify whether the account is used for anything beyond DBMS software installation, upgrade, and maintenance actions. If the account is used for anything beyond DBMS software installation, upgrade, and maintenance actions, this is a finding.
Fix: F-57243r1_fix
Restrict use of the DBMS software installation account to DBMS software installation, upgrade, and maintenance actions only. Disable installation accounts when authorized actions are not being performed.
- RMF Control
- CM-5
- Severity
- M
- CCI
- CCI-001499
- Version
- O112-OS-010700
- Vuln IDs
-
- V-52427
- Rule IDs
-
- SV-66643r1_rule
Checks: C-54455r1_chk
Review monitoring procedures and implementation evidence to verify that monitoring of changes to database software libraries, related applications, and configuration files is done. Verify the list of files, directories, and database application objects (procedures, functions, and triggers) being monitored is complete. If monitoring does not occur or is not complete, this is a finding.
Fix: F-57245r1_fix
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 since file dates may be manipulated by malicious users.
- RMF Control
- CM-5
- Severity
- M
- CCI
- CCI-001499
- Version
- O112-OS-011200
- Vuln IDs
-
- V-52429
- Rule IDs
-
- SV-66645r1_rule
Checks: C-54457r1_chk
Review permissions that control access to the DBMS software libraries. The software library location may be determined from vendor documentation or service/process executable paths. 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. Any others should be scrutinized and a reason for access provided by the DBA. If accounts that are not required and authorized to have access to the software library location do have access, this is a finding. Check to see which users have been granted DBA. Work from a basis of least privilege. Provide the least amount of privilege required to accomplish the job. SQL> select * from dba_role_privs where granted_role = 'DBA';
Fix: F-57247r1_fix
Restrict access to the DBMS software libraries to accounts that require access based on job function.
- RMF Control
- AC-7
- Severity
- M
- CCI
- CCI-000044
- Version
- O112-C2-005000
- Vuln IDs
-
- V-52431
- Rule IDs
-
- SV-66647r1_rule
Checks: C-54461r1_chk
The limit on the number of consecutive failed logon attempts is defined in the profile assigned to a user. To see what profile is assigned to a user, enter the following query: SQL>SELECT profile FROM dba_users WHERE username = '&USERNAME' This will return the profile name assigned to that user. Now check the values assigned to the profile returned from the query above: SQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE LIKE '&PROFILE_NAME' Check the settings for failed_login_attempts - this is the number of consecutive failed login attempts before locking the Oracle user account. If the value is greater than 3, this is a finding.
Fix: F-57251r1_fix
Configure the DBMS settings to specify the maximum number of consecutive failed login attempts to 3 (or less): ALTER PROFILE '&PROFILE_NAME' LIMIT FAILED_LOGON_ATTEMPTS 3;
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000136
- Version
- O112-P2-008100
- Vuln IDs
-
- V-52433
- Rule IDs
-
- SV-66649r1_rule
Checks: C-54459r1_chk
If the organization does not require the use of a centralized audit log repository, this is not a finding. If the organization requires the use of a centralized audit log repository, continue. Check that Oracle PL/SQL code or other software is in place to copy or transfer the specified audit record content to a centralized audit log repository. If it is not, this is a finding. Check that permissions are set on the Oracle audit trail tables and on the target repository, to enable the required transfer of audit data. If they are not, this is a finding. Verify that the specified audit record content is indeed copied or transferred to the central repository. If it is not, this is a finding.
Fix: F-57249r1_fix
If the organization requires the use of a centralized audit log repository, employ PL/SQL code or other software to copy or transfer the specified audit record content to the repository. Ensure that permissions are set to enable transfer of the data. If, after the preceding steps, the transfer is not succeeding, diagnose and repair the problem. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm
- RMF Control
- AC-7
- Severity
- M
- CCI
- CCI-000047
- Version
- O112-C2-005200
- Vuln IDs
-
- V-52435
- Rule IDs
-
- SV-66651r1_rule
Checks: C-54463r1_chk
The limit on the number of consecutive failed logon attempts is defined in the profile assigned to a user. To see what profile is assigned to a user, enter the following query: SQL>SELECT profile FROM dba_users WHERE username = '&USERNAME' This will return the profile name assigned to that user. Now check the values assigned to the profile returned from the query above: SQL>SELECT PROFILE, RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE LIKE '&PROFILE_NAME' Check the settings for failed_login_attempts - this is the number of consecutive failed login attempts before locking the Oracle user account. If the value is greater than 3, this is a finding.
Fix: F-57253r1_fix
Configure the DBMS settings to specify the maximum number of consecutive failed login attempts to 3 (or less): ALTER PROFILE '&PROFILE_NAME' LIMIT FAILED_LOGON_ATTEMPTS 3;
- RMF Control
- CM-5
- Severity
- M
- CCI
- CCI-001499
- Version
- O112-P2-010800
- Vuln IDs
-
- V-52437
- Rule IDs
-
- SV-66653r1_rule
Checks: C-54465r1_chk
Review procedures for controlling and granting access to use of the DBMS software installation account. If access or use of this account is not restricted to the minimum number of personnel required, or if unauthorized access to the account has been granted, this is a finding.
Fix: F-57255r1_fix
Develop, document, and implement procedures to restrict use of the DBMS software installation account.
- RMF Control
- AC-8
- Severity
- M
- CCI
- CCI-000050
- Version
- O112-C2-005400
- Vuln IDs
-
- V-52439
- Rule IDs
-
- SV-66655r1_rule
Checks: C-54467r1_chk
If all applications using the database (and having an interactive user interface) display a login banner with the prescribed wording, and the operating system hosting the database displays a login banner with the prescribed wording, and the banner is displayed until the user explicitly acknowledges it, this is not a finding. Otherwise, this is a finding. (See also the closely related requirement, SRG-APP-000068-DB-000027.)
Fix: F-57257r1_fix
If necessary, take the following steps: Create a text file containing the prescribed wording. Ensure the file is accessible by the database owner. Open the SQLNET.ORA file in a text editor. If the SEC_USER_UNAUTHORIZED_ACCESS_BANNER parameter is not present, create it. If the SEC_USER_AUDIT_ACTION_BANNER parameter is not present, create it. Set both parameter values equal to the complete path of the banner file. Example: SEC_USER_UNAUTHORIZED_ACCESS_BANNER=/opt/oracle/admin/data/unauthwarning.txt Configure all applications that use the database and have an interactive user interface to display the banner upon login and keep it visible until the user explicitly acknowledges it.
- RMF Control
- CM-5
- Severity
- M
- CCI
- CCI-001499
- Version
- O112-P2-010900
- Vuln IDs
-
- V-52441
- Rule IDs
-
- SV-66657r1_rule
Checks: C-54469r1_chk
Review the DBMS software library directory and note other root directories located on the same disk directory or any subdirectories. If any non-DBMS software directories exist on the disk directory, examine or investigate their use. If any of the directories are used by other applications, including third-party applications that use the DBMS, this is a finding. Only applications that are required for the functioning and administration, not use, of the DBMS should be located on the same disk directory as the DBMS software libraries. For databases located on mainframes, confirm that the database and its configuration files are isolated in their own DASD pools. If database software and database configuration files share DASD with other applications, this is a finding.
Fix: F-57259r1_fix
Install all applications on directories, or pools, separate from the DBMS software library directory. Re-locate any directories or re-install other application software that currently shares the DBMS software library directory to separate directories. For mainframe-based databases, locate database software and configuration files in separate DASD pools from other mainframe applications.
- RMF Control
- AC-8
- Severity
- M
- CCI
- CCI-001384
- Version
- O112-C2-005500
- Vuln IDs
-
- V-52443
- Rule IDs
-
- SV-66659r1_rule
Checks: C-54471r1_chk
Determine whether the system is publicly accessible. If the system is not publicly accessible, this is NA. Banner requirements are applicable only to interactive accounts. If all applications using the database (and having an interactive user interface) display a login banner with the appropriate wording, stop here: this is not a finding. (See the Discussion for what constitutes appropriate wording.) Review banner displayed by DBMS to verify it displays the system use information when appropriate, before granting further access. Review banner displayed by DBMS to verify it displays references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities. Review banner displayed by DBMS to verify it includes in the notice given to public users of the information system a description of the authorized uses of the system.
Fix: F-57261r1_fix
If necessary, take the following steps: Create a text file containing the appropriate wording. (See the Discussion for what constitutes appropriate wording.) Ensure the file is accessible by the database owner. Open the SQLNET.ORA file in a text editor. If the SEC_USER_UNAUTHORIZED_ACCESS_BANNER parameter is not present, create it. If the SEC_USER_AUDIT_ACTION_BANNER parameter is not present, create it. Set both parameter values equal to the complete path of the banner file. Example: SEC_USER_UNAUTHORIZED_ACCESS_BANNER=/opt/oracle/admin/data/unauthwarning.txt Configure all applications that use the database and have an interactive user interface to display the banner upon login.
- RMF Control
- CP-9
- Severity
- M
- CCI
- CCI-000537
- Version
- O112-P2-012700
- Vuln IDs
-
- V-52445
- Rule IDs
-
- SV-66661r1_rule
Checks: C-54473r1_chk
Review evidence of inclusion of the DBMS libraries in current backup records. If any DBMS library files are not included in regular backups, this is a finding.
Fix: F-57263r1_fix
Configure backups to include all DBMS application and third-party database application software libraries.
- RMF Control
- AU-4
- Severity
- M
- CCI
- CCI-000138
- Version
- O112-C2-005600
- Vuln IDs
-
- V-52447
- Rule IDs
-
- SV-66663r1_rule
Checks: C-54475r1_chk
Review the DBMS settings to determine whether audit logging is configured to produce logs consistent with the amount of space allocated for logging. If auditing will generate excessive logs so that they may outgrow the space reserved for logging, this is a finding. Oracle Auditing does not write to a log file. The audit logs are written to a table called AUD$, and if a Virtual Private Database is deployed, we also create a table called FGA_LOG$. First check the current location of the audit trail tables. CONN / AS SYSDBA SELECT table_name, tablespace_name FROM dba_tables WHERE table_name IN ('AUD$', 'FGA_LOG$') ORDER BY table_name; TABLE_NAME TABLESPACE_NAME ------------------------------ ------------------------------ AUD$ SYSTEM FGA_LOG$ SYSTEM If the tablespace name is SYSTEM, the table needs to be relocated to its own tablespace.
Fix: F-57265r1_fix
Ensure that the audit logging tables are in their own tablespaces, and that the tablespaces have enough room for the volume of log data that will be produced.
- RMF Control
- AU-4
- Severity
- M
- CCI
- CCI-000137
- Version
- O112-C2-005700
- Vuln IDs
-
- V-52449
- Rule IDs
-
- SV-66665r1_rule
Checks: C-54477r1_chk
Review the DBMS settings to determine whether audit logging is configured to produce logs consistent with the amount of space allocated for logging. If auditing will generate excessive logs so that they may outgrow the space reserved for logging, this is a finding. Oracle Auditing does not write to a log file. The audit logs are written to a table called AUD$, and if a Virtual Private Database is deployed, we also create a table called FGA_LOG$. First check the current location of the audit trail tables. CONN / AS SYSDBA SELECT table_name, tablespace_name FROM dba_tables WHERE table_name IN ('AUD$', 'FGA_LOG$') ORDER BY table_name; TABLE_NAME TABLESPACE_NAME ------------------------------ ------------------------------ AUD$ SYSTEM FGA_LOG$ SYSTEM If the tablespace name is SYSTEM, the table needs to be relocated to its own tablespace.
Fix: F-57267r1_fix
Ensure that the audit logging tables are in their own tablespaces, and that the tablespaces have enough room for the volume of log data that will be produced.
- RMF Control
- IA-2
- Severity
- M
- CCI
- CCI-000764
- Version
- O112-P2-012800
- Vuln IDs
-
- V-52451
- Rule IDs
-
- SV-66667r1_rule
Checks: C-54479r1_chk
Review DBMS settings, OS settings, and/or enterprise-level authentication/access mechanism settings, and site practices, to determine whether organizational users are uniquely identified and authenticated when logging onto the system. If organizational users are not uniquely identified and authenticated, this is a finding.
Fix: F-57269r1_fix
Configure DBMS, OS and/or enterprise-level authentication/access mechanism to uniquely identify and authenticate all organizational users who log onto the system. Ensure that each user has a separate account from all other users. (This is the default behavior of Oracle.)
- RMF Control
- AC-3
- Severity
- M
- CCI
- CCI-001693
- Version
- O112-C2-006600
- Vuln IDs
-
- V-52453
- Rule IDs
-
- SV-66669r1_rule
Checks: C-54481r1_chk
Verify the DBMS has the ability to grant permissions without the grantee receiving the right to grant those same permissions to another user. Review organization policies regarding access propagation. If an access propagation policy limiting the propagation of rights does not exist, this is a finding. Review DBMS configuration to verify access propagation policies are enforced by the DBMS as configured. If the DBMS does not enforce the access propagation policy, this is a finding.
Fix: F-57271r1_fix
Create and document an access propagation policy that limits the propagation of rights. Configure the DBMS to enforce the access propagation policy. When a user is granted access to an object they have access to the object. When a used is granted access to an object with the ADMIN option, then they can provide permissions to others. Without the ADMIN option, a user cannot grant access to an object. No configuration is required.
- RMF Control
- IA-8
- Severity
- M
- CCI
- CCI-000804
- Version
- O112-P2-015800
- Vuln IDs
-
- V-52455
- Rule IDs
-
- SV-66671r1_rule
Checks: C-54483r1_chk
Review DBMS settings to determine whether non-organizational users are uniquely identified and authenticated when logging onto the system. If non-organizational users are not uniquely identified and authenticated, this is a finding.
Fix: F-57273r1_fix
Configure DBMS settings to uniquely identify and authenticate all non-organizational users who log onto the system.
- RMF Control
- AC-3
- Severity
- M
- CCI
- CCI-001694
- Version
- O112-C2-006700
- Vuln IDs
-
- V-52457
- Rule IDs
-
- SV-66673r1_rule
Checks: C-54485r1_chk
Check DBMS settings and documentation to determine if users are able to assign and revoke rights to the objects and information they own. If users cannot assign or revoke rights to the objects and information they own to the granularity of a single user, this is a finding. (This is default Oracle behavior.)
Fix: F-57275r1_fix
Modify DBMS settings to allow users to assign or revoke access rights to objects and information owned by the user. The ability to grant or revoke rights must include the ability to grant or revoke those rights down to the granularity of a single user. (This is default Oracle behavior.)
- RMF Control
- SC-2
- Severity
- M
- CCI
- CCI-001082
- Version
- O112-P2-017300
- Vuln IDs
-
- V-52459
- Rule IDs
-
- SV-66675r1_rule
Checks: C-54487r1_chk
Check DBMS settings and vendor documentation to verify administrative functionality is separate from user functionality. If administrator and general user functionality is not separated either physically or logically, this is a finding.
Fix: F-58093r1_fix
Configure DBMS settings to separate database administration and general user functionality. Provide those who have both administrative and general-user responsibilities with separate accounts for these separate functions.
- RMF Control
- SC-2
- Severity
- M
- CCI
- CCI-001083
- Version
- O112-P2-017400
- Vuln IDs
-
- V-52461
- Rule IDs
-
- SV-66677r1_rule
Checks: C-54491r1_chk
Check DBMS settings and vendor documentation to verify administrative functionality is separate from user functionality. If administrator and general user functionality is not separated either physically or logically, this is a finding.
Fix: F-57277r1_fix
Configure DBMS settings to separate database administration and general user functionality. Provide those who have both administrative and general-user responsibilities with separate accounts for these separate functions.
- RMF Control
- AU-12
- Severity
- M
- CCI
- CCI-000169
- Version
- O112-C2-006800
- Vuln IDs
-
- V-52463
- Rule IDs
-
- SV-66679r1_rule
Checks: C-54495r1_chk
Verify, using vendor and system documentation if required, that the DBMS is configured to use Oracle's auditing features, or that a third-party product is deployed and configured to satisfy this requirement. If a third-party product is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding. The remainder of this Check deals specifically with Oracle auditing. To see if Oracle is configured to capture audit data, enter the following SQLPlus command: SHOW PARAMETER AUDIT_TRAIL or the following SQL query: SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail'; If Oracle does not return the value "DB_EXTENDED" or "DB, EXTENDED", and a third-party product is not deployed and configured to satisfy this requirement, this is a finding. If it does return "DB_EXTENDED" or "DB, EXTENDED", continue. Compare the organization-defined auditable events with the Oracle documentation to determine whether standard DB_EXTENDED auditing covers all the requirements. If it does, this is not a finding. If it does not, continue. Compare those organization-defined auditable events that are not covered by the standard DB_EXTENDED auditing, with the existing Fine-Grained Auditing (FGA) specifications returned by the following query: SELECT * FROM SYS.DBA_FGA_AUDIT_TRAIL; If any such auditable event is not covered by the existing FGA specifications, this is a finding.
Fix: F-57281r1_fix
Configure the DBMS's auditing to audit organization-defined auditable events. If preferred, use a third-party tool. The tool must provide the minimum capability to audit the required events. Either use Oracle's built-in auditing capabilities, or use a third-party product that supports session auditing. If using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows. Use this query to ensure auditable events are captured: ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE; After executing this statement, it may be necessary to shutdown and restart the Oracle instance. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm If the site-specific audit requirements are not covered by the default audit options, deploy and configure Fine-Grained Auditing. For details, refer to Oracle documentation, at the locations above.
- RMF Control
- AU-10
- Severity
- L
- CCI
- CCI-000166
- Version
- O112-P3-006200
- Vuln IDs
-
- V-52465
- Rule IDs
-
- SV-66681r1_rule
Checks: C-54493r1_chk
If there are no group accounts available to more than one user, this is not a finding. If a group account is used by an application to interact with the database, review the System Security Plan, the tables in the database, and the application source code/documentation to determine whether the application captures the individual user's identity and stores that identity along with all data inserted and updated (also with all records of reads and/or deletions, if these are required to be logged). If there are gaps in the application's ability to do this, and the gaps and the risk are not defined in the system documentation and accepted by the AO, this is a finding. If users are sharing a group account to log on to Oracle tools or third-party products that access the database, this is a finding. To ensure that user activities other than SELECT, INSERT, UPDATE and DELETE are also monitored and attributed to individuals, verify that Oracle auditing is enabled. To see if Oracle is configured to capture audit data, enter the following SQLPlus command: SHOW PARAMETER AUDIT_TRAIL or the following SQL query: SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail'; If Oracle does not return the value "DB_EXTENDED" or "DB, EXTENDED", and a third-party product is not deployed and configured to satisfy this requirement, this is a finding. If it does return "DB_EXTENDED" or "DB, EXTENDED", this is not a finding.
Fix: F-57279r1_fix
Use accounts assigned to individual users where feasible. Configure DBMS to provide individual accountability at the DBMS level, and in audit logs, for actions performed under a shared database account. Modify applications and data tables that are not capturing individual user identity to do so. Create and enforce the use of individual User IDs for logging on to Oracle tools and third-party products. If Oracle (or third-party) auditing is not already enabled, enable it. For Oracle auditing, using this query: ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE; After executing this statement, it may be necessary to shutdown and restart the Oracle instance. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm If the site-specific audit requirements are not covered by the default audit options, deploy and configure Fine-Grained Auditing. For details, refer to Oracle documentation, at the locations above. If this level of auditing does not meet site-specific requirements, consider deploying the Oracle Audit Vault. The Audit Vault is a highly configurable option from Oracle made specifically for performing the audit functions. It has reporting capabilities as well as user-defined rules that provide additional flexibility for complex auditing requirements.
- RMF Control
- AU-12
- Severity
- M
- CCI
- CCI-000171
- Version
- O112-C2-006900
- Vuln IDs
-
- V-52467
- Rule IDs
-
- SV-66683r1_rule
Checks: C-54497r1_chk
Check DBMS settings and documentation to determine whether designated personnel are able to select which auditable events are being audited. If designated personnel are not able to configure auditable events, this is a finding.
Fix: F-57283r1_fix
Configure the DBMS's settings to allow designated personnel to select which auditable events are audited. Note the following: In Oracle, any user can configure auditing for the objects in his or her own schema by using the AUDIT statement. To undo the audit configuration for an object, the user can use the NOAUDIT statement. No additional privileges are needed to perform this task. To audit objects in another schema, the user must have the AUDIT ANY system privilege. To audit system privileges, the user must have the AUDIT SYSTEM privilege. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm
- RMF Control
- AU-12
- Severity
- M
- CCI
- CCI-000172
- Version
- O112-C2-007000
- Vuln IDs
-
- V-52469
- Rule IDs
-
- SV-66685r1_rule
Checks: C-54499r1_chk
Check DBMS settings to determine if auditing is being performed on the events on the DoD-selected list of auditable events. If auditing is not being performed for any of the events on the DoD-selected list of auditable events, this is a finding.
Fix: F-57285r1_fix
Configure the DBMS's auditing settings to include auditing of events on the DoD-selected list of auditable events. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000130
- Version
- O112-C2-007400
- Vuln IDs
-
- V-52471
- Rule IDs
-
- SV-66687r1_rule
Checks: C-54501r1_chk
Verify, using vendor and system documentation if required, that the DBMS is configured to use Oracle's auditing features, or that a third-party product is deployed and configured to satisfy this requirement. If a third-party product is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding. The remainder of this Check deals specifically with Oracle auditing. To see if Oracle is configured to capture audit data, enter the following SQLPlus command: SHOW PARAMETER AUDIT_TRAIL or the following SQL query: SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail'; If Oracle does not return the value "DB_EXTENDED" or "DB, EXTENDED", and a third-party product is not deployed and configured to satisfy this requirement, this is a finding. If it does return "DB_EXTENDED" or "DB, EXTENDED", continue. To confirm that Oracle audit is capturing sufficient information to establish what type of events occurred, perform an auditable action, and then issue the SQL statement: SELECT SQLTEXT FROM SYS.AUD$ WHERE SQLTEXT IS NOT NULL; If no row is returned for the auditable action just performed, this is a finding.
Fix: F-57287r1_fix
Configure the DBMS's auditing to audit organization-defined auditable events. If preferred, use a third-party tool. The tool must provide the minimum capability to audit the required events. Either use Oracle's built-in auditing capabilities, or use a third-party product that supports session auditing. If using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows. Use this query to ensure auditable events are captured: ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE; After executing this statement, it may be necessary to shutdown and restart the Oracle instance. If the query SELECT SQLTEXT FROM SYS.AUD$ WHERE SQLTEXT IS NOT NULL; does not return rows for auditable actions, modify the audit settings to capture this information. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000131
- Version
- O112-C2-007500
- Vuln IDs
-
- V-52473
- Rule IDs
-
- SV-66689r1_rule
Checks: C-54503r1_chk
Verify, using vendor and system documentation if required, that the DBMS is configured to use Oracle's auditing features, or that a third-party product is deployed and configured to satisfy this requirement. If a third-party product is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding. The remainder of this Check deals specifically with Oracle auditing. To see if Oracle is configured to capture audit data, enter the following SQLPlus command: SHOW PARAMETER AUDIT_TRAIL or the following SQL query: SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail'; If Oracle does not return the value "DB_EXTENDED" or "DB, EXTENDED", and a third-party product is not deployed and configured to satisfy this requirement, this is a finding. If it does return "DB_EXTENDED" or "DB, EXTENDED", continue. To confirm that Oracle audit is capturing sufficient information to establish when events occurred, perform an auditable action, and then issue the SQL statement: SELECT NTIMESTAMP# FROM SYS.AUD$; If no timestamp is returned for the auditable action just performed, this is a finding.
Fix: F-57289r1_fix
Configure the DBMS's auditing to audit organization-defined auditable events. If preferred, use a third-party tool. The tool must provide the minimum capability to audit the required events. Either use Oracle's built-in auditing capabilities, or use a third-party product that supports session auditing. If using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows. Use this query to ensure auditable events are captured: ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE; After executing this statement, it may be necessary to shutdown and restart the Oracle instance. If the query SELECT NTIMESTAMP# FROM SYS.AUD$; does not return timestamps for auditable actions, modify the audit settings to capture this information. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000132
- Version
- O112-C2-007600
- Vuln IDs
-
- V-52475
- Rule IDs
-
- SV-66691r1_rule
Checks: C-54505r2_chk
Verify, using vendor and system documentation if required, that the DBMS is configured to use Oracle's auditing features, or that a third-party product is deployed and configured to satisfy this requirement. If a third-party product is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding. The remainder of this Check deals specifically with Oracle auditing. To see if Oracle is configured to capture audit data, enter the following SQLPlus command: SHOW PARAMETER AUDIT_TRAIL or the following SQL query: SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail'; If Oracle does not return the value "DB_EXTENDED" or "DB, EXTENDED", and a third-party product is not deployed and configured to satisfy this requirement, this is a finding. If it does return "DB_EXTENDED" or "DB, EXTENDED", continue. To confirm that Oracle audit is capturing sufficient information to establish where events occurred, perform an auditable action, and then issue the SQL statement: SELECT USERHOST, TERMINAL FROM SYS.AUD$; If no data is returned for the auditable action just performed, this is a finding.
Fix: F-57291r1_fix
Configure the DBMS's auditing to audit organization-defined auditable events. If preferred, use a third-party tool. The tool must provide the minimum capability to audit the required events. Either use Oracle's built-in auditing capabilities, or use a third-party product that supports session auditing. If using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows. Use this query to ensure auditable events are captured: ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE; After executing this statement, it may be necessary to shutdown and restart the Oracle instance. If the query SELECT USERHOST, TERMINAL FROM SYS.AUD$; does not return data for auditable actions, modify the audit settings to capture this information. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000133
- Version
- O112-C2-007700
- Vuln IDs
-
- V-52477
- Rule IDs
-
- SV-66693r1_rule
Checks: C-54507r1_chk
Verify, using vendor and system documentation if required, that the DBMS is configured to use Oracle's auditing features, or that a third-party product is deployed and configured to satisfy this requirement. If a third-party product is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding. The remainder of this Check deals specifically with Oracle auditing. To see if Oracle is configured to capture audit data, enter the following SQLPlus command: SHOW PARAMETER AUDIT_TRAIL or the following SQL query: SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail'; If Oracle does not return the value "DB_EXTENDED" or "DB, EXTENDED", and a third-party product is not deployed and configured to satisfy this requirement, this is a finding. If it does return "DB_EXTENDED" or "DB, EXTENDED", continue. To confirm that Oracle audit is capturing sufficient information to establish where events occurred, perform an auditable action, and then issue the SQL statement: SELECT USERHOST, TERMINAL FROM SYS.AUD$; If no data is returned for the auditable action just performed, this is a finding.
Fix: F-57293r1_fix
Configure the DBMS's auditing to audit organization-defined auditable events. If preferred, use a third-party tool. The tool must provide the minimum capability to audit the required events. Either use Oracle's built-in auditing capabilities, or use a third-party product that supports session auditing. If using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows. Use this query to ensure auditable events are captured: ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE; After executing this statement, it may be necessary to shutdown and restart the Oracle instance. If the query SELECT USERHOST, TERMINAL FROM SYS.AUD$; does not return data for auditable actions, modify the audit settings to capture this information. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000134
- Version
- O112-C2-007800
- Vuln IDs
-
- V-52479
- Rule IDs
-
- SV-66695r1_rule
Checks: C-54509r1_chk
Verify, using vendor and system documentation if required, that the DBMS is configured to use Oracle's auditing features, or that a third-party product is deployed and configured to satisfy this requirement. If a third-party product is used, compare its current configuration with the audit requirements. If any of the requirements is not covered by the configuration, this is a finding. The remainder of this Check deals specifically with Oracle auditing. To see if Oracle is configured to capture audit data, enter the following SQLPlus command: SHOW PARAMETER AUDIT_TRAIL or the following SQL query: SELECT * FROM SYS.V$PARAMETER WHERE NAME = 'audit_trail'; If Oracle does not return the value "DB_EXTENDED" or "DB, EXTENDED", and a third-party product is not deployed and configured to satisfy this requirement, this is a finding. If it does return "DB_EXTENDED" or "DB, EXTENDED", continue. To confirm that Oracle audit is capturing sufficient information to establish outcomes, perform a successful auditable action and an auditable action that results in an SQL error, and then issue the SQL statement: SELECT RETURNCODE FROM SYS.AUD$; If no data is returned for the auditable action just performed, this is a finding. If a code indicating an error is returned for the successful action, this is a finding. If a code indicating no error is returned for the unsuccessful action, this is a finding.
Fix: F-57295r1_fix
Configure the DBMS's auditing to audit organization-defined auditable events. If preferred, use a third-party tool. The tool must provide the minimum capability to audit the required events. Either use Oracle's built-in auditing capabilities, or use a third-party product that supports session auditing. If using a third-party product, proceed in accordance with the product documentation. If using Oracle's capabilities, proceed as follows. Use this query to ensure auditable events are captured: ALTER SYSTEM SET AUDIT_TRAIL=DB,EXTENDED SCOPE=SPFILE; After executing this statement, it may be necessary to shutdown and restart the Oracle instance. If the query SELECT RETURNCODE FROM SYS.AUD$; does not return valid data for auditable actions, modify the audit settings to capture this information. For more information on the configuration of auditing, please refer to "Auditing Database Activity" in the Oracle Database 2 Day + Security Guide: http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm and "Verifying Security Access with Auditing" in the Oracle Database Security Guide: http://docs.oracle.com/cd/E11882_01/network.112/e36292/auditing.htm#DBSEG006 and "27 DBMS_AUDIT_MGMT" in the Oracle Database PL/SQL Packages and Types Reference: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_audit_mgmt.htm
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-C2-015501
- Vuln IDs
-
- V-53281
- Rule IDs
-
- SV-67497r1_rule
Checks: C-54663r4_chk
Review configuration to confirm that accounts used by processes to connect to the DBMS are authenticated using valid, current DoD-issued PKI certificates. If any such account is not certificate-based, this is a finding.
Fix: F-58097r2_fix
For each such account, use DoD certificate-based authentication.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-021100
- Vuln IDs
-
- V-53959
- Rule IDs
-
- SV-68199r1_rule
Checks: C-54749r2_chk
Review and verify the implementation of an audit trail retention policy. Verify that audit data is maintained for a minimum of one year. If audit data is not maintained for a minimum of one year, this is a Finding.
Fix: F-58799r1_fix
Develop, document and implement an audit retention policy and procedures. It is recommended that the most recent thirty days of audit logs remain available online. After thirty days, the audit logs may be maintained offline. Online maintenance provides for a more timely capability and inclination to investigate suspicious activity.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-021200
- Vuln IDs
-
- V-53961
- Rule IDs
-
- SV-68201r1_rule
Checks: C-54751r2_chk
From SQL*Plus: select 'The number of replication objects defined is: '|| count(*) from all_tables where table_name like 'REPCAT%'; If the count returned is 0, then Oracle Replication is not installed and this check is Not a Finding. Otherwise: From SQL*Plus: select count(*) from sys.dba_repcatlog; If the count returned is 0, then Oracle Replication is not in use and this check is Not a Finding. If any results are returned, ask the IAO or DBA if the replication account (the default is REPADMIN, but may be customized) is restricted to IAO-authorized personnel only. If it is not, this is a Finding. If there are multiple replication accounts, confirm that all are justified and documented with the IAO. If they are not, this is a Finding.
Fix: F-58801r1_fix
Change the password for default and custom replication accounts and provide the password to IAO-authorized users only.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-021300
- Vuln IDs
-
- V-53963
- Rule IDs
-
- SV-68203r1_rule
Checks: C-54753r2_chk
From SQL*Plus: select instance_name from v$instance; select version from v$instance; If the instance name returned references the Oracle release number, this is a Finding. Numbers used that include version numbers by coincidence are not a Finding. The DBA should be able to relate the significance of the presence of a digit in the SID.
Fix: F-58803r1_fix
Follow the instructions in Oracle MetaLink Note 15390.1 (and related documents) to change the SID for the database without re-creating the database to a value that does not identify the Oracle version.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-021400
- Vuln IDs
-
- V-53965
- Rule IDs
-
- SV-68205r1_rule
Checks: C-54755r1_chk
From SQL*Plus: select owner||': '||db_link from dba_db_links; select count(*) from sys.dba_repcatlog; If no records are returned from the first SQL statement, this check is Not a Finding. If the value of the count returned is 0 for the second SQL statement, none of the database links listed above, if any, is used for replication. Confirm the public and fixed user database links listed are documented in the System Security Plan, are authorized by the IAO and are used for replication or operational system requirements. If any are not, this is a Finding.
Fix: F-58805r1_fix
Document all authorized connections from the database to remote databases in the System Security Plan. Remove all unauthorized remote database connection definitions from the database. From SQL*Plus: drop database link [link name]; OR drop public database link [link name]; Review remote database connection definitions periodically and confirm their use is still required and authorized.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-021500
- Vuln IDs
-
- V-53967
- Rule IDs
-
- SV-68207r1_rule
Checks: C-54757r1_chk
From SQL*Plus: select name from v$controlfile; DoD guidance recommends: 1. A minimum of two distinct control files for each Oracle Database Instance. 2a. Each control file is to be located on separate, archived physical storage devices OR 2b. Each control file is to be located on separate, archived directories within one or more RAID devices 3. The Logical Paths for each control file should differ at the highest level supported by your configuration, for example: UNIX /ora03/app/oracle/{SID}/control/control01.ctl /ora04/app/oracle/{SID}/control/control02.ctl Windows D:/oracle/{SID}/control/control01.ctl E:/oracle/{SID}/control/control02.ctl If this minimum listed above is not met, this is a Finding. Consult with the SA or DBA to determine that the mount points or partitions referenced in the file paths indicate separate physical disks or directories on RAID devices. NOTE: Distinct does not equal dedicated. You may share directory space with other Oracle database instances if present.
Fix: F-58807r1_fix
To prevent loss of service during disk failure, multiple copies of Oracle control files should be maintained on separate disks in archived directories or on separate, archived directories within one or more RAID devices. Adding or moving a control file requires careful planning and execution. Please consult and follow the instructions for creating control files in the Oracle Database Administrator's Guide, under Steps for Creating New Control Files.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-021600
- Vuln IDs
-
- V-53969
- Rule IDs
-
- SV-68209r1_rule
Checks: C-54759r1_chk
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.
Fix: F-58809r1_fix
To define additional redo log file groups: From SQL*Plus (Example): alter database add logfile group 2 ('diska:log2.log', 'diskb:log2.log') size 50K; To add additional redo log file [members] to an existing redo log file group: From SQL*Plus (Example): alter database add logfile member 'diskc:log2.log' to group 2; Replace diska, diskb, diskc with valid, different disk drive specifications. Replace log#.log file with valid or custom names for the log files.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-021700
- Vuln IDs
-
- V-53971
- Rule IDs
-
- SV-68211r1_rule
Checks: C-54761r1_chk
From SQL*Plus: select grantee||': '||owner||'.'||table_name from dba_tab_privs where grantable = 'YES' and owner not in (select distinct owner from dba_objects) and grantee not in (select grantee from dba_role_privs where granted_role = 'DBA') order by grantee; If any accounts are listed, this is a Finding.
Fix: F-58811r1_fix
Revoke privileges granted the WITH GRANT OPTION from non-DBA and accounts that do not own application objects. Re-grant privileges without specifying WITH GRANT OPTION.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-021800
- Vuln IDs
-
- V-53973
- Rule IDs
-
- SV-68213r1_rule
Checks: C-54763r1_chk
From SQL*Plus: select table_name from dba_tab_privs where grantee='PUBLIC' and privilege ='EXECUTE' and table_name in ('UTL_FILE', 'UTL_SMTP', 'UTL_TCP', 'UTL_HTTP', 'DBMS_RANDOM', 'DBMS_LOB', 'DBMS_SQL', 'DBMS_SYS_SQL', 'DBMS_JOB', 'DBMS_BACKUP_RESTORE', 'DBMS_OBFUSCATION_TOOLKIT'); If any records are returned, this is a Finding.
Fix: F-58813r1_fix
Revoking all default installation privilege assignments from PUBLIC is not required at this time. However, execute permissions to the specified packages is required to be revoked from PUBLIC. Removal of these privileges from PUBLIC may result in invalid packages in version 10.1 and later of Oracle and an inability to execute default Oracle applications and utilities. To correct this problem, grant execute privileges on these packages directly to the SYSMAN, WKSYS, MDSYS and SYSTEM accounts as well as any other default Oracle database and custom application object owner accounts as necessary to support execution of applications/utilities installed with an Oracle Database Server. At a minimum, revoke the following: From SQL*Plus: revoke execute on UTL_FILE from PUBLIC; revoke execute on UTL_SMTP from PUBLIC; revoke execute on UTL_TCP from PUBLIC; revoke execute on UTL_HTTP from PUBLIC; revoke execute on DBMS_RANDOM from PUBLIC; revoke execute on DBMS_LOB from PUBLIC; revoke execute on DBMS_SQL from PUBLIC; revoke execute on DBMS_SYS_SQL from PUBLIC; revoke execute on DBMS_JOB from PUBLIC; revoke execute on DBMS_BACKUP_RESTORE from PUBLIC; revoke execute on DBMS_OBFUSCATION_TOOLKIT from PUBLIC;
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- O112-BP-021900
- Vuln IDs
-
- V-53975
- Rule IDs
-
- SV-68215r1_rule
Checks: C-54765r1_chk
From SQL*Plus: select value from v$parameter where name = 'remote_os_authent'; If the value returned does not equal FALSE, this is a Finding.
Fix: F-58815r1_fix
Document remote OS authentication in the System Security Plan. If not required or not mitigated to an acceptable level, disable remote OS authentication. From SQL*Plus: alter system set remote_os_authent = FALSE scope = spfile; The above SQL*Plus command will set the parameter to take effect at next system startup.
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- O112-BP-022000
- Vuln IDs
-
- V-53977
- Rule IDs
-
- SV-68217r1_rule
Checks: C-54767r1_chk
From SQL*Plus: select value from v$parameter where name = 'remote_os_roles'; If the returned value is not FALSE or not documented in the System Security Plan as required, this is a Finding.
Fix: F-58817r1_fix
Document remote OS roles in the System Security Plan. If not required, disable use of remote OS roles. From SQL*Plus: alter system set remote_os_roles = FALSE scope = spfile; The above SQL*Plus command will set the parameter to take effect at next system startup.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-022100
- Vuln IDs
-
- V-53979
- Rule IDs
-
- SV-68219r1_rule
Checks: C-54769r1_chk
From SQL*Plus: select value from v$parameter where name = 'sql92_security'; If the value returned is set to FALSE, this is a Finding. If the parameter is set to TRUE or does not exist, this is Not a Finding.
Fix: F-58819r1_fix
Enable SQL92 security. From SQL*Plus: alter system set sql92_security = TRUE scope = spfile; The above SQL*Plus command will set the parameter to take effect at next system startup.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-022200
- Vuln IDs
-
- V-53981
- Rule IDs
-
- SV-68221r1_rule
Checks: C-54771r1_chk
From SQL*Plus: select value from v$parameter where name = 'remote_login_passwordfile'; If the value returned does not equal 'EXCLUSIVE' or 'NONE', this is a Finding.
Fix: F-58821r1_fix
Disable use of the remote_login_passwordfile where remote administration is not authorized by specifying a value of NONE. If authorized, restrict use of a password file to exclusive use by each database by specifying a value of EXCLUSIVE. From SQL*Plus: alter system set remote_login_passwordfile = 'EXCLUSIVE' scope = spfile; OR alter system set remote_login_passwordfile = 'NONE' scope = spfile; The above SQL*Plus command will set the parameter to take effect at next system startup.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-022300
- Vuln IDs
-
- V-53983
- Rule IDs
-
- SV-68223r1_rule
Checks: C-54773r1_chk
From SQL*Plus: select grantee, privilege from dba_sys_privs where grantee not in ('SYS', 'SYSTEM', 'AQ_ADMINISTRATOR_ROLE', 'DBA', 'MDSYS', 'LBACSYS', 'SCHEDULER_ADMIN', 'WMSYS') and admin_option = 'YES' and grantee not in (select grantee from dba_role_privs where granted_role = 'DBA'); If any accounts are listed, this is a Finding.
Fix: F-58823r1_fix
Revoke assignment of privileges with the WITH ADMIN OPTION from unauthorized users and re-grant them without the option. From SQL*Plus: revoke [privilege name] from user [username]; Replace [privilege name] with the named privilege and [username] with the named user. Restrict use of the WITH ADMIN OPTION to authorized administrators. Document authorized privilege assignments with the WITH ADMIN OPTION in the System Security Plan.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-022400
- Vuln IDs
-
- V-53985
- Rule IDs
-
- SV-68225r1_rule
Checks: C-54775r1_chk
From SQL*Plus: select privilege from dba_sys_privs where grantee = 'PUBLIC'; If any records are returned, this is a Finding.
Fix: F-58825r1_fix
Revoke any system privileges assigned to PUBLIC: From SQL*Plus: revoke [system privilege] from PUBLIC; Replace [system privilege] with the named system privilege. NOTE: System privileges are not granted to PUBLIC by default and would indicate a custom action.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-022500
- Vuln IDs
-
- V-53987
- Rule IDs
-
- SV-68227r1_rule
Checks: C-54777r1_chk
From SQL*Plus (NOTE: The owner list below is a short list of all possible default Oracle accounts): select grantee||': '||granted_role from dba_role_privs where grantee not in ('DBA', 'SYS', 'SYSTEM', 'WKSYS', 'LBACSYS', 'WMSYS', 'OWBSYS', 'CTXSYS', 'SPATIAL_CSW_ADMIN_USR', 'SPATIAL_WFS_ADMIN_USR', 'FLOWS_030000') and admin_option = 'YES' and grantee not in (select distinct owner from dba_objects) and grantee not in (select grantee from dba_role_privs where granted_role = 'DBA') order by grantee; Review the System Security Plan to confirm any grantees listed are IAO-authorized DBA accounts or application administration roles. If any grantees listed are not authorized and documented, this is a Finding.
Fix: F-58827r1_fix
Revoke assignment of roles with the WITH ADMIN OPTION from unauthorized grantees and re-grant them without the option if required. From SQL*Plus: revoke [role name] from [grantee]; grant [role name] to [grantee]; Restrict use of the WITH ADMIN OPTION to authorized administrators. Document authorized role assignments with the WITH ADMIN OPTION in the System Security Plan.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-022600
- Vuln IDs
-
- V-53989
- Rule IDs
-
- SV-68229r1_rule
Checks: C-54779r1_chk
From SQL*Plus (NOTE: The owner list below is a short list of all possible default Oracle accounts): select owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs where grantee = 'PUBLIC' and owner not in ('SYS', 'CTXSYS', 'MDSYS', 'ODM', 'OLAPSYS', 'MTSSYS', 'ORDPLUGINS', 'ORDSYS', 'SYSTEM', 'WKSYS', 'WMSYS', 'XDB', 'LBACSYS', 'PERFSTAT', 'SYSMAN', 'DMSYS', 'EXFSYS'); If any records that are not Oracle product accounts are returned, are not documented and authorized, this is a Finding. NOTE: This check may return false positives where other Oracle product accounts are not included in the exclusion list.
Fix: F-58829r1_fix
Revoke any privileges granted to PUBLIC for objects that are not owned by Oracle product accounts. From SQL*Plus: revoke [privilege name] from [user name] on [object name]; Assign permissions to custom application user roles based on job functions: From SQL*Plus: grant [privilege name] to [user role] on [object name];
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- O112-BP-022700
- Vuln IDs
-
- V-53991
- Rule IDs
-
- SV-68231r1_rule
Checks: C-54781r1_chk
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.
Fix: F-58831r1_fix
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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-022800
- Vuln IDs
-
- V-53993
- Rule IDs
-
- SV-68233r1_rule
Checks: C-54783r1_chk
From SQL*Plus: select granted_role from dba_role_privs where grantee = 'PUBLIC'; If any roles are listed, this is a Finding.
Fix: F-58833r1_fix
Revoke role grants from PUBLIC. Do not assign role privileges to PUBLIC. From SQL*Plus: revoke [role name] from PUBLIC;
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-022900
- Vuln IDs
-
- V-53995
- Rule IDs
-
- SV-68235r1_rule
Checks: C-54785r1_chk
From SQL*Plus (NOTE: The owner list below is a short list of all possible default Oracle accounts): select grantee, granted_role from dba_role_privs where default_role='YES' and granted_role in (select grantee from dba_sys_privs where upper(privilege) like '%USER%') and grantee not in 'DBA', 'SYS', 'SYSTEM', 'CTXSYS', 'DBA', 'IMP_FULL_DATABASE', 'MDSYS', 'SYS', 'WKSYS') and grantee not in (select distinct owner from dba_tables) and grantee not in (select distinct username from dba_users where upper(account_status) like '%LOCKED%'); Review the list of accounts reported for this check and ensures that they are authorized application administration roles. If any are not authorized application administration roles, this is a Finding.
Fix: F-58927r1_fix
For each role assignment returned, issue: From SQL*Plus: alter user [username] default role all except [role]; If the user has more than one application administration role assigned, then you will have to remove assigned roles from default assignment and assign individually the appropriate default roles.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-023000
- Vuln IDs
-
- V-53997
- Rule IDs
-
- SV-68237r1_rule
Checks: C-54787r1_chk
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 <> 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.
Fix: F-58835r2_fix
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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-023100
- Vuln IDs
-
- V-53999
- Rule IDs
-
- SV-68239r1_rule
Checks: C-54789r1_chk
The DBMS_JOB PL/SQL package has been replaced by DBMS_SCHEDULER in Oracle versions 10.1 and higher, though it continues to be supported for backward compatibility. From SQL*Plus: select value from v$parameter where name = 'job_queue_processes'; From SQL*Plus: select value from all_scheduler_global_attribute where ATTRIBUTE_NAME = 'MAX_JOB_SLAVE_PROCESSES'; To understand the relationship between these settings, review: http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/appendix_a003.htm Review documented and implemented procedures for monitoring the Oracle DBMS job/batch queues for unauthorized submissions. If procedures for job queue review are not defined, documented or evidence of implementation does not exist, this is a Finding. Job queue information is available from the DBA_JOBS view. The following command lists jobs submitted to the queue. DBMS_JOB does not generate a 'history' of previous job executions. From SQL*Plus: select job, next_date, next_sec, failures, broken from dba_jobs; Scheduler queue information is available from the DBA_SCHEDULER_JOBS view. The following command lists jobs submitted to the queue. From SQL*Plus: select owner, job_name, state, job_class, job_type, job_action from dba_scheduler_jobs;
Fix: F-58837r1_fix
Develop, document and implement procedures to monitor the database job queues for unauthorized job submissions. Develop, document and implement a formal migration plan to convert jobs using DBMS_JOB to use DBMS_SCHEDULER instead for Oracle versions 10.1 and higher. Set the value of the job_queue_processes parameter to a low value to restrict concurrent DBMS_JOB executions. Use auditing to capture use of the DBMS_JOB package in the audit trail. Review the audit trail for unauthorized use of the DBMS_JOB package.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-023200
- Vuln IDs
-
- V-54001
- Rule IDs
-
- SV-68241r1_rule
Checks: C-54791r1_chk
From SQL*Plus: select db_link||': '||host from dba_db_links; If no links are returned, this check is Not a Finding. Review documentation for definitions of authorized database links to external interfaces. The documentation should include: - Any remote access to the database - The purpose or function of the remote connection - Any access to data or procedures stored externally to the local DBMS - Any network ports or protocols used by remote connections, whether the remote connection is to a production, test, or development system - Any security accounts used by DBMS to access remote resources or objects If any unauthorized database links are defined or the definitions do not match the documentation, this is a Finding. NOTE: Findings for production-development links under this check are assigned to the production database only. If any database links are defined between the production database and any test or development databases, this is a Finding. If remote interface documentation does not exist or is incomplete, this is a Finding.
Fix: F-58839r1_fix
Document all remote or external interfaces used by the DBMS to connect to or allow connections from remote or external sources. Include with the documentation as appropriate, any network ports or protocols, security accounts, and the sensitivity of any data exchanged. Do not define or configure database links between production databases and test or development databases.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-023300
- Vuln IDs
-
- V-54003
- Rule IDs
-
- SV-68243r1_rule
Checks: C-54793r1_chk
If the database being reviewed is a production database, this check is Not a Finding. Review policy, procedures and restrictions for data imports of production data containing sensitive information into development databases. If data imports of production data are allowed, review procedures for protecting any sensitive data included in production exports. If sensitive data is included in the exports and no procedures are in place to remove or modify the data to render it not sensitive prior to import into a development database or policy and procedures are not in place to ensure authorization of development personnel to access sensitive information contained in production data, this is a Finding.
Fix: F-58841r1_fix
Develop, document and implement policy, procedures and restrictions for production data import. Require any users assigned privileges that allow the export of production data from the database to acknowledge understanding of import policies, procedures and restrictions. Restrict permissions of development personnel requiring use or access to production data imported into development databases containing sensitive information to authorized users. Implement policy and procedures to modify or remove sensitive information in production exports prior to import into development databases.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-023400
- Vuln IDs
-
- V-54005
- Rule IDs
-
- SV-68245r1_rule
Checks: C-54795r1_chk
Review policy, procedures and implementation evidence to determine if periodic reviews of user privileges by the IAO are being performed. Evidence may consist of email or other correspondence that acknowledges receipt of periodic reports and notification of review between the DBA and IAO or other auditors as assigned. If policy and procedures are incomplete or no evidence of implementation exists, this is a Finding.
Fix: F-58843r1_fix
Develop, document and implement policy and procedures for periodic review of database user accounts and privilege assignments. Include methods to provide evidence of review in the procedures to verify reviews occur in accordance with the procedures.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-023500
- Vuln IDs
-
- V-54007
- Rule IDs
-
- SV-68247r1_rule
Checks: C-54797r1_chk
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.
Fix: F-58845r1_fix
Develop, document and implement policy and procedures to monitor audit trail data daily.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-023600
- Vuln IDs
-
- V-54009
- Rule IDs
-
- SV-68249r1_rule
Checks: C-54799r1_chk
From SQL*Plus: select username from dba_users where (default_tablespace = 'SYSTEM' or temporary_tablespace = 'SYSTEM') and username not in ('AURORA$JIS$UTILITY$','AURORA$ORB$UNAUTHENTICATED', 'DBSNMP','MDSYS','ORDPLUGINS','ORDSYS','OSE$HTTP$ADMIN', 'OUTLN','REPADMIN','SYS','SYSTEM','TRACESVR','MTSSYS','DIP'); If any non-default account records are returned, this is a Finding.
Fix: F-58847r1_fix
Create and dedicate tablespaces to support only one application. Do not share tablespaces between applications. Do not grant quotas to application object owners on tablespaces not dedicated to their associated application. From SQL*Plus: alter user [username] default tablespace [tablespace_name] temporary tablespace TEMP; Replace [username] with the named user account. Replace [tablespace_name] with the new default tablespace name.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-023700
- Vuln IDs
-
- V-54011
- Rule IDs
-
- SV-68251r1_rule
Checks: C-54801r1_chk
From SQL*Plus (NOTE: The owner list below is a short list of all possible default Oracle accounts): select distinct owner, tablespace_name from dba_tables where owner not in ('SYS','SYSTEM','OUTLN','OLAPSYS','CTXSYS','WKSYS','ODM', 'ODM_MTR','MDSYS','ORDSYS','WMSYS','RMAN','XDB') and tablespace_name is not NULL and (owner, table_name) not in (select owner, table_name from dba_external_tables) order by tablespace_name; Review the list of returned table owners with the tablespace used. If any of the owners listed are not default Oracle accounts and use the SYSTEM or any other tablespace not dedicated for the application’s use, this is a Finding. Look for multiple applications that may share a tablespace. If no records were returned, ask the DBA if any applications use this database. If no applications use the database, this is not a Finding. If there are applications that do use the database or if the application uses the SYS or other default account and SYSTEM tablespace to store its objects, this is a Finding.
Fix: F-58849r1_fix
Create and assign dedicated tablespaces for the storage of data by each application using the CREATE TABLESPACE command.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-023800
- Vuln IDs
-
- V-54013
- Rule IDs
-
- SV-68253r1_rule
Checks: C-54803r1_chk
From SQL*Plus: select log_mode from v$database; select value from v$parameter where name = 'log_archive_dest'; select value from v$parameter where name = 'log_archive_duplex_dest'; select name, value from v$parameter where name LIKE 'log_archive_dest_%'; If the value returned for LOG_MODE is NOARCHIVELOG, this check is Not a Finding. If a value is not returned for LOG_ARCHIVE_DEST and no values are returned for any of the LOG_ARCHIVE_DEST_[1-10] parameters, this is a Finding. NOTE: LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST are incompatible with the LOG_ARCHIVE_DEST_n parameters, and must be defined as the null string (' ') when any LOG_ARCHIVE_DEST_n parameter has a value other than a null string. On UNIX Systems: ls -ld [pathname] Substitute [pathname] with the directory paths listed from the above SQL statements for log_archive_dest and log_archive_duplex_dest. If permissions are granted for world access, this is a Finding. On Windows Systems (From Windows Explorer): Browse to the directory specified. Select and right-click on the directory, select Properties, select the Security tab. If permissions are granted to everyone, this is a Finding. If any account other than the Oracle process and software owner accounts, Administrators, DBAs, System group or developers authorized to write and debug applications on this database are listed, this is a Finding.
Fix: F-58851r1_fix
Specify a valid and protected directory for archive log files. Restrict access to the Oracle process and software owner accounts, DBAs, and backup operator accounts.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-023900
- Vuln IDs
-
- V-54015
- Rule IDs
-
- SV-68255r1_rule
Checks: C-54805r1_chk
From SQL*Plus: select value from v$parameter where name = '_trace_files_public'; If the value returned is TRUE, this is a Finding. If the parameter does not exist or is set to FALSE, this is Not a Finding.
Fix: F-58853r1_fix
From SQL*Plus (shutdown database instance): shutdown immediate From SQL*Plus (create a pfile from spfile): create pfile='[PATH]init[SID].ora' from spfile; Edit the init[SID].ora file and remove the following line: *._trace_files_public=TRUE From SQL*Plus (update the spfile using the pfile): create spfile from pfile='[PATH]init[SID].ora'; From SQL*Plus (start the database instance): startup NOTE: [PATH] depends on the platform (Windows or UNIX). Ensure the file is directed to a writable location. [SID] is equal to the oracle SID or database instance ID.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-024000
- Vuln IDs
-
- V-54017
- Rule IDs
-
- SV-68257r1_rule
Checks: C-54807r2_chk
From SQL*Plus (NOTE: The owner list below is a short list of all possible default Oracle accounts): select distinct owner from dba_objects, dba_users where owner not in ('ANONYMOUS','AURORA$JIS$UTILITY$', 'AURORA$ORB$UNAUTHENTICATED','CTXSYS','DBSNMP','DIP','DVF', 'DVSYS','EXFSYS','LBACSYS','MDDATA','MDSYS','MGMT_VIEW','ODM', 'ODM_MTR','OLAPSYS','ORDPLUGINS','ORDSYS','OSE$HTTP$ADMIN', 'OUTLN','PERFSTAT','PUBLIC','REPADMIN','RMAN', 'SI_INFORMTN_SCHEMA','SYS','SYSMAN','SYSTEM','TRACESVR', 'TSMSYS','WK_TEST','WKPROXY','WKSYS','WKUSER','WMSYS','XDB') and owner in (select distinct owner from dba_objects where object_type <> 'SYNONYM') and owner = username and upper(account_status) not like '%LOCKED%'; To obtain a list of users assigned DBA privileges. From SQL*Plus: select grantee from dba_role_privs where granted_role = ’DBA’; If any records are returned, then verify the account is an authorized application object owner account or a default account installed to support an Oracle product. Verify that any objects owned by custom DBA accounts are for the personal use of that DBA. If any objects are used to support applications or any functions other than DBA functions, this is a Finding. Any unauthorized object owner accounts are not a finding under this check as they are noted as findings under check O112-C2-011000. Any other accounts listed are a Finding.
Fix: F-58855r1_fix
Disable any application object owner accounts. From SQL*Plus: alter user [username] account lock; Enable application object owner accounts only for installation and maintenance. DBA are special purpose accounts and do not require disabling although they may own objects. For application objects that require routine maintenance, e.g. index objects, to maintain performance, consider allowing a special purpose account to own the index or enable the application owner account for the duration of the routine maintenance function only.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-024100
- Vuln IDs
-
- V-54019
- Rule IDs
-
- SV-68259r1_rule
Checks: C-54809r1_chk
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.
Fix: F-58857r2_fix
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 O112-BP-025000 and O112-BP-025300). A dedicated host system in this case refers to an instance of the operating system at a minimum. The operating system may reside on a virtual host machine where supported by the DBMS vendor.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-024200
- Vuln IDs
-
- V-54021
- Rule IDs
-
- SV-68261r1_rule
Checks: C-54811r1_chk
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.
Fix: F-58859r1_fix
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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-024400
- Vuln IDs
-
- V-54023
- Rule IDs
-
- SV-68263r1_rule
Checks: C-54815r3_chk
If remote administrative access to the database is prohibited and is disabled, 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.
Fix: F-58863r1_fix
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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-024500
- Vuln IDs
-
- V-54025
- Rule IDs
-
- SV-68265r1_rule
Checks: C-54817r1_chk
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.
Fix: F-58865r1_fix
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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-024600
- Vuln IDs
-
- V-54027
- Rule IDs
-
- SV-68267r1_rule
Checks: C-54819r1_chk
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.
Fix: F-58867r1_fix
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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-024700
- Vuln IDs
-
- V-54029
- Rule IDs
-
- SV-68269r1_rule
Checks: C-54821r1_chk
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.
Fix: F-58869r1_fix
Develop, document and implement procedures for testing DBMS installations, upgrades and patches prior to deployment on production systems.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-024800
- Vuln IDs
-
- V-54031
- Rule IDs
-
- SV-68271r1_rule
Checks: C-54823r1_chk
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.
Fix: F-58871r3_fix
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 (O112-BP-023300). Grant access and need-to-know to developers where allowed by policy.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-024900
- Vuln IDs
-
- V-54033
- Rule IDs
-
- SV-68273r1_rule
Checks: C-54825r2_chk
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.
Fix: F-58873r1_fix
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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-025000
- Vuln IDs
-
- V-54035
- Rule IDs
-
- SV-68275r1_rule
Checks: C-54827r1_chk
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.
Fix: F-58875r1_fix
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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-025100
- Vuln IDs
-
- V-54037
- Rule IDs
-
- SV-68277r1_rule
Checks: C-54829r1_chk
Review the disk/directory specification where database data, transaction log and audit files are stored. If DBMS data, transaction or audit data files are stored in the same directory, this is a Finding. If separation of data, transaction and audit data is not supported by the DBMS, this check is Not a Finding. If stored separately and access permissions for each directory is the same, this is a Finding.
Fix: F-58877r1_fix
Product-specific fix pending development. Use Generic Fix listed below: Specify dedicated host system disk directories to store database data, transaction and audit files. Configure DBMS default file storage locations to use dedicated disk directories where supported by the DBMS.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-025200
- Vuln IDs
-
- V-54039
- Rule IDs
-
- SV-68279r1_rule
Checks: C-54831r1_chk
Review the list of defined database links generated from the DBMS. Compare to the list in the System Security Plan with the DBA. If no database links are listed in the database and in the System Security Plan, this check is Not a Finding. If any database links are defined in the DBMS, verify the authorization for the definition in the System Security Plan. If any database links exist that are not authorized or not listed in the System Security Plan, this is a Finding.
Fix: F-58879r1_fix
Grant access to database links to authorized users or applications only. Document all database links access authorizations in the System Security Plan.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-025300
- Vuln IDs
-
- V-54041
- Rule IDs
-
- SV-68281r1_rule
Checks: C-54835r1_chk
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.
Fix: F-58883r1_fix
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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-025400
- Vuln IDs
-
- V-54043
- Rule IDs
-
- SV-68283r1_rule
Checks: C-54837r1_chk
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.
Fix: F-58885r1_fix
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 is 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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-025500
- Vuln IDs
-
- V-54045
- Rule IDs
-
- SV-68285r1_rule
Checks: C-54839r1_chk
If a review of the System Security Plan confirms the use of replication is not required, not permitted and the database is not configured for replication, this check is Not a Finding. If any replication accounts are assigned DBA roles or roles with DBA privileges, this is a Finding.
Fix: F-58887r1_fix
Restrict privileges assigned to replication accounts to the fewest possible privileges. Remove DBA roles from replication accounts. Create and use custom replication accounts assigned least privileges for supporting replication operations.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-025600
- Vuln IDs
-
- V-54047
- Rule IDs
-
- SV-68287r1_rule
Checks: C-54841r2_chk
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.
Fix: F-58889r1_fix
Configure the database listener to restrict access by IP address or set up an external device to restrict network access to the DBMS.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-025700
- Vuln IDs
-
- V-54049
- Rule IDs
-
- SV-68289r1_rule
Checks: C-54843r1_chk
Review application database tables and their database file assignments. If application database tables from unrelated applications are stored in the same database data files, this is a Finding.
Fix: F-58891r1_fix
Relocate application database tables to distinct database data files where supported by the DBMS.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-025800
- Vuln IDs
-
- V-54051
- Rule IDs
-
- SV-68291r1_rule
Checks: C-54845r1_chk
From SQL*Plus: select value from v$parameter where name = 'audit_sys_operations'; If the value returned is FALSE, this is a Finding.
Fix: F-58893r1_fix
From SQL*Plus: alter system set audit_sys_operations = TRUE scope = spfile; The above SQL*Plus command will set the parameter to take effect at next system startup.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-025900
- Vuln IDs
-
- V-54053
- Rule IDs
-
- SV-68293r1_rule
Checks: C-54847r1_chk
Review audit settings for disabling or locking account events based on event failures. If the settings are not configured to include the cause of the lock or disabling, this is a Finding.
Fix: F-58895r1_fix
Determine and implement audit settings that will collect and store the cause of any DBMS account or connection lock or disabling actions taken by the DBMS.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-026000
- Vuln IDs
-
- V-54055
- Rule IDs
-
- SV-68295r1_rule
Checks: C-54849r1_chk
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.
Fix: F-58897r1_fix
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.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-026100
- Vuln IDs
-
- V-54067
- Rule IDs
-
- SV-68307r1_rule
Checks: C-54851r1_chk
If Symmetric keys are present and Oracle Advanced Security is not installed and operational on the DBMS host, this is a Finding. If the symmetric key management procedures and configuration settings for the DBMS are not specified in the System Security Plan, this is a Finding. If the procedures are not followed with evidence for audit, this is a Finding. NOTE: This check does not include a review of the key management procedures for validity. Specific key management requirements may be covered under separate checks.
Fix: F-58909r1_fix
Symmetric and other encryption keys require the following: - protection from unauthorized access in transit and in storage - utilization of accepted algorithms - generation in accordance with required standards for the key's use - expiration date - continuity - key backup and recovery - key change - archival key storage (as necessary) Details for key management requirements are provided by FIPS 140-2 key management standards available from NIST. Oracle Advanced Security is required to provide symmetric key management features.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-026200
- Vuln IDs
-
- V-54069
- Rule IDs
-
- SV-68309r1_rule
Checks: C-54853r1_chk
If no data is identified as being sensitive or classified by the Information Owner, in the System Security Plan or in the AIS Functional Architecture documentation, this check is Not a Finding. If no identified sensitive or classified data requires encryption by the Information Owner in the System Security Plan and/or AIS Functional Architecture documentation, this check is Not a Finding. From SQL*Plus: select * from dba_sa_audit_options; If no records are returned or if output from the SQL statement above does not show classification labels being audited as required in the System Security Plan, this is a Finding.
Fix: F-58911r1_fix
Define the policy for auditing changes to security labels defined for the data. Document the audit requirements in the System Security Plan and configure database auditing in accordance with the policy.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-026300
- Vuln IDs
-
- V-54071
- Rule IDs
-
- SV-68311r1_rule
Checks: C-54855r1_chk
From SQL*Plus: select value from v$parameter where name = 'global_names'; If the value returned is FALSE, this is a Finding.
Fix: F-58913r1_fix
From SQL*Plus: alter system set global_names = TRUE scope = spfile; NOTE: This parameter, if changed, will affect all currently defined Oracle database links. The above SQL*Plus command will set the parameter to take effect at next system startup.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-026400
- Vuln IDs
-
- V-54073
- Rule IDs
-
- SV-68313r1_rule
Checks: C-54857r1_chk
From SQL*Plus: select value from v$parameter where name='diagnostic_dest'; On UNIX Systems: ls -ld [pathname] Substitute [pathname] with the directory path listed from the above SQL command. If permissions are granted for world access, this is a Finding. If any groups that include members other than the Oracle process and software owner accounts, DBAs, auditors, or backup accounts are listed, this is a Finding. On Windows Systems (From Windows Explorer): Browse to the directory specified. Select and right-click on the directory, select Properties, select the Security tab. If permissions are granted to everyone, this is a Finding. If any account other than the Oracle process and software owner accounts, Administrators, DBAs, System group or developers authorized to write and debug applications on this database are listed, this is a Finding.
Fix: F-58915r1_fix
Alter host system permissions to the DIAGNOSTIC_DEST directory to the Oracle process and software owner accounts, DBAs, SAs (if required) and developers or other users that may specifically require access for debugging or other purposes. Authorize and document user access requirements to the directory outside of the Oracle, DBA and SA account list.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-026500
- Vuln IDs
-
- V-54075
- Rule IDs
-
- SV-68315r1_rule
Checks: C-54859r1_chk
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.
Fix: F-58917r1_fix
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
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-026600
- Vuln IDs
-
- V-54077
- Rule IDs
-
- SV-68317r1_rule
Checks: C-54861r1_chk
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 = 10 If the parameter does not exist, this is a Finding. If the parameter is not set to a value of 10 or higher, this is a Finding. NOTE: It has been reported that the there is an Oracle bug (6051243) that prevents connections to the DBMS using JDBC THIN drivers when this parameter is set. The fix is available as patch 6779501.
Fix: F-58919r1_fix
Edit the SQLNET.ORA file to add or edit the entry: SQLNET.ALLOWED_LOGON_VERSION = 10 Set the value to 10 or higher (10 and 11 are currently valid values).
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- O112-BP-024300
- Vuln IDs
-
- V-54079
- Rule IDs
-
- SV-68319r1_rule
Checks: C-54863r1_chk
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.
Fix: F-58921r1_fix
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.