Silverfish in the cupboard

Silverfish in the Cupboard

David Thompson

ml his is not an article about those little creepy crawlies in the linen closet. It concerns a group of computer users

who receive very little publicity; The authorised outsider or the non-employee whom a company permits access to its computing facilities. To begin, please put on the Security Manager’s hat and consider three situations:

Situation 1: An Australian company purchases a company in the US and installs a link to connect the two computer systems. However, each company is to retain responsibility for its IT operations including security policy and procedures. A concern for both Security Managers is that each has responsibility for security at his own site but each cannot really trust the security at the other site. It is possible, for example, that one site may operate unprotected dial-up modems or have a communication link to an outside organisation. The other site is vulnerable if either possibility exists. Should each Security Manager take further precautions or are existing controls adequate?

Situation 2: A company purchases an application and contracts the vendor to assist with implementation and to provide ongoing support remotely from the UK. The vendor will need login access to both the development and production systems. A concern for the Security Manager is that the company’s critical application source code and confidential production data will be within reach of the vendor. Should the Security Manager take

further precautions or are existing controls adequate?

Situation 3: A company purchases an ED1 package so that it can trade electronically with its customers, sup- pliers and financial institutions. A concern for the Security Manager is that a potentially large population will have access to the company computer. Should the Security Manager take further precautions or are existing controls adequate? The purpose of this article is to explain that there is an increased risk when nonemployees are permitted access to a company’s computer facilities and that a strategy is mandatory to minimise that risk. The article then describes a three stage strategy for MVS and Unix systems.

A new term To coin a term for the purpose of this article, I define a silverfish as a person whom the company has granted access to the computer operating system or to one of its applications! but whom the company running the computer does not employ. The person may be a vendor, contractor, consultant, customer or a user remotely logging in from a subsidiary computer. The definition does not include the hacker because he is not an authorised outsider; Management has not approved his access. Further controls are necessary to keep that creature out of the cupboard.

The threat Ideally security would be implemented

Computer Audit Update l November 1996 0 1996, Elsevier Science Ltd.

A I cc 0

based on the law of least privilege and then the Security Manager would not need to take further precautions. Each user, whether an employee or non- employee, would only be able to access resources that he actually requires. However, in reality, users can often access systems, applications, transactions and datasets that they do not require access to. The primary reason is cost. It takes considerable resources to implement and maintain a restrictive environment. Today, security is under further pressure by users who are demanding more services and more access. Business demands are making the production computer system more open and more accessible. A zero security approach is unacceptable because of the high risk of fraud, sabotage and industrial espionage. The challenge is to minimise risk whilst containing costs and remaining responsive to user demands. The more people who have access to the system, the greater the risk. Undoubtedly, the employee poses a threat however the company is aware of his background and his work is supervised. The employee is dependent on the company for his ongoing financial and job security and in return provides a level of loyalty. The company knows him. But what does the company know about the silverfish ? He may be a disgruntled exemployee now working for a vendor. He may be a competitor posing as a customer and after company secrets. He may be a hacker into a subsidiary computer who has found the connection to your computer. Or he may be an extremist seeking to harm a company involved in a con- troversial project.

A fallacy: “We have RACF! We’re protected!” There is a belief amongst certain senior management, but hopefully not amongst auditors, that the mere pre- sence of RACF is security enough. However this is a false sense of security. Firstly, RACF must be well administered, and secondly, it can be circumvented. For example, a system authorised third party product that has

lmputer Audit Update l November 1996 1996, Elsevier Science Ltd.

not been carefully coded may allow an outsider to bypass BACF - he can then access any data he wants to. And systems programmers sometimes write their own programs to bypass RACF. If an outsider can execute one of these programs, then he can bypass BACF. Auditors should ensure that management understand that RACF alone is not sufficient protection against outsiders. Security is a bigger picture than RACF.

What to do !

An auditor should ensure that his company recognises the silverfish as a special category of user and that there is an effective strategy in place to control silverfish access to the company’s computer facilities. The following three stage strategy describes the minimum activities required to control outsider access and the auditor should either compare it with his company’s strategy or use it as reference to develop a strategy where one does not exist.

Stage 1: Security Policy and Procedures The company’s Security Policy and Procedures should be updated to reflect management’s commitment to apply the law of least privilege to outsiders. A suitable statement to be included is: “Each outsider with access to the company’s computer resources will only be permitted to access resources that are explicitly authorised for that user”

i.e. There is to be no access to resources by default. Procedures and guidelines should then be written to support this policy statement. For example, there should be guidelines for defining outsider userids and for connecting them to groups.

Stage 2: Before the cupboard is opened The system should be reviewed to identify and resolve weaknesses and exposures that could be utilised by an

outsider to access resources not required to perform the job. Safeguards or restrictive controls designed specifically for outsiders will usually be ineffective if weaknesses or exposures exist in the system. For example, limiting an outsider to a set of commands is pointless if one of those commands allows him to obtain supervisor state. It has been suggested that a company could engage a technical consultant (A Hacker for Hire) to verify the effectiveness of its system security. The consultant attempts to breach system security, and if successful, produces a confidential report for the company to action. This is an excellent starting point for a company intending outsider access, because senior management will more likely take notice if an individual with no company knowledge can breach security (see also US Update on p. 23). From experience in systems programming and computer security, I have compiled security checklists for MVS and Unix systems that a company should implement before the first outsider is permitted access to the system. The checklists appear in the following appendices: Appendix Al: Checklist for MVS or Unix systems.

Appendix A2: Checklist for MVS systems.

Appendix A3: Checklist for Unix systems.

Stage 3: Netting the silverfish Once a company has identified and resolved its weaknesses and exposures, the final step is to develop safeguards or restrictive controls for individual outsiders. The intention is to limit an outsider’s access to what he actually needs, to specific applications and files without adversely affecting his ability to do the job. Consequently, the opportunity for accidental damage or a malicious act is reduced. Recom- mended safeguards appear in the following appendices: Appendix Bl: Safeguards for MVS or Unix systems.

Appendix B2: Safeguards for MVS systems.

Appendix B3: Safeguards for Unix systems.

Conclusion Not so long ago, it was widely ac- cepted by companies that only em- ployees should be able to login to the production computer system. How- ever, the pendulum has swung and today many of these companies have reversed their policy and not because of any improvement in computer security. The frost reason is IT cost cutting. It is usually cheaper for a company to purchase an application instead of developing it internally and to engage the vendor to assist in its implementation and support. The vendor is granted access to the development system to customise the application and then is granted access to the production system to support the application once it goes live. Secondly, IT direction is now being set by the IT department and the business units working together. The business units are interested in profits, and their customers want online access to information. Once a competitor provides this service, then a company must provide an equal service to survive. Consequently production applications are now being made available to customers to provide them with the services they need. Auditors should recognise the risk of silverfish in the cupboard and ensure that controls are in place to minimise that risk. The easy way out is to treat an outsider as an employee, relying on the existing standard security controls. However, these controls are generally inadequate against an outsider with a malicious intent - specific restrictive controls are required. The newspaper headlines would make you believe that your computer is only at risk from a hacker dialling telephone numbers from the solitude of his bedroom, and security consultants regard the employee as the high risk area, but don’t forget the silverfish.


Appendix Al: Checklist for MVS or Unix systems Review the level of public access to computer resources.

A company is making available unnecessary and excessive information to an outsider if it has not controlled public access to datasets. Should the company be concerned if an outsider reads the critical application source code? He can copy to diskette any information that is readable, remove it from the premises for a more detailed examination and possibly offer it for sale to one of the company’s competitors.

For MVS systems, UACC(NONE) should be defined in RACF profiles wherever possible and access lists should explicitly state who gets access. A RACF exit should be written to prevent owners 6f profiles changing UACC(NONE) once it is set. For Unix systems, WORLD authority should be NONE wherever possible.

Restrict access to sensitive documentation to ensure that an outsider does not learn more about your system than necessary. Do not make available:

- System and network configuration diagrams

- Software inventory lists

- Operation manuals of security devices (modems, encryption devices)

- Descriptions of security controls (user exits, security parameters)

- Disaster recovery plans

Attempt to identify insecure third party products installed on the system by requesting each vendor to sign an integrity statement with wording like:

- To the vendor’s knowledge, the software contains no security exposures that would allow an unauthorised program or user to acquire authorisation.

- If any such exposure is identified, the vendor undertakes to rectify the exposure within a reasonable time of being notified of it.

There is reason to be wary of the product if the vendor declines to sign. For future purchases, a signed statement should be mandatory.

For MVS systems, request the vendor to declare his product’s support for the IBM MVS System Integrity Standard as defined in the IBM Programming Announcement ZP81- 0282.

Attempt to identify known exposures by reviewing vendor error bulletins and checking that security fixes are installed.

Regular scrutiny is required and fixes should be installed at the earliest opportunity.

Implement verification mechanisms to ensure that security controls are not removed accidentally.

Installation of a new release of MVS might accidentally omit a security exit and it is likely that it will remain unnoticed for a long time. Users complain when they suddenly lose access to a resource, not when they suddenly gain access.

- Keep a register of all security controls, noting its description, purpose, owner and the system it resides on

- The owner of each security control should implement an automated procedure to verify that the control is in place and working at system IPL time or as soon as practical. Exception messages should be sent to the system console.

- The Security Manager should approve any modification or the removal of a registered security control

lu Computer Audit Update l November 1996 0 1996, Elsevier Science Ltd.

Review password controls and practices

- Change the passwords of vendor supplied userids from initial values and delete or at least revoke the userid if it is not required. These userids possess system privileges.

- Force users to change their passwords, say every 30 days. This will limit the risk if an outsider learns of an employee userid and password. The outsider will not be able to use that userid once the password is changed.

- Do not reset forgotten user passwords to the same initial password every time. Create a random password and pass it securely to the user.

- Users should not store passwords in keyboard function keys or in PC files to facilitate login, else an outsider can use the device to gain unauthorised access.

- Applications should store passwords one-way encrypted using an endorsed encryption algorithm.

- Password files should not be public readable because a brute force attack may reveal the passwords. Some versions of Unix provide a shadow password file that can be read only by the superuser to protect against this threat.

Two types of application do not adequately validate a user’s access to system resources and therefore require scrutiny:

a. Applications that process a login request without requiring the user to enter a userid for authentication.

b. Applications that allow a user to access resources with the authority level of that particular application; Not with the user’s personal authority.

Either type of application may let an outsider access a system resource that his personal userid is not authorised to access.

Scrutinise the security features of any application that uses its own security mechanism for validation and authentication to determine whether the features meet company security standards.

It may not be appropriate to provide outsiders with access to an application that does not have an acceptable level of security.

Develop an encryption policy that identities agencies qualified to certify encryption algorithms.

It is risky to trust a proprietary algorithm that has not been certified by a recognised agency. Your client-server database product may merely mask the characters of a password for storage. Also be aware that decryption programs for common Unix encryption commands are usually available on the Internet.

Ensure that guest or default accounts do not exist as they allow users to login without being authenticated.

Appendix A2: Checklist for MVS systems

Ensure that the RACF Global Access Table is not granting public access to datasets that your company does not want outsiders to access.

Ensure that your third party and company written MVS SVCs conform to the IBM MVS System Integrity Standard as defined in IBM Programming Announcement ZP81-0282

An SVC that does not conform to this standard is a security exposure that can permit an unauthorised program to acquire authorisation.


Appendix A3: Checklist for Unix systems Ensure that the following controls are implemented to restrict access to the superuser account:

- The NOT SECURE parameter in definitions for terminal lines and network ports to ensure that login to superuser can occur only from secure devices such as the system console.

- The WHEEL group or Group 0 to specify users authorised to SU to superuser.

Controlled administration of the superuser account.

Because administrators and systems programmers usually share the superuser account, there should be controlled administration of its password. The Security Administrator should be responsible for disclosing the superuser password to appropriate users and for resetting it immediately after use. A log should be kept (but not on the same Unix system) recording who used it, why and when.

Evaluate the need for a third party product to monitor security.

Unix regards every device to be a file. If an application needs to write to the system console, then the application issues a write instruction to the file representing that device. File access control is critical in Unix and the system supplied security tools are generally inadequate. Investigate third party products available on the market; Omniguard is one such product that does the following:

- Checks for vulnerabilities such as trap doors, Trojans and unauthorised privileges

- Detects changes to established security settings or file permissions

- Monitoring and intrusion detecting

- User administration and access control

- Identifies weak passwords

Regularly monitor the Internet security bulletin boards such as the Computer Emergency Response Team (CERT) and SUN’s Customer Warning System.

The Internet usually announces a Unix security exposure as soon as it is discovered, therefore it is important that the Security Administrator stays informed. A person intending unauthorised access will try known exposures before attempting methods requiring more skill. The Internet and vendors provide temporary and permanent fures but these should be tested thoroughly before installation on a production system.

Review SUID and SGID program tiles, especially if owned by the superuser, and enforce the following:

- Examine carefully source code of public domain software that runs SUID or SGID before installation.

- Examine carefully source code for company written SUID or SGID programs.

- Others should not be able to write to an SUID or SGID program file, otherwise an outsider can copy his code over the program and run it with the authority of the program’s owner.

A program’s SUID and SGID bits permit any user who can execute the program to adopt the authority of the program’s owner and group owner respectively. This is not a concern if the program is coded correctly, however it can be utilised to breach security if it contains an exposure (unintentional or deliberate).

Disable any network service that is not required.

Computer Audit Update l November 0 1996, Elsevier Science Ltd.

1996

For example, if there is not a requirement for users of a Unix machine to initiate remote login or remote execute requests to other machines in the network, and an outsider is likely to be permitted access to that machine, then the machine’s TELNET, REXEC and REOGIN services should be disabled to prevent the outsider accessing Unix machines other than the one he is authorised to.

Others should not be able to write to fues executed by the superuser, otherwise an outsider could modify a script to acquire higher privileges.

User configuration files (.profne, .login etc) and home directories should be owned and writable by that user only.

NE% An outsider should not be able to modify his own configuration files.

Ensure that the debug option is disabled on all programs that support its use.

Unix programs compiled in debug mode have been used in the past to allow users unrestricted access to the system it is running on.

Use the Access Control List (ACL) feature if it is available.

The ACL feature allows the administrator to specify the type of access permitted to individual user accounts; Unlike the standard Unix owner/group/other permissions which do not permit this level of granularity.

Ensure that the CPU and console are in a physically secure location.

If an outsider has access to the console, then he may be able to boot the system in single-user mode, acquire superuser authority and circumvent standard accesscontrols

Determine which networked Unix machines trust the computer that an outsider is authorised to access.

Users of trusted machines can login elsewhere without having to+enter a password.

The PATH variable for the superuser should never contain an entry for the current directory (.), otherwise an opportunity will exist for a Trojan to be executed instead of the true version of the program.

An outsider should generally not be allowed to read or write to device files, which represent Unix system resources and peripherals.

Read access to the device file representing a disk can provide access to data even though the file permission denies access, and read access to memory can reveal unencrypted login passwords held in buffers.

Appendix Bl: Safeguards for MVS or Unix systems Create a unique userid for each outsider and enable it only when required. Delete the userid when it is no longer needed.

Require an outsider, especially a vendor, to sign a non-disclosure agreement before authorising access to the system.

Software vendors may be provided with production data to test their applications or such information may be viewed during a dump analysis.

Do not connect an outsider to a normal access group because higher access can be acquired unintentionally and unknowingly. For example, if a contractor is connected to a programmer RACF group so that he can modify development datasets, and later the RACF group has its access changed from READ to UPDATE to an APF dataset, then the contractor also has been provided with UPDATE access to the dataset. A group(s) should be created specifically for outsiders.

Computer Audit Update l November 1996 c 1996, Elsevier Science Ltd.

Appendix B2: Safeguards for MVS systems Do not provide an outsider with UPDATE access to the following datasets:

- APF

- PARMLIB

- LINKLIB and LPALIB

- PROCLIB

- CLIST

Deny READ access to PARMLIB datasets; An inquisitive outsider would find the configuration information useful.

Do not define a TSO segment when creating an outsider’s RACF userid unless TSO access is needed.

A RACF userid requires a TSO segment to be able to login to TSO.

When TSO access is needed, provide an outsider with the subset of TSO features necessary for him to perform the task:

- When a single TSO application is to be accessed, control should pass directly to the application without a menu being displayed.

- A customised TSO procedure, restricting access to limited menus and applications. Do not provide submit job capability unless needed.

- Do not provide SDSF unless needed.

- Do not provide ISPF unless needed.

CL/Conference is a productivity tool that allows one or more terminal users (called attendees) to see an online VTAM application operated by another terminal user (called the moderator). During operation of the application, CL/Conference echoes the information entered and displayed on the moderator’s terminal to the attendees’ terminals. In addition, any attendee may become a presenter and interact with the application if allowed by the moderator.

A product of this type can be utilised to control a vendor providing remote support to one or more of your applications. If a problem occurs and vendor assistance is required from a remote location, both a company employee and the vendor login to CL/ Conference. The employee then logs on to the application requiring support and the vendor’s terminal displays all the information displayed at the employee’s terminal. The employee can choose whether to take directions from the vendor and enter all the keyboard input himself, or whether to enter a simple command and pass the keyboard to the vendor to allow him to do the typing, but under the employee’s supervision. This facility allows the company to supervise the actions of the vendor.

The alternative is to let the vendor login directly to the application, unsupervised, and to trust him. His activities can be logged, but may not be reliable if he obtains supervisor state and manipulates the log. The inconvenience of using a conference product is that a competent employee must be available when support is needed.

If your company’s MVS mainframe is linked to another company’s MVS mainframe, then your network control program (NCP) can be coded to restrict logins from the remote mainframe to approved applications only.

For example, if the link has been installed to provide access to your IMS application, then you should not allow a remote user to attempt login to any application other than IMS. This control ensures that login via the link is to IMS only.


l The following are two techniques to control an outsider connected to your MVS mainframe via a leased line:

a. The VTAM Session Management exit can restrict login requests via the leased line to approved applications only. This control is at the link level and not at the user level. This is satisfactory if all users on the leased line need to use the same set of applications.

b. Tighter control involves identifying the individual and restricting his access to a pre- defined set of applications. This can be achieved utilising a session manager product such as Netmaster which can acquire each terminal on the leased line as it powers up. Once the user is identified, a menu is displayed with a list of approved applications for that user.

The outsider cannot break out of the Netmaster session to attempt to establish a session directly with another application. Changes are required in VTAM to ensure that a native session cannot be established with another application if Netmaster is not running.

Appendix B3: Safeguards for Unix systems First it is necessary to determine an outsider’s access requirements before deciding which safeguard is appropriate. An outsider should not be provided with a Unix shell if he does not need to execute a Unix command because almost all successful Unix security breaches have resulted from commands or utilities being executed. The following are two safeguards that do not provide a shell to an outsider:

a.

b.

When an outsider needs to execute a single application only, then the simplest and most effective way to limit his access is to directly execute the application program at login. The user will automatically logout on exit. The outsider has no access to the Unix command line and cannot pass Unix commands to the operating system as long as the application program does not provide this facility.

When an outsider needs to execute more than one application, a front-end application can be written to display a menu of applications. The front-end executes the selected application and the user will either logout or return to the menu on exit.

An outsider will probably require a shell if he needs to execute multiple Unix commands. The following are two safeguards with the second providing more protection than the first but requiring greater effort to implement:

a. Specify a Unix Restricted Shell for the outsider that will start up and execute with the following restrictions:

- The user cannot change the current directory.

- The user cannot change the value of $PATH.

- The user cannot use command names containing slashes; He is prevented from using absolute path names, therefore he cannot execute a command that is not in a directory contained in $PATH.

- The user cannot redirect output.

Shell processing terminates if the outsider tries to interrupt processing of the $HOME.profile.

Warning: These restrictions will not take effect if the outsider is able to run another shell, because he will be able to execute commands that circumvent the restrictions. Many Unix commands allow shell escapes, or means of executing arbitrary commands or subshells from within themselves. Some programs that have shell escapes do not even document this feature. If a program that can be run by a restricted account has the ability to


run subprograms, then the account may not really be restricted at all. For example, if the restricted account can use man(l) to read reference pages, a person using the restricted account can use man to start up an editor, which can spawn a shell, which he can use to run programs on the system.

b. The CHROOT command can be used to set up a completely separate environment for the outsider by restricting his access to a portion of the Unix file system. This method is significantly more effective than a restricted shell. He simply cannot access files outside this portion. There is no way for him to access the full range of Unix commands, nor can he access other user’s files, except for those that you provide within his sub-file system. More effort is required to establish this environment than a restricted shell, but is the recommended option when security is critical.

Anonymous FTP uses CHROOT to allow people on the network who do not have an account on the computer to deposit or retrieve files from a special directory. The user simply specifies anonymous as the username and his real name as the password, which is used for information purposes only. Anonymous PTP is useful for companies that provide a bulletin board service for network users and for software companies as a low cost means for distributing maintenance fixes.

The following recommendations are applicable if an outsider has access to a shell and is able to execute Unix commands:

- Do not grant an outsider access to the superuser account, but if it is necessary, then:

a. Closely monitor his activity. Often when an outsider states that the task cannot be performed without superuser authority, it is not the case and he merely wants freedom to complete the task without access violations. Identifying the access required and modifying the access permissions should enable the outsider to perform the task without superuser authority.

b. Create a normal user account and require him to SU to superuser so that activity under superuser can be traced to the individual.

- Do not allow an outsider to execute the CD command because it will allow him to change his current working directory and roam around the file system

- Do not alIow an outsider to update his user .PROFILE file, otherwise he can modify controls (e.g. PATH) established to restrict him.

Bibliography S. Gartinkel and G. Spafford, Practical Unix Security, O’Reilly & Assoc., 1993 R.Thomas and R.Farrow, Unix Admin- istration Guide for System V, 1989 P.Wood and S.Kochan, Unix System Security, Hayden Books, 1985.

David Thompson is a consultant with the National Australia Bank

based in Melbourne, Australia. This paper was based on a

presentation first delivered at a recent EDPAC conference held

in Australia.

I Computer Audit Update l November 1996 0 1996, Elsevier Science Ltd.

Documents

Silverfish in the cupboard