WDIFF

draft-ietf-ssh-handbook-01.txt --> draft-ietf-ssh-handbook-02.txt

Internet Draft Barbara Fraser
Network Working Group SEI/CMU
Expires in six months December 1995 March 1996

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

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Table of Contents

1. Introduction.................................................... 2
1.1 Purpose of this Work............................................ 2
1.2 Audience........................................................ 2
1.3 Definitions..................................................... 3
1.4 Related Work.................................................... 3
1.5 Basic Approach.................................................. 3
1.6 Risk Assessment................................................. 4
2. Security Policies............................................... 3 5
2.1 What is a Computer Security Policy and Why Have One?............ 3 5
2.2 What Makes a Good Computer Security Policy?..................... 5 7
3. Architecture.................................................... 6 9
3.1 Objectives...................................................... 6 9
3.2 Network and Service Configurations.............................. 10
3.4 12
3.3 Firewalls....................................................... 13 16
4. Security Procedures............................................. 13 Services and Procedures................................ 19
4.1 Authentication.................................................. 13 19
4.2 Authorization................................................... 15 Confidentiality................................................. 22
4.3 Access.......................................................... 16 Integrity....................................................... 22
4.4 Modems.......................................................... 16 Authorization................................................... 23
4.5 Cryptography.................................................... 18 Access.......................................................... 23
4.6 Auditing........................................................ 18 27
4.7 Backups......................................................... 20 Securing Backups................................................ 29
5. Security Incident Handling...................................... 20 29
5.1 Preparing and Planning for Incident Handling.................... 22 31
5.2 Notification and Points of Contact.............................. 24 33
5.3 Identifying an Incident......................................... 31
5.4 Handling an Incident............................................ 33
5.5 Aftermath of an Incident........................................ 38 39

Site Security Handbook Working Group [Page 1]

Internet Draft Site Security Handbook November December 1995

5.4 Handling an Incident............................................ 41
5.5 Aftermath of an Incident........................................ 46
5.6 Responsibilities................................................ 39 47
6. Maintenance and Evaluation...................................... 40
6.1 Risk Assessments................................................ 40
6.2 Notification of Problems and Events............................. 40 Ongoing Activities.............................................. 48
Appendix A1 Tools and Locations..................................... 40 49
Appendix A2 Mailing Lists and Other Resources....................... 41 50
References........................................................... ?
Annotated Bibliography............................................... ?

1. INTRODUCTION

This document provides guidance to system and network administrators
on how to address security issues within the Internet community. It
builds on the foundation provided in RFC 1244 and is the collective
work of a number of contributing authors. Those authors include:
Jules P. Aronson, Nevil Brownlee, Joao Nuno Ferreira, Erik Gutmann,
Klaus-Peter Kossakowski, Edward.P.Lewis, Gary Malkin, Russ Mundy,
Philip J. Nesser, and Michael S. Ramsey.

A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook,
CICnet, for their vision, leadership, and effort in the creation of
the first version of this handbook. It is the working group's sincere
hope that this version will be as helpful to the community as the
earlier one was.

1.1 Purpose of this Work

This handbook is a guide to setting computer security policies and
procedures for sites that have systems on the Internet. This guide
lists issues and factors that a site must consider when setting their
own policies. It makes some recommendations and provides discussions
of relevant areas.

This guide is only a framework for setting security policies and
procedures. In order to have an effective set of policies and
procedures, a site will have to make many decisions, gain agreement,
and then communicate and implement the policies.

1.2 Audience

The audience for this document are system administrators and network administrators,
and decision makers (who are more traditionally called "administrators" or ( typically "middle management") at sites. For
brevity, we will use the term "administrator" throughout this
document to refer to system and network administrators.

This document is not directed at programmers or those trying to
create secure programs or systems. The focus of this document is on
the policies and procedures that need to be in place to support any
technical security features that a site may be implementing.

The primary audience for this work are sites that are members of the
Internet community. However, this document should be useful to any
site that allows communication with other sites. As a general guide
to security policies, this document may also be useful to sites with
isolated systems.

Site Security Handbook Working Group [Page 2]

Internet Draft Site Security Handbook November December 1995

isolated systems.

1.3 Definitions

For the purposes of this guide, a "site" is any organization that
owns computers or network-related resources. These resources may
include host computers that users use, routers, terminal servers,
PC's or other devices that have access to the Internet. A site may
be a end user of Internet services or a service provider such as a
regional network. However, most of the focus of this guide is on
those end users of Internet services.

We assume that the site has the ability to set policies and
procedures for itself with the concurrence and support from those who
actually own the resources.

The "Internet" is those set of networks and machines that use the
TCP/IP protocol suite, connected through gateways, and sharing a
common name and address spaces [1].

The term "system administrator" is used to cover all those who are
responsible for the day-to-day operation of resources. This may be a
number of individuals or an organization.

The term "decision maker" refers to those people at a site who set or
approve policy. These are often (but not always) the people who own
the resources.

1.4 Related Work

The IETF Guidelines for Security Incident Response Working Group
(GRIP) is developing a document for security incident response teams.
That document provides additional guidance to those organizations
planning to develop their own incident response team (IRT), including
a template that is useful to IRTs when descibing their policies and
services.

2. SECURITY POLICIES

2.1 What is a Computer Security Policy and Why Have One?

The security-related decisions you make, or fail to make, as network
administrator largely determines how secure or insecure your network
is, how much functionality your network offers, and how easy your
network

1.5 Basic Approach

This guide is written to use. However, you cannot make good decisions about provide basic guidance in developing a
security without first determining what plan for your security goals are.
Until you determine site. One generally accepted approach to this
is suggested by Fites, et. al. [ref] and includes the following
steps:

(1) Identify what your security goals are, you cannot make
effective use of any collection of security tools because you simply
will not know what are trying to check for and protect
(2) Determine what restrictions you are trying to impose.

For example, your goals will probably be very different protect it from
(3) Determine how likely the
goals of a product vendor. Vendors threats are trying to make configuration
and operation of their products as simple as possible,
(4) Implement meansures 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, 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 systems steps

Site Security Handbook Working Group [Page 3]

Internet Draft Site Security Handbook November December 1995

through them, open to any user who wanders by.

Your goals will

cannot be largely determined by the following key tradeoffs:

(1) services offered vs. security provided -
Each service offered avoided if an effective plan is to users carries its own be established at your
site. One old truism in security risks.
For some services the risk outweighs is that the benefit cost of protecting
yourself against a threat should be less than the service
and the administrator may choose to eliminate cost recovering if
the service rather
than try threat were to secure it.

(2) ease strike you. Without reasonable knowledge of use vs. security -
The easiest system to use would allow acces to any user what
you are protecting and require
no passwords; that is, there would what the likely threats are, following this
rule could be no security. Requiring
passwords makes difficult.

1.6 Risk Assessment

1.6.1 General Discussion

One of the system most important reasons for creating a little less convenient, but more secure.
Requiring device-generated one-time passwords makes the system even
more difficult computer security
policy is to use, but much more secure.

(3) cost of ensure that efforts spent on security vs. risk of loss -
There are many different costs yield cost
effective benefits. Although this may seem obvious, it is possible
to security: monetary (i.e., be mislead about where the
cost effort is needed. As an example, there
is a great deal of purchasing publicity about intruders on computers systems;
yet most surveys of computer security hardware and software like firewalls
and one-time password generators), performance (i.e., encryption 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 decryption take time), how to protect it. Is is the process of
examining all of your risks, and ease ranking those risks by level of use (as
severity. This process involves making cost-effective decisions on
what you want to protect. As mentioned above).
There are also many levels of risk: loss above, you should probably
not spend more to protect something than it is actually worth.

A full treatment of privacy (i.e., risk analysis is outside the
reading scope of information by unauthorized individuals), loss this
document. [3, FITES] and [16, PFLEEGER] provide introductions to
this topic. However, there are two elements of
data (i.e., a risk analysis that
will be briefly covered in the corruption or erasure of information), and next two sections:

(1) Identifying the
loss of service (e.g., assets
(2) Identifying the filling of data storage space, usage threats

For each asset, the basic goals of computational resources, security are availability,
confidentiality, and denial of network access). integrity. Each
type of cost must be weighed against each type of loss.

Your goals threat should be communicated examined with
an eye to all users, operations staff, and
managers through a set of security rules, called a "computer security
policy."

2.1.1 Definition of how the threat could affect these areas.

1.6.2 Identifying the Assets

One step in a Computer Security Policy

A computer security policy risk analysis is a formal statement of to identify all the rules by
which people who are given access things that need
to an organization's technology and
information assets must abide.

2.1.2 Purposes of a Computer Security Policy

The main purpose of a computer security policy is to inform users,
staff and managers of their obligatory requirements for protecting
technology and information assets. The policy should specify the
mechanisms through which these requirements can be met. Another
purpose is to provide a baseline from which to acquire, configure and
audit computer systems protected. Some things are obvious, like valuable proprietary
information or intellectual property and networks for compliance with all the policy.
Therefore an attempt to use a set various pieces of security tools in
hardware, but some are overlooked, such as the absence of
at least an implied security policy people who actually
use the systems. The essential point is meaningless.

2.1.3 Who Should to list all things that could
be Involved When Forming Policy?

In order for affected by a security policy to be appropriate and effective, it problem.

One list of categories is suggested by Pfleeger [16, PFLEEGER, page
459]; this list is adapted from that source:

(1) Hardware: cpus, boards, keyboards, terminals,
workstations, personal computers, printers, disk
drives, communication lines, terminal servers, routers.

Site Security Handbook Working Group [Page 4]

Internet Draft Site Security Handbook November December 1995

needs to have the acceptance and support of all levels of employees
within the organization. The following is a list of individuals who
should be involved in the creation and review of security policy
documents:

(1) site security administrator

(2) legal counsel Software: source programs, object programs,
utilities, diagnostic programs, operating systems,
communication programs.

(3) computing center personnel Data: during execution, stored on-line, archived off-line,
backups, audit logs, databases, in transit over
communication media.

(4) network administrators of large user groups within the organization
(e.g., business divisions, computer science department within a
university, etc.) People: users, people needed to run systems.

(5) Documentation: on programs, hardware, systems, local or national security incident response team
administrative procedures.

(6) representatives of Supplies: paper, forms, ribbons, magnetic media.

1.6.3 Identifying the user groups affected by Threats

Once the security policy

The list of above is representative of many organizations, but assets requiring protection are identified, it is not
necessarily comprehensive. necessary
to identify threats to those assests. The idea is threats can then be
examined to bring in representation determine what potential for loss exists. It helps to
consider from key stakeholders, management who have budget and policy
authority, technical staff who know what can and cannot be supported,
and legal counsel who know the legal ramifications of various policy
choices. Involving this group is important if resulting policy
statements threats you are trying to reach the broadest possible acceptance.

2.2 What Makes a Good Computer Security Policy? protect your assets.
The characteristics of a good security policy are:

(1) It must following are classic threats that should be implementable through system administration
procedures, publishing of acceptable use guidelines, or other
appropriate methods.

(2) It must considered.
Depending on your site, there will be enforcible with security tools, where appropriate, more specific threats that
should be identified and with sanctions, where actual prevention is not technically
feasible.

(3) It must clearly define the areas addressed.

(1) Unauthorized access to resources and/or information
(2) Disclosure of responsibility for the
users, staff, and administrators.

The components information
(3) Denial of service

2. SECURITY POLICIES

2.1 What is 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 Security Policy which defines reasonable expectations of privacy
regarding such issues as monitoring of electronic mail, logging of
keystrokes, and access Why Have One?

The security-related decisions you make, or fail to users' files.

(3) An Access Policy which defines access rights make, as network
administrator largely determines how secure or insecure your network
is, how much functionality your network offers, and privileges how easy your
network is to
protect assets from loss or disclosure by specifying acceptable 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
guidelines of any collection of security tools because you simply
will not know what to check for users, operations staff, and management. It should
provide guidelines for external connections, data communications,
connecting devices what restrictions to impose.

For example, your goals will probably be very different from the
goals of a network, product vendor. Vendors are trying to make configuration
and adding new software 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
systems. It should install new
products, it also specify leaves access to those systems, and other systems
through them, open to any required notification messages user who wanders by.

Your goals will be largely determined by the following key tradeoffs:

(1) services offered vs. security provided -

Site Security Handbook Working Group [Page 5]

Internet Draft Site Security Handbook November December 1995

(e.g., connect messages should provide warnings about authorized
usage and line monitoring, and not simply say "Welcome").

(4) An Accountability Policy which defines

Each service offered to users carries its own security risks.
For some services the responsibilities risk outweighs the benefit of users,
operations staff, and management. It should specify an audit
capability, the service
and provide incident handling guidelines (i.e., what the administrator may choose to
do and who eliminate the service rather
than try to contact if a possible intrusion is detected).

(5) An Authentication Policy which establishes trust through an effective
password policy, and by setting guidelines for remote location
authentication secure it.

(2) ease of use vs. security -
The easiest system to use would allow acces to any user and require
no passwords; that is, there would be no security. Requiring
passwords makes the use of authentication devices (e.g., system a little less convenient, but more secure.
Requiring device-generated one-time passwords and makes the devices that generate them).

(6) An Availability statement which sets users' expectations for system even
more difficult to use, but much more secure.

(3) cost of security vs. risk of loss -
There are many different costs to security: monetary (i.e., the
availability
cost of resources. It should address redundancy purchasing security hardware and recovery
issues, as well as specify operating hours software like firewalls
and maintenance down-time
periods. It should one-time password generators), performance (i.e., encryption
and decryption take time), and ease of use (as mentioned above).
There are also include contact many levels of risk: loss of privacy (i.e., the
reading of information for reporting
system by unauthorized individuals), loss of
data (i.e., the corruption or erasure of information), and network failures.

(7) A Violations Reporting Policy that indicates which types the
loss of
violations service (e.g., privacy and security, internal and external)
must be reported and to whom the reports are made. A
non-threatening atmosphere filling of data storage space, usage
of computational resources, and the possibility denial of anonymous reporting
will result in a greater probability that a violation will network access). Each
type of cost must be
reported if it is detected.

(8) Supporting Information which provides users, staff, and management
with contact information for weighed against each type of policy violation;
guidelines how handle outside queries about a security incident or
information which may loss.

Your goals should be considered confidential or proprietary; and
cross-references communicated to security procedures and related information, such
as company policies and regulatory requirements (federal, state, all users, operations staff, and
local).

There may be regulatory requirements that affect some aspects
managers through a set of your security policy (e.g., line monitoring). The creators rules, called a "computer security
policy."

2.1.1 Definition of the a Computer Security Policy

A computer security policy should consider seeking legal assistance in the
creation of the policy. At is a minimum, formal statement of the policy should be reviewed rules by legal counsel.

Once your
which people who are given access to an organization's technology and
information assets must abide.

2.1.2 Purposes of a Computer Security Policy

The main purpose of a computer security policy has been established it should be
clearly communicated is to inform users, staff, and management. Having all
personnel sign a statement indicating that they have read,
understood,
staff and agreed to abide by the policy is an important part managers of
the process. Finally, your their obligatory requirements for protecting
technology and information assets. The policy should specify the
mechanisms through which these requirements can be reviewed on met. Another
purpose is to provide a regular
basis baseline from which to see if it is successfully supporting your security needs.

3. ARCHITECTURE

3.1 Objectives

3.1.1 Completely defined acquire, configure and
audit computer systems and networks for compliance with the policy.
Therefore an attempt to use a set of security plans tools in the absence of
at least an implied security policy is meaningless.

An Appropriate Use Policy (AUP) may also be part of a security
policy. It should spell out what users may and may not do on the
various components of the system, including the type of traffic
allowed on the networks. The AUP should be as explicit as possible
to avoid ambiguity or misunderstanding. For example, an AUP might
list any prohibited newsgroups.

Site Security Handbook Working Group [Page 6]

Internet Draft Site Security Handbook November December 1995

Defining

2.1.3 Who Should be Involved When Forming Policy?

In order for a comprehensive security plan should policy to be done by appropriate and effective, it
needs to have the acceptance and support of all sites.
This plan should be at a higher level than levels of employees
within the specific policies
discussed in section 2. It should be crafted as organization. The following is a framework list of broad
guidelines into which specific policies will fit.

It is important to have this framework in place so that individual
policies can individuals who
should be consistant with involved in the overall creation and review of security policy
documents:

(1) site security
architecture. For example, having administrator
(2) legal counsel
(3) computing center personnel
(4) network administrators of large user groups within the organization
(e.g., business divisions, computer science department within a strong
university, etc.)
(5) security incident response team
(6) representatives of the user groups affected by the security policy with regard to
Internet access, but having weak restrictions on modem usage

The list of above is
inconsistent with an overall philosophy of strong security
restrictions on external access.

A security policy should contain, at a minimum: a list representative of services
which are currently, or will forseably be, provided; many organizations, but is not
necessarily comprehensive. The idea is to bring in representation
from key stakeholders, management who will have
access to those services; how access will be provided; budget and policy
authority, technical staff who will
administer those services; etc. It is also imperative to define any
limitations on which portions of an organization know what can provide
services.

Another aspect of and cannot be supported,
and legal counsel who know the plan should concern incident handling. Chapter
5 provides an in-depth discussion legal ramifications of responses to incidents, but various policy
choices. In some organizations, it may be appropriate to include
audit personel. Involving this group is important if resulting
policy statements are to define classes reach the broadest possible acceptance.

2.2 What Makes a Good Computer Security Policy?

The characteristics of incidents and define responses to
each class a good security policy are:

(1) It must be implementable through system administration
procedures, publishing of incident. For sites acceptable use guidelines, or other
appropriate methods.

(2) It must be enforcible with firewalls, how many attempts
to foil security tools, where appropriate,
and with sanctions, where actual prevention is not technically
feasible.

(3) It must clearly define the firewall will trigger a response? Are there levels areas of
escallation in both attacks responsibility for the
users, staff, and responses? For sites without
firewalls, does a single attempt to connect constitute an incident?
How about a systematic scan administrators.

The components of a good security policy include:

(1) Computer Technology Purchasing Guidelines which specify required,
or preferred, security features. These should supplement existing
purchasing policies and guidelines.

(2) A Privacy Policy which defines reasonable expectations of privacy
regarding such issues as monitoring of electronic mail, logging of
keystrokes, and access to users' files.

(3) An Access Policy which defines access rights and privileges to
protect assets from loss or disclosure by specifying acceptable use

Site Security Handbook Working Group [Page 7]

Internet Draft Site Security Handbook December 1995

guidelines for users, operations staff, and management. It should
provide guidelines for external connections, data communications,
connecting devices to a network, and adding new software to
systems. It should also specify any required notification messages
(e.g., connect messages should provide warnings about authorized
usage and line monitoring, and not simply say "Welcome").

(4) An Accountability Policy which defines the responsibilities of users,
operations staff, and management. It should specify an audit
capability, and provide incident handling guidelines (i.e., what to
do and who to contact if a possible intrusion is detected).

(5) An Authentication Policy which establishes trust through an effective
password policy, and by setting guidelines for remote location
authentication and the use of authentication devices (e.g., one-time
passwords and the devices that generate them).

(6) An Availability statement which sets users' expectations for the
availability of resources. It should address redundancy and recovery
issues, as well as specify operating hours and maintenance down-time
periods. It should also include contact information for reporting
system and network failures.

(7) A Violations Reporting Policy that indicates which types of
violations (e.g., privacy and security, internal and external)
must be reported and to whom the reports are made. A
non-threatening atmosphere and the possibility of anonymous reporting
will result in a greater probability that a violation will be
reported if it is detected.

(8) Supporting Information which provides users, staff, and management
with contact information for each type of policy violation;
guidelines how handle outside queries about a security incident or
information which may be considered confidential or proprietary; and
cross-references to security procedures and related information, such
as company policies and regulatory requirements (federal, state, and
local).

There may be regulatory requirements that affect some aspects of your
security policy (e.g., line monitoring). The creators of the
security policy should consider seeking legal assistance in the
creation of the policy. At a minimum, the policy should be reviewed
by legal counsel.

Once your computer security policy has been established it should be
clearly communicated to users, staff, and management. Having all
personnel sign a statement indicating that they have read,
understood, and agreed to abide by the policy is an important part of
the process. Finally, your policy should be reviewed on a regular
basis to see if it is successfully supporting your security needs.

2.3 Keep the policy flexible

Site Security Handbook Working Group [Page 8]

Internet Draft Site Security Handbook December 1995

In order for a security policy to be viable for the long term, it
requires a lot of flexibility. The mechanisms for updating the
policy should be clearly spelled out. This includes the process, the
people involved, and the people who must sign-off on the changes.

It is also important to recognize that there are exceptions to every
rule. Whenever possible, the policy should spell out what exceptions
to the general policy exist. For example, under what conditions is a
system administrator allowed to go through a user's files. Also,
there may be some cases when multiple users will have access to the
same userid. For example, on systems with a "root" user, multiple
system administrators may know the password and use the root account.

Another consideration is called the "Garbage Truck Syndrome." This
refers to what would happen to a site if a key person was suddenly
unavailable for his/her job function. While the greatest security
resides in the minimum dissemination of information, the risk of
losing critical information increases when that information is not
shared. It is necessary to determine what the proper balance is for
your site.

3. ARCHITECTURE

3.1 Objectives

3.1.1 Completely defined security plans

Defining a comprehensive security plan should be done by all sites.
This plan should be at a higher level than the specific policies
discussed in section 2. It should be crafted as a framework of broad
guidelines into which specific policies will fit.

It is important to have this framework in place so that individual
policies can be consistant with the overall site security
architecture. For example, having a strong policy with regard to
Internet access, but having weak restrictions on modem usage is
inconsistent with an overall philosophy of strong security
restrictions on external access.

A security policy should contain, at a minimum: a list of services
which are currently, or will forseably be, provided; who will have
access to those services; how access will be provided; who will
administer those services; etc. It is also imperative to define any
limitations on which portions of an organization can provide
services.

Another aspect of the plan should concern incident handling. Chapter
5 provides an in-depth discussion of responses to incidents, but it
is important to define classes of incidents and define responses to
each class of incident. For sites with firewalls, how many attempts
to foil the firewall will trigger a response? Are there levels of
escallation in both attacks and responses? For sites without
firewalls, does a single attempt to connect constitute an incident?

Site Security Handbook Working Group [Page 9]

Internet Draft Site Security Handbook December 1995

How about a systematic scan of machines?

For sites connected sites connected to the Internet, the rampant media glorification
of Internet related security incidents can overshadow a (potentially)
more serious internal security problem. Likewise, companies who have
never been on the Internet before, may have strong, well defined,
internal policies but fail to adequately address external connection
policy.

3.1.2 Separation of Services

There are many services which a site may wish to provide for its
users, some of which may be external. There are a variety of
security reasons to attempt to isolate services onto dedicated
machines. There are also performance reasons in most cases, but a
detailed discussion is beyond to scope of this document.

The services which a site may provide will, in most cases, have
different levels of access needs and models of trust. Services which
are essential to the security and smooth operation of a site would be
better off being placed on a dedicated machine with very limited
access restrictions (see Section 3.1.3 "deny all" model), rather than
a machine which provides a service (or services) which has
traditionally been less secure, or requires greater accessability by
users who may accidentally suborn security.

It is also important to distinguish between machines which operate
within different models of trust, say all the machines inside of a
firewall, and any machines on an exposed network.

Some of the services which should be examined for potential
separation are outlined below. More specific information will be
presented in section 3.3 (????). It is important to try to
understand that vulnerability is only as strong as the weakest link
in the chain. Several of the most publicized penetrations in recent
years has been through the electronic mail systems of machines. The
intruders were not trying to steal electronic mail, but they used the
vulnerability in that system to gain access to other systems.

If possible, each service should be running on a different machine
whose only duty is to provide a specific service. This help isolate
intruders and limit potential harm.

3.1.3 Deny all/ Allow all

There are two diametrically oppossed underlying philosophies which
can be adopted in defining a security plan. Both alternatives are
legitimate models to adopt, depending on the site and its needs for
security.

The first option is to turn off all services and then selectively
enable services on a case by case basis, be it at the machine or
network level, as they are needed. This model, which will here after
be referred to as the "deny all" model, is generally more secure.

Site Security Handbook Working Group [Page 10]

Internet Draft Site Security Handbook December 1995

More work is required to successfully implement a "deny all"
configuration and usually a better understanding of services; which
may require several pieces operating together to function correctly.
Only allowing known services allows a better analysis of a particular
service/protocol, and the design of a security mechanism suited to
the security level of the site.

The other model, which will here after be referred to as the "allow
all" model, is much easier to implement, but is in general less
secure than the "deny all" model. Simply turn on all services,
usually the default at the host level, and allow all protocols to
travel across network boundaries, usually the default at the router
level. As security holes become apparent, they are patched at either
the host or network level.

Each of these models can be applied to different portions of the
site, depending on functionality requirements, administrative
control, site policy etc. For example, the policy may be to use the
"allow all" model when setting up workstations for general use, but
adopt a "deny all" model when setting up information servers, like an
email hub. Likewise, an "allow all" policy may be adopted for
traffic between LAN's internal to the site, but a "deny all" policy
can be adopted between the site and the Internet.

Be careful when mixing philosophies as in the examples above. Many
sites adopt the M & M theory of a hard "crunchy" shell and a soft
"squishy" middle. They are willing to pay the cost of security for
their external traffic and require strong security measures, but are
unwilling or unable to provide similar protections internally. This
works fine as long as the outer defenses are never breached and the
internal users can be trusted. Once the outer shell (firewall) is
breached, subverting the internal network is trivial.

3.1.4 Identify real needs for services

There is a large variety of services which may be provided, both
internally and on the Internet at large. Managing security is in
many ways managing access to services internal to the site and
managing how internal users access information at remote sites.

Services tend to rush like waves over the Internet. Over the years
many sites have established anonymous ftp servers, gopher servers,
wais servers, www servers, etc. as they became popular but not
particularly needed at all sites. Evaluate all new services that are
established with a skeptical attitude to determine if they are
actually needed or just the current fad sweeping the Internet.

Bear in mind that security complexity can grow exponentially with the
number of services provided. Filtering routers need to be modified
to support the new protocols. Some protocols are inherently
difficult to filter safely (ex. rpc and udp services), thus providing
more openings to the internal network. Services provided on the same
machine can interact in catastrophic ways. (ex. allowing anonymous
ftp on the same machine as the www server may allow an intruder to

Site Security Handbook Working Group [Page 11]

Internet Draft Site Security Handbook December 1995

place a file in the anonymous ftp area and cause the http server to
execute it.)

3.2 Network and Service Configuration

3.2.1 Protecting the Infrastructure

Many network administrators go to great lengths to protect the hosts
on their networks. Few administrators make any effort to protect the
networks themselves. There is some rationale to this. For example,
it is far easier to protect a host than a network. Also, intruders
are likely to be after data on the hosts; damaging the network would
not serve their purposes. That said, there are still reasons to
protect the networks. For example, an intruder might divert network
traffic through an outside host in order to examine the data (i.e.,
to search for passwords). Also, infrastructure includes more than
the networks and the routers which interconnect them. Infrastructure
also includes network management (e.g., SNMP), services (e.g., DNS,
NFS, NTP, WWW), and security (i.e., user authentication and access
restrictions).

The infrastructure also needs protection against human error. When
an administrator misconfigures a host, that host may offer degraded
service. This only affects users who require that host, and unless
that host is a primary server, the number of affected users will
therefore be limited. However, if a router is misconfigured, all
users who require the network will be affected. Obviously, this is a
far larger number of users than those depending on any one host.

3.2.2 Protecting the Network

There are several problems to which networks are vulnerable. The
classic is a "denial of service" attack. In this case, the network
is brought to a state in which it can no longer carry legitimate
users' data. There are two common ways this can be done: by
attacking the routers and by flooding the network with extraneous
traffic. An attack on the router is designed to cause it to stop
forwarding packets, or to forward them improperly. The former case
may be due to a misconfiguration, the injection of a spurious routing
update, or a "flood attack" (i.e., the router is bombarded with
unroutable packets, causing its performance to degrade). A flood
attack on a network is similar to a flood attack on a router, except
that the flood packets are usually broadcast. An ideal flood attack
would be the injection of a single packet which exploits some known
flaw in the network nodes and causes them to retransmit the packet,
or generate error packets, each of which is picked up and repeated by
another host. A well chosen attack packet can even generate an
exponential explosion of transmissions.

Another classic problem is "spoofing." In this case, spurious
routing updates are sent to one or more routers causing them to
misroute packets. This differs from a denial of service attack only
in the purpose behind the spurious route. In denial of service, the
object is to make the router unusable; a state which will be quickly

Site Security Handbook Working Group [Page 12]

Internet Draft Site Security Handbook December 1995

detected by network users. In spoofing, the spurious route will
cause packets to be routed to a host from which an intruder may
monitor the data in the packets. These packets are then be re-routed
to their correct destinations. However, the intruder may or may not
have altered the contents of the packets.

The solution to most of these problems is to protect the routing
update packets sent by the routing protocols in use (e.g., RIP-2,
OSPF). There are three levels of protection: clear-text password,
cryptographic checksum, and encryption. Passwords offer only minimal
protection against intruders who do not have direct access to the
physical networks. Passwords also offer some protection against
misconfigured routers (i.e, routers which, out of the box, attempt to
route packets). The advantage of passwords is that they have a very
low overhead, in both bandwidth and CPU consumption. Checksums
protect against the injection of spurious packets, even if the
intruder has direct access to the physical network. Combined with a
sequence number, or other unique identifier, a checksum can also
protect again "replay" attacks, wherein an old (but valid at the
time) routing update is retransmitted by either an intruder or a
misbehaving router. The most security is provided by complete
encryption of sequenced, or uniquely identified, routing updates.
This prevents an intruder from determining the topology of the
network. The disadvantage to encryption is the Internet, overhead involved in
processing the rampant media glorification 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 Internet related security incidents attack is obvious when it occurs
and can overshadow be terminated relatively simply.

3.2.3 Protecting the Services

There are many types of services; each has its own security
requirements. These requirements will vary based on the intended use
of the service. For example, a (potentially)
more serious internal service which should only be usable
within a site (e.g., NFS) requires little protection. That is,
protecting the server from external access is sufficient to protect
the service. However, a WWW server, which provides a home page
intended for viewing by users anywhere on the Internet, requires
built-in protection. That is, the service/protocol/server must
provide whatever security problem. Likewise, companies who may be required to prevent unauthorized
access and modification of the Web database.

Internal services (i.e., services meant to be used only by users
within a site) and external services (i.e., services deliberately
available to users outside a site) will, in general, have
never been on protection
requirements which differ as previously described. It is therefore
wise to isolate the Internet before, may have strong, well defined, internal policies but fail services to adequately address one set of server machines
and the external connection
policy.

3.1.2 Separation services to another set of Services

There are server machines. That

Site Security Handbook Working Group [Page 13]

Internet Draft Site Security Handbook December 1995

is, internal and external servers should not be co-located. In fact,
many services which a site may wish sites go so far as to provide for its
users, some have one set of subnets (or even different
networks) which are accessible from the outside and another set which
may be external. There are accessed only within the site. Of course, there is usually a variety
firewall which connects these partitions. Great care must be taken
to ensure that such a firewall is operating properly.

One form of
security reasons 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 attempt
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 isolate services onto dedicated
machines. There 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 also performance reasons in the
most frequently used services, they are the most cases, but obvious points of
attack. Also, a
detailed discussion is beyond to scope successful attack on one of this document.

The these services which a site may provide will, in most cases, have
different levels can
produce disaster all out of access needs and models proportion to the innocence of trust. Services which 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 essential not used on the global Internet, but are
subject to the security and smooth 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 site would DNS server can
reroute traffic to subvert security protections. For examaple,
routine traffic can be
better off being placed on diverted to a dedicated machine compromised system to be
monitored; or, users can be tricked into providing authentication
secrets. An organization should create well known, protected sites
to act as secondary name servers and protect their DNS masters from
denial of service attacks using filtering routers.

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

Password and key servers generally protect their vital information
(i.e., the passwords and keys) with very limited
access restrictions (see Section 3.1.3 "deny all" model), rather than
a machine which provides encryption algorithms. However,
even a service (or services) which has
traditionally been less secure, or requires greater accessability one-way encrypted password can be determined by
users who may accidentally suborn security. a dictionary
attack (wherein common words are encrypted to see if they match the
stored encryption). It is also important therefore necessary to ensure that these
servers are not accessable by hosts whch do not plan to distinguish between machines which operate
within different models of trust, say all use them for
the machines inside of a service, and even those hosts should only be able to access the
service (i.e., general services, such as Telnet and FTP, should not
be allowed by anyone other than administrators).

3.2.3.3 Authentication/Proxy Servers (SOCKS, FWTK)

Site Security Handbook Working Group [Page 7] 14]

Internet Draft Site Security Handbook November December 1995

firewall, and any machines on an exposed network.

Some

A proxy server provides a number of the services which should be examined for potential
separation are outlined below. More specific information will be
presented in section 3.3 (????). security enhancements. It is important to try allows
sites to
understand that vulnerability is only as strong as the weakest link
in the chain. Several of the most publicized penetrations in recent
years has been concentrate services through the electronic mail systems of machines. The
intruders were not trying to steal electronic mail, but they used the
vulnerability in that system to gain access to other systems.

If possible, each service should be running on a different machine
whose only duty is to provide a specific service. host to allow
monitoring, hiding of internal structure, etc. This help isolate
intruders and limit funnelling of
services creates an attractive target for a potential harm.

3.1.2.1 Name Servers (DNS and NIS(+)) intruder. The Internet uses
type of protection required for a proxy server depends greatly on the Domain Name System (DNS) to perform name to
address resolution. The Network Information Service (NIS)
proxy protocol in use and NIS+
are not used on the global Internet but are subject services being proxied. The general
rule of limiting access only to those hosts which need the same risks
internally as a DNS server. Name-to-address resolution services,
and limiting access by those hosts to only those services, is critical 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 secure operation of outside world; most email servers accept input
from any network. source. An attacker who can
successfully control or impersonate a DNS email server can route traffic to
quickly subvert numerous security guards. Routine traffic can be
diverted to generally consists of two parts, a compromised system
receiving/sending agent and traffic can be monitored or
users can trivially be tricked into offering authentication secrets.
An organization would do well a processing agent. Since email is
delivered to arrange well known all users, and protected
sites is usually private, the processing agent
typically requires system (root) privileges to act as secondary name servers, and deliver the mail.
Most email implementations perform both portions of the service,
which means the receiving agent also protect their own
DNS masters from denial has system privileges. This
opens several security holes which this document will not describe.
There are some implementations available which allow a separation of service attacks using filtering routers.

3.1.2.2 Password/Key Servers (NIS(+)
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 KDC)

Machines used for password or key the powerful abilities to concentrate information services.
Most WWW servers protect take some of directions and actions from the persons
accessing their services. The most
valuable common example is taking a
request from a remote user and passing the provided information to a potential intruder,
program running on the encrypted passwords
and/or keys, which can be used server to access process the site. Since many
current schemes request. Some of encryption these
programs are either subject not written with security in mind and can create
security holes. If a Web server is available to dictionary or
brute force attacks, every effort must the Internet
community, it is especially important that confidential information
not be made to secure these
machines.

3.1.2.3 Authentication/Proxy Servers (SOCKS, FWTK)

The use of proxy servers co-located on the same host as the server. In fact, it is
recommended that the server have a dedicated host which is not
"trusted" by other internal hosts. It may be co-located with an
anonymous FTP server, since both protocols share common security technique will only continue
considerations.

3.2.3.6 File Transfer (FTP, TFTP)

FTP and TFTP allow users to expand. A proxy server provides receive and send electronic files in a number
point to point manner. Improperly configured FTP servers can allow
intruders to copy, replace and delete files at will, anywhere on a
host. TFTP does not support same range of functions, but has no
security
enhancements. It allows sites whatsoever. Access to concentrate services through a
specific machine for monitoring, hiding encrypted passwords, proprietary
data, and the introduction of internal structure, etc.
This funnelling effect creates an attractive target for trojan horses are just a potential
intruder.

3.1.2.4 Email

Electronic mail systems have traditionally been one source for
intruder break-ins. Most email servers typically accept input from
any source. Most email systems consist few of two parts, a
receiving/sending agent the
potential security holes. FTP and a processing agent. Since email is TFTP servers (especially Internet

Site Security Handbook Working Group [Page 8] 15]

Internet Draft Site Security Handbook November December 1995

delivered

accessable anonymous FTP servers) should reside on their own host.
It may be co-located with a Web server, since file transfer protocols
share common security considerations.

3.2.3.7 NFS

The Network File Service allows hosts to all users and share common disks. NFS is usually private, the processing agent
typically requires system privileges to deliver the mail. Most email
implementations perform both portions
most frequently used by diskless hosts who depend on a disk server
for all of their storage needs. Unfortunately, NFS has no built-in
security. It is therefore necessary that the service, NFS server be
accessable only by those hosts which means the
receiving agent has a direct link to system privileges. There are
several packages available which allow using it for service. It is
especially important that external hosts be unable to reach the NFS
host by any means. Ideally, such access attempts would be stopped by
a separation of firewall.

3.2.4 Protecting the two
pieces.

3.1.2.5 World Wide Web (WWW)

The WWW Protection

It is growing amazing how often a site will overlook the most obvious
weakness in popularity exponentially because of its ease of
use and security by leaving the powerful abilities security server itself open
to concentrate information services.
Most WWW servers take some directions and actions from attack. Based on considerations previously discussed, it should
be clear that: the persons
accessing their services. The most common example is taking a
request security server should not be accessible from a remote user and passing
off-site; should offer minimum access, except for the provided information authentication
function, to users on-site; and should not be co-located with any
other servers. Further, all access to a
program running on the server node, including access to process
the request. Those programs
can service itself, should be subverted easily if they are not written with security in
mind.

3.1.2.6 FTP

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

3.3 Firewalls

One of the possibilities.

3.1.3 Deny all/ Allow all

There are two diametrically oppossed underlying philosophies which
can be adopted most widely deployed and publicized security measures in defining
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 plan. Both alternatives issues. They are
legitimate models to adopt, depending on not. Firewalls are just another tool in
the site and its needs quest for system security.

The first option is to turn off all services They provide a certain level of
protection, and then selectively
enable services on are, in general, a case by case basis, be it way of implementing security
policy at the machine or network level, level. The level of security that a firewall
provides can vary as they are needed. This model, which will here after
be referred to much as the "deny all" model, is generally more secure.
More work is required to successfully implement a "deny all"
configuration and usually a better understanding of services; which
may require several pieces operating together to function correctly.
Only allowing known services allows a better analysis level of security on a particular
service/protocol, and
machine. There are the design traditional trade-offs of a security mechanism suited versus
ease of use, cost, complexity, etc.

A firewall is any one of several mechanisms used to control and watch
access to and from a network for the security level purpose of the site.

The other model, protecting it. A
firewall acts as a gateway through which will here after be referred all traffic to as and from the "allow
all" model, is much easier
protected network or machines passes. Firewalls help to implement, but is in general less
secure than the "deny all" model. Simply turn place
limitations on all services,
usually the default at the host level, amount and allow all protocols to
travel across network boundaries, usually type of communication that takes place
between the default at protected network and the router
level. As security holes become apparent, they are patched at either another network (e.g., the host
Internet, or network level.

Each another piece of these models can be applied the companyUs network).

A firewall is generally a way to different portions build a wall between one part of the
site, depending on functionality requirements, administrative

Site Security Handbook Working Group [Page 9]

Internet Draft Site Security Handbook November 1995

control, site policy etc. For a
network, a companyUs internal network, for example, and another part,
the policy may be to use the
"allow all" model when setting up workstations global Internet, for general use, but
adopt a "deny all" model when setting up information servers, like an
email hub. Likewise, an "allow all" policy may example. The unique feature about this wall
is that there needs to be adopted ways for some traffic between LAN's internal with particular
characteristics to pass through carefully monitored doors
("gateways"). The difficult part is to establish the site, but a "deny all" policy
can be adopted between the site and criteria by

Site Security Handbook Working Group [Page 16]

Internet Draft Site Security Handbook December 1995

which the Internet.

Be careful when mixing philosophies as in packets are allowed or denied access through the examples above. Many
sites adopt door.
Different books written on firewalls use different terminology to
describe the M & M theory various forms of a hard "crunchy" shell and a soft
"squishy" middle. They firewalls. This can be confusing to
system administrators who are willing not familiar with firewalls. The thing
to pay note here is that there is no fixed terminology for the cost
description of security for
their external traffic and require strong security measures, but firewalls.

Firewalls are
unwilling not always, or unable to provide similar protections internally. This
works fine as long as the outer defenses even typically, a single machine, but in
general are never breached a combination of routers, networks, and host machines, so
for the
internal users can be trusted. Once the outer shell (firewall) is
breached, subverting purposes of this discussion the internal network is trivial.

3.1.4 identify real needs for services

There is a large variety term "firewall" can consist
of services which may be provided, both
internally more than one physical device. Firewalls are typically built
using two different components, filtering routers and on proxy servers.

Filtering routers are the Internet at large. Managing security is in
many ways managing access to services internal easiest component to the site conceptualize in a
firewall. A router moves data back and
managing how internal users access information at remote sites.

Services tend forth between two (or more)
different networks. A "normal" router takes a packet from network A
and "routes" it to rush like waves over the Internet. Over its destination on network B. A filtering router
does the years
many sites have established anonymous ftp servers, gopher servers,
wais servers, www servers, etc. as they became popular same thing but decides not
particularly needed at all sites. Evaluate all new services that are
established with a skeptical attitude only how to determine if they are
actually needed or just route the current fad sweeping packet, but
*SHOULD* it route the Internet.

Bear in mind that security complexity can grow exponentially 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
number scope of services provided. Filtering routers need this
document. However, when evaluating a router to be modified
to support used for filtering
packets, the new protocols. Some protocols are inherently
difficult to filter safely (ex. rpc following criteria can be important when implementing a
filtering policy. These criteria include: source and udp services), thus providing
more openings to destination IP
address, source and destination TCP port numbers, state of the internal network. Services provided on 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 same
machine router reorders
filter instructions (designed to optimize filters, this can interact in catastrophic ways. (ex. allowing anonymous
ftp sometimes
change the meaning and cause unintended access), and whether it is
possible to apply filters for inbound and outbound packets on each
interface (if the same machine as router filters only outbound packets then the www server
router is "outside" of its filters and may allow an intruder be more vulnerable to
place a file in
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 anonymous ftp area ability to create filters based on IP
header options and cause the http server to
execute it.)

3.2 Network fragment state of a packet. Building a good
filter can be very difficult and Service Configuration

3.2.1 Protecting requires a good understanding of the Infrastructure

Many network administrators go to great lengths to protect
type of services(protocols) that will be filtered.

For better security the hosts
on their networks. Few administrators make any effort filters usually restrict access between the
two connected nets to protect just one host --- the
networks themselves. There bastion host. It is some rationale only
possible to this. For example, access the other network via this bastion host. As only
this host, rather than a few hundred hosts, can get attacked it is far
easier to protect maintain a certain level of security, because only this
host than a network. Also, intruders
are likely has to be after data on the hosts; damaging protected very carefully. To make resources available
to legitimate users across this firewall, services have to be
forwarded by the network would
not serve their purposes. That said, there are still reasons bastion host. Some servers have forwarding built in
(like DNS-servers or SMTP-servers), for other services (like Telnet,
FTP,...) proxy servers can be used to allow access to
protect the networks. For example, an intruder might divert network
traffic through an outside host resources

Site Security Handbook Working Group [Page 17]

Internet Draft Site Security Handbook December 1995

across the firewall in order a secure way. A proxy server is way to
concentrate application services through a single machine. There is
typically a single machine (the bastion host) that acts as a proxy
server for a variety of protocols (Telnet, SMTP, FTP, HTTP, etc.) but
there can be individual machines for each service. Instead of
connecting directly to examine an external server, the data (i.e., client connects to search for passwords). Also, infrastructure includes more than
the networks and the routers
proxy server which interconnect them. Infrastructure

Site Security Handbook Working Group [Page 10]

Internet Draft Site Security Handbook November 1995

also includes network management (e.g., SNMP), services (e.g., DNS,
NFS, NTP, WWW), and security (i.e., user authentication and access
restrictions).

The infrastructure also needs protection against human error. When
an administrator misconfigures a host, that host may offer degraded
service. This only affects users who require that host, and unless
that host is in turn initiates a primary server, connection to the number requested
external server. Depending on the type of affected users will
therefore be limited. However, if a router proxy server used, it is misconfigured, all
users who
possible to configure internal clients to perform this redirection
automatically without knowledge to the user, others might require
that 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 user connect directly to the Network proxy server and then initiate
the connection through a specified format.

There are several problems to significant security benefits which networks are vulnerable. The
classic can be derived from
using proxy servers. It is a "denial possible to add access control lists to
protocols, requiring users or machines to provide some level of service" attack. In this case, the network
authentication before access is brought to a state in granted. Smarter proxy servers,
sometimes called Application Layer Gateways (ALGs), can be written
which it understand specific protocols, and can no longer carry legitimate
users' data. There are two common ways this be configured to block
only subsections of the protocol. For example, an ALG for FTP can be done: by
attacking
tell the routers difference between the "put" command and by flooding the network with extraneous
traffic. "get" command.
An attack on the router is designed to cause it organization may wish to stop
forwarding packets, or allow users to forward them improperly. The former case
may "get" files from the
Internet, but for whatever reason not be due able to take internal files
and "put" them on a misconfiguration, the injection of remote server. By contrast a spurious routing
update, filtering router
could either block all FTP access or none but not a "flood attack" (i.e., the router is bombarded with
unroutable packets, causing its performance subset.

Proxy servers can also be configured to degrade). A flood
attack encrypt data streams based on
a network is similar variety of parameters. An organization might use this feature to a flood attack
allow encrypted connections between two locations whose sole access
points are on a router, except
that the flood packets Internet.

Firewalls are usually broadcast. An ideal flood attack
would be the injection typically thought of as a single packet which exploits some known
flaw in the network nodes and causes them way 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 keep intruders out,
but they are sent to one or more routers causing them to
misroute packets. This differs from also often used as a denial of service attack only
in the purpose behind the spurious route. In denial of service, the
object is way to make the router unusable; let legitimate users into a
site. There are many examples where a state which will be quickly
detected by network users. In spoofing, valid user might need to
regularly access the spurious route will
cause packets "home" site while traveling, at trade shows and
conferences, etc. Access to the Internet is usually available but
may be routed to a host from which through an intruder may
monitor the data in untrusted machine or network. A correctly setup
proxy server can allow the packets. These packets are then be re-routed
to their correct destinations. However, users into the intruder may 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 may not
have altered more proxy
servers on a network between the contents of two routers. This setup allows the packets.

The solution
external router to most of these problems is block off any attempts to protect use the routing
update packets sent by underlying IP
layer to break security (IP spoofing, source routing, packet
fragments), while allowing 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 proxy server to handle potential
security holes in the
physical networks. Passwords also offer some protection against
misconfigured routers (i.e, TCP protocols. The internal routers which, out of the box, attempt purpose is
to
route packets). The advantage of passwords block all traffic except to the proxy server. If this setup is that they have
rigidly implemented a very
low overhead, in both bandwidth and CPU consumption. Checksums
protect against the injection high level of security can be achieved.

Firewalls provide logging which can be tuned to make security
administration of spurious packets, even if the
intruder has direct access to network more convenient. Logging may be
centralized and the physical network. Combined with a system may be configured to send out alerts for
abnormal conditions. It is important to regularly monitor these logs

Site Security Handbook Working Group [Page 11] 18]

Internet Draft Site Security Handbook November December 1995

sequence number,

for any signs of intrusions or other unique identifier, a checksum can also
protect again "replay" attacks, wherein an old (but valid at the
time) routing update is retransmitted break-in attempts. Since some
intruders will attempt to cover their tracks by either an intruder or a
misbehaving router. The most security editing logs, it is provided by complete
encryption
desirable to protect these logs. A variety of sequenced, methods is available
including write once, read many (WORM) drives, papers logs, or uniquely identified, routing updates.
This prevents an intruder from determining
centralized logging via the topology of "syslog" utility. Another technique is
to use a "fake" serial printer, but have the
network. The disadvantage serial port connected to encryption is
an isolated machine or PC which keeps the overhead involved logs.

Firewalls are available in
processing the updates.

RIP-2 (RFC 1723) a wide range of quality and OSPF (RFC 1583) both support clear-text
passwords in their base design specifications. In addition, there
are extensions to each base protocol strengths.
Commercial packages start at approximately $10,000 US and go up to support MD5 encryption.

Unfortunately, there is no adequate protection against
over $250,000 US. "Home grown" firewalls can be built for smaller
amounts of capital . It should be remembered that the correct setup
of a flooding
attack, firewall (commercial or homegrown) requires a misbehaving host or router which is flooding the
network. Fortunately, this type significant amount
of attack is obvious when it occurs skill and can 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 terminated relatively simply.

3.2.3 Protecting considered in addition to the Services

There are many types cost of services; each has its own security
requirements. These requirements will vary based on the intended use physical
elements of the service. For example, firewall.

As an aside, building a service which "home grown" firewall requires a significant
amount of skill and knowledge of TCP/IP. It should only not be usable
within trivially
attempted because a site (e.g., NFS) requires little protection. That is,
protecting perceived sense of security is worse in the server from external access long
run than knowing that there is sufficient no security. As with all security
measures it is important to protect
the service. However, a WWW server, which provides a home page
intended for viewing by users anywhere decide on the Internet, requires
built-in protection. That is, threat, the service/protocol/server must
provide whatever security may be required to prevent unauthorized
access and modification value of the Web database.

Internal services (i.e., services meant
assets to be used only by users
within a site) protected and external services (i.e., services deliberately
available to users outside a site) will, in general, have protection
requirements which differ as previously described. It is therefore
wise to isolate the internal services costs to one set of server machines implement security.

A final note about firewalls. They can be a great aid when
implementing security for a site and the external services to another set they protect against a large
variety of server machines. That
is, internal and external servers should not be co-located. In fact,
many sites go so far as attacks. But it is important to have one set of subnets (or even different
networks) which keep in mind that they are accessible from the outside and another set which
may be accessed
only within one part of the site. Of course, there is usually solution. They canUt protect your site against
all types of attack.

4. SECURITY SERVICES AND PROCEDURES

This chapter guides the reader through a
firewall which connects these partitions. Great care must be taken
to ensure number of topics that such should
be addressed when securing a firewall is operating properly.

One form of external site. Each section touches on a
security service deserves some special consideration, and
that is anonymous, or guest, access. This capability that may be either anonymous
FTP or guest (unauthenticated) login. It is extremely important required to
ensure that anonymous FTP servers and guest login userids are
carefully isolated from any hosts protect the
information and file systems from which outside
users should be kept. Another area at a site. These are presented in a fairly
high-level to which special attention must
be paid concerns anonymous, writable access. A site may be legally
responsible for introduce the content reader to the concepts.

Throughout the chapter, you will find considerable mention of publicly available information, so
careful monitoring
cryptography. It is outside the scope of this document to delve into
details concerning cryptography and we point the information deposited reader to a small
appendix on the subject. If you would like more details on this
subject, please see [ref to Bruce Schnier sp?]

4.1 Authentication

For many years, the prescribed method for authenticating users has
been through the use of standard, reusable passwords. Originally,
these passwords were used by anonymous users is
advised. at terminals to authenticate
themselves to a central computer. At the time, there were no
networks (internally or externally) and hence the risk of disclosure
of the clear text password was minimal. Today, systems are connected

Site Security Handbook Working Group [Page 12] 19]

Internet Draft Site Security Handbook November December 1995

3.2.4 Protecting the Protection

It is amazing how often a site will overlook

together through local networks, and those local networks are further
connected together, and to the most obvious
weakness Internet. Users are logging in its security by leaving from
all over the security server itself open globe, and their reusable passwords are often
transmitted across those same networks in clear text, ripe for anyone
in-between to attack. Based on considerations previously discussed, it should
be 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 that: text
passwords. To address this threat, we are including sections on
better technologies like one-time passwords, and Kerberos.

With the security server should not be accessible from
off-site; should offer minimum access, except for advent of newer technologies like one-time passwords (e.g.,
S/Key), PGP, and token-based authentication devices, people are using
password- like strings as secret tokens and pins. We are including a
discussion on these since they are the foundation upon which stronger
authentication
function, to users on-site; techniques are based. If these secret tokens and should pins
are not properly selected and protected, the authentication will be co-located with any
other servers. Further, all access to
easily subverted.

4.1.1 One-Time passwords

As mentioned above, given today's networked environments, it is
recommended that sites concerned about the security and integrity of
their systems and networks consider moving away from standard,
reusable passwords. There have been many incidents involving Trojan
network programs (e.g., telnet and rlogin) and network packet
sniffing programs. These programs capture clear text hostname,
account name, password triplets. Intruders can use the node, including captured
information for subsequent access to those hosts and accounts. This
is possible because 1) the service itself, should be logged to provide a "paper trail" in password is used over and over (hence the event of a security breach.

3.3 Firewalls

4. SECURITY PROCEDURES

4.1 Authentication

For many years,
term "reusable"), and 2) the prescribed method for authenticating users has
been through password passes across the use of standard, reusable passwords. Originally, network in
clear text.

Several authentication techniques have been developed that address
this problem. Among these techniques are challenge-response
technologies that provide passwords were that are only used by users at terminals to authenticate
themselves once (commonly
called one-time passwords). This document provides a list of sources
for products that provide this capability. The decision to use a central computer. At the time, there were no
networks (internally or externally) and hence
product is the risk of disclosure responsibility of the cleartext password was minimal. Today, systems are connected
together through local networks, each organization, and those local networks are further
connected together, each
organization should perform its own evaluation and to the Internet. Users are logging in from
all over the globe, selection.

4.1.2 Kerberos

4.1.3 Choosing and their reusable passwords are often
transmitted across those same networks in cleartext, ripe for anyone
inbetween Protecting Secret Tokens and Pins

When selecting secret tokens, take care to capture. And indeed, choose them carefully.
Like the CERT Coordination Center selection of passwords, they should be robust against brute
force efforts to guess them. That is, they should not be singles
words in any language, any common, industry, or cultural acronyms,
etc. Ideally, they will be longer rather than shorter and
other response teams are seeing a tremendous number consist of incidents
involving packet sniffers which are capturing the cleartext
passwords. To address this threat, we are including sections on
better technologies like one-time passwords,
pass phrases that combine upper and Kerberos.

With lower character, digits, and
other characters.

Site Security Handbook Working Group [Page 20]

Internet Draft Site Security Handbook December 1995

Once chosen, the advent protection of newer technologies like one-time passwords (e.g.,
S/Key), PGP, and token-based authentication devices, people are using
password- like strings as these secret tokens and pins. We is very important.
Some are including a
discussion on used as pins to hardware devices (like token cards) and
these since they are should not be written down and placed in the foundation upon same location as
the device to which stronger
authentication techniques they are based. If these associated. Others, such as a secret tokens PGP
key, should be protected from unauthorized access.

One final word on this subject. When using a cryptography products,
like PGP, take care to determine the proper key length and pins ensure
that your users are not properly selected and protected, trained to do likewise. As technology advances,
the authentication minimum safe key length continues to grow. Make sure your site
keeps up with the current state of knowledge on the subject so that
you can ensure any cryptography used will be
easily subverted.

4.1.1 One-Time providing you the
protection you are assuming it is.

4.1.4 Password Assurance

While the need to eliminate the use of standard, reusable passwords

As mentioned above, given today's networked environments,
cannot be overstated, it is
recommended recognized that sites concerned about some organizations may
have to transition to the use of better technology. Given that
situation, we have included the security following advice to help with the
selection and integrity maintenance of
their systems and networks consider moving away from standard,
reusable traditional passwords. There have been many incidents involving Trojan
network programs (e.g., telnet and rlogin) and network packet
sniffing But remember,
none of these measures provides protection against disclosure due to
sniffer programs. These programs capture cleartext hostname,
account name, password triplets. Intruders can use

(1) The importance of robust passwords - In many (if not most) cases of
system penetration, the captured
information for subsequent intruder needs to gain access to those hosts an account
on the system, and accounts. This one way that goal is possible because 1) the password typically accomplished is used over and over (hence the
term "reusable"), and 2)
through guessing the password passes across the network in

Site Security Handbook Working Group [Page 13]

Internet Draft Site Security Handbook November 1995

clear text.

Several authentication techniques have been developed that address
this problem. Among these techniques are challenge-response
technologies that provide passwords that are only used once (commonly
called one-time passwords). This document provides a list of sources
for products that provide this capability. The decision to use a
product legitimate user. This is often
accomplished by running an automated password cracking program,
which utilizes a very large dictionary, against the responsibility of each organization, and each
organization should perform its own evaluation and selection.

4.1.2 Kerberos

4.1.3 Choosing and Protecting Secret Tokens and Pins

4.1.4 Password Assurance

While the need system's password
file. The only way to eliminate guard against passwords being disclosed in this
manner is through the use careful selection of standard, reusable passwords which cannot be overstated, it is recognized
easily guessed (i.e., combinations of numbers, letters, and punctuation
characters).

(2) Changing default passwords - Many operating systems and application
programs are installed with default accounts and passwords. These
must be changed immediately to something that some organizations may
have cannot be guessed or
cracked.

(3) Restricting access to transition the password file - In particular, a site
wants to protect the use encrypted password portion of better technology. Given the file so that
situation, we
would-be intruders don't have included the following advice them available for cracking. One
effective technique is to help with use shadow passwords where the
selection and maintenance of traditional passwords. But remember,
none password
field of these measures provides protection against disclosure due to
sniffer programs.

(1) the standard file contains a dummy or false password. The importance of robust
file containing the legitimate passwords are protected elsewhere on
the system.

(4) Password aging - In many (if 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 most) cases 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
system penetration, the intruder needs continued use of penetrated

Site Security Handbook Working Group [Page 21]

Internet Draft Site Security Handbook December 1995

accounts. However, the opposition claims that frequent password
changes lead to users writing down their passwords in visible areas
(such as pasting them to gain access a terminal), or to users selecting very simple
passwords that are easy to guess. It should also be stated that an account
on
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 system, issue and one way provide guidelines for how often
a user should change the password. It is recommended that goal passwords
be changed whenever root is typically accomplished penetrated, there is
through guessing the password of a legitimate user. This critical change in
personnel (especially if it is often
accomplished by running the system administrator!), or when an automated password cracking program,
which utilizes a very large dictionary, against
account has been compromised. In particular, if the system's root password
file. The only way to guard against passwords being disclosed in this
manner is through the careful selection of
compromised, all passwords which cannot on the system should be
easily guessed (i.e., combinations of numbers, letters, and punctuation
characters).

(2) Changing default passwords - Many operating systems and application
programs are installed with default accounts changed. In
addition, an annual change in their password is usually not difficult
for most users, and passwords. These
must you should consider requiring it.

4.2 Confidentiality

There will be changed immediately 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 something provide confidentiality is through
encryption. Encryption is accomplished by scrambling data so that cannot be guessed it
is very difficult and time consuming for anyone other than the
authorized recipients or
cracked.

(3) Restricting access owners to obtain the password file - In particular, a site
wants to protect plain text. Authorized
recipients and the encrypted password portion owner of the file so information will possess the
corresponding decryption keys that
would-be intruders don't have allow them available for cracking. One
effective technique to easily unscramble
the text to a readable (clear text) form. We recommend that sites use
encryption to provide confidentiality to protect valuable
information.

The use of encryption is sometimes controlled by govermental and site
regulations, so we encourage administrators to become informed of
laws or policies that regulate its use shadow passwords where before employing it. It is
outside the password
field scope of this document to discuss the standard file contains a dummy or false password. The
file containing various algorithms
and programs available for this purpose, but we do caution against
the legitimate passwords are protected elsewhere on casual use of the system.

(4) Password aging - When and how UNIX crypt program as it has been found to expire passwords is still a subject be
easily broken. We also encourage you to take time to understand the
strength of
controversy among the security community. It is generally accepted encryption in any given algorithm/product before
using it. Most well- known products are well-documented in the
literature, so this should be a fairly easy task.

4.3 Integrity

As an administrator, you will want to make sure that information
(e.g., operating system files, company data, etc.) has not been
altered in an unauthorized fashion. This means you will want to
provide some assurance as to the integrity of the information on your

Site Security Handbook Working Group [Page 14] 22]

Internet Draft Site Security Handbook November December 1995

a password should not be maintained once an account is no longer in use,
but it

systems. One way to provide this is hotly debated whether a user should be forced to change produce a
good password that's in active use. The arguments for changing
passwords relate checksum of the
unaltered file, store that checksum offline, and periodically (or
when desired) check to make sure the prevention checksum of the continued use of penetrated
accounts. However, online file
hasn't changed (which would indicate the opposition claims that frequent password changes
lead to users writing down their passwords in visible areas (such data has been modified).

Some operating systems come with checksumming programs, 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
UNIX sum program. However, these may not provide guidelines for how often
a user should change the password. It is recommended that passwords protection you
actually need. Files can be
changed whenever root is penetrated, there is a critical change modified in
personnel (especially if it is such a way as to preserve the system administrator!), or when an
account has been compromised. In particular, if
result of the root password is
compromised, all passwords on UNIX sum program! Therefore, we suggest that you use a
cryptographically strong program such as the system should message disgesting
program MD5 [ref] to produce checksums you will be using to assure
integrity.

There are other applications when integrity will want to be changed. In
addition, assured,
such as when transmitting an annual change in their password is usually not difficult
for most users, email message between two parties, and
there are products available that can provide this capability. The
purpose of this section is to acquaint you should consider requiring with this concept so that
you can apply it where needed. Once you identify that this is a
capability you need, you can go about identifying technologies that
will provide it.

4.2

4.4 Authorization

Authorization refers to the process of granting privileges to
processes and ultimately users. This differs from authentication in
that authentication is what occurs to identify a user. Once
identified (reliably), the privileges, rights, property, and
permissible actions of the user are determined by authorization.

Should "objects" and "entities" be defined here?>

Explicity listing the authorized activities of each user (and user
process) with respect to all resources (objects) is impossible in a reasonable
system. In a real system certain techniques all resources (objects) is impossible in a
reasonable system. In a real system certain techniques are used to
simplify the process of granting and checking authorization(s).

One approach, popularized in UNIX systems, is to assign to each
object three classes of user - the super user, the owner, and the
group. Super user, or root, is an entity that has access to all
portions (and objects) of the computer. The owner of an object is
the "user" who either created the object or was given it by the super
user. A group is a collection of users that share privileges over a
collection of objects. Groups ease authorization management by
simplifying the process of changing the authorization of users and by
changing the authority of a group to manage an object.

Another approach is to attach to an object a list which explicitly
contains the identity of all permitted users (or groups). This is an
Access Control List. The advantage of these are that they are easily
maintained (one central list per object).

4.5 Access

4.5.1 Physical Access

Restrict physical access to areas containing hosts to people who are used

Site Security Handbook Working Group [Page 23]

Internet Draft Site Security Handbook December 1995

supposed to simplify use the
process of granting hosts. Hosts include 'trusted' terminals (such
as system consoles, operator terminals and checking authorization(s).

One approach, popularized in UNIX systems, is terminals dedicated to assign
special tasks such as backup) and individual microcomputers and
workstations, especially those connected to each
object three classes your network. Make sure
access restrictions mesh well with people's work patterns, otherwise
they will find ways to circumvent your physical security, e.g.
jamming doors open.

Keep original and backup copies of user - the super user, the owner, data and the
group. Super user, or root, programs safe. Apart from
keeping them in good condition for backup purposes, they must be
protected from theft.

Portable hosts are a particular risk. Make sure it won't cause
problems if one of your staff's portable computer is an entity stolen. Consider
developing guidelines for the kinds of data that has access should be allowed to all
portions (and objects) of
reside on the computer. The owner disks of an object is
the "user" who either created portable computers as well as how the object or was given data
should be protected (e.g., encryption) when it by the super
user. A group is on a collection of portable
computer.

Other areas where physical access should be restricted is the wiring
closets and important network elements like file servers, name server
hosts, and routers.

4.5.2 Walk-up Network Connections

By 'walk-up' connections we mean sockets located so as to provide a
convenient way for users that share privileges over to connect a
collection 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 objects. Groups ease authorization attacks via techniques such as
IP address spoofing, packet sniffing, etc. Users and site management by
simplifying
must appreciate the process of changing risks involved. If you decide to provide walk-up
connections, plan the authorization of users service carefully, and by
changing define precisely where
you will provide it so that you can provide the authority of a group to manage an object.

Another approach necessary physical
access security.

A walk-up host should be authenticated before its user is permitted
to attach to access resources on your network. As an object a list which explicitly
contains alternative it may be
possible to control physical access, for example if the identity of all permitted users (or groups). This service is to
be used by students you might only provide walk-up connection sockets
in student laboratories.

Keep an
Access Control List. The advantage of these are that they are easily
maintained (one central list per object).

<NOTE: What other methods (short phrases eye on empty offices. It may be sensible to disconnect
connections to unused offices at the wiring closet. Consider using
secure hubs, and monitoring attempts to connect unauthorized hosts.

4.5.3 Other Network Technologies

Technologies considered here include X.25, ISDN, SMDS, DDS and Frame
Relay. All are all that's needed, I
probably know what they refer to) should provided via physical links which go through
telephone exchanges, providing the potential for them to be mentioned... > diverted.
Crackers are certainly interested in telephone switches as well as in
data networks!

Site Security Handbook Working Group [Page 15] 24]

Internet Draft Site Security Handbook November December 1995

<NOTE: Should the process of deciding what authorizations are to be
granted be described here (or

With switched technologies, use Permanent Virtual Circuits or Closed
User Groups whenever this is that in policies)? Should
mechanisms be described here? >

4.3 Access

4.4 possible. Technologies which provide
authentication and/or encryption (such as IPv6) on data links are
evolving rapidly. Consider using them on links where security is
important.

4.5.4 Modems

4.4.1

4.5.4.1 Modem lines must be managed

Although they provide convenient access to a site for its users, they
can also provide an effective detour around the site's firewalls.
For this reason it is essential to maintain proper control of modems.

Don't allow users to install a modem line without proper
authorization. This includes temporary installations, e.g. plugging
a modem into a facsimile or telephone line overnight.

Maintain a register of all your modem lines. Conduct regular site
checks for unauthorized modems; keep your register up to date.

4.4.2

4.5.4.2 Dial-in users must be authenticated

A username and password check should be completed before a user can
access anything on your network. Normal password security
considerations (such as choosing passwords which don't appear in
dictionaries and changing them from time to time) are particularly
important.

Remember that telephone lines can be tapped, and that it is quite
easy to intercept messages to cellular 'phones. Modern high-speed
modems use more sophisticated modulation techniques -, which makes
them somewhat more difficult to monitor - but it is prudent to assume
that hackers know how to eavesdrop on your lines. For this reason
you should use one-shot passwords (e.g. skey) or hardware
authentication devices (e.g. SecureID) SecurID) if this is at all possible.

It is helpful to have a single dial-in point, e.g. a single large
modem pool, so that all users are authenticated in the same way.

Users will occasionally mis-type a password. Set a short delay - say
two seconds - after the first and second failed logins, and force a
disconnect after the third. This will slow down automated password
attacks. Don't tell the user whether the username, the password or
both were incorrect.

4.4.3

4.5.4.3 All logins (successful and unsuccessful) should be logged

Don't keep correct passwords in the log, but consider keeping
incorrect passwords to aid in detecting password attacks. However,
bear in mind that most incorrect passwords are correct passwords with
one character mistyped, and may suggest the real password. If you
can't keep this information secure, don't log it at all.

Site Security Handbook Working Group [Page 16] 25]

Internet Draft Site Security Handbook November December 1995

If Calling Line Identification is available, take advantage of it by
recording the calling number for each login attempt. Be sensitive to
the privacy issues raised by Calling Lne Line Identification. Also be
aware that Calling Line Identification is not to be trusted; use the
data for informational purposes only, not for authentication. <NOTE:
it was suggested that we add " Caller ID data can be read from a
compatible modem via a serial line" >

4.4.5

4.5.4.4 Minimize the amount of information given in your opening banner

In particular, don't announce the type of host hardware or operating
system - this encourages specialist hackers.

Display a short banner, but don't offer an 'inviting' name (e.g.
University of XYZ, Student Records System). Instead, give your site
name, a short warning that all sessions are monitored, and a
username/password prompt. Get your site's lawyers to check your
banner to make sure it states your legal position correctly.

For high-security applications, consider using a 'blind' password,
i.e. give no response to an incoming call until the user has typed in
(without any echoing) a password. This effectively simulates a dead
modem.

4.4.6

4.5.4.5 Call-back Capability

Some dial-in servers offer call-back facilities, i.e. the user dials
in and is authenticated, then the system disconnects the call and
calls back on a specified number. You will probably have to pay the
charges for such calls.

This feature should be used with caution; it can easily be bypassed.
As a minimum, make sure that the return call is never made from the
same modem as the incoming one. Overall, although call-back can
improve modem security, you should not depend on it alone.

4.4.7

4.5.4.6 Dial-out authentication

Dial-out users should also be authenticated, particularly since your
site will have to pay their telephone charges.

Never allow dial-out from an unauthenticated dial-in call, and
consider whether you will allow it from an authenticated one. The
goal here is to prevent callers using your modem pool as part of a
chain of logins. This can be hard to detect, particularly if a
hacker sets up a path through several hosts on your site.

As a minimum, don't allow the same modems and phone lines to be used
for both dial-in and dial-out. This can be implemented easily if you
run separate dial-in and dial-out modem pools.

4.4.8

4.5.4.7 Make your modem programming as 'bullet-proof' as possible

Be sure modems can't be reprogrammed while they're in service. As a

Site Security Handbook Working Group [Page 17] 26]

Internet Draft Site Security Handbook November December 1995

minimum, make sure that three plus signs won't put your dial-in
modems into command mode!

Program your modems to reset to your standard configuration at the
start of each new call. Failing this, make them reset at the end of
each call. This precaution will protect you against accidental
reprogramming of your modems.

Check that your modems terminate calls cleanly. When a user logs out
from an access server, verify that the server hangs up the 'phone
line properly. It is equally important that the server forces
logouts from whatever sessions were active if the user hangs up
unexpectedly.

4.5 Cryptography

4.6 Auditing

This section covers the procedures for collecting data generated by
network activity that may be useful in analyzing the security of a
network and/or useful in responding to a security incident. This
section also covers the handling, preservation, and utilization of
the data.

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

4.6.1 What to collect

Audit data should include any attempt to achieve a different security
level of any person, process, or other entity in the network. The
most obvious example in this area is a log of attempts to login to a
host computer.

Audit data should also include data pertaining to any "public" or
anonymous access and retrieval of data, at least to the granularity
of the "remote" host.

And on and on...

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

4.6.2 Collection Process

The collection process should be enacted by the host or resource
being accessed. Depending on the importance of the data and the need
to have it local in instances in which services are being denied,
data could be kept local to the resource until needed or be
transmitted to storage after each event.

Reporting data can be done by writing to a file, writing to a line
printer, writing over a network, or writing over a non-network port,
such as a console port. Each of these has importance.

Site Security Handbook Working Group [Page 18]

Internet Draft Site Security Handbook November 1995

File system logging is the least resource intensive of all four
candidates (for a given audit log). It is also the least reliable.
If a resource has been compromised, the file system is the first to
go. If the network in front of the resource has become unusable, the
data is inaccessible, unless a direct console port is available.

Line printer logging is useful in system where permanent and
immediate logs are required. A real time system is an example of
this, where the exact point of a failure or attack must be recorded.

Site Security Handbook Working Group [Page 27]

Internet Draft Site Security Handbook December 1995

A laser printer, or other device which buffers data between the
auditing system and storage device may suffer from lost data if
buffers contain the needed data at a critical instant.

Reporting over the network provides for allowing a remote host to
store data in a more permanent and possibly more reliable manner.
However, this consumes bandwidth (at the minimum), exposes the audit
data in an easy package to a interloper, and could be lost during
network denial.

Reporting over a console port ensures the delivery of the data
follows the hardware design. The limitations are that the console
port requires physical security and using console ports on machines
more than a short distance away (e.g., across a campus) may require a
phone line in addition to the network connection. In some instances,
this is one more resource that may be constrained.

4.6.3 Collection Load

Collecting running data may result in a quick accumulation of bytes.
Storage of this must be considered in advance. There are a few ways
to limit the required storage space. Data may be compressed using
one of many methods. Another approach is to only archive summaries
of activity (possibly losing some detail in the process). Data may
be archived for just a fixed period of time, then is it permanently
removed.

The issue of archiving security data differs from archiving network
management and application data. Network management data
(statistics) can be reduced by altering the reporting period.
Security data does not have that option (for the most part).
Security data also does not have the permanence of application data.

4.6.4 Handling the Data/Preservation

Security data should be protected as least as much as any other data
is protected because from it, much can be inferred. Security data
may give away enough secrets to allow a "masquerader" to impersonate
an authorized administrator.

Data may also become key to the investigation, apprehension, or
prosecution of the perpetrator of an incident. Because of this, the
data needs to be protected and clearly documented. For this reason
it is advisable to seek the advice of local legal council or law
enforcement when deciding how security data is to be treated. This

Site Security Handbook Working Group [Page 19]

Internet Draft Site Security Handbook November 1995
should happen before an incident occurs.

If a data handling plan is not cleared prior to an incident, this
does not mean that it is useless. It means two things. You may not
have recourse in the aftermath of an event. You may also me liable
for penalties resulting from your treatment of the data too.

4.6.5 Audit Data Precautions

Site Security Handbook Working Group [Page 28]

Internet Draft Site Security Handbook December 1995

In certain instances, audit data may contain personal information.
Searching through the data, even for just a routine check of the
network's security could present an invasion of privacy or make the
auditing entity privy to information it should not be allowed to
have. Note that this is not automatically true - not all data is
"sensitive" and "sensitive" differs by locale.

Another danger presented by auditing data is that it may reveal a
pattern of incidents. If an organization knows about the incidents
but permits them to continue and this results in damage to another
organization ("downstream"), legal action could result. An
organization may also be liable for not (making a "best effort" to)
analyze this data for incidents.

4.7 Backups SECURING BACKUPS

The procedure of creating backups is a classic part of operating a
computer system. Within the context of this document, backups are
addressed as part of the overall security plan of a site. There are
several aspects to backups that are important within this context:

(1) Make sure your site is creating backups
(2) Make sure your site is using offsite storage for backups
(3) Consider encrypting your backups to provide additional protection of
the information once it is off-site. However, be aware that you will
need a good key management scheme so that you'll be able to recover
data at any point in the future. Also, make sure you will have
access to the necessary decryption programs at such time in the
future when you need to perform the decryption.
(4) Don't always assume that your backups are good. There have been
many instances of computer security incidents that have gone on for
long periods of time before a site has noticed the incident. In such
cases, backups of the affected systems are also tainted.
(5) Periodically check your backups.

5. SECURITY INCIDENT HANDLING

This section of the document will supply guidance to be applied
before, during, and after a computer security incident is in progress
on a machine, network, site, or multi-site environment. The
operative philosophy in the event of a breach of computer security is
to react according to a plan. This is true whether the breach is the
result of an external intruder attack, unintentional damage, a
student testing some new program to exploit a software vulnerability,
or a disgruntled employee. Each of the possible types of events
described above ,
such as those just listed, should be addressed in advance by an adequate
contingency plans.
Without a proactive approach to protect the assets in case of an
incident the handling process can not be as efficient as with well
prepared procedures, methods and policies in place.

Traditional computer security, while quite important in the overall
site security plan, usually falls heavily on protecting systems from
attack, and perhaps monitoring systems to detect attacks. Little pays little attention is usually paid for to how to actually
handle the attack when once it occurs. The result is that when an attack
is in progress, many decisions are made in haste and can be damaging
to tracking down the source of the incident, collecting evidence to

Site Security Handbook Working Group [Page 29]

Internet Draft Site Security Handbook December 1995

be used in prosecution efforts, preparing for the recovery of the
system, and protecting the valuable data contained on the system.

One of the most important but often overlooked benefit benefits for efficient
incident handling is an economic one. Having both technical and
managerial personnel respond to an incident requires considerable
resources, resources which could be utilized more profitably if an

Site Security Handbook Working Group [Page 20]

Internet Draft Site Security Handbook November 1995

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

Due to the worldwide world-wide network most of the incidents are not restricted to one site only.
a single site. Operating systems vulnerabilities apply (in some
cases) to several millions of systems systems, and many vulnerabilities are
exploited within the network itself. Therefore it is vital for all
sites that all involved parties are informed as soon as possible.

Another benefit is related to public relations. News about computer
security incidents tends to be damaging to an organization's stature
among current or potential clients. Efficient incident handling
minimizes the potential for negative exposure.

A final benefit of efficient incident handling is related to legal
issues. It is possible that in the near future organizations may be
sued because one of their nodes was used to launch a network attack.
In a similar vein, people who develop patches or workarounds may be
sued if the patches or workarounds are ineffective, resulting in
damage to systems, or if the patches or workarounds themselves damage
systems. Knowing about operating system vulnerabilities and patterns
of attacks and then taking appropriate measures is critical to
circumventing possible legal problems.

This sections in this chapter is arranged such that a list of relevant topics may be
drawn from the following outline, to provide a an outline and starting point
for creating a your sites policy for handling ongoing security incidents. The main points to
be included in a policy for handling incidents
sections are:

(1) Preparing and planning (what are the goals and objectives in
handling an incident).
(2) Notification (who should be contacted in the case of an incident).
(3) Evaluation (how serious is the incident).
(4) Handling (what should be done when an incident occurs).
This especially includes:
- Notification (who should be notified about the incident).
- Containment (how can the damage be limited).
- Eradication (eliminate (how to eliminate the reasons for the incident).
- Recovery (how to reestablish service and systems).
- Follow Up (what actions should be taken after the incident).
- Legal/Investigative implications (what are the legal and
prosecutorial implications of the incident).
- Documentation Logs (what records should be kept from
before, during, and after the incident).
(5) Aftermath (overall (what are the implications of past incidents).
(6) Responsibilities (for planning and handling (how to handle an incident). incident responsibly).

Each of these points subjects is important in an overall plan for handling
incidents. The remainder of this chapter will detail the issues
involved in each of the relevant topics, and provide some guidance as
to what should be included in a site policy for handling incidents.

Guidelines for End User involvement in dealing with compromised

Site Security Handbook Working Group [Page 21] 30]

Internet Draft Site Security Handbook November December 1995

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

to what should be included in dealing with incidents are the
"Guidelines and Recommendations a site policy for Incident Processing" [RFC xxx]. 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. occurs in the first place. This
includes establishing a suitable level of protections as explained
in the chapters before. Not only are
incidents avoided through Doing this protection but if the incident becomes
severe, the should help your site prevent
incidents as well as limit potential damage which can occur is limited. 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. As explained for the
site specific contingency plan in section xxx it It is vitally important to test the
proposed plan before an incident actually occurs through 'dry runs'. A team
might even consider hiring a tiger team to act in parallel with the
dry run.

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

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

(1) protect protecting the assets which are to protect by normal security
in case of a worst event could be compromised
(2) protect your protecting resources which could be utilized more profitably
if an incident did not require their services
(3) take taking care that (government) (government or other) regulations are complied
with
(4) prevent preventing the use of your systems in attacks against other
systems (which could incur legal liability)
(5) minimize minimizing the potential for negative exposure

As in any set of pre-planned procedures, attention must be placed on
a set of goals for handling an incident. These goals will be
prioritized differently depending on the site. The set of goals will
be closely related to the goals for security in general. Therefore,
the same guidelines as in section xxx for security in general might
be applied here. A specific set of
objectives can be identified for dealing with incidents:

Site Security Handbook Working Group [Page 22]

Internet Draft Site Security Handbook November 1995

(1) Figure out how it happened.
(2) Find out how to avoid further exploitations. exploitation of the same
vulnerability.
(3) Avoid escalation and further incidents.
(4) Recover from the incident.
(5) Find out who did it.

Due to the nature of the incident there might be a conflict between
analyzing the original source of a problem instead of restoring
systems and services. In this case overall goals (like assuring the
integrity of (life) critical systems) might be the reason for not
analyzing an incident. Of course this is an important management
decision, but all involved parties must be aware that without a
analysis the same incident may happen again.

It is important to prioritize actions to be taken during an incident
well in advance of the time an incident occurs. Sometimes an
incident may be so complex that it is impossible to do everything at
once to respond to it; priorities are essential. Although priorities

Site Security Handbook Working Group [Page 31]

Internet Draft Site Security Handbook December 1995

will vary from institution to institution, the following suggested
priorities may serve as a starting point for defining an
organization's response:

(1) Priority one -- protect human life and people's
safety; human life always has precedence over all
other considerations.

(2) Priority two -- protect classified and/or sensitive
data. Prevent exploitation of classified and/or
sensitive systems, networks or sites. Inform effected
classified and/or sensitive systems, networks or sites
about already occurred penetrations.
(Be aware of regulations by your site or by government)

(3) Priority three -- protect other data, including
proprietary, scientific, managerial and other data,
because loss of data is costly in terms of resources.
Prevent exploitations of other systems, networks or
sites and inform already effected systems, networks or
sites about successful penetrations.

(4) Priority four -- prevent damage to systems (e.g., loss
or alteration of system files, damage to disk drives,
etc.); damage to systems can result in costly down
time and recovery.

(5) Priority five -- minimize disruption of computing
resources; it is better in many cases to shut a system
down or disconnect from a network than to risk damage
to data or systems.

An important implication for defining priorities is that once human
life and national security considerations have been addressed, it is
generally more important to save data than system software and
hardware. Although it is undesirable to have any damage or loss

Site Security Handbook Working Group [Page 23]

Internet Draft Site Security Handbook November 1995
during an incident, systems can be replaced; the loss or compromise
of data (especially classified data), however, is usually not an
acceptable outcome under any circumstances.

Another important concern is the effect on others, beyond the systems
and networks where the incident occurs. Within the limits imposed by
government regulations it is always important to inform effected
parties at as soon as possible. Due to the legal implications of this
topic, it should be included in the planned procedures to avoid
further delays and uncertainty for the administrators.

Any plan for responding to security incidents should be guided by
local policies and regulations. Government and private sites that
deal with classified material have specific rules that they must
follow.

The policies chosen by your site on how it reacts to incidents will
shape your response. For example, it may make little sense to create

Site Security Handbook Working Group [Page 32]

Internet Draft Site Security Handbook December 1995

mechanisms to monitor and trace intruders if your site does not plan
to take action against the intruders if they are caught. Other
organizations may have policies that affect your plans. Telephone
companies often release information about telephone traces only to
law enforcement agencies.

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

5.2 Notification and Point of Contacts

It is important to establish contacts with various personnel before
a real incident occurs. These contacts are either local, other
system responsible or administrative contacts administrators
elsewhere on the internet Internet or are investigative agencies. Working
with these contacts appropriately will help to make your incident
handling process more efficient.

Communication may need to be established with various "Points of
Contact." These may be technical or administrative in nature, may
include legal or investigative agencies, as well as Service Providers
and vendors. It is important to decide how much information will be
shared, especially with the wider community of users at a site, with
the public (the press) and with other sites.

Settling these issues are especially important for the local person
responsible for handling the incident, since that is the person
responsible for the actual notification of others. A list of
contacts in each of these categories is an important time saver for
this person during an incident. It can be quite difficult to find an
appropriate person during an incident when many urgent events are
ongoing. Including relevant telephone numbers (also electronic mail
addresses and fax numbers) in the site security policy is strongly
recommended. It is especially important to know how to contact
individuals who will be directly involved in handling a security
incident.

Site Security Handbook Working Group [Page 24]

Internet Draft Site Security Handbook November 1995

5.2.1 Local Managers and Personnel

When an incident is under way, a major issue is deciding who is in
charge of coordinating the activity of the multitude of players. A
major mistake that can be made is to have a number of "points of
contact" (POC) that are not pulling their efforts together. This
will only add to the confusion of the event, and will probably lead
to wasted or ineffective effort.

The single point of contact may or may not be the person "in charge"
of the incident. There are two distinct rolls roles to fill when deciding
who shall be the point of contact and the person in charge of the
incident. The person in charge will make decisions as to the
interpretation of policy applied to the event. The responsibility
for the handling of the event falls onto this person. In contrast,
the point of contact must coordinate the effort of all the parties
involved with handling the event.

The point of contact must be a person with the technical expertise to
successfully coordinate the effort of the system managers and users

Site Security Handbook Working Group [Page 33]

Internet Draft Site Security Handbook December 1995

involved in monitoring and reacting to the attack. Often the
management structure of a site is such that the administrator of a
set of resources is not a technically competent person with regard to
handling the details of the operations of the computers, but is
ultimately responsible for the use of these resources.

Another important function of the POC is to maintain contact with law
enforcement and other external agencies to assure that multi- agency
involvement occurs. (In the U.S. FBI, CIA, DoD, U.S. Army, or others
might be concerned.)

Finally, if legal action in the form of prosecution is involved, the
POC may be asked to speak for the site in court. The alternative is
to have multiple witnesses that will be hard to coordinate in a legal
sense, and will weaken any case against the attackers. A single POC
may also be the single person in charge of collecting evidence, which
will keep the number of people accounting for evidence to a minimum.
As a rule of thumb, the more people that touch a potential piece of
evidence, the greater the possibility that it will be inadmissible in
court.

One of the most critical tasks for the POC is the coordination of
all relevant processes. As responsibilities might be distributed
over the whole site, which in fact can may well consist of multiple independent
departments or groups, a well coordination coordinate effort is crucial for
overall success. The situation get even worse if multiple sites are
involved. In many cases, no single POC in one nvolved site can coordinate
the handling of an entire incident. The appropriate incident
response teams are more suitable, if multiple sites are involved.

The incident handling process should provide some escalation
mechanisms. The POC might change; the impact of the incident force
the management to take the lead instead of giving the technical

Site Security Handbook Working Group [Page 25]

Internet Draft Site Security Handbook November 1995
administrator the responsibility. Other reasons for changing the POC
are the emergence of conflicts of interest, changing priorities or
responsibilities. Regardless of why the POC is changed, all involved
parties must be informed. Arrangements should be made to allow the
new POC to contact the old one, to ensure an adequate briefing of
background information.

5.2.2 Law Enforcement and Investigative Agencies

In the event of an incident that has legal consequences it is
important to establish contact with investigative agencies such as
the FBI and Secret Service or their equivalent in your country, as
soon as possible. Local law enforcement and local security offices
or campus police departments should also be informed when as appropriate.

A primary reason is that once a major attack is in progress, there
is little time to call
various personnel in these agencies to determine exactly who the
correct point of contact is. Another reason is that it is important
to cooperate with these agencies in a manner that will foster a good
working relationship, and that will be in accordance with the working
procedures of these agencies. Knowing the working procedures in

Site Security Handbook Working Group [Page 34]

Internet Draft Site Security Handbook December 1995

advance and the expectations of your point of contact is a big step
in this direction. For example, it is important to gather evidence
that will be admissible in a court of law. If you don't know in
advance law, requiring prior knowledge
of how to gather admissible evidence, your efforts to collect
evidence during an incident are likely to be of no value to the
investigative agency with which you deal. such evidence. A final reason for establishing
contacts as soon as possible is that it is impossible to know the
particular agency that will assume jurisdiction in any given
incident. Making contacts and finding the proper channels early will
make responding to an incident go considerably more smoothly.

If your organization or site has a legal counsel, you need to notify
this office soon after you learn that an incident is in progress. At
a minimum, your legal counsel needs to be involved to protect the
legal and financial interests of your site or organization. There
are many legal and practical issues, a few of which are:

(1) Whether your site or organization is willing to risk
negative publicity or exposure to cooperate with legal
prosecution efforts.

(2) Downstream liability--if you leave a compromised system
as is so it can be monitored and another computer is damaged
because the attack originated from your system, your site or
organization may be liable for damages incurred.

(3) Distribution of information--if your site or organization
distributes information about an attack in which another
site or organization may be involved or the vulnerability
in a product that may affect ability to market that
product, your site or organization may again be liable
for any damages (including damage of reputation).

(4) Liabilities due to monitoring--your site or organization

Site Security Handbook Working Group [Page 26]

Internet Draft Site Security Handbook November 1995
may be sued if users at your site or elsewhere discover
that your site is monitoring account activity without
informing users.

Unfortunately, there are no clear precedents yet on the liabilities
or responsibilities of organizations involved in a security incident
or who might be involved in supporting an investigative effort.
Investigators will often encourage organizations to help trace and
monitor intruders -- indeed, most investigators cannot pursue
computer intrusions without extensive support from the organizations
involved. However, investigators cannot provide protection from
liability claims, and these kinds of efforts may drag out for months
and may take lots of effort.

On the other side, an organization's legal council may advise extreme
caution and suggest that tracing activities be halted and an intruder
shut out of the system. This in itself may not provide protection
from liability, and may prevent investigators from identifying
anyone.

The balance between supporting investigative activity and limiting
liability is tricky; you'll need to consider the advice of your

Site Security Handbook Working Group [Page 35]

Internet Draft Site Security Handbook December 1995

council and the damage the intruder is causing (if any) in making
your decision about what to do during any particular incident.

Your legal counsel should also be involved in any decision to
contact investigative agencies when an incident occurs at your site.
The decision to coordinate efforts with investigative agencies is
most properly that of your site or organization. Involving your
legal counsel will also foster the multi-level coordination between
your site and the particular investigative agency involved which in
turn results in an efficient division of labor. Another result is
that you are likely to obtain guidance that will help you avoid
future legal mistakes.

Finally, your legal counsel should evaluate your site's written
procedures for responding to incidents. It is essential to obtain a
"clean bill of health" from a legal perspective before you actually
carry out these procedures.

One of the most important considerations in

It is vital when dealing with investigative agencies is verifying 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 information details
about incidents, allowed unauthorized people into their systems,
etc., because a caller has masqueraded as a representative of a
government agency (e. g. the FBI
or Secret Service in the US). agency.

A similar consideration is using a secure means of communication.
Because many network attackers can easily reroute electronic mail,
avoid using electronic mail to communicate with other agencies (as
well as others dealing with the incident at hand). Non-secured phone
lines (e. g., the (the phones normally used in the business world) are also
frequent targets for tapping by network intruders, so be careful!

Site Security Handbook Working Group [Page 27]

Internet Draft Site Security Handbook November 1995

There is no established set of rules for responding to an incident
when the local Government becomes involved. Normally, except by
court order, no agency can force you to monitor, to disconnect from
the network, to avoid telephone contact with the suspected attackers,
etc. As discussed before, you should consult the matter with your
legal counsel, especially before taking an action that your
organization has never taken.

The particular agency involved may ask you to leave an attacked machine on and to monitor activity on this
machine, for example. Your complying
machine on and to monitor activity. Complying with this request
will ensure continued cooperation of the agency. This is usually
the best route towards finding the source of the network attacks
and, ultimately, terminating these attacks. Additionally, you may
need information or a favor from the agency involved in the incident. involved. You are
likely to get what you need only if you have been cooperative. It
is particularly important to avoid unnecessary or unauthorized
disclosure of information about the incident, including any
information furnished by the agency involved. The trust between your
site and the agency hinges upon your ability to avoid compromising involved: Don't compromise the
case the agency will build; keeping "tight lipped" is imperative. trying to build. If you do not cooperate with an
agency, you will be less likely to receive help in the future.

Site Security Handbook Working Group [Page 36]

Internet Draft Site Security Handbook December 1995

Sometimes your needs and the needs of an investigative agency will
differ. Your site may want to get back to normal business by
closing an attack route, but the investigative agency may want you
to keep this route open. Similarly, your site may want to close a
compromised system down to avoid the possibility of negative
publicity, but again the investigative agency may want you to
continue monitoring. When there is such a conflict, there may be a
complex set of tradeoffs (e.g., interests of your site's management,
amount of resources you can devote to the problem, jurisdictional
boundaries, etc.). An important guiding principle is related to what
might be called "Internet citizenship" [22, IAB89, 23 (xxx old
references)] and its responsibilities. Your site can shut a system
down, and this will relieve you of the stress, resource demands, and
danger of negative exposure. The attacker, however, is likely to
simply move on to another system, temporarily leaving others blind to
the attacker's intention and actions until another path of attack can
be detected. Providing that there is no damage to your systems and
others, the most responsible course of action is to cooperate with
the participating agency by leaving your compromised system on. This
will allow monitoring (and, ultimately, the possibility of
terminating the source of the threat to systems just like yours). On
the other hand, if there is damage to computers illegally accessed
through your system, the choice is complicated: shutting down the
intruder may prevent further damage to systems, but might make it
impossible to track down the intruder. If there has been damage, the
decision about whether it is important to leave systems up to catch
the intruder should involve all the organizations effected. Further
complicating the issue tradeoffs (e.g., interests of network responsibility is the consideration
that if you do not cooperate with an agency, your site's management,
amount of resources you will be less likely can devote to receive help from that agency in the future. problem, jurisdictional
boundaries, etc.). An important guiding principle is related to what
might be called "Internet citizenship" [22, IAB89, 23 (xxx old
references)] and its responsibilities. See section 5.6.

5.2.3 Computer Security Incident Handling Teams

There now exists a number of Computer Security Incident Handling

Site Security Handbook Working Group [Page 28]

Internet Draft Site Security Handbook November 1995
teams (CSIH teams) such as the CERT Coordination Center and the CIAC
or other teams around the globe. Teams exist for many major
government agencies and large corporations. If such a team is
available, notifying it should be of primary importance during the
early stages of an incident. These teams are responsible for
coordinating computer security incidents over a range of sites and
larger entities. Even if the incident is believed to be contained
within a single site, it is possible that the information available
through a response team could help in closing out the incident.

If it is determined that the breach occurred due to a flaw in the
systems' hardware or software, the vendor (or supplier) and a
Computer Security Incident Handling team should be notified as soon
as possible. This is especially important due to the fact that many
other systems are vulnerable, too.

In setting up a site policy for incident handling, it may be
desirable to create a subgroup, much like those teams that already
exist, that will be responsible for handling computer security
incidents for the site (or organization). If such a team is created,
it is essential that communication lines be opened between this team
and other teams. Once an incident is under way, it is difficult to
open a trusted dialogue between other teams if none has existed
before. (See [RFC xxx] for more information about the considerations
for creating your own incident handling team.)

5.2.4 Effected and involved Sites

If an incident has an impact on other sites, it is good practice to
inform them. It may be obvious from the beginning that the incident
is not limited to the local site, or it may emerge only after further
analysis.

Each site might choose to contact other sites directly or they can
pass the information to an appropriate incident response team, to
which the involved site belongs. As it is often very difficult to
find the responsible POC at remote sites, the involvement of an
incident response team will facilitate contact by making use of

Site Security Handbook Working Group [Page 37]

Internet Draft Site Security Handbook December 1995

already established channels.

The legal and liability issues arising from a security incident may
differ from site to site. It is important to define a policy for the
sharing and logging of information about other sites before an
incident occurs. This policy should be crafted in consultation with
legal counsel.

Information about specific people is especially sensitive, and is
subject to privacy laws. To avoid problems in this area, irrelevent irrelevant
information should be deleted and a statement of how to handle the
remaining information should be included. A clear statement of how
this information is to be used is essential. (No one who informs a
site of a security incident would like to read in the newspaper that
they also had a problem.) Incident response teams are valuable in
this respect. As they pass information to responsible POCs, they are

Site Security Handbook Working Group [Page 29]

Internet Draft Site Security Handbook November 1995
able to protect the anonymity of the original source. But be aware
that in many cases the analysis of logs and information at other
sites will reveal addresses of your site.

All the problems discussed should be not seen as reasons not to
involve other sites. In fact, the experiences of existing teams
reveal that most sites informed about security problems are not even
aware that their site had been compromised. Without timely
information other sites are often unable to take measures against
intruders.

5.2.5 Public Relations - Press Releases

One of the most important issues to consider is when, who, and how
much to release to the general public through the press. There are
many issues to consider when deciding this particular issue. First
and foremost, if a public relations office exists for the site, it is
important to use this office as liaison to the press. The public
relations office is trained in the type and wording of information
released, and will help to assure that the image of the site is
protected during and after the incident (if possible). A public
relations office has the advantage that you can communicate candidly
with them, and provide a buffer between the constant press attention
and the need of the POC to maintain control over the incident.

If a public relations office is not available, the information
released to the press must be carefully considered. If the
information is sensitive, it may be advantageous to provide only
minimal or overview information to the press. It is quite possible
that any information provided to the press will be quickly reviewed
by the perpetrator of the incident. As a contrast to this
consideration, it was discussed above Also note that misleading the
press can often backfire and cause more damage than releasing
sensitive information.

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

(1) Keep the technical level of detail low. Detailed

Site Security Handbook Working Group [Page 38]

Internet Draft Site Security Handbook December 1995

information about the incident may provide enough
information for copy-cat events or even damage the
site's ability to prosecute once the event is over.

(2) Keep the speculation out of press statements.
Speculation of who is causing the incident or the
motives are very likely to be in error and may cause
an inflamed view of the incident.

(3) Work with law enforcement professionals to assure that
evidence is protected. If prosecution is involved,
assure that the evidence collected is not divulged to
the press.

(4) Try not to be forced into a press interview before you are
prepared. The popular press is famous for the "2am" "2 am"
interview, where the hope is to catch the interviewee off

Site Security Handbook Working Group [Page 30]

Internet Draft Site Security Handbook November 1995
guard and obtain information otherwise not available.

(5) Do not allow the press attention to detract from the
handling of the event. Always remember that the successful
closure of an incident is of primary importance.

5.3 Identifying an Incident

5.3.1 Is it real?

This stage involves determining, determining if a problem really exist. exists. Of
course many, many if not most, most signs often associated with virus
infections, 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. For example, widely available
software packages can greatly assist someone who thinks there may be
a virus in a personal computer. Audit information is also extremely useful, especially
in determining whether there is a network attack. It is extremely
important to obtain a system snapshot as soon as one suspects that
something is wrong. Many incidents cause a dynamic chain of events
to occur, and an initial system snapshot may do more
good in be the most valuable
tool for identifying the problem and any source of attack than most
other actions which can be taken at this stage. attack. Finally,
it is important to start a log book. Recording system events,
telephone conversations, time stamps, etc., can lead to a more rapid
and systematic identification of the problem, and is the basis for
subsequent stages of incident handling.

There are certain indications or "symptoms" of an incident which
deserve special attention:

(1) System crashes.
(2) New user accounts (e.g., the (the account RUMPLESTILTSKIN has
unexplainedly been created), or high activity on an account that has had virtually no activity for
months.
(3) New files (usually with novel or strange file names,
such as data.xx or k). k or .xx ).
(4) Accounting discrepancies (e.g., in (in a UNIX system you might
notice that the shrinking of an accounting file called
/usr/admin/lastlog has shrunk,

Site Security Handbook Working Group [Page 39]

Internet Draft Site Security Handbook December 1995

/usr/admin/lastlog, something that should make you very
suspicious that there may be an intruder).
(5) Changes in file lengths or dates (e.g., a (a user should be
suspicious if he/she observes that the .EXE files in an MS DOS computer have
unexplainedly grown by over 1800 bytes).
(6) Attempts to write to system (e.g., a (a system manager notices
that a privileged user in a VMS system is attempting to
alter RIGHTSLIST.DAT).
(7) Data modification or deletion (e.g., files start to
disappear).
(8) Denial of service (e.g., a system manager and all

Site Security Handbook Working Group [Page 31]

Internet Draft Site Security Handbook November 1995 (files start to disappear).
(8) Denial of service (a system manager and all other users
become locked out of a UNIX system, which
has been changed to now in single user mode).
(9) Unexplained, poor system performance (e.g., system
response time becomes unusually slow).
(10) Anomalies (e.g., "GOTCHA" ("GOTCHA" is displayed on a display
terminal the console or there
are frequent unexplained "beeps").
(11) Suspicious probes (e.g., there (there are numerous unsuccessful login
attempts from another node).
(12) Suspicious browsing (e.g., someone (someone becomes a root user on a UNIX
system and accesses file after file in one
user's account, then another's). many user accounts.)

By no means is this list comprehensive. We have just listed a number
of common indicators. Furthermore, none of these indications is
absolute "proof" that an incident is occurring, nor are all of these
indications normally observed when an incident occurs. If you
observe any of these indications, however, it is important to suspect
that an incident might be occurring, and act accordingly. There is
no formula for determining with 100 percent accuracy that an incident
is occurring. It is best at this point to collaborate with other
technical and computer security personnel to make a decision as a
group about whether an incident is occurring.

5.3.2 Types and Scope of Incidents

Along with the identification of the incident is the evaluation of
the scope and impact of the problem. It is important to correctly
identify the boundaries of the incident in order to effectively deal
with it. In addition, the impact of an incident will determine its
priority in allocating resources to deal with the event. Without an
indication of the scope and impact of the event, it is difficult to
determine a correct response. and prioritize responses.

In order to identify the scope and impact, impact a set of criteria should
be defined which is appropriate to the site and to the type of
connections available. Some of the issues are: include:

(1) Is this a multi-site incident?
(2) Are many computers at your site effected by this incident?
(3) Is sensitive information involved?
(4) What is the entry point of the incident (network,
phone line, local terminal, etc.)?
(5) Is the press involved?
(6) What is the potential damage of the incident?
(7) What is the estimated time to close out the incident?
(8) What resources could be required to handle the incident?
(9) Is law enforcement involved?

5.3.3 Assessing the Damage and Extent

The analysis of the damage and extent of the incident can be quite
time consuming, but should lead into some of the insight as to the
nature of the incident, and aid investigation and prosecution.

Site Security Handbook Working Group [Page 32]

Internet Draft Site Security Handbook November 1995 As
soon as the breach has occurred, the entire system and all its
components should be considered suspect. System software is the most
probable target. Preparation is key to be able to detect all changes

Site Security Handbook Working Group [Page 40]

Internet Draft Site Security Handbook December 1995

for a possibly tainted system. This includes checksumming all tapes
from the vendor using a checksum algorithm which (hopefully) is
resistant to tampering [10]. (See sections xxx.) xxx 4.7?)

Assuming original vendor distribution tapes are available, an
analysis of all system files should commence, and any irregularities
should be noted and referred to all parties involved in handling the
incident. It can be very difficult, in some cases, to decide which
backup tapes are showing a correct system status; consider that the
incident may have continued for months or years before discovery,
and that the suspect may be an employee of the site, or otherwise
have intimate knowledge or access to the systems. In all cases, the
pre-incident preparation will determine what recovery is possible.

If the system supports centralized logging (most do), go back over
the logs and look for abnormalities. If process accounting and
connect time accounting is enabled, look for patterns of system
usage. To a lesser extent, disk usage may shed light on the
incident. Accounting can provide much helpful information in an
analysis of an incident and subsequent prosecution.

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

5.4 Handling an Incident

Certain steps are necessary to take during the handling of an
incident. In all security related activities, the most important
point to be made is: One should have policies in place. Without
defined goals, activities undertaken will remain without focus. The
goals should be defined by management and legal counsel in advance.

One of the most fundamental objectives is to restore control of the
effected systems and to limit the impact and damage. In the worst
case scenario, shutting down the system or disconnecting the system
from the network may the only practical solution.

As the activities involved are complex, try to get as much help as
necessary. While trying to solve the problem alone, real damage
might occur due to delays or missing information. Most system
administrators take the discovery of an intruder as personal
challenge. By proceeding this way, other objectives as outlined in
the local policies may not always considered. Trying to catch
intruders may be a very low priority, compared to system integrity,
for example. One other pitfall is the premise that by monitoring the
activities of a hacker, other sites can be warned about problems they
have been exposed to. By allowing the intruder not always considered. Trying to (ab)use the local
system, a site catch
intruders may be incurring legal liability or indirect
responsibility for the damage caused to other sites.

For all the reasons outlined above, it is necessary a very low priority, compared to establish
procedures system integrity,
for example. Monitoring a hacker's activity is useful, but it might
not be considered worth the incident handling risk to allow the technical

Site Security Handbook Working Group [Page 33]

Internet Draft Site Security Handbook November 1995

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

5.4.1 Types of notification, Exchange of information

When you have confirmed that an incident is occurring, the
appropriate personnel must be notified. How this notification is
achieved is very important in keeping the event under control both
from a technical and emotional standpoint. The circumstances should
be described in as much detail as possible, in order to aid prompt
acknowledgment and understanding of the problem. Great care should

Site Security Handbook Working Group [Page 41]

Internet Draft Site Security Handbook December 1995

be taken to which groups detailed technical information is given
during the notification. For example it is helpful to pass this
kind of information to an incident handling team. They can assist
you by providing helpful hints for eradicating the vulnerabilities
involved in an incident. On the other hand putting the critical
knowledge into the public domain (e. g. netnews, mailing lists) may
potentially put a great number of systems at risk of intrusion. It
is a wrong
assumption, invalid to assume that all administrators are reading a particular
news
group, group have access to operating system source code or can even
understand the techniques an advisory well enough to take adequate steps.

First of all, any notification to either local or off-site personnel
must be explicit. This requires that any statement (be it an
electronic mail message, phone call, or fax) provides information
about the incident that is clear, concise, concise and fully qualified. When
you are notifying others that will help you to handle an event, a
"smoke screen" will only divide the effort and create confusion. If
a division of labor is suggested, it is helpful to provide
information to each section 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 other
information that would help them resolve a 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. This is especially true when the press is involved. When
an incident severe enough to gain press attention is ongoing, it is
likely that any false information you provide will not be
substantiated by other sources. This will reflect badly on the site
and may create enough ill-will between the site and the press to
damage the site's public relations.

The choice of language used when notifying people about the incident
can have a profound effect on the way that information is received.
When you use emotional or inflammatory terms, you raise the
expectations of damage and negative outcomes of the incident. It is
important to remain calm both in written and spoken notifications.

Another aspect of the choice of language used is that not all people
speak the same language. Due to this fact misunderstandings and
delay may arise, especially if it is a multi-national incident.

Site Security Handbook Working Group [Page 34]

Internet Draft Site Security Handbook November 1995
Other international concerns include differing legal implications of
a security incident and cultural differences. Cultural differences
do not only exist between countries like Germany and Australia. They
even exist within countries between different social groups or user
groups. An administrator of a university system might be very
relaxed about attempts to connect to the system via telnet, but the
administrator of a military system will follow his procedures and
consider the same action as a possible attack.

Another issue associated with the choice of language is the
notification of non-technical or off-site personnel. It is important
to accurately describe the incident without undue alarm or confusing
messages. While it is more difficult to describe the incident to a
non-technical audience, it is often more important. A non-technical
description may be required for upper-level management, the press, or
law enforcement liaisons. The importance of these notifications

Site Security Handbook Working Group [Page 42]

Internet Draft Site Security Handbook December 1995

cannot be underestimated and may make the difference between handling
the incident properly and escalating to some higher level of damage.

If a an IRT becomes involved it might be necessary to fill out a
template for the information exchange. Although this may seem to be
an additional burden and adds a certain delay, it helps the team to
act on this minimum set of information. The response team may be
able to respond to aspects of the incident which the local
administrator is unaware of. If information is given out to someone
else, the following minimum information should be provided:

(1) timezone of logs, ... in GMT or local time
(2) information about the remote system (including host names,
ip addresses and user ids)
(3) all log entries relevant for the remote site
(4) type of incident (what happened, why should you care)

If local information (ie. local user ids) is included in the log
entries, it might be necessary to sanitize the entries beforehand
to avoid privacy issues. In general, all information which might
assist a remote site in resolving an incident should be given out,
unless local policies prohibit this.

5.4.2 Protection of evidence and activity logs

When you respond to an incident, document all details related to the
incident. This will provide valuable information to yourself and
others as you try to unravel the course of events. Documenting all
details will ultimately save you time. If you don't document every
relevant phone call, for example, you are likely to forget a good
portion of information you obtain, requiring you to contact the
source of information once again. This wastes yours and others'
time, something you can ill afford. At the same time, recording
details will provide evidence for prosecution efforts, providing the
case moves in this direction. Documenting an incident also will help
you perform a final assessment of damage (something your management
as well as law enforcement officers will want to know), and will

Site Security Handbook Working Group [Page 35]

Internet Draft Site Security Handbook November 1995
provide the basis for a follow-up analysis in which you can engage in
a valuable "lessons learned" exercise. Additionally it will help
during later phases of the handling process, especially during the
eradiction process:
eradication, recovery and recovery. follow-up "lessons learned."

During the initial stages of an incident, it is often infeasible to
determine whether prosecution is viable, so you should document as if
you are gathering evidence for a court case. At a minimum, you
should record:

(1) All system events (audit records).
(2) All actions you take (time tagged).
(3) All phone conversations (including the person with whom
you talked, the date and time, and the content of the
conversation).

The most straightforward way to maintain documentation is keeping a
log book. This allows you to go to a centralized, chronological
source of information when you need it, instead of requiring you to

Site Security Handbook Working Group [Page 43]

Internet Draft Site Security Handbook December 1995

page through individual sheets of paper. Much of this information is
potential evidence in a court of law. Thus, when you initially
suspect that an incident will result in prosecution or when an
investigative agency becomes involved, you need to regularly to:

(1) Regularly (e.g., every day) turn in photocopied, signed
copies of your logbook (as well as media you use to record
system events) to a document custodian.
(2) The custodian who can should store these copied pages in a secure
place (e.g., a safe).
(3) When you submit information for storage, you should in
return receive a signed, dated receipt from the document
custodian.

Failure to observe these procedures can result in invalidation of
any evidence you obtain in a court of law.

5.4.3 Containment

The purpose of containment is to limit the extent of an attack. For
example, it is important to limit the spread of a worm attack on a
network as quickly as possible. An
essential part of containment is decision making (i.e., determining
whether to shut a system down, to disconnect from a network, to monitor
system or network activity, to set traps, to disable functions such as
remote file transfer on a UNIX system, etc.).

Sometimes this decision is trivial; shut the system down if the
system is life-critical, life critical, classified or sensitive, or if proprietary
information is at risk! Bear in mind that removing all access while
an incident is in progress obviously notifies all users, including
the alleged problem users, that the administrators are aware of a
problem; this may have a deleterious effect on an investigation. In
some cases, it is prudent to remove all access or functionality as
soon as possible, then restore normal operation in limited stages.
In other cases, it is worthwhile to risk having some damage to the system
if keeping the system up might enable you to identify an intruder.

This stage should involve carrying out predetermined procedures.
Your organization or site should, for example, define acceptable
risks in dealing with an incident, and should prescribe specific
actions and strategies accordingly. This is especially important
when a quick decision is necessary without the possibility to contact
all involved parties and discuss the decision. In most of the cases
the person in charge will have not the power to make a difficult
management decision (like to loss the results of a costly

Site Security Handbook Working Group [Page 36]

Internet Draft Site Security Handbook November 1995
experiment). Finally, notification of cognizant authorities should
occur during this stage.

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

5.4.4 Eradication

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

Site Security Handbook Working Group [Page 44]

Internet Draft Site Security Handbook December 1995

cleaning up the eradication. system.

Software may be available to help you in the eradiction process. For
example, eradication process,
such as anti-virus software is available to eliminate most viruses
which infect for small systems. If any bogus files have been created, it
is time to archive them for later use in case of a court case.
Thereafter delete any bogus files
have been created archive them from the system at this point. before deleting them. In the case of
virus infections, it is important to clean and reformat any disks
containing infected files. Finally, ensure that all backups are
clean. Many systems infected with viruses become periodically
reinfected re
infected simply because people do not systematically eradicate the
virus from backups. After eradiction eradication a new backup should be taken,
too.

Removing all vulnerabilities once an incident has occurred is
difficult. The key to removing vulnerabilities is knowledge and
understanding of the breach.

It may be necessary to go back to the original distributed tapes and
recustomize
re customize the system. To facilitate this worst case scenario, a
record of the original systems setup and each customization change
should be kept current with each change to the system. In the case
of a network-based attack, it is important to install patches for any
operating system vulnerability which was exploited.

As discussed in section $$.4.2, 5.4.2, a security log can be most valuable
during this phase of removing vulnerabilities. There are two
considerations here; the first is to keep The logs of the procedures that
have been used to make showing how
the system secure again. This should include
command procedures (e.g., shell scripts) that incident was discovered and contained can be run on a
periodic basis used later to recheck help
determine how extensive the security. Second, keep logs of
important system events. These damage was from a given incident. The
steps taken can be referenced when trying used in the future to
determine make sure the extent of problem does
not resurface. Ideally, one should automate and regularly apply same
test as was used to detect the damage of a given 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

Site Security Handbook Working Group [Page 37]

Internet Draft Site Security Handbook November 1995
security mailing lists and bulletins would be a good place to search
for this information and you can get advice from incident response
teams.

5.4.5 Recovery

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

5.4.6 Follow-Up

Once you believe that a system has been restored to a "safe" state,
it is still possible that holes and even traps could be lurking in
the system. One of the most important stages of responding to
incidents is also the most often omitted---the follow-up stage. In
the follow-up stage, the system should be monitored for items that
may have been missed during the cleanup stage. It would be prudent

Site Security Handbook Working Group [Page 45]

Internet Draft Site Security Handbook December 1995

to utilize some of the tools mentioned in section xxx (e.g., xxx) as
a start. Remember, these tools don't replace continual system
monitoring and good systems administration procedures.

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

After an incident, it
provides a reference is prudent to be used 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 case the clear understanding of other similar incidents. the problem. Creating
a formal chronology of events (including time stamps) is also
important for legal reasons. Similarly, it

A follow-up report is valuable for many reasons. It provides a
reference to be used in case of other similar incidents. It is
also important to as quickly as possible obtain a monetary estimate
of the amount of damage the incident caused in terms of any loss of
software and files, hardware damage, and manpower costs to restore
altered files, reconfigure affected systems, and so forth. This
estimate may become the basis for subsequent prosecution activity.
The report can also help justify an organization's computer
security effort to management.

5.5 Aftermath of an Incident

In the wake of an incident, several actions should take place. These
actions can be summarized as follows:

(1) An inventory should be taken of the systems' assets,

Site Security Handbook Working Group [Page 38]

Internet Draft Site Security Handbook November 1995
i. e., a careful examination should determine how the
system was affected by the incident,

(2) The lessons learned as a result of the incident
should be included in revised security plan to
prevent the incident from re-occurring,

(3) A new risk analysis should be developed in light of the
incident,

(4) An investigation and prosecution of the individuals
who caused the incident should commence, if it is
deemed desirable.

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

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

Site Security Handbook Working Group [Page 46]

Internet Draft Site Security Handbook December 1995

changing computing environments.

After

The whole purpose of this "post mortem" process is to improve all
security measures to protect the site against future attacks. In the
light of an incident, it incident one should gather practical knowledge from the
experience. A concrete goal is prudent developing proactive methods, for
example: early warning by probes. Another important facet of the
aftermath may be end user and administrator education to write prevent a report describing
reoccurrence of a security problem.

5.6 Responsibilities

5.6.1 Not crossing the line

It is one thing to protect one's own network, but quite another to
assume that one should protect other networks. During the handling
of an incident, method certain system vulnerabilities of discovery, correction procedure, monitoring
procedure, one's own systems
and the systems of others become apparent. It is quite easy and may
even be tempting to pursue the intruders in order to track them.
Keep in mind that at a certain point it is possible to 'cross the
line,' and with the best intentions, become no better than the
intruder.

The best rule when it comes to propriety is to not use any facility
of remote sites which is not public. This clearly excludes any entry
onto a system (such as a summary of lesson learned. remote shell or login session) which is not
expressly permitted. This will aid in the
clear understanding may be very tempting; after a breach of
security is detected, a system administrator may have the problem. Remember, means to
'follow it is difficult up,' to
learn from an incident if you don't understand the source.

The whole purpose of this "post mortem" process ascertain what damage is being done to improve all
security measures to protect the site against future attacks. In remote
site. Don't do it. Instead attempt to reach the
light appropriate point of an
contact for the affected site.

5.6.2 Good Internet Citizenship

During a security incident there are two choices one should gather practical knowledge from the
experience. This should improve one's ability can make.
First, a site can choose to detect watch the
occurance of similar problems intruder in the future. A concrete goal is
developing proactive methods, for example: early warning by probes.
Another important facet hopes of
catching him. Or, the aftermath is more related to end user
and administrator awareness and eduction. By reviewing site can go about cleaning up after the actual
incident handling effort and shut the process can intruder out of the systems. This is a
decision that must be improved and extended made very thoughtfully as there may be legal
liabilities if you choose to
reflect new lessons learned. All this will help the leave your site in 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
handling intruder. These
affected sites may be readily apparent after a thorough review of future incidents even if
your log files.

5.6.3 Administrative Response to Incidents

When a security incident involves a completely different kind of
attack occurs.

5.6 Responsibilities

It user, the site's security policy
should describe what action is one thing to protect one's own network, be taken. The transgression should
be taken seriously, but quite another it is very important to
assume that one should protect other networks. During the handling
of an incident, certain system vulnerabilities be sure of one's own systems
and the systems of others become apparent. It is quite easy and may
even be tempting to pursue role
the intruders in order to track them.
Keep in mind that at user played. Was the user naive? Could there be a certain point it is possible mistake in
attributing the security breach to 'cross the
line,' and with user? Applying administrative
action that assumes the best intentions, become no better than user intentionally caused the incident may

Site Security Handbook Working Group [Page 39] 47]

Internet Draft Site Security Handbook November December 1995

intruder.

The best rule when it comes to propriety is to

not be appropriate for a use any facility 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 remote sites which is not public. This clearly excludes any entry
onto a user) in addition
to more stern measures for intentional acts of intrusion and system (such as
misuse.

6. ONGOING ACTIVITIES

At this point in time, your site has hopefully developed a remote shell or login session) which is not
expressly permitted. This may complete
security policy and developed procedures to assist in the
configuration and management of your technology in support of those
policies. How nice it would be very tempting; after if you could sit back and relax at
this point and know that you were finished with the job of security.
Unfortunately, that isn't the case. Your systems and networks are
not a breach of
security is detected, static environment so you will need to review policies and
procedures on a system administrator may have the means regular basis. There are a number of steps you can
take to
'follow it up,' help you keep up with the changes around you so that you can
initiate corresponding actions to ascertain what damage address those changes. The
following is being done a starter set. You will add others as appropriate for
your site.

(1) Subscribe to advisories that are issued by various security incident
response teams, like those of the remote
site. Don't do it. Instead attempt CERT Coordination Center [ref], and
update your systems against those threats that apply to reach your site's
technology.

(2) Monitor security patches that are produced by the POC vendors of the effected
site.

6. MAINTENANCE your
equipment, and EVALUATION

6.1 Risk assessments

6.2 Notification obtain and install all that apply.

(3) Actively watch the configurations of problems/events your systems to identify any
changes that may have occurred. Then investigate all anomalies.

(4) Review all security policies and procedures annually (at a minimum)

(5) Read appropriate mailing lists and Netnews groups to keep up to date
with the latest information being shared by fellow administrators.

APPENDICES

A1 Tools and Locations

This section provides a brief overview of publicly available security
technology which can be downloaded from the Internet. Many of the
items described below will undoubtedly be surpassed or made obsolete
before this document is published. This section is divided into two
major subsections, applications and tools. The applications heading
will include all end user programs (clients) and their supporting
system infrastructure (servers). The tools heading will deal with
the tools that a general user will never see or need to use, but
which may be part of or used by applications, used to troubleshoot
security problems or guard against intruders by system and network
administrators.

Site Security Handbook Working Group [Page 48]

Internet Draft Site Security Handbook December 1995

The emphasis will be on unix UNIX applications and tools, but other
platforms, particularly PC's and Macintoshes, will be mentioned where
information is available.

Most of the tools and applications described below can be found in
one of the following two archive sites:

(1) CERT Coordination Center
ftp://info.cert.org:/pub/tools
(2) DFN-CERT
ftp://ftp.cert.dfn.de/pub/tools/
(3) Computer Operations, Audit, and Security Tools (COAST)
coast.cs.purdue.edu:/pub/tools

Any references to CERT or COAST will refer to these two locations.
These two sites act as repositories for most tools, exceptions will
be noted in the text. *** It is important to note that many sites,
including CERT and COAST are mirrored throughout the Internet. Be
careful to use a "well known" mirror site to retrieve software and to
use whatever verification tools possible, checksums, md5 checksums,
etc... to validate that software. A clever cracker might advertise

Site Security Handbook Working Group [Page 40]

Internet Draft Site Security Handbook November 1995
security software with designed flaws in order to gain access to data
or machines. ***

Applications

The sad truth is that there are very few security conscious
applications currently available. The real reason is the need for a
security infrastructure which must be first put into place for most
applications to operate securely. There is considerable effort
currently taking place to place this infrastructure so that
applications can take advantage of secure communications.

Unix based applications

PGP
MD5
S/KEY
TROJAN.PL
PEM
KERBEROS
Drawbridge
Tripwire
logdaemon
TCP-Wrapper
rpcbind/portmapper replacement
cops
tiger
ISS
SATAN
smrsh
swatch
identd (not really a security tool)
DES (non-US versions)

Site Security Handbook Working Group [Page 49]

Internet Draft Site Security Handbook December 1995

lsof
sfingerd
passwd-replacements (npasswd / ANLpasswd / passwd+ / ...)

A2 Mailing lists and other resources

It would be impossible to list all of the mail-lists and other
resources dealing with site security. However, these are some "jump-
points" from which the reader can begin. All of these references are
for the "INTERNET" constituency. More specific (vendor and
geographical) resouces can be found through these references.

Mailing Lists

(1) CERT Advisory
Send mail to: cert-advisory-request@cert.org
Message Body: subscribe cert FIRSTNAME LASTNAME

A CERT advisory provides information on how to obtain a patch or
details of a workaround for a known computer security problem.
The CERT Coordination Center works with vendors to produce a

Site Security Handbook Working Group [Page 41]

Internet Draft Site Security Handbook November 1995
workaround or a patch for a problem, and does not publish
vulnerability information until a workaround or a patch is
available. A CERT advisory may also be a warning to our
constituency about ongoing attacks (e.g.,
"CA-91:18.Active.Internet.tftp.Attacks").

CERT advisories are also published on the USENET newsgroup:

comp.security.announce

CERT advisory archives are available via anonymous FTP from
info.cert.org in the /pub/cert_advisories directory.

(2) CERT Tools Mailing List
Send mail to: cert-tools-request@cert.sei.cmu.edu
Message Body: subscribe cert-tools FIRSTNAME LASTNAME

The purpose of this moderated mailing list is to
encourage the exchange of information on security
tools and techniques. The list should not be used
for security problem reports.

(3) VIRUS-L List
Send mail to: listserv%lehiibm1.bitnet@mitvma.mit.edu
Message Body: subscribe virus-L FIRSTNAME LASTNAME

VIRUS-L is a moderated mailing list with a focus
on computer virus issues. For more information,
including a copy of the posting guidelines, see
the file "virus-l.README", available by anonymous
FTP from cs.ucr.edu.

Site Security Handbook Working Group [Page 50]

Internet Draft Site Security Handbook December 1995

(4) Academic Firewalls
Send mail to: majordomo@greatcircle.com
Message Body: subscribe firewalls user@host

The Firewalls mailing list is a discussion forum for
firewall administrators and implementors.

USENET newsgroups

(1) comp.security.announce
The comp.security.announce newsgroup is moderated
and is used solely for the distribution of CERT
advisories.

(2) comp.security.misc
The comp.security.misc is a forum for the
discussion of computer security, especially as it
relates to the UNIX(r) Operating System.

(3) alt.security
The alt.security newsgroup is also a forum for the

Site Security Handbook Working Group [Page 42]

Internet Draft Site Security Handbook November 1995
discussion of computer security, as well as other
issues such as car locks and alarm systems.

(4) comp.virus
The comp.virus newsgroup is a moderated newsgroup
with a focus on computer virus issues. For more
information, including a copy of the posting
guidelines, see the file "virus-l.README",
available via anonymous FTP on info.cert.org
in the /pub/virus-l directory.

(5) comp.risks
The comp.risks newsgroup is a moderated forum on
the risks to the public in computers and related
systems.

World-Wide Web Pages

(1) http://www.first.org/

Computer Security Resource Clearinghouse. The main focus is on
crisis response information; information on computer
security-related threats, vulnerabilities, and solutions. At the
same time, the Clearinghouse strives to be a general index to
computer security information on a broad variety of subjects,
including general risks, privacy, legal issues, viruses,
assurance, policy, and training.

(2) http://www.telstra.com.au/info/security.html

This Reference Index contains a list of links to information
sources on Network and Computer Security. There is no implied
fitness to the Tools, Techniques and Documents contained within this

Site Security Handbook Working Group [Page 51]

Internet Draft Site Security Handbook December 1995

archive. Many if not all of these items work well, but we do
not guarantee that this will be so. This information is for the
education and legitimate use of computer security techniques only.

(3) http://www.alw.nih.gov/Security/security.html

This page features general information about computer security.
Information is organized by source and each section is organized
by topic. Recent modifications are noted in What's New page.

Editor Information

Barbara Y. Fraser
Software Engineering Institute
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Phone: (412) 268-5010
Fax: (412) 268-6989
email: byf@cert.org

Site Security Handbook Working Group [Page 43] 52]

----