diff options
Diffstat (limited to 'doc/rfc/rfc2196.txt')
| -rw-r--r-- | doc/rfc/rfc2196.txt | 4203 |
1 files changed, 4203 insertions, 0 deletions
diff --git a/doc/rfc/rfc2196.txt b/doc/rfc/rfc2196.txt new file mode 100644 index 0000000..f736ca1 --- /dev/null +++ b/doc/rfc/rfc2196.txt @@ -0,0 +1,4203 @@ + + + + + + +Network Working Group B. Fraser +Request for Comments: 2196 Editor +FYI: 8 SEI/CMU +Obsoletes: 1244 September 1997 +Category: Informational + + + Site Security Handbook + + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + This handbook is a guide to developing computer security policies and + procedures for sites that have systems on the Internet. The purpose + of this handbook is to provide practical guidance to administrators + trying to secure their information and services. The subjects + covered include policy content and formation, a broad range of + technical system and network security topics, and security incident + response. + + +Table of Contents + +1. Introduction.................................................... 2 +1.1 Purpose of this Work............................................ 3 +1.2 Audience........................................................ 3 +1.3 Definitions..................................................... 3 +1.4 Related Work.................................................... 4 +1.5 Basic Approach.................................................. 4 +1.6 Risk Assessment................................................. 5 +2. Security Policies............................................... 6 +2.1 What is a Security Policy and Why Have One?..................... 6 +2.2 What Makes a Good Security Policy?.............................. 9 +2.3 Keeping the Policy Flexible..................................... 11 +3. Architecture.................................................... 11 +3.1 Objectives...................................................... 11 +3.2 Network and Service Configuration............................... 14 +3.3 Firewalls....................................................... 20 +4. Security Services and Procedures................................ 24 +4.1 Authentication.................................................. 24 +4.2 Confidentiality................................................. 28 +4.3 Integrity....................................................... 28 + + + +Fraser, Ed. Informational [Page 1] + +RFC 2196 Site Security Handbook September 1997 + + +4.4 Authorization................................................... 29 +4.5 Access.......................................................... 30 +4.6 Auditing........................................................ 34 +4.7 Securing Backups................................................ 37 +5. Security Incident Handling...................................... 37 +5.1 Preparing and Planning for Incident Handling.................... 39 +5.2 Notification and Points of Contact.............................. 42 +5.3 Identifying an Incident......................................... 50 +5.4 Handling an Incident............................................ 52 +5.5 Aftermath of an Incident........................................ 58 +5.6 Responsibilities................................................ 59 +6. Ongoing Activities.............................................. 60 +7. Tools and Locations............................................. 60 +8. Mailing Lists and Other Resources............................... 62 +9. References...................................................... 64 + +1. Introduction + + This document provides guidance to system and network administrators + on how to address security issues within the Internet community. It + builds on the foundation provided in RFC 1244 and is the collective + work of a number of contributing authors. Those authors include: + Jules P. Aronson (aronson@nlm.nih.gov), Nevil Brownlee + (n.brownlee@auckland.ac.nz), Frank Byrum (byrum@norfolk.infi.net), + Joao Nuno Ferreira (ferreira@rccn.net), Barbara Fraser + (byf@cert.org), Steve Glass (glass@ftp.com), Erik Guttman + (erik.guttman@eng.sun.com), Tom Killalea (tomk@nwnet.net), Klaus- + Peter Kossakowski (kossakowski@cert.dfn.de), Lorna Leone + (lorna@staff.singnet.com.sg), Edward.P.Lewis + (Edward.P.Lewis.1@gsfc.nasa.gov), Gary Malkin (gmalkin@xylogics.com), + Russ Mundy (mundy@tis.com), Philip J. Nesser + (pjnesser@martigny.ai.mit.edu), and Michael S. Ramsey + (msr@interpath.net). + + In addition to the principle writers, a number of reviewers provided + valuable comments. Those reviewers include: Eric Luiijf + (luiijf@fel.tno.nl), Marijke Kaat (marijke.kaat@sec.nl), Ray Plzak + (plzak@nic.mil) and Han Pronk (h.m.pronk@vka.nl). + + A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook, + CICnet, for their vision, leadership, and effort in the creation of + the first version of this handbook. It is the working group's sincere + hope that this version will be as helpful to the community as the + earlier one was. + + + + + + + +Fraser, Ed. Informational [Page 2] + +RFC 2196 Site Security Handbook September 1997 + + +1.1 Purpose of This Work + + This handbook is a guide to setting computer security policies and + procedures for sites that have systems on the Internet (however, the + information provided should also be useful to sites not yet connected + to the Internet). This guide lists issues and factors that a site + must consider when setting their own policies. It makes a number of + recommendations and provides discussions of relevant areas. + + This guide is only a framework for setting security policies and + procedures. In order to have an effective set of policies and + procedures, a site will have to make many decisions, gain agreement, + and then communicate and implement these policies. + +1.2 Audience + + The audience for this document are system and network administrators, + and decision makers (typically "middle management") at sites. For + brevity, we will use the term "administrator" throughout this + document to refer to system and network administrators. + + This document is not directed at programmers or those trying to + create secure programs or systems. The focus of this document is on + the policies and procedures that need to be in place to support the + technical security features that a site may be implementing. + + The primary audience for this work are sites that are members of the + Internet community. However, this document should be useful to any + site that allows communication with other sites. As a general guide + to security policies, this document may also be useful to sites with + isolated systems. + +1.3 Definitions + + For the purposes of this guide, a "site" is any organization that + owns computers or network-related resources. These resources may + include host computers that users use, routers, terminal servers, PCs + or other devices that have access to the Internet. A site may be an + end user of Internet services or a service provider such as a mid- + level network. However, most of the focus of this guide is on those + end users of Internet services. We assume that the site has the + ability to set policies and procedures for itself with the + concurrence and support from those who actually own the resources. It + will be assumed that sites that are parts of larger organizations + will know when they need to consult, collaborate, or take + recommendations from, the larger entity. + + + + + +Fraser, Ed. Informational [Page 3] + +RFC 2196 Site Security Handbook September 1997 + + + The "Internet" is a collection of thousands of networks linked by a + common set of technical protocols which make it possible for users of + any one of the networks to communicate with, or use the services + located on, any of the other networks (FYI4, RFC 1594). + + The term "administrator" is used to cover all those people who are + responsible for the day-to-day operation of system and network + resources. This may be a number of individuals or an organization. + + The term "security administrator" is used to cover all those people + who are responsible for the security of information and information + technology. At some sites this function may be combined with + administrator (above); at others, this will be a separate position. + + The term "decision maker" refers to those people at a site who set or + approve policy. These are often (but not always) the people who own + the resources. + +1.4 Related Work + + The Site Security Handbook Working Group is working on a User's Guide + to Internet Security. It will provide practical guidance to end users + to help them protect their information and the resources they use. + +1.5 Basic Approach + + This guide is written to provide basic guidance in developing a + security plan for your site. One generally accepted approach to + follow is suggested by Fites, et. al. [Fites 1989] and includes the + following steps: + + (1) Identify what you are trying to protect. + (2) Determine what you are trying to protect it from. + (3) Determine how likely the threats are. + (4) Implement measures which will protect your assets in a cost- + effective manner. + (5) Review the process continuously and make improvements each time + a weakness is found. + + Most of this document is focused on item 4 above, but the other steps + cannot be avoided if an effective plan is to be established at your + site. One old truism in security is that the cost of protecting + yourself against a threat should be less than the cost of recovering + if the threat were to strike you. Cost in this context should be + remembered to include losses expressed in real currency, reputation, + trustworthiness, and other less obvious measures. Without reasonable + knowledge of what you are protecting and what the likely threats are, + following this rule could be difficult. + + + +Fraser, Ed. Informational [Page 4] + +RFC 2196 Site Security Handbook September 1997 + + +1.6 Risk Assessment + +1.6.1 General Discussion + + One of the most important reasons for creating a computer security + policy is to ensure that efforts spent on security yield cost + effective benefits. Although this may seem obvious, it is possible + to be mislead about where the effort is needed. As an example, there + is a great deal of publicity about intruders on computers systems; + yet most surveys of computer security show that, for most + organizations, the actual loss from "insiders" is much greater. + + Risk analysis involves determining what you need to protect, what you + need to protect it from, and how to protect it. It is the process of + examining all of your risks, then ranking those risks by level of + severity. This process involves making cost-effective decisions on + what you want to protect. As mentioned above, you should probably + not spend more to protect something than it is actually worth. + + A full treatment of risk analysis is outside the scope of this + document. [Fites 1989] and [Pfleeger 1989] provide introductions to + this topic. However, there are two elements of a risk analysis that + will be briefly covered in the next two sections: + + (1) Identifying the assets + (2) Identifying the threats + + For each asset, the basic goals of security are availability, + confidentiality, and integrity. Each threat should be examined with + an eye to how the threat could affect these areas. + +1.6.2 Identifying the Assets + + One step in a risk analysis is to identify all the things that need + to be protected. Some things are obvious, like valuable proprietary + information, intellectual property, and all the various pieces of + hardware; but, some are overlooked, such as the people who actually + use the systems. The essential point is to list all things that could + be affected by a security problem. + + One list of categories is suggested by Pfleeger [Pfleeger 1989]; this + list is adapted from that source: + + (1) Hardware: CPUs, boards, keyboards, terminals, + workstations, personal computers, printers, disk + drives, communication lines, terminal servers, routers. + + + + + +Fraser, Ed. Informational [Page 5] + +RFC 2196 Site Security Handbook September 1997 + + + (2) Software: source programs, object programs, + utilities, diagnostic programs, operating systems, + communication programs. + + (3) Data: during execution, stored on-line, archived off-line, + backups, audit logs, databases, in transit over + communication media. + + (4) People: users, administrators, hardware maintainers. + + (5) Documentation: on programs, hardware, systems, local + administrative procedures. + + (6) Supplies: paper, forms, ribbons, magnetic media. + +1.6.3 Identifying the Threats + + Once the assets requiring protection are identified, it is necessary + to identify threats to those assets. The threats can then be + examined to determine what potential for loss exists. It helps to + consider from what threats you are trying to protect your assets. + The following are classic threats that should be considered. + Depending on your site, there will be more specific threats that + should be identified and addressed. + + (1) Unauthorized access to resources and/or information + (2) Unintented and/or unauthorized Disclosure of information + (3) Denial of service + +2. Security Policies + + Throughout this document there will be many references to policies. + Often these references will include recommendations for specific + policies. Rather than repeat guidance in how to create and + communicate such a policy, the reader should apply the advice + presented in this chapter when developing any policy recommended + later in this book. + +2.1 What is a Security Policy and Why Have One? + + The security-related decisions you make, or fail to make, as + administrator largely determines how secure or insecure your network + is, how much functionality your network offers, and how easy your + network is to use. However, you cannot make good decisions about + security without first determining what your security goals are. + Until you determine what your security goals are, you cannot make + effective use of any collection of security tools because you simply + will not know what to check for and what restrictions to impose. + + + +Fraser, Ed. Informational [Page 6] + +RFC 2196 Site Security Handbook September 1997 + + + For example, your goals will probably be very different from the + goals of a product vendor. Vendors are trying to make configuration + and operation of their products as simple as possible, which implies + that the default configurations will often be as open (i.e., + insecure) as possible. While this does make it easier to install new + products, it also leaves access to those systems, and other systems + through them, open to any user who wanders by. + + Your goals will be largely determined by the following key tradeoffs: + + (1) services offered versus security provided - + Each service offered to users carries its own security risks. + For some services the risk outweighs the benefit of the service + and the administrator may choose to eliminate the service rather + than try to secure it. + + (2) ease of use versus security - + The easiest system to use would allow access to any user and + require no passwords; that is, there would be no security. + Requiring passwords makes the system a little less convenient, + but more secure. Requiring device-generated one-time passwords + makes the system even more difficult to use, but much more + secure. + + (3) cost of security versus risk of loss - + There are many different costs to security: monetary (i.e., the + cost of purchasing security hardware and software like firewalls + and one-time password generators), performance (i.e., encryption + and decryption take time), and ease of use (as mentioned above). + There are also many levels of risk: loss of privacy (i.e., the + reading of information by unauthorized individuals), loss of + data (i.e., the corruption or erasure of information), and the + loss of service (e.g., the filling of data storage space, usage + of computational resources, and denial of network access). Each + type of cost must be weighed against each type of loss. + + + Your goals should be communicated to all users, operations staff, and + managers through a set of security rules, called a "security policy." + We are using this term, rather than the narrower "computer security + policy" since the scope includes all types of information technology + and the information stored and manipulated by the technology. + +2.1.1 Definition of a Security Policy + + A security policy is a formal statement of the rules by which people + who are given access to an organization's technology and information + assets must abide. + + + +Fraser, Ed. Informational [Page 7] + +RFC 2196 Site Security Handbook September 1997 + + +2.1.2 Purposes of a Security Policy + + The main purpose of a security policy is to inform users, staff and + managers of their obligatory requirements for protecting technology + and information assets. The policy should specify the mechanisms + through which these requirements can be met. Another purpose is to + provide a baseline from which to acquire, configure and audit + computer systems and networks for compliance with the policy. + Therefore an attempt to use a set of security tools in the absence of + at least an implied security policy is meaningless. + + An Appropriate Use Policy (AUP) may also be part of a security + policy. It should spell out what users shall and shall not do on the + various components of the system, including the type of traffic + allowed on the networks. The AUP should be as explicit as possible + to avoid ambiguity or misunderstanding. For example, an AUP might + list any prohibited USENET newsgroups. (Note: Appropriate Use Policy + is referred to as Acceptable Use Policy by some sites.) + +2.1.3 Who Should be Involved When Forming Policy? + + In order for a security policy to be appropriate and effective, it + needs to have the acceptance and support of all levels of employees + within the organization. It is especially important that corporate + management fully support the security policy process otherwise there + is little chance that they will have the intended impact. The + following is a list of individuals who should be involved in the + creation and review of security policy documents: + + (1) site security administrator + (2) information technology technical staff (e.g., staff from + computing center) + (3) administrators of large user groups within the organization + (e.g., business divisions, computer science department within a + university, etc.) + (4) security incident response team + (5) representatives of the user groups affected by the security + policy + (6) responsible management + (7) legal counsel (if appropriate) + + The list above is representative of many organizations, but is not + necessarily comprehensive. The idea is to bring in representation + from key stakeholders, management who have budget and policy + authority, technical staff who know what can and cannot be supported, + and legal counsel who know the legal ramifications of various policy + + + + + +Fraser, Ed. Informational [Page 8] + +RFC 2196 Site Security Handbook September 1997 + + + choices. In some organizations, it may be appropriate to include EDP + audit personnel. Involving this group is important if resulting + policy statements are to reach the broadest possible acceptance. It + is also relevant to mention that the role of legal counsel will also + vary from country to country. + +2.2 What Makes a Good Security Policy? + + The characteristics of a good security policy are: + + (1) It must be implementable through system administration + procedures, publishing of acceptable use guidelines, or other + appropriate methods. + + (2) It must be enforcible with security tools, where appropriate, + and with sanctions, where actual prevention is not technically + feasible. + + (3) It must clearly define the areas of responsibility for the + users, administrators, and management. + + The components of a good security policy include: + + (1) Computer Technology Purchasing Guidelines which specify + required, or preferred, security features. These should + supplement existing purchasing policies and guidelines. + + (2) A Privacy Policy which defines reasonable expectations of + privacy regarding such issues as monitoring of electronic mail, + logging of keystrokes, and access to users' files. + + (3) An Access Policy which defines access rights and privileges to + protect assets from loss or disclosure by specifying acceptable + use guidelines for users, operations staff, and management. It + should provide guidelines for external connections, data + communications, connecting devices to a network, and adding new + software to systems. It should also specify any required + notification messages (e.g., connect messages should provide + warnings about authorized usage and line monitoring, and not + simply say "Welcome"). + + (4) An Accountability Policy which defines the responsibilities of + users, operations staff, and management. It should specify an + audit capability, and provide incident handling guidelines + (i.e., what to do and who to contact if a possible intrusion is + detected). + + + + + +Fraser, Ed. Informational [Page 9] + +RFC 2196 Site Security Handbook September 1997 + + + (5) An Authentication Policy which establishes trust through an + effective password policy, and by setting guidelines for remote + location authentication and the use of authentication devices + (e.g., one-time passwords and the devices that generate them). + + (6) An Availability statement which sets users' expectations for the + availability of resources. It should address redundancy and + recovery issues, as well as specify operating hours and + maintenance down-time periods. It should also include contact + information for reporting system and network failures. + + (7) An Information Technology System & Network Maintenance Policy + which describes how both internal and external maintenance + people are allowed to handle and access technology. One + important topic to be addressed here is whether remote + maintenance is allowed and how such access is controlled. + Another area for consideration here is outsourcing and how it is + managed. + + (8) A Violations Reporting Policy that indicates which types of + violations (e.g., privacy and security, internal and external) + must be reported and to whom the reports are made. A non- + threatening atmosphere and the possibility of anonymous + reporting will result in a greater probability that a violation + will be reported if it is detected. + + (9) Supporting Information which provides users, staff, and + management with contact information for each type of policy + violation; guidelines on how to handle outside queries about a + security incident, or information which may be considered + confidential or proprietary; and cross-references to security + procedures and related information, such as company policies and + governmental laws and regulations. + + There may be regulatory requirements that affect some aspects of your + security policy (e.g., line monitoring). The creators of the + security policy should consider seeking legal assistance in the + creation of the policy. At a minimum, the policy should be reviewed + by legal counsel. + + Once your security policy has been established it should be clearly + communicated to users, staff, and management. Having all personnel + sign a statement indicating that they have read, understood, and + agreed to abide by the policy is an important part of the process. + Finally, your policy should be reviewed on a regular basis to see if + it is successfully supporting your security needs. + + + + + +Fraser, Ed. Informational [Page 10] + +RFC 2196 Site Security Handbook September 1997 + + +2.3 Keeping the Policy Flexible + + In order for a security policy to be viable for the long term, it + requires a lot of flexibility based upon an architectural security + concept. A security policy should be (largely) independent from + specific hardware and software situations (as specific systems tend + to be replaced or moved overnight). The mechanisms for updating the + policy should be clearly spelled out. This includes the process, the + people involved, and the people who must sign-off on the changes. + + It is also important to recognize that there are exceptions to every + rule. Whenever possible, the policy should spell out what exceptions + to the general policy exist. For example, under what conditions is a + system administrator allowed to go through a user's files. Also, + there may be some cases when multiple users will have access to the + same userid. For example, on systems with a "root" user, multiple + system administrators may know the password and use the root account. + + Another consideration is called the "Garbage Truck Syndrome." This + refers to what would happen to a site if a key person was suddenly + unavailable for his/her job function (e.g., was suddenly ill or left + the company unexpectedly). While the greatest security resides in + the minimum dissemination of information, the risk of losing critical + information increases when that information is not shared. It is + important to determine what the proper balance is for your site. + +3. Architecture + +3.1 Objectives + +3.1.1 Completely Defined Security Plans + + All sites should define a comprehensive security plan. This plan + should be at a higher level than the specific policies discussed in + chapter 2, and it should be crafted as a framework of broad + guidelines into which specific policies will fit. + + It is important to have this framework in place so that individual + policies can be consistent with the overall site security + architecture. For example, having a strong policy with regard to + Internet access and having weak restrictions on modem usage is + inconsistent with an overall philosophy of strong security + restrictions on external access. + + A security plan should define: the list of network services that will + be provided; which areas of the organization will provide the + services; who will have access to those services; how access will be + provided; who will administer those services; etc. + + + +Fraser, Ed. Informational [Page 11] + +RFC 2196 Site Security Handbook September 1997 + + + The plan should also address how incident will be handled. Chapter 5 + provides an in-depth discussion of this topic, but it is important + for each site to define classes of incidents and corresponding + responses. For example, sites with firewalls should set a threshold + on the number of attempts made to foil the firewall before triggering + a response? Escallation levels should be defined for both attacks + and responses. Sites without firewalls will have to determine if a + single attempt to connect to a host constitutes an incident? What + about a systematic scan of systems? + + For sites connected to the Internet, the rampant media magnification + of Internet related security incidents can overshadow a (potentially) + more serious internal security problem. Likewise, companies who have + never been connected to the Internet may have strong, well defined, + internal policies but fail to adequately address an external + connection policy. + +3.1.2 Separation of Services + + There are many services which a site may wish to provide for its + users, some of which may be external. There are a variety of + security reasons to attempt to isolate services onto dedicated host + computers. There are also performance reasons in most cases, but a + detailed discussion is beyond to scope of this document. + + The services which a site may provide will, in most cases, have + different levels of access needs and models of trust. Services which + are essential to the security or smooth operation of a site would be + better off being placed on a dedicated machine with very limited + access (see Section 3.1.3 "deny all" model), rather than on a machine + that provides a service (or services) which has traditionally been + less secure, or requires greater accessability by users who may + accidentally suborn security. + + It is also important to distinguish between hosts which operate + within different models of trust (e.g., all the hosts inside of a + firewall and any host on an exposed network). + + Some of the services which should be examined for potential + separation are outlined in section 3.2.3. It is important to remember + that security is only as strong as the weakest link in the chain. + Several of the most publicized penetrations in recent years have been + through the exploitation of vulnerabilities in electronic mail + systems. The intruders were not trying to steal electronic mail, but + they used the vulnerability in that service to gain access to other + systems. + + + + + +Fraser, Ed. Informational [Page 12] + +RFC 2196 Site Security Handbook September 1997 + + + If possible, each service should be running on a different machine + whose only duty is to provide a specific service. This helps to + isolate intruders and limit potential harm. + +3.1.3 Deny all/ Allow all + + There are two diametrically opposed underlying philosophies which can + be adopted when defining a security plan. Both alternatives are + legitimate models to adopt, and the choice between them will depend + on the site and its needs for security. + + The first option is to turn off all services and then selectively + enable services on a case by case basis as they are needed. This can + be done at the host or network level as appropriate. This model, + which will here after be referred to as the "deny all" model, is + generally more secure than the other model described in the next + paragraph. More work is required to successfully implement a "deny + all" configuration as well as a better understanding of services. + Allowing only known services provides for a better analysis of a + particular service/protocol and the design of a security mechanism + suited to the security level of the site. + + The other model, which will here after be referred to as the "allow + all" model, is much easier to implement, but is generally less secure + than the "deny all" model. Simply turn on all services, usually the + default at the host level, and allow all protocols to travel across + network boundaries, usually the default at the router level. As + security holes become apparent, they are restricted or patched at + either the host or network level. + + Each of these models can be applied to different portions of the + site, depending on functionality requirements, administrative + control, site policy, etc. For example, the policy may be to use the + "allow all" model when setting up workstations for general use, but + adopt a "deny all" model when setting up information servers, like an + email hub. Likewise, an "allow all" policy may be adopted for + traffic between LAN's internal to the site, but a "deny all" policy + can be adopted between the site and the Internet. + + Be careful when mixing philosophies as in the examples above. Many + sites adopt the theory of a hard "crunchy" shell and a soft "squishy" + middle. They are willing to pay the cost of security for their + external traffic and require strong security measures, but are + unwilling or unable to provide similar protections internally. This + works fine as long as the outer defenses are never breached and the + internal users can be trusted. Once the outer shell (firewall) is + breached, subverting the internal network is trivial. + + + + +Fraser, Ed. Informational [Page 13] + +RFC 2196 Site Security Handbook September 1997 + + +3.1.4 Identify Real Needs for Services + + There is a large variety of services which may be provided, both + internally and on the Internet at large. Managing security is, in + many ways, managing access to services internal to the site and + managing how internal users access information at remote sites. + + Services tend to rush like waves over the Internet. Over the years + many sites have established anonymous FTP servers, gopher servers, + wais servers, WWW servers, etc. as they became popular, but not + particularly needed, at all sites. Evaluate all new services that + are established with a skeptical attitude to determine if they are + actually needed or just the current fad sweeping the Internet. + + Bear in mind that security complexity can grow exponentially with the + number of services provided. Filtering routers need to be modified + to support the new protocols. Some protocols are inherently + difficult to filter safely (e.g., RPC and UDP services), thus + providing more openings to the internal network. Services provided + on the same machine can interact in catastrophic ways. For example, + allowing anonymous FTP on the same machine as the WWW server may + allow an intruder to place a file in the anonymous FTP area and cause + the HTTP server to execute it. + +3.2 Network and Service Configuration + +3.2.1 Protecting the Infrastructure + + Many network administrators go to great lengths to protect the hosts + on their networks. Few administrators make any effort to protect the + networks themselves. There is some rationale to this. For example, + it is far easier to protect a host than a network. Also, intruders + are likely to be after data on the hosts; damaging the network would + not serve their purposes. That said, there are still reasons to + protect the networks. For example, an intruder might divert network + traffic through an outside host in order to examine the data (i.e., + to search for passwords). Also, infrastructure includes more than + the networks and the routers which interconnect them. Infrastructure + also includes network management (e.g., SNMP), services (e.g., DNS, + NFS, NTP, WWW), and security (i.e., user authentication and access + restrictions). + + The infrastructure also needs protection against human error. When + an administrator misconfigures a host, that host may offer degraded + service. This only affects users who require that host and, unless + + + + + + +Fraser, Ed. Informational [Page 14] + +RFC 2196 Site Security Handbook September 1997 + + + that host is a primary server, the number of affected users will + therefore be limited. However, if a router is misconfigured, all + users who require the network will be affected. Obviously, this is a + far larger number of users than those depending on any one host. + +3.2.2 Protecting the Network + + There are several problems to which networks are vulnerable. The + classic problem is a "denial of service" attack. In this case, the + network is brought to a state in which it can no longer carry + legitimate users' data. There are two common ways this can be done: + by attacking the routers and by flooding the network with extraneous + traffic. Please note that the term "router" in this section is used + as an example of a larger class of active network interconnection + components that also includes components like firewalls, proxy- + servers, etc. + + An attack on the router is designed to cause it to stop forwarding + packets, or to forward them improperly. The former case may be due + to a misconfiguration, the injection of a spurious routing update, or + a "flood attack" (i.e., the router is bombarded with unroutable + packets, causing its performance to degrade). A flood attack on a + network is similar to a flood attack on a router, except that the + flood packets are usually broadcast. An ideal flood attack would be + the injection of a single packet which exploits some known flaw in + the network nodes and causes them to retransmit the packet, or + generate error packets, each of which is picked up and repeated by + another host. A well chosen attack packet can even generate an + exponential explosion of transmissions. + + Another classic problem is "spoofing." In this case, spurious + routing updates are sent to one or more routers causing them to + misroute packets. This differs from a denial of service attack only + in the purpose behind the spurious route. In denial of service, the + object is to make the router unusable; a state which will be quickly + detected by network users. In spoofing, the spurious route will + cause packets to be routed to a host from which an intruder may + monitor the data in the packets. These packets are then re-routed to + their correct destinations. However, the intruder may or may not + have altered the contents of the packets. + + The solution to most of these problems is to protect the routing + update packets sent by the routing protocols in use (e.g., RIP-2, + OSPF). There are three levels of protection: clear-text password, + cryptographic checksum, and encryption. Passwords offer only minimal + protection against intruders who do not have direct access to the + physical networks. Passwords also offer some protection against + misconfigured routers (i.e, routers which, out of the box, attempt to + + + +Fraser, Ed. Informational [Page 15] + +RFC 2196 Site Security Handbook September 1997 + + + route packets). The advantage of passwords is that they have a very + low overhead, in both bandwidth and CPU consumption. Checksums + protect against the injection of spurious packets, even if the + intruder has direct access to the physical network. Combined with a + sequence number, or other unique identifier, a checksum can also + protect again "replay" attacks, wherein an old (but valid at the + time) routing update is retransmitted by either an intruder or a + misbehaving router. The most security is provided by complete + encryption of sequenced, or uniquely identified, routing updates. + This prevents an intruder from determining the topology of the + network. The disadvantage to encryption is the overhead involved in + processing the updates. + + RIP-2 (RFC 1723) and OSPF (RFC 1583) both support clear-text + passwords in their base design specifications. In addition, there + are extensions to each base protocol to support MD5 encryption. + + Unfortunately, there is no adequate protection against a flooding + attack, or a misbehaving host or router which is flooding the + network. Fortunately, this type of attack is obvious when it occurs + and can usually be terminated relatively simply. + +3.2.3 Protecting the Services + + There are many types of services and each has its own security + requirements. These requirements will vary based on the intended use + of the service. For example, a service which should only be usable + within a site (e.g., NFS) may require different protection mechanisms + than a service provided for external use. It may be sufficient to + protect the internal server from external access. However, a WWW + server, which provides a home page intended for viewing by users + anywhere on the Internet, requires built-in protection. That is, the + service/protocol/server must provide whatever security may be + required to prevent unauthorized access and modification of the Web + database. + + Internal services (i.e., services meant to be used only by users + within a site) and external services (i.e., services deliberately + made available to users outside a site) will, in general, have + protection requirements which differ as previously described. It is + therefore wise to isolate the internal services to one set of server + host computers and the external services to another set of server + host computers. That is, internal and external servers should not be + co-located on the same host computer. In fact, many sites go so far + + + + + + + +Fraser, Ed. Informational [Page 16] + +RFC 2196 Site Security Handbook September 1997 + + + as to have one set of subnets (or even different networks) which are + accessible from the outside and another set which may be accessed + only within the site. Of course, there is usually a firewall which + connects these partitions. Great care must be taken to ensure that + such a firewall is operating properly. + + There is increasing interest in using intranets to connect different + parts of a organization (e.g., divisions of a company). While this + document generally differentiates between external and internal + (public and private), sites using intranets should be aware that they + will need to consider three separations and take appropriate actions + when designing and offering services. A service offered to an + intranet would be neither public, nor as completely private as a + service to a single organizational subunit. Therefore, the service + would need its own supporting system, separated from both external + and internal services and networks. + + One form of external service deserves some special consideration, and + that is anonymous, or guest, access. This may be either anonymous + FTP or guest (unauthenticated) login. It is extremely important to + ensure that anonymous FTP servers and guest login userids are + carefully isolated from any hosts and file systems from which outside + users should be kept. Another area to which special attention must + be paid concerns anonymous, writable access. A site may be legally + responsible for the content of publicly available information, so + careful monitoring of the information deposited by anonymous users is + advised. + + Now we shall consider some of the most popular services: name + service, password/key service, authentication/proxy service, + electronic mail, WWW, file transfer, and NFS. Since these are the + most frequently used services, they are the most obvious points of + attack. Also, a successful attack on one of these services can + produce disaster all out of proportion to the innocence of the basic + service. + +3.2.3.1 Name Servers (DNS and NIS(+)) + + The Internet uses the Domain Name System (DNS) to perform address + resolution for host and network names. The Network Information + Service (NIS) and NIS+ are not used on the global Internet, but are + subject to the same risks as a DNS server. Name-to-address + resolution is critical to the secure operation of any network. An + attacker who can successfully control or impersonate a DNS server can + re-route traffic to subvert security protections. For example, + routine traffic can be diverted to a compromised system to be + monitored; or, users can be tricked into providing authentication + secrets. An organization should create well known, protected sites + + + +Fraser, Ed. Informational [Page 17] + +RFC 2196 Site Security Handbook September 1997 + + + to act as secondary name servers and protect their DNS masters from + denial of service attacks using filtering routers. + + Traditionally, DNS has had no security capabilities. In particular, + the information returned from a query could not be checked for + modification or verified that it had come from the name server in + question. Work has been done to incorporate digital signatures into + the protocol which, when deployed, will allow the integrity of the + information to be cryptographically verified (see RFC 2065). + +3.2.3.2 Password/Key Servers (NIS(+) and KDC) + + Password and key servers generally protect their vital information + (i.e., the passwords and keys) with encryption algorithms. However, + even a one-way encrypted password can be determined by a dictionary + attack (wherein common words are encrypted to see if they match the + stored encryption). It is therefore necessary to ensure that these + servers are not accessable by hosts which do not plan to use them for + the service, and even those hosts should only be able to access the + service (i.e., general services, such as Telnet and FTP, should not + be allowed by anyone other than administrators). + +3.2.3.3 Authentication/Proxy Servers (SOCKS, FWTK) + + A proxy server provides a number of security enhancements. It allows + sites to concentrate services through a specific host to allow + monitoring, hiding of internal structure, etc. This funnelling of + services creates an attractive target for a potential intruder. The + type of protection required for a proxy server depends greatly on the + proxy protocol in use and the services being proxied. The general + rule of limiting access only to those hosts which need the services, + and limiting access by those hosts to only those services, is a good + starting point. + +3.2.3.4 Electronic Mail + + Electronic mail (email) systems have long been a source for intruder + break-ins because email protocols are among the oldest and most + widely deployed services. Also, by it's very nature, an email server + requires access to the outside world; most email servers accept input + from any source. An email server generally consists of two parts: a + receiving/sending agent and a processing agent. Since email is + delivered to all users, and is usually private, the processing agent + typically requires system (root) privileges to deliver the mail. + Most email implementations perform both portions of the service, + which means the receiving agent also has system privileges. This + opens several security holes which this document will not describe. + There are some implementations available which allow a separation of + + + +Fraser, Ed. Informational [Page 18] + +RFC 2196 Site Security Handbook September 1997 + + + the two agents. Such implementations are generally considered more + secure, but still require careful installation to avoid creating a + security problem. + +3.2.3.5 World Wide Web (WWW) + + The Web is growing in popularity exponentially because of its ease of + use and the powerful ability to concentrate information services. + Most WWW servers accept some type of direction and action from the + persons accessing their services. The most common example is taking + a request from a remote user and passing the provided information to + a program running on the server to process the request. Some of + these programs are not written with security in mind and can create + security holes. If a Web server is available to the Internet + community, it is especially important that confidential information + not be co-located on the same host as that server. In fact, it is + recommended that the server have a dedicated host which is not + "trusted" by other internal hosts. + + Many sites may want to co-locate FTP service with their WWW service. + But this should only occur for anon-ftp servers that only provide + information (ftp-get). Anon-ftp puts, in combination with WWW, might + be dangerous (e.g., they could result in modifications to the + information your site is publishing to the web) and in themselves + make the security considerations for each service different. + +3.2.3.6 File Transfer (FTP, TFTP) + + FTP and TFTP both allow users to receive and send electronic files in + a point-to-point manner. However, FTP requires authentication while + TFTP requires none. For this reason, TFTP should be avoided as much + as possible. + + Improperly configured FTP servers can allow intruders to copy, + replace and delete files at will, anywhere on a host, so it is very + important to configure this service correctly. Access to encrypted + passwords and proprietary data, and the introduction of Trojan horses + are just a few of the potential security holes that can occur when + the service is configured incorrectly. FTP servers should reside on + their own host. Some sites choose to co-locate FTP with a Web + server, since the two protocols share common security considerations + However, the the practice isn't recommended, especially when the FTP + service allows the deposit of files (see section on WWW above). As + mentioned in the opening paragraphs of section 3.2.3, services + offered internally to your site should not be co-located with + services offered externally. Each should have its own host. + + + + + +Fraser, Ed. Informational [Page 19] + +RFC 2196 Site Security Handbook September 1997 + + + TFTP does not support the same range of functions as FTP, and has no + security whatsoever. This service should only be considered for + internal use, and then it should be configured in a restricted way so + that the server only has access to a set of predetermined files + (instead of every world-readable file on the system). Probably the + most common usage of TFTP is for downloading router configuration + files to a router. TFTP should reside on its own host, and should + not be installed on hosts supporting external FTP or Web access. + +3.2.3.7 NFS + + The Network File Service allows hosts to share common disks. NFS is + frequently used by diskless hosts who depend on a disk server for all + of their storage needs. Unfortunately, NFS has no built-in security. + It is therefore necessary that the NFS server be accessable only by + those hosts which are using it for service. This is achieved by + specifying which hosts the file system is being exported to and in + what manner (e.g., read-only, read-write, etc.). Filesystems should + not be exported to any hosts outside the local network since this + will require that the NFS service be accessible externally. Ideally, + external access to NFS service should be stopped by a firewall. + +3.2.4 Protecting the Protection + + It is amazing how often a site will overlook the most obvious + weakness in its security by leaving the security server itself open + to attack. Based on considerations previously discussed, it should + be clear that: the security server should not be accessible from + off-site; should offer minimum access, except for the authentication + function, to users on-site; and should not be co-located with any + other servers. Further, all access to the node, including access to + the service itself, should be logged to provide a "paper trail" in + the event of a security breach. + +3.3 Firewalls + + One of the most widely deployed and publicized security measures in + use on the Internet is a "firewall." Firewalls have been given the + reputation of a general panacea for many, if not all, of the Internet + security issues. They are not. Firewalls are just another tool in + the quest for system security. They provide a certain level of + protection and are, in general, a way of implementing security policy + at the network level. The level of security that a firewall provides + can vary as much as the level of security on a particular machine. + There are the traditional trade-offs between security, ease of use, + cost, complexity, etc. + + + + + +Fraser, Ed. Informational [Page 20] + +RFC 2196 Site Security Handbook September 1997 + + + A firewall is any one of several mechanisms used to control and watch + access to and from a network for the purpose of protecting it. A + firewall acts as a gateway through which all traffic to and from the + protected network and/or systems passes. Firewalls help to place + limitations on the amount and type of communication that takes place + between the protected network and the another network (e.g., the + Internet, or another piece of the site's network). + + A firewall is generally a way to build a wall between one part of a + network, a company's internal network, for example, and another part, + the global Internet, for example. The unique feature about this wall + is that there needs to be ways for some traffic with particular + characteristics to pass through carefully monitored doors + ("gateways"). The difficult part is establishing the criteria by + which the packets are allowed or denied access through the doors. + Books written on firewalls use different terminology to describe the + various forms of firewalls. This can be confusing to system + administrators who are not familiar with firewalls. The thing to note + here is that there is no fixed terminology for the description of + firewalls. + + Firewalls are not always, or even typically, a single machine. + Rather, firewalls are often a combination of routers, network + segments, and host computers. Therefore, for the purposes of this + discussion, the term "firewall" can consist of more than one physical + device. Firewalls are typically built using two different + components, filtering routers and proxy servers. + + Filtering routers are the easiest component to conceptualize in a + firewall. A router moves data back and forth between two (or more) + different networks. A "normal" router takes a packet from network A + and "routes" it to its destination on network B. A filtering router + does the same thing but decides not only how to route the packet, but + whether it should route the packet. This is done by installing a + series of filters by which the router decides what to do with any + given packet of data. + + A discussion concerning capabilities of a particular brand of router, + running a particular software version is outside the scope of this + document. However, when evaluating a router to be used for filtering + packets, the following criteria can be important when implementing a + filtering policy: source and destination IP address, source and + destination TCP port numbers, state of the TCP "ack" bit, UDP source + and destination port numbers, and direction of packet flow (i.e.. A- + >B or B->A). Other information necessary to construct a secure + filtering scheme are whether the router reorders filter instructions + (designed to optimize filters, this can sometimes change the meaning + and cause unintended access), and whether it is possible to apply + + + +Fraser, Ed. Informational [Page 21] + +RFC 2196 Site Security Handbook September 1997 + + + filters for inbound and outbound packets on each interface (if the + router filters only outbound packets then the router is "outside" of + its filters and may be more vulnerable to attack). In addition to + the router being vulnerable, this distinction between applying + filters on inbound or outbound packets is especially relevant for + routers with more than 2 interfaces. Other important issues are the + ability to create filters based on IP header options and the fragment + state of a packet. Building a good filter can be very difficult and + requires a good understanding of the type of services (protocols) + that will be filtered. + + For better security, the filters usually restrict access between the + two connected nets to just one host, the bastion host. It is only + possible to access the other network via this bastion host. As only + this host, rather than a few hundred hosts, can get attacked, it is + easier to maintain a certain level of security because only this host + has to be protected very carefully. To make resources available to + legitimate users across this firewall, services have to be forwarded + by the bastion host. Some servers have forwarding built in (like + DNS-servers or SMTP-servers), for other services (e.g., Telnet, FTP, + etc.), proxy servers can be used to allow access to the resources + across the firewall in a secure way. + + A proxy server is way to concentrate application services through a + single machine. There is typically a single machine (the bastion + host) that acts as a proxy server for a variety of protocols (Telnet, + SMTP, FTP, HTTP, etc.) but there can be individual host computers for + each service. Instead of connecting directly to an external server, + the client connects to the proxy server which in turn initiates a + connection to the requested external server. Depending on the type + of proxy server used, it is possible to configure internal clients to + perform this redirection automatically, without knowledge to the + user, others might require that the user connect directly to the + proxy server and then initiate the connection through a specified + format. + + There are significant security benefits which can be derived from + using proxy servers. It is possible to add access control lists to + protocols, requiring users or systems to provide some level of + authentication before access is granted. Smarter proxy servers, + sometimes called Application Layer Gateways (ALGs), can be written + which understand specific protocols and can be configured to block + only subsections of the protocol. For example, an ALG for FTP can + tell the difference between the "put" command and the "get" command; + an organization may wish to allow users to "get" files from the + Internet, but not be able to "put" internal files on a remote server. + By contrast, a filtering router could either block all FTP access, or + none, but not a subset. + + + +Fraser, Ed. Informational [Page 22] + +RFC 2196 Site Security Handbook September 1997 + + + Proxy servers can also be configured to encrypt data streams based on + a variety of parameters. An organization might use this feature to + allow encrypted connections between two locations whose sole access + points are on the Internet. + + Firewalls are typically thought of as a way to keep intruders out, + but they are also often used as a way to let legitimate users into a + site. There are many examples where a valid user might need to + regularly access the "home" site while on travel to trade shows and + conferences, etc. Access to the Internet is often available but may + be through an untrusted machine or network. A correctly configured + proxy server can allow the correct users into the site while still + denying access to other users. + + The current best effort in firewall techniques is found using a + combination of a pair of screening routers with one or more proxy + servers on a network between the two routers. This setup allows the + external router to block off any attempts to use the underlying IP + layer to break security (IP spoofing, source routing, packet + fragments), while allowing the proxy server to handle potential + security holes in the higher layer protocols. The internal router's + purpose is to block all traffic except to the proxy server. If this + setup is rigidly implemented, a high level of security can be + achieved. + + Most firewalls provide logging which can be tuned to make security + administration of the network more convenient. Logging may be + centralized and the system may be configured to send out alerts for + abnormal conditions. It is important to regularly monitor these logs + for any signs of intrusions or break-in attempts. Since some + intruders will attempt to cover their tracks by editing logs, it is + desirable to protect these logs. A variety of methods is available, + including: write once, read many (WORM) drives; papers logs; and + centralized logging via the "syslog" utility. Another technique is + to use a "fake" serial printer, but have the serial port connected to + an isolated machine or PC which keeps the logs. + + Firewalls are available in a wide range of quality and strengths. + Commercial packages start at approximately $10,000US and go up to + over $250,000US. "Home grown" firewalls can be built for smaller + amounts of capital. It should be remembered that the correct setup + of a firewall (commercial or homegrown) requires a significant amount + of skill and knowledge of TCP/IP. Both types require regular + maintenance, installation of software patches and updates, and + regular monitoring. When budgeting for a firewall, these additional + costs should be considered in addition to the cost of the physical + elements of the firewall. + + + + +Fraser, Ed. Informational [Page 23] + +RFC 2196 Site Security Handbook September 1997 + + + As an aside, building a "home grown" firewall requires a significant + amount of skill and knowledge of TCP/IP. It should not be trivially + attempted because a perceived sense of security is worse in the long + run than knowing that there is no security. As with all security + measures, it is important to decide on the threat, the value of the + assets to be protected, and the costs to implement security. + + A final note about firewalls. They can be a great aid when + implementing security for a site and they protect against a large + variety of attacks. But it is important to keep in mind that they + are only one part of the solution. They cannot protect your site + against all types of attack. + +4. Security Services and Procedures + + This chapter guides the reader through a number of topics that should + be addressed when securing a site. Each section touches on a + security service or capability that may be required to protect the + information and systems at a site. The topics are presented at a + fairly high-level to introduce the reader to the concepts. + + Throughout the chapter, you will find significant mention of + cryptography. It is outside the scope of this document to delve into + details concerning cryptography, but the interested reader can obtain + more information from books and articles listed in the reference + section of this document. + +4.1 Authentication + + For many years, the prescribed method for authenticating users has + been through the use of standard, reusable passwords. Originally, + these passwords were used by users at terminals to authenticate + themselves to a central computer. At the time, there were no + networks (internally or externally), so the risk of disclosure of the + clear text password was minimal. Today, systems are connected + together through local networks, and these local networks are further + connected together and to the Internet. Users are logging in from + all over the globe; their reusable passwords are often transmitted + across those same networks in clear text, ripe for anyone in-between + to capture. And indeed, the CERT* Coordination Center and other + response teams are seeing a tremendous number of incidents involving + packet sniffers which are capturing the clear text passwords. + + With the advent of newer technologies like one-time passwords (e.g., + S/Key), PGP, and token-based authentication devices, people are using + password-like strings as secret tokens and pins. If these secret + tokens and pins are not properly selected and protected, the + authentication will be easily subverted. + + + +Fraser, Ed. Informational [Page 24] + +RFC 2196 Site Security Handbook September 1997 + + +4.1.1 One-Time passwords + + As mentioned above, given today's networked environments, it is + recommended that sites concerned about the security and integrity of + their systems and networks consider moving away from standard, + reusable passwords. There have been many incidents involving Trojan + network programs (e.g., telnet and rlogin) and network packet + sniffing programs. These programs capture clear text + hostname/account name/password triplets. Intruders can use the + captured information for subsequent access to those hosts and + accounts. This is possible because 1) the password is used over and + over (hence the term "reusable"), and 2) the password passes across + the network in clear text. + + Several authentication techniques have been developed that address + this problem. Among these techniques are challenge-response + technologies that provide passwords that are only used once (commonly + called one-time passwords). There are a number of products available + that sites should consider using. The decision to use a product is + the responsibility of each organization, and each organization should + perform its own evaluation and selection. + +4.1.2 Kerberos + + Kerberos is a distributed network security system which provides for + authentication across unsecured networks. If requested by the + application, integrity and encryption can also be provided. Kerberos + was originally developed at the Massachusetts Institute of Technology + (MIT) in the mid 1980s. There are two major releases of Kerberos, + version 4 and 5, which are for practical purposes, incompatible. + + Kerberos relies on a symmetric key database using a key distribution + center (KDC) which is known as the Kerberos server. A user or + service (known as "principals") are granted electronic "tickets" + after properly communicating with the KDC. These tickets are used + for authentication between principals. All tickets include a time + stamp which limits the time period for which the ticket is valid. + Therefore, Kerberos clients and server must have a secure time + source, and be able to keep time accurately. + + The practical side of Kerberos is its integration with the + application level. Typical applications like FTP, telnet, POP, and + NFS have been integrated with the Kerberos system. There are a + variety of implementations which have varying levels of integration. + Please see the Kerberos FAQ available at http://www.ov.com/misc/krb- + faq.html for the latest information. + + + + + +Fraser, Ed. Informational [Page 25] + +RFC 2196 Site Security Handbook September 1997 + + +4.1.3 Choosing and Protecting Secret Tokens and PINs + + When selecting secret tokens, take care to choose them carefully. + Like the selection of passwords, they should be robust against brute + force efforts to guess them. That is, they should not be single + words in any language, any common, industry, or cultural acronyms, + etc. Ideally, they will be longer rather than shorter and consist of + pass phrases that combine upper and lower case character, digits, and + other characters. + + Once chosen, the protection of these secret tokens is very important. + Some are used as pins to hardware devices (like token cards) and + these should not be written down or placed in the same location as + the device with which they are associated. Others, such as a secret + Pretty Good Privacy (PGP) key, should be protected from unauthorized + access. + + One final word on this subject. When using cryptography products, + like PGP, take care to determine the proper key length and ensure + that your users are trained to do likewise. As technology advances, + the minimum safe key length continues to grow. Make sure your site + keeps up with the latest knowledge on the technology so that you can + ensure that any cryptography in use is providing the protection you + believe it is. + +4.1.4 Password Assurance + + While the need to eliminate the use of standard, reusable passwords + cannot be overstated, it is recognized that some organizations may + still be using them. While it's recommended that these organizations + transition to the use of better technology, in the mean time, we have + the following advice to help with the selection and maintenance of + traditional passwords. But remember, none of these measures provides + protection against disclosure due to sniffer programs. + + (1) The importance of robust passwords - In many (if not most) cases + of system penetration, the intruder needs to gain access to an + account on the system. One way that goal is typically + accomplished is through guessing the password of a legitimate + user. This is often accomplished by running an automated + password cracking program, which utilizes a very large + dictionary, against the system's password file. The only way to + guard against passwords being disclosed in this manner is + through the careful selection of passwords which cannot be + easily guessed (i.e., combinations of numbers, letters, and + punctuation characters). Passwords should also be as long as + the system supports and users can tolerate. + + + + +Fraser, Ed. Informational [Page 26] + +RFC 2196 Site Security Handbook September 1997 + + + (2) Changing default passwords - Many operating systems and + application programs are installed with default accounts and + passwords. These must be changed immediately to something that + cannot be guessed or cracked. + + (3) Restricting access to the password file - In particular, a site + wants to protect the encrypted password portion of the file so + that would-be intruders don't have them available for cracking. + One effective technique is to use shadow passwords where the + password field of the standard file contains a dummy or false + password. The file containing the legitimate passwords are + protected elsewhere on the system. + + (4) Password aging - When and how to expire passwords is still a + subject of controversy among the security community. It is + generally accepted that a password should not be maintained once + an account is no longer in use, but it is hotly debated whether + a user should be forced to change a good password that's in + active use. The arguments for changing passwords relate to the + prevention of the continued use of penetrated accounts. + However, the opposition claims that frequent password changes + lead to users writing down their passwords in visible areas + (such as pasting them to a terminal), or to users selecting very + simple passwords that are easy to guess. It should also be + stated that an intruder will probably use a captured or guessed + password sooner rather than later, in which case password aging + provides little if any protection. + + While there is no definitive answer to this dilemma, a password + policy should directly address the issue and provide guidelines + for how often a user should change the password. Certainly, an + annual change in their password is usually not difficult for + most users, and you should consider requiring it. It is + recommended that passwords be changed at least whenever a + privileged account is compromised, there is a critical change in + personnel (especially if it is an administrator!), or when an + account has been compromised. In addition, if a privileged + account password is compromised, all passwords on the system + should be changed. + + (5) Password/account blocking - Some sites find it useful to disable + accounts after a predefined number of failed attempts to + authenticate. If your site decides to employ this mechanism, it + is recommended that the mechanism not "advertise" itself. After + + + + + + + +Fraser, Ed. Informational [Page 27] + +RFC 2196 Site Security Handbook September 1997 + + + disabling, even if the correct password is presented, the + message displayed should remain that of a failed login attempt. + Implementing this mechanism will require that legitimate users + contact their system administrator to request that their account + be reactivated. + + (6) A word about the finger daemon - By default, the finger daemon + displays considerable system and user information. For example, + it can display a list of all users currently using a system, or + all the contents of a specific user's .plan file. This + information can be used by would-be intruders to identify + usernames and guess their passwords. It is recommended that + sites consider modifying finger to restrict the information + displayed. + +4.2 Confidentiality + + There will be information assets that your site will want to protect + from disclosure to unauthorized entities. Operating systems often + have built-in file protection mechanisms that allow an administrator + to control who on the system can access, or "see," the contents of a + given file. A stronger way to provide confidentiality is through + encryption. Encryption is accomplished by scrambling data so that it + is very difficult and time consuming for anyone other than the + authorized recipients or owners to obtain the plain text. Authorized + recipients and the owner of the information will possess the + corresponding decryption keys that allow them to easily unscramble + the text to a readable (clear text) form. We recommend that sites + use encryption to provide confidentiality and protect valuable + information. + + The use of encryption is sometimes controlled by governmental and + site regulations, so we encourage administrators to become informed + of laws or policies that regulate its use before employing it. It is + outside the scope of this document to discuss the various algorithms + and programs available for this purpose, but we do caution against + the casual use of the UNIX crypt program as it has been found to be + easily broken. We also encourage everyone to take time to understand + the strength of the encryption in any given algorithm/product before + using it. Most well-known products are well-documented in the + literature, so this should be a fairly easy task. + +4.3 Integrity + + As an administrator, you will want to make sure that information + (e.g., operating system files, company data, etc.) has not been + altered in an unauthorized fashion. This means you will want to + provide some assurance as to the integrity of the information on your + + + +Fraser, Ed. Informational [Page 28] + +RFC 2196 Site Security Handbook September 1997 + + + systems. One way to provide this is to produce a checksum of the + unaltered file, store that checksum offline, and periodically (or + when desired) check to make sure the checksum of the online file + hasn't changed (which would indicate the data has been modified). + + Some operating systems come with checksumming programs, such as the + UNIX sum program. However, these may not provide the protection you + actually need. Files can be modified in such a way as to preserve + the result of the UNIX sum program! Therefore, we suggest that you + use a cryptographically strong program, such as the message digesting + program MD5 [ref], to produce the checksums you will be using to + assure integrity. + + There are other applications where integrity will need to be assured, + such as when transmitting an email message between two parties. There + are products available that can provide this capability. Once you + identify that this is a capability you need, you can go about + identifying technologies that will provide it. + +4.4 Authorization + + Authorization refers to the process of granting privileges to + processes and, ultimately, users. This differs from authentication + in that authentication is the process used to identify a user. Once + identified (reliably), the privileges, rights, property, and + permissible actions of the user are determined by authorization. + + Explicitly listing the authorized activities of each user (and user + process) with respect to all resources (objects) is impossible in a + reasonable system. In a real system certain techniques are used to + simplify the process of granting and checking authorization(s). + + One approach, popularized in UNIX systems, is to assign to each + object three classes of user: owner, group and world. The owner is + either the creator of the object or the user assigned as owner by the + super-user. The owner permissions (read, write and execute) apply + only to the owner. A group is a collection of users which share + access rights to an object. The group permissions (read, write and + execute) apply to all users in the group (except the owner). The + world refers to everybody else with access to the system. The world + permissions (read, write and execute) apply to all users (except the + owner and members of the group). + + Another approach is to attach to an object a list which explicitly + contains the identity of all permitted users (or groups). This is an + Access Control List (ACL). The advantage of ACLs are that they are + + + + + +Fraser, Ed. Informational [Page 29] + +RFC 2196 Site Security Handbook September 1997 + + + easily maintained (one central list per object) and it's very easy to + visually check who has access to what. The disadvantages are the + extra resources required to store such lists, as well as the vast + number of such lists required for large systems. + +4.5 Access + +4.5.1 Physical Access + + Restrict physical access to hosts, allowing access only to those + people who are supposed to use the hosts. Hosts include "trusted" + terminals (i.e., terminals which allow unauthenticated use such as + system consoles, operator terminals and terminals dedicated to + special tasks), and individual microcomputers and workstations, + especially those connected to your network. Make sure people's work + areas mesh well with access restrictions; otherwise they will find + ways to circumvent your physical security (e.g., jamming doors open). + + Keep original and backup copies of data and programs safe. Apart + from keeping them in good condition for backup purposes, they must be + protected from theft. It is important to keep backups in a separate + location from the originals, not only for damage considerations, but + also to guard against thefts. + + Portable hosts are a particular risk. Make sure it won't cause + problems if one of your staff's portable computer is stolen. + Consider developing guidelines for the kinds of data that should be + allowed to reside on the disks of portable computers as well as how + the data should be protected (e.g., encryption) when it is on a + portable computer. + + Other areas where physical access should be restricted is the wiring + closets and important network elements like file servers, name server + hosts, and routers. + +4.5.2 Walk-up Network Connections + + By "walk-up" connections, we mean network connection points located + to provide a convenient way for users to connect a portable host to + your network. + + Consider whether you need to provide this service, bearing in mind + that it allows any user to attach an unauthorized host to your + network. This increases the risk of attacks via techniques such as + + + + + + + +Fraser, Ed. Informational [Page 30] + +RFC 2196 Site Security Handbook September 1997 + + + IP address spoofing, packet sniffing, etc. Users and site management + must appreciate the risks involved. If you decide to provide walk-up + connections, plan the service carefully and define precisely where + you will provide it so that you can ensure the necessary physical + access security. + + A walk-up host should be authenticated before its user is permitted + to access resources on your network. As an alternative, it may be + possible to control physical access. For example, if the service is + to be used by students, you might only provide walk-up connection + sockets in student laboratories. + + If you are providing walk-up access for visitors to connect back to + their home networks (e.g., to read e-mail, etc.) in your facility, + consider using a separate subnet that has no connectivity to the + internal network. + + Keep an eye on any area that contains unmonitored access to the + network, such as vacant offices. It may be sensible to disconnect + such areas at the wiring closet, and consider using secure hubs and + monitoring attempts to connect unauthorized hosts. + +4.5.3 Other Network Technologies + + Technologies considered here include X.25, ISDN, SMDS, DDS and Frame + Relay. All are provided via physical links which go through + telephone exchanges, providing the potential for them to be diverted. + Crackers are certainly interested in telephone switches as well as in + data networks! + + With switched technologies, use Permanent Virtual Circuits or Closed + User Groups whenever this is possible. Technologies which provide + authentication and/or encryption (such as IPv6) are evolving rapidly; + consider using them on links where security is important. + +4.5.4 Modems + +4.5.4.1 Modem Lines Must Be Managed + + Although they provide convenient access to a site for its users, they + can also provide an effective detour around the site's firewalls. + For this reason it is essential to maintain proper control of modems. + + Don't allow users to install a modem line without proper + authorization. This includes temporary installations (e.g., plugging + a modem into a facsimile or telephone line overnight). + + + + + +Fraser, Ed. Informational [Page 31] + +RFC 2196 Site Security Handbook September 1997 + + + Maintain a register of all your modem lines and keep your register up + to date. Conduct regular (ideally automated) site checks for + unauthorized modems. + +4.5.4.2 Dial-in Users Must Be Authenticated + + A username and password check should be completed before a user can + access anything on your network. Normal password security + considerations are particularly important (see section 4.1.1). + + Remember that telephone lines can be tapped, and that it is quite + easy to intercept messages to cellular phones. Modern high-speed + modems use more sophisticated modulation techniques, which makes them + somewhat more difficult to monitor, but it is prudent to assume that + hackers know how to eavesdrop on your lines. For this reason, you + should use one-time passwords if at all possible. + + It is helpful to have a single dial-in point (e.g., a single large + modem pool) so that all users are authenticated in the same way. + + Users will occasionally mis-type a password. Set a short delay - say + two seconds - after the first and second failed logins, and force a + disconnect after the third. This will slow down automated password + attacks. Don't tell the user whether the username, the password, or + both, were incorrect. + +4.5.4.3 Call-back Capability + + Some dial-in servers offer call-back facilities (i.e., the user dials + in and is authenticated, then the system disconnects the call and + calls back on a specified number). Call-back is useful since if + someone were to guess a username and password, they are disconnected, + and the system then calls back the actual user whose password was + cracked; random calls from a server are suspicious, at best. This + does mean users may only log in from one location (where the server + is configured to dial them back), and of course there may be phone + charges associated with there call-back location. + + This feature should be used with caution; it can easily be bypassed. + At a minimum, make sure that the return call is never made from the + same modem as the incoming one. Overall, although call-back can + improve modem security, you should not depend on it alone. + +4.5.4.4 All Logins Should Be Logged + + All logins, whether successful or unsuccessful should be logged. + However, do not keep correct passwords in the log. Rather, log them + simply as a successful login attempt. Since most bad passwords are + + + +Fraser, Ed. Informational [Page 32] + +RFC 2196 Site Security Handbook September 1997 + + + mistyped by authorized users, they only vary by a single character + from the actual password. Therefore if you can't keep such a log + secure, don't log it at all. + + If Calling Line Identification is available, take advantage of it by + recording the calling number for each login attempt. Be sensitive to + the privacy issues raised by Calling Line Identification. Also be + aware that Calling Line Identification is not to be trusted (since + intruders have been known to break into phone switches and forward + phone numbers or make other changes); use the data for informational + purposes only, not for authentication. + +4.5.4.5 Choose Your Opening Banner Carefully + + Many sites use a system default contained in a message of the day + file for their opening banner. Unfortunately, this often includes the + type of host hardware or operating system present on the host. This + can provide valuable information to a would-be intruder. Instead, + each site should create its own specific login banner, taking care to + only include necessary information. + + Display a short banner, but don't offer an "inviting" name (e.g., + University of XYZ, Student Records System). Instead, give your site + name, a short warning that sessions may be monitored, and a + username/password prompt. Verify possible legal issues related to + the text you put into the banner. + + For high-security applications, consider using a "blind" password + (i.e., give no response to an incoming call until the user has typed + in a password). This effectively simulates a dead modem. + +4.5.4.6 Dial-out Authentication + + Dial-out users should also be authenticated, particularly since your + site will have to pay their telephone charges. + + Never allow dial-out from an unauthenticated dial-in call, and + consider whether you will allow it from an authenticated one. The + goal here is to prevent callers using your modem pool as part of a + chain of logins. This can be hard to detect, particularly if a + hacker sets up a path through several hosts on your site. + + At a minimum, don't allow the same modems and phone lines to be used + for both dial-in and dial-out. This can be implemented easily if you + run separate dial-in and dial-out modem pools. + + + + + + +Fraser, Ed. Informational [Page 33] + +RFC 2196 Site Security Handbook September 1997 + + +4.5.4.7 Make Your Modem Programming as "Bullet-proof" as Possible + + Be sure modems can't be reprogrammed while they're in service. At a + minimum, make sure that three plus signs won't put your dial-in + modems into command mode! + + Program your modems to reset to your standard configuration at the + start of each new call. Failing this, make them reset at the end of + each call. This precaution will protect you against accidental + reprogramming of your modems. Resetting at both the end and the + beginning of each call will assure an even higher level of confidence + that a new caller will not inherit a previous caller's session. + + Check that your modems terminate calls cleanly. When a user logs out + from an access server, verify that the server hangs up the phone line + properly. It is equally important that the server forces logouts + from whatever sessions were active if the user hangs up unexpectedly. + +4.6 Auditing + + This section covers the procedures for collecting data generated by + network activity, which may be useful in analyzing the security of a + network and responding to security incidents. + +4.6.1 What to Collect + + Audit data should include any attempt to achieve a different security + level by any person, process, or other entity in the network. This + includes login and logout, super user access (or the non-UNIX + equivalent), ticket generation (for Kerberos, for example), and any + other change of access or status. It is especially important to note + "anonymous" or "guest" access to public servers. + + The actual data to collect will differ for different sites and for + different types of access changes within a site. In general, the + information you want to collect includes: username and hostname, for + login and logout; previous and new access rights, for a change of + access rights; and a timestamp. Of course, there is much more + information which might be gathered, depending on what the system + makes available and how much space is available to store that + information. + + One very important note: do not gather passwords. This creates an + enormous potential security breach if the audit records should be + improperly accessed. Do not gather incorrect passwords either, as + they often differ from valid passwords by only a single character or + transposition. + + + + +Fraser, Ed. Informational [Page 34] + +RFC 2196 Site Security Handbook September 1997 + + +4.6.2 Collection Process + + The collection process should be enacted by the host or resource + being accessed. Depending on the importance of the data and the need + to have it local in instances in which services are being denied, + data could be kept local to the resource until needed or be + transmitted to storage after each event. + + There are basically three ways to store audit records: in a + read/write file on a host, on a write-once/read-many device (e.g., a + CD-ROM or a specially configured tape drive), or on a write-only + device (e.g., a line printer). Each method has advantages and + disadvantages. + + File system logging is the least resource intensive of the three + methods and the easiest to configure. It allows instant access to + the records for analysis, which may be important if an attack is in + progress. File system logging is also the least reliable method. If + the logging host has been compromised, the file system is usually the + first thing to go; an intruder could easily cover up traces of the + intrusion. + + Collecting audit data on a write-once device is slightly more effort + to configure than a simple file, but it has the significant advantage + of greatly increased security because an intruder could not alter the + data showing that an intrusion has occurred. The disadvantage of + this method is the need to maintain a supply of storage media and the + cost of that media. Also, the data may not be instantly available. + + Line printer logging is useful in system where permanent and + immediate logs are required. A real time system is an example of + this, where the exact point of a failure or attack must be recorded. + A laser printer, or other device which buffers data (e.g., a print + server), may suffer from lost data if buffers contain the needed data + at a critical instant. The disadvantage of, literally, "paper + trails" is the need to keep the printer fed and the need to scan + records by hand. There is also the issue of where to store the, + potentially, enormous volume of paper which may be generated. + + For each of the logging methods described, there is also the issue of + securing the path between the device generating the log and actual + logging device (i.e., the file server, tape/CD-ROM drive, printer). + If that path is compromised, logging can be stopped or spoofed or + both. In an ideal world, the logging device would be directly + + + + + + + +Fraser, Ed. Informational [Page 35] + +RFC 2196 Site Security Handbook September 1997 + + + attached by a single, simple, point-to-point cable. Since that is + usually impractical, the path should pass through the minimum number + of networks and routers. Even if logs can be blocked, spoofing can + be prevented with cryptographic checksums (it probably isn't + necessary to encrypt the logs because they should not contain + sensitive information in the first place). + +4.6.3 Collection Load + + Collecting audit data may result in a rapid accumulation of bytes so + storage availability for this information must be considered in + advance. There are a few ways to reduce the required storage space. + First, data can be compressed, using one of many methods. Or, the + required space can be minimized by keeping data for a shorter period + of time with only summaries of that data kept in long-term archives. + One major drawback to the latter method involves incident response. + Often, an incident has been ongoing for some period of time when a + site notices it and begins to investigate. At that point in time, + it's very helpful to have detailed audit logs available. If these are + just summaries, there may not be sufficient detail to fully handle + the incident. + +4.6.4 Handling and Preserving Audit Data + + Audit data should be some of the most carefully secured data at the + site and in the backups. If an intruder were to gain access to audit + logs, the systems themselves, in addition to the data, would be at + risk. + + Audit data may also become key to the investigation, apprehension, + and prosecution of the perpetrator of an incident. For this reason, + it is advisable to seek the advice of legal council when deciding how + audit data should be treated. This should happen before an incident + occurs. + + If a data handling plan is not adequately defined prior to an + incident, it may mean that there is no recourse in the aftermath of + an event, and it may create liability resulting from improper + treatment of the data. + +4.6.5 Legal Considerations + + Due to the content of audit data, there are a number of legal + questions that arise which might need to be addressed by your legal + counsel. If you collect and save audit data, you need to be prepared + for consequences resulting both from its existence and its content. + + + + + +Fraser, Ed. Informational [Page 36] + +RFC 2196 Site Security Handbook September 1997 + + + One area concerns the privacy of individuals. In certain instances, + audit data may contain personal information. Searching through the + data, even for a routine check of the system's security, could + represent an invasion of privacy. + + A second area of concern involves knowledge of intrusive behavior + originating from your site. If an organization keeps audit data, is + it responsible for examining it to search for incidents? If a host + in one organization is used as a launching point for an attack + against another organization, can the second organization use the + audit data of the first organization to prove negligence on the part + of that organization? + + The above examples are meant to be comprehensive, but should motivate + your organization to consider the legal issues involved with audit + data. + +4.7 Securing Backups + + The procedure of creating backups is a classic part of operating a + computer system. Within the context of this document, backups are + addressed as part of the overall security plan of a site. There are + several aspects to backups that are important within this context: + + (1) Make sure your site is creating backups + (2) Make sure your site is using offsite storage for backups. The + storage site should be carefully selected for both its security + and its availability. + (3) Consider encrypting your backups to provide additional protection + of the information once it is off-site. However, be aware that + you will need a good key management scheme so that you'll be + able to recover data at any point in the future. Also, make + sure you will have access to the necessary decryption programs + at such time in the future as you need to perform the + decryption. + (4) Don't always assume that your backups are good. There have been + many instances of computer security incidents that have gone on + for long periods of time before a site has noticed the incident. + In such cases, backups of the affected systems are also tainted. + (5) Periodically verify the correctness and completeness of your + backups. + +5. Security Incident Handling + + This chapter of the document will supply guidance to be used before, + during, and after a computer security incident occurs on a host, + network, site, or multi-site environment. The operative philosophy + in the event of a breach of computer security is to react according + + + +Fraser, Ed. Informational [Page 37] + +RFC 2196 Site Security Handbook September 1997 + + + to a plan. This is true whether the breach is the result of an + external intruder attack, unintentional damage, a student testing + some new program to exploit a software vulnerability, or a + disgruntled employee. Each of the possible types of events, such as + those just listed, should be addressed in advance by adequate + contingency plans. + + Traditional computer security, while quite important in the overall + site security plan, usually pays little attention to how to actually + handle an attack once one occurs. The result is that when an attack + is in progress, many decisions are made in haste and can be damaging + to tracking down the source of the incident, collecting evidence to + be used in prosecution efforts, preparing for the recovery of the + system, and protecting the valuable data contained on the system. + + One of the most important, but often overlooked, benefits for + efficient incident handling is an economic one. Having both + technical and managerial personnel respond to an incident requires + considerable resources. If trained to handle incidents efficiently, + less staff time is required when one occurs. + + Due to the world-wide network most incidents are not restricted to a + single site. Operating systems vulnerabilities apply (in some cases) + to several millions of systems, and many vulnerabilities are + exploited within the network itself. Therefore, it is vital that all + sites with involved parties be informed as soon as possible. + + Another benefit is related to public relations. News about computer + security incidents tends to be damaging to an organization's stature + among current or potential clients. Efficient incident handling + minimizes the potential for negative exposure. + + A final benefit of efficient incident handling is related to legal + issues. It is possible that in the near future organizations may be + held responsible because one of their nodes was used to launch a + network attack. In a similar vein, people who develop patches or + workarounds may be sued if the patches or workarounds are + ineffective, resulting in compromise of the systems, or, if the + patches or workarounds themselves damage systems. Knowing about + operating system vulnerabilities and patterns of attacks, and then + taking appropriate measures to counter these potential threats, is + critical to circumventing possible legal problems. + + + + + + + + + +Fraser, Ed. Informational [Page 38] + +RFC 2196 Site Security Handbook September 1997 + + + The sections in this chapter provide an outline and starting point + for creating your site's policy for handling security incidents. The + sections are: + + (1) Preparing and planning (what are the goals and objectives in + handling an incident). + (2) Notification (who should be contacted in the case of an + incident). + - Local managers and personnel + - Law enforcement and investigative agencies + - Computer security incidents handling teams + - Affected and involved sites + - Internal communications + - Public relations and press releases + (3) Identifying an incident (is it an incident and how serious is + it). + (4) Handling (what should be done when an incident occurs). + - Notification (who should be notified about the incident) + - Protecting evidence and activity logs (what records should be + kept from before, during, and after the incident) + - Containment (how can the damage be limited) + - Eradication (how to eliminate the reasons for the incident) + - Recovery (how to reestablish service and systems) + - Follow Up (what actions should be taken after the incident) + (5) Aftermath (what are the implications of past incidents). + (6) Administrative response to incidents. + + The remainder of this chapter will detail the issues involved in each + of the important topics listed above, and provide some guidance as to + what should be included in a site policy for handling incidents. + +5.1 Preparing and Planning for Incident Handling + + Part of handling an incident is being prepared to respond to an + incident before the incident occurs in the first place. This + includes establishing a suitable level of protections as explained in + the preceding chapters. Doing this should help your site prevent + incidents as well as limit potential damage resulting from them when + they do occur. Protection also includes preparing incident handling + guidelines as part of a contingency plan for your organization or + site. Having written plans eliminates much of the ambiguity which + occurs during an incident, and will lead to a more appropriate and + thorough set of responses. It is vitally important to test the + proposed plan before an incident occurs through "dry runs". A team + might even consider hiring a tiger team to act in parallel with the + dry run. (Note: a tiger team is a team of specialists that try to + penetrate the security of a system.) + + + + +Fraser, Ed. Informational [Page 39] + +RFC 2196 Site Security Handbook September 1997 + + + Learning to respond efficiently to an incident is important for a + number of reasons: + + (1) Protecting the assets which could be compromised + (2) Protecting resources which could be utilized more + profitably if an incident did not require their services + (3) Complying with (government or other) regulations + (4) Preventing the use of your systems in attacks against other + systems (which could cause you to incur legal liability) + (5) Minimizing the potential for negative exposure + + As in any set of pre-planned procedures, attention must be paid to a + set of goals for handling an incident. These goals will be + prioritized differently depending on the site. A specific set of + objectives can be identified for dealing with incidents: + + (1) Figure out how it happened. + (2) Find out how to avoid further exploitation of the same + vulnerability. + (3) Avoid escalation and further incidents. + (4) Assess the impact and damage of the incident. + (5) Recover from the incident. + (6) Update policies and procedures as needed. + (7) Find out who did it (if appropriate and possible). + + Due to the nature of the incident, there might be a conflict between + analyzing the original source of a problem and restoring systems and + services. Overall goals (like assuring the integrity of critical + systems) might be the reason for not analyzing an incident. Of + course, this is an important management decision; but all involved + parties must be aware that without analysis the same incident may + happen again. + + It is also important to prioritize the actions to be taken during an + incident well in advance of the time an incident occurs. Sometimes + an incident may be so complex that it is impossible to do everything + at once to respond to it; priorities are essential. Although + priorities will vary from institution to institution, the following + suggested priorities may serve as a starting point for defining your + organization's response: + + (1) Priority one -- protect human life and people's + safety; human life always has precedence over all + other considerations. + + (2) Priority two -- protect classified and/or sensitive + data. Prevent exploitation of classified and/or + sensitive systems, networks or sites. Inform affected + + + +Fraser, Ed. Informational [Page 40] + +RFC 2196 Site Security Handbook September 1997 + + + classified and/or sensitive systems, networks or sites + about already occurred penetrations. + (Be aware of regulations by your site or by government) + + (3) Priority three -- protect other data, including + proprietary, scientific, managerial and other data, + because loss of data is costly in terms of resources. + Prevent exploitations of other systems, networks or + sites and inform already affected systems, networks or + sites about successful penetrations. + + (4) Priority four -- prevent damage to systems (e.g., loss + or alteration of system files, damage to disk drives, + etc.). Damage to systems can result in costly down + time and recovery. + + (5) Priority five -- minimize disruption of computing + resources (including processes). It is better in many + cases to shut a system down or disconnect from a network + than to risk damage to data or systems. Sites will have + to evaluate the trade-offs between shutting down and + disconnecting, and staying up. There may be service + agreements in place that may require keeping systems + up even in light of further damage occurring. However, + the damage and scope of an incident may be so extensive + that service agreements may have to be over-ridden. + + An important implication for defining priorities is that once human + life and national security considerations have been addressed, it is + generally more important to save data than system software and + hardware. Although it is undesirable to have any damage or loss + during an incident, systems can be replaced. However, the loss or + compromise of data (especially classified or proprietary data) is + usually not an acceptable outcome under any circumstances. + + Another important concern is the effect on others, beyond the systems + and networks where the incident occurs. Within the limits imposed by + government regulations it is always important to inform affected + parties as soon as possible. Due to the legal implications of this + topic, it should be included in the planned procedures to avoid + further delays and uncertainties for the administrators. + + Any plan for responding to security incidents should be guided by + local policies and regulations. Government and private sites that + deal with classified material have specific rules that they must + follow. + + + + + +Fraser, Ed. Informational [Page 41] + +RFC 2196 Site Security Handbook September 1997 + + + The policies chosen by your site on how it reacts to incidents will + shape your response. For example, it may make little sense to create + mechanisms to monitor and trace intruders if your site does not plan + to take action against the intruders if they are caught. Other + organizations may have policies that affect your plans. Telephone + companies often release information about telephone traces only to + law enforcement agencies. + + Handling incidents can be tedious and require any number of routine + tasks that could be handled by support personnel. To free the + technical staff it may be helpful to identify support staff who will + help with tasks like: photocopying, fax'ing, etc. + +5.2 Notification and Points of Contact + + It is important to establish contacts with various personnel before a + real incident occurs. Many times, incidents are not real + emergencies. Indeed, often you will be able to handle the activities + internally. However, there will also be many times when others + outside your immediate department will need to be included in the + incident handling. These additional contacts include local managers + and system administrators, administrative contacts for other sites on + the Internet, and various investigative organizations. Getting to + know these contacts before incidents occurs will help to make your + incident handling process more efficient. + + For each type of communication contact, specific "Points of Contact" + (POC) should be defined. These may be technical or administrative in + nature and may include legal or investigative agencies as well as + service providers and vendors. When establishing these contact, it + is important to decide how much information will be shared with each + class of contact. It is especially important to define, ahead of + time, what information will be shared with the users at a site, with + the public (including the press), and with other sites. + + Settling these issues are especially important for the local person + responsible for handling the incident, since that is the person + responsible for the actual notification of others. A list of + contacts in each of these categories is an important time saver for + this person during an incident. It can be quite difficult to find an + appropriate person during an incident when many urgent events are + ongoing. It is strongly recommended that all relevant telephone + numbers (also electronic mail addresses and fax numbers) be included + in the site security policy. The names and contact information of + all individuals who will be directly involved in the handling of an + incident should be placed at the top of this list. + + + + + +Fraser, Ed. Informational [Page 42] + +RFC 2196 Site Security Handbook September 1997 + + +5.2.1 Local Managers and Personnel + + When an incident is under way, a major issue is deciding who is in + charge of coordinating the activity of the multitude of players. A + major mistake that can be made is to have a number of people who are + each working independently, but are not working together. This will + only add to the confusion of the event and will probably lead to + wasted or ineffective effort. + + The single POC may or may not be the person responsible for handling + the incident. There are two distinct roles to fill when deciding who + shall be the POC and who will be the person in charge of the + incident. The person in charge of the incident will make decisions + as to the interpretation of policy applied to the event. In + contrast, the POC must coordinate the effort of all the parties + involved with handling the event. + + The POC must be a person with the technical expertise to successfully + coordinate the efforts of the system managers and users involved in + monitoring and reacting to the attack. Care should be taken when + identifying who this person will be. It should not necessarily be + the same person who has administrative responsibility for the + compromised systems since often such administrators have knowledge + only sufficient for the day to day use of the computers, and lack in + depth technical expertise. + + Another important function of the POC is to maintain contact with law + enforcement and other external agencies to assure that multi-agency + involvement occurs. The level of involvement will be determined by + management decisions as well as legal constraints. + + A single POC should also be the single person in charge of collecting + evidence, since as a rule of thumb, the more people that touch a + potential piece of evidence, the greater the possibility that it will + be inadmissible in court. To ensure that evidence will be acceptable + to the legal community, collecting evidence should be done following + predefined procedures in accordance with local laws and legal + regulations. + + One of the most critical tasks for the POC is the coordination of all + relevant processes. Responsibilities may be distributed over the + whole site, involving multiple independent departments or groups. + This will require a well coordinated effort in order to achieve + overall success. The situation becomes even more complex if multiple + sites are involved. When this happens, rarely will a single POC at + one site be able to adequately coordinate the handling of the entire + incident. Instead, appropriate incident response teams should be + involved. + + + +Fraser, Ed. Informational [Page 43] + +RFC 2196 Site Security Handbook September 1997 + + + The incident handling process should provide some escalation + mechanisms. In order to define such a mechanism, sites will need to + create an internal classification scheme for incidents. Associated + with each level of incident will be the appropriate POC and + procedures. As an incident is escalated, there may be a change in + the POC which will need to be communicated to all others involved in + handling the incident. When a change in the POC occurs, old POC + should brief the new POC in all background information. + + Lastly, users must know how to report suspected incidents. Sites + should establish reporting procedures that will work both during and + outside normal working hours. Help desks are often used to receive + these reports during normal working hours, while beepers and + telephones can be used for out of hours reporting. + +5.2.2 Law Enforcement and Investigative Agencies + + In the event of an incident that has legal consequences, it is + important to establish contact with investigative agencies (e.g, the + FBI and Secret Service in the U.S.) as soon as possible. Local law + enforcement, local security offices, and campus police departments + should also be informed as appropriate. This section describes many + of the issues that will be confronted, but it is acknowledged that + each organization will have its own local and governmental laws and + regulations that will impact how they interact with law enforcement + and investigative agencies. The most important point to make is that + each site needs to work through these issues. + + A primary reason for determining these point of contact well in + advance of an incident is that once a major attack is in progress, + there is little time to call these agencies to determine exactly who + the correct point of contact is. Another reason is that it is + important to cooperate with these agencies in a manner that will + foster a good working relationship, and that will be in accordance + with the working procedures of these agencies. Knowing the working + procedures in advance, and the expectations of your point of contact + is a big step in this direction. For example, it is important to + gather evidence that will be admissible in any subsequent legal + proceedings, and this will require prior knowledge of how to gather + such evidence. A final reason for establishing contacts as soon as + possible is that it is impossible to know the particular agency that + will assume jurisdiction in any given incident. Making contacts and + finding the proper channels early on will make responding to an + incident go considerably more smoothly. + + + + + + + +Fraser, Ed. Informational [Page 44] + +RFC 2196 Site Security Handbook September 1997 + + + If your organization or site has a legal counsel, you need to notify + this office soon after you learn that an incident is in progress. At + a minimum, your legal counsel needs to be involved to protect the + legal and financial interests of your site or organization. There + are many legal and practical issues, a few of which are: + + + (1) Whether your site or organization is willing to risk negative + publicity or exposure to cooperate with legal prosecution + efforts. + + (2) Downstream liability--if you leave a compromised system as is so + it can be monitored and another computer is damaged because the + attack originated from your system, your site or organization + may be liable for damages incurred. + + (3) Distribution of information--if your site or organization + distributes information about an attack in which another site or + organization may be involved or the vulnerability in a product + that may affect ability to market that product, your site or + organization may again be liable for any damages (including + damage of reputation). + + (4) Liabilities due to monitoring--your site or organization may be + sued if users at your site or elsewhere discover that your site + is monitoring account activity without informing users. + + Unfortunately, there are no clear precedents yet on the liabilities + or responsibilities of organizations involved in a security incident + or who might be involved in supporting an investigative effort. + Investigators will often encourage organizations to help trace and + monitor intruders. Indeed, most investigators cannot pursue computer + intrusions without extensive support from the organizations involved. + However, investigators cannot provide protection from liability + claims, and these kinds of efforts may drag out for months and may + take a lot of effort. + + On the other hand, an organization's legal council may advise extreme + caution and suggest that tracing activities be halted and an intruder + shut out of the system. This, in itself, may not provide protection + from liability, and may prevent investigators from identifying the + perpetrator. + + The balance between supporting investigative activity and limiting + liability is tricky. You'll need to consider the advice of your legal + counsel and the damage the intruder is causing (if any) when making + your decision about what to do during any particular incident. + + + + +Fraser, Ed. Informational [Page 45] + +RFC 2196 Site Security Handbook September 1997 + + + Your legal counsel should also be involved in any decision to contact + investigative agencies when an incident occurs at your site. The + decision to coordinate efforts with investigative agencies is most + properly that of your site or organization. Involving your legal + counsel will also foster the multi-level coordination between your + site and the particular investigative agency involved, which in turn + results in an efficient division of labor. Another result is that + you are likely to obtain guidance that will help you avoid future + legal mistakes. + + Finally, your legal counsel should evaluate your site's written + procedures for responding to incidents. It is essential to obtain a + "clean bill of health" from a legal perspective before you actually + carry out these procedures. + + It is vital, when dealing with investigative agencies, to verify that + the person who calls asking for information is a legitimate + representative from the agency in question. Unfortunately, many well + intentioned people have unknowingly leaked sensitive details about + incidents, allowed unauthorized people into their systems, etc., + because a caller has masqueraded as a representative of a government + agency. (Note: this word of caution actually applies to all external + contacts.) + + A similar consideration is using a secure means of communication. + Because many network attackers can easily re-route electronic mail, + avoid using electronic mail to communicate with other agencies (as + well as others dealing with the incident at hand). Non-secured phone + lines (the phones normally used in the business world) are also + frequent targets for tapping by network intruders, so be careful! + + There is no one established set of rules for responding to an + incident when the local government becomes involved. Normally (in + the U.S.), except by legal order, no agency can force you to monitor, + to disconnect from the network, to avoid telephone contact with the + suspected attackers, etc. Each organization will have a set of local + and national laws and regulations that must be adhered to when + handling incidents. It is recommended that each site be familiar with + those laws and regulations, and identify and get know the contacts + for agencies with jurisdiction well in advance of handling an + incident. + +5.2.3 Computer Security Incident Handling Teams + + There are currently a number of of Computer Security Incident + Response teams (CSIRTs) such as the CERT Coordination Center, the + German DFN-CERT, and other teams around the globe. Teams exist for + many major government agencies and large corporations. If such a + + + +Fraser, Ed. Informational [Page 46] + +RFC 2196 Site Security Handbook September 1997 + + + team is available, notifying it should be of primary consideration + during the early stages of an incident. These teams are responsible + for coordinating computer security incidents over a range of sites + and larger entities. Even if the incident is believed to be + contained within a single site, it is possible that the information + available through a response team could help in fully resolving the + incident. + + If it is determined that the breach occurred due to a flaw in the + system's hardware or software, the vendor (or supplier) and a + Computer Security Incident Handling team should be notified as soon + as possible. This is especially important because many other systems + are vulnerable, and these vendor and response team organizations can + help disseminate help to other affected sites. + + In setting up a site policy for incident handling, it may be + desirable to create a subgroup, much like those teams that already + exist, that will be responsible for handling computer security + incidents for the site (or organization). If such a team is created, + it is essential that communication lines be opened between this team + and other teams. Once an incident is under way, it is difficult to + open a trusted dialogue between other teams if none has existed + before. + +5.2.4 Affected and Involved Sites + + If an incident has an impact on other sites, it is good practice to + inform them. It may be obvious from the beginning that the incident + is not limited to the local site, or it may emerge only after further + analysis. + + Each site may choose to contact other sites directly or they can pass + the information to an appropriate incident response team. It is often + very difficult to find the responsible POC at remote sites and the + incident response team will be able to facilitate contact by making + use of already established channels. + + The legal and liability issues arising from a security incident will + differ from site to site. It is important to define a policy for the + sharing and logging of information about other sites before an + incident occurs. + + Information about specific people is especially sensitive, and may be + subject to privacy laws. To avoid problems in this area, irrelevant + information should be deleted and a statement of how to handle the + remaining information should be included. A clear statement of how + this information is to be used is essential. No one who informs a + site of a security incident wants to read about it in the public + + + +Fraser, Ed. Informational [Page 47] + +RFC 2196 Site Security Handbook September 1997 + + + press. Incident response teams are valuable in this respect. When + they pass information to responsible POCs, they are able to protect + the anonymity of the original source. But, be aware that, in many + cases, the analysis of logs and information at other sites will + reveal addresses of your site. + + All the problems discussed above should be not taken as reasons not + to involve other sites. In fact, the experiences of existing teams + reveal that most sites informed about security problems are not even + aware that their site had been compromised. Without timely + information, other sites are often unable to take action against + intruders. + +5.2.5 Internal Communications + + It is crucial during a major incident to communicate why certain + actions are being taken, and how the users (or departments) are + expected to behave. In particular, it should be made very clear to + users what they are allowed to say (and not say) to the outside world + (including other departments). For example, it wouldn't be good for + an organization if users replied to customers with something like, + "I'm sorry the systems are down, we've had an intruder and we are + trying to clean things up." It would be much better if they were + instructed to respond with a prepared statement like, "I'm sorry our + systems are unavailable, they are being maintained for better service + in the future." + + Communications with customers and contract partners should be handled + in a sensible, but sensitive way. One can prepare for the main issues + by preparing a checklist. When an incident occurs, the checklist can + be used with the addition of a sentence or two for the specific + circumstances of the incident. + + Public relations departments can be very helpful during incidents. + They should be involved in all planning and can provide well + constructed responses for use when contact with outside departments + and organizations is necessary. + +5.2.6 Public Relations - Press Releases + + There has been a tremendous growth in the amount of media coverage + dedicated to computer security incidents in the United States. Such + press coverage is bound to extend to other countries as the Internet + continues to grow and expand internationally. Readers from countries + where such media attention has not yet occurred, can learn from the + experiences in the U.S. and should be forwarned and prepared. + + + + + +Fraser, Ed. Informational [Page 48] + +RFC 2196 Site Security Handbook September 1997 + + + One of the most important issues to consider is when, who, and how + much to release to the general public through the press. There are + many issues to consider when deciding this particular issue. First + and foremost, if a public relations office exists for the site, it is + important to use this office as liaison to the press. The public + relations office is trained in the type and wording of information + released, and will help to assure that the image of the site is + protected during and after the incident (if possible). A public + relations office has the advantage that you can communicate candidly + with them, and provide a buffer between the constant press attention + and the need of the POC to maintain control over the incident. + + If a public relations office is not available, the information + released to the press must be carefully considered. If the + information is sensitive, it may be advantageous to provide only + minimal or overview information to the press. It is quite possible + that any information provided to the press will be quickly reviewed + by the perpetrator of the incident. Also note that misleading the + press can often backfire and cause more damage than releasing + sensitive information. + + While it is difficult to determine in advance what level of detail to + provide to the press, some guidelines to keep in mind are: + + (1) Keep the technical level of detail low. Detailed + information about the incident may provide enough + information for others to launch similar attacks on + other sites, or even damage the site's ability to + prosecute the guilty party once the event is over. + + (2) Keep the speculation out of press statements. + Speculation of who is causing the incident or the + motives are very likely to be in error and may cause + an inflamed view of the incident. + + (3) Work with law enforcement professionals to assure that + evidence is protected. If prosecution is involved, + assure that the evidence collected is not divulged to + the press. + + (4) Try not to be forced into a press interview before you are + prepared. The popular press is famous for the "2 am" + interview, where the hope is to catch the interviewee off + guard and obtain information otherwise not available. + + (5) Do not allow the press attention to detract from the + handling of the event. Always remember that the successful + closure of an incident is of primary importance. + + + +Fraser, Ed. Informational [Page 49] + +RFC 2196 Site Security Handbook September 1997 + + +5.3 Identifying an Incident + +5.3.1 Is It Real? + + This stage involves determining if a problem really exists. Of + course many if not most signs often associated with virus infection, + system intrusions, malicious users, etc., are simply anomalies such + as hardware failures or suspicious system/user behavior. To assist + in identifying whether there really is an incident, it is usually + helpful to obtain and use any detection software which may be + available. Audit information is also extremely useful, especially in + determining whether there is a network attack. It is extremely + important to obtain a system snapshot as soon as one suspects that + something is wrong. Many incidents cause a dynamic chain of events + to occur, and an initial system snapshot may be the most valuable + tool for identifying the problem and any source of attack. Finally, + it is important to start a log book. Recording system events, + telephone conversations, time stamps, etc., can lead to a more rapid + and systematic identification of the problem, and is the basis for + subsequent stages of incident handling. + + There are certain indications or "symptoms" of an incident that + deserve special attention: + + (1) System crashes. + (2) New user accounts (the account RUMPLESTILTSKIN has been + unexpectedly created), or high activity on a previously + low usage account. + (3) New files (usually with novel or strange file names, + such as data.xx or k or .xx ). + (4) Accounting discrepancies (in a UNIX system you might + notice the shrinking of an accounting file called + /usr/admin/lastlog, something that should make you very + suspicious that there may be an intruder). + (5) Changes in file lengths or dates (a user should be + suspicious if .EXE files in an MS DOS computer have + unexplainedly grown by over 1800 bytes). + (6) Attempts to write to system (a system manager notices + that a privileged user in a VMS system is attempting to + alter RIGHTSLIST.DAT). + (7) Data modification or deletion (files start to disappear). + (8) Denial of service (a system manager and all other users + become locked out of a UNIX system, now in single user mode). + (9) Unexplained, poor system performance + (10) Anomalies ("GOTCHA" is displayed on the console or there + are frequent unexplained "beeps"). + (11) Suspicious probes (there are numerous unsuccessful login + attempts from another node). + + + +Fraser, Ed. Informational [Page 50] + +RFC 2196 Site Security Handbook September 1997 + + + (12) Suspicious browsing (someone becomes a root user on a UNIX + system and accesses file after file on many user accounts.) + (13) Inability of a user to log in due to modifications of his/her + account. + + By no means is this list comprehensive; we have just listed a number + of common indicators. It is best to collaborate with other technical + and computer security personnel to make a decision as a group about + whether an incident is occurring. + +5.3.2 Types and Scope of Incidents + + Along with the identification of the incident is the evaluation of + the scope and impact of the problem. It is important to correctly + identify the boundaries of the incident in order to effectively deal + with it and prioritize responses. + + In order to identify the scope and impact a set of criteria should be + defined which is appropriate to the site and to the type of + connections available. Some of the issues include: + + (1) Is this a multi-site incident? + (2) Are many computers at your site affected by this incident? + (3) Is sensitive information involved? + (4) What is the entry point of the incident (network, + phone line, local terminal, etc.)? + (5) Is the press involved? + (6) What is the potential damage of the incident? + (7) What is the estimated time to close out the incident? + (8) What resources could be required to handle the incident? + (9) Is law enforcement involved? + +5.3.3 Assessing the Damage and Extent + + The analysis of the damage and extent of the incident can be quite + time consuming, but should lead to some insight into the nature of + the incident, and aid investigation and prosecution. As soon as the + breach has occurred, the entire system and all of its components + should be considered suspect. System software is the most probable + target. Preparation is key to be able to detect all changes for a + possibly tainted system. This includes checksumming all media from + the vendor using a algorithm which is resistant to tampering. (See + sections 4.3) + + Assuming original vendor distribution media are available, an + analysis of all system files should commence, and any irregularities + should be noted and referred to all parties involved in handling the + incident. It can be very difficult, in some cases, to decide which + + + +Fraser, Ed. Informational [Page 51] + +RFC 2196 Site Security Handbook September 1997 + + + backup media are showing a correct system status. Consider, for + example, that the incident may have continued for months or years + before discovery, and the suspect may be an employee of the site, or + otherwise have intimate knowledge or access to the systems. In all + cases, the pre-incident preparation will determine what recovery is + possible. + + If the system supports centralized logging (most do), go back over + the logs and look for abnormalities. If process accounting and + connect time accounting is enabled, look for patterns of system + usage. To a lesser extent, disk usage may shed light on the + incident. Accounting can provide much helpful information in an + analysis of an incident and subsequent prosecution. Your ability to + address all aspects of a specific incident strongly depends on the + success of this analysis. + +5.4 Handling an Incident + + Certain steps are necessary to take during the handling of an + incident. In all security related activities, the most important + point to be made is that all sites should have policies in place. + Without defined policies and goals, activities undertaken will remain + without focus. The goals should be defined by management and legal + counsel in advance. + + One of the most fundamental objectives is to restore control of the + affected systems and to limit the impact and damage. In the worst + case scenario, shutting down the system, or disconnecting the system + from the network, may the only practical solution. + + As the activities involved are complex, try to get as much help as + necessary. While trying to solve the problem alone, real damage + might occur due to delays or missing information. Most + administrators take the discovery of an intruder as a personal + challenge. By proceeding this way, other objectives as outlined in + the local policies may not always be considered. Trying to catch + intruders may be a very low priority, compared to system integrity, + for example. Monitoring a hacker's activity is useful, but it might + not be considered worth the risk to allow the continued access. + +5.4.1 Types of Notification and Exchange of Information + + When you have confirmed that an incident is occurring, the + appropriate personnel must be notified. How this notification is + achieved is very important to keeping the event under control both + from a technical and emotional standpoint. The circumstances should + be described in as much detail as possible, in order to aid prompt + acknowledgment and understanding of the problem. Great care should + + + +Fraser, Ed. Informational [Page 52] + +RFC 2196 Site Security Handbook September 1997 + + + be taken when determining to which groups detailed technical + information is given during the notification. For example, it is + helpful to pass this kind of information to an incident handling team + as they can assist you by providing helpful hints for eradicating the + vulnerabilities involved in an incident. On the other hand, putting + the critical knowledge into the public domain (e.g., via USENET + newsgroups or mailing lists) may potentially put a large number of + systems at risk of intrusion. It is invalid to assume that all + administrators reading a particular newsgroup have access to + operating system source code, or can even understand an advisory well + enough to take adequate steps. + + First of all, any notification to either local or off-site personnel + must be explicit. This requires that any statement (be it an + electronic mail message, phone call, fax, beeper, or semaphone) + providing information about the incident be clear, concise, and fully + qualified. When you are notifying others that will help you handle + an event, a "smoke screen" will only divide the effort and create + confusion. If a division of labor is suggested, it is helpful to + provide information to each participant about what is being + accomplished in other efforts. This will not only reduce duplication + of effort, but allow people working on parts of the problem to know + where to obtain information relevant to their part of the incident. + + Another important consideration when communicating about the incident + is to be factual. Attempting to hide aspects of the incident by + providing false or incomplete information may not only prevent a + successful resolution to the incident, but may even worsen the + situation. + + The choice of language used when notifying people about the incident + can have a profound effect on the way that information is received. + When you use emotional or inflammatory terms, you raise the potential + for damage and negative outcomes of the incident. It is important to + remain calm both in written and spoken communications. + + Another consideration is that not all people speak the same language. + Due to this fact, misunderstandings and delay may arise, especially + if it is a multi-national incident. Other international concerns + include differing legal implications of a security incident and + cultural differences. However, cultural differences do not only + exist between countries. They even exist within countries, between + different social or user groups. For example, an administrator of a + university system might be very relaxed about attempts to connect to + the system via telnet, but the administrator of a military system is + likely to consider the same action as a possible attack. + + + + + +Fraser, Ed. Informational [Page 53] + +RFC 2196 Site Security Handbook September 1997 + + + Another issue associated with the choice of language is the + notification of non-technical or off-site personnel. It is important + to accurately describe the incident without generating undue alarm or + confusion. While it is more difficult to describe the incident to a + non-technical audience, it is often more important. A non-technical + description may be required for upper-level management, the press, or + law enforcement liaisons. The importance of these communications + cannot be underestimated and may make the difference between + resolving the incident properly and escalating to some higher level + of damage. + + If an incident response team becomes involved, it might be necessary + to fill out a template for the information exchange. Although this + may seem to be an additional burden and adds a certain delay, it + helps the team to act on this minimum set of information. The + response team may be able to respond to aspects of the incident of + which the local administrator is unaware. If information is given out + to someone else, the following minimum information should be + provided: + + (1) timezone of logs, ... in GMT or local time + (2) information about the remote system, including host names, + IP addresses and (perhaps) user IDs + (3) all log entries relevant for the remote site + (4) type of incident (what happened, why should you care) + + If local information (i.e., local user IDs) is included in the log + entries, it will be necessary to sanitize the entries beforehand to + avoid privacy issues. In general, all information which might assist + a remote site in resolving an incident should be given out, unless + local policies prohibit this. + +5.4.2 Protecting Evidence and Activity Logs + + When you respond to an incident, document all details related to the + incident. This will provide valuable information to yourself and + others as you try to unravel the course of events. Documenting all + details will ultimately save you time. If you don't document every + relevant phone call, for example, you are likely to forget a + significant portion of information you obtain, requiring you to + contact the source of information again. At the same time, recording + details will provide evidence for prosecution efforts, providing the + case moves in that direction. Documenting an incident will also help + you perform a final assessment of damage (something your management, + as well as law enforcement officers, will want to know), and will + provide the basis for later phases of the handling process: + eradication, recovery, and follow-up "lessons learned." + + + + +Fraser, Ed. Informational [Page 54] + +RFC 2196 Site Security Handbook September 1997 + + + During the initial stages of an incident, it is often infeasible to + determine whether prosecution is viable, so you should document as if + you are gathering evidence for a court case. At a minimum, you + should record: + + (1) all system events (audit records) + (2) all actions you take (time tagged) + (3) all external conversations (including the person with whom + you talked, the date and time, and the content of the + conversation) + + The most straightforward way to maintain documentation is keeping a + log book. This allows you to go to a centralized, chronological + source of information when you need it, instead of requiring you to + page through individual sheets of paper. Much of this information is + potential evidence in a court of law. Thus, when a legal follow-up + is a possibility, one should follow the prepared procedures and avoid + jeopardizing the legal follow-up by improper handling of possible + evidence. If appropriate, the following steps may be taken. + + (1) Regularly (e.g., every day) turn in photocopied, signed + copies of your logbook (as well as media you use to record + system events) to a document custodian. + (2) The custodian should store these copied pages in a secure + place (e.g., a safe). + (3) When you submit information for storage, you should + receive a signed, dated receipt from the document + custodian. + + Failure to observe these procedures can result in invalidation of any + evidence you obtain in a court of law. + +5.4.3 Containment + + The purpose of containment is to limit the extent of an attack. An + essential part of containment is decision making (e.g., determining + whether to shut a system down, disconnect from a network, monitor + system or network activity, set traps, disable functions such as + remote file transfer, etc.). + + Sometimes this decision is trivial; shut the system down if the + information is classified, sensitive, or proprietary. Bear in mind + that removing all access while an incident is in progress obviously + notifies all users, including the alleged problem users, that the + administrators are aware of a problem; this may have a deleterious + + + + + + +Fraser, Ed. Informational [Page 55] + +RFC 2196 Site Security Handbook September 1997 + + + effect on an investigation. In some cases, it is prudent to remove + all access or functionality as soon as possible, then restore normal + operation in limited stages. In other cases, it is worthwhile to + risk some damage to the system if keeping the system up might enable + you to identify an intruder. + + This stage should involve carrying out predetermined procedures. + Your organization or site should, for example, define acceptable + risks in dealing with an incident, and should prescribe specific + actions and strategies accordingly. This is especially important + when a quick decision is necessary and it is not possible to first + contact all involved parties to discuss the decision. In the absence + of predefined procedures, the person in charge of the incident will + often not have the power to make difficult management decisions (like + to lose the results of a costly experiment by shutting down a + system). A final activity that should occur during this stage of + incident handling is the notification of appropriate authorities. + +5.4.4 Eradication + + Once the incident has been contained, it is time to eradicate the + cause. But before eradicating the cause, great care should be taken + to collect all necessary information about the compromised system(s) + and the cause of the incident as they will likely be lost when + cleaning up the system. + + Software may be available to help you in the eradication process, + such as anti-virus software. If any bogus files have been created, + archive them before deleting them. In the case of virus infections, + it is important to clean and reformat any media containing infected + files. Finally, ensure that all backups are clean. Many systems + infected with viruses become periodically re-infected simply because + people do not systematically eradicate the virus from backups. After + eradication, a new backup should be taken. + + Removing all vulnerabilities once an incident has occurred is + difficult. The key to removing vulnerabilities is knowledge and + understanding of the breach. + + It may be necessary to go back to the original distribution media and + re-customize the system. To facilitate this worst case scenario, a + record of the original system setup and each customization change + should be maintained. In the case of a network-based attack, it is + important to install patches for each operating system vulnerability + which was exploited. + + + + + + +Fraser, Ed. Informational [Page 56] + +RFC 2196 Site Security Handbook September 1997 + + + As discussed in section 5.4.2, a security log can be most valuable + during this phase of removing vulnerabilities. The logs showing how + the incident was discovered and contained can be used later to help + determine how extensive the damage was from a given incident. The + steps taken can be used in the future to make sure the problem does + not resurface. Ideally, one should automate and regularly apply the + same test as was used to detect the security incident. + + If a particular vulnerability is isolated as having been exploited, + the next step is to find a mechanism to protect your system. The + security mailing lists and bulletins would be a good place to search + for this information, and you can get advice from incident response + teams. + +5.4.5 Recovery + + Once the cause of an incident has been eradicated, the recovery phase + defines the next stage of action. The goal of recovery is to return + the system to normal. In general, bringing up services in the order + of demand to allow a minimum of user inconvenience is the best + practice. Understand that the proper recovery procedures for the + system are extremely important and should be specific to the site. + +5.4.6 Follow-Up + + Once you believe that a system has been restored to a "safe" state, + it is still possible that holes, and even traps, could be lurking in + the system. One of the most important stages of responding to + incidents is also the most often omitted, the follow-up stage. In + the follow-up stage, the system should be monitored for items that + may have been missed during the cleanup stage. It would be prudent + to utilize some of the tools mentioned in chapter 7 as a start. + Remember, these tools don't replace continual system monitoring and + good systems administration practices. + + The most important element of the follow-up stage is performing a + postmortem analysis. Exactly what happened, and at what times? How + well did the staff involved with the incident perform? What kind of + information did the staff need quickly, and how could they have + gotten that information as soon as possible? What would the staff do + differently next time? + + After an incident, it is prudent to write a report describing the + exact sequence of events: the method of discovery, correction + procedure, monitoring procedure, and a summary of lesson learned. + This will aid in the clear understanding of the problem. Creating a + formal chronology of events (including time stamps) is also important + for legal reasons. + + + +Fraser, Ed. Informational [Page 57] + +RFC 2196 Site Security Handbook September 1997 + + + A follow-up report is valuable for many reasons. It provides a + reference to be used in case of other similar incidents. It is also + important to, as quickly as possible obtain a monetary estimate of + the amount of damage the incident caused. This estimate should + include costs associated with any loss of software and files + (especially the value of proprietary data that may have been + disclosed), hardware damage, and manpower costs to restore altered + files, reconfigure affected systems, and so forth. This estimate may + become the basis for subsequent prosecution activity. The report can + also help justify an organization's computer security effort to + management. + +5.5 Aftermath of an Incident + + In the wake of an incident, several actions should take place. These + actions can be summarized as follows: + + (1) An inventory should be taken of the systems' assets, + (i.e., a careful examination should determine how the + system was affected by the incident). + + (2) The lessons learned as a result of the incident + should be included in revised security plan to + prevent the incident from re-occurring. + + (3) A new risk analysis should be developed in light of the + incident. + + (4) An investigation and prosecution of the individuals + who caused the incident should commence, if it is + deemed desirable. + + If an incident is based on poor policy, and unless the policy is + changed, then one is doomed to repeat the past. Once a site has + recovered from and incident, site policy and procedures should be + reviewed to encompass changes to prevent similar incidents. Even + without an incident, it would be prudent to review policies and + procedures on a regular basis. Reviews are imperative due to today's + changing computing environments. + + The whole purpose of this post mortem process is to improve all + security measures to protect the site against future attacks. As a + result of an incident, a site or organization should gain practical + knowledge from the experience. A concrete goal of the post mortem is + to develop new proactive methods. Another important facet of the + aftermath may be end user and administrator education to prevent a + reoccurrence of the security problem. + + + + +Fraser, Ed. Informational [Page 58] + +RFC 2196 Site Security Handbook September 1997 + + +5.6 Responsibilities + +5.6.1 Not Crossing the Line + + It is one thing to protect one's own network, but quite another to + assume that one should protect other networks. During the handling + of an incident, certain system vulnerabilities of one's own systems + and the systems of others become apparent. It is quite easy and may + even be tempting to pursue the intruders in order to track them. + Keep in mind that at a certain point it is possible to "cross the + line," and, with the best of intentions, become no better than the + intruder. + + The best rule when it comes to propriety is to not use any facility + of remote sites which is not public. This clearly excludes any entry + onto a system (such as a remote shell or login session) which is not + expressly permitted. This may be very tempting; after a breach of + security is detected, a system administrator may have the means to + "follow it up," to ascertain what damage is being done to the remote + site. Don't do it! Instead, attempt to reach the appropriate point + of contact for the affected site. + +5.6.2 Good Internet Citizenship + + During a security incident there are two choices one can make. + First, a site can choose to watch the intruder in the hopes of + catching him; or, the site can go about cleaning up after the + incident and shut the intruder out of the systems. This is a + decision that must be made very thoughtfully, as there may be legal + liabilities if you choose to leave your site open, knowing that an + intruder is using your site as a launching pad to reach out to other + sites. Being a good Internet citizen means that you should try to + alert other sites that may have been impacted by the intruder. These + affected sites may be readily apparent after a thorough review of + your log files. + +5.6.3 Administrative Response to Incidents + + When a security incident involves a user, the site's security policy + should describe what action is to be taken. The transgression should + be taken seriously, but it is very important to be sure of the role + the user played. Was the user naive? Could there be a mistake in + attributing the security breach to the user? Applying administrative + action that assumes the user intentionally caused the incident may + + + + + + + +Fraser, Ed. Informational [Page 59] + +RFC 2196 Site Security Handbook September 1997 + + + not be appropriate for a user who simply made a mistake. It may be + appropriate to include sanctions more suitable for such a situation + in your policies (e.g., education or reprimand of a user) in addition + to more stern measures for intentional acts of intrusion and system + misuse. + +6. Ongoing Activities + + At this point in time, your site has hopefully developed a complete + security policy and has developed procedures to assist in the + configuration and management of your technology in support of those + policies. How nice it would be if you could sit back and relax at + this point and know that you were finished with the job of security. + Unfortunately, that isn't possible. Your systems and networks are + not a static environment, so you will need to review policies and + procedures on a regular basis. There are a number of steps you can + take to help you keep up with the changes around you so that you can + initiate corresponding actions to address those changes. The + following is a starter set and you may add others as appropriate for + your site. + + (1) Subscribe to advisories that are issued by various security incident + response teams, like those of the CERT Coordination Center, and + update your systems against those threats that apply to your site's + technology. + + (2) Monitor security patches that are produced by the vendors of your + equipment, and obtain and install all that apply. + + (3) Actively watch the configurations of your systems to identify any + changes that may have occurred, and investigate all anomalies. + + (4) Review all security policies and procedures annually (at a minimum). + + (5) Read relevant mailing lists and USENET newsgroups to keep up to + date with the latest information being shared by fellow + administrators. + + (6) Regularly check for compliance with policies and procedures. This + audit should be performed by someone other than the people who + define or implement the policies and procedures. + +7. Tools and Locations + + This chapter provides a brief list of publicly available security + technology which can be downloaded from the Internet. Many of the + items described below will undoubtedly be surpassed or made obsolete + before this document is published. + + + +Fraser, Ed. Informational [Page 60] + +RFC 2196 Site Security Handbook September 1997 + + + Some of the tools listed are applications such as end user programs + (clients) and their supporting system infrastructure (servers). + Others are tools that a general user will never see or need to use, + but may be used by applications, or by administrators to troubleshoot + security problems or to guard against intruders. + + A sad fact is that there are very few security conscious applications + currently available. Primarily, this is caused by the need for a + security infrastructure which must first be put into place for most + applications to operate securely. There is considerable effort + currently taking place to build this infrastructure so that + applications can take advantage of secure communications. + + Most of the tools and applications described below can be found in + one of the following archive sites: + + (1) CERT Coordination Center + ftp://info.cert.org:/pub/tools + (2) DFN-CERT + ftp://ftp.cert.dfn.de/pub/tools/ + (3) Computer Operations, Audit, and Security Tools (COAST) + coast.cs.purdue.edu:/pub/tools + + It is important to note that many sites, including CERT and COAST are + mirrored throughout the Internet. Be careful to use a "well known" + mirror site to retrieve software, and to use verification tools (md5 + checksums, etc.) to validate that software. A clever cracker might + advertise security software that has intentionally been designed to + provide access to data or systems. + +Tools + + COPS + DES + Drawbridge + identd (not really a security tool) + ISS + Kerberos + logdaemon + lsof + MD5 + PEM + PGP + rpcbind/portmapper replacement + SATAN + sfingerd + S/KEY + smrsh + + + +Fraser, Ed. Informational [Page 61] + +RFC 2196 Site Security Handbook September 1997 + + + ssh + swatch + TCP-Wrapper + tiger + Tripwire* + TROJAN.PL + +8. Mailing Lists and Other Resources + + It would be impossible to list all of the mail-lists and other + resources dealing with site security. However, these are some "jump- + points" from which the reader can begin. All of these references are + for the "INTERNET" constituency. More specific (vendor and + geographical) resources can be found through these references. + + Mailing Lists + + (1) CERT(TM) Advisory + Send mail to: cert-advisory-request@cert.org + Message Body: subscribe cert <FIRST NAME> <LAST NAME> + + A CERT advisory provides information on how to obtain a patch or + details of a workaround for a known computer security problem. + The CERT Coordination Center works with vendors to produce a + workaround or a patch for a problem, and does not publish + vulnerability information until a workaround or a patch is + available. A CERT advisory may also be a warning to our + constituency about ongoing attacks (e.g., + "CA-91:18.Active.Internet.tftp.Attacks"). + + + CERT advisories are also published on the USENET newsgroup: + comp.security.announce + + CERT advisory archives are available via anonymous FTP from + info.cert.org in the /pub/cert_advisories directory. + + (2) VIRUS-L List + Send mail to: listserv%lehiibm1.bitnet@mitvma.mit.edu + Message Body: subscribe virus-L FIRSTNAME LASTNAME + + VIRUS-L is a moderated mailing list with a focus + on computer virus issues. For more information, + including a copy of the posting guidelines, see + the file "virus-l.README", available by anonymous + FTP from cs.ucr.edu. + + + + + +Fraser, Ed. Informational [Page 62] + +RFC 2196 Site Security Handbook September 1997 + + + (3) Internet Firewalls + Send mail to: majordomo@greatcircle.com + Message Body: subscribe firewalls user@host + + The Firewalls mailing list is a discussion forum for + firewall administrators and implementors. + + USENET newsgroups + + (1) comp.security.announce + The comp.security.announce newsgroup is moderated + and is used solely for the distribution of CERT + advisories. + + (2) comp.security.misc + The comp.security.misc is a forum for the + discussion of computer security, especially as it + relates to the UNIX(r) Operating System. + + (3) alt.security + The alt.security newsgroup is also a forum for the + discussion of computer security, as well as other + issues such as car locks and alarm systems. + + (4) comp.virus + The comp.virus newsgroup is a moderated newsgroup + with a focus on computer virus issues. For more + information, including a copy of the posting + guidelines, see the file "virus-l.README", + available via anonymous FTP on info.cert.org + in the /pub/virus-l directory. + + (5) comp.risks + The comp.risks newsgroup is a moderated forum on + the risks to the public in computers and related + systems. + + World-Wide Web Pages + + (1) http://www.first.org/ + + Computer Security Resource Clearinghouse. The main focus is on + crisis response information; information on computer + security-related threats, vulnerabilities, and solutions. At the + same time, the Clearinghouse strives to be a general index to + computer security information on a broad variety of subjects, + including general risks, privacy, legal issues, viruses, + assurance, policy, and training. + + + +Fraser, Ed. Informational [Page 63] + +RFC 2196 Site Security Handbook September 1997 + + + (2) http://www.telstra.com.au/info/security.html + + This Reference Index contains a list of links to information + sources on Network and Computer Security. There is no implied + fitness to the Tools, Techniques and Documents contained within this + archive. Many if not all of these items work well, but we do + not guarantee that this will be so. This information is for the + education and legitimate use of computer security techniques only. + + (3) http://www.alw.nih.gov/Security/security.html + + This page features general information about computer security. + Information is organized by source and each section is organized + by topic. Recent modifications are noted in What's New page. + + (4) http://csrc.ncsl.nist.gov + + This archive at the National Institute of Standards and Technology's + Computer Security Resource Clearinghouse page contains a number of + announcements, programs, and documents related to computer security. + + * CERT and Tripwire are registered in the U.S. Patent and Trademark Office + +9. References + + The following references may not be available in all countries. + + [Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and + McAuliffe, "The Law and The Internet", USENIX 1995 Technical + Conference on UNIX and Advanced Computing, New Orleans, LA, January + 16-20, 1995. + + [ABA, 1989] American Bar Association, Section of Science and + Technology, "Guide to the Prosecution of Telecommunication Fraud by + the Use of Computer Crime Statutes", American Bar Association, 1989. + + [Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery", + Computers in Libraries, Vol. 9, No. 2, Pg. 4, February 1989. + + [Barrett, 1996] D. Barrett, "Bandits on the Information + Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996. + + [Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks, + Telecommunications and Data Communications", McGraw-Hill, 1992. + + [Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP + Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48, + April 1989. + + + +Fraser, Ed. Informational [Page 64] + +RFC 2196 Site Security Handbook September 1997 + + + [Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the + Kerberos Authentication System", Computer Communications Review, + October 1990. + + [Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings + of the Third Usenix Security Symposium, Baltimore, MD. September, + 1992. + + [Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M. + Bender, New York, NY, 1978-present. + + [Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes", + Dow Jones- Irwin, Homewood, IL. 1990. + + [Brand, 1990] R. Brand, "Coping with the Threat of Computer Security + Incidents: A Primer from Prevention through Recovery", R. Brand, 8 + June 1990. + + [Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and + the Vulnerability of National Telecommunications Networks to Computer + Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989. + + [BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt, + "BS 7799 : 1995 Code of Practice for Information Security + Management", British Standards Institution, London, 54, Effective 15 + February 1995. + + [Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of + Information", Proceedings of the Fifth IFIP International Conference + on Computer Security, IFIP/Sec '88. + + [Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition, + Butterworth Publishers, Stoneham, MA, 1987. + + [Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and + The Law", MIT Press, Cambridge, MA, 1995. + + [CCH, 1989] Commerce Clearing House, "Guide to Computer Law", + (Topical Law Reports), Chicago, IL., 1989. + + [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet + Filtering", USENIX: Proceedings of the Third UNIX Security Symposium, + Baltimore, MD, September 1992. + + [Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building + Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995. + + + + + +Fraser, Ed. Informational [Page 65] + +RFC 2196 Site Security Handbook September 1997 + + + [Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet + Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, + June 1990. + + [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker + is Lured, Endured, and Studied", AT&T Bell Laboratories. + + [Cheswick and Bellovin, 1994] W. Cheswick and S. Bellovin, "Firewalls + and Internet Security: Repelling the Wily Hacker", Addison-Wesley, + Reading, MA, 1994. + + [Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation + and Prosecution", U.S. Dept. of Justice, Office of Justice Programs, + Under Contract Number OJP-86-C-002, National Institute of Justice, + Washington, DC, July 1989. + + [Cooper, 1989] J. Cooper, "Computer and Communications Security: + Strategies for the 1990s", McGraw-Hill, 1989. + + [CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR + Statement on the Computer Virus", CPSR, Communications of the ACM, + Vol. 32, No. 6, Pg. 699, June 1989. + + [CSC-STD-002-85, 1985] Department of Defense, "Password Management + Guideline", CSC-STD-002-85, 12 April 1985, 31 pages. + + [Curry, 1990] D. Curry, "Improving the Security of Your UNIX System", + SRI International Report ITSTD-721-FR-90-21, April 1990. + + [Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and + Systems Administrators", Addision-Wesley, Reading, MA, 1992. + + [DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem + Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 + November 1988. + + [DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin + 03", DDN Security Coordination Center, 17 October 1989. + + [Denning, 1990] P. Denning, Editor, "Computers Under Attack: + Intruders, Worms, and Viruses", ACM Press, 1990. + + [Eichin and Rochlis, 1989] M. Eichin, and J. Rochlis, "With + Microscope and Tweezers: An Analysis of the Internet Virus of + November 1988", Massachusetts Institute of Technology, February 1989. + + + + + + +Fraser, Ed. Informational [Page 66] + +RFC 2196 Site Security Handbook September 1997 + + + [Eisenberg, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D. + Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell + University, 6 February 1989. + + [Ermann, Willians, and Gutierrez, 1990] D. Ermann, M. Williams, and + C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford + University Press, NY, 1990. (376 pages, includes bibliographical + references). + + [Farmer and Spafford, 1990] D. Farmer and E. Spafford, "The COPS + Security Checker System", Proceedings of the Summer 1990 USENIX + Conference, Anaheim, CA, Pgs. 165-170, June 1990. + + [Farrow, 1991] Rik Farrow, "UNIX Systems Security", Addison-Wesley, + Reading, MA, 1991. + + [Fenwick, 1985] W. Fenwick, Chair, "Computer Litigation, 1985: Trial + Tactics and Techniques", Litigation Course Handbook Series No. 280, + Prepared for distribution at the Computer Litigation, 1985: Trial + Tactics and Techniques Program, February-March 1985. + + [Fites 1989] M. Fites, P. Kratz, and A. Brebner, "Control and + Security of Computer Information Systems", Computer Science Press, + 1989. + + [Fites, Johnson, and Kratz, 1992] Fites, Johnson, and Kratz, "The + Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992. + + [Forester and Morrison, 1990] T. Forester, and P. Morrison, "Computer + Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, + Cambridge, MA, 1990. + + [Foster and Morrision, 1990] T. Forester, and P. Morrison, "Computer + Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, + Cambridge, MA, 1990. (192 pages including index.) + + [GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer + Security - Virus Highlights Need for Improved Internet Management", + United States General Accounting Office, Washington, DC, 1989. + + [Garfinkel and Spafford, 1991] S. Garfinkel, and E. Spafford, + "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2, + May 1991. + + [Garfinkel, 1995] S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly & + Associates, Sebastopol, CA, 1996. + + + + + +Fraser, Ed. Informational [Page 67] + +RFC 2196 Site Security Handbook September 1997 + + + [Garfinkel and Spafford, 1996] S. Garfinkel and E. Spafford, + "Practical UNIX and Internet Security", O'Reilly & Associates, + Sebastopol, CA, 1996. + + [Gemignani, 1989] M. Gemignani, "Viruses and Criminal Law", + Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989. + + [Goodell, 1996] J. Goodell, "The Cyberthief and the Samurai: The True + Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell + Publishing, 1996. + + [Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and + Social Implications of Computer Networking", Westview Press, Boulder, + CO, 1989. + + [Greenia, 1989] M. Greenia, "Computer Security Information + Sourcebook", Lexikon Services, Sacramento, CA, 1989. + + [Hafner and Markoff, 1991] K. Hafner and J. Markoff, "Cyberpunk: + Outlaws and Hackers on the Computer Frontier", Touchstone, Simon & + Schuster, 1991. + + [Hess, Safford, and Pooch] D. Hess, D. Safford, and U. Pooch, "A Unix + Network Protocol Security Study: Network Information Service", Texas + A&M University. + + [Hoffman, 1990] L. Hoffman, "Rogue Programs: Viruses, Worms, and + Trojan Horses", Van Nostrand Reinhold, NY, 1990. (384 pages, + includes bibliographical references and index.) + + [Howard, 1995] G. Howard, "Introduction to Internet Security: From + Basics to Beyond", Prima Publishing, Rocklin, CA, 1995. + + [Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors, + "Protection of Computer Systems and Software: New Approaches for + Combating Theft of Software and Unauthorized Intrusion", Papers + presented at a workshop sponsored by the National Science Foundation, + 1986. + + [Hughes, 1995] L. Hughes Jr., "Actually Useful Internet Security + Techniques", New Riders Publishing, Indianapolis, IN, 1995. + + [IAB-RFC1087, 1989] Internet Activities Board, "Ethics and the + Internet", RFC 1087, IAB, January 1989. Also appears in the + Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989. + + + + + + +Fraser, Ed. Informational [Page 68] + +RFC 2196 Site Security Handbook September 1997 + + + [Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W. + VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly & + Associates, Sebastopol, CA, 1995. + + [IVPC, 1996] IVPC, "International Virus Prevention Conference '96 + Proceedings", NCSA, 1996. + + [Johnson and Podesta] D. Johnson, and J. Podesta, "Formulating A + Company Policy on Access to and Use and Disclosure of Electronic Mail + on Company Computer Systems". + + [Kane, 1994] P. Kane, "PC Security and Virus Protection Handbook: The + Ongoing War Against Information Sabotage", M&T Books, 1994. + + [Kaufman, Perlman, and Speciner, 1995] C. Kaufman, R. Perlman, and M. + Speciner, "Network Security: PRIVATE Communication in a PUBLIC + World", Prentice Hall, Englewood Cliffs, NJ, 1995. + + [Kent, 1990] S. Kent, "E-Mail Privacy for the Internet: New Software + and Strict Registration Procedures will be Implemented this Year", + Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January + 1990. + + [Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution", + Delta, 1984. + + [Lewis, 1996] S. Lewis, "Disaster Recovery Yellow Pages", The Systems + Audit Group, 1996. + + [Littleman, 1996] J. Littleman, "The Fugitive Game: Online with Kevin + Mitnick", Little, Brown, Boston, MA., 1996. + + [Lu and Sundareshan, 1989] W. Lu and M. Sundareshan, "Secure + Communication in Internet Environments: A Hierarchical Key Management + Scheme for End-to-End Encryption", IEEE Transactions on + Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989. + + [Lu and Sundareshan, 1990] W. Lu and M. Sundareshan, "A Model for + Multilevel Security in Computer Networks", IEEE Transactions on + Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990. + + [Martin and Schinzinger, 1989] M. Martin, and R. Schinzinger, "Ethics + in Engineering", McGraw Hill, 2nd Edition, 1989. + + [Merkle] R. Merkle, "A Fast Software One Way Hash Function", Journal + of Cryptology, Vol. 3, No. 1. + + + + + +Fraser, Ed. Informational [Page 69] + +RFC 2196 Site Security Handbook September 1997 + + + [McEwen, 1989] J. McEwen, "Dedicated Computer Crime Units", Report + Contributors: D. Fester and H. Nugent, Prepared for the National + Institute of Justice, U.S. Department of Justice, by Institute for + Law and Justice, Inc., under contract number OJP-85-C-006, + Washington, DC, 1989. + + [MIT, 1989] Massachusetts Institute of Technology, "Teaching Students + About Responsible Use of Computers", MIT, 1985-1986. Also reprinted + in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena + Project, MIT, June 1989. + + [Mogel, 1989] Mogul, J., "Simple and Flexible Datagram Access + Controls for UNIX-based Gateways", Digital Western Research + Laboratory Research Report 89/4, March 1989. + + [Muffett, 1992] A. Muffett, "Crack Version 4.1: A Sensible Password + Checker for Unix" + + [NCSA1, 1995] NCSA, "NCSA Firewall Policy Guide", 1995. + + [NCSA2, 1995] NCSA, "NCSA's Corporate Computer Virus Prevention + Policy Model", NCSA, 1995. + + [NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96 + Proceedings", 1996. + + [NCSC-89-660-P, 1990] National Computer Security Center, "Guidelines + for Formal Verification Systems", Shipping list no.: 89-660-P, The + Center, Fort George G. Meade, MD, 1 April 1990. + + [NCSC-89-254-P, 1988] National Computer Security Center, "Glossary of + Computer Security Terms", Shipping list no.: 89-254-P, The Center, + Fort George G. Meade, MD, 21 October 1988. + + [NCSC-C1-001-89, 1989] Tinto, M., "Computer Viruses: Prevention, + Detection, and Treatment", National Computer Security Center C1 + Technical Report C1-001-89, June 1989. + + [NCSC Conference, 1989] National Computer Security Conference, "12th + National Computer Security Conference: Baltimore Convention Center, + Baltimore, MD, 10-13 October, 1989: Information Systems Security, + Solutions for Today - Concepts for Tomorrow", National Institute of + Standards and National Computer Security Center, 1989. + + [NCSC-CSC-STD-003-85, 1985] National Computer Security Center, + "Guidance for Applying the Department of Defense Trusted Computer + System Evaluation Criteria in Specific Environments", CSC-STD-003-85, + NCSC, 25 June 1985. + + + +Fraser, Ed. Informational [Page 70] + +RFC 2196 Site Security Handbook September 1997 + + + [NCSC-STD-004-85, 1985] National Computer Security Center, "Technical + Rationale Behind CSC-STD-003-85: Computer Security Requirements", + CSC-STD-004-85, NCSC, 25 June 1985. + + [NCSC-STD-005-85, 1985] National Computer Security Center, "Magnetic + Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November + 1985. + + [NCSC-TCSEC, 1985] National Computer Security Center, "Trusted + Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001- + 83, NCSC, December 1985. + + [NCSC-TG-003, 1987] NCSC, "A Guide to Understanding DISCRETIONARY + ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30 + September 1987, 29 pages. + + [NCSC-TG-001, 1988] NCSC, "A Guide to Understanding AUDIT in Trusted + Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages. + + [NCSC-TG-004, 1988] National Computer Security Center, "Glossary of + Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988. + + [NCSC-TG-005, 1987] National Computer Security Center, "Trusted + Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987. + + [NCSC-TG-006, 1988] NCSC, "A Guide to Understanding CONFIGURATION + MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March + 1988, 31 pages. + + [NCSC-TRUSIX, 1990] National Computer Security Center, "Trusted UNIX + Working Group (TRUSIX) rationale for selecting access control list + features for the UNIX system", Shipping list no.: 90-076-P, The + Center, Fort George G. Meade, MD, 1990. + + [NRC, 1991] National Research Council, "Computers at Risk: Safe + Computing in the Information Age", National Academy Press, 1991. + + [Nemeth, et. al, 1995] E. Nemeth, G. Snyder, S. Seebass, and T. Hein, + "UNIX Systems Administration Handbook", Prentice Hall PTR, Englewood + Cliffs, NJ, 2nd ed. 1995. + + [NIST, 1989] National Institute of Standards and Technology, + "Computer Viruses and Related Threats: A Management Guide", NIST + Special Publication 500-166, August 1989. + + [NSA] National Security Agency, "Information Systems Security + Products and Services Catalog", NSA, Quarterly Publication. + + + + +Fraser, Ed. Informational [Page 71] + +RFC 2196 Site Security Handbook September 1997 + + + [NSF, 1988] National Science Foundation, "NSF Poses Code of + Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. + 688, June 1989. Also appears in the minutes of the regular meeting + of the Division Advisory Panel for Networking and Communications + Research and Infrastructure, Dave Farber, Chair, November 29-30, + 1988. + + [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation + Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58 + pages. + + [OTA-CIT-310, 1987] United States Congress, Office of Technology + Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for + Electronic Information", OTA-CIT-310, October 1987. + + [OTA-TCT-606] Congress of the United States, Office of Technology + Assessment, "Information Security and Privacy in Network + Environments", OTA-TCT-606, September 1994. + + [Palmer and Potter, 1989] I. Palmer, and G. Potter, "Computer + Security Risk Management", Van Nostrand Reinhold, NY, 1989. + + [Parker, 1989] D. Parker, "Computer Crime: Criminal Justice Resource + Manual", U.S. Dept. of Justice, National Institute of Justice, Office + of Justice Programs, Under Contract Number OJP-86-C-002, Washington, + D.C., August 1989. + + [Parker, Swope, and Baker, 1990] D. Parker, S. Swope, and B. Baker, + "Ethical Conflicts: Information and Computer Science, Technology and + Business", QED Information Sciences, Inc., Wellesley, MA. (245 + pages). + + [Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall, + Englewood Cliffs, NJ, 1989. + + [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks + and Conferencing Systems Worldwide", Digital Press, Bedford, MA, + 1990. + + [Ranum1, 1992] M. Ranum, "An Internet Firewall", Proceedings of World + Conference on Systems Management and Security, 1992. + + [Ranum2, 1992] M. Ranum, "A Network Firewall", Digital Equipment + Corporation Washington Open Systems Resource Center, June 12, 1992. + + [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993. + + + + + +Fraser, Ed. Informational [Page 72] + +RFC 2196 Site Security Handbook September 1997 + + + [Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and + Methods for Internet Firewalls", Trustest Information Systems, 1994. + + [Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX + Network Security" + + [Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX + Network Security", ARINC Research Corporation, February 18, 1993. + + [Reynolds-RFC1135, 1989] The Helminthiasis of the Internet, RFC 1135, + USC/Information Sciences Institute, Marina del Rey, CA, December + 1989. + + [Russell and Gangemi, 1991] D. Russell and G. Gangemi, "Computer + Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991. + + [Schneier 1996] B. Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", John Wiley & Sons, New York, + second edition, 1996. + + [Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989 + Winter USENIX Conference, Usenix Association, San Diego, CA, February + 1989. + + [Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986", + Congressional Record (3 June 1986), Washington, D.C., 3 June 1986. + + [Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit + and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw- + by the Man Who Did It", Hyperion, 1996. + + [Shirey, 1990] R. Shirey, "Defense Data Network Security + Architecture", Computer Communication Review, Vol. 20, No. 2, Page + 66, 1 April 1990. + + [Slatalla and Quittner, 1995] M. Slatalla and J. Quittner, "Masters + of Deception: The Gang that Ruled Cyberspace", Harper Collins + Publishers, 1995. + + [Smith, 1989] M. Smith, "Commonsense Computer Security: Your + Practical Guide to Preventing Accidental and Deliberate Electronic + Data Loss", McGraw-Hill, New York, NY, 1989. + + [Smith, 1995] D. Smith, "Forming an Incident Response Team", Sixth + Annual Computer Security Incident Handling Workshop, Boston, MA, July + 25-29, 1995. + + + + + +Fraser, Ed. Informational [Page 73] + +RFC 2196 Site Security Handbook September 1997 + + + [Spafford, 1988] E. Spafford, "The Internet Worm Program: An + Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM, + January 1989. Also issued as Purdue CS Technical Report CSD-TR-823, + 28 November 1988. + + [Spafford, 1989] G. Spafford, "An Analysis of the Internet Worm", + Proceedings of the European Software Engineering Conference 1989, + Warwick England, September 1989. Proceedings published by Springer- + Verlag as: Lecture Notes in Computer Science #387. Also issued as + Purdue Technical Report #CSD-TR-933. + + [Spafford, Keaphy, and Ferbrache, 1989] E. Spafford, K. Heaphy, and + D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism + and Programmed Threats", ADAPSO, 1989. (109 pages.) + + [Stallings1, 1995] W. Stallings, "Internet Security Handbook", IDG + Books, Foster City CA, 1995. + + [Stallings2, 1995] W. Stallings, "Network and InterNetwork Security", + Prentice Hall, , 1995. + + [Stallings3, 1995] W. Stallings, "Protect Your Privacy: A Guide for + PGP Users" PTR Prentice Hall, 1995. + + [Stoll, 1988] C. Stoll, "Stalking the Wily Hacker", Communications of + the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988. + + [Stoll, 1989] C. Stoll, "The Cuckoo's Egg", ISBN 00385-24946-2, + Doubleday, 1989. + + [Treese and Wolman, 1993] G. Treese and A. Wolman, "X Through the + Firewall, and Other Applications Relays", Digital Equipment + Corporation, Cambridge Research Laboratory, CRL 93/10, May 3, 1993. + + [Trible, 1986] P. Trible, "The Computer Fraud and Abuse Act of 1986", + U.S. Senate Committee on the Judiciary, 1986. + + [Venema] W. Venema, "TCP WRAPPER: Network monitoring, access control, + and booby traps", Mathematics and Computing Science, Eindhoven + University of Technology, The Netherlands. + + [USENIX, 1988] USENIX, "USENIX Proceedings: UNIX Security Workshop", + Portland, OR, August 29-30, 1988. + + [USENIX, 1990] USENIX, "USENIX Proceedings: UNIX Security II + Workshop", Portland, OR, August 27-28, 1990. + + + + + +Fraser, Ed. Informational [Page 74] + +RFC 2196 Site Security Handbook September 1997 + + + [USENIX, 1992] USENIX, "USENIX Symposium Proceedings: UNIX Security + III", Baltimore, MD, September 14-16, 1992. + + [USENIX, 1993] USENIX, "USENIX Symposium Proceedings: UNIX Security + IV", Santa Clara, CA, October 4-6, 1993. + + [USENIX, 1995] USENIX, "The Fifth USENIX UNIX Security Symposium", + Salt Lake City, UT, June 5-7, 1995. + + [Wood, et.al., 1987] C. Wood, W. Banks, S. Guarro, A. Garcia, V. + Hampel, and H. Sartorio, "Computer Security: A Comprehensive + Controls Checklist", John Wiley and Sons, Interscience Publication, + 1987. + + [Wrobel, 1993] L. Wrobel, "Writing Disaster Recovery Plans for + Telecommunications Networks and LANS", Artech House, 1993. + + [Vallabhaneni, 1989] S. Vallabhaneni, "Auditing Computer Security: A + Manual with Case Studies", Wiley, New York, NY, 1989. + +Security Considerations + + This entire document discusses security issues. + +Editor Information + + Barbara Y. Fraser + Software Engineering Institute + Carnegie Mellon University + 5000 Forbes Avenue + Pittsburgh, PA 15213 + + Phone: (412) 268-5010 + Fax: (412) 268-6989 + EMail: byf@cert.org + + + + + + + + + + + + + + + + +Fraser, Ed. Informational [Page 75] + |