Network Working Group P. Holbrook Request for Comments: 11XX CERT J. Reynolds ISI Editors MMMM 1990 DRAFT - 26-Nov-90 Security Policy Handbook Status of this Memo This handbook is the product of the Security Policy Handbook Working Group (SPHWG), a combined effort of the Security Area and User Services Area of the Internet Engineering Task Force (IETF). The SPHWG is co-chaired by J. Paul Holbrook (CERT) and Joyce K. Reynolds (ISI). This RFC provides information for the Internet community. It does not specify any standard. Distribution of this memo is unlimited. Contributing Authors and Acknowledgements The following are the authors of the Security Policy Handbook. Without their dedication, this handbook would not have been possible. Dave Curry (davy@erg.sri.com) Sean Kirkpatrick (sean@nisd.cam.unisys.com) Tom Longstaff (longstaf@cheetah.llnl.gov) Greg Hollingsworth (gregh@aplcen.apl.jhu.edu) Jeffrey Carpenter (jjc@unix.cis.pitt.edu) Allen Sturtevant (sturtevant@ccc.nersc.gov) Fred Ostapik (fred@nic.ddn.mil) Jim Duncan (jim@augusta.math.psu.edu) Frank Byrum (byrum@decuac.dec.com) Thanks to the SPHWG'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.). Last, but NOT least, we would like to thank members of the SPHWG and Friends for their additional contributions: Dave Grisham (UNM), Nancy Lee Kirkpatrick (Typist Extraordinaire), Chris McDonald (WSMR), H. Craig McKee (Mitre), Aileen Yuan (Mitre), ---put in more as warranted, if I've missed people, TELL ME! --jkrey. Security Policy Handbook Working Group [Page 1] RFC 11XX Security Policy Handbook MMMM 1990 Table of Contents 1. Introduction..................................................... X 1.1 Purpose of this Work............................................ X 1.2 Audience........................................................ X 1.3 Definitions..................................................... X 1.4 Related Work.................................................... X 1.5 Scope........................................................... X 1.6 Why Do We Need Security Policies and Procedures?................ X 1.7 Basic Approach.................................................. X 1.8 Organization of this Document................................... X 2. Establishing Official Site Policy on Computer Security........... X 2.1 Brief Overview.................................................. X 2.2 Risk Assessment................................................. X 2.3 Policy.......................................................... X 2.4 What Happens When the Policy Is Violated........................ X 2.5 Locking In or Out............................................... X 2.6 Publicizing the Policy.......................................... X 3. Establishing Procedures to Prevent Security Problems............. X 3.1 Overview........................................................ X 3.2 System Security Audits.......................................... X 3.3 Account Management Procedures................................... X 3.4 Password Management Procedures.................................. X 3.5 Configuration Management Procedures............................. X 3.6 Procedures to Recognize Unauthorized Activity................... X 3.7 Define Actions to Take When Unauthorized Activity is Suspected.. X 3.8 Communicating Security Policy................................... X 3.9 Resources to Prevent Security Breaches.......................... X 4. Incident Handling................................................ X 4.1 Overview........................................................ X 4.2 Evaluation...................................................... X 4.3 Possible Types of Notification.................................. X 4.4 Response........................................................ X 4.5 Legal/Investigative............................................. X 4.6 Documentation Logs.............................................. X 5. Establishing Post-Incident Procedures............................ X 5.1 Overview........................................................ X 5.2 Removing Vulnerabilities........................................ X 5.3 Capturing Lessons Learned....................................... X 5.4 Upgrading Policies and Procedures............................... X 6. References....................................................... X 7. Annotated Bibliography........................................... X 7.1 Computer Law.................................................... X 7.2 Computer Security............................................... X 7.3 Ethics.......................................................... X 7.4 The Internet Worm............................................... X 7.5 National Computer Security Center (NCSC)........................ X 7.6 Security Checklists............................................. X Security Policy Handbook Working Group [Page 2] RFC 11XX Security Policy Handbook MMMM 1990 7.7 Additional Publications......................................... X 8. Security Considerations.......................................... X 9. Authors' Addresses............................................... X 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. 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 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. Security Policy Handbook Working Group [Page 3] RFC 11XX Security Policy Handbook MMMM 1990 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 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. 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. 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 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 Security Policy Handbook Working Group [Page 4] RFC 11XX Security Policy Handbook MMMM 1990 the perceived 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, accounting for all resources. Computing in the 1990s 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 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 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. Security Policy Handbook Working Group [Page 5] RFC 11XX Security Policy Handbook MMMM 1990 - 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. - 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? Security Policy Handbook Working Group [Page 6] RFC 11XX Security Policy Handbook MMMM 1990 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 six 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 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 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 Security Policy Handbook Working Group [Page 7] RFC 11XX Security Policy Handbook MMMM 1990 protected and the level of resources that should be applied to protect them. Section 3 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 (CMU) estimates that 80% or more of the problems they see have to do with poorly chosen passwords. Section 4 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 5 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. ===== Section 2 - Draft of November 19, 1990 Authors: Jeffrey Carpenter (jjc@unix.cis.pitt.edu), Greg Hollingsworth (gregh@aplcen.apl.jhu.edu), Allen Sturtevant (sturtevant@CCC.NERSC.GOV). 2. Establishing Official Site Policy on Computer Security 2.1 Brief Overview 2.1.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. The goals and direction of the organization should be considered. A military base may have very different security concerns from a university. Security Policy Handbook Working Group [Page 8] RFC 11XX Security Policy Handbook MMMM 1990 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 enforceable nor implementable is useless. Since a computer security policy can effect 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 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 the eventual 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 Security Policy Handbook Working Group [Page 9] RFC 11XX Security Policy Handbook MMMM 1990 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 the efforts spent on security are worth the time and effort spent on them. 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 looking at what you need to protect, what you need to protect it from, and how to protect it. It also involves making cost-effective decisions on what to protect. The old security adage says that you shouldn't spend more to protect something than it's actually worth. There are various approaches to the details of how to do a risk assessment, but they all have common elements. One typical approach is given by Fites [3, FITES, page 29]: 1. Create a team of people to do the job. 2. Identify the assets. 3. Identify the threats. 4. Determine the probabilities of the threats. 5. Calculate the exposures. 6. Introduce safeguards. 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. A full treatment of risk analysis is outside the scope of this book. [3, FITES] and [16, PFLEEGER] provide introductions to this topic. 2.2.2 Assets The first step in a risk analysis is to identify all these 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. One list of categories is suggested by Pfleeger [16, PFLEEGER, Security Policy Handbook Working Group [Page 10] RFC 11XX Security Policy Handbook MMMM 1990 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 This part of the risk analysis is an inventory of existing assets. The essential point is to list all things that could be affected by a security problem. 2.2.3 Threats Identifying threat is a key element in calculating security risks. Consider what are you trying to protect your assets from. The following sections describe some of the possible threats. Each site must evaluate for itself how vulnerable it is from these kinds of threats. 2.2.3.1 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. Security Policy Handbook Working Group [Page 11] RFC 11XX Security Policy Handbook MMMM 1990 The risk from unauthorized access may vary from site to site. The the Computer Emergency Response Team (CERT - see section 3.9.7.3.1) has observed that well known universities, government sites, and military sites seem to attract more intruders. 2.2.3.2 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. 2.2.3.3 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 number. Determine the services that are essential to the site and the effect that would be realized if the service were to be disabled. 2.2.4 Possible Problems To determine risk, vulnerabilities must be identified. Part of the purpose of the policy is to aid in shoring up the vulnerabilities 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. 2.2.4.1 Access Points Access points are typically used for entry by unauthorized users. Many access points indiscriminately allow access to an organization's computer and network facilities. 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 Security Policy Handbook Working Group [Page 12] RFC 11XX Security Policy Handbook MMMM 1990 number of network services, and each service has compromise potential. 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. 2.2.4.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. Because this person either has no experience in systems management, or has no extra time to learn proper management procedures, simply getting the system working is often satisfactory. 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. 2.2.4.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. 2.2.4.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. Security Policy Handbook Working Group [Page 13] RFC 11XX Security Policy Handbook MMMM 1990 The ability to access the components of a system makes most systems easier to compromise. Most desktop workstations can be easily manipulated so that they grant privileged access. Access to a local area network provides the ability to view possibly sensitive data traversing the network. 2.3 Policy 2.3.1 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 are they allowed to use the system/services for? 3. What are their rights and responsibilities for using the system/services? This section of the handbook covers these questions. 2.3.2 Basic Assumptions [ I am having problems figuring out what should be in this section. Any input is welcome!] - Connected to the Internet. When developing your security policy, you should not only consider the security implications of your own network, but you should also consider the security implications of the other networks you are connected to. - Inventory of networked components including PCs, servers, networked devices, physical security. You need to know what devices are connected to your network. Unauthorized connections may be used to breach security. You will most likely know what is connected by requiring users to follow a procedure in order to legitimately connect. You also need to take steps to ensure the physical security of your network, so that users cannot attach unauthorized devices without your knowledge. - Introduce problem areas/assets. ----->needs to be filled in.<------ Security Policy Handbook Working Group [Page 14] RFC 11XX Security Policy Handbook MMMM 1990 2.3.3 Policy Issues 2.3.3.1 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 granting 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: 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 between security and convenience. The more centralized, the easier to secure. What methods will you use for creating accounts and terminating access? 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. 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 Security Policy Handbook Working Group [Page 15] RFC 11XX Security Policy Handbook MMMM 1990 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 log in. Consider that some users may never even log in, 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.3.2 Who is it You are Giving Access To? While developing your security policy, it is important to address the procedures on internal security issues. 2.3.3.2.1 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. One approach that can be taken is to grant only enough privileges to accomplish the tasks necessary. Restricting privileges is one way to deal with threats from insiders. 2.3.3.2.2 Accountability for Actions Taken/Auditing Whenever a security problem develops, one of the first steps you will want to take is to examine logs and auditing trails. In many cases, these will be essential to track down the culprit. In addition, the lack of accounting for operations performed by privileged administrators is an invitation for abuse. You need to ensure that mechanisms are developed to make actions performed by system administrators with privileges are logged and easily audited. Security Policy Handbook Working Group [Page 16] RFC 11XX Security Policy Handbook MMMM 1990 2.3.3.2.3 Methods of Selecting People You need to ensure that people who you grant privileges to are accountable to you or some other authority. If the people you grant privileges to are not accountable, you run the risk of loosing control of your system and will have difficulty managing a compromise in security. 2.3.3.3 What is the Proper Use of Resources? Provide guidelines for acceptable use. 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. Your acceptable use policy should clearly state that individual users are responsible for their actions. Their responsibility exists regardless of the security mechanisms that are in place. You should clearly state that breaking into accounts or bypassing security is not permitted. In your acceptable use policy, you should cover the following points: 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". 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 "license to hack", where 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 Security Policy Handbook Working Group [Page 17] RFC 11XX Security Policy Handbook MMMM 1990 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 it 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 (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 What the process for obtaining permission to conduct these tests are. 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 appropriate inclusion of provisions in your policy to permit this. Define limits to access and authority as 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. 2.3.3.4 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, etc.). Your policy in this area needs to be coordinated with the policy concerning the right of system administrators versus users (see section 2.3.6). Security Policy Handbook Working Group [Page 18] RFC 11XX Security Policy Handbook MMMM 1990 2.3.3.5 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 you may do so. o Methods of conveying information on the copyright/licensed status of software. o When in doubt, DON'T COPY. ----->**** 2.3.4 Ethical Behavior 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. Parker, Swope and Baker [17, PARKER90] and Forester and Morrison [18, FORESTER] are two useful references that address ethical issues. 2.3.5 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 create their own. Security Policy Handbook Working Group [Page 19] RFC 11XX Security Policy Handbook MMMM 1990 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 (Electronic Communications Privacy Act). 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. 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 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 Rights and Responsibilities of System Administrators versus Rights of Users o Can an administrator monitor or read a user's files for any reason? o Liabilities o 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 Security Policy Handbook Working Group [Page 20] RFC 11XX Security Policy Handbook MMMM 1990 system administrator's 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 under these circumstances. 2.4 What Happens When the Policy is Violated [AS] The following items discuss some ideas that one should consider when enforcing a computer security policy. Defining the actual computer security policy enforcement methods is beyond the scope of this document since computer security requirements vary greatly depending on the type of electronic data to be protected. As an example, a Department of Defense (DoD) computer facility performing top secret research would have far more stringent requirements than, a collection of universities sharing unclassified information about joint biological research over the Internet. 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. This is guaranteed. 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 how the violation was performed. For the few types of violations mentioned above, there would be different forms of actions needed. 2.4.1 What to do When Outsiders Violate the Policy [AS] What is an "outsider"? Depending on your perception, the term outsiders may mean, for example, another group within your organization, another organization within your division, another division within your company or another company altogether. This word actually refers to many kinds of outsiders, with each kind being defined by your administrative, legal or political Security Policy Handbook Working Group [Page 21] RFC 11XX Security Policy Handbook MMMM 1990 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 outsider violating your computer security policy. This all seems rather complicated, but should be addressed long before the need becomes necessary. 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 outsiders who are using your computer illegally, the problem is basically the same. What type of outsider 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 a drastic action. ----->*****[add more here]*****<----- 2.4.2 What to do When Local Users Violate the Policy [AS] The term "local user" (or "insider") falls under same definition rules mentioned for "outsiders". Anyone who is not an outsider is a local user as far as this document is concerned. 2.4.3 What to do for Insider Intrusion - Libel And Slander [AS] [to be completed] 2.4.4 What to do When Local Users Violate the Policy of a Remote Site [AS] [to be completed] 2.4.5 Define Contacts and Responsibilities to Outside Organizations [AS] [to be completed - talk about policy, escalation procedures, who is allowed to talk to outsiders, who performs which role, etc...] Security Policy Handbook Working Group [Page 22] RFC 11XX Security Policy Handbook MMMM 1990 2.4.6 Who is Authorized to Make Outside Contacts? [AS] [to be completed] 2.4.7 What are Your Obligations to Those Contacts? [AS] [to be completed] 2.4.8 What are the Responsibilities to our Neighbors and Other Internet Sites? [AS] [to be completed - reference Security Policy Working Group work on recommended Internet security policy] 2.4.9 Issues for Incident Handling Procedures [AS] [to be completed - reference Section IV C 4] ===== Author: Fred Ostapik (fred@NISC.SRI.COM) - Draft: 7-Nov-90 2.5 Locking In or Out Whenever a site incurs an incident which may compromise computer security, the reaction strategies 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 person or persons responsible. 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. Security Policy Handbook Working Group [Page 23] RFC 11XX Security Policy Handbook MMMM 1990 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 what the choices are and how they will be made 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 whatever approach is taken. The following are checklists to help a site determine which strategy to adopt: "Protect and Proceed" or "Pursue and Prosecute". 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, if their resources are undermined. Pursue and Prosecute 1. If assets/system 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. Security Policy Handbook Working Group [Page 24] RFC 11XX Security Policy Handbook MMMM 1990 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 letting 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 with the operating system and related utilities and systems to make the pursuit worthwhile. 10. If there is willingness on the part of management to prosecute. 11. If the system gurus know 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 Publicizing the Policy Once the site security policy has been established and committed to writing, a vigorous process should be engaged which will 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 unforseen 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 troops. Security is a collective effort. Security Policy Handbook Working Group [Page 25] RFC 11XX Security Policy Handbook MMMM 1990 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. ===== Section 3 Draft of November 15 & 16, 1990 Authors: Dave Curry (davy@erg.sri.com), Sean Kirkpatrick (sean@nisd.cam.unisys.com) 3. Establishing Procedures to Prevent Security Problems [DC] This section discusses the procedures used to prevent security problems, as well as the procedures used in the event a security problem arises. 3.1 Overview [DC] It is important to develop procedures to prevent security problems at your site. By following a fixed set of procedures, you can be reasonably sure that there are least some things you don't have to worry about (provided the procedures are followed, of course). 3.1.1 Security Policy Identifies Assets to Protect [DC] One part of your security policy will identify exactly what you are trying to protect, and what you're trying to protect it from. Generally speaking, you are trying to protect your computer systems and data from being compromised, modified, stolen, deleted, etc. The security policy will spell this out in more detail, usually by dividing your computer systems (and possibly the data) into several categories, and spelling out how you plan to protect the assets in those categories. [SK] input: One of the major purposes of a security policy is to define those things that need some sort of protection, and to define the type of protection that those things need. The physical equipment, computers, cabling, terminals or workstations, etc, are all physical assets that obviously need protecting. Security Policy Handbook Working Group [Page 26] RFC 11XX Security Policy Handbook MMMM 1990 It's not always clear however, what other assets there may be that need protecting. For example, a business may use computers to process information about employees (such as salary), as well as data about the business operations itself (such as business plans and other technical data). Hospitals typically use computers to maintain patient data, and there exists a very well defined legal requirement to protect this data from disclosure. A university may be involved in research, the disclosure of which may result in a loss of future funding. In each of these examples, the data maintained by computers should be regarded as sensitive assets that must be afforded some kind of protection. The security policy should carefully enumerate what those assets are, and why they are deserving of protection. 3.1.2 Risk Assessment Establishes What's Cost-Effective to Protect [DC] Risk assessment is the process of examining all of your risks, and ranking those risks by level of severity. This determines what risks are cost-effective to protect against. You don't want to spend a lot of time and money protecting yourself against something you don't feel is a serious risk. For example, you may decide that your site is very worried about being broken into over the network or via a dialup modem, but that you are not very concerned with security violations from your own employees. In this case, you would want to focus most of your time and effort (and money) on protecting your system against network and modem intruders, and you would spend only a little time on setting up ways for users to protect their files from each other. [SK] input: Once the assets requiring protection are identified, a process of risk assessment should examine the threats to those assets, and what potential for loss exists. Once this is done, it is then possible to examine potential counters to those threats, and to establish a reasonable approach to implementing required protection mechanisms. 3.1.3 Choose Controls to Protect Assets in a Cost-Effective Way [DC] After establishing what is to be protected, and assessing the risks these assets face, it is necessary to decide how to implement the controls which protect these assets. [SK] input: It should be obvious that the controls and protection mechanisms should be selected in a way so as to adequately counter Security Policy Handbook Working Group [Page 27] RFC 11XX Security Policy Handbook MMMM 1990 the threats found during risk assessment, and to implement those controls in a cost effective manner. It makes little sense to spend an exorbitant sum of money and overly constrict the user base if the risk of exposure is very small. 3.1.3.1 Choose the Right Set of Controls [DC] [I'm not sure what belongs in this section - it seems sort of obvious that you don't want to choose the *wrong* set of controls.] [SK] input: The controls that are selected represent the physical embodiment of your security policy. They are the first and primary line of defense in the protection of your assets. It is therefore most important to ensure that the controls that you select are the right set of controls. If the major threat to your system is outside penetrators, it probably doesn't make much sense to use biometric devices to authenticate your regular system users. On the other hand, if the major threat is unauthorized use of computing resources by regular system users, you'll probably want to establish very rigorous automated accounting procedures. 3.1.3.2 Use Common Sense [DC] One thing to remember when setting up your security controls is to use common sense. While elaborate security systems are impressive, and they do have their place, there is little point in purchasing or implementing an elaborate scheme if the simple things are forgotten. For example, no matter how elaborate a system you put into place on top of existing security controls, a single user with a poor password can still leave your system open to attack. When implementing your security controls, don't forget the simple things that still require attention. [SK] input: It probably cannot be said enough that common sense is the most appropriate tool that can be used to establish your security policy. The idea of a security policy centers around the notion of reasonable and credible controls. Elaborate schemes and mechanisms, while appealing to a sense of the exotic, are frequently of less objective than simpler mechanisms. Furthermore, it may be that expending effort on elaborate mechanisms may hide and otherwise obvious hole in your overall policy. 3.1.4 Use Multiple Strategies to Protect Assets [DC] Another method of protecting assets is to use multiple strategies. Security Policy Handbook Working Group [Page 28] RFC 11XX Security Policy Handbook MMMM 1990 In this way, if one strategy fails or is circumvented, another strategy comes into play to continue protecting the asset. By using several simpler strategies, a system can often be made more secure than if one very sophisticated method were used in its place. [SK] input: It is also a reasonable approach to use multiple strategies to protect your assets. Dial-back modems can be used in conjunction with traditional logon mechanisms. Many similar approaches could be devised that provide several levels of protection for assets. However, it's very easy to go overboard with extra mechanisms. One must keep in mind exactly what it is that need to be protected. 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,DC] 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. 3.2.2 Test Procedures [DC] Even if you don't 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. And so on. Security Policy Handbook Working Group [Page 29] RFC 11XX Security Policy Handbook MMMM 1990 [SK] input: When a security audit is required, 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, that is, if a test is defined to examine the user logon process, it should be explicitly stated that both valid and invalid user names and passwords will be used to demonstrate proper operation of the logon program. Keep in mind that there is a limit to what reasonable tests are. The purpose of testing is to develop confidence that the security policy is being correctly enforced, and not to "prove" the absoluteness of the system or policy. The goal should be to obtain some assurance that the reasonable and credible controls imposed by your security policy are adequate. 3.3 Account Management Procedures [DC] Procedures to manage accounts are important in preventing unauthorized access to your system. It is necessary to decide several things: Who may have an account on the system? How long may someone have an account without renewing his/her request? How do old accounts get removed from the system? The answers to all these questions should be set out in a policy in order to prevent unintentional violations. 3.3.1 Determine Authorization of System or Network Use [DC] In addition to deciding who may use a system, it may be important to determine what each user may use the system for (is personal use allowed, for example). If you are connected to an outside network, your site or the network management may have rules about what the network may be used for. [SK] input: It is important for any security policy to define an adequate account management procedure for both administrators and users. Typically, the system administrator would be responsible for creating and deleting user accounts, and generally maintain overall control of system use. To some degree, account management is also the responsibility of each system user in the sense that the user should observe any system messages and events that may be Security Policy Handbook Working Group [Page 30] RFC 11XX Security Policy Handbook MMMM 1990 indicative of a policy violation. For example, a message at logon that indicates the date and time of the last logon should be reported by the user if it indicates an unreasonable time of last logon. 3.4 Password Management Procedures [DC] A policy on password management may be important, if your site wishes to enforce secure passwords. These procedures may range from asking or forcing users to change their passwords occasionally to actively attempting to break users' passwords and then informing the user of how easy it was to do. Another part of password management policy covers who may distribute passwords - can users give their passwords to other users? 3.5 Configuration Management Procedures [SK] Configuration management is generally applied to the software development process. However, it is certainly applicable in a operational sense as well. Consider that the since many of the system level programs are intended to enforce the security policy, it is important that these be "known" as correct. That is, one should not allow system level programs (such as operating system updates, etc.) to be changed arbitrarily. At very least, the procedures should state who is authorized to make changes to systems, under what circumstances, and how the changes should be documented. In some environments, configuration management is also desirable as applied to physical configuration of equipment as well. Maintaining valid and authorized hardware configuration should be given due consideration in your security policy. 3.5.1 Physical Security [SK] input: Editorial note: I don't quite understand what Physical Security, et. al., has to do with configuration management. While it is appropriate to discuss physical security as a topic, I don't think it belongs here. [PH] input: It is a given that in computer security, if the system itself is not physically secure, nothing else about the system can be considered secure. With physical access to a machine, an intruder can halt the machine, bring it back up in privileged mode, replace or alter the disk, plant Trojan horse programs (see section 3.9.9.2), or take any number of other undesirable (and hard to protect) actions. Critical communications links, important servers, and other key Security Policy Handbook Working Group [Page 31] RFC 11XX Security Policy Handbook MMMM 1990 machines should be located in physically secure areas. Some security systems (such as Kerberos) require that the machine be physically secure. If you cannot physically secure machines, care should be taken about trusting those machines. Sites should consider limiting access from non-secure machines to more secure machines. In particular, allowing trusted access (e.g., the BSD Unix r- commands) from these kinds of hosts is particularly risky. For machines that are physically secure, care should be taken about who has access to the machines. Remember that custodial and maintenance staff often have keys to rooms. 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 intruders. 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] Several simple procedures can be used to detect most unauthorized uses of a computer system. These procedures use tools provided with Security Policy Handbook Working Group [Page 32] RFC 11XX Security Policy Handbook MMMM 1990 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, and 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 an intruder. - 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 Security Policy Handbook Working Group [Page 33] RFC 11XX Security Policy Handbook MMMM 1990 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 started by an intruder. 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, checklists 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 checklist (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 frequently, 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 an intruder to predict your actions. For example, if an intruder knows that each day at 5:00 p.m. 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. Security Policy Handbook Working Group [Page 34] RFC 11XX Security Policy Handbook MMMM 1990 [SK] input: Despite the advantages that regular system monitoring provides, some intruders will know the things an administrator may do to monitor their system, and will sometimes take action to disable monitoring mechanisms. Regular monitoring therefore does not provide any guarantees that your system is secure, but can still be a valuable defensive technique that can be used to increase the assurance that your system is not being abused. [DC] input: Note that some intruders may be aware of the standard logging mechanisms in use on systems they are attacking, and will actively attempt to disable or fool these mechanisms. Monitoring commands are useful in detecting intruders, but they should not be considered an infallible method of detecting unauthorized use. 3.7 Define Actions to Take When Unauthorized Activity is Suspected Sections 2.4 and 2.5 discussed the course of action a site should take when it suspects its systems are being abused. The computer security policy should state the general approach towards dealing with these problems. The procedures for dealing with these types of problems should be written down. Who has authority to decide what actions will be taken? Should law enforcement be involved? Should your organization cooperate with other sites in trying to track down an intruder? Answers to all the questions in section 2.4 should be part of the incident handling procedures. [We still need to fill in those questions in 2.4! --jkrey] Whether you decide to lock out or pursue intruders, you should have tools and procedures ready to apply. It is best to work up these tools and procedures before you need them. Don't wait until an intruder is on your system to figure out how to track the intruder's actions; you will be busy enough if an intruder strikes. 3.8 Communicating Security Policy [DC] Security policies, in order to be effective, must be communicated to 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. Security Policy Handbook Working Group [Page 35] RFC 11XX Security Policy Handbook MMMM 1990 3.8.1.1 Proper Account/Workstation Use [DC] All users should be informed about what is considered the "proper" use of their account or workstation ("proper" use is discussed in section 2.3.1). This can most easily be done at the time a user receives their account, by giving them 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. A more complete list of items to consider when writing a policy statement is given in section 2.3. 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 be fully exploited by an intruder if he/she can gain access via a poorly chosen password. It is important to define Security Policy Handbook Working Group [Page 36] RFC 11XX Security Policy Handbook MMMM 1990 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 Security Policy Handbook Working Group [Page 37] RFC 11XX Security Policy Handbook MMMM 1990 words which are usually pronounceable, and thus easily remembered. - Choose two short words and concatenate them together with a punctuation character between them. Users should also be told to change their password periodically, usually every three to six months. This makes sure that an intruder who has guessed a password will eventually lose access, as well as invalidating any list of passwords he/she 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. [5, CURRY] Some systems provide software which forces users to change their passwords on a regular basis. Many of these systems also include password generators, which provide the user with a set of passwords to choose from. The user is not permitted to make up his/her own password. There are arguments both for and against systems such as these. On the one hand, by using generated passwords, users are prevented from selecting insecure passwords. On the other hand, unless the generator is good at making up easy to remember passwords, users will begin writing them down in order to remember them. 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, he/she should be told to check that time and note whether or not it agrees with the last time he/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. Security Policy Handbook Working Group [Page 38] RFC 11XX Security Policy Handbook MMMM 1990 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 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 are generally very dangerous, since they allow anyone to access the system. Even accounts which do not execute a command interpreter (e.g., accounts which exist only to see who is logged in to the system) can be compromised if set up incorrectly. A related concept, that of "anonymous" file transfer (FTP) [20], allows users from all over the network to access your system to retrieve files from (usually) a protected disk area. You should carefully weigh the benefits that an account without a password provides against the security risks of providing such access to your system. 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. It protects passwords by hiding their encrypted values from unprivileged users. This prevents an attacker from copying your password file to his/her machine and then attempting to break the passwords at his/her leisure. 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. Security Policy Handbook Working Group [Page 39] RFC 11XX Security Policy Handbook MMMM 1990 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. Many intruders collect information on the vulnerabilities of particular system versions. The older a system, the more likely it is that there are security problems in that version which have since been fixed by the vendor in a later release. For this reason, it is important to weigh the risks of not upgrading to a new operating system release (thus leaving security holes unplugged) against the cost of upgrading to the new software (possibly breaking third-party software, etc.). Bug fixes from the vendor should be weighed in a similar fashion, with the added note that "security" fixes from a vendor usually address fairly serious security problems. 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 an intruder has suggested a "fix" which actually gives his/her 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 against unauthorized changes made by an intruder. Without a copy of your data the way it's "supposed" to be, it can be difficult to undo something an attacker has done. Backups, especially if run daily, can also be useful in providing a history of an intruder's activities. Looking through old backups can establish when your system was first penetrated. Intruders may leave files around which although deleted later, are captured on the backup tapes. Backups can Security Policy Handbook Working Group [Page 40] RFC 11XX Security Policy Handbook MMMM 1990 also be used to document an intruder's activities to law enforcement agencies if necessary. 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. Other methods include setting up some sort of response team similar to the CERT, or establishing a "hotline" serviced by an existing support group. 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 Network Connections and Firewalls [SK,DC] 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 less susceptible to threats from outside their own organization, although intrusions may still occur via paths such as dial-up modems. On the other hand, many other organizations will be connected to other sites via much larger networks, such as the Internet. These sites are susceptible to the entire range of threats incipient to a networked environment. The risks of connecting to outside networks must be weighed against the benefits. It may be desirable to limit connection to Security Policy Handbook Working Group [Page 41] RFC 11XX Security Policy Handbook MMMM 1990 outside networks to those hosts which do not store sensitive material, keeping "vital" machines (such as those which maintain company payroll or inventory systems) isolated. If there is a need to participate in a Wide Area Network (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 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 even with a firewall system, compromise of the firewall could result in compromise of the network behind the firewall. Work has been done in some areas to construct a firewall which even when compromised, still protects the local network. [6, CHESWICK] 3.9.2 Confidentiality [SK,DC] 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 site where everything is protected, or a site where all information is usually regarded as public, or something in-between. Most sites lean toward the latter, at least until some penetration has occurred. Generally, there are three instances in which information is vulnerable to disclosure: when the information is stored on a computer system, when the information is in transit to another system (on the network), and when the information is stored on backup tapes. The first of these cases is controlled by file permissions, access control lists, and other similar mechanisms. The last can be controlled by restricting access to the backup tapes (by locking them in a safe, for example). All three cases can be helped by using encryption mechanisms. Security Policy Handbook Working Group [Page 42] RFC 11XX Security Policy Handbook MMMM 1990 3.9.2.1 Encryption (hardware and software) [SK,DC] 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. The advantage of using encryption is that even if other access control mechanisms (passwords, file permissions, etc.) are compromised by an intruder, the data is still protected by being unusable. Naturally, encryption keys and the like should be protected at least as well as account passwords. Information in transit (over a network) may be vulnerable to interception as well. Several solutions to this exist, ranging from simply encrypting files before transferring them (end-to- end encryption) to special network hardware which encrypts everything it sends without user intervention (secure links). The Internet as a whole does not use secure links, thus end- to-end encryption must be used if encryption is desired across the Internet. 3.9.2.1.1 DES [SK] DES, the Data Encryption Standard, is perhaps the most widely used data encryption mechanism 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 encrypt data using the DES algorithm. Security Policy Handbook Working Group [Page 43] RFC 11XX Security Policy Handbook MMMM 1990 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,DC] Electronic mail normally transits the network in the clear (i.e., anyone can read it). This is obviously 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 and deployed on the Internet. The Internet Activities Board Privacy Task Force has defined a draft standard, elective protocol for use in implementing privacy enhanced mail. This protocol is defined in RFCs 1113, 1114, and 1115 [7,8,9]. Please refer to the current edition of the "IAB Official Protocol Standards" (currently, RFC 1140 [21]) for the standardization state and status of these protocols. 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 else's 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 message 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. Security Policy Handbook Working Group [Page 44] RFC 11XX Security Policy Handbook MMMM 1990 In this scheme, the public key is used to authenticate the originator's use of his/her private key, and hence the identity of the originator is more rigorously proven. The most widely known implementation of a public key cryptosystem is the RSA system. The Internet standard for privacy enhanced mail makes use of the RSA system. [citation for RSA?? --jkrey] 3.9.4 Information Integrity [SK,DC] 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 value of information integrity to a site will vary. For example, it is more important for military and government 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. 3.9.4.1 Checksums [SK,DC] 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. A specific type of checksum, called a CRC checksum, is considerably more robust than a simple checksum. It is only slightly more difficult to implement and provides a much finer degree of catching errors. It too, however, suffers from the Security Policy Handbook Working Group [Page 45] RFC 11XX Security Policy Handbook MMMM 1990 ability to be compromised by an attacker. Checksums may be used to detect the altering of information. However, they do not actively guard against changes being made. For this, other mechanisms such as access controls and encryption should be used. 3.9.4.2 Cryptographic Checksums [SK,DC] Cryptographic checksums (also called cryptosealing) involve breaking a file up into smaller chunks, calculating a (CRC) checksum for each chunk, and adding the CRCs 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 sometimes computationally intensive and may be prohibitive except in cases where the utmost integrity protection is desired. Another related mechanism, called a one-way hash function (or a Manipulation Detection Code (MDC)) can also be used to uniquely identify a file. The idea behind these functions is that no two inputs can produce the same output, thus a modified file will not have the same hash value. One-way hash functions can be implemented efficiently on a wide variety of systems, making unbreakable integrity checks possible. (Snefru, a one-way hash function available via USENET as well as the Internet is just one example of an efficient one-way hash function.) [10] 3.9.5 Limiting Network Access [DC] The dominant network protocols in use on the Internet, IP (RFC 791) [11], TCP (RFC 793) [12], and UDP (RFC 768) [13], 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 Security Policy Handbook Working Group [Page 46] RFC 11XX Security Policy Handbook MMMM 1990 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. 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, one 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. [14] 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 himself/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.). Security Policy Handbook Working Group [Page 47] RFC 11XX Security Policy Handbook MMMM 1990 3.9.6.1 Kerberos [SK,DC] 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 the Massachusetts Institute of Technology (MIT), it uses a combination of encryption and distributed databases so that a user at a campus facility can 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. Some vendors are now incorporating Kerberos into their systems. It should be noted that while Kerberos makes several advances in the area of authentication, some security weaknesses in the protocol still remain. [15] 3.9.6.2 Smart Cards [SK] Some computer systems have instituted new password procedures that require a user to enter a value obtained 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 can provide you with a good start. In addition, information can be obtained from a variety of other sources, some of which are described in this section. 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 Security Policy Handbook Working Group [Page 48] RFC 11XX Security Policy Handbook MMMM 1990 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 Defense Data Network's Network Information Center's (DDN NIC) 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 open to the public, and is implemented as a moderated 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. This list is also available via the USENET newsgroup "comp.virus". The Computer Underground Digest "is an open forum dedicated to sharing information among computerists and to the presentation and debate of diverse views." While not directly a security list, it does contain discussions about privacy and other security related topics. The list can be read on USENET as alt.society.cu-digest, or to join the mailing list, send mail to Gordon Myer (TK0JUT2%NIU.bitnet@mitvma.mit.edu). Submissions may be mailed to: cud@chinacat.unicom.com. Security Policy Handbook Working Group [Page 49] RFC 11XX Security Policy Handbook MMMM 1990 3.9.7.2 Networking Mailing Lists [DC] The TCP-IP mailing 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". 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. The USENET groups misc.security and alt.security also discuss security issues. misc.security is a moderated group, and also includes discussions of physical security and locks. alt.security is unmoderated. 3.9.7.3 Response Teams [DC] Several organizations have formed special groups of people to deal with computer security problems. These teams collect information about possible security holes and disseminate it to the proper people, track intruders, and assist in recovery from security violations. The teams typically have both electronic mail distribution lists as well as a special telephone number which can be called for information or to report a problem. Many of these teams are members of the CERT System, which is coordinated by the National Institute of Standards and Technology (NIST), and exists to facilitate the exchange of information between the various teams. 3.9.7.3.1 DARPA Computer Emergency Response Team [DC] The Computer Emergency Response Team/Coordination Center (CERT/CC) was established in December 1988 by the Defense Advanced Research Projects Agency (DARPA) to address computer security concerns of research users of the Internet. It is operated by the Software Engineering Institute (SEI) at Carnegie-Mellon University (CMU). The CERT can immediately confer with experts to diagnose and solve security problems, and also establish and maintain communications with the affected computer users and government authorities as appropriate. The CERT/CC serves as a clearing house for the Security Policy Handbook Working Group [Page 50] RFC 11XX Security Policy Handbook MMMM 1990 identification and repair of security vulnerabilities, informal assessments of existing systems, improvement of emergency response capability, and both vendor and user security awareness. In addition, the team works with vendors of various systems in order to coordinate the fixes for security problems. The CERT/CC 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. The material sent to this list also appears in the USENET newsgroup "comp.security.announce". Past advisories are available for anonymous FTP from the host CERT.SEI.CMU.EDU. The 24-hour hotline number is (412) 268- 7090. The CERT/CC also maintains a CERT-TOOLS list to encourage the exchange of information on tools and techniques that increase the secure operation of Internet systems. The CERT/CC does not review or endorse the tools described on the list. To subscribe, send a message to CERT-TOOLS- REQUEST@CERT.SEI.CMU.EDU and ask to be added to the mailing list. The CERT/CC maintains other generally useful security information for anonymous FTP from CERT.SEI.CMU.EDU. Get the README file for a list of what is available. For more information, contact: CERT Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 (412) 268-7090 cert@cert.sei.cmu.edu. 3.9.7.3.2 DDN Security Coordination Center [DC] For DDN users, the Security Coordination Center (SCC) serves a function similar to CERT. The SCC is the DDN's clearing- Security Policy Handbook Working Group [Page 51] RFC 11XX Security Policy Handbook MMMM 1990 house for host/user security problems and fixes, and works with the DDN Network Security Officer. The SCC also distributes the DDN Security Bulletin, which communicates information on network and host security exposures, fixes, and concerns to security and management personnel at DDN facilities. It is available online, via kermit or anonymous FTP, from the host NIC.DDN.MIL, in SCC:DDN-SECURITY-yy- nn.TXT (where "yy" is the year and "nn" is the bulletin number). The SCC provides immediate assistance with DDN- related host security problems; call (800) 235-3155 (6:00 a.m. to 5:00 p.m. Pacific Time) or send email to SCC@NIC.DDN.MIL. For 24 hour coverage, call the MILNET Trouble Desk (800) 451-7413 or AUTOVON 231-1713. 3.9.7.3.3 NIST Computer Security Resource and Response Center [DC] The National Institute of Standards and Technology (NIST) has responsibility within the U.S. Federal Governmen