STIGhubSTIGhub
STIGsSearchCompare

STIGhub

A free tool to search and browse the entire DISA STIG library. Saves up to 75% in security compliance research time.

Navigation

  • Browse STIGs
  • Search
  • Compare Versions

Resources

  • About
  • Release Notes
  • VPAT
  • DISA STIG Library
STIGs updated 3 hours ago
Powered by Pylon
© 2026 Beacon Cloud Solutions, Inc. All rights reserved.
← Back to CA IDMS Security Technical Implementation Guide

V-251604

CAT II (Medium)

Databases must be secured to protect from structural changes.

Rule ID

SV-251604r960960_rule

STIG

CA IDMS Security Technical Implementation Guide

Version

V2R1

CCIs

CCI-001499, CCI-001813

Discussion

Database objects, like areas and run units, can be changed or deleted if not protected. Steps must be taken to secure these objects via the external security manager (ESM). Satisfies: SRG-APP-000133-DB-000362, SRG-APP-000380-DB-000360

Check Content

All database objects to be secured must be specified to the CA IDMS centralized security in the security resource type table (SRTT) as being secured externally.

Log on to a DC system in the security domain. 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.

Check each entry in the SRTT. If the resource type is DB, AREA, NRU, QSCH, NSCH, TABL, DACC, SACC, DMCL, or DBTB, the resource type is a database object. If it contains SECBY=INTERNAL, this is a finding. 

If any of the database types are not found in the SRTT, this is a finding.

For SQL access, check that both the catalog and user database are secured in the SRTT. If not, this is a finding.

If batch jobs are allowed to be run which access an IDMS database, check whether the access is covered by standard ESM dataset security and/or the user-written exit 14 (issues a security check at BIND/READY time). If not, this is a finding.
                                                     
If the ESM definition is correct but the role(s)/groups(s) are not defined correctly to give the appropriate permissions, this is a finding.

Fix Text

Secure database object resources not found in SECRTT or found to be secured internally, through the ESM chosen by the organization (e.g., TSS, ACF 2, RACF).

Users, groups, roles, etc., are defined to the ESM, and it is here where the authorization for ownership is determined.

Once externally secured, create or modify the #SECRTT entries specify TYPE=ENTRY and TYPE=OCCURRENCE for the database resource type with the parameter of SECBY=EXTERNAL.

Use the RESTYPE DB which implicitly includes the subtypes AREA, NRU, QSCH, NSCH, TABL, DACC, and SACC. For each subtype, an entry must be added. The restypes for database tables and DMCLs are DBTB and DMCL, respectively.  

For SQL access, include #SECRTT RESTYPE=DB for  both the catalog and user database through all dbname and segment names that can access the catalog and database.                                                                                                                               

For batch jobs that access database objects, use the ESM standard dataset security and/or the user-written exit 14 to secure the database objects.

Create the corresponding entry in the ESM and give appropriate permissions to role(s)/ group(s) to allow database changes by appropriate users (usually DBAs).