idnits 2.17.1 draft-ietf-ssh-handbook-02.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-24) 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 51 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 52 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. ** There are 76 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 894 has weird spacing: '...between apply...' == Line 1334 has weird spacing: '...onsider keepi...' == Line 1548 has weird spacing: '...ingency plan...' == Line 1615 has weird spacing: '...evel of prote...' == Line 2211 has weird spacing: '...code or can ...' == (5 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1996) is 10267 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 section? '1' on line 126 looks like a reference -- Missing reference section? '3' on line 188 looks like a reference -- Missing reference section? 'FITES' on line 188 looks like a reference -- Missing reference section? '16' on line 188 looks like a reference -- Missing reference section? 'PFLEEGER' on line 188 looks like a reference -- Missing reference section? '10' on line 2151 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 8 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 March 1996 5 Site Security Handbook 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Table of Contents 28 1. Introduction.................................................... 2 29 1.1 Purpose of this Work............................................ 2 30 1.2 Audience........................................................ 2 31 1.3 Definitions..................................................... 3 32 1.4 Related Work.................................................... 3 33 1.5 Basic Approach.................................................. 3 34 1.6 Risk Assessment................................................. 4 35 2. Security Policies............................................... 5 36 2.1 What is a Computer Security Policy and Why Have One?............ 5 37 2.2 What Makes a Good Computer Security Policy?..................... 7 38 3. Architecture.................................................... 9 39 3.1 Objectives...................................................... 9 40 3.2 Network and Service Configurations.............................. 12 41 3.3 Firewalls....................................................... 16 42 4. Security Services and Procedures................................ 19 43 4.1 Authentication.................................................. 19 44 4.2 Confidentiality................................................. 22 45 4.3 Integrity....................................................... 22 46 4.4 Authorization................................................... 23 47 4.5 Access.......................................................... 23 48 4.6 Auditing........................................................ 27 49 4.7 Securing Backups................................................ 29 50 5. Security Incident Handling...................................... 29 51 5.1 Preparing and Planning for Incident Handling.................... 31 52 5.2 Notification and Points of Contact.............................. 33 53 5.3 Identifying an Incident......................................... 39 54 5.4 Handling an Incident............................................ 41 55 5.5 Aftermath of an Incident........................................ 46 56 5.6 Responsibilities................................................ 47 57 6. Ongoing Activities.............................................. 48 58 Appendix A1 Tools and Locations..................................... 49 59 Appendix A2 Mailing Lists and Other Resources....................... 50 60 References........................................................... ? 61 Annotated Bibliography............................................... ? 63 1. INTRODUCTION 65 This document provides guidance to system and network administrators 66 on how to address security issues within the Internet community. It 67 builds on the foundation provided in RFC 1244 and is the collective 68 work of a number of contributing authors. Those authors include: 69 Jules P. Aronson, Nevil Brownlee, Joao Nuno Ferreira, Erik Gutmann, 70 Klaus-Peter Kossakowski, Edward.P.Lewis, Gary Malkin, Russ Mundy, 71 Philip J. Nesser, and Michael S. Ramsey. 73 A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook, 74 CICnet, for their vision, leadership, and effort in the creation of 75 the first version of this handbook. It is the working group's sincere 76 hope that this version will be as helpful to the community as the 77 earlier one was. 79 1.1 Purpose of this Work 81 This handbook is a guide to setting computer security policies and 82 procedures for sites that have systems on the Internet. This guide 83 lists issues and factors that a site must consider when setting their 84 own policies. It makes some recommendations and provides discussions 85 of relevant areas. 87 This guide is only a framework for setting security policies and 88 procedures. In order to have an effective set of policies and 89 procedures, a site will have to make many decisions, gain agreement, 90 and then communicate and implement the policies. 92 1.2 Audience 94 The audience for this document are system and network administrators, 95 and decision makers ( typically "middle management") at sites. For 96 brevity, we will use the term "administrator" throughout this 97 document to refer to system and network administrators. 99 This document is not directed at programmers or those trying to 100 create secure programs or systems. The focus of this document is on 101 the policies and procedures that need to be in place to support any 102 technical security features that a site may be implementing. 104 The primary audience for this work are sites that are members of the 105 Internet community. However, this document should be useful to any 106 site that allows communication with other sites. As a general guide 107 to security policies, this document may also be useful to sites with 108 isolated systems. 110 1.3 Definitions 112 For the purposes of this guide, a "site" is any organization that 113 owns computers or network-related resources. These resources may 114 include host computers that users use, routers, terminal servers, 115 PC's or other devices that have access to the Internet. A site may 116 be a end user of Internet services or a service provider such as a 117 regional network. However, most of the focus of this guide is on 118 those end users of Internet services. 120 We assume that the site has the ability to set policies and 121 procedures for itself with the concurrence and support from those who 122 actually own the resources. 124 The "Internet" is those set of networks and machines that use the 125 TCP/IP protocol suite, connected through gateways, and sharing a 126 common name and address spaces [1]. 128 The term "system administrator" is used to cover all those who are 129 responsible for the day-to-day operation of resources. This may be a 130 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 incident response team (IRT), including 142 a template that is useful to IRTs when descibing their policies and 143 services. 145 1.5 Basic Approach 147 This guide is written to provide basic guidance in developing a 148 security plan for your site. One generally accepted approach to this 149 is suggested by Fites, et. al. [ref] and includes the following 150 steps: 152 (1) Identify what you are trying to protect 153 (2) Determine what you are trying to protect it from 154 (3) Determine how likely the threats are 155 (4) Implement meansures which will protect your assets in a cost- 156 effective manner. 157 (5) Review the process continuously, and make improvements each time 158 a weakness is found. 160 Most of this document is focused on item 4 above, but the other steps 161 cannot be avoided if an effective plan is to be established at your 162 site. One old truism in security is that the cost of protecting 163 yourself against a threat should be less than the cost recovering if 164 the threat were to strike you. Without reasonable knowledge of what 165 you are protecting and what the likely threats are, following this 166 rule could be difficult. 168 1.6 Risk Assessment 170 1.6.1 General Discussion 172 One of the most important reasons for creating a computer security 173 policy is to ensure that efforts spent on security yield cost 174 effective benefits. Although this may seem obvious, it is possible 175 to be mislead about where the effort is needed. As an example, there 176 is a great deal of publicity about intruders on computers systems; 177 yet most surveys of computer security show that for most 178 organizations, the actual loss from "insiders" is much greater. 180 Risk analysis involves determining what you need to protect, what you 181 need to protect it from, and how to protect it. Is is the process of 182 examining all of your risks, and ranking those risks by level of 183 severity. This process involves making cost-effective decisions on 184 what you want to protect. As mentioned above, you should probably 185 not spend more to protect something than it is actually worth. 187 A full treatment of risk analysis is outside the scope of this 188 document. [3, FITES] and [16, PFLEEGER] provide introductions to 189 this topic. However, there are two elements of a risk analysis that 190 will be briefly covered in the next two sections: 192 (1) Identifying the assets 193 (2) Identifying the threats 195 For each asset, the basic goals of security are availability, 196 confidentiality, and integrity. Each threat should be examined with 197 an eye to how the threat could affect these areas. 199 1.6.2 Identifying the Assets 201 One step in a risk analysis is to identify all the things that need 202 to be protected. Some things are obvious, like valuable proprietary 203 information or intellectual property and all the various pieces of 204 hardware, but some are overlooked, such as the people who actually 205 use the systems. The essential point is to list all things that could 206 be affected by a security problem. 208 One list of categories is suggested by Pfleeger [16, PFLEEGER, page 209 459]; this list is adapted from that source: 211 (1) Hardware: cpus, boards, keyboards, terminals, 212 workstations, personal computers, printers, disk 213 drives, communication lines, terminal servers, routers. 215 (2) Software: source programs, object programs, 216 utilities, diagnostic programs, operating systems, 217 communication programs. 219 (3) Data: during execution, stored on-line, archived off-line, 220 backups, audit logs, databases, in transit over 221 communication media. 223 (4) People: users, people needed to run systems. 225 (5) Documentation: on programs, hardware, systems, local 226 administrative procedures. 228 (6) Supplies: paper, forms, ribbons, magnetic media. 230 1.6.3 Identifying the Threats 232 Once the assets requiring protection are identified, it is necessary 233 to identify threats to those assests. The threats can then be 234 examined to determine what potential for loss exists. It helps to 235 consider from what threats you are trying to protect your assets. 236 The following are classic threats that should be considered. 237 Depending on your site, there will be more specific threats that 238 should be identified and addressed. 240 (1) Unauthorized access to resources and/or information 241 (2) Disclosure of information 242 (3) Denial of service 244 2. SECURITY POLICIES 246 2.1 What is a Computer Security Policy and Why Have One? 248 The security-related decisions you make, or fail to make, as network 249 administrator largely determines how secure or insecure your network 250 is, how much functionality your network offers, and how easy your 251 network is to use. However, you cannot make good decisions about 252 security without first determining what your security goals are. 253 Until you determine what your security goals are, you cannot make 254 effective use of any collection of security tools because you simply 255 will not know what to check for and what restrictions to impose. 257 For example, your goals will probably be very different from the 258 goals of a product vendor. Vendors are trying to make configuration 259 and operation of their products as simple as possible, which implies 260 that the default configurations will often be as open (i.e., 261 insecure) as possible. While this does make it easier to install new 262 products, it also leaves access to those systems, and other systems 263 through them, open to any user who wanders by. 265 Your goals will be largely determined by the following key tradeoffs: 267 (1) services offered vs. security provided - 268 Each service offered to users carries its own security risks. 269 For some services the risk outweighs the benefit of the service 270 and the administrator may choose to eliminate the service rather 271 than try to secure it. 273 (2) ease of use vs. security - 274 The easiest system to use would allow acces to any user and require 275 no passwords; that is, there would be no security. Requiring 276 passwords makes the system a little less convenient, but more secure. 277 Requiring device-generated one-time passwords makes the system even 278 more difficult to use, but much more secure. 280 (3) cost of security vs. risk of loss - 281 There are many different costs to security: monetary (i.e., the 282 cost of purchasing security hardware and software like firewalls 283 and one-time password generators), performance (i.e., encryption 284 and decryption take time), and ease of use (as mentioned above). 285 There are also many levels of risk: loss of privacy (i.e., the 286 reading of information by unauthorized individuals), loss of 287 data (i.e., the corruption or erasure of information), and the 288 loss of service (e.g., the filling of data storage space, usage 289 of computational resources, and denial of network access). Each 290 type of cost must be weighed against each type of loss. 292 Your goals should be communicated to all users, operations staff, and 293 managers through a set of security rules, called a "computer security 294 policy." 296 2.1.1 Definition of a Computer Security Policy 298 A computer security policy is a formal statement of the rules by 299 which people who are given access to an organization's technology and 300 information assets must abide. 302 2.1.2 Purposes of a Computer Security Policy 304 The main purpose of a computer security policy is to inform users, 305 staff and managers of their obligatory requirements for protecting 306 technology and information assets. The policy should specify the 307 mechanisms through which these requirements can be met. Another 308 purpose is to provide a baseline from which to acquire, configure and 309 audit computer systems and networks for compliance with the policy. 310 Therefore an attempt to use a set of security tools in the absence of 311 at least an implied security policy is meaningless. 313 An Appropriate Use Policy (AUP) may also be part of a security 314 policy. It should spell out what users may and may not do on the 315 various components of the system, including the type of traffic 316 allowed on the networks. The AUP should be as explicit as possible 317 to avoid ambiguity or misunderstanding. For example, an AUP might 318 list any prohibited newsgroups. 320 2.1.3 Who Should be Involved When Forming Policy? 322 In order for a security policy to be appropriate and effective, it 323 needs to have the acceptance and support of all levels of employees 324 within the organization. The following is a list of individuals who 325 should be involved in the creation and review of security policy 326 documents: 328 (1) site security administrator 329 (2) legal counsel 330 (3) computing center personnel 331 (4) network administrators of large user groups within the organization 332 (e.g., business divisions, computer science department within a 333 university, etc.) 334 (5) security incident response team 335 (6) representatives of the user groups affected by the security policy 337 The list of above is representative of many organizations, but is not 338 necessarily comprehensive. The idea is to bring in representation 339 from key stakeholders, management who have budget and policy 340 authority, technical staff who know what can and cannot be supported, 341 and legal counsel who know the legal ramifications of various policy 342 choices. In some organizations, it may be appropriate to include 343 audit personel. Involving this group is important if resulting 344 policy statements are to reach the broadest possible acceptance. 346 2.2 What Makes a Good Computer Security Policy? 348 The characteristics of a good security policy are: 350 (1) It must be implementable through system administration 351 procedures, publishing of acceptable use guidelines, or other 352 appropriate methods. 354 (2) It must be enforcible with security tools, where appropriate, 355 and with sanctions, where actual prevention is not technically 356 feasible. 358 (3) It must clearly define the areas of responsibility for the 359 users, staff, and administrators. 361 The components of a good security policy include: 363 (1) Computer Technology Purchasing Guidelines which specify required, 364 or preferred, security features. These should supplement existing 365 purchasing policies and guidelines. 367 (2) A Privacy Policy which defines reasonable expectations of privacy 368 regarding such issues as monitoring of electronic mail, logging of 369 keystrokes, and access to users' files. 371 (3) An Access Policy which defines access rights and privileges to 372 protect assets from loss or disclosure by specifying acceptable use 373 guidelines for users, operations staff, and management. It should 374 provide guidelines for external connections, data communications, 375 connecting devices to a network, and adding new software to 376 systems. It should also specify any required notification messages 377 (e.g., connect messages should provide warnings about authorized 378 usage and line monitoring, and not simply say "Welcome"). 380 (4) An Accountability Policy which defines the responsibilities of users, 381 operations staff, and management. It should specify an audit 382 capability, and provide incident handling guidelines (i.e., what to 383 do and who to contact if a possible intrusion is detected). 385 (5) An Authentication Policy which establishes trust through an effective 386 password policy, and by setting guidelines for remote location 387 authentication and the use of authentication devices (e.g., one-time 388 passwords and the devices that generate them). 390 (6) An Availability statement which sets users' expectations for the 391 availability of resources. It should address redundancy and recovery 392 issues, as well as specify operating hours and maintenance down-time 393 periods. It should also include contact information for reporting 394 system and network failures. 396 (7) A Violations Reporting Policy that indicates which types of 397 violations (e.g., privacy and security, internal and external) 398 must be reported and to whom the reports are made. A 399 non-threatening atmosphere and the possibility of anonymous reporting 400 will result in a greater probability that a violation will be 401 reported if it is detected. 403 (8) Supporting Information which provides users, staff, and management 404 with contact information for each type of policy violation; 405 guidelines how handle outside queries about a security incident or 406 information which may be considered confidential or proprietary; and 407 cross-references to security procedures and related information, such 408 as company policies and regulatory requirements (federal, state, and 409 local). 411 There may be regulatory requirements that affect some aspects of your 412 security policy (e.g., line monitoring). The creators of the 413 security policy should consider seeking legal assistance in the 414 creation of the policy. At a minimum, the policy should be reviewed 415 by legal counsel. 417 Once your computer security policy has been established it should be 418 clearly communicated to users, staff, and management. Having all 419 personnel sign a statement indicating that they have read, 420 understood, and agreed to abide by the policy is an important part of 421 the process. Finally, your policy should be reviewed on a regular 422 basis to see if it is successfully supporting your security needs. 424 2.3 Keep the policy flexible 425 In order for a security policy to be viable for the long term, it 426 requires a lot of flexibility. The mechanisms for updating the 427 policy should be clearly spelled out. This includes the process, the 428 people involved, and the people who must sign-off on the changes. 430 It is also important to recognize that there are exceptions to every 431 rule. Whenever possible, the policy should spell out what exceptions 432 to the general policy exist. For example, under what conditions is a 433 system administrator allowed to go through a user's files. Also, 434 there may be some cases when multiple users will have access to the 435 same userid. For example, on systems with a "root" user, multiple 436 system administrators may know the password and use the root account. 438 Another consideration is called the "Garbage Truck Syndrome." This 439 refers to what would happen to a site if a key person was suddenly 440 unavailable for his/her job function. While the greatest security 441 resides in the minimum dissemination of information, the risk of 442 losing critical information increases when that information is not 443 shared. It is necessary to determine what the proper balance is for 444 your site. 446 3. ARCHITECTURE 448 3.1 Objectives 450 3.1.1 Completely defined security plans 452 Defining a comprehensive security plan should be done by all sites. 453 This plan should be at a higher level than the specific policies 454 discussed in section 2. It should be crafted as a framework of broad 455 guidelines into which specific policies will fit. 457 It is important to have this framework in place so that individual 458 policies can be consistant with the overall site security 459 architecture. For example, having a strong policy with regard to 460 Internet access, but having weak restrictions on modem usage is 461 inconsistent with an overall philosophy of strong security 462 restrictions on external access. 464 A security policy should contain, at a minimum: a list of services 465 which are currently, or will forseably be, provided; who will have 466 access to those services; how access will be provided; who will 467 administer those services; etc. It is also imperative to define any 468 limitations on which portions of an organization can provide 469 services. 471 Another aspect of the plan should concern incident handling. Chapter 472 5 provides an in-depth discussion of responses to incidents, but it 473 is important to define classes of incidents and define responses to 474 each class of incident. For sites with firewalls, how many attempts 475 to foil the firewall will trigger a response? Are there levels of 476 escallation in both attacks and responses? For sites without 477 firewalls, does a single attempt to connect constitute an incident? 478 How about a systematic scan of machines? 480 For sites connected to the Internet, the rampant media glorification 481 of Internet related security incidents can overshadow a (potentially) 482 more serious internal security problem. Likewise, companies who have 483 never been on the Internet before, may have strong, well defined, 484 internal policies but fail to adequately address external connection 485 policy. 487 3.1.2 Separation of Services 489 There are many services which a site may wish to provide for its 490 users, some of which may be external. There are a variety of 491 security reasons to attempt to isolate services onto dedicated 492 machines. There are also performance reasons in most cases, but a 493 detailed discussion is beyond to scope of this document. 495 The services which a site may provide will, in most cases, have 496 different levels of access needs and models of trust. Services which 497 are essential to the security and smooth operation of a site would be 498 better off being placed on a dedicated machine with very limited 499 access restrictions (see Section 3.1.3 "deny all" model), rather than 500 a machine which provides a service (or services) which has 501 traditionally been less secure, or requires greater accessability by 502 users who may accidentally suborn security. 504 It is also important to distinguish between machines which operate 505 within different models of trust, say all the machines inside of a 506 firewall, and any machines on an exposed network. 508 Some of the services which should be examined for potential 509 separation are outlined below. More specific information will be 510 presented in section 3.3 (????). It is important to try to 511 understand that vulnerability is only as strong as the weakest link 512 in the chain. Several of the most publicized penetrations in recent 513 years has been through the electronic mail systems of machines. The 514 intruders were not trying to steal electronic mail, but they used the 515 vulnerability in that system to gain access to other systems. 517 If possible, each service should be running on a different machine 518 whose only duty is to provide a specific service. This help isolate 519 intruders and limit potential harm. 521 3.1.3 Deny all/ Allow all 523 There are two diametrically oppossed underlying philosophies which 524 can be adopted in defining a security plan. Both alternatives are 525 legitimate models to adopt, depending on the site and its needs for 526 security. 528 The first option is to turn off all services and then selectively 529 enable services on a case by case basis, be it at the machine or 530 network level, as they are needed. This model, which will here after 531 be referred to as the "deny all" model, is generally more secure. 533 More work is required to successfully implement a "deny all" 534 configuration and usually a better understanding of services; which 535 may require several pieces operating together to function correctly. 536 Only allowing known services allows a better analysis of a particular 537 service/protocol, and the design of a security mechanism suited to 538 the security level of the site. 540 The other model, which will here after be referred to as the "allow 541 all" model, is much easier to implement, but is in general less 542 secure than the "deny all" model. Simply turn on all services, 543 usually the default at the host level, and allow all protocols to 544 travel across network boundaries, usually the default at the router 545 level. As security holes become apparent, they are patched at either 546 the host or network level. 548 Each of these models can be applied to different portions of the 549 site, depending on functionality requirements, administrative 550 control, site policy etc. For example, the policy may be to use the 551 "allow all" model when setting up workstations for general use, but 552 adopt a "deny all" model when setting up information servers, like an 553 email hub. Likewise, an "allow all" policy may be adopted for 554 traffic between LAN's internal to the site, but a "deny all" policy 555 can be adopted between the site and the Internet. 557 Be careful when mixing philosophies as in the examples above. Many 558 sites adopt the M & M theory of a hard "crunchy" shell and a soft 559 "squishy" middle. They are willing to pay the cost of security for 560 their external traffic and require strong security measures, but are 561 unwilling or unable to provide similar protections internally. This 562 works fine as long as the outer defenses are never breached and the 563 internal users can be trusted. Once the outer shell (firewall) is 564 breached, subverting the internal network is trivial. 566 3.1.4 Identify real needs for services 568 There is a large variety of services which may be provided, both 569 internally and on the Internet at large. Managing security is in 570 many ways managing access to services internal to the site and 571 managing how internal users access information at remote sites. 573 Services tend to rush like waves over the Internet. Over the years 574 many sites have established anonymous ftp servers, gopher servers, 575 wais servers, www servers, etc. as they became popular but not 576 particularly needed at all sites. Evaluate all new services that are 577 established with a skeptical attitude to determine if they are 578 actually needed or just the current fad sweeping the Internet. 580 Bear in mind that security complexity can grow exponentially with the 581 number of services provided. Filtering routers need to be modified 582 to support the new protocols. Some protocols are inherently 583 difficult to filter safely (ex. rpc and udp services), thus providing 584 more openings to the internal network. Services provided on the same 585 machine can interact in catastrophic ways. (ex. allowing anonymous 586 ftp on the same machine as the www server may allow an intruder to 587 place a file in the anonymous ftp area and cause the http server to 588 execute it.) 590 3.2 Network and Service Configuration 592 3.2.1 Protecting the Infrastructure 594 Many network administrators go to great lengths to protect the hosts 595 on their networks. Few administrators make any effort to protect the 596 networks themselves. There is some rationale to this. For example, 597 it is far easier to protect a host than a network. Also, intruders 598 are likely to be after data on the hosts; damaging the network would 599 not serve their purposes. That said, there are still reasons to 600 protect the networks. For example, an intruder might divert network 601 traffic through an outside host in order to examine the data (i.e., 602 to search for passwords). Also, infrastructure includes more than 603 the networks and the routers which interconnect them. Infrastructure 604 also includes network management (e.g., SNMP), services (e.g., DNS, 605 NFS, NTP, WWW), and security (i.e., user authentication and access 606 restrictions). 608 The infrastructure also needs protection against human error. When 609 an administrator misconfigures a host, that host may offer degraded 610 service. This only affects users who require that host, and unless 611 that host is a primary server, the number of affected users will 612 therefore be limited. However, if a router is misconfigured, all 613 users who require the network will be affected. Obviously, this is a 614 far larger number of users than those depending on any one host. 616 3.2.2 Protecting the Network 618 There are several problems to which networks are vulnerable. The 619 classic is a "denial of service" attack. In this case, the network 620 is brought to a state in which it can no longer carry legitimate 621 users' data. There are two common ways this can be done: by 622 attacking the routers and by flooding the network with extraneous 623 traffic. An attack on the router is designed to cause it to stop 624 forwarding packets, or to forward them improperly. The former case 625 may be due to a misconfiguration, the injection of a spurious routing 626 update, or a "flood attack" (i.e., the router is bombarded with 627 unroutable packets, causing its performance to degrade). A flood 628 attack on a network is similar to a flood attack on a router, except 629 that the flood packets are usually broadcast. An ideal flood attack 630 would be the injection of a single packet which exploits some known 631 flaw in the network nodes and causes them to retransmit the packet, 632 or generate error packets, each of which is picked up and repeated by 633 another host. A well chosen attack packet can even generate an 634 exponential explosion of transmissions. 636 Another classic problem is "spoofing." In this case, spurious 637 routing updates are sent to one or more routers causing them to 638 misroute packets. This differs from a denial of service attack only 639 in the purpose behind the spurious route. In denial of service, the 640 object is to make the router unusable; a state which will be quickly 641 detected by network users. In spoofing, the spurious route will 642 cause packets to be routed to a host from which an intruder may 643 monitor the data in the packets. These packets are then be re-routed 644 to their correct destinations. However, the intruder may or may not 645 have altered the contents of the packets. 647 The solution to most of these problems is to protect the routing 648 update packets sent by the routing protocols in use (e.g., RIP-2, 649 OSPF). There are three levels of protection: clear-text password, 650 cryptographic checksum, and encryption. Passwords offer only minimal 651 protection against intruders who do not have direct access to the 652 physical networks. Passwords also offer some protection against 653 misconfigured routers (i.e, routers which, out of the box, attempt to 654 route packets). The advantage of passwords is that they have a very 655 low overhead, in both bandwidth and CPU consumption. Checksums 656 protect against the injection of spurious packets, even if the 657 intruder has direct access to the physical network. Combined with a 658 sequence number, or other unique identifier, a checksum can also 659 protect again "replay" attacks, wherein an old (but valid at the 660 time) routing update is retransmitted by either an intruder or a 661 misbehaving router. The most security is provided by complete 662 encryption of sequenced, or uniquely identified, routing updates. 663 This prevents an intruder from determining the topology of the 664 network. The disadvantage to encryption is the overhead involved in 665 processing the updates. 667 RIP-2 (RFC 1723) and OSPF (RFC 1583) both support clear-text 668 passwords in their base design specifications. In addition, there 669 are extensions to each base protocol to support MD5 encryption. 671 Unfortunately, there is no adequate protection against a flooding 672 attack, or a misbehaving host or router which is flooding the 673 network. Fortunately, this type of attack is obvious when it occurs 674 and can be terminated relatively simply. 676 3.2.3 Protecting the Services 678 There are many types of services; each has its own security 679 requirements. These requirements will vary based on the intended use 680 of the service. For example, a service which should only be usable 681 within a site (e.g., NFS) requires little protection. That is, 682 protecting the server from external access is sufficient to protect 683 the service. However, a WWW server, which provides a home page 684 intended for viewing by users anywhere on the Internet, requires 685 built-in protection. That is, the service/protocol/server must 686 provide whatever security may be required to prevent unauthorized 687 access and modification of the Web database. 689 Internal services (i.e., services meant to be used only by users 690 within a site) and external services (i.e., services deliberately 691 available to users outside a site) will, in general, have protection 692 requirements which differ as previously described. It is therefore 693 wise to isolate the internal services to one set of server machines 694 and the external services to another set of server machines. That 695 is, internal and external servers should not be co-located. In fact, 696 many sites go so far as to have one set of subnets (or even different 697 networks) which are accessible from the outside and another set which 698 may be accessed only within the site. Of course, there is usually a 699 firewall which connects these partitions. Great care must be taken 700 to ensure that such a firewall is operating properly. 702 One form of external service deserves some special consideration, and 703 that is anonymous, or guest, access. This may be either anonymous 704 FTP or guest (unauthenticated) login. It is extremely important to 705 ensure that anonymous FTP servers and guest login userids are 706 carefully isolated from any hosts and file systems from which outside 707 users should be kept. Another area to which special attention must 708 be paid concerns anonymous, writable access. A site may be legally 709 responsible for the content of publicly available information, so 710 careful monitoring of the information deposited by anonymous users is 711 advised. 713 Now we shall consider some of the most popular services: name 714 service, password/key service, authentication/proxy service, 715 electronic mail, WWW, file transfer, and NFS. Since these are the 716 most frequently used services, they are the most obvious points of 717 attack. Also, a successful attack on one of these services can 718 produce disaster all out of proportion to the innocence of the basic 719 service. 721 3.2.3.1 Name Servers (DNS and NIS(+)) 723 The Internet uses the Domain Name System (DNS) to perform address 724 resolution for host and network names. The Network Information 725 Service (NIS) and NIS+ are not used on the global Internet, but are 726 subject to the same risks as a DNS server. Name-to-address 727 resolution is critical to the secure operation of any network. An 728 attacker who can successfully control or impersonate a DNS server can 729 reroute traffic to subvert security protections. For examaple, 730 routine traffic can be diverted to a compromised system to be 731 monitored; or, users can be tricked into providing authentication 732 secrets. An organization should create well known, protected sites 733 to act as secondary name servers and protect their DNS masters from 734 denial of service attacks using filtering routers. 736 3.2.3.2 Password/Key Servers (NIS(+) and KDC) 738 Password and key servers generally protect their vital information 739 (i.e., the passwords and keys) with encryption algorithms. However, 740 even a one-way encrypted password can be determined by a dictionary 741 attack (wherein common words are encrypted to see if they match the 742 stored encryption). It is therefore necessary to ensure that these 743 servers are not accessable by hosts whch do not plan to use them for 744 the service, and even those hosts should only be able to access the 745 service (i.e., general services, such as Telnet and FTP, should not 746 be allowed by anyone other than administrators). 748 3.2.3.3 Authentication/Proxy Servers (SOCKS, FWTK) 749 A proxy server provides a number of security enhancements. It allows 750 sites to concentrate services through a specific host to allow 751 monitoring, hiding of internal structure, etc. This funnelling of 752 services creates an attractive target for a potential intruder. The 753 type of protection required for a proxy server depends greatly on the 754 proxy protocol in use and the services being proxied. The general 755 rule of limiting access only to those hosts which need the services, 756 and limiting access by those hosts to only those services, is a good 757 starting point. 759 3.2.3.4 Electronic Mail 761 Electronic mail (email) systems have long been a source for intruder 762 break-ins because email protocols are among the oldest and most 763 widely deployed services. Also, by it's very nature, an email server 764 requires access to the outside world; most email servers accept input 765 from any source. An email server generally consists of two parts, a 766 receiving/sending agent and a processing agent. Since email is 767 delivered to all users, and is usually private, the processing agent 768 typically requires system (root) privileges to deliver the mail. 769 Most email implementations perform both portions of the service, 770 which means the receiving agent also has system privileges. This 771 opens several security holes which this document will not describe. 772 There are some implementations available which allow a separation of 773 the two agents. Such implementations are generally considered more 774 secure, but still require careful installation to avoid creating a 775 security problem. 777 3.2.3.5 World Wide Web (WWW) 779 The Web is growing in popularity exponentially because of its ease of 780 use and the powerful abilities to concentrate information services. 781 Most WWW servers take some directions and actions from the persons 782 accessing their services. The most common example is taking a 783 request from a remote user and passing the provided information to a 784 program running on the server to process the request. Some of these 785 programs are not written with security in mind and can create 786 security holes. If a Web server is available to the Internet 787 community, it is especially important that confidential information 788 not be co-located on the same host as the server. In fact, it is 789 recommended that the server have a dedicated host which is not 790 "trusted" by other internal hosts. It may be co-located with an 791 anonymous FTP server, since both protocols share common security 792 considerations. 794 3.2.3.6 File Transfer (FTP, TFTP) 796 FTP and TFTP allow users to receive and send electronic files in a 797 point to point manner. Improperly configured FTP servers can allow 798 intruders to copy, replace and delete files at will, anywhere on a 799 host. TFTP does not support same range of functions, but has no 800 security whatsoever. Access to encrypted passwords, proprietary 801 data, and the introduction of trojan horses are just a few of the 802 potential security holes. FTP and TFTP servers (especially Internet 803 accessable anonymous FTP servers) should reside on their own host. 804 It may be co-located with a Web server, since file transfer protocols 805 share common security considerations. 807 3.2.3.7 NFS 809 The Network File Service allows hosts to share common disks. NFS is 810 most frequently used by diskless hosts who depend on a disk server 811 for all of their storage needs. Unfortunately, NFS has no built-in 812 security. It is therefore necessary that the NFS server be 813 accessable only by those hosts which are using it for service. It is 814 especially important that external hosts be unable to reach the NFS 815 host by any means. Ideally, such access attempts would be stopped by 816 a firewall. 818 3.2.4 Protecting the Protection 820 It is amazing how often a site will overlook the most obvious 821 weakness in its security by leaving the security server itself open 822 to attack. Based on considerations previously discussed, it should 823 be clear that: the security server should not be accessible from 824 off-site; should offer minimum access, except for the authentication 825 function, to users on-site; and should not be co-located with any 826 other servers. Further, all access to the node, including access to 827 the service itself, should be logged to provide a "paper trail" in 828 the event of a security breach. 830 3.3 Firewalls 832 One of the most widely deployed and publicized security measures in 833 use on the Internet is a "firewall." Firewalls have been given the 834 reputation of a general panacea for many, if not all, of the Internet 835 security issues. They are not. Firewalls are just another tool in 836 the quest for system security. They provide a certain level of 837 protection, and are, in general, a way of implementing security 838 policy at the network level. The level of security that a firewall 839 provides can vary as much as the level of security on a particular 840 machine. There are the traditional trade-offs of security versus 841 ease of use, cost, complexity, etc. 843 A firewall is any one of several mechanisms used to control and watch 844 access to and from a network for the purpose of protecting it. A 845 firewall acts as a gateway through which all traffic to and from the 846 protected network or machines passes. Firewalls help to place 847 limitations on the amount and type of communication that takes place 848 between the protected network and the another network (e.g., the 849 Internet, or another piece of the companyUs network). 851 A firewall is generally a way to build a wall between one part of a 852 network, a companyUs internal network, for example, and another part, 853 the global Internet, for example. The unique feature about this wall 854 is that there needs to be ways for some traffic with particular 855 characteristics to pass through carefully monitored doors 856 ("gateways"). The difficult part is to establish the criteria by 857 which the packets are allowed or denied access through the door. 858 Different books written on firewalls use different terminology to 859 describe the various forms of firewalls. This can be confusing to 860 system administrators who are not familiar with firewalls. The thing 861 to note here is that there is no fixed terminology for the 862 description of firewalls. 864 Firewalls are not always, or even typically, a single machine, but in 865 general are a combination of routers, networks, and host machines, so 866 for the purposes of this discussion the term "firewall" can consist 867 of more than one physical device. Firewalls are typically built 868 using two different components, filtering routers and proxy servers. 870 Filtering routers are the easiest component to conceptualize in a 871 firewall. A router moves data back and forth between two (or more) 872 different networks. A "normal" router takes a packet from network A 873 and "routes" it to its destination on network B. A filtering router 874 does the same thing but decides not only how to route the packet, but 875 *SHOULD* it route the packet. This is done by installing a series of 876 filters by which the router decides what to do with any given packet 877 of data. 879 A discussion concerning capabilities of a particular brand of router, 880 running a particular software version is outside the scope of this 881 document. However, when evaluating a router to be used for filtering 882 packets, the following criteria can be important when implementing a 883 filtering policy. These criteria include: source and destination IP 884 address, source and destination TCP port numbers, state of the TCP 885 "ack" bit, UDP source and destination port numbers, and direction of 886 packet flow (i.e.. A- >B or B->A). Other information necessary to 887 construct a secure filtering scheme are whether the router reorders 888 filter instructions (designed to optimize filters, this can sometimes 889 change the meaning and cause unintended access), and whether it is 890 possible to apply filters for inbound and outbound packets on each 891 interface (if the router filters only outbound packets then the 892 router is "outside" of its filters and may be more vulnerable to 893 attack). In addition to the router being vulnerable, this 894 distinction between applying filters on inbound or outbound packets 895 is especially relevant for routers with more than 2 interfaces. 896 Other important issues are the ability to create filters based on IP 897 header options and the fragment state of a packet. Building a good 898 filter can be very difficult and requires a good understanding of the 899 type of services(protocols) that will be filtered. 901 For better security the filters usually restrict access between the 902 two connected nets to just one host --- the bastion host. It is only 903 possible to access the other network via this bastion host. As only 904 this host, rather than a few hundred hosts, can get attacked it is 905 easier to maintain a certain level of security, because only this 906 host has to be protected very carefully. To make resources available 907 to legitimate users across this firewall, services have to be 908 forwarded by the bastion host. Some servers have forwarding built in 909 (like DNS-servers or SMTP-servers), for other services (like Telnet, 910 FTP,...) proxy servers can be used to allow access to the resources 911 across the firewall in a secure way. A proxy server is way to 912 concentrate application services through a single machine. There is 913 typically a single machine (the bastion host) that acts as a proxy 914 server for a variety of protocols (Telnet, SMTP, FTP, HTTP, etc.) but 915 there can be individual machines for each service. Instead of 916 connecting directly to an external server, the client connects to the 917 proxy server which in turn initiates a connection to the requested 918 external server. Depending on the type of proxy server used, it is 919 possible to configure internal clients to perform this redirection 920 automatically without knowledge to the user, others might require 921 that the user connect directly to the proxy server and then initiate 922 the connection through a specified format. 924 There are significant security benefits which can be derived from 925 using proxy servers. It is possible to add access control lists to 926 protocols, requiring users or machines to provide some level of 927 authentication before access is granted. Smarter proxy servers, 928 sometimes called Application Layer Gateways (ALGs), can be written 929 which understand specific protocols, and can be configured to block 930 only subsections of the protocol. For example, an ALG for FTP can 931 tell the difference between the "put" command and the "get" command. 932 An organization may wish to allow users to "get" files from the 933 Internet, but for whatever reason not be able to take internal files 934 and "put" them on a remote server. By contrast a filtering router 935 could either block all FTP access or none but not a subset. 937 Proxy servers can also be configured to encrypt data streams based on 938 a variety of parameters. An organization might use this feature to 939 allow encrypted connections between two locations whose sole access 940 points are on the Internet. 942 Firewalls are typically thought of as a way to keep intruders out, 943 but they are also often used as a way to let legitimate users into a 944 site. There are many examples where a valid user might need to 945 regularly access the "home" site while traveling, at trade shows and 946 conferences, etc. Access to the Internet is usually available but 947 may be through an untrusted machine or network. A correctly setup 948 proxy server can allow the correct users into the site, while still 949 denying access to other users. 951 The current best effort in firewall techniques is found using a 952 combination of a pair of screening routers with one or more proxy 953 servers on a network between the two routers. This setup allows the 954 external router to block off any attempts to use the underlying IP 955 layer to break security (IP spoofing, source routing, packet 956 fragments), while allowing the proxy server to handle potential 957 security holes in the TCP protocols. The internal routers purpose is 958 to block all traffic except to the proxy server. If this setup is 959 rigidly implemented a high level of security can be achieved. 961 Firewalls provide logging which can be tuned to make security 962 administration of the network more convenient. Logging may be 963 centralized and the system may be configured to send out alerts for 964 abnormal conditions. It is important to regularly monitor these logs 965 for any signs of intrusions or break-in attempts. Since some 966 intruders will attempt to cover their tracks by editing logs, it is 967 desirable to protect these logs. A variety of methods is available 968 including write once, read many (WORM) drives, papers logs, or 969 centralized logging via the "syslog" utility. Another technique is 970 to use a "fake" serial printer, but have the serial port connected to 971 an isolated machine or PC which keeps the logs. 973 Firewalls are available in a wide range of quality and strengths. 974 Commercial packages start at approximately $10,000 US and go up to 975 over $250,000 US. "Home grown" firewalls can be built for smaller 976 amounts of capital . It should be remembered that the correct setup 977 of a firewall (commercial or homegrown) requires a significant amount 978 of skill and knowledge of TCP/IP. Both types require regular 979 maintenance, installation of software patches and updates, and 980 regular monitoring. When budgeting for a firewall, these additional 981 costs should be considered in addition to the cost of the physical 982 elements of the firewall. 984 As an aside, building a "home grown" firewall requires a significant 985 amount of skill and knowledge of TCP/IP. It should not be trivially 986 attempted because a perceived sense of security is worse in the long 987 run than knowing that there is no security. As with all security 988 measures it is important to decide on the threat, the value of the 989 assets to be protected and the costs to implement security. 991 A final note about firewalls. They can be a great aid when 992 implementing security for a site and they protect against a large 993 variety of attacks. But it is important to keep in mind that they are 994 only one part of the solution. They canUt protect your site against 995 all types of attack. 997 4. SECURITY SERVICES AND PROCEDURES 999 This chapter guides the reader through a number of topics that should 1000 be addressed when securing a site. Each section touches on a 1001 security service or capability that may be required to protect the 1002 information and systems at a site. These are presented in a fairly 1003 high-level to introduce the reader to the concepts. 1005 Throughout the chapter, you will find considerable mention of 1006 cryptography. It is outside the scope of this document to delve into 1007 details concerning cryptography and we point the reader to a small 1008 appendix on the subject. If you would like more details on this 1009 subject, please see [ref to Bruce Schnier sp?] 1011 4.1 Authentication 1013 For many years, the prescribed method for authenticating users has 1014 been through the use of standard, reusable passwords. Originally, 1015 these passwords were used by users at terminals to authenticate 1016 themselves to a central computer. At the time, there were no 1017 networks (internally or externally) and hence the risk of disclosure 1018 of the clear text password was minimal. Today, systems are connected 1019 together through local networks, and those local networks are further 1020 connected together, and to the Internet. Users are logging in from 1021 all over the globe, and their reusable passwords are often 1022 transmitted across those same networks in clear text, ripe for anyone 1023 in-between to capture. And indeed, the CERT Coordination Center and 1024 other response teams are seeing a tremendous number of incidents 1025 involving packet sniffers which are capturing the clear text 1026 passwords. To address this threat, we are including sections on 1027 better technologies like one-time passwords, and Kerberos. 1029 With the advent of newer technologies like one-time passwords (e.g., 1030 S/Key), PGP, and token-based authentication devices, people are using 1031 password- like strings as secret tokens and pins. We are including a 1032 discussion on these since they are the foundation upon which stronger 1033 authentication techniques are based. If these secret tokens and pins 1034 are not properly selected and protected, the authentication will be 1035 easily subverted. 1037 4.1.1 One-Time passwords 1039 As mentioned above, given today's networked environments, it is 1040 recommended that sites concerned about the security and integrity of 1041 their systems and networks consider moving away from standard, 1042 reusable passwords. There have been many incidents involving Trojan 1043 network programs (e.g., telnet and rlogin) and network packet 1044 sniffing programs. These programs capture clear text hostname, 1045 account name, password triplets. Intruders can use the captured 1046 information for subsequent access to those hosts and accounts. This 1047 is possible because 1) the password is used over and over (hence the 1048 term "reusable"), and 2) the password passes across the network in 1049 clear text. 1051 Several authentication techniques have been developed that address 1052 this problem. Among these techniques are challenge-response 1053 technologies that provide passwords that are only used once (commonly 1054 called one-time passwords). This document provides a list of sources 1055 for products that provide this capability. The decision to use a 1056 product is the responsibility of each organization, and each 1057 organization should perform its own evaluation and selection. 1059 4.1.2 Kerberos 1061 1063 4.1.3 Choosing and Protecting Secret Tokens and Pins 1065 When selecting secret tokens, take care to choose them carefully. 1066 Like the selection of passwords, they should be robust against brute 1067 force efforts to guess them. That is, they should not be singles 1068 words in any language, any common, industry, or cultural acronyms, 1069 etc. Ideally, they will be longer rather than shorter and consist of 1070 pass phrases that combine upper and lower character, digits, and 1071 other characters. 1073 Once chosen, the protection of these secret tokens is very important. 1074 Some are used as pins to hardware devices (like token cards) and 1075 these should not be written down and placed in the same location as 1076 the device to which they are associated. Others, such as a secret PGP 1077 key, should be protected from unauthorized access. 1079 One final word on this subject. When using a cryptography products, 1080 like PGP, take care to determine the proper key length and ensure 1081 that your users are trained to do likewise. As technology advances, 1082 the minimum safe key length continues to grow. Make sure your site 1083 keeps up with the current state of knowledge on the subject so that 1084 you can ensure any cryptography used will be providing you the 1085 protection you are assuming it is. 1087 4.1.4 Password Assurance 1089 While the need to eliminate the use of standard, reusable passwords 1090 cannot be overstated, it is recognized that some organizations may 1091 have to transition to the use of better technology. Given that 1092 situation, we have included the following advice to help with the 1093 selection and maintenance of traditional passwords. But remember, 1094 none of these measures provides protection against disclosure due to 1095 sniffer programs. 1097 (1) The importance of robust passwords - In many (if not most) cases of 1098 system penetration, the intruder needs to gain access to an account 1099 on the system, and one way that goal is typically accomplished is 1100 through guessing the password of a legitimate user. This is often 1101 accomplished by running an automated password cracking program, 1102 which utilizes a very large dictionary, against the system's password 1103 file. The only way to guard against passwords being disclosed in this 1104 manner is through the careful selection of passwords which cannot be 1105 easily guessed (i.e., combinations of numbers, letters, and punctuation 1106 characters). 1108 (2) Changing default passwords - Many operating systems and application 1109 programs are installed with default accounts and passwords. These 1110 must be changed immediately to something that cannot be guessed or 1111 cracked. 1113 (3) Restricting access to the password file - In particular, a site 1114 wants to protect the encrypted password portion of the file so that 1115 would-be intruders don't have them available for cracking. One 1116 effective technique is to use shadow passwords where the password 1117 field of the standard file contains a dummy or false password. The 1118 file containing the legitimate passwords are protected elsewhere on 1119 the system. 1121 (4) Password aging - When and how to expire passwords is still a subject 1122 of controversy among the security community. It is generally accepted 1123 that a password should not be maintained once an account is no longer in 1124 use, but it is hotly debated whether a user should be forced to change a 1125 good password that's in active use. The arguments for changing 1126 passwords relate to the prevention of the continued use of penetrated 1127 accounts. However, the opposition claims that frequent password 1128 changes lead to users writing down their passwords in visible areas 1129 (such as pasting them to a terminal), or to users selecting very simple 1130 passwords that are easy to guess. It should also be stated that an 1131 intruder will probably use a captured or guessed password sooner rather 1132 than later, in which case password aging provides little if any 1133 protection. 1135 While there is no definitive answer to this dilemma, a password policy 1136 should directly address the issue and provide guidelines for how often 1137 a user should change the password. It is recommended that passwords 1138 be changed whenever root is penetrated, there is a critical change in 1139 personnel (especially if it is the system administrator!), or when an 1140 account has been compromised. In particular, if the root password is 1141 compromised, all passwords on the system should be changed. In 1142 addition, an annual change in their password is usually not difficult 1143 for most users, and you should consider requiring it. 1145 4.2 Confidentiality 1147 There will be information assets that your site will want to protect 1148 from disclosure to unauthorized entities. Operating systems often 1149 have built-in file protection mechanisms that allow an administrator 1150 to control who on the system can access, or "see", the contents of a 1151 given file. A stronger way to provide confidentiality is through 1152 encryption. Encryption is accomplished by scrambling data so that it 1153 is very difficult and time consuming for anyone other than the 1154 authorized recipients or owners to obtain the plain text. Authorized 1155 recipients and the owner of the information will possess the 1156 corresponding decryption keys that allow them to easily unscramble 1157 the text to a readable (clear text) form. We recommend that sites use 1158 encryption to provide confidentiality to protect valuable 1159 information. 1161 The use of encryption is sometimes controlled by govermental and site 1162 regulations, so we encourage administrators to become informed of 1163 laws or policies that regulate its use before employing it. It is 1164 outside the scope of this document to discuss the various algorithms 1165 and programs available for this purpose, but we do caution against 1166 the casual use of the UNIX crypt program as it has been found to be 1167 easily broken. We also encourage you to take time to understand the 1168 strength of the encryption in any given algorithm/product before 1169 using it. Most well- known products are well-documented in the 1170 literature, so this should be a fairly easy task. 1172 4.3 Integrity 1174 As an administrator, you will want to make sure that information 1175 (e.g., operating system files, company data, etc.) has not been 1176 altered in an unauthorized fashion. This means you will want to 1177 provide some assurance as to the integrity of the information on your 1178 systems. One way to provide this is to produce a checksum of the 1179 unaltered file, store that checksum offline, and periodically (or 1180 when desired) check to make sure the checksum of the online file 1181 hasn't changed (which would indicate the data has been modified). 1183 Some operating systems come with checksumming programs, such as the 1184 UNIX sum program. However, these may not provide the protection you 1185 actually need. Files can be modified in such a way as to preserve the 1186 result of the UNIX sum program! Therefore, we suggest that you use a 1187 cryptographically strong program such as the message disgesting 1188 program MD5 [ref] to produce checksums you will be using to assure 1189 integrity. 1191 There are other applications when integrity will want to be assured, 1192 such as when transmitting an email message between two parties, and 1193 there are products available that can provide this capability. The 1194 purpose of this section is to acquaint you with this concept so that 1195 you can apply it where needed. Once you identify that this is a 1196 capability you need, you can go about identifying technologies that 1197 will provide it. 1199 4.4 Authorization 1201 Authorization refers to the process of granting privileges to 1202 processes and ultimately users. This differs from authentication in 1203 that authentication is what occurs to identify a user. Once 1204 identified (reliably), the privileges, rights, property, and 1205 permissible actions of the user are determined by authorization. 1207 Explicity listing the authorized activities of each user (and user 1208 process) with respect to all resources (objects) is impossible in a 1209 reasonable system. In a real system certain techniques are used to 1210 simplify the process of granting and checking authorization(s). 1212 One approach, popularized in UNIX systems, is to assign to each 1213 object three classes of user - the super user, the owner, and the 1214 group. Super user, or root, is an entity that has access to all 1215 portions (and objects) of the computer. The owner of an object is 1216 the "user" who either created the object or was given it by the super 1217 user. A group is a collection of users that share privileges over a 1218 collection of objects. Groups ease authorization management by 1219 simplifying the process of changing the authorization of users and by 1220 changing the authority of a group to manage an object. 1222 Another approach is to attach to an object a list which explicitly 1223 contains the identity of all permitted users (or groups). This is an 1224 Access Control List. The advantage of these are that they are easily 1225 maintained (one central list per object). 1227 4.5 Access 1229 4.5.1 Physical Access 1231 Restrict physical access to areas containing hosts to people who are 1232 supposed to use the hosts. Hosts include 'trusted' terminals (such 1233 as system consoles, operator terminals and terminals dedicated to 1234 special tasks such as backup) and individual microcomputers and 1235 workstations, especially those connected to your network. Make sure 1236 access restrictions mesh well with people's work patterns, otherwise 1237 they will find ways to circumvent your physical security, e.g. 1238 jamming doors open. 1240 Keep original and backup copies of data and programs safe. Apart from 1241 keeping them in good condition for backup purposes, they must be 1242 protected from theft. 1244 Portable hosts are a particular risk. Make sure it won't cause 1245 problems if one of your staff's portable computer is stolen. Consider 1246 developing guidelines for the kinds of data that should be allowed to 1247 reside on the disks of portable computers as well as how the data 1248 should be protected (e.g., encryption) when it is on a portable 1249 computer. 1251 Other areas where physical access should be restricted is the wiring 1252 closets and important network elements like file servers, name server 1253 hosts, and routers. 1255 4.5.2 Walk-up Network Connections 1257 By 'walk-up' connections we mean sockets located so as to provide a 1258 convenient way for users to connect a portable host to your network. 1260 Consider whether you need to provide this service, bearing in mind 1261 that it allows any user to attach an unauthorized host to your 1262 network. This increases the risk of attacks via techniques such as 1263 IP address spoofing, packet sniffing, etc. Users and site management 1264 must appreciate the risks involved. If you decide to provide walk-up 1265 connections, plan the service carefully, and define precisely where 1266 you will provide it so that you can provide the necessary physical 1267 access security. 1269 A walk-up host should be authenticated before its user is permitted 1270 to access resources on your network. As an alternative it may be 1271 possible to control physical access, for example if the service is to 1272 be used by students you might only provide walk-up connection sockets 1273 in student laboratories. 1275 Keep an eye on empty offices. It may be sensible to disconnect 1276 connections to unused offices at the wiring closet. Consider using 1277 secure hubs, and monitoring attempts to connect unauthorized hosts. 1279 4.5.3 Other Network Technologies 1281 Technologies considered here include X.25, ISDN, SMDS, DDS and Frame 1282 Relay. All are provided via physical links which go through 1283 telephone exchanges, providing the potential for them to be diverted. 1284 Crackers are certainly interested in telephone switches as well as in 1285 data networks! 1286 With switched technologies, use Permanent Virtual Circuits or Closed 1287 User Groups whenever this is possible. Technologies which provide 1288 authentication and/or encryption (such as IPv6) on data links are 1289 evolving rapidly. Consider using them on links where security is 1290 important. 1292 4.5.4 Modems 1294 4.5.4.1 Modem lines must be managed 1296 Although they provide convenient access to a site for its users, they 1297 can also provide an effective detour around the site's firewalls. 1298 For this reason it is essential to maintain proper control of modems. 1300 Don't allow users to install a modem line without proper 1301 authorization. This includes temporary installations, e.g. plugging 1302 a modem into a facsimile or telephone line overnight. 1304 Maintain a register of all your modem lines. Conduct regular site 1305 checks for unauthorized modems; keep your register up to date. 1307 4.5.4.2 Dial-in users must be authenticated 1309 A username and password check should be completed before a user can 1310 access anything on your network. Normal password security 1311 considerations (such as choosing passwords which don't appear in 1312 dictionaries and changing them from time to time) are particularly 1313 important. 1315 Remember that telephone lines can be tapped, and that it is quite 1316 easy to intercept messages to cellular 'phones. Modern high-speed 1317 modems use more sophisticated modulation techniques -, which makes 1318 them somewhat more difficult to monitor - but it is prudent to assume 1319 that hackers know how to eavesdrop on your lines. For this reason 1320 you should use one-shot passwords (e.g. skey) or hardware 1321 authentication devices (e.g. SecurID) if this is at all possible. 1323 It is helpful to have a single dial-in point, e.g. a single large 1324 modem pool, so that all users are authenticated in the same way. 1326 Users will occasionally mis-type a password. Set a short delay - say 1327 two seconds - after the first and second failed logins, and force a 1328 disconnect after the third. This will slow down automated password 1329 attacks. Don't tell the user whether the username, the password or 1330 both were incorrect. 1332 4.5.4.3 All logins (successful and unsuccessful) should be logged 1334 Don't keep correct passwords in the log, but consider keeping 1335 incorrect passwords to aid in detecting password attacks. However, 1336 bear in mind that most incorrect passwords are correct passwords with 1337 one character mistyped, and may suggest the real password. If you 1338 can't keep this information secure, don't log it at all. 1340 If Calling Line Identification is available, take advantage of it by 1341 recording the calling number for each login attempt. Be sensitive to 1342 the privacy issues raised by Calling Line Identification. Also be 1343 aware that Calling Line Identification is not to be trusted; use the 1344 data for informational purposes only, not for authentication. 1348 4.5.4.4 Minimize the amount of information given in your opening banner 1350 In particular, don't announce the type of host hardware or operating 1351 system - this encourages specialist hackers. 1353 Display a short banner, but don't offer an 'inviting' name (e.g. 1354 University of XYZ, Student Records System). Instead, give your site 1355 name, a short warning that all sessions are monitored, and a 1356 username/password prompt. Get your site's lawyers to check your 1357 banner to make sure it states your legal position correctly. 1359 For high-security applications, consider using a 'blind' password, 1360 i.e. give no response to an incoming call until the user has typed in 1361 (without any echoing) a password. This effectively simulates a dead 1362 modem. 1364 4.5.4.5 Call-back Capability 1366 Some dial-in servers offer call-back facilities, i.e. the user dials 1367 in and is authenticated, then the system disconnects the call and 1368 calls back on a specified number. You will probably have to pay the 1369 charges for such calls. 1371 This feature should be used with caution; it can easily be bypassed. 1372 As a minimum, make sure that the return call is never made from the 1373 same modem as the incoming one. Overall, although call-back can 1374 improve modem security, you should not depend on it alone. 1376 4.5.4.6 Dial-out authentication 1378 Dial-out users should also be authenticated, particularly since your 1379 site will have to pay their telephone charges. 1381 Never allow dial-out from an unauthenticated dial-in call, and 1382 consider whether you will allow it from an authenticated one. The 1383 goal here is to prevent callers using your modem pool as part of a 1384 chain of logins. This can be hard to detect, particularly if a 1385 hacker sets up a path through several hosts on your site. 1387 As a minimum, don't allow the same modems and phone lines to be used 1388 for both dial-in and dial-out. This can be implemented easily if you 1389 run separate dial-in and dial-out modem pools. 1391 4.5.4.7 Make your modem programming as 'bullet-proof' as possible 1393 Be sure modems can't be reprogrammed while they're in service. As a 1394 minimum, make sure that three plus signs won't put your dial-in 1395 modems into command mode! 1397 Program your modems to reset to your standard configuration at the 1398 start of each new call. Failing this, make them reset at the end of 1399 each call. This precaution will protect you against accidental 1400 reprogramming of your modems. 1402 Check that your modems terminate calls cleanly. When a user logs out 1403 from an access server, verify that the server hangs up the 'phone 1404 line properly. It is equally important that the server forces 1405 logouts from whatever sessions were active if the user hangs up 1406 unexpectedly. 1408 4.6 Auditing 1410 This section covers the procedures for collecting data generated by 1411 network activity that may be useful in analyzing the security of a 1412 network and/or useful in responding to a security incident. This 1413 section also covers the handling, preservation, and utilization of 1414 the data. 1416 4.6.1 What to collect 1418 Audit data should include any attempt to achieve a different security 1419 level of any person, process, or other entity in the network. The 1420 most obvious example in this area is a log of attempts to login to a 1421 host computer. 1423 Audit data should also include data pertaining to any "public" or 1424 anonymous access and retrieval of data, at least to the granularity 1425 of the "remote" host. 1427 4.6.2 Collection Process 1429 The collection process should be enacted by the host or resource 1430 being accessed. Depending on the importance of the data and the need 1431 to have it local in instances in which services are being denied, 1432 data could be kept local to the resource until needed or be 1433 transmitted to storage after each event. 1435 Reporting data can be done by writing to a file, writing to a line 1436 printer, writing over a network, or writing over a non-network port, 1437 such as a console port. Each of these has importance. 1439 File system logging is the least resource intensive of all four 1440 candidates (for a given audit log). It is also the least reliable. 1441 If a resource has been compromised, the file system is the first to 1442 go. If the network in front of the resource has become unusable, the 1443 data is inaccessible, unless a direct console port is available. 1445 Line printer logging is useful in system where permanent and 1446 immediate logs are required. A real time system is an example of 1447 this, where the exact point of a failure or attack must be recorded. 1449 A laser printer, or other device which buffers data between the 1450 auditing system and storage device may suffer from lost data if 1451 buffers contain the needed data at a critical instant. 1453 Reporting over the network provides for allowing a remote host to 1454 store data in a more permanent and possibly more reliable manner. 1455 However, this consumes bandwidth (at the minimum), exposes the audit 1456 data in an easy package to a interloper, and could be lost during 1457 network denial. 1459 Reporting over a console port ensures the delivery of the data 1460 follows the hardware design. The limitations are that the console 1461 port requires physical security and using console ports on machines 1462 more than a short distance away (e.g., across a campus) may require a 1463 phone line in addition to the network connection. In some instances, 1464 this is one more resource that may be constrained. 1466 4.6.3 Collection Load 1468 Collecting running data may result in a quick accumulation of bytes. 1469 Storage of this must be considered in advance. There are a few ways 1470 to limit the required storage space. Data may be compressed using 1471 one of many methods. Another approach is to only archive summaries 1472 of activity (possibly losing some detail in the process). Data may 1473 be archived for just a fixed period of time, then is it permanently 1474 removed. 1476 The issue of archiving security data differs from archiving network 1477 management and application data. Network management data 1478 (statistics) can be reduced by altering the reporting period. 1479 Security data does not have that option (for the most part). 1480 Security data also does not have the permanence of application data. 1482 4.6.4 Handling the Data/Preservation 1484 Security data should be protected as least as much as any other data 1485 is protected because from it, much can be inferred. Security data 1486 may give away enough secrets to allow a "masquerader" to impersonate 1487 an authorized administrator. 1489 Data may also become key to the investigation, apprehension, or 1490 prosecution of the perpetrator of an incident. Because of this, the 1491 data needs to be protected and clearly documented. For this reason 1492 it is advisable to seek the advice of local legal council or law 1493 enforcement when deciding how security data is to be treated. This 1494 should happen before an incident occurs. 1496 If a data handling plan is not cleared prior to an incident, this 1497 does not mean that it is useless. It means two things. You may not 1498 have recourse in the aftermath of an event. You may also me liable 1499 for penalties resulting from your treatment of the data too. 1501 4.6.5 Audit Data Precautions 1502 In certain instances, audit data may contain personal information. 1503 Searching through the data, even for just a routine check of the 1504 network's security could present an invasion of privacy or make the 1505 auditing entity privy to information it should not be allowed to 1506 have. Note that this is not automatically true - not all data is 1507 "sensitive" and "sensitive" differs by locale. 1509 Another danger presented by auditing data is that it may reveal a 1510 pattern of incidents. If an organization knows about the incidents 1511 but permits them to continue and this results in damage to another 1512 organization ("downstream"), legal action could result. An 1513 organization may also be liable for not (making a "best effort" to) 1514 analyze this data for incidents. 1516 4.7 SECURING BACKUPS 1518 The procedure of creating backups is a classic part of operating a 1519 computer system. Within the context of this document, backups are 1520 addressed as part of the overall security plan of a site. There are 1521 several aspects to backups that are important within this context: 1523 (1) Make sure your site is creating backups 1524 (2) Make sure your site is using offsite storage for backups 1525 (3) Consider encrypting your backups to provide additional protection of 1526 the information once it is off-site. However, be aware that you will 1527 need a good key management scheme so that you'll be able to recover 1528 data at any point in the future. Also, make sure you will have 1529 access to the necessary decryption programs at such time in the 1530 future when you need to perform the decryption. 1531 (4) Don't always assume that your backups are good. There have been 1532 many instances of computer security incidents that have gone on for 1533 long periods of time before a site has noticed the incident. In such 1534 cases, backups of the affected systems are also tainted. 1535 (5) Periodically check your backups. 1537 5. SECURITY INCIDENT HANDLING 1539 This section of the document will supply guidance to be applied 1540 before, during, and after a computer security incident is in progress 1541 on a machine, network, site, or multi-site environment. The 1542 operative philosophy in the event of a breach of computer security is 1543 to react according to a plan. This is true whether the breach is the 1544 result of an external intruder attack, unintentional damage, a 1545 student testing some new program to exploit a software vulnerability, 1546 or a disgruntled employee. Each of the possible types of events , 1547 such as those just listed, should be addressed in advance by adequate 1548 contingency plans. 1550 Traditional computer security, while quite important in the overall 1551 site security plan, usually pays little attention to how to actually 1552 handle the attack once it occurs. The result is that when an attack 1553 is in progress, many decisions are made in haste and can be damaging 1554 to tracking down the source of the incident, collecting evidence to 1555 be used in prosecution efforts, preparing for the recovery of the 1556 system, and protecting the valuable data contained on the system. 1558 One of the most important but often overlooked benefits for efficient 1559 incident handling is an economic one. Having both technical and 1560 managerial personnel respond to an incident requires considerable 1561 resources. If trained to handle incidents efficiently, less staff 1562 time is required when one occurs. 1564 Due to the world-wide network most incidents are not restricted to 1565 a single site. Operating systems vulnerabilities apply (in some 1566 cases) to several millions of systems, and many vulnerabilities are 1567 exploited within the network itself. Therefore it is vital for all 1568 sites that involved parties are informed as soon as possible. 1570 Another benefit is related to public relations. News about computer 1571 security incidents tends to be damaging to an organization's stature 1572 among current or potential clients. Efficient incident handling 1573 minimizes the potential for negative exposure. 1575 A final benefit of efficient incident handling is related to legal 1576 issues. It is possible that in the near future organizations may be 1577 sued because one of their nodes was used to launch a network attack. 1578 In a similar vein, people who develop patches or workarounds may be 1579 sued if the patches or workarounds are ineffective, resulting in 1580 damage to systems, or if the patches or workarounds themselves damage 1581 systems. Knowing about operating system vulnerabilities and patterns 1582 of attacks and then taking appropriate measures is critical to 1583 circumventing possible legal problems. 1585 This sections in this chapter provide an outline and starting point 1586 for creating your sites policy for handling security incidents. The 1587 sections are: 1589 (1) Preparing and planning (what are the goals and objectives in 1590 handling an incident). 1591 (2) Notification (who should be contacted in the case of an incident). 1592 (3) Evaluation (how serious is the incident). 1593 (4) Handling (what should be done when an incident occurs). 1594 - Notification (who should be notified about the incident). 1595 - Containment (how can the damage be limited). 1596 - Eradication (how to eliminate the reasons for the incident). 1597 - Recovery (how to reestablish service and systems). 1598 - Follow Up (what actions should be taken after the incident). 1599 - Legal/Investigative implications (what are the legal and 1600 prosecutorial implications of the incident). 1601 - Documentation Logs (what records should be kept from 1602 before, during, and after the incident). 1603 (5) Aftermath (what are the implications of past incidents). 1604 (6) Responsibilities (how to handle an incident responsibly). 1606 Each of these subjects is important in an overall plan for handling 1607 incidents. The remainder of this chapter will detail the issues 1608 involved in each of the relevant topics, and provide some guidance as 1609 to what should be included in a site policy for handling incidents. 1611 5.1 Preparing and Planning for Incident Handling 1613 Part of handling an incident is being prepared to respond to an 1614 incident before the incident occurs in the first place. This 1615 includes establishing a suitable level of protections as explained 1616 in the chapters before. Doing this should help your site prevent 1617 incidents as well as limit potential damage resulting from them when 1618 they do occur. Protection also includes preparing incident handling 1619 guidelines as part of a contingency plan for your organization or 1620 site. Having written plans eliminates much of the ambiguity which 1621 occurs during an incident, and will lead to a more appropriate and 1622 thorough set of responses. It is vitally important to test the 1623 proposed plan before an incident occurs through 'dry runs'. A team 1624 might even consider hiring a tiger team to act in parallel with the 1625 dry run. 1627 Learning to respond efficiently to an incident is important for a 1628 number of reasons: 1630 (1) protecting the assets which could be compromised 1631 (2) protecting resources which could be utilized more profitably 1632 if an incident did not require their services 1633 (3) taking care that (government or other) regulations are complied 1634 with 1635 (4) preventing the use of your systems in attacks against other 1636 systems (which could incur legal liability) 1637 (5) minimizing the potential for negative exposure 1639 As in any set of pre-planned procedures, attention must be placed on 1640 a set of goals for handling an incident. These goals will be 1641 prioritized differently depending on the site. A specific set of 1642 objectives can be identified for dealing with incidents: 1644 (1) Figure out how it happened. 1645 (2) Find out how to avoid further exploitation of the same 1646 vulnerability. 1647 (3) Avoid escalation and further incidents. 1648 (4) Recover from the incident. 1649 (5) Find out who did it. 1651 Due to the nature of the incident there might be a conflict between 1652 analyzing the original source of a problem instead of restoring 1653 systems and services. In this case overall goals (like assuring the 1654 integrity of (life) critical systems) might be the reason for not 1655 analyzing an incident. Of course this is an important management 1656 decision, but all involved parties must be aware that without a 1657 analysis the same incident may happen again. 1659 It is important to prioritize actions to be taken during an incident 1660 well in advance of the time an incident occurs. Sometimes an 1661 incident may be so complex that it is impossible to do everything at 1662 once to respond to it; priorities are essential. Although priorities 1663 will vary from institution to institution, the following suggested 1664 priorities may serve as a starting point for defining an 1665 organization's response: 1667 (1) Priority one -- protect human life and people's 1668 safety; human life always has precedence over all 1669 other considerations. 1671 (2) Priority two -- protect classified and/or sensitive 1672 data. Prevent exploitation of classified and/or 1673 sensitive systems, networks or sites. Inform effected 1674 classified and/or sensitive systems, networks or sites 1675 about already occurred penetrations. 1676 (Be aware of regulations by your site or by government) 1678 (3) Priority three -- protect other data, including 1679 proprietary, scientific, managerial and other data, 1680 because loss of data is costly in terms of resources. 1681 Prevent exploitations of other systems, networks or 1682 sites and inform already effected systems, networks or 1683 sites about successful penetrations. 1685 (4) Priority four -- prevent damage to systems (e.g., loss 1686 or alteration of system files, damage to disk drives, 1687 etc.); damage to systems can result in costly down 1688 time and recovery. 1690 (5) Priority five -- minimize disruption of computing 1691 resources; it is better in many cases to shut a system 1692 down or disconnect from a network than to risk damage 1693 to data or systems. 1695 An important implication for defining priorities is that once human 1696 life and national security considerations have been addressed, it is 1697 generally more important to save data than system software and 1698 hardware. Although it is undesirable to have any damage or loss 1699 during an incident, systems can be replaced; the loss or compromise 1700 of data (especially classified data), however, is usually not an 1701 acceptable outcome under any circumstances. 1703 Another important concern is the effect on others, beyond the systems 1704 and networks where the incident occurs. Within the limits imposed by 1705 government regulations it is always important to inform effected 1706 parties as soon as possible. Due to the legal implications of this 1707 topic, it should be included in the planned procedures to avoid 1708 further delays and uncertainty for the administrators. 1710 Any plan for responding to security incidents should be guided by 1711 local policies and regulations. Government and private sites that 1712 deal with classified material have specific rules that they must 1713 follow. 1715 The policies chosen by your site on how it reacts to incidents will 1716 shape your response. For example, it may make little sense to create 1717 mechanisms to monitor and trace intruders if your site does not plan 1718 to take action against the intruders if they are caught. Other 1719 organizations may have policies that affect your plans. Telephone 1720 companies often release information about telephone traces only to 1721 law enforcement agencies. 1723 5.2 Notification and Point of Contacts 1725 It is important to establish contacts with various personnel before 1726 a real incident occurs. These contacts are either local, other 1727 system responsible or administrative contacts administrators 1728 elsewhere on the Internet or are investigative agencies. Working 1729 with these contacts appropriately will help to make your incident 1730 handling process more efficient. 1732 Communication may need to be established with various "Points of 1733 Contact." These may be technical or administrative in nature, may 1734 include legal or investigative agencies, as well as Service Providers 1735 and vendors. It is important to decide how much information will be 1736 shared, especially with the wider community of users at a site, with 1737 the public (the press) and with other sites. 1739 Settling these issues are especially important for the local person 1740 responsible for handling the incident, since that is the person 1741 responsible for the actual notification of others. A list of 1742 contacts in each of these categories is an important time saver for 1743 this person during an incident. It can be quite difficult to find an 1744 appropriate person during an incident when many urgent events are 1745 ongoing. Including relevant telephone numbers (also electronic mail 1746 addresses and fax numbers) in the site security policy is strongly 1747 recommended. It is especially important to know how to contact 1748 individuals who will be directly involved in handling a security 1749 incident. 1751 5.2.1 Local Managers and Personnel 1753 When an incident is under way, a major issue is deciding who is in 1754 charge of coordinating the activity of the multitude of players. A 1755 major mistake that can be made is to have a number of "points of 1756 contact" (POC) that are not pulling their efforts together. This 1757 will only add to the confusion of the event, and will probably lead 1758 to wasted or ineffective effort. 1760 The single point of contact may or may not be the person "in charge" 1761 of the incident. There are two distinct roles to fill when deciding 1762 who shall be the point of contact and the person in charge of the 1763 incident. The person in charge will make decisions as to the 1764 interpretation of policy applied to the event. The responsibility 1765 for the handling of the event falls onto this person. In contrast, 1766 the point of contact must coordinate the effort of all the parties 1767 involved with handling the event. 1769 The point of contact must be a person with the technical expertise to 1770 successfully coordinate the effort of the system managers and users 1771 involved in monitoring and reacting to the attack. Often the 1772 management structure of a site is such that the administrator of a 1773 set of resources is not a technically competent person with regard to 1774 handling the details of the operations of the computers, but is 1775 ultimately responsible for the use of these resources. 1777 Another important function of the POC is to maintain contact with law 1778 enforcement and other external agencies to assure that multi- agency 1779 involvement occurs. (In the U.S. FBI, CIA, DoD, U.S. Army, or others 1780 might be concerned.) 1782 Finally, if legal action in the form of prosecution is involved, the 1783 POC may be asked to speak for the site in court. The alternative is 1784 to have multiple witnesses that will be hard to coordinate in a legal 1785 sense, and will weaken any case against the attackers. A single POC 1786 may also be the single person in charge of collecting evidence, which 1787 will keep the number of people accounting for evidence to a minimum. 1788 As a rule of thumb, the more people that touch a potential piece of 1789 evidence, the greater the possibility that it will be inadmissible in 1790 court. 1792 One of the most critical tasks for the POC is the coordination of 1793 all relevant processes. As responsibilities might be distributed 1794 over the whole site, which may well consist of multiple independent 1795 departments or groups, a well coordinate effort is crucial for 1796 overall success. The situation get even worse if multiple sites are 1797 involved. In many cases, no single POC in one site can coordinate 1798 the handling of an entire incident. The appropriate incident 1799 response teams are more suitable, if multiple sites are involved. 1801 The incident handling process should provide some escalation 1802 mechanisms. The POC might change; the impact of the incident force 1803 the management to take the lead instead of giving the technical 1804 administrator the responsibility. Other reasons for changing the POC 1805 are the emergence of conflicts of interest, changing priorities or 1806 responsibilities. Regardless of why the POC is changed, all involved 1807 parties must be informed. Arrangements should be made to allow the 1808 new POC to contact the old one, to ensure an adequate briefing of 1809 background information. 1811 5.2.2 Law Enforcement and Investigative Agencies 1813 In the event of an incident that has legal consequences it is 1814 important to establish contact with investigative agencies such as 1815 the FBI and Secret Service or their equivalent in your country, as 1816 soon as possible. Local law enforcement and local security offices 1817 or campus police departments should also be informed as appropriate. 1819 A primary reason is that once a major attack is in progress, there 1820 is little time to call these agencies to determine exactly who the 1821 correct point of contact is. Another reason is that it is important 1822 to cooperate with these agencies in a manner that will foster a good 1823 working relationship, and that will be in accordance with the working 1824 procedures of these agencies. Knowing the working procedures in 1825 advance and the expectations of your point of contact is a big step 1826 in this direction. For example, it is important to gather evidence 1827 that will be admissible in a court of law, requiring prior knowledge 1828 of how to gather such evidence. A final reason for establishing 1829 contacts as soon as possible is that it is impossible to know the 1830 particular agency that will assume jurisdiction in any given 1831 incident. Making contacts and finding the proper channels early will 1832 make responding to an incident go considerably more smoothly. 1834 If your organization or site has a legal counsel, you need to notify 1835 this office soon after you learn that an incident is in progress. At 1836 a minimum, your legal counsel needs to be involved to protect the 1837 legal and financial interests of your site or organization. There 1838 are many legal and practical issues, a few of which are: 1840 (1) Whether your site or organization is willing to risk 1841 negative publicity or exposure to cooperate with legal 1842 prosecution efforts. 1844 (2) Downstream liability--if you leave a compromised system 1845 as is so it can be monitored and another computer is damaged 1846 because the attack originated from your system, your site or 1847 organization may be liable for damages incurred. 1849 (3) Distribution of information--if your site or organization 1850 distributes information about an attack in which another 1851 site or organization may be involved or the vulnerability 1852 in a product that may affect ability to market that 1853 product, your site or organization may again be liable 1854 for any damages (including damage of reputation). 1856 (4) Liabilities due to monitoring--your site or organization 1857 may be sued if users at your site or elsewhere discover 1858 that your site is monitoring account activity without 1859 informing users. 1861 Unfortunately, there are no clear precedents yet on the liabilities 1862 or responsibilities of organizations involved in a security incident 1863 or who might be involved in supporting an investigative effort. 1864 Investigators will often encourage organizations to help trace and 1865 monitor intruders -- indeed, most investigators cannot pursue 1866 computer intrusions without extensive support from the organizations 1867 involved. However, investigators cannot provide protection from 1868 liability claims, and these kinds of efforts may drag out for months 1869 and may take lots of effort. 1871 On the other side, an organization's legal council may advise extreme 1872 caution and suggest that tracing activities be halted and an intruder 1873 shut out of the system. This in itself may not provide protection 1874 from liability, and may prevent investigators from identifying 1875 anyone. 1877 The balance between supporting investigative activity and limiting 1878 liability is tricky; you'll need to consider the advice of your 1879 council and the damage the intruder is causing (if any) in making 1880 your decision about what to do during any particular incident. 1882 Your legal counsel should also be involved in any decision to 1883 contact investigative agencies when an incident occurs at your site. 1884 The decision to coordinate efforts with investigative agencies is 1885 most properly that of your site or organization. Involving your 1886 legal counsel will also foster the multi-level coordination between 1887 your site and the particular investigative agency involved which in 1888 turn results in an efficient division of labor. Another result is 1889 that you are likely to obtain guidance that will help you avoid 1890 future legal mistakes. 1892 Finally, your legal counsel should evaluate your site's written 1893 procedures for responding to incidents. It is essential to obtain a 1894 "clean bill of health" from a legal perspective before you actually 1895 carry out these procedures. 1897 It is vital when dealing with investigative agencies to verify that 1898 the person who calls asking for information is a legitimate 1899 representative from the agency in question. Unfortunately, many 1900 well intentioned people have unknowingly leaked sensitive details 1901 about incidents, allowed unauthorized people into their systems, 1902 etc., because a caller has masqueraded as a representative of a 1903 government agency. 1905 A similar consideration is using a secure means of communication. 1906 Because many network attackers can easily reroute electronic mail, 1907 avoid using electronic mail to communicate with other agencies (as 1908 well as others dealing with the incident at hand). Non-secured phone 1909 lines (the phones normally used in the business world) are also 1910 frequent targets for tapping by network intruders, so be careful! 1912 There is no established set of rules for responding to an incident 1913 when the local Government becomes involved. Normally, except by 1914 court order, no agency can force you to monitor, to disconnect from 1915 the network, to avoid telephone contact with the suspected attackers, 1916 etc. As discussed before, you should consult the matter with your 1917 legal counsel, especially before taking an action that your 1918 organization has never taken. 1920 The particular agency involved may ask you to leave an attacked 1921 machine on and to monitor activity. Complying with this request 1922 will ensure continued cooperation of the agency. This is usually 1923 the best route towards finding the source of the network attacks 1924 and, ultimately, terminating these attacks. Additionally, you may 1925 need information or a favor from the agency involved. You are 1926 likely to get what you need only if you have been cooperative. It 1927 is particularly important to avoid unnecessary or unauthorized 1928 disclosure of information about the incident, including any 1929 information furnished by the agency involved: Don't compromise the 1930 case the agency is trying to build. If you do not cooperate with an 1931 agency, you will be less likely to receive help in the future. 1933 Sometimes your needs and the needs of an investigative agency will 1934 differ. Your site may want to get back to normal business by 1935 closing an attack route, but the investigative agency may want you 1936 to keep this route open. Similarly, your site may want to close a 1937 compromised system down to avoid the possibility of negative 1938 publicity, but again the investigative agency may want you to 1939 continue monitoring. When there is such a conflict, there may be a 1940 complex set of tradeoffs (e.g., interests of your site's management, 1941 amount of resources you can devote to the problem, jurisdictional 1942 boundaries, etc.). An important guiding principle is related to what 1943 might be called "Internet citizenship" [22, IAB89, 23 (xxx old 1944 references)] and its responsibilities. See section 5.6. 1946 5.2.3 Computer Security Incident Handling Teams 1948 There now exists a number of Computer Security Incident Handling 1949 teams (CSIH teams) such as the CERT Coordination Center and the CIAC 1950 or other teams around the globe. Teams exist for many major 1951 government agencies and large corporations. If such a team is 1952 available, notifying it should be of primary importance during the 1953 early stages of an incident. These teams are responsible for 1954 coordinating computer security incidents over a range of sites and 1955 larger entities. Even if the incident is believed to be contained 1956 within a single site, it is possible that the information available 1957 through a response team could help in closing out the incident. 1959 If it is determined that the breach occurred due to a flaw in the 1960 systems' hardware or software, the vendor (or supplier) and a 1961 Computer Security Incident Handling team should be notified as soon 1962 as possible. This is especially important due to the fact that many 1963 other systems are vulnerable, too. 1965 In setting up a site policy for incident handling, it may be 1966 desirable to create a subgroup, much like those teams that already 1967 exist, that will be responsible for handling computer security 1968 incidents for the site (or organization). If such a team is created, 1969 it is essential that communication lines be opened between this team 1970 and other teams. Once an incident is under way, it is difficult to 1971 open a trusted dialogue between other teams if none has existed 1972 before. (See [RFC xxx] for more information about the considerations 1973 for creating your own incident handling team.) 1975 5.2.4 Effected and involved Sites 1977 If an incident has an impact on other sites, it is good practice to 1978 inform them. It may be obvious from the beginning that the incident 1979 is not limited to the local site, or it may emerge only after further 1980 analysis. 1982 Each site might choose to contact other sites directly or they can 1983 pass the information to an appropriate incident response team, to 1984 which the involved site belongs. As it is often very difficult to 1985 find the responsible POC at remote sites, the involvement of an 1986 incident response team will facilitate contact by making use of 1987 already established channels. 1989 The legal and liability issues arising from a security incident may 1990 differ from site to site. It is important to define a policy for the 1991 sharing and logging of information about other sites before an 1992 incident occurs. This policy should be crafted in consultation with 1993 legal counsel. 1995 Information about specific people is especially sensitive, and is 1996 subject to privacy laws. To avoid problems in this area, irrelevant 1997 information should be deleted and a statement of how to handle the 1998 remaining information should be included. A clear statement of how 1999 this information is to be used is essential. (No one who informs a 2000 site of a security incident would like to read in the newspaper that 2001 they also had a problem.) Incident response teams are valuable in 2002 this respect. As they pass information to responsible POCs, they are 2003 able to protect the anonymity of the original source. But be aware 2004 that in many cases the analysis of logs and information at other 2005 sites will reveal addresses of your site. 2007 All the problems discussed should be not seen as reasons not to 2008 involve other sites. In fact, the experiences of existing teams 2009 reveal that most sites informed about security problems are not even 2010 aware that their site had been compromised. Without timely 2011 information other sites are often unable to take measures against 2012 intruders. 2014 5.2.5 Public Relations - Press Releases 2016 One of the most important issues to consider is when, who, and how 2017 much to release to the general public through the press. There are 2018 many issues to consider when deciding this particular issue. First 2019 and foremost, if a public relations office exists for the site, it is 2020 important to use this office as liaison to the press. The public 2021 relations office is trained in the type and wording of information 2022 released, and will help to assure that the image of the site is 2023 protected during and after the incident (if possible). A public 2024 relations office has the advantage that you can communicate candidly 2025 with them, and provide a buffer between the constant press attention 2026 and the need of the POC to maintain control over the incident. 2028 If a public relations office is not available, the information 2029 released to the press must be carefully considered. If the 2030 information is sensitive, it may be advantageous to provide only 2031 minimal or overview information to the press. It is quite possible 2032 that any information provided to the press will be quickly reviewed 2033 by the perpetrator of the incident. Also note that misleading the 2034 press can often backfire and cause more damage than releasing 2035 sensitive information. 2037 While it is difficult to determine in advance what level of detail to 2038 provide to the press, some guidelines to keep in mind are: 2040 (1) Keep the technical level of detail low. Detailed 2041 information about the incident may provide enough 2042 information for copy-cat events or even damage the 2043 site's ability to prosecute once the event is over. 2045 (2) Keep the speculation out of press statements. 2046 Speculation of who is causing the incident or the 2047 motives are very likely to be in error and may cause 2048 an inflamed view of the incident. 2050 (3) Work with law enforcement professionals to assure that 2051 evidence is protected. If prosecution is involved, 2052 assure that the evidence collected is not divulged to 2053 the press. 2055 (4) Try not to be forced into a press interview before you are 2056 prepared. The popular press is famous for the "2 am" 2057 interview, where the hope is to catch the interviewee off 2058 guard and obtain information otherwise not available. 2060 (5) Do not allow the press attention to detract from the 2061 handling of the event. Always remember that the successful 2062 closure of an incident is of primary importance. 2064 5.3 Identifying an Incident 2066 5.3.1 Is it real? 2068 This stage involves determining if a problem really exists. Of 2069 course many if not most signs often associated with virus infection, 2070 system intrusions, malicious users, etc., are simply anomalies such 2071 as hardware failures or suspicious system/user behavior. To assist 2072 in identifying whether there really is an incident, it is usually 2073 helpful to obtain and use any detection software which may be 2074 available. Audit information is also extremely useful, especially 2075 in determining whether there is a network attack. It is extremely 2076 important to obtain a system snapshot as soon as one suspects that 2077 something is wrong. Many incidents cause a dynamic chain of events 2078 to occur, and an initial system snapshot may be the most valuable 2079 tool for identifying the problem and any source of attack. Finally, 2080 it is important to start a log book. Recording system events, 2081 telephone conversations, time stamps, etc., can lead to a more rapid 2082 and systematic identification of the problem, and is the basis for 2083 subsequent stages of incident handling. 2085 There are certain indications or "symptoms" of an incident which 2086 deserve special attention: 2088 (1) System crashes. 2089 (2) New user accounts (the account RUMPLESTILTSKIN has 2090 unexplainedly been created), or high activity on an 2091 (3) New files (usually with novel or strange file names, 2092 such as data.xx or k or .xx ). 2093 (4) Accounting discrepancies (in a UNIX system you might 2094 notice the shrinking of an accounting file called 2095 /usr/admin/lastlog, something that should make you very 2096 suspicious that there may be an intruder). 2097 (5) Changes in file lengths or dates (a user should be 2098 suspicious if .EXE files in an MS DOS computer have 2099 unexplainedly grown by over 1800 bytes). 2100 (6) Attempts to write to system (a system manager notices 2101 that a privileged user in a VMS system is attempting to 2102 alter RIGHTSLIST.DAT). 2103 (7) Data modification or deletion (files start to disappear). 2104 (8) Denial of service (a system manager and all other users 2105 become locked out of a UNIX system, now in single user mode). 2106 (9) Unexplained, poor system performance 2107 (10) Anomalies ("GOTCHA" is displayed on the console or there 2108 are frequent unexplained "beeps"). 2109 (11) Suspicious probes (there are numerous unsuccessful login 2110 attempts from another node). 2111 (12) Suspicious browsing (someone becomes a root user on a UNIX 2112 system and accesses file after file many user accounts.) 2114 By no means is this list comprehensive. We have just listed a number 2115 of common indicators. It is best to collaborate with other 2116 technical and computer security personnel to make a decision as a 2117 group about whether an incident is occurring. 2119 5.3.2 Types and Scope of Incidents 2121 Along with the identification of the incident is the evaluation of 2122 the scope and impact of the problem. It is important to correctly 2123 identify the boundaries of the incident in order to effectively deal 2124 with it and prioritize responses. 2126 In order to identify the scope and impact a set of criteria should 2127 be defined which is appropriate to the site and to the type of 2128 connections available. Some of the issues include: 2130 (1) Is this a multi-site incident? 2131 (2) Are many computers at your site effected by this incident? 2132 (3) Is sensitive information involved? 2133 (4) What is the entry point of the incident (network, 2134 phone line, local terminal, etc.)? 2135 (5) Is the press involved? 2136 (6) What is the potential damage of the incident? 2137 (7) What is the estimated time to close out the incident? 2138 (8) What resources could be required to handle the incident? 2139 (9) Is law enforcement involved? 2141 5.3.3 Assessing the Damage and Extent 2143 The analysis of the damage and extent of the incident can be quite 2144 time consuming, but should lead into some of the insight as to the 2145 nature of the incident, and aid investigation and prosecution. As 2146 soon as the breach has occurred, the entire system and all its 2147 components should be considered suspect. System software is the most 2148 probable target. Preparation is key to be able to detect all changes 2149 for a possibly tainted system. This includes checksumming all tapes 2150 from the vendor using a checksum algorithm which (hopefully) is 2151 resistant to tampering [10]. (See sections xxx 4.7?) 2153 Assuming original vendor distribution tapes are available, an 2154 analysis of all system files should commence, and any irregularities 2155 should be noted and referred to all parties involved in handling the 2156 incident. It can be very difficult, in some cases, to decide which 2157 backup tapes are showing a correct system status; consider that the 2158 incident may have continued for months or years before discovery, 2159 and that the suspect may be an employee of the site, or otherwise 2160 have intimate knowledge or access to the systems. In all cases, the 2161 pre-incident preparation will determine what recovery is possible. 2163 If the system supports centralized logging (most do), go back over 2164 the logs and look for abnormalities. If process accounting and 2165 connect time accounting is enabled, look for patterns of system 2166 usage. To a lesser extent, disk usage may shed light on the 2167 incident. Accounting can provide much helpful information in an 2168 analysis of an incident and subsequent prosecution. Your ability 2169 to address all aspects of a specific incident strongly depends on 2170 the success of this analysis. 2172 5.4 Handling an Incident 2174 Certain steps are necessary to take during the handling of an 2175 incident. In all security related activities, the most important 2176 point to be made is: One should have policies in place. Without 2177 defined goals, activities undertaken will remain without focus. The 2178 goals should be defined by management and legal counsel in advance. 2180 One of the most fundamental objectives is to restore control of the 2181 effected systems and to limit the impact and damage. In the worst 2182 case scenario, shutting down the system or disconnecting the system 2183 from the network may the only practical solution. 2185 As the activities involved are complex, try to get as much help as 2186 necessary. While trying to solve the problem alone, real damage 2187 might occur due to delays or missing information. Most system 2188 administrators take the discovery of an intruder as personal 2189 challenge. By proceeding this way, other objectives as outlined in 2190 the local policies may not always considered. Trying to catch 2191 intruders may be a very low priority, compared to system integrity, 2192 for example. Monitoring a hacker's activity is useful, but it might 2193 not be considered worth the risk to allow continued access. 2195 5.4.1 Types of notification, Exchange of information 2197 When you have confirmed that an incident is occurring, the 2198 appropriate personnel must be notified. How this notification is 2199 achieved is very important in keeping the event under control both 2200 from a technical and emotional standpoint. The circumstances should 2201 be described in as much detail as possible, in order to aid prompt 2202 acknowledgment and understanding of the problem. Great care should 2203 be taken to which groups detailed technical information is given 2204 during the notification. For example it is helpful to pass this 2205 kind of information to an incident handling team. They can assist 2206 you by providing helpful hints for eradicating the vulnerabilities 2207 involved in an incident. On the other hand putting the critical 2208 knowledge into the public domain (e. g. netnews, mailing lists) may 2209 potentially put a great number of systems at risk of intrusion. It 2210 is invalid to assume that all administrators are reading a particular 2211 news group have access to operating system source code or can even 2212 understand an advisory well enough to take adequate steps. 2214 First of all, any notification to either local or off-site personnel 2215 must be explicit. This requires that any statement (be it an 2216 electronic mail message, phone call, or fax) provides information 2217 about the incident that is clear, concise and fully qualified. When 2218 you are notifying others that will help you to handle an event, a 2219 "smoke screen" will only divide the effort and create confusion. If 2220 a division of labor is suggested, it is helpful to provide 2221 information to each participant about what is being accomplished in 2222 other efforts. This will not only reduce duplication of effort, but 2223 allow people working on parts of the problem to know where to obtain 2224 information relevant to their part of the incident. 2226 Another important consideration when communicating about the incident 2227 is to be factual. Attempting to hide aspects of the incident by 2228 providing false or incomplete information may not only prevent a 2229 successful resolution to the incident, but may even worsen the 2230 situation. 2232 The choice of language used when notifying people about the incident 2233 can have a profound effect on the way that information is received. 2234 When you use emotional or inflammatory terms, you raise the 2235 expectations of damage and negative outcomes of the incident. It is 2236 important to remain calm both in written and spoken notifications. 2238 Another aspect of the choice of language used is that not all people 2239 speak the same language. Due to this fact misunderstandings and 2240 delay may arise, especially if it is a multi-national incident. 2241 Other international concerns include differing legal implications of 2242 a security incident and cultural differences. Cultural differences 2243 do not only exist between countries like Germany and Australia. They 2244 even exist within countries between different social groups or user 2245 groups. An administrator of a university system might be very 2246 relaxed about attempts to connect to the system via telnet, but the 2247 administrator of a military system will follow his procedures and 2248 consider the same action as a possible attack. 2250 Another issue associated with the choice of language is the 2251 notification of non-technical or off-site personnel. It is important 2252 to accurately describe the incident without undue alarm or confusing 2253 messages. While it is more difficult to describe the incident to a 2254 non-technical audience, it is often more important. A non-technical 2255 description may be required for upper-level management, the press, or 2256 law enforcement liaisons. The importance of these notifications 2257 cannot be underestimated and may make the difference between handling 2258 the incident properly and escalating to some higher level of damage. 2260 If an IRT becomes involved it might be necessary to fill out a 2261 template for the information exchange. Although this may seem to be 2262 an additional burden and adds a certain delay, it helps the team to 2263 act on this minimum set of information. The response team may be 2264 able to respond to aspects of the incident which the local 2265 administrator is unaware of. If information is given out to someone 2266 else, the following minimum information should be provided: 2268 (1) timezone of logs, ... in GMT or local time 2269 (2) information about the remote system (including host names, 2270 ip addresses and user ids) 2271 (3) all log entries relevant for the remote site 2272 (4) type of incident (what happened, why should you care) 2274 If local information (ie. local user ids) is included in the log 2275 entries, it might be necessary to sanitize the entries beforehand 2276 to avoid privacy issues. In general, all information which might 2277 assist a remote site in resolving an incident should be given out, 2278 unless local policies prohibit this. 2280 5.4.2 Protection of evidence and activity logs 2282 When you respond to an incident, document all details related to the 2283 incident. This will provide valuable information to yourself and 2284 others as you try to unravel the course of events. Documenting all 2285 details will ultimately save you time. If you don't document every 2286 relevant phone call, for example, you are likely to forget a good 2287 portion of information you obtain, requiring you to contact the 2288 source of information once again. At the same time, recording 2289 details will provide evidence for prosecution efforts, providing the 2290 case moves in this direction. Documenting an incident also will help 2291 you perform a final assessment of damage (something your management 2292 as well as law enforcement officers will want to know), and will 2293 provide the basis for later phases of the handling process: 2294 eradication, recovery and follow-up "lessons learned." 2296 During the initial stages of an incident, it is often infeasible to 2297 determine whether prosecution is viable, so you should document as if 2298 you are gathering evidence for a court case. At a minimum, you 2299 should record: 2301 (1) All system events (audit records). 2302 (2) All actions you take (time tagged). 2303 (3) All phone conversations (including the person with whom 2304 you talked, the date and time, and the content of the 2305 conversation). 2307 The most straightforward way to maintain documentation is keeping a 2308 log book. This allows you to go to a centralized, chronological 2309 source of information when you need it, instead of requiring you to 2310 page through individual sheets of paper. Much of this information is 2311 potential evidence in a court of law. Thus, when you initially 2312 suspect that an incident will result in prosecution or when an 2313 investigative agency becomes involved, you need to: 2315 (1) Regularly (e.g., every day) turn in photocopied, signed 2316 copies of your logbook (as well as media you use to record 2317 system events) to a document custodian. 2318 (2) The custodian should store these copied pages in a secure 2319 place (e.g., a safe). 2320 (3) When you submit information for storage, you should in 2321 return receive a signed, dated receipt from the document 2322 custodian. 2324 Failure to observe these procedures can result in invalidation of 2325 any evidence you obtain in a court of law. 2327 5.4.3 Containment 2329 The purpose of containment is to limit the extent of an attack. An 2330 essential part of containment is decision making (i.e., determining 2331 whether to shut a system down, disconnect from a network, monitor 2332 system or network activity, set traps, disable functions such as 2333 remote file transfer on a UNIX system, etc.). 2335 Sometimes this decision is trivial; shut the system down if the 2336 system is life critical, classified or sensitive, or if proprietary 2337 information is at risk! Bear in mind that removing all access while 2338 an incident is in progress obviously notifies all users, including 2339 the alleged problem users, that the administrators are aware of a 2340 problem; this may have a deleterious effect on an investigation. In 2341 some cases, it is prudent to remove all access or functionality as 2342 soon as possible, then restore normal operation in limited stages. 2343 In other cases, it is worthwhile to risk some damage to the system 2344 if keeping the system up might enable you to identify an intruder. 2346 This stage should involve carrying out predetermined procedures. 2347 Your organization or site should, for example, define acceptable 2348 risks in dealing with an incident, and should prescribe specific 2349 actions and strategies accordingly. This is especially important 2350 when a quick decision is necessary without the possibility to contact 2351 all involved parties and discuss the decision. In most of the cases 2352 the person in charge will have not the power to make a difficult 2353 management decision (like to loss the results of a costly 2354 experiment). Finally, notification of cognizant authorities should 2355 occur during this stage. 2357 5.4.4 Eradication 2359 Once the incident has been contained, it is time to eradicate the 2360 cause. But before eradicating the cause great care should be taken 2361 to collect all necessary information about the compromised system 2362 and the cause of the incident as they will likely be lost when 2363 cleaning up the system. 2365 Software may be available to help you in the eradication process, 2366 such as anti-virus software for small systems. If any bogus files 2367 have been created archive them before deleting them. In the case of 2368 virus infections, it is important to clean and reformat any disks 2369 containing infected files. Finally, ensure that all backups are 2370 clean. Many systems infected with viruses become periodically re 2371 infected simply because people do not systematically eradicate the 2372 virus from backups. After eradication a new backup should be taken, 2373 too. 2375 Removing all vulnerabilities once an incident has occurred is 2376 difficult. The key to removing vulnerabilities is knowledge and 2377 understanding of the breach. 2379 It may be necessary to go back to the original distributed tapes and 2380 re customize the system. To facilitate this worst case scenario, a 2381 record of the original systems setup and each customization change 2382 should be kept current with each change to the system. In the case 2383 of a network-based attack, it is important to install patches for any 2384 operating system vulnerability which was exploited. 2386 As discussed in section 5.4.2, a security log can be most valuable 2387 during this phase of removing vulnerabilities. The logs showing how 2388 the incident was discovered and contained can be used later to help 2389 determine how extensive the damage was from a given incident. The 2390 steps taken can be used in the future to make sure the problem does 2391 not resurface. Ideally, one should automate and regularly apply same 2392 test as was used to detect the security incident. 2394 If a particular vulnerability is isolated as having been exploited, 2395 the next step is to find a mechanism to protect your system. The 2396 security mailing lists and bulletins would be a good place to search 2397 for this information and you can get advice from incident response 2398 teams. 2400 5.4.5 Recovery 2402 Once the cause of an incident has been eradicated, the recovery phase 2403 defines the next stage of action. The goal of recovery is to return 2404 the system to normal. In general, bringing up services in the order 2405 of demand to allow a minimum of user inconvenience is the best 2406 practice. Understand that the proper recovery procedures for the 2407 system are extremely important and should be specific to the site. 2409 5.4.6 Follow-Up 2411 Once you believe that a system has been restored to a "safe" state, 2412 it is still possible that holes and even traps could be lurking in 2413 the system. One of the most important stages of responding to 2414 incidents is also the most often omitted---the follow-up stage. In 2415 the follow-up stage, the system should be monitored for items that 2416 may have been missed during the cleanup stage. It would be prudent 2417 to utilize some of the tools mentioned in section xxx (e.g., xxx) as 2418 a start. Remember, these tools don't replace continual system 2419 monitoring and good systems administration practices. 2421 The most important element of the follow-up stage is performing a 2422 postmortem analysis. Exactly what happened, and at what times? How 2423 well did the staff involved with the incident perform? What kind of 2424 information did the staff need quickly, and how could they have 2425 gotten that information as soon as possible? What would the staff do 2426 differently next time? 2428 After an incident, it is prudent to write a report describing the 2429 exact sequence of events: the method of discovery, correction 2430 procedure, monitoring procedure, and a summary of lesson learned. 2431 This will aid in the clear understanding of the problem. Creating 2432 a formal chronology of events (including time stamps) is also 2433 important for legal reasons. 2435 A follow-up report is valuable for many reasons. It provides a 2436 reference to be used in case of other similar incidents. It is 2437 also important to as quickly as possible obtain a monetary estimate 2438 of the amount of damage the incident caused in terms of any loss of 2439 software and files, hardware damage, and manpower costs to restore 2440 altered files, reconfigure affected systems, and so forth. This 2441 estimate may become the basis for subsequent prosecution activity. 2442 The report can also help justify an organization's computer 2443 security effort to management. 2445 5.5 Aftermath of an Incident 2447 In the wake of an incident, several actions should take place. These 2448 actions can be summarized as follows: 2450 (1) An inventory should be taken of the systems' assets, 2451 i. e., a careful examination should determine how the 2452 system was affected by the incident, 2454 (2) The lessons learned as a result of the incident 2455 should be included in revised security plan to 2456 prevent the incident from re-occurring, 2458 (3) A new risk analysis should be developed in light of the 2459 incident, 2461 (4) An investigation and prosecution of the individuals 2462 who caused the incident should commence, if it is 2463 deemed desirable. 2465 If an incident is based on poor policy, and unless the policy is 2466 changed, then one is doomed to repeat the past. Once a site has 2467 recovered from and incident, site policy and procedures should be 2468 reviewed to encompass changes to prevent similar incidents. Even 2469 without an incident, it would be prudent to review policies and 2470 procedures on a regular basis. Reviews are imperative due to today's 2471 changing computing environments. 2473 The whole purpose of this "post mortem" process is to improve all 2474 security measures to protect the site against future attacks. In the 2475 light of an incident one should gather practical knowledge from the 2476 experience. A concrete goal is developing proactive methods, for 2477 example: early warning by probes. Another important facet of the 2478 aftermath may be end user and administrator education to prevent a 2479 reoccurrence of a security problem. 2481 5.6 Responsibilities 2483 5.6.1 Not crossing the line 2485 It is one thing to protect one's own network, but quite another to 2486 assume that one should protect other networks. During the handling 2487 of an incident, certain system vulnerabilities of one's own systems 2488 and the systems of others become apparent. It is quite easy and may 2489 even be tempting to pursue the intruders in order to track them. 2490 Keep in mind that at a certain point it is possible to 'cross the 2491 line,' and with the best intentions, become no better than the 2492 intruder. 2494 The best rule when it comes to propriety is to not use any facility 2495 of remote sites which is not public. This clearly excludes any entry 2496 onto a system (such as a remote shell or login session) which is not 2497 expressly permitted. This may be very tempting; after a breach of 2498 security is detected, a system administrator may have the means to 2499 'follow it up,' to ascertain what damage is being done to the remote 2500 site. Don't do it. Instead attempt to reach the appropriate point of 2501 contact for the affected site. 2503 5.6.2 Good Internet Citizenship 2505 During a security incident there are two choices one can make. 2506 First, a site can choose to watch the intruder in the hopes of 2507 catching him. Or, the site can go about cleaning up after the 2508 incident and shut the intruder out of the systems. This is a 2509 decision that must be made very thoughtfully as there may be legal 2510 liabilities if you choose to leave your site open, knowing that an 2511 intruder is using your site as a launching pad to reach out to other 2512 sites. Being a good Internet citizen means that you should try to 2513 alert other sites that may have been impacted by the intruder. These 2514 affected sites may be readily apparent after a thorough review of 2515 your log files. 2517 5.6.3 Administrative Response to Incidents 2519 When a security incident involves a user, the site's security policy 2520 should describe what action is to be taken. The transgression should 2521 be taken seriously, but it is very important to be sure of the role 2522 the user played. Was the user naive? Could there be a mistake in 2523 attributing the security breach to the user? Applying administrative 2524 action that assumes the user intentionally caused the incident may 2525 not be appropriate for a use who simply made a mistake. It may be 2526 appropriate to include sanctions more suitable for such a situation 2527 in your policies (e.g., education or reprimand of a user) in addition 2528 to more stern measures for intentional acts of intrusion and system 2529 misuse. 2531 6. ONGOING ACTIVITIES 2533 At this point in time, your site has hopefully developed a complete 2534 security policy and developed procedures to assist in the 2535 configuration and management of your technology in support of those 2536 policies. How nice it would be if you could sit back and relax at 2537 this point and know that you were finished with the job of security. 2538 Unfortunately, that isn't the case. Your systems and networks are 2539 not a static environment so you will need to review policies and 2540 procedures on a regular basis. There are a number of steps you can 2541 take to help you keep up with the changes around you so that you can 2542 initiate corresponding actions to address those changes. The 2543 following is a starter set. You will add others as appropriate for 2544 your site. 2546 (1) Subscribe to advisories that are issued by various security incident 2547 response teams, like those of the CERT Coordination Center [ref], and 2548 update your systems against those threats that apply to your site's 2549 technology. 2551 (2) Monitor security patches that are produced by the vendors of your 2552 equipment, and obtain and install all that apply. 2554 (3) Actively watch the configurations of your systems to identify any 2555 changes that may have occurred. Then investigate all anomalies. 2557 (4) Review all security policies and procedures annually (at a minimum) 2559 (5) Read appropriate mailing lists and Netnews groups to keep up to date 2560 with the latest information being shared by fellow administrators. 2562 APPENDICES 2564 A1 Tools and Locations 2566 This section provides a brief overview of publicly available security 2567 technology which can be downloaded from the Internet. Many of the 2568 items described below will undoubtedly be surpassed or made obsolete 2569 before this document is published. This section is divided into two 2570 major subsections, applications and tools. The applications heading 2571 will include all end user programs (clients) and their supporting 2572 system infrastructure (servers). The tools heading will deal with 2573 the tools that a general user will never see or need to use, but 2574 which may be part of or used by applications, used to troubleshoot 2575 security problems or guard against intruders by system and network 2576 administrators. 2578 The emphasis will be on UNIX applications and tools, but other 2579 platforms, particularly PC's and Macintoshes, will be mentioned where 2580 information is available. 2582 Most of the tools and applications described below can be found in 2583 one of the following two archive sites: 2585 (1) CERT Coordination Center 2586 ftp://info.cert.org:/pub/tools 2587 (2) DFN-CERT 2588 ftp://ftp.cert.dfn.de/pub/tools/ 2589 (3) Computer Operations, Audit, and Security Tools (COAST) 2590 coast.cs.purdue.edu:/pub/tools 2592 Any references to CERT or COAST will refer to these two locations. 2593 These two sites act as repositories for most tools, exceptions will 2594 be noted in the text. *** It is important to note that many sites, 2595 including CERT and COAST are mirrored throughout the Internet. Be 2596 careful to use a "well known" mirror site to retrieve software and to 2597 use whatever verification tools possible, checksums, md5 checksums, 2598 etc... to validate that software. A clever cracker might advertise 2599 security software with designed flaws in order to gain access to data 2600 or machines. *** 2602 Applications 2604 The sad truth is that there are very few security conscious 2605 applications currently available. The real reason is the need for a 2606 security infrastructure which must be first put into place for most 2607 applications to operate securely. There is considerable effort 2608 currently taking place to place this infrastructure so that 2609 applications can take advantage of secure communications. 2611 Unix based applications 2613 PGP 2614 MD5 2615 S/KEY 2616 TROJAN.PL 2617 PEM 2618 KERBEROS 2619 Drawbridge 2620 Tripwire 2621 logdaemon 2622 TCP-Wrapper 2623 rpcbind/portmapper replacement 2624 cops 2625 tiger 2626 ISS 2627 SATAN 2628 smrsh 2629 swatch 2630 identd (not really a security tool) 2631 DES (non-US versions) 2632 lsof 2633 sfingerd 2634 passwd-replacements (npasswd / ANLpasswd / passwd+ / ...) 2636 A2 Mailing lists and other resources 2638 It would be impossible to list all of the mail-lists and other 2639 resources dealing with site security. However, these are some "jump- 2640 points" from which the reader can begin. All of these references are 2641 for the "INTERNET" constituency. More specific (vendor and 2642 geographical) resouces can be found through these references. 2644 Mailing Lists 2646 (1) CERT Advisory 2647 Send mail to: cert-advisory-request@cert.org 2648 Message Body: subscribe cert FIRSTNAME LASTNAME 2650 A CERT advisory provides information on how to obtain a patch or 2651 details of a workaround for a known computer security problem. 2652 The CERT Coordination Center works with vendors to produce a 2653 workaround or a patch for a problem, and does not publish 2654 vulnerability information until a workaround or a patch is 2655 available. A CERT advisory may also be a warning to our 2656 constituency about ongoing attacks (e.g., 2657 "CA-91:18.Active.Internet.tftp.Attacks"). 2659 CERT advisories are also published on the USENET newsgroup: 2661 comp.security.announce 2663 CERT advisory archives are available via anonymous FTP from 2664 info.cert.org in the /pub/cert_advisories directory. 2666 (2) CERT Tools Mailing List 2667 Send mail to: cert-tools-request@cert.sei.cmu.edu 2668 Message Body: subscribe cert-tools FIRSTNAME LASTNAME 2670 The purpose of this moderated mailing list is to 2671 encourage the exchange of information on security 2672 tools and techniques. The list should not be used 2673 for security problem reports. 2675 (3) VIRUS-L List 2676 Send mail to: listserv%lehiibm1.bitnet@mitvma.mit.edu 2677 Message Body: subscribe virus-L FIRSTNAME LASTNAME 2679 VIRUS-L is a moderated mailing list with a focus 2680 on computer virus issues. For more information, 2681 including a copy of the posting guidelines, see 2682 the file "virus-l.README", available by anonymous 2683 FTP from cs.ucr.edu. 2685 (4) Academic Firewalls 2686 Send mail to: majordomo@greatcircle.com 2687 Message Body: subscribe firewalls user@host 2689 The Firewalls mailing list is a discussion forum for 2690 firewall administrators and implementors. 2692 USENET newsgroups 2694 (1) comp.security.announce 2695 The comp.security.announce newsgroup is moderated 2696 and is used solely for the distribution of CERT 2697 advisories. 2699 (2) comp.security.misc 2700 The comp.security.misc is a forum for the 2701 discussion of computer security, especially as it 2702 relates to the UNIX(r) Operating System. 2704 (3) alt.security 2705 The alt.security newsgroup is also a forum for the 2706 discussion of computer security, as well as other 2707 issues such as car locks and alarm systems. 2709 (4) comp.virus 2710 The comp.virus newsgroup is a moderated newsgroup 2711 with a focus on computer virus issues. For more 2712 information, including a copy of the posting 2713 guidelines, see the file "virus-l.README", 2714 available via anonymous FTP on info.cert.org 2715 in the /pub/virus-l directory. 2717 (5) comp.risks 2718 The comp.risks newsgroup is a moderated forum on 2719 the risks to the public in computers and related 2720 systems. 2722 World-Wide Web Pages 2724 (1) http://www.first.org/ 2726 Computer Security Resource Clearinghouse. The main focus is on 2727 crisis response information; information on computer 2728 security-related threats, vulnerabilities, and solutions. At the 2729 same time, the Clearinghouse strives to be a general index to 2730 computer security information on a broad variety of subjects, 2731 including general risks, privacy, legal issues, viruses, 2732 assurance, policy, and training. 2734 (2) http://www.telstra.com.au/info/security.html 2736 This Reference Index contains a list of links to information 2737 sources on Network and Computer Security. There is no implied 2738 fitness to the Tools, Techniques and Documents contained within this 2739 archive. Many if not all of these items work well, but we do 2740 not guarantee that this will be so. This information is for the 2741 education and legitimate use of computer security techniques only. 2743 (3) http://www.alw.nih.gov/Security/security.html 2745 This page features general information about computer security. 2746 Information is organized by source and each section is organized 2747 by topic. Recent modifications are noted in What's New page. 2749 Editor Information 2751 Barbara Y. Fraser 2752 Software Engineering Institute 2753 Carnegie Mellon University 2754 5000 Forbes Avenue 2755 Pittsburgh, PA 15213 2757 Phone: (412) 268-5010 2758 Fax: (412) 268-6989 2759 email: byf@cert.org