idnits 2.17.1 draft-ietf-ssh-handbook-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 82 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 82 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 79 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1208 has weird spacing: '..., it is recog...' == Line 2168 has weird spacing: '...able to facil...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1997) is 9875 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '1' is mentioned on line 146, but not defined == Missing Reference: '3' is mentioned on line 212, but not defined == Missing Reference: 'FITES' is mentioned on line 212, but not defined == Missing Reference: '16' is mentioned on line 212, but not defined == Missing Reference: 'PFLEEGER' is mentioned on line 212, but not defined == Missing Reference: 'Stool' is mentioned on line 3892, but not defined == Missing Reference: 'Cheswick2' is mentioned on line 4045, but not defined == Missing Reference: 'Aucion' is mentioned on line 4359, but not defined == Missing Reference: 'IEEE' is mentioned on line 4401, but not defined == Unused Reference: 'Aucoin' is defined on line 2967, but no explicit reference was found in the text == Unused Reference: 'NCSA1' is defined on line 3231, but no explicit reference was found in the text == Unused Reference: 'NCSA2' is defined on line 3233, but no explicit reference was found in the text == Unused Reference: 'Ranum1' is defined on line 3349, but no explicit reference was found in the text == Unused Reference: 'Ranum2' is defined on line 3352, but no explicit reference was found in the text == Unused Reference: 'Schneier 1996' is defined on line 3373, but no explicit reference was found in the text == Unused Reference: 'Stoll' is defined on line 3431, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ABA' -- Possible downref: Non-RFC (?) normative reference: ref. '1989' -- Possible downref: Non-RFC (?) normative reference: ref. 'Aucoin' -- Possible downref: Non-RFC (?) normative reference: ref. 'Barrett' -- Possible downref: Non-RFC (?) normative reference: ref. '1996' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bates' -- Possible downref: Non-RFC (?) normative reference: ref. '1992' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin' -- Possible downref: Non-RFC (?) normative reference: ref. '1990' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bender' -- Possible downref: Non-RFC (?) normative reference: ref. '1894' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bloombecker' -- Possible downref: Non-RFC (?) normative reference: ref. 'Brand' -- Possible downref: Non-RFC (?) normative reference: ref. 'Brock' -- Possible downref: Non-RFC (?) normative reference: ref. 'BS 7799' -- Possible downref: Non-RFC (?) normative reference: ref. 'Caelli' -- Possible downref: Non-RFC (?) normative reference: ref. '1988' -- Possible downref: Non-RFC (?) normative reference: ref. 'Carroll' -- Possible downref: Non-RFC (?) normative reference: ref. '1987' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'Chapman' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cheswick' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cheswick1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Conly' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cooper' -- Possible downref: Non-RFC (?) normative reference: ref. 'CPSR' -- Possible downref: Non-RFC (?) normative reference: ref. 'CSC-STD-002-85' -- Possible downref: Non-RFC (?) normative reference: ref. '1985' -- Possible downref: Non-RFC (?) normative reference: ref. 'Curry' -- Possible downref: Non-RFC (?) normative reference: ref. 'DDN88' -- Possible downref: Non-RFC (?) normative reference: ref. 'DDN89' -- Possible downref: Non-RFC (?) normative reference: ref. 'Denning' -- Possible downref: Non-RFC (?) normative reference: ref. 'Farrow' -- Possible downref: Non-RFC (?) normative reference: ref. '1991' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fenwick' -- Possible downref: Non-RFC (?) normative reference: ref. 'Garfinkel' -- Possible downref: Non-RFC (?) normative reference: ref. '1995' -- Possible downref: Non-RFC (?) normative reference: ref. 'Gemignani' -- Possible downref: Non-RFC (?) normative reference: ref. 'Goodell' -- Possible downref: Non-RFC (?) normative reference: ref. 'Gould' -- Possible downref: Non-RFC (?) normative reference: ref. 'Greenia' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hoffman' -- Possible downref: Non-RFC (?) normative reference: ref. 'Howard' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hughes' ** Downref: Normative reference to an Unknown state RFC: RFC 1087 -- Duplicate reference: RFC1087, mentioned in '89', was also mentioned in 'IAB-RFC1087'. ** Downref: Normative reference to an Unknown state RFC: RFC 1087 (ref. '89') -- Possible downref: Non-RFC (?) normative reference: ref. 'IVPC' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kane' -- Possible downref: Non-RFC (?) normative reference: ref. '1994' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kent' -- Possible downref: Non-RFC (?) normative reference: ref. 'Levy' -- Possible downref: Non-RFC (?) normative reference: ref. '1984' -- Possible downref: Non-RFC (?) normative reference: ref. 'Lewis' -- Possible downref: Non-RFC (?) normative reference: ref. 'Littleman' -- Possible downref: Non-RFC (?) normative reference: ref. 'Merkle' -- Possible downref: Non-RFC (?) normative reference: ref. 'McEwen' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIT' -- Possible downref: Non-RFC (?) normative reference: ref. 'Mogel' -- Possible downref: Non-RFC (?) normative reference: ref. 'Muffett' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSA1' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSA2' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-89-660-P' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-89-254-P' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-C1-001-89' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-CSC-STD-003-85' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-STD-004-85' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-STD-005-85' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-TCSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-TG-003' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-TG-001' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-TG-004' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-TG-005' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-TG-006' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCSC-TRUSIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'NRC' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'NSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'NSF' -- Possible downref: Non-RFC (?) normative reference: ref. 'NTISSAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'OTA-CIT-310' -- Possible downref: Non-RFC (?) normative reference: ref. 'OTA-TCT-606' -- Possible downref: Non-RFC (?) normative reference: ref. 'Parker' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pfleeger' -- Possible downref: Non-RFC (?) normative reference: ref. 'Quarterman' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ranum1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ranum2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ranum' -- Possible downref: Non-RFC (?) normative reference: ref. '1993' -- Possible downref: Non-RFC (?) normative reference: ref. 'Reinhardt' ** Downref: Normative reference to an Informational RFC: RFC 1135 -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier 1996' -- Possible downref: Non-RFC (?) normative reference: ref. 'Seeley' -- Possible downref: Non-RFC (?) normative reference: ref. 'Shaw' -- Possible downref: Non-RFC (?) normative reference: ref. '1986' -- Possible downref: Non-RFC (?) normative reference: ref. 'Shimomura' -- Possible downref: Non-RFC (?) normative reference: ref. 'Shirey' -- Possible downref: Non-RFC (?) normative reference: ref. 'Smith' -- Possible downref: Non-RFC (?) normative reference: ref. 'Spafford' -- Possible downref: Non-RFC (?) normative reference: ref. 'Stallings1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Stallings2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Stallings3' -- Possible downref: Non-RFC (?) normative reference: ref. 'Stoll' -- Possible downref: Non-RFC (?) normative reference: ref. 'Trible' -- Possible downref: Non-RFC (?) normative reference: ref. 'Venema' -- Possible downref: Non-RFC (?) normative reference: ref. 'USENIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'Wrobel' -- Possible downref: Non-RFC (?) normative reference: ref. 'Vallabhaneni' Summary: 14 errors (**), 0 flaws (~~), 22 warnings (==), 108 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Barbara Fraser 3 Network Working Group SEI/CMU 4 Expires in six months Editor 5 March 1997 7 Site Security Handbook 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 24 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This handbook is a guide to developing computer security policies and 31 procedures for sites that have systems on the Internet. The purpose 32 of this handbook is to provide practical guidance to administrators 33 trying to secure their information and services. The subjects 34 covered include policy content and formation, a broad range of 35 technical system and network security topics, and security incident 36 response. 38 Table of Contents 40 1. Introduction.................................................... 2 41 1.1 Purpose of this Work............................................ 2 42 1.2 Audience........................................................ 2 43 1.3 Definitions..................................................... 3 44 1.4 Related Work.................................................... 3 45 1.5 Basic Approach.................................................. 3 46 1.6 Risk Assessment................................................. 4 47 2. Security Policies............................................... 5 48 2.1 What is a Security Policy and Why Have One?..................... 5 49 2.2 What Makes a Good Security Policy?.............................. 7 50 2.3 Keeping the Policy Flexible..................................... 9 51 3. Architecture.................................................... 9 52 3.1 Objectives...................................................... 10 53 3.2 Network and Service Configuration............................... 12 54 3.3 Firewalls....................................................... 17 55 4. Security Services and Procedures................................ 21 56 4.1 Authentication.................................................. 21 57 4.2 Confidentiality................................................. 24 58 4.3 Integrity....................................................... 24 59 4.4 Authorization................................................... 25 60 4.5 Access.......................................................... 25 61 4.6 Auditing........................................................ 29 62 4.7 Securing Backups................................................ 31 63 5. Security Incident Handling...................................... 32 64 5.1 Preparing and Planning for Incident Handling.................... 33 65 5.2 Notification and Points of Contact.............................. 35 66 5.3 Identifying an Incident......................................... 42 67 5.4 Handling an Incident............................................ 44 68 5.5 Aftermath of an Incident........................................ 49 69 5.6 Responsibilities................................................ 50 70 6. Ongoing Activities.............................................. 51 71 7. Tools and Locations............................................. 52 72 8. Mailing Lists and Other Resources............................... 53 73 9. References...................................................... 55 74 10. Annotated Bibliography.......................................... 65 76 1. Introduction 78 This document provides guidance to system and network administrators 79 on how to address security issues within the Internet community. It 80 builds on the foundation provided in RFC 1244 and is the collective 81 work of a number of contributing authors. Those authors include: 82 Jules P. Aronson, Nevil Brownlee, Frank Byrum, Joao Nuno Ferreira, 83 Barbara Fraser, Steve Glass, Erik Guttman, Tom Killalea, Klaus-Peter 84 Kossakowski, Lorna Leone, Edward.P.Lewis, Gary Malkin, Russ Mundy, 85 Philip J. Nesser, and Michael S. Ramsey. 87 In addition to the principle writers, a number of reviewers provided 88 valuable comments. Those reviewers include: Eric Luiijf, Marijke 89 Kaat, and Han Pronk. 91 A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook, 92 CICnet, for their vision, leadership, and effort in the creation of 93 the first version of this handbook. It is the working group's sincere 94 hope that this version will be as helpful to the community as the 95 earlier one was. 97 1.1 Purpose of This Work 99 This handbook is a guide to setting computer security policies and 100 procedures for sites that have systems on the Internet (however, the 101 information provided should also be useful to sites not yet connected 102 to the Internet). This guide lists issues and factors that a site 103 must consider when setting their own policies. It makes a number of 104 recommendations and provides discussions of relevant areas. 106 This guide is only a framework for setting security policies and 107 procedures. In order to have an effective set of policies and 108 procedures, a site will have to make many decisions, gain agreement, 109 and then communicate and implement these policies. 111 1.2 Audience 113 The audience for this document are system and network administrators, 114 and decision makers (typically "middle management") at sites. For 115 brevity, we will use the term "administrator" throughout this 116 document to refer to system and network administrators. 118 This document is not directed at programmers or those trying to 119 create secure programs or systems. The focus of this document is on 120 the policies and procedures that need to be in place to support the 121 technical security features that a site may be implementing. 123 The primary audience for this work are sites that are members of the 124 Internet community. However, this document should be useful to any 125 site that allows communication with other sites. As a general guide 126 to security policies, this document may also be useful to sites with 127 isolated systems. 129 1.3 Definitions 131 For the purposes of this guide, a "site" is any organization that 132 owns computers or network-related resources. These resources may 133 include host computers that users use, routers, terminal servers, 134 PC's or other devices that have access to the Internet. A site may 135 be an end user of Internet services or a service provider such as a 136 mid-level network. However, most of the focus of this guide is on 137 those end users of Internet services. We assume that the site has 138 the ability to set policies and procedures for itself with the 139 concurrence and support from those who actually own the resources. It 140 will be assumed that sites that are parts of larger organizations 141 will know when they need to consult, collaborate, or take 142 recommendations from, the larger entity. 144 The "Internet" is that set of networks and machines which use the 145 TCP/IP protocol suite, connect through gateways, and share common 146 name and address spaces [1]. 148 The term "administrator" is used to cover all those people who are 149 responsible for the day-to-day operation of system and network 150 resources. This may be a number of individuals or an organization. 152 The term "security administrator" is used to cover all those people 153 who are responsible for the security of information and information 154 technology. At some sites this function may be combined with 155 administrator (above); at others, this will be a separate position. 157 The term "decision maker" refers to those people at a site who set or 158 approve policy. These are often (but not always) the people who own 159 the resources. 161 1.4 Related Work 163 The Site Security Handbook Working Group is working on a User's Guide 164 to Internet Security. It will provide practical guidance to end users 165 to help them protect their information and the resources they use. 167 1.5 Basic Approach 169 This guide is written to provide basic guidance in developing a 170 security plan for your site. One generally accepted approach to 171 follow is suggested by Fites, et. al. [ref] and includes the 172 following steps: 174 (1) Identify what you are trying to protect. 175 (2) Determine what you are trying to protect it from. 176 (3) Determine how likely the threats are. 177 (4) Implement measures which will protect your assets in a cost- 178 effective manner. 179 (5) Review the process continuously and make improvements each time 180 a weakness is found. 182 Most of this document is focused on item 4 above, but the other steps 183 cannot be avoided if an effective plan is to be established at your 184 site. One old truism in security is that the cost of protecting 185 yourself against a threat should be less than the cost of recovering 186 if the threat were to strike you. Cost in this context should be 187 remembered to include losses expressed in real currency, reputation, 188 trustworthiness, and other less obvious measures. Without reasonable 189 knowledge of what you are protecting and what the likely threats are, 190 following this rule could be difficult. 192 1.6 Risk Assessment 194 1.6.1 General Discussion 196 One of the most important reasons for creating a computer security 197 policy is to ensure that efforts spent on security yield cost 198 effective benefits. Although this may seem obvious, it is possible 199 to be mislead about where the effort is needed. As an example, there 200 is a great deal of publicity about intruders on computers systems; 201 yet most surveys of computer security show that, for most 202 organizations, the actual loss from "insiders" is much greater. 204 Risk analysis involves determining what you need to protect, what you 205 need to protect it from, and how to protect it. It is the process of 206 examining all of your risks, then ranking those risks by level of 207 severity. This process involves making cost-effective decisions on 208 what you want to protect. As mentioned above, you should probably 209 not spend more to protect something than it is actually worth. 211 A full treatment of risk analysis is outside the scope of this 212 document. [3, FITES] and [16, PFLEEGER] provide introductions to 213 this topic. However, there are two elements of a risk analysis that 214 will be briefly covered in the next two sections: 216 (1) Identifying the assets 217 (2) Identifying the threats 219 For each asset, the basic goals of security are availability, 220 confidentiality, and integrity. Each threat should be examined with 221 an eye to how the threat could affect these areas. 223 1.6.2 Identifying the Assets 225 One step in a risk analysis is to identify all the things that need 226 to be protected. Some things are obvious, like valuable proprietary 227 information, intellectual property, and all the various pieces of 228 hardware; but, some are overlooked, such as the people who actually 229 use the systems. The essential point is to list all things that could 230 be affected by a security problem. 232 One list of categories is suggested by Pfleeger [16, PFLEEGER, page 233 459]; this list is adapted from that source: 235 (1) Hardware: CPUs, boards, keyboards, terminals, 236 workstations, personal computers, printers, disk 237 drives, communication lines, terminal servers, routers. 239 (2) Software: source programs, object programs, 240 utilities, diagnostic programs, operating systems, 241 communication programs. 243 (3) Data: during execution, stored on-line, archived off-line, 244 backups, audit logs, databases, in transit over 245 communication media. 247 (4) People: users, administrators, hardware maintainers. 249 (5) Documentation: on programs, hardware, systems, local 250 administrative procedures. 252 (6) Supplies: paper, forms, ribbons, magnetic media. 254 1.6.3 Identifying the Threats 256 Once the assets requiring protection are identified, it is necessary 257 to identify threats to those assets. The threats can then be 258 examined to determine what potential for loss exists. It helps to 259 consider from what threats you are trying to protect your assets. 260 The following are classic threats that should be considered. 261 Depending on your site, there will be more specific threats that 262 should be identified and addressed. 264 (1) Unauthorized access to resources and/or information 265 (2) Unintented and/or unauthorized Disclosure of information 266 (3) Denial of service 268 2. Security Policies 270 Throughout this document there will be many references to policies. 271 Often these references will include recommendations for specific 272 policies. Rather than repeat guidance in how to create and 273 communicate such a policy, the reader should apply the advice 274 presented in this chapter when developing any policy recommended 275 later in this book. 277 2.1 What is a Security Policy and Why Have One? 279 The security-related decisions you make, or fail to make, as 280 administrator largely determines how secure or insecure your network 281 is, how much functionality your network offers, and how easy your 282 network is to use. However, you cannot make good decisions about 283 security without first determining what your security goals are. 284 Until you determine what your security goals are, you cannot make 285 effective use of any collection of security tools because you simply 286 will not know what to check for and what restrictions to impose. 288 For example, your goals will probably be very different from the 289 goals of a product vendor. Vendors are trying to make configuration 290 and operation of their products as simple as possible, which implies 291 that the default configurations will often be as open (i.e., 292 insecure) as possible. While this does make it easier to install new 293 products, it also leaves access to those systems, and other systems 294 through them, open to any user who wanders by. 296 Your goals will be largely determined by the following key tradeoffs: 298 (1) services offered versus security provided - 299 Each service offered to users carries its own security risks. 300 For some services the risk outweighs the benefit of the service 301 and the administrator may choose to eliminate the service rather 302 than try to secure it. 304 (2) ease of use versus security - 305 The easiest system to use would allow access to any user and require 306 no passwords; that is, there would be no security. Requiring 307 passwords makes the system a little less convenient, but more secure. 308 Requiring device-generated one-time passwords makes the system even 309 more difficult to use, but much more secure. 311 (3) cost of security versus risk of loss - 312 There are many different costs to security: monetary (i.e., the 313 cost of purchasing security hardware and software like firewalls 314 and one-time password generators), performance (i.e., encryption 315 and decryption take time), and ease of use (as mentioned above). 316 There are also many levels of risk: loss of privacy (i.e., the 317 reading of information by unauthorized individuals), loss of 318 data (i.e., the corruption or erasure of information), and the 319 loss of service (e.g., the filling of data storage space, usage 320 of computational resources, and denial of network access). Each 321 type of cost must be weighed against each type of loss. 323 Your goals should be communicated to all users, operations staff, and 324 managers through a set of security rules, called a "security policy." 325 We are using this term, rather than the narrower "computer security 326 policy" since the scope includes all types of information technology 327 and the information stored and manipulated by the technology. 329 2.1.1 Definition of a Security Policy 331 A security policy is a formal statement of the rules by which people 332 who are given access to an organization's technology and information 333 assets must abide. 335 2.1.2 Purposes of a Security Policy 337 The main purpose of a security policy is to inform users, staff and 338 managers of their obligatory requirements for protecting technology 339 and information assets. The policy should specify the mechanisms 340 through which these requirements can be met. Another purpose is to 341 provide a baseline from which to acquire, configure and audit 342 computer systems and networks for compliance with the policy. 343 Therefore an attempt to use a set of security tools in the absence of 344 at least an implied security policy is meaningless. 346 An Appropriate Use Policy (AUP) may also be part of a security 347 policy. It should spell out what users shall and shall not do on the 348 various components of the system, including the type of traffic 349 allowed on the networks. The AUP should be as explicit as possible 350 to avoid ambiguity or misunderstanding. For example, an AUP might 351 list any prohibited USENET newsgroups. (Note: Appropriate Use Policy 352 is referred to as Acceptable Use Policy by some sites.) 354 2.1.3 Who Should be Involved When Forming Policy? 356 In order for a security policy to be appropriate and effective, it 357 needs to have the acceptance and support of all levels of employees 358 within the organization. The following is a list of individuals who 359 should be involved in the creation and review of security policy 360 documents: 362 (1) site security administrator 363 (2) information technology technical staff (e.g., staff from 364 computing center) 365 (3) administrators of large user groups within the organization 366 (e.g., business divisions, computer science department within a 367 university, etc.) 368 (4) security incident response team 369 (5) representatives of the user groups affected by the security policy 370 (6) responsible management 371 (7) legal counsel (if appropriate) 373 The list above is representative of many organizations, but is not 374 necessarily comprehensive. The idea is to bring in representation 375 from key stakeholders, management who have budget and policy 376 authority, technical staff who know what can and cannot be supported, 377 and legal counsel who know the legal ramifications of various policy 378 choices. In some organizations, it may be appropriate to include EDP 379 audit personnel. Involving this group is important if resulting 380 policy statements are to reach the broadest possible acceptance. It 381 is also relevant to mention that the role of legal counsel will also 382 vary from country to country. 384 2.2 What Makes a Good Security Policy? 386 The characteristics of a good security policy are: 388 (1) It must be implementable through system administration 389 procedures, publishing of acceptable use guidelines, or other 390 appropriate methods. 392 (2) It must be enforcible with security tools, where appropriate, 393 and with sanctions, where actual prevention is not technically 394 feasible. 396 (3) It must clearly define the areas of responsibility for the 397 users, administrators, and management. 399 The components of a good security policy include: 401 (1) Computer Technology Purchasing Guidelines which specify required, 402 or preferred, security features. These should supplement existing 403 purchasing policies and guidelines. 405 (2) A Privacy Policy which defines reasonable expectations of privacy 406 regarding such issues as monitoring of electronic mail, logging of 407 keystrokes, and access to users' files. 409 (3) An Access Policy which defines access rights and privileges to 410 protect assets from loss or disclosure by specifying acceptable use 411 guidelines for users, operations staff, and management. It should 412 provide guidelines for external connections, data communications, 413 connecting devices to a network, and adding new software to 414 systems. It should also specify any required notification messages 415 (e.g., connect messages should provide warnings about authorized 416 usage and line monitoring, and not simply say "Welcome"). 418 (4) An Accountability Policy which defines the responsibilities of users, 419 operations staff, and management. It should specify an audit 420 capability, and provide incident handling guidelines (i.e., what to 421 do and who to contact if a possible intrusion is detected). 423 (5) An Authentication Policy which establishes trust through an effective 424 password policy, and by setting guidelines for remote location 425 authentication and the use of authentication devices (e.g., one-time 426 passwords and the devices that generate them). 428 (6) An Availability statement which sets users' expectations for the 429 availability of resources. It should address redundancy and recovery 430 issues, as well as specify operating hours and maintenance down-time 431 periods. It should also include contact information for reporting 432 system and network failures. 434 (7) An Information Technology System & Network Maintenance Policy 435 which describes how both internal and external maintenance people 436 are allowed to handle and access technology. One important 437 topic to be addressed here is whether remote maintenance is 438 allowed and how such access is controlled. Another area for 439 consideration here is outsourcing and how it is managed. 441 (8) A Violations Reporting Policy that indicates which types of 442 violations (e.g., privacy and security, internal and external) 443 must be reported and to whom the reports are made. A 444 non-threatening atmosphere and the possibility of anonymous reporting 445 will result in a greater probability that a violation will be 446 reported if it is detected. 448 (9) Supporting Information which provides users, staff, and management 449 with contact information for each type of policy violation; 450 guidelines on how to handle outside queries about a security incident, 451 or information which may be considered confidential or proprietary; 452 and cross-references to security procedures and related information, 453 such as company policies and governmental laws and regulations. 455 There may be regulatory requirements that affect some aspects of your 456 security policy (e.g., line monitoring). The creators of the 457 security policy should consider seeking legal assistance in the 458 creation of the policy. At a minimum, the policy should be reviewed 459 by legal counsel. 461 Once your security policy has been established it should be clearly 462 communicated to users, staff, and management. Having all personnel 463 sign a statement indicating that they have read, understood, and 464 agreed to abide by the policy is an important part of the process. 465 Finally, your policy should be reviewed on a regular basis to see if 466 it is successfully supporting your security needs. 468 2.3 Keeping the Policy Flexible 470 In order for a security policy to be viable for the long term, it 471 requires a lot of flexibility based upon an architectural security 472 concept. A security policy should be (largely) independent from 473 specific hardware and software situations (as specific systems tend 474 to be replaced or moved overnight). The mechanisms for updating the 475 policy should be clearly spelled out. This includes the process, the 476 people involved, and the people who must sign-off on the changes. 478 It is also important to recognize that there are exceptions to every 479 rule. Whenever possible, the policy should spell out what exceptions 480 to the general policy exist. For example, under what conditions is a 481 system administrator allowed to go through a user's files. Also, 482 there may be some cases when multiple users will have access to the 483 same userid. For example, on systems with a "root" user, multiple 484 system administrators may know the password and use the root account. 486 Another consideration is called the "Garbage Truck Syndrome." This 487 refers to what would happen to a site if a key person was suddenly 488 unavailable for his/her job function (e.g., was suddenly ill or left 489 the company unexpectedly). While the greatest security resides in 490 the minimum dissemination of information, the risk of losing critical 491 information increases when that information is not shared. It is 492 important to determine what the proper balance is for your site. 494 3. Architecture 496 3.1 Objectives 498 3.1.1 Completely Defined Security Plans 500 All sites should define a comprehensive security plan. This plan 501 should be at a higher level than the specific policies discussed in 502 chapter 2, and it should be crafted as a framework of broad 503 guidelines into which specific policies will fit. 505 It is important to have this framework in place so that individual 506 policies can be consistent with the overall site security 507 architecture. For example, having a strong policy with regard to 508 Internet access and having weak restrictions on modem usage is 509 inconsistent with an overall philosophy of strong security 510 restrictions on external access. 512 A security plan should define: the list of network services that will 513 be provided; which areas of the organization will provide the 514 services; who will have access to those services; how access will be 515 provided; who will administer those services; etc. 517 The plan should also address how incident will be handled. Chapter 5 518 provides an in-depth discussion of this topic, but it is important 519 for each site to define classes of incidents and corresponding 520 responses. For example, sites with firewalls should set a threshold 521 on the number of attempts made to foil the firewall before triggering 522 a response? Escallation levels should be defined for both attacks 523 and responses. Sites without firewalls will have to determine if a 524 single attempt to connect to a host constitutes an incident? What 525 about a systematic scan of systems? 527 For sites connected to the Internet, the rampant media magnification 528 of Internet related security incidents can overshadow a (potentially) 529 more serious internal security problem. Likewise, companies who have 530 never been connected to the Internet may have strong, well defined, 531 internal policies but fail to adequately address an external 532 connection policy. 534 3.1.2 Separation of Services 536 There are many services which a site may wish to provide for its 537 users, some of which may be external. There are a variety of 538 security reasons to attempt to isolate services onto dedicated host 539 computers. There are also performance reasons in most cases, but a 540 detailed discussion is beyond to scope of this document. 542 The services which a site may provide will, in most cases, have 543 different levels of access needs and models of trust. Services which 544 are essential to the security or smooth operation of a site would be 545 better off being placed on a dedicated machine with very limited 546 access (see Section 3.1.3 "deny all" model), rather than on a machine 547 that provides a service (or services) which has traditionally been 548 less secure, or requires greater accessability by users who may 549 accidentally suborn security. 551 It is also important to distinguish between hosts which operate 552 within different models of trust (e.g., all the hosts inside of a 553 firewall and any host on an exposed network). 555 Some of the services which should be examined for potential 556 separation are outlined in section 3.2.3. It is important to remember 557 that security is only as strong as the weakest link in the chain. 558 Several of the most publicized penetrations in recent years have been 559 through the exploitation of vulnerabilities in electronic mail 560 systems. The intruders were not trying to steal electronic mail, but 561 they used the vulnerability in that service to gain access to other 562 systems. 564 If possible, each service should be running on a different machine 565 whose only duty is to provide a specific service. This helps to 566 isolate intruders and limit potential harm. 568 3.1.3 Deny all/ Allow all 570 There are two diametrically opposed underlying philosophies which can 571 be adopted when defining a security plan. Both alternatives are 572 legitimate models to adopt, and the choice between them will depend 573 on the site and its needs for security. 575 The first option is to turn off all services and then selectively 576 enable services on a case by case basis as they are needed. This can 577 be done at the host or network level as appropriate. This model, 578 which will here after be referred to as the "deny all" model, is 579 generally more secure than the other model described in the next 580 paragraph. More work is required to successfully implement a "deny 581 all" configuration as well as a better understanding of services. 582 Allowing only known services provides for a better analysis of a 583 particular service/protocol and the design of a security mechanism 584 suited to the security level of the site. 586 The other model, which will here after be referred to as the "allow 587 all" model, is much easier to implement, but is generally less secure 588 than the "deny all" model. Simply turn on all services, usually the 589 default at the host level, and allow all protocols to travel across 590 network boundaries, usually the default at the router level. As 591 security holes become apparent, they are restricted or patched at 592 either the host or network level. 594 Each of these models can be applied to different portions of the 595 site, depending on functionality requirements, administrative 596 control, site policy, etc. For example, the policy may be to use the 597 "allow all" model when setting up workstations for general use, but 598 adopt a "deny all" model when setting up information servers, like an 599 email hub. Likewise, an "allow all" policy may be adopted for 600 traffic between LAN's internal to the site, but a "deny all" policy 601 can be adopted between the site and the Internet. 603 Be careful when mixing philosophies as in the examples above. Many 604 sites adopt the theory of a hard "crunchy" shell and a soft "squishy" 605 middle. They are willing to pay the cost of security for their 606 external traffic and require strong security measures, but are 607 unwilling or unable to provide similar protections internally. This 608 works fine as long as the outer defenses are never breached and the 609 internal users can be trusted. Once the outer shell (firewall) is 610 breached, subverting the internal network is trivial. 612 3.1.4 Identify Real Needs for Services 614 There is a large variety of services which may be provided, both 615 internally and on the Internet at large. Managing security is, in 616 many ways, managing access to services internal to the site and 617 managing how internal users access information at remote sites. 619 Services tend to rush like waves over the Internet. Over the years 620 many sites have established anonymous FTP servers, gopher servers, 621 wais servers, WWW servers, etc. as they became popular, but not 622 particularly needed, at all sites. Evaluate all new services that 623 are established with a skeptical attitude to determine if they are 624 actually needed or just the current fad sweeping the Internet. 626 Bear in mind that security complexity can grow exponentially with the 627 number of services provided. Filtering routers need to be modified 628 to support the new protocols. Some protocols are inherently 629 difficult to filter safely (e.g., RPC and UDP services), thus 630 providing more openings to the internal network. Services provided 631 on the same machine can interact in catastrophic ways. For example, 632 allowing anonymous FTP on the same machine as the WWW server may 633 allow an intruder to place a file in the anonymous FTP area and cause 634 the HTTP server to execute it. 636 3.2 Network and Service Configuration 638 3.2.1 Protecting the Infrastructure 640 Many network administrators go to great lengths to protect the hosts 641 on their networks. Few administrators make any effort to protect the 642 networks themselves. There is some rationale to this. For example, 643 it is far easier to protect a host than a network. Also, intruders 644 are likely to be after data on the hosts; damaging the network would 645 not serve their purposes. That said, there are still reasons to 646 protect the networks. For example, an intruder might divert network 647 traffic through an outside host in order to examine the data (i.e., 648 to search for passwords). Also, infrastructure includes more than 649 the networks and the routers which interconnect them. Infrastructure 650 also includes network management (e.g., SNMP), services (e.g., DNS, 651 NFS, NTP, WWW), and security (i.e., user authentication and access 652 restrictions). 654 The infrastructure also needs protection against human error. When 655 an administrator misconfigures a host, that host may offer degraded 656 service. This only affects users who require that host and, unless 657 that host is a primary server, the number of affected users will 658 therefore be limited. However, if a router is misconfigured, all 659 users who require the network will be affected. Obviously, this is a 660 far larger number of users than those depending on any one host. 662 3.2.2 Protecting the Network 664 There are several problems to which networks are vulnerable. The 665 classic problem is a "denial of service" attack. In this case, the 666 network is brought to a state in which it can no longer carry 667 legitimate users' data. There are two common ways this can be done: 668 by attacking the routers and by flooding the network with extraneous 669 traffic. Please note that the term "router" in this section is used 670 as an example of a larger class of active network interconnection 671 components that also includes components like firewalls, proxy- 672 servers, etc. 674 An attack on the router is designed to cause it to stop forwarding 675 packets, or to forward them improperly. The former case may be due 676 to a misconfiguration, the injection of a spurious routing update, or 677 a "flood attack" (i.e., the router is bombarded with unroutable 678 packets, causing its performance to degrade). A flood attack on a 679 network is similar to a flood attack on a router, except that the 680 flood packets are usually broadcast. An ideal flood attack would be 681 the injection of a single packet which exploits some known flaw in 682 the network nodes and causes them to retransmit the packet, or 683 generate error packets, each of which is picked up and repeated by 684 another host. A well chosen attack packet can even generate an 685 exponential explosion of transmissions. 687 Another classic problem is "spoofing." In this case, spurious 688 routing updates are sent to one or more routers causing them to 689 misroute packets. This differs from a denial of service attack only 690 in the purpose behind the spurious route. In denial of service, the 691 object is to make the router unusable; a state which will be quickly 692 detected by network users. In spoofing, the spurious route will 693 cause packets to be routed to a host from which an intruder may 694 monitor the data in the packets. These packets are then re-routed to 695 their correct destinations. However, the intruder may or may not 696 have altered the contents of the packets. 698 The solution to most of these problems is to protect the routing 699 update packets sent by the routing protocols in use (e.g., RIP-2, 700 OSPF). There are three levels of protection: clear-text password, 701 cryptographic checksum, and encryption. Passwords offer only minimal 702 protection against intruders who do not have direct access to the 703 physical networks. Passwords also offer some protection against 704 misconfigured routers (i.e, routers which, out of the box, attempt to 705 route packets). The advantage of passwords is that they have a very 706 low overhead, in both bandwidth and CPU consumption. Checksums 707 protect against the injection of spurious packets, even if the 708 intruder has direct access to the physical network. Combined with a 709 sequence number, or other unique identifier, a checksum can also 710 protect again "replay" attacks, wherein an old (but valid at the 711 time) routing update is retransmitted by either an intruder or a 712 misbehaving router. The most security is provided by complete 713 encryption of sequenced, or uniquely identified, routing updates. 714 This prevents an intruder from determining the topology of the 715 network. The disadvantage to encryption is the overhead involved in 716 processing the updates. 718 RIP-2 (RFC 1723) and OSPF (RFC 1583) both support clear-text 719 passwords in their base design specifications. In addition, there 720 are extensions to each base protocol to support MD5 encryption. 722 Unfortunately, there is no adequate protection against a flooding 723 attack, or a misbehaving host or router which is flooding the 724 network. Fortunately, this type of attack is obvious when it occurs 725 and can usually be terminated relatively simply. 727 3.2.3 Protecting the Services 729 There are many types of services and each has its own security 730 requirements. These requirements will vary based on the intended use 731 of the service. For example, a service which should only be usable 732 within a site (e.g., NFS) may require different protection mechanisms 733 than a service provided for external use. It may be sufficient to 734 protect the internal server from external access. However, a WWW 735 server, which provides a home page intended for viewing by users 736 anywhere on the Internet, requires built-in protection. That is, the 737 service/protocol/server must provide whatever security may be 738 required to prevent unauthorized access and modification of the Web 739 database. 741 Internal services (i.e., services meant to be used only by users 742 within a site) and external services (i.e., services deliberately 743 made available to users outside a site) will, in general, have 744 protection requirements which differ as previously described. It is 745 therefore wise to isolate the internal services to one set of server 746 host computers and the external services to another set of server 747 host computers. That is, internal and external servers should not be 748 co-located on the same host computer. In fact, many sites go so far 749 as to have one set of subnets (or even different networks) which are 750 accessible from the outside and another set which may be accessed 751 only within the site. Of course, there is usually a firewall which 752 connects these partitions. Great care must be taken to ensure that 753 such a firewall is operating properly. 755 There is increasing interest in using intranets to connect different 756 parts of a organization (e.g., divisions of a company). While this 757 document generally differentiates between external and internal 758 (public and private), sites using intranets should be aware that they 759 will need to consider three separations and take appropriate actions 760 when designing and offering services. A service offered to an 761 intranet would be neither public, nor as completely private as a 762 service to a single organizational subunit. Therefore, the service 763 would need its own supporting system, separated from both external 764 and internal services and networks. 766 One form of external service deserves some special consideration, and 767 that is anonymous, or guest, access. This may be either anonymous 768 FTP or guest (unauthenticated) login. It is extremely important to 769 ensure that anonymous FTP servers and guest login userids are 770 carefully isolated from any hosts and file systems from which outside 771 users should be kept. Another area to which special attention must 772 be paid concerns anonymous, writable access. A site may be legally 773 responsible for the content of publicly available information, so 774 careful monitoring of the information deposited by anonymous users is 775 advised. 777 Now we shall consider some of the most popular services: name 778 service, password/key service, authentication/proxy service, 779 electronic mail, WWW, file transfer, and NFS. Since these are the 780 most frequently used services, they are the most obvious points of 781 attack. Also, a successful attack on one of these services can 782 produce disaster all out of proportion to the innocence of the basic 783 service. 785 3.2.3.1 Name Servers (DNS and NIS(+)) 787 The Internet uses the Domain Name System (DNS) to perform address 788 resolution for host and network names. The Network Information 789 Service (NIS) and NIS+ are not used on the global Internet, but are 790 subject to the same risks as a DNS server. Name-to-address 791 resolution is critical to the secure operation of any network. An 792 attacker who can successfully control or impersonate a DNS server can 793 re-route traffic to subvert security protections. For example, 794 routine traffic can be diverted to a compromised system to be 795 monitored; or, users can be tricked into providing authentication 796 secrets. An organization should create well known, protected sites 797 to act as secondary name servers and protect their DNS masters from 798 denial of service attacks using filtering routers. 800 Traditionally, DNS has had no security capabilities. In particular, 801 the information returned from a query could not be checked for 802 modification or verified that it had come from the name server in 803 question. Work has been done to incorporate digital signatures into 804 the protocol which, when deployed, will allow the integrity of the 805 information to be cryptographically verified (see RFC 2065). 807 3.2.3.2 Password/Key Servers (NIS(+) and KDC) 809 Password and key servers generally protect their vital information 810 (i.e., the passwords and keys) with encryption algorithms. However, 811 even a one-way encrypted password can be determined by a dictionary 812 attack (wherein common words are encrypted to see if they match the 813 stored encryption). It is therefore necessary to ensure that these 814 servers are not accessable by hosts which do not plan to use them for 815 the service, and even those hosts should only be able to access the 816 service (i.e., general services, such as Telnet and FTP, should not 817 be allowed by anyone other than administrators). 819 3.2.3.3 Authentication/Proxy Servers (SOCKS, FWTK) 821 A proxy server provides a number of security enhancements. It allows 822 sites to concentrate services through a specific host to allow 823 monitoring, hiding of internal structure, etc. This funnelling of 824 services creates an attractive target for a potential intruder. The 825 type of protection required for a proxy server depends greatly on the 826 proxy protocol in use and the services being proxied. The general 827 rule of limiting access only to those hosts which need the services, 828 and limiting access by those hosts to only those services, is a good 829 starting point. 831 3.2.3.4 Electronic Mail 833 Electronic mail (email) systems have long been a source for intruder 834 break-ins because email protocols are among the oldest and most 835 widely deployed services. Also, by it's very nature, an email server 836 requires access to the outside world; most email servers accept input 837 from any source. An email server generally consists of two parts: a 838 receiving/sending agent and a processing agent. Since email is 839 delivered to all users, and is usually private, the processing agent 840 typically requires system (root) privileges to deliver the mail. 841 Most email implementations perform both portions of the service, 842 which means the receiving agent also has system privileges. This 843 opens several security holes which this document will not describe. 844 There are some implementations available which allow a separation of 845 the two agents. Such implementations are generally considered more 846 secure, but still require careful installation to avoid creating a 847 security problem. 849 3.2.3.5 World Wide Web (WWW) 851 The Web is growing in popularity exponentially because of its ease of 852 use and the powerful ability to concentrate information services. 853 Most WWW servers accept some type of direction and action from the 854 persons accessing their services. The most common example is taking 855 a request from a remote user and passing the provided information to 856 a program running on the server to process the request. Some of 857 these programs are not written with security in mind and can create 858 security holes. If a Web server is available to the Internet 859 community, it is especially important that confidential information 860 not be co-located on the same host as that server. In fact, it is 861 recommended that the server have a dedicated host which is not 862 "trusted" by other internal hosts. 864 Many sites may want to co-locate FTP service with their WWW service. 865 But this should only occur for anon-ftp servers that only provide 866 information (ftp-get). Anon-ftp puts, in combination with WWW, might 867 be dangerous (e.g., they could result in modifications to the 868 information your site is publishing to the web) and in themselves 869 make the security considerations for each service different. 871 3.2.3.6 File Transfer (FTP, TFTP) 873 FTP and TFTP both allow users to receive and send electronic files in 874 a point-to-point manner. However, FTP requires authentication while 875 TFTP requires none. For this reason, TFTP should be avoided as much 876 as possible. 878 Improperly configured FTP servers can allow intruders to copy, 879 replace and delete files at will, anywhere on a host, so it is very 880 important to configure this service correctly. Access to encrypted 881 passwords and proprietary data, and the introduction of trojan horses 882 are just a few of the potential security holes that can occur when 883 the service is configured incorrectly. FTP servers should reside on 884 their own host. Some sites choose to co-locate FTP with a Web 885 server, since the two protocols share common security considerations 886 However, the the practice isn't recommended, especially when the FTP 887 service allows the deposit of files (see section on WWW above). As 888 mentioned in the opening paragraphs of section 3.2.3, services 889 offered internally to your site should not be co-located with 890 services offered externally. Each should have its own host. 892 TFTP does not support the same range of functions as FTP, and has no 893 security whatsoever. This service should only be considered for 894 internal use, and then it should be configured in a restricted way so 895 that the server only has access to a set of predetermined files 896 (instead of every world-readable file on the system). Probably the 897 most common usage of TFTP is for downloading router configuration 898 files to a router. TFTP should reside on its own host, and should 899 not be installed on hosts supporting external FTP or Web access. 901 3.2.3.7 NFS 903 The Network File Service allows hosts to share common disks. NFS is 904 frequently used by diskless hosts who depend on a disk server for all 905 of their storage needs. Unfortunately, NFS has no built-in security. 906 It is therefore necessary that the NFS server be accessable only by 907 those hosts which are using it for service. This is achieved by 908 specifying which hosts the file system is being exported to and in 909 what manner (e.g., read-only, read-write, etc.). Filesystems should 910 not be exported to any hosts outside the local network since this 911 will require that the NFS service be accessible externally. Ideally, 912 external access to NFS service should be stopped by a firewall. 914 3.2.4 Protecting the Protection 916 It is amazing how often a site will overlook the most obvious 917 weakness in its security by leaving the security server itself open 918 to attack. Based on considerations previously discussed, it should 919 be clear that: the security server should not be accessible from 920 off-site; should offer minimum access, except for the authentication 921 function, to users on-site; and should not be co-located with any 922 other servers. Further, all access to the node, including access to 923 the service itself, should be logged to provide a "paper trail" in 924 the event of a security breach. 926 3.3 Firewalls 928 One of the most widely deployed and publicized security measures in 929 use on the Internet is a "firewall." Firewalls have been given the 930 reputation of a general panacea for many, if not all, of the Internet 931 security issues. They are not. Firewalls are just another tool in 932 the quest for system security. They provide a certain level of 933 protection and are, in general, a way of implementing security policy 934 at the network level. The level of security that a firewall provides 935 can vary as much as the level of security on a particular machine. 936 There are the traditional trade-offs between security, ease of use, 937 cost, complexity, etc. 939 A firewall is any one of several mechanisms used to control and watch 940 access to and from a network for the purpose of protecting it. A 941 firewall acts as a gateway through which all traffic to and from the 942 protected network and/or systems passes. Firewalls help to place 943 limitations on the amount and type of communication that takes place 944 between the protected network and the another network (e.g., the 945 Internet, or another piece of the site's network). 947 A firewall is generally a way to build a wall between one part of a 948 network, a company's internal network, for example, and another part, 949 the global Internet, for example. The unique feature about this wall 950 is that there needs to be ways for some traffic with particular 951 characteristics to pass through carefully monitored doors 952 ("gateways"). The difficult part is establishing the criteria by 953 which the packets are allowed or denied access through the doors. 954 Books written on firewalls use different terminology to describe the 955 various forms of firewalls. This can be confusing to system 956 administrators who are not familiar with firewalls. The thing to note 957 here is that there is no fixed terminology for the description of 958 firewalls. 960 Firewalls are not always, or even typically, a single machine. 961 Rather, firewalls are often a combination of routers, network 962 segments, and host computers. Therefore, for the purposes of this 963 discussion, the term "firewall" can consist of more than one physical 964 device. Firewalls are typically built using two different 965 components, filtering routers and proxy servers. 967 Filtering routers are the easiest component to conceptualize in a 968 firewall. A router moves data back and forth between two (or more) 969 different networks. A "normal" router takes a packet from network A 970 and "routes" it to its destination on network B. A filtering router 971 does the same thing but decides not only how to route the packet, but 972 whether it should route the packet. This is done by installing a 973 series of filters by which the router decides what to do with any 974 given packet of data. 976 A discussion concerning capabilities of a particular brand of router, 977 running a particular software version is outside the scope of this 978 document. However, when evaluating a router to be used for filtering 979 packets, the following criteria can be important when implementing a 980 filtering policy: source and destination IP address, source and 981 destination TCP port numbers, state of the TCP "ack" bit, UDP source 982 and destination port numbers, and direction of packet flow (i.e.. A- 983 >B or B->A). Other information necessary to construct a secure 984 filtering scheme are whether the router reorders filter instructions 985 (designed to optimize filters, this can sometimes change the meaning 986 and cause unintended access), and whether it is possible to apply 987 filters for inbound and outbound packets on each interface (if the 988 router filters only outbound packets then the router is "outside" of 989 its filters and may be more vulnerable to attack). In addition to 990 the router being vulnerable, this distinction between applying 991 filters on inbound or outbound packets is especially relevant for 992 routers with more than 2 interfaces. Other important issues are the 993 ability to create filters based on IP header options and the fragment 994 state of a packet. Building a good filter can be very difficult and 995 requires a good understanding of the type of services (protocols) 996 that will be filtered. 998 For better security, the filters usually restrict access between the 999 two connected nets to just one host, the bastion host. It is only 1000 possible to access the other network via this bastion host. As only 1001 this host, rather than a few hundred hosts, can get attacked, it is 1002 easier to maintain a certain level of security because only this host 1003 has to be protected very carefully. To make resources available to 1004 legitimate users across this firewall, services have to be forwarded 1005 by the bastion host. Some servers have forwarding built in (like 1006 DNS-servers or SMTP-servers), for other services (e.g., Telnet, FTP, 1007 etc.), proxy servers can be used to allow access to the resources 1008 across the firewall in a secure way. 1010 A proxy server is way to concentrate application services through a 1011 single machine. There is typically a single machine (the bastion 1012 host) that acts as a proxy server for a variety of protocols (Telnet, 1013 SMTP, FTP, HTTP, etc.) but there can be individual host computers for 1014 each service. Instead of connecting directly to an external server, 1015 the client connects to the proxy server which in turn initiates a 1016 connection to the requested external server. Depending on the type 1017 of proxy server used, it is possible to configure internal clients to 1018 perform this redirection automatically, without knowledge to the 1019 user, others might require that the user connect directly to the 1020 proxy server and then initiate the connection through a specified 1021 format. 1023 There are significant security benefits which can be derived from 1024 using proxy servers. It is possible to add access control lists to 1025 protocols, requiring users or systems to provide some level of 1026 authentication before access is granted. Smarter proxy servers, 1027 sometimes called Application Layer Gateways (ALGs), can be written 1028 which understand specific protocols and can be configured to block 1029 only subsections of the protocol. For example, an ALG for FTP can 1030 tell the difference between the "put" command and the "get" command; 1031 an organization may wish to allow users to "get" files from the 1032 Internet, but not be able to "put" internal files on a remote server. 1033 By contrast, a filtering router could either block all FTP access, or 1034 none, but not a subset. 1036 Proxy servers can also be configured to encrypt data streams based on 1037 a variety of parameters. An organization might use this feature to 1038 allow encrypted connections between two locations whose sole access 1039 points are on the Internet. 1041 Firewalls are typically thought of as a way to keep intruders out, 1042 but they are also often used as a way to let legitimate users into a 1043 site. There are many examples where a valid user might need to 1044 regularly access the "home" site while on travel to trade shows and 1045 conferences, etc. Access to the Internet is often available but may 1046 be through an untrusted machine or network. A correctly configured 1047 proxy server can allow the correct users into the site while still 1048 denying access to other users. 1050 The current best effort in firewall techniques is found using a 1051 combination of a pair of screening routers with one or more proxy 1052 servers on a network between the two routers. This setup allows the 1053 external router to block off any attempts to use the underlying IP 1054 layer to break security (IP spoofing, source routing, packet 1055 fragments), while allowing the proxy server to handle potential 1056 security holes in the higher layer protocols. The internal router's 1057 purpose is to block all traffic except to the proxy server. If this 1058 setup is rigidly implemented, a high level of security can be 1059 achieved. 1061 Most firewalls provide logging which can be tuned to make security 1062 administration of the network more convenient. Logging may be 1063 centralized and the system may be configured to send out alerts for 1064 abnormal conditions. It is important to regularly monitor these logs 1065 for any signs of intrusions or break-in attempts. Since some 1066 intruders will attempt to cover their tracks by editing logs, it is 1067 desirable to protect these logs. A variety of methods is available, 1068 including: write once, read many (WORM) drives; papers logs; and 1069 centralized logging via the "syslog" utility. Another technique is 1070 to use a "fake" serial printer, but have the serial port connected to 1071 an isolated machine or PC which keeps the logs. 1073 Firewalls are available in a wide range of quality and strengths. 1074 Commercial packages start at approximately $10,000US and go up to 1075 over $250,000US. "Home grown" firewalls can be built for smaller 1076 amounts of capital. It should be remembered that the correct setup 1077 of a firewall (commercial or homegrown) requires a significant amount 1078 of skill and knowledge of TCP/IP. Both types require regular 1079 maintenance, installation of software patches and updates, and 1080 regular monitoring. When budgeting for a firewall, these additional 1081 costs should be considered in addition to the cost of the physical 1082 elements of the firewall. 1084 As an aside, building a "home grown" firewall requires a significant 1085 amount of skill and knowledge of TCP/IP. It should not be trivially 1086 attempted because a perceived sense of security is worse in the long 1087 run than knowing that there is no security. As with all security 1088 measures, it is important to decide on the threat, the value of the 1089 assets to be protected, and the costs to implement security. 1091 A final note about firewalls. They can be a great aid when 1092 implementing security for a site and they protect against a large 1093 variety of attacks. But it is important to keep in mind that they 1094 are only one part of the solution. They cannot protect your site 1095 against all types of attack. 1097 4. Security Services and Procedures 1099 This chapter guides the reader through a number of topics that should 1100 be addressed when securing a site. Each section touches on a 1101 security service or capability that may be required to protect the 1102 information and systems at a site. The topics are presented at a 1103 fairly high-level to introduce the reader to the concepts. 1105 Throughout the chapter, you will find significant mention of 1106 cryptography. It is outside the scope of this document to delve into 1107 details concerning cryptography, but the interested reader can obtain 1108 more information from books and articles listed in the reference 1109 section of this document. 1111 4.1 Authentication 1113 For many years, the prescribed method for authenticating users has 1114 been through the use of standard, reusable passwords. Originally, 1115 these passwords were used by users at terminals to authenticate 1116 themselves to a central computer. At the time, there were no 1117 networks (internally or externally), so the risk of disclosure of the 1118 clear text password was minimal. Today, systems are connected 1119 together through local networks, and these local networks are further 1120 connected together and to the Internet. Users are logging in from 1121 all over the globe; their reusable passwords are often transmitted 1122 across those same networks in clear text, ripe for anyone in-between 1123 to capture. And indeed, the CERT Coordination Center and other 1124 response teams are seeing a tremendous number of incidents involving 1125 packet sniffers which are capturing the clear text passwords. 1127 With the advent of newer technologies like one-time passwords (e.g., 1128 S/Key), PGP, and token-based authentication devices, people are using 1129 password-like strings as secret tokens and pins. If these secret 1130 tokens and pins are not properly selected and protected, the 1131 authentication will be easily subverted. 1133 4.1.1 One-Time passwords 1135 As mentioned above, given today's networked environments, it is 1136 recommended that sites concerned about the security and integrity of 1137 their systems and networks consider moving away from standard, 1138 reusable passwords. There have been many incidents involving Trojan 1139 network programs (e.g., telnet and rlogin) and network packet 1140 sniffing programs. These programs capture clear text 1141 hostname/account name/password triplets. Intruders can use the 1142 captured information for subsequent access to those hosts and 1143 accounts. This is possible because 1) the password is used over and 1144 over (hence the term "reusable"), and 2) the password passes across 1145 the network in clear text. 1147 Several authentication techniques have been developed that address 1148 this problem. Among these techniques are challenge-response 1149 technologies that provide passwords that are only used once (commonly 1150 called one-time passwords). There are a number of products available 1151 that sites should consider using. The decision to use a product is 1152 the responsibility of each organization, and each organization should 1153 perform its own evaluation and selection. 1155 4.1.2 Kerberos 1157 Kerberos is a distributed network security system which provides for 1158 authentication across unsecured networks. If requested by the 1159 application, integrity and encryption can also be provided. Kerberos 1160 was originally developed at the Massachusetts Institute of Technology 1161 (MIT) in the mid 1980's. There are two major releases of Kerberos, 1162 version 4 and 5, which are for practical purposes, incompatible. 1164 Kerberos relies on a symmetric key database using a key distribution 1165 center (KDC) which is known as the Kerberos server. A user or 1166 service (known as "principals") are granted electronic "tickets" 1167 after properly communicating with the KDC. These tickets are used 1168 for authentication between principals. All tickets include a time 1169 stamp which limits the time period for which the ticket is valid. 1170 Therefore, Kerberos clients and server must have a secure time 1171 source, and be able to keep time accurately. 1173 The practical side of Kerberos is its integration with the 1174 application level. Typical applications like FTP, telnet, POP, and 1175 NFS have been integrated with the Kerberos system. There are a 1176 variety of implementations which have varying levels of integration. 1177 Please see the Kerberos FAQ available at http://www.ov.com/misc/krb- 1178 faq.html for the latest information. 1180 4.1.3 Choosing and Protecting Secret Tokens and PINs 1182 When selecting secret tokens, take care to choose them carefully. 1183 Like the selection of passwords, they should be robust against brute 1184 force efforts to guess them. That is, they should not be single 1185 words in any language, any common, industry, or cultural acronyms, 1186 etc. Ideally, they will be longer rather than shorter and consist of 1187 pass phrases that combine upper and lower case character, digits, and 1188 other characters. 1190 Once chosen, the protection of these secret tokens is very important. 1191 Some are used as pins to hardware devices (like token cards) and 1192 these should not be written down or placed in the same location as 1193 the device with which they are associated. Others, such as a secret 1194 Pretty Good Privacy (PGP) key, should be protected from unauthorized 1195 access. 1197 One final word on this subject. When using cryptography products, 1198 like PGP, take care to determine the proper key length and ensure 1199 that your users are trained to do likewise. As technology advances, 1200 the minimum safe key length continues to grow. Make sure your site 1201 keeps up with the latest knowledge on the technology so that you can 1202 ensure that any cryptography in use is providing the protection you 1203 believe it is. 1205 4.1.4 Password Assurance 1207 While the need to eliminate the use of standard, reusable passwords 1208 cannot be overstated, it is recognized that some organizations may 1209 still be using them. While it's recommended that these organizations 1210 transition to the use of better technology, in the mean time, we have 1211 the following advice to help with the selection and maintenance of 1212 traditional passwords. But remember, none of these measures provides 1213 protection against disclosure due to sniffer programs. 1215 (1) The importance of robust passwords - In many (if not most) cases of 1216 system penetration, the intruder needs to gain access to an account 1217 on the system. One way that goal is typically accomplished is 1218 through guessing the password of a legitimate user. This is often 1219 accomplished by running an automated password cracking program, 1220 which utilizes a very large dictionary, against the system's password 1221 file. The only way to guard against passwords being disclosed in this 1222 manner is through the careful selection of passwords which cannot be 1223 easily guessed (i.e., combinations of numbers, letters, and punctuation 1224 characters). Passwords should also be as long as the system supports 1225 and users can tolerate. 1227 (2) Changing default passwords - Many operating systems and application 1228 programs are installed with default accounts and passwords. These 1229 must be changed immediately to something that cannot be guessed or 1230 cracked. 1232 (3) Restricting access to the password file - In particular, a site 1233 wants to protect the encrypted password portion of the file so that 1234 would-be intruders don't have them available for cracking. One 1235 effective technique is to use shadow passwords where the password 1236 field of the standard file contains a dummy or false password. The 1237 file containing the legitimate passwords are protected elsewhere on 1238 the system. 1240 (4) Password aging - When and how to expire passwords is still a subject 1241 of controversy among the security community. It is generally accepted 1242 that a password should not be maintained once an account is no longer in 1243 use, but it is hotly debated whether a user should be forced to change a 1244 good password that's in active use. The arguments for changing 1245 passwords relate to the prevention of the continued use of penetrated 1246 accounts. However, the opposition claims that frequent password 1247 changes lead to users writing down their passwords in visible areas 1248 (such as pasting them to a terminal), or to users selecting very simple 1249 passwords that are easy to guess. It should also be stated that an 1250 intruder will probably use a captured or guessed password sooner rather 1251 than later, in which case password aging provides little if any 1252 protection. 1254 While there is no definitive answer to this dilemma, a password policy 1255 should directly address the issue and provide guidelines for how often 1256 a user should change the password. Certainly, an annual change in 1257 their password is usually not difficult for most users, and you 1258 should consider requiring it. It is recommended that passwords 1259 be changed at least whenever a privileged account is compromised, 1260 there is a critical change in personnel (especially if it is an 1261 administrator!), or when an account has been compromised. In 1262 addition, if a privileged account password is compromised, 1263 all passwords on the system should be changed. 1265 4.2 Confidentiality 1267 There will be information assets that your site will want to protect 1268 from disclosure to unauthorized entities. Operating systems often 1269 have built-in file protection mechanisms that allow an administrator 1270 to control who on the system can access, or "see," the contents of a 1271 given file. A stronger way to provide confidentiality is through 1272 encryption. Encryption is accomplished by scrambling data so that it 1273 is very difficult and time consuming for anyone other than the 1274 authorized recipients or owners to obtain the plain text. Authorized 1275 recipients and the owner of the information will possess the 1276 corresponding decryption keys that allow them to easily unscramble 1277 the text to a readable (clear text) form. We recommend that sites 1278 use encryption to provide confidentiality and protect valuable 1279 information. 1281 The use of encryption is sometimes controlled by governmental and 1282 site regulations, so we encourage administrators to become informed 1283 of laws or policies that regulate its use before employing it. It is 1284 outside the scope of this document to discuss the various algorithms 1285 and programs available for this purpose, but we do caution against 1286 the casual use of the UNIX crypt program as it has been found to be 1287 easily broken. We also encourage everyone to take time to understand 1288 the strength of the encryption in any given algorithm/product before 1289 using it. Most well-known products are well-documented in the 1290 literature, so this should be a fairly easy task. 1292 4.3 Integrity 1294 As an administrator, you will want to make sure that information 1295 (e.g., operating system files, company data, etc.) has not been 1296 altered in an unauthorized fashion. This means you will want to 1297 provide some assurance as to the integrity of the information on your 1298 systems. One way to provide this is to produce a checksum of the 1299 unaltered file, store that checksum offline, and periodically (or 1300 when desired) check to make sure the checksum of the online file 1301 hasn't changed (which would indicate the data has been modified). 1303 Some operating systems come with checksumming programs, such as the 1304 UNIX sum program. However, these may not provide the protection you 1305 actually need. Files can be modified in such a way as to preserve 1306 the result of the UNIX sum program! Therefore, we suggest that you 1307 use a cryptographically strong program, such as the message digesting 1308 program MD5 [ref], to produce the checksums you will be using to 1309 assure integrity. 1311 There are other applications where integrity will need to be assured, 1312 such as when transmitting an email message between two parties. There 1313 are products available that can provide this capability. Once you 1314 identify that this is a capability you need, you can go about 1315 identifying technologies that will provide it. 1317 4.4 Authorization 1319 Authorization refers to the process of granting privileges to 1320 processes and, ultimately, users. This differs from authentication 1321 in that authentication is the process used to identify a user. Once 1322 identified (reliably), the privileges, rights, property, and 1323 permissible actions of the user are determined by authorization. 1325 Explicitly listing the authorized activities of each user (and user 1326 process) with respect to all resources (objects) is impossible in a 1327 reasonable system. In a real system certain techniques are used to 1328 simplify the process of granting and checking authorization(s). 1330 One approach, popularized in UNIX systems, is to assign to each 1331 object three classes of user: owner, group and world. The owner is 1332 either the creator of the object or the user assigned as owner by the 1333 super-user. The owner permissions (read, write and execute) apply 1334 only to the owner. A group is a collection of users which share 1335 access rights to an object. The group permissions (read, write and 1336 execute) apply to all users in the group (except the owner). The 1337 world refers to everybody else with access to the system. The world 1338 permissions (read, write and execute) apply to all users (except the 1339 owner and members of the group). 1341 Another approach is to attach to an object a list which explicitly 1342 contains the identity of all permitted users (or groups). This is an 1343 Access Control List (ACL). The advantage of ACLs are that they are 1344 easily maintained (one central list per object) and it's very easy to 1345 visually check who has access to what. The disadvantages are the 1346 extra resources required to store such lists, as well as the vast 1347 number of such lists required for large systems. 1349 4.5 Access 1351 4.5.1 Physical Access 1353 Restrict physical access to hosts, allowing access only to those 1354 people who are supposed to use the hosts. Hosts include "trusted" 1355 terminals (i.e., terminals which allow unauthenticated use such as 1356 system consoles, operator terminals and terminals dedicated to 1357 special tasks), and individual microcomputers and workstations, 1358 especially those connected to your network. Make sure people's work 1359 areas mesh well with access restrictions; otherwise they will find 1360 ways to circumvent your physical security (e.g., jamming doors open). 1362 Keep original and backup copies of data and programs safe. Apart 1363 from keeping them in good condition for backup purposes, they must be 1364 protected from theft. It is important to keep backups in a separate 1365 location from the originals, not only for damage considerations, but 1366 also to guard against thefts. 1368 Portable hosts are a particular risk. Make sure it won't cause 1369 problems if one of your staff's portable computer is stolen. 1370 Consider developing guidelines for the kinds of data that should be 1371 allowed to reside on the disks of portable computers as well as how 1372 the data should be protected (e.g., encryption) when it is on a 1373 portable computer. 1375 Other areas where physical access should be restricted is the wiring 1376 closets and important network elements like file servers, name server 1377 hosts, and routers. 1379 4.5.2 Walk-up Network Connections 1381 By "walk-up" connections, we mean network connection points located 1382 to provide a convenient way for users to connect a portable host to 1383 your network. 1385 Consider whether you need to provide this service, bearing in mind 1386 that it allows any user to attach an unauthorized host to your 1387 network. This increases the risk of attacks via techniques such as 1388 IP address spoofing, packet sniffing, etc. Users and site management 1389 must appreciate the risks involved. If you decide to provide walk-up 1390 connections, plan the service carefully and define precisely where 1391 you will provide it so that you can ensure the necessary physical 1392 access security. 1394 A walk-up host should be authenticated before its user is permitted 1395 to access resources on your network. As an alternative, it may be 1396 possible to control physical access. For example, if the service is 1397 to be used by students, you might only provide walk-up connection 1398 sockets in student laboratories. 1400 If you are providing walk-up access for visitors to connect back to 1401 their home networks (e.g., to read e-mail, etc.) in your facility, 1402 consider using a separate subnet that has no connectivity to the 1403 internal network. 1405 Keep an eye on any area that contains unmonitored access to the 1406 network, such as vacant offices. It may be sensible to disconnect 1407 such areas at the wiring closet, and consider using secure hubs and 1408 monitoring attempts to connect unauthorized hosts. 1410 4.5.3 Other Network Technologies 1412 Technologies considered here include X.25, ISDN, SMDS, DDS and Frame 1413 Relay. All are provided via physical links which go through 1414 telephone exchanges, providing the potential for them to be diverted. 1415 Crackers are certainly interested in telephone switches as well as in 1416 data networks! 1418 With switched technologies, use Permanent Virtual Circuits or Closed 1419 User Groups whenever this is possible. Technologies which provide 1420 authentication and/or encryption (such as IPv6) are evolving rapidly; 1421 consider using them on links where security is important. 1423 4.5.4 Modems 1425 4.5.4.1 Modem Lines Must Be Managed 1427 Although they provide convenient access to a site for its users, they 1428 can also provide an effective detour around the site's firewalls. 1429 For this reason it is essential to maintain proper control of modems. 1431 Don't allow users to install a modem line without proper 1432 authorization. This includes temporary installations (e.g., plugging 1433 a modem into a facsimile or telephone line overnight). 1435 Maintain a register of all your modem lines and keep your register up 1436 to date. Conduct regular (ideally automated) site checks for 1437 unauthorized modems. 1439 4.5.4.2 Dial-in Users Must Be Authenticated 1441 A username and password check should be completed before a user can 1442 access anything on your network. Normal password security 1443 considerations are particularly important (see section 4.1.1). 1445 Remember that telephone lines can be tapped, and that it is quite 1446 easy to intercept messages to cellular phones. Modern high-speed 1447 modems use more sophisticated modulation techniques, which makes them 1448 somewhat more difficult to monitor, but it is prudent to assume that 1449 hackers know how to eavesdrop on your lines. For this reason, you 1450 should use one-time passwords if at all possible. 1452 It is helpful to have a single dial-in point (e.g., a single large 1453 modem pool) so that all users are authenticated in the same way. 1455 Users will occasionally mis-type a password. Set a short delay - say 1456 two seconds - after the first and second failed logins, and force a 1457 disconnect after the third. This will slow down automated password 1458 attacks. Don't tell the user whether the username, the password, or 1459 both, were incorrect. 1461 4.5.4.3 Call-back Capability 1463 Some dial-in servers offer call-back facilities (i.e., the user dials 1464 in and is authenticated, then the system disconnects the call and 1465 calls back on a specified number). Call-back is useful since if 1466 someone were to guess a username and password, they are disconnected, 1467 and the system then calls back the actual user whose password was 1468 cracked; random calls from a server are suspicious, at best. This 1469 does mean users may only log in from one location (where the server 1470 is configured to dial them back), and of course there may be phone 1471 charges associated with there call-back location. 1473 This feature should be used with caution; it can easily be bypassed. 1474 At a minimum, make sure that the return call is never made from the 1475 same modem as the incoming one. Overall, although call-back can 1476 improve modem security, you should not depend on it alone. 1478 4.5.4.4 All Logins Should Be Logged 1480 All logins, whether successful or unsuccessful should be logged. 1481 However, do not keep correct passwords in the log. Rather, log them 1482 simply as a successful login attempt. Since most bad passwords are 1483 mistyped by authorized users, they only vary by a single character 1484 from the actual password. Therefore if you can't keep such a log 1485 secure, don't log it at all. 1487 If Calling Line Identification is available, take advantage of it by 1488 recording the calling number for each login attempt. Be sensitive to 1489 the privacy issues raised by Calling Line Identification. Also be 1490 aware that Calling Line Identification is not to be trusted (since 1491 intruders have been known to break into phone switches and forward 1492 phone numbers or make other changes); use the data for informational 1493 purposes only, not for authentication. 1495 4.5.4.5 Choose Your Opening Banner Carefully 1497 Many sites use a system default contained in a message of the day 1498 file for their opening banner. Unfortunately, this often includes the 1499 type of host hardware or operating system present on the host. This 1500 can provide valuable information to a would-be intruder. Instead, 1501 each site should create its own specific login banner, taking care to 1502 only include necessary information. 1504 Display a short banner, but don't offer an "inviting" name (e.g., 1505 University of XYZ, Student Records System). Instead, give your site 1506 name, a short warning that sessions may be monitored, and a 1507 username/password prompt. Verify possible legal issues related to 1508 the text you put into the banner. 1510 For high-security applications, consider using a "blind" password 1511 (i.e., give no response to an incoming call until the user has typed 1512 in a password). This effectively simulates a dead modem. 1514 4.5.4.6 Dial-out Authentication 1516 Dial-out users should also be authenticated, particularly since your 1517 site will have to pay their telephone charges. 1519 Never allow dial-out from an unauthenticated dial-in call, and 1520 consider whether you will allow it from an authenticated one. The 1521 goal here is to prevent callers using your modem pool as part of a 1522 chain of logins. This can be hard to detect, particularly if a 1523 hacker sets up a path through several hosts on your site. 1525 At a minimum, don't allow the same modems and phone lines to be used 1526 for both dial-in and dial-out. This can be implemented easily if you 1527 run separate dial-in and dial-out modem pools. 1529 4.5.4.7 Make Your Modem Programming as "Bullet-proof" as Possible 1531 Be sure modems can't be reprogrammed while they're in service. At a 1532 minimum, make sure that three plus signs won't put your dial-in 1533 modems into command mode! 1535 Program your modems to reset to your standard configuration at the 1536 start of each new call. Failing this, make them reset at the end of 1537 each call. This precaution will protect you against accidental 1538 reprogramming of your modems. Resetting at both the end and the 1539 beginning of each call will assure an even higher level of confidence 1540 that a new caller will not inherit a previous caller's session. 1542 Check that your modems terminate calls cleanly. When a user logs out 1543 from an access server, verify that the server hangs up the phone line 1544 properly. It is equally important that the server forces logouts 1545 from whatever sessions were active if the user hangs up unexpectedly. 1547 4.6 Auditing 1549 This section covers the procedures for collecting data generated by 1550 network activity, which may be useful in analyzing the security of a 1551 network and responding to security incidents. 1553 4.6.1 What to Collect 1555 Audit data should include any attempt to achieve a different security 1556 level by any person, process, or other entity in the network. This 1557 includes login and logout, super user access (or the non-UNIX 1558 equivalent), ticket generation (for Kerberos, for example), and any 1559 other change of access or status. It is especially important to note 1560 "anonymous" or "guest" access to public servers. 1562 The actual data to collect will differ for different sites and for 1563 different types of access changes within a site. In general, the 1564 information you want to collect includes: username and hostname, for 1565 login and logout; previous and new access rights, for a change of 1566 access rights; and a timestamp. Of course, there is much more 1567 information which might be gathered, depending on what the system 1568 makes available and how much space is available to store that 1569 information. 1571 One very important note: do not gather passwords. This creates an 1572 enormous potential security breach if the audit records should be 1573 improperly accessed. Do not gather incorrect passwords either, as 1574 they often differ from valid passwords by only a single character or 1575 transposition. 1577 4.6.2 Collection Process 1579 The collection process should be enacted by the host or resource 1580 being accessed. Depending on the importance of the data and the need 1581 to have it local in instances in which services are being denied, 1582 data could be kept local to the resource until needed or be 1583 transmitted to storage after each event. 1585 There are basically three ways to store audit records: in a 1586 read/write file on a host, on a write-once/read-many device (e.g., a 1587 CD-ROM or a specially configured tape drive), or on a write-only 1588 device (e.g., a line printer). Each method has advantages and 1589 disadvantages. 1591 File system logging is the least resource intensive of the three 1592 methods and the easiest to configure. It allows instant access to 1593 the records for analysis, which may be important if an attack is in 1594 progress. File system logging is also the least reliable method. If 1595 the logging host has been compromised, the file system is usually the 1596 first thing to go; an intruder could easily cover up traces of the 1597 intrusion. 1599 Collecting audit data on a write-once device is slightly more effort 1600 to configure than a simple file, but it has the significant advantage 1601 of greatly increased security because an intruder could not alter the 1602 data showing that an intrusion has occurred. The disadvantage of 1603 this method is the need to maintain a supply of storage media and the 1604 cost of that media. Also, the data may not be instantly available. 1606 Line printer logging is useful in system where permanent and 1607 immediate logs are required. A real time system is an example of 1608 this, where the exact point of a failure or attack must be recorded. 1609 A laser printer, or other device which buffers data (e.g., a print 1610 server), may suffer from lost data if buffers contain the needed data 1611 at a critical instant. The disadvantage of, literally, "paper 1612 trails" is the need to keep the printer fed and the need to scan 1613 records by hand. There is also the issue of where to store the, 1614 potentially, enormous volume of paper which may be generated. 1616 For each of the logging methods described, there is also the issue of 1617 securing the path between the device generating the log and actual 1618 logging device (i.e., the file server, tape/CD-ROM drive, printer). 1620 If that path is compromised, logging can be stopped or spoofed or 1621 both. In an ideal world, the logging device would be directly 1622 attached by a single, simple, point-to-point cable. Since that is 1623 usually impractical, the path should pass through the minimum number 1624 of networks and routers. Even if logs can be blocked, spoofing can 1625 be prevented with cryptographic checksums (it probably isn't 1626 necessary to encrypt the logs because they should not contain 1627 sensitive information in the first place). 1629 4.6.3 Collection Load 1631 Collecting audit data may result in a rapid accumulation of bytes so 1632 storage availability for this information must be considered in 1633 advance. There are a few ways to reduce the required storage space. 1634 First, data can be compressed, using one of many methods. Or, the 1635 required space can be minimized by keeping data for a shorter period 1636 of time with only summaries of that data kept in long-term archives. 1637 One major drawback to the latter method involves incident response. 1638 Often, an incident has been ongoing for some period of time when a 1639 site notices it and begins to investigate. At that point in time, 1640 it's very helpful to have detailed audit logs available. If these are 1641 just summaries, there may not be sufficient detail to fully handle 1642 the incident. 1644 4.6.4 Handling and Preserving Audit Data 1646 Audit data should be some of the most carefully secured data at the 1647 site and in the backups. If an intruder were to gain access to audit 1648 logs, the systems themselves, in addition to the data, would be at 1649 risk. 1651 Audit data may also become key to the investigation, apprehension, 1652 and prosecution of the perpetrator of an incident. For this reason, 1653 it is advisable to seek the advice of legal council when deciding how 1654 audit data should be treated. This should happen before an incident 1655 occurs. 1657 If a data handling plan is not adequately defined prior to an 1658 incident, it may mean that there is no recourse in the aftermath of 1659 an event, and it may create liability resulting from improper 1660 treatment of the data. 1662 4.6.5 Legal Considerations 1664 Due to the content of audit data, there are a number of legal 1665 questions that arise which might need to be addressed by your legal 1666 counsel. If you collect and save audit data, you need to be prepared 1667 for consequences resulting both from its existence and its content. 1669 One area concerns the privacy of individuals. In certain instances, 1670 audit data may contain personal information. Searching through the 1671 data, even for a routine check of the system's security, could 1672 represent an invasion of privacy. 1674 A second area of concern involves knowledge of intrusive behavior 1675 originating from your site. If an organization keeps audit data, is 1676 it responsible for examining it to search for incidents? If a host 1677 in one organization is used as a launching point for an attack 1678 against another organization, can the second organization use the 1679 audit data of the first organization to prove negligence on the part 1680 of that organization? 1682 The above examples are meant to be comprehensive, but should motivate 1683 your organization to consider the legal issues involved with audit 1684 data. 1686 4.7 Securing Backups 1688 The procedure of creating backups is a classic part of operating a 1689 computer system. Within the context of this document, backups are 1690 addressed as part of the overall security plan of a site. There are 1691 several aspects to backups that are important within this context: 1693 (1) Make sure your site is creating backups 1694 (2) Make sure your site is using offsite storage for backups. The 1695 storage site should be carefully selected for both its security and 1696 its availability. 1697 (3) Consider encrypting your backups to provide additional protection of 1698 the information once it is off-site. However, be aware that you will 1699 need a good key management scheme so that you'll be able to recover 1700 data at any point in the future. Also, make sure you will have 1701 access to the necessary decryption programs at such time in the 1702 future as you need to perform the decryption. 1703 (4) Don't always assume that your backups are good. There have been 1704 many instances of computer security incidents that have gone on for 1705 long periods of time before a site has noticed the incident. In such 1706 cases, backups of the affected systems are also tainted. 1707 (5) Periodically verify the correctness and completeness of your 1708 backups. 1710 5. Security Incident Handling 1712 This chapter of the document will supply guidance to be used before, 1713 during, and after a computer security incident occurs on a host, 1714 network, site, or multi-site environment. The operative philosophy 1715 in the event of a breach of computer security is to react according 1716 to a plan. This is true whether the breach is the result of an 1717 external intruder attack, unintentional damage, a student testing 1718 some new program to exploit a software vulnerability, or a 1719 disgruntled employee. Each of the possible types of events, such as 1720 those just listed, should be addressed in advance by adequate 1721 contingency plans. 1723 Traditional computer security, while quite important in the overall 1724 site security plan, usually pays little attention to how to actually 1725 handle an attack once one occurs. The result is that when an attack 1726 is in progress, many decisions are made in haste and can be damaging 1727 to tracking down the source of the incident, collecting evidence to 1728 be used in prosecution efforts, preparing for the recovery of the 1729 system, and protecting the valuable data contained on the system. 1731 One of the most important, but often overlooked, benefits for 1732 efficient incident handling is an economic one. Having both 1733 technical and managerial personnel respond to an incident requires 1734 considerable resources. If trained to handle incidents efficiently, 1735 less staff time is required when one occurs. 1737 Due to the world-wide network most incidents are not restricted to a 1738 single site. Operating systems vulnerabilities apply (in some cases) 1739 to several millions of systems, and many vulnerabilities are 1740 exploited within the network itself. Therefore, it is vital that all 1741 sites with involved parties be informed as soon as possible. 1743 Another benefit is related to public relations. News about computer 1744 security incidents tends to be damaging to an organization's stature 1745 among current or potential clients. Efficient incident handling 1746 minimizes the potential for negative exposure. 1748 A final benefit of efficient incident handling is related to legal 1749 issues. It is possible that in the near future organizations may be 1750 held responsible because one of their nodes was used to launch a 1751 network attack. In a similar vein, people who develop patches or 1752 workarounds may be sued if the patches or workarounds are 1753 ineffective, resulting in compromise of the systems, or, if the 1754 patches or workarounds themselves damage systems. Knowing about 1755 operating system vulnerabilities and patterns of attacks, and then 1756 taking appropriate measures to counter these potential threats, is 1757 critical to circumventing possible legal problems. 1759 The sections in this chapter provide an outline and starting point 1760 for creating your site's policy for handling security incidents. The 1761 sections are: 1763 (1) Preparing and planning (what are the goals and objectives in 1764 handling an incident). 1765 (2) Notification (who should be contacted in the case of an incident). 1766 - Local managers and personnel 1767 - Law enforcement and investigative agencies 1768 - Computer security incidents handling teams 1769 - Affected and involved sites 1770 - Internal communications 1771 - Public relations and press releases 1772 (3) Identifying an incident (is it an incident and how serious is it). 1773 (4) Handling (what should be done when an incident occurs). 1774 - Notification (who should be notified about the incident) 1775 - Protecting evidence and activity logs (what records should be 1776 kept from before, during, and after the incident) 1777 - Containment (how can the damage be limited) 1778 - Eradication (how to eliminate the reasons for the incident) 1779 - Recovery (how to reestablish service and systems) 1780 - Follow Up (what actions should be taken after the incident) 1781 (5) Aftermath (what are the implications of past incidents). 1783 (6) Administrative response to incidents. 1785 The remainder of this chapter will detail the issues involved in each 1786 of the important topics listed above, and provide some guidance as to 1787 what should be included in a site policy for handling incidents. 1789 5.1 Preparing and Planning for Incident Handling 1791 Part of handling an incident is being prepared to respond to an 1792 incident before the incident occurs in the first place. This 1793 includes establishing a suitable level of protections as explained in 1794 the preceding chapters. Doing this should help your site prevent 1795 incidents as well as limit potential damage resulting from them when 1796 they do occur. Protection also includes preparing incident handling 1797 guidelines as part of a contingency plan for your organization or 1798 site. Having written plans eliminates much of the ambiguity which 1799 occurs during an incident, and will lead to a more appropriate and 1800 thorough set of responses. It is vitally important to test the 1801 proposed plan before an incident occurs through "dry runs". A team 1802 might even consider hiring a tiger team to act in parallel with the 1803 dry run. (Note: a tiger team is a team of specialists that try to 1804 penetrate the security of a system.) 1806 Learning to respond efficiently to an incident is important for a 1807 number of reasons: 1809 (1) Protecting the assets which could be compromised 1810 (2) Protecting resources which could be utilized more 1811 profitably if an incident did not require their services 1812 (3) Complying with (government or other) regulations 1813 (4) Preventing the use of your systems in attacks against other 1814 systems (which could cause you to incur legal liability) 1815 (5) Minimizing the potential for negative exposure 1817 As in any set of pre-planned procedures, attention must be paid to a 1818 set of goals for handling an incident. These goals will be 1819 prioritized differently depending on the site. A specific set of 1820 objectives can be identified for dealing with incidents: 1822 (1) Figure out how it happened. 1823 (2) Find out how to avoid further exploitation of the same 1824 vulnerability. 1825 (3) Avoid escalation and further incidents. 1826 (4) Assess the impact and damage of the incident. 1827 (5) Recover from the incident. 1828 (6) Update policies and procedures as needed. 1829 (5) Find out who did it (if appropriate and possible). 1831 Due to the nature of the incident, there might be a conflict between 1832 analyzing the original source of a problem and restoring systems and 1833 services. Overall goals (like assuring the integrity of critical 1834 systems) might be the reason for not analyzing an incident. Of 1835 course, this is an important management decision; but all involved 1836 parties must be aware that without analysis the same incident may 1837 happen again. 1839 It is also important to prioritize the actions to be taken during an 1840 incident well in advance of the time an incident occurs. Sometimes 1841 an incident may be so complex that it is impossible to do everything 1842 at once to respond to it; priorities are essential. Although 1843 priorities will vary from institution to institution, the following 1844 suggested priorities may serve as a starting point for defining your 1845 organization's response: 1847 (1) Priority one -- protect human life and people's 1848 safety; human life always has precedence over all 1849 other considerations. 1851 (2) Priority two -- protect classified and/or sensitive 1852 data. Prevent exploitation of classified and/or 1853 sensitive systems, networks or sites. Inform affected 1854 classified and/or sensitive systems, networks or sites 1855 about already occurred penetrations. 1856 (Be aware of regulations by your site or by government) 1858 (3) Priority three -- protect other data, including 1859 proprietary, scientific, managerial and other data, 1860 because loss of data is costly in terms of resources. 1861 Prevent exploitations of other systems, networks or 1862 sites and inform already affected systems, networks or 1863 sites about successful penetrations. 1865 (4) Priority four -- prevent damage to systems (e.g., loss 1866 or alteration of system files, damage to disk drives, 1867 etc.). Damage to systems can result in costly down 1868 time and recovery. 1870 (5) Priority five -- minimize disruption of computing 1871 resources (including processes). It is better in many 1872 cases to shut a system down or disconnect from a network 1873 than to risk damage to data or systems. Sites will have 1874 to evaluate the trade-offs between shutting down and 1875 disconnecting, and staying up. There may be service 1876 agreements in place that may require keeping systems 1877 up even in light of further damage occurring. However, 1878 the damage and scope of an incident may be so extensive 1879 that service agreements may have to be over-ridden. 1881 An important implication for defining priorities is that once human 1882 life and national security considerations have been addressed, it is 1883 generally more important to save data than system software and 1884 hardware. Although it is undesirable to have any damage or loss 1885 during an incident, systems can be replaced. However, the loss or 1886 compromise of data (especially classified or proprietary data) is 1887 usually not an acceptable outcome under any circumstances. 1889 Another important concern is the effect on others, beyond the systems 1890 and networks where the incident occurs. Within the limits imposed by 1891 government regulations it is always important to inform affected 1892 parties as soon as possible. Due to the legal implications of this 1893 topic, it should be included in the planned procedures to avoid 1894 further delays and uncertainties for the administrators. 1896 Any plan for responding to security incidents should be guided by 1897 local policies and regulations. Government and private sites that 1898 deal with classified material have specific rules that they must 1899 follow. 1901 The policies chosen by your site on how it reacts to incidents will 1902 shape your response. For example, it may make little sense to create 1903 mechanisms to monitor and trace intruders if your site does not plan 1904 to take action against the intruders if they are caught. Other 1905 organizations may have policies that affect your plans. Telephone 1906 companies often release information about telephone traces only to 1907 law enforcement agencies. 1909 Handling incidents can be tedious and require any number of routine 1910 tasks that could be handled by support personnel. To free the 1911 technical staff it may be helpful to identify support staff who will 1912 help with tasks like: photocopying, fax'ing, etc. 1914 5.2 Notification and Points of Contact 1916 It is important to establish contacts with various personnel before a 1917 real incident occurs. Many times, incidents are not real 1918 emergencies. Indeed, often you will be able to handle the activities 1919 internally. However, there will also be many times when others 1920 outside your immediate department will need to be included in the 1921 incident handling. These additional contacts include local managers 1922 and system administrators, administrative contacts for other sites on 1923 the Internet, and various investigative organizations. Getting to 1924 know these contacts before incidents occurs will help to make your 1925 incident handling process more efficient. 1927 For each type of communication contact, specific "Points of Contact" 1928 (POC) should be defined. These may be technical or administrative in 1929 nature and may include legal or investigative agencies as well as 1930 service providers and vendors. When establishing these contact, it 1931 is important to decide how much information will be shared with each 1932 class of contact. It is especially important to define, ahead of 1933 time, what information will be shared with the users at a site, with 1934 the public (including the press), and with other sites. 1936 Settling these issues are especially important for the local person 1937 responsible for handling the incident, since that is the person 1938 responsible for the actual notification of others. A list of 1939 contacts in each of these categories is an important time saver for 1940 this person during an incident. It can be quite difficult to find an 1941 appropriate person during an incident when many urgent events are 1942 ongoing. It is strongly recommended that all relevant telephone 1943 numbers (also electronic mail addresses and fax numbers) be included 1944 in the site security policy. The names and contact information of 1945 all individuals who will be directly involved in the handling of an 1946 incident should be placed at the top of this list. 1948 5.2.1 Local Managers and Personnel 1950 When an incident is under way, a major issue is deciding who is in 1951 charge of coordinating the activity of the multitude of players. A 1952 major mistake that can be made is to have a number of people who are 1953 each working independently, but are not working together. This will 1954 only add to the confusion of the event and will probably lead to 1955 wasted or ineffective effort. 1957 The single POC may or may not be the person responsible for handling 1958 the incident. There are two distinct roles to fill when deciding who 1959 shall be the POC and who will be the person in charge of the 1960 incident. The person in charge of the incident will make decisions 1961 as to the interpretation of policy applied to the event. In 1962 contrast, the POC must coordinate the effort of all the parties 1963 involved with handling the event. 1965 The POC must be a person with the technical expertise to successfully 1966 coordinate the efforts of the system managers and users involved in 1967 monitoring and reacting to the attack. Care should be taken when 1968 identifying who this person will be. It should not necessarily be 1969 the same person who has administrative responsibility for the 1970 compromised systems since often such administrators have knowledge 1971 only sufficient for the day to day use of the computers, and lack in 1972 depth technical expertise. 1974 Another important function of the POC is to maintain contact with law 1975 enforcement and other external agencies to assure that multi-agency 1976 involvement occurs. The level of involvement will be determined by 1977 management decisions as well as legal constraints. 1979 A single POC should also be the single person in charge of collecting 1980 evidence, since as a rule of thumb, the more people that touch a 1981 potential piece of evidence, the greater the possibility that it will 1982 be inadmissible in court. To ensure that evidence will be acceptable 1983 to the legal community, collecting evidence should be done following 1984 predefined procedures in accordance with local laws and legal 1985 regulations. 1987 One of the most critical tasks for the POC is the coordination of all 1988 relevant processes. Responsibilities may be distributed over the 1989 whole site, involving multiple independent departments or groups. 1990 This will require a well coordinated effort in order to achieve 1991 overall success. The situation becomes even more complex if multiple 1992 sites are involved. When this happens, rarely will a single POC at 1993 one site be able to adequately coordinate the handling of the entire 1994 incident. Instead, appropriate incident response teams should be 1995 involved. 1997 The incident handling process should provide some escalation 1998 mechanisms. In order to define such a mechanism, sites will need to 1999 create an internal classification scheme for incidents. Associated 2000 with each level of incident will be the appropriate POC and 2001 procedures. As an incident is escalated, there may be a change in 2002 the POC which will need to be communicated to all others involved in 2003 handling the incident. When a change in the POC occurs, old POC 2004 should brief the new POC in all background information. 2006 Lastly, users must know how to report suspected incidents. Sites 2007 should establish reporting procedures that will work both during and 2008 outside normal working hours. Help desks are often used to receive 2009 these reports during normal working hours, while beepers and 2010 telephones can be used for out of hours reporting. 2012 5.2.2 Law Enforcement and Investigative Agencies 2014 In the event of an incident that has legal consequences, it is 2015 important to establish contact with investigative agencies (e.g, the 2016 FBI and Secret Service in the U.S.) as soon as possible. Local law 2017 enforcement, local security offices, and campus police departments 2018 should also be informed as appropriate. This section describes many 2019 of the issues that will be confronted, but it is acknowledged that 2020 each organization will have its own local and governmental laws and 2021 regulations that will impact how they interact with law enforcement 2022 and investigative agencies. The most important point to make is that 2023 each site needs to work through these issues. 2025 A primary reason for determining these point of contact well in 2026 advance of an incident is that once a major attack is in progress, 2027 there is little time to call these agencies to determine exactly who 2028 the correct point of contact is. Another reason is that it is 2029 important to cooperate with these agencies in a manner that will 2030 foster a good working relationship, and that will be in accordance 2031 with the working procedures of these agencies. Knowing the working 2032 procedures in advance, and the expectations of your point of contact 2033 is a big step in this direction. For example, it is important to 2034 gather evidence that will be admissible in any subsequent legal 2035 proceedings, and this will require prior knowledge of how to gather 2036 such evidence. A final reason for establishing contacts as soon as 2037 possible is that it is impossible to know the particular agency that 2038 will assume jurisdiction in any given incident. Making contacts and 2039 finding the proper channels early on will make responding to an 2040 incident go considerably more smoothly. 2042 If your organization or site has a legal counsel, you need to notify 2043 this office soon after you learn that an incident is in progress. At 2044 a minimum, your legal counsel needs to be involved to protect the 2045 legal and financial interests of your site or organization. There 2046 are many legal and practical issues, a few of which are: 2048 (1) Whether your site or organization is willing to risk negative 2049 publicity or exposure to cooperate with legal prosecution efforts. 2051 (2) Downstream liability--if you leave a compromised system as is so 2052 it can be monitored and another computer is damaged because the 2053 attack originated from your system, your site or organization 2054 may be liable for damages incurred. 2056 (3) Distribution of information--if your site or organization distributes 2057 information about an attack in which another site or organization may 2058 be involved or the vulnerability in a product that may affect ability 2059 to market that product, your site or organization may again be liable 2060 for any damages (including damage of reputation). 2062 (4) Liabilities due to monitoring--your site or organization may be sued 2063 if users at your site or elsewhere discover that your site is 2064 monitoring account activity without informing users. 2066 Unfortunately, there are no clear precedents yet on the liabilities 2067 or responsibilities of organizations involved in a security incident 2068 or who might be involved in supporting an investigative effort. 2069 Investigators will often encourage organizations to help trace and 2070 monitor intruders. Indeed, most investigators cannot pursue computer 2071 intrusions without extensive support from the organizations involved. 2072 However, investigators cannot provide protection from liability 2073 claims, and these kinds of efforts may drag out for months and may 2074 take a lot of effort. 2076 On the other hand, an organization's legal council may advise extreme 2077 caution and suggest that tracing activities be halted and an intruder 2078 shut out of the system. This, in itself, may not provide protection 2079 from liability, and may prevent investigators from identifying the 2080 perpetrator. 2082 The balance between supporting investigative activity and limiting 2083 liability is tricky. You'll need to consider the advice of your legal 2084 counsel and the damage the intruder is causing (if any) when making 2085 your decision about what to do during any particular incident. 2087 Your legal counsel should also be involved in any decision to contact 2088 investigative agencies when an incident occurs at your site. The 2089 decision to coordinate efforts with investigative agencies is most 2090 properly that of your site or organization. Involving your legal 2091 counsel will also foster the multi-level coordination between your 2092 site and the particular investigative agency involved, which in turn 2093 results in an efficient division of labor. Another result is that 2094 you are likely to obtain guidance that will help you avoid future 2095 legal mistakes. 2097 Finally, your legal counsel should evaluate your site's written 2098 procedures for responding to incidents. It is essential to obtain a 2099 "clean bill of health" from a legal perspective before you actually 2100 carry out these procedures. 2102 It is vital, when dealing with investigative agencies, to verify that 2103 the person who calls asking for information is a legitimate 2104 representative from the agency in question. Unfortunately, many well 2105 intentioned people have unknowingly leaked sensitive details about 2106 incidents, allowed unauthorized people into their systems, etc., 2107 because a caller has masqueraded as a representative of a government 2108 agency. (Note: this word of caution actually applies to all external 2109 contacts.) 2111 A similar consideration is using a secure means of communication. 2112 Because many network attackers can easily re-route electronic mail, 2113 avoid using electronic mail to communicate with other agencies (as 2114 well as others dealing with the incident at hand). Non-secured phone 2115 lines (the phones normally used in the business world) are also 2116 frequent targets for tapping by network intruders, so be careful! 2118 There is no one established set of rules for responding to an 2119 incident when the local government becomes involved. Normally (in 2120 the U.S.), except by legal order, no agency can force you to monitor, 2121 to disconnect from the network, to avoid telephone contact with the 2122 suspected attackers, etc. Each organization will have a set of local 2123 and national laws and regulations that must be adhered to when 2124 handling incidents. It is recommended that each site be familiar with 2125 those laws and regulations, and identify and get know the contacts 2126 for agencies with jurisdiction well in advance of handling an 2127 incident. 2129 5.2.3 Computer Security Incident Handling Teams 2131 There are currently a number of of Computer Security Incident 2132 Response teams (CSIRTs) such as the CERT Coordination Center, the 2133 German DFN-CERT, and other teams around the globe. Teams exist for 2134 many major government agencies and large corporations. If such a 2135 team is available, notifying it should be of primary consideration 2136 during the early stages of an incident. These teams are responsible 2137 for coordinating computer security incidents over a range of sites 2138 and larger entities. Even if the incident is believed to be 2139 contained within a single site, it is possible that the information 2140 available through a response team could help in fully resolving the 2141 incident. 2143 If it is determined that the breach occurred due to a flaw in the 2144 system's hardware or software, the vendor (or supplier) and a 2145 Computer Security Incident Handling team should be notified as soon 2146 as possible. This is especially important because many other systems 2147 are vulnerable, and these vendor and response team organizations can 2148 help disseminate help to other affected sites. 2150 In setting up a site policy for incident handling, it may be 2151 desirable to create a subgroup, much like those teams that already 2152 exist, that will be responsible for handling computer security 2153 incidents for the site (or organization). If such a team is created, 2154 it is essential that communication lines be opened between this team 2155 and other teams. Once an incident is under way, it is difficult to 2156 open a trusted dialogue between other teams if none has existed 2157 before. 2159 5.2.4 Affected and Involved Sites 2160 If an incident has an impact on other sites, it is good practice to 2161 inform them. It may be obvious from the beginning that the incident 2162 is not limited to the local site, or it may emerge only after further 2163 analysis. 2165 Each site may choose to contact other sites directly or they can pass 2166 the information to an appropriate incident response team. It is often 2167 very difficult to find the responsible POC at remote sites and the 2168 incident response team will be able to facilitate contact by making 2169 use of already established channels. 2171 The legal and liability issues arising from a security incident will 2172 differ from site to site. It is important to define a policy for the 2173 sharing and logging of information about other sites before an 2174 incident occurs. 2176 Information about specific people is especially sensitive, and may be 2177 subject to privacy laws. To avoid problems in this area, irrelevant 2178 information should be deleted and a statement of how to handle the 2179 remaining information should be included. A clear statement of how 2180 this information is to be used is essential. No one who informs a 2181 site of a security incident wants to read about it in the public 2182 press. Incident response teams are valuable in this respect. When 2183 they pass information to responsible POCs, they are able to protect 2184 the anonymity of the original source. But, be aware that, in many 2185 cases, the analysis of logs and information at other sites will 2186 reveal addresses of your site. 2188 All the problems discussed above should be not taken as reasons not 2189 to involve other sites. In fact, the experiences of existing teams 2190 reveal that most sites informed about security problems are not even 2191 aware that their site had been compromised. Without timely 2192 information, other sites are often unable to take action against 2193 intruders. 2195 5.2.5 Internal Communications 2197 It is crucial during a major incident to communicate why certain 2198 actions are being taken, and how the users (or departments) are 2199 expected to behave. In particular, it should be made very clear to 2200 users what they are allowed to say (and not say) to the outside world 2201 (including other departments). For example, it wouldn't be good for 2202 an organization if users replied to customers with something like, 2203 "I'm sorry the systems are down, we've had an intruder and we are 2204 trying to clean things up." It would be much better if they were 2205 instructed to respond with a prepared statement like, "I'm sorry our 2206 systems are unavailable, they are being maintained for better service 2207 in the future." 2209 Communications with customers and contract partners should be handled 2210 in a sensible, but sensitive way. One can prepare for the main issues 2211 by preparing a checklist. When an incident occurs, the checklist can 2212 be used with the addition of a sentence or two for the specific 2213 circumstances of the incident. 2215 Public relations departments can be very helpful during incidents. 2216 They should be involved in all planning and can provide well 2217 constructed responses for use when contact with outside departments 2218 and organizations is necessary. 2220 5.2.6 Public Relations - Press Releases 2222 There has been a tremendous growth in the amount of media coverage 2223 dedicated to computer security incidents in the United States. Such 2224 press coverage is bound to extend to other countries as the Internet 2225 continues to grow and expand internationally. Readers from countries 2226 where such media attention has not yet occurred, can learn from the 2227 experiences in the U.S. and should be forwarned and prepared. 2229 One of the most important issues to consider is when, who, and how 2230 much to release to the general public through the press. There are 2231 many issues to consider when deciding this particular issue. First 2232 and foremost, if a public relations office exists for the site, it is 2233 important to use this office as liaison to the press. The public 2234 relations office is trained in the type and wording of information 2235 released, and will help to assure that the image of the site is 2236 protected during and after the incident (if possible). A public 2237 relations office has the advantage that you can communicate candidly 2238 with them, and provide a buffer between the constant press attention 2239 and the need of the POC to maintain control over the incident. 2241 If a public relations office is not available, the information 2242 released to the press must be carefully considered. If the 2243 information is sensitive, it may be advantageous to provide only 2244 minimal or overview information to the press. It is quite possible 2245 that any information provided to the press will be quickly reviewed 2246 by the perpetrator of the incident. Also note that misleading the 2247 press can often backfire and cause more damage than releasing 2248 sensitive information. 2250 While it is difficult to determine in advance what level of detail to 2251 provide to the press, some guidelines to keep in mind are: 2253 (1) Keep the technical level of detail low. Detailed 2254 information about the incident may provide enough 2255 information for others to launch similar attacks on 2256 other sites, or even damage the site's ability to 2257 prosecute the guilty party once the event is over. 2259 (2) Keep the speculation out of press statements. 2260 Speculation of who is causing the incident or the 2261 motives are very likely to be in error and may cause 2262 an inflamed view of the incident. 2264 (3) Work with law enforcement professionals to assure that 2265 evidence is protected. If prosecution is involved, 2266 assure that the evidence collected is not divulged to 2267 the press. 2269 (4) Try not to be forced into a press interview before you are 2270 prepared. The popular press is famous for the "2 am" 2271 interview, where the hope is to catch the interviewee off 2272 guard and obtain information otherwise not available. 2274 (5) Do not allow the press attention to detract from the 2275 handling of the event. Always remember that the successful 2276 closure of an incident is of primary importance. 2278 5.3 Identifying an Incident 2280 5.3.1 Is It Real? 2282 This stage involves determining if a problem really exists. Of 2283 course many if not most signs often associated with virus infection, 2284 system intrusions, malicious users, etc., are simply anomalies such 2285 as hardware failures or suspicious system/user behavior. To assist 2286 in identifying whether there really is an incident, it is usually 2287 helpful to obtain and use any detection software which may be 2288 available. Audit information is also extremely useful, especially in 2289 determining whether there is a network attack. It is extremely 2290 important to obtain a system snapshot as soon as one suspects that 2291 something is wrong. Many incidents cause a dynamic chain of events 2292 to occur, and an initial system snapshot may be the most valuable 2293 tool for identifying the problem and any source of attack. Finally, 2294 it is important to start a log book. Recording system events, 2295 telephone conversations, time stamps, etc., can lead to a more rapid 2296 and systematic identification of the problem, and is the basis for 2297 subsequent stages of incident handling. 2299 There are certain indications or "symptoms" of an incident that 2300 deserve special attention: 2302 (1) System crashes. 2303 (2) New user accounts (the account RUMPLESTILTSKIN has been 2304 unexpectedly created), or high activity on a previously 2305 low usage account. 2306 (3) New files (usually with novel or strange file names, 2307 such as data.xx or k or .xx ). 2308 (4) Accounting discrepancies (in a UNIX system you might 2309 notice the shrinking of an accounting file called 2310 /usr/admin/lastlog, something that should make you very 2311 suspicious that there may be an intruder). 2312 (5) Changes in file lengths or dates (a user should be 2313 suspicious if .EXE files in an MS DOS computer have 2314 unexplainedly grown by over 1800 bytes). 2315 (6) Attempts to write to system (a system manager notices 2316 that a privileged user in a VMS system is attempting to 2317 alter RIGHTSLIST.DAT). 2318 (7) Data modification or deletion (files start to disappear). 2319 (8) Denial of service (a system manager and all other users 2320 become locked out of a UNIX system, now in single user mode). 2321 (9) Unexplained, poor system performance 2322 (10) Anomalies ("GOTCHA" is displayed on the console or there 2323 are frequent unexplained "beeps"). 2324 (11) Suspicious probes (there are numerous unsuccessful login 2325 attempts from another node). 2326 (12) Suspicious browsing (someone becomes a root user on a UNIX 2327 system and accesses file after file on many user accounts.) 2329 By no means is this list comprehensive; we have just listed a number 2330 of common indicators. It is best to collaborate with other technical 2331 and computer security personnel to make a decision as a group about 2332 whether an incident is occurring. 2334 5.3.2 Types and Scope of Incidents 2336 Along with the identification of the incident is the evaluation of 2337 the scope and impact of the problem. It is important to correctly 2338 identify the boundaries of the incident in order to effectively deal 2339 with it and prioritize responses. 2341 In order to identify the scope and impact a set of criteria should be 2342 defined which is appropriate to the site and to the type of 2343 connections available. Some of the issues include: 2345 (1) Is this a multi-site incident? 2346 (2) Are many computers at your site affected by this incident? 2347 (3) Is sensitive information involved? 2348 (4) What is the entry point of the incident (network, 2349 phone line, local terminal, etc.)? 2350 (5) Is the press involved? 2351 (6) What is the potential damage of the incident? 2352 (7) What is the estimated time to close out the incident? 2353 (8) What resources could be required to handle the incident? 2354 (9) Is law enforcement involved? 2356 5.3.3 Assessing the Damage and Extent 2358 The analysis of the damage and extent of the incident can be quite 2359 time consuming, but should lead to some insight into the nature of 2360 the incident, and aid investigation and prosecution. As soon as the 2361 breach has occurred, the entire system and all of its components 2362 should be considered suspect. System software is the most probable 2363 target. Preparation is key to be able to detect all changes for a 2364 possibly tainted system. This includes checksumming all media from 2365 the vendor using a algorithm which is resistant to tampering. (See 2366 sections 4.3) 2368 Assuming original vendor distribution media are available, an 2369 analysis of all system files should commence, and any irregularities 2370 should be noted and referred to all parties involved in handling the 2371 incident. It can be very difficult, in some cases, to decide which 2372 backup media are showing a correct system status. Consider, for 2373 example, that the incident may have continued for months or years 2374 before discovery, and the suspect may be an employee of the site, or 2375 otherwise have intimate knowledge or access to the systems. In all 2376 cases, the pre-incident preparation will determine what recovery is 2377 possible. 2379 If the system supports centralized logging (most do), go back over 2380 the logs and look for abnormalities. If process accounting and 2381 connect time accounting is enabled, look for patterns of system 2382 usage. To a lesser extent, disk usage may shed light on the 2383 incident. Accounting can provide much helpful information in an 2384 analysis of an incident and subsequent prosecution. Your ability to 2385 address all aspects of a specific incident strongly depends on the 2386 success of this analysis. 2388 5.4 Handling an Incident 2390 Certain steps are necessary to take during the handling of an 2391 incident. In all security related activities, the most important 2392 point to be made is that all sites should have policies in place. 2393 Without defined policies and goals, activities undertaken will remain 2394 without focus. The goals should be defined by management and legal 2395 counsel in advance. 2397 One of the most fundamental objectives is to restore control of the 2398 affected systems and to limit the impact and damage. In the worst 2399 case scenario, shutting down the system, or disconnecting the system 2400 from the network, may the only practical solution. 2402 As the activities involved are complex, try to get as much help as 2403 necessary. While trying to solve the problem alone, real damage 2404 might occur due to delays or missing information. Most 2405 administrators take the discovery of an intruder as a personal 2406 challenge. By proceeding this way, other objectives as outlined in 2407 the local policies may not always be considered. Trying to catch 2408 intruders may be a very low priority, compared to system integrity, 2409 for example. Monitoring a hacker's activity is useful, but it might 2410 not be considered worth the risk to allow the continued access. 2412 5.4.1 Types of Notification and Exchange of Information 2414 When you have confirmed that an incident is occurring, the 2415 appropriate personnel must be notified. How this notification is 2416 achieved is very important to keeping the event under control both 2417 from a technical and emotional standpoint. The circumstances should 2418 be described in as much detail as possible, in order to aid prompt 2419 acknowledgment and understanding of the problem. Great care should 2420 be taken when determining to which groups detailed technical 2421 information is given during the notification. For example, it is 2422 helpful to pass this kind of information to an incident handling team 2423 as they can assist you by providing helpful hints for eradicating the 2424 vulnerabilities involved in an incident. On the other hand, putting 2425 the critical knowledge into the public domain (e.g., via USENET 2426 newsgroups or mailing lists) may potentially put a large number of 2427 systems at risk of intrusion. It is invalid to assume that all 2428 administrators reading a particular newsgroup have access to 2429 operating system source code, or can even understand an advisory well 2430 enough to take adequate steps. 2432 First of all, any notification to either local or off-site personnel 2433 must be explicit. This requires that any statement (be it an 2434 electronic mail message, phone call, fax, beeper, or semaphone) 2435 providing information about the incident be clear, concise, and fully 2436 qualified. When you are notifying others that will help you handle 2437 an event, a "smoke screen" will only divide the effort and create 2438 confusion. If a division of labor is suggested, it is helpful to 2439 provide information to each participant about what is being 2440 accomplished in other efforts. This will not only reduce duplication 2441 of effort, but allow people working on parts of the problem to know 2442 where to obtain information relevant to their part of the incident. 2444 Another important consideration when communicating about the incident 2445 is to be factual. Attempting to hide aspects of the incident by 2446 providing false or incomplete information may not only prevent a 2447 successful resolution to the incident, but may even worsen the 2448 situation. 2450 The choice of language used when notifying people about the incident 2451 can have a profound effect on the way that information is received. 2452 When you use emotional or inflammatory terms, you raise the potential 2453 for damage and negative outcomes of the incident. It is important to 2454 remain calm both in written and spoken communications. 2456 Another consideration is that not all people speak the same language. 2457 Due to this fact, misunderstandings and delay may arise, especially 2458 if it is a multi-national incident. Other international concerns 2459 include differing legal implications of a security incident and 2460 cultural differences. However, cultural differences do not only 2461 exist between countries. They even exist within countries, between 2462 different social or user groups. For example, an administrator of a 2463 university system might be very relaxed about attempts to connect to 2464 the system via telnet, but the administrator of a military system is 2465 likely to consider the same action as a possible attack. 2467 Another issue associated with the choice of language is the 2468 notification of non-technical or off-site personnel. It is important 2469 to accurately describe the incident without generating undue alarm or 2470 confusion. While it is more difficult to describe the incident to a 2471 non-technical audience, it is often more important. A non-technical 2472 description may be required for upper-level management, the press, or 2473 law enforcement liaisons. The importance of these communications 2474 cannot be underestimated and may make the difference between 2475 resolving the incident properly and escalating to some higher level 2476 of damage. 2478 If an incident response team becomes involved, it might be necessary 2479 to fill out a template for the information exchange. Although this 2480 may seem to be an additional burden and adds a certain delay, it 2481 helps the team to act on this minimum set of information. The 2482 response team may be able to respond to aspects of the incident of 2483 which the local administrator is unaware. If information is given out 2484 to someone else, the following minimum information should be 2485 provided: 2487 (1) timezone of logs, ... in GMT or local time 2488 (2) information about the remote system, including host names, 2489 IP addresses and (perhaps) user IDs 2490 (3) all log entries relevant for the remote site 2491 (4) type of incident (what happened, why should you care) 2493 If local information (i.e., local user IDs) is included in the log 2494 entries, it will be necessary to sanitize the entries beforehand to 2495 avoid privacy issues. In general, all information which might assist 2496 a remote site in resolving an incident should be given out, unless 2497 local policies prohibit this. 2499 5.4.2 Protecting Evidence and Activity Logs 2501 When you respond to an incident, document all details related to the 2502 incident. This will provide valuable information to yourself and 2503 others as you try to unravel the course of events. Documenting all 2504 details will ultimately save you time. If you don't document every 2505 relevant phone call, for example, you are likely to forget a 2506 significant portion of information you obtain, requiring you to 2507 contact the source of information again. At the same time, recording 2508 details will provide evidence for prosecution efforts, providing the 2509 case moves in that direction. Documenting an incident will also help 2510 you perform a final assessment of damage (something your management, 2511 as well as law enforcement officers, will want to know), and will 2512 provide the basis for later phases of the handling process: 2513 eradication, recovery, and follow-up "lessons learned." 2515 During the initial stages of an incident, it is often infeasible to 2516 determine whether prosecution is viable, so you should document as if 2517 you are gathering evidence for a court case. At a minimum, you 2518 should record: 2520 (1) all system events (audit records) 2521 (2) all actions you take (time tagged) 2522 (3) all external conversations (including the person with whom 2523 you talked, the date and time, and the content of the 2524 conversation) 2526 The most straightforward way to maintain documentation is keeping a 2527 log book. This allows you to go to a centralized, chronological 2528 source of information when you need it, instead of requiring you to 2529 page through individual sheets of paper. Much of this information is 2530 potential evidence in a court of law. Thus, when a legal follow-up 2531 is a possibility, one should follow the prepared procedures and avoid 2532 jeopardizing the legal follow-up by improper handling of possible 2533 evidence. If appropriate, the following steps may be taken. 2535 (1) Regularly (e.g., every day) turn in photocopied, signed 2536 copies of your logbook (as well as media you use to record 2537 system events) to a document custodian. 2538 (2) The custodian should store these copied pages in a secure 2539 place (e.g., a safe). 2540 (3) When you submit information for storage, you should 2541 receive a signed, dated receipt from the document 2542 custodian. 2544 Failure to observe these procedures can result in invalidation of any 2545 evidence you obtain in a court of law. 2547 5.4.3 Containment 2549 The purpose of containment is to limit the extent of an attack. An 2550 essential part of containment is decision making (e.g., determining 2551 whether to shut a system down, disconnect from a network, monitor 2552 system or network activity, set traps, disable functions such as 2553 remote file transfer, etc.). 2555 Sometimes this decision is trivial; shut the system down if the 2556 information is classified, sensitive, or proprietary. Bear in mind 2557 that removing all access while an incident is in progress obviously 2558 notifies all users, including the alleged problem users, that the 2559 administrators are aware of a problem; this may have a deleterious 2560 effect on an investigation. In some cases, it is prudent to remove 2561 all access or functionality as soon as possible, then restore normal 2562 operation in limited stages. In other cases, it is worthwhile to 2563 risk some damage to the system if keeping the system up might enable 2564 you to identify an intruder. 2566 This stage should involve carrying out predetermined procedures. 2567 Your organization or site should, for example, define acceptable 2568 risks in dealing with an incident, and should prescribe specific 2569 actions and strategies accordingly. This is especially important 2570 when a quick decision is necessary and it is not possible to first 2571 contact all involved parties to discuss the decision. In the absence 2572 of predefined procedures, the person in charge of the incident will 2573 often not have the power to make difficult management decisions (like 2574 to lose the results of a costly experiment by shutting down a 2575 system). A final activity that should occur during this stage of 2576 incident handling is the notification of appropriate authorities. 2578 5.4.4 Eradication 2580 Once the incident has been contained, it is time to eradicate the 2581 cause. But before eradicating the cause, great care should be taken 2582 to collect all necessary information about the compromised system(s) 2583 and the cause of the incident as they will likely be lost when 2584 cleaning up the system. 2586 Software may be available to help you in the eradication process, 2587 such as anti-virus software. If any bogus files have been created, 2588 archive them before deleting them. In the case of virus infections, 2589 it is important to clean and reformat any media containing infected 2590 files. Finally, ensure that all backups are clean. Many systems 2591 infected with viruses become periodically re-infected simply because 2592 people do not systematically eradicate the virus from backups. After 2593 eradication, a new backup should be taken. 2595 Removing all vulnerabilities once an incident has occurred is 2596 difficult. The key to removing vulnerabilities is knowledge and 2597 understanding of the breach. 2599 It may be necessary to go back to the original distribution media and 2600 re-customize the system. To facilitate this worst case scenario, a 2601 record of the original system setup and each customization change 2602 should be maintained. In the case of a network-based attack, it is 2603 important to install patches for each operating system vulnerability 2604 which was exploited. 2606 As discussed in section 5.4.2, a security log can be most valuable 2607 during this phase of removing vulnerabilities. The logs showing how 2608 the incident was discovered and contained can be used later to help 2609 determine how extensive the damage was from a given incident. The 2610 steps taken can be used in the future to make sure the problem does 2611 not resurface. Ideally, one should automate and regularly apply the 2612 same test as was used to detect the security incident. 2614 If a particular vulnerability is isolated as having been exploited, 2615 the next step is to find a mechanism to protect your system. The 2616 security mailing lists and bulletins would be a good place to search 2617 for this information, and you can get advice from incident response 2618 teams. 2620 5.4.5 Recovery 2622 Once the cause of an incident has been eradicated, the recovery phase 2623 defines the next stage of action. The goal of recovery is to return 2624 the system to normal. In general, bringing up services in the order 2625 of demand to allow a minimum of user inconvenience is the best 2626 practice. Understand that the proper recovery procedures for the 2627 system are extremely important and should be specific to the site. 2629 5.4.6 Follow-Up 2631 Once you believe that a system has been restored to a "safe" state, 2632 it is still possible that holes, and even traps, could be lurking in 2633 the system. One of the most important stages of responding to 2634 incidents is also the most often omitted, the follow-up stage. In 2635 the follow-up stage, the system should be monitored for items that 2636 may have been missed during the cleanup stage. It would be prudent 2637 to utilize some of the tools mentioned in chapter 7 as a start. 2638 Remember, these tools don't replace continual system monitoring and 2639 good systems administration practices. 2641 The most important element of the follow-up stage is performing a 2642 postmortem analysis. Exactly what happened, and at what times? How 2643 well did the staff involved with the incident perform? What kind of 2644 information did the staff need quickly, and how could they have 2645 gotten that information as soon as possible? What would the staff do 2646 differently next time? 2648 After an incident, it is prudent to write a report describing the 2649 exact sequence of events: the method of discovery, correction 2650 procedure, monitoring procedure, and a summary of lesson learned. 2651 This will aid in the clear understanding of the problem. Creating a 2652 formal chronology of events (including time stamps) is also important 2653 for legal reasons. 2655 A follow-up report is valuable for many reasons. It provides a 2656 reference to be used in case of other similar incidents. It is also 2657 important to, as quickly as possible obtain a monetary estimate of 2658 the amount of damage the incident caused. This estimate should 2659 include costs associated with any loss of software and files 2660 (especially the value of proprietary data that may have been 2661 disclosed), hardware damage, and manpower costs to restore altered 2662 files, reconfigure affected systems, and so forth. This estimate may 2663 become the basis for subsequent prosecution activity. The report can 2664 also help justify an organization's computer security effort to 2665 management. 2667 5.5 Aftermath of an Incident 2669 In the wake of an incident, several actions should take place. These 2670 actions can be summarized as follows: 2672 (1) An inventory should be taken of the systems' assets, 2673 (i.e., a careful examination should determine how the 2674 system was affected by the incident). 2676 (2) The lessons learned as a result of the incident 2677 should be included in revised security plan to 2678 prevent the incident from re-occurring. 2680 (3) A new risk analysis should be developed in light of the 2681 incident. 2683 (4) An investigation and prosecution of the individuals 2684 who caused the incident should commence, if it is 2685 deemed desirable. 2687 If an incident is based on poor policy, and unless the policy is 2688 changed, then one is doomed to repeat the past. Once a site has 2689 recovered from and incident, site policy and procedures should be 2690 reviewed to encompass changes to prevent similar incidents. Even 2691 without an incident, it would be prudent to review policies and 2692 procedures on a regular basis. Reviews are imperative due to today's 2693 changing computing environments. 2695 The whole purpose of this post mortem process is to improve all 2696 security measures to protect the site against future attacks. As a 2697 result of an incident, a site or organization should gain practical 2698 knowledge from the experience. A concrete goal of the post mortem is 2699 to develop new proactive methods. Another important facet of the 2700 aftermath may be end user and administrator education to prevent a 2701 reoccurrence of the security problem. 2703 5.6 Responsibilities 2705 5.6.1 Not Crossing the Line 2707 It is one thing to protect one's own network, but quite another to 2708 assume that one should protect other networks. During the handling 2709 of an incident, certain system vulnerabilities of one's own systems 2710 and the systems of others become apparent. It is quite easy and may 2711 even be tempting to pursue the intruders in order to track them. 2712 Keep in mind that at a certain point it is possible to "cross the 2713 line," and, with the best of intentions, become no better than the 2714 intruder. 2716 The best rule when it comes to propriety is to not use any facility 2717 of remote sites which is not public. This clearly excludes any entry 2718 onto a system (such as a remote shell or login session) which is not 2719 expressly permitted. This may be very tempting; after a breach of 2720 security is detected, a system administrator may have the means to 2721 "follow it up," to ascertain what damage is being done to the remote 2722 site. Don't do it! Instead, attempt to reach the appropriate point 2723 of contact for the affected site. 2725 5.6.2 Good Internet Citizenship 2727 During a security incident there are two choices one can make. 2728 First, a site can choose to watch the intruder in the hopes of 2729 catching him; or, the site can go about cleaning up after the 2730 incident and shut the intruder out of the systems. This is a 2731 decision that must be made very thoughtfully, as there may be legal 2732 liabilities if you choose to leave your site open, knowing that an 2733 intruder is using your site as a launching pad to reach out to other 2734 sites. Being a good Internet citizen means that you should try to 2735 alert other sites that may have been impacted by the intruder. These 2736 affected sites may be readily apparent after a thorough review of 2737 your log files. 2739 5.6.3 Administrative Response to Incidents 2741 When a security incident involves a user, the site's security policy 2742 should describe what action is to be taken. The transgression should 2743 be taken seriously, but it is very important to be sure of the role 2744 the user played. Was the user naive? Could there be a mistake in 2745 attributing the security breach to the user? Applying administrative 2746 action that assumes the user intentionally caused the incident may 2747 not be appropriate for a user who simply made a mistake. It may be 2748 appropriate to include sanctions more suitable for such a situation 2749 in your policies (e.g., education or reprimand of a user) in addition 2750 to more stern measures for intentional acts of intrusion and system 2751 misuse. 2753 6. Ongoing Activities 2755 At this point in time, your site has hopefully developed a complete 2756 security policy and has developed procedures to assist in the 2757 configuration and management of your technology in support of those 2758 policies. How nice it would be if you could sit back and relax at 2759 this point and know that you were finished with the job of security. 2760 Unfortunately, that isn't possible. Your systems and networks are 2761 not a static environment, so you will need to review policies and 2762 procedures on a regular basis. There are a number of steps you can 2763 take to help you keep up with the changes around you so that you can 2764 initiate corresponding actions to address those changes. The 2765 following is a starter set and you may add others as appropriate for 2766 your site. 2768 (1) Subscribe to advisories that are issued by various security incident 2769 response teams, like those of the CERT Coordination Center, and 2770 update your systems against those threats that apply to your site's 2771 technology. 2773 (2) Monitor security patches that are produced by the vendors of your 2774 equipment, and obtain and install all that apply. 2776 (3) Actively watch the configurations of your systems to identify any 2777 changes that may have occurred, and investigate all anomalies. 2779 (4) Review all security policies and procedures annually (at a minimum). 2781 (5) Read relevant mailing lists and USENET newsgroups to keep up to 2782 date with the latest information being shared by fellow 2783 administrators. 2785 (6) Regularly check for compliance with policies and procedures. This 2786 audit should be performed by someone other than the people who 2787 define or implement the policies and procedures. 2789 7. Tools and Locations 2791 This chapter provides a brief list of publicly available security 2792 technology which can be downloaded from the Internet. Many of the 2793 items described below will undoubtedly be surpassed or made obsolete 2794 before this document is published. 2796 Some of the tools listed are applications such as end user programs 2797 (clients) and their supporting system infrastructure (servers). 2798 Others are tools that a general user will never see or need to use, 2799 but may be used by applications, or by administrators to troubleshoot 2800 security problems or to guard against intruders. 2802 A sad fact is that there are very few security conscious applications 2803 currently available. Primarily, this is caused by the need for a 2804 security infrastructure which must first be put into place for most 2805 applications to operate securely. There is considerable effort 2806 currently taking place to build this infrastructure so that 2807 applications can take advantage of secure communications. 2809 Most of the tools and applications described below can be found in 2810 one of the following archive sites: 2812 (1) CERT Coordination Center 2813 ftp://info.cert.org:/pub/tools 2814 (2) DFN-CERT 2815 ftp://ftp.cert.dfn.de/pub/tools/ 2816 (3) Computer Operations, Audit, and Security Tools (COAST) 2817 coast.cs.purdue.edu:/pub/tools 2819 It is important to note that many sites, including CERT and COAST are 2820 mirrored throughout the Internet. Be careful to use a "well known" 2821 mirror site to retrieve software, and to use verification tools (md5 2822 checksums, etc.) to validate that software. A clever cracker might 2823 advertise security software that has intentionally been designed to 2824 provide access to data or systems. 2826 Tools 2828 COPS 2829 DES 2830 Drawbridge 2831 identd (not really a security tool) 2832 ISS 2833 Kerberos 2834 logdaemon 2835 lsof 2836 MD5 2837 PEM 2838 PGP 2839 rpcbind/portmapper replacement 2840 SATAN 2841 sfingerd 2842 S/KEY 2843 smrsh 2844 ssh 2845 swatch 2846 TCP-Wrapper 2847 tiger 2848 Tripwire 2849 TROJAN.PL 2851 8. Mailing Lists and Other Resources 2853 It would be impossible to list all of the mail-lists and other 2854 resources dealing with site security. However, these are some "jump- 2855 points" from which the reader can begin. All of these references are 2856 for the "INTERNET" constituency. More specific (vendor and 2857 geographical) resources can be found through these references. 2859 Mailing Lists 2861 (1) CERT Advisory 2862 Send mail to: cert-advisory-request@cert.org 2863 Message Body: subscribe cert 2865 A CERT advisory provides information on how to obtain a patch or 2866 details of a workaround for a known computer security problem. 2867 The CERT Coordination Center works with vendors to produce a 2868 workaround or a patch for a problem, and does not publish 2869 vulnerability information until a workaround or a patch is 2870 available. A CERT advisory may also be a warning to our 2871 constituency about ongoing attacks (e.g., 2872 "CA-91:18.Active.Internet.tftp.Attacks"). 2874 CERT advisories are also published on the USENET newsgroup: 2875 comp.security.announce 2877 CERT advisory archives are available via anonymous FTP from 2878 info.cert.org in the /pub/cert_advisories directory. 2880 (2) VIRUS-L List 2881 Send mail to: listserv%lehiibm1.bitnet@mitvma.mit.edu 2882 Message Body: subscribe virus-L FIRSTNAME LASTNAME 2884 VIRUS-L is a moderated mailing list with a focus 2885 on computer virus issues. For more information, 2886 including a copy of the posting guidelines, see 2887 the file "virus-l.README", available by anonymous 2888 FTP from cs.ucr.edu. 2890 (3) Internet Firewalls 2891 Send mail to: majordomo@greatcircle.com 2892 Message Body: subscribe firewalls user@host 2894 The Firewalls mailing list is a discussion forum for 2895 firewall administrators and implementors. 2897 USENET newsgroups 2899 (1) comp.security.announce 2900 The comp.security.announce newsgroup is moderated 2901 and is used solely for the distribution of CERT 2902 advisories. 2904 (2) comp.security.misc 2905 The comp.security.misc is a forum for the 2906 discussion of computer security, especially as it 2907 relates to the UNIX(r) Operating System. 2909 (3) alt.security 2910 The alt.security newsgroup is also a forum for the 2911 discussion of computer security, as well as other 2912 issues such as car locks and alarm systems. 2914 (4) comp.virus 2915 The comp.virus newsgroup is a moderated newsgroup 2916 with a focus on computer virus issues. For more 2917 information, including a copy of the posting 2918 guidelines, see the file "virus-l.README", 2919 available via anonymous FTP on info.cert.org 2920 in the /pub/virus-l directory. 2922 (5) comp.risks 2923 The comp.risks newsgroup is a moderated forum on 2924 the risks to the public in computers and related 2925 systems. 2927 World-Wide Web Pages 2929 (1) http://www.first.org/ 2931 Computer Security Resource Clearinghouse. The main focus is on 2932 crisis response information; information on computer 2933 security-related threats, vulnerabilities, and solutions. At the 2934 same time, the Clearinghouse strives to be a general index to 2935 computer security information on a broad variety of subjects, 2936 including general risks, privacy, legal issues, viruses, 2937 assurance, policy, and training. 2939 (2) http://www.telstra.com.au/info/security.html 2941 This Reference Index contains a list of links to information 2942 sources on Network and Computer Security. There is no implied 2943 fitness to the Tools, Techniques and Documents contained within this 2944 archive. Many if not all of these items work well, but we do 2945 not guarantee that this will be so. This information is for the 2946 education and legitimate use of computer security techniques only. 2948 (3) http://www.alw.nih.gov/Security/security.html 2950 This page features general information about computer security. 2951 Information is organized by source and each section is organized 2952 by topic. Recent modifications are noted in What's New page. 2954 9. References 2956 The following references may not be available in all countries. 2958 [Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and 2959 McAuliffe, "The Law and The Internet", USENIX 1995 Technical 2960 Conference on UNIX and Advanced Computing, New Orleans, LA, January 2961 16-20, 1995. 2963 [ABA, 1989] American Bar Association, Section of Science and 2964 Technology, "Guide to the Prosecution of Telecommunication Fraud by 2965 the Use of Computer Crime Statutes", American Bar Association, 1989. 2967 [Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery", 2968 Computers in Libraries, Vol. 9, No. 2, Pg. 4, February 1989. 2970 [Barrett, 1996] D. Barrett, "Bandits on the Information 2971 Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996. 2973 [Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks, 2974 Telecommunications and Data Communications", McGraw-Hill, 1992. 2976 [Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP 2977 Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48, 2978 April 1989. 2980 [Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the 2981 Kerberos Authentication System", Computer Communications Review, 2982 October 1990. 2984 [Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings 2985 of the Third Usenix Security Symposium, Baltimore, MD. September, 2986 1992. 2988 [Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M. 2989 Bender, New York, NY, 1978-present. 2991 [Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes", 2992 Dow Jones- Irwin, Homewood, IL. 1990. 2994 [Brand, 1990] R. Brand, "Coping with the Threat of Computer Security 2995 Incidents: A Primer from Prevention through Recovery", R. Brand, 8 2996 June 1990. 2998 [Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and 2999 the Vulnerability of National Telecommunications Networks to Computer 3000 Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989. 3002 [BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt, 3003 "BS 7799 : 1995 Code of Practice for Information Security 3004 Management", British Standards Institution, London, 54, Effective 15 3005 February 1995. 3007 [Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of 3008 Information", Proceedings of the Fifth IFIP International Conference 3009 on Computer Security, IFIP/Sec '88. 3011 [Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition, 3012 Butterworth Publishers, Stoneham, MA, 1987. 3014 [Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and 3015 The Law", MIT Press, Cambridge, MA, 1995. 3017 [CCH, 1989] Commerce Clearing House, "Guide to Computer Law", 3018 (Topical Law Reports), Chicago, IL., 1989. 3020 [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet 3021 Filtering", USENIX: Proceedings of the Third UNIX Security Symposium, 3022 Baltimore, MD, September 1992. 3024 [Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building 3025 Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995. 3027 [Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet 3028 Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, 3029 June 1990. 3031 [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker 3032 is Lured, Endured, and Studied", AT&T Bell Laboratories. 3034 [Cheswick and Bellovin, 1994] W. Cheswick and S. Bellovin, "Firewalls 3035 and Internet Security: Repelling the Wily Hacker", Addison-Wesley, 3036 Reading, MA, 1994. 3038 [Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation 3039 and Prosecution", U.S. Dept. of Justice, Office of Justice Programs, 3040 Under Contract Number OJP-86-C-002, National Institute of Justice, 3041 Washington, DC, July 1989. 3043 [Cooper, 1989] J. Cooper, "Computer and Communications Security: 3044 Strategies for the 1990s", McGraw-Hill, 1989. 3046 [CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR 3047 Statement on the Computer Virus", CPSR, Communications of the ACM, 3048 Vol. 32, No. 6, Pg. 699, June 1989. 3050 [CSC-STD-002-85, 1985] Department of Defense, "Password Management 3051 Guideline", CSC-STD-002-85, 12 April 1985, 31 pages. 3053 [Curry, 1990] D. Curry, "Improving the Security of Your UNIX System", 3054 SRI International Report ITSTD-721-FR-90-21, April 1990. 3056 [Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and 3057 Systems Administrators", Addision-Wesley, Reading, MA, 1992. 3059 [DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem 3060 Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 3061 November 1988. 3063 [DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin 3064 03", DDN Security Coordination Center, 17 October 1989. 3066 [Denning, 1990] P. Denning, Editor, "Computers Under Attack: 3067 Intruders, Worms, and Viruses", ACM Press, 1990. 3069 [Eichin and Rochlis, 1989] M. Eichin, and J. Rochlis, "With 3070 Microscope and Tweezers: An Analysis of the Internet Virus of 3071 November 1988", Massachusetts Institute of Technology, February 1989. 3073 [Eisenberg, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D. 3074 Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell 3075 University, 6 February 1989. 3077 [Ermann, Willians, and Gutierrez, 1990] D. Ermann, M. Williams, and 3078 C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford 3079 University Press, NY, 1990. (376 pages, includes bibliographical 3080 references). 3082 [Farmer and Spafford, 1990] D. Farmer and E. Spafford, "The COPS 3083 Security Checker System", Proceedings of the Summer 1990 USENIX 3084 Conference, Anaheim, CA, Pgs. 165-170, June 1990. 3086 [Farrow, 1991] Rik Farrow, "UNIX Systems Security", Addison-Wesley, 3087 Reading, MA, 1991. 3089 [Fenwick, 1985] W. Fenwick, Chair, "Computer Litigation, 1985: Trial 3090 Tactics and Techniques", Litigation Course Handbook Series No. 280, 3091 Prepared for distribution at the Computer Litigation, 1985: Trial 3092 Tactics and Techniques Program, February-March 1985. 3094 [Fites, Kratz, and Brebner, 1989] M. Fites, P. Kratz, and A. Brebner, 3095 "Control and Security of Computer Information Systems", Computer 3096 Science Press, 1989. 3098 [Fites, Johnson, and Kratz, 1992] Fites, Johnson, and Kratz, "The 3099 Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992. 3101 [Forester and Morrison, 1990] T. Forester, and P. Morrison, "Computer 3102 Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, 3103 Cambridge, MA, 1990. 3105 [Foster and Morrision, 1990] T. Forester, and P. Morrison, "Computer 3106 Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, 3107 Cambridge, MA, 1990. (192 pages including index.) 3109 [GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer 3110 Security - Virus Highlights Need for Improved Internet Management", 3111 United States General Accounting Office, Washington, DC, 1989. 3113 [Garfinkel and Spafford, 1991] S. Garfinkel, and E. Spafford, 3114 "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2, 3115 May 1991. 3117 [Garfinkel, 1995] S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly & 3118 Associates, Sebastopol, CA, 1996. 3120 [Garfinkel and Spafford, 1996] S. Garfinkel and E. Spafford, 3121 "Practical UNIX and Internet Security", O'Reilly & Associates, 3122 Sebastopol, CA, 1996. 3124 [Gemignani, 1989] M. Gemignani, "Viruses and Criminal Law", 3125 Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989. 3127 [Goodell, 1996] J. Goodell, "The Cyberthief and the Samurai: The True 3128 Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell 3129 Publishing, 328pp, 1996. 3131 [Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and 3132 Social Implications of Computer Networking", Westview Press, Boulder, 3133 CO, 1989. 3135 [Greenia, 1989] M. Greenia, "Computer Security Information 3136 Sourcebook", Lexikon Services, Sacramento, CA, 1989. 3138 [Hafner and Markoff, 1991] K. Hafner and J. Markoff, "Cyberpunk: 3139 Outlaws and Hackers on the Computer Frontier", Touchstone, Simon & 3140 Schuster, 1991. 3142 [Hess, Safford, and Pooch] D. Hess, D. Safford, and U. Pooch, "A Unix 3143 Network Protocol Security Study: Network Information Service", Texas 3144 A&M University. 3146 [Hoffman, 1990] L. Hoffman, "Rogue Programs: Viruses, Worms, and 3147 Trojan Horses", Van Nostrand Reinhold, NY, 1990. (384 pages, 3148 includes bibliographical references and index.) 3150 [Howard, 1995] G. Howard, "Introduction to Internet Security: From 3151 Basics to Beyond", Prima Publishing, Rocklin, CA, 1995. 3153 [Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors, 3154 "Protection of Computer Systems and Software: New Approaches for 3155 Combating Theft of Software and Unauthorized Intrusion", Papers 3156 presented at a workshop sponsored by the National Science Foundation, 3157 1986. 3159 [Hughes, 1995] L. Hughes Jr., "Actually Useful Internet Security 3160 Techniques", New Riders Publishing, Indianapolis, IN, 1995. 3162 [IAB-RFC1087, 89] Internet Activities Board, "Ethics and the 3163 Internet", RFC 1087, IAB, January 1989. Also appears in the 3164 Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989. 3166 [Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W. 3167 VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly & 3168 Associates, Sebastopol, CA, 1995. 3170 [IVPC, 1996] IVPC, "International Virus Prevention Conference '96 3171 Proceedings", NCSA, 1996. 3173 [Johnson and Podesta] D. Johnson, and J. Podesta, "Formulating A 3174 Company Policy on Access to and Use and Disclosure of Electronic Mail 3175 on Company Computer Systems". 3177 [Kane, 1994] P. Kane, "PC Security and Virus Protection Handbook: The 3178 Ongoing War Against Information Sabotage", M&T Books, 1994. 3180 [Kaufman, Perlman, and Speciner, 1995] C. Kaufman, R. Perlman, and M. 3181 Speciner, "Network Security: PRIVATE Communication in a PUBLIC 3182 World", Prentice Hall, Englewood Cliffs, NJ, 1995. 3184 [Kent, 1990] S. Kent, "E-Mail Privacy for the Internet: New Software 3185 and Strict Registration Procedures will be Implemented this Year", 3186 Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January 3187 1990. 3189 [Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution", 3190 Delta, 1984. 3192 [Lewis, 1996] S. Lewis, "Disaster Recovery Yellow Pages", The Systems 3193 Audit Group, 1996. 3195 [Littleman, 1996] J. Littleman, "The Fugitive Game: Online with Kevin 3196 Mitnick", Little, Brown, Boston, MA. 333p, 1996. 3198 [Lu and Sundareshan, 1989] W. Lu and M. Sundareshan, "Secure 3199 Communication in Internet Environments: A Hierarchical Key Management 3200 Scheme for End-to-End Encryption", IEEE Transactions on 3201 Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989. 3203 [Lu and Sundareshan, 1990] W. Lu and M. Sundareshan, "A Model for 3204 Multilevel Security in Computer Networks", IEEE Transactions on 3205 Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990. 3207 [Martin and Schinzinger, 1989] M. Martin, and R. Schinzinger, "Ethics 3208 in Engineering", McGraw Hill, 2nd Edition, 1989. 3210 [Merkle] R. Merkle, "A Fast Software One Way Hash Function", Journal 3211 of Cryptology, Vol. 3, No. 1. 3213 [McEwen, 1989] J. McEwen, "Dedicated Computer Crime Units", Report 3214 Contributors: D. Fester and H. Nugent, Prepared for the National 3215 Institute of Justice, U.S. Department of Justice, by Institute for 3216 Law and Justice, Inc., under contract number OJP-85-C-006, 3217 Washington, DC, 1989. 3219 [MIT, 1989] Massachusetts Institute of Technology, "Teaching Students 3220 About Responsible Use of Computers", MIT, 1985-1986. Also reprinted 3221 in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena 3222 Project, MIT, June 1989. 3224 [Mogel, 1989] Mogul, J., "Simple and Flexible Datagram Access 3225 Controls for UNIX-based Gateways", Digital Western Research 3226 Laboratory Research Report 89/4, March 1989. 3228 [Muffett, 1992] A. Muffett, "Crack Version 4.1: A Sensible Password 3229 Checker for Unix" 3231 [NCSA1, 1995] NCSA, "NCSA Firewall Policy Guide", 1995. 3233 [NCSA2, 1995] NCSA, "NCSA's Corporate Computer Virus Prevention 3234 Policy Model", NCSA, 1995. 3236 [NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96 3237 Proceedings", 1996. 3239 [NCSC-89-660-P, 1990] National Computer Security Center, "Guidelines 3240 for Formal Verification Systems", Shipping list no.: 89-660-P, The 3241 Center, Fort George G. Meade, MD, 1 April 1990. 3243 [NCSC-89-254-P, 1988] National Computer Security Center, "Glossary of 3244 Computer Security Terms", Shipping list no.: 89-254-P, The Center, 3245 Fort George G. Meade, MD, 21 October 1988. 3247 [NCSC-C1-001-89, 1989] Tinto, M., "Computer Viruses: Prevention, 3248 Detection, and Treatment", National Computer Security Center C1 3249 Technical Report C1-001-89, June 1989. 3251 [NCSC Conference, 1989] National Computer Security Conference, "12th 3252 National Computer Security Conference: Baltimore Convention Center, 3253 Baltimore, MD, 10-13 October, 1989: Information Systems Security, 3254 Solutions for Today - Concepts for Tomorrow", National Institute of 3255 Standards and National Computer Security Center, 1989. 3257 [NCSC-CSC-STD-003-85, 1985] National Computer Security Center, 3258 "Guidance for Applying the Department of Defense Trusted Computer 3259 System Evaluation Criteria in Specific Environments", CSC-STD-003-85, 3260 NCSC, 25 June 1985. 3262 [NCSC-STD-004-85, 1985] National Computer Security Center, "Technical 3263 Rationale Behind CSC-STD-003-85: Computer Security Requirements", 3264 CSC-STD-004-85, NCSC, 25 June 1985. 3266 [NCSC-STD-005-85, 1985] National Computer Security Center, "Magnetic 3267 Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November 3268 1985. 3270 [NCSC-TCSEC, 1985] National Computer Security Center, "Trusted 3271 Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001- 3272 83, NCSC, December 1985. 3274 [NCSC-TG-003, 1987] NCSC, "A Guide to Understanding DISCRETIONARY 3275 ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30 3276 September 1987, 29 pages. 3278 [NCSC-TG-001, 1988] NCSC, "A Guide to Understanding AUDIT in Trusted 3279 Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages. 3281 [NCSC-TG-004, 1988] National Computer Security Center, "Glossary of 3282 Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988. 3284 [NCSC-TG-005, 1987] National Computer Security Center, "Trusted 3285 Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987. 3287 [NCSC-TG-006, 1988] NCSC, "A Guide to Understanding CONFIGURATION 3288 MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March 3289 1988, 31 pages. 3291 [NCSC-TRUSIX, 1990] National Computer Security Center, "Trusted UNIX 3292 Working Group (TRUSIX) rationale for selecting access control list 3293 features for the UNIX system", Shipping list no.: 90-076-P, The 3294 Center, Fort George G. Meade, MD, 1990. 3296 [NRC, 1991] National Research Council, "Computers at Risk: Safe 3297 Computing in the Information Age", National Academy Press, 1991. 3299 [Nemeth, et. al, 1995] E. Nemeth, G. Snyder, S. Seebass, and T. Hein, 3300 "UNIX Systems Administration Handbook", Prentice Hall PTR, Englewood 3301 Cliffs, NJ, 2ed. 1995. 3303 [NIST, 1989] National Institute of Standards and Technology, 3304 "Computer Viruses and Related Threats: A Management Guide", NIST 3305 Special Publication 500-166, August 1989. 3307 [NSA] National Security Agency, "Information Systems Security 3308 Products and Services Catalog", NSA, Quarterly Publication. 3310 [NSF, 1988] National Science Foundation, "NSF Poses Code of 3311 Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. 3312 688, June 1989. Also appears in the minutes of the regular meeting 3313 of the Division Advisory Panel for Networking and Communications 3314 Research and Infrastructure, Dave Farber, Chair, November 29-30, 3315 1988. 3317 [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation 3318 Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58 3319 pages. 3321 [OTA-CIT-310, 1987] United States Congress, Office of Technology 3322 Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for 3323 Electronic Information", OTA-CIT-310, October 1987. 3325 [OTA-TCT-606] Congress of the United States, Office of Technology 3326 Assessment, "Information Security and Privacy in Network 3327 Environments", OTA-TCT-606, September 1994. 3329 [Palmer and Potter, 1989] I. Palmer, and G. Potter, "Computer 3330 Security Risk Management", Van Nostrand Reinhold, NY, 1989. 3332 [Parker, 1989] D. Parker, "Computer Crime: Criminal Justice Resource 3333 Manual", U.S. Dept. of Justice, National Institute of Justice, Office 3334 of Justice Programs, Under Contract Number OJP-86-C-002, Washington, 3335 D.C., August 1989. 3337 [Parker, Swope, and Baker, 1990] D. Parker, S. Swope, and B. Baker, 3338 "Ethical Conflicts: Information and Computer Science, Technology and 3339 Business", QED Information Sciences, Inc., Wellesley, MA. (245 3340 pages). 3342 [Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall, 3343 Englewood Cliffs, NJ, 1989. 3345 [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks 3346 and Conferencing Systems Worldwide", Digital Press, Bedford, MA, 3347 1990. 3349 [Ranum1, 1992] M. Ranum, "An Internet Firewall", Proceedings of World 3350 Conference on Systems Management and Security, 1992. 3352 [Ranum2, 1992] M. Ranum, "A Network Firewall", Digital Equipment 3353 Corporation Washington Open Systems Resource Center, June 12, 1992. 3355 [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993. 3357 [Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and 3358 Methods for Internet Firewalls", Trustest Information Systems, 1994. 3360 [Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX 3361 Network Security" 3363 [Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX 3364 Network Security", ARINC Research Corporation, February 18, 1993. 3366 [Reynolds-RFC1135, 1989] The Helminthiasis of the Internet, RFC 1135, 3367 USC/Information Sciences Institute, Marina del Rey, CA, December 3368 1989. 3370 [Russell and Gangemi, 1991] D. Russell and G. Gangemi, "Computer 3371 Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991. 3373 [Schneier 1996] B. Schneier, "Applied Cryptography: Protocols, 3374 Algorithms, and Source Code in C", John Wiley & Sons, New York, 3375 second edition, 1996. 3377 [Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989 3378 Winter USENIX Conference, Usenix Association, San Diego, CA, February 3379 1989. 3381 [Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986", 3382 Congressional Record (3 June 1986), Washington, D.C., 3 June 1986. 3384 [Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit 3385 and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw- 3386 by the Man Who Did It", Hyperion, 324p, 1996. 3388 [Shirey, 1990] R. Shirey, "Defense Data Network Security 3389 Architecture", Computer Communication Review, Vol. 20, No. 2, Page 3390 66, 1 April 1990. 3392 [Slatalla and Quittner, 1995] M. Slatalla and J. Quittner, "Masters 3393 of Deception: The Gang that Ruled Cyberspace", Harper Collins 3394 Publishers, 1995. 3396 [Smith, 1989] M. Smith, "Commonsense Computer Security: Your 3397 Practical Guide to Preventing Accidental and Deliberate Electronic 3398 Data Loss", McGraw-Hill, New York, NY, 1989. 3400 [Smith, 1995] D. Smith, "Forming an Incident Response Team", Sixth 3401 Annual Computer Security Incident Handling Workshop, Boston, MA, July 3402 25-29, 1995. 3404 [Spafford, 1988] E. Spafford, "The Internet Worm Program: An 3405 Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM, 3406 January 1989. Also issued as Purdue CS Technical Report CSD-TR-823, 3407 28 November 1988. 3409 [Spafford, 1989] G. Spafford, "An Analysis of the Internet Worm", 3410 Proceedings of the European Software Engineering Conference 1989, 3411 Warwick England, September 1989. Proceedings published by Springer- 3412 Verlag as: Lecture Notes in Computer Science #387. Also issued as 3413 Purdue Technical Report #CSD-TR-933. 3415 [Spafford, Keaphy, and Ferbrache, 1989] E. Spafford, K. Heaphy, and 3416 D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism 3417 and Programmed Threats", ADAPSO, 1989. (109 pages.) 3419 [Stallings1, 1995] W. Stallings, "Internet Security Handbook", IDG 3420 Books, Foster City CA, 1995. 3422 [Stallings2, 1995] W. Stallings, "Network and InterNetwork Security", 3423 Prentice Hall, , 1995. 3425 [Stallings3, 1995] W. Stallings, "Protect Your Privacy: A Guide for 3426 PGP Users" PTR Prentice Hall, 1995. 3428 [Stoll, 1988] C. Stoll, "Stalking the Wily Hacker", Communications of 3429 the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988. 3431 [Stoll, 1989] C. Stoll, "The Cuckoo's Egg", ISBN 00385-24946-2, 3432 Doubleday, 1989. 3434 [Treese and Wolman, 1993] G. Treese and A. Wolman, "X Through the 3435 Firewall, and Other Applications Relays", Digital Equipment 3436 Corporation, Cambridge Research Laboratory, CRL 93/10, May 3, 1993. 3438 [Trible, 1986] P. Trible, "The Computer Fraud and Abuse Act of 1986", 3439 U.S. Senate Committee on the Judiciary, 1986. 3441 [Venema] W. Venema, "TCP WRAPPER: Network monitoring, access control, 3442 and booby traps", Mathematics and Computing Science, Eindhoven 3443 University of Technology, The Netherlands. 3445 [USENIX, 1988] USENIX, "USENIX Proceedings: UNIX Security Workshop", 3446 Portland, OR, August 29-30, 1988. 3448 [USENIX, 1990] USENIX, "USENIX Proceedings: UNIX Security II 3449 Workshop", Portland, OR, August 27-28, 1990. 3451 [USENIX, 1992] USENIX, "USENIX Symposium Proceedings: UNIX Security 3452 III", Baltimore, MD, September 14-16, 1992. 3454 [USENIX, 1993] USENIX, "USENIX Symposium Proceedings: UNIX Security 3455 IV", Santa Clara, CA, October 4-6, 1993. 3457 [USENIX, 1995] USENIX, "The Fifth USENIX UNIX Security Symposium", 3458 Salt Lake City, UT, June 5-7, 1995. 3460 [Wood, et.al., 1987] C. Wood, W. Banks, S. Guarro, A. Garcia, V. 3462 Hampel, and H. Sartorio, "Computer Security: A Comprehensive 3463 Controls Checklist", John Wiley and Sons, Interscience Publication, 3464 1987. 3466 [Wrobel, 1993] L. Wrobel, "Writing Disaster Recovery Plans for 3467 Telecommunications Networks and LANS", Artech House, 1993. 3469 [Vallabhaneni, 1989] S. Vallabhaneni, "Auditing Computer Security: A 3470 Manual with Case Studies", Wiley, New York, NY, 1989. 3472 10. Annotated Bibliography 3474 The intent of this annotated bibliography is to offer a 3475 representative collection of resources of information that will help 3476 the user of this handbook. It is meant provide a starting point for 3477 further research in the security area. Included are references to 3478 other sources of information for those who wish to pursue issues of 3479 the computer security environment. 3481 10.1 Computer Law 3483 [Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and 3484 McAuliffe, "The Law and The Internet", USENIX 1995 Technical 3485 Conference on UNIX and Advanced Computing, New Orleans, LA, January 3486 16-20, 1995. 3488 [ABA, 1989] American Bar Association, Section of Science and 3489 Technology, "Guide to the Prosecution of Telecommunication Fraud by 3490 the Use of Computer Crime Statutes", American Bar Association, 1989. 3492 [Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M. 3493 Bender, New York, NY, 1978-present. 3495 Kept up to date with supplements. Years covering 1978-1984 focuses 3496 on: Computer law, evidence and procedures. The years 1984 to the 3497 current focus on general computer law. Bibliographical references 3498 and index included. 3500 [Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes", 3501 Dow Jones- Irwin, Homewood, IL. 1990. 3503 [Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and 3504 The Law", MIT Press, Cambridge, MA, 1995. 3506 [CCH, 1989] Commerce Clearing House, "Guide to Computer Law", 3507 (Topical Law Reports), Chicago, IL., 1989. 3509 Court cases and decisions rendered by federal and state courts 3510 throughout the United States on federal and state computer law. 3511 Includes Case Table and Topical Index. 3513 [Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation 3514 and Prosecution", U.S. Dept. of Justice, Office of Justice Programs, 3515 Under Contract Number OJP-86-C-002, National Institute of Justice, 3516 Washington, DC, July 1989. 3518 [Fenwick, 1985] W. Fenwick, Chair, "Computer Litigation, 1985: Trial 3519 Tactics and Techniques", Litigation Course Handbook Series No. 280, 3520 Prepared for distribution at the Computer Litigation, 1985: Trial 3521 Tactics and Techniques Program, February-March 1985. 3523 [Gemignani, 1989] M. Gemignani, "Viruses and Criminal Law", 3524 Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989. 3526 [Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors, 3527 "Protection of Computer Systems and Software: New Approaches for 3528 Combating Theft of Software and Unauthorized Intrusion", Papers 3529 presented at a workshop sponsored by the National Science Foundation, 3530 1986. 3532 [McEwen, 1989] J. McEwen, "Dedicated Computer Crime Units", Report 3533 Contributors: D. Fester and H. Nugent, Prepared for the National 3534 Institute of Justice, U.S. Department of Justice, by Institute for 3535 Law and Justice, Inc., under contract number OJP-85-C-006, 3536 Washington, DC, 1989. 3538 [Parker, 1989] D. Parker, "Computer Crime: Criminal Justice Resource 3539 Manual", U.S. Dept. of Justice, National Institute of Justice, Office 3540 of Justice Programs, Under Contract Number OJP-86-C-002, Washington, 3541 D.C., August 1989. 3543 [Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986, 3544 Congressional Record (3 June 1986), Washington, D.C., 3 June 1986. 3546 [Trible, 1986] P. Trible, "The Computer Fraud and Abuse Act of 1986", 3547 U.S. Senate Committee on the Judiciary, 1986. 3549 10.2 Computer and Network Security 3551 [Brand, 1990] Brand, R., "Coping with the Threat of Computer Security 3552 Incidents: A Primer from Prevention through Recovery", R. Brand, 3553 available on-line from: cert.sei.cmu.edu:/pub/info/primer, 8 June 3554 1990. 3556 [Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP 3557 Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48, 3558 April 1989. 3560 [Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the 3561 Kerberos Authentication System", Computer Communications Review, 3562 October 1990. 3564 [BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt, 3565 "BS 7799 : 1995 Code of Practice for Information Security 3566 Management", British Standards Institution, London, 54, Effective 15 3567 February 1995. 3569 Based on PD 0003: Price c. GBP 35 3571 The code is divided into 10 sections: security policy, security 3572 organization, assets classification and control, personnel security, 3573 physical and environmental security, computer and network management, 3574 system and access control, system development and maintenance, 3575 business continuity planning, and compliance. 3577 [Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of 3578 Information", Proceedings of the Fifth IFIP International Conference 3579 on Computer Security, IFIP/Sec '88. 3581 [Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition, 3582 Butterworth Publishers, Stoneham, MA, 1987. 3584 [Cooper, 1989] J. Cooper, "Computer and Communications Security: 3585 Strategies for the 1990s", McGraw-Hill, 1989. 3587 [Brand, 1990] R. Brand, "Coping with the Threat of Computer Security 3588 Incidents: A Primer from Prevention through Recovery", R. Brand, 8 3589 June 1990. 3591 As computer security becomes a more important issue in modern 3592 society, it begins to warrant a systematic approach. The vast 3593 majority of the computer security problems and the costs associated 3594 with them can be prevented with simple inexpensive measures. The 3595 most important and cost effective of these measures are available in 3596 the prevention and planning phases. These methods are presented in 3597 this paper, followed by a simplified guide to incident handling and 3598 recovery. Available on-line from: 3599 cert.sei.cmu.edu:/pub/info/primer. 3601 [Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet 3602 Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, 3603 June 1990. 3605 Brief abstract (slight paraphrase from the original abstract): AT&T 3606 maintains a large internal Internet that needs to be protected from 3607 outside attacks, while providing useful services between the two. 3608 This paper describes AT&T's Internet gateway. This gateway passes 3609 mail and many of the common Internet services between AT&T internal 3610 machines and the Internet. This is accomplished without IP 3611 connectivity using a pair of machines: a trusted internal machine and 3612 an untrusted external gateway. These are connected by a private 3613 link. The internal machine provides a few carefully-guarded services 3614 to the external gateway. This configuration helps protect the 3615 internal internet even if the external machine is fully compromised. 3617 This is a very useful and interesting design. Most firewall gateway 3618 systems rely on a system that, if compromised, could allow access to 3619 the machines behind the firewall. Also, most firewall systems 3620 require users who want access to Internet services to have accounts 3621 on the firewall machine. AT&T's design allows AT&T internal internet 3622 users access to the standard services of TELNET and FTP from their 3623 own workstations without accounts on the firewall machine. A very 3624 useful paper that shows how to maintain some of the benefits of 3625 Internet connectivity while still maintaining strong security. 3627 [Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and 3628 Systems Administrators", Addision-Wesley, Reading, MA, 1992. 3630 [Curry, 1990] D. Curry, "Improving the Security of Your UNIX System", 3631 SRI International Report ITSTD-721-FR-90-21, April 1990. 3633 This paper describes measures that you, as a system administrator can 3634 take to make your UNIX system(s) more secure. Oriented primarily at 3635 SunOS 4.x, most of the information covered applies equally well to 3636 any Berkeley UNIX system with or without NFS and/or Yellow Pages 3637 (NIS). Some of the information can also be applied to System V, 3638 although this is not a primary focus of the paper. A very useful 3639 reference, this is also available on the Internet in various 3640 locations, including the directory cert.sei.cmu.edu:/pub/info. 3642 [Farmer and Spafford, 1990] D. Farmer and E. Spafford, "The COPS 3643 Security Checker System", Proceedings of the Summer 1990 USENIX 3644 Conference, Anaheim, CA, Pgs. 165-170, June 1990. 3646 [Farrow, 1991] Rik Farrow, "UNIX Systems Security", Addison-Wesley, 3647 Reading, MA, 1991. 3649 [Fites, Kratz, and Brebner, 1989] M. Fites, P. Kratz, and A. Brebner, 3650 "Control and Security of Computer Information Systems", Computer 3651 Science Press, 1989. 3653 This book serves as a good guide to the issues encountered in forming 3654 computer security policies and procedures. The book is designed as a 3655 textbook for an introductory course in information systems security. 3657 The book is divided into five sections: Risk Management (I), 3658 Safeguards: security and control measures, organizational and 3659 administrative (II), Safeguards: Security and Control Measures, 3660 Technical (III), Legal Environment and Professionalism (IV), and CICA 3661 Computer Control Guidelines (V). 3663 The book is particularly notable for its straight-forward approach to 3664 security, emphasizing that common sense is the first consideration in 3665 designing a security program. The authors note that there is a 3666 tendency to look to more technical solutions to security problems 3667 while overlooking organizational controls which are often cheaper and 3668 much more effective. 298 pages, including references and index. 3670 [Forester and Morrison, 1990] T. Forester, and P. Morrison, "Computer 3671 Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, 3672 Cambridge, MA, 1990. 3674 [Garfinkel and Spafford, 1991] S. Garfinkel, and E. Spafford, 3675 "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2, 3676 May 1991. 3678 Approx 450 pages, $29.95. Orders: 1-800-338-6887 (US & Canada), 3679 1-707-829-0515 (Europe), email: nuts@ora.com 3681 This is one of the most useful books available on Unix security. The 3682 first part of the book covers standard Unix and Unix security basics, 3683 with particular emphasis on passwords. The second section covers 3684 enforcing security on the system. Of particular interest to the 3685 Internet user are the sections on network security, which address 3686 many of the common security problems that afflict Internet Unix 3687 users. Four chapters deal with handling security incidents, and the 3688 book concludes with discussions of encryption, physical security, and 3689 useful checklists and lists of resources. The book lives up to its 3690 name; it is filled with specific references to possible security 3691 holes, files to check, and things to do to improve security. This 3692 book is an excellent complement to this handbook. 3694 [Garfinkel, 1995] S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly & 3695 Associates, Sebastopol, CA, 1996. 3697 [Garfinkel and Spafford, 1996] S. Garfinkel and E. Spafford, 3698 "Practical UNIX and Internet Security", O'Reilly & Associates, 3699 Sebastopol, CA, 1996. 3701 If you thought that the first edition was good, well this is better. 3703 [Greenia, 1989] M. Greenia, "Computer Security Information 3704 Sourcebook", Lexikon Services, Sacramento, CA, 1989. 3706 A manager's guide to computer security. Contains a sourcebook of key 3707 reference materials including access control and computer crimes 3708 bibliographies. 3710 [Hess, Safford, and Pooch] D. Hess, D. Safford, and U. Pooch, "A Unix 3711 Network Protocol Security Study: Network Information Service", Texas 3712 A&M University. 3714 [Hoffman, 1990] L. Hoffman, "Rogue Programs: Viruses, Worms, and 3715 Trojan Horses", Van Nostrand Reinhold, NY, 1990. (384 pages, 3716 includes bibliographical references and index.) 3718 [Hughes, 1995] L. Hughes Jr., "Actually Useful: Internet Security 3719 Techniques", New Riders Publishing, Indianapolis, IN, 1995. 3721 [Howard, 1995] G. Howard, "Introduction to Internet Security: From 3722 Basics to Beyond", Prima Publishing, Rocklin, CA, 1995. 3724 [Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W. 3725 VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly & 3726 Associates, Sebastopol, CA, 1995. 3728 [Johnson and Podesta] D. Johnson, and J. Podesta, "Formulating A 3729 Company Policy on Access to and Use and Disclosure of Electronic Mail 3730 on Company Computer Systems". 3732 A white paper prepared for the EMA, written by two experts in privacy 3733 law. Gives background on the issues, and presents some policy 3734 options. 3736 Available from: The Electronic Mail Association (EMA) 1555 Wilson 3737 Blvd, Suite 555, Arlington, VA, 22209. (703) 522-7111. 3739 [Kaufman, Perlman, and Speciner, 1995] C. Kaufman, R. Perlman, and M. 3740 Speciner, "Network Security: PRIVATE Communication in a PUBLIC 3741 World", Prentice Hall, Englewood Cliffs, NJ, 1995. 3743 A comprehensive guide to the latest advances in computer network 3744 security protocols. 504 pages. 3746 [Kent, 1990] S. Kent, "E-Mail Privacy for the Internet: New Software 3747 and Strict Registration Procedures will be Implemented this Year", 3748 Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January 3749 1990. 3751 [Lu and Sundareshan, 1989] W. Lu and M. Sundareshan, "Secure 3752 Communication in Internet Environments: A Hierarchical Key Management 3753 Scheme for End-to-End Encryption", IEEE Transactions on 3754 Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989. 3756 [Lu and Sundareshan, 1990] W. Lu and M. Sundareshan, "A Model for 3757 Multilevel Security in Computer Networks", IEEE Transactions on 3758 Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990. 3760 [Merkle] R. Merkle, "A Fast Software One Way Hash Function", Journal 3761 of Cryptology, Vol. 3, No. 1. 3763 [Mogel, 1989] Mogul, J., "Simple and Flexible Datagram Access 3764 Controls for UNIX-based Gateways", Digital Western Research 3765 Laboratory Research Report 89/4, March 1989. 3767 [Muffett, 1992] A. Muffett, "Crack Version 4.1: A Sensible Password 3768 Checker for Unix" 3770 [NRC, 1991] National Research Council, "Computers at Risk: Safe 3771 Computing int the Information Age", National Academy Press, 1991. 3773 [Nemeth, et. al, 1995] E. Nemeth, G. Snyder, S. Seebass, and T. Hein, 3774 "UNIX Systems Administration Handbook", Prentice Hall PTR, Englewood 3775 Cliffs, NJ, 2ed. 1995. 3777 Best book on UNIX System Administration. Also addresses UNIX 3778 security in easy understandable way. 3780 [NSA] National Security Agency, "Information Systems Security 3781 Products and Services Catalog", NSA, Quarterly Publication. 3783 NSA's catalogue contains chapter on: Endorsed Cryptographic Products 3784 List; NSA Endorsed Data Encryption Standard (DES) Products List; 3785 Protected Services List; Evaluated Products List; Preferred Products 3786 List; and Endorsed Tools List. 3788 The catalogue is available from the Superintendent of Documents, U.S. 3789 Government Printing Office, Washington, D.C. One may place telephone 3790 orders by calling: (202) 783-3238. 3792 [OTA-CIT-310, 1987] United States Congress, Office of Technology 3793 Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for 3794 Electronic Information", OTA-CIT-310, October 1987. 3796 This report, prepared for congressional committee considering Federal 3797 policy on the protection of electronic information, is interesting 3798 because of the issues it raises regarding the impact of technology 3799 used to protect information. It also serves as a reasonable 3800 introduction to the various encryption and information protection 3801 mechanisms. 185 pages. Available from the U.S. Government Printing 3802 Office. 3804 [OTA-TCT-606] Congress of the United States, Office of Technology 3805 Assessment, "Information Security and Privacy in Network 3806 Environments", OTA-TCT-606, September 1994. 3808 "This report was prepared in response to a request by the Senate 3809 Committee on Governmental Affairs and the House Subcommittee on 3810 Telecommunications and Finance. The report focuses on policy issues 3811 in three areas: 1)national cryptography policy, including federal 3812 information processing standards and export controls; 2)guidance on 3813 safeguarding unclassified information in federal agencies; and 3814 3)legal issues and information security, including electronic 3815 commerce, privacy, and intellectual property." 244 pages. Available 3816 from the U.S. Government Printing Office. 3818 [Palmer and Potter, 1989] I. Palmer, and G. Potter, "Computer 3819 Security Risk Management", Van Nostrand Reinhold, NY, 1989. 3821 [Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall, 3822 Englewood Cliffs, NJ, 1989. 3824 A general textbook in computer security, this book provides an 3825 excellent and very readable introduction to classic computer security 3826 problems and solutions, with a particular emphasis on encryption. 3827 The encryption coverage serves as a good introduction to the subject. 3828 Other topics covered include building secure programs and systems, 3829 security of database, personal computer security, network and 3830 communications security, physical security, risk analysis and 3831 security planning, and legal and ethical issues. 538 pages including 3832 index and bibliography. 3834 [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks 3835 and Conferencing Systems Worldwide", Digital Press, Bedford, MA, 3836 1990. 3838 [Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX 3839 Network Security" 3840 More details in USENIX Third UNIX Security Symposium, September 14-16 3841 1992. 3843 [Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX 3844 Network Security", ARINC Research Corporation, February 18, 1993. 3846 [Russell and Gangemi, 1991] D. Russell and G. Gangemi, "Computer 3847 Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991. 3849 [Shirey, 1990] R. Shirey, "Defense Data Network Security 3850 Architecture", Computer Communication Review, Vol. 20, No. 2, Page 3851 66, 1 April 1990. 3853 [Smith, 1994] D. Smith, "Forming an Incident Response Team", Sixth 3854 Annual Computer Security Incident Handling Workshop, Boston, MA, July 3855 25-29, 1995. 3857 [Smith, 1989] M. Smith, "Common Sense Computer Security: Your 3858 Practical Guide to Preventing Accidental and Deliberate Electronic 3859 Data Loss", McGraw-Hill, New York, NY, 1989. 3861 A general text on computer security and how to access actual effort 3862 based on need. 3864 [Spafford, Keaphy, and Ferbrache, 1989] E. Spafford, K. Heaphy, and 3865 D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism 3866 and Programmed Threats", ADAPSO, 1989. (109 pages.) 3868 This is a good general reference on computer viruses and related 3869 concerns. In addition to describing viruses in some detail, it also 3870 covers more general security issues, legal recourse in case of 3871 security problems, and includes lists of laws, journals focused on 3872 computers security, and other security-related resources. 3874 Available from: ADAPSO, 1300 N. 17th St, Suite 300, Arlington VA 3875 22209. (703) 522-5055. 3877 [Stallings1, 1995] W. Stallings, "Internet Security Handbook", IDG 3878 Books, Foster City CA, 1995. 3880 [Stallings2, 1995] W. Stallings, "Network and InterNetwork Security", 3881 Prentice Hall, , 1995. 3883 [Stallings3, 1995] W. Stallings, "Protect Your Privacy: A Guide for 3884 PGP Users" PTR Prentice Hall, 1995. 3886 [Stool, 1988] C. Stoll, "Stalking the Wily Hacker", Communications of 3887 the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988. 3889 This article describes some of the technical means used to trace the 3890 intruder that was later chronicled in "Cuckoo's Egg" (see below). 3892 [Stool, 1989] C. Stoll, "The Cuckoo's Egg", ISBN 00385-24946-2, 3893 Doubleday, 1989. 3895 Clifford Stoll, an astronomer turned UNIX System Administrator, 3896 recounts an exciting, true story of how he tracked a computer 3897 intruder through the maze of American military and research networks. 3898 This book is easy to understand and can serve as an interesting 3899 introduction to the world of networking. Jon Postel says in a book 3900 review, "[this book] ... is absolutely essential reading for anyone 3901 that uses or operates any computer connected to the Internet or any 3902 other computer network." 3904 [USENIX, 1988] USENIX, "USENIX Proceedings: UNIX Security Workshop", 3905 Portland, OR, August 29-30, 1988. 3907 [USENIX, 1990] USENIX, "USENIX Proceedings: UNIX Security II 3908 Workshop", Portland, OR, August 27-28, 1990. 3910 [USENIX, 1992] USENIX, "USENIX Symposium Proceedings: UNIX Security 3911 III", Baltimore, MD, September 14-16, 1992. 3913 [USENIX, 1993] USENIX, "USENIX Symposium Proceedings: UNIX Security 3914 IV", Santa Clara, CA, October 4-6, 1993. 3916 [USENIX, 1995] USENIX, "The Fifth USENIX UNIX Security Symposium", 3917 Salt Lake City, UT, June 5-7, 1995. 3919 [Vallabhaneni, 1989] S. Vallabhaneni, "Auditing Computer Security: A 3920 Manual with Case Studies", Wiley, New York, NY, 1989. 3922 10.3 Ethics 3924 [CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR 3925 Statement on the Computer Virus", CPSR, Communications of the ACM, 3926 Vol. 32, No. 6, Pg. 699, June 1989. 3928 This memo is a statement on the Internet Computer Virus by the 3929 Computer Professionals for Social Responsibility (CPSR). 3931 [Denning, 1990] P. Denning, Editor, "Computers Under Attack: 3932 Intruders, Worms, and Viruses", ACM Press, 1990. 3934 A collection of 40 pieces divided into six sections: the emergence of 3935 worldwide computer networks, electronic break-ins, worms, viruses, 3936 counterculture (articles examining the world of the "hacker"), and 3937 finally a section discussing social, legal, and ethical 3938 considerations. 3940 A thoughtful collection that addresses the phenomenon of attacks on 3941 computers. This includes a number of previously published articles 3942 and some new ones. The previously published ones are well chosen, 3943 and include some references that might be otherwise hard to obtain. 3944 This book is a key reference to computer security threats that have 3945 generated much of the concern over computer security in recent years. 3947 [Ermann, Willians, and Gutierrez, 1990] D. Ermann, M. Williams, and 3948 C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford 3949 University Press, NY, 1990. (376 pages, includes bibliographical 3950 references). 3952 [Foster and Morrision, 1990] T. Forester, and P. Morrison, "Computer 3953 Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, 3954 Cambridge, MA, 1990. (192 pages including index.) 3956 From the preface: "The aim of this book is two-fold: (1) to describe 3957 some of the problems created by society by computers, and (2) to show 3958 how these problems present ethical dilemmas for computers 3959 professionals and computer users. 3961 The problems created by computers arise, in turn, from two main 3962 sources: from hardware and software malfunctions and from misuse by 3963 human beings. We argue that computer systems by their very nature 3964 are insecure, unreliable, and unpredictable -- and that society has 3965 yet to come to terms with the consequences. We also seek to show how 3966 society has become newly vulnerable to human misuse of computers in 3967 the form of computer crime, software theft, hacking, the creation of 3968 viruses, invasions of privacy, and so on." 3970 The eight chapters include "Computer Crime", "Software Theft", 3971 "Hacking and Viruses", "Unreliable Computers", "The Invasion of 3972 Privacy", "AI and Expert Systems", and "Computerizing the Workplace." 3973 Includes extensive notes on sources and an index. 3975 [Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and 3976 Social Implications of Computer Networking", Westview Press, Boulder, 3977 CO, 1989. 3979 [IAB-RFC1087, 89] Internet Activities Board, "Ethics and the 3980 Internet", RFC 1087, IAB, January 1989. Also appears in the 3981 Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989. 3983 This memo is a statement of policy by the Internet Activities Board 3984 (IAB) concerning the proper use of the resources of the Internet. 3985 Available on-line on host ftp.nisc.sri.com, directory rfc, filename 3986 rfc1087.txt. Also available on host nis.nsf.net, directory RFC, 3987 filename RFC1087.TXT-1. 3989 [Martin and Schinzinger, 1989] M. Martin, and R. Schinzinger, "Ethics 3990 in Engineering", McGraw Hill, 2nd Edition, 1989. 3992 [MIT, 1989] Massachusetts Institute of Technology, "Teaching Students 3993 About Responsible Use of Computers", MIT, 1985-1986. Also reprinted 3994 in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena 3995 Project, MIT, June 1989. This memo is a statement of policy by the 3996 Massachusetts Institute of Technology (MIT) on the responsible use of 3997 computers. 3999 [NIST, 1989] National Institute of Standards and Technology, 4000 "Computer Viruses and Related Threats: A Management Guide", NIST 4001 Special Publication 500-166, August 1989. 4003 [NSF, 1988] National Science Foundation, "NSF Poses Code of 4004 Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. 4005 688, June 1989. Also appears in the minutes of the regular meeting 4006 of the Division Advisory Panel for Networking and Communications 4007 Research and Infrastructure, Dave Farber, Chair, November 29-30, 4008 1988. 4010 This memo is a statement of policy by the National Science Foundation 4011 (NSF) concerning the ethical use of the Internet. 4013 [Parker, Swope, and Baker, 1990] D. Parker, S. Swope, and B. Baker, 4014 "Ethical Conflicts: Information and Computer Science, Technology and 4015 Business", QED Information Sciences, Inc., Wellesley, MA. (245 4016 pages). 4018 Additional publications on Ethics: 4020 The University of New Mexico (UNM) 4022 The UNM has a collection of ethics documents. Included are 4023 legislation from several states and policies from many 4024 institutions. 4026 Access is via FTP, IP address ariel.umn.edu. Look in the 4027 directory /ethics. 4029 10.4 Firewalls 4031 [Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings 4032 of the Third Usenix Security Symposium, Baltimore, MD. September, 4033 1992. 4035 [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet 4036 Filtering", USENIX: Proceedings of the Third UNIX Security Symposium, 4037 Baltimore, MD, September 1992. 4039 [Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building 4040 Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995. 4042 [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker 4043 is Lured, Endured, and Studied", AT&T Bell Laboratories. 4045 [Cheswick2] W. Cheswick, "The Design of a Secure Internet Gateway", 4046 Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990. 4048 [Cheswick and Bellovin, 1994] W. Cheswick and S. Bellovin, "Firewalls 4049 and Internet Security: Repelling the Wily Hacker", Addision-Wesley, 4050 Reading, MA, 1994. 4052 Landmark book on Firewalls. A must for anyone designing, installing, 4053 managing firewalls. 4055 [NCSA, 1995] NCSA, "NCSA Firewall Policy Guide", 1995. 4057 [NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96 4058 Proceedings", 1996. 4060 [Ranum, 1992] M. Ranum, "A Network Firewall", Digital Equipment 4061 Corporation Washington Open Systems Resource Center, June 12, 1992. 4063 [Ranum, 1992] M. Ranum, "An Internet Firewall", Proceedings of World 4064 Conference on Systems Management and Security, 1992. 4066 Available ftp://decuac.dec.com/pub/docs/firewall/firewall.ps 4068 [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993. 4070 A good start for those implementing or installing firewalls. 4071 Available ftp://ftp.tis.com 4073 [Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and 4074 Methods for Internet Firewalls", Trustest Information Systems, 1994. 4076 Available ftp://ftp.tis.com 4078 [Treese and Wolman, 1993] G. Treese and A. Wolman, "X Through the 4079 Firewall, and Other Applications Relays", Digital Equipment 4080 Corporation, Cambridge Research Laboratory, CRL 93/10, May 3, 1993. 4082 [Venema] W. Venema, "TCP WRAPPER: Network monitoring, access control, 4083 and booby traps", Mathematics and Computing Science, Eindhoven 4084 University of Technology, The Netherlands. 4086 Available ftp://ftp.win.tue.nl/pub/security 4088 10.5 Internet Worms, Hackers, Computer Viruses, etc 4090 [Barrett, 1996] D. Barrett, "Bandits on the Information 4091 Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996. 4093 [Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and 4094 the Vulnerability of National Telecommunications Networks to Computer 4095 Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989. 4097 Testimonial statement of Jack L. Brock, Director, U. S. Government 4098 Information before the Subcommittee on Telecommunications and 4099 Finance, Committee on Energy and 4100 Commerce, House of Representatives. 4102 [Eichin and Rochlis, 1989] M. Eichin, and J. Rochlis, "With 4103 Microscope and Tweezers: An Analysis of the Internet Virus of 4104 November 1988", Massachusetts Institute of Technology, February 1989. 4106 Provides a detailed dissection of the worm program. The paper 4107 discusses the major points of the worm program then reviews 4108 strategies, chronology, lessons and open issues, Acknowledgments; 4109 also included are a detailed appendix on the worm program subroutine 4110 by subroutine, an appendix on the cast of characters, and a reference 4111 section. 4113 [Eisenbery, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D. 4114 Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell 4115 University, 6 February 1989. 4117 A Cornell University Report presented to the Provost of the 4118 University on 6 February 1989 on the Internet Worm. 4120 [Fites, Johnson, and Kratz, 1992] Fites, Johnson, and Kratz, "The 4121 Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992. 4123 [GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer 4124 Security - Virus Highlights Need for Improved Internet Management", 4125 United States General Accounting Office, Washington, DC, 1989. 4127 This 36 page report (GAO/IMTEC-89-57), by the U.S. Government 4128 Accounting Office, describes the Internet worm and its effects. It 4129 gives a good overview of the various U.S. agencies involved in the 4130 Internet today and their concerns vis-a-vis computer security and 4131 networking. 4133 Available on-line on host nnsc.nsf.net, directory pub, filename 4134 GAO_RPT; and on nis.nsf.net, directory nsfnet, filename GAO_RPT.TXT. 4136 [Goodell, 1996] J. Goodell, "The Cyberthief and the Samurai: The True 4137 Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell 4138 Publishing, 328pp, 1996. 4140 [Hafner and Markoff, 1991] K. Hafner and J. Markoff, "Cyberpunk: 4141 Outlaws and Hackers on the Computer Frontier", Touchstone, Simon & 4142 Schuster, 1991. 4144 [Kane, 1994] P. Kane, "PC Security and Virus Protection Handbook: The 4145 Ongoing War Against Information Sabotage", M&T Books, 1994. 4147 [IVPC, 1996] IVPC, "International Virus Prevention Conference '96 4148 Proceedings", NCSA, 1996. 4150 [Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution", 4151 Delta, 1984. 4153 The Original. 4155 [NCSA, 1995] NCSA, "NCSA's Corporate Computer Virus Prevention Policy 4156 Model", NCSA, 1995. 4158 [Littleman, 1996] J. Littleman, "The Fugitive Game: Online with Kevin 4159 Mitnick", Little, Brown, Boston, MA. 333p, 1996. 4161 [Reynolds-RFC1135, 1989] The Helminthiasis of the Internet, RFC 1135, 4162 USC/Information Sciences Institute, Marina del Rey, CA, December 4163 1989. 4165 This report looks back at the helminthiasis (infestation with, or 4166 disease caused by parasitic worms) of the Internet that was unleashed 4167 the evening of 2 November 1988. This document provides a glimpse at 4168 the infection,its festering, and cure. The impact of the worm on the 4169 Internet community, ethics statements, the role of the news media, 4170 crime in the computer world, and future prevention is discussed. A 4171 documentation review presents four publications that describe in 4172 detail this particular parasitic computer program. Reference and 4173 bibliography sections are also included. Available on-line on host 4174 ftp.nisc.sri.com directory rfc, filename rfc1135.txt. Also available 4175 on host nis.nsf.net, directory RFC, filename RFC1135.TXT-1. 4177 [Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989 4178 Winter USENIX Conference, Usenix Association, San Diego, CA, February 4179 1989. 4181 Details are presented as a "walk through" of this particular worm 4182 program. The paper opened with an abstract, introduction, detailed 4183 chronology of events upon the discovery of the worm, an overview, the 4184 internals of the worm, personal opinions, and conclusion. 4186 [Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit 4187 and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw- 4188 by the Man Who Did It", Hyperion, 324p, 1996. 4190 [Slatalla and Quittner, 1995] M. Slatalla and J. Quittner, "Masters 4191 of Deception: The Gang that Ruled Cyberspace", Harper Collins 4192 Publishers, 1995. 4194 [Spafford, 1988] E. Spafford, "The Internet Worm Program: An 4195 Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM, 4196 January 1989. Also issued as Purdue CS Technical Report CSD-TR-823, 4197 28 November 1988. 4199 Describes the infection of the Internet as a worm program that 4200 exploited flaws in utility programs in UNIX based systems. The 4201 report gives a detailed description of the components of the worm 4202 program: data and functions. Spafford focuses his study on two 4203 completely independent reverse-compilations of the worm and a version 4204 disassembled to VAX assembly language. 4206 [Spafford, 1989] G. Spafford, "An Analysis of the Internet Worm", 4207 Proceedings of the European Software Engineering Conference 1989, 4208 Warwick England, September 1989. Proceedings published by Springer- 4209 Verlag as: Lecture Notes in Computer Science #387. Also issued as 4210 Purdue Technical Report #CSD-TR-933. 4212 10.6 National Computer Security Center (NCSC) 4214 All NCSC publications, approved for public release, are available 4215 from the NCSC Superintendent of Documents. 4217 NCSC = National Computer Security Center 9800 Savage Road Ft Meade, 4218 MD 20755-6000 4220 CSC = Computer Security Center: an older name for the NCSC 4222 NTISS = National Telecommunications and Information Systems Security 4223 NTISS Committee, National Security Agency Ft Meade, MD 20755-6000 4225 [CSC-STD-002-85, 1985] Department of Defense, "Password Management 4226 Guideline", CSC-STD-002-85, 12 April 1985, 31 pages. 4228 The security provided by a password system depends on the passwords 4229 being kept secret at all times. Thus, a password is vulnerable to 4230 compromise whenever it is used, stored, or even known. In a 4231 password-based authentication mechanism implemented on an ADP system, 4232 passwords are vulnerable to compromise due to five essential aspects 4233 of the password system: 1) a password must be initially assigned to a 4234 user when enrolled on the ADP system; 2) a user's password must be 4235 changed periodically; 3) the ADP system must maintain a 'password 4236 database'; 4) users must remember their passwords; and 5) users must 4237 enter their passwords into the ADP system at authentication time. 4238 This guideline prescribes steps to be taken to minimize the 4239 vulnerability of passwords in each of these circumstances. 4241 [NCSC-TG-001, 1988] NCSC, "A Guide to Understanding AUDIT in Trusted 4242 Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages. 4244 Audit trails are used to detect and deter penetration of a computer 4245 system and to reveal usage that identifies misuse. At the discretion 4246 of the auditor, audit trails may be limited to specific events or may 4247 encompass all of the activities on a system. Although not required 4248 by the criteria, it should be possible for the target of the audit 4249 mechanism to be either a subject or an object. That is to say, the 4250 audit mechanism should be capable of monitoring every time John 4251 accessed the system as well as every time the nuclear reactor file 4252 was accessed; and likewise every time John accessed the nuclear 4253 reactor file. 4255 [NCSC-TG-003, 1987] NCSC, "A Guide to Understanding DISCRETIONARY 4256 ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30 4257 September 1987, 29 pages. 4259 Discretionary control is the most common type of access control 4260 mechanism implemented in computer systems today. The basis of this 4261 kind of security is that an individual user, or program operating on 4262 the user's behalf, is allowed to specify explicitly the types of 4263 access other users (or programs executing on their behalf) may have 4264 to information under the user's control. [...] Discretionary 4265 controls are not a replacement for mandatory controls. In any 4266 environment in which information is protected, discretionary security 4267 provides for a finer granularity of control within the overall 4268 constraints of the mandatory policy. 4270 [NCSC-TG-006, 1988] NCSC, "A Guide to Understanding CONFIGURATION 4271 MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March 4272 1988, 31 pages. 4274 Configuration management consists of four separate tasks: 4275 identification, control, status accounting, and auditing. For every 4276 change that is made to an automated data processing (ADP) system, the 4277 design and requirements of the changed version of the system should 4278 be identified. The control task of configuration management is 4279 performed by subjecting every change to documentation, hardware, and 4280 software/firmware to review and approval by an authorized authority. 4281 Configuration status accounting is responsible for recording and 4282 reporting on the configuration of the product throughout the change. 4283 Finally, though the process of a configuration audit, the completed 4284 change can be verified to be functionally correct, and for trusted 4285 systems, consistent with the security policy of the system. 4287 [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation 4288 Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58 4289 pages. 4291 This document provides guidance to users, managers, security 4292 officers, and procurement officers of Office Automation Systems. 4293 Areas addressed include: physical security, personnel security, 4294 procedural security, hardware/software security, emanations security 4295 (TEMPEST), and communications security for stand-alone OA Systems, OA 4296 Systems used as terminals connected to mainframe computer systems, 4297 and OA Systems used as hosts in a Local Area Network (LAN). 4298 Differentiation is made between those Office Automation Systems 4299 equipped with removable storage media only (e.g., floppy disks, 4300 cassette tapes, removable hard disks) and those Office Automation 4301 Systems equipped with fixed media (e.g., Winchester disks). 4303 Additional NCSC Publications: 4305 [NCSC-TG-004, 1988] National Computer Security Center, "Glossary of 4306 Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988. 4308 [NCSC-TCSEC, 1985] National Computer Security Center, "Trusted 4309 Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001- 4310 83, NCSC, December 1985. 4312 [NCSC-CSC-STD-003-85, 1985] National Computer Security Center, 4313 "Guidance for Applying the Department of Defense Trusted Computer 4314 System Evaluation Criteria in Specific Environments", CSC-STD-003-85, 4315 NCSC, 25 June 1985. 4317 [NCSC-STD-004-85, 1985] National Computer Security Center, "Technical 4318 Rationale Behind CSC-STD-003-85: Computer Security Requirements", 4319 CSC-STD-004-85, NCSC, 25 June 1985. 4321 [NCSC-STD-005-85, 1985] National Computer Security Center, "Magnetic 4322 Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November 4323 1985. 4325 This guideline is tagged as a "For Official Use Only" exemption under 4326 Section 6, Public Law 86-36 (50 U.S. Code 402). Distribution 4327 authorized of U.S. Government agencies and their contractors to 4328 protect unclassified technical, operational, or administrative data 4329 relating to operations of the National Security Agency. 4331 [NCSC-89-660-P, 1990] National Computer Security Center, "Guidelines 4332 for Formal Verification Systems", Shipping list no.: 89-660-P, The 4333 Center, Fort George G. Meade, MD, 1 April 1990. 4335 [NCSC-89-254-P, 1988] National Computer Security Center, "Glossary of 4336 Computer Security Terms", Shipping list no.: 89-254-P, The Center, 4337 Fort George G. Meade, MD, 21 October 1988. 4339 [NCSC-TRUSIX, 1990] National Computer Security Center, "Trusted UNIX 4340 Working Group (TRUSIX) rationale for selecting access control list 4341 features for the UNIX system", Shipping list no.: 90-076-P, The 4342 Center, Fort George G. Meade, MD, 1990. 4344 [NCSC-TG-005, 1987] National Computer Security Center, "Trusted 4345 Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987. 4347 [NCSC-C1-001-89, 1989] Tinto, M., "Computer Viruses: Prevention, 4348 Detection, and Treatment", National Computer Security Center C1 4349 Technical Report C1-001-89, June 1989. 4351 [NCSC Conference, 1989] National Computer Security Conference, "12th 4352 National Computer Security Conference: Baltimore Convention Center, 4353 Baltimore, MD, 10-13 October, 1989: Information Systems Security, 4354 Solutions for Today - Concepts for Tomorrow", National Institute of 4355 Standards and National Computer Security Center, 1989. 4357 10.7 Security Checklists 4359 [Aucion, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery", 4360 Computers in Libraries, Vol. 9, No. 2, Pg. 4, 1 February 1989. 4362 [Wood, et.al., 1987] C. Wood, W. Banks, S. Guarro, A. Garcia, V. 4363 Hampel, and H. Sartorio, "Computer Security: A Comprehensive 4364 Controls Checklist", John Wiley and Sons, Interscience Publication, 4365 1987. 4367 10.8 Disaster Recovery 4369 [Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks, 4370 Telecommunications and Data Communications", McGraw-Hill, 1992. 4372 [Lewis, 1996] S. Lewis, "Disaster Recovery Yellow Pages", The Systems 4373 Audit Group, 1996. 4375 [Wrobel, 1993] L. Wrobel, "Writing Disaster Recovery Plans for 4376 Telecommunications Networks and LANS", Artech House, 1993. 4378 10.9 Additional Publications 4379 10.9.1 Defense Data Network's Network Information Center (DDN NIC) 4381 The DDN NIC maintains DDN Security bulletins and DDN Management 4382 bulletins online on the machine: NIC.DDN.MIL. They are available via 4383 anonymous FTP. The DDN Security bulletins are in the directory: SCC, 4384 and the DDN Management bulletins are in the directory: DDN-NEWS. 4386 For additional information, you may send a message to: 4387 NIC@NIC.DDN.MIL, or call the DDN NIC at: 1-800-235-3155. 4389 [DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem 4390 Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 4391 November 1988. 4393 A Defense Data Network Management Bulletin announcement on the 4.2bsd 4394 and 4.3bsd software fixes to the Internet worm. 4396 [DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin 4397 03", DDN Security Coordination Center, 17 October 1989. 4399 10.9.2 IEEE Proceedings 4401 [IEEE] "Proceedings of the IEEE Symposium on Security and Privacy", 4402 published annually. 4404 IEEE Proceedings are available from: 4406 Computer Society of the IEEE P.O. Box 80452 Worldway Postal Center 4407 Los Angeles, CA 90080 4409 10.9.3 Other Publications: 4411 Computer Law and Tax Report Computers and Security Security 4412 Management Magazine Journal of Information Systems Management Data 4413 Processing & Communications Security SIG Security, Audit & Control 4414 Review 4416 Editor Information 4418 Barbara Y. Fraser 4419 Software Engineering Institute 4420 Carnegie Mellon University 4421 5000 Forbes Avenue 4422 Pittsburgh, PA 15213 4424 Phone: (412) 268-5010 4425 Fax: (412) 268-6989 4426 email: byf@cert.org