Syschange Compliancy Mngt - Generic Systems Australiagensys.com.au/.../pdf/Syschange_Compliancy_Mngt... · The “Compliancy Management” component provides member-level security

SYSchange is an Advanced System Software Change Management and Application Lifecycle Management Solution for z/OS. It is designed to enhance the z/OS system security, reliability and availability by providing simple and comprehensive set of automated functions. SYSchange is currently utilized by major financial and other corporate institutions world-wide. Our solutions have been used in industry since1992 in the following key areas:

Compliancy Management

Advanced Deployment for all software changes across z/OS environments

Life-cycle change management for application developers

Version control and source management using the Change Request (CR) Process

The “Compliancy Management” component provides member-level security which is required by all Auditors to complement their RACF and Top Secret products.

® SYSchange Summary of Functions


Top 4 SYSchange Uses: p2 Automatic member-level backup and recovery of critical systems and application libraries

p4 Auditing of all real-time changes and verifying software integrity

p6 Freehand change implementation

p7 Member-level, dataset-level, and DASD-level protection

www.gfssoftware.com

IBM – SYSchange is a validated tool by IBM and is published on the IBM Global Solutions Directory

SYS ®change


This component of SYSchange provides real-time protection for system libraries at the member-level. Introducing unauthorized change at the member-level is prevented. When a library is protected, system changes can be easily documented online as the change is introduced. The Audit capabilities of SYSchange ensure compliance with Sarbanes-Oxley requirements. Protecting critical libraries achieves the following:

- Member-level change activities are recorded by the SYSchange Started Task around the clock.

- Automatic backup of changed members; no changed version is ever lost whether the change is introduced using ISPF or batch functions (source and load modules).

- Ability to document changes online as the change is introduced using the CSAVE command; CSAVE may be enforced for certain user selected libraries.

- Online view of contents of member versions enables users to recover the right version with certainty and without any guesswork.

- Online compare of any two member versions to identify and report the changes introduced.

- Member-level protection against unauthorized change; by using the LOCK feature for certain critical libraries, only authorized users will be allowed to introduce change.

- CHECKOUT command provides “exclusive ownership” to desired library members. Only designated users to whom members are checked out can edit and save those members. This feature allows consolidating CICS, DB2, IMS, and z/OS PROCLIBs into a single consolidated library, thereby allowing different departments to work with their own groups of members. Members can be “checked out” to a TSO-id or a RACF group where multiple users are defined in the group.

- Supports a SYSPLEX implementation where a central repository for all changes is created on a shared DASD. Regardless of where the change is introduced, in a SYSPLEX implementation, the SYSNAME of the LPAR where the change is introduced is recorded in the change event; as an example, when a change is made on SYSA or SYSB the recorded change indicates the system name in the common SYSchange repository.

usinessBartnerP

R

R

Once a critical library has become protected by the SYSchange Started Task (STC), SYSchange automatically and transparently backs up the changed member to its repository every time a change is introduced, regardless of the method of change.

Thus, users are enabled to recover from an undesired change online. Additionally, member-level backups can be augmented with a user- supplied comment at the time the change is introduced. This descriptive comment allows for easy version identification in case recovery is required.

Extra member versions are automatically archived to the SYSchange long-term storage media (the SYSchange archive system) for future recovery needs. Similar to live backups, the archived backups are always available online for viewing, comparing, and recovery purposes – all from a single intuitive ISPF screen.

The following diagram shows the STC monitoring the change activities in protected libraries around the clock. The ISPF panels on the next page show how online recovery is done with a few simple steps.

Top 4 uses of the SYSchange Compliancy Component

Automatic Member-level Backup and Recovery of Critical Systems and Application Libraries


1

SYSchange STC

Create Member-LevelBackup for:

(ADD, UPD, REN)

www.gfssoftware..com

SYSchange STC

Create Member-LevelBackup for:

(ADD, UPD, REN)

Record Member-LevelActions for:

(ADD, DEL, UPD, REN)


1

Screen 1: A display of “List of Protected Resources”

for user’s selection.

Screen 3: Member backups (versions) are displayed on

this panel. The oldest version is at the bottom

of the list.

Screen 2: Panel to specify an explicit member. All

member versions for the specified member

will be displayed on the next panel.

Screen 4: Once “View” was specified for a desired

version on the previous panel, the content of

that version is displayed on this panel. User can

save this content to target library of choice.


Auditing of All Real-time Changes and Verifying Software Integrity


2

1

The SYSchange Started Task monitors real-time change activities for protected libraries. SYSchange provides two approaches to auditing.

In the first approach, users protect critical libraries using the SYSchange "protect a resource" function, thereby requesting the STC to record member-level changes in real time and transparently back up the changed members to its repository.

This approach is recommended for volatile systems libraries, such as your PARMLIB, PROCLIB, JCLLIB, LINKLIB, etc. Real-time tracking allows you to audit your critical z/OS libraries by identifying who has made the change, what has been changed, when the change has been made, which programs have been used to introduce the change, and why the change has been made (real-time documentation of the change by using the SYSchange CSAVE command). ISPF and batch updates are all recorded. This approach has been discussed above.

REMOTEGRCUPCOMPARE

ZOS.OLDTOKEN

COMPARISON OF z/OS ENVIRONMENTS

ZOS.NEWTOKEN

Referring to these token files, installations may run the SYSchange "group compare" function or the PATHCOMPARE command to identify and report any changes introduced to the entire z/OS environment or the USS environment since the environ ment was first tokenized. This process can be used to verify the integrity of z/OS software environments or the USS environment residing on multiple local or remote LPARs. In this case after the local environment is tokenized, this small token file repre senting a software environment is transferred to the remote LPAR using NDM, FTP, XMIT, or as an E-mail attachment. Once the two token files have been made available on the same processor, the SYSchange REMOTEGROUPCOMPARE function or the PATHCOMPARE function may run to report the differences between the two environments.

Datasets with member differences or USS directories with any file differences are clearly identified and reported. In all cases, lack of change between two environments is a guarantee that software residing on both LPARs has remained identical and hence integrity is verified.

For a sample audit report of Real-Time changes collected by the STC, refer to the following page.

The second approach to auditing software changes can be used both within and between environments. Using the SYSchange tokenization technology, patterns of datasets or patterns of USS directories are tokenized to establish "content reference tokens" for individual members or USS files, or to establish one token for the entire file (as for physical sequential or direct access files).

These reference tokens represent the contents of the files at the exact time of tokenization and are stored either in the SYSchange control file, or on an external file referred to as a "token file."

TOKENIZE A PDS OR PDSE

A, B, C

A, B, C

TOKEN (A) TOKEN (B) TOKEN (C)

file1.txt file2.txt file3.txt

TOKENIZE A DIRECTORY (RECURSIVE TOKENIZATION)

/user/bin/*.*

node.USS.TOKENS



The following shows a sample audit report of real-time changes collected by the STC. As you note from the three protected libraries in this group, two of them show change activities (red) and one has had no change activity since it has been protected (green).

Audit Report: (Case when there is no DATE specified)

List of Protected Librar ies VOLSER Protec tion-Date LOCK

DEV.SYC.INSTALL

DEV.SYC.LINKLIB DEV.SYC.SAMPLES

-

- -

2011/01/16 11:55

2011/01/16 11:56 2011/01/16 11:56

NO

NO NO

SYCMAIN (712I) 3 Protected Libraries were found.

List of Activities in Protected Libraries: 2011/01/26 18:11

DATE=ALL OPTIONS=ALL

DSN=DEV.SYC.INSTALL


Member

SYCSTC

By-User

IBMUSER2

Action

UPD

Action-Date-Time

2011/01/26 18:12

JOBNAME

IBMUSER

Program

IKJEFT01

Documentation of the change

STC: -Changed a PARM for CICS

SYCSTC IBMUSER UPD 2011/01/26 18:09 IBMUSER IKJEFT01 STC: -OTH IKJEFT01 IBMUSER

SYCSTC IBMUSER UPD 2011/01/16 12:40 IBMUSER IKJEFT01 STC: -UPD IKJEFT01 IBMUSER

SYCSTC IBMUSER2 UPD 2011/01/16 12:21 IBMUSER IKJEFT01 STC: -Demo how CSAVE works



SYCSTC IBMUSER UPD 2011/01/16 12:00 IBMUSER IEBCOPY -



DSN=DEV.SYC.LINKLIB

Member By-User Action Action-Date-Time JOBNAME Program Documentation of the change

SYCDEFLT IBMUSER2 UPD 2011/01/26 18:08 BMUSERZ AMASPZAP STC: -OTH AMASPZAP

SYCDEFLT IBMUSER UPD 2011/01/16 12:11 IBMUSERZ AMASPZAP STC: -OTH AMASPZAP

SYCMOD IBMUSER2 DEL 2011/01/16 12:08 IBMUSER IKJEFT01 STC: -SYCNAMEX IBMUSER

SYCNAMEX IBMUSER REN 2011/01/16 12:05 IBMUSER IKJEFT01 STC: -REN IKJEFT01 IBMUSER

DSN=DEV.SYC.SAMPLES -

* * NO CHANGE * *

SYCMAIN (238I) 3 DSNs checked for activities;

1 DSNs determined to have no activities

2 DSNs determined to have change activities

Freehand Change Implementation


3SYSchange provides the capability to introduce changes freely without enforcing arduous change management procedures. For example, by using "LOCK=NO" when a resource is protected, all members of that library remain available for update by anyone passing RACF or similar security packages. Once the change is made, upon pressing PF3 or issuing the SAVE command, the user is optionally prompted (depending on the installation parameters) to document that change.The user-supplied documentation is stored in the SYSchange Control File, and the STC generated backup is stored in the SYSchange Data File.

The SYSchange freehand functionality also allows a SYSchange global administrator to grant exclusive ownership over groups of members. Such members will only be available for updates by pre-designated users or a RACF group. The benefit of this approach is that it provides the freedom to selectively freeze some members, while the rest of the members can be updated by all.

The following diagram illustrates the concept of the SYSchange freehand mode where a library has been pro-tected with the "LOCK=NO" option.

A, B, C

PDS WITH LOCK=NO (FREEHAND MODE)

Available for update

Unavailable (explicitly "checked out")

All members are available for update by any users Available

The following diagram shows the opposite of the previous case. Here, protection with "LOCK=YES" is being employed. Consequently, all members of that PDS become unavailable for update. However, those members that are explicitly "checked out" (below there are three shown in green), can be updated by their designated developer (e.g., a RACF group or the TSO userid to whom these members are explicitly checked out to by SYSchange).

A, B, C

PDS WITH LOCK=YES

Available for update (Checked out)

Unavailable for Update (Locked)

All members are locked except the three checked out


Member-level, Dataset-level and DASD-level Protection


4SYSchange provides both member-level and dataset-level protection. Using the "LOCK=YES" specification during library protection, SYSchange enforces the requirement of using the SYSchange CHECKOUT function. When "LOCK=YES" is used, none of the library members can be modified unless the user is authorized to do so by an explicit checkout granted by the SYSchange global administrator.

Furthermore, "LOCK=YES" ensures that the started task (STC) is constantly monitoring the resource for update activities by recording and backing up any changes. In this way, SYSchange protects system assets and eliminates system downtime and unauthorized tampering with the system saving time during problem determination and resolution. When we consider dataset-level protection, "LOCK=YES" not only protects against ISPF changes but it also protects against other types of changes introduced by batch functions. Refer to the diagrams below.

The DASD-level protection feature disallows updates of all datasets on one or more volumes, except by pre-assigned super users. The benefit of this feature is that it enables a SYSchange global administrator to keep entire production volumes or an alternate SYSRES completely immune from unauthorized updates, using minimal effort and resources.

DATASET-LEVEL AND DASD-LEVEL PROTECTION

Update attempts by non Super-Users are blocked (SAF Exit)

DS1DS2

DSn

Super-Users are granted update access to all the data sets on the DASD volume.

User's Experience

"The high number of LPARs coupled with the constant changes being introduced to those systems, make the tasks of security and change control a daunting one at best. This is because traditional products do not offer an automated and transparent process for tracking changes that take place in every corner of our data center. Inherent to this challenge are the enormous resources that are ordinarily required to achieve such ends."

"At Rabobank, one of our imperatives was to acquire a solution offering a comprehensive set of change management technologies that would help us gain control of change and keep us at the helm."

The Solution — SYSchange for z/OS

Rabobank regularly benefits from the capabilities delivered by SYSchange to protect their own critical system libraries and monitor changes in those libraries; the ones that they decide as being critical.

"SYSchange has provided us the assurance that all system-wide activities are centrally monitored, backed up for recovery purposes, and quickly reported."

"SYSchange provides us with key change information such as: who made the change, why the change was made, when the change was made, and what has changed …"

SYSchange provides Rabobank with key information for their entire system


For more information please visit:www.gfssoftware.comNovember,2011


This, along with the ability to resort to an earlier member version on-line has been very important for Rabobank. In SYSPLEX environments they are also able to identify the LPAR on which the change has been introduced.

In addition to the real-time monitoring and control of changes, SYSchange also provides change information using alternative technologies. For example, if Rabobank wants to keep track of changes made to a certain software environment, they simply tokenize that environment. They have been able to tokenize several DASD volumes in minutes. Then, before a mass distribution they simply re-tokenize the same environment to identify and report changes to ensure there are no unexpected or unauthorized changes that will infect their target environments.

By defining libraries for SYSchange protection, Rabobank has automated the notification process. Each night a report is generated on each system, and sent out via SMTP to the appropriate persons. All reports are combined into one, sorted on system ID, dataset name, and date and time of change. This report is used by the change managers to see first-hand where changes have occurred.

"…we have automated the process of informing auditors and change managers of critical changes, on a nightly basis. … This report is used by the change managers to see first-hand where changes have occurred."

Additionally, tokenization provides Rabobank the benefit of readily identifying the changes in between major distributions. Another very beneficial aspect of this tokenization process is that before a major distribution, SYSchange identifies whether or not the changes that are about to be deployed to the target system, have already been introduced as a part of another distribution cycle; which is a very useful technique for helping them eliminate regression.

In the past, using their traditional full copy distribution techniques, changes made on a target system but not on the master system were later overlaid by the full distribution of the master system (a regression case). Investigation of such dangerous regression cases (if NOT discovered in-time), would be costly.

Rabobank uses the packaging features built into SYSchange for deploying their changes across all systems and activating them. They can perform these critical tasks with confidence because SYSchange provides another useful technology referred to as a "rollback" package (this is a feature that Rabobank had specifically requested). This means that if they ever need to revert back to the state prior to a promotion, they can use the rollback function of SYSchange. The rollback function becomes even more critical if a PTF contains errors.

"…we now use the packaging features built into SYSchange for deploying our changes across all systems and activating them."

At Rabobank, another long-time concern was that the task of change creation versus change promotion was administered all by the same group. SYSchange provides Rabobank with the versatility of splitting the task of change creation versus change activation. This way the dangers of having the same technician(s) work on both the development system and production system is eliminated.


GFS Software, Inc. is an authorized distributor of SYSchange.

SYSchange is a product of Pristine Software Company LLC.

GFS Software, Inc.

1133 Broadway, Suite 310New York, NY 10010Phone +1 212 659-2220Fax +1 646 786-4174

e-mail: [email protected] September, 2012

Documents

Syschange Compliancy Mngt - Generic Systems Australiagensys.com.au/.../pdf/Syschange_Compliancy_Mngt... · The “Compliancy Management” component provides member-level security