What changed in CA IDMS STIG V2R2V2R2 changes

Title

IDMS must use the ESM to generate auditable records for resources when DoOD-defined auditable events occur.

Severity

highmedium

Check text

Examine load module RHDCSRTT by executing CA IDMS utility IDMSSRTD or by issuing command "DCMT DISPLAY SRTT" while signed ontoon to the CV and reviewing the output. Note: This requires PTFs SO07995 and SO09476. If the ESM specification does not match the RHDCSRTT entry, this is a finding. Validate each of the following listed entries: Access Actions such as login - Resource type SGON Privileged system access - Resource types SYST, DB, DMCL, DBTB Privileged object access - Resource types SLOD, SACC, QUEU Privileged program access - Resource type TASK, SPGM If any are not secured externally, this is a finding.

Fix text

If some of the resource types were not defined to the #SECRTT with SECBY=EXTERNAL, update the #SECRTT security module to include the appropriate definitions. Access Actions such as login - Resource type SGON Privileged system access - Resource types SYST, DB, DMCL, DBTB Privileged object access - Resource types SLOD, SACC, QUEU Privileged program access - Resource type TASK, SPGM To update the #SECRTT entries, change any invalid definitions of SECBY=INTERNAL to SECBY=EXTERNAL for the resources listed above. If any of the resource types are missing, add them. Once the updates are complete, recompile the RHDCSRTT module. ThenConfirm confirm that the resource types are referenced appropriately by the external security manager.

Discussion

Audit records provide a tool to help research events within IDMS. IDMS does not produce audit records, but when using external security, records can be produced through the ESM. IDMS relies on the ESM to log organization-defined auditable events. To ensure that all secure actions are logged, those actions must be defined to the IDMS Security Resource Type Table (SRTT) with a type of external security. When IDMS has to perform a given security check, it will defer to the ESM to determine the user's authorization. The auditing functionality of the ESM can be used to track the IDMS security calls. Some organization-defined auditable events are expected to be handled solely by the ESM. This would include requirements such as "successful and unsuccessful attempts to modify or delete privileges, security objects, security levels, or categories of information" as well as "account creation, modification, disablement, or termination." For the audit logging of other organization-defined auditable events, IDMS requires RHDCSRTT security module set up to route requests for these events through the ESM. This will ensure that they are audited appropriately. The following resource types must be defined with SECBY type of EXTERNAL in the RHDCSRTT load module to achieve the appropriate level of audit logging. If there is not a resource type definition with a security type of EXTERNAL for the following resources, this is a finding.

V-251599 in V2R2

Title

CA IDMS must implement NIST FIPS 140-23 validated cryptographic modules to protect data- in- transit.

Check text

Verify that connection to IDMS is FIPS- compliant. 1. For ODBC and JDBC Type 2 connections: a. Configure the Data Source to enable the DTS-JCLI logging option. b. Perform a connection test using the "Test" function on the administrator. c. View the generated log entries to determine the TLS version, cipher algorithm, and certificate employed. 2020/04/27 09:51:41.946 P:0000502C T:00005DC8 JCLI Trace: SSL_connect(832) successful! 2020/04/27 09:51:41.946 P:0000502C T:00005DC8 JCLI Trace: SSL_connect(832) connection attempts: 1 2020/04/27 09:51:41.947 P:0000502C T:00005DC8 JCLI Trace: SSL_connect(832) TLS version TLSv1.2 2020/04/27 09:51:41.947 P:0000502C T:00005DC8 JCLI Trace: SSL_connect(832) cipher TLS_RSA_WITH_AES_256_CBC_SHA256 (this should be one or more of the accepted ciphers) Cipher Specifications 3DES_SHAWhat TLS cipher suites are allowed in the FIPS 140-3 standard? AES_256_SHAThe following suites are allowed for the TLS 1.3 protocol: AES_128_SHATLS_AES_128_GCM_SHA256 IfTLS_AES_256_GCM_SHA384 The connectionfollowing suites are allowed for the TLS 1.2 protocol: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 Connection is not verified this is a finding. 2. For all connection types: IBM provides configuration options for multiple SSL components, to force FIPS-140 compliance. a. System SSL: The environment variable GSK_FIPS_STATE specifies GSK_FIPS_STATE_ON in the envar file in the GSKSRVR home directory or message "GSK01057I SSL server starting in FIPS mode" is in the JES log. b. ICFS: Review the JES log for the ICSF region forto verify the following message is issued on startup: CSFM015I FIPS 140 SELF CHECKS FOR PKCS11 SERVICES SUCCESSFUL. If either of the above is true, this is not a finding. If none of the above is true, this is a finding.

Fix text

Contact the appropriate system administrators to make the needed changes to allow the use of AT-TLS and the associated software. See Refer to Broadcom Techdocs for further information on: - ConfigureConfiguring Secure Sockets. See Refer to IBM's z/OS Communications Server bookshelf for information on: - Configuring AT-TLS. See Refer to IBM's z/OS Cryptographic Services System bookshelf for information on: - Algorithms and key sizes. - System SSL . - ICSF Services.

Discussion

Use of weak or untested encryption algorithms undermines the purposes of utilizingusing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. ItThe is the responsibility of the data owner tois assessresponsible for assessing the cryptography requirements in light of applicable federal laws, Executive Orders, directives, policies, regulations, and standards. For detailed information, refer to NIST FIPS Publication 140-23, Security Requirements for Cryptographic Modules. Note that the product's cryptographic modules must be validated and certified by NIST as FIPS- compliant.

V-251656 in V2R2