abstract each rfc is designated by an

8/14/2019 Abstract Each RFC is Designated by An

1/16

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 tohave 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 forRequest 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 oftechnical 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 ofindividuals 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 setor 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


2/16

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 arisk 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, operatingsystems, 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 theadministrator 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 userand require no passwords; that is, there would be no security. Requiring passwords makes

2


3/16

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 andone-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 datastorage 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 informationtechnology 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 computersystems 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 outwhat 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 prohibitedUSENET newsgroups.

Who should be Involved When Forming Policy?

The following is a list of individuals who should be involved in the creation and review ofsecurity 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


4/16

(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, andmanagement.

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 isallowed 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., privacyand security, internal and external) must be reported and to whom the reports are made. A

4


5/16

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 queriesabout 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). Thecreators 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, andmanagement. 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 supportingyoursecurityneeds.

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 anoverall philosophy of strong security restrictions on external access.

A security plan should define: the list of network services that will be provided; whichareas 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 siteto 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 securityproblem. 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


6/16

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 regardto 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 ontodedicated 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, isgenerally 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, ismuch 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 ofthese 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'sinternal 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


7/16

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 asthe 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


8/16

This Glossary provides an internally consistent, complementary set of abbreviations,

definitions, explanations, and recommendations for use of terminology related toinformation 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 allother 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 inthis 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 forthe SHOULD NOTsso 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 ISDsneed 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

implementedCorrectly.

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


9/16

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: GreenBook); 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 ofterminology 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 shouldspecifically 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- Internetdefinition 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


10/16

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 bereused 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 whichuse 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 anaccess control service.

(C) An ACC is sometimes used in conjunction with a key center to implement accesscontrol 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


11/16

(I) A security service that protects against a system entity using a system resourcein a way not authorized by the systems security policy; in short, protection of

system resources against unauthorized access. (See: access control,

discretionary access control, identity-based security policy, mandatory accesscontrol, 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. Thetwo 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, whichcan be held responsible for its actions. (See: audit service.)

(C) Accountability permits detection and subsequent investigation of securitybreaches.

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, availableroyalty-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


12/16

- Active vs. passive: An "active attack" attempts to alter system resources or

affect their operation. A "passive attack" attempts to learn or make use ofinformation 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 outsidethe 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 hostilegovernments.

(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


13/16

1. Identification step: Presenting an identifier to the security system.

(Identifiers should be assigned carefully, because authenticated identities are the basis forother security Services, such as access control service.)

2. Verification step: Presenting or generating authentication informationthat 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 systems security features and other safeguards to

establish the extent to which the systems design and implementation meet specifiedSecurity 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 theentity 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 byduly 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 isRequired 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


14/16

(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 designedto provide.

(See: cryptology.)

(O) "The analysis of a cryptographic system and/or its inputs and outputs to deriveconfidential 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 definitionapplies 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 elses 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 meaningunintelligible (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 changesto data are detectable. (See: data integrity.)

A data integrity service can only detect a change and report it to an appropriate systementity; 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 dataintegrity 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 ofa received data unit is as claimed; there can be no such verification if the data unit has

been altered

14


15/16

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 theentity 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: InternetProtocol.)

(C) In particular, a series of ordered steps involving computing and communication thatare 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: Internettandard.)

(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 isindependent 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) SSLs 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) SSLs upper layer provides asymmetriccryptography for server authentication (verifying the servers identity to the client) and

optional client authentication (verifying the clients identity to the server), and also

15


16/16

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. Akeyed hash provides data integrity service for encapsulated data.

REFERENCES

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

16

abstract each rfc is designated by an

Documents