Using IBM zSecure Command Verifier to Achieve Compliance

I am often asked why we can’t grant granular access to specific RACF commands. Have you ever been asked why you can’t place restrictions upon a powerful system SPECIAL UserID? Compliance problems like these can be solved by IBM Security zSecure Command Verifier. Command Verifier is a software product that is a part of the IBM Security zSecure software suite, which offers granular control over RACF commands.

SUBHEAD: How zSecure Command Verifier Works

As a part of installing IBM Security zSecure Command Verifier IRREVX01 (the RACF common command dynamic exit point) will be installed. Using IRREVX01 allows zSecure to intercept most RACF commands both before and after RACF has control of the command. There is a lot of flexibility in how to slice and dice RACF commands. Command Verifier can block a RACF command completely, modify a RACF command and send it away without the command issuer being any wiser, or grant very granular authority to RACF commands beyond what is offered by native RACF.

Out of the box, the XFACILIT general resource class is used and, by defining profiles that start with C4R, an additional layer of security is then enforced upon RACF commands. The ability to tightly control RACF commands back into RACF itself is abstracted. Optionally, a usermod can be put in to define a general resource class, if desired. Note the following RACF commands are not eligible for use via IRREVX01: RVARY, RACLINK, RACDCERT, RACPRIV or RACMAP, meaning you cannot control them via the IRREVX01 exit point per RACF’s design.

SUBHEAD: An Improved Audit Trail

I‘m often asked, “Who last changed this UserID?” to which I always respond, “When do you think the change happened?” Randomly searching through SMF records can be a painstaking or impossible task. This problem is now solved by the Command Verifier Audit Trail feature. The trail is enabled using profiles in the XFACILIT class as follows:

C4R.class.=CMDAUD.=SEGMENT.profile-identification

C4R.class.=CMDAUD.=ATTR.profile-identification

C4R.class.=CMDAUD.=CONNECT.profile-identification

C4R.class.=CMDAUD.=ACL.profile-identification

C4R.class.=CMDAUD.=MEMBER.profile-identification

C4R.class.=CMDAUD.=MAINT.profile-identification

You can get an audit trail with Julian date and time stamp for segment changes, UserID attributes, group connects, access control list changes and grouping class members. These changes can be tracked very granularly by class and for specific profiles. Or, if you wish to track everything, build the profiles with a UACC of NONE, as:

C4R.*.=CMDAUD.=SEGMENT.**

C4R.*.=CMDAUD.=ATTR.**

C4R.*.=CMDAUD.=CONNECT.**

C4R.*.=CMDAUD.=ACL.**

C4R.*.=CMDAUD.=MEMBER.**

The access level to these profiles has no meaning. If these profiles exist, then the audit trail is logged to USRDATA fields back into the RACF database. I recommend setting the UACC to NONE because read, update, control, alter, etc., do nothing and will raise questions by auditors.

SUBHEAD: Maintaining and Viewing the Audit Trail

Now that you have told zSecure to record an audit trail, here’s how you view and secure it.

  • Define C4R.*.=CMDAUD.=MAINT.** UACC(NONE) to the XFACILIT class
    • This RACF profile secures the ability to view and delete the command verifier audit trail entries.
    • READ access allows the audit trail to be appended to native RACF list commands automatically.
    • UPDATE access allows listing of the audit trail using the C4RCATMN command.
    • CONTROL access allows deleting of command audit trail entries with the C4RCATMN command. So PERMIT CONTROL access with extreme care.
  • SAF checks use this resource format:
    • class.=CMDAUD.=MAINT.profile-identification
    • So you could define all sorts of access lists to control viewing the command audit trail based upon class and profile name if desired.
  • Finally, you need to define these profiles in the XFACILIT class:
    • USRDATA.*.XFACILIT.**
    • USRDATA.*.GXFACILI.**

These profiles will protect against someone issuing a zSecure CKGRACF command to wipe out the USRDATA fields used by command verifier. PERMIT UPDATE access with to these profiles with extreme care; they can generate a command via zSecure Admin to erase the USRDATA fields from the RACF database.

SUBHEAD: Policy Profiles

There are many types of policy profiles that, when set up, will block or limit who can issue RACF commands and set mandatory or default values, meaning the command issuer might not be aware the RACF command changed. Beyond this article, read more in the zSecure Command Verifier User Guide.

It is a comprehensive document that you will refer to regularly when designing zSecure Command Verifier policy profiles. Policy profiles will often contain special keywords with / or = in the third qualifier. These profiles often enforce default or mandatory values. It is key to always remember such policy profiles cannot be covered by a best match generic profile; the third qualifier must always be explicitly specified when it starts with / or =.

SUBHEAD: Controlling RACF System SPECIAL, OPERATIONS and AUDITOR Attributes

Once the following profiles are defined in class XFACILIT with UACC(NONE):

C4R.USER.ATTR.SPECIAL.**

C4R.USER.ATTR.OPERATIONS.**

C4R.USER.ATTR.AUDITOR.**

READ access allows using the NOSPECIAL, NOOPERTIONS or NOAUDITOR keywords in an ADDUSER or ALTUSER command.

UPDATE access adds using the SPECIAL, OPERATIONS, or AUDTOR keywords in an ADDUSER or ALTUSER command.

While I have used the ** at the end, each of these profiles have two additional qualifiers. For example, C4R.USER.ATTR.SPECIAL.owner.userid meaning you could set up granular policies about who can grant or remove system SPECIAL based around UserID naming and ownership. You have ensured that only authorized personnel can grant security authorities to make changes to security or access all data on the system. Multiple regulatory standards require tight control of such access.

SUBHEAD: Preventing Changes to RACF Profiles: No-Change Policy

The ability to lock down a RACF profile so no one can modify it except users in a C4R access list in the XFACILIT class is referred to as a no-change policy. The profiles take the following two styles:

C4R.DATASET.=NOCHANGE.dsname       APPLDATA(‘LEVEL=99’)

C4R.class.=NOCHANGE.profile               APPLDATA(‘LEVEL=99’)

Note that the =NOCHANGE can’t be covered by a generic. It must be specified fully as listed above in the third qualifier or this type of control won’t work.

The C4R.DATASET.=NOCHANGE profiles control all ADDSD, DELDSD, ALTDSD and PERMIT commands for any dataset profile name or mask specified.

The C4R.class.=NOCHANGE profiles control all RDEFINE, RDELETE, RALTER and PERMIT commands for any general resource class and profile name or mask specified.

Add the statement “LEVEL=xx” and specify a level number in the APPLDATA field of the profiles above. Finally, change the LEVEL setting of the RACF profiles you want to be protected by the no-change policy. By utilizing the LEVEL field you control which profiles in the class are under control of the no-change policy. A very good use of this type of policy is to tightly control who can grant access to the RACF databases, another compliance item you can now ensure is under lock and key by Command Verifier.

SUBHEAD: Controlling Use of the RESET Keyword on RACF PERMIT Commands

Another useful—or destructive, if used improperly—RACF keyword is RESET. Adding the keyword RESET to any PERMIT command will completely wipe out the entire access control list of that RACF profile. Let’s see how we can use Command Verifier to protect against human error if use of the RESET keyword goes awry.

There are three ways to make use of RESET. The first, RESET, is short for RESET(ALL), which will reset both the standard and conditional access control list portions of the RACF profile. The second, RESET(STANDARD), will only reset the standard access control list. The third, RESET(WHEN), will only reset the conditional access control list. You will see later the difference this makes in which Command Verifier profiles come into play.

The following two types of profiles control the RESET keyword.

C4R.class.ACL.=RESET.profile

C4R.class.CONDACL.=RESET.profile

Typically we have seen how qualifiers of Command Verifier profiles with = or / in them can’t be covered by a generic. However, these profiles break that general rule. You could build a profile of C4R.*.*ACL*.**, for example, which would control all RACF PERMIT commands for all general resource classes as well as the DATASET class. I would caution doing so until you are certain who or what is issuing PERMIT commands in your shop. A general recommendation with any of these profiles is to start small and build it up slowly rather than try doing too much at once. I recommend you build to profiles as follows:

RDEFINE C4R.*.ACL.=RESET.** UACC(NONE) AUDIT(ALL(READ))

RDEFINE C4R.*.CONDACL.=RESET.** UACC(NONE) AUDIT(ALL(READ))

Now the question is whom do you want in the access list? The controls for this profile are simple: If you have UPDATE then you are authorized to use the RESET keyword.   no other access levels apply. You could do one of two things:

  • Allow system SPECIALs to permit themselves as necessary to the profile with UPDATE. That way, the profile will throw a RACF error since they will not normally have access.
  • Permit a group of your choosing with UPDATE access and connect authorized personnel to it with a REVOKE in the CONNECT command. Then, if use of the access is desired, all that is necessary is to unrevoke the group connection, log out and back on.

SUBHEAD: Summary

I have taken you through some key uses of Command Verifier to solve common compliance issues as well as scenarios that will help reduce human error. IBM Security zSecure Command Verifier allows greater control over RACF commands while abstracting those controls for RACF commands back into RACF itself. Leveraging Command Verifier controls can protect your compliance investment and ensure that once RACF is cleaned up, it will stay clean.

 

Joel Tilton is a senior mainframe security engineer. A former employee of IBM, where he got his start with mainframes, he continues to champion mainframe security issues and solutions. He can be reached via LinkedIn at http://www.linkedin.com/in/joeltilton.  The views I have expressed are my own personal views, and are not endorsed or supported by, and do not necessarily express or reflect, the views, positions or strategies of my employer.

 

 

 

 

 

 

 

 

 

 

 

Training Icon

Submit a Comment

Your email address will not be published. Required fields are marked *