Controlling VM with ACF2

Computer Audit Update July 1993

CONTROLLING VM WITH ACF2

Alison Webb

The most interesting part of a technical audit often comes at the stage when, having absorbed the principles of the system that needs to be secured and the system that's being used to secure it, you compare one with another. This article looks at some of the questions you might ask about the security of your VM site; at where and how ACF2 might be used; and how you might check to see what is happening in practice.

There are always plenty of quirks in the way work is organized and distributed at a particular site, which means that what the manual says is a good thing to do, isn't always workable in practice. For this reason, this article isn't an audit program: a lot will depend on the key applications running at your site what sort of machines they run on and who the other users are. What I've tried to do is to provide usable information so that when you've decided what your key audit objectives are, you'll be able to design a detailed program, and have to hand a summary of the technical reference material you'l l need. Obv ious ly , you wil l need the ACF2 documentation as well, especiallythe User Guide and the Repor ts and Ut i l i t ies Manuals . Unfortunately, there's no separate Auditors' Guide.

In the last article (see June issue), I outlined the two chief risks in a multi-user system like VM as:

• other users might be able to log on to our machine; and

• other machines might be able to access the information we're processing on our machine.

For the audit, you may want to break them down into a series of subsidiary questions, linked to what you find is happening in practice.

1. Do the global ACF2 options provide the level of security we need?

Display these using ACF SHOW ALL, as I described in the last article.

Exactly what matters depends on how your site is run, but normally worth looking at would be:

MODE: determines whether security violations prevent the user being given what he wants, or whether some milder action (logging, warning or nothing at all) is taken. You can have different modes for access, command and diagnose rules, and all three should be set to ABORT;

MAXVIO: is the number of violations allowed before a batch job terminates;

CONTROL: If CENTRAL, only the security administrator is allowed to change the access rules. If not, a user can adjust rules whose ID matches his or her own;

ZEROFIELDS: prevents mistakes in creating new Iogon IDs. To make this quicker, the administrator can copy an existing record as the basis for the new one. To stop privileges being allocated inadvertently, you can specify that certain fields will not be copied over when this method is used. They should include SECURITY, ACCOUNT, NON-CNCL, AUTOALL, AUDIT and READALL.

2. Are users checked properly before they are allowed access?

As I've said, ACF2 authenticates users by associating a password with each Iogon ID. There are two questions to ask:

• are the password rules imposed by the global options secure enough?

The password rules are defined in the settings of global options in the software (display them using the ACF enquiry facility). The most important are the password length, the number of invalid attempts allowed per day before the user

8 ©1993 Elsevier Science Publishers Ltd

July 1993 Computer Audit Update

is suspended, and whether or not he/she is forced to change passwords the first time he/she logs on after the expiry date;

• is anyone having an easy time?

Some password rules can be set specifically for each user, inc luding MAXDAYS and MINDAYS, the largest and smallest intervals allowed between password changes. It is often instructive to list users with MAXDAYS of zero: they never have to change their passwords. You can do this most easily using the SL report with the 'IF' selection.

3. What mistakes are users making in practice?

A standard ACF2 report lists password violations in the period covered by the SMF records you choose to read. There's also a field on the Iogon ID record which shows you the date the user last put in a wrong password.

4. Are there rules to stop people getting at others' data?

If you identify the machines you think might process sensitive data, and machines you think ought to be fairly restricted in what they can see, then you can run ACF2 cross-reference reports which list:

which machines can access the disk areas associated with a particular VM machine, and what rights they have;

which disk areas a particular Iogon ID can access (i.e. the processing looks through all the access rules or that Iogon ID).

rd look particularly at which IDs have WRITE access to MAINT's minidisks; these contain operating system code and so I would expect them to be restricted to the people responsible for maintaining live code.

5. Have they tried even though they haven't got access?

A standard report lists access attempts made, which violate the rules.

6. Who decides what the access rules should be?

ACF2 writes any changes to the access rules to the log, and you can list them on the RL report. You should find the reason for the change documented as part of the change-control system; or as part of the procedures for installing new users.

7. Are there any back-doors?

In fact, there are quite a few:

overlapping disk areas: does someone check that disk areas allocated to machines do not overlap?

Whoever is operating VM will issue the commands that allocate physical disk space to individual machines each time he/she makes a new entry in the VM directory. How does he/she know he/she isn't allocating someone else's area, and how do I know, as auditor, that they've guarded against this possibility?

If the'site uses the VM utility DIRMAINT to change entries in the VM directory, then ACF2 reports everything it's done (DL report) and also highlights any minidisk overlaps. Many sites use third-party products like VMDIRECT, which manage physical disk space and prevent human errors. (You should be aware that sometimes, overlapping minidisks are defined deliberately: e.g. to let an operator access a whole disk to do backing up.);

• can users read data on temporary disk space they share with other users?

VM allocates temporary work space on disk to users from a pool. If the area allocated isn't cleared before use, there is a risk that a user may read data left on it from its last allocation.

It is easy to prevent this, by choosing the right option in either (if you use VM/XA) the VM macro which specifies the major system parameters, or in the ACF2 field definition record. If your site relies just on the VM macro, you should be aware that any VM command class B user can turn off the clearing by using the SET command. There

©1993 Elsevier Science Publishers Ltd 9


should therefore be an ACF rule to limit the use of it;

• what happens to the data on the disks when a machine is dismantled?

It's possible to set up DIRMAINT so deleted disks are cleared by default. Any such deletions will be logged and can be reported on the DL report, so if the default is over-ridden, it'll be obvious.

8. Can ACF2 control tapes?

If the tape datasets belong to our applications on VSE, can we expect ACF2 on VM to guard them for us? Once working under VSE, our local users may be denied access: but what will happen if foreigners on other machines call for our tapes by serial number and define them as unlabelled?

It is possible to define a list of tape serial numbers for ACF2 to check each time they're loaded: but often this is simply impractical. Where VM runs a number of VSE machines for customers of an FM supplier, for instance, each customer will have its own tape numbering system. Serial numbers may well overlap, but no-one will be willing to re-number the tapes because of the work involved.

Controlling this sort of risk usually depends on strict security rules over the handling of tapes.

9. Who can bypass the boundaries between systems to read our data?

What I've said above about the MAINT machine, and the way VM provides central services implies that it is possible in some circumstances for one machine to read another's data.

The basic control is via the access rules, but there are other ways to get access:

Access privileges

Any security system can give access rights to key users which over-ride the rules. ACF2 users with the attribute NON-CNCL can access all data and are never cancelled by ACF2 for

security violations. Read access to all data is granted to all users with the READALL attribute. These two at t r ibutes should usual ly be associated only with the machine that does the backing-up; because they bypass validation and logging, they make it more efficient.

With AUDIT authority, you can use the SL report to list all users with specific attributes, and satisfy yourself the rights are necessary.

Using a VM command to access a whole disk pack

To back up a whole DASD volume the machine that does it needs access to all of it. The simplest way of giving a user full access is to let him/her ATTACH his/her machine to the entire volume. This has two drawbacks: the ATTACH'd user can have write access to the entire volume; and, while ATTACH'd, he/she prevents anyone else using the volume at all. ATTACH should be limited by a command rule, if it's used. An alternative would be the way I mentioned above: to define a minidisk, which maps the entire DASD volume and will therefore overlap with the minidisks defined to separate Iogonids. The user can then have READALL access, and nothing needs to be changed between back-ups.

Using spool commands

A single area on disk is used to store print files, reader files and punch files created by every virtual machine on the system. Four CP commands associated with the spooling system can be executed by any user; VM Class G users can only affect their own files; class D users can target any fi les on the system. The four commands are:

SPOOL and CHANGE: to change the output class, number of copies, hold status and form type;

PURGE: to remove unwanted files;

TRANSFER: to move files from one user or queue to another.

Command- l imi t ing rules can help by


July 1993 Computer Audit Update

restricting who can act as a spool operator; and by logging what they do.

Using DIAL

The VM DIAL command can be very insecure because it allows a VM user to dial into another user's machine and use its facilities without any security checking. It's roughly equivalent to the 'trusted host' automatic Iogin found on Unix networks because in both cases, the machine allowing the access is relying to some extent on how well security on the accessing machine is managed.

ACF2 stops this by introducing an ID and password check every time the DIAL command is issued, and then looking to see what DIAL resource rules are set up. These resources rules list for each user when and who they are allowed to DIAL, and if the access is to be logged. If none are set up, then no-one can DIAL. It's also possible to introduce fine-tuning with command limiting rules, for example to limit CMS users to one CICS region on a VSE machine.

To allow some flexibility, ACF2 lets you give a machine the attribute, DIALBYP. This negates the protection and allows anyone to access the machine without being checked. In practice, it may be misused, as giving a machine DIALBYP is much easier and quicker than thinking out what may be complicated rules. Keeping out intruders then depends on the security installed on the machine being DIAL'd.

Using AUTOLOG

The modular nature of VM means that many of the system functions run as separate virtual machines. I've mentioned MAINT and the ACF2 machine; there are others for performance monitoring, database management and so on. Some sites automate their back-up routines by letting a service machine execute the necessary commands. These machines must all be logged on at appropriate times. To simplify the process, VM starts one or more machines as part of the IPL process, which themselves start the service machines by issuing AUTOLOG commands. ACF2 resource-protects AUTOLOG, like DIAL, by default, leaving you to write the resource and command-limiting rules you need.

A well-recognized practical problem with AUTOLOG is passwords. As auditors, we'll insist that the passwords for each machine are changed regularly, but if they're AUTOLOG'd, the scripts run by the machine that logs them on have to be changed every time. It also means that passwords (which are kept carefully encrypted within ACF2) are written in clear text in the script file. To overcome this, ACF2 allows two ways, depending on Iogon ID attributes, of logging on a machine without entering a password:

the machine doing the logging-on has AUTO- ALL. Obviously, such a machine must be kept very secure;

the machine being logged on has AUTON- OPW. Anyone trying to AUTOLOG it need not enter a password. This means it's still important to restrict the AUTOLOG command properly.

10. How do I know ACF2 runs all the t ime?

Normally, the ACF2 machine is AUTOLOG'd immediately after IPL. If it isn't, no-one can use the system, as all data requests will be refused at the exit point where the ACF2 modules are installed.

To cope with emergencies, you specify 'force Iogonids' when you install ACF2; these and only these IDs will be allowed unrestricted access to a system where the ACF2 service machine is not running. You can choose whether VM will check its directory password when the ID is entered in an emergency (ACF2 lists the force IDs and the setting of the password option as part of the output from the SHOW command).

What this means in practice is that you have to trust somebody. There doesn't seem to be any log record written when the ACF2 machine starts up, so you can't check whether or not it has started at each IPL; the best you can do is make sure the force IDs have passwords.

11. What else should I check?

As I've said, each VM installation will have its own particular configuration, which you must take into account as you evaluate your answers to the audit questions rve listed. I haven't, for example,

©1993 Elsevier Science Publishers Ltd 11


mentioned any of the exit processing, apart from that introduced by ACF2, which your site may have.

Equally, what I've said applies where all the machines under one VM belong to one organizat ion. It is much harder to audit successfully where an facilities management provider runs your applications. The provider, for the security of his other customers, will want to limit the scope of your enquiries, and can easily do this by defining a SCOPELIST for your ID, so your audit privilege only extends to the machines on the list. How, for example, will you know which machines belonging to other FM customers have the SECURITY or ACCOUNT attribute and possibly without a scopelist? How will you be sure someone else's spool operator doesn't read, copy or delete your files.

As with most computer audits, you can't pull a standard audit programme out of the cupboard and expect it to do everything. On the other hand, it is understanding the environment you're working in, and adapting the work you do to meet special circumstances, which makes the job interesting.

Alison Webb is an independent computer audit specialist. She divides her time between advising on security for specific applications, mainframe control and security reviews, general reviews of computer installations, and file interrogation. She also lectures and writes on computer audit topics.

IT SECURITY TESTING m A PRACTICAL GUIDE PART 9

THE FOLLOW UP PROCESS

Bernard Robertson and David Pullen PA Consulting Group

This article concludes this series on the subject of IT security testing. It describes the

follow up process that will be required to correct the problems identified during security testing. This article details the objectives, process and common issues associated with a follow up process and gives hints and examples of how an effective follow up may be achieved.

Objectives

The primary short term objective of a follow up programme is to improve the level of security of the target system. This primary objective depends upon a number of supporting objectives which are:

to get the results of the test exercise fully accepted by senior management. In some cases management may prefer to ignore security testing, through fear, embarrassment or lack of visibility. This attitude needs to be overcome to develop an action plan with agreed priorities and deadlines;

to ensure that the identified actions are im- plemented -- th is will normally involve correc- ting system errors and shortcomings to ensure that adequate funding and manpower is available.

Common medium term objectives are to:

make sure that all new systems are designed, tested and operated with the appropriate security measures borne in mind;

• ensure that securitytesting is included as part of the standard development cycle.

A longer term objective is to create a culture change within the group responsible for the tested system to ensure that all security aspects are considered, tested and adhered to.

Process

After having distributed the final test report the key activities in a successful follow up programme are to:

• organize a meeting with system management to discuss key findings and their impact. This


Controlling VM with ACF2

Documents

Transcript of Controlling VM with ACF2