As per Relevance of the word computer, we have this rfc below:
Network Working Group P.
Request for Comments: 1244
FYI: 8 J.
July 1991
Site Security
Status of this
This handbook is the product of the Site Security Policy
Working Group (SSPHWG), a combined effort of the Security Area
User Services Area of the Internet Engineering Task Force (IETF).
This FYI RFC provides information for the Internet community.
does not specify an Internet standard. Distribution of this memo
unlimited
Contributing
The following are the authors of the Site Security Handbook.
their dedication, this handbook would not have been possible
Dave Curry (Purdue University), Sean Kirkpatrick (Unisys),
Longstaff (LLNL), Greg Hollingsworth (Johns Hopkins University),
Jeffrey Carpenter (University of Pittsburgh), Barbara Fraser (CERT),
Fred Ostapik (SRI NISC), Allen Sturtevant (LLNL), Dan Long (BBN),
Duncan (Pennsylvania State University), and Frank Byrum (DEC).
Editors'
This FYI RFC is a first attempt at providing Internet users
on how to deal with security issues in the Internet. As such,
document is necessarily incomplete. There are some clear shortfalls
for example, this document focuses mostly on resources available
the United States. In the spirit of the Internet's "Request
Comments" series of notes, we encourage feedback from users of
handbook. In particular, those who utilize this document to
their own policies and procedures
This handbook is meant to be a starting place for further
and should be viewed as a useful resource, but not the
authority. Different organizations and jurisdictions will
different resources and rules. Talk to your local organizations
consult an informed lawyer, or consult with local and national
enforcement. These groups can help fill in the gaps that
document cannot hope to cover
Site Security Policy Handbook Working Group [Page 1]
RFC 1244 Site Security Handbook July 1991
Finally, we intend for this FYI RFC to grow and evolve. Please
comments and suggestions to: ssphwg@cert.sei.cmu.edu
Table of
1. Introduction..................................................... 3
1.1 Purpose of this Work............................................ 3
1.2 Audience........................................................ 3
1.3 Definitions..................................................... 4
1.4 Related Work.................................................... 4
1.5 Scope........................................................... 4
1.6 Why Do We Need Security Policies and Procedures?................ 5
1.7 Basic Approach.................................................. 7
1.8 Organization of this Document................................... 7
2. Establishing Official Site Policy on Computer Security........... 9
2.1 Brief Overview.................................................. 9
2.2 Risk Assessment................................................. 10
2.3 Policy Issues................................................... 13
2.4 What Happens When the Policy Is Violated........................ 19
2.5 Locking In or Out............................................... 21
2.6 Interpreting the Policy......................................... 23
2.7 Publicizing the Policy.......................................... 23
3. Establishing Procedures to Prevent Security Problems............. 24
3.1 Security Policy Defines What Needs to be Protected.............. 24
3.2 Identifing Possible Problems.................................... 24
3.3 Choose Controls to Protect Assets in a Cost-Effective Way....... 26
3.4 Use Multiple Strategies to Protect Assets....................... 26
3.5 Physical Security............................................... 27
3.6 Procedures to Recognize Unauthorized Activity................... 27
3.7 Define Actions to Take When Unauthorized Activity is Suspected.. 29
3.8 Communicating Security Policy................................... 30
3.9 Resources to Prevent Security Breaches.......................... 34
4. Types of Security Procedures..................................... 56
4.1 System Security Audits.......................................... 56
4.2 Account Management Procedures................................... 57
4.3 Password Management Procedures.................................. 57
4.4 Configuration Management Procedures............................. 60
5. Incident Handling................................................ 61
5.1 Overview........................................................ 61
5.2 Evaluation...................................................... 65
5.3 Possible Types of Notification.................................. 67
5.4 Response........................................................ 71
5.5 Legal/Investigative............................................. 73
5.6 Documentation Logs.............................................. 77
6. Establishing Post-Incident Procedures............................ 78
6.1 Overview........................................................ 78
6.2 Removing Vulnerabilities........................................ 78
6.3 Capturing Lessons Learned....................................... 80
Site Security Policy Handbook Working Group [Page 2]
RFC 1244 Site Security Handbook July 1991
6.4 Upgrading Policies and Procedures............................... 81
7. References....................................................... 81
8. Annotated Bibliography........................................... 83
8.1 Computer Law.................................................... 84
8.2 Computer Security............................................... 85
8.3 Ethics.......................................................... 91
8.4 The Internet Worm............................................... 93
8.5 National Computer Security Center (NCSC)........................ 95
8.6 Security Checklists............................................. 99
8.7 Additional Publications......................................... 99
9. Acknlowledgements................................................101
10. Security Considerations.........................................101
11. Authors' Addresses..............................................101
1.
1.1 Purpose of this
This handbook is a guide to setting computer security policies
procedures for sites that have systems on the Internet. This
lists issues and factors that a site must consider when setting
own policies. It makes some recommendations and gives discussions
relevant areas
This guide is only a framework for setting security policies
procedures. In order to have an effective set of policies
procedures, a site will have to make many decisions, gain agreement
and then communicate and implement the policies
1.2
The audience for this work are system administrators and
makers (who are more traditionally called "administrators" or "
management") at sites. This document is not directed at
or those trying to create secure programs or systems. The focus
this document is on the policies and procedures that need to be
place to support any technical security features that a site may
implementing
The primary audience for this work are sites that are members of
Internet community. However, this document should be useful to
site that allows communication with other sites. As a general
to security policies, this document may also be useful to sites
isolated systems
Site Security Policy Handbook Working Group [Page 3]
RFC 1244 Site Security Handbook July 1991
1.3
For the purposes of this guide, a "site" is any organization
owns computers or network-related resources. These resources
include host computers that users use, routers, terminal servers
PC's or other devices that have access to the Internet. A site
be a end user of Internet services or a service provider such as
regional network. However, most of the focus of this guide is
those end users of Internet services
We assume that the site has the ability to set policies
procedures for itself with the concurrence and support from those
actually own the resources
The "Internet" is those set of networks and machines that use
TCP/IP protocol suite, connected through gateways, and sharing
common name and address spaces [1].
The term "system administrator" is used to cover all those who
responsible for the day-to-day operation of resources. This may be
number of individuals or an organization
The term "decision maker" refers to those people at a site who set
approve policy. These are often (but not always) the people who
the resources
1.4 Related
The IETF Security Policy Working Group (SPWG) is working on a set
recommended security policy guidelines for the Internet [23].
guidelines may be adopted as policy by regional networks or owners
other resources. This handbook should be a useful tool to help
implement those policies as desired or required. However,
implementing the proposed policies isn't enough to secure a site
The proposed Internet policies deal only with network
security. It says nothing about how sites should deal with
security issues
1.5
This document covers issues about what a computer security
should contain, what kinds of procedures are need to
security, and some recommendations about how to deal with
problem. When developing a security policy, close attention
be made not only on the security needs and requirements of the
network, but also the security needs and requirements of the
interconnected networks
Site Security Policy Handbook Working Group [Page 4]
RFC 1244 Site Security Handbook July 1991
This is not a cookbook for computer security. Each site
different needs; the security needs of a corporation might well
different than the security needs of an academic institution.
security plan has to conform 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
essential in setting and implementing effective security policy,
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
secure systems or programs
1.6 Why Do We Need Security Policies and Procedures
For most sites, the interest in computer security is proportional
the perception of risk and threats
The world of computers has changed dramatically over the
twenty-five years. Twenty-five years ago, most computers
centralized and managed by data centers. Computers were kept
locked rooms and staffs of people made sure they were
managed and physically secured. Links outside a site were unusual
Computer security threats were rare, and were basically
with insiders: authorized users misusing accounts, theft
vandalism, and so forth. These threats were well understood
dealt with using standard techniques: computers behind locked doors
and accounting for all resources
Computing in the 1990's is radically different. Many systems are
private offices and labs, often managed by individuals or
employed outside a computer center. Many systems are connected
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
"don't write your password down and put it in your desk" lest
find it. With world-wide Internet connections, someone could
into your system from the other side of the world and steal
password in the middle of the night when your building is locked up
Viruses and worms can be passed from machine to machine.
Internet allows the electronic equivalent of the thief who looks
open windows and doors; now a person can check hundreds of
for vulnerabilities in a few hours
System administrators and decision makers have to understand
security threats that exist, what the risk and cost of a
Site Security Policy Handbook Working Group [Page 5]
RFC 1244 Site Security Handbook July 1991
would be, and what kind of action they want to take (if any)
prevent and respond to security threats
As an illustration of some of the issues that need to be dealt
in security problems, consider the following scenarios (thanks
Russell Brand [2, BRAND] for these):
- A system programmer gets a call reporting that
major underground cracker newsletter is
distributed from the administrative machine at
center to five thousand sites in the US
Western Europe
Eight weeks later, the authorities call to
you the information in one of these
was used to disable "911" in a major city
five hours
- A user calls in to report that he can't login to
account at 3 o'clock in the morning on a Saturday.
system staffer can't login either. After rebooting
single user mode, he finds that password file is empty
By Monday morning, your staff determines that a
of privileged file transfers took place between
machine and a local university
Tuesday morning a copy of the deleted password file
found on the university machine along with
files for a dozen other machines
A week later you find that your system
files had been altered in a hostile fashion
- You receive a call saying that a breakin to a
lab occurred from one of your center's machines.
are requested to provide accounting files to
trackdown the attacker
A week later you are given a list of machines at
site that have been broken into
- A reporter calls up asking about the breakin at
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
Site Security Policy Handbook Working Group [Page 6]
RFC 1244 Site Security Handbook July 1991
- 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
leave the system open to monitor the situation or
you close down the holes and open them up again later
- If an intruder is using your site, should you call
enforcement? Who makes that decision? If law enforcement
you to leave your site open, who makes that decision
- What steps should be taken if another site calls you and
they see activity coming from an account on your system?
if the account is owned by a local manager
1.7 Basic
Setting security policies and procedures really means developing
plan for how to deal with computer security. One way to
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
cost-effective manner
- Review the process continuously, and improve things every
a weakness is found
This handbook will concentrate mostly on the last two steps, but
first three are critically important to making effective
about security. One old truism in security is that the cost
protecting yourself against a threat should be less than the
recovering if the threat were to strike you. Without
knowledge of what you are protecting and what the likely threats are
following this rule could be difficult
1.8 Organization of this
This document is organized into seven parts in addition to
introduction
The basic form of each section is to discuss issues that a site
want to consider in creating a computer security policy and
procedures to implement that policy. In some cases, possible
are discussed along with the some of the ramifications of
Site Security Policy Handbook Working Group [Page 7]
RFC 1244 Site Security Handbook July 1991
choices. As far as possible, this document tries not to dictate
choices a site should make, since these depend on
circumstances. Some of the issues brought up may not apply to
sites. Nonetheless, all sites should at least consider the
brought up here to ensure that they do not miss some important area
The overall flow of the document is to discuss policy issues
by the issues that come up in creating procedures to implement
policies
Section 2 discusses setting official site policies for access
computing resources. It also goes into the issue of what
when the policy is violated. The policies will drive the
that need to be created, so decision makers will need to make
about policies before many of the procedural issues in
sections can be dealt with. A key part of creating policies is
some kind of risk assessment to decide what really needs to
protected and the level of resources that should be applied
protect them
Once policies are in place, procedures to prevent future
problems should be established. Section 3 defines and
actions to take when unauthorized activity is suspected.
to prevent secruity breaches are also discussed
Section 4 discusses types of procedures to prevent security problems
Prevention is a key to security; as an example, the
Emergency Response Team/Coordination Center (CERT/CC) at Carnegie
Mellon University (CMU) estimates that 80% or more of the
they see have to do with poorly chosen passwords
Section 5 discusses incident handling: what kinds of issues does
site face when someone violates the security policy. Many
will have to made on the spot as the incident occurs, but many of
options and issues can be discussed in advance. At very least
responsibilities and methods of communication can be
before an incident. Again, the choices here are influenced by
policies discussed in section 2.
Section 6 deals with what happens after a security violation has
dealt with. Security planning is an on-going cycle; just after
incident has occurred is an excellent opportunity to improve
and procedures
The rest of the document provides references and an
bibliography
Site Security Policy Handbook Working Group [Page 8]
RFC 1244 Site Security Handbook July 1991
2. Establishing Official Site Policy on Computer
2.1 Brief
2.1.1 Organization
The goal in developing an official site policy on
security is to define the organization's expectations of
computer and network use and to define procedures to prevent
respond to security incidents. In order to do this, aspects
the particular organization must be considered
First, the goals and direction of the organization should
considered. For example, a military base may have very
security concerns from a those of a university
Second, the site security policy developed must conform
existing policies, rules, regulations and laws that
organization is subject to. Therefore it will be necessary
identify these and take them into consideration while
the policy
Third, unless the local network is completely isolated
standalone, it is necessary to consider security implications in
more global context. The policy should address the issues
local security problems develop as a result of a remote site
well as when problems occur on remote systems as a result of
local host or user
2.1.2 Who Makes the Policy
Policy creation must be a joint effort by technical personnel,
understand the full ramifications of the proposed policy and
implementation of the policy, and by decision makers who have
power to enforce the policy. A policy which is
implementable nor enforceable is useless
Since a computer security policy can affect everyone in
organization, it is worth taking some care to make sure you
the right level of authority in on the policy decisions. Though
particular group (such as a campus information services group)
have responsibility for enforcing a policy, an even higher
may have to support and approve the policy
2.1.3 Who is Involved
Establishing a site policy has the potential for involving
computer user at the site in a variety of ways. Computer
Site Security Policy Handbook Working Group [Page 9]
RFC 1244 Site Security Handbook July 1991
may be responsible for personal password administration.
managers are obligated to fix security holes and to oversee
system
It is critical to get the right set of people involved at
start of the process. There may already be groups concerned
security who would consider a computer security policy to be
area. Some of the types of groups that might be involved
auditing/control, organizations that deal with physical security
campus information systems groups, and so forth. Asking
types of groups to "buy in" from the start can help facilitate
acceptance of the policy
2.1.4
A key element of a computer security policy is making
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
assigned to deal with it
There may be levels of responsibility associated with a policy
computer security. At one level, each user of a
resource may have a responsibility to protect his account. A
who allows his account to be compromised increases the chances
compromising other accounts or resources
System managers may form another responsibility level: they
help to ensure the security of the computer system.
managers may reside at yet another level
2.2 Risk
2.2.1 General
One of the most important reasons for creating a computer
policy is to ensure that efforts spent on security yield
effective benefits. Although this may seem obvious, it
possible to be mislead about where the effort is needed. As
example, there is a great deal of publicity about intruders
computers systems; yet most surveys of computer security show
for most organizations, the actual loss from "insiders" is
greater
Risk analysis involves determining what you need to protect,
you need to protect it from, and how to protect it. Is is
process of examining all of your risks, and ranking those risks
level of severity. This process involves making cost-
Site Security Policy Handbook Working Group [Page 10]
RFC 1244 Site Security Handbook July 1991
decisions on what you want to protect. The old security
says that you should not spend more to protect something than
is actually worth
A full treatment of risk analysis is outside the scope of
document. [3, FITES] and [16, PFLEEGER] provide introductions
this topic. However, there are two elements of a risk
that will be briefly covered in the next two sections
1. Identifying the
2. Identifying the
For each asset, the basic goals of security are availability
confidentiality, and integrity. Each threat should be
with an eye to how the threat could affect these areas
2.2.2 Identifying the
One step in a risk analysis is to identify all the things
need to be protected. Some things are obvious, like all
various pieces of hardware, but some are overlooked, such as
people who actually use the systems. The essential point is
list all things that could be affected by a security problem
One list of categories is suggested by Pfleeger [16, PFLEEGER
page 459]; this list is adapted from that source
1. Hardware: cpus, boards, keyboards, terminals
workstations, personal computers, printers,
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
communication media
4. People: users, people needed to run systems
5. Documentation: on programs, hardware, systems,
administrative procedures
6. Supplies: paper, forms, ribbons, magnetic media
Site Security Policy Handbook Working Group [Page 11]
RFC 1244 Site Security Handbook July 1991
2.2.3 Identifying the
Once the assets requiring protection are identified, it
necessary to identify threats to those assests. The threats
then be examined to determine what potential for loss exists.
helps to consider from what threats you are trying to protect
assets
The following sections describe a few of the possible threats
2.2.3.1 Unauthorized
A common threat that concerns many sites is unauthorized
to computing facilities. Unauthorized access takes many forms
One means of unauthorized access is the use of another user'
account to gain access to a system. The use of any
resource without prior permission may be
unauthorized access to computing facilities
The seriousness of an unauthorized access will vary from
to site. For some sites, the mere act of granting access to
unauthorized user may cause irreparable harm by negative
coverage. For other sites, an unauthorized access opens
door to other security threats. In addition, some sites may
more frequent targets than others; hence the risk
unauthorized access will vary from site to site. The
Emergency Response Team (CERT - see section 3.9.7.3.1)
observed that well-known universities, government sites,
military sites seem to attract more intruders
2.2.3.2 Disclosure of
Another common threat is disclosure of information.
the value or sensitivity of the information stored on
computers. Disclosure of a password file might allow
future unauthorized accesses. A glimpse of a proposal may
a competitor an unfair advantage. A technical paper
contain years of valuable research
2.2.3.3 Denial of
Computers and networks provide valuable services to
users. Many people rely on these services in order to
their jobs efficiently. When these services are not
when called upon, a loss in productivity results
Denial of service comes in many forms and might affect users
a number of ways. A network may be rendered unusable by
Site Security Policy Handbook Working Group [Page 12]
RFC 1244 Site Security Handbook July 1991
rogue packet, jamming, or by a disabled network component.
virus might slow down or cripple a computer system. Each
should determine which services are essential, and for each
these services determine the affect to the site if that
were to become disabled
2.3 Policy
There are a number of issues that must be addressed when developing
security policy. These are
1. Who is allowed to use the resources
2. What is the proper use of the resources
3. Who is authorized to grant access and approve usage
4. Who may have system administration privileges
5. What are the user's rights and responsibilities
6. What are the rights and responsibilities of
system administrator vs. those of the user
7. What do you do with sensitive information
These issues will be discussed below. In addition you may wish
include a section in your policy concerning ethical use of
resources. Parker, Swope and Baker [17, PARKER90] and Forester
Morrison [18, FORESTER] are two useful references that
ethical issues
2.3.1 Who is Allowed to use the Resources
One step you must take in developing your security policy
defining who is allowed to use your system and services.
policy should explicitly state who is authorized to use
resources
2.3.2 What is the Proper Use of the Resources
After determining who is allowed access to system resources it
necessary to provide guidelines for the acceptable use of
resources. You may have different guidelines for different
of users (i.e., students, faculty, external users). The
should state what is acceptable use as well as unacceptable use
It should also include types of use that may be restricted
Define limits to access and authority. You will need to
the level of access various users will have and what
will be available or restricted to various groups of people
Your acceptable use policy should clearly state that
users are responsible for their actions. Their
Site Security Policy Handbook Working Group [Page 13]
RFC 1244 Site Security Handbook July 1991
exists regardless of the security mechanisms that are in place
It should be clearly stated that breaking into accounts
bypassing security is not permitted
The following points should be covered when developing
acceptable use policy
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-
grants them the authorization to read it
o Should users be permitted to modify files that
not their own even if they happen to have
permission
o Should users share accounts
The answer to most of these questions will be "no".
You may wish to incorporate a statement in your
concerning copyrighted and licensed software.
agreements with vendors may require some sort of effort on
part to ensure that the license is not violated. In addition,
may wish to inform users that the copying of copyrighted
may be a violation of the copyright laws, and is not permitted
Specifically concerning copyrighted and/or licensed software,
may wish to include the following information
o Copyrighted and licensed software may not be
unless it is explicitly stated that you may do so
o Methods of conveying information on
copyright/licensed status of software
o When in doubt, DON'T COPY
Your acceptable use policy is very important. A policy which
not clearly state what is not permitted may leave you unable
prove that a user violated policy
There are exception cases like tiger teams and users
administrators wishing for "licenses to hack" -- you may face
situation where users will want to "hack" on your services
security research purposes. You should develop a policy that
determine whether you will permit this type of research on
services and if so, what your guidelines for such research
be
Points you may wish to cover in this area
Site Security Policy Handbook Working Group [Page 14]
RFC 1244 Site Security Handbook July 1991
o Whether it is permitted at all
o What type of activity is permitted: breaking in,
worms, releasing viruses, etc..
o What type of controls must be in place to ensure that
does not get out of control (e.g., separate a segment
your network for these tests).
o How you will protect other users from being victims
these activities, including external users and networks
o The process for obtaining permission to conduct
tests
In cases where you do permit these activities, you should
the portions of the network that are being tested from your
network. Worms and viruses should never be released on a
network
You may also wish to employ, contract, or otherwise solicit one
more people or organizations to evaluate the security of
services, of which may include "hacking". You may wish to
for this in your policy
2.3.3 Who Is Authorized to Grant Access and Approve Usage
Your policy should state who is authorized to grant access to
services. Further, it must be determined what type of access
are permitted to give. If you do not have control over who
granted access to your system, you will not have control over
is using your system. Controlling who has the authorization
grant access will also enable you to know who was or was
granting access if problems develop later
There are many schemes that can be developed to control
distribution of access to your services. The following are
factors that you must consider when determining who
distribute access to your services
o Will you be distributing access from a
point or at various points
You can have a centralized distribution point to a
system where various sites or departments independently
access. The trade off is between security and convenience.
more centralized, the easier to secure
o What methods will you use for creating accounts
terminating access
From a security standpoint, you need to examine the mechanism
Site Security Policy Handbook Working Group [Page 15]
RFC 1244 Site Security Handbook July 1991
you will be using to create accounts. In the least
case, the people who are authorized to grant access would be
to go into the system directly and create an account by hand
through vendor supplied mechanisms. Generally, these
place a great deal of trust in the person running them, and
person running them usually has a large amount of privileges.
this is the choice you make, you need to select someone who
trustworthy to perform this task. The opposite solution is
have an integrated system that the people authorized to
accounts run, or the users themselves may actually run. Be
that even in the restrictive case of having a mechanized
to create accounts does not remove the potential for abuse
You should have specific procedures developed for the creation
accounts. These procedures should be well documented to
confusion and reduce mistakes. A security vulnerability in
account authorization process is not only possible through abuse
but is also possible if a mistake is made. Having clear and
documented procedure will help ensure that these mistakes won'
happen. You should also be sure that the people who will
following these procedures understand them
The granting of access to users is one of the most vulnerable
times. You should ensure that the selection of an
password cannot be easily guessed. You should avoid using
initial password that is a function of the username, is part
the user's name, or some algorithmically generated password
can easily be guessed. In addition, you should not permit
to continue to use the initial password indefinitely.
possible, you should force users to change the initial
the first time they login. Consider that some users may
even login, leaving their password vulnerable indefinitely.
sites choose to disable accounts that have never been accessed
and force the owner to reauthorize opening the account
2.3.4 Who May Have System Administration Privileges
One security decision that needs to be made very carefully is
will have access to system administrator privileges and
for your services. Obviously, the system administrators will
access, but inevitably other users will request
privileges. The policy should address this issue.
privileges is one way to deal with threats from local users.
challenge is to balance restricting access to these to
security with giving people who need these privileges access
that they can perform their tasks. One approach that can be
is to grant only enough privilege to accomplish the
tasks
Site Security Policy Handbook Working Group [Page 16]
RFC 1244 Site Security Handbook July 1991
Additionally, people holding special privileges should
accountable to some authority and this should also be
within the site's security policy. If the people you
privileges to are not accountable, you run the risk of
control of your system and will have difficulty managing
compromise in security
2.3.5 What Are The Users' Rights and Responsibilities
The policy should incorporate a statement on the users' rights
responsibilities concerning the use of the site's computer
and services. It should be clearly stated that users
responsible for understanding and respecting the security rules
the systems they are using. The following is a list of
that you may wish to cover in this area of the policy
o What guidelines you have regarding resource
(whether users are restricted, and if so, what
restrictions are).
o What might constitute abuse in terms of system performance
o Whether users are permitted to share accounts or let
use their accounts
o How "secret" users should keep their passwords
o How often users should change their passwords and any
password restrictions or requirements
o Whether you provide backups or expect the users to
their own
o Disclosure of information that may be proprietary
o Statement on Electronic Mail Privacy (
Communications Privacy Act).
o Your policy concerning controversial mail or postings
mailing lists or discussion groups (obscenity, harassment
etc.).
o Policy on electronic communications: mail forging, etc
The Electronic Mail Association sponsored a white paper on
privacy of electronic mail in companies [4]. Their
recommendation is that every site should have a policy on
protection of employee privacy. They also recommend
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
third parties
2. Does the policy unnecessarily compromise the interest
Site Security Policy Handbook Working Group [Page 17]
RFC 1244 Site Security Handbook July 1991
the employee, the employer or third parties
3. Is the policy workable as a practical matter and likely
be enforced
4. Does the policy deal appropriately with all
forms of communications and record keeping with the office
5. Has the policy been announced in advance and agreed to
all concerned
2.3.6 What Are The Rights and Responsibilities of
Administrators Versus Rights of
There is a tradeoff between a user's right to absolute privacy
the need of system administrators to gather sufficient
to diagnose problems. There is also a distinction between
system administrator's need to gather information to
problems and investigating security violations. The policy
specify to what degree system administrators can examine
files to diagnose problems or for other purposes, and what
you grant to the users. You may also wish to make a
concerning system administrators' obligation to maintaining
privacy of information viewed under these circumstances. A
questions that should be answered are
o Can an administrator monitor or read a user's
for any reason
o What are the liabilities
o Do network administrators have the right to
network or host traffic
2.3.7 What To Do With Sensitive
Before granting users access to your services, you need
determine at what level you will provide for the security of
on your systems. By determining this, you are determining
level of sensitivity of data that users should store on
systems. You do not want users to store very
information on a system that you are not going to secure
well. You need to tell users who might store
information what services, if any, are appropriate for the
of sensitive information. This part should include storing
data in different ways (disk, magnetic tape, file servers, etc.).
Your policy in this area needs to be coordinated with the
concerning the rights of system administrators versus users (
section 2.3.6).
Site Security Policy Handbook Working Group [Page 18]
RFC 1244 Site Security Handbook July 1991
2.4 What Happens When the Policy is
It is obvious that when any type of official policy is defined, be
related to computer security or not, it will eventually be broken
The violation may occur due to an individual's negligence,
mistake, having not been properly informed of the current policy,
not understanding the current policy. It is equally possible that
individual (or group of individuals) may knowingly perform an
that is in direct violation of the defined policy
When a policy violation has been detected, the immediate course
action should be pre-defined to ensure prompt and proper enforcement
An investigation should be performed to determine how and why
violation occurred. Then the appropriate corrective action should
executed. The type and severity of action taken varies depending
the type of violation that occurred
2.4.1 Determining the Response to Policy
Violations to policy may be committed by a wide variety of users
Some may be local users and others may be from outside the
environment. Sites may find it helpful to define what
considers "insiders" and "outsiders" based upon administrative
legal or political boundaries. These boundaries imply what
of action must be taken to correct the offending party; from
written reprimand to pressing legal charges. So, not only do
need to define actions based on the type of violation, you
need to have a clearly defined series of actions based on the
of user violating your computer security policy. This all
rather complicated, but should be addressed long before it
necessary as the result of a violation
One point to remember about your policy is that proper
is your best defense. For the outsiders who are using
computer legally, it is your responsibility to verify that
individuals are aware of the policies that you have set forth
Having this proof may assist you in the future if legal
becomes necessary
As for users who are using your computer illegally, the problem
basically the same. What type of user violated the policy and
and why did they do it? Depending on the results of
investigation, you may just prefer to "plug" the hole in
computer security and chalk it up to experience. Or if
significant amount of loss was incurred, you may wish to take
drastic action
Site Security Policy Handbook Working Group [Page 19]
RFC 1244 Site Security Handbook July 1991
2.4.2 What to do When Local Users Violate the Policy of a
In the event that a local user violates the security policy of
remote site, the local site should have a clearly defined set
administrative actions to take concerning that local user.
site should also be prepared to protect itself against
actions by the remote site. These situations involve legal
which should be addressed when forming the security policy
2.4.3 Defining Contacts and Responsibilities to
The local security policy should include procedures
interaction with outside organizations. These include
enforcement agencies, other sites, external response
organizations (e.g., the CERT, CIAC) and various press agencies
The procedure should state who is authorized to make such
and how it should be handled. Some questions to be
include
o Who may talk to the press
o When do you contact law enforcement and investigative agencies
o If a connection is made from a remote site, is
system manager authorized to contact that site
o Can data be released? What kind
Detailed contact information should be readily available
with clearly defined procedures to follow
2.4.4 What are the Responsibilities to our Neighbors and
Internet Sites
The Security Policy Working Group within the IETF is working on
document entitled, "Policy Guidelines for the Secure Operation
the Internet" [23]. It addresses the issue that the Internet is
cooperative venture and that sites are expected to provide
security assistance. This should be addressed when developing
site's policy. The major issue to be determined is how
information should be released. This will vary from site to
according to the type of site (e.g., military, education
commercial) as well as the type of security violation
occurred
2.4.5 Issues for Incident Handling
Along with statements of policy, the document being
should include procedures for incident handling. This is
Site Security Policy Handbook Working Group [Page 20]
RFC 1244 Site Security Handbook July 1991
in detail in the next chapter. There should be
available that cover all facets of policy violation
2.5 Locking In or
Whenever a site suffers an incident which may compromise
security, the strategies for reacting may be influenced by
opposing pressures
If management fears that the site is sufficiently vulnerable, it
choose a "Protect and Proceed" strategy. This approach will have
its primary goal the protection and preservation of the
facilities and to provide for normalcy for its users as quickly
possible. Attempts will be made to actively interfere with
intruder's processes, prevent further access and begin
damage assessment and recovery. This process may involve
down the facilities, closing off access to the network, or
drastic measures. The drawback is that unless the intruder
identified directly, they may come back into the site via a
path, or may attack another site
The alternate approach, "Pursue and Prosecute", adopts the
philosophy and goals. The primary goal is to allow intruders
continue their activities at the site until the site can identify
responsible persons. This approach is endorsed by law
agencies and prosecutors. The drawback is that the agencies
exempt a site from possible user lawsuits if damage is done to
systems and data
Prosecution is not the only outcome possible if the intruder
identified. If the culprit is an employee or a student,
organization may choose to take disciplinary actions. The
security policy needs to spell out the choices and how they will
selected if an intruder is caught
Careful consideration must be made by site management regarding
approach to this issue before the problem occurs. The
adopted might depend upon each circumstance. Or there may be
global policy which mandates one approach in all circumstances.
pros and cons must be examined thoroughly and the users of
facilities must be made aware of the policy so that they
their vulnerabilities no matter which approach is taken
The following are checklists to help a site determine which
to adopt: "Protect and Proceed" or "Pursue and Prosecute".
Site Security Policy Handbook Working Group [Page 21]
RFC 1244 Site Security Handbook July 1991
Protect and
1. If assets are not well protected
2. If continued penetration could result in
financial risk
3. If the possibility or willingness to
is not present
4. If user base is unknown
5. If users are unsophisticated and their work
vulnerable
6. If the site is vulnerable to lawsuits from users, e.g.,
if their resources are undermined
Pursue and
1. If assets and systems are well protected
2. If good backups are available
3. If the risk to the assets is outweighed by
disruption caused by the present and possibly
penetrations
4. If this is a concentrated attack occurring with
frequency and intensity
5. If the site has a natural attraction to intruders,
consequently regularly attracts intruders
6. If the site is willing to incur the financial (or other
risk to assets by allowing the penetrator continue
7. If intruder access can be controlled
8. If the monitoring tools are sufficiently well-
to make the pursuit worthwhile
9. If the support staff is sufficiently clever and
about the operating system, related utilities, and
to make the pursuit worthwhile
10. If there is willingness on the part of management
prosecute
Site Security Policy Handbook Working Group [Page 22]
RFC 1244 Site Security Handbook July 1991
11. If the system adminitrators know in general what kind
evidence would lead to prosecution
12. If there is established contact with knowledgeable
enforcement
13. If there is a site representative versed in the
legal issues
14. If the site is prepared for possible legal action
its own users if their data or systems become
during the pursuit
2.6 Interpreting the
It is important to define who will interpret the policy. This
be an individual or a committee. No matter how well written,
policy will require interpretation from time to time and this
would serve to review, interpret, and revise the policy as needed
2.7 Publicizing the
Once the site security policy has been written and established,
vigorous process should be engaged to ensure that the
statement is widely and thoroughly disseminated and discussed.
mailing of the policy should not be considered sufficient. A
for comments should be allowed before the policy becomes effective
ensure that all affected users have a chance to state their
and discuss any unforeseen ramifications. Ideally, the policy
strike a balance between protection and productivity
Meetings should be held to elicit these comments, and also to
that the policy is correctly understood. (Policy promulgators
not necessarily noted for their skill with the language.)
meetings should involve higher management as well as line employees
Security is a collective effort
In addition to the initial efforts to publicize the policy, it
essential for the site to maintain a continual awareness of
computer security policy. Current users may need periodic
New users should have the policy included as part of their
introduction packet. As a condition for using the site facilities
it may be advisable to have them sign a statement that they have
and understood the policy. Should any of these users require
action for serious policy violations, this signed statement
prove to be a valuable aid
Site Security Policy Handbook Working Group [Page 23]
RFC 1244 Site Security Handbook July 1991
3. Establishing Procedures to Prevent Security
The security policy defines what needs to be protected. This
discusses security procedures which specify what steps will be
to carry out the security policy
3.1 Security Policy Defines What Needs to be
The security policy defines the WHAT's: what needs to be protected
what is most important, what the priorities are, and what the
approach to dealing with security problems should be
The security policy by itself doesn't say HOW things are protected
That is the role of security procedures, which this
discusses. The security policy should be a high level document
giving general strategy. The security procedures need to set out,
detail, the precise steps your site will take to protect itself
The security policy should include a general risk assessment of
types of threats a site is mostly likely to face and the
of those threats (see section 2.2). Part of doing a risk
will include creating a general list of assets that should
protected (section 2.2.2). This information is critical in
cost-effective procedures
It is often tempting to start creating security procedures
deciding on different mechanisms first: "our site should have
on all hosts, call-back modems, and smart cards for all users."
approach could lead to some areas that have too much protection
the risk they face, and other areas that aren't protected enough
Starting with the security policy and the risks it outlines
ensure that the procedures provide the right level of protect for
assets
3.2 Identifing Possible
To determine risk, vulnerabilities must be identified. Part of
purpose of the policy is to aid in shoring up the vulnerabilities
thus to decrease the risk in as many areas as possible. Several
the more popular problem areas are presented in sections below.
list is by no means complete. In addition, each site is likely
have a few unique vulnerabilities
3.2.1 Access
Access points are typically used for entry by unauthorized users
Having many access points increases the risk of access to
organization's computer and network facilities
Site Security Policy Handbook Working Group [Page 24]
RFC 1244 Site Security Handbook July 1991
Network links to networks outside the organization allow
into the organization for all others connected to that
network. A network link typically provides access to a
number of network services, and each service has a potential to
compromised
Dialup lines, depending on their configuration, may provide
merely to a login port of a single system. If connected to
terminal server, the dialup line may give access to the
network
Terminal servers themselves can be a source of problem.
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
go out to the local network. Some terminal servers are
so that intruders can TELNET [19] in from outside the network,
then TELNET back out again, again serving to make it difficult
trace them
3.2.2 Misconfigured
Misconfigured systems form a large percentage of security holes
Today's operating systems and their associated software
become so complex that understanding how the system works
become a full-time job. Often, systems managers will be non
specialists chosen from the current organization's staff
Vendors are also partly responsible for misconfigured systems.
make the system installation process easier, vendors
choose initial configurations that are not secure in
environments
3.2.3 Software
Software will never be bug free. Publicly known security bugs
common methods of unauthorized entry. Part of the solution
this problem is to be aware of the security problems and to
the software when problems are detected. When bugs are found
they should be reported to the vendor so that a solution to
problem can be implemented and distributed
3.2.4 "Insider"
An insider to the organization may be a considerable threat to
security of the computer systems. Insiders often have
access to the computer and network hardware components.
ability to access the components of a system makes most
Site Security Policy Handbook Working Group [Page 25]
RFC 1244 Site Security Handbook July 1991
easier to compromise. Most desktop workstations can be
manipulated so that they grant privileged access. Access to
local area network provides the ability to view possibly
data traversing the network
3.3 Choose Controls to Protect Assets in a Cost-Effective
After establishing what is to be protected, and assessing the
these assets face, it is necessary to decide how to implement
controls which protect these assets. The controls and
mechanisms should be selected in a way so as to adequately
the threats found during risk assessment, and to implement
controls in a cost effective manner. It makes little sense to
an exorbitant sum of money and overly constrict the user base if
risk of exposure is very small
3.3.1 Choose the Right Set of
The controls that are selected represent the physical
of your security policy. They are the first and primary line
defense in the protection of your assets. It is therefore
important to ensure that the controls that you select are
right set of controls. If the major threat to your system
outside penetrators, it probably doesn't make much sense to
biometric devices to authenticate your regular system users.
the other hand, if the major threat is unauthorized use
computing resources by regular system users, you'll probably
to establish very rigorous automated accounting procedures
3.3.2 Use Common
Common sense is the most appropriate tool that can be used
establish your security policy. Elaborate security schemes
mechanisms are impressive, and they do have their place, yet
is little point in investing money and time on an
implementation scheme if the simple controls are forgotten.
example, no matter how elaborate a system you put into place
top of existing security controls, a single user with a
password can still leave your system open to attack
3.4 Use Multiple Strategies to Protect
Another method of protecting assets is to use multiple strategies
In this way, if one strategy fails or is circumvented,
strategy comes into play to continue protecting the asset. By
several simpler strategies, a system can often be made more
than if one very sophisticated method were used in its place.
example, dial-back modems can be used in conjunction with
Site Security Policy Handbook Working Group [Page 26]
RFC 1244 Site Security Handbook July 1991
logon mechanisms. Many similar approaches could be devised
provide several levels of protection for assets. However, it's
easy to go overboard with extra mechanisms. One must keep in
exactly what it is that needs to be protected
3.5 Physical
It is a given in computer security if the system itself is
physically secure, nothing else about the system can be
secure. With physical access to a machine, an intruder can halt
machine, bring it back up in privileged mode, replace or alter
disk, plant Trojan horse programs (see section 2.13.9.2), or take
number of other undesirable (and hard to prevent) actions
Critical communications links, important servers, and other
machines should be located in physically secure areas. Some
systems (such as Kerberos) require that the machine be
secure
If you cannot physically secure machines, care should be taken
trusting those machines. Sites should consider limiting access
non-secure machines to more secure machines. In particular,
trusted access (e.g., the BSD Unix remote commands such as rsh)
these kinds of hosts is particularly risky
For machines that seem or are intended to be physically secure,
should be taken about who has access to the machines. Remember
custodial and maintenance staff often have keys to rooms
3.6 Procedures to Recognize Unauthorized
Several simple procedures can be used to detect most
uses of a computer system. These procedures use tools provided
the operating system by the vendor, or tools publicly available
other sources
3.6.1 Monitoring System
System monitoring can be done either by a system administrator,
by software written for the purpose. Monitoring a system
looking at several parts of the system and searching for
unusual. Some of the easier ways to do this are described in
section
The most important thing about monitoring system use is that it
done on a regular basis. Picking one day out of the month
monitor the system is pointless, since a security breach can
isolated to a matter of hours. Only by maintaining a
Site Security Policy Handbook Working Group [Page 27]
RFC 1244 Site Security Handbook July 1991
vigil can you expect to detect security violations in time
react to them
3.6.2 Tools for Monitoring the
This section describes tools and methods for monitoring a
against unauthorized access and use
3.6.2.1
Most operating systems store numerous bits of information
log files. Examination of these log files on a regular
is often the first line of defense in detecting
use of the system
- Compare lists of currently logged in users and
login histories. Most users typically log in and
at roughly the same time each day. An account
in outside the "normal" time for the account may be
use by an intruder
- Many systems 