Previous Topic: DFSMSdfpNext Topic: CA Examine


CA Top Secret

The following is supported when MLS is active on an CA Top Secret system:

Restrictions

If you are running any of the following software, it must meet the following minimum requirements to run concurrently with CA Top Secret:

If your site shares DASD, the following restrictions apply:

Configuration Checklist

This checklist describes the software configuration requirements when MLS is active on an CA Top Secret system.

Requirement

Complete

Provide DAC controls

Control options

DAC control mechanisms

Resource rules

Provide accountability controls

Do not use UADS

Identify all system users to CA Top Secret

Do not reuse acids

Define required acids

Identify users with special privileges

Specify PSWD control options

Provide MLS controls

Define the MLS control options

Define MLS SECLEVEL Records

Define MLS CATEGORY Records

Define MLS SECLABEL Records

Assign Security Labels to Users

Assign Security Labels to Objects

Assign Security Labels to DB2 Objects

Protect object reuse

DAC Control Mechanisms

CA Top Secret provides several mechanisms to achieve DAC controls. Global control options establish site options for your CA Top Secret system. The security administrator must ensure that the system provides controlled access to data sets using ownership and permissions.

Providing Accountability Controls

This section describes the following identification and authentication controls that you should configure in an MLS system:

Do Not Use UADS

If your site is currently using UADS, CA Top Secret provides a conversion utility.

Identifying All System Users

A security administrator must create a unique acid record for each system user. The account manager assigns various privileges to each user based on the tasks the user must perform.

Do Not Reuse Acids

Acids should never be reissued to different people. When this is done, it makes it very difficult to determine from security logs who the person responsible for an action was and it then becomes necessary to keep a log of who owned each acid at various times. This is error-prone, and can be avoided by simply not reissuing acids.

Defining Required Acids

You should define the following CA Top Secret acids that are used by system-started tasks: INIT, JES2 or JES3, LLA, VLF and other system address spaces.

In addition, you should assign security label, SYSHIGH, to each of these acids by adding the seclabel to the acid record.

Providing MLS Controls

This section describes the required settings of the following MLS records:

Defining the MLS Control Options

This section describes the ML control option field settings that the security administrator should select to fully implement an MLS system.

MLMODE(FAIL) causes CA Top Secret to deny any accesses that would violate the MAC simple security and confinement properties.

Defining MLS SECLEVEL Records

The security administrator should create MLS SECLEVEL records for all security levels the site wants to use. The security administrator must specify a unique level number for each SECLEVEL record.

To define a security level with a value of 50 and the descriptive name SECRET, enter:

TSS ADD(mls) SECLEVEL(50)
             LVLNAME(secret)

Defining MLS CATEGORY Records

The security administrator should create MLS CATEGORY records for all categories the site wants to use, if any. (Categories are optional in an MLS system.) The security administrator must specify a unique name for each CATEGORY record.

Examples

To define a category with a value of HUMANRESOURCES, enter:

TSS ADD(mls) category(humanresources)

Defining MLS SECLABEL Records

The security administrator should create SECLABEL records for all the security labels the site wants to use. Security labels, SYSHIGH, SYSLOW, SYSMULTI, and SYSNONE, are already provided with the system and do not need to be defined. The security administrator must specify a unique name for each SECLABEL record.

Examples

To define a security label with a security level of 50 and the category HUMANRESOURCES, enter:

TSS ADD(mls) SECLABEL(labela)
             SECLEVEL(50)
            CATEGORY(humanresources)

Assigning Security Labels to Users

One or more security labels and a default security label may be added to users. The security administrator should create add these fields to users who need access to data or resources that are classified with security labels. The security administrator should also delegate the privilege to reclassify data sets to any users who need this capability.

Example

To assign the security label LABELA to the DB2 table resource TEST.QEWRQER.ASDF.TESTCOLUMN3, issue the following commands:

TSS ADD(mls) DB2TABLE(test.qewrqer.asdf.testcolumn3)
             SECLABEL(labela)

Assigning Security Labels to DB2 Objects

DB2 resources may be protected with security labels The security administrator should create MLS resource records for any DB2 resources that are deemed sensitive in an organization, that if left unprotected, might result in data disclosure or declassification.

Examples

To assign the security label LABELA to the CICS transaction CEMT, enter:

TSS ADD(mls) OTRAN(cemt)
             SECLABEL(labela)

To assign the security label SYSHIGH to the SYS1.MANx data sets, enter:

TSS ADD(mls) DSN(sys1.man)
             SECLABEL(syshigh)