Abstract

Each RFC is designated by an RFC number. Once published, an RFC never changes.
Modifications to an original RFC are assigned a new RFC number
This guide is only a framework for setting security policies and procedures. In order to
have an effective set of policies and procedures, a site will have to make many decisions,
gain agreement, and then communicate and implement these policies.

RFC

Short for Request for Comments, a series of notes about the Internet, started in 1969 (when
the Internet was the ARPANET). An Internet Document can be submitted to the IETF by
anyone, but the IETF decides if the document becomes an RFC. Eventually, if it gains
enough interest, it may evolve into an Internet standard.

RFC2196

Definition

The "Internet" is a collection of thousands of networks linked by a common set of

technical protocols which make it possible for users of any one of the networks to
communicate with, or use the services located on, any of the other networks (FYI4, RFC
1594). The term "administrator" is used to cover all those people who are responsible for
the day-to-day operation of system and network resources. This may be a number of
individuals or an organization. The term "security administrator" is used to cover all those
people who are responsible for the security of information and information technology. At
some sites this function may be combined with administrator (above); at others, this will
be a separate position. The term "decision maker" refers to those people at a site who set
or approves policy. These are often (but not always) the people who own their source.

Basic Approach

One generally accepted approach to follow is suggested by Fites, et. al. [Fites 1989] and
includes the following steps:

(1) Identify what you are trying to protect.

(2) Determine what you are trying to protect it from.
(3) Determine how likely the threats are.
(4) Implement measures which will protect your assets in a cost- effective manner.
(5) Review the process continuously and make improvements each time a weakness is
found.

1
Risk Assessment

A full treatment of risk analysis is outside the scope of this document. [Fites 1989] and
[Pfleeger 1989] provide introductions to this topic. However, there are two elements of a
risk analysis that will be briefly covered in the next two sections:

(1) Identifying the assets

(2) Identifying the threats

For each asset, the basic goals of security are availability, confidentiality, and integrity.
Each threat should be examined with an eye to how the threatcould affect these areas.

Identifying the Assets

One list of categories is suggested by Pfleeger [Pfleeger 1989]; this list is adapted from
that source:

(1) Hardware: CPUs, boards, keyboards, terminals, workstations, personal computers,

printers, disk drives, communication lines, terminal servers, routers.
(2) Software: source programs, object programs, utilities, diagnostic programs, operating
systems, and communication programs.
(3) Data: during execution, stored on-line, archived off-line, backups, audit logs,
databases, in transit over communication media.
(4) People: users, administrators, hardware maintainers.
(5) Documentation: on programs, hardware, systems, and local administrative procedures.
(6)Supplies: paper, forms, ribbons, magnetic media

Identifying the Threats

(1) Unauthorized access to resources and/or information

(2) Unintended and/or unauthorized Disclosure of information
(3) Denial of service

Security Policies

Goals will be largely determined by the following key tradeoffs:

(1) Services offered versus security provided - Each service offered to users carries its
own security risks. For some services the risk outweighs the benefit of the service and the
administrator may choose to eliminate the service rather than try to secure it.

(2) Ease of use versus security - The easiest system to use would allow access to any user
and require no passwords; that is, there would be no security. Requiring passwords makes

2
the system a little less convenient, but more secure. Requiring device-generated one-time
passwords makes the system even more difficult to use, but much more secure.

(3) Cost of security versus risk of loss - There are many different costs to security:
monetary (i.e., the cost of purchasing security hardware and software like firewalls and
one-time password generators), performance (i.e., encryption and decryption take time),
and ease of use (as mentioned above). There are also many levels of risk: loss of privacy
(i.e., the reading of information by unauthorized individuals), loss of data (i.e., the
corruption or erasure of information), and the loss of service (e.g., the filling of data
storage space, usage of computational resources, and denial of network access). Each type
of cost must be weighed against each type of loss.

Your goals should be communicated to all users, operations staff, and managers through a
set of security rules, called a "security policy." We are using this term, rather than the
narrower "computer security policy" since the scope includes all types of information
technology and the information stored and manipulated by the technology

Definition of a Security Policy

A security policy is a formal statement of the rules by which people who are given access
to an organization's technology and information assets must abide.

Purposes of a Security Policy

The main purpose of a security policy is to inform users, staff and managers of their
obligatory requirements for protecting technology and information assets. The policy
should specify the mechanisms through which these requirements can be met. Another
purpose is to provide a baseline from which to acquire, configure and audit computer
systems and networks for compliance with the policy. Therefore an attempt to use a set of
security tools in the absence of at least an implied security policy is meaningless. An
Appropriate Use Policy (AUP) may also be part of a security policy. It should spell out
what users shall and shall not do on the various components of the system, including the
type of traffic allowed on the networks. The AUP should be as explicit as possible to
avoid ambiguity or misunderstanding. For example, an AUP might list any prohibited
USENET newsgroups.

Who should be Involved When Forming Policy?

The following is a list of individuals who should be involved in the creation and review of
security policy documents:

(1) Site security administrator

(2) Information technology technical staff (e.g., staff from computing center)
(3) Administrators of large user groups within the organization (e.g., business divisions,
computer science department within a university, etc.)
(4) Security incident response team

3
(5) Representatives of the user groups affected by the security policy
(6) Responsible management
(7) Legal counsel
What Makes a Good Security Policy?

The characteristics of a good security policy are:

(1) It must be implement able through system administration procedures, publishing of

acceptable use guidelines, or other appropriate methods.
(2) It must be enforceable with security tools, where appropriate, and with sanctions,
where actual prevention is not technically feasible.
(3) It must clearly define the areas of responsibility for the users, administrators, and
management.

The components of a good security policy include:

(1) Computer Technology Purchasing Guidelines, which specify required, or preferred,

security features. These should supplement existing purchasing policies and guidelines.

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

(3) An Access Policy, which defines access rights and privileges to protect assets from
loss or disclosure by specifying acceptable use guidelines for users, operations staff, and
management. It should provide guidelines for external connections, data communications,
connecting devices to a network, and adding new software to systems. It should also
specify any required notification messages (e.g., connect messages should provide
warnings about authorized usage and line monitoring, and not simply say "Welcome").

(4) An Accountability Policy that defines the responsibilities of users, operations staff, and
management. It should specify an audit capability, and provide incident handling
guidelines (i.e., what to do and who to contact if a possible intrusion is detected).
(5) An Authentication Policy which establishes trust through an effective password policy,
and by setting guidelines for remote location authentication and the use of authentication
devices (e.g., one-time passwords and the devices that generate them).
(6) An Availability statement, which sets users' expectations for the availability of
resources. It should address redundancy and recovery issues, as well as specify operating
hours and maintenance downtime periods. It should also include contact information for
reporting system and network failures.
(7) An Information Technology System & Network Maintenance Policy which describes
how both internal and external maintenance people are allowed to handle and access
technology. One important topic to be addressed here is whether remote maintenance is
allowed and how such access is controlled. Another area for consideration here is
outsourcing and how it is managed.
(8) A Violations Reporting Policy that indicates which types of violations (e.g., privacy
and security, internal and external) must be reported and to whom the reports are made. A

4
non- threatening atmosphere and the possibility of anonymous reporting will result in a
greater probability that a violation will be reported if it is detected.

(9) Supporting Information which provides users, staff, and management with contact
information for each type of policy violation; guidelines on how to handle outside queries
about a security incident, or information which may be considered confidential or
proprietary; and cross-references to security procedures and related information, such as
company policies and governmental laws and regulations. There may be regulatory
requirements that affect some aspects of your security policy (e.g., line monitoring). The
creators of the security policy should consider seeking legal assistance in the creation of
the policy. At a minimum, legal counsel should review the policy. Once your security
policy has been established it should be clearly communicated to users, staff, and
management. Having all personnel sign a statement indicating that they have read,
understood, and agreed to abide by the policy is an important part of the process. Finally,
your policy should be reviewed on a regular basis to see if it is successfully supporting
yoursecurityneeds.

Completely Defined Security Plans

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

A security plan should define: the list of network services that will be provided; which
areas of the organization will provide the services; who will have access to those services;
how access will be provided; who will administer those services; etc.

The plan should also address how incident will be handled. but it is important for each site
to define classes of incidents and corresponding responses. For example, sites with
firewalls should set a threshold on the number of attempts made to foil the firewall before
triggering a response? Escallation levels should be defined for both attacks and responses.

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

Architecture
Completely Defined Security Plans

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

A security plan should define: the list of network services that will be provided; which
areas of the organization will provide the services; who will have access to those services;
how access will be provided; who will administer those services; etc.

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

There are many services that a site may wish to provide for its users, some of which may
be external. There are a variety of security reasons to attempt to isolate services onto
dedicated host computers.

Deny all/ allow all

There are two diametrically opposed underlying philosophies that can be adopted when
defining a security plan. Both alternatives are legitimate models to adopt, and the choice
between them will depend on the site and its needs for security.
The first option is to turn off all services and then selectively enable services on a case-by-
case basis, as they are needed. This can be done at the host or network level as
appropriate. This model, which will here after be referred to as the "deny all" model, is
generally more secure than the other model described in the next paragraph. More work is
required to successfully implement a "deny all" configuration as well as a better
understanding of services.
Allowing only known services provides for a better analysis of a particular
service/protocol and the design of a security mechanism suited to the security level of the
site. The other model, which will here after be referred to as the "allow all" model, is
much easier to implement, but is generally less secure than the "deny all" model. Simply
turn on all services, usually the default at the host level, and allow all protocols to travel
across network boundaries, usually the default at the router level. As security holes
become apparent, they are restricted or patched at either the host or network level. Each of
these models can be applied to different portions of the site, depending on functionality
requirements, administrative control, site policy, etc.

For example, the policy may be to use the "allow all" model when setting up workstations
for general use, but adopt a "deny all" model when setting up information servers, like an
email hub. Likewise, an "allow all" policy may be adopted for traffic between LAN's
internal to the site, but a "deny all" policy can be adopted between the site and the
Internet. Be careful when mixing philosophies as in the examples above. Many sites adopt
the theory of a hard "crunchy" shell and a soft "squishy" middle. They are willing to pay

6
the cost of security for their external traffic and require strong security measures, but are
unwilling or unable to provide similar protections internally. This works fine as long as
the outer defenses are never breached and the internal users can be trusted. Once the outer
shell (firewall) is breached, subverting the internal network is trivial

REFERENCES

http://www.faqs.org/rfcs/rfc2196.html

RFC 2828

Introduction

7
This Glossary provides an internally consistent, complementary set of abbreviations,
definitions, explanations, and recommendations for use of terminology related to
information system security. The intent of this Glossary is to improve the
comprehensibility of Internet Standards documents (ISDs)--i.e., RFCs, Internet-Drafts,
and other material produced as part of the Internet Standards Process [R2026]and of all
other Internet material, too. Some non-security terms are included to make the Glossary
self-contained, but more complete lists of networking terms are available elsewhere
[R1208, R1983]. Some glossaries (e.g., [Raym]) list terms that are not listed here
but could be applied to Internet security. However, those terms have not been included in
this Glossary because they are not appropriate for ISDs. This Glossary marks terms and
definitions as being either endorsed or deprecated for use in ISDs, but this Glossary is not
an Internet standard. The key words "SHOULD","SHOULDNOT","RECOMMENDED",
"MAY", and "OPTIONAL" are intended to be interpreted the same way as in an
Internet Standard [R2119], but this guidance represents only the recommendations of this
author. However, this Glossary includes reasons for the recommendations--particularly for
the SHOULD NOTs—so that readers can judge.

Clear, Concise, and Easily Understood Documentation

This Glossary seeks to improve comprehensibility of security related content of ISDs.

That requires wording to be clear and understandable, and requires the set of security-
related terms and definitions to be consistent and self-supporting. Also, the terminology
needs to be uniform across all ISDs; i.e., the same term or definition needs to be used
whenever and wherever the same concept is mentioned. Harmonization of existing ISDs
need not be done immediately, but it is desirable to correct and standardize the
terminology when new versions are issued in the normal course of standards development
and evolution.

Technical Excellence

Just as Internet Standard (STD) protocols should operate effectively, ISDs should use
terminology accurately, precisely, and unambiguously to enable Internet Standards to be
implemented
Correctly.

Prior Implementation and Testing

Just as STD protocols require demonstrated experience and stability before adoption, ISDs
need to use well-established language. Using terms in their plainest, dictionary sense
(when appropriate) helps to ensure international understanding. ISDs need to avoid using

8
private, made-up terms in place of generally accepted terms from standards and
other publications. ISDs need to avoid substituting new definitions that
conflict with established ones. ISDs need to avoid using "cute" synonyms (e.g., see: Green
Book); no matter how popular a nickname may be in one community, it is likely to cause
confusion in another.

Openness, Fairness, and Timeliness

ISDs need to avoid terms that are proprietary or otherwise favor a particular vendor, or
that create a bias toward a particular security technology or mechanism over other,
competing techniques that already exist or might be developed in the future. The set of
terminology used across the set of ISDs needs to be flexible and adaptable as the state of
Internet security art evolves.

Explanation of Paragraph Markings

Other Definitions ("O")

The paragraph marking "O" indicates a definition that has a non- Internet basis, but
indicates that the definition SHOULD NOT be used in ISDs *except* in cases where the
term is specifically identified as non-Internet.

For example, an ISD might mention "BCA" (see: brand certification authority) or
"baggage" as an example to illustrate some concept; in that case, the document should
specifically say "SET (trademark) BCA" or "SET (trademark) baggage" and include the
definition of the term.
For some terms that have a definition published by a non-Internet authority--government
(see: object reuse), industry (see: Secure Data Exchange), national (see: Data Encryption
Standard), or international (see: data confidentiality)--this Glossary marks the definition
"N", recommending its use in Internet documents. In other cases, the non- Internet
definition of a term is inadequate or inappropriate for ISDs. For example, it may be
narrow or outdated, or it may need clarification by substituting more careful or more

9
explanatory wording using other terms that are defined in this Glossary. In those cases,
this Glossary marks the tern "O" and provides an "I" definition (or sometimes a different
"N" definition), which precedes and supersedes the definition marked "O".

Deprecated Terms, Definitions, and Uses ("D")

If this Glossary recommends that a term or definition SHOULD NOT be used in ISDs,
then either the definition has the paragraph marking "D", or the restriction is stated in a
"D" paragraph that immediately follows the term or definition.

Commentary and Additional Guidance ("C")

The paragraph marking "C" identifies text that is advisory or tutorial. This text MAY be
reused in other Internet documents. This text is not intended to be authoritative, but is
provided to clarify the definitions and to enhance this Glossary so that Internet security
novices can use it

Definitions

Access control

(I) Protection of system resources against unauthorized access; a process by which

use of system resources is regulated according to a security policy and is
permitted by only authorized entities

Access control center (ACC)

(I) A computer containing a database with entries that define a security policy for an
access control service.

(C) An ACC is sometimes used in conjunction with a key center to implement access
control in a key distribution system for symmetric cryptography.

Access control list (ACL)

(I) A mechanism that implements access control for a system resource by

enumerating the identities of the system entities that are permitted to access the
resource. (See: capability.)

Access mode

(I) A distinct type of data processing operation--e.g., read, write, append, or

execute--that a subject can potentially perform on an object in a computer
system.
Access control service

10
 (I) A security service that protects against a system entity using a system resource
in a way not authorized by the system’s security policy; in short, protection of
system resources against unauthorized access. (See: access control,
discretionary access control, identity-based security policy, mandatory access
control, and rule-based security policy.)

(C) This service includes protecting against use of a resource in an unauthorized

manner by an entity that is authorized to use the resource in some other manner. The
two basic mechanisms for implementing this service are ACLs and tickets.

Accountability

(I) The property of a system (including all of its system resources) that ensures
that the actions of a system entity may be traced uniquely to that entity, which
can be held responsible for its actions. (See: audit service.)

(C) Accountability permits detection and subsequent investigation of security

breaches.

Administrative security

(I) Management procedures and constraints to prevent unauthorized access to a

system. (See: security architecture.)

(O) "The management constraints, operational procedures, accountability procedures,

and supplemental controls established to provide an acceptable level of protection for
sensitive data." [FP039]

(C) Examples include clear delineation and separation of duties, and configuration control.

Advanced Encryption Standard (AES)

(N) A future FIPS publication being developed by NIST to succeed DES. Intended to
specify an unclassified, publicly-disclosed, symmetric encryption algorithm, available
royalty-free worldwide

Attack

(I) An assault on system security that derives from an intelligent threat, i.e., an intelligent
act that is a deliberate attempt (especially in the sense of a method or technique) to evade
Security services and violate the security policy of a system. (See: penetration, violation,
vulnerability.)

11
 - Active vs. passive: An "active attack" attempts to alter system resources or
affect their operation. A "passive attack" attempts to learn or make use of
information from the system but does not affect system resources. (E.g.,
see: wiretapping.)

- Insider vs. outsider: An "inside attack" is an attack initiated by an entity

inside the security perimeter (an "insider"), i.e., an entity that is authorized
to access system resources but uses them in a way not approved by those
who granted the authorization. An "outside attack" is initiated from outside
the perimeter, by an unauthorized or illegitimate user of the system (an
"outsider"). In the Internet, potential outside attackers range from amateur
pranksters to organized criminals, international terrorists, and hostile
governments.

(C) The term "attack" relates to some other basic security terms as shown in the following
diagram:

Attribute authority

(I) A CA that issues attribute certificates.

(O) "An authority, trusted by the verifier to delegate privilege, which issues attribute
certificates." [FPDAM]

Authentication

(I) The process of verifying an identity claimed by or for a system entity. (See:
authenticate, authentication exchange, authentication information, credential, data origin
Authentication, peer entity authentication.)

(C) An authentication process consists of two steps:

12
 1. Identification step: Presenting an identifier to the security system.
(Identifiers should be assigned carefully, because authenticated identities are the basis for
other security Services, such as access control service.)

2. Verification step: Presenting or generating authentication information

that corroborates the binding between the entity and the identifier. (See: verification.)

(C) See: ("relationship between data integrity service and authentication services" under)
data integrity service.

Certification

(I) Information system usage: Technical evaluation (usually made in support of an

accreditation action) of an information system’s security features and other safeguards to
establish the extent to which the system’s design and implementation meet specified
Security requirements. [FP102] (See: accreditation.)

(I) Digital certificate usage: The act or process of vouching for the truth and
accuracy of the binding between data items in a certificate. (See: certify.)

(I) Public key usage: The act or process of vouching for the ownership of a public
key by issuing a public-key certificate that binds the key to the name of the
entity that possesses the matching private key. In addition to binding a key to a
name, a public-key certificate may bind those items to other restrictive or
explanatory data items. (See: X.509 public-key certificate.).

(O) SET usage: "The process of ascertaining that a set of requirements or criteria has been
fulfilled and attesting to that fact to others, usually with some written instrument. A
system that has been inspected and evaluated as fully compliant with the SET protocol by
duly authorized parties and process would be said to have been certified compliant."

Classification level

(I) (1.) A grouping of classified information to which a hierarchical, restrictive security

label is applied to increase protection of the data. (2.) The level of protection that is
Required to be applied to that information. (See: security level.)

Computer security (COMPUSEC)

(I) Measures that implement and assure security services in a compute system,
particularly those that assure access control service.

(C) Usually understood to include functions, features, and technical characteristics of

computer hardware and software, especially operating systems.

Cryptanalysis

13
(I) The mathematical science that deals with analysis of a cryptographic system in order to
gain knowledge needed to break or circumvent the protection that the system is designed
to provide.
(See: cryptology.)
(O) "The analysis of a cryptographic system and/or its inputs and outputs to derive
confidential variables and/or sensitive data including clear text."

(C) The "O" definition states the traditional goal of cryptanalysis--convert the cipher text
to plaintext (which usually is clear text) without knowing the key--but that definition
applies only to encryption systems. Today, the term is used with reference to all kinds of
cryptographic algorithms and key management, and the "I" definition reflects that. In all
cases, however, a cryptanalyst tries to uncover or reproduce someone else’s sensitive data,
such as clear text, a key, or an algorithm. The basic cryptanalytic attacks on encryption
systems are ciphertextonly, known-plaintext, chosen-plaintext, and chosen-cipher text; and
these generalize to the other kinds of cryptography.

Cryptography

The mathematical science that deals with transforming data to render its meaning
unintelligible (i.e., to hide its semantic content), prevent its undetected alteration, or
prevent its unauthorized use. If the transformation is reversible, cryptography also deals
with restoring encrypted data to intelligible form. (See: cryptology, steganography.)

"The discipline which embodies principles, means, and methods for the transformation of
data in order to hide its information content, prevent its undetected modification and/or
prevent its unauthorized use. . . . Cryptography determines the methods used in
encipherment and decipherment."

Data integrity service

A security service that protects against unauthorized changes to data, including both
intentional change or destruction and accidental change or loss, by ensuring that changes
to data are detectable. (See: data integrity.)

A data integrity service can only detect a change and report it to an appropriate system
entity; changes cannot be prevented unless the system is perfect (error-free) and no
malicious user has access. However, a system that offers data integrity service might also
attempt to correct and recover from changes.

Relationship between data integrity service and authentication services: Although data
integrity service is defined separately from data origin authentication service and peer
entity authentication service, it is closely related to them.

Authentication services depend, by definition, on companion data integrity services. Data

origin authentication service provides verification that the identity of the original source of
a received data unit is as claimed; there can be no such verification if the data unit has
been altered

14
Privacy

(I) The right of an entity (normally a person), acting in its own behalf, to determine the
degree to which it will interact with its environment, including the degree to which the
entity is willing to share information about itself with others. (See: anonymity.)

(O) "The right of individuals to control or influence what information related to them may
be collected and stored and by whom and to whom that information may be disclosed."

Protocol

(I) A set of rules (i.e., formats and procedures) to implement and control some
type of association (e.g., communication) between systems. (E.g., see: Internet
Protocol.)

(C) In particular, a series of ordered steps involving computing and communication that
are performed by two or more system entities to achieve a joint objective.

Request for Comment (RFC)

(I) One of the documents in the archival series that is the official channel for ISDs
and other publications of the Internet Engineering Steering Group, the Internet
Architecture Board, and the Internet community in general (See: Internet
tandard.)

(C) This term is *not* a synonym for "Internet Standard".

Secure Sockets Layer (SSL)

(N) An Internet protocol (originally developed by Netscape Communications, Inc.) that

uses connection-oriented end-to-end encryption to provide data confidentiality service and
data integrity service for traffic between a client (often a web browser) and a server, and
that can optionally provide peer entity authentication between the client and the server.
(See: Transport Layer Security.)

(C) SSL is layered below HTTP and above a reliable transport protocol (TC). SSL is
independent of the application it encapsulates, and any higher level protocol can layer on
top of SSL transparently. However, many Internet applications might be
Better served by IPsec.

(C) SSL has two layers: (a) SSL’s lower layer, the SSL Record Protocol, is layered on top
of the transport protocol and encapsulates higher level protocols. One such encapsulated
Protocol is SSL Handshake Protocol. (b) SSL’s upper layer provides asymmetric
cryptography for server authentication (verifying the server’s identity to the client) and
optional client authentication (verifying the client’s identity to the server), and also

15
enables them to negotiate a symmetric encryption algorithm and secret session key (to use
for data confidentiality) before the application protocol transmits or receives data. A
keyed hash provides data integrity service for encapsulated data.

REFERENCES

http://www.faqs.org/rfcs/rfc2828.html

16