Network Working Group P. Holbrook
Request for Comments: 11XX CERT
J. Reynolds
ISI
Editors
MMMM 1990
DRAFT - 26-Nov-90
Security Policy Handbook
Status of this Memo
This handbook is the product of the Security Policy Handbook Working
Group (SPHWG), a combined effort of the Security Area and User
Services Area of the Internet Engineering Task Force (IETF). The
SPHWG is co-chaired by J. Paul Holbrook (CERT) and Joyce K. Reynolds
(ISI). This RFC provides information for the Internet community. It
does not specify any standard. Distribution of this memo is
unlimited.
Contributing Authors and Acknowledgements
The following are the authors of the Security Policy Handbook.
Without their dedication, this handbook would not have been possible.
Dave Curry (davy@erg.sri.com)
Sean Kirkpatrick (sean@nisd.cam.unisys.com)
Tom Longstaff (longstaf@cheetah.llnl.gov)
Greg Hollingsworth (gregh@aplcen.apl.jhu.edu)
Jeffrey Carpenter (jjc@unix.cis.pitt.edu)
Allen Sturtevant (sturtevant@ccc.nersc.gov)
Fred Ostapik (fred@nic.ddn.mil)
Jim Duncan (jim@augusta.math.psu.edu)
Frank Byrum (byrum@decuac.dec.com)
Thanks to the SPHWG's illustrious "Outline Squad", who assembled at
USC/Information Sciences Institute on 12-June-90: Ray Bates (ISI),
Frank Byrum (DEC), Michael A. Contino (PSU), Dave Dalva (Trusted
Information Systems, Inc.), Jim Duncan (Penn State Math Department),
Bruce Hamilton (Xerox), Sean Kirkpatrick (Unisys), Tom Longstaff
(CIAC/LLNL), Fred Ostapik (SRI/NIC), Keith Pilotti (SAIC), and Bjorn
Satdeva (/sys/admin, inc.).
Last, but NOT least, we would like to thank members of the SPHWG and
Friends for their additional contributions: Dave Grisham (UNM), Nancy
Lee Kirkpatrick (Typist Extraordinaire), Chris McDonald (WSMR), H.
Craig McKee (Mitre), Aileen Yuan (Mitre), ---put in more as
warranted, if I've missed people, TELL ME! --jkrey.
Security Policy Handbook Working Group [Page 1]
RFC 11XX Security Policy Handbook MMMM 1990
Table of Contents
1. Introduction..................................................... X
1.1 Purpose of this Work............................................ X
1.2 Audience........................................................ X
1.3 Definitions..................................................... X
1.4 Related Work.................................................... X
1.5 Scope........................................................... X
1.6 Why Do We Need Security Policies and Procedures?................ X
1.7 Basic Approach.................................................. X
1.8 Organization of this Document................................... X
2. Establishing Official Site Policy on Computer Security........... X
2.1 Brief Overview.................................................. X
2.2 Risk Assessment................................................. X
2.3 Policy.......................................................... X
2.4 What Happens When the Policy Is Violated........................ X
2.5 Locking In or Out............................................... X
2.6 Publicizing the Policy.......................................... X
3. Establishing Procedures to Prevent Security Problems............. X
3.1 Overview........................................................ X
3.2 System Security Audits.......................................... X
3.3 Account Management Procedures................................... X
3.4 Password Management Procedures.................................. X
3.5 Configuration Management Procedures............................. X
3.6 Procedures to Recognize Unauthorized Activity................... X
3.7 Define Actions to Take When Unauthorized Activity is Suspected.. X
3.8 Communicating Security Policy................................... X
3.9 Resources to Prevent Security Breaches.......................... X
4. Incident Handling................................................ X
4.1 Overview........................................................ X
4.2 Evaluation...................................................... X
4.3 Possible Types of Notification.................................. X
4.4 Response........................................................ X
4.5 Legal/Investigative............................................. X
4.6 Documentation Logs.............................................. X
5. Establishing Post-Incident Procedures............................ X
5.1 Overview........................................................ X
5.2 Removing Vulnerabilities........................................ X
5.3 Capturing Lessons Learned....................................... X
5.4 Upgrading Policies and Procedures............................... X
6. References....................................................... X
7. Annotated Bibliography........................................... X
7.1 Computer Law.................................................... X
7.2 Computer Security............................................... X
7.3 Ethics.......................................................... X
7.4 The Internet Worm............................................... X
7.5 National Computer Security Center (NCSC)........................ X
7.6 Security Checklists............................................. X
Security Policy Handbook Working Group [Page 2]
RFC 11XX Security Policy Handbook MMMM 1990
7.7 Additional Publications......................................... X
8. Security Considerations.......................................... X
9. Authors' Addresses............................................... X
1. Introduction
1.1 Purpose of this Work
This handbook is a guide to setting computer security policies and
procedures for sites that have systems on the Internet. This guide
lists issues and factors that a site must consider when setting their
own policies. It makes some recommendations and gives discussions of
relevant areas.
This guide is only a framework for setting security policies and
procedures. In order to have an effective set of policies and
procedures, a site will have to make many decisions, gain agreement,
and then communicate and implement the policies.
1.2 Audience
The audience for this work are system administrators and decision
makers (who are more traditionally called "administrators" or "middle
management") at sites. This document is not directed at programmers
or those trying to create secure programs or systems. The focus of
this document is on the policies and procedures that need to be in
place to support any technical security features that a site may be
implementing.
The primary audience for this work are sites that are members of the
Internet community. However, this document should be useful to any
site that allows communication with other sites. As a general guide
to security policies, this document may also be useful to sites with
isolated systems.
1.3 Definitions
For the purposes of this guide, a "site" is any organization that
owns computers or network related resources. These resources may
include host computers that users use, routers, terminal servers, PC
or other devices that have access to the Internet. A site may be a
end user of Internet services or a service provider such as a
regional network. However, most of the focus of this guide is on
those end users of Internet services.
We assume that the site has the ability to set policies and
procedures for itself with the concurrence and support from those who
actually own the resources.
Security Policy Handbook Working Group [Page 3]
RFC 11XX Security Policy Handbook MMMM 1990
The "Internet" is those set of networks and machines that use the
TCP/IP protocol suite, connected through gateways, and sharing a
common name and address spaces. [1]
The term "system administrator" is used to cover all those who are
responsible for the day-to-day operation of resources. This may be a
number of individuals or an organization.
The term "decision maker" refers to those people at a site who set or
approve policy. These are often (but not always) the people who own
the resources.
1.4 Related Work
The IETF Security Policy Working Group (SPWG) is working on a
recommended security policy for the Internet. These policy
recommendations may be adopted by regional networks or owners of
other resources. This handbook should be a useful tool to help sites
implement those policies as desired or required. However, even
implementing the proposed policies isn't enough to secure a site.
The proposed Internet policies deal only with network access
security. It says nothing about how sites should deal with local
security issues.
1.5 Scope
This document covers issues about what a computer security policy
should contain, what kinds of procedures are need to enforce
security, and some recommendations about how to deal with the
problem.
This is not a cookbook for computer security. Each site has
different needs; the security needs of a corporation might well be
different than the security needs of an academic institution. Any
security plan has to confirm to the needs and culture of the site.
This handbook does not cover details of how to do risk assessment,
contingency planning, or physical security. These things are
essential in setting and implementing effective security policy, but
this document leaves treatment of those issues to other documents.
We will try to provide some pointers in that direction.
This document also doesn't talk about how to design or implement
secure systems or programs.
1.6 Why Do We Need Security Policies and Procedures?
For most sites, the interest in computer security is proportional to
Security Policy Handbook Working Group [Page 4]
RFC 11XX Security Policy Handbook MMMM 1990
the perceived risk and threats.
The world of computers has changed dramatically over the past
twenty-five years. Twenty-five years ago, most computers were
centralized and managed by data centers. Computers were kept in
locked rooms and staffs of people made sure they were carefully
managed and physically secured. Links outside a site were unusual.
Computer security threats were rare, and were basically concerned
with insiders: authorized users misusing accounts, theft and
vandalism, and so forth. These threats were well understood and
dealt with using standard techniques: computers behind locked doors,
accounting for all resources.
Computing in the 1990s is radically different. Many systems are in
private offices and labs, often managed by individuals or persons
employed outside a computer center. Many systems are connected into
the Internet, and from there around the world: the United States,
Europe, Asia, and Australia are all connected together.
Security threats are different today. The time honored advice says
"don't write your password down and put it in your desk" lest someone
find it. With world wide Internet connections, someone could get
into your system from the other side of the world and steal your
password in the middle of the night when your building is locked up.
Viruses and worms can be passed from machine to machine. The
Internet allows the electronic equivalent of the thief who looks for
open windows and doors; now a person can check hundreds of machines
in a few hours for vulnerabilities.
System administrators and decision makers have to understand the
security threats that exist, what the risk and cost of a problem
would be, and what kind of action they want to take (if any) to
prevent and respond to security threats.
As an illustration of some of the issues that need to be dealt with
in security problems, consider the following scenarios (thanks to
Russell Brand [2, BRAND] for these):
- A system programmer gets a call reporting that a
major underground cracker newsletter is being
distributed from the administrative machine at his
center to five thousand sites in the US and
Western Europe.
Eight weeks later, the authorities call to inform
you the information in one of these newsletters
was used to disable "911" in a major city for
five hours.
Security Policy Handbook Working Group [Page 5]
RFC 11XX Security Policy Handbook MMMM 1990
- A user calls in to report that he can't login to his
account at 3 o'clock in the morning on a Saturday. The
system staffer can't login either. After rebooting to
single user mode, he finds that password file is empty.
By Monday morning, your staff determines that a number
of privileged file transfers took place between this
machine and a local university.
Tuesday morning a copy of the deleted password file is
found on the university machine along with password
files for a dozen other machines.
A week later you find that your system initialization
files had been altered in a hostile fashion.
- You receive a call saying that a breakin to a government
lab occurred from one of your center's machines. You
are requested to provide accounting files to help
trackdown the attacker.
A week later you are given a list of machines at your
site that have been broken into.
- A reporter calls up asking about the breakin at your
center. You haven't heard of any such breakin.
Three days later, you learn that there was a breakin.
The center director had his wife's name as a password.
- A change in system binaries is detected.
The day that it is corrected they again are changed.
This repeats itself for some weeks.
- If an intruder is found on your system, should you
leave the system open to monitor the situation or should
you close down the holes and open them up again later?
- If an intruder is using your site, should you call law
enforcement? Who makes that decision? If law enforcement asks
you to leave your site open, who makes that decision?
- What steps should be taken if another site calls you and says
they see activity coming from an account on your system? What
if the account is owned by a local manager?
Security Policy Handbook Working Group [Page 6]
RFC 11XX Security Policy Handbook MMMM 1990
1.7 Basic Approach
Setting security policies and procedures really means developing a
plan for how to deal with computer security. One way to approach
this task is suggested by Fites, et. al. [3, FITES]:
- Look at what you are trying to protect.
- Look at what you need to protect it from.
- Determine how likely the threats are.
- Implement measures which will protect your assets in a
cost-effective manner.
- Review the process continuously, and improve things every time
a weakness is found.
This handbook will concentrate mostly on the last two steps, but the
first three are critically important to making effective decisions
about security. One old truism in security is that the cost of
protecting yourself against a threat should be less than the cost
recovering if the threat were to strike you. Without reasonable
knowledge of what you are protecting and what the likely threats are,
following this rule could be difficult.
1.8 Organization of this Document
This document is organized into six parts in addition to this
introduction.
The basic form of each section is to discuss issues that a site might
want to consider in creating a computer security policy and setting
procedures to implement that policy. In some cases, possible options
are discussed along with the some of the ramifications of those
choices. As far as possible, this document tries not to dictate the
choices a site should make, since these depend on local
circumstances. Some of the issues brought up may not apply to all
sites. None the less, all sites should at least consider the issues
brought up here to ensure that they do not miss some important area.
The overall flow of the document is to discuss policy issues followed
by the issues that come up in creating procedures to implement the
policies.
Section 2 discusses setting official site policies for access to
computing resources. It also goes into the issue of what happens
when the policy is violated. The policies will drive the procedures
that need to be created, so decision makers will need to make choices
about policies before many of the procedural issues in following
sections can be dealt with. A key part of creating policies is doing
some kind of risk assessment to decide what really needs to be
Security Policy Handbook Working Group [Page 7]
RFC 11XX Security Policy Handbook MMMM 1990
protected and the level of resources that should be applied to
protect them.
Section 3 discusses procedures to prevent security problems.
Prevention is a key to security; as an example, the Computer
Emergency Response Team/Coordination Center (CERT/CC) at Carnegie-
Mellon University (CMU) estimates that 80% or more of the problems
they see have to do with poorly chosen passwords.
Section 4 discusses incident handling: what kinds of issues does a
site face when someone violates the security policy. Many decisions
will have to made on the spot as the incident occurs, but many of the
options and issues can be discussed in advance. At very least,
responsibilities and methods of communication can be established
before an incident. Again, the choices here are influenced by the
policies discussed in section 2.
Section 5 deals with what happens after a security violation has been
dealt with. Security planning is an on-going cycle; just after an
incident has occurred is an excellent opportunity to improve policies
and procedures.
The rest of the document provides references and an annotated
bibliography.
=====
Section 2 - Draft of November 19, 1990
Authors: Jeffrey Carpenter (jjc@unix.cis.pitt.edu), Greg
Hollingsworth (gregh@aplcen.apl.jhu.edu), Allen Sturtevant
(sturtevant@CCC.NERSC.GOV).
2. Establishing Official Site Policy on Computer Security
2.1 Brief Overview
2.1.1 Organization Goals
The goal in developing an official site policy on computer
security is to define the organization's expectations of proper
computer and network use and to define procedures to prevent and
to respond to security incidents.
The goals and direction of the organization should be considered.
A military base may have very different security concerns from a
university.
Security Policy Handbook Working Group [Page 8]
RFC 11XX Security Policy Handbook MMMM 1990
2.1.2 Who Makes the Policy?
Policy creation must be a joint effort by technical personnel who
understand the full ramifications of the proposed policy and the
implementation of the policy and by decision makers who have the
power to enforce the policy. A policy which is neither
enforceable nor implementable is useless.
Since a computer security policy can effect everyone in an
organization, it is worth taking some care to make sure you have
the right level of authority in on the policy decisions. Though a
particular group (such as a campus information services group) may
have responsibility for enforcing a policy, an even higher group
may have to support and approve the policy.
2.1.3 Who is Involved?
Establishing a site policy has the potential for involving every
computer user at the site in a variety of ways. Computer users
may be responsible for personal password administration. Systems
managers are obligated to fix security holes and to oversee the
system.
It is critical to get the right set of people involved at the
start of the process. There may already be groups concerned with
security who would consider a computer security policy to be their
area. Some of the types of groups that might be involved include
auditing/control, organizations that deal with physical security,
campus information systems groups, and so forth. Asking these
types of groups to "buy in" from the start can help the eventual
acceptance of the policy.
2.1.4 Responsibilities
A key element of a computer security policy is making sure
everyone knows their own responsibility for maintaining security.
A computer security policy cannot anticipate all possibilities;
however, it can ensure that each kind of problem does have someone
assigned to deal with it.
There may be levels of responsibility associated with a policy on
computer security. At one level, each user of a computing
resource may have a responsibility to protect his account. A user
who allows his account to be compromised increases the chances of
compromising other accounts or resources.
System managers may form another responsibility level, they must
help to ensure the security of the computer system. Network
Security Policy Handbook Working Group [Page 9]
RFC 11XX Security Policy Handbook MMMM 1990
managers may reside at yet another level.
2.2 Risk Assessment
2.2.1 General Discussion
One of the most important reasons for creating a computer security
policy is to ensure that the efforts spent on security are worth
the time and effort spent on them. 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 looking at what you need to protect, what
you need to protect it from, and how to protect it. It also
involves making cost-effective decisions on what to protect. The
old security adage says that you shouldn't spend more to protect
something than it's actually worth.
There are various approaches to the details of how to do a risk
assessment, but they all have common elements. One typical
approach is given by Fites [3, FITES, page 29]:
1. Create a team of people to do the job.
2. Identify the assets.
3. Identify the threats.
4. Determine the probabilities of the threats.
5. Calculate the exposures.
6. Introduce safeguards.
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.
A full treatment of risk analysis is outside the scope of this
book. [3, FITES] and [16, PFLEEGER] provide introductions to this
topic.
2.2.2 Assets
The first step in a risk analysis is to identify all these things
that need to be protected. Some things are obvious, like all the
various pieces of hardware, but some are overlooked, such as the
people who actually use the systems.
One list of categories is suggested by Pfleeger [16, PFLEEGER,
Security Policy Handbook Working Group [Page 10]
RFC 11XX Security Policy Handbook MMMM 1990
page 459]; this list is adapted from that source:
1. Hardware: cpus, boards, keyboards, terminals,
workstations, personal computers, printers disk
drives, communication lines, terminal servers, routers
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, people needed to run systems
5. Documentation: on programs, hardware, systems, local
administrative procedures
6. Supplies: paper, forms, ribbons, magnetic media
This part of the risk analysis is an inventory of existing assets.
The essential point is to list all things that could be affected
by a security problem.
2.2.3 Threats
Identifying threat is a key element in calculating security risks.
Consider what are you trying to protect your assets from.
The following sections describe some of the possible threats.
Each site must evaluate for itself how vulnerable it is from these
kinds of threats.
2.2.3.1 Unauthorized Access
A common threat that concerns many sites is unauthorized access
to computing facilities. Unauthorized access takes many forms.
A common means of unauthorized access is the use of another
user's account to gain access to a system. The use of any
computer resource without prior permission may be considered
unauthorized access to computing facilities.
The seriousness of an unauthorized access will vary from site
to site. For some sites, the mere act of granting access to an
unauthorized user may cause irreparable harm by negative media
coverage. For other sites, an unauthorized access opens the
door to other security threats.
Security Policy Handbook Working Group [Page 11]
RFC 11XX Security Policy Handbook MMMM 1990
The risk from unauthorized access may vary from site to site.
The the Computer Emergency Response Team (CERT - see section
3.9.7.3.1) has observed that well known universities,
government sites, and military sites seem to attract more
intruders.
2.2.3.2 Disclosure of Information
Another common threat is disclosure of information. Determine
the value or sensitivity of the information stored on your
computers. Disclosure of a password file might allow for
future unauthorized accesses. A glimpse of a proposal may give
a competitor an unfair edge. A technical paper may contain
years of valuable research.
2.2.3.3 Denial of Service
Computers and networks provide valuable services to their
users. Many people rely on these services in order to perform
their jobs efficiently. When these services are not available
when called upon, a loss in productivity results.
Denial of service comes in many forms and might effect users in
a number of ways. A network may be made unusable by a rogue
packet, jamming, or by a disabled network component. A virus
might slow down or cripple a computer system. The
possibilities are large in number. Determine the services that
are essential to the site and the effect that would be realized
if the service were to be disabled.
2.2.4 Possible Problems
To determine risk, vulnerabilities must be identified. Part of
the purpose of the policy is to aid in shoring up the
vulnerabilities to decrease the risk in as many areas as possible.
Several of the more popular problem areas are presented in
sections below. This list is by no means complete. In addition,
each site is likely to have a few unique vulnerabilities.
2.2.4.1 Access Points
Access points are typically used for entry by unauthorized
users. Many access points indiscriminately allow access to an
organization's computer and network facilities.
Network links to networks outside the organization allow access
into the organization for all others connected to that external
network. A network link typically provides access to a large
Security Policy Handbook Working Group [Page 12]
RFC 11XX Security Policy Handbook MMMM 1990
number of network services, and each service has compromise
potential.
Dialup lines, depending on their configuration, may provide
access merely to a login port of a single system. If connected
to a terminal server, the dialup line may give access to the
entire network.
Terminal servers themselves can be a source of problem. Many
terminal servers do not require any kind of authentication.
Intruders often use terminal servers to disguise their actions,
dialing in on a local phone and then using the terminal server
to go out to the local network. Some terminal servers are
configured so that intruders can TELNET [19] in from outside
the network, and then TELNET back out again, again serving to
make it difficult to trace them.
2.2.4.2 Misconfigured Systems
Misconfigured systems form a large percentage of security
holes. Today's operating systems and their associated software
have become so complex that understanding how the system works
has become a full-time job. Often, systems managers will be
non-specialists chosen from the current organization's staff.
Because this person either has no experience in systems
management, or has no extra time to learn proper management
procedures, simply getting the system working is often
satisfactory.
Vendors are also partly responsible for misconfigured systems.
To make the system installation process easier, vendors
occasionally choose initial configurations that are not secure
in all environments.
2.2.4.3 Software Bugs
Software will never be bug free. Publicly known security bugs
are common methods of unauthorized entry. Part of the solution
to this problem is to be aware of the security problems and to
update the software when problems are detected. When bugs are
found, they should be reported to the vendor so that a solution
to the problem can be implemented and distributed.
2.2.4.4 "Insider" Threats
An insider to the organization may be a considerable threat to
the security of the computer systems. Insiders often have
direct access to the computer and network hardware components.
Security Policy Handbook Working Group [Page 13]
RFC 11XX Security Policy Handbook MMMM 1990
The ability to access the components of a system makes most
systems easier to compromise. Most desktop workstations can be
easily manipulated so that they grant privileged access.
Access to a local area network provides the ability to view
possibly sensitive data traversing the network.
2.3 Policy
2.3.1 Define Authorized Access to Computing Resources
One of the most important steps you must take in developing your
security policy is defining the following:
1. Who is allowed to use your services?
2. What are they allowed to use the system/services for?
3. What are their rights and responsibilities for using the
system/services?
This section of the handbook covers these questions.
2.3.2 Basic Assumptions
[ I am having problems figuring out what should be in this
section. Any input is welcome!]
- Connected to the Internet.
When developing your security policy, you should not only
consider the security implications of your own network, but you
should also consider the security implications of the other
networks you are connected to.
- Inventory of networked components including PCs, servers,
networked devices, physical security.
You need to know what devices are connected to your network.
Unauthorized connections may be used to breach security. You
will most likely know what is connected by requiring users to
follow a procedure in order to legitimately connect. You also
need to take steps to ensure the physical security of your
network, so that users cannot attach unauthorized devices
without your knowledge.
- Introduce problem areas/assets.
----->needs to be filled in.<------
Security Policy Handbook Working Group [Page 14]
RFC 11XX Security Policy Handbook MMMM 1990
2.3.3 Policy Issues
2.3.3.1 Who is Authorized to Grant Access and Approve Usage?
Your policy should state who is authorized to grant access to
your services. Further, it must be determined what type of
access they are permitted to give. If you do not have control
over who is granting access to your system, you will not have
control over who is using your system. Controlling who has the
authorization to grant access will also enable you to know who
was or was not granting access if problems develop later.
There are many schemes that can be developed to control the
distribution of access to your services. The following are the
factors that you must consider when determining who will
distribute access to your services:
Will you be distributing access from a centralized
point or at various points?
You can have a centralized distribution point to a distributed
system where various sites or departments independently
authorize access. The trade off between security and
convenience. The more centralized, the easier to secure.
What methods will you use for creating accounts and
terminating access?
From a security standpoint, you need to examine the mechanism
that you will be using to create accounts. In the least
restrictive case, the persons who are authorized to grant
access would be able to go into the system directly and create
an account by hand or through vendor supplied mechanisms.
Generally, these mechanisms place a great deal of trust in the
person running them, and the person running them usually has a
large amount of privileges. If this is the choice you make,
you need to select someone who is trustworthy to perform this
task. The opposite solution is to have an integrated system
that the people authorized to create accounts run, or the users
themselves may actually run. Be aware that even in the
restrictive case of having a mechanized facility to create
accounts does not remove the potential for abuse.
You should have specific procedures developed for the creation
of accounts. These procedures should be well documented to
prevent confusion and reduce mistakes. A security
vulnerability in the account authorization process is not only
possible through abuse, but is also possible if a mistake is
Security Policy Handbook Working Group [Page 15]
RFC 11XX Security Policy Handbook MMMM 1990
made. Having clear and well documented procedure will help
ensure that these mistakes won't happen. You should also be
sure that the people who will be following these procedures
understand them.
The granting of access to users is one of the most vulnerable
of times. You should ensure that the selection of an initial
password cannot be easily guessed. You should avoid using an
initial password that is a function of the username, is part of
the user's name, or some algorithmically generated password
that can easily be guessed. In addition, you should not permit
users to continue to use the initial password indefinitely. If
possible, you should force users to change the initial password
the first time they log in. Consider that some users may never
even log in, leaving their password vulnerable indefinitely.
Some sites choose to disable accounts that have never been
accessed, and force the owner to reauthorize opening the
account.
2.3.3.2 Who is it You are Giving Access To?
While developing your security policy, it is important to
address the procedures on internal security issues.
2.3.3.2.1 Who Gets System Administrator Privileges or
Passwords?
One security decision that you need to make very carefully
is who will have access to system administrator privileges
and passwords for your services. You need to balance
restricting access to these to protect security with giving
people who need these privileges access so that they can
perform their tasks. One approach that can be taken is to
grant only enough privileges to accomplish the tasks
necessary. Restricting privileges is one way to deal with
threats from insiders.
2.3.3.2.2 Accountability for Actions Taken/Auditing
Whenever a security problem develops, one of the first steps
you will want to take is to examine logs and auditing
trails. In many cases, these will be essential to track
down the culprit. In addition, the lack of accounting for
operations performed by privileged administrators is an
invitation for abuse. You need to ensure that mechanisms
are developed to make actions performed by system
administrators with privileges are logged and easily
audited.
Security Policy Handbook Working Group [Page 16]
RFC 11XX Security Policy Handbook MMMM 1990
2.3.3.2.3 Methods of Selecting People
You need to ensure that people who you grant privileges to
are accountable to you or some other authority. If the
people you grant privileges to are not accountable, you run
the risk of loosing control of your system and will have
difficulty managing a compromise in security.
2.3.3.3 What is the Proper Use of Resources?
Provide guidelines for acceptable use. You need to determine
and ensure that the users are aware of what you will permit
them to use their services for. You may have different
guidelines for different types of users (i.e., students,
faculty, external users). This policy needs to state what
users are permitted to use their accounts for and what they
cannot use their accounts for, and what types of use may be
restricted.
Your acceptable use policy should clearly state that individual
users are responsible for their actions. Their responsibility
exists regardless of the security mechanisms that are in place.
You should clearly state that breaking into accounts or
bypassing security is not permitted.
In your acceptable use policy, you should cover the following
points:
o Is breaking into accounts permitted?
o Is cracking passwords permitted?
o Is disrupting service permitted?
o Should users assume that a file being world readable
grants them the authorization to read it?
o Should users be permitted to modify files that are
not their own even if they happen to have write
permission?
o Should users share accounts?
The answer to most of these questions will be "no".
Your acceptable use policy is very important. A policy which
does not clearly state what is not permitted may leave you
unable to prove that a user violated policy.
There are exception cases like tiger teams and "license to
hack", where you may face the situation where users will want
to "hack" on your services for security research purposes. You
should develop a policy that will determine whether you will
Security Policy Handbook Working Group [Page 17]
RFC 11XX Security Policy Handbook MMMM 1990
permit this type of research on your services and if so, what
your guidelines for such research will be.
Points you may wish to cover in this policy:
o Whether it is permitted at all.
o What type of activity is permitted: hacking, releasing
worms, releasing viruses, etc.
o What type of controls must be in place to ensure that it
does not get out of control (e.g., separate a segment of
your network for these tests).
o How you will protect other users from being victims of
these activities, including external users and networks.
o What the process for obtaining permission to conduct these
tests are.
In cases where you do permit these activities, you should
isolate the portions of the network that are being tested from
your main network. Worms and viruses should never be released
on a live network.
You may also wish to employ, contract, or otherwise solicit one
or more people or organizations to evaluate the security of
your services, of which may include "hacking". You may wish to
provide for appropriate inclusion of provisions in your policy
to permit this.
Define limits to access and authority as you will need to
consider the level of access various users will have and what
resources will be available or restricted to various groups of
people.
2.3.3.4 What to do with Sensitive Information
Before granting users access to your services, you need to
determine at what level you will provide the security for data
on your services. By determining this, you are determining the
level of sensitivity of data that users should store on your
systems. You do not want users to store very sensitive
information on a system that you are not going to secure very
well. You need to tell users who might store sensitive
information what services, if any, are appropriate for the
storage of sensitive information. This part should include
storing of data in different ways (disk, mag tape, file
servers, etc.). Your policy in this area needs to be
coordinated with the policy concerning the right of system
administrators versus users (see section 2.3.6).
Security Policy Handbook Working Group [Page 18]
RFC 11XX Security Policy Handbook MMMM 1990
2.3.3.5 Proper use of Copyrighted/Licensed Software
You may wish to incorporate a statement in your policies
concerning copyrighted and licensed software. Licensing
agreements with vendors may require some sort of effort on your
part to ensure that the license is not violated. In addition,
you may wish to inform users that the copying of copyrighted
software may be a violation of the copyright laws, and is not
permitted.
Specifically concerning copyrighted and/or licensed software,
you may wish to include the following information:
o Copyrighted and licensed software may not be duplicated
unless it is explicitly stated that you may do so.
o Methods of conveying information on the
copyright/licensed status of software.
o When in doubt, DON'T COPY.
----->****<I need legal help with this section. Are there
references that I can use to help me here? I used the
University of Missouri here>
2.3.4 Ethical Behavior
In addition to specific policies and guidelines on acceptable use,
you may wish to include an additional section in your policies
concerning ethical use of computing resources. Parker, Swope and
Baker [17, PARKER90] and Forester and Morrison [18, FORESTER] are
two useful references that address ethical issues.
2.3.5 Users' Rights and Responsibilities
You should adopt a policy that incorporates a statement on what a
user's rights and responsibilities are concerning the use of your
services. The following is a list of topics that you may wish to
cover in this type of policy:
o Whether users can read or modify files that do not belong to
them (do they need the owners permission).
o What might constitute abuse in terms of system performance.
o Whether users are permitted to share accounts or let others
use their accounts.
o How "secret" users should keep their passwords.
o How often users should change their passwords and any other
password restrictions/requirements.
o Whether you provide backups or expect the users to create
their own.
Security Policy Handbook Working Group [Page 19]
RFC 11XX Security Policy Handbook MMMM 1990
o What guidelines you have regarding resource consumption
(whether users are restricted, and if so, what the
restrictions are).
o Disclosure of information that may be proprietary.
o Statement on Electronic Mail Privacy (Electronic
Communications Privacy Act).
o What users are specifically not permitted to do, such as
cracking passwords, trying to break into accounts, etc.
o Your policy concerning controversial mail/postings to
mailing lists or discussion groups (obscene, harassing, etc.).
o Policy on electronic communications: mail forging, etc.
The Electronic Mail Association sponsored a white paper on the
privacy of electronic mail in companies [4]. Their basic
recommendation is that every site should have a policy on the
protection of employee privacy. They also recommend that
organizations establish privacy policies that deal with all media,
rather than singling out electronic mail.
They suggest five criteria for evaluating any policy:
1. Does the policy comply with law and with duties to
third parties?
2. Does the policy unnecessarily compromise the interest of
the employee, the employer or third parties?
3. Is the policy workable as a practical matter and likely to
be enforced?
4. Does the policy deal appropriately with all different
forms of communications and record keeping with the office?
5. Has the policy been announced in advance and agreed to by
all concerned?
2.3.6 Rights and Responsibilities of System Administrators
versus Rights of Users
o Can an administrator monitor or read a user's files
for any reason?
o Liabilities
o Do net administrators have the right to examine
network or host traffic?
There is a tradeoff between a user's right to absolute privacy and
the need of system administrators to gather sufficient information
to diagnose problems. There is also a distinction between a
Security Policy Handbook Working Group [Page 20]
RFC 11XX Security Policy Handbook MMMM 1990
system administrator's need to gather information to diagnose
problems and looking/investigating use policy or security
violations. You need to determine to what degree system
administrators can examine user files to diagnose problems or for
other purposes, and what rights you grant to the users. You may
also wish to make a statement concerning system administrators
maintaining the privacy of information viewed under these
circumstances.
2.4 What Happens When the Policy is Violated [AS]
The following items discuss some ideas that one should consider
when enforcing a computer security policy. Defining the actual
computer security policy enforcement methods is beyond the scope
of this document since computer security requirements vary greatly
depending on the type of electronic data to be protected. As an
example, a Department of Defense (DoD) computer facility
performing top secret research would have far more stringent
requirements than, a collection of universities sharing
unclassified information about joint biological research over the
Internet.
It is obvious that when any type of official policy is defined, be
it related to computer security or not, it will eventually be
broken. This is guaranteed. The violation may occur due to an
individual's negligence, accidental mistake, having not been
properly informed of the current policy, or not understanding the
current policy. It is equally possible that an individual (or
group of individuals) may knowingly perform an act that is in
direct violation of the defined policy.
When a policy violation has been detected, the immediate course of
action should be pre-defined to ensure prompt and proper
enforcement. An investigation should be performed to determine
how and why the violation occurred. Then the appropriate
corrective action should be executed. The type and severity of
action taken varies depending on how the violation was performed.
For the few types of violations mentioned above, there would be
different forms of actions needed.
2.4.1 What to do When Outsiders Violate the Policy [AS]
What is an "outsider"? Depending on your perception, the term
outsiders may mean, for example, another group within your
organization, another organization within your division, another
division within your company or another company altogether. This
word actually refers to many kinds of outsiders, with each kind
being defined by your administrative, legal or political
Security Policy Handbook Working Group [Page 21]
RFC 11XX Security Policy Handbook MMMM 1990
boundaries. These boundaries imply what type of action must be
taken to correct the offending party; from a written reprimand to
pressing legal charges. So, not only do you need to define
actions based on the type of violation, you also need to have a
clearly defined series of actions based on the kind of outsider
violating your computer security policy. This all seems rather
complicated, but should be addressed long before the need becomes
necessary.
One point to remember about your policy is that proper education
is your best defense. For the outsiders who are using your
computer legally, it is your responsibility to verify that these
individuals are aware of the policies that you have set forth.
Having this proof may assist you in the future if legal action
becomes necessary.
As for outsiders who are using your computer illegally, the
problem is basically the same. What type of outsider violated the
policy and how and why did they do it? Depending on the results
of your investigation, you may just prefer to "plug" the hole in
your computer security and chalk it up to experience. Or if a
significant amount of loss was incurred, you may wish to take more
a drastic action.
----->*****[add more here]*****<-----
2.4.2 What to do When Local Users Violate the Policy [AS]
The term "local user" (or "insider") falls under same definition
rules mentioned for "outsiders". Anyone who is not an outsider is
a local user as far as this document is concerned.
2.4.3 What to do for Insider Intrusion - Libel And Slander [AS]
[to be completed]
2.4.4 What to do When Local Users Violate the Policy of a Remote
Site [AS]
[to be completed]
2.4.5 Define Contacts and Responsibilities to Outside Organizations
[AS]
[to be completed - talk about policy, escalation procedures, who
is allowed to talk to outsiders, who performs which role, etc...]
Security Policy Handbook Working Group [Page 22]
RFC 11XX Security Policy Handbook MMMM 1990
2.4.6 Who is Authorized to Make Outside Contacts? [AS]
[to be completed]
2.4.7 What are Your Obligations to Those Contacts? [AS]
[to be completed]
2.4.8 What are the Responsibilities to our Neighbors and Other
Internet Sites? [AS]
[to be completed - reference Security Policy Working Group work on
recommended Internet security policy]
2.4.9 Issues for Incident Handling Procedures [AS]
[to be completed - reference Section IV C 4]
=====
Author: Fred Ostapik (fred@NISC.SRI.COM) - Draft: 7-Nov-90
2.5 Locking In or Out
Whenever a site incurs an incident which may compromise computer
security, the reaction strategies may be influenced by two opposing
pressures.
If management fears that the site is sufficiently vulnerable, it may
choose a "Protect and Proceed" strategy. This approach will have as
its primary goal the protection and preservation of the site
facilities and to provide for normalcy for its users as quickly as
possible. Attempts will be made to actively interfere with the
intruder's processes, prevent further access and begin immediate
damage assessment and recovery. This process may involve shutting
down the facilities, closing off access to the network, or other
drastic measures. The drawback is that unless the intruder is
identified directly, they may come back into the site via a different
path, or may attack another site.
The alternate approach, "Pursue and Prosecute", adopts the opposite
philosophy and goals. The primary goal is to allow intruders to
continue their activities at the site until the site can identify the
person or persons responsible. This approach is endorsed by law
enforcement agencies and prosecutors. The drawback is that the
agencies cannot exempt a site from possible user lawsuits if damage
is done to their systems and data.
Security Policy Handbook Working Group [Page 23]
RFC 11XX Security Policy Handbook MMMM 1990
Prosecution is not the only outcome possible if the intruder is
identified. If the culprit is an employee or a student, the
organization may choose to take disciplinary actions. The computer
security policy needs to spell out what the choices are and how they
will be made if an intruder is caught.
Careful consideration must be made by site management regarding their
approach to this issue before the problem occurs. The strategy
adopted might depend upon each circumstance. Or there may be a
global policy which mandates one approach in all circumstances. The
pros and cons must be examined thoroughly and the users of the
facilities must be made aware of the policy so that they understand
their vulnerabilities whatever approach is taken.
The following are checklists to help a site determine which strategy
to adopt: "Protect and Proceed" or "Pursue and Prosecute".
Protect and Proceed
1. If assets are not well protected.
2. If continued penetration could result in great
financial risk.
3. If the possibility or willingness to prosecute
is not present.
4. If user base is unknown.
5. If users are unsophisticated and their work is
vulnerable.
6. If the site is vulnerable to lawsuits from users, if
their resources are undermined.
Pursue and Prosecute
1. If assets/system are well protected.
2. If good backups are available.
3. If the risk to the assets is outweighed by the
disruption caused by the present and possibly future
penetrations.
4. If this is a concentrated attack occurring with great
frequency and intensity.
Security Policy Handbook Working Group [Page 24]
RFC 11XX Security Policy Handbook MMMM 1990
5. If the site has a natural attraction to intruders, and
consequently regularly attracts intruders.
6. If the site is willing to incur the financial (or other)
risk to assets by letting the penetrator continue.
7. If intruder access can be controlled.
8. If the monitoring tools are sufficiently well-developed
to make the pursuit worthwhile.
9. If the support staff is sufficiently clever and knowledgable
with the operating system and related utilities and systems
to make the pursuit worthwhile.
10. If there is willingness on the part of management to
prosecute.
11. If the system gurus know what kind of evidence would lead
to prosecution.
12. If there is established contact with knowledgeable law
enforcement.
13. If there is a site representative versed in the relevant
legal issues.
14. If the site is prepared for possible legal action from
its own users if their data or systems become compromised
during the pursuit.
2.6 Publicizing the Policy
Once the site security policy has been established and committed to
writing, a vigorous process should be engaged which will ensure that
the policy statement is widely and thoroughly disseminated and
discussed. A mailing of the policy should not be considered
sufficient. A period for comments should be allowed before the
policy becomes effective to ensure that all affected users have a
chance to state their reactions and discuss any unforseen
ramifications. Ideally, the policy should strike a balance between
protection and productivity.
Meetings should be held to elicit these comments, and also to ensure
that the policy is correctly understood. (Policy promulgators are
not necessarily noted for their skill with the language.) These
meetings should involve higher management as well as troops.
Security is a collective effort.
Security Policy Handbook Working Group [Page 25]
RFC 11XX Security Policy Handbook MMMM 1990
In addition to the initial efforts to publicize the policy, it is
essential for the site to maintain a continual awareness of its
computer security policy. Current users may need periodic reminders
New users should have the policy included as part of their site
introduction packet. As a condition for using the site facilities,
it may be advisable to have them sign a statement that they have read
and understood the policy. Should any of these users require legal
action for serious policy violations, this signed statement might
prove to be a valuable aid.
=====
Section 3
Draft of November 15 & 16, 1990
Authors: Dave Curry (davy@erg.sri.com), Sean Kirkpatrick
(sean@nisd.cam.unisys.com)
3. Establishing Procedures to Prevent Security Problems [DC]
This section discusses the procedures used to prevent security
problems, as well as the procedures used in the event a security
problem arises.
3.1 Overview [DC]
It is important to develop procedures to prevent security problems at
your site. By following a fixed set of procedures, you can be
reasonably sure that there are least some things you don't have to
worry about (provided the procedures are followed, of course).
3.1.1 Security Policy Identifies Assets to Protect [DC]
One part of your security policy will identify exactly what you
are trying to protect, and what you're trying to protect it from.
Generally speaking, you are trying to protect your computer
systems and data from being compromised, modified, stolen,
deleted, etc. The security policy will spell this out in more
detail, usually by dividing your computer systems (and possibly
the data) into several categories, and spelling out how you plan
to protect the assets in those categories.
[SK] input: One of the major purposes of a security policy is to
define those things that need some sort of protection, and to
define the type of protection that those things need. The
physical equipment, computers, cabling, terminals or workstations,
etc, are all physical assets that obviously need protecting.
Security Policy Handbook Working Group [Page 26]
RFC 11XX Security Policy Handbook MMMM 1990
It's not always clear however, what other assets there may be that
need protecting. For example, a business may use computers to
process information about employees (such as salary), as well as
data about the business operations itself (such as business plans
and other technical data). Hospitals typically use computers to
maintain patient data, and there exists a very well defined legal
requirement to protect this data from disclosure. A university
may be involved in research, the disclosure of which may result in
a loss of future funding.
In each of these examples, the data maintained by computers should
be regarded as sensitive assets that must be afforded some kind of
protection. The security policy should carefully enumerate what
those assets are, and why they are deserving of protection.
3.1.2 Risk Assessment Establishes What's Cost-Effective to Protect
[DC]
Risk assessment is the process of examining all of your risks, and
ranking those risks by level of severity. This determines what
risks are cost-effective to protect against. You don't want to
spend a lot of time and money protecting yourself against
something you don't feel is a serious risk.
For example, you may decide that your site is very worried about
being broken into over the network or via a dialup modem, but that
you are not very concerned with security violations from your own
employees. In this case, you would want to focus most of your
time and effort (and money) on protecting your system against
network and modem intruders, and you would spend only a little
time on setting up ways for users to protect their files from each
other.
[SK] input: Once the assets requiring protection are identified, a
process of risk assessment should examine the threats to those
assets, and what potential for loss exists. Once this is done, it
is then possible to examine potential counters to those threats,
and to establish a reasonable approach to implementing required
protection mechanisms.
3.1.3 Choose Controls to Protect Assets in a Cost-Effective Way [DC]
After establishing what is to be protected, and assessing the
risks these assets face, it is necessary to decide how to
implement the controls which protect these assets.
[SK] input: It should be obvious that the controls and protection
mechanisms should be selected in a way so as to adequately counter
Security Policy Handbook Working Group [Page 27]
RFC 11XX Security Policy Handbook MMMM 1990
the threats found during risk assessment, and to implement those
controls in a cost effective manner. It makes little sense to
spend an exorbitant sum of money and overly constrict the user
base if the risk of exposure is very small.
3.1.3.1 Choose the Right Set of Controls [DC]
[I'm not sure what belongs in this section - it seems sort of
obvious that you don't want to choose the *wrong* set of
controls.]
[SK] input: The controls that are selected represent the
physical embodiment of your security policy. They are the
first and primary line of defense in the protection of your
assets. It is therefore most important to ensure that the
controls that you select are the right set of controls. If the
major threat to your system is outside penetrators, it probably
doesn't make much sense to use biometric devices to
authenticate your regular system users. On the other hand, if
the major threat is unauthorized use of computing resources by
regular system users, you'll probably want to establish very
rigorous automated accounting procedures.
3.1.3.2 Use Common Sense [DC]
One thing to remember when setting up your security controls is
to use common sense. While elaborate security systems are
impressive, and they do have their place, there is little point
in purchasing or implementing an elaborate scheme if the simple
things are forgotten. For example, no matter how elaborate a
system you put into place on top of existing security controls,
a single user with a poor password can still leave your system
open to attack. When implementing your security controls,
don't forget the simple things that still require attention.
[SK] input: It probably cannot be said enough that common sense
is the most appropriate tool that can be used to establish your
security policy. The idea of a security policy centers around
the notion of reasonable and credible controls. Elaborate
schemes and mechanisms, while appealing to a sense of the
exotic, are frequently of less objective than simpler
mechanisms. Furthermore, it may be that expending effort on
elaborate mechanisms may hide and otherwise obvious hole in
your overall policy.
3.1.4 Use Multiple Strategies to Protect Assets [DC]
Another method of protecting assets is to use multiple strategies.
Security Policy Handbook Working Group [Page 28]
RFC 11XX Security Policy Handbook MMMM 1990
In this way, if one strategy fails or is circumvented, another
strategy comes into play to continue protecting the asset. By
using several simpler strategies, a system can often be made more
secure than if one very sophisticated method were used in its
place.
[SK] input: It is also a reasonable approach to use multiple
strategies to protect your assets. Dial-back modems can be used
in conjunction with traditional logon mechanisms. Many similar
approaches could be devised that provide several levels of
protection for assets. However, it's very easy to go overboard
with extra mechanisms. One must keep in mind exactly what it is
that need to be protected.
3.2 System Security Audits [SK]
Most businesses undergo some sort of annual financial auditing as a
regular part of their business life. Security audits are an
important part of running any computing environment. Part of the
security audit should be a review of any policies that concern system
security, as well as the mechanisms that are put in place to enforce
them.
3.2.1 Organize Scheduled Drills [SK,DC]
Although not something that would be done each day or week,
scheduled drills may be conducted to determine if the procedures
defined are adequate for the threat to be countered. If your
major threat is one of natural disaster, then a drill would be
conducted to verify your backup and recovery mechanisms. On the
other hand, if your greatest threat is from external intruders
attempting to penetrate your system, a drill might be conducted to
actually try a penetration to observe the effect of the policies.
Drills are a valuable way to test that your policies and
procedures are effective. On the other hand, drills can be time-
consuming and disruptive to normal operations. It is important to
weigh the benefits of the drills against the possible time loss
which may be associated with them.
3.2.2 Test Procedures [DC]
Even if you don't use scheduled drills to examine your entire
security procedure at one time, it is important to test individual
procedures frequently. Examine your backup procedure to make sure
you can recover data from the tapes. Check log files to be sure
that information which is supposed to be logged to them is being
logged to them. And so on.
Security Policy Handbook Working Group [Page 29]
RFC 11XX Security Policy Handbook MMMM 1990
[SK] input: When a security audit is required, great care should
be used in devising tests of the security policy. It is important
to clearly identify what is being tested, how the test will be
conducted, and results expected from the test. This should all be
documented and included in or as an adjunct to the security policy
document itself.
It is important to test all aspects of the security policy, both
procedural and automated, with a particular emphasis on the
automated mechanisms used to enforce the policy. Tests should be
defined to ensure a comprehensive examination of policy features,
that is, if a test is defined to examine the user logon process,
it should be explicitly stated that both valid and invalid user
names and passwords will be used to demonstrate proper operation
of the logon program.
Keep in mind that there is a limit to what reasonable tests are.
The purpose of testing is to develop confidence that the security
policy is being correctly enforced, and not to "prove" the
absoluteness of the system or policy. The goal should be to
obtain some assurance that the reasonable and credible controls
imposed by your security policy are adequate.
3.3 Account Management Procedures [DC]
Procedures to manage accounts are important in preventing
unauthorized access to your system. It is necessary to decide
several things: Who may have an account on the system? How long may
someone have an account without renewing his/her request? How do old
accounts get removed from the system? The answers to all these
questions should be set out in a policy in order to prevent
unintentional violations.
3.3.1 Determine Authorization of System or Network Use [DC]
In addition to deciding who may use a system, it may be important
to determine what each user may use the system for (is personal
use allowed, for example). If you are connected to an outside
network, your site or the network management may have rules about
what the network may be used for.
[SK] input: It is important for any security policy to define an
adequate account management procedure for both administrators and
users. Typically, the system administrator would be responsible
for creating and deleting user accounts, and generally maintain
overall control of system use. To some degree, account management
is also the responsibility of each system user in the sense that
the user should observe any system messages and events that may be
Security Policy Handbook Working Group [Page 30]
RFC 11XX Security Policy Handbook MMMM 1990
indicative of a policy violation. For example, a message at logon
that indicates the date and time of the last logon should be
reported by the user if it indicates an unreasonable time of last
logon.
3.4 Password Management Procedures [DC]
A policy on password management may be important, if your site wishes
to enforce secure passwords. These procedures may range from asking
or forcing users to change their passwords occasionally to actively
attempting to break users' passwords and then informing the user of
how easy it was to do. Another part of password management policy
covers who may distribute passwords - can users give their passwords
to other users?
3.5 Configuration Management Procedures [SK]
Configuration management is generally applied to the software
development process. However, it is certainly applicable in a
operational sense as well. Consider that the since many of the
system level programs are intended to enforce the security policy, it
is important that these be "known" as correct. That is, one should
not allow system level programs (such as operating system updates,
etc.) to be changed arbitrarily. At very least, the procedures
should state who is authorized to make changes to systems, under what
circumstances, and how the changes should be documented.
In some environments, configuration management is also desirable as
applied to physical configuration of equipment as well. Maintaining
valid and authorized hardware configuration should be given due
consideration in your security policy.
3.5.1 Physical Security
[SK] input: Editorial note: I don't quite understand what Physical
Security, et. al., has to do with configuration management. While
it is appropriate to discuss physical security as a topic, I don't
think it belongs here.
[PH] input: It is a given that in computer security, if the system
itself is not physically secure, nothing else about the system can
be considered secure. With physical access to a machine, an
intruder can halt the machine, bring it back up in privileged
mode, replace or alter the disk, plant Trojan horse programs (see
section 3.9.9.2), or take any number of other undesirable (and
hard to protect) actions.
Critical communications links, important servers, and other key
Security Policy Handbook Working Group [Page 31]
RFC 11XX Security Policy Handbook MMMM 1990
machines should be located in physically secure areas. Some
security systems (such as Kerberos) require that the machine be
physically secure.
If you cannot physically secure machines, care should be taken
about trusting those machines. Sites should consider limiting
access from non-secure machines to more secure machines. In
particular, allowing trusted access (e.g., the BSD Unix r-
commands) from these kinds of hosts is particularly risky.
For machines that are physically secure, care should be taken
about who has access to the machines. Remember that custodial and
maintenance staff often have keys to rooms.
3.5.1.1 Security Boundary, Site Boundary
3.5.1.2 Definition of Terms
3.5.2 Develop Tools as Preventive and Reactive
3.5.2.1 Inventory of Tools
3.5.3 Non-Standard Configurations [DC]
Occasionally, it may be beneficial to have a slightly non-standard
configuration in order to thwart the "standard" attacks used by
some intruders. The non-standard parts of the configuration might
include different password encryption algorithms, different
configuration file locations, and rewritten or functionally
limited system commands.
Non-standard configurations, however, also have their drawbacks.
By changing the "standard" system, these modifications make
software maintenance more difficult by requiring extra
documentation to be written, software modification after operating
system upgrades, and usually someone with special knowledge of the
changes.
Because of the drawbacks of non-standard configurations, they are
often only used in environments with a "firewall" machine (see
section 3.9.1). The firewall machine is modified in non-standard
ways since it is susceptible to attack, while internal systems
behind the firewall are left in their standard configurations.
3.6 Procedures to Recognize Unauthorized Activity [DC]
Several simple procedures can be used to detect most unauthorized
uses of a computer system. These procedures use tools provided with
Security Policy Handbook Working Group [Page 32]
RFC 11XX Security Policy Handbook MMMM 1990
the operating system by the vendor, or tools publicly available from
other sources.
3.6.1 Monitoring System Use [DC]
System monitoring can be done either by a system administrator, or
by software written for the purpose. Monitoring a system involves
looking at several parts of the system, and searching for anything
unusual. Some of the easier ways to do this are described in this
section.
The most important thing about monitoring system use is that it be
done on a regular basis. Picking one day out of the month to
monitor the system is pointless, since a security breach can be
over and done with in a matter of hours. Only by maintaining a
constant vigil can you expect to detect security violations in
time to react to them.
3.6.2 Tools for Monitoring the System [DC]
This section describes tools and methods for monitoring a system
against unauthorized access and use.
3.6.2.1 Logging [DC]
Most operating systems store numerous bits of information in
log files. Examination of these log files on a regular basis
is often the first line of defense in detecting unauthorized
use of the system.
- Compare lists of currently logged in users and past
login histories. Most users typically log in and out
at roughly the same time each day. An account logged
in outside the "normal" time for the account may be in
use by an intruder.
- Many systems maintain accounting records for billing
purposes. These records can also be used to determine
usage patterns for the system; unusual accounting records
may indicate unauthorized use of the system.
- System logging facilities, such as the UNIX "syslog"
utility, should be checked for unusual error messages
from system software. For example, a large number of
failed login attempts in a short period of time may
indicate someone trying to guess passwords.
- Operating system commands which list currently executing
Security Policy Handbook Working Group [Page 33]
RFC 11XX Security Policy Handbook MMMM 1990
processes can be used to detect users running programs
they are not authorized to use, as well as to detect
unauthorized programs which have been started by an
intruder.
3.6.2.2 Monitoring Software [DC]
Other monitoring tools can easily be constructed using standard
operating system software, by using several often unrelated
programs together. For example, checklists of file ownerships
and permission settings can be constructed (for example, with
"ls" and "find" on UNIX) and stored off-line. These lists can
then be reconstructed periodically and compared against the
master checklist (on UNIX, by using the "diff" utility).
Differences may indicate that unauthorized modifications have
been made to the system.
Still other tools are available from third party vendors and
public software distribution sites. Section 3.9.7 lists
several sources from which you can learn what tools are
available, and how to get them.
3.6.2.3 Other Tools [DC]
Other tools can also be used to monitor systems for security
violations, although this is not their primary purpose in life.
For example, network monitors can be used to detect and log
connections from unknown sites.
3.6.3 Vary the Monitoring Schedule
The task of system monitoring is not as daunting as it may seem.
System administrators can execute many of the commands used for
monitoring periodically throughout the day during idle moments
(e.g., while talking on the telephone), rather than spending fixed
periods of each day monitoring the system. By executing the
commands frequently, you will rapidly become used to seeing
"normal" output, and will easily spot things which are out of the
ordinary.
By running various monitoring commands at different times
throughout the day, you make it hard for an intruder to predict
your actions. For example, if an intruder knows that each day at
5:00 p.m. the system is checked to see that everyone has logged
off, he will simply wait until after the check has completed
before logging in. But the intruder cannot guess when a system
administrator might type "who" in an idle moment, and thus he runs
a much greater risk of detection.
Security Policy Handbook Working Group [Page 34]
RFC 11XX Security Policy Handbook MMMM 1990
[SK] input: Despite the advantages that regular system monitoring
provides, some intruders will know the things an administrator may
do to monitor their system, and will sometimes take action to
disable monitoring mechanisms. Regular monitoring therefore does
not provide any guarantees that your system is secure, but can
still be a valuable defensive technique that can be used to
increase the assurance that your system is not being abused.
[DC] input: Note that some intruders may be aware of the standard
logging mechanisms in use on systems they are attacking, and will
actively attempt to disable or fool these mechanisms. Monitoring
commands are useful in detecting intruders, but they should not be
considered an infallible method of detecting unauthorized use.
3.7 Define Actions to Take When Unauthorized Activity is Suspected
Sections 2.4 and 2.5 discussed the course of action a site should
take when it suspects its systems are being abused. The computer
security policy should state the general approach towards dealing
with these problems.
The procedures for dealing with these types of problems should be
written down. Who has authority to decide what actions will be
taken? Should law enforcement be involved? Should your
organization cooperate with other sites in trying to track down an
intruder? Answers to all the questions in section 2.4 should be
part of the incident handling procedures. [We still need to fill
in those questions in 2.4! --jkrey]
Whether you decide to lock out or pursue intruders, you should
have tools and procedures ready to apply. It is best to work up
these tools and procedures before you need them. Don't wait until
an intruder is on your system to figure out how to track the
intruder's actions; you will be busy enough if an intruder
strikes.
3.8 Communicating Security Policy [DC]
Security policies, in order to be effective, must be communicated to
both the users of the system and the system maintainers. This
section describes what these people should be told, and how to tell
them.
3.8.1 Educating the Users [DC]
Users should be made aware of how the computer systems are
expected to be used, and how to protect themselves from
unauthorized users.
Security Policy Handbook Working Group [Page 35]
RFC 11XX Security Policy Handbook MMMM 1990
3.8.1.1 Proper Account/Workstation Use [DC]
All users should be informed about what is considered the
"proper" use of their account or workstation ("proper" use is
discussed in section 2.3.1). This can most easily be done at
the time a user receives their account, by giving them a policy
statement. Proper use policies typically dictate things such
as whether or not the account or workstation may be used for
personal activities (such as checkbook balancing or letter
writing), whether profit-making activities are allowed, whether
game playing is permitted, and so on. These policy statements
may also be used to summarize how the computer facility is
licensed and what software licenses are held by the
institution; for example, many universities have educational
licenses which explicitly prohibit commercial uses of the
system. A more complete list of items to consider when writing
a policy statement is given in section 2.3.
3.8.1.2 Account/Workstation Management Procedures [DC]
Each user should be told how to properly manage their account
and/or workstation. This includes explaining how to protect
files stored on the system, how to log out or lock the
terminal/workstation, and so on. Much of this information is
typically covered in the "beginning user" documentation
provided by the operating system vendor, although many sites
elect to supplement this material with local information.
If your site offers dial-up modem access to the computer
systems, special care must be taken to inform users of the
security problems inherent in providing this access. Issues
such as making sure to log out before hanging up the modem
should be covered when the user is initially given dial-up
access.
Likewise, access to the systems via local and wide-area
networks presents its own set of security problems which users
should be made aware of. Files which grant "trusted host" or
"trusted user" status to remote systems and users should be
carefully explained.
3.8.1.3 Password Management Procedures [DC]
Perhaps the most vulnerable part of any computer system is the
account password. Any computer system, no matter how secure it
is from network or dial-up attack, Trojan horse programs, and
so on, can be fully exploited by an intruder if he/she can gain
access via a poorly chosen password. It is important to define
Security Policy Handbook Working Group [Page 36]
RFC 11XX Security Policy Handbook MMMM 1990
a good set of rules for password selection, and distribute
these rules to all users. If possible, the software which sets
user passwords should be modified to enforce as many of the
rules as possible.
A sample set of guidelines for password selection is shown
below:
- DON'T use your login name in any form (as-is,
reversed, capitalized, doubled, etc.).
- DON'T use your first, middle, or last name in any form.
- DON'T use your spouse's or child's name.
- DON'T use other information easily obtained about you.
This includes license plate numbers, telephone numbers,
social security numbers, the make of your automobile,
the name of the street you live on, etc.
- DON'T use a password of all digits, or all the same
letter.
- DON'T use a word contained in English or foreign
language dictionaries, spelling lists, or other
lists of words.
- DON'T use a password shorter than six characters.
- DO use a password with mixed-case alphabetics.
- DO use a password with non-alphabetic characters (digits
or punctuation).
- DO use a password that is easy to remember, so you don't
have to write it down.
- DO use a password that you can type quickly, without
having to look at the keyboard.
Methods of selecting a password which adheres to these
guidelines include:
- Choose a line or two from a song or poem, and use the
first letter of each word.
- Alternate between one consonant and one or two vowels, up
to seven or eight characters. This provides nonsense
Security Policy Handbook Working Group [Page 37]
RFC 11XX Security Policy Handbook MMMM 1990
words which are usually pronounceable, and thus easily
remembered.
- Choose two short words and concatenate them together with
a punctuation character between them.
Users should also be told to change their password
periodically, usually every three to six months. This makes
sure that an intruder who has guessed a password will
eventually lose access, as well as invalidating any list of
passwords he/she may have obtained. Many systems enable the
system administrator to force users to change their passwords
after an expiration period; this software should be enabled if
your system supports it. [5, CURRY]
Some systems provide software which forces users to change
their passwords on a regular basis. Many of these systems also
include password generators, which provide the user with a set
of passwords to choose from. The user is not permitted to make
up his/her own password. There are arguments both for and
against systems such as these. On the one hand, by using
generated passwords, users are prevented from selecting
insecure passwords. On the other hand, unless the generator is
good at making up easy to remember passwords, users will begin
writing them down in order to remember them.
3.8.1.4 Determining Account Misuse [DC]
Users should be told how to detect unauthorized access to their
account. If the system prints the last login time when a user
logs in, he/she should be told to check that time and note
whether or not it agrees with the last time he/she actually
logged in.
Command interpreters on some systems (e.g., the UNIX C shell)
maintain histories of the last several commands executed.
Users should check these histories to be sure someone has not
executed other commands with their account.
3.8.1.5 Problem Reporting Procedures [DC]
A procedure should be developed to enable users to report
suspected misuse of their accounts, or other misuse they may
have noticed. This can be done either by providing the name
and telephone number of a system administrator who manages
security of the computer system, or by creating an electronic
mail address (e.g., "security") to which users can address
their problems.
Security Policy Handbook Working Group [Page 38]
RFC 11XX Security Policy Handbook MMMM 1990
3.8.2 Educating the Host Administrators [DC]
In many organizations, computer systems are administered by a wide
variety of people. These administrators must know how to protect
their own systems from attack and unauthorized use, as well as how
to communicate successful penetration of their systems to other
administrators as a warning.
3.8.2.1 Account Management Procedures [DC]
Care must be taken when installing accounts on the system in
order to make them secure. When installing a system from
distribution media, the password file should be examined for
"standard" accounts provided by the vendor. Many vendors
provide accounts for use by system services or field service
personnel. These accounts typically have either no password or
one which is common knowledge. These accounts should be given
new passwords if they are needed, or disabled and/or deleted
from the system if they are not.
Accounts without passwords are generally very dangerous, since
they allow anyone to access the system. Even accounts which do
not execute a command interpreter (e.g., accounts which exist
only to see who is logged in to the system) can be compromised
if set up incorrectly. A related concept, that of "anonymous"
file transfer (FTP) [20], allows users from all over the
network to access your system to retrieve files from (usually)
a protected disk area. You should carefully weigh the benefits
that an account without a password provides against the
security risks of providing such access to your system.
If the operating system provides a "shadow" password facility
which stores passwords in a separate file accessible only to
privileged users, this facility should be used. System V UNIX,
SunOS 4.0 and above, and versions of Berkeley UNIX after 4.3BSD
Tahoe, as well as others, provide this feature. It protects
passwords by hiding their encrypted values from unprivileged
users. This prevents an attacker from copying your password
file to his/her machine and then attempting to break the
passwords at his/her leisure.
Keep track of who has access to privileged user accounts (e.g.,
"root" on UNIX or "MAINT" on VMS). Whenever a privileged user
leaves the organization or no longer has need of the privileged
account, the passwords on all privileged accounts should be
changed.
Security Policy Handbook Working Group [Page 39]
RFC 11XX Security Policy Handbook MMMM 1990
3.8.2.2 Configuration Management Procedures [DC]
When installing a system from the distribution media, or when
installing third-party software, it is important to check the
installation carefully. Many installation procedures assume a
"trusted" site, and hence will install files with world write
permission enabled, etc.
Network services should also be examined carefully when first
installed. Many vendors provide default network permission
files which imply that all outside hosts are to be "trusted",
which is rarely the case when connected to wide-area networks
such as the Internet.
Many intruders collect information on the vulnerabilities of
particular system versions. The older a system, the more
likely it is that there are security problems in that version
which have since been fixed by the vendor in a later release.
For this reason, it is important to weigh the risks of not
upgrading to a new operating system release (thus leaving
security holes unplugged) against the cost of upgrading to the
new software (possibly breaking third-party software, etc.).
Bug fixes from the vendor should be weighed in a similar
fashion, with the added note that "security" fixes from a
vendor usually address fairly serious security problems.
Other bug fixes, received via network mailing lists and the
like, should usually be installed, but not without careful
examination. Never install a bug fix unless you're sure you
know what the consequences of the fix are - there's always the
possibility that an intruder has suggested a "fix" which
actually gives his/her access to the system.
3.8.2.3 Recovery Procedures - Backups [DC]
It is impossible to overemphasize the need for a good backup
strategy. File system backups not only protect you in the
event of hardware failure or accidental deletions, but they
also protect you against unauthorized changes made by an
intruder. Without a copy of your data the way it's "supposed"
to be, it can be difficult to undo something an attacker has
done.
Backups, especially if run daily, can also be useful in
providing a history of an intruder's activities. Looking
through old backups can establish when your system was first
penetrated. Intruders may leave files around which although
deleted later, are captured on the backup tapes. Backups can
Security Policy Handbook Working Group [Page 40]
RFC 11XX Security Policy Handbook MMMM 1990
also be used to document an intruder's activities to law
enforcement agencies if necessary.
A good backup strategy will dump the entire system to tape at
least once a month. Partial (or "incremental") dumps should be
done at least twice a week, and ideally they should be done
daily. Commands specifically designed for performing file
system backups (e.g., UNIX "dump" or VMS "BACKUP") should be
used in preference to other file copying commands, since these
tools are designed with the express intent of restoring a
system to a known state.
3.8.2.4 Problem Reporting Procedures [DC]
As with users, system administrators should have a defined
procedure for reporting security problems. In large
installations, this is often done by creating an electronic
mail alias which contains the names of all system
administrators in the organization. Other methods include
setting up some sort of response team similar to the CERT, or
establishing a "hotline" serviced by an existing support group.
3.9 Resources to Prevent Security Breaches [SK]
This section discusses software, hardware, and procedural resources
that can be used to support your site security policy.
3.9.1 Network Connections and Firewalls [SK,DC]
A "firewall" is put in place in a building to provide a point of
resistance to the entry of flames into another area. Similarly, a
secretary's desk and reception area provides a point of
controlling access to other office spaces. This same technique
can be applied to a computer site, particularly as it pertains to
network connection.
Some sites will be connected only to other sites within the same
organization and will not have the ability to connect to other
networks. Sites such as these are less susceptible to threats
from outside their own organization, although intrusions may still
occur via paths such as dial-up modems. On the other hand, many
other organizations will be connected to other sites via much
larger networks, such as the Internet. These sites are
susceptible to the entire range of threats incipient to a
networked environment.
The risks of connecting to outside networks must be weighed
against the benefits. It may be desirable to limit connection to
Security Policy Handbook Working Group [Page 41]
RFC 11XX Security Policy Handbook MMMM 1990
outside networks to those hosts which do not store sensitive
material, keeping "vital" machines (such as those which maintain
company payroll or inventory systems) isolated. If there is a
need to participate in a Wide Area Network (WAN), consider
restricting all access to your local network through a single
system. That is, all access to or from your own local network
must be made through a single host computer that acts as a
firewall between you and the outside world. This firewall system
should be rigorously controlled and password protected, and
external users accessing it should also be constrained by
restricting the functionality available to remote users. By using
this approach, your site could relax some of the internal security
controls on your local net, but still be afforded the protection
of a rigorously controlled host front end.
Note that even with a firewall system, compromise of the firewall
could result in compromise of the network behind the firewall.
Work has been done in some areas to construct a firewall which
even when compromised, still protects the local network. [6,
CHESWICK]
3.9.2 Confidentiality [SK,DC]
Confidentiality, the act of keeping things hidden or secret, is
one of the primary goals of computer security practitioners.
Several mechanisms are provided by most modern operating systems
to enable users to control the dissemination of information.
Depending upon where you work, you may have a site where
everything is protected, or a site where all information is
usually regarded as public, or something in-between. Most sites
lean toward the latter, at least until some penetration has
occurred.
Generally, there are three instances in which information is
vulnerable to disclosure: when the information is stored on a
computer system, when the information is in transit to another
system (on the network), and when the information is stored on
backup tapes.
The first of these cases is controlled by file permissions, access
control lists, and other similar mechanisms. The last can be
controlled by restricting access to the backup tapes (by locking
them in a safe, for example). All three cases can be helped by
using encryption mechanisms.
Security Policy Handbook Working Group [Page 42]
RFC 11XX Security Policy Handbook MMMM 1990
3.9.2.1 Encryption (hardware and software) [SK,DC]
Encryption is the process of taking information that exists in
some readable form and converting it into a non-readable form.
There are several types of commercially available encryption
packages in both hardware and software forms. Hardware
encryption engines have the advantage that they are much faster
than the software equivalent, yet because they are faster, they
are of greater potential benefit to an attacker who wants to
execute a brute force attack to your encrypted information.
The advantage of using encryption is that even if other access
control mechanisms (passwords, file permissions, etc.) are
compromised by an intruder, the data is still protected by
being unusable. Naturally, encryption keys and the like should
be protected at least as well as account passwords.
Information in transit (over a network) may be vulnerable to
interception as well. Several solutions to this exist, ranging
from simply encrypting files before transferring them (end-to-
end encryption) to special network hardware which encrypts
everything it sends without user intervention (secure links).
The Internet as a whole does not use secure links, thus end-
to-end encryption must be used if encryption is desired across
the Internet.
3.9.2.1.1 DES [SK]
DES, the Data Encryption Standard, is perhaps the most
widely used data encryption mechanism today. Many hardware
and software implementations exist, and some commercial
computers are provided with a software version. DES
transforms plain text information into encrypted data (or
ciphertext) by means of a special algorithm and "seed" value
called a key. So long as the key is retained (or
remembered) by the original user, the ciphertext can be
restored to the original plain text.
One of the pitfalls of all encryption systems is the need to
remember the key under which a thing was encrypted (this is
not unlike the password problem discussed elsewhere in this
document). If the key is written down, it becomes less
secure. If forgotten, there is little if any hope of
recovering the original data.
Most UNIX systems provide a DES command that enables a user
to encrypt data using the DES algorithm.
Security Policy Handbook Working Group [Page 43]
RFC 11XX Security Policy Handbook MMMM 1990
3.9.2.1.2 Crypt [SK]
Similar to the DES command, the UNIX "crypt" command allows
a user to encrypt data. Unfortunately, the algorithm used
by "crypt" is very insecure (based on the World War II
"Enigma" device), and files encrypted with this command can
be decrypted easily in a matter of a few hours. Generally,
use of the "crypt" command should be avoided for any but the
most trivial encryption tasks.
3.9.2.2 Privacy Enhanced Mail [SK,DC]
Electronic mail normally transits the network in the clear
(i.e., anyone can read it). This is obviously not the optimal
solution. Privacy enhanced mail provides a means to
automatically encrypt your electronic mail messages so that a
person eavesdropping at a mail distribution node is not
(easily) capable of reading your mail messages. Several
privacy enhanced mail packages are currently being developed
and deployed on the Internet.
The Internet Activities Board Privacy Task Force has defined a
draft standard, elective protocol for use in implementing
privacy enhanced mail. This protocol is defined in RFCs 1113,
1114, and 1115 [7,8,9]. Please refer to the current edition of
the "IAB Official Protocol Standards" (currently, RFC 1140
[21]) for the standardization state and status of these
protocols.
3.9.3 Origin Authentication [SK]
We mostly take it on faith that the header of an electronic mail
message truly indicates the originator of a message. However,
there are documented cases it which mail messages have been
"spoofed", or forged using someone else's name. Origin
authentication provides a means to be certain of the originator of
a message or other object in the same way that a Notary Public
assures a signature on a legal document. This is done by means of
a "Public Key" cryptosystem.
A public key cryptosystem differs from a private key cryptosystem
in several ways. First, a public key system uses two keys, a
Public Key that anyone can use (hence the name, Public Key) and a
Private Key that only the originator of a message uses. The
originator uses the private key to encrypt the message similar to
DES. The receiver, who has obtained the public key for the
originator, may then decrypt the message.
Security Policy Handbook Working Group [Page 44]
RFC 11XX Security Policy Handbook MMMM 1990
In this scheme, the public key is used to authenticate the
originator's use of his/her private key, and hence the identity of
the originator is more rigorously proven. The most widely known
implementation of a public key cryptosystem is the RSA system.
The Internet standard for privacy enhanced mail makes use of the
RSA system. [citation for RSA?? --jkrey]
3.9.4 Information Integrity [SK,DC]
Information Integrity refers to the state of information such that
it is complete, correct, and unchanged from the last time in which
it was verified to be in an "integral" state. The value of
information integrity to a site will vary. For example, it is
more important for military and government installations to
prevent the "disclosure" of classified information, whether it is
right or wrong. A bank, on the other hand, is far more concerned
with whether the account information maintained for its customers
is complete and accurate.
Numerous computer system mechanisms, as well as procedural
controls, have an influence on the integrity of system
information. Traditional access control mechanisms maintain
controls over who can access system information. These mechanisms
alone are not sufficient in some cases to provide the degree of
integrity required. Some other mechanisms are briefly discussed
below.
It should be noted that there are other aspects to maintaining
system integrity besides these mechanisms, such as two person
controls, and Integrity Validation Procedures. These are beyond
the scope of this document.
3.9.4.1 Checksums [SK,DC]
Easily the simplest mechanism, a simple checksum routine can
compute a value for a system file and compare it with the last
known value. If the two are equal, no change has occurred. If
not, the file has been changed by some unknown means.
Though it is the easiest to implement, the checksum scheme
suffers from a serious failing in that it is not very
sophisticated and a determined attacker could easily add enough
characters to the file to eventually obtain the correct value.
A specific type of checksum, called a CRC checksum, is
considerably more robust than a simple checksum. It is only
slightly more difficult to implement and provides a much finer
degree of catching errors. It too, however, suffers from the
Security Policy Handbook Working Group [Page 45]
RFC 11XX Security Policy Handbook MMMM 1990
ability to be compromised by an attacker.
Checksums may be used to detect the altering of information.
However, they do not actively guard against changes being made.
For this, other mechanisms such as access controls and
encryption should be used.
3.9.4.2 Cryptographic Checksums [SK,DC]
Cryptographic checksums (also called cryptosealing) involve
breaking a file up into smaller chunks, calculating a (CRC)
checksum for each chunk, and adding the CRCs together.
Depending upon the exact algorithm used, this can result in a
nearly unbreakable method of determining whether a file has
been changed. This mechanism suffers from the fact that it is
sometimes computationally intensive and may be prohibitive
except in cases where the utmost integrity protection is
desired.
Another related mechanism, called a one-way hash function (or a
Manipulation Detection Code (MDC)) can also be used to uniquely
identify a file. The idea behind these functions is that no
two inputs can produce the same output, thus a modified file
will not have the same hash value. One-way hash functions can
be implemented efficiently on a wide variety of systems, making
unbreakable integrity checks possible. (Snefru, a one-way hash
function available via USENET as well as the Internet is just
one example of an efficient one-way hash function.) [10]
3.9.5 Limiting Network Access [DC]
The dominant network protocols in use on the Internet, IP (RFC
791) [11], TCP (RFC 793) [12], and UDP (RFC 768) [13], carry
certain control information which can be used to restrict access
to certain hosts or networks within an organization.
The IP packet header contains the network addresses of both the
sender and recipient of the packet. Further, the TCP and UDP
protocols provide the notion of a "port", which identifies the
endpoint (usually a network server) of a communications path. In
some instances, it may be desirable to deny access to a specific
TCP or UDP port, or even to certain hosts and networks altogether.
3.9.5.1 Gateway Routing Tables [DC]
One of the simplest approaches to preventing unwanted network
connections is to simply remove certain networks from a
gateway's routing tables. This makes it "impossible" for a
Security Policy Handbook Working Group [Page 46]
RFC 11XX Security Policy Handbook MMMM 1990
host to send packets to these networks. (Most protocols
require bidirectional packet flow even for unidirectional data
flow, thus breaking one side of the route is usually
sufficient.)
This approach is commonly taken in "firewall" systems, by
preventing the firewall from advertising local routes to the
outside world. The approach is deficient in that it often
prevents "too much" (e.g., in order to prevent access to one
system on the network, access to all systems on the network is
disabled).
3.9.5.2 Router Packet Filtering [DC]
Many commercially available gateway systems (more correctly
called routers) provide the ability to filter packets based not
only on sources or destinations, but also on source-destination
combinations. This mechanism can be used to deny access to a
specific host, network, or subnet from any other host, network,
or subnet.
Gateway systems from cisco Systems support an even more complex
scheme, allowing finer control over source and destination
addresses. Via the use of address masks, one can deny access
to all but one host on a particular network. The cisco Systems
also allow packet screening based on IP protocol type and TCP
or UDP port numbers. [14]
3.9.6 Authentication Systems [SK]
Authentication refers to the process of proving a claimed identity
to the satisfaction of some permission granting authority.
Authentication systems are hardware, software, or procedural
mechanisms that enable a user to obtain access to computing
resources. At the simplest level, the system administrator who
adds new user accounts to the system is part of the system
authentication mechanism. At the other end of the spectrum,
finger print readers or retinal scanners provide a very high tech
solution to establishing a potential user's identity. Without
establishing and proving a user's identity prior to establishing a
session, your sites computers are vulnerable to any sort of
attack.
Typically, a user authenticates himself/herself to the system by
entering a password in response to a prompt. Challenge/Response
mechanisms improve upon passwords by prompting the user for any
one of a number of pieces of information shared by both the
computer and the user (such as mother's maiden name, etc.).
Security Policy Handbook Working Group [Page 47]
RFC 11XX Security Policy Handbook MMMM 1990
3.9.6.1 Kerberos [SK,DC]
Kerberos, named after the dog who in mythology is said to stand
at the gates of Hades, is a collection of software used in a
large network to establish a user's claimed identity.
Developed at the Massachusetts Institute of Technology (MIT),
it uses a combination of encryption and distributed databases
so that a user at a campus facility can log in and start a
session from any computer located on the campus. This has
clear advantages in certain environments where there are a
large number of potential users who may establish a connection
from any one of a large number of workstations. Some vendors
are now incorporating Kerberos into their systems.
It should be noted that while Kerberos makes several advances
in the area of authentication, some security weaknesses in the
protocol still remain. [15]
3.9.6.2 Smart Cards [SK]
Some computer systems have instituted new password procedures
that require a user to enter a value obtained from a "smart
card" (a small calculator-like device) when asked for a
password by the computer. Typically, the host machine will
give the user some piece of information that is entered into
the keyboard of the smart card. The smart card will display
the response which must then be entered into the computer
before the session will be established.
This is a better way of dealing with authentication than with
the traditional password approach. On the other hand, some say
it's inconvenient to carry the smart card. Start up costs are
likely to be high as well.
3.9.7 Books/Lists/Informational Sources [SK]
There are many good sources for information regarding computer
security. The annotated bibliography at the end of this document
can provide you with a good start. In addition, information can
be obtained from a variety of other sources, some of which are
described in this section.
3.9.7.1 Security Mailing Lists [DC]
The UNIX Security mailing list exists to notify system
administrators of security problems before they become common
knowledge, and to provide security enhancement information. It
is a restricted-access list, open only to people who can be
Security Policy Handbook Working Group [Page 48]
RFC 11XX Security Policy Handbook MMMM 1990
verified as being principal systems people at a site. Requests
to join the list must be sent by either the site contact listed
in the Defense Data Network's Network Information Center's (DDN
NIC) WHOIS database, or from the "root" account on one of the
major site machines. You must include the destination address
you want on the list, an indication of whether you want to be
on the mail reflector list or receive weekly digests, the
electronic mail address and voice telephone number of the site
contact if it isn't you, and the name, address, and telephone
number of your organization. This information should be sent
to SECURITY-REQUEST@CPD.COM.
The RISKS digest is a component of the ACM Committee on
Computers and Public Policy, moderated by Peter G. Neumann. It
is a discussion forum on risks to the public in computers and
related systems, and along with discussing computer security
and privacy issues, has discussed such subjects as the Stark
incident, the shooting down of the Iranian airliner in the
Persian Gulf (as it relates to the computerized weapons
systems), problems in air and railroad traffic control systems,
software engineering, and so on. To join the mailing list,
send a message to RISKS-REQUEST@CSL.SRI.COM. This list is also
available in the USENET newsgroup "comp.risks".
The VIRUS-L list is a forum for the discussion of computer
virus experiences, protection software, and related topics.
The list is open to the public, and is implemented as a
moderated digest. Most of the information is related to
personal computers, although some of it may be applicable to
larger systems. To subscribe, send the line:
SUB VIRUS-L your full name
to the address LISTSERV%LEHIIBM1.BITNET@MITVMA.MIT.EDU. This
list is also available via the USENET newsgroup "comp.virus".
The Computer Underground Digest "is an open forum dedicated to
sharing information among computerists and to the presentation
and debate of diverse views." While not directly a security
list, it does contain discussions about privacy and other
security related topics. The list can be read on USENET as
alt.society.cu-digest, or to join the mailing list, send mail
to Gordon Myer (TK0JUT2%NIU.bitnet@mitvma.mit.edu).
Submissions may be mailed to: cud@chinacat.unicom.com.
Security Policy Handbook Working Group [Page 49]
RFC 11XX Security Policy Handbook MMMM 1990
3.9.7.2 Networking Mailing Lists [DC]
The TCP-IP mailing list is intended to act as a discussion
forum for developers and maintainers of implementations of the
TCP/IP protocol suite. It also discusses network-related
security problems when they involve programs providing network
services, such as "sendmail". To join the TCP-IP list, send a
message to TCP-IP-REQUEST@NIC.DDN.MIL. This list is also
available in the USENET newsgroup "comp.protocols.tcp-ip".
SUN-NETS is a discussion list for items pertaining to
networking on Sun systems. Much of the discussion is related
to NFS, Yellow Pages, and name servers. To subscribe, send a
message to SUN-NETS-REQUEST@UMIACS.UMD.EDU.
The USENET groups misc.security and alt.security also discuss
security issues. misc.security is a moderated group, and also
includes discussions of physical security and locks.
alt.security is unmoderated.
3.9.7.3 Response Teams [DC]
Several organizations have formed special groups of people to
deal with computer security problems. These teams collect
information about possible security holes and disseminate it to
the proper people, track intruders, and assist in recovery from
security violations. The teams typically have both electronic
mail distribution lists as well as a special telephone number
which can be called for information or to report a problem.
Many of these teams are members of the CERT System, which is
coordinated by the National Institute of Standards and
Technology (NIST), and exists to facilitate the exchange of
information between the various teams.
3.9.7.3.1 DARPA Computer Emergency Response Team [DC]
The Computer Emergency Response Team/Coordination Center
(CERT/CC) was established in December 1988 by the Defense
Advanced Research Projects Agency (DARPA) to address
computer security concerns of research users of the
Internet. It is operated by the Software Engineering
Institute (SEI) at Carnegie-Mellon University (CMU). The
CERT can immediately confer with experts to diagnose and
solve security problems, and also establish and maintain
communications with the affected computer users and
government authorities as appropriate.
The CERT/CC serves as a clearing house for the
Security Policy Handbook Working Group [Page 50]
RFC 11XX Security Policy Handbook MMMM 1990
identification and repair of security vulnerabilities,
informal assessments of existing systems, improvement of
emergency response capability, and both vendor and user
security awareness. In addition, the team works with
vendors of various systems in order to coordinate the fixes
for security problems.
The CERT/CC sends out security advisories to the CERT-
ADVISORY mailing list whenever appropriate. They also
operate a 24-hour hotline that can be called to report
security problems (e.g., someone breaking into your system),
as well as to obtain current (and accurate) information
about rumored security problems.
To join the CERT-ADVISORY mailing list, send a message to
CERT@CERT.SEI.CMU.EDU and ask to be added to the mailing
list. The material sent to this list also appears in the
USENET newsgroup "comp.security.announce". Past advisories
are available for anonymous FTP from the host
CERT.SEI.CMU.EDU. The 24-hour hotline number is (412) 268-
7090.
The CERT/CC also maintains a CERT-TOOLS list to encourage
the exchange of information on tools and techniques that
increase the secure operation of Internet systems. The
CERT/CC does not review or endorse the tools described on
the list. To subscribe, send a message to CERT-TOOLS-
REQUEST@CERT.SEI.CMU.EDU and ask to be added to the mailing
list.
The CERT/CC maintains other generally useful security
information for anonymous FTP from CERT.SEI.CMU.EDU. Get
the README file for a list of what is available.
For more information, contact:
CERT
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
(412) 268-7090
cert@cert.sei.cmu.edu.
3.9.7.3.2 DDN Security Coordination Center [DC]
For DDN users, the Security Coordination Center (SCC) serves
a function similar to CERT. The SCC is the DDN's clearing-
Security Policy Handbook Working Group [Page 51]
RFC 11XX Security Policy Handbook MMMM 1990
house for host/user security problems and fixes, and works
with the DDN Network Security Officer. The SCC also
distributes the DDN Security Bulletin, which communicates
information on network and host security exposures, fixes,
and concerns to security and management personnel at DDN
facilities. It is available online, via kermit or anonymous
FTP, from the host NIC.DDN.MIL, in SCC:DDN-SECURITY-yy-
nn.TXT (where "yy" is the year and "nn" is the bulletin
number). The SCC provides immediate assistance with DDN-
related host security problems; call (800) 235-3155 (6:00
a.m. to 5:00 p.m. Pacific Time) or send email to
SCC@NIC.DDN.MIL. For 24 hour coverage, call the MILNET
Trouble Desk (800) 451-7413 or AUTOVON 231-1713.
3.9.7.3.3 NIST Computer Security Resource and Response Center
[DC]
The National Institute of Standards and Technology (NIST)
has responsibility within the U.S. Federal Government for
computer science and technology activities. NIST has played
a strong role in organizing the CERT System and is now
serving as the CERT System Secretariat. NIST also operates
a Computer Security Resource and Response Center (CSRC) to
provide help and information regarding computer security
events and incidents, as well as to raise awareness about
computer security vulnerabilities.
The CSRC team operates a 24-hour hotline, at (301) 975-5200.
For individuals with access to the Internet, on-line
publications and computer security information can be
obtained via anonymous FTP from the host CSRC.NCSL.NIST.GOV
(129.6.48.87). NIST also operates a personal computer
bulletin board that contains information regarding computer
viruses as well as other aspects of computer security. To
access this board, set your modem to 300/1200/2400 BPS, 1
stop bit, no parity, and 8-bit characters, and call (301)
948-5717. All users are given full access to the board
immediately upon registering.
NIST has produced several special publications related to
computer security and computer viruses in particular; some
of these publications are downloadable. For further
information, contact NIST at the following address:
Security Policy Handbook Working Group [Page 52]
RFC 11XX Security Policy Handbook MMMM 1990
Computer Security Resource and Response Center
A-216 Technology
Gaithersburg, MD 20899
Telephone: (301) 975-3359
Electronic Mail: CSRC@nist.gov
3.9.7.3.4 DOE Computer Incident Advisory Capability (CIAC) [DC]
CIAC is the Department of Energy's (DOE's) Computer Incident
Advisory Capability. CIAC is a four-person team of computer
scientists from Lawrence Livermore National Laboratory
(LLNL) charged with the primary responsibility of assisting
DOE sites faced with computer security incidents (e.g.,
intruder attacks, virus infections, worm attacks, etc.).
This capability is available to DOE sites on a 24-hour-a-day
basis.
CIAC was formed to provide a centralized response capability
(including technical assistance), to keep sites informed of
current events, to deal proactively with computer security
issues, and to maintain liaisons with other response teams
and agencies. CIAC's charter is to assist sites (direct
technical assistance, providing information, or referring
inquiries to other technical experts), serve as a
clearinghouse for information about threats/known
incidents/vulnerabilities, develop guidelines for incident
handling, develop software for responding to
events/incidents, analyze events and trends, conduct
training and awareness activities, and alert and advise
sites about vulnerabilities and potential attacks.
CIAC's business hours phone number is (415) 422-8193 or FTS
532-8193. CIAC's e-mail address is CIAC@TIGER.LLNL.GOV.
3.9.7.3.5 NASA Ames Computer Network Security Response Team
[DC]
The Computer Network Security Response Team (CNSRT) is NASA
Ames Research Center's local version of the DARPA CERT.
Formed in August of 1989, the team has a constituency that
is primarily Ames users, but it is also involved in
assisting other NASA Centers and federal agencies. CNSRT
maintains liaisons with the DOE's CIAC team and the DARPA
CERT. It is also a charter member of the CERT System. The
team may be reached by 24 hour pager at (415) 694-0571, or
by electronic mail to CNSRT@AMES.ARC.NASA.GOV.
------>*****[ I expect to have a list of more teams Real
Security Policy Handbook Working Group [Page 53]
RFC 11XX Security Policy Handbook MMMM 1990
Soon Now, but I probably won't have all the information by
Nov. 9th --dave]
3.9.7.4 DDN Management Bulletins [DC]
The DDN Management Bulletin is distributed electronically by
the DDN NIC under contract to the Defense Communications Agency
(DCA). It is a means of communicating official policy,
procedures, and other information of concern to management
personnel at DDN facilities.
The DDN Security Bulletin is distributed electronically by the
DDN SCC, also under contract to DCA, as a means of
communicating information on network and host security
exposures, fixes, and concerns to security and management
personnel at DDN facilities.
Anyone may join the mailing lists for these two bulletins by
sending a message to NIC@NIC.DDN.MIL and asking to be placed on
the mailing lists. These messages are also posted to the
USENET newsgroup "ddn.mgt-bulletin". For additional
information, see section 7.7.
3.9.7.5 System Administration Lists [DC]
The SYSADM-LIST is a list pertaining exclusively to UNIX system
administration. Mail requests to be added to the list to
SYSADM-LIST-REQUEST@SYSADMIN.COM.
*** Others?
3.9.7.6 Vendor Specific System Lists
The SUN-SPOTS and SUN-MANAGERS lists are discussion groups for
users and administrators of systems supplied by Sun
Microsystems. SUN-SPOTS is a fairly general list, discussing
everything from hardware configurations to simple UNIX
questions. To subscribe, send a message to SUN-SPOTS-
REQUEST@RICE.EDU. This list is also available in the USENET
newsgroup "comp.sys.sun". SUN-MANAGERS is a discussion list
for Sun system administrators and covers all aspects of Sun
system administration. To subscribe, send a message to SUN-
MANAGERS-REQUEST@EECS.NWU.EDU.
The APOLLO list discusses the HP/Apollo system and its
software. To subscribe, send a message to APOLLO-
REQUEST@UMIX.CC.UMICH.EDU. APOLLO-L is a similar list which
can be subscribed to by sending
Security Policy Handbook Working Group [Page 54]
RFC 11XX Security Policy Handbook MMMM 1990
SUB APOLLO-L your full name
to LISTSERV%UMRVMB.BITNET@VM1.NODAK.EDU.
HPMINI-L pertains to the Hewlett-Packard 9000 series and HP/UX
operating system. To subscribe, send
SUB HPMINI-L your full name
to LISTSERV%UAFSYSB.BITNET@VM1.NODAK.EDU.
INFO-IBMPC discusses IBM PCs and compatibles, as well as MS-
DOS. To subscribe, send a note to INFO-IBMPC-REQUEST@WSMR-
SIMTEL20.ARMY.MIL.
There are numerous other mailing lists for nearly every popular
computer or workstation in use today. For a complete list,
obtain the file "netinfo/interest-groups" via anonymous FTP
from the host FTP.NISC.SRI.COM.
3.9.7.7 Professional Societies and Journals [SK,DC]
The IEEE Technical Committee on Security & Privacy publishes a
quarterly magazine, "CIPHER".
IEEE Computer Society,
1730 Massachusetts Ave. N.W.
Washington, DC 2036-1903
The ACM SigSAC (Special Interest Group on Security, Audit, and
Controls) publishes a quarterly magazine, "SIGSAC Review".
Association for Computing Machinery
11 West 42nd St.
New York, N.Y. 10036
The Information Systems Security Association publishes a
quarterly magazine called "ISSA Access".
Information Systems Security Association
P.O. Box 9457
Newport Beach, CA 92658
"Computers and Security" is an "international journal for the
professional involved with computer security, audit and
control, and data integrity."
Security Policy Handbook Working Group [Page 55]
RFC 11XX Security Policy Handbook MMMM 1990
$266/year, 8 issues (1990)
Elsevier Advanced Technology
Journal Information Center
655 Avenue of the Americas
New York, NY 10010
The "Data Security Letter" is published "to help data security
professionals by providing inside information and knowledgable
analysis of developments in computer and communications
security."
$690/year, 9 issues (1990)
Data Security Letter
P.O. Box 1593
Palo Alto, CA 94302
3.9.8 Problem Reporting Tools
3.9.9 Auditing [SK]
Auditing is an important tool that can be used to enhance the
security of your installation. Not only does it give you a means
of identifying who has accessed your system (and maybe done
something to it) but it also gives you an indication of how your
system is being used (abused) by authorized users and attackers
alike. In addition, the audit trail traditionally kept by
computer systems can become an invaluable piece of evidence should
your system be penetrated.
3.9.9.1 Verify Security [SK]
An audit trail shows how the system is being used from day to
day. Depending upon how your site audit log is configured,
your log files should show a range of access attempts that can
show what normal system usage should look like. Deviation from
that normal usage could be the result of penetration from an
outside source using an old (stale) user account. Observing a
deviation in logins, for example, could be your first
indication that something unusual is happening.
3.9.9.2 Verify Software Configurations [SK]
One of the ruses used by attackers to gain access to a system
is by the insertion of a so-called Trojan Horse program. A
Trojan Horse program can be a program that does something
useful, or merely something interesting. It always does
Security Policy Handbook Working Group [Page 56]
RFC 11XX Security Policy Handbook MMMM 1990
something unexpected, like steal passwords or copy files
without your knowledge. Imagine a Trojan login program that
prompts for username and password in the usual way, but also
writes that information to a special file that the attacker can
come back and read at will. Imagine a Trojan Editor program
that, despite the file permissions you have given your files,
makes copies of everything in your directory space without you
knowing about it.
This points out the need for configuration management of the
software that runs on a system, not as it is being developed,
but as it is in actual operation. Techniques for doing this
range from checking each command every time it is executed
against some criteria (such as a cryptoseal, described above)
or merely checking the date/time stamp of the executable.
Another technique might be to check each command in batch mode
at midnight.
3.9.9.3 Tools [DC]
COPS is a security tool for system administrators that checks
for numerous common security problems on UNIX systems. COPS is
a collection of shell scripts and C programs that can easily be
run on almost any UNIX variant. Among other things, it checks
the following items and sends the results to the system
administrator:
- Checks "/dev/kmem" and other devices for world
read/writability.
- Checks special/important files and directories for
"bad" modes (world writable, etc.).
- Checks for easily guessed passwords.
- Checks for duplicate user ids, invalid fields in the
password file, etc.
- Checks for duplicate group ids, invalid fields in the
group file, etc.
- Checks all users' home directories and their ".cshrc",
".login", ".profile", and ".rhosts" files for security
problems.
- Checks all commands in the "/etc/rc" files and "cron"
files for world writability.
Security Policy Handbook Working Group [Page 57]
RFC 11XX Security Policy Handbook MMMM 1990
- Checks for bad "root" paths, NFS file systems exported
to the world, etc.
- Includes an expert system that checks to see if a given
user (usually "root") can be compromised, given that
certain rules are true.
- Checks for changes in the setuid status of programs on the
system.
The COPS package is available from the "comp.sources.unix"
archive on "ftp.uu.net", and also from the UNIX-SW repository
on the MILNET host "wsmr-simtel20.army.mil".
------>>>>>*** What else?
3.9.10 Communication Among Administrators
3.9.11 Secure Operating Systems [DC]
The following list of products and vendors is adapted from the
National Computer Security Center's (NCSC) Evaluated Products
List. They represent those companies who have either received an
evaluation from the NCSC or are in the process of a product
evaluation. This list is not complete, but it is representative
of those operating systems and add on components available in the
commercial marketplace.
For a more detailed listing of the current products appearing in
the NCSC EPL, contact the NCSC at:
National Computer Security Center
9800 Savage Road
Fort George G. Meade, MD 20755-6000
(301) 859-4458
Version Evaluation
Evaluated Product Vendor Evaluated Class
-----------------------------------------------------------------------
Secure Communications Honeywell Information 2.1 A1
Processor (SCOMP) Systems, Inc.
Multics Honeywell Information MR11.0 B2
Systems, Inc.
System V/MLS 1.1.2 on UNIX AT&T 1.1.2 B1
System V 3.1.1 on AT&T 3B2/500and 3B2/600
Security Policy Handbook Working Group [Page 58]
RFC 11XX Security Policy Handbook MMMM 1990
OS 1100 Unisys Corp. Security B1
Release 1
MPE V/E Hewlett-Packard Computer G.03.04 C2
Systems Division
AOS/VS on MV/ECLIPSE series Data General Corp. 7.60 C2
VM/SP or VM/SP HPO with CMS, IBM Corp. 5 C2
RACF, DIRMAINT, VMTAPE-MS,
ISPF
MVS/XA with RACF IBM Corp. 2.2,2.3 C2
AX/VMS Digital Equipment Corp. 4.3 C2
NOS Control Data Corp. NOS
Security C2
Eval Product
TOP SECRET CGA Software Products 3.0/163 C2
Group, Inc.
Access Control Facility 2 SKK, Inc. 3.1.3 C2
UTX/32S Gould, Inc. Computer 1.0 C2
Systems Division
A Series MCP/AS with Unisys Corp. 3.7 C2
InfoGuard Security
Enhancements
Primos Prime Computer, Inc. 21.0.1DODC2A C2
Resource Access Control IBM Corp. 1.5 C1
Facility (RACF)
Security Policy Handbook Working Group [Page 59]
RFC 11XX Security Policy Handbook MMMM 1990
Version Candidate
Candidate Product Vendor Evaluated Class
-----------------------------------------------------------------------
Boeing MLS LAN Boeing Aerospace A1 M1
Trusted XENIX Trusted Information
Systems, Inc. B2
VSLAN VERDIX Corp. B2
System V/MLS AT&T B1
VM/SP with RACF IBM Corp. 5/1.8.2 C2
Wang SVS/OS with CAP Wang Laboratories, Inc. 1.0 C2
3.9.12 Obtaining Fixes for Known Problems [SK]
It goes without saying that computer systems have bugs. Even
operating systems, upon which we depend for protection of our
data, has bugs. And since there are bugs, things can be broken,
both maliciously and accidentally. It is important that whenever
bugs are discovered, that a fix be found and implemented just as
soon as possible. This should minimize any exposure caused by the
bug in the first place.
Corallary to the bug problem is, from whom do I obtain the fixes?
Most systems have some support from the manufacturer or supplier.
Fixes coming from that source tend to be implemented quickly after
receipt. Fixes for some problems are often posted on the network
and are left to the system administrators to incorporate as they
can. The problem is that one wants to have faith that the fix
will close the hole and not introduce any others. We will tend to
trust that the manufacturer's fixes are better than those that are
posted on the net.
3.9.12.1 Sun Customer Warning System [DC]
Sun Microsystems has established a Customer Warning System
(CWS) for handling security incidents. This is a formal
process which includes:
- Having a well advertised point of contact in Sun
for reporting security problems.
- Pro-actively alerting customers of worms, viruses,
or other security holes that could affect their systems.
- Distributing the patch (and/or work-around) as quickly
as possible.
Security Policy Handbook Working Group [Page 60]
RFC 11XX Security Policy Handbook MMMM 1990
They have created an electronic mail address, SECURITY-
ALERT@SUN.COM, which will enable customers to report security
problems. A voice-mail backup is available at (415) 688-9081.
A "Security Contact" can be designated by each customer site;
this person will be contacted by Sun in case of any new
security problems. For more information, contact your Sun
representative.
3.9.13 Trusted Archive Servers [DC]
Several sites on the Internet maintain large repositories of
public-domain and freely distributable software, and make this
material available for anonymous FTP. This section describes some
of the larger repositories. Note that none of these servers
implements secure checksums, or anything else guaranteeing the
integrity of their data. Thus, the notion of "trust" should be
taken as a somewhat limited definition.
3.9.13.1 Sun Fixes on UUNET [DC]
Sun Microsystems has contracted with UUNET Communications
Services, Inc., to make fixes for bugs in Sun software
available via anonymous FTP. You can access these fixes by
using the "ftp" command to connect to the host FTP.UU.NET.
Then change into the directory "sun-dist/security", and obtain
a directory listing. The file "README" contains a brief
description of what each file in this directory contains, and
what is required to install the fix.
3.9.13.2 Berkeley Fixes [DC]
The University of California at Berkeley also makes fixes
available via anonymous FTP; these fixes pertain primarily to
the current release of BSD UNIX (currently, release 4.3).
However, even if you are not running their software, these
fixes are still important, since many vendors (Sun, DEC,
Sequent, etc.) base their software on the Berkeley releases.
The Berkeley fixes are available for anonymous FTP from the
host UCBARPA.BERKELEY.EDU in the directory "4.3/ucb-fixes".
The file "INDEX" in this directory describes what each file
contains. They are also available from UUNET (see section
3.9.13.3).
Berkeley also distributes new versions of "sendmail" and
"named" from this machine. New versions of these commands are
stored in the "4.3" directory, usually in the files
"sendmail.tar.Z" and "bind.tar.Z", respectively.
Security Policy Handbook Working Group [Page 61]
RFC 11XX Security Policy Handbook MMMM 1990
3.9.13.3 Simtel-20 and UUNET
The two largest general-purpose software repositories on the
Internet are the hosts WSMR-SIMTEL20.ARMY.MIL and FTP.UU.NET.
WSMR-SIMTEL20.ARMY.MIL is a TOPS-20 machine operated by the
U.S. Army at White Sands Missile Range (WSMR), New Mexico. The
directory "pd2:<unix-c>" contains a large amount of UNIX
software, primarily taken from the "comp.sources" newsgroups.
The directories "pd1:<msdos>" and "pd2:<msdos2>" contains
software for IBM PC systems, and "pd3:<macintosh>" contains
software for the Apple Macintosh.
FTP.UU.NET is operated by UUNET Communications Services, Inc.
in Falls Church, Virginia. This company sells Internet and
USENET access to sites all over the country (and
internationally). The software posted to the following USENET
source newsgroups is stored here, in directories of the same
name:
comp.sources.games
comp.sources.misc
comp.sources.sun
comp.sources.unix
comp.sources.x
Numerous other distributions, such as all the freely
distributable Berkeley UNIX source code, Internet Request for
Comments (RFCs), and so on are also stored on this machine.
3.9.13.4 Vendors [DC]
Many vendors make fixes for bugs in their software available
electronically, either via mailing lists or via anonymous FTP.
You should contact your vendor to find out if they offer this
service, and if so, how to access it. Some vendors that offer
these services include Sun Microsystems (see above), Digital
Equipment Corporation (DEC), the University of California at
Berkeley (see above), and Apple Computer. [5, CURRY]
=====
Section 4 - Draft: 9-Nov-90
Author: Tom Longstaff (longstaf@cheetah.llnl.gov)
4. Incident Handling
4.1 Overview
Security Policy Handbook Working Group [Page 62]
RFC 11XX Security Policy Handbook MMMM 1990
This section of the document will supply some guidance to be
applied when a computer security event is in progress on a
machine, network, site, or multi-site environment. The operative
philosophy in the event of a breach of computer security, whether
it be an external intruder attack or a disgruntled employee, is to
plan for adverse events in advance. There is no substitute for
creating contingency plans for the types of events described
above.
Traditional computer security, while quite important in the
overall site security plan, usually falls heavily on protecting
systems from attack, and perhaps monitoring systems to detect
attacks. Little attention is usually paid for how to actually
handle the attack when it occurs. The result is that when an
attack is in progress, many decisions are made in haste and can be
damaging to tracking down the source of the incident, collecting
evidence to be used in prosecution efforts, preparing for the
recovery of the system, and protecting the valuable data contained
on the system.
4.1.1 Have a Plan to Follow in Case of an Incident
Part of handling an incident is being prepared to respond
before the incident occurs. This includes establishing a
suitable level of protections, so that if the incident becomes
severe, the damage which can occur is limited. Protection
includes preparing incident handling guidelines or a
contingency response 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. Second, part of protection is
preparing a method of notification, so you will know who to
call and what everyone's phone number is. It is important, for
example, to conduct "dry runs," in which your computer security
personnel, system administrators, and managers simulate
handling an incident.
Learning to respond efficiently to an incident is important for
numerous reasons. The most important benefit is directly to
human beings--preventing loss of human life. Some computing
systems are life critical systems, systems on which human life
depends (e.g., by controlling some aspects of surgery in a
hospital or assisting air traffic controllers).
An important but often overlooked benefit is an economic one.
Having both technical and managerial personnel respond to an
incident requires considerable resources, resources which could
be utilized more profitably if an incident did not require
Security Policy Handbook Working Group [Page 63]
RFC 11XX Security Policy Handbook MMMM 1990
their services. If these personnel are trained to handle an
incident efficiently, less of their time is required to deal
with that incident.
A third benefit is protecting classified, sensitive, and/or
proprietary information. One of the major dangers of a
computer security incident is that information may be
irrecoverable. Efficient incident handling minimizes this
danger. When classified information is involved, other
government regulations may apply and must be integrated into
any plan for incident handling.
A fourth 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 and/or institutions may be sued because one of
their nodes was used to launch a network attack. In a similar
vein, people who develop patches or workarounds may be sued if
the patches or workarounds are ineffective, resulting in damage
to systems, or if the patches or workarounds themselves damage
systems. Knowing about operating system vulnerabilities and
patterns of attacks, then taking appropriate measures is
critical to circumventing possible legal problems.
4.1.2 Order of Discussion in this Session Suggests an Order for
a Plan
This chapter is arranged such that a list may be generated from
the Table of Contents to provide a starting point for creating
a policy for handling ongoing incidents. The main points to be
included in a policy for handling incidents are:
o Overview (what are the goals and objectives in handling the
incident).
o Evaluation (how serious is the incident).
o Notification (who should be notified about the incident).
o Response (what should the response to the incident be).
o Legal/Investigative (What are the legal implications of the
incident).
o Documentation Logs (what records should be kept during and
after the incident).
Each of these points is important in an overall plan for
Security Policy Handbook Working Group [Page 64]
RFC 11XX Security Policy Handbook MMMM 1990
handling incidents. The remainder of this chapter will detail
the issues involved in each of these topics, and provide some
guidance as to what should be included in a site policy for
handling incidents.
4.1.3 Possible Goals and Incentives for Efficient Incident
Handling
As in any set of pre-planned procedures, attention must be
placed on a set of goals to be obtained in handling an
incident. These goals will be placed in order of importance
depending on the site, but one such set of goals might be:
Assure integrity of (life) critical systems.
Maintain and restore data.
Maintain and restore service.
Figure out how it happened.
Avoid escalation and further incidents.
Avoid negative publicity.
Find out who did it.
Punish the attackers.
It is important to prioritize actions to be taken during an
incident well in advance of the time an incident occurs.
Sometimes an incident may be so complex that it is impossible
to do everything at once to respond to it; priorities are
essential. Although priorities will vary from organization-
to-organization and institution-to-institution, the following
suggested priorities serve as a starting point for defining an
organization/institution's response:
o Priority one -- protect human life and people's
safety; human life always has precedence over all
other considerations.
o Priority two -- protect classified and/or sensitive
data (as regulated by your site or by government
regulations).
o Priority three -- protect other data, including
proprietary, scientific, managerial and other data,
because loss of data is costly in terms of resources.
o 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.
Security Policy Handbook Working Group [Page 65]
RFC 11XX Security Policy Handbook MMMM 1990
o Priority five -- minimize disruption of computing
resources; it is better in many cases to shut a system
down or disconnect from a network than to risk damage
to data and/or systems.
An important implication for defining priorities is that once
human life and national security considerations have been
addressed, it is generally more important to save data than
system software and/or hardware. Although it is undesirable to
have any damage and/or loss during an incident, systems can be
replaced; the loss or compromise of data (especially classified
data), however, is usually not an acceptable outcome under any
circumstances.
Part of handling an incident is being prepared to respond
before the incident occurs. This includes establishing a
suitable level of protections, so that if the incident becomes
severe, the damage which can occur is limited. Protection
includes preparing incident handling guidelines or a
contingency response 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. Second, part of protection is
preparing a method of notification, so you will know who to
call and what everyone's phone number is. For example, every
member of DOE's CIAC Team carries a card with every other team
member's work and home phone numbers, as well as beeper numbers
(see section 3.9.7.3.4 for further information). Third, your
organization or site should establish backup procedures for
every machine and system. Having backups eliminates much of
the threat of even a severe incident, in that backups preclude
data loss. Fourth, you should set up secure systems. This
involves eliminating vulnerabilities, establishing an effective
password policy, and other procedures, all of which will be
explained later in this document. Finally, conducting training
activities is part of protection. It is important, for
example, to conduct "dry runs," in which your computer security
personnel, system administrators, and managers simulate
handling an incident.
4.2 Evaluation
4.2.1 Is It Real?
This stage involves determining exactly what the problem is. Of
course, many if not most signs often associated with virus
infections, system intrusions, etc., are simply anomalies, such as
hardware failures. To assist in identifying whether there really
Security Policy Handbook Working Group [Page 66]
RFC 11XX Security Policy Handbook MMMM 1990
is an incident, it is usually helpful to obtain and use any
detection software which may be available. For example, widely
available software packages can greatly assist someone who thinks
there may be a virus in a Macintosh computer. Audit information
is also extremely useful, especially in determining whether there
is a network attack. It is extremely important to obtain a system
snapshot as soon as one suspects that something is wrong. Many
incidents cause a dynamic chain of events to occur, and an initial
system snapshot may do more good in identifying the problem and
any source of attack than most other actions which can be taken at
this stage. Finally, it is important to start a log book.
Recording system events, telephone conversations, time stamps,
etc., can lead to a more rapid and systematic identification of
the problem, and is the basis for subsequent stages of incident
handling.
There are certain indications or "symptoms" of an incident which
deserve special attention:
o System crashes.
o New user accounts (e.g., the account RUMPLESTILTSKIN
has unexplainedly been created), or high activity on
an account that has had virtually no activity for
months.
o New files (usually with novel or strange file names,
such as data.xx or k)
o Accounting discrepancies (e.g., in a UNIX system you
might notice that the accounting file called
/usr/admin/lastlog has shrunk, something that should
make you very suspicious that there may be an
intruder).
o Changes in file lengths or dates (e.g., a user should
be suspicious if he/she observes that the .EXE files in
an MS DOS computer have unexplainedly grown
by over 1800 bytes).
o Attempts to write to system (e.g., a system manager
notices that a privileged user in a VMS system is
attempting to alter RIGHTSLIST.DAT).
o Data modification or deletion (e.g., files start to
disappear).
o Denial of service (e.g., a system manager and all
Security Policy Handbook Working Group [Page 67]
RFC 11XX Security Policy Handbook MMMM 1990
other users become locked out of a UNIX system, which
has been changed to single user mode).
o Unexplained, poor system performance (e.g., system
response time becomes unusually slow).
o Anomalies (e.g., "GOTCHA" is displayed on a display
terminal or there are frequent, unexplained "beeps").
o Suspicious probes (e.g., there are numerous
unsuccessful login attempts from another node).
o Suspicious browsing (e.g., someone becomes a root user
on a UNIX system and accesses file after file in one
user's account, then another's).
None of these indications is absolute "proof" that an incident is
occurring, nor are all of these indications normally observed when
an incident occurs. If you observe any of these indications,
however, it is important to suspect that an incident might be
occurring, and act accordingly. There is no formula for
determining with 100 percent accuracy that an incident is
occurring (possible exception: when a virus detection package
indicates that your machine has the nVIR virus and you confirm
this by examining contents of the nVIR resource in your Macintosh
computer, you can be very certain that your machine is infected).
It is best at this point to collaborate with other technical and
computer security personnel to make a corporate decision about
whether an incident is occurring.
4.2.2 Scope
Along with the identification of the incident is the evaluation of
the scope and impact of the problem. It is important to correctly
identify the boundaries of the incident in order to effectively
deal with it. In addition, the impact of an incident will
determine its priority in allocating resources to deal with the
event. Without an indication of the scope and impact of the
event, it is difficult to determine a correct response.
In order to identify the scope and impact, a set of criteria
should be defined, appropriate to the site and to the type of
connections available. Some of the issues are:
o Is this a multi-site incident?
o Are many computers at your site effected by this
incident?
o Is sensitive information involved?
Security Policy Handbook Working Group [Page 68]
RFC 11XX Security Policy Handbook MMMM 1990
o What is the entry point of the incident (network,
phoneline, local terminal, etc.)?
o Is the press involved?
o What is the potential damage of the incident?
o What is the estimated time to close out the incident?
o What resources could be required to handle the incident?
4.3 Possible Types of Notification
When you have confirmed that an incident is occurring, the
appropriate personnel must be notified. Who and how this
notification is achieved is very important in keeping the event under
control both from a technical and emotional standpoint.
4.3.1 Explicit
First of all, any notification to either local or off-site
personnel must be explicit. This requires that any statement (be
it an electronic mail message, phone call, or fax) provides
information about the incident that is clear, concise, and fully
qualified. When you are notifying others that will help you to
handle an event, a "smoke screen" will only divide the effort and
create confusion. If a division of labor is suggested, it is
helpful to provide information to each section about what is being
accomplished in other efforts. This will not only reduce
duplication of effort, but allow people working on parts of the
problem to know where to obtain other information that would help
them resolve a part of the incident.
4.3.2 Factual
Another important consideration when communicating about the
incident is to be factual. Attempting to hide aspects of the
incident by providing false or incomplete information may not only
prevent a successful resolution to the incident, but may even
worsen the situation. This is especially true when the press is
involved. When an incident severe enough to gain press attention
is ongoing, it is likely that any false information you provide
will not be substantiated by other sources. This will reflect
badly on the site and may create enough ill-will between the site
and the press to damage the site's public relations.
4.3.3 Choice of Language
The choice of language used when notifying people about the
incident can have a profound effect on the way that information is
received. When you use emotional or inflammatory terms, you raise
the expectations of damage and negative outcomes of the incident.
Security Policy Handbook Working Group [Page 69]
RFC 11XX Security Policy Handbook MMMM 1990
It is important to remain calm both in written and spoken
notifications.
Another issue associated with the choice of language is the
notification to non-technical or off-site personnel. It is
important to accurately describe the incident without undue alarm
or confusing messages. While it is more difficult to describe the
incident to a non-technical audience, it is often more important.
A non-technical description may be required for upper-level
management, the press, or law enforcement liaisons. The
importance of these notifications cannot be underestimated and may
make the difference between handling the incident properly and
escalating to some higher level of damage.
4.3.4 Notification of:
o Point of Contact (POC) people (Technical, Administrative,
Response Teams, Investigative, Legal, Vendors, Service
providers), and which POCs are visible to whom.
o Wider community (users).
o Other sites that might be affected.
Finally, there is the question of who should be notified during
and after the incident. There are several classes of individuals
that need to be considered for notification. These are the
technical personnel, administration, appropriate response teams
(such as CERT or CIAC), law enforcement, vendors, and other
service providers. These issues are important for the central
point of contact, since that is the person responsible for the
actual notification of others (see section 4.3.6 for further
information). A list of people in each of these categories is an
important time saver for the POC during an incident. It is much
more difficult to find an appropriate person during an incident
when many urgent events are ongoing.
In addition to the people responsible for handling part of the
incident, there may be other sites affected by the incident (or
perhaps simply at risk from the incident). A wider community of
users may also benefit from knowledge of the incident. Often, a
report of the incident once it is closed out is appropriate for
publication to the wider user community.
4.3.5 Public Relations - Press Releases
One of the most important issues to consider is when, who, and how
much to release to the general public through the press. There
are many issues to consider when deciding this particular issue.
First and foremost, if a public relations office exists for the
Security Policy Handbook Working Group [Page 70]
RFC 11XX Security Policy Handbook MMMM 1990
site, it is important to use this office as liaison to the press.
The public relations office is trained in the type and wording of
information released, and will help to assure that the image of
the site is protected during and after the incident (if possible).
A public relations office has the advantage that you can
communicate candidly with them, and provide a buffer between the
constant press attention and the need of the POC to maintain
control over the incident.
If a public relations office is not available, the information
released to the press must be carefully considered. If the
information is sensitive, it may be advantageous to provide only
minimal or overview information to the press. It is quite
possible that any information provided to the press will be
quickly reviewed by the perpetrator of the incident. As a
contrast to this consideration, it was discussed above that
misleading the press can often backfire and cause more damage than
releasing sensitive information.
While it is difficult to determine in advance what level of detail
to provide to the press, some guideline to keep in mind are:
o Keep the technical level of detail low. Detailed
information about the incident may provide enough
information for copy-cat events or even damage the
site's ability to prosecute once the event is over.
o Keep the speculation out of press statements.
Speculation of who is causing the incident or the
motives are very likely to be in error and may cause
an inflamed view of the incident.
o Work with law enforcement professionals to assure that
evidence is protected. If prosecution is involved,
assure that the evidence collected is not divulged to
the press.
o Try not to be forced into a press interview before you are
prepared. The popular press is famous for the "2am"
interview, where the hope is to catch the interviewee off
guard and obtain information otherwise not available.
o 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.
Security Policy Handbook Working Group [Page 71]
RFC 11XX Security Policy Handbook MMMM 1990
4.3.6 Who Needs to Get Involved?
There now exists a number of incident response teams (IRTs) such
as the CERT and the CIAC. (See sections 3.9.7.3.1 and 3.9.7.3.4.)
Teams exists for many major government agencies and large
corporations. If such a team is available for your site, the
notification of this team should be of primary importance during
the early stages of an incident. These teams are responsible for
coordinating computer security incidents over a range of sites and
larger entities. Even if the incident is believed to be contained
to a single site, it is possible that the information available
through a response team could help in closing out the incident.
In setting up a site policy for incident handling, it may be
desirable to create an incident handling team (IHT), 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 IHTs.
Once an incident is under way, it is difficult to open a trusted
dialogue between other IHTs if none has existed before.
4.4 Response
A major topic still untouched here is how to actually respond to
an event. The response to an event will fall into the general
categories of containment, erradication, recovery, and follow-up.
Each of these stages will be described in more detail below.
Containment
The purpose of containment is to limit the extent of an attack.
For example, it is important to limit the spread of a worm
attack on a network as quickly as possible. An essential part
of containment is decision making (i.e., determining whether to
shut a system down, to disconnect from a network, to monitor
system or network activity, to set traps, to disable functions
such as remote file transfer on a UNIX system, etc.).
Sometimes this decision is trivial; shut the system down if the
system is classified or sensitive, or if proprietary
information is at risk! In other cases, it is worthwhile to
risk having some damage to the system if keeping the system up
might enable you to identify an intruder.
The third stage, containment, 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
Security Policy Handbook Working Group [Page 72]
RFC 11XX Security Policy Handbook MMMM 1990
accordingly. Finally, notification of cognizant authorities
should occur during this stage.
Eradication
Once an incident has been detected, it is important to first
think about containing the incident. Once the incident has
been contained, it is now time to eradicate the cause.
Software may be available to help you in this effort. For
example, eradication software is available to eliminate most
viruses which infect small systems. If any bogus files have
been created, it is time to delete them at this point. In the
case of virus infections, it is important to clean and reformat
any disks containing infected files. (Important note: if a
classified system has been infected with a virus, it is
essential to follow guidance issued by the DOE Office of
Safeguards and Security. We also strongly advise in this case
that a low-level format be performed to ensure the integrity of
classified information.) Finally, ensure that all backups are
clean. Many systems infected with viruses become periodically
reinfected simply because people do not systematically
eradicate the virus from backups.
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 the case of a network-
based attack, it is important to install patches for any
operating system vulnerability which was exploited. Again,
there is special guidance for recovery in classified computing
systems from the DOE Office of Safeguards and Security. [can we
get a pointer to this?? --jkrey]
Follow-up
One of the most important stages of responding to incidents is
also the most often omitted---the follow-up stage. This stage
is important because it helps those involved in handling the
incident develop a set of "lessons learned" (see section 5.3)
to improve future performance in such situations. This stage
also provides information which justifies an organization's
computer security effort to management, and yields information
which may be essential in legal proceedings.
The most important element of the follow-up stage is performing
a postmortem analysis. Exactly what happened, and at what
times? How well did the staff involved in dealing with the
Security Policy Handbook Working Group [Page 73]
RFC 11XX Security Policy Handbook MMMM 1990
incident do? What kind of information did the staff need
quickly, and how could they have gotten that information as
soon as possible? What would the staff do differently next
time? A follow-up report is valuable in that it provides a
reference to be used in case of other, similar incidents.
Creating a formal chronology of events (including time stamps)
is also important for legal reasons. Similarly, it is also
important to as quickly as possible obtain a monetary estimate
of the amount of damage the incident caused in terms of any
loss of software and files, hardware damage, and manpower costs
to restore altered files, reconfigure affected systems, and so
forth. This estimate may become the basis for subsequent
prosecution activity by the FBI, the U.S. Attorney General's
Office, etc.
4.4.1 What Will You Do?
o Restore control.
o Relates to policy.
o Which level of service is needed?
o Monitor activity.
o Constrain or shut down system.
4.4.2 Consider Designating a "Single Point of Contact"
When an incident is under way, a major issue is deciding who is in
charge of coordinating the activity of the multitude of players.
A major mistake that can be made is to have a number of "points of
contact" (POC) that are not pulling their efforts together. This
will only add to the confusion of the event, and will probably
lead to additional confusion and wasted or ineffective effort.
The single point of contact may or may not be the person "in
charge" of the incident. There are two distinct rolls to fill
when deciding who shall be the point of contact and the person in
charge of the incident. The person in charge will make decisions
as to the interpretation of policy applied to the event. The
responsibility for the handling of the event falls onto this
person. In contrast, the point of contact must coordinate the
effort of all the parties involved with handling the event.
The point of contact must be a person with the technical expertise
to successfully coordinate the effort of the system managers and
users involved in monitoring and reacting to the attack. Often
the management structure of a site is such that the administrator
of a set of resources is not a technically competent person with
regards to handling the details of the operations of the
computers, but is ultimately responsible for the use of these
Security Policy Handbook Working Group [Page 74]
RFC 11XX Security Policy Handbook MMMM 1990
resources.
Another important function of the POC is to maintain contact with
law enforcement and other external agencies (such as the CIA, DoD,
U.S. Army, or others) to assure that multi-agency involvement
occurs.
Finally, if legal action in the form of prosecution is involved,
the POC may be able to speak for the site in court. The
alternative is to have multiple witnesses that will be hard to
coordinate in a legal sense, and will weaken any case against the
attackers. A single POC may also be the single person in charge
of evidence collected, which will keep the number of people
accounting for evidence to a minimum. As a rule of thumb, the
more people that touch a potential piece of evidence, the better
the possibility that it will be inadmissible in court. The
section below (Legal/Investigative) will provide more details for
consideration on this topic.
4.5 Legal/Investigative
4.5.1 Establishing Contacts with Investigative Agencies
It is important to establish contacts with personnel from
investigative agencies such as the FBI and U.S. Attorney General's
Office as soon as possible, for several reasons. A primary reason
is that once a major attack is in progress, there is little time
to call various personnel in these agencies to determine exactly
who the correct point of contact is. Another reason is that it is
important to cooperate with these agencies in a manner that will
foster a good working relationship, and that will be in accordance
with the working procedures of these agencies. Knowing the
working procedures in advance and the expectations of your point
of contact is a big step in this direction. For example, it is
important to gather evidence that will be admissible in a court of
law. If you don't know in advance how to gather admissible
evidence, your efforts to collect evidence during an incident are
likely to be of no value to the investigative agency with which
you deal. A final reason for establishing contacts as soon as
possible is that it is impossible to know the particular agency
that will assume jurisdiction in any given incident. The FBI, for
example, may not get involved when there are intrusions believed
to be originating from another country--some other agency such as
the Secret Service may, however. Making contacts and finding the
proper channels early will make responding to an incident go
considerably more smoothly.
If your organization or site has a legal counsel, you need to
Security Policy Handbook Working Group [Page 75]
RFC 11XX Security Policy Handbook MMMM 1990
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/exposure to cooperate with legal
prosecution efforts.
2. Downstream liability--if you leave a compromised system
on to monitor 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 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.
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 that results in efficient division of labor.
Another result is that you are likely to obtain guidance that will
help you avoid 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.
4.5.2 Formal and Informal Legal Procedures
One of the most important considerations in dealing with
investigative agencies is verifying that the person who calls
asking for information is a legitimate representative from the
agency in question. Unfortunately, many well intentioned people
Security Policy Handbook Working Group [Page 76]
RFC 11XX Security Policy Handbook MMMM 1990
have unknowingly leaked sensitive information about incidents,
allowed unauthorized people into their systems, etc., because a
caller has masqueraded as an FBI or Secret Service agent. A
similar consideration is using a secure means of communication.
Because many network attackers can easily reroute electronic mail,
avoid using electronic mail to communicate with other agencies (as
well as others dealing with the incident at hand). Non-secured
phone lines (e.g., the phones normally used in the business world)
are also frequent targets for tapping by network intruders, so be
careful!
There is no established set of rules for responding to an incident
when the U.S. Federal Government becomes involved. Except by
court order, no agency can force you to monitor, to disconnect
from the network, to avoid telephone contact with the suspected
attackers, etc. It is wisest, however, to comply with whatever
requests the agency may make of you. The particular agency
involved may ask you to leave an attacked machine on and to
monitor activity on this machine, for example. Your complying
with this request will ensure continued cooperation of the
agency--usually the best route towards finding the source of the
network attacks and, ultimately, terminating these attacks.
Additionally, you may need some information or a favor from the
agency involved in the incident. You are likely to get what you
need only if you have been cooperative. Of particular importance
is avoiding unnecessary or unauthorized disclosure of information
about the incident, including any information furnished by the
agency involved. The trust between your site and the agency
hinges upon your ability to avoid compromising the case the agency
will build; keeping "tight lipped" is imperative.
Sometimes your needs and the needs of an investigative agency will
differ. Your site may want to get back to normal business by
closing an attack route, but the investigative agency may want you
to keep this route open. Similarly, your site may want to close
an attacked system down to avoid the possibility of negative
publicity, but again the investigative agency may want you to
continue monitoring. When there is such a conflict, there may be
a complex set of tradeoffs (e.g., interests of your site's
management, amount of resources you can devote to the problem,
jurisdictional boundaries, etc.). An important guiding principle
is related to what might be called "Internet citizenship" [22,
IAB89] and its responsibilities. Your site can shut a system
down, and this will relieve you of the stress, resource demands,
and danger of negative exposure. The attacker, however, is likely
to simply move on to another system, temporarily leaving others
blind to the attacker's intention and actions until another path
of attack can be detected. Providing that there is no damage to
Security Policy Handbook Working Group [Page 77]
RFC 11XX Security Policy Handbook MMMM 1990
your systems and others, the most responsible course of action is
to cooperate with the participating agency by leaving your
compromised system on. This will allow monitoring (and,
ultimately, the possibility of terminating the source of the
threat to systems just like yours). On the other hand, if there
is damage to computers illegally accessed through your system, the
most responsible course of action may be to turn your system off,
even if the agency involved wants you to leave the system on.
Complicating the issue of network responsibility is the
consideration that if you do not cooperate with the agency
involved, you will be less likely to receive help from that agency
in the future.
4.6 Documentation Logs
When you respond to an incident, document all details related to the
incident. Your doing this will provide valuable information to
yourself and others as you try to unravel the course of events.
Documenting all details will ultimately save you time. If you don't
document every relevant phone call, for example, you are likely to
forget a good portion of information you obtain, requiring you to
contact the source of information once again. This wastes yours and
others' time, something you can ill afford. At the same time,
recording details will provide evidence for prosecution efforts,
providing the case moves in this direction. Documenting an incident
also will help you perform a final assessment of damage (something
your management as well as law enforcement officers will want to
know), and will provide the basis for a follow-up analysis in which
you can engage in a valuable "lessons learned" exercise.
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:
o All system events (audit records).
o All actions you take (time tagged).
o All phone conversations (including the person with whom
you talked, the date and time, and the content of the
conversation).
The most straightforward way to maintain documentation is keeping a
log book. This allows you to go to a centralized, chronological
source of information when you need it, instead of requiring you to
page through individual sheets of paper. Much of this information is
potential evidence in a court of law. Thus, when you initially
suspect that an incident will result in prosecution or when an
investigative agency becomes involved, you need to regularly (e.g.,
Security Policy Handbook Working Group [Page 78]
RFC 11XX Security Policy Handbook MMMM 1990
every day) turn in photocopied, signed copies of your logbook (as
well as media you use to record system events) to a document
custodian who can store these copied pages in a secure place (e.g., a
safe). When you submit information for storage, you should in return
receive a signed, dated receipt from the document custodian. Failure
to observe these procedures can result in invalidation of any
evidence you obtain in a court of law.
=====
Section 5 - Draft: July 29, 1990
Authors: Jim Duncan (jim@math.psu.edu), Frank Byrum
(byrum@decuac.dec.com).
5. Establishing Post-Incident Procedures
5.1 Overview
In the wake of an incident (or perhaps while the incident continues),
several actions should take place. These actions can be condensed to
the following:
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, [We currently have no bullet for risk analysis; I
suggest we add one. Jim]
4. and an investigation and prosecution of the individuals
who caused the incident should commence, if it is
deemed desirable.
All four steps shall provide feedback to the site security policy
committee, leading to prompt re-evaluation and amendment of the
current policy.
5.2 Removing Vulnerabilities
Removing all vulnerabilities once an incident has occurred is
difficult. The key to removing vulnerabilities is knowledge and
understanding of the breach. In some cases, it is prudent to remove
Security Policy Handbook Working Group [Page 79]
RFC 11XX Security Policy Handbook MMMM 1990
all access or functionality as soon as possible, and then restore
normal operation in limited stages. Bear in mind that removing all
access while an incident is in progress will obviously notify all
users, including the alleged problem users, that the administrators
are aware of a problem; this may have a deleterious effect on an
investigation. However, allowing an incident to continue may also
open the likelihood of greater damage, loss, aggravation, or
liability (civil or criminal).
If it is determined that the breach occurred due to a flaw in the
systems' hardware or software, the vendor (or supplier) and the CERT
should be notified as soon as possible. Including relevant telephone
numbers (also electronic mail addresses and fax numbers) in the site
security policy is strongly recommended. To aid prompt
acknowledgement and understanding of the problem, the flaw should be
described in as much detail as possible, including details about how
to exploit the flaw.
As soon as the breach has occurred, the entire system and all its
components should be considered suspect. System software is the most
probable target. Preparation is key to recovering from a possibly
tainted system. This includes checksumming all tapes from the vendor
using a checksum algorithm which (hopefully) is invertible [10].
(See sections 3.9.4.1, 3.9.4.2.) Assuming original vendor
distribution tapes are available, an analysis of all system files
should commence, and any irregularities should be noted and referred
to all parties involved in handling the incident. It can be very
difficult, in some cases, to decide which backup tapes to recover
from; consider that the incident may have continued for months or
years before discovery, and that the suspect may be an employee of
the site, or otherwise have intimate knowledge or access to the
systems. In all cases, the pre-incident preparation will determine
what recovery is possible. Many sites have poor, if any, backup
procedures. At worst case, restoration from the original
manufactures' media and a re-installation of the systems will be the
most prudent solution.
Review the lessons learned from the incident and always update the
policy and procedures to reflect changes necessitated by the
incident.
5.2.1 Assessing Damage
Before cleanup can begin, the actual system damage must be
discerned. This can be quite time consuming, but should lead into
some of the insight as to the nature of the incident, and aid
investigation and prosecution. It is best to compare previous
backups or original tapes when possible; advance preparation is
Security Policy Handbook Working Group [Page 80]
RFC 11XX Security Policy Handbook MMMM 1990
the key. 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.
5.2.2 Cleanup
Once the damage has been assessed, it is necessary to develop a
plan for system cleanup. In general, bring up services in the
order of demand to allow minimum uses inconvenience is the best
practice. Understand that the proper recovery procedures for the
system is extremely important and should be site specific.
It may be necessary to go back to the original distributed tapes
and recustomize the system. To facilitate this worst case
scenario, a record of the original systems setup and each
customization change should be kept current with each change to
the system.
5.2.3 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. In the follow up stage, the system should
be monitored for items that may have been missed during the
cleanup stage. It would be prudent to utilize some of the tools
mentioned in section 3.9.9.3 (e.g., COPS) as a start. Remember,
these tools don't replace continual system monitoring and good
systems administration procedures.
5.2.4 Keep a Security Log
As discussed in section 4.6, a security log can be most valuable
during this phase of removing vulnerabilities. There are two
considerations here, the first is to keep logs of the procedures
that have been used to make the system secure again. This should
include command procedures (e.g., shell scripts) that can be run
on a periodic basis to recheck the security. Second, keep logs of
important systems events. These can be referenced when trying to
determine the extent of the damage of a given incident.
Security Policy Handbook Working Group [Page 81]
RFC 11XX Security Policy Handbook MMMM 1990
5.3 Capturing Lessons Learned
5.3.1 Understand the Lesson
After an incident, it is prudent to write a report describing the
incident, method of discovery, correction procedure, monitoring
procedure, and summary of lesson learned. This will aid in the
clear understanding of the problem. Remember, it is difficult to
learn from an incident, if you don't understand the source.
5.3.2 Resources
5.3.2.1 Other Security Devices, Methods
Security is a dynamic, not static process. Sites are dependent
on the nature of security available at each site, and the array
of devices and methods that will help promote security.
Keeping up with the security area of the computer industry and
their methods will assure a security manager of taking
advantage of the latest technology.
5.3.2.2 Repository of Books, Lists, Information Sources
Keep an on site collection of books, lists, information
sources, etc., as guides and references for securing the
system. Keep this collection up to date. Remember, as systems
change, so do security methods and problems.
5.3.2.3 Form a Subgroup
Form a subgroup of system administration personnel that will be
the core security staff. This will allow discussions of
security problems and multiple views of the site's security
issues. This subgroup can also act to develop the site
security policy and make suggested changes as necessary to
ensure site security.
5.4 Upgrading Policies and Procedures
5.4.1 Establish Mechanisms for Updating Policies and Procedures,
Tools
If an incident is based on poor policy, and unless the policy is
changed, then one is doomed to repeat the past. Once an incident
has been recovered from, 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
Security Policy Handbook Working Group [Page 82]
RFC 11XX Security Policy Handbook MMMM 1990
today's dynamic changing computing environments.
5.4.2 Problem Reporting Procedures
A problem reporting procedure should be implemented to describe,
in detail, the incident and the solutions to the incident. Each
incident should be reviewed by the site security subgroup to allow
understanding of the incident with possible suggestions to the
site policy and procedures.
=====
6. References
[1] Quarterman, J., "The Matrix: Computer Networks and Conferencing
Systems Worldwide", Pg. 278, Digital Press, Bedford, MA, 1990.
[2] Brand, R., "Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery", R. Brand,
available on-line from: cert.sei.cmu.edu:/pub/info/primer, 8 June
1990.
[3] Fites, M., Kratz, P. and A. Brebner, "Control and Security of
Computer Information Systems", Computer Science Press, 1989.
[4] Johnson, D., and J. Podesta, "Formulating a Company Policy on
Access to and Use and Disclosure of Electronic Mail on Company
Computer Systems", Available from: The Electronic Mail
Association (EMA) 1555 Wilson Blvd, Suite 555, Arlington VA
22209, (703) 522-7111, 22 October 1990.
[5] Curry, D., "Improving the Security of Your UNIX System", SRI
International Report ITSTD-721-FR-90-21, April 1990.
[6] Cheswick, B., "The Design of a Secure Internet Gateway",
Proceedings of the Summer Usenix Conference, Anaheim, CA, June
1990.
[7] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
I -- Message Encipherment and Authentication Procedures", RFC
1113, IAB Privacy Task Force, August 1989.
[8] Kent, S., and J. Linn, "Privacy Enhancement for Internet
Electronic Mail: Part II -- Certificate-Based Key Management",
RFC 1114, IAB Privacy Task Force, August 1989.
[9] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
III -- Algorithms, Modes, and Identifiers", RFC 1115, IAB Privacy
Security Policy Handbook Working Group [Page 83]
RFC 11XX Security Policy Handbook MMMM 1990
Task Force, August 1989.
[10] Merkle, R., "A Fast Software One Way Hash Function", Journal of
Cryptology, Vol. 3, No. 1.
[11] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
Specification", RFC 791, DARPA, September 1981.
[12] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, DARPA, September 1981.
[13] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, 28 August 1980.
[14] Mogul, J., "Simple and Flexible Datagram Access Controls for
UNIX-based Gateways", Digital Western Research Laboratory
Research Report 89/4, March 1989.
[15] Bellovin, S., and M. Merritt, "Limitations of the Kerberos
Authentication System", Computer Communications Review, October
1990.
[16] Pfleeger, C., "Security in Computing", Prentice-Hall, Englewood
Cliffs, N.J., 1989.
[17] Parker, D., Swope, S., and B. Baker, "Ethical Conflicts:
Information and Computer Science, Technology and Business", QED
Information Sciences, Inc., Wellesley, MA.
[18] Forester, T., and P. Morrison, "Computer Ethics: Tales and
Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990.
[19] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC
854, USC/Information Sciences Institute, May 1983.
[20] Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959,
USC/Information Sciences Institute, October 1985.
[21] Postel, J., Editor, "IAB Official Protocol Standards", RFC 1140,
IAB, May 1990.
[22] Internet Activities Board, "Ethics and the Internet", RFC 1087,
Internet Activities Board, January 1989.
Security Policy Handbook Working Group [Page 84]
RFC 11XX Security Policy Handbook MMMM 1990
7. Annotated Bibliography - DRAFT - 19-Nov-90
The intent of this annotated bibliography is to offer a
representative collection of resources of information that will help
the user of this handbook. It is meant provide a starting point for
further research in the security area. Included are references to
other sources of information for those who wish to pursue issues of
the computer security environment.
7.1 Computer Law
[ABA89]
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.
[BENDER]
Bender, D., "Computer Law: Evidence and Procedure",
M. Bender, New York, NY, 1978-present.
Kept up to date with supplements.
Years covering 1978-1984 focuses on: Computer law,
evidence and procedures. The years 1984 to the current
focus on: general computer law. Bibliographical
references and index included.
[BLOOMBECKER]
Bloombecker, B., "Spectacular Computer Crimes", Dow Jones-
Irwin, Homewood, Ill. 1990.
[CCH]
Commerce Clearing House, "Guide to Computer Law", (Topical
Law Reports), Chicago, Ill., 1989.
Court cases and decisions rendered by federal and state
courts throughout the United States on federal and state
computer law. Includes Case Table and Topical Index.
[CONLY]
Conly, C., "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, D.C., July 1989.
[FENWICK]
Fenwick, W., Chair, "Computer Litigation, 1985: Trial
Tactics and Techniques", Litigation Course Handbook
Security Policy Handbook Working Group [Page 85]
RFC 11XX Security Policy Handbook MMMM 1990
Series No. 280, Prepared for distribution at the
Computer Litigation, 1985: Trial Tactics and
Techniques Program, February-March 1985.
[GEMIGNANI]
Gemignani, M., "Viruses and Criminal Law", Communications
of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.
[HUBAND]
Huband, F., 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.
[MCEWEN]
McEwen, J., "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, D.C., 1989.
[PARKER]
Parker, D., "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.
[SHAW]
Shaw, E., Jr., "Computer Fraud and Abuse Act of 1986,
Congressional Record (3 June 1986), Washington, D.C.,
3 June 1986.
[TRIBLE]
Trible, P., "The Computer Fraud and Abuse Act of 1986",
U.S. Senate Committee on the Judiciary, 1986.
7.2 Computer Security
[CAELLI]
Caelli, W., Editor, "Computer Security in the Age of
Information", Proceedings of the Fifth IFIP International
Conference on Computer Security, IFIP/Sec '88.
[CARROLL]
Carroll, J., "Computer Security", 2nd Edition, Butterworth
Publishers, Stoneham, MA, 1987.
Security Policy Handbook Working Group [Page 86]
RFC 11XX Security Policy Handbook MMMM 1990
[COOPER]
Cooper, J., "Computer and Communications Security:
Strategies for the 1990s", McGraw-Hill, 1989.
[BRAND]
Brand, R., "Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery",
R. Brand, 8 June 1990.
As computer security becomes a more important issue in
modern society, it begins to warrant a systematic approach.
The vast majority of the computer security problems and the
costs associated with them can be prevented with simple
inexpensive measures. The most important and cost
effective of these measures are available in the prevention
and planning phases. These methods are presented in this
paper, followed by a simplified guide to incident
handling and recovery. Available on-line from:
cert.sei.cmu.edu:/pub/info/primer.
[CHESWICK]
Cheswick, B., "The Design of a Secure Internet Gateway",
Proceedings of the Summer Usenix Conference, Anaheim, CA,
June 1990.
Brief abstract (slight paraphrase from the original
abstract): AT&T maintains a large internal Internet that
needs to be protected from outside attacks, while
providing useful services between the two.
This paper describes AT&T's Internet gateway. This
gateway passes mail any many of the common Internet
services between AT&T internal machines and the Internet.
This is accomplished without IP connectivity using a pair
of machines: a trusted internal machine and an untrusted
external gateway. These are connected by a private link.
The internal machine provides a few carefully-guarded
services to the external gateway. This configuration
helps protect the internal internet even if the external
machine is fully compromised.
Holbrook's comments: This is a very useful and
interesting design. Most firewall gateway systems rely
on a system that, if compromised, could allow access to
the machines behind the firewall. Also, most
firewall systems require users who want access to
Internet services to have accounts on the firewall
machine. AT&T's design allows AT&T internal internet
users access to the standard services of TELNET and
Security Policy Handbook Working Group [Page 87]
RFC 11XX Security Policy Handbook MMMM 1990
FTP from their own workstations without accounts on
the firewall machine. A very useful paper that shows
how to maintain some of the benefits of Internet
connectivity while still maintaining strong
security.
[CURRY]
Curry, D., "Improving the Security of Your UNIX System",
SRI International Report ITSTD-721-FR-90-21, April 1990.
This paper describes measures that you, as a system
administrator can take to make your UNIX system(s) more
secure. Oriented primarily at SunOS 4.x, most of the
information covered applies equally well to any Berkeley
UNIX system with or without NFS and/or Yellow Pages (NIS).
Some of the information can also be applied to System V,
although this is not a primary focus of the paper.
[FITES] Fites, M., Kratz, P. and A. Brebner, "Control and
Security of Computer Information Systems", Computer Science
Press, 1989.
This book serves as a good guide to the issues encountered
in forming computer security policies and procedures. The
book is designed as a textbook for an introductory course
in information systems security.
The book is divided into five sections: Risk Management (I),
Safeguards: security and control measures, organizational
and administrative (II)., Safeguards: Security and Control
Measures, Technical (III), Legal Environment and
Professionalism (IV), and CICA Computer Control Guidelines
(V).
The book is particularly notable for it's straight-forward
approach to security, emphasizing that common sense is the
first consideration in designing a security program. The
authors note that there is a tendency to look to more
technical solutions to security problems while overlooking
organizational controls which are often cheaper and much
more effective. 298 pages, including references and index.
[GREENIA90]
Greenia, M., "Computer Security Information Sourcebook",
Lexikon Services, Sacramento, CA, 1989.
A manager's guide to computer security. Contains a
sourcebook of key reference materials including
Security Policy Handbook Working Group [Page 88]
RFC 11XX Security Policy Handbook MMMM 1990
access control and computer crimes bibliographies.
[HAWKINS]
Hawkins, C., "What Users Should Know About Computer Viruses",
Telecommunications, North American Edition, Vol. 23, No. 7,
1 July 1989.
[HOFFMAN]
Hoffman, L., "Rogue Programs: Viruses, Worms, and
Trojan Horses", Van Nostrand Reinhold, New York, 1990.
(384 pages, includes bibliographical references and index.)
[JOHNSON]
Johnson, D., and J. Podesta, "Formulating A Company Policy
on Access to and Use and Disclosure of Electronic Mail on
Company Computer Systems".
A white paper prepared for the EMA, written by two experts
in privacy law. Gives background on the issues, and presents
some policy options.
Available from: The Electronic Mail Association (EMA)
1555 Wilson Blvd, Suite 555, Arlington VA 22209
(703) 522-7111.
[KENT]
Kent, Stephen, "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.
[LU]
Lu, W., and M. Sundareshan, "Secure Communication in
Internet Environments: A Hierachical Key Management Scheme
for End-to-End Encryption", IEEE Transactions on
Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.
[LU1]
Lu, W., 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.
[NSA]
National Security Agency, "Information Systems Security
Products and Services Catalog", NSA, Quarterly Publication.
NSA's catalogue contains chapter on: Endorsed Cryptographoic
Products List; NSA Endorsed Data Encryption Standard (DES)
Security Policy Handbook Working Group [Page 89]
RFC 11XX Security Policy Handbook MMMM 1990
Products List; Protected Services List; Evaluated Products
List; Preferred Products List; and Endorsed Tools List.
The catalogue is available from the Superintendent of
Documents, U.S. Government Printing Office, Washington,
D.C. One may place telephone orders by calling:
(202) 783-3238.
[PALMER]
Palmer, I., and G. Potter, "Computer Security Risk
Management", Van Nostrand Reinhold, New York,
1989.
[PFLEEGER]
Pfleeger, C., "Security in Computing", Prentice-Hall,
Englewood Cliffs, N.J., 1989.
[SHIREY]
Shirey, R., "Defense Data Network Security Architecture",
Computer Communication Review, Vol. 20, No. 2, Page 66,
1 April 1990.
[SPAFFORD]
Spafford, E., Heaphy, K., and D. Ferbrache, "Computer
Viruses: Dealing with Electronic Vandalism and Programmed
Threats", ADAPSO, 1989. (109 pages.)
This is a good general reference on computer viruses and
related concerns. In addition to describing viruses in
some detail, it also covers more general security issues,
legal recourse in case of security problems, and includes
lists of laws, journals focused on computers security,
and other security-related resources.
Available from: ADAPSO, 1300 N. 17th St, Suite 300,
Arlington VA 22209. (703) 522-5055.
[STOLL88]
Stoll, C., "Stalking the Wily Hacker", Communications
of the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM,
New York, NY, May 1988.
This article describes some of the technical means used
to trace the intruder that was later chronicled in
"Cuckoo's Egg" (see below).
[STOLL89]
Stoll, C., "The Cuckoo's Egg", ISBN 00385-24946-2,
Security Policy Handbook Working Group [Page 90]
RFC 11XX Security Policy Handbook MMMM 1990
Doubleday, 1989.
Clifford Stoll, an astronomer turned UNIX System
Administrator, recounts an exciting, true story of how he
tracked a computer intruder through the maze of American
military and research networks. This book is easy to
understand and can serve as an interesting introduction to
the world of networking. Jon Postel says in a book review,
this book "... is absolutely essential reading for anyone
that uses or operates any computer connected to the Internet
or any other computer network."
[VALLA]
Vallabhaneni, S., "Auditing Computer Security: A Manual with
Case Studies", Wiley, New York, NY, 1989.
7.3 Ethics
[CPSR89]
Computer Professionals for Social Responsibility, "CPSR
Statement on the Computer Virus", CPSR, Communications of the
ACM, Vol. 32, No. 6, Pg. 699, June 1989.
This memo is a statement on the Internet Computer Virus
by the Computer Professionals for Social Responsibility
(CPSR).
[ERMANN]
Ermann, D., Williams, M., and C. Gutierrez, Editors,
"Computers, Ethics, and Society", Oxford University Press,
New York, 1990. (376 pages, includes bibliographical
references.)
[FORESTER]
Forester, T., and P. Morrison, "Computer Ethics: Tales and
Ethical Dilemmas in Computing", MIT Press, Cambridge, MA,
1990. (192 pages including index.)
From the preface: "The aim of this book is two-fold: (1) to
describe some of the problems created by society by computers,
and (2) to show how these problems present ethical dilemmas
for computers professionals and computer users.
The problems created by computers arise, in turn, from two
main sources: from hardware and software malfunctions and
from misuse by human beings. We argue that computer systems
by their very nature are insecure, unreliable, and
Security Policy Handbook Working Group [Page 91]
RFC 11XX Security Policy Handbook MMMM 1990
unpredictable -- and that society has yet to come to terms
with the consequences. We also seek to show how society
has become newly vulnerable to human misuse of computers in
the form of computer crime, software theft, hacking, the
creation of viruses, invasions of privacy, and so on."
The eight chapters include "Computer Crime", "Software
Theft", "Hacking and Viruses", "Unreliable Computers",
"The Invasion of Privacy", "AI and Expert Systems",
and "Computerizing the Workplace." Includes extensive
notes on sources and an index.
[GOULD]
Gould, C., Editor, "The Information Web: Ethical and Social
Implications of Computer Networking", Westview Press,
Boulder, CO., 1989.
[IAB89]
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.
This memo is a statement of policy by the Internet
Activities Board (IAB) concerning the proper use of
the resources of the Internet. Available on-line on
host nic.ddn.mil, directory RFC, filename RFC1087.TXT.
Also available on host nis.nsf.net, directory RFC,
filename RFC1087.TXT-1.
[MARTIN]
Martin, M., and R. Schinzinger, "Ethics in Engineering",
McGraw Hill, 2nd Edition, 1989.
[MIT89]
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.
This memo is a statement of policy by the Massachusetts
Institute of Technology (MIT) on the responsible use
of computers.
[NIST]
National Institute of Standards and Technology, "Computer
Viruses and Related Threats: A Management Guide", NIST
Special Publication 500-166, August 1989.
Security Policy Handbook Working Group [Page 92]
RFC 11XX Security Policy Handbook MMMM 1990
[NSF88]
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.
This memo is a statement of policy by the National Science
Foundation (NSF) concerning the ethical use of the Internet.
[PARKER90]
Parker, D., Swope, S., and B. Baker, "Ethical Conflicts:
Information and Computer Science, Technology and Business",
QED Information Sciences, Inc., Wellesley, MA. (245 pages.)
Additional publications on Ethics:
The University of New Mexico (UNM)
The UNM has a collection of ethics documents. Included are
legislation from several states and policies from many
institutions.
Access is via FTP, IP address 129.24.8.1. Look in the
directory /ethics.
7.4 The Internet Worm
[BROCK]
Brock, J., "November 1988 Internet Computer Virus and the
Vulnerability of National Telecommunications Networks to
Computer Viruses", GAO/T-IMTEC-89-10, Washington, D.C.,
20 July 1989.
Testimonial statement of Jack L. Brock, Director, U. S.
Government Information before the Subcommittee on
Telecommunications and Finance, Committee on Energy and
Commerce, House of Representatives.
[EICHIN89]
Eichin, M., and J. Rochlis, "With Microscope and Tweezers:
An Analysis of the Internet Virus of November 1988",
Massachusetts Institute of Technology, February 1989.
Provides a detailed dissection of the worm program. The
paper discusses the major points of the worm program then
Security Policy Handbook Working Group [Page 93]
RFC 11XX Security Policy Handbook MMMM 1990
reviews strategies, chronology, lessons and open issues,
acknowledgements; also included are a detailed appendix
on the worm program subroutine by subroutine, an
appendix on the cast of characters, and a reference section.
[EISENBERG89]
Eisenberg, T., D. Gries, J. Hartmanis, D. Holcomb,
M. Lynn, and T. Santoro, "The Computer Worm", Cornell
University, 6 February 1989.
A Cornell University Report presented to the Provost of the
University on 6 February 1989 on the Internet Worm.
[GAO]
U.S. General Accounting Office, "Computer Security - Virus
Highlights Need for Improved Internet Management", United
States General Accounting Office, Washington, DC, 1989.
This 36 page report (GAO/IMTEC-89-57), by the U.S.
Government Accounting Office, describes the Internet worm
and its effects. It gives a good overview of the various
U.S. agencies involved in the Internet today and their
concerns vis-a-vis computer security and networking.
Available on-line on host nnsc.nsf.net, directory
pub, filename GAO_RPT; and on nis.nsf.net, directory nsfnet,
filename GAO_RPT.TXT.
[REYNOLDS89]
The Helminthiasis of the Internet, RFC 1135,
USC/Information Sciences Institute, Marina del Rey,
CA, December 1989.
This report looks back at the helminthiasis (infestation
with, or disease caused by parasitic worms) of the
Internet that was unleashed the evening of 2 November 1988.
It provides information about an event that occurred in
the life of the Internet. This document provides a glimpse
at the infection,its festering, and cure. The impact of
the worm on the Internet community, ethics statements, the
role of the news media, crime in the computer world, and
future prevention is discussed. A documentation review
presents four publications that describe in detail this
particular parasitic computer program. Reference and
bibliography sections are also included. Available
on-line on host nic.ddn.mil, directory RFC, filename
RFC1135.TXT. Also available on host nis.nsf.net,
directory RFC, filename RFC1135.TXT-1.
Security Policy Handbook Working Group [Page 94]
RFC 11XX Security Policy Handbook MMMM 1990
[SEELEY89]
Seeley, D., "A Tour of the Worm", Proceedings of 1989
Winter USENIX Conference, Usenix Association, San Diego, CA,
February 1989.
Details are presented as a "walk thru" of this particular
worm program. The paper opened with an abstract,
introduction, detailed chronology of events upon the
discovery of the worm, an overview, the internals of the
worm, personal opinions, and conclusion.
[SPAFFORD88]
Spafford, E., "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.
Described the infection of the Internet as a worm
program that exploited flaws in utility programs in
UNIX based systems. The report gives a detailed
description of the components of the worm program:
data and functions. Spafford focuses his study on two
completely independent reverse-compilations of the
worm and a version disassembled to VAX assembly language.
[SPAFFORD89]
Spafford, G., "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.
7.5 National Computer Security Center (NCSC)
All NCSC publications, approved for public release, are available
from the NCSC Superintendent of Documents.
NCSC = National Computer Security Center
9800 Savage Road
Ft Meade, MD 20755-6000
CSC = Computer Security Center:
an older name for the NCSC
NTISS = National Telecommunications and
Information Systems Security
Security Policy Handbook Working Group [Page 95]
RFC 11XX Security Policy Handbook MMMM 1990
NTISS Committee, National Security Agency
Ft Meade, MD 20755-6000
[CSC]
Department of Defense, "Password Management Guideline",
CSC-STD-002-85, 12 April 1985, 31 pages.
The security provided by a password system depends on
the passwords being kept secret at all times. Thus, a
password is vulnerable to compromise whenever it is used,
stored, or even known. In a password-based authentication
mechanism implemented on an ADP system, passwords are
vulnerable to compromise due to five essential aspects
of the password system: 1) a password must be initially
assigned to a user when enrolled on the ADP system;
2) a user's password must be changed periodically;
3) the ADP system must maintain a 'password
database'; 4) users must remember their passwords; and
5) users must enter their passwords into the ADP system at
authentication time. This guideline prescribes steps to be
taken to minimize the vulnerability of passwords in each of
these circumstances.
[NCSC1]
NCSC, "A Guide to Understanding AUDIT in Trusted Systems",
NCSC-TG-001, Version-2, 1 June 1988, 25 pages.
Audit trails are used to detect and deter penetration of
a computer system and to reveal usage that identifies
misuse. At the discretion of the auditor, audit trails
may be limited to specific events or may encompass all of
the activities on a system. Although not required by
the criteria, it should be possible for the target of the
audit mechanism to be either a subject or an object. That
is to say, the audit mechanism should be capable of
monitoring every time John accessed the system as well as
every time the nuclear reactor file was accessed; and
likewise every time John accessed the nuclear reactor
file.
[NCSC2]
NCSC, "A Guide to Understanding DISCRETIONARY ACCESS CONTROL
in Trusted Systems", NCSC-TG-003, Version-1, 30 September
1987, 29 pages.
Discretionary control is the most common type of access
control mechanism implemented in computer systems today.
The basis of this kind of security is that an individual
Security Policy Handbook Working Group [Page 96]
RFC 11XX Security Policy Handbook MMMM 1990
user, or program operating on the user's behalf, is
allowed to specify explicitly the types of access other
users (or programs executing on their behalf) may have to
information under the user's control. [...] Discretionary
controls are not a replacement for mandatory controls. In
any environment in which information is protected,
discretionary security provides for a finer granularity of
control within the overall constraints of the mandatory
policy.
[NCSC3]
NCSC, "A Guide to Understanding CONFIGURATION MANAGEMENT
in Trusted Systems", NCSC-TG-006, Version-1, 28 March 1988,
31 pages.
Configuration management consists of four separate tasks:
identification, control, status accounting, and auditing.
For every change that is made to an automated data
processing (ADP) system, the design and requirements of the
changed version of the system should be identified. The
control task of configuration management is performed
by subjecting every change to documentation, hardware, and
software/firmware to review and approval by an authorized
authority. Configuration status accounting is responsible
for recording and reporting on the configuration of the
product throughout the change. Finally, though the process
of a configuration audit, the completed change can be
verified to be functionally correct, and for trusted
systems, consistent with the security policy of the system.
[NTISS]
NTISS, "Advisory Memorandum on Office Automation Security
Guideline", NTISSAM CONPUSEC/1-87, 16 January 1987,
58 pages.
This document provides guidance to users, managers, security
officers, and procurement officers of Office Automation
Systems. Areas addressed include: physical security,
personnel security, procedural security, hardware/software
security, emanations security (TEMPEST), and communications
security for stand-alone OA Systems, OA Systems
used as terminals connected to mainframe computer systems,
and OA Systems used as hosts in a Local Area Network (LAN).
Differentiation is made between those Office Automation
Systems equipped with removable storage media only (e.g.,
floppy disks, cassette tapes, removable hard disks) and
those Office Automation Systems equipped with fixed media
(e.g., Winchester disks).
Security Policy Handbook Working Group [Page 97]
RFC 11XX Security Policy Handbook MMMM 1990
Additional NCSC Publications:
[NCSC4]
National Computer Security Center, "Glossary of Computer
Security Terms", NCSC-TG-004, NCSC, 21 October 1988.
[NCSC5]
National Computer Security Center, "Trusted
Computer System Evaluation Criteria", DoD 5200.28-STD,
CSC-STD-001-83, NCSC, December 1985.
[NCSC6]
National Computer Security Center, "Password
Management Guide", CSC-STD-002-85, NCSC, 12 April 1985.
[NCSC7]
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.
[NCSC8]
National Computer Security Center, "Technical Rationale
Behind CSC-STD-003-85: Computer Security Requirements",
CSC-STD-004-85, NCSC, 25 June 85.
[NCSC9]
National Computer Security Center, "Magnetic Remanence
Security Guideline", CSC-STD-005-85, NCSC, 15 November 1985.
This guideline is tagged as a "For Official Use Only"
exemption under Section 6, Public Law 86-36 (50 U.S. Code
402). Distribution authorized of U.S. Government agencies
and their contractors to protect unclassified technical,
operational, or administrative data relating to operations
of the National Security Agency.
[NCSC10]
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.
[NCSC11]
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.
Security Policy Handbook Working Group [Page 98]
RFC 11XX Security Policy Handbook MMMM 1990
[NCSC12]
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.
[NCSC13]
National Computer Security Center, "Trusted Network
Interpretation", NCSC-TG-005, NCSC, 31 July 1987.
[NCSC14]
Tinto, M., "Computer Viruses: Prevention, Detection, and
Treatment", National Computer Security Center C1
Technical Report C1-001-89, June 1989.
[NCSC15]
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.
7.6 Security Checklists
[AUCOIN]
Aucoin, R., "Computer Viruses: Checklist for Recovery",
Computers in Libraries, Vol. 9, No. 2, Pg. 4,
1 February 1989.
[WOOD]
Wood, C., Banks, W., Guarro, S., Garcia, A., Hampel, V.,
H. Sartorio, "Computer Security: A Comprehensive Controls
Checklist", John Wiley and Sons, Interscience Publication,
1987.
7.7 Additional Publications:
Defense Data Network's Network Information Center (DDN NIC)
The DDN NIC maintains DDN Security bulletins and DDN Management
bulletins online on the machine: NIC.DDN.MIL. They are available
via anonymous FTP. The DDN Security bulletins are in the
directory: SCC, and the DDN Management bulletins are in the
directory: DDN-NEWS.
Security Policy Handbook Working Group [Page 99]
RFC 11XX Security Policy Handbook MMMM 1990
For additional information, you may send a message to:
NIC@NIC.DDN.MIL, or call the DDN NIC at: 1-800-235-3155.
[DDN88]
Defense Data Network, "BSD 4.2 and 4.3 Software Problem
Resolution", DDN MGT Bulletin #43, DDN Network Information
Center, 3 November 1988.
A Defense Data Network Management Bulletin announcement
on the 4.2bsd and 4.3bsd software fixes to the Internet
worm.
[DDN89]
DCA DDN Defense Communications System, "DDN Security
Bulletin 03", DDN Security Coordination Center,
17 October 1989.
IEEE Proceedings
[IEEE]
"Proceedings of the IEEE Symposium on Security
and Privacy", published annually.
IEEE Proceedings are available from:
Computer Society of the IEEE
P.O. Box 80452
Worldway Postal Center
Los Angeles, CA 90080
Other Publications:
Computer Law and Tax Report
Computers and Security
Security Management Magazine
Journal of Information Systems Management
Data Processing & Communications Security
SIG Security, Audit & Control Review
8. Security Considerations
If security considerations had not been so widely ignored in the
Internet, this memo would not have been possible.
Security Policy Handbook Working Group [Page 100]
RFC 11XX Security Policy Handbook MMMM 1990
9. Authors' Addresses
J. Paul Holbrook
Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
4500 Fifth Avenue
Pittsburgh, PA 15213
Phone: (412) 268-7090
EMail: ph@CERT.SEI.CMU.EDU
Joyce K. Reynolds
University of Southern California
Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: (213) 822-1511
EMail: JKREY@ISI.EDU
The Security Policy Handbook Working Group can be contacted via
ssphwg@cert.sei.cmu.edu.
Security Policy Handbook Working Group [Page 101]