Audit Serve, Inc.

The Worldwide Connection for Audit, Security, Control and SOX Professionals

Change Management Approaches Used in the 
VAX/VMS Environment

By: Mitchell H. Levine, CISA
Audit Serve, Inc.

                                                             

Low Cost & Highly Skilled 
IT Audit and SOX Consulting Resources Available Immediately
Call Mitch Levine at (203) 972-3567 or 
email levinemh@auditserve.com for additional information

The purpose of this article is to discuss the various methods used within a VAX/VMS environment (i.e., referred to in the industry as OPEN/VMS) for software management. The main feature discussed in this article pertains to the migration of program changes through the various directories used within a change migration process.

Traditional Program Migration Controls
Typically, the directories in which program change passes through during its migration (i.e., promotion) to the production environment consists of: programmers development directories, holding directories, testing directories, and production directories.

When promoting a program change to production, the user usually requires update access to the directory where the changes are being migrated to and read access to the directories from where modules are being copied. A necessary control when update access is required in order to migrate changes through the directories used in the change migration process is the segregation of duties between the programmer who makes the change and the person responsible for migrating the change.

Regardless of whether there is segregation of duties for migrating changes through directories used in the change migration process, an audit trail is required at the module level of the changes that occurred in the directories used in the change migration path. UIC-based security, which is one security alternative within a VAX/VMS environment, enables access rights (i.e., Read, Write, Execute, Delete) to directories to be defined for users who fall into a specific category (i.e., System, Owner, Group, World), but does not provide options to log specific types of access to a directory.

However, Access Control Lists Entries, which is an alternate means of protection offered by VMS, can be used to generate an ACL alarm written to the security archive file. This can be used to set an alarm on the directories used in the change migration process. This audit trail could then be reviewed by an independent person to ensure that all updates to directories used in the change migration process were based on changes approved by management. The ACL alarms will generate an audit trail which identifies the mode of access, the file that was accessed, and the specific access privileges that were used to access the file.

When analyzing all of the controls required in a change migration process and comparing it to the available controls provided by the approach just described, it must be noted that there are some controls missing. The process just described would only identify an unauthorized module being migrated. That is assuming that the management review includes the identification of modules required to be changed for a project. Such a process would not identify whether the person authorized to migrate modules migrated modules from a directory that is not part of the change migration process (e.g., their personal directory). In addition, the entire process would not identify unauthorized changes to a module residing in directories used in the change migration which have been authorized to be migrated. This is because the audit trails are not generated to distinguish between a module that is edited within a directory from a module that was copied to a directory.

Alternate Approach Using a Captive Account
The controls illustrated in the previous change migration process relied on detective controls to identify unauthorized changes made by those individuals required to perform the migration based on their job function.

The entire process is solely dependant on a review of changes to directories used in the change migration process. Since the users performing the migration do not require the ability to update these directories except for required migrations, this detective control approach should be automated to provide a preventive control. This would restrict their ability to make changes outside the approved change migration path.

The VAX/VMS operating system provides the captive account which can be used to restrict the individual using the account to installation established functions. An installation can create a menu driven environment using DCL commands to perform such functions as:

• prompting an individual to migrate modules to a testing or production environment from pre-defined directories
• providing an audit trail of all migrated modules which can be reviewed to ensure that only modules associated with an approved project are migrated

Using a captive account denies the user access to the DCL command level where they would be able to perform unauthorized updates since the account itself would still require update access to the directories used in the change migration process. As of version 5.2 of VMS, the captive account prevents a user from gaining access to the DCL command line under all circumstances. However, prior to version 5.2, it was possible for captive users to break out into the DCL command line in some cases.

To establish this type of change control process, a commitment from management must be obtained as a result of the development effort required to write the DCL shells which creates the menus. The benefits obtained from having a secured and controlled change migration process should out-weigh the costs.

DEC provides other add-on products which could be used to construct a controlled change management process and additional software management controls which are beyond the scope of this article. One of these products is the Code Management System (CMS) which tracks all changes to source modules and provides a controlled mechanism for source management through its check-out system. The other DEC product is the Module Management System (MMS) which automates the compilation and linking process to ensure that applications are built in the proper manner.

This article was written more than three years ago. Events may have 
changed since this article was written.

Copyright  2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

This article appeared in a past issue of the Audit Vision E-Mail Newsletter.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.