WDIFF

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

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

Site Security Handbook for System and Network Administrators
<draft-ietf-ssh-handbook-00.txt>
<draft-ietf-ssh-handbook-01.txt>

Status of this Memo

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

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

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

Table of Contents

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

Site Security Handbook Working Group [Page 1]

Internet Draft Site Security Handbook November 1995

5.6 Responsibilities................................................ 39
6. Maintenance and Evaluation...................................... 40
6.1 Risk Assessments................................................ 40
6.2 Notification of Problems and Events............................. 40
Appendix A1 Tools and Locations..................................... 40
Appendix A2 Mailing Lists and Other Resources....................... 41
References........................................................... ?
Annotated Bibliography............................................... ?

1. INTRODUCTION

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

2. SECURITY POLICIES

2.1 What Is a Security Policy Nevil Brownlee, Joao Nuno Ferreira, Erik Gutmann,
Klaus-Peter Kossakowski, Edward.P.Lewis, Gary Malkin, Philip J.
Nesser, and Why Have One?

The security-related decisions Michael S. Ramsey.

A special thank you make, or fail goes to make, as system
administrator largely determines how secure or insecure your system
is, how much functionality your system offers, Joyce Reynolds, ISI, and Paul Holbrook,
CICnet, for their vision, leadership, and how easy your
system is to use. However, you cannot make good decisions about
security without first determining what your security goals are. And
until you determine what your security goals are, you cannot make
effective use effort in the creation of any collection
the first version of security tools, because you simply
won't know what to check for, or what restrictions to impose.

For instance, your goals this handbook. It is the working group's sincere
hope that this version will probably be very different from as helpful to the
goals community as the
earlier one was.

1.1 Purpose of this Work

This handbook is a hardware or software vendor who ships your system software
set up in a default state that allows maximum access (e.g., all
services turned on), but provides minimal security.

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

(1) services offered (functionality) vs. security
(2) ease of use vs. security
(3) cost of security vs. risk of loss

Your goals are communicated guide to all users, operations staff, and managers
through a set of security rules, called a "computer security policy".

2.1.1 Definition of a Computer Security Policy

A setting computer security policy is a formal specification of policies and
procedures for sites that have systems on the rules by
which people are given access to an organization's technology Internet. This guide
lists issues and
information assets.

2.1.2 Purposes of factors that a Computer Security Policy

The main purpose site must consider when setting their
own policies. It makes some recommendations and provides discussions
of relevant areas.

This guide is only a computer framework for setting security policy is to inform users,
staff policies and managers
procedures. In order to have an effective set of their obligatory requirements for protecting
technology policies and information assets through a consistent approach to
policy matters. Another purpose is to provide
procedures, a baseline from which site will have to acquire, configure make many decisions, gain agreement,
and audit computer systems for compliance with
the policy. Therefore an attempt to use a set of security tools in then communicate and implement the absence of policies.

1.2 Audience

The audience for this document are system administrators and decision
makers (who are more traditionally called "administrators" or "middle
management") at least an implied security policy sites. This document is meaningless.

2.2 What Makes a Good Computer Security Policy? not directed at programmers
or those trying to create secure programs or systems. The characteristics focus of a good security policy are:

(1) Able
this document is on the policies and procedures that need to be implemented (e.g. through system administration
procedures, and by publishing 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 acceptable use guidelines, etc.).
(2) Can the
Internet community. However, this document should be enforced (e.g., via useful to any
site that allows communication with other sites. As a general guide
to security tools where appropriate,
but policies, this document may also from a human perspective, via sanctions).
(3) Clearly defines be useful to sites with
isolated systems.

Site Security Handbook Working Group [Page 2]

Internet Draft Site Security Handbook November 1995

1.3 Definitions

For the areas of responsibilities.

The components purposes of this guide, a good security policy include:

(1) Computer Technology Purchasing Guidelines - Specifies required "site" is any organization that
owns computers or preferred security features network-related resources. These resources may
include host computers that users use, routers, terminal servers,
PC's or other devices that have access to supplement existing purchasing
policy and guidelines.

(2) Privacy Policy - Defines reasonable expectations the Internet. A site may
be a end user of privacy
regarding Internet services or a service provider such issues as monitoring a
regional network. However, most of electronic mail and
logging the focus of keystrokes.

(3) Access Policy - Defines access rights this guide is on
those end users of Internet services.

We assume that the site has the ability to set policies and privileges,
procedures for itself with the concurrence and protects
assets support from loss or disclosure by specifying acceptable those who
actually own the resources.

The "Internet" is those set of networks and machines that use
guidelines for users, operations staff, the
TCP/IP protocol suite, connected through gateways, and management. Provides
guidelines for external connections, data communications,
connecting devices to sharing a network,
common name and adding new software address spaces [1].

The term "system administrator" is used to a
system. Also provides notification guidelines (e.g., requires
a login warning banner stating that the system is cover all those who are
responsible for authorized
users only, instead the day-to-day operation of displaying resources. This may be a welcome banner.)

(4) Accountability Policy - Defines the responsibilities
number of users,
management, and operations staff. Specifies an audit capability,
and provides incident handling guidelines.

(5) Authentication Policy - Establishes trust through individuals or an effective
password policy, and by setting guidelines for remote location
authentication, and organization.

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

(6) Availability - Defines availability expectations. Addresses people who own
the
redundancy of resources.

1.4 Related Work

The IETF Guidelines for Security Incident Response Working Group
(GRIP) is developing a document for security functions. Specifies recovery procedures
and mechanisms.

(7) Violations Reporting - Denotes which types of violation must be
reported, and incident response teams.
That document provides additional guidance to those organizations
planning to develop their own incident response team (IRT), including
a central reporting point. A non-
threatening atmosphere and the possibility of anonymous reporting
will result in a greater likelihood template that if a violation is
detected, it will be reported.

(8) Supporting Information - Provides users, staff, useful to IRTs when descibing their policies and management with
contact information for each type of policy violation. Gives
guidelines
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 public relations office on network
is, how handle outside
queries about a security incident. Provides cross-references much functionality your network offers, and how easy your
network is to use. However, you cannot make good decisions about
security procedures and related information, such as company
policies and regulatory requirements (federal, state, and local).

Once without first determining what your computer security policy has been established it should be
clearly communicated goals are.
Until you determine what your security goals are, you cannot make
effective use of any collection of security tools because you simply
will not know what to users, staff, and management. Having all
personnel sign a statement indicating that they have read, understood, check for and agree what restrictions to abide by the policy is an important part of the process.
Finally, impose.

For example, your policy should goals will probably be reviewed on very different from the
goals of a regular basis product vendor. Vendors are trying to see if it
is successfully supporting your security needs.

3. SECURITY PROCEDURES

3.1 Authentication

3.1.1 One-Time passwords

Given today's networked environments, it is recommended that sites
concerned about the security make configuration
and integrity operation 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 products as simple as possible, which implies
that the captured information for subsequent 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 hosts and accounts. This is possible because 1) the password is
used over systems, and over (hence other systems

Site Security Handbook Working Group [Page 3]

Internet Draft Site Security Handbook November 1995

through them, open to any user who wanders by.

Your goals will be largely determined by the term "reusable"), and 2) following key tradeoffs:

(1) services offered vs. security provided -
Each service offered to users carries its own security risks.
For some services the password
passes across risk outweighs the network in clear text.

Several authentication techniques have been developed that address
this problem. Among these techniques are challenge-response
technologies that provide passwords that are only used once (commonly
called one-time passwords). This document provides a list benefit of sources
for products that provide this capability. The decision to use a
product is the responsibility of each organization, and each
organization should perform its own evaluation service
and selection.

3.1.2 Kerberos

3.1.3 Password Assurance

While the need administrator may choose to eliminate the use of standard, reusable passwords
cannot be overstated, it is recognized that some organizations may
have service rather
than try to transition secure it.

(2) ease of use vs. security -
The easiest system to the use of this technology. Given would allow acces to any user and require
no passwords; that situation,
we have included is, there would be no security. Requiring
passwords makes the following sections system a little less convenient, but more secure.
Requiring device-generated one-time passwords makes the system even
more difficult to help with use, but much more secure.

(3) cost of security vs. risk of loss -
There are many different costs to security: monetary (i.e., the selection
cost of purchasing security hardware and
maintenance software like firewalls
and one-time password generators), performance (i.e., encryption
and decryption take time), and ease of traditional passwords. If you have to use them, here
is some pertinent advice.

3.1.3.1 The importance (as mentioned above).
There are also many levels of robust passwords

In almost all cases risk: loss of system penetration, privacy (i.e., the intruder needs to
gain access to an interactive user account on the system. One way
that goal is typically accomplished is through guessing the password
reading of a legitimate user. The intruder may attempt to guess a password information by knowing something about unauthorized individuals), loss of
data (i.e., the legitimate user, corruption or (more commonly)
by trying dictionary words erasure of information), and other simple guesses. This threat is
increased by the easy availability
loss of service (e.g., the password file, since an
intruder may attempt to guess the encrypted passwords in that file by
using another (perhaps faster filling of data storage space, usage
of computational resources, and more powerful) system to run automated
"cracking" tools on the stolen password file. To guard denial of network access). Each
type of cost must be weighed against this
threat, the simplest and most straightforward approach is each type of loss.

Your goals should be communicated to assure that
the passwords on all accounts are not easily guessed. Once the system users, operations staff, and
managers through a set of security rules, called a "computer security
policy."

2.1.1 Definition of a Computer Security Policy

A computer security policy is
guarded against this threat, a formal statement of the intruder would have rules by
which people who are given access to devote an
inordinately large amount organization's technology and
information assets must abide.

2.1.2 Purposes of resources to try to crack your passwords.
It a Computer Security Policy

The main purpose of a computer security policy is more likely that the intruder would try to find another method inform users,
staff and managers of
penetration, or would give up their obligatory requirements for protecting
technology and try another system.

3.1.3.2 Restricting access to the password file information assets. The first step to password assurance policy should specify the
mechanisms through which these requirements can be met. Another
purpose is to limit access provide a baseline from which to acquire, configure and
audit computer systems and networks for compliance with the encrypted
portion policy.
Therefore an attempt to use a set of security tools in the users' password. If the encrypted portion is unavailable
to absence of
at least an attacker, guessing passwords cannot implied security policy is meaningless.

2.1.3 Who Should be done off-line at Involved When Forming Policy?

In order for a remote
(and possibly more powerful) location.

The typical method used security policy to protect the encrypted password is be appropriate and effective, it

Site Security Handbook Working Group [Page 4]

Internet Draft Site Security Handbook November 1995

needs to use a
shadow password file scheme. This requires have the use acceptance and support of two distinct
password files. all levels of employees
within the organization. The first contains following is a list of individuals who
should be involved in the standard password file information
(username, full-name, login directory, creation and shell) but contains review of security policy
documents:

(1) site security administrator
(2) legal counsel
(3) computing center personnel
(4) network administrators of large user groups within the organization
(e.g., business divisions, computer science department within a dummy
university, etc.)
(5) local or
false encrypted password field. This information national security incident response team
(6) representatives of the user groups affected by the security policy

The list of above is kept in another
password file that representative of many organizations, but is not
necessarily comprehensive. The idea is available only to the root user or system. In this
case, standard system utilities (such as FTP) bring in representation
from key stakeholders, management who have budget and policy
authority, technical staff who know what can and users without elevated
privileges cannot gain access to be supported,
and legal counsel who know the legal ramifications of various policy
choices. Involving this information.

It group is important if resulting policy
statements are to note that use of a shadow password file does not
remove the need for robust password selection on reach the part broadest possible acceptance.

2.2 What Makes a Good Computer Security Policy?

The characteristics of the user,
but is one additional protection against penetration.

3.1.3.3 Initial password selection

One problem often found in systems that have been penetrated is that a user's initial password, set by the good security policy are:

(1) It must be implementable through system administrator, is easily
guessed by an intruder. While the setting administration
procedures, publishing of this password is usually
accompanied by the request that the password acceptable use guidelines, or other
appropriate methods.

(2) It must be changed as soon as the
account enforcible with security tools, where appropriate,
and with sanctions, where actual prevention is used, many users lack the knowledge or motivation to change
it. Also, by giving a user a simple password, the system administrator
sets up an expectation on not technically
feasible.

(3) It must clearly define the part areas of responsibility for the user that simple passwords are
acceptable. Therefore, a naive user is unlikely to select
users, staff, and administrators.

The components of a more robust
password, since 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 passwords tend issues as monitoring of electronic mail, logging of
keystrokes, and access to be harder users' files.

(3) An Access Policy which defines access rights and privileges to remember.

Because of this threat, the system administrator
protect assets from loss or disclosure by specifying acceptable use
guidelines for users, operations staff, and management. It should follow some
sensible
provide guidelines (such as the criteria shown below) for selecting
"good" initial passwords for the users of the system, and for selecting external connections, data communications,
connecting devices to a good root password as well. The system administrator network, and adding new software to
systems. It should also specify any required notification messages

Site Security Handbook Working Group [Page 5]

Internet Draft Site Security Handbook November 1995

(e.g., connect messages should provide users with guidance on choosing their own robust passwords.

3.1.3.4 Password selection criteria

Many users give little thought to what makes a "good" password, warnings about authorized
usage and
would be surprised at just how easy some passwords are for intruders to
guess. Unfortunately, line monitoring, and not simply say "Welcome").

(4) An Accountability Policy which defines the increasing power responsibilities of computing is making
password "cracking" far easier than ever before. users,
operations staff, and management. It is now fairly
trivial should specify an audit
capability, and provide incident handling guidelines (i.e., what to launch
do and who to contact if a brute-force attack on any 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 four characters
or less. Also, authentication devices (e.g., one-time
passwords and the devices that generate them).

(6) An Availability statement which sets users' expectations for the increasing
availability of disk space is allowing
intruders access to complete dictionaries of not only English, but many
foreign languages resources. It should address redundancy and recovery
issues, as well. Some password selection criteria 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 can
reasonably indicates which types of
violations (e.g., privacy and security, internal and external)
must be included reported and to whom the reports are made. A
non-threatening atmosphere and the possibility of anonymous reporting
will result in a password policy are:

o The minimum password length should be 7-8 characters
. o The password should not be greater probability that a permutation violation will be
reported if it is detected.

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

There may be regulatory requirements that affect some aspects of your
security number.
o policy (e.g., line monitoring). The password creators of the
security policy should not be contained in any English or foreign
dictionary consider seeking legal assistance in regular use. This includes real/imaginary character
names or terms from folklore.
o The password should not consist the
creation of acronyms or project-specific
information relating to the user's job or function.

While these criteria may seem overly restrictive, there are many
schemes that will generate hard to guess passwords that are still easy
to remember. One example is to take policy. At a well known phrase and use minimum, the
first or second letter of each word to form policy should be reviewed
by legal counsel.

Once your password. Another is computer security policy has been established it should be
clearly communicated to use two short words separated by users, staff, and management. Having all
personnel sign a control or punctuation character.

3.1.3.5 Password aging

When statement indicating that they have read,
understood, and how agreed to expire passwords abide by the policy is still a subject an important part of controversy among
the security community. It is generally accepted that a password process. Finally, your policy should
not be maintained once an account is no longer in use, but reviewed on a regular
basis to see if it is hotly
debated whether successfully supporting your security needs.

3. ARCHITECTURE

3.1 Objectives

3.1.1 Completely defined security plans

Site Security Handbook Working Group [Page 6]

Internet Draft Site Security Handbook November 1995

Defining a user comprehensive security plan should be forced to change done by all sites.
This plan should be at a good password that's
in active use. The arguments for changing passwords relate to the
prevention of the continued use of penetrated accounts. However, higher level than the
opposition claims that frequent password changes lead to users writing
down their passwords specific policies
discussed in visible areas (such section 2. It should be crafted as pasting them to a
terminal), or to users selecting very simple passwords that are easy to
guess.

While there is no definitive answer to this dilemma, a password policy
should directly address the issue and provide framework of broad
guidelines for how often
a user should change the password. into which specific policies will fit.

It is recommended important to have this framework in place so that passwords individual
policies can be
changed whenever root is penetrated, there is consistant with the overall site security
architecture. For example, having a critical change in
personnel (especially if it strong policy with regard to
Internet access, but having weak restrictions on modem usage is the system administrator!), or when
inconsistent with an
account has been compromised. In particular, if the root password is
compromised, all passwords overall philosophy of strong security
restrictions on the system 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 changed. In addition,
an annual change in their password provided; who will
administer those services; etc. It is usually not difficult for most
users, and you should consider requiring it.

3.1.3.6 Machine generated passwords

An alternative also imperative to allowing users define any
limitations on which portions of an organization can provide
services.

Another aspect of the opportunity plan should concern incident handling. Chapter
5 provides an in-depth discussion of responses to select easily guessed
passwords incidents, but it
is important to require machine generated passwords. These have
historically been a problem due to the difficulty define classes of remembering such
passwords. As a result, they were often written down, incidents and therefore more
easily stolen. Another alternative is define responses to present a list
each class of several
machine generated passwords and allow the user incident. For sites with firewalls, how many attempts
to select foil the one that's
easiest for him or her to remember.

It is recommended that if machine generated passwords are mandated by
your policy, then users should not be required firewall will trigger a response? Are there levels of
escallation in both attacks and responses? For sites without
firewalls, does a single attempt to change passwords very
frequently. (For example, not more than once every six months.)

3.1.3.8 Multiple accounts

It is now commonplace for connect constitute an incident?
How about a user systematic scan of machines?

For sites connected to have accounts on many different
systems. One problem is that if the same password is used on all of
these systems, Internet, the penetration rampant media glorification
of one system will easily spread to the
others. It is therefore recommended that Internet related security incidents can overshadow a user should (potentially)
more serious internal security problem. Likewise, companies who have different
passwords
never been on each system. However, if 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 user plans site may wish to use the same
password on more than one system, these systems should all be in the
same administrative domain, and should all be running the same operating
system.

3.1.3.9 Tools provide for password assurance its
users, some of which may be external. There are tools to aid a variety of
security administrator in assuring robust
passwords. These tools fall generally into two categories:
"password cracking" and "password filtering" programs.

Password cracking programs take the encrypted password field and reasons to attempt to perform the same task an intruder would try -- guessing the password
from dictionaries and common words. This is a lengthy process for any isolate services onto dedicated
machines. There are also performance reasons in most cases, but the simplest of schemes since the guesses have a
detailed discussion is beyond to be encrypted once
for each compare against the encrypted password entry. However, the
intruder scope of this document.

The services which a site may provide will, in most cases, have
different levels of access to better dictionaries needs and more powerful systems
than the security administrator. Nonetheless, password cracking programs
provide a mechanism for assuring that no user has a password that is
contained in your own dictionaries. Examples models of tools that provide
password cracking trust. Services which
are "crack" and "cops". Crack is a tool that is
completely devoted essential to password cracking the security and provides smooth operation of a mechanism for
variations site would be
better off being placed on dictionary words, and also provides the ability to
distribute the processing over a network of computers to take advantage
of parallelism. Cops is dedicated machine with very limited
access restrictions (see Section 3.1.3 "deny all" model), rather than
a more general security tool that machine which provides a service (or services) which has password
cracking as one of its functions.
traditionally been less secure, or requires greater accessability by
users who may accidentally suborn security.

It is not as complete as crack, but
serves as a first level also important to distinguish between machines which operate
within different models of protection for a system.

Password filtering programs are replacements for the system utility that
is invoked to change a user's password. In this scheme, trust, say all the user submits machines inside of a plain-text password to

Site Security Handbook Working Group [Page 7]

Internet Draft Site Security Handbook November 1995

firewall, and any machines on an exposed network.

Some of the tool, services which checks 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 password against
some criteria before changing weakest link
in the encrypted password on chain. Several of the system.
This scheme most publicized penetrations in recent
years has been through the advantage that more tests can be run against electronic mail systems of machines. The
intruders were not trying to steal electronic mail, but they used the
plain-text password (such as a check for recurring patterns or reverse
words)
vulnerability in that would be very expensive system to check for in a password cracking
program. gain access to other systems.

If such possible, each service should be running on a tool different machine
whose only duty is installed, it should completely replace the
password changing to provide a specific service. This help isolate
intruders and setting mechanism so that no user can bypass limit potential harm.

3.1.2.1 Name Servers (DNS and NIS(+))

The Internet uses the
program Domain Name System (DNS) to perform name to
address resolution. The Network Information Service (NIS) and change NIS+
are not used on the password global Internet but are subject to the same risks
internally as a less robust string. An example of
a tool that provides password filtering DNS server. Name-to-address resolution is "npasswd".

3.2 Authorization

Authorization refers critical
to the process secure operation of granting privileges any network. An attacker who can
successfully control or impersonate a DNS server can route traffic to processes and
ultimately users. This differs from authentication in that authentication
is what occurs
quickly subvert numerous security guards. Routine traffic can be
diverted to identify a user. Once identified (reliably), the
privileges, rights, property, compromised system and permissible actions traffic can be monitored or
users can trivially be tricked into offering authentication secrets.
An organization would do well to arrange well known and protected
sites to act as secondary name servers, and also protect their own
DNS masters from denial of the user are
determined by authorization.

<Should "objects" service attacks using filtering routers.

3.1.2.2 Password/Key Servers (NIS(+) and "entities" be defined here?>
Explicity listing the authorized activities KDC)

Machines used for password or key servers protect some of each user (and user process)
with respect the most
valuable information to all resources (objects) is impossible in a reasonable
system. In a real system certain techniques are potential intruder, the encrypted passwords
and/or keys, which can be used to simplify access the
process site. Since many
current schemes of granting and checking authorization(s).

One approach, popularized in UNIX systems, is to assign encryption are either subject to each object
three classes of user - the super user, the owner, and the group. Super
user, dictionary or root, is an entity that has access
brute force attacks, every effort must be made to all portions (and objects)
of the computer. secure these
machines.

3.1.2.3 Authentication/Proxy Servers (SOCKS, FWTK)

The owner use of an object is the "user" who either created
the object or was given it by the super user. proxy servers as a security technique will only continue
to expand. A group is proxy server provides a collection number of
users that share privileges over security
enhancements. It allows sites to concentrate services through a collection of objects. Groups ease
authorization management by simplifying the process of changing the
authorization of users and by changing the authority
specific machine for monitoring, hiding of a group to manage
an object.

Another approach is to attach to internal structure, etc.
This funnelling effect creates an object attractive target for a list which explicitly contains
the identity potential
intruder.

3.1.2.4 Email

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

Site Security Handbook Working Group [Page 8]

Internet Draft Site Security Handbook November 1995

delivered to all permitted users (or groups). This and is an Access Control
List. The advantage usually private, the processing agent
typically requires system privileges to deliver the mail. Most email
implementations perform both portions of these are that they are easily maintained (one
central list per object).

<NOTE: What other methods (short phrases the service, which means the
receiving agent has a direct link to system privileges. There are all that's needed, I
probably know what they refer to) should be mentioned... >

<NOTE: Should
several packages available which allow a separation of the process two
pieces.

3.1.2.5 World Wide Web (WWW)

The WWW is growing in popularity exponentially because of deciding what authorizations are its ease of
use and the powerful abilities to be
granted be described here (or concentrate information services.
Most WWW servers take some directions and actions from the persons
accessing their services. The most common example is that in policies)? Should mechanisms
be described here? >

3.3 Access
3.4 Modems

3.4.1 Modem lines must taking a
request from a remote user and passing the provided information to a
program running on the server to process the request. Those programs
can be managed.

Although subverted easily if they provide convenient access are not written with security in
mind.

3.1.2.6 FTP

FTP allows users to receive and send electronic files in a site for its users, they
can also provide an effective detour around the site's firewalls. For
this reason it is essential point to maintain proper control of modems.

Don't
point manner. Improperly configured ftp servers can allow users intruders
to install copy or replace files at will from throughout a modem line without proper authorization.
This includes temporary installations, e.g. plugging a modem into a
facsimile system. Access to
encrypted passwords, proprietary data, or telephone line overnight.

Maintain the introduction of trojan
horses are just a register few of the possibilities.

3.1.3 Deny all/ Allow all your modem lines. Conduct regular

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
checks and its needs for unauthorized modems; keep your register up
security.

The first option is to date.

3.4.2 Dial-in users must be authenticated.

A username turn off all services and password check should be completed before a user can
access anything then selectively
enable services on your network. Normal password security considerations
(such a case by case basis, be it at the machine or
network level, as choosing passwords which don't appear in dictionaries and
changing them from time to time) they are particularly important.

Remember that telephone lines can needed. This model, which will here after
be tapped, and that it is quite
easy to intercept messages referred to cellular 'phones. Modern high-speed
modems use more sophisticated modulation techniques -, which makes
them somewhat as the "deny all" model, is generally more difficult to monitor - but it secure.
More work is prudent to assume
that hackers know how required to eavesdrop on your lines. For this reason you
should use one-shot passwords (e.g. skey) or hardware authentication
devices (e.g. SecureID) if this is at all possible.

It is helpful successfully implement a "deny all"
configuration and usually a better understanding of services; which
may require several pieces operating together to have function correctly.
Only allowing known services allows a single dial-in point, e.g. better analysis of a single large
modem pool, so that all users are authenticated in particular
service/protocol, and the same way.

Users will occasionally mis-type a password. Set design of a short delay - say
two seconds - after security mechanism suited to
the first and second failed logins, and force a
disconnect after security level of the third. This site.

The other model, which will slow down automated password
attacks. Don't tell the user whether the username, the password or
both were incorrect.

3.4.3 All logins (successful and unsuccessful) should here after be logged.

Don't keep correct passwords in referred to as the log, but consider keeping incorrect
passwords "allow
all" model, is much easier to aid in detecting password attacks. However, bear implement, but is in mind
that most incorrect passwords are correct passwords with one character
mistyped, and may suggest general less
secure than the real password. If you can't keep this
information secure, don't log it "deny all" model. Simply turn on all services,
usually the default at all.

If Calling Line Identification is available, take advantage of it
by recording the calling number for each login attempt. Be sensitive host level, and allow all protocols to
travel across network boundaries, usually the privacy issues raised by Calling Lne Identification. Also 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
aware that Calling Line Identification is not applied to different portions of the
site, depending on functionality requirements, administrative

Site Security Handbook Working Group [Page 9]

Internet Draft Site Security Handbook November 1995

control, site policy etc. For example, the policy may be trusted; to use the
data for informational purposes only, not
"allow all" model when setting up workstations for authentication. <NOTE:
it was suggested that we add " Caller ID data can be read from a
compatible modem via general use, but
adopt a serial line" >

3.4.5 Minimize the amount of "deny all" model when setting up 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 servers, like 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
email hub. Likewise, an incoming call until "allow all" policy may be adopted for
traffic between LAN's internal to the user has typed in
(without any echoing) a password. This effectively simulates site, but a dead
modem.

3.4.6 Call-back Capability

Some dial-in servers offer call-back facilities, i.e. "deny all" policy
can be adopted between the user dials
in site and is authenticated, then the system disconnects Internet.

Be careful when mixing philosophies as in the call examples above. Many
sites adopt the M & M theory of a hard "crunchy" shell and calls
back on a specified number. You will probably have soft
"squishy" middle. They are willing to pay the charges cost of security for
such calls.
their external traffic and require strong security measures, but are
unwilling or unable to provide similar protections internally. This feature should be used with caution; it
works fine as long as the outer defenses are never breached and the
internal users can easily be bypassed.
As a minimum, make sure that trusted. Once the return call outer shell (firewall) is never made from
breached, subverting the
same modem as the incoming one. Overall, although call-back can
improve modem security, you should not depend 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 it alone.

3.4.7 Dial-out authentication

Dial-out users should also be authenticated, particularly since your
site will have the Internet at large. Managing security is in
many ways managing access to pay their telephone charges.

Never allow dial-out from an unauthenticated dial-in call, services internal to the site and consider
whether you will allow it from an authenticated one. The goal here is
managing how internal users access information at remote sites.

Services tend to prevent callers using your modem pool rush like waves over the Internet. Over the years
many sites have established anonymous ftp servers, gopher servers,
wais servers, www servers, etc. as part of they became popular but not
particularly needed at all sites. Evaluate all new services that are
established with a chain of logins.
This 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 hard modified
to detect, particularly if a hacker sets up a path
through several hosts 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 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
machine can be implemented easily if you run
separate dial-in and dial-out modem pools.

3.4.8 Make your modem programming as 'bullet-proof' as possible.

Be sure modems can't be reprogrammed while they're interact in service. As a
minimum, make sure that three plus signs won't put your dial-in modems
into command mode!

Program your modems catastrophic ways. (ex. allowing anonymous
ftp on the same machine as the www server may allow an intruder to reset
place a file in the anonymous ftp area and cause the http server to your standard configuration at
execute it.)

3.2 Network and Service Configuration

3.2.1 Protecting the
start of each new call. Failing this, make them reset at the end of
each call. This precaution will Infrastructure

Many network administrators go to great lengths to 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 hosts
on their networks. Few administrators make any effort to protect the 'phone line
properly. It
networks themselves. There is equally important that the server forces logouts from
whatever sessions were active if 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 user hangs up unexpectedly.

3.5 Cryptography

3.6 Auditing

This section covers hosts; damaging the procedures for collecting data generated by network
activity that may be useful in analyzing would
not serve their purposes. That said, there are still reasons to
protect the security of a networks. For example, an intruder might divert network and/or
useful
traffic through an outside host in responding order to a examine the data (i.e.,
to search for passwords). Also, infrastructure includes more than
the networks and the routers which interconnect them. Infrastructure

Site Security Handbook Working Group [Page 10]

Internet Draft Site Security Handbook November 1995

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

The infrastructure also covers the
handling, preservation, 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 utilization of unless
that host is a primary server, the data.

(This number of affected users will
therefore be reworked as I develop limited. However, if a router is misconfigured, all
users who require the remainder.)

3.6.1 What to collect

Audit data should include any attempt to achieve network will be affected. Obviously, this is a different security level
far larger number of users than those depending on any person, process, or other entity in one host.

3.2.2 Protecting the network. Network

There are several problems to which networks are vulnerable. The most obvious
example in this area
classic is a log "denial of attempts to login service" attack. In this case, the network
is brought 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 state in which it can no longer carry legitimate
users' data. There are two common ways this can be done: by
attacking the "remote"
host.

And on routers and on...

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

3.6.2 Collection Process

The collection process should be enacted by flooding the host or resource being
accessed. Depending network with extraneous
traffic. An attack on the importance of the data and the need router is designed to have cause it
local in instances in which services are being denied, data could be kept
local to the resource until needed stop
forwarding packets, or be transmitted to storage after each
event.

Reporting data can forward them improperly. The former case
may be done by writing to a file, writing due to a line printer,
writing over misconfiguration, the injection of a network, spurious routing
update, or writing over a non-network port, such as "flood attack" (i.e., the router is bombarded with
unroutable packets, causing its performance to degrade). A flood
attack on a
console port. Each of these has importance.

File system logging network is similar to a flood attack on a router, except
that the least resource intensive flood packets are usually broadcast. An ideal flood attack
would be the injection 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 single packet which exploits some known
flaw in the first network nodes and causes them to go. If retransmit the network in
front packet,
or generate error packets, each of the resource has become unusable, the data is inaccessible, unless
a direct console port is available.

Line printer logging which is useful in system where permanent picked up and immediate logs
are required. repeated by
another host. A real time system is well chosen attack packet can even generate an example of this, where the exact
point
exponential explosion of a failure 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 must be recorded. A laser printer, or other
device which buffers data between only
in the auditing system and storage device
may suffer from lost data if buffers contain purpose behind the needed data at a critical
instant.

Reporting over spurious route. In denial of service, the
object is to make the router unusable; a state which will be quickly
detected by network provides for allowing users. In spoofing, the spurious route will
cause packets to be routed to a remote host to store from which an intruder may
monitor the data in a more permanent and possibly more reliable manner. the packets. These packets are then be re-routed
to their correct destinations. However, this
consumes bandwidth (at the minimum), exposes intruder may or may not
have altered the audit data in an easy
package to a interloper, and could be lost during network denial.

Reporting over a console port ensures contents of the delivery packets.

The solution to most of these problems is to protect the data follows routing
update packets sent by the
hardware design. The limitations routing protocols in use (e.g., RIP-2,
OSPF). There are that the console port requires
physical security three levels of protection: clear-text password,
cryptographic checksum, and using console ports on machines more than a short
distance away (e.g., across a campus) may require a phone line in addition encryption. Passwords offer only minimal
protection against intruders who do not have direct access to the network connection. In
physical networks. Passwords also offer some instances, this protection against
misconfigured routers (i.e, routers which, out of the box, attempt to
route packets). The advantage of passwords is one more resource that may be constrained.

3.6.3 Collection Load

Collecting running data may result in they have a quick accumulation of bytes.
Storage of this must be considered very
low overhead, in advance. There are a few ways to
limit both bandwidth and CPU consumption. Checksums
protect against the required storage space. Data may be compressed using one injection of many
methods. Another approach is spurious packets, even if the
intruder has direct access to only archive summaries of activity
(possibly losing some detail in the process). Data may be archived for
just physical network. Combined with a fixed period of time, then

Site Security Handbook Working Group [Page 11]

Internet Draft Site Security Handbook November 1995

sequence number, or other unique identifier, a checksum can also
protect again "replay" attacks, wherein an old (but valid at the
time) routing update is it permanently removed. retransmitted by either an intruder or a
misbehaving router. The issue of archiving most security data differs from archiving network
management and application data. Network management data (statistics) can
be reduced is provided by altering complete
encryption of sequenced, or uniquely identified, routing updates.
This prevents an intruder from determining the reporting period. Security data does not have
that option (for topology of the most part). Security data also does not have
network. The disadvantage to encryption is the
permanence of application data.

3.6.4 Handling overhead involved in
processing 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" 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 impersonate an authorized
administrator.

Data may also become key each base protocol to the investigation, apprehension, support MD5 encryption.

Unfortunately, there is no adequate protection against a flooding
attack, or prosecution a misbehaving host or router which is flooding the
network. Fortunately, this type of attack is obvious when it occurs
and can be terminated relatively simply.

3.2.3 Protecting the perpetrator Services

There are many types of an incident. Because services; each has its own security
requirements. These requirements will vary based on the intended use
of this, the data needs to be
protected and clearly documented. service. For this reason it example, a service which should only be usable
within a site (e.g., NFS) requires little protection. That is,
protecting the server from external access is advisable sufficient to seek protect
the advice of local legal council or law enforcement when deciding how 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 data is may be required to prevent unauthorized
access and modification of the Web database.

Internal services (i.e., services meant to be treated. This should happen before an incident
occurs.

If used only by users
within a data handling plan is not cleared prior site) and external services (i.e., services deliberately
available to an incident, this does not
mean that it is useless. It means two things. You may not have recourse users outside a site) will, in general, have protection
requirements which differ as previously described. It is therefore
wise to isolate the aftermath internal services to one set of an event. You may also me liable for penalties
resulting from your treatment of the data too.

3.6.5 Audit Data Precautions

In certain instances, audit data may contain personal information.
Searching through the data, even for just a routine check of the network's
security could present an invasion of privacy or make server machines
and the auditing entity
privy external services to information it another set of server machines. That
is, internal and external servers should not be allowed co-located. In fact,
many sites go so far as 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 have one set of incidents. If an organization knows about subnets (or even different
networks) which are accessible from the incidents but permits
them to continue outside and this results in damage to another organization
("downstream"), legal action could result. An organization set which
may also be
liable for not (making a "best effort" to) analyze this data for incidents.

3.7 Backups

4. ARCHITECTURE

4.1 Objectives
4.2 Service Configurations
4.3 Network Configurations
Topology
Infrastructure elements (DNS, mail hub, information servers, etc.)
Network management
4.4 Firewalls

5. INCIDENT HANDLING

This section of accessed only within the document will supply guidance to be applied before,
during and after a computer security incident site. Of course, there is in progress on a machine,
network, site, or multi-site environment. The operative philosophy in the
event of usually a breach of computer security is to react according
firewall which connects these partitions. Great care must be taken
to ensure that such a plan.
This is true whether the breach firewall is the result operating properly.

One form of an external intruder
attack, unintentional damage, a student testing service deserves some new program to
exploit a software vulnerability, special consideration, and
that is anonymous, or a disgruntled employee. Each of the
possible types of events described above should guest, access. This may be considered for an
adequate contingency plan. Without a proactive approach either anonymous
FTP or guest (unauthenticated) login. It is extremely important to protect
the assets in case of an incident the handling process can not be as
efficient as with well prepared procedures, methods
ensure that anonymous FTP servers and policies in place.

Traditional computer security, while quite important in the overall
site security plan, usually falls heavily on protecting systems guest login userids are
carefully isolated from
attack, any hosts and perhaps monitoring file systems from which outside
users should be kept. Another area to detect attacks. Little which special attention is usually must
be paid concerns anonymous, writable access. A site may be legally
responsible for how to actually handle the attack when
it occurs. The result content of publicly available information, so
careful monitoring of the information deposited by anonymous users is that when an attack
advised.

Site Security Handbook Working Group [Page 12]

Internet Draft Site Security Handbook November 1995

3.2.4 Protecting the Protection

It is amazing how often a site will overlook the most obvious
weakness in progress, many
decisions are made in haste its security by leaving the security server itself open
to attack. Based on considerations previously discussed, it should
be clear that: the security server should not be accessible from
off-site; should offer minimum access, except for the authentication
function, to users on-site; and can should not be damaging co-located with any
other servers. Further, all access to tracking down the
source of the incident, collecting evidence node, including access to
the service itself, should be used logged to provide a "paper trail" in prosecution
efforts, preparing for
the recovery event of a security breach.

3.3 Firewalls

4. SECURITY PROCEDURES

4.1 Authentication

For many years, the system, and protecting prescribed method for authenticating users has
been through the
valuable data contained on use of standard, reusable passwords. Originally,
these passwords were used by users at terminals to authenticate
themselves to a central computer. At the system.

One time, there were no
networks (internally or externally) and hence the risk of disclosure
of the most important but often overlooked benefit for efficient
incident handling is an economic one. Having both technical cleartext password was minimal. Today, systems are connected
together through local networks, and
managerial personnel respond to an incident requires considerable
resources, resources which could be utilized more profitably if an
incident did not require their services. If these personnel those local networks are
trained further
connected together, and to handle an incident efficiently, less of the Internet. Users are logging in from
all over the globe, and their time is
required to deal with that incident.

Due reusable passwords are often
transmitted across those same networks in cleartext, ripe for anyone
inbetween to capture. And indeed, the worldwide network most CERT Coordination Center and
other response teams are seeing a tremendous number of the incidents
involving packet sniffers which are not restricted
to one site only. Operating systems vulnerabilities apply (in some
cases) to several millions capturing the cleartext
passwords. To address this threat, we are including sections on
better technologies like one-time passwords, and Kerberos.

With the advent of systems newer technologies like one-time passwords (e.g.,
S/Key), PGP, and many vulnerabilities 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
exploited within the network itself. Therefore foundation upon which stronger
authentication techniques are based. If these secret tokens and pins
are not properly selected and protected, the authentication will be
easily subverted.

4.1.1 One-Time passwords

As mentioned above, given today's networked environments, it is vital for
all sites
recommended that all involved parties are informed as soon as possible.

Another benefit is related to public relations. News sites concerned about
computer the security and integrity of
their systems and networks consider moving away from standard,
reusable passwords. There have been many incidents tends to be damaging to an
organization's stature among current or potential clients.
Efficient incident handling minimizes involving Trojan
network programs (e.g., telnet and rlogin) and network packet
sniffing programs. These programs capture cleartext hostname,
account name, password triplets. Intruders can use the potential captured
information for negative
exposure.

A final benefit of efficient incident handling is related subsequent access to legal
issues. It those hosts and accounts. This
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 1) the patches or
workarounds themselves damage systems. Knowing about operating
system vulnerabilities password is used over and patterns of attacks over (hence the
term "reusable"), and then taking
appropriate measures is critical to circumventing possible legal
problems.

This chapter is arranged such 2) the password passes across the network in

Site Security Handbook Working Group [Page 13]

Internet Draft Site Security Handbook November 1995

clear text.

Several authentication techniques have been developed that address
this problem. Among these techniques are challenge-response
technologies that provide passwords that are only used once (commonly
called one-time passwords). This document provides a list of relevant topics may be
generated from the Table of Contents to sources
for products that provide this capability. The decision to use a starting point for
creating a policy for handling ongoing incidents. The main points to
be included in a policy for handling incidents are:

o Preparing and planning (what are the goals and objectives in
handling an incident).
o Notification (who should be contacted in case of an incident).
o Evaluation (how serious
product is the incident).
o Handling (what should be done when an incident occurs).
This especially includes:
- Notification (who responsibility of each organization, and each
organization should be notified perform its own evaluation and selection.

4.1.2 Kerberos

4.1.3 Choosing and systems).
- Follow Up (what actions should Protecting Secret Tokens and Pins

4.1.4 Password Assurance

While the incident).
- Legal/Investigative implications (what are need to eliminate the legal and
prosecutorial implications use of the incident).
- Documentation Logs (what records should standard, reusable passwords
cannot be kept from before,
during, and after overstated, it is recognized that some organizations may
have to transition to the incident).
o Aftermath (overall implications use of past incidents).
o Responsibilities (for planning better technology. Given that
situation, we have included the following advice to help with the
selection and handling an incident).

Each maintenance of traditional passwords. But remember,
none of these points is important in an overall plan for handling
incidents. measures provides protection against disclosure due to
sniffer programs.

(1) The remainder importance of this chapter will detail the issues
involved in each robust passwords - In many (if not most) cases of
system penetration, the relevant topics, and provide some guidance
as intruder needs to what should be included in a site policy for handling incidents.

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

5.1 Preparing system, and Planning for Incident Handling

Part of handling an incident one way that goal is being prepared to respond before typically accomplished is
through guessing the incident occurs. password of a legitimate user. This includes establishing is often
accomplished by running an automated password cracking program,
which utilizes a suitable level
of protections as explained in very large dictionary, against the chapters before. Not system's password
file. The only are
incidents avoided through way to guard against passwords being disclosed in this protection but if the incident
becomes severe, the damage which can occur
manner is limited. Protection
includes preparing incident handling guidelines as part of a
contingency plan for your organization or site. Having written
plans eliminates much of through the ambiguity careful selection of passwords which occurs during an
incident, cannot be
easily guessed (i.e., combinations of numbers, letters, and will lead to a more appropriate punctuation
characters).

(2) Changing default passwords - Many operating systems and thorough set of
responses. As explained for application
programs are installed with default accounts and passwords. These
must be changed immediately to something that cannot be guessed or
cracked.

(3) Restricting access to the password file - In particular, a site specific contingency plan in
section xxx it is vital important
wants to test protect the proposed plan before
an incident actually occurs through 'dry runs'.

Once encrypted password portion of the file so that
would-be intruders don't have them available for cracking. One
effective technique is to use shadow passwords where the password
field of the standard file contains a site has recovered from and incident, site policy dummy or false password. The
file containing the legitimate passwords are protected elsewhere on
the system.

(4) Password aging - When and
procedures should be reviewed to encompass changes how to prevent
similar incidents. If an incident expire passwords is based on poor policy, and
unless still a subject of
controversy among the policy is changed, then one security community. It is doomed to repeat the past.
Even without generally accepted that

Site Security Handbook Working Group [Page 14]

Internet Draft Site Security Handbook November 1995

a password should not be maintained once an incident, account is no longer in use,
but 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 is hotly debated whether a problem reporting procedure user should be implemented forced to describe, change a
good password that's in detail, the incident and the solutions active use. The arguments for changing
passwords relate to the incident. Each
incident should be reviewed by prevention of the site security subgroup to allow
understanding continued use of penetrated
accounts. However, the incident with possible suggestions opposition claims that frequent password changes
lead to the
site policy and procedures.

Learning users writing down their passwords in visible areas (such as
pasting them to respond efficiently a terminal), or to an incident is important for
numerous reasons:

o protect the assets which users selecting very simple passwords
that are easy to protect by normal security
in case of a worst event
o protect your resources which could guess. It should also be utilized more profitably
if an incident did not require their services
o take care stated that (government) regulations are complied with
o prevent an intruder will
probably use of your systems against other systems (which
could incur legal liability)
o minimize the potential for negative exposure

As a captured or guessed password sooner rather than later,
in which case password aging provides little if 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 protection.

While there is no definitive answer to this dilemma, a password policy
should directly address the goals for security in general. Therefore,
the same issue and provide 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:

o Figure out how it happened.
o Find out how to avoid further exploitations.
o Avoid escalation and further incidents.
o Recover from the incident.
o Find out who did it.

Due to the nature of often
a user should change the incident there might password. It is recommended that passwords be
changed whenever root is penetrated, there is a conflict between
analyzing critical change in
personnel (especially if it is the original source of a problem instead of restoring
systems and services. system administrator!), or when an
account has been compromised. In this case overall goals (like assuring particular, if the integrity of (life) critical systems) might be the reason for
not analyzing an incident. Of course this root password is an important management
decision, but
compromised, all involved parties must be aware that without a
analysis passwords on the same incident may happen again.

It is important to prioritize actions to system should be taken during changed. In
addition, an
incident well annual change in advance of the time an incident occurs.
Sometimes an incident may be so complex that it their password is impossible to
do everything at once usually not difficult
for most users, and you should consider requiring it.

4.2 Authorization

Authorization refers to respond the process of granting privileges to it; priorities are essential.
Although priorities will vary
processes and ultimately users. This differs from institution authentication in
that authentication is what occurs to institution, the
following suggested priorities may serve as identify a starting point for
defining an organization's response:

o Priority one -- protect human life user. Once
identified (reliably), the privileges, rights, property, and people's
safety; human life always has precedence over all
other considerations.

o 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
permissible actions of regulations by your site or the user are determined by government)

o Priority three -- protect other data, including
proprietary, scientific, managerial authorization.

Should "objects" and other data,
because loss "entities" be defined here?> Explicity listing
the authorized activities of data each user (and user process) with
respect to all resources (objects) is costly impossible in terms of resources.
Prevent exploitations of other systems, networks or
sites and inform already effected systems, networks or
sites about successful penetrations.

o Priority four -- prevent damage to systems (e.g., loss
or alteration of a reasonable
system. In a real system files, damage to disk drives,
etc.); damage certain techniques are used to systems can result in costly down
time and recovery.

o Priority five -- minimize disruption simplify the
process of computing
resources; it is better granting and checking authorization(s).

One approach, popularized in many cases to shut a system
down or disconnect from a network than UNIX systems, is to risk damage assign to data each
object three classes of user - the super user, the owner, and the
group. Super user, or systems.

An important implication for defining priorities root, is an entity 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 has access to have any
damage or loss during an incident, systems can be replaced; all
portions (and objects) of the
loss or compromise computer. The owner of data (especially classified data), however,
is usually not an acceptable outcome under any circumstances.

Another important concern object is
the effect on other, beyond the
systems and networks where "user" who either created the incident occurs.
Additionally to government regulations object or was given it by the super
user. A group is always important
to inform effected parties at soon as possible. Due to a collection of users that share privileges over a
collection of objects. Groups ease authorization management by
simplifying the fact process of legal implications this topic should be addressed in changing the plans
to avoid further delays authorization of users 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 your site makes chooses how it reacts to incidents will
shape your response. For example, it may make little sense
changing the authority of a group to create
mechanisms manage an object.

Another approach is to monitor and trace intruders if your site does not plan attach to take action against an object a list which explicitly
contains the intruders if they identity of all permitted users (or groups). This is an
Access Control List. The advantage of these are caught. Other
organizations may have policies that affect your plans. Telephone
companies often release information about telephone traces only they are easily
maintained (one central list per object).

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

Site Security Handbook Working Group [Page 15]

Internet Draft Site Security Handbook November 1995

<NOTE: Should the process of deciding what authorizations are to
law enforcement agencies.

You may also note that if any legal action be
granted be described here (or is planned, there
are specific guidelines that in policies)? Should
mechanisms be described here? >

4.3 Access

4.4 Modems

4.4.1 Modem lines must be followed managed

Although they provide convenient access to make sure that
any information collected a site for its users, they
can be used as evidence.

5.2 Notification and Point of Contacts

It also provide an effective detour around the site's firewalls.
For this reason it is essential to maintain proper control of modems.

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

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

4.4.2 Dial-in users must be authenticated

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

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

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

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

4.4.3 All logins (successful and unsuccessful) should be logged

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

Site Security Handbook Working Group [Page 16]

Internet Draft Site Security Handbook November 1995

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

4.4.5 Minimize the amount of information given in your opening banner

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

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

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

4.4.6 Call-back Capability

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

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

4.4.7 Dial-out authentication

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

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

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

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

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

Site Security Handbook Working Group [Page 17]

Internet Draft Site Security Handbook November 1995

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

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

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

4.5 Cryptography

4.6 Auditing

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

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

4.6.1 What to collect

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

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

And on and on...

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

4.6.2 Collection Process

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

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

Site Security Handbook Working Group [Page 18]

Internet Draft Site Security Handbook November 1995

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

Line printer logging is useful in system where permanent and
immediate logs are required. A real time system is an example of
this, where the exact point of a failure or attack must be recorded.
A laser printer, or other device which buffers data between the
auditing system and storage device may suffer from lost data if
buffers contain the needed data at a critical instant.

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

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

4.6.3 Collection Load

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

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

4.6.4 Handling the Data/Preservation

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

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

Site Security Handbook Working Group [Page 19]

Internet Draft Site Security Handbook November 1995

should happen before an incident occurs.

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

4.6.5 Audit Data Precautions

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

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

4.7 Backups

5. SECURITY INCIDENT HANDLING

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

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

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

Site Security Handbook Working Group [Page 20]

Internet Draft Site Security Handbook November 1995

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

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

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

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

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

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

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

Guidelines for End User involvement in dealing with compromised

Site Security Handbook Working Group [Page 21]

Internet Draft Site Security Handbook November 1995

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

5.1 Preparing and Planning for Incident Handling

Part of handling an incident is being prepared to respond before the
incident occurs. This includes establishing a suitable level of
protections as explained in the chapters before. Not only are
incidents avoided through this protection but if the incident becomes
severe, the damage which can occur is limited. Protection includes
preparing incident handling guidelines as part of a contingency plan
for your organization or site. Having written plans eliminates much
of the ambiguity which occurs during an incident, and will lead to a
more appropriate and thorough set of responses. As explained for the
site specific contingency plan in section xxx it is vitally important
to test the proposed plan before an incident actually occurs through
'dry runs'. A team might even consider hiring a tiger team to act in
parallel with the dry run.

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

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

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

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

Site Security Handbook Working Group [Page 22]

Internet Draft Site Security Handbook November 1995

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

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

It is important to prioritize actions to be taken during an incident
well in advance of the time an incident occurs. Sometimes an
incident may be so complex that it is impossible to do everything at
once to respond to it; priorities are essential. Although priorities
will vary from institution to institution, the following suggested
priorities may serve as a starting point for defining an
organization's response:

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

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

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

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

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

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

Site Security Handbook Working Group [Page 23]

Internet Draft Site Security Handbook November 1995

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

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

The policies chosen by your site on how it reacts to incidents will
shape your response. For example, it may make little sense to create
mechanisms to monitor and trace intruders if your site does not plan
to take action against the intruders if they are caught. Other
organizations may have policies that affect your plans. Telephone
companies often release information about telephone traces only to
law enforcement agencies.

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

5.2 Notification and Point of Contacts

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

o Point

Communication may need to be established with various "Points of Contact (POC) people (Technical, Administrative,
Response Teams, Investigative, Legal, Vendors,
Contact." These may be technical or administrative in nature, may
include legal or investigative agencies, as well as Service
providers), Providers
and which POCs are visible vendors. It is important to whom.
o Wider community (users).
o Other sites that might decide how much information will be affected.
o The
shared, especially with the wider community of users at a site, with
the public (press).

These (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. 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 additional confusion and wasted or ineffective effort.

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

The point of contact must be a person with the technical expertise to
successfully coordinate the effort of the system managers and users
involved in monitoring and reacting to the attack. Often the
management structure of a site is such that the administrator of a
set of resources is not a technically competent person with regard to
handling the details of the operations of the computers, but is
ultimately responsible for the use of these resources.

Another important function of the POC is to maintain contact with law
enforcement and other external agencies to assure that multi-agency 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 able 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 evidence collected, 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.

It is very important to prepare a method of notification, so that
you will know who to call and how to contact them. For example,
every member

One of the Department most critical tasks for the POC is the coordination of Energy's CIAC Team carries a card
with every other team member's work and home phone numbers, as well
as pager numbers.

<no text yet>
+ all
relevant processes. As responsibilities are might be distributed over
the whole site, this has
strong implications which in fact can consist of multiple independent
departments or groups, a well coordination effort is crucial for coordinating
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
+ in multi-site incidents this even gets worser
+ the POS 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 changed during informed. Arrangements should be made to allow the
new POC to contact the old one, to ensure an incident because adequate briefing of conflicting
priorities/responsibilities
background information.

5.2.2 Law Enforcement and Investigative Agencies

In the event of an incident it is important to establish contact with
investigative agencies such as the FBI and Secret Service or their
equivalent in your country, as soon as possible, for several reasons. possible. Local law
enforcement and local security offices or campus police organizations departments
should also be informed when appropriate. A primary reason is that
once a major attack is in progress, there is little time to call
various personnel in these agencies to determine exactly who the
correct point of contact is. Another reason is that it is important
to cooperate with these agencies in a manner that will foster a good
working relationship, and that will be in accordance with the working
procedures of these agencies. Knowing the working procedures in
advance and the expectations of your point of contact is a big step
in this direction. For example, it is important to gather evidence
that will be admissible in a court of law. If you don't know in
advance how to gather admissible evidence, your efforts to collect
evidence during an incident are likely to be of no value to the
investigative agency with which you deal. A final reason for
establishing contacts as soon as possible is that it is impossible to
know the particular agency that will assume jurisdiction in any given
incident. Making contacts and finding the proper channels early will
make responding to an incident go considerably more smoothly.

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

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

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

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

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

Site Security Handbook Working Group [Page 26]

Internet Draft Site Security Handbook November 1995

may be sued if users at your site or elsewhere discover
that your site is monitoring account activity without
informing users.

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

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

The balance between supporting investigative activity and limiting
liability is tricky; you'll need to consider the advice of your
council and the damage the intruder is causing (if any) in making
your decision about what to do during any particular incident.

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

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

One of the most important considerations in dealing with
investigative agencies is verifying that the person who calls asking
for information is a legitimate representative from the agency in
question. Unfortunately, many well intentioned people have
unknowingly leaked sensitive information about incidents, allowed
unauthorized people into their systems, etc., because a caller has
masqueraded as a representative of a government agency (e. g. the FBI
or Secret Service in the US). A similar consideration is using a
secure means of communication. Because many network attackers can
easily reroute electronic mail, avoid using electronic mail to
communicate with other agencies (as well as others dealing with the
incident at hand). Non-secured phone lines (e. g., the phones
normally used in the business world) are also frequent targets for
tapping by network intruders, so be careful!

Site Security Handbook Working Group [Page 27]

Internet Draft Site Security Handbook November 1995

There is no established set of rules for responding to an incident
when the local Government becomes involved. Normally, except by
court order, no agency can force you to monitor, to disconnect from
the network, to avoid telephone contact with the suspected attackers, etc..
etc. As discussed before, you should consult the matter with your
legal counsel, especially before taking an action that your
organization has never taken. The particular agency involved may ask
you to leave an attacked machine on and to monitor activity on this
machine, for example. Your complying with this request will ensure
continued cooperation of the agency--usually agency. This is usually the best route
towards finding the source of the network attacks and, ultimately,
terminating these attacks. Additionally, you may need some information or
a favor from the agency involved in the incident. You are likely to
get what you need only if you have been cooperative. Of particular importance It is avoiding
particularly important to avoid unnecessary or unauthorized
disclosure of information about the incident, including any
information furnished by the agency involved. The trust between your
site and the agency hinges upon your ability to avoid compromising
the case the agency will build; keeping "tight lipped" is imperative.

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

5.2.3 Computer Security Incident Handling Teams

There now exists a number of Computer Security Incident Handling

Site Security Handbook Working Group [Page 28]

Internet Draft Site Security Handbook November 1995

teams (CSIH teams) such as the CERT Coordination Center and the CIAC
or other teams around the globe. Teams exist for many major
government agencies and large corporations. If such a team is
available, notifying it should be of primary importance during the
early stages of an incident. These teams are responsible for
coordinating computer security incidents over a range of sites and
larger entities. Even if the incident is believed to be contained
to
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 trusted dialogue between other teams if none has existed
before. (See [RFC xxx] for more information about the considerations
for creating your own incident handling team.)

5.2.4 Effected and involved Sites

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

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

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

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

Site Security Handbook Working Group [Page 29]

Internet Draft Site Security Handbook November 1995

able to protect the considerations for
creating your own incident handling team.)

5.2.4 Effected anonymity of the original source. But be aware
that in many cases the analysis of logs and involved Sites

<no text yet>
+ special care information at other
sites will reveal addresses of your site.

All the problems discussed should be taken not seen as reasons not to inform
involve other effected sites
+ directly: but who is responsible for the contact, who is
responsible for an incident at sites. In fact, the other experiences of existing teams
reveal that most sites informed about security problems are not even
aware that their site
+ indirectly: utilizing a incident response team
+ responsibility/liability
+ privacy reasons had been compromised. Without timely
information other sites are often unable to protect specific data take measures against
intruders.

5.2.5 Public Relations - Press Releases

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

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

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

(1) Keep the technical level of detail low. Detailed
information about the incident may provide enough
information for copy-cat events or even damage the
site's ability to prosecute once the event is over.
o
(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.
o
(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.
o
(4) Try not to be forced into a press interview before you are
prepared. The popular press is famous for the "2am"
interview, where the hope is to catch the interviewee off

Site Security Handbook Working Group [Page 30]

Internet Draft Site Security Handbook November 1995

guard and obtain information otherwise not available.
o
(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 It is Is it real?

This stage involves determining, if a problem really exist. Of
course many, if not most, signs often associated with virus
infections, system intrusions, malicious users, etc., are simply
anomalies such as hardware failures or suspicious system/user
behavior. To assist in identifying whether there really is an
incident, it is usually helpful to obtain and use any detection
software which may be available. For example, widely available
software packages can greatly assist someone who thinks there may be
a virus in a personal computer. Audit information is also extremely
useful, especially in determining whether there is a network attack.
It is extremely important to obtain a system snapshot as soon as one
suspects that something is wrong. Many incidents cause a dynamic
chain of events to occur, and an initial system snapshot may do more
good in identifying the problem and any source of attack than most
other actions which can be taken at this stage. Finally, it is
important to start a log book. Recording system events, telephone
conversations, time stamps, etc., can lead to a more rapid and
systematic identification of the problem, and is the basis for
subsequent stages of incident handling.

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

(1) System crashes.
o
(2) New user accounts (e.g., the account RUMPLESTILTSKIN
has unexplainedly been created), or high activity on
an account that has had virtually no activity for
months.
o
(3) New files (usually with novel or strange file names,
such as data.xx or k).
o
(4) Accounting discrepancies (e.g., in a UNIX system you
might notice that the accounting file called
/usr/admin/lastlog has shrunk, something that should
make you very suspicious that there may be an
intruder).
o
(5) Changes in file lengths or dates (e.g., a user should
be suspicious if he/she observes that the .EXE files in
an MS DOS computer have unexplainedly grown
by over 1800 bytes).
o
(6) Attempts to write to system (e.g., a system manager
notices that a privileged user in a VMS system is
attempting to alter RIGHTSLIST.DAT).
o
(7) Data modification or deletion (e.g., files start to
disappear).
o
(8) Denial of service (e.g., a system manager and all

Site Security Handbook Working Group [Page 31]

Internet Draft Site Security Handbook November 1995

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

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

5.3.2 Types and Scope of Incidents

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

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

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

5.3.3 Assessing the Damage and Extent

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

Site Security Handbook Working Group [Page 32]

Internet Draft Site Security Handbook November 1995

As soon as the breach has occurred, the entire system and all its
components should be considered suspect. System software is the most
probable target. Preparation is key to be able to detect all changes
for a possibly tainted system. This includes checksumming all tapes
from the vendor using a checksum algorithm which (hopefully) is
resistant to tampering [10]. (See sections xxx.) Assuming original
vendor distribution tapes are available, an analysis of all system
files should commence, and any irregularities should be noted and
referred to all parties involved in handling the incident. It can be
very difficult, in some cases, to decide which backup tapes are
showing a correct system status; consider that the incident may have
continued for months or years before discovery, and that the suspect
may be an employee of the site, or otherwise have intimate knowledge
or access to the systems. In all cases, the pre-incident preparation
will determine what recovery is possible. If the system supports
centralized logging (most do), go back over the logs and look for
abnormalities. If process accounting and connect time accounting is
enabled, look for patterns of system usage. To a lesser extent, disk
usage may shed light on the incident. Accounting can provide much
helpful information in an analysis of an incident and subsequent
prosecution.

If you can address all aspects of a specific incident strongly
depends on the success of this analysis. This also effects the efficience
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

A major topic still untouched here is how to actually respond to an
event. The response to an event will fall into the general
categories:

o Containment.
o Eradication.
o Recovery.
o Follow-up.

Two other topics by the incident.

5.4 Handling an Incident

Certain steps are vital for necessary to take during the incident handling and relevant for of an
incident. In all security related activities, the most important
point to be made is: One should have policies in place. Without
defined goals, activities undertaken will remain without focus. One
of the categories mentioned above. They are therefore addressed
before these categories:

o Types most fundamental objectives is to restore control of notification the
effected systems and to limit the exchange of information
o Protection of evidence impact and activity logs

<no text yet>
+ what are damage. In the goals for this process.
+ what is worst
case scenario, shutting down the best way to handle an incident.
+ important: do not system or disconnecting the system
from the network may the only practical solution.

As the activities involved are complex, try to handle the incident alone
+ get as much help as necessary

<no text yet>
+ part of original RFC1244 which is
necessary. While trying to less solve the problem alone, real damage
might occur due to serve delays or missing information. Most system
administrators take the discovery of an intruder as a guideline
but nevertheless personal
challenge. By proceeding this way, other objectives as outlined in
the topics should local policies may not always considered. Trying to catch
intruders may be covered here, too

<NOTE: this a very low priority, compared to system integrity,
for example. One other pitfall is from rfc1244; don't know if it will the premise that by monitoring the
activities of a hacker, other sites can be included
5.4.1 What Will You Do?

o Restore control.
o Relation warned about problems they
have been exposed to. By allowing the intruder to policy.
o Which level of service is needed?
o Monitor activity.
o Constrain (ab)use the local
system, a site may be incurring legal liability or shut down system.

END OF rfc1244 section> indirect
responsibility for the damage caused to other sites.

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

Site Security Handbook Working Group [Page 33]

Internet Draft Site Security Handbook November 1995

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

5.4.1 Types of notification, Exchange of information

When you have confirmed that an incident is occurring, the
appropriate personnel must be notified. How this notification is
achieved is very important in keeping the event under control both
from a technical and emotional standpoint. To aid prompt acknowledgment
and understanding of the problem, the The circumstances should
be described in as much detail as possible. possible, in order to aid prompt
acknowledgment and understanding of the problem. Great care should
be taken to which groups detailed technical information is given
during the notification. For example it is helpful to pass this kind
of information to an incident handling team. They can assist you by
providing helpful hints for eradicating the vulnerabilities involved
in an incident. On the other hand putting the critical knowledge
into the public domain (e. g. netnews, mailing lists) may potentially
put a great number of systems at risk of intrusion. It is a wrong
assumption, that all administrators are reading a particular news
group, have access to operating system source code or can even
understand the techniques well enough to take adequate steps.

First of all, any notification to either local or off-site personnel
must be explicit. This requires that any statement (be it an
electronic mail message, phone call, or fax) provides information
about the incident that is clear, concise, and fully qualified. When
you are notifying others that will help you to handle an event, a
"smoke screen" will only divide the effort and create confusion. If
a division of labor is suggested, it is helpful to provide
information to each section about what is being accomplished in other
efforts. This will not only reduce duplication of effort, but allow
people working on parts of the problem to know where to obtain other
information that would help them resolve a part of the incident.

Another important consideration when communicating about the incident
is to be factual. Attempting to hide aspects of the incident by
providing false or incomplete information may not only prevent a
successful resolution to the incident, but may even worsen the
situation. This is especially true when the press is involved. When
an incident severe enough to gain press attention is ongoing, it is
likely that any false information you provide will not be
substantiated by other sources. This will reflect badly on the site
and may create enough ill-will between the site and the press to
damage the site's public relations.

The choice of language used when notifying people about the incident
can have a profound effect on the way that information is received.
When you use emotional or inflammatory terms, you raise the
expectations of damage and negative outcomes of the incident. It is
important to remain calm both in written and spoken notifications.
Another aspect of the choice of language used is that not all people
speak the same language. Due to this fact misunderstandings and
delay may arise, especially if it is a multi-national incident.

<no text yet>
+ more about

Site Security Handbook Working Group [Page 34]

Internet Draft Site Security Handbook November 1995

Other international aspects 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 to of non-technical or off-site personnel. It is important
to accurately describe the incident without undue alarm or confusing
messages. While it is more difficult to describe the incident to a
non-technical audience, it is often more important. A non-technical
description may be required for upper-level management, the press, or
law enforcement liaisons. The importance of these notifications
cannot be underestimated and may make the difference between handling
the incident properly and escalating to some higher level of damage.

<no text yet>
+ Template

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

If information is given out to someone else, the following minimum
information exchange+
+ Advice for Reporting, e.g. Timezones should be provided:

(1) timezone of logs, ... in GMT,...
+ give whole GMT or local time
(2) information (e.g. about the remote system (including host names,
ip addresses and user ids)
(3) all tcpwrapper log entries belonging to relevant for the incident and not only talking about: "found remote site

If local information (ie. local user ids) is included in the tcp wrapper logs,
I assume ..."
+ international aspects 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 can engage in
a valuable "lessons learned" exercise. Additionally it will help
during later phases of the handling process, especially during the
eradiction and recovery.

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

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

The most straightforward way to maintain documentation is keeping a
log book. This allows you to go to a centralized, chronological
source of information when you need it, instead of requiring you to
page through individual sheets of paper. Much of this information is
potential evidence in a court of law. Thus, when you initially
suspect that an incident will result in prosecution or when an
investigative agency becomes involved, you need to regularly (e.g.,
every day) turn in photocopied, signed copies of your logbook (as
well as media you use to record system events) to a document
custodian who can store these copied pages in a secure place (e.g., a
safe). When you submit information for storage, you should in return
receive a signed, dated receipt from the document custodian. Failure
to observe these procedures can result in invalidation of any
evidence you obtain in a valuable "lessons learned" exercise. Additionally it will help
during later phases court of law.

5.4.3 Containment

The purpose of containment is to limit the handling process, especially during the
eradiction and recovery.

During the initial stages extent of an incident, attack. For
example, it is often infeasible important to
determine whether prosecution is viable, so you should document limit the spread of a worm attack on a
network as if
you are gathering evidence for quickly as possible. An essential part of containment is
decision making (i.e., determining whether to shut a court case. At system down, to
disconnect from a minimum, you
should record:

o All network, to monitor system events (audit records).
o All actions you take (time tagged).
o All phone conversations (including 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 person with whom
you talked,
system down if the date and time, and system is life-critical, classified or sensitive,
or if proprietary information is at risk! In other cases, it is
worthwhile to risk having some damage to the content of system if keeping the
conversation).

The most straightforward way
system up might enable you to maintain documentation 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 keeping especially important
when a
log book. This allows you quick decision is necessary without the possibility to go 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 centralized, chronological
source of information when you need it, instead of requiring you difficult
management decision (like to
page through individual sheets loss the results of paper. Much 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 information stage.

In some cases, it is
potential evidence prudent to remove all access or functionality as
soon as possible, and then restore normal operation in a court of law. Thus, when you initially
suspect limited
stages. Bear in mind that removing all access while an incident will result is
in prosecution or when 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
investigative agency becomes involved, you need investigation.

5.4.4 Eradication

Once an incident has been detected, it is important to regularly (e.g.,
every day) turn in photocopied, signed copies of your logbook (as
well as media you use first think
about containing the incident. Once the incident has been contained,
it is now time to record system events) eradicate the cause. But before eradicate the
cause great care should be taken to a document
custodian who can store these copied pages in a secure place (e.g., a
safe). When you submit collect all necessary information for storage, you should in return
receive a signed, dated receipt from
about the document custodian. Failure compromised system and the cause of the incident due later
on they will disappear during the eradication.

Software may be available to observe these procedures can result in invalidation of any
evidence help you obtain in a court of law.

5.4.3 Containment

The purpose of containment is to limit the extent of an attack. eradiction process. For
example, it eradication software is important available to limit the spread of a worm attack
on a network as quickly as possible. An essential part of
containment eliminate most viruses
which infect small systems. If any bogus files have been created, it
is decision making (i.e., determining whether time to shut archive them for later use in case of a system down, to disconnect court case.
Thereafter delete them from a network, to monitor system or
network activity, to set traps, to disable functions such as
remote file transfer on a UNIX system, etc.). Sometimes this
decision is trivial; shut the system down if the system is
life-critical, classified or sensitive, or if proprietary information
is at risk! this point. In other cases, the case of
virus infections, it is worthwhile to risk having some
damage important to clean and reformat any disks
containing infected files. Finally, ensure that all backups are
clean. Many systems infected with viruses become periodically
reinfected simply because people do not systematically eradicate the system if keeping the system up might enable you to
identify an intruder.

This stage
virus from backups. After eradiction a new backup should involve carrying out predetermined procedures.
Your organization or site should, for example, define acceptable
risks in dealing with be taken,
too.

Removing all vulnerabilities once an incident, and should prescribe specific
actions and strategies accordingly. This is especially important
when a quick decision incident has occurred is necessary without the possibility
difficult. The key to
contact all involved parties removing vulnerabilities is knowledge and discuss the decision. In most
understanding of the cases the person in charge will have not the power breach.

It may be necessary to make
a difficult management decision (like go back to loss the results of original distributed tapes and
recustomize the system. To facilitate this worst case scenario, a
costly experiment). Finally, notification
record of cognizant authorities the original systems setup and each customization change
should occur during this stage.

<no text yet>
+ since I decided be kept current with each change to make this an own section it should contain more
more text? the system. In some cases, the case
of a network-based attack, it is prudent important to remove all access or functionality
as soon as possible, and then restore normal operation in limited
stages. Bear install patches for any
operating system vulnerability which was exploited.

As discussed in mind that section $$.4.2, a security log can be most valuable
during this phase of removing all access while an incident vulnerabilities. There are two
considerations here; the first is
in progress will obviously notify all users, including to keep logs of the alleged
problem users, procedures that the administrators are aware of a problem; this
may
have a deleterious effect been used to make the system secure again. This should include
command procedures (e.g., shell scripts) that can be run on an investigation. However, allowing
an incident a
periodic basis to continue may also open recheck the likelihood security. Second, keep logs of greater damage,
loss, aggravation, or liability (civil or criminal). That's another
reason why the relevant decisions belong
important system events. These can be referenced when trying to
determine the site policy extent of the damage of a given incident.

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

Site Security Handbook Working Group [Page 37]

Internet Draft Site Security Handbook November 1995

security mailing lists and should bulletins would be determined before an a good place to search
for this information and you can get advice from incident occurs.

5.4.4 Eradiction response
teams.

5.4.5 Recovery

Once the cause of an incident has been detected, it eradicated, the recovery phase
defines the next stage of action. The goal of recovery is important to first think
about containing return
the incident. Once system to normal. In general, bringing up services in the incident has been
contained, it is now time order
of demand to eradicate allow a minimum of user inconvenience is the cause. But before
eradicate best
practice. Understand that the cause great care proper recovery procedures for the
system are extremely important and should be taken specific to collect all
necessary information about the compromised 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 cause system. One of the incident due later on they will disappear during the
eradication.

Software may be available most important stages of responding to help you in the eradiction process.
For example, eradication software
incidents is available to eliminate also the most
viruses which infect small systems. If any bogus files often omitted---the follow-up stage. In
the follow-up stage, the system should be monitored for items that
may have been
created, it is time missed during the cleanup stage. It would be prudent
to archive them for later use in case utilize some of a
court case. Thereafter delete them from the tools mentioned in section xxx (e.g., xxx) as
a start. Remember, these tools don't replace continual system at this point.
In the case of virus infections, it is important to clean
monitoring and
reformat any disks containing infected files. Finally, ensure
that all backups are clean. Many good systems infected with viruses
become periodically reinfected simply administration procedures.

The follow-up stage is important for another reason, too, because people do not
systematically eradicate it
helps those involved in handling the virus from backups. After eradiction incident develop a new backup should be taken, too.

Removing all vulnerabilities once set of
"lessons learned" (see section $$.5) to improve future performance in
such situations. This stage also provides information which
justifies an incident has occurred is
difficult. The key organization's computer security effort to removing vulnerabilities is knowledge management,
and
understanding of the breach.

It yields information which may be necessary to go back to essential in legal proceedings.

The most important element of the original distributed tapes follow-up stage is performing a
postmortem analysis. Exactly what happened, and recustomize at what times? How
well did the system. To facilitate this worst case
scenario, a record staff involved with the incident perform? What kind of
information did the original systems setup staff need quickly, and each
customization change should be kept current with each change to
the system. In how could they have
gotten that information as soon as possible? What would the staff do
differently next time? A follow-up report is valuable because it
provides a reference to be used in case of other similar incidents.
Creating a network-based attack, formal chronology of events (including time stamps) is
also important for legal reasons. Similarly, it is also important to install patches for
as quickly obtain a monetary estimate of the amount of damage the
incident caused in terms of any operating system vulnerability which was
exploited.

<no text yet>
+ patch 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 vulnerabilities not available
+ uncertainty subsequent prosecution activity.

5.5 Aftermath of cause

As discussed in section $$.4.2, a security log an Incident

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

(1) An inventory should be taken of removing vulnerabilities. There are two
considerations here; the first is to keep logs 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 procedures
that have been used incident
should be included in revised security plan to make
prevent the system secure again. This incident from re-occurring,

(3) A new risk analysis should
include command procedures (e.g., shell scripts) that can be run
on a periodic basis to recheck developed in light of the security. Second, keep logs
incident,

(4) An investigation and prosecution of
important system events. These can be referenced when trying the individuals
who caused the incident should commence, if it is
deemed desirable.

All four steps should provide feedback to
determine the extent of the damage site security policy
committee, leading to prompt re-evaluation and amendment of a given incident.

5.4.5 Recovery

Once the cause of
current policy.

If an incident has been eradicated, the recovery
phase defines the next stage of action. The goal of recovery is
to return based on poor policy, and unless the system policy is
changed, then one is doomed to normal. In general, bringing
up services in repeat the order of demand to allow past. Once a minimum of user
inconvenience is the best practice. Understand that the proper
recovery procedures for the system are extremely important site has
recovered from and incident, site policy and procedures should be specific
reviewed to the site.

<no text yet>
+ more text needed?

5.4.6 Follow-Up

Once you believe that a system has been restored encompass changes to a "safe"
state, prevent similar incidents. Even
without an incident, it is still possible that holes and even traps could would be
lurking in the system. One of the most important stages of
responding prudent to incidents review policies and
procedures on a regular basis. Reviews are imperative due to today's
changing computing environments.

After an incident, it is also the most often omitted---the
follow-up stage. In the follow-up stage, the system should
be monitored for items that may have been missed during the
cleanup stage. It would be prudent to utilize some of the tools
mentioned in section xxx (e.g., xxx) as write a start. Remember,
these tools don't replace continual system report describing the
incident, method of discovery, correction procedure, monitoring
procedure, and good
systems administration procedures.

The follow-up stage is important for another reason, too, because
it helps those involved a summary of lesson learned. This will aid in handling the
clear understanding of the problem. Remember, it is difficult to
learn from an incident develop a set if you don't understand the source.

The whole purpose of
"lessons learned" (see section $$.5) this "post mortem" process is to improve all
security measures to protect the site against future performance
in such situations. This stage also provides information which
justifies attacks. In the
light of an organization's computer security effort incident one should gather practical knowledge from the
experience. This should improve one's ability to management,
and yields information which may be essential detect the
occurance of similar problems in legal proceedings.

The most the future. A concrete goal is
developing proactive methods, for example: early warning by probes.
Another important element facet of the follow-up stage aftermath is performing a
postmortem analysis. Exactly what happened, more related to end user
and at what times?
How well did the staff involved with administrator awareness and eduction. By reviewing the actual
incident perform? What handling effort the process can be improved and extended to
reflect new lessons learned. All this will help the site in the
handling of future incidents even if a completely different kind of information did
attack occurs.

5.6 Responsibilities

It is one thing to protect one's own network, but quite another to
assume that one should protect other networks. During the staff need quickly, handling
of an incident, certain system vulnerabilities of one's own systems
and how could they
have gotten that information as soon as possible? What would the
staff do differently next time? A follow-up report systems of others become apparent. It is valuable
because it provides a reference to quite easy and may
even be used tempting to pursue the intruders in order to track them.
Keep in case of other
similar incidents. Creating mind that at a formal chronology of events
(including time stamps) certain point it is also important for legal reasons.
Similarly, possible to 'cross the
line,' and with the best intentions, become no better than the

Site Security Handbook Working Group [Page 39]

Internet Draft Site Security Handbook November 1995

intruder.

The best rule when it comes to propriety is also important to not use any facility
of remote sites which is not public. This clearly excludes any entry
onto a system (such as quickly obtain a monetary
estimate remote shell or login session) which is not
expressly permitted. This may be very tempting; after a breach of
security is detected, a system administrator may have the amount of means to
'follow it up,' to ascertain what damage is being done to the incident caused in terms of
any loss of software and files, hardware damage, and manpower
costs remote
site. Don't do it. Instead attempt to restore altered files, reconfigure affected systems, and
so forth. This estimate may become reach the basis for subsequent
prosecution activity.

5.5 Aftermath POC of an Incident

In the wake effected
site.

6. MAINTENANCE and EVALUATION

6.1 Risk assessments

6.2 Notification of an incident, several actions should take place. These
actions problems/events

APPENDICES

A1 Tools and Locations

This section provides a brief overview of publicly available security
technology which can be summarized as follows:

(1) An inventory should be taken downloaded from the Internet. Many of the systems' assets,
i. e.,
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 careful examination should determine how the
system was affected general user will never see or need to use, but
which may be part of or used by the incident,

(2) applications, used to troubleshoot
security problems or guard against intruders by system and network
administrators.

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

Most of the incident
should tools and applications described below can be included found in revised security plan to
prevent
one of the incident from re-occurring, 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) A new risk analysis should 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 developed noted in light of the
incident,

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

All four steps should provide feedback important to note that many sites,
including CERT and COAST are mirrored throughout the Internet. Be
careful to use a "well known" mirror site security policy
committee, leading to prompt re-evaluation and amendment of the
current policy.

If an incident is based on poor policy, retrieve software and unless the policy 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
changed, then one that there are very few security conscious
applications currently available. The real reason is doomed to repeat the past. Once need for a site has
recovered from and incident, site policy and procedures should
security infrastructure which must be
reviewed first put into place for most
applications to encompass changes operate securely. There is considerable effort
currently taking place to prevent similar incidents. Even
without an incident, it place this infrastructure so that
applications can take advantage of secure communications.

Unix based applications

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

A2 Mailing lists and other resources

It would be prudent to review policies and
procedures on a regular basis. Reviews are imperative due to
today's changing computing environments.

After an incident, it is prudent impossible to write a report describing the
incident, method list all of discovery, correction procedure, monitoring
procedure, the mail-lists and a summary of lesson learned. This will aid in other
resources dealing with site security. However, these are some "jump-
points" from which the
clear understanding reader can begin. All of these references are
for the problem. Remember, it is difficult to
learn from an incident if you don't understand the source.

<no text yet>
+ improving proactive methods
+ educate users, administrators "INTERNET" constituency. More specific (vendor and managers

5.6 Responsibilities

<no text yet>
This is a total new section but it address some aspects because
we sometimes experience
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 somewhat strange interpretation patch or
details of
responsibility. One example: to protect a network is workaround for a good thing,
but to protect someone other's network is difficult, if you don't
have the authority to do so. If you start known computer security problem.
The CERT Coordination Center works with vendors to try this new hacker
tool on produce a network, it is fair to contact some responsible person
before. In the other case we experience (false

Site Security Handbook Working Group [Page 41]

Internet Draft Site Security Handbook November 1995

workaround or unnecessary) alerts
every now a patch for a problem, and then. If you think about does not publish
vulnerability information until a successful breakin as workaround or a
good education lesson, you can patch is
available. A CERT advisory may also be sued for this like an ordinary
cracker.
+ testing of known vulnerabilities
+ disclosure of information
+ testing of local sites
+ tiger teams (for remote sites)
+ announcing site security contact information
+ check advice before acting on behalf (hacker claims a warning to be ROOT)
+ protect the communication
+ legal procedures
was section 5.5.2 in our
constituency about ongoing attacks (e.g.,
"CA-91:18.Active.Internet.tftp.Attacks").

CERT advisories are also published on the old RFC
(most of this section is already included in 5.2.2)

6. MAINTENANCE and EVALUATION

6.1 Risk assessments
6.2 Notification of problems/events

Appendices

A1 Tools and Locations

This section provides a brief overview of publically USENET newsgroup:

comp.security.announce

CERT advisory archives are available security
technology which can be downloaded via anonymous FTP from
info.cert.org in 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 /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 or used by applications, used this moderated mailing list is to troubleshoot
encourage the exchange of information on security problems or guard against intruders by system
tools and
network administrators. techniques. The emphasis will 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 unix applications computer virus issues. For more information,
including a copy of the posting guidelines, see
the file "virus-l.README", available by anonymous
FTP from cs.ucr.edu.

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

The Firewalls mailing list is a discussion forum for
firewall administrators and tools, but other platforms,
particularly PC's implementors.

USENET newsgroups

(1) comp.security.announce
The comp.security.announce newsgroup is moderated
and Macintoshes, will be mentioned where information is
available.

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

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

Any references to CERT or COAST will refer to these two locations. These
two sites act as repositories
advisories.

(2) comp.security.misc
The comp.security.misc is a forum for most tools, exceptions will be noted in the text. *** It is important
discussion of computer security, especially as it
relates to note that many sites, including CERT and
COAST are mirrored throughout the Internet. Be careful to use UNIX(r) Operating System.

(3) alt.security
The alt.security newsgroup is also a "well
known" mirror site to retrieve software and to use whatever verification
tools possible, checksums, md5 checksums, etc... to validate that
software. A clever cracker might advertise security software 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 designed
flaws 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 order to gain access to data or machines. ***

Applications the /pub/virus-l directory.

(5) comp.risks
The sad truth comp.risks newsgroup is that there are very few security conscious applications
currently available. 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 real reason main focus is on
crisis response information; information on computer
security-related threats, vulnerabilities, and solutions. At the need for
same time, the Clearinghouse strives to be a general index to
computer security
infrastructure which must be first put into place for most applications 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
operate securely. information
sources on Network and Computer Security. There is considerable effort currently taking place no implied
fitness to
place the Tools, Techniques and Documents contained within this infrastructure so
archive. Many if not all of these items work well, but we do
not guarantee that applications can take advantage this will be so. This information is for the
education and legitimate use 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 computer security tool)
DES (non-US versions)
lsof
sfingerd
passwd-replacements (npasswd / ANLpasswd / passwd+ / ...)

A2 Mailing lists 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 other resources

<To be completed> 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]

----