HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 08:29:16 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 30 Mar 1996 23:00:00 GMT ETag: "323ba2-2539a-315dbcf0" Accept-Ranges: bytes Content-Length: 152474 Connection: close Content-Type: text/plain Internet Draft Barbara Fraser Network Working Group SEI/CMU Expires in six months March 1996 Site Security Handbook Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Table of Contents 1. Introduction.................................................... 2 1.1 Purpose of this Work............................................ 2 1.2 Audience........................................................ 2 1.3 Definitions..................................................... 3 1.4 Related Work.................................................... 3 1.5 Basic Approach.................................................. 3 1.6 Risk Assessment................................................. 4 2. Security Policies............................................... 5 2.1 What is a Computer Security Policy and Why Have One?............ 5 2.2 What Makes a Good Computer Security Policy?..................... 7 3. Architecture.................................................... 9 3.1 Objectives...................................................... 9 3.2 Network and Service Configurations.............................. 12 3.3 Firewalls....................................................... 16 4. Security Services and Procedures................................ 19 4.1 Authentication.................................................. 19 4.2 Confidentiality................................................. 22 4.3 Integrity....................................................... 22 4.4 Authorization................................................... 23 4.5 Access.......................................................... 23 4.6 Auditing........................................................ 27 4.7 Securing Backups................................................ 29 5. Security Incident Handling...................................... 29 5.1 Preparing and Planning for Incident Handling.................... 31 5.2 Notification and Points of Contact.............................. 33 5.3 Identifying an Incident......................................... 39 Site Security Handbook Working Group [Page 1] Internet Draft Site Security Handbook December 1995 5.4 Handling an Incident............................................ 41 5.5 Aftermath of an Incident........................................ 46 5.6 Responsibilities................................................ 47 6. Ongoing Activities.............................................. 48 Appendix A1 Tools and Locations..................................... 49 Appendix A2 Mailing Lists and Other Resources....................... 50 References........................................................... ? Annotated Bibliography............................................... ? 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, Nevil Brownlee, Joao Nuno Ferreira, Erik Gutmann, Klaus-Peter Kossakowski, Edward.P.Lewis, Gary Malkin, Russ Mundy, Philip J. Nesser, and Michael S. Ramsey. 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. 1.1 Purpose of this Work This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet. This guide lists issues and factors that a site must consider when setting their own policies. It makes some recommendations and 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 the 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 any technical security features that a site may be implementing. The primary audience for this work are sites that are members of the Internet community. However, this document should be useful to any site that allows communication with other sites. As a general guide to security policies, this document may also be useful to sites with Site Security Handbook Working Group [Page 2] Internet Draft Site Security Handbook December 1995 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, PC's or other devices that have access to the Internet. A site may be a end user of Internet services or a service provider such as a regional network. However, most of the focus of this guide is on those end users of Internet services. We assume that the site has the ability to set policies and procedures for itself with the concurrence and support from those who actually own the resources. The "Internet" is those set of networks and machines that use the TCP/IP protocol suite, connected through gateways, and sharing a common name and address spaces [1]. The term "system administrator" is used to cover all those who are responsible for the day-to-day operation of resources. This may be a number of individuals or an organization. The term "decision maker" refers to those people at a site who set or approve policy. These are often (but not always) the people who own the resources. 1.4 Related Work The IETF Guidelines for Security Incident Response Working Group (GRIP) is developing a document for security incident response teams. That document provides additional guidance to those organizations planning to develop their own incident response team (IRT), including a template that is useful to IRTs when descibing their policies and services. 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 this is suggested by Fites, et. al. [ref] 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 meansures 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 Site Security Handbook Working Group [Page 3] Internet Draft Site Security Handbook December 1995 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 recovering if the threat were to strike you. Without reasonable knowledge of what you are protecting and what the likely threats are, following this rule could be difficult. 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. Is is the process of examining all of your risks, and 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. [3, FITES] and [16, PFLEEGER] 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 or 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 [16, PFLEEGER, page 459]; this list is adapted from that source: (1) Hardware: cpus, boards, keyboards, terminals, workstations, personal computers, printers, disk drives, communication lines, terminal servers, routers. Site Security Handbook Working Group [Page 4] Internet Draft Site Security Handbook December 1995 (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, people needed to run systems. (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 assests. 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) Disclosure of information (3) Denial of service 2. SECURITY POLICIES 2.1 What is a Computer Security Policy and Why Have One? The security-related decisions you make, or fail to make, as network 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. 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 vs. security provided - Site Security Handbook Working Group [Page 5] Internet Draft Site Security Handbook December 1995 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 vs. security - The easiest system to use would allow acces 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 vs. 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 "computer security policy." 2.1.1 Definition of a Computer Security Policy A computer 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. 2.1.2 Purposes of a Computer Security Policy The main purpose of a computer 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 may and may 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 newsgroups. Site Security Handbook Working Group [Page 6] Internet Draft Site Security Handbook December 1995 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. 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) legal counsel (3) computing center personnel (4) network administrators of large user groups within the organization (e.g., business divisions, computer science department within a university, etc.) (5) security incident response team (6) representatives of the user groups affected by the security policy The list of 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 choices. In some organizations, it may be appropriate to include audit personel. Involving this group is important if resulting policy statements are to reach the broadest possible acceptance. 2.2 What Makes a Good Computer 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, staff, and administrators. 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 Site Security Handbook Working Group [Page 7] Internet Draft Site Security Handbook December 1995 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). (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) 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. (8) Supporting Information which provides users, staff, and management with contact information for each type of policy violation; guidelines how 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 regulatory requirements (federal, state, and local). 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 computer 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. 2.3 Keep the policy flexible Site Security Handbook Working Group [Page 8] Internet Draft Site Security Handbook December 1995 In order for a security policy to be viable for the long term, it requires a lot of flexibility. 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. 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 necessary to determine what the proper balance is for your site. 3. ARCHITECTURE 3.1 Objectives 3.1.1 Completely defined security plans Defining a comprehensive security plan should be done by all sites. This plan should be at a higher level than the specific policies discussed in section 2. 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 consistant with the overall site security architecture. For example, having a strong policy with regard to Internet access, but having weak restrictions on modem usage is inconsistent with an overall philosophy of strong security restrictions on external access. A security policy should contain, at a minimum: a list of services which are currently, or will forseably be, provided; who will have access to those services; how access will be provided; who will administer those services; etc. It is also imperative to define any limitations on which portions of an organization can provide services. Another aspect of the plan should concern incident handling. Chapter 5 provides an in-depth discussion of responses to incidents, but it is important to define classes of incidents and define responses to each class of incident. For sites with firewalls, how many attempts to foil the firewall will trigger a response? Are there levels of escallation in both attacks and responses? For sites without firewalls, does a single attempt to connect constitute an incident? Site Security Handbook Working Group [Page 9] Internet Draft Site Security Handbook December 1995 How about a systematic scan of machines? For sites connected to the Internet, the rampant media glorification of Internet related security incidents can overshadow a (potentially) more serious internal security problem. Likewise, companies who have never been on the Internet before, may have strong, well defined, internal policies but fail to adequately address 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 machines. 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 and smooth operation of a site would be better off being placed on a dedicated machine with very limited access restrictions (see Section 3.1.3 "deny all" model), rather than a machine which 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 machines which operate within different models of trust, say all the machines inside of a firewall, and any machines on an exposed network. Some of the services which should be examined for potential separation are outlined below. More specific information will be presented in section 3.3 (????). It is important to try to understand that vulnerability is only as strong as the weakest link in the chain. Several of the most publicized penetrations in recent years has been through the electronic mail systems of machines. The intruders were not trying to steal electronic mail, but they used the vulnerability in that system to gain access to other systems. If possible, each service should be running on a different machine whose only duty is to provide a specific service. This help isolate intruders and limit potential harm. 3.1.3 Deny all/ Allow all There are two diametrically oppossed underlying philosophies which can be adopted in defining a security plan. Both alternatives are legitimate models to adopt, depending 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, be it at the machine or network level, as they are needed. This model, which will here after be referred to as the "deny all" model, is generally more secure. Site Security Handbook Working Group [Page 10] Internet Draft Site Security Handbook December 1995 More work is required to successfully implement a "deny all" configuration and usually a better understanding of services; which may require several pieces operating together to function correctly. Only allowing known services allows 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 in general 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 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 M & M 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. 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 (ex. rpc and udp services), thus providing more openings to the internal network. Services provided on the same machine can interact in catastrophic ways. (ex. allowing anonymous ftp on the same machine as the www server may allow an intruder to Site Security Handbook Working Group [Page 11] Internet Draft Site Security Handbook December 1995 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 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 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. 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 Site Security Handbook Working Group [Page 12] Internet Draft Site Security Handbook December 1995 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 be 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 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 be terminated relatively simply. 3.2.3 Protecting the Services There are many types of services; 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) requires little protection. That is, protecting the server from external access is sufficient to protect the service. 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 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 machines and the external services to another set of server machines. That Site Security Handbook Working Group [Page 13] Internet Draft Site Security Handbook December 1995 is, internal and external servers should not be co-located. In fact, many sites go so far 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. 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 reroute traffic to subvert security protections. For examaple, 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 to act as secondary name servers and protect their DNS masters from denial of service attacks using filtering routers. 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 whch 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) Site Security Handbook Working Group [Page 14] Internet Draft Site Security Handbook December 1995 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 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 abilities to concentrate information services. Most WWW servers take some directions and actions 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 the server. In fact, it is recommended that the server have a dedicated host which is not "trusted" by other internal hosts. It may be co-located with an anonymous FTP server, since both protocols share common security considerations. 3.2.3.6 File Transfer (FTP, TFTP) FTP and TFTP allow users to receive and send electronic files in a point to point manner. Improperly configured FTP servers can allow intruders to copy, replace and delete files at will, anywhere on a host. TFTP does not support same range of functions, but has no security whatsoever. Access to encrypted passwords, proprietary data, and the introduction of trojan horses are just a few of the potential security holes. FTP and TFTP servers (especially Internet Site Security Handbook Working Group [Page 15] Internet Draft Site Security Handbook December 1995 accessable anonymous FTP servers) should reside on their own host. It may be co-located with a Web server, since file transfer protocols share common security considerations. 3.2.3.7 NFS The Network File Service allows hosts to share common disks. NFS is most 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. It is especially important that external hosts be unable to reach the NFS host by any means. Ideally, such access attempts would 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 of security versus ease of use, cost, complexity, etc. 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 or machines 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 companyUs network). A firewall is generally a way to build a wall between one part of a network, a companyUs 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 to establish the criteria by Site Security Handbook Working Group [Page 16] Internet Draft Site Security Handbook December 1995 which the packets are allowed or denied access through the door. Different 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, but in general are a combination of routers, networks, and host machines, so 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 *SHOULD* it 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. These criteria include: 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 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 (like Telnet, FTP,...) proxy servers can be used to allow access to the resources Site Security Handbook Working Group [Page 17] Internet Draft Site Security Handbook December 1995 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 machines 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 machines 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 for whatever reason not be able to take internal files and "put" them on a remote server. By contrast a filtering router could either block all FTP access or none but not a subset. 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 traveling, at trade shows and conferences, etc. Access to the Internet is usually available but may be through an untrusted machine or network. A correctly setup 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 TCP protocols. The internal routers 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. 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 Site Security Handbook Working Group [Page 18] Internet Draft Site Security Handbook December 1995 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, or 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,000 US and go up to over $250,000 US. "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. 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 canUt 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. These are presented in a fairly high-level to introduce the reader to the concepts. Throughout the chapter, you will find considerable mention of cryptography. It is outside the scope of this document to delve into details concerning cryptography and we point the reader to a small appendix on the subject. If you would like more details on this subject, please see [ref to Bruce Schnier sp?] 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) and hence the risk of disclosure of the clear text password was minimal. Today, systems are connected Site Security Handbook Working Group [Page 19] Internet Draft Site Security Handbook December 1995 together through local networks, and those local networks are further connected together, and to the Internet. Users are logging in from all over the globe, and 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. To address this threat, we are including sections on better technologies like one-time passwords, and Kerberos. 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. We are including a discussion on these since they are the foundation upon which stronger authentication techniques are based. If these secret tokens and pins are not properly selected and protected, the authentication will be easily subverted. 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). This document provides a list of sources for products that provide this capability. 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 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 singles 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 character, digits, and other characters. Site Security Handbook Working Group [Page 20] Internet Draft Site Security Handbook December 1995 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 and placed in the same location as the device to which they are associated. Others, such as a secret PGP key, should be protected from unauthorized access. One final word on this subject. When using a 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 current state of knowledge on the subject so that you can ensure any cryptography used will be providing you the protection you are assuming 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 have to transition to the use of better technology. Given that situation, we have included 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, and 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). (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 Site Security Handbook Working Group [Page 21] Internet Draft Site Security Handbook December 1995 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. It is recommended that passwords be changed whenever root is penetrated, there is a critical change in personnel (especially if it is the system administrator!), or when an account has been compromised. In particular, if the root password is compromised, all passwords on the system should be changed. In addition, an annual change in their password is usually not difficult for most users, and you should consider requiring it. 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 to protect valuable information. The use of encryption is sometimes controlled by govermental 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 you 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 Site Security Handbook Working Group [Page 22] Internet Draft Site Security Handbook December 1995 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 disgesting program MD5 [ref] to produce checksums you will be using to assure integrity. There are other applications when integrity will want to be assured, such as when transmitting an email message between two parties, and there are products available that can provide this capability. The purpose of this section is to acquaint you with this concept so that you can apply it where needed. 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 what occurs to identify a user. Once identified (reliably), the privileges, rights, property, and permissible actions of the user are determined by authorization. Explicity 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 - the super user, the owner, and the group. Super user, or root, is an entity that has access to all portions (and objects) of the computer. The owner of an object is the "user" who either created the object or was given it by the super user. A group is a collection of users that share privileges over a collection of objects. Groups ease authorization management by simplifying the process of changing the authorization of users and by changing the authority of a group to manage an object. 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. The advantage of these are that they are easily maintained (one central list per object). 4.5 Access 4.5.1 Physical Access Restrict physical access to areas containing hosts to people who are Site Security Handbook Working Group [Page 23] Internet Draft Site Security Handbook December 1995 supposed to use the hosts. Hosts include 'trusted' terminals (such as system consoles, operator terminals and terminals dedicated to special tasks such as backup) and individual microcomputers and workstations, especially those connected to your network. Make sure access restrictions mesh well with people's work patterns, 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. 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 sockets located so as 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 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 provide 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. Keep an eye on empty offices. It may be sensible to disconnect connections to unused offices at the wiring closet. 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! Site Security Handbook Working Group [Page 24] Internet Draft Site Security Handbook December 1995 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) on data links 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. Maintain a register of all your modem lines. Conduct regular site checks for unauthorized modems; keep your register up to date. 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 (such as choosing passwords which don't appear in dictionaries and changing them from time to time) are particularly important. 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-shot passwords (e.g. skey) or hardware authentication devices (e.g. SecurID) if this is 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 All logins (successful and unsuccessful) should be logged Don't keep correct passwords in the log, but consider keeping incorrect passwords to aid in detecting password attacks. However, bear in mind that most incorrect passwords are correct passwords with one character mistyped, and may suggest the real password. If you can't keep this information secure, don't log it at all. Site Security Handbook Working Group [Page 25] Internet Draft Site Security Handbook December 1995 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; use the data for informational purposes only, not for authentication. 4.5.4.4 Minimize the amount of information given in your opening banner In particular, don't announce the type of host hardware or operating system - this encourages specialist hackers. 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 all sessions are monitored, and a username/password prompt. Get your site's lawyers to check your banner to make sure it states your legal position correctly. For high-security applications, consider using a 'blind' password, i.e. give no response to an incoming call until the user has typed in (without any echoing) a password. This effectively simulates a dead modem. 4.5.4.5 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. You will probably have to pay the charges for such calls. This feature should be used with caution; it can easily be bypassed. As 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.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. As 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. 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. As a Site Security Handbook Working Group [Page 26] Internet Draft Site Security Handbook December 1995 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. 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 that may be useful in analyzing the security of a network and/or useful in responding to a security incident. This section also covers the handling, preservation, and utilization of the data. 4.6.1 What to collect Audit data should include any attempt to achieve a different security level of any person, process, or other entity in the network. The most obvious example in this area is a log of attempts to login to a host computer. Audit data should also include data pertaining to any "public" or anonymous access and retrieval of data, at least to the granularity of the "remote" host. 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. Reporting data can be done by writing to a file, writing to a line printer, writing over a network, or writing over a non-network port, such as a console port. Each of these has importance. File system logging is the least resource intensive of all four candidates (for a given audit log). It is also the least reliable. If a resource has been compromised, the file system is the first to go. If the network in front of the resource has become unusable, the data is inaccessible, unless a direct console port is 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. Site Security Handbook Working Group [Page 27] Internet Draft Site Security Handbook December 1995 A laser printer, or other device which buffers data between the auditing system and storage device may suffer from lost data if buffers contain the needed data at a critical instant. Reporting over the network provides for allowing a remote host to store data in a more permanent and possibly more reliable manner. However, this consumes bandwidth (at the minimum), exposes the audit data in an easy package to a interloper, and could be lost during network denial. Reporting over a console port ensures the delivery of the data follows the hardware design. The limitations are that the console port requires physical security and using console ports on machines more than a short distance away (e.g., across a campus) may require a phone line in addition to the network connection. In some instances, this is one more resource that may be constrained. 4.6.3 Collection Load Collecting running data may result in a quick accumulation of bytes. Storage of this must be considered in advance. There are a few ways to limit the required storage space. Data may be compressed using one of many methods. Another approach is to only archive summaries of activity (possibly losing some detail in the process). Data may be archived for just a fixed period of time, then is it permanently removed. The issue of archiving security data differs from archiving network management and application data. Network management data (statistics) can be reduced by altering the reporting period. Security data does not have that option (for the most part). Security data also does not have the permanence of application data. 4.6.4 Handling the Data/Preservation Security data should be protected as least as much as any other data is protected because from it, much can be inferred. Security data may give away enough secrets to allow a "masquerader" to impersonate an authorized administrator. Data may also become key to the investigation, apprehension, or prosecution of the perpetrator of an incident. Because of this, the data needs to be protected and clearly documented. For this reason it is advisable to seek the advice of local legal council or law enforcement when deciding how security data is to be treated. This should happen before an incident occurs. If a data handling plan is not cleared prior to an incident, this does not mean that it is useless. It means two things. You may not have recourse in the aftermath of an event. You may also me liable for penalties resulting from your treatment of the data too. 4.6.5 Audit Data Precautions Site Security Handbook Working Group [Page 28] Internet Draft Site Security Handbook December 1995 In certain instances, audit data may contain personal information. Searching through the data, even for just a routine check of the network's security could present an invasion of privacy or make the auditing entity privy to information it should not be allowed to have. Note that this is not automatically true - not all data is "sensitive" and "sensitive" differs by locale. Another danger presented by auditing data is that it may reveal a pattern of incidents. If an organization knows about the incidents but permits them to continue and this results in damage to another organization ("downstream"), legal action could result. An organization may also be liable for not (making a "best effort" to) analyze this data for incidents. 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 (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 when 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 check your backups. 5. SECURITY INCIDENT HANDLING This section of the document will supply guidance to be applied before, during, and after a computer security incident is in progress on a machine, network, site, or multi-site environment. The operative philosophy in the event of a breach of computer security is to react according 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 the attack once it 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 Site Security Handbook Working Group [Page 29] Internet Draft Site Security Handbook December 1995 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 for all sites that involved parties are 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 sued 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 damage to systems, or if the patches or workarounds themselves damage systems. Knowing about operating system vulnerabilities and patterns of attacks and then taking appropriate measures is critical to circumventing possible legal problems. This sections in this chapter provide an outline and starting point for creating your sites 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). (3) Evaluation (how serious is the incident). (4) Handling (what should be done when an incident occurs). - Notification (who should be notified about 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). - Legal/Investigative implications (what are the legal and prosecutorial implications of the incident). - Documentation Logs (what records should be kept from before, during, and after the incident). (5) Aftermath (what are the implications of past incidents). (6) Responsibilities (how to handle an incident responsibly). Each of these subjects is important in an overall plan for handling incidents. The remainder of this chapter will detail the issues involved in each of the relevant topics, and provide some guidance as Site Security Handbook Working Group [Page 30] Internet Draft Site Security Handbook December 1995 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 chapters before. 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. 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) taking care that (government or other) regulations are complied with (4) preventing the use of your systems in attacks against other systems (which could incur legal liability) (5) minimizing the potential for negative exposure As in any set of pre-planned procedures, attention must be placed on 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) Recover from the incident. (5) Find out who did it. Due to the nature of the incident there might be a conflict between analyzing the original source of a problem instead of restoring systems and services. In this case overall goals (like assuring the integrity of (life) 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 a analysis the same incident may happen again. It is important to prioritize 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 Site Security Handbook Working Group [Page 31] Internet Draft Site Security Handbook December 1995 will vary from institution to institution, the following suggested priorities may serve as a starting point for defining an 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 effected 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 effected 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; it is better in many cases to shut a system down or disconnect from a network than to risk damage to data or systems. 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; the loss or compromise of data (especially classified data), however, 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 effected 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 uncertainty 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. 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 Site Security Handbook Working Group [Page 32] Internet Draft Site Security Handbook December 1995 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. 5.2 Notification and Point of Contacts It is important to establish contacts with various personnel before a real incident occurs. These contacts are either local, other system responsible or administrative contacts administrators elsewhere on the Internet or are investigative agencies. Working with these contacts appropriately will help to make your incident handling process more efficient. Communication may need to be established with various "Points of Contact." These may be technical or administrative in nature, may include legal or investigative agencies, as well as Service Providers and vendors. It is important to decide how much information will be shared, especially with the wider community of users at a site, with the public (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. Including relevant telephone numbers (also electronic mail addresses and fax numbers) in the site security policy is strongly recommended. It is especially important to know how to contact individuals who will be directly involved in handling a security incident. 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 "points of contact" (POC) that are not pulling their efforts together. This will only add to the confusion of the event, and will probably lead to wasted or ineffective effort. The single point of contact may or may not be the person "in charge" of the incident. There are two distinct roles to fill when deciding who shall be the point of contact and the person in charge of the incident. The person in charge will make decisions as to the interpretation of policy applied to the event. The responsibility for the handling of the event falls onto this person. In contrast, the point of contact must coordinate the effort of all the parties involved with handling the event. The point of contact must be a person with the technical expertise to successfully coordinate the effort of the system managers and users Site Security Handbook Working Group [Page 33] Internet Draft Site Security Handbook December 1995 involved in monitoring and reacting to the attack. Often the management structure of a site is such that the administrator of a set of resources is not a technically competent person with regard to handling the details of the operations of the computers, but is ultimately responsible for the use of these resources. Another important function of the POC is to maintain contact with law enforcement and other external agencies to assure that multi- agency involvement occurs. (In the U.S. FBI, CIA, DoD, U.S. Army, or others might be concerned.) Finally, if legal action in the form of prosecution is involved, the POC may be asked to speak for the site in court. The alternative is to have multiple witnesses that will be hard to coordinate in a legal sense, and will weaken any case against the attackers. A single POC may also be the single person in charge of collecting evidence, which will keep the number of people accounting for evidence to a minimum. 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. One of the most critical tasks for the POC is the coordination of all relevant processes. As responsibilities might be distributed over the whole site, which may well consist of multiple independent departments or groups, a well coordinate effort is crucial for overall success. The situation get even worse if multiple sites are involved. In many cases, no single POC in one site can coordinate the handling of an entire incident. The appropriate incident response teams are more suitable, if multiple sites are involved. The incident handling process should provide some escalation mechanisms. The POC might change; the impact of the incident force the management to take the lead instead of giving the technical administrator the responsibility. Other reasons for changing the POC are the emergence of conflicts of interest, changing priorities or responsibilities. Regardless of why the POC is changed, all involved parties must be informed. Arrangements should be made to allow the new POC to contact the old one, to ensure an adequate briefing of background information. 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 such as the FBI and Secret Service or their equivalent in your country, as soon as possible. Local law enforcement and local security offices or campus police departments should also be informed as appropriate. A primary reason 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 Site Security Handbook Working Group [Page 34] Internet Draft Site Security Handbook December 1995 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 a court of law, requiring 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 will make responding to an incident go considerably more smoothly. 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 lots of effort. On the other side, 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 anyone. The balance between supporting investigative activity and limiting liability is tricky; you'll need to consider the advice of your Site Security Handbook Working Group [Page 35] Internet Draft Site Security Handbook December 1995 council and the damage the intruder is causing (if any) in making your decision about what to do during any particular incident. 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. A similar consideration is using a secure means of communication. Because many network attackers can easily reroute 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 established set of rules for responding to an incident when the local Government becomes involved. Normally, except by court order, no agency can force you to monitor, to disconnect from the network, to avoid telephone contact with the suspected attackers, etc. As discussed before, you should consult the matter with your legal counsel, especially before taking an action that your organization has never taken. The particular agency involved may ask you to leave an attacked machine on and to monitor activity. Complying with this request will ensure continued cooperation of the agency. This is usually the best route towards finding the source of the network attacks and, ultimately, terminating these attacks. Additionally, you may need information or a favor from the agency involved. You are likely to get what you need only if you have been cooperative. It is particularly important to avoid unnecessary or unauthorized disclosure of information about the incident, including any information furnished by the agency involved: Don't compromise the case the agency is trying to build. If you do not cooperate with an agency, you will be less likely to receive help in the future. Site Security Handbook Working Group [Page 36] Internet Draft Site Security Handbook December 1995 Sometimes your needs and the needs of an investigative agency will differ. Your site may want to get back to normal business by closing an attack route, but the investigative agency may want you to keep this route open. Similarly, your site may want to close a compromised system down to avoid the possibility of negative publicity, but again the investigative agency may want you to continue monitoring. When there is such a conflict, there may be a complex set of tradeoffs (e.g., interests of your site's management, amount of resources you can devote to the problem, jurisdictional boundaries, etc.). An important guiding principle is related to what might be called "Internet citizenship" [22, IAB89, 23 (xxx old references)] and its responsibilities. See section 5.6. 5.2.3 Computer Security Incident Handling Teams There now exists a number of Computer Security Incident Handling teams (CSIH teams) such as the CERT Coordination Center and the CIAC or other teams around the globe. Teams exist for many major government agencies and large corporations. If such a team is available, notifying it should be of primary importance 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 closing out the incident. If it is determined that the breach occurred due to a flaw in the systems' 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 due to the fact that many other systems are vulnerable, too. 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. (See [RFC xxx] for more information about the considerations for creating your own incident handling team.) 5.2.4 Effected 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 might choose to contact other sites directly or they can pass the information to an appropriate incident response team, to which the involved site belongs. As it is often very difficult to find the responsible POC at remote sites, the involvement of an incident response team will facilitate contact by making use of Site Security Handbook Working Group [Page 37] Internet Draft Site Security Handbook December 1995 already established channels. The legal and liability issues arising from a security incident may 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. This policy should be crafted in consultation with legal counsel. Information about specific people is especially sensitive, and is 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 would like to read in the newspaper that they also had a problem.) Incident response teams are valuable in this respect. As 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 should be not seen 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 measures against intruders. 5.2.5 Public Relations - Press Releases 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 Site Security Handbook Working Group [Page 38] Internet Draft Site Security Handbook December 1995 information about the incident may provide enough information for copy-cat events or even damage the site's ability to prosecute 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. 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 which deserve special attention: (1) System crashes. (2) New user accounts (the account RUMPLESTILTSKIN has unexplainedly been created), or high activity on an (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 Site Security Handbook Working Group [Page 39] Internet Draft Site Security Handbook December 1995 /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). (12) Suspicious browsing (someone becomes a root user on a UNIX system and accesses file after file many user accounts.) 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 effected 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 into some of the insight as to the nature of the incident, and aid investigation and prosecution. As soon as the breach has occurred, the entire system and all its components should be considered suspect. System software is the most probable target. Preparation is key to be able to detect all changes Site Security Handbook Working Group [Page 40] Internet Draft Site Security Handbook December 1995 for a possibly tainted system. This includes checksumming all tapes from the vendor using a checksum algorithm which (hopefully) is resistant to tampering [10]. (See sections xxx 4.7?) Assuming original vendor distribution tapes 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 backup tapes are showing a correct system status; consider that the incident may have continued for months or years before discovery, and that 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: One should have policies in place. Without defined 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 effected 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 system administrators take the discovery of an intruder as personal challenge. By proceeding this way, other objectives as outlined in the local policies may not always 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 continued access. 5.4.1 Types of notification, 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 in 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 Site Security Handbook Working Group [Page 41] Internet Draft Site Security Handbook December 1995 be taken 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. 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. netnews, mailing lists) may potentially put a great number of systems at risk of intrusion. It is invalid to assume that all administrators are reading a particular news group 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, or fax) provides information about the incident that is clear, concise and fully qualified. When you are notifying others that will help you to 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 expectations of damage and negative outcomes of the incident. It is important to remain calm both in written and spoken notifications. Another aspect of the choice of language used 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. Cultural differences do not only exist between countries like Germany and Australia. They even exist within countries between different social groups or user groups. 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 will follow his procedures and consider the same action as a possible attack. 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 undue alarm or confusing messages. 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 notifications Site Security Handbook Working Group [Page 42] Internet Draft Site Security Handbook December 1995 cannot be underestimated and may make the difference between handling the incident properly and escalating to some higher level of damage. If an IRT 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 which the local administrator is unaware of. 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 user ids) (3) all log entries relevant for the remote site (4) type of incident (what happened, why should you care) If local information (ie. local user ids) is included in the log entries, it might 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 Protection of 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 good portion of information you obtain, requiring you to contact the source of information once again. At the same time, recording details will provide evidence for prosecution efforts, providing the case moves in this direction. Documenting an incident also will 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." 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 phone 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 Site Security Handbook Working Group [Page 43] Internet Draft Site Security Handbook December 1995 page through individual sheets of paper. Much of this information is potential evidence in a court of law. Thus, when you initially suspect that an incident will result in prosecution or when an investigative agency becomes involved, you need to: (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 in return 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 (i.e., 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 on a UNIX system, etc.). Sometimes this decision is trivial; shut the system down if the system is life critical, classified or sensitive, or if proprietary information is at risk! 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 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 without the possibility to contact all involved parties and discuss the decision. In most of the cases the person in charge will have not the power to make a difficult management decision (like to loss the results of a costly experiment). Finally, notification of cognizant authorities should occur during this stage. 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 and the cause of the incident as they will likely be lost when Site Security Handbook Working Group [Page 44] Internet Draft Site Security Handbook December 1995 cleaning up the system. Software may be available to help you in the eradication process, such as anti-virus software for small systems. 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 disks 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, too. 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 distributed tapes and re customize the system. To facilitate this worst case scenario, a record of the original systems setup and each customization change should be kept current with each change to the system. In the case of a network-based attack, it is important to install patches for any operating system vulnerability which was exploited. 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 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 Site Security Handbook Working Group [Page 45] Internet Draft Site Security Handbook December 1995 to utilize some of the tools mentioned in section xxx (e.g., xxx) 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. 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 in terms of any loss of software and files, 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 Site Security Handbook Working Group [Page 46] Internet Draft Site Security Handbook December 1995 changing computing environments. The whole purpose of this "post mortem" process is to improve all security measures to protect the site against future attacks. In the light of an incident one should gather practical knowledge from the experience. A concrete goal is developing proactive methods, for example: early warning by probes. Another important facet of the aftermath may be end user and administrator education to prevent a reoccurrence of a security problem. 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 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 Site Security Handbook Working Group [Page 47] Internet Draft Site Security Handbook December 1995 not be appropriate for a use 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 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 the case. 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. You will 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 [ref], 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. Then investigate all anomalies. (4) Review all security policies and procedures annually (at a minimum) (5) Read appropriate mailing lists and Netnews groups to keep up to date with the latest information being shared by fellow administrators. APPENDICES A1 Tools and Locations This section provides a brief overview 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. This section is divided into two major subsections, applications and tools. The applications heading will include all end user programs (clients) and their supporting system infrastructure (servers). The tools heading will deal with the tools that a general user will never see or need to use, but which may be part of or used by applications, used to troubleshoot security problems or guard against intruders by system and network administrators. Site Security Handbook Working Group [Page 48] Internet Draft Site Security Handbook December 1995 The emphasis will be on UNIX applications and tools, but other platforms, particularly PC's and Macintoshes, will be mentioned where information is available. Most of the tools and applications described below can be found in one of the following two 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 Any references to CERT or COAST will refer to these two locations. These two sites act as repositories for most tools, exceptions will be noted in the text. *** 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 whatever verification tools possible, checksums, md5 checksums, etc... to validate that software. A clever cracker might advertise security software with designed flaws in order to gain access to data or machines. *** Applications The sad truth is that there are very few security conscious applications currently available. The real reason is the need for a security infrastructure which must be first put into place for most applications to operate securely. There is considerable effort currently taking place to place this infrastructure so that applications can take advantage of secure communications. Unix based applications PGP MD5 S/KEY TROJAN.PL PEM KERBEROS Drawbridge Tripwire logdaemon TCP-Wrapper rpcbind/portmapper replacement cops tiger ISS SATAN smrsh swatch identd (not really a security tool) DES (non-US versions) Site Security Handbook Working Group [Page 49] Internet Draft Site Security Handbook December 1995 lsof sfingerd passwd-replacements (npasswd / ANLpasswd / passwd+ / ...) A2 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) resouces can be found through these references. Mailing Lists (1) CERT Advisory Send mail to: cert-advisory-request@cert.org Message Body: subscribe cert FIRSTNAME LASTNAME 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) CERT Tools Mailing List Send mail to: cert-tools-request@cert.sei.cmu.edu Message Body: subscribe cert-tools FIRSTNAME LASTNAME The purpose of this moderated mailing list is to encourage the exchange of information on security tools and techniques. The list should not be used for security problem reports. (3) 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. Site Security Handbook Working Group [Page 50] Internet Draft Site Security Handbook December 1995 (4) Academic 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. (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 Site Security Handbook Working Group [Page 51] Internet Draft Site Security Handbook December 1995 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. 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 Site Security Handbook Working Group [Page 52]