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