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