RFCs in HTML Format

RFC 1244

Network Working Group                                        P. Holbrook
Request for Comments:  1244                                       CICNet
FYI: 8                                                       J. Reynolds
                                                               July 1991

                         Site Security Handbook

Editors' Note

   This FYI RFC is a first attempt at providing Internet users guidance
   on how to deal with security issues in the Internet.  As such, this
   document is necessarily incomplete.  There are some clear shortfalls;
   for example, this document focuses mostly on resources available in
   the United States.  In the spirit of the Internet's "Request for
   Comments" series of notes, we encourage feedback from users of this
   handbook.  In particular, those who utilize this document to craft
   their own policies and procedures.

   This handbook is meant to be a starting place for further research
   and should be viewed as a useful resource, but not the final
   authority.  Different organizations and jurisdictions will have
   different resources and rules.  Talk to your local organizations,
   consult an informed lawyer, or consult with local and national law
   enforcement.  These groups can help fill in the gaps that this
   document cannot hope to cover.

Site Security Policy Handbook Working Group                     [Page 1]

RFC 1244 Site Security Handbook July 1991 Finally, we intend for this FYI RFC to grow and evolve. Please send comments and suggestions to: ssphwg@cert.sei.cmu.edu. Table of Contents 1. Introduction..................................................... 3 1.1 Purpose of this Work............................................ 3 1.2 Audience........................................................ 3 1.3 Definitions..................................................... 4 1.4 Related Work.................................................... 4 1.5 Scope........................................................... 4 1.6 Why Do We Need Security Policies and Procedures?................ 5 1.7 Basic Approach.................................................. 7 1.8 Organization of this Document................................... 7 2. Establishing Official Site Policy on Computer Security........... 9 2.1 Brief Overview.................................................. 9 2.2 Risk Assessment................................................. 10 2.3 Policy Issues................................................... 13 2.4 What Happens When the Policy Is Violated........................ 19 2.5 Locking In or Out............................................... 21 2.6 Interpreting the Policy......................................... 23 2.7 Publicizing the Policy.......................................... 23 3. Establishing Procedures to Prevent Security Problems............. 24 3.1 Security Policy Defines What Needs to be Protected.............. 24 3.2 Identifing Possible Problems.................................... 24 3.3 Choose Controls to Protect Assets in a Cost-Effective Way....... 26 3.4 Use Multiple Strategies to Protect Assets....................... 26 3.5 Physical Security............................................... 27 3.6 Procedures to Recognize Unauthorized Activity................... 27 3.7 Define Actions to Take When Unauthorized Activity is Suspected.. 29 3.8 Communicating Security Policy................................... 30 3.9 Resources to Prevent Security Breaches.......................... 34 4. Types of Security Procedures..................................... 56 4.1 System Security Audits.......................................... 56 4.2 Account Management Procedures................................... 57 4.3 Password Management Procedures.................................. 57 4.4 Configuration Management Procedures............................. 60 5. Incident Handling................................................ 61 5.1 Overview........................................................ 61 5.2 Evaluation...................................................... 65 5.3 Possible Types of Notification.................................. 67 5.4 Response........................................................ 71 5.5 Legal/Investigative............................................. 73 5.6 Documentation Logs.............................................. 77 6. Establishing Post-Incident Procedures............................ 78 6.1 Overview........................................................ 78 6.2 Removing Vulnerabilities........................................ 78 6.3 Capturing Lessons Learned....................................... 80 Site Security Policy Handbook Working Group [Page 2]
RFC 1244 Site Security Handbook July 1991 6.4 Upgrading Policies and Procedures............................... 81 7. References....................................................... 81 8. Annotated Bibliography........................................... 83 8.1 Computer Law.................................................... 84 8.2 Computer Security............................................... 85 8.3 Ethics.......................................................... 91 8.4 The Internet Worm............................................... 93 8.5 National Computer Security Center (NCSC)........................ 95 8.6 Security Checklists............................................. 99 8.7 Additional Publications......................................... 99 9. Acknlowledgements................................................101 10. Security Considerations.........................................101 11. Authors' Addresses..............................................101 1. Introduction 1.1 Purpose of this Work 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. 1.2 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 members of the Internet community. However, this document should be useful to any site that allows communication with other sites. As a general guide to security policies, this document may also be useful to sites with isolated systems. Site Security Policy Handbook Working Group [Page 3]
RFC 1244 Site Security Handbook July 1991 1.3 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's 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 [1]. 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. 1.4 Related Work The IETF Security Policy Working Group (SPWG) is working on a set of recommended security policy guidelines for the Internet [23]. These guidelines may be adopted as policy 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. 1.5 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. When developing a security policy, close attention should be made not only on the security needs and requirements of the local network, but also the security needs and requirements of the other interconnected networks. Site Security Policy Handbook Working Group [Page 4]
RFC 1244 Site Security Handbook July 1991 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 conform to the needs and culture of the site. This handbook 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. 1.6 Why Do We Need Security Policies and Procedures? For most sites, the interest in computer security is proportional to the perception of risk and threats. The world of computers has changed dramatically over the past twenty-five years. Twenty-five 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, and accounting for all resources. Computing in the 1990's 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 the thief who looks for open windows and doors; now a person can check hundreds of machines for vulnerabilities in a few hours. System administrators and decision makers have to understand the security threats that exist, what the risk and cost of a problem Site Security Policy Handbook Working Group [Page 5]
RFC 1244 Site Security Handbook July 1991 would be, and what kind of action they want to take (if any) to prevent and respond to security threats. As an illustration of some of the issues that need to be dealt with in security problems, consider the following scenarios (thanks to Russell Brand [2, BRAND] 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 o'clock 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 transfers 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 a breakin to a government lab occurred from one of your center's machines. You are requested to provide accounting files to help trackdown 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 Working Group [Page 6]
RFC 1244 Site Security Handbook July 1991 - 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 on your system, should you leave the system open to monitor the situation or should you close down the holes and open them 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? 1.7 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. [3, FITES]: - 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. 1.8 Organization of this Document This document is organized into seven parts in addition to this introduction. 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 Site Security Policy Handbook Working Group [Page 7]
RFC 1244 Site Security Handbook July 1991 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. Nonetheless, 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 2 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. Once policies are in place, procedures to prevent future security problems should be established. Section 3 defines and suggests actions to take when unauthorized activity is suspected. Resources to prevent secruity breaches are also discussed. Section 4 discusses types of 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 (CMU) estimates that 80% or more of the problems they see have to do with poorly chosen passwords. Section 5 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 2. Section 6 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 references and an annotated bibliography. Site Security Policy Handbook Working Group [Page 8]
RFC 1244 Site Security Handbook July 1991 2. Establishing Official Site Policy on Computer Security 2.1 Brief Overview 2.1.1 Organization Issues 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 respond to security incidents. In order to do this, aspects of the particular organization must be considered. First, the goals and direction of the organization should be considered. For example, a military base may have very different security concerns from a those of a university. Second, the site security policy developed must conform to existing policies, rules, regulations and laws that the organization is subject to. Therefore it will be necessary to identify these and take them into consideration while developing the policy. Third, unless the local network is completely isolated and standalone, it is necessary to consider security implications in a more global context. The policy should address the issues when local security problems develop as a result of a remote site as well as when problems occur on remote systems as a result of a local host or user. 2.1.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 decision makers who have the power to enforce the policy. A policy which is neither implementable nor enforceable is useless. Since a computer security policy can affect everyone in an organization, it is worth taking some care to make sure you have the right level of authority in on the policy decisions. Though a particular group (such as a campus information services group) may have responsibility for enforcing a policy, an even higher group may have to support and approve the policy. 2.1.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 Site Security Policy Handbook Working Group [Page 9]
RFC 1244 Site Security Handbook July 1991 may be responsible for personal password administration. Systems managers are obligated to fix security holes and to oversee the system. It is critical to get the right set of people involved at the start of the process. There may already be groups concerned with security who would consider a computer security policy to be their area. Some of the types of groups that might be involved include auditing/control, organizations that deal with physical security, campus information systems groups, and so forth. Asking these types of groups to "buy in" from the start can help facilitate the acceptance of the policy. 2.1.4 Responsibilities A key element of a computer security policy is making sure everyone knows their own responsibility for maintaining security. A computer security policy cannot anticipate all possibilities; however, it can ensure that each kind of problem does have someone assigned to deal with it. 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. 2.2 Risk Assessment 2.2.1 General Discussion One of the most important reasons for creating a computer security policy is to ensure that efforts spent on security yield cost effective benefits. Although this may seem obvious, it is possible to be mislead about where the effort is needed. As an example, there is a great deal of publicity about intruders on computers systems; yet most surveys of computer security show that for most organizations, the actual loss from "insiders" is much greater. Risk analysis involves determining what you need to protect, what you need to protect it from, and how to protect it. Is is the process of examining all of your risks, and ranking those risks by level of severity. This process involves making cost-effective Site Security Policy Handbook Working Group [Page 10]
RFC 1244 Site Security Handbook July 1991 decisions on what you want to protect. The old security adage says that you should not spend more to protect something than it is actually worth. A full treatment of risk analysis is outside the scope of this document. [3, FITES] and [16, PFLEEGER] provide introductions to this topic. However, there are two elements of a risk analysis that will be briefly covered in the next two sections: 1. Identifying the assets 2. Identifying the threats For each asset, the basic goals of security are availability, confidentiality, and integrity. Each threat should be examined with an eye to how the threat could affect these areas. 2.2.2 Identifying the Assets One step in a risk analysis is to identify all the things that need to be protected. Some things are obvious, like all the various pieces of hardware, but some are overlooked, such as the people who actually use the systems. The essential point is to list all things that could be affected by a security problem. One list of categories is suggested by Pfleeger [16, PFLEEGER, page 459]; this list is adapted from that source: 1. Hardware: cpus, boards, keyboards, terminals, workstations, personal computers, printers, disk drives, communication lines, terminal servers, routers. 2. Software: source programs, object programs, utilities, diagnostic programs, operating systems, communication programs. 3. Data: during execution, stored on-line, archived off-line, backups, audit logs, databases, in transit over communication media. 4. People: users, people needed to run systems. 5. Documentation: on programs, hardware, systems, local administrative procedures. 6. Supplies: paper, forms, ribbons, magnetic media. Site Security Policy Handbook Working Group [Page 11]
RFC 1244 Site Security Handbook July 1991 2.2.3 Identifying the Threats Once the assets requiring protection are identified, it is necessary to identify threats to those assests. The threats can then be examined to determine what potential for loss exists. It helps to consider from what threats you are trying to protect your assets. The following sections describe a few of the possible threats. Unauthorized Access A common threat that concerns many sites is unauthorized access to computing facilities. Unauthorized access takes many forms. One 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. In addition, some sites may be more frequent targets than others; hence the risk from unauthorized access will vary from site to site. The Computer Emergency Response Team (CERT - see section has observed that well-known universities, government sites, and military sites seem to attract more intruders. 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 advantage. A technical paper may contain years of valuable research. 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 affect users in a number of ways. A network may be rendered unusable by a Site Security Policy Handbook Working Group [Page 12]
RFC 1244 Site Security Handbook July 1991 rogue packet, jamming, or by a disabled network component. A virus might slow down or cripple a computer system. Each site should determine which services are essential, and for each of these services determine the affect to the site if that service were to become disabled. 2.3 Policy Issues There are a number of issues that must be addressed when developing a security policy. These are: 1. Who is allowed to use the resources? 2. What is the proper use of the resources? 3. Who is authorized to grant access and approve usage? 4. Who may have system administration privileges? 5. What are the user's rights and responsibilities? 6. What are the rights and responsibilities of the system administrator vs. those of the user? 7. What do you do with sensitive information? These issues will be discussed below. In addition you may wish to include a section in your policy concerning ethical use of computing resources. Parker, Swope and Baker [17, PARKER90] and Forester and Morrison [18, FORESTER] are two useful references that address ethical issues. 2.3.1 Who is Allowed to use the Resources? One step you must take in developing your security policy is defining who is allowed to use your system and services. The policy should explicitly state who is authorized to use what resources. 2.3.2 What is the Proper Use of the Resources? After determining who is allowed access to system resources it is necessary to provide guidelines for the acceptable use of the resources. You may have different guidelines for different types of users (i.e., students, faculty, external users). The policy should state what is acceptable use as well as unacceptable use. It should also include types of use that may be restricted. 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. Your acceptable use policy should clearly state that individual users are responsible for their actions. Their responsibility Site Security Policy Handbook Working Group [Page 13]
RFC 1244 Site Security Handbook July 1991 exists regardless of the security mechanisms that are in place. It should be clearly stated that breaking into accounts or bypassing security is not permitted. The following points should be covered when developing an acceptable use policy: o Is breaking into accounts permitted? o Is cracking passwords permitted? o Is disrupting service permitted? o Should users assume that a file being world-readable grants them the authorization to read it? o Should users be permitted to modify files that are not their own even if they happen to have write permission? o Should users share accounts? The answer to most of these questions will be "no". 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 you may do so. o Methods of conveying information on the copyright/licensed status of software. o When in doubt, DON'T COPY. Your acceptable use policy is very important. A policy which does not clearly state what is not permitted may leave you unable to prove that a user violated policy. There are exception cases like tiger teams and users or administrators wishing for "licenses 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 area: Site Security Policy Handbook Working Group [Page 14]
RFC 1244 Site Security Handbook July 1991 o Whether it is permitted at all. o What type of activity is permitted: breaking in, releasing worms, releasing viruses, etc.. o What type of controls must be in place to ensure that it does not get out of control (e.g., separate a segment of your network for these tests). o How you will protect other users from being victims of these activities, including external users and networks. o The process for obtaining permission to conduct these tests. In cases where you do permit these activities, you should isolate the portions of the network that are being tested from your main network. Worms and viruses should never be released on a live network. You may also wish to employ, contract, or otherwise solicit one or more people or organizations to evaluate the security of your services, of which may include "hacking". You may wish to provide for this in your policy. 2.3.3 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. If you do not have control over who is granted access to your system, you will not have control over who is using your system. Controlling who has the authorization to grant access will also enable you to know who was or was not granting access if problems develop later. 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: o Will you be distributing access from a centralized point or at various points? You can have a centralized distribution point to a distributed system where various sites or departments independently authorize access. The trade off is between security and convenience. The more centralized, the easier to secure. o What methods will you use for creating accounts and terminating access? From a security standpoint, you need to examine the mechanism that Site Security Policy Handbook Working Group [Page 15]
RFC 1244 Site Security Handbook July 1991 you will be using to create accounts. In the least restrictive case, the people 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. You should have specific procedures developed for the creation of accounts. These procedures should be well documented to prevent confusion and reduce mistakes. A security vulnerability in the account authorization process is not only possible through abuse, but is also possible if a mistake is made. Having clear and well documented procedure will help ensure that these mistakes won't happen. You should also be sure that the people who will be following these procedures understand them. The granting of access to users is one of the most vulnerable of times. You should ensure that the selection of an initial password cannot be easily guessed. You should avoid using an initial password that is a function of the username, is part of the user's name, or some algorithmically generated password that can easily be guessed. In addition, you should not permit users to continue to use the initial password indefinitely. If possible, you should force users to change the initial password the first time they login. Consider that some users may never even login, leaving their password vulnerable indefinitely. Some sites choose to disable accounts that have never been accessed, and force the owner to reauthorize opening the account. 2.3.4 Who May Have System Administration Privileges? One security decision that needs to be made very carefully is who will have access to system administrator privileges and passwords for your services. Obviously, the system administrators will need access, but inevitably other users will request special privileges. The policy should address this issue. Restricting privileges is one way to deal with threats from local users. The challenge is to balance restricting access to these to protect security with giving people who need these privileges access so that they can perform their tasks. One approach that can be taken is to grant only enough privilege to accomplish the necessary tasks. Site Security Policy Handbook Working Group [Page 16]
RFC 1244 Site Security Handbook July 1991 Additionally, people holding special privileges should be accountable to some authority and this should also be identified within the site's security policy. If the people you grant privileges to are not accountable, you run the risk of losing control of your system and will have difficulty managing a compromise in security. 2.3.5 What Are The Users' Rights and Responsibilities? The policy should incorporate a statement on the users' rights and responsibilities concerning the use of the site's computer systems and services. It should be clearly stated that users are responsible for understanding and respecting the security rules of the systems they are using. The following is a list of topics that you may wish to cover in this area of the policy: o What guidelines you have regarding resource consumption (whether users are restricted, and if so, what the restrictions are). 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 or requirements. o Whether you provide backups or expect the users to create their own. o Disclosure of information that may be proprietary. o Statement on Electronic Mail Privacy (Electronic Communications Privacy Act). o Your policy concerning controversial mail or postings to mailing lists or discussion groups (obscenity, harassment, etc.). o Policy on electronic communications: mail forging, etc. The Electronic Mail Association sponsored a white paper on the privacy of electronic mail in companies [4]. Their basic recommendation is that every site should have a policy on the protection of employee privacy. They also recommend that organizations establish privacy policies that deal with all media, rather than singling out electronic mail. They suggest five criteria for evaluating any policy: 1. Does the policy comply with law and with duties to third parties? 2. Does the policy unnecessarily compromise the interest of Site Security Policy Handbook Working Group [Page 17]
RFC 1244 Site Security Handbook July 1991 the employee, the employer or third parties? 3. Is the policy workable as a practical matter and likely to be enforced? 4. Does the policy deal appropriately with all different forms of communications and record keeping with the office? 5. Has the policy been announced in advance and agreed to by all concerned? 2.3.6 What Are The Rights and Responsibilities of System Administrators Versus Rights of Users 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 administrator's need to gather information to diagnose problems and investigating security violations. The policy should specify 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' obligation to maintaining the privacy of information viewed under these circumstances. A few questions that should be answered are: o Can an administrator monitor or read a user's files for any reason? o What are the liabilities? o Do network administrators have the right to examine network or host traffic? 2.3.7 What To Do With Sensitive Information Before granting users access to your services, you need to determine at what level you will provide for the security of data on your systems. 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, magnetic tape, file servers, etc.). Your policy in this area needs to be coordinated with the policy concerning the rights of system administrators versus users (see section 2.3.6). Site Security Policy Handbook Working Group [Page 18]
RFC 1244 Site Security Handbook July 1991 2.4 What Happens When the Policy is Violated It is obvious that when any type of official policy is defined, be it related to computer security or not, it will eventually be broken. The violation may occur due to an individual's negligence, accidental mistake, having not been properly informed of the current policy, or not understanding the current policy. It is equally possible that an individual (or group of individuals) may knowingly perform an act that is in direct violation of the defined policy. When a policy violation has been detected, the immediate course of action should be pre-defined to ensure prompt and proper enforcement. An investigation should be performed to determine how and why the violation occurred. Then the appropriate corrective action should be executed. The type and severity of action taken varies depending on the type of violation that occurred. 2.4.1 Determining the Response to Policy Violations Violations to policy may be committed by a wide variety of users. Some may be local users and others may be from outside the local environment. Sites may find it helpful to define what it considers "insiders" and "outsiders" based upon administrative, legal or political boundaries. These boundaries imply what type of action must be taken to correct the offending party; from a written reprimand to pressing legal charges. So, not only do you need to define actions based on the type of violation, you also need to have a clearly defined series of actions based on the kind of user violating your computer security policy. This all seems rather complicated, but should be addressed long before it becomes necessary as the result of a violation. One point to remember about your policy is that proper education is your best defense. For the outsiders who are using your computer legally, it is your responsibility to verify that these individuals are aware of the policies that you have set forth. Having this proof may assist you in the future if legal action becomes necessary. As for users who are using your computer illegally, the problem is basically the same. What type of user violated the policy and how and why did they do it? Depending on the results of your investigation, you may just prefer to "plug" the hole in your computer security and chalk it up to experience. Or if a significant amount of loss was incurred, you may wish to take more drastic action. Site Security Policy Handbook Working Group [Page 19]
RFC 1244 Site Security Handbook July 1991 2.4.2 What to do When Local Users Violate the Policy of a Remote Site In the event that a local user violates the security policy of a remote site, the local site should have a clearly defined set of administrative actions to take concerning that local user. The site should also be prepared to protect itself against possible actions by the remote site. These situations involve legal issues which should be addressed when forming the security policy. 2.4.3 Defining Contacts and Responsibilities to Outside Organizations The local security policy should include procedures for interaction with outside organizations. These include law enforcement agencies, other sites, external response team organizations (e.g., the CERT, CIAC) and various press agencies. The procedure should state who is authorized to make such contact and how it should be handled. Some questions to be answered include: o Who may talk to the press? o When do you contact law enforcement and investigative agencies? o If a connection is made from a remote site, is the system manager authorized to contact that site? o Can data be released? What kind? Detailed contact information should be readily available along with clearly defined procedures to follow. 2.4.4 What are the Responsibilities to our Neighbors and Other Internet Sites? The Security Policy Working Group within the IETF is working on a document entitled, "Policy Guidelines for the Secure Operation of the Internet" [23]. It addresses the issue that the Internet is a cooperative venture and that sites are expected to provide mutual security assistance. This should be addressed when developing a site's policy. The major issue to be determined is how much information should be released. This will vary from site to site according to the type of site (e.g., military, education, commercial) as well as the type of security violation that occurred. 2.4.5 Issues for Incident Handling Procedures Along with statements of policy, the document being prepared should include procedures for incident handling. This is covered Site Security Policy Handbook Working Group [Page 20]
RFC 1244 Site Security Handbook July 1991 in detail in the next chapter. There should be procedures available that cover all facets of policy violation. 2.5 Locking In or Out Whenever a site suffers an incident which may compromise computer security, the strategies for reacting may be influenced by two opposing pressures. If management fears that the site is sufficiently vulnerable, it may choose a "Protect and Proceed" strategy. This approach will have as its primary goal the protection and preservation of the site facilities and to provide for normalcy for its users as quickly as possible. Attempts will be made to actively interfere with the intruder's processes, prevent further access and begin immediate damage assessment and recovery. This process may involve shutting down the facilities, closing off access to the network, or other drastic measures. The drawback is that unless the intruder is identified directly, they may come back into the site via a different path, or may attack another site. The alternate approach, "Pursue and Prosecute", adopts the opposite philosophy and goals. The primary goal is to allow intruders to continue their activities at the site until the site can identify the responsible persons. This approach is endorsed by law enforcement agencies and prosecutors. The drawback is that the agencies cannot exempt a site from possible user lawsuits if damage is done to their systems and data. Prosecution is not the only outcome possible if the intruder is identified. If the culprit is an employee or a student, the organization may choose to take disciplinary actions. The computer security policy needs to spell out the choices and how they will be selected if an intruder is caught. Careful consideration must be made by site management regarding their approach to this issue before the problem occurs. The strategy adopted might depend upon each circumstance. Or there may be a global policy which mandates one approach in all circumstances. The pros and cons must be examined thoroughly and the users of the facilities must be made aware of the policy so that they understand their vulnerabilities no matter which approach is taken. The following are checklists to help a site determine which strategy to adopt: "Protect and Proceed" or "Pursue and Prosecute". Site Security Policy Handbook Working Group [Page 21]
RFC 1244 Site Security Handbook July 1991 Protect and Proceed 1. If assets are not well protected. 2. If continued penetration could result in great financial risk. 3. If the possibility or willingness to prosecute is not present. 4. If user base is unknown. 5. If users are unsophisticated and their work is vulnerable. 6. If the site is vulnerable to lawsuits from users, e.g., if their resources are undermined. Pursue and Prosecute 1. If assets and systems are well protected. 2. If good backups are available. 3. If the risk to the assets is outweighed by the disruption caused by the present and possibly future penetrations. 4. If this is a concentrated attack occurring with great frequency and intensity. 5. If the site has a natural attraction to intruders, and consequently regularly attracts intruders. 6. If the site is willing to incur the financial (or other) risk to assets by allowing the penetrator continue. 7. If intruder access can be controlled. 8. If the monitoring tools are sufficiently well-developed to make the pursuit worthwhile. 9. If the support staff is sufficiently clever and knowledgable about the operating system, related utilities, and systems to make the pursuit worthwhile. 10. If there is willingness on the part of management to prosecute. Site Security Policy Handbook Working Group [Page 22]
RFC 1244 Site Security Handbook July 1991 11. If the system adminitrators know in general what kind of evidence would lead to prosecution. 12. If there is established contact with knowledgeable law enforcement. 13. If there is a site representative versed in the relevant legal issues. 14. If the site is prepared for possible legal action from its own users if their data or systems become compromised during the pursuit. 2.6 Interpreting the Policy It is important to define who will interpret the policy. This could be an individual or a committee. No matter how well written, the policy will require interpretation from time to time and this body would serve to review, interpret, and revise the policy as needed. 2.7 Publicizing the Policy Once the site security policy has been written and established, a vigorous process should be engaged to ensure that the policy statement is widely and thoroughly disseminated and discussed. A mailing of the policy should not be considered sufficient. A period for comments should be allowed before the policy becomes effective to ensure that all affected users have a chance to state their reactions and discuss any unforeseen ramifications. Ideally, the policy should strike a balance between protection and productivity. Meetings should be held to elicit these comments, and also to ensure that the policy is correctly understood. (Policy promulgators are not necessarily noted for their skill with the language.) These meetings should involve higher management as well as line employees. Security is a collective effort. In addition to the initial efforts to publicize the policy, it is essential for the site to maintain a continual awareness of its computer security policy. Current users may need periodic reminders New users should have the policy included as part of their site introduction packet. As a condition for using the site facilities, it may be advisable to have them sign a statement that they have read and understood the policy. Should any of these users require legal action for serious policy violations, this signed statement might prove to be a valuable aid. Site Security Policy Handbook Working Group [Page 23]
RFC 1244 Site Security Handbook July 1991 3. Establishing Procedures to Prevent Security Problems The security policy defines what needs to be protected. This section discusses security procedures which specify what steps will be used to carry out the security policy. 3.1 Security Policy Defines What Needs to be Protected The security policy defines the WHAT's: what needs to be protected, what is most important, what the priorities are, and what the general approach to dealing with security problems should be. The security policy by itself doesn't say HOW things are protected. That is the role of security procedures, which this section discusses. The security policy should be a high level document, giving general strategy. The security procedures need to set out, in detail, the precise steps your site will take to protect itself. The security policy should include a general risk assessment of the types of threats a site is mostly likely to face and the consequences of those threats (see section 2.2). Part of doing a risk assessment will include creating a general list of assets that should be protected (section 2.2.2). This information is critical in devising cost-effective procedures. It is often tempting to start creating security procedures by deciding on different mechanisms first: "our site should have logging on all hosts, call-back modems, and smart cards for all users." This approach could lead to some areas that have too much protection for the risk they face, and other areas that aren't protected enough. Starting with the security policy and the risks it outlines should ensure that the procedures provide the right level of protect for all assets. 3.2 Identifing Possible Problems To determine risk, vulnerabilities must be identified. Part of the purpose of the policy is to aid in shoring up the vulnerabilities and thus to decrease the risk in as many areas as possible. Several of the more popular problem areas are presented in sections below. This list is by no means complete. In addition, each site is likely to have a few unique vulnerabilities. 3.2.1 Access Points Access points are typically used for entry by unauthorized users. Having many access points increases the risk of access to an organization's computer and network facilities. Site Security Policy Handbook Working Group [Page 24]
RFC 1244 Site Security Handbook July 1991 Network links to networks outside the organization allow access into the organization for all others connected to that external network. A network link typically provides access to a large number of network services, and each service has a potential to be compromised. Dialup lines, depending on their configuration, may provide access merely to a login port of a single system. If connected to a terminal server, the dialup line may give access to the entire network. Terminal servers themselves can be a source of problem. Many terminal servers do not require any kind of authentication. Intruders often use terminal servers to disguise their actions, dialing in on a local phone and then using the terminal server to go out to the local network. Some terminal servers are configured so that intruders can TELNET [19] in from outside the network, and then TELNET back out again, again serving to make it difficult to trace them. 3.2.2 Misconfigured Systems Misconfigured systems form a large percentage of security holes. Today's operating systems and their associated software have become so complex that understanding how the system works has become a full-time job. Often, systems managers will be non- specialists chosen from the current organization's staff. Vendors are also partly responsible for misconfigured systems. To make the system installation process easier, vendors occasionally choose initial configurations that are not secure in all environments. 3.2.3 Software Bugs Software will never be bug free. Publicly known security bugs are common methods of unauthorized entry. Part of the solution to this problem is to be aware of the security problems and to update the software when problems are detected. When bugs are found, they should be reported to the vendor so that a solution to the problem can be implemented and distributed. 3.2.4 "Insider" Threats An insider to the organization may be a considerable threat to the security of the computer systems. Insiders often have direct access to the computer and network hardware components. The ability to access the components of a system makes most systems Site Security Policy Handbook Working Group [Page 25]
RFC 1244 Site Security Handbook July 1991
RFC 1244 Site Security Handbook July 1991 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 (WSMR), New Mexico. The directory "pd2:<unix-c>" contains a large amount of UNIX software, primarily taken from the "comp.sources" newsgroups. The directories "pd1:<msdos>" and "pd2:<msdos2>" contains software for IBM PC systems, and "pd3:<macintosh>" 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 system. Vendors 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 Corporation (DEC), the University of California at Berkeley (see above), and Apple Computer [5, CURRY]. Site Security Policy Handbook Working Group [Page 55]
RFC 1244 Site Security Handbook July 1991 4. Types of Security Procedures 4.1 System Security Audits 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. 4.1.1 Organize Scheduled Drills Although not something that would be done each day or week, scheduled drills may 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 would be conducted to verify your backup and recovery mechanisms. On the other hand, if your greatest threat is from external intruders attempting to penetrate your system, a drill might be conducted to actually try a penetration to observe the effect of the policies. Drills are a valuable way to test that your policies and procedures are effective. On the other hand, drills can be time- consuming and disruptive to normal operations. It is important to weigh the benefits of the drills against the possible time loss which may be associated with them. 4.1.2 Test Procedures If the choice is made to not to use scheduled drills to examine your entire security procedure at one time, it is important to test individual procedures frequently. Examine your backup procedure to make sure you can recover data from the tapes. Check log files to be sure that information which is supposed to be logged to them is being logged to them, etc.. When a security audit is mandated, great care should be used in devising tests of the security policy. It is important to clearly identify what is being tested, how the test will be conducted, and results expected from the test. This should all be documented and included in or as an adjunct to the security policy document itself. It is important to test all aspects of the security policy, both procedural and automated, with a particular emphasis on the automated mechanisms used to enforce the policy. Tests should be defined to ensure a comprehensive examination of policy features, Site Security Policy Handbook Working Group [Page 56]
RFC 1244 Site Security Handbook July 1991
RFC 1244 Site Security Handbook July 1991 security problems and solutions, with a particular emphasis on encryption. The encryption coverage serves as a good introduction to the subject. Other topics covered include building secure programs and systems, security of database, personal computer security, network and communications security, physical security, risk analysis and security planning, and legal and ethical issues. 538 pages including index and bibliography. [SHIREY] Shirey, R., "Defense Data Network Security Architecture", Computer Communication Review, Vol. 20, No. 2, Page 66, 1 April 1990. [SPAFFORD] Spafford, E., Heaphy, K., and D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism and Programmed Threats", ADAPSO, 1989. (109 pages.) This is a good general reference on computer viruses and related concerns. In addition to describing viruses in some detail, it also covers more general security issues, legal recourse in case of security problems, and includes lists of laws, journals focused on computers security, and other security-related resources. Available from: ADAPSO, 1300 N. 17th St, Suite 300, Arlington VA 22209. (703) 522-5055. [STOLL88] Stoll, C., "Stalking the Wily Hacker", Communications of the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988. This article describes some of the technical means used to trace the intruder that was later chronicled in "Cuckoo's Egg" (see below). [STOLL89] Stoll, C., "The Cuckoo's Egg", ISBN 00385-24946-2, Doubleday, 1989. Clifford Stoll, an astronomer turned UNIX System Administrator, recounts an exciting, true story of how he tracked a computer intruder through the maze of American military and research networks. This book is easy to understand and can serve as an interesting introduction to the world of networking. Jon Postel says in a book review, Site Security Policy Handbook Working Group [Page 90]
RFC 1244 Site Security Handbook July 1991 "[this book] ... is absolutely essential reading for anyon that uses or operates any computer connected to the Internet or any other computer network." [VALLA] Vallabhaneni, S., "Auditing Computer Security: A Manual with Case Studies", Wiley, New York, NY, 1989. 8.3 Ethics [CPSR89] Computer Professionals for Social Responsibility, "CPSR Statement on the Computer Virus", CPSR, Communications of the ACM, Vol. 32, No. 6, Pg. 699, June 1989. This memo is a statement on the Internet Computer Virus by the Computer Professionals for Social Responsibility (CPSR). [DENNING] Denning, Peter J., Editor, "Computers Under Attack: Intruders, Worms, and Viruses", ACM Press, 1990. A collection of 40 pieces divided into six sections: the emergence of worldwide computer networks, electronic breakins, worms, viruses, counterculture (articles examining the world of the "hacker"), and finally a section discussing social, legal, and ethical considerations. A thoughtful collection that addresses the phenomenon of attacks on computers. This includes a number of previously published articles and some new ones. The previously published ones are well chosen, and include some references that might be otherwise hard to obtain. This book is a key reference to computer security threats that have generated much of the concern over computer security in recent years. [ERMANN] Ermann, D., Williams, M., and C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford University Press, NY, 1990. (376 pages, includes bibliographical references). [FORESTER] Forester, T., and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990. (192 pages including index.) Site Security Policy Handbook Working Group [Page 91]
RFC 1244 Site Security Handbook July 1991 From the preface: "The aim of this book is two-fold: (1) to describe some of the problems created by society by computers, and (2) to show how these problems present ethical dilemmas for computers professionals and computer users. The problems created by computers arise, in turn, from two main sources: from hardware and software malfunctions and from misuse by human beings. We argue that computer systems by their very nature are insecure, unreliable, and unpredictable -- and that society has yet to come to terms with the consequences. We also seek to show how society has become newly vulnerable to human misuse of computers in the form of computer crime, software theft, hacking, the creation of viruses, invasions of privacy, and so on." The eight chapters include "Computer Crime", "Software Theft", "Hacking and Viruses", "Unreliable Computers", "The Invasion of Privacy", "AI and Expert Systems", and "Computerizing the Workplace." Includes extensive notes on sources and an index. [GOULD] Gould, C., Editor, "The Information Web: Ethical and Social Implications of Computer Networking", Westview Press, Boulder, CO, 1989. [IAB89] 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. This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet. Available on-line on host ftp.nisc.sri.com, directory rfc, filename rfc1087.txt. Also available on host nis.nsf.net, directory RFC, filename RFC1087.TXT-1. [MARTIN] Martin, M., and R. Schinzinger, "Ethics in Engineering", McGraw Hill, 2nd Edition, 1989. [MIT89] 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. Site Security Policy Handbook Working Group [Page 92]
RFC 1244 Site Security Handbook July 1991 This memo is a statement of policy by the Massachusetts Institute of Technology (MIT) on the responsible use of computers. [NIST] National Institute of Standards and Technology, "Computer Viruses and Related Threats: A Management Guide", NIST Special Publication 500-166, August 1989. [NSF88] 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. This memo is a statement of policy by the National Science Foundation (NSF) concerning the ethical use of the Internet. [PARKER90] Parker, D., Swope, S., and B. Baker, "Ethical Conflicts: Information and Computer Science, Technology and Business", QED Information Sciences, Inc., Wellesley, MA. (245 pages). Additional publications on Ethics: The University of New Mexico (UNM) The UNM has a collection of ethics documents. Included are legislation from several states and policies from many institutions. Access is via FTP, IP address ariel.umn.edu. Look in the directory /ethics. 8.4 The Internet Worm [BROCK] Brock, J., "November 1988 Internet Computer Virus and the Vulnerability of National Telecommunications Networks to Computer Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989. Testimonial statement of Jack L. Brock, Director, U. S. Government Information before the Subcommittee on Telecommunications and Finance, Committee on Energy and Site Security Policy Handbook Working Group [Page 93]
RFC 1244 Site Security Handbook July 1991 Commerce, House of Representatives. [EICHIN89] Eichin, M., and J. Rochlis, "With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988", Massachusetts Institute of Technology, February 1989. Provides a detailed dissection of the worm program. The paper discusses the major points of the worm program then reviews strategies, chronology, lessons and open issues, Acknowledgments; also included are a detailed appendix on the worm program subroutine by subroutine, an appendix on the cast of characters, and a reference section. [EISENBERG89] Eisenberg, T., D. Gries, J. Hartmanis, D. Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell University, 6 February 1989. A Cornell University Report presented to the Provost of the University on 6 February 1989 on the Internet Worm. [GAO] U.S. General Accounting Office, "Computer Security - Virus Highlights Need for Improved Internet Management", United States General Accounting Office, Washington, DC, 1989. This 36 page report (GAO/IMTEC-89-57), by the U.S. Government Accounting Office, describes the Internet worm and its effects. It gives a good overview of the various U.S. agencies involved in the Internet today and their concerns vis-a-vis computer security and networking. Available on-line on host nnsc.nsf.net, directory pub, filename GAO_RPT; and on nis.nsf.net, directory nsfnet, filename GAO_RPT.TXT. [REYNOLDS89] The Helminthiasis of the Internet, RFC 1135, USC/Information Sciences Institute, Marina del Rey, CA, December 1989. This report looks back at the helminthiasis (infestation with, or disease caused by parasitic worms) of the Internet that was unleashed the evening of 2 November 1988. This document provides a glimpse at the infection,its festering, and cure. The impact of the worm on the Internet community, ethics statements, the role of the news media, Site Security Policy Handbook Working Group [Page 94]
RFC 1244 Site Security Handbook July 1991 crime in the computer world, and future prevention is discussed. A documentation review presents four publications that describe in detail this particular parasitic computer program. Reference and bibliography sections are also included. Available on-line on host ftp.nisc.sri.com directory rfc, filename rfc1135.txt. Also available on host nis.nsf.net, directory RFC, filename RFC1135.TXT-1. [SEELEY89] Seeley, D., "A Tour of the Worm", Proceedings of 1989 Winter USENIX Conference, Usenix Association, San Diego, CA, February 1989. Details are presented as a "walk thru" of this particular worm program. The paper opened with an abstract, introduction, detailed chronology of events upon the discovery of the worm, an overview, the internals of the worm, personal opinions, and conclusion. [SPAFFORD88] 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. Describes the infection of the Internet as a worm program that exploited flaws in utility programs in UNIX based systems. The report gives a detailed description of the components of the worm program: data and functions. Spafford focuses his study on two completely independent reverse-compilations of the worm and a version disassembled to VAX assembly language. [SPAFFORD89] Spafford, G., "An Analysis of the Internet Worm", Proceedings of the European Software Engineering Conference 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. 8.5 National Computer Security Center (NCSC) All NCSC publications, approved for public release, are available from the NCSC Superintendent of Documents. NCSC = National Computer Security Center Site Security Policy Handbook Working Group [Page 95]
RFC 1244 Site Security Handbook July 1991 9800 Savage Road Ft Meade, MD 20755-6000 CSC = Computer Security Center: an older name for the NCSC NTISS = National Telecommunications and Information Systems Security NTISS Committee, National Security Agency Ft Meade, MD 20755-6000 [CSC] Department of Defense, "Password Management Guideline", CSC-STD-002-85, 12 April 1985, 31 pages. The security provided by a password system depends on the passwords being kept secret at all times. Thus, a password is vulnerable to compromise whenever it is used, stored, or even known. In a password-based authentication mechanism implemented on an ADP system, passwords are vulnerable to compromise due to five essential aspects of the password system: 1) a password must be initially assigned to a user when enrolled on the ADP system; 2) a user's password must be changed periodically; 3) the ADP system must maintain a 'password database'; 4) users must remember their passwords; and 5) users must enter their passwords into the ADP system at authentication time. This guideline prescribes steps to be taken to minimize the vulnerability of passwords in each of these circumstances. [NCSC1] NCSC, "A Guide to Understanding AUDIT in Trusted Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages. Audit trails are used to detect and deter penetration of a computer system and to reveal usage that identifies misuse. At the discretion of the auditor, audit trails may be limited to specific events or may encompass all of the activities on a system. Although not required by the criteria, it should be possible for the target of the audit mechanism to be either a subject or an object. That is to say, the audit mechanism should be capable of monitoring every time John accessed the system as well as every time the nuclear reactor file was accessed; and likewise every time John accessed the nuclear reactor file. Site Security Policy Handbook Working Group [Page 96]
RFC 1244 Site Security Handbook July 1991 [NCSC2] NCSC, "A Guide to Understanding DISCRETIONARY ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30 September 1987, 29 pages. Discretionary control is the most common type of access control mechanism implemented in computer systems today. The basis of this kind of security is that an individual user, or program operating on the user's behalf, is allowed to specify explicitly the types of access other users (or programs executing on their behalf) may have to information under the user's control. [...] Discretionary controls are not a replacement for mandatory controls. In any environment in which information is protected, discretionary security provides for a finer granularity of control within the overall constraints of the mandatory policy. [NCSC3] NCSC, "A Guide to Understanding CONFIGURATION MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March 1988, 31 pages. Configuration management consists of four separate tasks: identification, control, status accounting, and auditing. For every change that is made to an automated data processing (ADP) system, the design and requirements of the changed version of the system should be identified. The control task of configuration management is performed by subjecting every change to documentation, hardware, and software/firmware to review and approval by an authorized authority. Configuration status accounting is responsible for recording and reporting on the configuration of the product throughout the change. Finally, though the process of a configuration audit, the completed change can be verified to be functionally correct, and for trusted systems, consistent with the security policy of the system. [NTISS] NTISS, "Advisory Memorandum on Office Automation Security Guideline", NTISSAM CONPUSEC/1-87, 16 January 1987, 58 pages. This document provides guidance to users, managers, security officers, and procurement officers of Office Automation Systems. Areas addressed include: physical security, personnel security, procedural security, hardware/software security, emanations security (TEMPEST), and communications Site Security Policy Handbook Working Group [Page 97]
RFC 1244 Site Security Handbook July 1991 security for stand-alone OA Systems, OA Systems used as terminals connected to mainframe computer systems, and OA Systems used as hosts in a Local Area Network (LAN). Differentiation is made between those Office Automation Systems equipped with removable storage media only (e.g., floppy disks, cassette tapes, removable hard disks) and those Office Automation Systems equipped with fixed media (e.g., Winchester disks). Additional NCSC Publications: [NCSC4] National Computer Security Center, "Glossary of Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988. [NCSC5] National Computer Security Center, "Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001-83, NCSC, December 1985. [NCSC7] National Computer Security Center, "Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments", CSC-STD-003-85, NCSC, 25 June 1985. [NCSC8] National Computer Security Center, "Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements", CSC-STD-004-85, NCSC, 25 June 85. [NCSC9] National Computer Security Center, "Magnetic Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November 1985. This guideline is tagged as a "For Official Use Only" exemption under Section 6, Public Law 86-36 (50 U.S. Code 402). Distribution authorized of U.S. Government agencies and their contractors to protect unclassified technical, operational, or administrative data relating to operations of the National Security Agency. [NCSC10] 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. Site Security Policy Handbook Working Group [Page 98]
RFC 1244 Site Security Handbook July 1991 [NCSC11] 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. [NCSC12] 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. [NCSC13] National Computer Security Center, "Trusted Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987. [NCSC14] Tinto, M., "Computer Viruses: Prevention, Detection, and Treatment", National Computer Security Center C1 Technical Report C1-001-89, June 1989. [NCSC15] 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. 8.6 Security Checklists [AUCOIN] Aucoin, R., "Computer Viruses: Checklist for Recovery", Computers in Libraries, Vol. 9, No. 2, Pg. 4, 1 February 1989. [WOOD] Wood, C., Banks, W., Guarro, S., Garcia, A., Hampel, V., and H. Sartorio, "Computer Security: A Comprehensive Controls Checklist", John Wiley and Sons, Interscience Publication, 1987 8.7 Additional Publications Defense Data Network's Network Information Center (DDN NIC) The DDN NIC maintains DDN Security bulletins and DDN Management Site Security Policy Handbook Working Group [Page 99]
RFC 1244 Site Security Handbook July 1991 bulletins online on the machine: NIC.DDN.MIL. They are available via anonymous FTP. The DDN Security bulletins are in the directory: SCC, and the DDN Management bulletins are in the directory: DDN-NEWS. For additional information, you may send a message to: NIC@NIC.DDN.MIL, or call the DDN NIC at: 1-800-235-3155. [DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 November 1988. A Defense Data Network Management Bulletin announcement on the 4.2bsd and 4.3bsd software fixes to the Internet worm. [DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin 03", DDN Security Coordination Center, 17 October 1989. IEEE Proceedings [IEEE] "Proceedings of the IEEE Symposium on Security and Privacy", published annually. IEEE Proceedings are available from: Computer Society of the IEEE P.O. Box 80452 Worldway Postal Center Los Angeles, CA 90080 Other Publications: Computer Law and Tax Report Computers and Security Security Management Magazine Journal of Information Systems Management Data Processing & Communications Security SIG Security, Audit & Control Review Site Security Policy Handbook Working Group [Page 100]
RFC 1244 Site Security Handbook July 1991 9. Acknowledgments Thanks to the SSPHWG's illustrious "Outline Squad", who assembled at USC/Information Sciences Institute on 12-June-90: Ray Bates (ISI), Frank Byrum (DEC), Michael A. Contino (PSU), Dave Dalva (Trusted Information Systems, Inc.), Jim Duncan (Penn State Math Department), Bruce Hamilton (Xerox), Sean Kirkpatrick (Unisys), Tom Longstaff (CIAC/LLNL), Fred Ostapik (SRI/NIC), Keith Pilotti (SAIC), and Bjorn Satdeva (/sys/admin, inc.). Many thanks to Rich Pethia and the Computer Emergency Response Team (CERT); much of the work by Paul Holbrook was done while he was working for CERT. Rich also provided a very thorough review of this document. Thanks also to Jon Postel and USC/Information Sciences Institute for contributing facilities and moral support to this effort. Last, but NOT least, we would like to thank members of the SSPHWG and Friends for their additional contributions: Vint Cerf (CNRI), Dave Grisham (UNM), Nancy Lee Kirkpatrick (Typist Extraordinaire), Chris McDonald (WSMR), H. Craig McKee (Mitre), Gene Spafford (Purdue), and Aileen Yuan (Mitre). 10. Security Considerations If security considerations had not been so widely ignored in the Internet, this memo would not have been possible.

Back to RFC index




Register domain name and transfer | Cheap webhosting service | Domain name registration