doc: Add RFC documents

1 files changed, 4203 insertions, 0 deletions

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