dealing with mvs exposures

UPDATE on Computer Audit, Control and Security

DEALING WITH MVS EXPOSURES

by Martin King

A paper presented to COMPACS "89 (13th InternationalConference on Computer Audit, Security & Control, London, March 1989)

Many audit and security specialists believe that computer viruses will be the most important security issue of the 1990s. But judging from the number of articles that have already appeared in the press, including cover stories from Business Week and Time; we may not have to wait that long. Legislation is already being considered by the US Congress to deal with the threat of computer viruses. Bills such as HRS061, the Cordputer Virus Act of 1988, would make it a Federal crime to develop and spread viruses in the States. But ,prosecutors aren't waiting until new legislation can be passed. Using existing laws, a Texas court convicted a programmer this September of planting a computer 'virus' in his former employer's system. News reports claimed that the virus was activated two days after the programmer was f~red, destroying over 168,000 sales commission records before it was detected. Some experts even see the threat of contaminated software as ending the era of freedom we have had in ex- changing computerised information. One thing is certain. In the light of what has already happened, no one can afford a 'business as usual' attitude. We all must take steps to protect ourselves.

But, since media coverage tends to sensationalise computer abuses and gloss over important technical details, it is often difficult.for us to accurately assess the potential danger to our own systems. The situation is complicated by reporters who lump trap doors, logic bombs, and Tro- jan horses together with viruses. In their view, anything that attacks a system is a virus. In truth, most of these mechanisms have been with us for years, only viruses are new. Predictably, not everyone even agrees what a virus is. Although most security specialists seem to prefer to use the term 'virus' for software programs that can make copies of themselves and spread to new users, a few experts disagree. These purists insist that if we strictly follow the biological model, programs whicl~ reproduce themselves are more properly labelled 'bacteria' or 'p~sts'. Tlae3/feel the term 'virus' should only be applied to a module which infects another to reproduce itself. From their point of view, it isn't a true virus unless'a 'carrier' program is involved.

Although conceding the point, I prefer the broader defin- ition of a computer virus. Few people care that the differ- ence between leprosy and smallpox is that one is a virus

and the other is not. They don' t want either one! So for our purposes, I will define a virus as any software program that has the ability to replicate and spread itself, regardless of whether it is by direct or indirect means. This is the ability that distinguishes a virus froni other system threats.

Fortunately for those of us in the mainframe world, the majority of documented virus incidents have involved personal computers. There are two main reasons for the vulnerability of PCs: lack of internal controls attd sharing of software. Because most PCs were intended to be single user systems, they often lack adequate internal protec- tion mechanisms, making them easy prey for virus programs. Nothing stops a malicious program from attacking either the operating system or application programs. Furthermore, the large scale sharing of programs among PC users contributes to the rapid spread of contaminated software.

/

The good news is that neither of these situations exist in the mainframe world. Systems such as MVS have largely escaped the virus plague because they were designed from the beginning to support multiple users. This means they have the internal control mechanisms to protect both the operating system and other users from malicious programs. It is also true that significantly less software is shared between mainframe users. Thus , the risk of infection from contaminated software is much lower than in the PC world.

Unfortunately, this lower risk is offset by the infinitely greater value of what we have to lose in the mainframe world. General Ledger, Accounts Payable, Accounts Re- ceivable, Personnel, Inventory, etc. are typically mainframe-based systems. Those of us using IBM hardware, depend on business systems which run under CICS, IMS, IDMS, DB2 and other system software. The bad news is that although viruses are considerably more difficult to construct for an environment such as IBM's MVS, they are certainly possible from a technical point of view. Techniques and mechanisms have already been identified which could be used for viral infection and re- plication.

Nor are other mainframe operating systems safe. The in- famous 'IBM Christmas Gremlin' was a VM virus. It

2 Volume 1 Number 6 May/June 1989


COPkRAI ING SYS I I=XPOSUHI:S ) spread over the communications network in the form of a program that generated a Christmas tree shaped message on victims' screens. Recipients were encouraged to run an EXEC to receive a Yule-time greeting. Those curious enoush to do so, were rewarded by being 'infected' by a computer virus. The virus spread rapidly, clogging IBM's internal network for hours before it could be purged. And yet this was a relatively harmless virus. It could have erased all of its victim's data files.

Incidents of viruses spread over telecommunication networks, such as the one that recently infected qver 6,000 UNIX based computers on Internet, add a new dimen- sion of threat. Although most communication network viruses have been benign, some security experts even suggest the potential of international computer ter- rorism. Just as the first airline hijacking forever changed how we view airline travel, computer viruses are forcing a permanent change in how we view data processing. It is clear that we must respond to the threat.

But in order to effectively deal with viruses, we must first understand how software becomes contaminated. Virus programs combine the traditional hacker's logic bombs, Trojan horses, and trap doors with the capability to replicate and spread. For example, the 'Christmas Gremlin' used a Trojan horse approach to trick victims into execut- ing its viral code. Once executed, the virus could reproduce itself and then spread to other computers. Although some purists might classify the 'Christmas Gremlin' as a 'Trojan horse bacterium' or a 'Trojan pest', and not a virus, the potential danger is clear regardless of the final classification assigned during the post-mortem examination.

Viruses can function at either a system level or an application level. Application viruses in an MVS system can only attack the files, libraries, and main memory which can be updated by the victim, whereas system level viruses, i.e. those that infect MVS itself, have no such limitations. They may attack all programs, files, libraries, and even your access control software. Although system viruses are harder to develop, the rewards to a computer criminal are obvious.

It is also true that a well designed virus may enter your system at an application level and then make the transi- tion to the significantly more dangerous system level. However, since most MVS systems have access control software, the virus must find a way to get past the security system and avoid alerting the data centre's security officer,to its presence. Although it is possible that the virus might be able to identify and exploit some obscure MVS integrity exposure, a far more straight forward "technique is available to it. All the virus has to do is wait patiently until its viral codo is executed by a victim who has update access privileges to an Authorised Program Facility (APF) library.

This implies the virus must have logic within it to test the access privileges of its victim. This is easier to do than you may think, since most security software products

allow users to list information about their own userids. For example, a virus running in a RACF controlled system can utilise the L IS TU S ER command to determine the characteristics of the user profile it is being executed under. Either the SPECIAL or OPERATIONS privileges would allow the virus to update APF libraries. Similar commands are available in other access control software packages unless their usage has been restricted.

The critical point here is that once the MVS APF library system has been compromised, supervisor state and the master storageprotection key (key 0) can be quickly obtained. Once the virus has these powers, it can circumvent all security mechanisms and move about the system at will. An APF authorised virus could quickly identify the various locations throughout the MVS environment that it could copy or link edit parts of itself into. System modules, compilers, uti l i ty programs and even TSO CLISTS are attractive candidates. This point should not be lost on those of us who have the job of protecting our systems from viruses. Nothing says the virus has to be a single contiguous load module. In fact, from a computer criminal's point of view, a 'distributed virus' makes a lot of sense.

Very small and highly specialised destruction modules could be designed to fit into system utilities such as language translators and the Linkage Editor, or other utilities which process applications programs. Consider the damage that could be done by a 'bomb generator' that attached a 'time bomb' CSECT to each production application program the utility processed. Over a period of time, a large number of programs would be corrupted. They would have to be identified one-by-one. Even if the bomb generator itself were found and removed, the hidden part of the virus could re-implant it at a later date.

But regardless of the specific technique, the virus will always attempt to find a location where it will be executed by potential victims. This allows the viral program to spread within the infected system or simply remain where it is and plant logic bombs in applications programs. The virus could propagate to other systems via any mechanism that moves load modules or source modules to other computers. JES networks, public domain software, and dial-in terminals with upload/download facilities are the most likely means of propagation. If a user becomes 'infected' through contact with contaminated software, the virus may then spread to other users who are in cotrract with the victim. For example, insiders disclosed that the 'Christmas Gremlin' spread by reading the electronic mail distribution lists of its victims, and then sending itself to everyone on the lists.

Theoretically, viruses could enter an MVS system by exploiting the vulnerability of personal computers. The growing popularity of using PCs as 3270 or similar terminals potentially allows a virus to infect the PC, detect 3270 emulation and insert viral source code during a user's TSO session. The infected PC would intercept and suppress the resulting TSO dialogue until after its mut- ant MVS form was successfully implanted. The infected

Volume 1 Number 6 May/June 1989 3


(OPERATING SYSTEM EXPOSURES ) PC could even purge all spooled job information by en- tering appropriate SDSF or JCL commands. The unsuspecting user would probably assume the signon delay was caused by a brief peak in the MVS workload. The complexity of this approach suggests a relatively large PC virus'program. Unfortunately, the increasing storage capacity of PC disks could probably successfully hide even a large ,~irus program. Other types of viral attacks require significantly less technical sophistication. An MVS system could be brought to its knees by a virus that submitted thousands of spurious lobs through the internal reader, flooding all lob queues. Submission of iobs with valid userids but randomly chosen passwords could cause innocent userids to be sus- pended by the security system. MOUNT commands issued through JCL could disrupt production processing. RESERVES issued against all online share disk packs would disrupt the entire data centre. Nor does the list stop here.

The good news is that the techniques you can use to control viruses are fairly straight forward. Choose the right MVS options and parameters, use your access control software product to restrict dpdate access to the system and application libraries, implement an effective change control procedure and create a quality assurance function. Remember that viruses have to be executed to infect a computer system. Browsing a module containing a virus is perfectly safe. Beware of any unverified load modules that are executed on your system, such as those obtained through user groups, public domain software, free or abnormally cheap utilities, programs brought by temporary contractors and consultants, or any programs received via Network Job Entry (NJE) where the sender cannot be absolutely trusted. Since program modules, utilities, CLISTS, etc. are executed under the access authority of the current user; never run unverified modules under a security officer, system programmer, production or other powerful userid.

To prevent a viral infection in an MVS system, identify and protect the critical gateways that would allow a virus to gain supervisor state and/or the master storage protec- tion key. Start with the APF library system, which is the easiest way for the virus to gain these powers. The impor- tance o f controlling APF libraries cannot be over em-

phasised. A single virus infected program executed from the APF authorised library could disrupt an entire MVS data centre for months. Unfortunately, review of APF without an automated tool designed for that function is difficult, because the librarie~ are not marked in any way. Another major " /" dffficuhy.w~th APF is that MVS deter- mines which libraries are-to be APF libraries by reading the system parameter library, but only during IPL.

This crcates a problem for auditors and security officers, because what they see in SYS I. PARMLIB at the time of their review, may not be what the system is actually running with.. Unless you have access to a memory-based analysis tool, you will have to make do with listing the IEAAPFxx and optionally the LNKLSTxx members of

SYS1.PARMLIB to determine the names of the data centre specified APF libraries. After making certain that your security software is protecting all of the specified libraries, trace the origin of all APF library modules back to a responsible source. Looking at program names may not be enough, since a clever virus designer will probably follow IBM's naming conventions. Furthermore, relying on the load module length to detect infection is not fool- proof, since many programs contain 'patch areas' that could hide a small virus without increasing the length of the module.

Next analyse all Supervisor Calls (SVCs) with particular emphasis on type 3 and type 4 SVCs which are normally executed from one of the viral storage resident Link Pack Areas (LPA). Since a virus needs to be executed, it may be designed to intercept commonly installed high usage SVCs. Carefully review any SVC table entries pointing to memory addresses in areas like Common Service Area (CSA or ECSA) or the Modifiable Link Pack Area (MLPA or EMLPA). Since modification of the MVS SVC table to dynamically install program modules is a well established technique used by a number of program products, you will need to determine which modifications are legitimate and which are not. An unaccountable SVC table alteration may indicate a virus has dynamically infected the MVS system and has inserted itself by 'front- ending' a legitimate SVC.

Other MVS facilities must also be examined. Check for unusual entries in the Program Properties Table (PPT); then carefully review system exits, appendages, and subsystems. As previously mentioned, always analyse the contents of the Link Pack Areas (LPA), particularly the Modifiable Link Pack Area (MLPA). Remember that an MVS/XA or MVS/ESA system may have as many as six LPAs. Thoroughly research any irregularities by looking for machine instructions that would indicate the presence of a virus. Since the actual viral code may be quite small, a detailed examination may be required.

Although significantly less software is shared in the mainframe world, it is still commonplace for systems programmers to utilise utility programs obtained from public domain sources or previous employment. Avoid any soft~vare developed or copied on unsecured computer systems, which are easy prey for virus infections. Software from organisations with a high level of security awareness and effective internal security measures is un- likely to be infe~ted. However, it is difficult to assess the level of security precautions taken by another site from which software tools are imported. Recent events in the PC software industry have shown that insufficient security measures, even by vendors, can result in rapid, wide-spread virus contamination.

Because of the potential for massive disruption and the associated business losses that are possible in the MVS world, our emphasis in virus control must be placed on prevention. Identifying an MVS virus after it has at- tacked the system may be very much like performing an autopsy to determine the cause of death. The patient, or

4 Velume 1 Number 6 May/June 1989


COPERATING SYSTEM EXPOSURES ) business, is beyond treatment before the cause is identified. The consequences of personal computer viruses have proven to be disruptive and costly to those who have been infected. We also know that viruses spread through communications systems have already clogged the networks of universities and research laboratories causing severe disruptions, but have so far caused little actual damage. By'comparison, a prolonged MVS virus infection in a business data processing system could fatally disrupt the cash flow of an organisation. Even elaborate offsite disaster recovery plans, effective against physical destruction, could prove ineffective if the virus had already moved to the data vaults along with organisations backup tapes and programs.

Unfortunately, the effort required to identify and trace suspicious modules or detect unauthorised program modifications is not trivial in a large MVS data centre. There may be over 200 APF authorised libraries containing thousands of modules, plus IPL options, JES parameters, exits, SVCs, I/O appendages, and other exposures. Simply identifying ifa surreptitious change has occurred requires substantial time and expense. This question must be answered to determine if a more thorough investigation should be initiated involving even greater effort and expense. The high cost has lead many organisations to ignore the whole issue and simply pre- tend that disaster would never happen to their MVS data centre. So far, their gamble has been largely successful. However, the odds are changing and many MVS data centres remain surprisingly vulnerable to a virus attack.

Many of the techniques used to identify computer viruses will identify other types of contaminated software as well. One of the most common of these is the 'logic bomb'. Although logic bombs may be incorporated into MVS modules or employed by viruses, it is far more typi- cal to find them embedded in business application programs. Logic bombs pose the greatest threat to the data processing systems which run under MVS, because they can corrupt or destroy irreplaceable data. A logic bomb in an MVS system processing critical business applications could be devastating. Just like their explosive brethren, logic bombs lie dormant until being triggered. There are two primary categories of logic bombs: time bombs and event bombs. Both techniques can be used in the same 'device', or even combined with viruses.

As their name implies, time bombs are triggered on a specific date or at a specific time. Thus they will usually be found in a system routine that is frequently executed and performs date/time checking. Since much of com- mercial data processing depends upon billing cycles, month end closings, fiscal year processing, etc. finding a place to put a time bomb is rarely a problem. Time bombs are often planted by people seeking revenge against the organisation that depends on the computer. The person wants to create a costly or embarrassing situation, therefore no warning threats or notification will be given.

submitted or withheld from the system. Witholding a trigger transaction from the system is a popular technique with extortionists seeking personal financial gain. Unless their demands are met, they won't supply the transaction to disable the bomb.

What happens when a logic bomb 'explodes', depends on how it has been designed. Some merely stop a program from running. However, more malicious logic bombs may erase master files, destroy backup tapes, etc. Others may mimic hardware failure, corrupting only an occa- sional byte of data chosen at random. Beware that logic bomb damage may not be recoverable if your back-up tapes have been re-cycled before you detect it. Logic bombs can cause long term disruption and expense within MVS data centres. Logic bombs represent a seri- ous threat because of the increasing business dependence on computer processing.

To protect yourself from logic bombs, use your security product to control update access to the system libraries. Implement a quality assurance function. Insist that MVS and business application system maintenance be applied through an auditable change control process. Review all MVS exit source code, and make sure each exit is documented as to its purpose, usage, and function.

To detect logic bombs in an MVS environment, check for unauthorised machine language changes, ('ZAPS', or other hooks in widely used MVS modules that cannot be traced to a standard system maintenance procedure such as SMP). Look for non-standard CSECT names in IBM modules, and compare suspicious modules to the original distribution libraries. Review the contents of the Link Pack Areas. Check LPA for suspicious modules that may be activated by a logic bomb. Pay particular attention to the Modified Link Pack Area (MLPA/EMLPA). Most bombs are intended to crash the system or corrupt data. Those intended to take down the system will probably need APF authorisation. Check the APF libraries and system exits carefully. Sometimes logic bombs can be detected by looking for their triggers. Review each module to see if it checks for particular jobs, files, programs or user ids. If it does, find out why.

A 'tral~door' is a completely different category of system modification designed to gain access to information or MVS features beyond a person's appropriate authority. The distinguishing feature of a trap door is that it is intentionally hidden and used only when needed. The person who installs a trap door does not want anyone to accidently discover his secret. The trap door is often a special command, available to those users who know how to acti- vate it. Trap doors are very popular in the MVS mainframe world. In fact, it is often difficult to find a system that doesn't have one buried somewhere. Very few trap doors are the work of outside individuals; but some trap doors have been introduced, perhaps accidently, by 'high performance' options and data base management products from outside vendors.

Event bombs are triggered by input data. Usually, they Unfortunately, most trap doors are intentionally put into are set to go offwhen a certain input transaction is either MVS by the data centre's own technical support person-



OPERATING SYSTEM EXPOSURES ) neI. The three most common reasons heard for this are: the systems programmers want to be able to install MVS maintenance without performing an IPL; they want to issue operator commands from their TSO terminals; and they want to bypass the data centre's security system in case they need access to something in the middle of the night.

Although these trap doors are placed into the MVS system with good intentions, the existence of un- documented and hidden mechanisms in the operating system to circumvent established controls does not make good business sense. MVS production reliability will be reduced by ad hoc updating of system modules and control blocks through a trap door, and may inadvertently crash the system. The computer operators cannot main- tain control of the system when people are submitting master console commands from TSO terminals any- where in the network. The security officer will have no hope of successfully keeping out hackers, thieves, other outsiders and unauthorised insiders if the security system can be bypassed at will. Finally, there is always the danger that the wrong person may discover the trap door and use it in malicious way-~, such as infecting the MVS system with viruses or imbedding logic bombs.

Most MVS trap doors are implemented as either Time Sharing Option (TSO) commands or as operating system Supervisor Calls (SVCs). TSO commands are convenient for programmers to use, and SVCs are easily issued from either TSO or batch programs. Trap door TSO commands will normally require APF authorisation, hence will be found in the IKJEFTE2 and IKJEFTE8 tables or their TSO/E counterparts, IKJTABLs and IKJEF TAP. These tables should be examined carefully for suspicious entries.

system. Eliminate duplicate and obsolete modules. Iden- tify non-standard modules in your APF libraries. Analyse the memory-resident LPA, as it is also part of APF. All system maintenance to a production environment should be subject to change control and quality assurance procedures.

Another major category of unauthorised system modifications that we find in MVS systems is the Trojan horse. This term is used for any technique that depends on fool- ing someone. In a data processing context, these techniques include Trojan horse logons, messages, ISPF dialogues, utilities and games. They all involve hiding modules in system or applications software to trick an un- witting victim into performing some function under their user authorisation or divulging confidential information.

Recent articles, such as Clifford Stoll's "Stalking the wily hacker '~, have shown that Trojan horses are an important tool used by outsiders to penetrate systems by gaining passwords or installing trap doors. A Trojan horse can also be used by anyone who wants to perform a restricted function which they lack the authority to do. All the in- truder has to do is find someone who does have the necessary authority and trick them into doing it. For example, a Trojan horse message containing a Security system command, in a darkened field, could be sent to the data centre's security officer. If the security officer responded to the seemingly blank screen by hitting the enter key, the Trojan horse command would be executed by the security system. The beauty of this approach is that if usage of the restricted function is ever discovered, the security system records will implicate the security officer! Trojan horses may play an important role in spreading computer viruses to system software. They may be used to corrupt legitimate software prior to its transmission to other sites.

Trap door SVCs will be found'in either LPA or the MVS nucleus, depending on SVC type. Pay particular attention to user defined SVC numbers 200 through 255 when looking for trap doors. These are site defined SVCs, which will be used by various program products and data centre developed functions, making them an ideal hiding place for a secret trap door. D o not ignore other SVCs which are reserved for specific IBM products that may not be installed in your MVS system, such as the reserved RACF SVCs from 130 through 133. Although trap doors based on APF authorised TSO commands and user supplied SVCs are the most popular kinds, system exits, subsystems, appendages, and the Program Properties Table (PPT) also offer opportunities for trap doors.

Sometimes you can find trap doors by finding the modules which service them. In almost every case, the instal- le~-of a trap door will require access to an APF library. Preventing un-authorised update of these libraries is critical. Use your access control software to protect them. Review the current contents of these libraries and periodically recheck these modules to ensure they have not been changed outside the approved procedures. Remember that critical mqd~les could be tampered with during system maintenance or by IPLing a non-secure MVS 'test'

Trojan. horse applications, such as the one hidden in games or the ones that generate false logon screens, are easy to develop. Creating a Trojan horse logon screen that collects logon user ids and passwords is very easily implemented on personal computers that are also used as 'MVS 3270 terminals. A simple PC program can simulate or simply capture an image of the TSO, CICS, IMS or other signon screens containing the user's identity and password. The perpetrator simply uses the PC to occa- sionally harvest the latest ids and passwords. These programs can be easily brought into an organisation on a floppy disk and installed in the personal computers of prominent users or on PCs that are shared by a variety of users. No operating system modifications are required and these programs are available from various under- ground bulletin boards.

A similar Trojan horse logon screen technique can be implemented directly on the MVS side of the system by writing a program or CLIST that displays what appears to be a standard signon screen. This Trojan horse is left running on the system under the perpetrators user id. Unsuspecting victims attempt to logon, but receive a message that the maximum number of users or some other condition prevents their logon. Meanwhile, the

6 Volume 1 Number 6 May/June 1989


PERATING SYSTEM EXPOSURES.__ Trojan horse logon has captured their id and password in a file for later retrieval by the perpetrator. Any time you are finable to logon to the system, you can check for this type of Trojan horse by powering off the terminal and then powering it back on. This should abend the Trojan horge logon program and allow you to access the system.

Trojan horses are difficult to control, however those embedded in the operating system can usually be identified by the same techniques used to find logic bombs and trap doors. You can combat them by using CA-ACF2 and CA- TOP SECRET to prevent unauthorised update of system libraries. You should also implement effective change control procedures and a quality assurance function for system software changes.

To reduce your risk of a Trojan horse attack, never move load modules directly from test libraries to production libraries. Always insist on reviewing the program source code and re-compiling the production programs from the certified source code. Thorough review is necessary since the Trojan horse could be included or copied into the program either before or during the compilation, assem- bly or linkage editing processes. Trojan horses embedded in application software or utilities may be quite difficult to detect. Good administrative procedures must be used for their control. Be wary of public domain software, free utilities, and software brought by temporary contractors or consultants. Periodically review TSO user datasets, and review the System Management File (SMF) log on a regular basis to check for critical dat] Set updates that do not have corresponding change control authorisation. Monitor system library changes. Para- phrasing an old saying, you should definitely look a gift Trojan horse.in the mouth!

data centres may have over 200 APF authorised !ibraries to identify and control. Each library may contain several thousand programs, any'one of which could carry a vii'us into the all powerful MVS supervisor state. But, APF libraries are just one of the critical MVS integrity mechanisms requiring constant attention. Procedure libraries (PROCLIB), system parameter libraries (PARMLIB), JES parameters, IPL options, User a n d vendor SVCs, I/O appendages, the Program Properties Table (PPT), SMF audit trail reporting options!and exits, and a growing array of system software products must all be carefully controlled to prevent the introduc- tion of the integrity exposures presented in this article.

Computer viruses, logic bombs, trap doors and Trojan horses all have the ability to destroy priceless business data and render key systems useless. Given the high level of dependence most companies have on data processing, ignoring these risks by doing nothing is unacceptable. We are engaged in a battle of technology with those who would corrupt the power of today's computers; turning these machines against the organisations who rely upon them. The motivation of these individuals may be curios- ity, personal financial gain, ego, revenge or even ter- rorism directed at major national institutions. The threat is real and growing as computer.technology becomes more prominent in the fabric of industrialised society. The consequences of failure are also increasing as more vital financial, manufacturing, engineering, transporta- tion and medical information is transferred to computerised systems. Systems programmers, data security officers, EDP auditors and management cannot remain idle while unethical individuals implant viruses, logic bombs, trap doors and Trojan horses in their computer systems.

Trojan Horses embedded in the operating system can be found using the same analysis techniques used to find trap doors. Note however, the Trojan horse designer has a completely different intent than the trap door architect. A Trojan horse designer will place his creation where a victim is sure to execute it. Trojan horses will almost always be added to or called from some popular system module, CLIST or utility function. The trap door designer tries to place his tool somewhere where no one else will ever execute it!

Many of these threats have existed since the initial de- velopment of computers. The vulnerabilities of the MVS operating system have been extensively discussed and publicised by MVS securityexperts such as Keith Soper andMike Villegas for years. Many of the security exposure~ pointed out in'a 1983 article called "Surreptitious security violation in the MVS operating system" by Ronald Paans and Guus Bonnes of Delft University in the Netherlands are still with'us today.

The responsibility for MVS integrity rests heavily upon the shoulders of the data centre managers and technical personnel. This weight is growing heavier as each new hardware and software upgrade increases the size and complexity of-the installations they manage. Today large

References

Paans, R. and Bonnes A.H.J. (1983) "Surreptitious security violation in the MVS operating system", IFIP/Sec '83 pp 95-106 (Security, IFIPISec83, Proceedings of the First Security Conference, Stockholm, Sweden, 16-19 May 1983, V. Fak (Ed)). North Holland Publishing, ISBN 444 86669-8, also Computers and Security, 1983, Vol 2 (2), June, pp. 144-152. Stoll'; C. (1988) "Stalking the wily hacker", Communica- tions of the ACM, Vol 31 (5), May.

Martin King, BSc, CDP, CISA, is Manager, Audit Services, Computer Associates and is Past President, Detroit Chapter and board member Chicago Chapter of EDP Auditors Association.


dealing with mvs exposures

Documents