With the introduction of Resource Access Control Facility (RACF) in 1976, ACF2 and Top Secret Security shortly thereafter, and their evolutionary path into z/OS security servers, these External Security Managers (ESMs) have provided tight controls around authentication and access control that have advanced to support for X.500 series, digital certificates, the ability to administer, store, use and export keys, with a notable uplift in security around mobility, analytics and the cloud.

However, mainframe security goes beyond access control. As has been pointed out many times in many publications, without the underlying system integrity (see IBM’s z/OS System Integrity Statement), access control can be bypassed and therefore access can be gained to about anything in the environment while bypassing the ESM, audit trails and SMF recording.  

As sophisticated as today’s mainframe security mechanisms are, there are still vulnerabilities. Mainframe security and system integrity will be as effective as your internal security policies, the ability to enforce them and the certainty that all are adhering to the rules. Some examples of vulnerabilities:

• “Common” or shared TSO IDs or even the occasional sharing of IDs

• Shared DASD among development, test and production environments

• Use of interactive debuggers in production environments

• Lax control of APF programs and libraries, user SVCs, PCs and system exits

• Use of user key in Common Area Storage (CSA) for example Key 8 CSA usage in customer programs as well as in ISV products

• Unencrypted connections to z/OS via Windows workstations, IDEs, mobile devices and even 3270 connections (recall the Logica z/OS hack in 2013 by Pirate Bay co-founder Gottfrid Svartholm Warg).

 In one case I actually recall a data center where the operations manager (due to misplaced control issues) required his department to provide their TSO credentials to him.  We know of managers giving their credentials to others so approvals can be issued during vacations and absences. When its 3:00am and production is dead in the water, there have been times where TSO credentials are exchanged between operations and an application developer to expeditiously get production back up and running.  While step debuggers should support production mode (read only), that doesn’t mean this feature is always enabled.

From a system integrity perspective, all it takes is access to one library in the  APF list and you really do have the keys to the system. There are many unintentional vulnerabilities as well such as CSA key 8 storage allocated on the system. IBM has come around in z/OS 1.9 to make the default behavior to not allow user key CSA with AllowUserKeyCSA parameter set to YES as default. For some time, there were several vendor products that still required this to be set to YES, but hopefully in recent years these have been addressed.  

Then there are the Unix vulnerabilities within z/OS, the abuse of Unix Superuser Privilege, abuse of UNIXPRIV profiles etc.

The  intent here isn’t to catalog all of the possible vulnerabilities in the z/OS environment, just know that there are many.  Effective access control is absolutely necessary, but that is only part of the solution.  

Bad changes happen. Sometimes they are malicious, sometimes they are accidental and well-intended. Sometimes the right people make the wrong changes.

This is where ChangeMan SSM can help. ChangeMan SSM is not access control in the sense that RACF, CA-ACF2 or CA-TSS are (although ChangeMan SSM works with any SAF-enabled security server). Nonetheless, ChangeMan SSM plays an important role because even in the face of bad practices, human error or outright malevolence, you have the capability to monitor changes to data sets, members, files before they take place. You also have the ability to be notified of changes and more importantly, if a rogue or errant change goes in, you have the capability to identify it and back it out.  

With regard to system integrity, ChangeMan SSM is configured to automatically track the following critical system resources out of the box:

• Datasets in the APF list

• Datasets in LPA lists

• Datasets in Linklist

• Nucleus

• IPLPARM

• All parmlib datasets referenced at IPL

• Proclibs allocated in the Master address space

• Proclibs allocated in the JES2/3 address space

 You have the capability of being notified, via email or TSO, if any member of these libraries change: The nature of the update,  who changed it, what program, what job, which LPAR etc.

In addition to the definitions above, you can define data sets, patterns and volumes to ChangeMan SSM, this includes production critical datasets as well as critical system datasets.

ChangeMan SSM’s capabilities fall into three primary categories:      

• Change Tracking

• Detection and Synchronization

• Data Extraction 

All of ChangeMan SSM’s facilities use Serena’s Fingerprinting technology; a technology that uniquely identifies a file (or member) by creating a unique 8-byte token representing the contents, known as the fingerprint. When the contents of a dataset or member changes, so does the fingerprint. A dataset can be copied to another volume, distributed to a remote site, or re-blocked without  any change to the fingerprint. However if the content changes, the fingerprint changes to reflect the updated token*.

ChangeMan SSM uses this technology to detect differences in the contents of one or more members, an entire dataset, a group of datasets, a volume or group of volumes regardless of the naming conventions.

For VSAM KSDS clusters, one token is generated per record and a composite token for the entire data component. These fingerprints are stored externally in a fingerprint dataset.

For HFS files, you can compare local or remote software environments, detect changes, and verify synchronization. You can perform the following tasks for HFS files:

• Fingerprint a group of HFS files

•  Compare two HFS fingerprint data sets and report differences

• Capture changes into an HFS change basket

• Apply an HFS change basket to synchronize environments

• Use path modeling to compare files in different locations, as well as update a location with a different path. 

  Although ChangeMan SSM is useful for synchronization, disaster recovery, software rationalization, audit compliance and other tasks, this entry is not intended to cover all of ChangeMan SSM’s capabilities and will focus on the Change Tracking capabilities as it relates to mainframe security.

  The Change Tracking function of ChangeMan SSM operates in two modes:

• Batch Interval Change Tracking (BICT)

• Real Time Change Tracking (RTCT) 

  Once system or application critical datasets are defined to ChangeMan SSM’s change tracking component, any updates made to the datasets or members within are identified and logged to a ChangeMan SSM database. When the change takes place, the change tracking component can automatically back up the changed member to the Delta Master database. This allows you to recover prior versions of datasets and members, analyze the changes with a built in compare function, and recover if appropriate (available options are Browse, Compare, Recover, View).

  The following optional features are available when using Real Time Change Tracking:

• Notification of change events (specified users can be notified via TSO or email)

• Member Level Security (protects specified members from update by unauthorized users)

• Member Reference Tracking (if you only want to see when members are referenced by which jobs or users, and when)

In any of the above scenarios where potential vulnerabilities exist, with critical datasets defined to ChangeMan SSM, changes can be tracked, and real time notifications sent out when changes occur, allowing for analysis of these changes, recovery to a prior level if necessary. In the latest version of ChangeMan SSM, 8.5, the change can wait for an approval when working in conjunction with Serena SBM.   

Where access control may allow the “right” person to make the “wrong” change, with ChangeMan SSM, it is possible to have visibility into any and all changes, and be able to quickly recover from them, keeping an audit trail from beginning to end.

* A major vulnerability is having copies of sensitive data reside outside of the production environment. Generally for testing purposes, and often not accounted for or properly cleaned up. ChangeMan SSM has Redundancy Detection including a Redundancy report which is not only useful for reclaiming space, it can identify if you have copies of sensitive data outside the production domain. Recall that fingerprints are based on name, structure and content. The ChangeMan SSM’s redundancy detection can identify datasets that have the same structure and content, but a different name. Serena  Comparex can be used to squeeze and mask out sensitive customer information for creation of test data. In the absence of this functionality, using ChangeMan SSM’s Redundancy Detection is critical in identifying if any sensitive data resides somewhere unsecured, uncontrolled and outside of the production environment.