Computer Audit Update December 1993

References

1. Compulink Information Exchange +44 81 390 8446.

2. Demon Internet Services +44 81 343 3881.

3. The Internet Companion by Tracy LaQuey and Jeanne C. Ryer, published by Addison Wesley at £9.95.

Kenneth R. Lindup is a senior consultant at SRI International, UK. He can be contacted on: tel : +44 81 686 5555; E-maih Ken_lindup@croydon. sri. co. uk.

NETWORKS AND SECURITY: THE ROLE OF THE SESSION MANAGER

Alison Webb

Networked computers are commonplace now, and they offer enormous advantages. Many of us feel that without cash machines and electronic banking, the quality of life would decline substantially. People or processes working remotely can pool their results centrally, so everyone can share them more quickly. It means that network security is high on the agenda of most computer auditors. And yet, the phrase 'network security' is almost an oxymoron: we are not trying to restrict when we set up networks, but trying to give as many people as possible access to systems and information.

Auditors do not overlook this when Unix processors are being joined together. The risks in making remote connections easy for users by employ ing t rus ted hosts and users are well-documented and widely-known. Because it's acknowledged that end users can themselves decide to some extent how they will protect their

data, and that this autonomy must be policed, Unix secur i ty admin is t ra t ion is now an established role at any networked installation. Most users who share a common network agree to conform to a set of minimal security standards to ensure their own and others' privacy and to keep the data safe. Perhaps because Unix can be so obviously open, it has forced its users to think seriously about network security.

In parallel with the growth in Unix networking are changes and extensions to SNA. They have attracted rather less attention, perhaps partly because the use of SNA isn't growing like that of TCP/IP, and partly because we looked at the security problems ten years ago and we think we know what they are, and how to solve them. However, in those days, most such networks were single-domain (one key processor ran applications which were accessed remotely as well as locally); and the security and control problems in such a network were more easily identified and addressed than they can be in today's more complex environments. The danger is that solutions acceptable then have not been reassessed since; and may no longer be adequate.

What is a session manager?

I was forcibly reminded of this recently, when reviewing the implementation of a session manager, TUBES on MVS.

Most people who use a mainframe system have encountered a session manager in one form or another: it manages the connections between the user and his/her applications, hiding the complexity. It's the mainframe equivalent of Windows, a way for the user to move easily between the applications he/she is using without wasting time.

Without such a manager, users must negotiate with the base software any network runs to put the user in contact with the processor: VTAM software for a mainframe IBM site. VTAM recognizes terminals and applications, and if it receives the right command, will put one in touch

10 @1993 Elsevier Science Publishers Ltd

December 1993 Computer Audit Update

with the other. The initiating command can come from either end. As a terminal user, I may request a particular application: a CICS region, for example, or the CICS region may issue a command when it wants to print at a remote printer.

How exactly do I request CICS? If I'm not using a session manager, the form of the commands VTAM will accept from me is set out in a table - - 'the unformatted systems services table' or USSTAB-- associated with my terminal. Essentially, all I can do is to log on to a VTAM application, and to log off again when I've finished, but to make life simpler, the table can be set up so when I type in 'PRODCICS', it will translate that into a request to log on to production CICS; and send me the appropriate screen.

The shortcoming with the most immediate practical impact is the one I've already implied in passing: a user who normally uses several applications regularly in the course of his/her work will spend a lot of time logging on and logging off during a typical day, because he/she must free his/her terminal from one application before attaching it to another.

Secondly, although you can use message processing to some extent to present the user with a VTAM logo and maybe a menu of options, the menu can't - - if terminals are shared by people with different jobs and therefore application needs - - be tailored specifically for one user and so will be larger and more complicated than anyone individually needs. Without the menu, everyone has to remember the exact commands to reach his/her application. These commands may need a string of parameters: almost the equivalent of a string of nonsensical passwords for the end user who is more concerned with, say, his/her project costs or credit control than the workings of MVS or VTAM.

How do they work?

How does the session manager rework the onward connection to the application you want in

a more friendly way? TUBES mediates the connection between the terminal and VTAM, by interposing what it calls virtual terminals. You define names for these virtual terminals within TUBES' parameters when you set the software up. When you request a new session, the manager associates your physical terminal with one of the virtual definitions, and uses VTAM to establish a session between the application and the virtual terminal. It's possible to attach a number of virtual terminals to one physical terminal, so you can have several sessions going simultaneously and hot-key between them. This removes the major disadvantage of VTAM and saves hours a day in logging on/off time.

A session manager will itself run as a VTAM application. (If you like, you can stick to the old VTAM access method and call it up when you want, perhaps when you can't remember the commands, just as for the CICS application I described above). For most end users, life will be easier if they work entirely through the session manager and you can enforce this by making sure all the terminals they use are automatically put into the session manager when they're swi tched on. You do this by coding LOGAPPL=session-manager-name in the VTAM LU definitions for your terminals.

The user profile

The other advantage for users is that unlike VTAM, the session manager recognizes them as people, not terminals, and so can supply them with individually-tailored menus.

Normally, each user is defined separately to the session manager.

His/her user ID will be listed in a user table, together with other entries which decide how his/her use of the system will be managed. For TUBES, the key entry is the user's profile, which defines:

The set of applications he/she can use (the names are the ones VTAM uses).

What the user must do to call up the applica-

@1993 Elsevier Science Publishers Ltd 11

Computer Audit Update December 1993

tion, e.g. entering a name, or pressing a pf key.

The way the options will be presented to the user on a menu. You must specify a default menu, which the system will use if you don't put an entry here, and there can only be one menu screen specified per user.

Any overrides to defaults set for all users of the system. An example would be an alterna- tive to the standard autologoff period.

Any special processing you want when the user first selects the application, or when he/she leaves it. Both of these are important for security, and I discuss them in more detail below

What about security?

The use of a session manager offers some very obvious advantages for site security, which most installations have been pleased to exploit.

By linking terminals to TUBES using the LOGAPPL setting in the VTAM terminal definition, you stop anyone working at such a terminal arriving at an application except via TUBES. This means that if you do a security check to authenticate your user as soon as he/she switches on the terminal and then restrict him/her to a menu of options, theoretically, there's no need to repeat the check when he/she reaches his/her chosen application. This has the advantage that the user will now have to remember just one ID/password combination for all mainframe applications he/she uses with perhaps only specially sensitive data needing extra checks.

Many sites have chosen to use this rather elegant security simplification. In TUBES, the initial session manager screen invites the user to sign-on using a user ID and password, and uses processing exits to pass the information to major security packages like RACF and ACF2 for authenticating before allowing the user to do

anything further. The processing can be sophisticated enough to check the password expiry date, forcing the user to change passwords if necessary, and to log the access attempt and its result in the SMF records. It can also pass the physical terminal address to RACF, so this appears in the SMF log, rather than the virtual terminal ID, which is really of no use at all. Even before attempting to reach an application, the user's credentials are checked.

The next stage, the processing of the user's profile, limits users because if the function isn't defined for you, then you can't reach it. This is how security works on small systems: there is an initial authorization check at Iogon time, but then what you can do is restricted simply by menus. A problem with this, which may be negligible or manageable at a small site, happens when an exit in an application allows you to move outside it without returning to the manager's menu screen. An example would be using the Windows exit to get the DOS prompt: the user can then use any DOS function, and is not restricted by menus. The equivalent in a mainframe site occurs when, say, the session manager application selection screen is used to put the user straight into a CICS application. What happens when he/she leaves this application? If he/she gets a blank CICS screen, this is in some ways the equivalent of the DOS C: prompt, and he/she may then be able to use CICS transactions within the same region which have no front-end protection.

So the solution can work well, but only if whoever administers TUBES is meticulous about defining users securely:

• The user's menu must be right, or they will reach applications they should not see.

The profile processing must take them tidily into an application session and out of it back to the menu screen in all circumstances, in- cluding network failure, or they may be able to reach other applications.

12 @1993 Elsevier Science Publishers Ltd

December 1993 Computer Audit Update

No application should let a user escape from it to a less well-controlled environment. One instance of this would be the blank ClCS screen described above, but it also applies to TUBES itself. There should be no need for end users to have command-level access, for example.

For the same reason, the default menu, which appears if a user passes the authentication check but isn't in the TUBES list, must be harmless - - for example, a single option which allows the user to log off, and no more.

What does this mean for networking?

The popularity of session managers means that many sites now pay much less attention to application security than they might have done five years ago, relying on the session manager security and the menu processing for protection.

This may be a considerable disadvantage where the site does not remain isolated, but becomes part of a network. Outsiders defined to VTAM's on other processors won't necessarily play fair by using session managers of their own. If they use just VTAM, then their users can have a go at logging on to any application they choose - - yours included. Reprisals may not be easy. As security administrator for one isolated processor, the job has boundaries: it's possible to list all the people who need to access your system, check what they're doing and discipline them if they misuse their rights. If your processors are connected to an extensive network, who knows what other machines are part of the same network, and even if you find this out, how will you identify all the potential users, let alone how they are controlled?

It seems to me that security administrators should reassess security when they become part of a multi-domain network, and particularly if they share that network with outsiders. If application security has decayed, the solution must be to reauthenticate users before they use each application defined to VTAM. This shouldn't be difficult, or costly, as most applications these days come provided with at least an exit that can

be used for the purpose, and for some, like CICS, for example, there are facilities within the security package to check users- - but the consequences of not doing so could be serious.

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

THE PURPOSE OF APPLICATION REVIEWS

Chris Nelms

An application review is a review of an existing system which was not necessarily reviewed during development. Ideally, systems should be reviewed while under development, so that any additional requirements can be included in the design. There is somewhat less scope for making changes once the system has been implemented.

So why review an existing application at all? If it has been in use for several years, is there not a presumption that either it must be working satisfactorily, or any problems must have long since been discovered, and that there is therefore nothing to learn from reviewing it? Not necessarily. There may be latent weaknesses that have gone unnoticed or have received insufficient attention because they have not caused problems yet, and which would not necessarily be discovered in an audit of user departments: e.g. the system may have been producing consistently slightly wrong output; there may be poor access security; poor segregation of duties; poor control of master file data; inadequate documentation making the system difficult to maintain or teach new users; inadequate vendor or in-house support; inadequate backup arrangements, etc. Or it may

@1993 Elsevier Science Publishers Ltd 13