Data Set Protection

Protecting Resources › Data Set Protection

Data Set Protection

Data sets must be owned before being authorized.

To protect a data set

Enter the command:
```
TSS CREATE|ADDTO(acid) DSNAME(name)
```
Ownership of the data set is established.
Enter the command:
```
TSS PERMIT(acid) DSNAME(name)
```
The data set is protected.

Another option is to bypass data set level security checking entirely and depend on volume level security checking.

Data Set Ownership Removal

To remove ownership of a data set

Revoke all permissions for the resource. Do not specify an access level or the command will fail.
Remove ownership of the data set

Example: remove ownership

This example revokes permission and then removes ownership of a dataset.

TSS REVOKE(USER01) DSNAME(PAYROLL.)

TSS REMOVE(DEPT01) DSNAME(PAYROLL.)

Automatic Data Set Protection

Use the ADSP control option to automatically set the security bit for newly created data sets in a non‑Alwayscall environment. A data set with the security bit set on can only be accessed when a security product is installed.

The values you can assign to the ADSP control option are:

ADSP(YES)

(Default) Turns on the security bit for all data sets that are created by a defined user. This option takes effect in all modes except DORMANT.

ADSP(ALL)

Turns on the security bit for all data sets created by all users in all modes.

ADSP(NO)

Tells CA Top Secret not to turn on the security bits for newly created data sets. SAF environments where no pre‑ICF VSAM catalogs are present should use ADSP(NO).

You can use the NOADSP attribute to override the ADSP control option for individual users.

In a non‑Alwayscall environment it is generally best to set ADSP(ALL) to prevent undefined users from being able to create data sets anywhere and then access them without security checking.

Example: automatic data set protection

This example tells CA Top Secret that any new data set owned by SYSPAGE will not automatically have its security bit turned on regardless of how the ADSP control option is set.

TSS ADDTO(SYSPAGE) NOADSP

Extend Default Protection

CA Top Secret provides default protection of data sets in FAIL mode. Default protection extends security protection to a data set even if it has not yet been defined to CA Top Secret. A security violation occurs if a request is made to access any unowned data set.

Example: extend default protection

This example extends default protection to data sets in IMPLEMENT and WARN modes by attaching the DEFPROT attribute to the resource class named DATASET:

TSS REPLACE(RDT) RESCLASS(DATASET)
                 ATTR(DEFPROT)

When accessing any CA Top Secret files (for example the security file, backup security file, ATF file, ATF2 file, and recovery file) MODE is forced to FAIL and an AUDIT event is forced.

Recommendations

In IMPLEMENT mode give data sets default protection. This preserves the concept of using IMPLEMENT mode to bring an installation under the CA Top Secret umbrella in controlled phases.

In a non‑Alwayscall environment set ADSP(ALL) to prevent undefined users from creating data sets anywhere and then access them without security checking.

Generic Prefixing

Data set ownership is typically designated by installation default using generic prefixes. Once a prefix is owned, any data set beginning with that prefix is protected and must be permitted to other ACIDs.

Example: generic prefixing

This example gives ownership of system data sets that begin with the prefixes SYS or IPO to the ACID SYSGROUP:

TSS ADDTO(SYSGROUP) DSNAME(SYS,IPO)

Data Set Masking

Masking can group data sets whose names share similar characteristics. These shared patterns can then be used as the operands of the DSNAME parameter in TSS entries.

A masked data set name is treated by CA Top Secret like a generic prefix. Any data set that begins with a mask is considered a match by the security validation algorithm, and the associated access authorizations are honored. You can add a resource name containing a mask only if the name begins with a masking character.

Masking characters cannot be used within the owned portion of the DSNAME. For example, if TSS ADDTO(dept01) DSNAME(abc.xyz) is issued to establish ownership for data set abc.xyz, then TSS PERMIT(acid) DSNAME(abc.x*) is not valid.

Examples: data set masking

This example masks data sets with bc and yz:

TSS ADDTO(dept01) DSNAME(+bc.+yz)

Data Set Access Authorization

You can allow designated users to access data sets in an unlimited or a restricted manner. To specify a particular data set, place single quotes around the full data set name.

Examples: data set access authorization

This example allows USER01 to read data sets beginning with the qualifier PAYROLL. through the Batch facility:

TSS PERMIT(USER01) DSNAME(PAYROLL.)
                   ACCESS(READ)
                   FACILITY(BATCH)

This example authorizes USER01 to have complete access to the data set TNT.LIB.CNTL.BOOM.

TSS PERMIT(USER01) DSNAME('TNT.LIB.CNTL.BOOM')
                   ACCESS(ALL)

Data Set Access Levels

Access levels are assigned using the ACCESS parameter. The access levels that can be specified for data sets (VSAM and non‑VSAM) are:

ALL: Data set can be accessed in any way.
CONTROL: VSAM data set can be used for control interval update processing (for example, for an IDCAMS VERIFY function). VSAM data set that had a control password can be used.
CREATE: Data set can be created.
FETCH: Programs from the data set (library) can only be executed, not read.
NONE: Data set cannot be used in any way.
UPDATE: Data set can be updated; READ and WRITE access is implied. This access level is needed to perform a restore of the data set.
READ: (Default) Data sets can be read (opened for input). READ implies FETCH. This access level is needed to perform a backup of the data set.
SCRATCH: Data set can be scratched.
WRITE: Data can only be written into the data set (opened for output).

If the CA Top Secret validation algorithm detects two data set name permissions of equal length, it selects the first permission with a PERMIT access level of NONE (if such a permission exists). Otherwise, the first PERMIT with any access level is selected.

Example: assign an access level

This example authorizes USER01 to update any data set that matches the masked prefix SAL*M.

TSS PERMIT(USER01) DSNAME(SAL*M)
                   ACCESS(UPDATE)

Required Access Levels

A user must have the following minimum access levels to rename a data set:

READ and SCRATCH for the old data set name
WRITE and CREATE for the new data set name

To access VSAM data sets the access level required corresponds to the previous password level for the catalog:

READ access when READ password was used
UPDATE access when UPDATE password was used
ALL access when MASTER password was used

To create a data set, the ACID must meet one of these conditions:

Own the volume.
Possess CREATE (or ALL) access at both the volume and data set level.
CA Top Secret cannot prevent undefined users from creating data sets in a z/OS environment that is non‑Alwayscall except in FAIL mode. z/OS does not recognize CA Top Secret modes and z/OS controls new data set creation for defined users only.
Possess CREATE and CONTROL at the volume level.

Program Pathing

Program pathing restricts access to sensitive data to designated programs. Program pathing:

Restricts production control personnel from accessing inappropriate data without keeping them from performing their regular functions.
Blocks unwanted exposure introduced by CA‑Panvalet. For example, always opening programs for UPDATE access even if only READ access is needed. Using program pathing, you can force access to the data set through a program that only has the ability to read it.

Example: program pathing

This example authorizes USER01 to read data sets whose highest level qualifiers are SALPAY.MASTER, but only through program APUPDATE when running in the Batch facility:

TSS PERMIT(USER01) DSNAME(SALPAY.MASTER)
                   PRIVPGM(APUPDATE)
                   FACILITY(BATCH)

If APUPDATE is protected, the following PERMIT is required:

TSS PERMIT(USER01) PROGRAM(APUPDATE)

Load Library Pathing

You can force a designated program to be loaded from a specific library. The library is specified as a job or step library, or can also be a task library (for example, like that used with the TSO CALL command). Then, if the privileged library is not used as the load library, the access request is failed.

Load library pathing is implemented using the LIBRARY parameter.

Examples: load library pathing

In these examples, USER01 is restricted to FETCH access to the SALPAY.BKUP load library data set:

TSS PERMIT(USER01) DSNAME(SALPAY.MASTER)
                   PRIVPGM(APUPDATE)
                   LIBRARY('SALPAY.BKUP')
                   FACILITY(BATCH)

TSS PERMIT(USER01) PROGRAM(APUPDATE)

TSS PERMIT(USER01) DSNAME('SALPAY.BKUP')
                   ACCESS(FETCH)

If a library is not specified, the privileged program must reside in LINKLIST.

Access to all Data Sets

To allow users access to all data sets use the variable character substitution mask DSNAME(*****)

Assign ownership of the mask to the MSCA
Use the mask in a PERMIT statement

The advantages to using this approach rather than the NODSNCHK attribute to bypass data set level security checking are:

All the restrictions available to the PERMIT command function (such as time of day and privileged program pathing) can also be specified
You have the option of granting a less powerful access level, such as READ or SCRATCH
A TSS WHOHAS DSNAME(*****) can be used to find which users have access to all data sets
Data set auditing will take place if ACTION(AUDIT) is specified for the ACID or the data set being accessed is in the Audit Record

Example: access all data sets

This example assigns ALL access to bypass data set level security giving USER01 complete access to any data set.

TSS ADDTO(MSCA) DSNAME(*****)

TSS PERMIT(USER01) DSNAME(*****)
                   ACCESS(ALL)

Resource class DATASET is a synonym for resource class DSNAME. These examples are equivalent:

TSS PER(ACID) DATASET(ABC)
              ACC(READ)

TSS PER(ACID) DSNAME(ABC)
              ACC(READ)

Data Set Level Security Bypass

To bypass all data set level security attach the NODSNCHK attribute to an ACID or profile. Volume level security checking is still in effect and auditing still occurs. Restrict NODSNCHK to special products that must access many data sets. For example DASD space managers.

Example: bypass data set level security

This example uses NODSNCHK to bypass data level security

TSS ADDTO(SUPRACID) NODSNCHK

Data Set Checking From the Volume Bypass

To bypass data set level security checking attach the keyword ACTION(NODSN) to a PERMIT for a volume.

Forced Data Set Password Check

Unless specifically turned on, z/OS data set passwords are ignored by CA Top Secret. To return control to z/OS password checking after the CA Top Secret validation process has completed add the ACTION(PASSWORD) parameter to your PERMIT statement.

Access to the data set must be granted by the security validation process before this feature is triggered.

To use this feature:

The data set must be a DASD data set. This feature does not apply to VSAM data sets or to any data set check that occurs by allocating an SMS‑managed data set.
The data set must be password protected using O/S utilities.
The data set must not have its RACF security bit indicator set.
You must be running a SAF/Alwayscall environment.

Example: force data set password checking

This example determines if USER01 is allowed to access a PAY.SALES data set, then automatically returns control to z/OS password checking:

TSS PERMIT(USER01) DSNAME(PAY.SALES)
                   ACTION(PASSWORD,FAIL)
                   ACCESS(access level)

Forced Password Checking for All Data Sets

The MSCA must own the DSNAME(*****) mask to use this feature.

To force password checking for all data sets, enter the command:

TSS PERMIT(ALL) DSNAME(*****)
                ACTION(PASSWORD)
                ACCESS(access level)

Secure Catalogs

CA Top Secret provides security protection for:

ICF catalogs
VSAM (ICF) catalogs
VSAM (non‑ICF) catalogs

You can use prefixing when authorizing access to catalogs.

Important! Catalog management always passes the VOLSER of the catalog and not that of the data set being created. Volume authorization should be based on the catalog's volume and not the data set's volume.

Example: implement catalog security

This example gives USER01 READ and CONTROL access to the data sets in the VSAM catalogs prefixed with USERCAT.

Enter the command:
```
TSS ADDTO(SYSDEPT) DSNAME(USERCAT.)
```
The catalog is assigned an owner.

Enter the command:

TSS PERMIT(USER01) DSNAME(USERCAT.)
                   ACCESS(READ,CONTROL)

Access is authorized to the secured catalog.

Assign Catalog Management Access Levels

Catalog management processing first calls CA Top Secret to validate access to the catalog itself. If the user has sufficient catalog access authority to perform the requested operation the specific authorization for the data set examined.

It is recommended that UPDATE access is only permitted to those user catalogs that the specific user will use. ALL access to those catalogs should be restricted to ACIDs who need to create or delete catalogs.

ALL access to a catalog may cause the operating system catalog management routines to bypass dataset checking. It should only be allowed on a very restricted basis.

To create a new entry, the user must have:

UPDATE access to the user catalog
READ access to the master catalog
CREATE access to the catalog volume

To delete a non‑VSAM entry, the user must have:

READ access to the master catalog
UPDATE access to the user catalog
SCRATCH or ALL access to the data set
SCRATCH access to the volume

For information on the required access levels for access method services functions, see the IBM manual Access Method Services for the Integrated Catalog Facility.

ICF Catalogs

ICF catalogs and the data sets within them are protected when they are defined to CA Top Secret. Because ICF uses z/OS Alwayscall logic, it is not necessary to run the TSSPROT utility against these catalogs. Once the catalog is defined to CA Top Secret, password protection in all modes is not enforced. All security checking is done through CA Top Secret.

Forced Catalog Password Protection

You can protect passwords on a data set, data set prefix or mask in WARN and IMPLEMENT mode.

Example: force catalog password protection

This example forces catalog password protection and CA Top Secret protection to be used for the ACID specified:

TSS PERMIT(acid) DSNAME(ICF.)
                 ACCESS(UPDATE)
                 ACTION(FAIL,PASSWORD)

Secure VSAM (Non-ICF) Catalogs

To protect VSAM catalogs in a z/OS non‑Alwayscall environment:

Set the security bit for the catalog.
Define the catalog to CA Top Secret.
All VSAM catalogs are defined to CA Top Secret using their actual data set names; prefixes can also be used.
Protect the VSAM catalogs by running the TSSPROT utility.

The TSSPROT Utility

The TSSPROT utility is used to secure z/OS and data sets only in an SU‑32 (non‑SAF) environment. A secured data set is one that has a RACF security indicator turned on. Both VSAM and non‑VSAM data sets can be processed. Only the MSCA can use this utility.

To get VSAM protection, the catalog must be protected using TSSPROT. z/OS does not recognize individual data set protection if the associated catalog is not secured.

For information on the JCL for executing TSSPROT and the verbs and options used to construct the control statement, see the Report and Tracking Guide.

If your system operates under an z/OS Alwayscall environment, you do not need to use the TSSPROT utility.

Examples: TSSPROT

This example secures all non‑VSAM data sets starting with the prefix PAY on all PRODxx volumes:

PROTECT D(PAY) VOLUME(PROD) UNIT(3380)

This example secures a VSAM user catalog:

PROTECT DSNAME(PROD.VSAMCATA) CATAPE(PROD.VSAMCATA)

This example secures all VSAM data sets cataloged in a user catalog:

PROTECT CATAPE(PROD.VSAMCATA)

This example protects all DASD data sets on all online DASD volumes, including password‑protected data sets (in FAIL mode):

P PASSWORD(PROTECT)

This example simulates protection of all accessible non‑VSAM DASD data sets:

PROTECT SIM