[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 rfc2196                                        
Internet Draft                                             Barbara Fraser
Network Working Group                                             SEI/CMU
Expires in six months                                       December 1995


                         Site Security Handbook
                    <draft-ietf-ssh-handbook-01.txt>

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
2.   Security Policies...............................................  3
2.1  What is a Computer Security Policy and Why Have One?............  3
2.2  What Makes a Good Computer Security Policy?.....................  5
3.   Architecture....................................................  6
3.1  Objectives......................................................  6
3.2  Network and Service Configurations.............................. 10
3.4  Firewalls....................................................... 13
4.   Security Procedures............................................. 13
4.1  Authentication.................................................. 13
4.2  Authorization................................................... 15
4.3  Access.......................................................... 16
4.4  Modems.......................................................... 16
4.5  Cryptography.................................................... 18
4.6  Auditing........................................................ 18
4.7  Backups......................................................... 20
5.   Security Incident Handling...................................... 20
5.1  Preparing and Planning for Incident Handling.................... 22
5.2  Notification and Points of Contact.............................. 24
5.3  Identifying an Incident......................................... 31
5.4  Handling an Incident............................................ 33
5.5  Aftermath of an Incident........................................ 38



Site Security Handbook Working Group                            [Page 1]


Internet Draft           Site Security Handbook            November 1995


5.6  Responsibilities................................................ 39
6.   Maintenance and Evaluation...................................... 40
6.1  Risk Assessments................................................ 40
6.2  Notification of Problems and Events............................. 40
Appendix A1  Tools and Locations..................................... 40
Appendix A2  Mailing Lists and Other Resources....................... 41
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, 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 administrators and decision
   makers (who are more traditionally called "administrators" or "middle
   management") at sites.  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
   isolated systems.




Site Security Handbook Working Group                            [Page 2]


Internet Draft           Site Security Handbook            November 1995


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.

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



Site Security Handbook Working Group                            [Page 3]


Internet Draft           Site Security Handbook            November 1995


   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 -
        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.

2.1.3  Who Should be Involved When Forming Policy?

   In order for a security policy to be appropriate and effective, it



Site Security Handbook Working Group                            [Page 4]


Internet Draft           Site Security Handbook            November 1995


   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)  local or national 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.  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
        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



Site Security Handbook Working Group                            [Page 5]


Internet Draft           Site Security Handbook            November 1995


        (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.

3.  ARCHITECTURE

3.1 Objectives

3.1.1 Completely defined security plans




Site Security Handbook Working Group                            [Page 6]


Internet Draft           Site Security Handbook            November 1995


   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?
   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



Site Security Handbook Working Group                            [Page 7]


Internet Draft           Site Security Handbook            November 1995


   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.2.1 Name Servers (DNS and NIS(+))

   The Internet uses the Domain Name System (DNS) to perform name to
   address resolution.  The Network Information Service (NIS) and NIS+
   are not used on the global Internet but are subject to the same risks
   internally 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 route traffic to
   quickly subvert numerous security guards.  Routine traffic can be
   diverted to a compromised system and traffic can be monitored or
   users can trivially be tricked into offering authentication secrets.
   An organization would do well to arrange well known and protected
   sites to act as secondary name servers, and also protect their own
   DNS masters from denial of service attacks using filtering routers.

3.1.2.2 Password/Key Servers (NIS(+) and KDC)

   Machines used for password or key servers protect some of the most
   valuable information to a potential intruder, the encrypted passwords
   and/or keys, which can be used to access the site.  Since many
   current schemes of encryption are either subject to dictionary or
   brute force attacks, every effort must be made to secure these
   machines.

3.1.2.3 Authentication/Proxy Servers (SOCKS, FWTK)

   The use of proxy servers as a security technique will only continue
   to expand.  A proxy server provides a number of security
   enhancements.  It allows sites to concentrate services through a
   specific machine for monitoring, hiding of internal structure, etc.
   This funnelling effect creates an attractive target for a potential
   intruder.

3.1.2.4 Email

   Electronic mail systems have traditionally been one source for
   intruder break-ins.  Most email servers typically accept input from
   any source.  Most email systems consist of two parts, a
   receiving/sending agent and a processing agent.  Since email is



Site Security Handbook Working Group                            [Page 8]


Internet Draft           Site Security Handbook            November 1995


   delivered to all users and is usually private, the processing agent
   typically requires system privileges to deliver the mail.  Most email
   implementations perform both portions of the service, which means the
   receiving agent has a direct link to system privileges.  There are
   several packages available which allow a separation of the two
   pieces.

3.1.2.5 World Wide Web (WWW)

   The WWW 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.  Those programs
   can be subverted easily if they are not written with security in
   mind.

3.1.2.6 FTP

   FTP allows users to receive and send electronic files in a point to
   point manner.  Improperly configured ftp servers can allow intruders
   to copy or replace files at will from throughout a system.  Access to
   encrypted passwords, proprietary data, or the introduction of trojan
   horses are just a few of the possibilities.

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.
   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



Site Security Handbook Working Group                            [Page 9]


Internet Draft           Site Security Handbook            November 1995


   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
   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



Site Security Handbook Working Group                           [Page 10]


Internet Draft           Site Security Handbook            November 1995


   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
   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



Site Security Handbook Working Group                           [Page 11]


Internet Draft           Site Security Handbook            November 1995


   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
   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.



Site Security Handbook Working Group                           [Page 12]


Internet Draft           Site Security Handbook            November 1995


   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

4.  SECURITY PROCEDURES

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 cleartext password was minimal.  Today, systems are connected
   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 cleartext, ripe for anyone
   inbetween 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 cleartext
   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 cleartext 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



Site Security Handbook Working Group                           [Page 13]


Internet Draft           Site Security Handbook            November 1995


   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

   <insert info about this technology here>

4.1.3  Choosing and Protecting Secret Tokens and Pins

   <to be filled in>

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



Site Security Handbook Working Group                           [Page 14]


Internet Draft           Site Security Handbook            November 1995


        a password should not be maintained once an account is no longer in use,
        but it is hotly debated whether a user should be forced to change a
        good password that's in active use.  The arguments for changing
        passwords relate to the prevention of the continued use of penetrated
        accounts.  However, the opposition claims that frequent password changes
        lead to users writing down their passwords in visible areas (such as
        pasting them to a terminal), or to users selecting very simple passwords
        that are easy to guess.  It should also be stated that an intruder will
        probably use a captured or guessed password sooner rather than later,
        in which case password aging provides little if any protection.

        While there is no definitive answer to this dilemma, a password policy
        should directly address the issue and provide guidelines for how often
        a user should change the password.  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  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.

   Should "objects" and "entities" be defined here?> 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).

   <NOTE: What other methods (short phrases are all that's needed, I
   probably know what they refer to) should be mentioned... >




Site Security Handbook Working Group                           [Page 15]


Internet Draft           Site Security Handbook            November 1995


   <NOTE: Should the process of deciding what authorizations are to be
   granted be described here (or is that in policies)?  Should
   mechanisms be described here? >

4.3 Access

4.4 Modems

4.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.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. SecureID) 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.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 16]


Internet Draft           Site Security Handbook            November 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 Lne Identification.  Also be
   aware that Calling Line Identification is not to be trusted; use the
   data for informational purposes only, not for authentication. <NOTE:
   it was suggested that we add " Caller ID data can be read from a
   compatible modem via a serial line" >

4.4.5  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.4.6  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.4.7  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.4.8  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 17]


Internet Draft           Site Security Handbook            November 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.5  Cryptography

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.

   (This will be reworked as I develop the remainder.)

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.

   And on and on...

   <NOTE: I'd appreciate suggested logs items (and what level of detail
   is
    intended). >

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.



Site Security Handbook Working Group                           [Page 18]


Internet Draft           Site Security Handbook            November 1995


   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.
   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



Site Security Handbook Working Group                           [Page 19]


Internet Draft           Site Security Handbook            November 1995


   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

   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  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
   described above should be addressed by an adequate contingency plans.
   Without a proactive approach to protect the assets in case of an
   incident the handling process can not be as efficient as with well
   prepared procedures, methods and policies in place.

   Traditional computer security, while quite important in the overall
   site security plan, usually falls heavily on protecting systems from
   attack, and perhaps monitoring systems to detect attacks.  Little
   attention is usually paid for how to actually handle the attack when
   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 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 benefit for efficient
   incident handling is an economic one.  Having both technical and
   managerial personnel respond to an incident requires considerable
   resources, resources which could be utilized more profitably if an



Site Security Handbook Working Group                           [Page 20]


Internet Draft           Site Security Handbook            November 1995


   incident did not require their services.  If these personnel are
   trained to handle an incident efficiently, less of their time is
   required to deal with that incident.

   Due to the worldwide network most of the incidents are not restricted
   to one site only.  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 all 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 chapter is arranged such that a list of relevant topics may be
   drawn from the following outline, to provide a starting point for
   creating a policy for handling ongoing incidents.  The main points to
   be included in a policy for handling incidents are:

   (1)  Preparing and planning (what are the goals and objectives in
        handling an incident).
   (2)  Notification (who should be contacted in case of an incident).
   (3)  Evaluation (how serious is the incident).
   (4)  Handling (what should be done when an incident occurs).
        This especially includes:
        - Notification (who should be notified about the incident).
        - Containment (how can the damage be limited).
        - Eradication (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 (overall implications of past incidents).
   (6)  Responsibilities (for planning and handling an incident).

   Each of these points 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
   to what should be included in a site policy for handling incidents.

   Guidelines for End User involvement in dealing with compromised



Site Security Handbook Working Group                           [Page 21]


Internet Draft           Site Security Handbook            November 1995


   accounts and vulnerabilities are covered in the corresponding "End
   User Security Handbook" [RFC xxx]. Especially interesting for Site
   Administrators which act as Site Security Contact in assisting other
   users and administrators in dealing with incidents are the
   "Guidelines and Recommendations for Incident Processing" [RFC xxx].

5.1  Preparing and Planning for Incident Handling

   Part of handling an incident is being prepared to respond before the
   incident occurs.  This includes establishing a suitable level of
   protections as explained in the chapters before.  Not only are
   incidents avoided through this protection but if the incident becomes
   severe, the damage which can occur is limited.  Protection 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.  As explained for the
   site specific contingency plan in section xxx it is vitally important
   to test the proposed plan before an incident actually occurs through
   'dry runs'. A team might even consider hiring a tiger team to act in
   parallel with the dry run.

   Once a site has recovered from an incident, site policy and
   procedures should be reviewed to encompass changes to prevent similar
   incidents.  If an incident is based on poor policy, and unless the
   policy is changed, then one is doomed to repeat the past.  Even
   without an incident, it would be prudent to review policies and
   procedures on a regular basis.  Reviews are imperative due to today's
   changing computing environments.  To improve this process a problem
   reporting procedure should be implemented to describe, in detail, the
   incident and the solutions to the incident.  Each incident should be
   reviewed by the site security subgroup to allow understanding of the
   incident with possible suggestions to the site policy and procedures.

   Learning to respond efficiently to an incident is important for
   numerous reasons:

   (1)  protect the assets which are to protect by normal security
        in case of a worst event
   (2)  protect your resources which could be utilized more profitably
        if an incident did not require their services
   (3)  take care that (government) regulations are complied with
   (4)  prevent use of your systems against other systems (which
        could incur legal liability)
   (5)  minimize 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.  The set of goals will
   be closely related to the goals for security in general.  Therefore,
   the same guidelines as in section xxx for security in general might
   be applied here.  A specific set of objectives can be identified for
   dealing with incidents:




Site Security Handbook Working Group                           [Page 22]


Internet Draft           Site Security Handbook            November 1995


   (1)  Figure out how it happened.
   (2)  Find out how to avoid further exploitations.
   (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
   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



Site Security Handbook Working Group                           [Page 23]


Internet Draft           Site Security Handbook            November 1995


   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 at 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
   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.

   You may also note that if any legal action is planned, there are
   specific guidelines that must be followed to make sure that any
   information collected can be used as evidence.

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
   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.



Site Security Handbook Working Group                           [Page 24]


Internet Draft           Site Security Handbook            November 1995


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 rolls 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
   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 in fact can consist of multiple independent
   departments or groups, a well coordination effort is crucial for
   overall success.  The situation get even worse if multiple sites are
   involved.  In many cases, no single POC in one nvolved 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



Site Security Handbook Working Group                           [Page 25]


Internet Draft           Site Security Handbook            November 1995


   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 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 when appropriate.  A primary reason is that
   once a major attack is in progress, there is little time to call
   various personnel in these agencies to determine exactly who the
   correct point of contact is.  Another reason is that it is important
   to cooperate with these agencies in a manner that will foster a good
   working relationship, and that will be in accordance with the working
   procedures of these agencies.  Knowing the working procedures in
   advance and the expectations of your point of contact is a big step
   in this direction.  For example, it is important to gather evidence
   that will be admissible in a court of law.  If you don't know in
   advance how to gather admissible evidence, your efforts to collect
   evidence during an incident are likely to be of no value to the
   investigative agency with which you deal.  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



Site Security Handbook Working Group                           [Page 26]


Internet Draft           Site Security Handbook            November 1995


        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
   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.

   One of the most important considerations in dealing with
   investigative agencies is verifying 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 information about incidents, allowed
   unauthorized people into their systems, etc., because a caller has
   masqueraded as a representative of a government agency (e. g. the FBI
   or Secret Service in the US).  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 (e. g., the phones
   normally used in the business world) are also frequent targets for
   tapping by network intruders, so be careful!



Site Security Handbook Working Group                           [Page 27]


Internet Draft           Site Security Handbook            November 1995


   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 on this
   machine, for example.  Your 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 in the incident.  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.  The trust between your
   site and the agency hinges upon your ability to avoid compromising
   the case the agency will build; keeping "tight lipped" is imperative.

   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.  Your site can shut a system
   down, and this will relieve you of the stress, resource demands, and
   danger of negative exposure.  The attacker, however, is likely to
   simply move on to another system, temporarily leaving others blind to
   the attacker's intention and actions until another path of attack can
   be detected.  Providing that there is no damage to your systems and
   others, the most responsible course of action is to cooperate with
   the participating agency by leaving your compromised system on.  This
   will allow monitoring (and, ultimately, the possibility of
   terminating the source of the threat to systems just like yours).  On
   the other hand, if there is damage to computers illegally accessed
   through your system, the choice is complicated: shutting down the
   intruder may prevent further damage to systems, but might make it
   impossible to track down the intruder.  If there has been damage, the
   decision about whether it is important to leave systems up to catch
   the intruder should involve all the organizations effected.  Further
   complicating the issue of network responsibility is the consideration
   that if you do not cooperate with an agency, you will be less likely
   to receive help from that agency in the future.

5.2.3  Computer Security Incident Handling Teams

   There now exists a number of Computer Security Incident Handling



Site Security Handbook Working Group                           [Page 28]


Internet Draft           Site Security Handbook            November 1995


   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
   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, irrelevent
   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



Site Security Handbook Working Group                           [Page 29]


Internet Draft           Site Security Handbook            November 1995


   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.  As a contrast to this
   consideration, it was discussed above that misleading the press can
   often backfire and cause more damage than releasing sensitive
   information.

   While it is difficult to determine in advance what level of detail to
   provide to the press, some guidelines to keep in mind are:

   (1)  Keep the technical level of detail low.  Detailed
        information about the incident may provide enough
        information for 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 "2am"
        interview, where the hope is to catch the interviewee off



Site Security Handbook Working Group                           [Page 30]


Internet Draft           Site Security Handbook            November 1995


        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 exist.  Of
   course many, if not most, signs often associated with virus
   infections, 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.  For example, widely available
   software packages can greatly assist someone who thinks there may be
   a virus in a personal computer.  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 do more
   good in identifying the problem and any source of attack than most
   other actions which can be taken at this stage.  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 (e.g., the account RUMPLESTILTSKIN
        has unexplainedly been created), or high activity on
        an account that has had virtually no activity for
        months.
   (3)  New files (usually with novel or strange file names,
        such as data.xx or k).
   (4)  Accounting discrepancies (e.g., in a UNIX system you
        might notice that the accounting file called
        /usr/admin/lastlog has shrunk, something that should
        make you very suspicious that there may be an
        intruder).
   (5)  Changes in file lengths or dates (e.g., a user should
        be suspicious if he/she observes that the .EXE files in
        an MS DOS computer have unexplainedly grown
        by over 1800 bytes).
   (6)  Attempts to write to system (e.g., a system manager
        notices that a privileged user in a VMS system is
        attempting to alter RIGHTSLIST.DAT).
   (7)  Data modification or deletion (e.g., files start to
        disappear).
   (8)  Denial of service (e.g., a system manager and all



Site Security Handbook Working Group                           [Page 31]


Internet Draft           Site Security Handbook            November 1995


        other users become locked out of a UNIX system, which
        has been changed to single user mode).
   (9)  Unexplained, poor system performance (e.g., system
        response time becomes unusually slow).
   (10) Anomalies (e.g., "GOTCHA" is displayed on a display
        terminal or there are frequent unexplained "beeps").
   (11) Suspicious probes (e.g., there are numerous
        unsuccessful login attempts from another node).
   (12) Suspicious browsing (e.g., someone becomes a root user
        on a UNIX system and accesses file after file in one
        user's account, then another's).

   By no means is this list comprehensive. We have just listed a number
   of common indicators.  Furthermore, none of these indications is
   absolute "proof" that an incident is occurring, nor are all of these
   indications normally observed when an incident occurs.  If you
   observe any of these indications, however, it is important to suspect
   that an incident might be occurring, and act accordingly.  There is
   no formula for determining with 100 percent accuracy that an incident
   is occurring.  It is best at this point 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.  In addition, the impact of an incident will determine its
   priority in allocating resources to deal with the event.  Without an
   indication of the scope and impact of the event, it is difficult to
   determine a correct response.

   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 are:

   (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?

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.




Site Security Handbook Working Group                           [Page 32]


Internet Draft           Site Security Handbook            November 1995


   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
   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.) 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.

   If you can address all aspects of a specific incident strongly
   depends on the success of this analysis.  This also effects the
   efficiency of the incident handling process.  Review the lessons
   learned from the analysis and always update the policy and procedures
   to reflect changes necessitated by the incident.

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. 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.  One other pitfall is the premise that by monitoring the
   activities of a hacker, other sites can be warned about problems they
   have been exposed to.   By allowing the intruder to (ab)use the local
   system, a site may be incurring legal liability or indirect
   responsibility for the damage caused to other sites.

   For all the reasons outlined above, it is necessary to establish
   procedures for the incident handling to allow the technical



Site Security Handbook Working Group                           [Page 33]


Internet Draft           Site Security Handbook            November 1995


   administrator to do the "right" thing, as identified by management
   and legal counsel.


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
   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 a wrong
   assumption, that all administrators are reading a particular news
   group, have access to operating system source code or can even
   understand the techniques 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 section 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 other
   information that would help them resolve a 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.  This is especially true when the press is involved.  When
   an incident severe enough to gain press attention is ongoing, it is
   likely that any false information you provide will not be
   substantiated by other sources.  This will reflect badly on the site
   and may create enough ill-will between the site and the press to
   damage the site's public relations.

   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.



Site Security Handbook Working Group                           [Page 34]


Internet Draft           Site Security Handbook            November 1995


   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
   cannot be underestimated and may make the difference between handling
   the incident properly and escalating to some higher level of damage.

   If a 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

   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.  This wastes yours and others'
   time, something you can ill afford.  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



Site Security Handbook Working Group                           [Page 35]


Internet Draft           Site Security Handbook            November 1995


   provide the basis for a follow-up analysis in which you can engage in
   a valuable "lessons learned" exercise.  Additionally it will help
   during later phases of the handling process, especially during the
   eradiction and recovery.

   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
   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 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 who can store these copied pages in a secure place (e.g., a
   safe).  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.  For
   example, it is important to limit the spread of a worm attack on a
   network as quickly as possible.  An essential part of containment is
   decision making (i.e., determining whether to shut a system down, to
   disconnect from a network, to monitor system or network activity, to
   set traps, to 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!  In other cases, it is
   worthwhile to risk having 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



Site Security Handbook Working Group                           [Page 36]


Internet Draft           Site Security Handbook            November 1995


   experiment).  Finally, notification of cognizant authorities should
   occur during this stage.

   In some cases, it is prudent to remove all access or functionality as
   soon as possible, and then restore normal operation in limited
   stages.  Bear in mind that removing all access while an incident is
   in progress will obviously notify all users, including the alleged
   problem users, that the administrators are aware of a problem; this
   may have a deleterious effect on an investigation.


5.4.4  Eradication

   Once an incident has been detected, it is important to first think
   about containing the incident.  Once the incident has been contained,
   it is now time to eradicate the cause.  But before eradicate the
   cause great care should be taken to collect all necessary information
   about the compromised system and the cause of the incident due later
   on they will disappear during the eradication.

   Software may be available to help you in the eradiction process.  For
   example, eradication software is available to eliminate most viruses
   which infect small systems.  If any bogus files have been created, it
   is time to archive them for later use in case of a court case.
   Thereafter delete them from the system at this point.  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
   reinfected simply because people do not systematically eradicate the
   virus from backups.  After eradiction 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
   recustomize 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 $$.4.2, a security log can be most valuable
   during this phase of removing vulnerabilities.  There are two
   considerations here; the first is to keep logs of the procedures that
   have been used to make the system secure again.  This should include
   command procedures (e.g., shell scripts) that can be run on a
   periodic basis to recheck the security.  Second, keep logs of
   important system events.  These can be referenced when trying to
   determine the extent of the damage of a given incident.

   If a particular vulnerability is isolated as having been exploited,
   the next step is to find a mechanism to protect your system.  The



Site Security Handbook Working Group                           [Page 37]


Internet Draft           Site Security Handbook            November 1995


   security mailing lists and bulletins would be a good place to search
   for this information and you can get advice from incident response
   teams.

5.4.5  Recovery

   Once the cause of an incident has been eradicated, the recovery phase
   defines the next stage of action.  The goal of recovery is to return
   the system to normal.  In general, bringing up services in the order
   of demand to allow a minimum of user inconvenience is the best
   practice.  Understand that the proper recovery procedures for the
   system are extremely important and should be specific to the site.

5.4.6  Follow-Up

   Once you believe that a system has been restored to a "safe" state,
   it is still possible that holes and even traps could be lurking in
   the system.  One of the most important stages of responding to
   incidents is also the most often omitted---the follow-up stage.  In
   the follow-up stage, the system should be monitored for items that
   may have been missed during the cleanup stage.  It would be prudent
   to utilize some of the tools mentioned in section xxx (e.g., xxx) as
   a start.  Remember, these tools don't replace continual system
   monitoring and good systems administration procedures.

   The follow-up stage is important for another reason, too, because it
   helps those involved in handling the incident develop a set of
   "lessons learned" (see section $$.5) to improve future performance in
   such situations.  This stage also provides information which
   justifies an organization's computer security effort to management,
   and yields information which may be essential in legal proceedings.

   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?  A follow-up report is valuable because it
   provides a reference to be used in case of other similar incidents.
   Creating a formal chronology of events (including time stamps) is
   also important for legal reasons.  Similarly, it is also important to
   as quickly 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.


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,



Site Security Handbook Working Group                           [Page 38]


Internet Draft           Site Security Handbook            November 1995


        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.

   All four steps should provide feedback to the site security policy
   committee, leading to prompt re-evaluation and amendment of the
   current policy.

   If an incident is based on poor policy, and unless the policy is
   changed, then one is doomed to repeat the past.  Once a site has
   recovered from and incident, site policy and procedures should be
   reviewed to encompass changes to prevent similar incidents.  Even
   without an incident, it would be prudent to review policies and
   procedures on a regular basis.  Reviews are imperative due to today's
   changing computing environments.

   After an incident, it is prudent to write a report describing the
   incident, method of discovery, correction procedure, monitoring
   procedure, and a summary of lesson learned.  This will aid in the
   clear understanding of the problem.  Remember, it is difficult to
   learn from an incident if you don't understand the source.

   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.  This should improve one's ability to detect the
   occurance of similar problems in the future.  A concrete goal is
   developing proactive methods, for example: early warning by probes.
   Another important facet of the aftermath is more related to end user
   and administrator awareness and eduction.  By reviewing the actual
   incident handling effort the process can be improved and extended to
   reflect new lessons learned.  All this will help the site in the
   handling of future incidents even if a completely different kind of
   attack occurs.

5.6  Responsibilities

   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



Site Security Handbook Working Group                           [Page 39]


Internet Draft           Site Security Handbook            November 1995


   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 POC of the effected
   site.

6.  MAINTENANCE and EVALUATION

6.1  Risk assessments

6.2  Notification of problems/events

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.

   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



Site Security Handbook Working Group                           [Page 40]


Internet Draft           Site Security Handbook            November 1995


   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)
   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



Site Security Handbook Working Group                           [Page 41]


Internet Draft           Site Security Handbook            November 1995


        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.

   (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



Site Security Handbook Working Group                           [Page 42]


Internet Draft           Site Security Handbook            November 1995


        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
        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 43]