sponsored by the Henderson Group
Computer Security Consulting and Training

Trends in MVS Security: What They Mean to Auditors and Data Security Officers

INTRODUCTION

A look at security for IBM's MVS operating system, what to expect in the future, and what this might mean to security and audit professionals. This article was first written in 1995, updated in November, 2000, and updated again in July of 2007.

Since the 1960's, IBM's MVS operating system, or some version of it, has been the predominant system software for IBM's family of mainframe computers. MVS has been the environment for which the best-known and most widely used security products have been developed, and it has influenced our thinking about security for all computer systems. But MVS security is not a static concept; it is a moving target on which security product vendors and infosecurity professionals must keep focused. Data security officers need to understand the history of MVS security, and they should be aware of the recent developments.

This takes on greater importance since the mainframe is not dying or going away. The Gartner Group calculates that the cost per user and cost per transaction is often lower on a mainframe than on other platforms. It is relatively easy to demonstrate that MVS provides the most secure and most reliable version of: UNIX, TCP/IP, and Internet web server of any commonly available platform.

In discussing MVS security, five basic ideas should be kept in mind:

1. The different protective tools available with MVS are all inter-related. A weakness in one undermines the security of them all.

2. Security tools have evolved in response to the increasing complexity of the operating system, including the number and type of users and programs supported. This complexity also includes the increasing number of system software components. Once there was just an operating system; now JES, VTAM, TSO, DB2, CICS, USS, TCP/IP, the WWW Server, and other software must be taken into consideration.

3. The security provided by these tools is based on two basic questions: "Who is this user?" and "Can this user do x?". Each security tool addresses at least one of these questions.

4. As tools increased in sophistication, they have relied less on hardware controls, and more on software controls. This has required more attention and greater effort by security administrators to ensure that security tools are used rigorously and consistently.

5. As more types of hardware and software are interconnected (including: mainframes, AS/400s, personal computers, non-IBM computers, as well as computers which belong to our customers, suppliers, and competitors), there is greater need to coordinate the security mechanisms and standards among them. When this is not well understood, security officers may not be informed of changes in a timely fashion, and they may not be able to provide adequate, efficient control.

To provide comprehensive computer security, it is important to understand the different security features available to MVS systems and how they fit together: hardware controls; MVS controls; add-on security software such as ACF-2, RACF, and TopSecret; VTAM security; DB2 security; and other software controls.

MVS History: Security Through Hardware

MVS's evolution may be viewed in several stages, each of which was built upon its predecessors and upon basic hardware controls to support computer security.

PCP: One Job At a Time

IBM developed the MVS hardware and software together, starting in the 1960's with the S/360 computers and the PCP (Primary Control Program) operating system, the forerunner of MVS. Since only one job or program could execute at a time, there was no need to prevent one program from interfering with another. In this sense, one of the earliest controls was isolation - that is, allowing only one program to execute at a time. In addition, PCP relied on two basic hardware controls to prevent programs from interfering with the operating system itself. These were supervisor state and protect keys.

Supervisor state is a two-position switch built into the hardware of every S/360, S/370, S/390, and z/series computer. When it is on (in supervisor state), programs can execute any instruction given them. When the switch is off (the problem program state), however, programs cannot execute privileged instructions - such as sending a command to a tape drive to start reading data.

As a general rule, MVS reserves supervisor state for itself, causing all application programs to execute in problem program state. Any time a program needs some powerful function, it must issue a supervisor call instruction to request the operating system to perform it. For example, to read data in from a tape drive, a program must issue a supervisor call instruction to request MVS to tell the tape drive to perform the read. MVS will execute the necessary privileged instructions, but only after performing various checks to make sure the program should be allowed to read from that tape drive. After issuing or denying the requested commands, MVS returns control to the application program in problem program state.

IBM has provided several ways for application programs to obtain supervisor state: by adding user written supervisor call routines to the operating system, for example, or by executing exit routines which run in supervisor state. While these methods are provided by IBM, each installation must provide appropriate controls over their use. Since most of these techniques are coordinated by information in the MVS dataset SYS1.PARMLIB (or the parmlibs, there can now be more than one in use), change control and access control over this dataset are important parts of an effective security program. Ideally, such routines should use the same sort of logic as IBM's supervisor calls, making sure that the program issuing the supervisor call instruction should be permitted to do so. For example, the supervisor call to open a file contains checks to make sure that the requesting program is authorized to open that specific file. IBM provides classes and manuals (such as "MVS Programming Authorized Assembler Services Guide") describing techniques to ensure that supervisor calls and similar "backdoors" to MVS security are coded in a safe manner. "Safe" means that they don't make it possible for unauthorized users to obtain the privileges of MVS, which would let the users bypass all the security on the system.

Protect keys are numbers (0 through 15) associated with every memory location in every S/360, S/370, S/390, and z/OS computer. When a program tries to write to a given memory location, the hardware compares that location's protect key to the current protect key, a counter representing the protect key of the program which is currently executing. If the current protect key matches the protect key of the memory location, or if the current protect key is 0, then the access is allowed. Otherwise the hardware prevents access.

When the current protect key is 0, the executing program can access any memory location, regardless of its protect key. MVS generally reserves protect key 0 for itself.

Once your program has supervisor state, it can give itself protect key 0; once it has protect key 0, it can give itself supervisor state. Thus, instructions to change the current protect key, or to change the protect key for a given memory location, are all privileged. To execute them then requires supervisor state.

The PCP operating system used these two controls to protect itself from programs which might accidentally or deliberately damage it. PCP allowed programs to execute only in problem program state, reserving supervisor state for itself. It also reserved protect key 0 for itself, assigning a protect key such as 8 or 9 to any executing program. This meant that programs could execute basic instructions, such as those which do arithmetic and move characters around memory, but only within memory that shared the same protect key. Programs could not alter PCP itself, because PCP resided in memory with a different protect key.

In summary, PCP provided security control by:

• Allowing only one program to execute at a time (isolation).
• Reserving supervisor state for itself.
• Reserving protect key 0 for itself.

In its current (year 2007) stage of evolution, MVS still uses supervisor state and protect keys to support security. While MVS no longer uses isolation the way PCP did, it does use isolation by means of address spaces, (which we shall describe shortly), to prevent one job from interfering with another.

MFT and MVT: Multiple Tasks

As IBM developed the operating system to support more users and functions, the need for additional controls became apparent. The first came with MFT (Multi-programming with a Fixed number of Tasks). MFT was similar to PCP, and the next major step on the road to today's MVS. As its name implies, MFT allowed more than one program to execute at a time. To prevent jobs from interfering with each other, MFT restricted each job to a given region of memory, and then assigned different non-zero protect keys to each region. This limited the number of regions (and therefore the number of jobs which could execute at the same time) to 15.

IBM next offered more flexibility with MVT (Multi-programming with a Variable number of Tasks), which allowed regions to be allocated dynamically, without the fixed boundaries of MFT. This provided much greater operational flexibility, since operators no longer needed to reconfigure the number and size of the regions. This also increased the pressure to support more than 15 executing programs at once.

MVS: Address Spaces and Hardware

IBM addressed this pressure with the concept of address spaces, introduced with the S/370 hardware and the SVS and MVS operating systems. (SVS stands for Single Virtual Space; MVS for Multiple Virtual Space - these also went by the names VS/1 and VS/2, respectively.) An address space is a set of memory locations from zero to some limit.

Assume, for our example, that the limit is address 16 million. If Job-A has its own address space, then it has its own set of addresses from 0 to 16 million. If Job-B has its own address space, then it has its own set of memory addresses from 0 to 16 million. Hardware is used to translate address space locations to real or actual memory addresses for both Job-A and Job-B. MVS maintains a translation table for each job, listing all the addresses in its address space, along with the real storage addresses to which they correspond. When Job-A is executing, MVS points the hardware to Job-A's translation table. When Job-B is executing, it points the hardware to Job-B's translation table. This protects Job-A from interference by Job-B, since Job-B cannot access Job-A's memory. In effect, Job-A's memory doesn't exist when Job-B is executing, because the table pointing to Job-A's address space is not being used.

A program can execute without using the address translation tables. In this case it is said to run "in real mode", and each address is treated as real or actual, not needing translation. With some exceptions, MVS reserves this capability for itself. Instructions to activate or deactivate address translation can only be executed by programs in supervisor state. It is also possible to move data from one address space to another by means of MVS's Cross Memory Services feature, which requires supervisor state as well.

In summary, the address translation facility added a fourth control:

• Isolating jobs and users in separate address spaces.

These first four means of protection were all hardware based, and therefore they operated in an automatic and rigorous manner. As systems moved beyond the hardware controls and began to rely on software controls, these attributes began to diminish.

XA and ESA: More Memory and the SAF

The next step in MVS's evolution was MVS/XA (eXtended Architecture). While the main feature of XA was an increase in the maximum possible memory address, it also introduced a new security feature: SAF, the System Authorization Facility.

SAF is a table of addresses pointing to each different security function. For example, the first entry might have the address of the routine used to verify a user's userid and password. The second entry might have the address of the routine that can answer the question: "Can this user do x?". New security functions can be added by making new entries to the table.

While SAF added no new security functions to MVS, it did centralize all security requests. Application programs which previously made direct use of security routines, now had to call them through SAF, using a code to indicate which function should be invoked. SAF made it possible to write exit routines which were given control of SAF's logic, and thus able to intercept every security request. Such exits could be used to improve security by adding additional checking, or alternatively, to introduce new exposures by bypassing security.

SAF is a common point within MVS through which all requests for security related functions should pass. For example, all IBM-supplied programs which call RACF do so through SAF. Of course non-IBM software such as ACF2 and TopSecret can also make use of SAF calls, since SAF is part of MVS and not part of RACF. SAF made it relatively easy for IBM to add significant new security functions to MVS.

After XA, the next step in the evolution of MVS was ESA, Enterprise Systems Architecture. This hardware provided additional flexibility in address space communications, without significant increase in security function. The MVS/ESA version of the operating systems takes advantage of this additional flexibility to improve performance.

MVS Security Provided by Other Software

In parallel with the evolution of MVS and its security functions, other software was evolving to enhance the basic MVS protection. IBM offered the PCF, or Program Control Facility, to add security functions to its TSO time-sharing system. Because PCF was embedded in TSO, it provided no protection against access by non-TSO users. It also relied on hard-coded security logic, which required assembly language programming. PCF is now considered obsolete.

IBM also offered password protection of datasets, which relied on setting flags to indicate that a dataset was protected. This password protection scheme also relied on a dataset which contained all the passwords in clear, unencrypted form. This approach was considered difficult to use and less than rigorous, and it is obsolete today. One important lesson we learned from this is that passwords should be associated with a user, not with a dataset. Having password protection on datasets made change difficult, since every job that used the protected dataset might need to be updated.

Several other software products (for example, SDSF, which allows users to browse print files on the JES queue) allowed system programmers to hardcode security functions into a program. Overall, this weakened controls and made it difficult to change security rules quickly. We learned by experience that security which is hardcoded or specific to a single application is not as effective as security implemented in a more centralized manner.

With the increased use of on-line systems such as TSO, IMS, and CICS, there was greater need for controls to protect the many programs executing at once from interfering with each other. The 15 available protect keys were not sufficient to distinguish among hundreds of on-line users. TSO provided some protection by giving each TSO user his or her own address space. IMS and CICS developed their own security systems based on termids, or terminal identifiers. These security systems would allow programs to execute only from specified terminals, on the assumption that only authorized people could gain access to them.

Most on-line software also started supporting userids, or user identifiers, to control what each program was allowed to do. A user would prove who he/she was by entering his/her userid, followed by a secret password which only that user should know.

For on-line systems then, two additional controls evolved and survived to improve security:

• Terminal-based security systems.
• Userid-based security systems.

Terminal-based security was rapidly found to be less than effective, except where there was absolute physical control over who could use each terminal. Userid-based systems were more rigorous and more flexible, but caused other problems because each system had its own set of userids and passwords. The solution came in the form of separate security software.

Security Software: ACF2, RACF, TopSecret

As more and more userid-based systems came into use, people found that they needed to memorize several different userids and passwords: one set for CICS, another for IMS, and yet another for TSO. The solution was the introduction of software dedicated to security, notably, ACF2, RACF, and TopSecret. These packages let people use the same userid and password with any on-line system, since TSO, IMS, CICS, and other on-line software would turn to the security software to establish users' identities.

While there seem to be many differences among these security software products, they all provide two basic functions: establish a user's identity, usually by verifying his password, and determining whether the user is permitted to perform some action, such as opening a dataset. All three packages create a control block in memory called the ACEE, (Access Control Environment Element), when a user's identify is established. The ACEE is then used to describe the user and his privileges when determining what he should be allowed to do.

Of these three security packages, IBM's RACF was developed first, in the early 1970's. ACF2 was developed independently, in response to perceived shortcomings in the way RACF then functioned. In particular, the original RACF was missing two important features: always-call and protect-all.

Always-call means that the security software is called every time a dataset is opened. Originally the OPEN function would only call RACF under certain conditions, such as when a RACF flag was set for the dataset, or if the user had certain attributes. The result was incomplete security. In contrast, ACF2 dynamically modified the OPEN function to call ACF2 for every dataset. This made ACF2 both easier to use and more effective. Eventually, IBM added the always-call feature to the OPEN function.

Although the always-call concept applied originally to the opening of datasets, many people now consider it in other contexts, such as sign-on to CICS, execution of IMS transactions, and execution of operator commands. For each of these, the key question is whether the security software always receives control.

Protect-all means that every dataset must be defined to the security software. This was the default condition with ACF2, but was later added as an option with RACF. Since adding always-call and protect-all, RACF's market share has increased significantly.

As with always-call, the protect-all concept has been applied to new contexts. For example, when a user tries to execute a CICS transaction, CICS can call the security software to determine whether or not to allow the transaction. If the security software returns a code indicating that the transaction ID is not defined, then CICS does not allow the request.

TopSecret was developed last of the three major products. Although ACF2 and TopSecret were developed independently, both are now marketed and supported by Computer Associates International as CA-ACF2 and CA-TopSecret. IBM continues to market and support RACF.

While RACF is now considered to have the greatest market share, knowledgeable people seem to agree that all three products do an excellent job of providing security. There are minor functional and usability differences among them, but all three do the job well.

Each of these products improved security by providing a single means of identifying a user, as well as a single means of determining what functions that user was allowed to perform. But then IBM's strategic database software DB2 came along, featuring its own built-in security system, ways of defining users, and ways of determining what a user can do. This was a temporary setback to the notion of centralized security administration that had been achieved with the separate security packages. Computer Associates has since enhanced ACF2 and TopSecret to handle DB2 security under their own architecture. IBM has since provided its own DB2-RACF interface.

RECENT DEVELOPMENTS (as of 1995)

More recent stages of the evolution in MVS security involve new SAF calls, security labels and tokens, greater support and demand for encryption, and the need for better security over the new "open" systems.

In the past decade, MVS security evolution has made a major jump, partly in response to the Federal government's rating system for computer security. The Orange Book rating system, which was developed and promulgated by the National Computer Security Center (NCSC), extends from A to D, and the ratings are further divided, for example, C1 and C2. ACF2, RACF, and TopSecret have all earned a B1 rating from the NCSC. Technically, the rating applies to a combination of hardware and software, including MVS but excluding CICS. However, most people think of the rating as applying primarily to the security software, not to the whole configuration.

New SAF Calls

To earn the B1 rating for RACF, IBM realized it would also need to make changes to system software including MVS, JES, VTAM, and VSAM. They inserted SAF calls at appropriate points in these system software programs allowing RACF to obtain control from the SAF calls.

These new SAF calls provide security for functions such as control over access to print and sysout files on the JES spool, the ability to execute operator commands, the ability to open a VTAM access control buffer (ACB), submission of jobs to the internal reader with a different userid (without providing the password), allocation of certain types of unit record device, and use of RJE (Remote Job Entry) and NJE (Network Job Entry).

The new SAF calls also provide support for the concept of a trusted system. When one data center submits jobs to be executed at another data center, the two computers involved communicate through the NJE facility of JES. For example, say a New York data center submits batch jobs through NJE for execution in a San Francisco data center. The San Francisco data center can refuse the jobs, or it can accept them but require passwords and userids on each JOB card. However, if San Francisco considers New York to be a trusted system, then it can accept the jobs and the New York userids, without requiring passwords. In effect, San Francisco is trusting that New York has verified the identity of the user associated with each batch job. If San Francisco and New York have different naming conventions, then San Francisco can translate New York userids to the corresponding San Francisco userids.

The new SAF calls also provided support for access based upon a batch job's origin, or Port of Entry. The Port of Entry is the place the batch job entered the system, for example from the card reader, the internal reader, from a TSO SUBMIT command, from an RJE station, or from an NJE node. This provides the ability to grant a user, for example, read access to a dataset, but only if the user entered the system from the New York NJE node.

Security Labels and Tokens

Security labels are names, up to eight characters, which can be assigned to users, jobs, datasets, and resources. Security labels are defined as the combination of two other concepts: categories and levels.

A security category is simply a name associated with a particular type of data. For example, marketing, finance, operations, and EDP could all be categories for data. In another implementation, categories could represent customers, accounts, branches, and suppliers. Many other grouping of data into categories can be constructed. Categories are first defined to the security software, and then can be assigned to users, datasets, and resources.

A security level is a hierarchical characterization of data. For example, depending upon its sensitivity, data might be assigned such levels as: Public, Private, Secret, and For-Your-Eyes-Only. Each of these levels would have a higher value than the level which precede it. As with categories, security levels can be associated with users, datasets, and resources.

When a level is combined with zero or more categories, the resulting construct is termed a label. A label might, for instance, combine the Secret level with Marketing and Finance categories. If label checking is rigorously enforced, a user might be able to access data and resources only when he is logged on with the appropriate security label. With full label checking, a user can be prevented from copying data with one label to a dataset with a different label. This makes it possible to permit access to each label's data, but only one label at a time. For example, a user could be allowed to look at both marketing and finance data but prevented from making marketing data accessible to finance people.

Few organizations other than those dealing with the Pentagon make use of security labels, categories, or levels.

RECENT DEVELOPMENTS (as of 2007)

Even more recently:

• IBM has re-packaged MVS as part of the OS/390 system, and (in the year 2000) as part of the z/OS system. Both of these systems include MVS along with several other software components. Z/OS provides 64 bit addressing. It also provides support for "sysplexes" (collections of computers connected by fiber optic cable) which provide extreme reliability. IBM states that with a properly configured sysplex, you should expect no more than 3 to 4 minutes of unscheduled down time per YEAR. Many mainframe installations now re-IPL (start up) the system only once every three or four months.
• Knowledgable people are less willing to rely on passwords as a way to prove a person's identity. Instead, there is a strong movement towards other methods: biometrics, encryption, and hand-held tokens. Encryption methods include both Kerberos and SSL (Secure Sockets Layer) and the successor to SSL, TLS (Transport Layer Security).
• Cross-Platform security standards are becoming widely implemented on IBM mainframes and other platforms, including Windows 2000 and Novell. These standards include: Kerberos, digital certificates, DCE (Distributed Computing Environment), and SSL (Secure Sockets Layer). IBM supports these all in a secure fashion with: MVS, RACF, USS (UNIX under MVS, aka OMVS) security, the mainframe firewall, TCP/IP security, and the Websphere (World Wide Web Server) security.

Encryption

Until recently the primary standard for encryption was DES (the federal Data Encryption Standard), which is commonly used in both hardware and software implementation to provide encryption for MVS and other computer systems. DES uses a single key for both encrypting and decrypting data. Encryption methods which such as DES are called "private key encryption", since the key used for encryption and decryption must be kept secret. A clearer name for such systems (which we will use in this article) is "One Key Systems", since they use only one key for both encryption and decryption.

A more recent development is public key encryption which uses separate keys for encryption and for decryption. RSA is a well known example of such an encryption system. A clearer name for such systems is "Two Key Systems", since they use a two keys, one for encryption and one for decryption. The keys come in matched pairs: a message encrypted with either key of the pair can be decrypted ONLY with the other key of the pair. Public key systems make it possible for a person to publish one of his encryption keys, for example, in a telephone directory. This allows users to send messages to that person that only that person can decode, since he knows the other key of the pair. Each pair of keys then is considered to consist of a "public key" and a "secret key". This lays the foundation for mechanisms that can establish another user's identity. The first user can send an encrypted message to the second user, after encrypting the message with the second user's public key. The second user then decrypts it, re-encrypts it with the first user's public key, and sends it back to the first user. When the re-encrypted message is received and successfully decrypted, then the first user knows that only the second user could have decrypted and re- encrypted that message correctly. In this way it is possible to verify the identity of another user without having to exchange secret passwords. IBM has added both hardware and software support for DES, RSA, and other encryption algorithms with recent releases of MVS.

You can see that "two key" systems are only as reliable as the phone book, or whatever source is used to provide the public key of another user. In real life, we don't use phone books. Rather, we use "Certifying Authorities" or CAs. The RACF database can serve as such CA, that is, a reliable source for users' public keys. Companies such as Verisign can also serve as CAs.

A message from a CA telling you some user's public key is called a "digital certificate". For digital certificates to be reliable, we need to be able to trust the security provided by MVS and by all the other system software (including browsers such as Netscape and Internet Explorer).

IBM provides extremely strong security with current releases of MVS, RACF, USS (UNIX under MVS, also known as OMVS), TCP/IP, and Websphere. TCP/IP security is supported by the the mainframe firewall (now called "Policy Agent"), a tool which filters messages between the mainframe, local intranets, and the Internet and which also provides intrusion detection). Additional TCP/IP security is provided by the SERVAUTH resource class, which uses the security software to control access to ports, to IP addresses, and to other resources. It is the responsibility of the Data Security Officer to ensure that these software tools are configured in such a way as to provide effective security.

The Need for Better Security Over the New "Open" Systems

As IBM increases the flexibility of interconnections among systems, it becomes more important to maintain a consistent security philosophy and architecture across the connection points. Examples of easier interconnection facilities include: the APPN feature of VTAM which lets networks interconnect more easily; the high level language facility of DB2 which lets users make calls to DB2 in any standard programming language; the DDF or Distributed Data Facility of DB2, which lets one copy of DB2 access data on a DB2 system in another data center; connection of LANs (Local Area Networks); and LU6.2, the communications protocol which makes it easier to establish connections between different types of hardware and software).

More recently, interconnection is made easier by software which IBM gives us with the z/OS system (including MVS). These include: MQ Series, USS (Unix under MVS, formerly called OMVS), TCP/IP, and the Websphere Server which connects the mainframe to the Internet.

Each of these facilities presents an opportunity for the user identification and access control functions to break down across the boundaries of interconnected systems. Perhaps the best known example of this is the way DB2 employs its own security sub-system, defining in its own way who a user is, and what each user can do. ACF2, TopSecret, and RACF all now provide DB2 interfaces to re-integrate DB2 security with the rest of the mainframe software.

Other security developments on the mainframe include: complete support for JAVA security (including a hardware JAVA byte-code accelerator), encryption for tapes provided by the hardware in the tape drives, and hardware encryption processors for the mainframe.

Looking Ahead

If we project the evolution of MVS security into the future, we might expect to see a number of these developments become increasingly important:

• More use of software rather than hardware tools, with a corresponding need for greater enforcement and standards.

• Increasing interconnection of MVS systems with other computers including the Internet, with a corresponding increase in the need to define and enforce the sphere of influence and degree of trust for the security tools on both sides of each interconnection.

• More software products which increase functionality and flexibility while introducing the possibility of greater exposure.

• More use of address spaces to provide control by isolation.

• Greater use of DB2, with greater need to integrate its security with that of the operating system

• Widespread acceptance of the need for a single security tool (such as ACF2, RACF, or TopSecret) implemented rigorously and automatically within a clearly defined sphere of influence (eg: "All MVS computers in this data center will use software package X for all security functions.")

• Less reliance on tools which have not worked well in the past - notably those which rely on terminal identification, flags being set, hardcoding, or a non-standard way of defining a user's identity.

• Increased use of encryption

• Parallel evolution of security on personal computers. The 80486 chip from Intel already supports address spaces and a mode similar to supervisor state. For personal computers, we need to consider whether we are likely to repeat all the lessons we learned the hard way with MVS, and whether we can profit from the experience.

• The following areas are often considered to be the areas of greatest weakness in mainframe (and other platform) security, and will need to be addressed: passwords, tape datasets, residual data on tape and disk, protection of printouts on the print queue, control of operator commands, TCP/IP and the Internet, APPN connections between your organization's SNA network and those of your business partners. (No, SNA is not going away any time soon. It may tunnel through TCP/IP, or have TCP/IP tunnel through it, but it will be with us for a long, long time.)

  Further, any organization which uses LANs (Local Area Networks) for users to log onto the mainframe will run the risk of a sniffer program executing on one workstation and learning all the userids and passwords of everyone on that subnet. This is a LAN issue, not a mainframe issue. However, it can be protected against by use of encryption, either Kerberos or SSL/TLS. The mainframe supports all of these (as does Active Directory on Windows).

  For all of these issues, the tools are available to provide effective security, for example: Erase-on-scratch (which is called AUTOERASE in ACF2 and Top Secret), the Policy Agent software which provides filtering of TCP/IP messages and intrusion detection, hardware encryption on tape drives, resource classes such as SERVAUTH, JESSPOOL, OPERCMDS, and VTAMAPPL.

What This Means to the Security Professional and to Auditors

Successful security implementations in the future will be both rigorous and automatic. They will rely on a single tool to establish a user's identity and to determine what users can do. They will recognize the boundaries within which a given security tool is effective (eg: a specific data center or particular network), and will provide clear ways of handling trust issues and name translation between security mechanisms. Mainframes will be connected to the Internet, requiring organization-wide configuration of firewalls. Security officers and auditors will need to understand not just MVS, but also: UNIX, TCP/IP, firewalls, and the Internet.

Security officers and auditors will want to look for opportunities to:

• Make security automatic and rigorous and comprehensive, by encouraging the concepts of protect-all and always-call.

• Coordinate naming conventions for userids, datasets, and resources, as well as assigment of UNIX UIDs and GIDs, and names for users on other platforms.

• Provide for translation of userids, nodes, and other names between different security software and between different networks.

• Centralize on a single means of identifying a user and determining what a user is permitted to do. For most MVS installations this will be one of the big three security software products. But it will not be sufficient merely to have one of these products implemented; There is a need to establish standards and enforcement that ALL applications and purchased software will work within the overall security architecture and strategy.

• Develop a strategy to integrate security for software like DB2 and MQ Series with the rest of MVS security.

• Identify computer systems and LANs which are connected or are likely to be connected to your own organization's computers, in order to identify the degree of trust possible and to initiate security based on that trust.

• Address network security, including both TCP/IP and APPN (with SNA).

About the Author

Stuart Henderson is an experienced consultant and trainer who specializes in effective IT audits and computer security. He has helped hundreds of organizations make better use of security software such as RACF, ACF2, and TopSecret. He has also helped these organizations address the technical and organizational issues surrounding cross-platform security. As President of the Henderson Group, he directs a variety of activities in support of the computer security and IT audit communities. These include: seminars, consulting services, articles, and speeches. He is an experienced system programmer who has earned the Certified Internal Auditor, Certified Management Accountant, and Certified Data Processor designations. His seminars on computer security and audit of: MVS, DB2, RACF, VTAM, Windows 2000, and other subjects are taught nationwide. He teaches Certified Information Systems Auditor review courses for the National Capital Area Chapter of the ISACA.

He speaks to groups such as the Computer Security Institute, the DPMA, the ISSA, and the ISACA. Some of his topics have been: "What System Programmers Know that DSOs and EDP Auditors Should (or How I Would Break into Your System and What You Should be Doing to Stop Me)", What Non-Data Processing Executives Should Know and Do About Computer Security", "Combining VAX/VMS Security with IBM Mainframe Security", and "Tools for Maintaining Single Point of Control for Security". He is founder of the New York RACF Users Group and Editor of its newsletter. His website is http://www.stuhenderson.com. He can be reached at (301) 229-7187 or stu@stuhenderson.com.