Security in z/VSE is provided by the Basic Security Manager (BSM), which is part of z/VSE central functions and provides basic functionality. Clients with more demanding security needs (e.g., field-level security, command security) may choose to use a security manager product from an Independent Software Vendor (ISV) instead of BSM.

z/VSE V3.1.1 introduced an enhanced BSM that supports additional resources and new functions. z/VSE V4.1 continued the trend of addressing key client security needs. It introduces new logging and reporting functions to the BSM. This article provides an overview of the BSM and new auditing functions.

What BSM Protects

User IDs and resources are defined to BSM as profiles. Looking at where those profiles are stored, we see three groups.

In the first group, we have the user IDs. User profiles are stored in the VSE control file (IESCNTL). Usually, these profiles are defined and maintained via interactive interface dialogs. User profile definition via batch job is possible, but with a few limitations.

In the second group, we have:

• VSE files

• VSE libraries

• VSE sublibraries

• Members of the VSE sub-libraries.

They’re protected via the phase DTSECTAB. Security definitions of those resources are made via macro calls in an Assembler source. The authorization checking must be activated at IPL time with the system command SYS SEC=YES. This command also activates the batch security. That means a user ID, including its authorization, can be assigned to a batch job. The user ID, together with its authorization, can be inherited to a child job.

In the third group, there are general resources. Most are the online resources or CICS resources, including:

• Transactions

• Transient data

• Files

• Journals

• Started and XPCT-checked transactions

• Application programs

• Temporary storage.

Although not strictly CICS resources, the APPL resources also are used by CICS. The APPL class allows control of the terminal users’ access to VTAM applications such as CICS (i.e., DBDCCICS and PrODCICS). The users’ authority to use an application will be checked during sign-on.

The resource class FACILITY also is in this group. It’s for miscellaneous use by applications such as DITTO or the CICS report control facility. To use this class in a batch job, the batch security must be active (SYS SEC=YES). Otherwise, no user ID information is available and no user-related security decision can occur.

The profiles for the online resources and the resources of the class FACILITY are stored in the BSM control file (BSTCNTL). This is a VSAM file administrated via interactive interface dialogs or BSTADMIN commands in a batch job or from a console.

With z/VSE V3.1.1, groups of users can be defined. Those group profiles also are stored in the BSM control file.

New in z/vSE v4.1

With z/VSE V4.1, the focus of BSM enhancements was to improve the auditing support. Until z/VSE 3.1, logging was limited to violation messages on the system console. Only resources protected via the DTSECTAB could have more granular logging and reporting, using the IBM product Access Control Logging and reporting (ACLr).

To provide more granular logging and reporting for resources not protected via DTSECTAB, the BSM of z/VSE V4.1 contains several enhancements. These involve the AUDIT parameter, System Management Facility (SMF) records for logging, and use of the Data Management Facility (DMF) to collect SMF records.

AUDIT Parameter in the Profile Definition

The administrator can define an audit value in the security profile of a resource so that:

• All unauthorized access attempts to a resource should be logged the same as in the past. This also is the default if nothing was specified.

• All successful access attempts should be logged because, for some resources, it’s more important to know who has accessed or changed a resource.

• All successful and unauthorized access attempts should be logged.

• No access attempt should be logged. This might be useful to suppress logging entries for resources that should not be audited.

Using SMF Records for Logging

The audit entries are based on SMF records. Similar to rACF in z/OS, the BSM in z/VSE V4.1 uses SMF record type 80 to log certain security events.

Using DMF to Collect SMF Records

Other than in z/OS, z/VSE V4.1 uses the DMF to collect the SMF records; it’s part of CICS Transaction Server (CICS TS) for VSE/ESA. But using DMF doesn’t require having CICS TS active.

Detailed and Summary Reports

After DMF collects records and SMF80 records are extracted with the DMF dump utility (DFHDFOU), the BSM report writer program (BSTrPWTr) can be used to create a detailed report and several summary reports.

The detailed report shows the date and time of an event, and the user ID or job name that was used for this event. In the “Event” column, the code number of this event is shown; for example, 2 for a resource access. The “Qual” column contains the event qualifier number showing the result of this event, such as 0 for successful access. A verbal description of these code numbers follows the job name in the same line. Summary reports include the:

• User summary list, which shows the number of successful logons and logon violations for a user ID and also a summary of the resource accesses for the user ID.

• Resource summary list shows the number of successful and unsuccessful access attempts per resource; it also contains information about which access levels were targeted in attempted uses.

• The general summary shows the total number of processed SMF records, logon attempts, and resource-related events.

Summary

The BSM is the part of z/VSE that provides basic security functionality. BSM enhancements in z/VSE V4.1 now offer additional logging and reporting functions.