Network Working Group Authors Request for Comments: 11XX Affliations MMMM 1990 Security Policy Handbook Status of this Memo This document is the product of the Security Policy Handbook Working Group (SPWG) of the Internet Engineering Task Force (IETF), co- chaired by: J. Paul Holbrook (CERT) and Joyce K. Reynolds (USC/ISI). The working group can be contacted via ssphwg@cert.sei.cmu.edu. Distribution of this memo is unlimited. Table of Contents Purpose of this Work Author: J. Paul Holbrook (ph@cert.sei.cmu.edu) This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet. This guide lists issues and factors that a site must consider when setting their own policies. It makes some recommendations and gives discussions of relevant areas. This guide is only a framework for setting security policies and procedures. In order to have an effective set of policies and procedures, a site will have to make many decisions, gain agreement, and then communicate and implement the policies. Audience The audience for this work are system administrators and decision makers (who are more traditionally called "administrators" or "middle management") at sites. This document is not directed at programmers or those trying to create secure programs or systems. The focus of this document is on the policies and procedures that need to be in place to support any technical security features that a site may be implementing. The primary audience for this work are sites that are connected into the Internet. However, this document should be useful to any site that allows communication with other sites. As a general guide to Site Security Policy Handbook WG [Page 1] RFC 11XX Security Policy Handbook MMMM 1990 security policies, this document may also be useful to sites with isolated systems. Definitions For the purposes of this guide, a "site" is any organization that owns computers or network related resources. These resources may include host computers that users use, routers, terminal servers, PC or other devices that have access to the Internet. A site may be a end user of Internet services or a service provider such as a regional network. However, most of the focus of this guide is on those end users of Internet services. We assume that the site has the ability to set policies and procedures for itself with the concurrence and support from those who actually own the resources. The "Internet" is those set of networks and machines that use the TCP/IP protocol suite, connected through gateways, and sharing a common name and address spaces. [Quarterman 90 [matrix] p. 278]. The term "system administrator" is used to cover all those who are responsible for the day-to-day operation of resources. This may be a number of individuals or an organization. The term "decision maker" refers to those people at a site who set or approve policy. These are often (but not always) the people who own the resources. Related Work The IETF Security Policy Handbook Working Group (SPWG) is working on a recommended security policy for the Internet. These policy recommendations may be adopted by regional networks or owners of other resources. This handbook should be a useful tool to help sites implement those policies as desired or required. However, even implementing the proposed policies isn't enough to secure a site. The proposed Internet policies deal only with network access security. It says nothing about how sites should deal with local security issues. Scope This document covers issues about what a computer security policy should contain, what kinds of procedures are need to enforce security, and some recommendations about how to deal with the problem. Site Security Policy Handbook WG [Page 2] RFC 11XX Security Policy Handbook MMMM 1990 This is not a cookbook for computer security. Each site has different needs; the security needs of a corporation might well be different than the security needs of an academic institution. Any security plan has to confirm to the needs and culture of the site. This document does not cover details of how to do risk assessment, contingency planning, or physical security. These things are essential in setting and implementing effective security policy, but this document leaves treatment of those issues to other documents. We will try to provide some pointers in that direction. This document also doesn't talk about how to design or implement secure systems or programs. Need for Security Policies and Procedures For most sites, the interest in computer security is proportional to the perceived risk and threats. The world of computers has changed dramatically over the past 25 years. 25 years ago, most computers were centralized and managed by data centers. Computers were kept in locked rooms and staffs of people made sure they were carefully managed and physically secured. Links outside a site were unusual. Computer security threats were rare, and were basically concerned with insiders: authorized users misusing accounts, theft and vandalism, and so forth. These threats were well understood and dealt with using standard techniques: computers behind locked doors, accounting for all resources. Computing in the 90s is radically different. Many systems are in private offices and labs, often managed by individuals or persons employed outside a computer center. Many systems are connected into the Internet, and from there around the world: the United States, Europe, Asia, and Australia are all connected together. Security threats are different today. The time honored advice says "don't write your password down and put it in your desk" lest someone find it. With world wide Internet connections, someone could get into your system from the other side of the world and steal your password in the middle of the night when your building is locked up. Viruses and worms can be passed from machine to machine. The Internet allows the electronic equivalent of of the thief who looks for open windows and doors; now a person can check hundreds of machines in a few hours for vulnerabilities. System administrators and decision makers have to understand the security threats that exist, what the risk and cost of a problem would be, and what kind of action they want to take (if any) to Site Security Policy Handbook WG [Page 3] RFC 11XX Security Policy Handbook MMMM 1990 prevent and respond to security threats. Why Do We Need Security Policies and Procedures? As an illustration of some of the issues that need to be dealt with in dealing with security problems, consider some of the following scenarios (thanks to Russell Brand [Brand 90] for these): - A system programmer gets a call reporting that a major underground cracker newsletter is being distributed from the administrative machine at his center to five thousand sites in the US and Western Europe. Eight weeks later, the authorities call to inform you the information in one of these newsletters was used to disable ``911'' in a major city for five hours. - A user calls in to report that he can't login to his account at 3 in the morning on a Saturday. The system staffer can't login either. After rebooting to single user mode, he finds that password file is empty. By Monday morning, your staff determines that a number of privileged file transfer took place between this machine and a local university. Tuesday morning a copy of the deleted password file is found on the university machine along with password files for a dozen other machines. A week later you find that your system initialization files had been altered in a hostile fashion. - You receive a call saying that breakin to a government lab occurred from one of your center's machines. You are requested to provide accounting files to help track down the attacker. A week later you are given a list of machines at your site that have been broken into. - A reporter calls up asking about the breakin at your center. You haven't heard of any such breakin. Three days later you learn that there was a breakin. The center director had his wife's name as a password. Site Security Policy Handbook WG [Page 4] RFC 11XX Security Policy Handbook MMMM 1990 - A change in system binaries is detected. The day that it is corrected they again are changed. This repeats itself for some weeks. - If an intruder is found at on your system, should you leave the system open to monitor the situation or should you close down the holes and open up again later? - If an intruder is using your site, should you call law enforcement? Who makes that decision? If law enforcement asks you to leave your site open, who makes that decision? - What steps should be taken if another site calls you and says they see activity coming from an account on your system? What if the account is owned by a local manager? Basic Approach Setting security policies and procedures really means developing a plan for how to deal with computer security. One way to approach this task is suggested by Fites et. al [Fites 89]: Look at what you are trying to protect. Look at what you need to protect it from. Determine how likely the threats are. Implement measures which will protect your assets in a cost-effective manner. Review the process continuously, and improve things every time a weakness is found. This handbook will concentrate mostly on the last two steps, but the first three are critically important to making effective decisions about security. One old truism in security is that the cost of protecting yourself against a threat should be less than the cost recovering if the threat were to strike you. Without reasonable knowledge of what you are protecting and what the likely threats are, following this rule could be difficult. Organization of this Document This document is organized into six parts in addition to this introduction. Site Security Policy Handbook WG [Page 5] RFC 11XX Security Policy Handbook MMMM 1990 The basic form of each section is to discuss issues that a site might want to consider in creating a computer security policy and setting procedures to implement that policy. In some cases possible options are discussed along with the some of the ramifications of those choices. As far as possible, this document tries not to dictate the choices a site should make, since these depend on local circumstances. Some of the issues brought up may not apply to all sites. None the less, all sites should at least consider the issues brought up here to ensure that they do not miss some important area. The overall flow of the document is to discuss policy issues followed by the issues that come up in creating procedures to implement the policies. Section II discusses setting official site policies for access to computing resources. It also goes into the issue of what happens when the policy is violated. The policies will drive the procedures that need to be created, so decision makers will need to make choices about policies before many of the procedural issues in following sections can be dealt with. A key part of creating policies is doing some kind of risk assessment to decide what really needs to be protected and the level of resources that should be applied to protect them. Section III discusses procedures to prevent security problems. Prevention is a key to security; as an example, the Computer Emergency Response Team/Coordination Center (CERT/CC) at Carnegie Mellon University estimates that 80% or more of the problems they see have to do with poorly chosen passwords. Section IV discusses incident handling: what kinds of issues does a site face when someone violates the security policy. Many decisions will have to made on the spot as the incident occurs, but many of the options and issues can be discussed in advance. At very least, responsibilities and methods of communication can be established before an incident. Again, the choices here are influenced by the policies discussed in section II. Section V deals with what happens after a security violation has been dealt with. Security planning is an on-going cycle; just after an incident has occurred is an excellent opportunity to improve policies and procedures. The rest of the document provides resources that might be useful to a site, including a section of appendices on various topics and an annotated bibliography. Section 2 Site Security Policy Handbook WG [Page 6] RFC 11XX Security Policy Handbook MMMM 1990 Author: Greg Hollingsworth (gregh@aplcen.apl.jhu.edu) II. Establishing official site policy on computer security: A. Brief Overview 1. Organization Goals The goal in developing an official site policy on computer security is to define the organization's expectations of proper computer and network use and to define procedures to prevent and to respond to security incidents. 2. Who makes the policy? Policy creation must be a joint effort by technical personnel who understand the full ramifications of the proposed policy and the implementation of the policy and by administrators who have the power to enforce the policy. A policy which is neither enforceable nor implementable is useless. 3. Who is involved? Establishing a site policy has the potential for involving every computer user at the site in a variety of ways. Computer users may be responsible for personal password administration. Systems managers are obligated to fix security holes and to oversee the system. 4. Responsibilities There may be levels of responsibility associated with a policy on computer security. At one level, each user of a computing resource may have a responsibility to protect his account. A user who allows his account to be compromised increases the chances of compromising other accounts or resources. System managers may form another responsibility level, they must help to ensure the security of the computer system. Network managers may reside at yet another level. B. Risk Assessment 1. General discussion In establishing a site computer security policy, risks, the possibility of loss or damage to assets, must be determined. To find what is at risk, a site must first identify the assets it wishes to Site Security Policy Handbook WG [Page 7] RFC 11XX Security Policy Handbook MMMM 1990 protect. The potential threats to these assets must be calculated and the vulnerabilities determined. To determine the risks to guard against, rank each in order of the potential damage that could be caused. Consider the costs or inconveniences associated with protecting or recovering the asset. Keep in mind that it makes little sense to spend more protecting the asset than that asset is worth. 2. THREATS Identifying threat is a key element in calculating security risks. Consider what are you trying to protect your assets from. a. Unauthorized access A common threat that concerns many sites is unauthorized access to computing facilities. Unauthorized access takes many forms. A common means of unauthorized access is the use of another user's account to gain access to a system. The use of any computer resource without prior permission may be considered unauthorized access to computing facilities. The seriousness of an unauthorized access will vary from site to site. For some sites, the mere act of granting access to an unauthorized user may cause irreparable harm by negative media coverage. For other sites, an unauthorized access opens the door to other security threats. b. Disclosure of information Another common threat is disclosure of information. Determine the value or sensitivity of the information stored on your computers. Disclosure of a password file might allow for future unauthorized accesses. A glimpse of a proposal may give a competitor an unfair edge. A technical paper may contain years of valuable research. c. Denial of service Computers and networks provide valuable services to their users. Many people rely on these services in order to perform their jobs efficiently. When these services are not available when called upon, a loss in productivity results. Denial of service comes in many forms and might effect users in a number of ways. A network may be made unusable by a rogue packet, jamming, or by a disabled network component. A virus might slow down or cripple a computer system. The possibilities are large in Site Security Policy Handbook WG [Page 8] RFC 11XX Security Policy Handbook MMMM 1990 number. Determine the services that are essential to the site and the effect that would be realized if the service were to be disabled. d. .. and so forth .. 2. Possible problems To determine risk, vulnerabilities must be identified. Part of the purpone Section 2 Author: Jeff Carpenter (jjc@unix.cis.pitt.edu) University of Pittsburgh, Computing and Information Services C. Define authorized access to computing resources One of the most important steps you must take in developing your security policy is defining the following: 1. Who is allowed to use your services? 2. What they are allowed to use the system/services for. 3. What their rights and responsibilities for using the system/services are. This section of the handbook covers these questions. 1. Basic Assumptions: a. Connected to the Internet b. Inventory of networked components including PCs, servers, networked devices, physical security c. Introduce problem areas/assets 2. Policy Issues: a. Who is authorized to grant access and approve usage Your policy should state who is authorized to grant access to your services. Further, it must be determined what type of access they are permitted to give. There are many schemes that can be developed to control the distribution of access to your services. The following are the factors that you must consider when determining who will distribute access to your services: Site Security Policy Handbook WG [Page 9] RFC 11XX Security Policy Handbook MMMM 1990 1. Will you be distributing access from a centralized point or at various points? 2. What methods will you use for creating accounts and terminating access? 3. 1. You can have a centralized distribution point to a distributed system where various sites or departments independently distribute access. The trade off between security and convenience. The more centralized the easier to secure. 2. From a security standpoint, you need to examine the mechanism that you will be using to create accounts. In the least restrictive case, the persons who are authorized to grant access would be able to go into the system directly and create an account by hand or through vendor supplied mechanisms. Generally, these mechanisms place a great deal of trust in the person running them, and the person running them usually has a large amount of privileges. If this is the choice you make, you need to select someone who is trustworthy to perform this task. The opposite solution is to have an integrated system that the people authorized to create accounts run, or the users themselves may actually run. Be aware that even in the restrictive case of having a mechanized facility to create accounts does not remove the potential for abuse. developing procedures security issues b. Who is it you are giving access to? i. Who gets system administrator privileges or passwords One security decision that you need to make very carefully is who will have access to system administrator privileges and passwords for your services. You need to balance restricting access to these to protect security with giving people who need these privileges access so that they can perform their tasks. Mention possible schemes accountability for actions taken/auditing methods of selecting people c. What is proper use of resources i. Provide guidelines for acceptable use Site Security Policy Handbook WG [Page 10] RFC 11XX Security Policy Handbook MMMM 1990 You need to determine and ensure that the users are aware of what you will permit them to use their services for. You may have different guidelines for different types of users (i.e. students, faculty, external users). This policy needs to state what users are permitted to use their accounts for and what they cannot use their accounts for and what types of use may be restricted. restrictions: o students can complete course work only o for academic related purposes o no commercial use o consulting is/is not permitted o game playing is/is not permitted/is restricted You also need to determine what the consequences are for violating these policies and what mechanism you will develop to handle violations. (See section II.D) When connected to outside networks, such as a regional network, NSFNET, BITNET, etc.. you should mention that users using those external networks should use them in accordance to that networks acceptable use guidelines along with your policy. In addition, you may have restrictions concerning the type of use an account may have. An account that's use is being paid from a grant cannot be used for regular departmental work. ii. Exception cases like tiger teams and "License to hack" You may face the situation where users will want to "hack" on your services for security research purposes. You should develop a policy that will determine whether you will permit this type of research on your services and if so, what your guidelines for such research will be. Points you may wish to cover in this policy: o Whether is is permitted at all o What type of activity is permitted: hacking, releasing worms, releasing viruses, etc... o What type of controls must be in place to ensure that it does not get out of control (separate a segment of your network for these tests). How you will protect other users from being victims of these activities including external users and networks. o What the process for obtaining permission to conduct these tests are. You may also wish to employ, contract, or otherwise solicit one or more people or organizations to evaluate the security of your Site Security Policy Handbook WG [Page 11] RFC 11XX Security Policy Handbook MMMM 1990 services, of which may include "hacking". You may wish to provide for appropriate inclusion of provisions in your policy to permit this. iii. Define limits to access and authority You will need to consider the level of access various users will have and what resources will be available or restricted to various groups of people. d. What to do with sensitive information Before granting users access to your services, you need to determine at what level you will provide the security for data on your services. By determining this, you are determining the level of sensitivity of data that users should store on your systems. You do not want users to store very sensitive information on a system that you are not going to secure very well. You need to tell users who might store sensitive information what services, if any, are appropriate for the storage of sensitive information. This part should include storing of data in different ways (disk, mag tape, file servers) e. Proper use of copyrighted/licensed software You may wish to incorporate a statement in your policies concerning Copyrighted and licensed software. Licensing agreements with vendors may require some sort of effort on your part to ensure that the license is not violated. In addition, you may wish to inform users that the copying of copyrighted software may be a violation of the copyright laws, and is not permitted. Specifically concerning copyrighted and/or licensed software, you may wish to include the following information: o Copyrighted and licensed software may not be duplicated unless it is explicitly stated that it can o Methods of conveying information on the copyright/licensed status of software o When in doubt, don't copy 3. Ethical Behavior Site Security Policy Handbook WG [Page 12] RFC 11XX Security Policy Handbook MMMM 1990 In addition to specific policies and guidelines on acceptable use, you may wish to include an additional section in your policies concerning ethical use of computing resources. The following is a list of topics that might be covered in this section: o Academic dishonesty for students completing assignments 4. Users' Rights and Responsibilities You should adopt a policy that incorporates a statement on what a user's rights and responsibilities are concerning the use of your services. The following is a list of topics that you may wish to cover in this type of policy: o Whether users can read or modify files that do not belong to them (do they need the owners permission) o What might constitute abuse in terms of system performance o Whether users are permitted to share accounts or let others use their accounts o How secret users should keep their passwords o How often users should change their passwords and any other password restrictions/requirements o Whether you provide backups or expect the users to make their own o What guidelines you have regarding resource consumption (whether users are restricted, and if so, what the restrictions are) o Disclosure of information that may be proprietary o Statement on Electronic mail privacy o What users are specifically not permitted to do such as cracking passwords, trying to break into accounts, etc. o Your policy concerning controversial mail/postings to mailing lists or discussion groups (obscene, harassing, etc.) o Policy on electronic communications: mail forging, etc 5. Rights and responsibilities of System Administrators vs Rights of users a. Can an administrator monitor or read a user's files for any reason b. Liabilities c. Do net administrators have the right to examine network or host traffic There is a tradeoff between a user's right to absolute privacy and the need of system administrators to gather sufficient information to diagnose problems. There is also a distinction between a system administrators need to gather information to diagnose problems and looking/investigating use policy or security violations. You need to determine to what degree system administrators can examine user files to diagnose problems or for other purposes and what rights you grant to the users. You may also wish to make a statement concerning system administrators maintaining the privacy of information viewed Site Security Policy Handbook WG [Page 13] RFC 11XX Security Policy Handbook MMMM 1990 under these circumstances. Section 3 Draft of July 20, 1990 Authors: Frank Byrum (byrum@decuac.dec.com) Dave Curry (davy@itstd.sri.com) Sean Kirkpatrick (sean@nisc.cam.unisys.com) Allen Sturtevant (sturtevant@ccc.nersc.gov) 3. Establishing Procedures to Prevent Security Problems 3.1. Overview 3.1.1. - policy identifies assets to protect 3.1.2. - risk assessment establishes what's cost-effective to protect 3.1.3. - controls should be chosen to protect assets in cost-effective way 3.1.3.1. - many different ways to actually implement a policy; need to choose the right set of controls. 3.1.3.2. - use common sense -- no use using elaborate schemes if poor passwords can still be used to break system 3.1.4. - use multiple strategies to protect assets: if one is breached, another comes into play. 3.2. System Security Audits [SK] Most businesses undergo some sort of annual financial auditing as a regular part of their business life. Security audits are an important part of running any computing environment. Part of the security audit should be a review of any policies that concern system security, as well as the mechanisms that are put in place to enforce them. 3.2.1. Organize Scheduled Drills [SK] Although not something that would be done each day or week, scheduled drills should be conducted to determine if the procedures defined are adequate for the threat to be countered. If your major threat is one of natural disaster, then a drill should be conducted to verify your backup and recovery mechanisms. On the other hand, if your greatest Site Security Policy Handbook WG [Page 14] RFC 11XX Security Policy Handbook MMMM 1990 threat is from external crackers attempting to penetrate your system, a drill might be conducted to actually try a penetration to observe the effect of the policies. 3.2.2. Test Procedures 3.3. Account Management Procedures 3.3.1. - determine authorization of system or network use 3.4. Password Management Procedures 3.4.1. - determine authorization of system or network use 3.5. Configuration Management Procedures 3.5.1. Physical Security 3.5.1.1. - security boundary, site boundary 3.5.1.2. Definition of Terms 3.5.2. - develop tools as preventive and reactive 3.5.2.1. - inventory of tools 3.5.3. Non-Standard Configurations [DC] Occasionally it may be beneficial to have a slightly non-standard configuration in order to thwart the "standard" attacks used by some crackers. The non-standard parts of the configuration might include different password encryption algorithms, different configuration file locations, and rewritten or functionally limited system commands. Non-standard configurations, however, also have their drawbacks. By changing the "standard" system, these modifications make software maintenance more difficult by requiring extra documentation to be written, software modification after operating system upgrades, and usually someone with special knowledge of the changes. Because of the drawbacks of non-standard configurations, they are often only used in environments with a "firewall" machine (see section 3.9.1). The firewall machine is modified in non-standard ways since it is susceptible to attack, while internal systems behind the firewall are left in their standard configurations. 3.6. Procedures to Recognize Unauthorized Activity [DC] Site Security Policy Handbook WG [Page 15] RFC 11XX Security Policy Handbook MMMM 1990 Several simple procedures can be used to detect most unauthorized uses of a computer system. These procedures use tools provided with the operating system by the vendor, or tools publicly available from other sources. 3.6.1. Monitoring System Use [DC] System monitoring can be done either by a system administrator, or by software written for the purpose. Monitoring a system involves looking at several parts of the system, searching for anything unusual. Some of the easier ways to do this are described in this section. The most important thing about monitoring system use is that it be done on a regular basis. Picking one day out of the month to monitor the system is pointless, since a security breach can be over and done with in a matter of hours. Only by maintaining a constant vigil can you expect to detect security violations in time to react to them. 3.6.2. Tools for Monitoring the System [DC] This section describes tools and methods for monitoring a system against unauthorized access and use. 3.6.2.1. Logging [DC] Most operating systems store numerous bits of information in log files. Examination of these log files on a regular basis is often the first line of defense in detecting unauthorized use of the system. - Compare lists of currently logged in users and past login histories. Most users typically log in and out at roughly the same time each day. An account logged in outside the "normal" time for the account may be in use by a cracker. - Many systems maintain accounting records for billing purposes. These records can also be used to determine usage patterns for the system; unusual accounting records may indicate unauthorized use of the system. - System logging facilities, such as the UNIX "syslog" utility, should be checked for unusual error messages from system software. For example, a large number of failed login attempts in a short period of time may indicate someone trying to guess passwords. - Operating system commands which list currently executing processes can be used to detect users running programs they are not authorized to use, as well as to detect unauthorized programs which have been Site Security Policy Handbook WG [Page 16] RFC 11XX Security Policy Handbook MMMM 1990 started by a cracker. 3.6.2.2. Monitoring Software [DC] Other monitoring tools can easily be constructed using standard operating system software, by using several often unrelated programs together. For example, check lists of file ownerships and permission settings can be constructed (for example, with "ls" and "find" on UNIX) and stored off-line. These lists can then be reconstructed periodically and compared against the master check list (on UNIX, by using the "diff" utility). Differences may indicate that unauthorized modifications have been made to the system. Still other tools are available from third party vendors and public software distribution sites. Section 3.9.7 lists several sources from which you can learn what tools are available, and how to get them. 3.6.2.3. Other Tools [DC] Other tools can also be used to monitor systems for security violations, although this is not their primary purpose in life. For example, network monitors can be used to detect and log connections from unknown sites. 3.6.3. Vary the Monitoring Schedule The task of system monitoring is not as daunting as it may seem. System administrators can execute many of the commands used for monitoring periodically throughout the day during idle moments (e.g. while talking on the telephone), rather than spending fixed periods of each day monitoring the system. By executing the commands regularly, you will rapidly become used to seeing "normal" output, and will easily spot things which are out of the ordinary. By running various monitoring commands at different times throughout the day, you make it hard for a cracker to predict your actions. For example, if an intruder knows that each day at 5:00pm the system is checked to see that everyone has logged off, he will simply wait until after the check has completed before logging in. But the intruder cannot guess when a system administrator might type "who" in an idle moment, and thus he runs a much greater risk of detection. 3.7. - define actions to take when unauthorized activity is suspected. 3.8. Communicating Security Policy [DC] Security policies, in order to be effective, must be communicated to Site Security Policy Handbook WG [Page 17] RFC 11XX Security Policy Handbook MMMM 1990 both the users of the system and the system maintainers. This section describes what these people should be told, and how to tell them. 3.8.1. Educating the Users [DC] Users should be made aware of how the computer systems are expected to be used, and how to protect themselves from unauthorized users. 3.8.1.1. Proper Account/Workstation Use [DC] All users should be informed about what is considered "proper" use of their account or workstation. This can most easily be done at the time a user receives her account, by giving her a policy statement. Proper use policies typically dictate things such as whether or not the account or workstation may be used for personal activities (such as checkbook balancing or letter writing), whether profit-making activities are allowed, whether game playing is permitted, and so on. These policy statements may also be used to summarize how the computer facility is licensed and what software licenses are held by the institution; for example, many universities have educational licenses which explicitly prohibit commercial uses of the system. 3.8.1.2. Account/Workstation Management Procedures [DC] Each user should be told how to properly manage their account and/or workstation. This includes explaining how to protect files stored on the system, how to log out or lock the terminal/workstation, and so on. Much of this information is typically covered in the "beginning user" documentation provided by the operating system vendor, although many sites elect to supplement this material with local information. If your site offers dial-up modem access to the computer systems, special care must be taken to inform users of the security problems inherent in providing this access. Issues such as making sure to log out before hanging up the modem should be covered when the user is initially given dial-up access. Likewise, access to the systems via local and wide-area networks presents its own set of security problems which users should be made aware of. Files which grant "trusted host" or "trusted user" status to remote systems and users should be carefully explained. 3.8.1.3. Password Management Procedures [DC] Perhaps the most vulnerable part of any computer system is the account password. Any computer system, no matter how secure it is from network or dial-up attack, Trojan horse programs, and so on, can Site Security Policy Handbook WG [Page 18] RFC 11XX Security Policy Handbook MMMM 1990 be fully exploited by a cracker if he can gain access via a poorly chosen password. It is important to define a good set of rules for password selection, and distribute these rules to all users. If possible, the software which sets user passwords should be modified to enforce as many of the rules as possible. A sample set of guidelines for password selection is shown below: - DON'T use your login name in any form (as-is, reversed, capitalized, doubled, etc.). - DON'T use your first, middle, or last name in any form. - DON'T use your spouse's or child's name. - DON'T use other information easily obtained about you. This includes license plate numbers, telephone numbers, social security numbers, the make of your automobile, the name of the street you live on, etc. - DON'T use a password of all digits, or all the same letter. - DON'T use a word contained in English or foreign language dictionaries, spelling lists, or other lists of words. - DON'T use a password shorter than six characters. - DO use a password with mixed-case alphabetics. - DO use a password with non-alphabetic characters (digits or punctuation). - DO use a password that is easy to remember, so you don't have to write it down. - DO use a password that you can type quickly, without having to look at the keyboard. Methods of selecting a password which adheres to these guidelines include: - Choose a line or two from a song or poem, and use the first letter of each word. - Alternate between one consonant and one or two vowels, up to seven or eight characters. This provides nonsense words which are usually pronounceable, and thus easily remembered. - Choose two short words and concatenate them together with a punctuation Site Security Policy Handbook WG [Page 19] RFC 11XX Security Policy Handbook MMMM 1990 character between them. Users should also be told to change their password periodically, usually every three to six months. This makes sure that a cracker who has guessed a password will eventually lose access, as well as invalidating any list of passwords he may have obtained. Many systems enable the system administrator to force users to change their passwords after an expiration period; this software should be enabled if your system supports it. [Reference: "Improving the Security of Your UNIX System", David A. Curry, SRI International Report ITSTD-721-FR-90-21, April 1990] 3.8.1.4. Determining Account Misuse [DC] Users should be told how to detect unauthorized access to their account. If the system prints the last login time when a user logs in, she should be told to check that time and note whether or not it agrees with the last time she actually logged in. Command interpreters on some systems (e.g. the UNIX C shell) maintain histories of the last several commands executed. Users should check these histories to be sure someone has not executed other commands with their account. 3.8.1.5. Problem Reporting Procedures [DC] A procedure should be developed to enable users to report suspected misuse of their accounts, or other misuse they may have noticed. This can be done either by providing the name and telephone number of a system administrator who manages security of the computer system, or by creating an electronic mail address (e.g., "security") to which users can address their problems. 3.8.2. Educating the Host Administrators [DC] In many organizations, computer systems are administered by a wide variety of people. These administrators must know how to protect their own systems from attack and unauthorized use, as well as how to communicate successful penetration of their systems to other administrators as a warning. 3.8.2.1. Account Management Procedures [DC] Care must be taken when installing accounts on the system in order to make them secure. When installing a system from distribution media, the password file should be examined for "standard" accounts provided Site Security Policy Handbook WG [Page 20] RFC 11XX Security Policy Handbook MMMM 1990 by the vendor. Many vendors provide accounts for use by system services or field service personnel. These accounts typically have either no password or one which is common knowledge. These accounts should be given new passwords if they are needed, or disabled and/or deleted from the system if they are not. Accounts without passwords should never be allowed on the system, regardless of how "harmless" they are. Even accounts which do not execute a command interpreter can be compromised if set up incorrectly. If the operating system provides a "shadow" password facility which stores passwords in a separate file accessible only to privileged users, this facility should be used. System V UNIX, SunOS 4.0 and above, and versions of Berkeley UNIX after 4.3BSD Tahoe, as well as others, provide this feature. Keep track of who has access to privileged user accounts (e.g. "root" on UNIX or "MAINT" on VMS). Whenever a privileged user leaves the organization or no longer has need of the privileged account, the passwords on all privileged accounts should be changed. 3.8.2.2. Configuration Management Procedures [DC] When installing a system from the distribution media, or when installing third-party software, it is important to check the installation carefully. Many installation procedures assume a "trusted" site, and hence will install files with world write permission enabled, etc. Network services should also be examined carefully when first installed. Many vendors provide default network permission files which imply that all outside hosts are to be "trusted", which is rarely the case when connected to wide-area networks such as the Internet. Bug fixes supplied by the vendor should always be installed. Other bug fixes, received via network mailing lists and the like, should usually be installed, but not without careful examination. Never install a bug fix unless you're sure you know what the consequences of the fix are - there's always the possibility that a cracker has suggested a "fix" which actually gives him access to the system. 3.8.2.3. Recovery Procedures - Backups [DC] It is impossible to overemphasize the need for a good backup strategy. File system backups not only protect you in the event of hardware failure or accidental deletions, but they also protect you Site Security Policy Handbook WG [Page 21] RFC 11XX Security Policy Handbook MMMM 1990 against unauthorized changes made by a cracker. A good backup strategy will dump the entire system to tape at least once a month. Partial (or "incremental") dumps should be done at least twice a week, and ideally they should be done daily. Commands specifically designed for performing file system backups (e.g. UNIX "dump" or VMS "BACKUP") should be used in preference to other file copying commands, since these tools are designed with the express intent of restoring a system to a known state. 3.8.2.4. Problem Reporting Procedures [DC] As with users, system administrators should have a defined procedure for reporting security problems. In large installations, this is often done by creating an electronic mail alias which contains the names of all system administrators in the organization. 3.9. Resources to Prevent Security Breaches [SK] This section discusses software, hardware, and procedural resources that can be used to support your site security policy. 3.9.1. - concept of "inter-net" and "outer-net" - circles of trust, "firewalls" of protection [SK] A "firewall" is put in place in a building to provide a point of resistance to the entry of flames into another area. Similarly, a secretary's desk and reception area provides a point of controlling access to other office spaces. This same technique can be applied to a computer site, particularly as it pertains to network connection. Some sites will be connected only to other sites within the same organization and will not have the ability to connect to other networks. Sites such as these are not susceptible to threats from outside their own organization. On the other hand, many other organizations will be connected to other organizations via much larger networks, such as the Internet. These sites are susceptible to the entire range of threats incipient to a networked environment. One must carefully examine the need for connection to wide area networks. If your organization wishes to remain protected from WAN threats, the connection may simply be removed or should not made in the first place. If there is need to participate in a WAN, consider restricting all access to your local network through a single system. That is, all access to or from your own local network must be made through a single host computer that acts as a firewall between you and the outside world. This firewall system should be rigorously controlled and password protected, and external users accessing it Site Security Policy Handbook WG [Page 22] RFC 11XX Security Policy Handbook MMMM 1990 should also be constrained by restricting the functionality available to remote users. By using this approach, your site could relax some of the internal security controls on your local net, but still be afforded the protection of a rigorously controlled host front end. Note that compromise of the remote host could result in compromise of the local network. 3.9.2. Confidentiality [SK] Confidentiality, the act of keeping things hidden or secret, is one of the primary goals of computer security practitioners. Several mechanisms are provided by most modern operating systems to enable users to control the dissemination of information. Depending upon where you work, you may have a paranoid site, where everything is protected, or an unconcerned site, where all information is usually regarded as public. Most sites lean toward the latter, at least until some penetration has occurred. 3.9.2.1. Encryption (hardware and software) [SK] Encryption is the process of taking information that exists in some readable form and converting it into a non-readable form. There are several types of commercially available encryption packages in both hardware and software forms. Hardware encryption engines have the advantage that they are much faster than the software equivalent, yet because they are faster, they are of greater potential benefit to an attacker who wants to execute a brute force attack to your encrypted information. 3.9.2.1.1. DES [SK] DES, the Data Encryption Standard, is perhaps the most widely used data encryption mechanisms used today. Many hardware and software implementations exist, and some commercial computers are provided with a software version. DES transforms plain text information into encrypted data (or ciphertext) by means of a special algorithm and "seed" value called a key. So long as the key is retained (or remembered) by the original user, the ciphertext can be restored to the original plain text. One of the pitfalls of all encryption systems is the need to remember the key under which a thing was encrypted (this is not unlike the password problem discussed elsewhere in this document). If the key is written down, it becomes less secure. If forgotten, there is little if any hope of recovering the original data. Most UNIX systems provide a DES command that enables a user to Site Security Policy Handbook WG [Page 23] RFC 11XX Security Policy Handbook MMMM 1990 encrypt data using the DES algorithm. This implementation has been slightly modified so that it doesn't exactly reproduce the DES algorithm, which (allegedly) increases its resistance to attack. It cannot be said with any certainty that this is true. *** This is not true of the command itself; only the password encryption routine. *** 3.9.2.1.2. Crypt [SK] Similar to the DES command, the UNIX 'crypt' command allows a user to encrypt data. Unfortunately, the algorithm used by 'crypt' is very insecure (based on the World War II "Enigma" device), and files encrypted with this command can be decrypted easily in a matter of a few hours. Generally, use of the 'crypt' command should be avoided for any but the most trivial encryption tasks. 3.9.2.2. Privacy Enhanced Mail [SK] Electronic mail normally transits the network in the clear (anyone can read it). This is clearly not the optimal solution. Privacy enhanced mail provides a means to automatically encrypt your electronic mail messages so that a person eavesdropping at a mail distribution node is not (easily) capable of reading your mail messages. Several privacy enhanced mail packages are currently being developed, although none are currently in widespread use on the Internet. 3.9.3. Origin Authentication [SK] We mostly take it on faith that the header of an electronic mail message truly indicates the originator of a message. However, there are documented cases it which mail messages have been "spoofed", or forged using someone elses name. Origin authentication provides a means to be certain of the originator of a message or other object in the same way that a Notary Public assures a signature on a legal document. This is done by means of a "Public Key" cryptosystem. A public key cryptosystem differs from a private key cryptosystem in several ways. First, a public key system uses two keys, a Public key that anyone can use (hence the name, Public Key) and a Private key that only the originator of a messages uses. The originator uses the private key to encrypt the message similar to DES. The receiver, who has obtained the public key for the originator, may then decrypt the message. In this scheme, the public key is used to authenticate the originators use of her private key, and hence the identity of the originator is more rigorously proven. Site Security Policy Handbook WG [Page 24] RFC 11XX Security Policy Handbook MMMM 1990 The most widely known implementation of a public key cryptosystem is the RSA system. Although not widely used at present, public key cryptosystems should begin to make their way into the commercial and private sectors in the near future. 3.9.4. Information Integrity [SK] Information Integrity refers to the state of information such that it is complete, correct, and unchanged from the last time in which it was verified to be in an "integral" state. The degree to which information can be considered "Integral" (sic) is dependent upon the site. For example, it is far more important for DoD installations to prevent the "disclosure" of classified information, whether it is right or wrong. A bank, on the other hand, is far more concerned with whether the account information maintained for its customers is complete and accurate. Numerous computer system mechanisms, as well as procedural controls, have an influence on the integrity of system information. Traditional access control mechanisms maintain controls over who can access system information. These mechanisms alone are not sufficient in some cases to provide the degree of integrity required. Some other mechanisms are briefly discussed below. It should be noted that there are other aspects to maintaining system integrity besides these mechanisms, such as two person controls, and Integrity Validation Procedures. These are beyond the scope of this document and the interested reader should refer to the appendix for more information. 3.9.4.1. Checksums [SK] Easily the simplest mechanism, a simple checksum routine can compute a value for a system file and compare it with the last known value. If the two are equal, no change has occurred. If not, the file has been changed by some unknown means. Though it is the easiest to implement, the checksum scheme suffers from a serious failing in that it is not very sophisticated and a determined attacker could easily add enough characters to the file to eventually obtain the correct value. 3.9.4.2. CRC Checksum [SK] The CRC Checksum mechanism is considerably more robust than the simple checksum mechanism described above. It is only slightly more difficult to implement and provides a much finer degree of catching errors. It too, however, suffers from the ability to be compromised Site Security Policy Handbook WG [Page 25] RFC 11XX Security Policy Handbook MMMM 1990 by an attacker. 3.9.4.3. Cryptosealing [SK] Cryptosealing is the process of breaking a file up into smaller chunks, calculating a (CRC) checksum for each chunk, and adding the CRC's together. Depending upon the exact algorithm used, this can result in a nearly unbreakable method of determining whether a file has been changed. This mechanism suffers from the fact that it is computationally intensive and may be prohibitive except in cases where the utmost integrity protection is desired. 3.9.5. Limiting Network Access [DC] The dominant network protocols in use on the Internet, IP [RFC791], TCP [RFC793], and UDP [RFC768], carry certain control information which can be used to restrict access to certain hosts or networks within an organization. The IP packet header contains the network addresses of both the sender and recipient of the packet. Further, the TCP and UDP protocols provide the notion of a "port", which identifies the endpoint (usually a network server) of a communications path. In some instances, it may be desirable to deny access to a specific TCP or UDP port, or even to certain hosts and networks altogether. 3.9.5.1. Gateway Routing Tables [DC] One of the simplest approaches to preventing unwanted network connections is to simply remove certain networks from a gateway's routing tables. This makes it "impossible" for a host to send packets to these networks. (Most protocols require bidirectional packet flow even for unidirectional data flow, thus breaking one side of the route is usually sufficient.) This approach is commonly taken in "firewall" systems, by preventing the firewall from advertising local routes to the outside world. The approach is deficient in that it often prevents "too much", e.g. in order to prevent access to one system on the network, access to all systems on the network is disabled. 3.9.5.2. Router Packet Filtering [DC] Many commercially available gateway systems (more correctly called routers) provide the ability to filter packets based not only on sources or destinations, but also on source-destination combinations. This mechanism can be used to deny access to a specific host, network, or subnet from any other host, network, or subnet. Site Security Policy Handbook WG [Page 26] RFC 11XX Security Policy Handbook MMMM 1990 Gateway systems from cisco Systems support an even more complex scheme, allowing finer control over source and destination addresses. Via the use of address masks, once can deny access to all but one host on a particular network. The cisco systems also allow packet screening based on IP protocol type and TCP or UDP port numbers. [Reference: "Simple and Flexible Datagram Access Controls for UNIX- based Gateways", Jeffrey C. Mogul, Digital Western Research Laboratory Research Report 89/4, March 1989] 3.9.6. Authentication Systems [SK] Authentication refers to the process of proving a claimed identity to the satisfaction of some permission granting authority. Authentication systems are hardware, software, or procedural mechanisms that enable a user to obtain access to computing resources. At the simplest level, the system administrator who adds new user accounts to the system is part of the system authentication mechanism. At the other end of the spectrum, finger print readers or retinal scanners provide a very high tech solution to establishing a potential user's identity. Without establishing and proving a user's identity prior to establishing a session, your sites computers are vulnerable to any sort of attack. Typically, a user authenticates herself to the system by entering a password in response to a prompt. Challenge/Response mechanisms improve upon passwords by prompting the user for any one of a number of pieces of information shared by both the computer and the user (such as mother's maiden name, etc.). 3.9.6.1. Kerberos [SK] Kerberos, named after the dog who in mythology is said to stand at the gates of Hades, is a collection of software used in a large network to establish a user's claimed identity. Developed at MIT, it uses a combination of encryption and distributed databases so that a user at a campus facility could log in and start a session from any computer located on the campus. This has clear advantages in certain environments where there are a large number of potential users who may establish a connection from any one of a large number of workstations. 3.9.6.2. Smart Cards [SK] In the recent past, some computer systems have instituted new password procedures that require a user to enter a value obtained Site Security Policy Handbook WG [Page 27] RFC 11XX Security Policy Handbook MMMM 1990 from a "smart card" (a small calculator-like device) when asked for a password by the computer. Typically, the host machine will give the user some piece of information that is entered into the keyboard of the smart card. The smart card will display the response which must then be entered into the computer before the session will be established. This is a better way of dealing with authentication than with the traditional password approach. On the other hand, some say it's inconvenient to carry the smart card. Start up costs are likely to be high as well. 3.9.7. Books/Lists/Informational Sources [SK] There are many good sources for information regarding computer security. The annotated bibliography at the end of this document is one of the most comprehensive available anywhere. In addition, information can be obtained from a variety of sources. 3.9.7.1. Security Mailing Lists [DC] The UNIX Security mailing list exists to notify system administrators of security problems before they become common knowledge, and to provide security enhancement information. It is a restricted-access list, open only to people who can be verified as being principal systems people at a site. Requests to join the list must be sent by either the site contact listed in the Network Information Center's WHOIS database, or from the "root" account on one of the major site machines. You must include the destination address you want on the list, an indication of whether you want to be on the mail reflector list or receive weekly digests, the electronic mail address and voice telephone number of the site contact if it isn't you, and the name, address, and telephone number of your organization. This information should be sent to "security-request@cpd.com". The RISKS digest is a component of the ACM Committee on Computers and Public Policy, moderated by Peter G. Neumann. It is a discussion forum on risks to the public in computers and related systems, and along with discussing computer security and privacy issues, has discussed such subjects as the Stark incident, the shooting down of the Iranian airliner in the Persian Gulf (as it relates to the computerized weapons systems), problems in air and railroad traffic control systems, software engineering, and so on. To join the mailing list, send a message to "risks-request@csl.sri.com". This list is also available in the USENET newsgroup "comp.risks". The VIRUS-L list is a forum for the discussion of computer virus experiences, protection software, and related topics. The list is Site Security Policy Handbook WG [Page 28] RFC 11XX Security Policy Handbook MMMM 1990 open to the public, and is implemented as a mail reflector, not a digest. Most of the information is related to personal computers, although some of it may be applicable to larger systems. To subscribe, send the line SUB VIRUS-L your full name to the address "listserv%lehiibm1.bitnet@mitvma.mit.edu". 3.9.7.2. Networking Mailing Lists [DC] The TCP-IP list is intended to act as a discussion forum for developers and maintainers of implementations of the TCP/IP protocol suite. It also discusses network-related security problems when they involve programs providing network services, such as "sendmail". To join the TCP-IP list, send a message to "tcp-ip-request@nic.ddn.mil". This list is also available in the USENET newsgroup "comp.protocols.tcp-ip". 3.9.7.3. The Computer Emergency Response Team (CERT) [DC] The Computer Emergency Response Team (CERT) was established in December 1988 by the Defense Advanced Research Projects Agency to address computer security concerns of research users of the Internet. It is operated by the Software Engineering Institute at Carnegie- Mellon University. The CERT serves as a focal point for the reporting of security violations, and the dissemination of security advisories to the Internet community. In addition, the team works with vendors of various systems in order to coordinate the fixes for security problems. The CERT sends out security advisories to the "cert-advisory" mailing list whenever appropriate. They also operate a 24-hour hotline that can be called to report security problems (e.g., someone breaking into your system), as well as to obtain current (and accurate) information about rumored security problems. To join the "cert-advisory" mailing list, send a message to "cert@cert.sei.cmu.edu" and ask to be added to the mailing list. Past advisories are available for anonymous FTP from the host "cert.sei.cmu.edu". The 24-hour hotline number is (412) 268-7090. 3.9.7.4. DDN Management Bulletins [DC] The DDN Management Bulletin is distributed electronically by the Defense Data Network (DDN) Network Information Center under contract to the Defense Communications Agency. It is a means of communicating official policy, procedures, and other information of concern to Site Security Policy Handbook WG [Page 29] RFC 11XX Security Policy Handbook MMMM 1990 management personnel at DDN facilities. The DDN Security Bulletin is distributed electronically by the DDN SCC (Security Coordination Center), also under contract to DCA, as a means of communicating information on network and host security exposures, fixes, and concerns to security and management personnel at DDN facilities. Anyone may join the mailing lists for these two bulletins by sending a message to "nic@nic.ddn.mil" and asking to be placed on the mailing lists. 3.9.7.5. System Administration Lists [DC] The SUN-SPOTS, SUN-NETS, and SUN-MANAGERS lists are all discussion groups for users and administrators of systems supplied by Sun Microsystems. SUN-SPOTS is a fairly general list, discussing everything from hardware configurations to simple UNIX questions. To subscribe, send a message to "sun-spots-request@rice.edu". This list is also available in the USENET newsgroup "comp.sys.sun". SUN-NETS is a discussion list for items pertaining to networking on Sun systems. Much of the discussion is related to NFS, Yellow Pages, and name servers. To subscribe, send a message to "sun-nets- request@umiacs.umd.edu". SUN-MANAGERS is a discussion list for Sun system administrators and covers all aspects of Sun system administration. To subscribe, send a message to "sun-managers-request@eecs.nwu.edu". *** Also describe info-vax, etc. 3.9.7.6. Vendor Specific System Lists 3.9.7.7. Professional Societies [SK] The IEEE Technical Committee on Security & Privacy publishes a quarterly magazine, "CIPHER". IEEE Computer Society, 1730 Massachusetts Ave. N.W. Washington, DC 2036-1903 The ACM SigSAC (Special Interest Group on Security, Audit, and Controls) publishes a quartely magazine, "SIGSAC Review". Association for Computing Machinery 11 West 42nd St. Site Security Policy Handbook WG [Page 30] RFC 11XX Security Policy Handbook MMMM 1990 New York, N.Y. 10036 The Information Systems Security Association publishes a quarterly magazine called "ISSA Access". Information Systems Security Association P.O. Box 9457 Newport Beach, CA 92658 3.9.8. Problem Reporting Tools 3.9.9. Auditing [SK] Auditing is an important tool that can be used to enhance the security of your installation. Not only does it give you a means of identifying who has accessed your system (and maybe done something to it) but it also gives you an indication of how your system is being used (abused) by authorized users and attackers alike. In addition, the audit trail traditionally kept by computer systems can become an invaluable piece of evidence should your system be penetrated. 3.9.9.1 Verify Security [SK] An audit trail shows how the system is being used from day to day. Depending upon how your site audit log is configured, your log files should show a range of access attempts that can show what normal system usage should look like. Deviation from that normal usage could be the result of penetration from an outside source using an old (stale) user account. Observing a deviation in logins, for example, could be your first indication that something unusual is happening. 3.9.9.2. Verify Software Configurations [SK] One of the ruses used by attackers to gain access to a system is by the insertion of a so-called Trojan Horse program. A Trojan Horse program can be a program that does something useful, or merely something interesting. It always does something unexpected, like steal passwords or copy files without your knowledge. Imagine a Trojan login program that prompts for username and password in the usual way, but also writes that information to a special file that the attacker can come back and read at will. Imagine a Trojan Editor program that, despite the file permissions you have given your files, makes copies of everything in your directory space without you knowing about it. This points out the need for configuration management of the software that runs on a system, not as it is being developed, but as it is in actual operation. Techniques for doing this range from checking each Site Security Policy Handbook WG [Page 31] RFC 11XX Security Policy Handbook MMMM 1990 command every time it is executed against some criteria (such as a cryptoseal, described above) or merely checking the date/time stamp of the executable. Another technique might be to check each command in batch mode at midnight. 3.9.9.3. Tools [DC] COPS is a security tool for system administrators that checks for numerous common security problems on UNIX systems. COPS is a collection of shell scripts and C programs that can easily be run on almost any UNIX variant. Among other things, it checks the following items and sends the results to the system administrator: - Checks "/dev/kmem" and other devices for world read/writability. - Checks special/important files and directories for "bad" modes (world writable, etc.). - Checks for easily guessed passwords. - Checks for duplicate user ids, invalid fields in the password file, etc. - Checks for duplicate group ids, invalid fields in the group file, etc. - Checks all users' home directories and their ".cshrc", ".login", ".profile", and ".rhosts" files for security problems. - Checks all commands in the "/etc/rc" files and "cron" files for world writability. - Checks for bad "root" paths, NFS file systems exported to the world, etc. - Includes an expert system that checks to see if a given user (usually "root") can be compromised, given that certain rules are true. - Checks for changes in the setuid status of programs on the system. The COPS package is available from the "comp.sources.unix" archive on "ftp.uu.net", and also from the UNIX-SW repository on the MILNET host "wsmr-simtel20.army.mil". *** What else? 3.9.10. Communication Among Administrators 3.9.11. Secure Operating Systems [DC] Site Security Policy Handbook WG [Page 32] RFC 11XX Security Policy Handbook MMMM 1990 The following list of products and vendors is adapted from the National Computer Security Centers Evaluated Products List. They represent those companies who have either received an evaluation from the NCSC or are in the process of a product evaluation. This list is not complete, but it is representative of those operating systems and add on components available in the commercial marketplace. For a more detailed listing of the current products appearing in the NCSC EPL, contact the NCSC at: National Computer Security Center 9800 Savage Road Fort George G. Meade, MD 20755-6000 (301) 859-4458 Version Evaluation Evaluated Product Vendor Evaluated Class ------------------------------------------------------------------------------- Secure Communications Honeywell Information 2.1 A1 Processor (SCOMP) Systems, Inc. Multics Honeywell Information MR11.0 B2 Systems, Inc. System V/MLS 1.1.2 on UNIX AT&T 1.1.2 B1 System V 3.1.1 on AT&T 3B2/500 and 3B2/600 OS 1100 Unisys Corp. Security B1 Release 1 MPE V/E Hewlett-Packard Computer G.03.04 C2 Systems Division AOS/VS on MV/ECLIPSE series Data General Corp. 7.60 C2 VM/SP or VM/SP HPO with CMS, IBM Corp. 5 C2 RACF, DIRMAINT, VMTAPE-MS, ISPF MVS/XA with RACF IBM Corp. 2.2,2.3 C2 VAX/VMS Digital Equipment Corp. 4.3 C2 NOS Control Data Corp. NOS Security C2 Eval Product TOP SECRET CGA Software Products 3.0/163 C2 Site Security Policy Handbook WG [Page 33] RFC 11XX Security Policy Handbook MMMM 1990 Group, Inc. Access Control Facility 2 SKK, Inc. 3.1.3 C2 UTX/32S Gould, Inc. Computer 1.0 C2 Systems Division A Series MCP/AS with Unisys Corp. 3.7 C2 InfoGuard Security Enhancements Primos Prime Computer, Inc. 21.0.1DODC2A C2 Resource Access Control IBM Corp. 1.5 C1 Facility (RACF) Version Candidate Candidate Product Vendor Evaluated Class ------------------------------------------------------------------------------- Boeing MLS LAN Boeing Aerospace A1 M1 Trusted XENIX Trusted Information Systems, Inc. B2 VSLAN VERDIX Corp. B2 System V/MLS AT&T B1 VM/SP with RACF IBM Corp. 5/1.8.2 C2 Wang SVS/OS with CAP Wang Laboratories, Inc. 1.0 C2 3.9.12. Obtaining Fixes for Known Problems [SK] It goes without saying that computer systems have bugs. Even operating systems, upon which we depend for protection of our data, has bugs. And since there are bugs, things can be broken, both maliciously and accidentally. It is important that whenever bugs are discovered, that a fix be found and implemented just as soon as possible. This should minimize any exposure caused by the bug in the first place. Corollary to the bug problem is, from whom do I obtain the fixes? Most systems have some support from the manufacturer or supplier. Fixes coming from that source tend to be implemented quickly after receipt. Fixes for some problems are often posted on the network and are left to the system administrators to incorporate as they can. The problem is that one wants to have faith that the fix will close the hole and not introduce any others. We will tend to trust that Site Security Policy Handbook WG [Page 34] RFC 11XX Security Policy Handbook MMMM 1990 the manufacturer's fixes are better than those that are posted on the net. The best solution [??????????] 3.9.13. Trusted Archive Servers [DC] Several sites on the Internet maintain large repositories of public- domain and freely distributable software, and make this material available for anonymous FTP. This section describes some of the larger repositories. 3.9.13.1. Sun Fixes on UUNET [DC] Sun Microsystems has contracted with UUNET Communications Services, Inc. to make fixes for bugs in Sun software available via anonymous FTP. You can access these fixes by using the "ftp" command to connect to the host "ftp.uu.net". Then change into the directory "sun-fixes", and obtain a directory listing. The file "README" contains a brief description of what each file in this directory contains, and what is required to install the fix. 3.9.13.2. Berkeley Fixes [DC] The University of California at Berkeley also makes fixes available via anonymous FTP; these fixes pertain primarily to the current release of BSD UNIX (currently release 4.3). However, even if you are not running their software, these fixes are still important, since many vendors (Sun, DEC, Sequent, etc.) base their software on the Berkeley releases. The Berkeley fixes are available for anonymous FTP from the host "ucbarpa.berkeley.edu" in the directory "4.3/ucb-fixes". The file "INDEX" in this directory describes what each file contains. Berkeley also distributes new versions of "sendmail" and "named" from this machine. New versions of these commands are stored in the "4.3" directory, usually in the files "sendmail.tar.Z" and "bind.tar.Z", respectively. 3.9.13.3. Simtel-20 and UUNET The two largest general-purpose software repositories on the Internet are the hosts "wsmr-simtel20.army.mil" and "ftp.uu.net". "wsmr-simtel20.army.mil" is a TOPS-20 machine operated by the U. S. Army at White Sands Missile Range, New Mexico. The directory "pd2:" contains a large amount of UNIX software, primarily taken from the "comp.sources" newsgroups. The directory "pd2:" [???] contains software for IBM PC systems, and Site Security Policy Handbook WG [Page 35] RFC 11XX Security Policy Handbook MMMM 1990 "pd2:" [???] contains software for the Apple Macintosh. "ftp.uu.net" is operated by UUNET Communications Services, Inc. in Falls Church, Virginia. This company sells Internet and USENET access to sites all over the country (and internationally). The software posted to the following USENET source newsgroups is stored here, in directories of the same name: comp.sources.games comp.sources.misc comp.sources.sun comp.sources.unix comp.sources.x Numerous other distributions, such as all the freely distributable Berkeley UNIX source code, Internet Request for Comments (RFCs), and so on are also stored on this machine. 3.9.13.4. Vendors [DC] Many vendors make fixes for bugs in their software available electronically, either via mailing lists or via anonymous FTP. You should contact your vendor to find out if they offer this service, and if so, how to access it. Some vendors that offer these services include Sun Microsystems (see above), Digital Equipment Corp., the University of California at Berkeley (see above), and Apple Computer. [Reference: "Improving the Security of Your UNIX System", David A. Curry, SRI International Report ITSTD-721-FR-90-21, April 1990] Section 4 Section 5 Site Security Policy Handbook Section 5 Draft of July 25, 1990 Authors: Frank Byrum (byrum@decuac.dec.com) Jim Duncan (jim@math.psu.edu) 5. Establishing post-incident procedures 5.1 Overview Site Security Policy Handbook WG [Page 36] RFC 11XX Security Policy Handbook MMMM 1990 In general removing all vulnerabilities once an incident has occurred in a difficult problem. It can be very difficult, in some cases, to decided which backup tapes to recover from. Not to mention that may sites have poor if any backup procedures. In may cases the preincident preparation will determine what recovery is possible. At worst case a restore from the original manufacturer tapes and a re- customization of the systems may be the only solution. If possible review the lessons learned from the incident and always update the policy and procedures to reflect changes necessitated be the incident. 5.2 Removing vulnerabilities 5.2.1 Assessing damage Before cleanup can begin, the actual system damage must be discerned. This can be quite time consuming, but should lead into some of the insight as to the nature of the incident. It is best to compare to previous backups or original tapes when possible. Having known good checksums of system files that have been kept off-line or encrypted can help in evaluating whether system programs or files have been corrupted. The checksum program itself should be loaded from a known good source. 5.2.2 Cleanup Once the damage has been assessed it is necessary to develop a plan for system cleanup. In general, bring up services in the order of demand to allow minimum uses inconvenience is the best practice. Understand proper recovery procedures for the system is extremely important and should be site specific. It may be necessary to go back to the original distributed tapes and recustomize the system. To facilitate this worst case scenario, a record of the original systems setup and each customization change should be kept current with each change to the system. Note that the backups can be corrupted as well, especially if they introduced Trojan Horse programs or modified standard system scripts or files. The best bet is to restore only user data from backup and all system files from installation tapes. Of course, if you can determine what they did and assure yourself that it's all they did, you might be able to avoid this. If the intruder could have captured any information or passwords that might help them get back in later, this information should be changed. Especially for Unix systems, ALL passwords should be Site Security Policy Handbook WG [Page 37] RFC 11XX Security Policy Handbook MMMM 1990 changed, as the intruder could have taken a copy of the password file and use it to get back in at a later time. Even if a 'good' password was used, a sufficiently persistent intruder may be able to crack it. 5.2.3 Follow up Once you believe that a system has been restored to a "safe" state, it is still possible holes and even traps to be lurking in the system. In the follow up stage the system is monitored for things that may have been missed during the cleanup stage. It would be prudent to used some of the tools in section 1 of the appendices (eg. COPS) as a start. Remember these tools don't replace continual system monitoring and good systems administration procedures If the intruder could have captured any information or passwords that might help them get back in later, this information should be changed. Especially for Unix systems, ALL passwords should be changed, as the intruder could have taken a copy of the password file and use it to get back in at a later time. Even if a 'good' password was used, a sufficiently persistent intruder may be able to crack it. 5.2.4 Keep a Security Log A security log can be most valuable during this phase of removing vulnerabilities. There are two considerations here, the first is to keep logs of the procedures that have been used to make the system secure again. This should include command procedures (eg shell scripts) that can be run on a periodic basis to recheck the security. Second, keep logs of important systems events. These can be referenced when trying to determine the extent of the damage of a given incident. Be careful where this log is maintained. Though security should not rely on secrecy, if an intruder knows the exact procedures and techniques you use to secure a system, they may be able to subvert them. 5.3 Capturing Lessons Learned 5.3.1 Understand lesson After an incident it is prudent to write a document describing the incident, method of discovery, correction procedure, monitoring procedure, and summary of lesson learned. This will aid in the clear understanding of the problem. Remember, it is difficult to learn from a problems it you don't understand the problem. 5.3.2 Resources Site Security Policy Handbook WG [Page 38] RFC 11XX Security Policy Handbook MMMM 1990 5.3.2.1 Other security devices, methods Security is a dynamic not static process. Depending on the nature of security at each site that are array of devices and methods that will help promote security. Keeping up with the security section of the computer industry and methods will assure a security manager of taking advantage of the latest technology. 5.3.2.2 Repository of books, list, information sources Keep an on site collection of books, list, information sources, etc as guides and references for securing the system. Keep this collection up to date. Remember, as systems changes so do security methods and problems. 5.3.2.3 Form a Subgroup Form a subgroup of system administrations personal that will be the core security staff. This will allow discussions of security problems and multiply views of sites security issues. This groups can also act to develop the site security policy and make suggested changes as necessary to ensure site security. 5.4 Upgrading policies and procedures 5.4.1 Establish mechanism for updating policies and procedures, tool If an incident is based on poor policy, then unless the policy is changed one is doomed to repeat the past. Once a incident has been recovered from, site policy and procedures should be reviewed to encompass changes to prevent similar incidents. This also would be prudent to review on a regular basis even with out incidents to allow for reviews of procedures and to implement policy and procedure changes due to today's dynamic changing computing environments. 5.4.2 Problem reporting procedures A problem reporting procedure should be implemented to describe in detail the incident and the solutions to the incident. Each incident should be review by the site security subgroup to allow understanding of the incident with possible suggestions to the site policy and procedures. Section 7 Annotated Bibliography DRAFT BIBLIOGRAPHY - 25 July 1990 Site Security Policy Handbook WG [Page 39] RFC 11XX Security Policy Handbook MMMM 1990 Internet Activities Board, "Ethics and the Internet", RFC 1087, IAB, January 1989. Also appears in the Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989. National Science Foundation, "NSF Poses Code of Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. 688, June 1989. Also appears in the minutes of the regular meeting of the Division Advisory Panel for Networking and Communications Research and Infrastructure, Dave Farber, Chair, November 29-30 1988. Massachusetts Institute of Technology, "Teaching Students About Responsible Use of Computers", MIT, 1985-1986. Also reprinted in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena Project, MIT, June 1989. Computer Professionals for Social Responsibility, "CPSR Statement on the Computer Virus", CPSR, Communications of the ACM, Vol. 32, No. 6, Pg. 699, June 1989. Eisenberg, T., D. Gries, J. Hartmanis, D. Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell University, 6 February 1989. Eichin, M., and J. Rochlis, "With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988", Massachusetts Institute of Technology, February 1989. Seeley, D., "A Tour of the Worm", Proceedings of 1989 Winter USENIX Conference, Usenix Association, San Diego, CA, February 1989. Spafford, E., "The Internet Worm Program: An Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM, January 1989. Also issued as Purdue CS Technical Report CSD-TR-823, 28 November 1988. DCA DDN Defense Communications System, "DDN Security Bulletin 03", DDN Security Coordination Center, 17 October 1989. Aucoin, R., "Computer Viruses: Checklist for Recovery", Computers in Libraries, Vol. 9, No. 2, Pg. 4, 1 February 1989. American Bar Association, Section of Science and Technology, "Guide to the Prosecution of Telecommunication Fraud by the Use of Computer Crime Statutes", American Bar Association, 1989. Site Security Policy Handbook WG [Page 40] RFC 11XX Security Policy Handbook MMMM 1990 Barnes, J., "Drawing the Lines: Changes in Computer Technology and Law Guarantee that Resdistricting in ther 1990s will be Different and a More Difficult Game", National Journal, Vol. 21, No. 13, Pg. 787, 1 April 1989. Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol. 19, No. 2, Pg. 32, 1 April 1989. Bellovin, S., "The Worm and the Debug Option", Forum Risks to the Publics in Computer and Related Systems, Vol. 7, No. 74, ACM Committee on Computers and Public Policy, 10 November 1988. Bender, D., "Computer Law: Evidence and Procedure", (Kept up to date with supplements.), M. Bender, New York, NY, 1978-present. Bidgoli, H., and R. Azarmsa, "Computer Security: New Managerial Concern for the 1990's and Beyond", Journal of Systems Management, Vol. 40, No. 10, Pg. 21, 1 October 1989. Bloombecker, J., "Short-Circuiting Computer Crime", Datamation, Vol. 35, No. 19, Pg. 71, 1 October 1989. Bloombecker, J., and J. Buck, "Computer Ethics for Cynics", Computers and Society, Vol. 18, No. 3, Pgs. 30-32, ACM Special Interest Group on Computers and Society, New York, NY, July 1988. Bologna, J. "Computer Insecurities: An Analysis of Recent Surveys on Computer Related Crime and Computer Security", Data Processing & Communications Security, Vol. 12, No. 4, Fall 1988. Bologna, J. "The One Minute Fraud Auditor", Computers & Security, Vol. 8, No. 1, Pg. 29, 1 February 1989. Brand, R., "Attack of the Tiger Teams: Inside America's Computer Security Crisis", Tempus Books, August 1989. Brenner, A., "LAN Security", LAN Magazine, August 1989. Burger, R., "Computer Viruses: A High-Tech Disease", 2nd Edition, Abacus, Grand Rapids, Michigan, 1988. Campell, D., "Computer Contagion", Security Management, Vol. 32, No. 10, Pg. 83, 1 October 1988. Chess, D., "Computer Viruses and Related Threats to Computer and Network Integrity", Computer Networks and ISDN Systems, Vol. 17, No. 2, 1989. Site Security Policy Handbook WG [Page 41] RFC 11XX Security Policy Handbook MMMM 1990 Christiansen, D., "A Matter of Ethics", IEEE Spectrum, Vol. 25, Pg. 15, August 1988. Cohen, F., "Computational Aspects of Computer Viruses", Computers & Security, Vol. 8, No. 4., Pg. 325, 1 June 1989. Cohen, F., "Models of Practical Defenses Against Computer Viruses", Computers & Security, Vol. 8, No. 2, Pg. 149, 1 April 1989. Colyer, J., "Risks of Unchecked Input in C Programs", Forum Risks to the Publics in Computer and Related Systems, Vol. 7, No. 74, ACM Committee on Computers and Public Policy, 10 November 1988. Commerce Clearing House, "Guide to Computer Law", (Topical Law Reports), Chicago, Ill., 1989. Computer Law and Tax Report, "Difficult to Prosecute Virus Authors", Computer Law and Tax Report, Vol. 15, No. 5, Pg. 7, 1 December 1988. Computer Law and Tax Report, "Virus Bill Introduced", Computer Law and Tax Report, Vol. 15, No. 4, Pg. 13, 1 November 1988. Cornell Computer Science Department, "Policy for the Use of the Research Computing Facility", Cornell University, 21 August, 1987. Data Communications, "Internet Virus Aftermath: Is Tighter Security Coming?", Data Communications, Vol. 17, No. 14, Pg. 52, 1 December 1988. Defense Data Network, "BSD 4.2 and 4.3 Software Problem Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 November 1988. Demaio, H., "Viruses - A Management Issue", Computers & Security, Vol. 8, No. 5, Pg. 381, 1 August 1989. Denning, P., "The Science of Computing: The Internet Worm", American Scientist, Vol. 77, No. 2, Pgs. 126-128, March 1989. Devoy, J., Gilssmann, R., and K. Miklofsky, "Media, File Management Schemes Facilitate WORM Utilization", Computer Technology Review, Vol. 8, No. 13, Fall 1988. Dewdney, A., "Computer Recreations; Of Worms, Viruses and Core War", Scientific American, March 1989 Discover, "Technology: Communicable Computer Disease", Discover, Vol. 10, No. 1, Pg. 64, 1 January 1989. Site Security Policy Handbook WG [Page 42] RFC 11XX Security Policy Handbook MMMM 1990 El-Baghdadi, M., "The Pivotal Role in Computer Security", Security Management, Vol. 33, No. 7, Pg. 63, 1 July 1989. Electronic Learning, "Computer Viruses: An Epidemic Real or Imagined?", Electronic Learning, Vol. 8, No. 6, April 1989. Eloff, J., "Computer Security Policy: Important Issues", Computers & Security, Vol. 7, No. 6, Pg. 559, 1 December 1988. Ellis, A., "Underwriting Update-Computer Viruses: Working Out the Bugs", Best's Review, Vol. 90, No. 1, Pg. 84, 1 May 1989. Fenwick, W., Chair, "Computer Litigation, 1985: Trial Tactics and Techniques", Litigation Course Handbook Series No. 280, Prepared for distribution at the Computer Litigation, 1985: Trial Tactics and Techniques Program, February-March 1985. Fifield, K., "Smartcards Outsmart Computer Crime", Computers & Security, Vol. 8, No. 3, May 1989. Fites, P., Johnston, P., and M. Kratz, "The Computer Virus Crisis", Van Nostrand Reinhold, New York, NY., 1989 Forcht, K., Thomas, D., and K. Wigginton, "Computer Crime: Assessing the Lawyer's Perspective", Journal of Business Ethics, Vol. 8, No. 4 April 1989. Gardner, E., Samuels, L., and B. Render, "Computer Security", The Journal of Information Systems Management, Vol. 6, No. 4, Pg. 42, Fall 1989. Gardner, P., "The Internet Worm: What Was Said and When", Computers & Security, Vol. 8, No. 4, June 1989. Gemignani, M., "Viruses and Criminal Law", Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989. Gerlth, J., "Intruders Into Computer Systems Still Hard to Prosecute", The New York Times, 5 November 1988. Gleissner, W., "A Mathematical Theory for the Spread of Computer Viruses", Computers & Security, Vol. 8, No. 1, Pg. 35, 1 February 1989. Greenberg, R., "Know thy Viral Enemy: It's More Important Than Ever to Guard Your Data and Your System Against Infection by Computer Viruses", Byte, Vol. 14, No. 6, Pg. 275, 1 June 1989. Site Security Policy Handbook WG [Page 43] RFC 11XX Security Policy Handbook MMMM 1990 Greenia, M., "Computer Security Information Sourcebook", Lexikon Services, Sacramento, CA, 1989. Harvard College, "Misuse of Computer Systems", Handbook for Students", Pg. 85, Harvard College, 1987-1988. Hawkins, C., "What Users Should Know About Computer Viruses", Telecommunications, North American Edition, Vol. 23, No. 7, 1 July 1989. Herrick, G., "Computer Viruses: Prevention is Better than Cure", The Accountant's Magazine, Vol. 93, No. 992, Pg. 24, 1 March 1989. Hertzoff, I., "Layer Your LAN", Security Management, Vol. 33, No. 9, Pg. 201, 1 September 1989. Highland, H., "Reports from the Victims", Computers & Security, Vol. 8, No. 2, Pg. 101, 1 April 1989. Hoffer, J., and D. Straub, "The 9 to 5 Underground: Are You Policing Computer Crimes?", Sloan Management Review, Vol. 30, No. 4, Pg. 35, Summer 1989. Hoffman, L., "Risk Analysis and Computer Security: Towards a Theory at Last", Computers & Security, Vol. 8, No. 1, Pg 23, 1 February 1989. Huband, F., and R. Shelton, Editors, "Protection of Computer Systems and Software: New Approaches for Combating Theft of Software and Unauthorized Intrusion", Papers presented at a workshop sponsored by the National Science Foundation, 1986. Hughes, W., "The Computer Fraud and Abuse Act of 1986, Congressional Record (30 April 1986)", Washington, D.C., 30 April 1986. Information Executive, "Promoting Computer Ethics: The Next Generation", Information Executive, Vol., 2, No. 4, Pg. 42, Fall 1989. Jamieson, R., and L. Graham, "Security and Control Issues in Local Area Network Design, Computers & Security, Vol. 8, No. 4, Pg. 305, 1 June 1989. Jander, M., "The Naked Network", Computer Decisions, Vol. 21, No. 4, Pg. 39, 1 April 1989. Keenan, T., "Emerging Vulnerabilities in Office Automation Security", Computers & Security, Vol. 8, No. 3, Pg. 223, 1 May 1989. Site Security Policy Handbook WG [Page 44] RFC 11XX Security Policy Handbook MMMM 1990 Kellam-Scott, B., "Profile: Bellcore Computer and Network Security Symposium", Bellcore Exchange, Vol. 5, No. 1, Pg. 24, 1 January 1989. King, K., "Overreaction to External Attacks on Computer Systems Could be More Harmful Than the Viruses Themselves", Chronicle of Higher Education, Pg. A36, 23 November 1988. Also in: Educom Bulletin, Vol. 23, No. 4, Pg. 5, Winter 1988 Kluepfel, H., "Computer Use and Abuse: Computer Systems and Their Data are Vulnerable to Error, Omission, and Abuse", Security Management, Vol. 33, No. 2, Pg. 72, 1 February 1989. Kosko, J., "Computer Security Experts Advise Steps to Reduce the Risk of Virus Attacks", Virus Discussion List, 22 September 1989. Kruys, J., "Security of Open Systems", Computers & Security, Vol. 8, No. 2, Pg. 139, 1 April 1989. Lapsley, P., "'We are Under Attack. . .' (The Internet 'Worm': a Chronology)", UNIX Review, Vol. 7, No. 1, Pgs. 69-70, 72-73, January 1989. Lerner, E., "Computer Virus Threatens to Become Epidemic", Aerospace America, Vol. 27, No. 2, Pg. 14, 1 February 1989. Lu, W., and M. Sundareshan, "Secure Communication in Internet Environments: A Hierachical Key Management Scheme for End-to-End Encryption", IEEE Transactions on Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989. Lunt, T., "Access Control Policies: Some Unanswered Questions", Computers & Security, Vol. 8, No. 1, Pg. 43, 1 February 1989. Lynn, M., "Ethical Responsibility Key to Computer Security", The Educational Record, Vol. 70, No. 2, Pg. 36, Spring 1989. Martin, M., and R. Schinzinger, "Ethics in Engineering", McGraw Hill, 2nd Edition, 1989. McAfee, J., "The Virus Cure", Datamation, Vol. 35, No. 4, Pg. 29, 15 February 1989. McEwen, J., "Dedicated Computer Crime Units", Report Contributors: D. Fester and H. Nugent, Prepared for the National Institute of Justice, U.S. Department of Justice, by Institute for Law and Justice, Inc. under contract number OJP-85-C-006, Washington, D.C., 1989. Site Security Policy Handbook WG [Page 45] RFC 11XX Security Policy Handbook MMMM 1990 Menkus, B., "It's Time to Rethink Data Processing Fire Protection", Computers & Security, Vol. 8, No. 5, Pg. 389, 1 August 1989. Menkus, B., "The Computer Virus Situation is not Encouraging", Computers & Security, Vol. 8, No. 2, Pg. 115, 1 April 1989. Menkus, B., "The Employee's Role in Protecting Information Assets", Computers & Security, Vol. 8, No. 6, Pg. 487, 1 October 1989. Menkus, B., "Understanding Password Compromise", Computers & Security, Vol. 7, No. 6, Pg. 549, 1 December 1989. Menkus, B., "U.S. Government Agencies Belatedly Address Information System Security Issues", Computers & Security, Vol. 7, No. 4, Pg. 361, 1 August 1988. Mizock, M., "Ethics--The Guiding Light of Professionalism", Data Management, Vol. 24, No. 8, August 1986. Moir, D., "Maintaining System Security", Dr. Dobb's Journal of Software Tools for the Pro, Vol. 14, No. 6, Pg. 75, 1 June 1989. National Computer Security Center, "Proceedings of the Virus Post- Mortem Meeting", NCSC, St. George Meade, MD, 8 November 1988. National Institute of Standards and Technology, "Computer Viruses and Related Threats: A Management Guide", NIST Special Publication 500- 166, August 1989. Neumann, P., Editor, "Forum of Risks to the Public in Computers and Related Systems", Vol. 7, No. 69, ACM Committee on Computers and Public Policy, 3 November 1988. NSF Network Service Center (NNSC), "Internet Computer Virus Update", NSFNET, Cambridge, MA, 4 November 1988. Ostapik, F., "The Effect of the Internet Worm on Network and Computer Security", ConneXtions, Vol. 3, No. 9, Pgs. 16-17, September 1989. Palmore, T., "Computer Bytes: Viruses and Vaccines", TechTrends, Vol. 34, No. 2, Pg. 26, 1 March 1989. Parker, D., "Fighting Computer Crime", Scribner, New York, 1983. Parker, D., "Computer Crime: Criminal Justice Resource Manual", U.S. Dept. of Justice, National Institute of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, Washington, D.C., August 1989. Site Security Policy Handbook WG [Page 46] RFC 11XX Security Policy Handbook MMMM 1990 Perry, W., "Why Software Defects So Often Go Undiscovered", Government Computer News, Vol. 7, No. 24, Pg. 85, 21 November 1988. Radai, Y., "The Israeli PC Virus", Computers & Security, Vol. 8, No. 2, Pg. 111, 1 April 1989. Reese, L., "Of MICE and Men", Security Management, Vol. 33, No. 9, Pg. 89, 1 September 1989. Resource Management, "Computer Viruses: Background and Recommendations for Keeping Software Healthy are Detailed", Resource Management, Pg. 8, 1 July 1989. Richards, T., and R. Knotts, "Top Management's View of Computer Related Fraud", Sig Security, Audit & Control Review, Vol. 6, No. 4, Pg. 34, Winter 1989. Rivera, A., "Computer Viruses: A Different Perspective", Data Processing & Communications Security, Vol. 13, No. 1, Winter 1989. Rowe, J., Shelton, C., and M. Krohn, "Avoiding Computer Viruses", Business Education Forum, Vol. 44, No. 2, Pg. 17, 1 November 1989. Samuelson, P., "Can Hackers be Sued for Damages Caused by Computer Viruses?", Communications of the ACM, Vol. 32, No. 6, Pgs. 666-669, June 1989. Schneider, W., "Computer Viruses: What They Are, How They Work, How They Might Get You, and How to Control Them in Academic Institutions", Behavior Research Methods, Instruments, & Computers, Vol. 21, No. 2, Pg. 334, 1 April 1989. Schultz, J., "Low Cost Security Solutions for Personal Computers", Signal, Vol. 44, No. 3, Pg. 71, 1 November 1989. Schweitzer, J., "Protecting Information on Local Area Networks", Butterworths, Boston, 1988. Seeley, D., "Password Cracking: A Game of Wits", Communications of the ACM, Vol. 32, No. 6, Pgs. 700-703, June 1989. Shadabuddin, S., "Computer Security Problems and Control Techniques", American Business Review, Vol. 7, No., 1, Pg. 14, 1 January 1989. Shaw, E., Jr., "Computer Fraud and Abuse Act of 1986, Congressional Record (3 June 1986), Washington, D.C., 3 June 1986. Slayden, P. II, "Computer Flu Blues: Computer Managers Must be Ready Site Security Policy Handbook WG [Page 47] RFC 11XX Security Policy Handbook MMMM 1990 to Provide Vaccines Against Infectious Computer Viruses", Security Management, Vol. 33, No. 8, Pg. 108, 1 August 1989. Spafford, E., "Some Musing on Ethics and Computer Break-Ins", Proceedings of the Winter USENIX Conference, USENIX Association, San Diego, CA, February 1989. Spafford, E., "The Internet Worm: Crisis and Aftermath", Communications of the ACM, Vol. 32, No. 6, Pgs. 689-698, June 1989. Spafford, G., "A Cure!!!!!", Forum Risks to the Publics in Computer and Related Systems, Vol. 7, No. 70, ACM Committee on Computers and Public Policy, 3 November 1988. Spafford, G., "A Worm 'condom'", Forum Risks to the Publics in Computer and Related Systems, Vol. 7, No. 70, ACM Committee on Computers and Public Policy, 3 November 1988. State of Wisconsin, "Computer Law - State of Wisconsin Statute", Chapter 293, Laws of 1981, Section 943.70, Computer Crimes. Steinberg, T., "Developing a Computer Security Charter", Sig Security, Audit & Control Review, Vol. 6, No. 4, Pg. 12, Winter 1989. Stoll, C., "How Secure are Computers in the U.S.A.?", Computers & Security, Vol. 7, No. 6, Pg. 543, 1 December 1988. Stoll, C., "Stalking the Wily Hacker", Communications of the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988. Stoll, C., "The Cuckoo's Egg", ISBN 00385-24946-2, Doubleday, 1989. Tester, D., "The Key to Data Security", Security Management, Vol. 33, No., 9, Pg. 206, 1 September 1989. The Engineer, "Disk Diseases", The Engineer, Vol. 267, No. 6921, Pg. 28, 17 November 1988. Tinto, M., "Computer Viruses: Prevention, Detection, and Treatment", National Computer Security Center C1 Technical Report C1-001-89, June 1989. Trible, P., "The Computer Fraud and Abuse Act of 1986", U.S. Senate Committee on the Judiciary, 1986. United States, "Computer Fraud and Abuse Act of 1986, An Act to Amend Title 18, United States Code, to Provide Additional Penalties for Fraud and Related Activities in Connection with Access Devices and Site Security Policy Handbook WG [Page 48] RFC 11XX Security Policy Handbook MMMM 1990 Computers, and for Other Purposes", Washington, D.C., G.P.O., Distributor, 1986. United States Congress House Committee on Science, Space, and Technology, Subcommittee on Transportation, Aviation, and Materials, "Implementation of the Computer Security Act: Hearing Before the Subcommittee on Transportation, Aviation, and Materials of the Committee on Science, Space, and Technology", U.S. House of Representatives, One Hundredth Congress, Second Session, Washington, D.C., 22 September 1988. United States Congress House Committee on Science, Space, and Technology, Subcommittee on Transportation, Aviation, and Materials, "Implementation of the Computer Security Act: Hearing Before the Subcommittee on Transportation, Aviation, and Materials and the Subcommittee on Science, Research, and Technology of the Committee on Science, Space, and Technology", U.S. House of Representatives, One Hundred First Congress, First Session, Washington, D.C., 21 March 1989. United States Congress Senate Committee on the Judiciary, "The Computer Fraud and Abuse Act of 1986, Hearing before the Committee on the Judiciary", United States Senate, Ninety-ninth Congress, Second Session, Washington, D.C., 16 April 1986. United States Congress Senate Committee on the Judiciary, "The Computer Fraud and Abuse Act of 1986, Report (to accompany H.R. 4712)", Washington, D.C., 22 May 1986. United States Congress Senate Committee on the Judiciary, "The Computer Fraud and Abuse Act of 1986, Report Together with Additional Views", Ninety-ninth Congress, Second Session, Washington, D.C., 3 September 1986. United States General Accounting Office, "Computer Security", GAO/IMTEC-89-57, June 1989. United States of America, "Computer Security Act of 1987", G.P.O. Distributor, Washington D.C., 1988. Vance, M., "Computer Crime", Vance Bibliographies, Monticello, Ill., February 1988. Vasilyev, D., and Y. Novikov, "Technology: Computer Viruses", Soviet Life, No. 394, Pg. 37, 1 July 1989. Wasik, M., "Law Reform Proposals on Computer Misuse", The Crimminal Law Review, Pg. 257, 1 April 1989. Site Security Policy Handbook WG [Page 49] RFC 11XX Security Policy Handbook MMMM 1990 White, C. Jr., "Viruses and Worms: A Campus Under Attack", Computers & Security, Vol. 8, No. 4, Pg. 283, 1 June 1989. White, S., and D. Chess, "Coping with Computer Viruses and Related Problems", IBM Research Report RC 14405 (#64367), January 1989. Wiseman, S., "Preventing Viruses in Computer Systems", Computers and Security, Vol. 8, No. 5, Pg. 427, 1 August 1989. Wood, C., "Planning: A Means to Achieve Data Communications Security", Computers & Security, Vol. 8, No. 3, Pg. 189, 1 May 1989. Yovel, S., "Conquering Computer Viruses", Security Management, Vol. 33, No. 2, Pg. 64, 1 February 1989. Zajac, B., "Disaster Recovery - Are You Really Ready?", Computers & Security, Vol. 8, No. 4, Pg. 297, 1 June 1989. Zajac, B., "Legal Options to Computer Viruses", Computers & Security, Vol. 8, No. 1, Pg. 25, 1 February 1989. Zajac, B., "Viruses: Should We Quit Talking About Them", Computers & Security, Vol. 7, No. 5, Pg. 471, 1 October 1989. Agrawal, D., and A. El Abbadi, "Integrating Security with Fault- tolerant Distributed Databases", The Computer journal, Vol. 33, No. 1, Pg. 71, 1 February 1990. Al-Dossary, G., "Computer Virus Protection and Containment on Mainframes", Computers & Security, Vol. 9, No. 2, Page 131, 1 April 1990. Axelrod, C., "Security During System Recovery and Repair", The Journal of Information Systems Management", Vol. 7, No. 1, Pg. 42, Winter 1989. Aucoin, R., "Guarding Against Computer Viruses: Some General Precautions", Computer in Libraries, Vol. 9, No. 11, Pg. 24, 1 December 1989. Bacon, M., "Assessing Public Network Security", Telecommunications - North American Edition, Vol. 23, No. 12, Pg. 19, 1 December 1989. Badenhorst, K., and J. Eloff, "Framework of a Methodology for the Life Cycle of Computer Security in an Organization", Computers & Security, Vol. 8, No. 5, Pg. 433, 1 August 1989. Site Security Policy Handbook WG [Page 50] RFC 11XX Security Policy Handbook MMMM 1990 Bear, G., "Knowledge of Computer Ethics: Its Relationship to Computer Attitude and Sociomoral Reasoning", Journal of Educational Computing Research, Vol. 6, No. 1, Pg. 77, 1990. Caelli, W., Editor, "Computer Security in the Age of Information", Proceedings of the Fifth IFIP International Conference on Computer Security, IFIP/Sec '88. Cavanagh, J., "Securing Data with 10NET Secure LAN", LAN Technology, Vol. 6, No. 5, Page 39, 1 May 1990. Conly, C., "Organizing for Computer Crime Investigation and Prosecution", U.S. Dept. of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, National Institute of Justice, Washington, D.C., July 1989. Cooper, J., "Computer and Communications Security: Strategies for the 1990s", McGraw-Hill, 1989. Current Municipal Problems, "Getting the Bugs Out: Computer Security", Current Municipal Problems, Vol. 16, No. 12, Pg. 243, 1989. Data processing & communications security, "Computer Security Practitioner's Legal Handbook", Vol. 14, No. 1, Page 19, Winter 1990. Data processing & communications security, "Internal Controls", Vol 14, No. 1, Page 13, Winter 1990. DeGroot, K., "An Overview of Recent Changes in California Computer Crime Laws", Santa Clara Computer and High-technology Law Journal, Vol. 6, No. 1, Pg. 135, 1 March 1990. Desilets Jr., R., "Software Vendors' Exposure to Products Liability for Computer Viruses", Computer Law Journal, Vol. 9, No. 4, Pg. 509, Fall 1989. Feuerlicht, J., and P. Grattan, "The Role of Classification of Information in Controlling Data Proliferation in End-User Personal Computer Environment", Vol. 8, No. 1, Pg. 59, 1 February 1989. Flach, J., "Not Just Another Article on Viruses: Will all this Attention on Computer Viruses Lead to More Harm than Good?", Data processing & communications security, Vol. 13, No. 3, Pg. 11, Summer 1989. Site Security Policy Handbook WG [Page 51] RFC 11XX Security Policy Handbook MMMM 1990 Gould, C., Editor, "The Information Web: Ethical and Social Implications of Computer Networking", Westview Press, Boulder, CO., 1989. Hayes, F., "Is Your System Safe?", UNIX World, Vol. 7, No. 6, Page 44, 1 June 1990. Kammer, R., "Defending Against Virus Attacks", Security Management, Vol. 34, No. 5, Page 37, 1 May 1990. Lu, W., and M. Sundareshan, "A Model for Multilevel Security in Computer Networks", IEEE transactions on software engineering, Vol. 16, No. 6, Page 647, 1 June 1990. I'Anson, C., and C. Mitchell, "Security Defects in CCITT Recommendation X.509 - The Directory Authentication Framework", Computer communication review, Vol. 20, No. 2, Page 30, 1 April 1990. Informationweek, "Security Complex", No. 273, Page 36, 4 June 1990. Informationweek, "Judgment Day", Informationweek, No. 269, Page 57, 7 May 1990. Joseph, G., "Computer Virus Recovery Planning-An Auditor's Concerns", Journal of accounting and EDP, Vol. 6, No. 1, Pg. 26, Spring 1990. Kent, Stephen, "E-Mail Privacy for the Internet: New Software and Strict Registration Procedures will be Implemented this Year", Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January 1990. Kerr, S., "Using AI to Improve Security", Datamation, Vol. 36, No. 3, Pg. 57, 1 February 1990. Keefe, T., Thuraisingham, M., and W. Tsai, "Secure Query- Processing Strategies", Computer, Vol. 22, No. 3, Pg. 63, 1 March 1989. Knotts, R., and R. Richards, "Computer Security: Who's Minding the Store?", The Academy of Management Executive, Vol. 3, No. 1, Pg. 63, 1 February 1989. Management review, "Controlling the Threat to Computer Security, Vol. 79, No. 6, Page 54, 1 June 1990. McEwen, J., "Dedicated Computer Crime Units", Report Site Security Policy Handbook WG [Page 52] RFC 11XX Security Policy Handbook MMMM 1990 Contributors, Dennis Fester, Hugh Nugent, Prepared for the National Institute of Justice, U.S. Department of Justice, by the Institute for Law and Justice, Inc., Under Contract Number OJP-85-C-006, Washington, D.C., June 1989. Mills, D., Schragger, P., and M. Davis, "Internet Architecture Workshop: Future of the Internet System Architecture and TCP/IP Protocols", Computer communication review, Vol. 20, No. 1, Pg. 6, 1 January 1990. National Computer Security Conference, "12th National Computer Security Conference : Baltimore Convention Center, Baltimore, MD, 10-13 October, 1989 : Information systems security, solutions for today - concepts for tomorrow", National Institute of Standards and National Computer Security Center, 1989. National Computer Security Center, "Guidelines for formal verification systems", Shipping list no.: 89-660-P, The Center, Fort George G. Meade, MD, 1 April 1990. National Computer Security Center, "Glossary of computer security terms", Shipping list no.: 89-254-P, The Center, Fort George G. Meade, MD, 21 October 1988. National Computer Security Center, "Trusted UNIX Working Group (TRUSIX) rationale for selecting access control list features for the UNIX system", Shipping list no.: 90-076-P, The Center, Fort George G. Meade, MD, 1990.2 Muftic, S., "Extended OSI Security Architecture: Second Stage of the CEC COST-11 TER Project", Computer Networks and ISDN Systems, vol. 17, No. 3, Pg. 233, 15 September 1989. Murray, W., "Computer viruses - is there a vaccine?", Financial executive, Vol. 5, No. 2, Pg. 39, 1 March 1989. Okamoto, E., and K. Tanaka, "Identity-Based Information Security Management System for Personal Computer Networks", IEEE Journal on Selected Areas in Communications, Vol. 7, No. 2, Pg. 290, 1 February 1989. Ozier, W., "Disaster Recovery and Risk Avoidance/Acceptance", Data processing & communications security, Vol. 14, No. 1, Page 11, Winter 1990. Palmer, I., and G. Potter, "Computer security risk management", 317 Pages, Van Nostrand Reinhold, New York, 1989. Site Security Policy Handbook WG [Page 53] RFC 11XX Security Policy Handbook MMMM 1990 Parker, D., "Computer crime : criminal justice resource manual", U.S. Dept. of Justice, National Institute of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, Washington, D.C., August 1989. Pfleeger, C., "Security in computing", Prentice-Hall, Englewood Cliffs, N.J., 1989. Review, "Taking a stand against computer viruses", Reivew, Vol. 33, No. 2, Pg. 46, 1989. Rishe, N., and M. Lipkind, "Modelling of virus interrelationships for computer analysis of inhibition data", Mathematical and computer modelling, Vol. 13, No. 1, Pg. 39, 1990. Rosenberger, R., "Computer Virus Myths", SIG security, audit & control review, Vol. 7, No. 4, Page 21, Winter 1990. Rosenblatt, K., "Deterring Computer Crime", Technology Reivew, Vol. 93, No. 2, Pg. 34, 1 February 1990. Rutgers computer & technology law journal, "Computer Viruses: Is There a Legal `Antibiotic?'", Rutgers computer & technology law journal, Vol. 16, No. 1, Pg. 253, 1990. Shirey, R., "Defense Data Network Security Architecture", Computer communication review, Vol. 20, No. 2, Page 66, 1 April 1990. Shoop, T., and D. Stang, "Beating Back a Virus Attack", Government Executive, Vol. 22, No. 4, Pg. 40, 1 April 1990. Spafford, G., "An Analysis of the Internet Worm", Proceedings of the European Software Engineering Confernce 1989, Warwick England, September 1989. Proceedings published by Springer- Verlag as: Lecture Notes in Computer Science #387. Also issued as Purdue Technical Report #CSD-TR-933. Spafford, E., Heaphy, K., and D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism and Programmed Threats", ADAPSO, 1989. Stiller, W., "Protect Your Data with PCDATA, the Data Integrity Toolkit", PC magazine, Vol. 9, No. 3, Pg. 263, 13 February 1990. Tabbey, K., "Computer crime: "preparing the computer specific search warrant", Computers & security, Vol. 9, NO. 2, Page 117, Site Security Policy Handbook WG [Page 54] RFC 11XX Security Policy Handbook MMMM 1990 1 April 1990. Tester, D., "A Headache for the Host", Security management, Vol. 34, No. 1, Pg. 83, 1 January 1990. The Computer Lawyer, "Current Developments: Legislation", The Computer Lawyer, Vol. 6, No. 12, Pg. 50, 1 December 1990. United States. Congress. House. Committee on Science, Space, and Technology. Subcommittee on Transportation, Aviation, and Materials, "Implementation of the Computer Security Act : hearing before the Subcommittee on Transportation, Aviation, and Materials of the Committee on Science, Space, and Technology, House of Representatives, One Hundredth Congress, second session, September 22, 1988, Washington : U.S. G.P.O., 1989. United States. Congress. House. Committee on Government Operations. Legislation and National Security Subcommittee, "Military and civilian control of computer security issues" : hearing before the Legislation and National Security Subcommittee of the Committee on Government Operations, House of Representatives, One Hundred First Congress, first session, U.S. G.P.O., Washington, D.C., 4 May 1989. United States General Accounting Office, " Computer security : virus highlights need for improved Internet management : report to the chairman, Subcommittee on Telecommunications and Finance, Committee on Energy and Commerce, House of Representatives", GAO/IMTEC-89-57, Washington, D.C., 1989. United States General Accounting Office, "Computer security : unauthorized access to a NASA scientific network", GAO/IMTEC- 90-2, Washington, D.C., 1989. Utter, A., "The Four Essentials of Computer and Information Security", The Internet Auditor, Vol. 46, No. 6, Pg. 44, 1 December 1989. Vaiciulis, M., "Keeping the Contagion at Bay: The Proliferation of Computer Viruses has Computer Security Managers Scrambling for Relief", Security Management, Vol. 33, No. 12, Pg. 31, 1 December 1989. Vallabhaneni, S., "Auditing Computer Security: A Manual with Case Studies", Wiley, New York, NY, 1989. Von Solms, S., and N. Edwards, "Designing and implementation of Site Security Policy Handbook WG [Page 55] RFC 11XX Security Policy Handbook MMMM 1990 a New Security Model", International Journal of Computer Mathematics, Vol. 29, No. 2, Pg. 139, 1989. Wood, C., Banks, W., Guarro, S., Garcia, A., Hampel, V., H. Sartorio, "Computer Security: A Comprehensive Controls Checklist", John Wiley and Sons, Interscience Publication, 1987. Zajac Jr., B., "Computer viruses: Can they be prevented?", Computers & security, Vol. 9, No. 1, Pg. 25, 1 February 1990. References Curry, D., "Improving the Security of Your UNIX System", SRI International Report ITSTD-721-FR-90-21, April 1990. Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, DARPA, September 1981. Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. Mogul, J., "Simple and Flexible Datagram Access Controls for UNIX- based Gateways", Digital Western Research Laboratory Research Report 89/4, March 1989. Quarterman, John S., "The Matrix: Computer Networks and Conferencing Systems Worldwide", Digital Press, Bedford, MA, 1990. [Brand 90] Russell B., "Coping with the Threat of Computer Security Incidents - A Primer from Prevention through Recovery", Unpublished work available from the author. [Fites 90] Fites, M., Kratz, P. and A. Brebner, "Control and Security of Computer Information Systems", Computer Science Press, 1989. 10. Security Considerations If security considerations had not been so widely ignored in the Internet community, this memo would not have been possible. Co-Chairs' Addresses This proposal is the product of the Security Policy Handbook Working Site Security Policy Handbook WG [Page 56] RFC 11XX Security Policy Handbook MMMM 1990 Group (SPWG) Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the co-chairs: J. Paul Holbrook Computer Emergency Response Team Software Engineering Instutite Carnegie Mellon University 4500 Fifth Avenue Pittsburgh, PA 15213 Phone: (412) 268-7090 EMail: ph@CERT.SEI.CMU.EDU Joyce K. Reynolds University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (213) 822-1511 EMail: JKREY@ISI.EDU Authors' Addresses Frank Byrum EMail: byrum@decuac.dec.com Jeffrey J. Carpenter University of Pittsburgh Computing and Information Services 600 Epsilon Drive Pittsburgh, PA 15238 Phone: (412) 624-6424 EMail: jjc@unix.cis.pitt.edu David A. Curry SRI International 333 Ravenswood Avenue Menlo Park, CA 94025 Phone: (415) 859-2508 EMail: davy@ITSTD.SRI.COM Site Security Policy Handbook WG [Page 57] RFC 11XX Security Policy Handbook MMMM 1990 Jim Duncan EMail: jim@augusta.math.psu.edu Greg Hollingsworth The Johns Hopkins University Applied Physics Laboratory Phone: (301) 953-6065 EMail: gregh@janus.jhuapl.edu Sean Kirkpatrick Unisys Corporation Advanced Projects, Networks and Information Security Division 5151 Camino Ruiz, MS/C210 Camarillo, CA 93010 Phone: (805) 987-6811 ext 4519 EMail: sean@KRONOS.NISD.CAM.UNISYS.COM Allen Sturtevant EMail: sturtevant@CCC.NERSC.GOV Site Security Policy Handbook WG [Page 58]