Database objects in an IDMS environment must be secured to prevent privileged actions from being performed by unauthorized users.

An XCCDF Rule

Description

<VulnDiscussion>If database objects like areas, schemas, and run units are not secured, they may be changed or deleted by unauthorized users.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>

ID: SV-251601r960960_rule
Severity: Medium
References: CCI-001499
Updated: 17 days ago

Before securing a database externally, it is VERY IMPORTANT to weigh the following considerations:
- If adding an SRTT TYPE=ENTRY that secures the DB resource type externally, it automatically secures a group of database resource types externally for all databases.

- If the SRTT contains one or more TYPE=OCCUR (occurrence overrides) that specify external security for resource type DB, also add an SRTT entry specifying external resource class and external resource name for each of the database resource types that are automatically secured externally for the database being secured in that TYPE=OCCUR statement.

- The only database-related RESTYPE valid with TYPE=OCCUR is DB.
See the IDMS Techdocs for more information on securing database resources.

The SRTT module must have an entry coded to secure one or more database resources. For instance:

 #SECRTT TYPE=INITIAL,                         x
  ENVNAME=SYS001

 #SECRTT TYPE=ENTRY,                           X
   RESTYPE=DB,                                           X
   SECBY=OFF,                                              X
   EXTNAME=(ENVIR,RESNAME,RESTYPE),     X
   EXTCLS='CA@IDMS'
 
 #SECRTT TYPE=OCCUR,                         X
   RESTYPE=DB,                                           X
   SECBY=EXTERNAL ,                                X
   RESNAME='PROD'

The above example could be used to secure external name of SYS001.PROD.DB.

When securing SQL access, it is necessary to secure both the DBNAME containing the catalog segment (probably SYSSQL in APPLDICT) and the database being accessed.

 #SECRTT  TYPE=OCCUR,SECBY=EXT,RESTYPE=DB,  X
    RESNAME=APPLDICT'
#SECRTT  TYPE=OCCUR,SECBY=EXT,RESTYPE=DB,  X
    RESNAME='USERDB'

Because the above example also secures the DB subtypes, add SRTT entries to allow the ability to grant or deny access to them:

 #SECRTT TYPE=ENTRY,RESTYPE=AREA,    X
     SECBY=EXT,EXTNAME=(ENVIR,RESTYPE,RESNAME)
 #SECRTT TYPE=ENTRY,RESTYPE=NRU,     X
     SECBY=EXT,EXTNAME=(ENVIR,RESTYPE,RESNAME)
 #SECRTT TYPE=ENTRY,RESTYPE=QSCH,    X
     SECBY=EXT,EXTNAME=(ENVIR,RESTYPE,RESNAME)
 #SECRTT TYPE=ENTRY,RESTYPE=NSCH,    X
     SECBY=EXT,EXTNAME=(ENVIR,RESTYPE,RESNAME)
 #SECRTT TYPE=ENTRY,RESTYPE=DACC,    X
     SECBY=EXT,EXTNAME=(ENVIR,RESTYPE,RESNAME)
 #SECRTT TYPE=ENTRY,RESTYPE=TABL,    X
     SECBY=EXT,EXTNAME=(ENVIR,RESTYPE,RESNAME)

Note that the TABL resource type represents base tables, functions, procedures, table procedures, and views. 

Ensure that the ESM has a corresponding entry to give access to the desired users. For instance, in Top Secret:
TSS PER(user_id) CA@IDMS(SYS001.PROD.DB) ACCESS(access_level)
and assuming that the user wants to grant access to the area:
TSS PER(user_id) CA@IDMS(SYS001.PROD.AREA) ACCESS(access_level)

Database objects in an IDMS environment must be secured to prevent privileged actions from being performed by unauthorized users.

Description

Remediation - Manual Procedure