Network Working Group P. Holbrook Request for Comments: 1244 CICNet FYI: 8 J. Reynolds ISI Editors July 1991 Site Security Handbook Status of this Memo This handbook is the product of the Site Security Policy Handbook Working Group (SSPHWG), a combined effort of the Security Area and User Services Area of the Internet Engineering Task Force (IETF). This FYI RFC provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Contributing Authors The following are the authors of the Site Security Handbook. Without their dedication, this handbook would not have been possible. Dave Curry (Purdue University), Sean Kirkpatrick (Unisys), Tom Longstaff (LLNL), Greg Hollingsworth (Johns Hopkins University), Jeffrey Carpenter (University of Pittsburgh), Barbara Fraser (CERT), Fred Ostapik (SRI NISC), Allen Sturtevant (LLNL), Dan Long (BBN), Jim Duncan (Pennsylvania State University), and Frank Byrum (DEC). Editors' Note This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. As such, this document is necessarily incomplete. There are some clear shortfalls; for example, this document focuses mostly on resources available in the United States. In the spirit of the Internet's "Request for Comments" series of notes, we encourage feedback from users of this handbook. In particular, those who utilize this document to craft their own policies and procedures. This handbook is meant to be a starting place for further research and should be viewed as a useful resource, but not the final authority. Different organizations and jurisdictions will have different resources and rules. Talk to your local organizations, consult an informed lawyer, or consult with local and national law enforcement. These groups can help fill in the gaps that this document cannot hope to cover. Site Security Policy Handbook Working Group [Page 1] RFC 1244 Site Security Handbook July 1991 Finally, we intend for this FYI RFC to grow and evolve. Please send comments and suggestions to: ssphwg@cert.sei.cmu.edu. Table of Contents 1. Introduction..................................................... 3 1.1 Purpose of this Work............................................ 3 1.2 Audience........................................................ 3 1.3 Definitions..................................................... 4 1.4 Related Work.................................................... 4 1.5 Scope........................................................... 4 1.6 Why Do We Need Security Policies and Procedures?................ 5 1.7 Basic Approach.................................................. 7 1.8 Organization of this Document................................... 7 2. Establishing Official Site Policy on Computer Security........... 9 2.1 Brief Overview.................................................. 9 2.2 Risk Assessment................................................. 10 2.3 Policy Issues................................................... 13 2.4 What Happens When the Policy Is Violated........................ 19 2.5 Locking In or Out............................................... 21 2.6 Interpreting the Policy......................................... 23 2.7 Publicizing the Policy.......................................... 23 3. Establishing Procedures to Prevent Security Problems............. 24 3.1 Security Policy Defines What Needs to be Protected.............. 24 3.2 Identifing Possible Problems.................................... 24 3.3 Choose Controls to Protect Assets in a Cost-Effective Way....... 26 3.4 Use Multiple Strategies to Protect Assets....................... 26 3.5 Physical Security............................................... 27 3.6 Procedures to Recognize Unauthorized Activity................... 27 3.7 Define Actions to Take When Unauthorized Activity is Suspected.. 29 3.8 Communicating Security Policy................................... 30 3.9 Resources to Prevent Security Breaches.......................... 34 4. Types of Security Procedures..................................... 56 4.1 System Security Audits.......................................... 56 4.2 Account Management Procedures................................... 57 4.3 Password Management Procedures.................................. 57 4.4 Configuration Management Procedures............................. 60 5. Incident Handling................................................ 61 5.1 Overview........................................................ 61 5.2 Evaluation...................................................... 65 5.3 Possible Types of Notification.................................. 67 5.4 Response........................................................ 71 5.5 Legal/Investigative............................................. 73 5.6 Documentation Logs.............................................. 77 6. Establishing Post-Incident Procedures............................ 78 6.1 Overview........................................................ 78 6.2 Removing Vulnerabilities........................................ 78 6.3 Capturing Lessons Learned....................................... 80 Site Security Policy Handbook Working Group [Page 2] RFC 1244 Site Security Handbook July 1991 6.4 Upgrading Policies and Procedures............................... 81 7. References....................................................... 81 8. Annotated Bibliography........................................... 83 8.1 Computer Law.................................................... 84 8.2 Computer Security............................................... 85 8.3 Ethics.......................................................... 91 8.4 The Internet Worm............................................... 93 8.5 National Computer Security Center (NCSC)........................ 95 8.6 Security Checklists............................................. 99 8.7 Additional Publications......................................... 99 9. Acknlowledgements................................................101 10. Security Considerations.........................................101 11. Authors' Addresses..............................................101 1. Introduction 1.1 Purpose of this Work This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet. This guide lists issues and factors that a site must consider when setting their own policies. It makes some recommendations and gives discussions of relevant areas. This guide is only a framework for setting security policies and procedures. In order to have an effective set of policies and procedures, a site will have to make many decisions, gain agreement, and then communicate and implement the policies. 1.2 Audience The audience for this work are system administrators and decision makers (who are more traditionally called "administrators" or "middle management") at sites. This document is not directed at programmers or those trying to create secure programs or systems. The focus of this document is on the policies and procedures that need to be in place to support any technical security features that a site may be implementing. The primary audience for this work are sites that are members of the Internet community. However, this document should be useful to any site that allows communication with other sites. As a general guide to security policies, this document may also be useful to sites with isolated systems. Site Security Policy Handbook Working Group [Page 3] RFC 1244 Site Security Handbook July 1991 1.3 Definitions For the purposes of this guide, a "site" is any organization that owns computers or network-related resources. These resources may include host computers that users use, routers, terminal servers, PC's or other devices that have access to the Internet. A site may be a end user of Internet services or a service provider such as a regional network. However, most of the focus of this guide is on those end users of Internet services. We assume that the site has the ability to set policies and procedures for itself with the concurrence and support from those who actually own the resources. The "Internet" is those set of networks and machines that use the TCP/IP protocol suite, connected through gateways, and sharing a common name and address spaces [1]. The term "system administrator" is used to cover all those who are responsible for the day-to-day operation of resources. This may be a number of individuals or an organization. The term "decision maker" refers to those people at a site who set or approve policy. These are often (but not always) the people who own the resources. 1.4 Related Work The IETF Security Policy Working Group (SPWG) is working on a set of recommended security policy guidelines for the Internet [23]. These guidelines may be adopted as policy by regional networks or owners of other resources. This handbook should be a useful tool to help sites implement those policies as desired or required. However, even implementing the proposed policies isn't enough to secure a site. The proposed Internet policies deal only with network access security. It says nothing about how sites should deal with local security issues. 1.5 Scope This document covers issues about what a computer security policy should contain, what kinds of procedures are need to enforce security, and some recommendations about how to deal with the problem. When developing a security policy, close attention should be made not only on the security needs and requirements of the local network, but also the security needs and requirements of the other interconnected networks. Site Security Policy Handbook Working Group [Page 4] RFC 1244 Site Security Handbook July 1991 This is not a cookbook for computer security. Each site has different needs; the security needs of a corporation might well be different than the security needs of an academic institution. Any security plan has to conform to the needs and culture of the site. This handbook does not cover details of how to do risk assessment, contingency planning, or physical security. These things are essential in setting and implementing effective security policy, but this document leaves treatment of those issues to other documents. We will try to provide some pointers in that direction. This document also doesn't talk about how to design or implement secure systems or programs. 1.6 Why Do We Need Security Policies and Procedures? For most sites, the interest in computer security is proportional to the perception of risk and threats. The world of computers has changed dramatically over the past twenty-five years. Twenty-five years ago, most computers were centralized and managed by data centers. Computers were kept in locked rooms and staffs of people made sure they were carefully managed and physically secured. Links outside a site were unusual. Computer security threats were rare, and were basically concerned with insiders: authorized users misusing accounts, theft and vandalism, and so forth. These threats were well understood and dealt with using standard techniques: computers behind locked doors, and accounting for all resources. Computing in the 1990's is radically different. Many systems are in private offices and labs, often managed by individuals or persons employed outside a computer center. Many systems are connected into the Internet, and from there around the world: the United States, Europe, Asia, and Australia are all connected together. Security threats are different today. The time honored advice says "don't write your password down and put it in your desk" lest someone find it. With world-wide Internet connections, someone could get into your system from the other side of the world and steal your password in the middle of the night when your building is locked up. Viruses and worms can be passed from machine to machine. The Internet allows the electronic equivalent of the thief who looks for open windows and doors; now a person can check hundreds of machines for vulnerabilities in a few hours. System administrators and decision makers have to understand the security threats that exist, what the risk and cost of a problem Site Security Policy Handbook Working Group [Page 5] RFC 1244 Site Security Handbook July 1991 would be, and what kind of action they want to take (if any) to prevent and respond to security threats. As an illustration of some of the issues that need to be dealt with in security problems, consider the following scenarios (thanks to Russell Brand [2, BRAND] for these): - A system programmer gets a call reporting that a major underground cracker newsletter is being distributed from the administrative machine at his center to five thousand sites in the US and Western Europe. Eight weeks later, the authorities call to inform you the information in one of these newsletters was used to disable "911" in a major city for five hours. - A user calls in to report that he can't login to his account at 3 o'clock in the morning on a Saturday. The system staffer can't login either. After rebooting to single user mode, he finds that password file is empty. By Monday morning, your staff determines that a number of privileged file transfers took place between this machine and a local university. Tuesday morning a copy of the deleted password file is found on the university machine along with password files for a dozen other machines. A week later you find that your system initialization files had been altered in a hostile fashion. - You receive a call saying that a breakin to a government lab occurred from one of your center's machines. You are requested to provide accounting files to help trackdown the attacker. A week later you are given a list of machines at your site that have been broken into. - A reporter calls up asking about the breakin at your center. You haven't heard of any such breakin. Three days later, you learn that there was a breakin. The center director had his wife's name as a password. Site Security Policy Handbook Working Group [Page 6] RFC 1244 Site Security Handbook July 1991 - A change in system binaries is detected. The day that it is corrected, they again are changed. This repeats itself for some weeks. - If an intruder is found on your system, should you leave the system open to monitor the situation or should you close down the holes and open them up again later? - If an intruder is using your site, should you call law enforcement? Who makes that decision? If law enforcement asks you to leave your site open, who makes that decision? - What steps should be taken if another site calls you and says they see activity c