STIGViewer Support

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

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-251599IDMS-DB-000190SV-251599r960879_ruleCCI-000169high
Description
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.
STIGDate
CA IDMS Security Technical Implementation Guide2024-09-13

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (15) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

END-01Endpoint Device Management (EDM)
1.00
END-04Malicious Code Protection (Anti-Malware)
1.00
END-06Endpoint File Integrity Monitoring (FIM)
1.00
MON-01Continuous Monitoring
1.00
MON-01.1Intrusion Detection & Prevention Systems (IDS & IPS)
1.00
MON-01.3Inbound & Outbound Communications Traffic
1.00
MON-01.4System Generated Alerts
1.00
MON-01.7File Integrity Monitoring (FIM)
1.00
MON-01.8Security Event Monitoring
1.00
MON-03Content of Event Logs
1.00

+5 more (top 10 by confidence shown)

NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (57) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-16Security and Privacy Attributes
1.00
AC-17(1)Monitoring and Control
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(11)Usage Conditions
1.00
AC-2(3)Disable Accounts
1.00
AC-2(4)Automated Audit Actions
1.00
AC-3Access Enforcement
1.00
AC-3(3)Mandatory Access Control
1.00
AC-6(9)Log Use of Privileged Functions
1.00
AC-7Unsuccessful Logon Attempts
1.00

+47 more (top 10 by confidence shown)

NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.3.1
1.00
3.3.2
1.00
CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (4) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

Who does this work

12 NICE work roles and 9 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-251599r960879_chk)

Examine load module RHDCSRTT by executing CA IDMS utility IDMSSRTD or by issuing command "DCMT DISPLAY SRTT" while signed onto 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 (F-54988r858837_fix)

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. Then confirm that the resource types are referenced appropriately by the external security manager.