The NIST Computer User’s Guide to the Protection of Information Resources

Computer User’s Guide to the Protection of Information
Resources

National Institute of Standards and Technology
The National Institute of Standards and Technology (NIST) is
responsible or developing standards, providing technical
assistance, and conducting research for computers and related
systems. These activities provide technical support to government
and industry in the effective, safe, and economical use of
computers. With the passage of the Computer Security
Act of 1987 (P.L. 100-235), NIST’s activities also include the
development of standards and guidelines needed to assure the
cost-effective security and privacy of sensitive information in
Federal computer systems. This guide is just one of three
brochures designed for a specific audience. The “Executive Guide
to the Protection of Information Resources,” and the “Managers
Guide to the Protection of Information Resources” complete the
series.

ACKNOWLEDGMENTS
This guide was written by Cheryl Helsing of Deloitte, Haskins &
Sells in conjunction with Marianne Swanson and Mary Anne Todd of
the National Institute of Standards and Technology.

Introduction
Today’s computer technology, with microcomputers and on-line
access, has placed the power of the computer where it belongs, in
YOUR hands. YOU, the users, develop computer applications and
perform other data processing functions which previously were
only done by the computer operations personnel. These advances
have greatly improved our efficiency and effectiveness but, also
present a serious challenge in achieving adequate data security.

While excellent progress has been made in computer technology,
very little has been done to inform users of the vulnerability of
data and information to such threats as unauthorized
modification, disclosure, and destruction, either deliberate or
accidental. This guide will make you aware of some of the
undesirable things that can happen to data and will provide some
practical solutions for reducing your risks to these threats.

WHO IS RESPONSIBLE FOR PROTECTING DATA AND INFORMATION?
The statement that “security is everyone’s responsibility” is
absolutely true. Owners, developers, operators and users of
information systems each has a personal responsibility to protect
these resources. Functional managers have the responsibility to
provide appropriate security controls for any information
resources entrusted to them. These managers are personally
responsible for understanding the sensitivity and criticality of
their data and the extent of losses that could occur if the
resources are not protected. Managers must ensure that all users
of their data and systems are made aware of the practices and
procedures used to protect the information resources. When you
don’t know what your security responsibilities are, ASK YOUR
MANAGER OR SUPERVISOR.
WHAT IS “SENSITIVE” DATA?
All data is sensitive to some degree; exactly how sensitive is
unique to each business environment. Within the Federal
Government, personal information is sensitive to unauthorized
disclosure under the Privacy Act of 1974. In some cases, data is
far more sensitive to accidental errors or omissions that
compromise accuracy, integrity, or availability. For example, in
a Management Information System, inaccurate, incomplete, or
obsolete information can result in erroneous management decisions
which could cause serious damage and require time and money to
rectify. Data and information which are critical to an agency’s
ability to perform its mission are sensitive to nonavailability.

Still other data are sensitive to fraudulent manipulation for
personal gain. Systems that process electronic funds transfers,
control inventories, issue checks, control accounts receivables
and payables, etc., can be fraudulently exploited resulting in
serious losses to an agency.
One way to determine the sensitivity of data is to ask the
questions “What will it cost if the data is wrong? Manipulated
for fraudulent purposes? Not available? Given to the wrong
person?” If the damage is more than you can tolerate, then the
data is sensitive and should have adequate security controls to
prevent or lessen the potential loss.

WHAT RISKS ARE ASSOCIATED WITH THE USE OF COMPUTERS?
Over the past several decades, computers have taken over
virtually all of our major record-keeping functions. Recently,
personal computers have made it cost-effective to automate many
office functions. Computerization has many advantages and is here
to stay; however, automated systems introduce new risks, and we
should take steps to control those risks.
We should be concerned with the same risks that existed when
manual procedures were used, as well as some new risks created by
the unique nature of computers themselves. One risk introduced by
computers is the concentration of tremendous amounts of data in
one location. The greater the concentration, the greater the
consequences of loss or damage. Another example is that computer
users access information from remote terminals. We must be able
to positively identify the user, as well as ensure that the user
is only able to access information and functions that have been
authorized. Newspaper accounts of computer “hackers,” computer
virus attacks, and other types of intruders underscore the
reality of the threat to government and commercial computer
systems.

HOW MUCH SECURITY IS ENOUGH?
No matter how many controls or safeguards we use, we can never
achieve total security. We can, however, decrease the risk in
proportion to the strength of the protective measures. The degree
of protection is based on the value of the information; in other
words, how serious would be the consequences if a certain type of
information were to be wrongfully changed, disclosed, delayed, or
destroyed?

General Responsibilities
All Federal computer system users share certain general
responsibilities for information resource protection. The
following considerations should guide your actions.

Treat information as you would any valuable asset.
You would not walk away from your desk leaving cash or other
valuables unattended. You should take the same care to protect
information. If you are not sure of the value or sensitivity of
the various kinds of information you handle, ask your manager for
guidance.

Use government computer systems only for lawful and authorized
purposes.
The computer systems you use in your daily work should be used
only for authorized purposes and in a lawful manner. There are
computer crime laws that prescribe criminal penalties for those
who illegally access Federal computer systems or data.
Additionally, the unauthorized use of Federal computer systems or
use of authorized privileges for unauthorized purposes could
result in disciplinary action.

Observe policies and procedures established by agency
management.
Specific requirements for the protection of information have been
established by your agency. These requirements may be found in
policy manuals, rules, or procedures. Ask your manager if you are
unsure about your own responsibilities for protection of
information.

Recognize that you are accountable for your activities on
computer systems.
After you receive authorization to use any Federal computer
system, you become personally responsible and accountable for
your activity on the system. Accordingly, your use should be
restricted to those functions needed to carry out job
responsibilities.

Report unusual occurrences to your manager.
Many losses would be avoided if computer users would report any
circumstances that seem unusual or irregular. Warning signals
could include such things as unexplainable system activity that
you did not perform, data that appears to be of questionable
accuracy, and unexpected or incorrect processing results. If you
should notice anything of a questionable nature, bring it to your
manager’s attention.

Security and Control Guidelines
Some common-sense protective measures can reduce the risk of
loss, damage, or disclosure of information. Following are the
most important areas of information systems controls that assure
that the system is properly used, resistant to disruptions, and
reliable.

Make certain no one can impersonate you.
If a password is used to verify your identity, this is the key to
system security. Do not disclose your password to anyone, or
allow anyone to observe your password as you enter it during the
sign-on process. If you choose your own password, avoid selecting
a password with any personal associations, or one that is very
simple or short. The aim is to select a password that would be
difficult to guess or derive. “1REDDOG” would be a better
password than “DUKE.”
If your system allows you to change your own password, do so
regularly. Find out what your agency requires, and change
passwords at least that frequently. Periodic password changes
keep undetected intruders from continuously using the password of
a legitimate user.

After you are logged on, the computer will attribute all activity
to your user id. Therefore, never leave your terminal without
logging off — even for a few minutes. Always log off or
otherwise inactivate your terminal so no one could perform any
activity under your user id when you are away from the area.

Safeguard sensitive information from disclosure to others.
People often forget to lock up sensitive reports and computer
media containing sensitive data when they leave their work areas.
Information carelessly left on top of desks and in unlocked
storage can be casually observed, or deliberately stolen. Every
employee who works with sensitive information should have
lockable space available for storage when information is not in
use. If you aren’t sure what information should be locked up or
what locked storage is available, ask your manager.

While working, be aware of the visibility of data on your
personal computer or terminal display screen. You may need to
reposition equipment or furniture to eliminate over-the-shoulder
viewing. Be especially careful near windows and in public areas.
Label all sensitive diskettes and other computer media to alert
other employees of the need to be especially careful. When no
longer needed, sensitive information should be deleted or
discarded in such a way that unauthorized individuals cannot
recover the data. Printed reports should be finely shredded,
while data on magnetic media should be overwritten. Files that
are merely deleted are not really erased and can still be
recovered.

Install physical security devices or software on personal
computers.
The value and popularity of personal computers make theft a big
problem, especially in low-security office areas. Relatively
inexpensive hardware devices greatly reduce the risk of equipment
loss. Such devices involve lock-down cables or enclosures that
attach equipment to furniture. Another approach is to place
equipment in lockable cabinets.
When data is stored on a hard disk, take some steps to keep
unauthorized individuals from accessing that data. A power lock
device only allows key-holders to turn on power to the personal
computer. Where there is a need to segregate information between
multiple authorized users of a personal computer, additional
security in the form of software is probably needed. Specific
files could be encrypted to make them unintelligible to
unauthorized staff, or access control software can divide storage
space among authorized users, restricting each user to their own
files.

Avoid costly disruptions caused by data or hardware loss.
Disruptions and delays are expensive. No one enjoys working
frantically to re-enter work, do the same job twice, or fix
problems while new work piles up. Most disruptions can be
prevented, and the impact of disruptions can be minimized by
advance planning. Proper environmental conditions and power
supplies minimize equipment outages and information loss. Many
electrical circuits in office areas do not constitute an adequate
power source, so dedicated circuits for computer systems should
be considered. Make certain that your surroundings meet the
essential requirements for correct equipment operation. Cover
equipment when not in use to protect it from dust, water leaks,
and other hazards.

For protection from accidental or deliberate destruction of data,
regular data backups are essential. Complete system backups
should be taken at intervals determined by how quickly
information changes or by the volume of transactions. Backups
should be stored in another location, to guard against the
possibility of original and backup copies being destroyed by the
same fire or other disaster.

Maintain the authorized hardware/software configuration.
Some organizations have been affected by computer “viruses”
acquired through seemingly useful or innocent software obtained
from public access bulletin boards or other sources; others have
been liable for software illegally copied by employees. The
installation of unauthorized hardware can cause damage,
invalidate warranties, or have other negative consequences.
Install only hardware or software that has been acquired through
normal acquisition procedures and comply with all software
licensing agreement requirements.

SUMMARY
Ultimately, computer security is the user’s responsibility. You,
the user, must be alert to possible breaches in security and
adhere to the security regulations that have been established
within your agency. The security practices listed are not
inclusive, but rather designed to remind you and raise your
awareness towards securing your information resources:

PROTECT YOUR EQUIPMENT
Keep it in a secure environment
Keep food, drink, and cigarettes AWAY from it
Know where the fire suppression equipment is located and know
how to use it

PROTECT YOUR AREA
Keep unauthorized people AWAY from your equipment and data
Challenge strangers in your area

PROTECT YOUR PASSWORD
Never write it down or give it to anyone
Don’t use names, numbers or dates which are personally
identified with you
Change it often, but change it immediately if you think it has
been compromised

PROTECT YOUR FILES
Don’t allow unauthorized access to your files and data
NEVER leave your equipment unattended with your password
activated – SIGN OFF!

PROTECT AGAINST VIRUSES
Don’t use unauthorized software
Back up your files before implementing ANY new software

LOCK UP STORAGE MEDIA CONTAINING SENSITIVE DATA
If the data or information is sensitive or critical to your
operation, lock it up!

BACK UP YOUR DATA
Keep duplicates of your sensitive data in a safe place, out of
your immediate area
Back it up as often as necessary

REPORT SECURITY VIOLATIONS
Tell your manager if you see any unauthorized changes to your
data
Immediately report any loss of data or programs, whether
automated or hard copy

For Additional Information
National Institute of Standards and Technology
Computer Security Program Office
A-216 Technology
Gaithersburg, MD 20899
(301) 975-5200

For further information on the management of information
resources, NIST publishes Federal Information Processing
Standards Publications (FIBS PUBS). These publications deal with
many aspects of computer security, including password usage, data
encryption, ADP risk management and contingency planning, and
computer system security certification and accreditation. A list
of current publications is available from:

Standards Processing Coordinator (ADP)
National Computer Systems Laboratory
National Institute of Standards and Technology
Technology Building, B-64
Gaithersburg, MD 20899
Phone: (301) 975-2817
����������������������������������������������������������������������������������������������

Review of Federal Agency Computer Security and Privacy Plans

NCSL BULLETIN
OCTOBER, 1990

REVIEW OF FEDERAL AGENCY
COMPUTER SECURITY AND PRIVACY PLANS (CSPP): A SUMMARY REPORT

Sensitive information and information resources have become
increasingly important to the functioning of the federal
government. The protection of such information is integral to
the government serving the public trust. Concern that federal
agencies were not protecting their information caused Congress to
enact Public Law 100-235, “Computer Security Act of 1987” (the
Act). The Act reaffirmed the National Institute of Standards and
Technology’s (NIST) computer security responsibilities. These
responsibilities include developing standards and guidelines to
protect sensitive unclassified information. Other
responsibilities include providing new governmentwide programs in
computer security awareness training and security planning.

The Act required federal agencies to conduct educational programs
to increase staff awareness of the need for computer security.
The first-year activity included agencies identifying their
computer systems containing sensitive information. These
agencies prepared and submitted security plans for those systems
to the NIST and National Security Agency (NSA) review team for
advice and comment. This document summarizes a report on the
review of the computer security and privacy plans that were
submitted by federal agencies.

How The Reviews Were Conducted

The Office of Management and Budget (OMB) issued OMB Bulletin 88-
16, “Guidance for Preparation and Submission of Security Plans
for Federal Computer Systems Containing Sensitive Information,”
to guide agencies on preparing and submitting computer security
plans. The bulletin specified the information that was to appear
in each plan. The bulletin further requested that agencies
identify systems as major application or general ADP support
systems. Finally, the bulletin provided the agency the option of
identifying any needs for guidance or technical support. This
option also included making any comments the agency thought
appropriate. Although a four-part format appeared, agencies were
able to use latitude as long as all pertinent information was
present. This permitted agencies with existing programs to
submit current related documents. Submission of an agency
overview was optional and most agencies chose not to provide one.

The joint NIST/NSA review team examined 1,583 plans for 63
federal civilian agencies and 27,992 plans from 441 Department of
Defense (DoD) organizations. Most DoD submissions consisted
mainly of accreditation documentation prepared for other computer
security planning purposes. During the review process, the
review team recorded data about the systems for analysis. The
conclusions made in this report stem principally, but not
exclusively, from the civilian agency submissions.

Major Findings

The review team arrived at a number of conclusions about the
plans and the plan review process, seeing both many positive
signs and some areas for improvement. These findings include:

o The civilian agency CSPPs basically conformed with the
guidance given by OMB Bulletin 88-16. Many controls to
protect sensitive systems were already in place or
planned. These controls appeared consistent with
identified system functions, environment, and security
needs. However, some respondents appeared to have just
“checked the boxes,” perhaps presenting a falsely
optimistic picture.

o Many agencies appeared to report on isolated systems
rather than all systems subject to the Computer
Security Act and OMB Bulletin 88-16.

o Agencywide guidance on how to prepare the plans was not
clear. There was also some question whether a high-
level official reviewed the plans. Also unclear is the
distribution of agency-level computer security policy
and guidance. Further, most plans did not reflect the
joint involvement of ADP, computer security, and
applications communities in computer security planning.

o Significantly, the plans rarely addressed the security
concerns on networking, interfaces with other systems,
and the use of contractors and their facilities. This
may reflect a general confusion about the boundaries
and limits of responsibility for a given system.

o Many plans equated sensitivity only with privacy or
confidentiality and did not fully address requirements
for integrity and availability.

o Most plans did not communicate an appreciation for the
role of risk management activities in computer security
planning.

o Although most agencies said they had computer security
awareness and training, many did not show that all
applicable employees received periodic training.

o Finally, the CSPP submission and review effort raised
the level of federal awareness regarding the need to
protect sensitive information and the importance of
computer security planning.

Recommendations for Agencies

Based on the needs that became apparent during the plan review,
the review team recommends the following:

o Agency management should ensure that computer security
has the highest level of management involvement. This
involvement is also important in the computer security
planning process. Computer security benefits from the
multiple perspectives of and input from agency
information resources management, computer security,
and functional, user, and applications personnel.

o Agency management should identify and describe the
security needs of their systems which contain sensitive
information.

o Agency management should recognize the importance of
computer security and its required planning. This
recognition should be aggressively communicated to
their staffs, perhaps using their computer security and
awareness training programs as one of the vehicles.

o Agencies should incorporate computer security planning
with other information systems planning activities.

o Agencies should consider the protection requirements
for integrity and availability on an equal basis with
that of confidentiality.

o Agencies should assess risks, and select and implement
realistic controls throughout the system life cycle.
This involves awareness of technology changes with
regard to system hardware and software. This awareness
also requires a knowledge of new technology and new
methods for protecting and recovering from system
threats. In addition, agencies should fully document
in-place controls to ease periodic reevaluation,
internal audit, and oversight agency review.

o Agencies should implement certification and
accreditation programs. There is a lack of awareness
of guidance regarding certification and accreditation,
including FIPS PUB 102, “Guideline for Computer
Security Certification and Accreditation.” There is
also a lack of knowledge of the certification
requirements in OMB Circular A-130, “Management of
Federal Information Resources.” Agencies may use OMB
Circular A-130 as the basis for these programs.

o Agencies should clarify the boundaries and limits of
responsibility for each system, and should include, in
any planned risk assessment activity, full
consideration of the telecommunications and networking
environment and relationships with contractors and
other organizations.

o Agencies should stress security awareness and training
for their employees. This includes all employees
involved in the design, management, development,
operation, or use of federal computer systems
containing sensitive information.

o Agencies should develop computer security policy and
operative guidance. Such policy and guidance should
fully reflect and comprehensively address an
encompassing view of computer security. The Computer
Security Act, OMB Circular A-130, and OMB Bulletins 88-
16 and 89-17, “Federal Information Systems and
Technology Planning,” and their successors all contain
this view. The policy should directly address the full
scope of computer security planning and risk management
activities. It must incorporate an application system
perspective and give more detailed consideration to
confidentiality, integrity, and availability protection
requirements.

What NIST is Doing

NIST is evolving a strategy for helping federal agencies in
identifying and protecting sensitive information systems. This
strategy shifts emphasis to the implementation of computer
security plans, particularly those developed under OMB Bulletin
88-16. It provides for visits by OMB, NIST, and NSA staff. This
group will provide direct comments, advice, and technical aid
focused on the agency’s implementation of the Act.

In addition to the agency visits described above, NIST has
initiated the following computer security projects to help
agencies more easily and effectively comply with the Computer
Security Act:

o NIST will develop standardized specifications and
language for federal government computer security
services contracts.

o NIST will develop a guidance document on computer
security in the ADP procurement cycle.

o NIST has recently published guidance on the use of
Trusted Systems.

o NIST will develop guidance on computer security
planning.

o NIST has developed, and will continue to operate, a
computer incident response center in order to address
viruses, worms, and other malicious software attacks.

o NIST will support and coordinate computer security
resource and response centers nationwide.

o NIST will enhance and operate the National Computer
Systems Laboratory (NCSL) Computer Security Bulletin
Board System.

o NIST will operate the NIST/NSA Risk Management
Laboratory and prepare further guidelines on risk
management.

o NIST will develop guidance and recommendations on
assuring information integrity in computer systems.

In addition to the above plans, NIST has already developed a
number of guidelines and other resources to help federal managers
secure their computer systems.

Future Directions

Federal managers have computer security requirements that are
similar to their counterparts in the private sector. We believe
that private sector organizations can learn and benefit from the
federal experience in implementing the Computer Security Act. In
both environments, a vigorous computer security awareness program
is important at all levels in the organization. Also, in both
environments, the active involvement of user, management, ADP,
and computer security communities in computer security planning
could help end some of the existing and potential barriers to
effective computer security. Such collective involvement would
also help ensure cost-effective control measures commensurate
with system function, system sensitivity, security requirements,
and analyzed and considered risks.

Agencies need to be aware of developments taking place in the
national and international standards arena on system
interoperability and data interchange. These developments will
impact information system product availability, protection
requirements, and protection alternatives as agencies do their
near-, mid-, and long-term IRM and computer security planning.

Finally, because agency awareness of problems is fundamental to
the solution, this project has been valuable. Computer security
officers say that the CSPP preparation and review activity has
raised the level of awareness in all parts of their organizations
and has made it easier for them to promote computer security.
The CSPP review project significantly raised the level of federal
awareness about the protection of sensitive information and the
importance of computer security planning. In the final analysis,
this contribution may be among the most meaningful results of the
project.

The complete report of the CSPP review project will be published
as an NIST Interagency Report (NISTIR), and will be available
from the National Technical Information Service (NTIS) U.S.
Department of Commerce, 5285 Port Royal Road, Springfield,
VA 22161. Telephone: (703) 487-4650 FTS 737-4650. For
information about the report findings, contact Dennis Gilbert,
National Institute of Standards and Technology, A216, Technology
Building, Gaithersburg, MD 20899. Telephone: (301) 975-3872.

Downloaded From P-80 International Information Systems 304-744-2253

The NIST Management Guide to the Protection of Information Resources

Management Guide to the Protection of Information
Resources

National Institute of Standards and Technology
The National Institute of Standards and Technology (NIST), is
responsible for developing standards, providing technical
assistance, and conducting research for computers and related
systems. These activities provide technical support to
government and industry in the effective, safe, and
economical use of computers. With the passage of the Computer
Security Act of 1987 (P.L. 100-235), NIST’s activities also
include the development of standards and guidelines needed to
assure the cost-effective security and privacy of sensitive
information in Federal computer systems. This guide represents
one activity towards the protection and management of sensitive
information resources.

Acknowledgments
This guide was written by Cheryl Helsing of Deloitte, Haskins &
Sells in conjunction with Marianne Swanson and Mary Anne Todd,
National Institute of Standards and Technology.

Executive Summary
Today computers are integral to all aspects of operations within
an organization. As Federal agencies are becoming critically
dependent upon computer information systems to carry out their
missions, the agency executives (policy makers) are recognizing
that computers and computer-related problems must be understood
and managed, the same as any other resource. They are beginning
to understand the importance of setting policies, goals, and
standards for protection of data, information, and computer
resources, and are committing resources for information security
programs. They are also learning that primary responsibility for
data security must rest with the managers of the functional areas
supported by the data.

All managers who use any type of automated information resource
system must become familiar with their agency’s policies and
procedures for protecting the information which is processed and
stored within them. Adequately secure systems deter, prevent, or
detect unauthorized disclosure, modification, or use of
information. Agency information requires protection from
intruders, as well as from employees with authorized computer
access privileges who attempt to perform unauthorized actions.
Protection is achieved not only by technical, physical and
personnel safeguards, but also by clearly articulating and
implementing agency policy regarding authorized system use to
information users and processing personnel at all levels. This
guide is one of three brochures that have been designed for a
specific audience. The “Executive Guide to the Protection of
Information Resources” and the “Computer User’s Guide to the
Protection of Information Resources” complete the series.

Table of Contents

Executive Summary iv
Introduction 1
Purpose of Guide 1
The Risks 1
Responsibilities 2
Information Systems Development 5
Control Decisions 5
Security Principles 5
Access Decisions 7
Systems Development Process 7
Computer Facility Management 9
Physical Security 9
Data Security 11
Monitoring and Review 11
Personnel Management 13
Personnel Security 13
Training 14
For Additional Information 15

Introduction

Purpose of this Guide
This guide introduces information systems security concerns and
outlines the issues that must be addressed by all agency managers
in meeting their responsibilities to protect information systems
within their organizations. It describes essential components of
an effective information resource protection process that applies
to a stand alone personal computer or to a large data processing
facility.

The Risks
Effort is required by every Federal agency to safeguard
information resources and to reduce risks to a prudent level.
The spread of computing power to individual employees via
personal computers, local-area networks, and distributed
processing has drastically changed the way we manage and control
information resources. Internal controls and control points that
were present in the past when we were dealing with manual or
batch processes have not been established in many of today’s
automated systems. Reliance upon inadequately controlled computer
systems can have serious consequences, including:

Inability or impairment of the agency’s ability to perform its
mission

Inability to provide needed services to the public

Waste, loss, misuse, or misappropriation of funds

Loss of credibility or embarrassment to an agency

To avoid these consequences, a broad set of information security
issues must be effectively and comprehensively addressed.
Responsibilities
All functional managers have a responsibility to implement the
policies and goals established by executive management for
protection of automated information resources (data, processes,
facilities, equipment, personnel, and information). Managers in
all areas of an organization are clearly accountable for the
protection of any of these resources assigned to them to enable
them to perform their duties. They are responsible for
developing, administering, monitoring, and enforcing internal
controls, including security controls, within their assigned
areas of authority. Each manager’s specific responsibilities will
vary, depending on the role that manager has with regard to
computer systems.

Portions of this document provide more detailed information on
the respective security responsibilities of managers of computer
resources, managers responsible for information systems
applications and the personnel security issues involved.
However, all agency management must strive to:

Achieve Cost-Effective Security
The dollars spent for security measures to control or contain
losses should never be more than the projected dollar loss if
something adverse happened to the information resource.
Cost-effective security results when reduction in risk through
implementation of safeguards is balanced with costs. The greater
the value of information processed, or the more severe the
consequences if something happens to it, the greater the need
for control measures to protect it.
The person who can best determine the value or importance of
data is the functional manager who is responsible for the data.
For example, the manager responsible for the agency’s budget
program is the one who should establish requirements for the
protection of the automated data which supports the program. This
manager knows better than anyone else in the organization what
the impact will be if the data is inaccurate or unavailable.
Additionally, this manager usually is the supervisor of most of
the users of the data.

It is important that these trade-offs of cost versus risk
reduction be explicitly considered, and that management
understand the degree of risk remaining after selected controls
are implemented.

Assure Operational Continuity
With ever-increasing demands for timely information and greater
volumes of information being processed, the threat of information
system disruption is a very serious one. In some cases,
interruptions of only a few hours are unacceptable. The impact
due to inability to process data should be assessed, and actions
should be taken to assure availability of those systems
considered essential to agency operation. Functional management
must identify critical computer applications and develop
contingency plans so that the probability of loss of data
processing and telecommunications support is minimized.

Maintain Integrity
Integrity of information means you can trust the data and the
processes that manipulate it. Not only does this mean that errors
and omissions are minimized, but also that the information system
is protected from deliberate actions to wrongfully change the
data. Information can be said to have integrity when it
corresponds to the expectations and assumptions of the users.

Assure Confidentiality
Confidentiality of sensitive data is often, but not always, a
requirement of agency systems. Privacy requirements for personal
information is dictated by statute, while confidentiality of
other agency information is determined by the nature of that
information, e.g., information submitted by bidders in
procurement actions. The impact of wrongful disclosure must be
considered in understanding confidentiality requirements.

Comply with Applicable Laws and Regulations
As risks and vulnerabilities associated with information systems
become better understood, the body of law and regulations
compelling positive action to protect information resources
grows. OMB Circular No. A-130, “Management of Federal
Information Resources” and Public Law 100-235, “Computer Security
Act of 1987” are two documents where the knowledge of these
regulations and laws provide a baseline for an information
resource security program.

Information Systems Development
This section describes the protective measures that should be
included as part of the design and development of information
processing application systems. The functional manager that is
responsible for and will use the information contained in the
system, must ensure that security measures have been included and
are adequate. This includes applications designed for personal
computers as well as large mainframes.

Control Decisions
The official responsible for the agency function served by the
automated information system has a critical role in making
decisions regarding security and control. In the past, risk was
often unconsciously accepted when such individuals assumed the
computer facility operators were taking care of security. In
fact, there are decisions to be made and security elements to be
provided that cannot be delegated to the operator of the system.
In many cases, the user or manager develops the application and
operates solely.

The cost of control must be balanced with system efficiency and
usability issues. Risk must be evaluated and cost-effective
controls selected to provide a prudent level of control while
maximizing productivity. Controls are often closely connected
with the system function, and cannot be effectively designed
without significant understanding of the process being automated.

Security Principles
There are some common security attributes that should be present
in any system that processes valuable personal or sensitive
information. System designs should include mechanisms to enforce
the following security attributes.

Identification and Authentication of Users
Each user of a computer system should have a unique
identification on the system, such as an account number or other
user identification code. There must also be a means of verifying
that the individual claiming that identity (e.g., by typing in
that identifying code at a terminal) is really the authorized
individual and not an imposter. The most common means of
authentication is by a secret password, known only to the
authorized user.

Authorization Capability Enforcing the Principle of Least
Possible Privilege
Beyond ensuring that only authorized individuals can access the
system, it is also necessary to limit the users access to
information and transaction capabilities. Each person should be
limited to only the information and transaction authority that is
required by their job responsibilities. This concept, known as
the principle of least possible privilege, is a long-standing
control practice. There should be a way to easily assign each
user just the specific access authorities needed.

Individual Accountability
From both a control and legal point of view, it is necessary to
maintain records of the activities performed by each computer
user. The requirements for automated audit trails should be
developed when a system is designed. The information to be
recorded depends on what is significant about each particular
system. To be able to hold individuals accountable for their
actions, there must be a positive means of uniquely identifying
each computer user and a routinely maintained record of each
user’s activities.

Audit Mechanisms
Audit mechanisms detect unusual events and bring them to the
attention of management. This commonly occurs by violation
reporting or by an immediate warning to the computer system
operator. The type of alarm generated depends on the seriousness
of the event.

A common technique to detect access attempts by unauthorized
individuals is to count attempts. The security monitoring
functions of the system can automatically keep track of
unsuccessful attempts to gain access and generate an alarm if the
attempts reach an unacceptable number.

Performance Assurance
A basic design consideration for any information system should
be the ability to verify that the system is functioning as
intended. Systems that are developed without such design
considerations are often very difficult to independently audit or
review, leading to the possibility of unintended results or
inaccurate processing.

Recoverability
Because Federal agencies can potentially be heavily dependent on
a computer system, an important design consideration is the
ability to easily recover from troublesome events, whether minor
problems or major disruptions of the system. From a design point
of view, systems should be designed to easily recover from minor
problems, and to be either transportable to another backup
computer system or replaced by manual processes in case of major
disruption or loss of computer facility.

Access Decisions
Once the automated system is ready to use, decisions must be
made regarding access to the system and the information it
contains. For example, many individuals require the ability to
access and view data, but not the ability to change or delete
data. Even when computer systems have been designed to provide
the ability to narrowly designate access authorities, a
knowledgeable and responsible official must actually make those
access decisions. The care that is taken in this process is a
major determining factor of the level of security and control
present in the system. If sensitive data is being transmitted
over unprotected lines, it can be intercepted or passive
eavesdropping can occur. Encrypting the files will make the data
unintelligible and port protection devices will protect the files
from unauthorized access, if warranted.

Systems Development Process
All information systems software should be developed in a
controlled and systematic manner according to agency standards.
The quality and efficiency of the data processed, and the
possible reconfiguration of the system can all be affected by an
inadequate development process. The risk of security exposures
and vulnerabilities is greatly reduced when the systems
development process is itself controlled.

Computer Facility Management
Functional managers play a critical role in assuring that agency
information resources are appropriately safeguarded. This section
describes the protective measures that should be incorporated
into the ongoing management of information resource processing
facilities. As defined in OMB Circular No. A-130, “Management of
Federal Information Resources,” the term “information technology
facility” means an organizationally defined set of personnel,
hardware, software, and physical facilities, a primary function
of which is the operation of information technology. This
section, therefore applies to any manager who houses a personal
computer, mainframe or any other form of office system or
automated equipment.

Physical Security
Information cannot be appropriately protected unless the
facilities that house the equipment are properly protected from
physical threats and hazards. The major areas of concern are
described below.

Environmental Conditions
For many types of computer equipment, strict environmental
conditions must be maintained. Manufacturer’s specifications
should be observed for temperature, humidity, and electrical
power requirements.

Control of Media
The media upon which information is stored should be carefully
controlled. Transportable media such as tapes and cartridges
should be kept in secure locations, and accurate records kept of
the location and disposition of each. In addition, media from an
external source should be subject to a check-in process to ensure
it is from an authorized source.

Control of Physical Hazards
Each area should be surveyed for potential physical hazards.
Fire and water are two of the most damaging forces with regard to
computer systems. Opportunities for loss should be minimized by
an effective fire detection and suppression mechanism, and
planning reduces the danger of leaks or flooding. Other physical
controls include reducing the visibility of the equipment and
strictly limiting access to the area or equipment.

Contingency Planning
Although risks can be minimized, they cannot be eliminated. When
reliance upon a computer facility or application is substantial,
some type of contingency plan should be devised to allow critical
systems to be recovered following a major disaster, such as a
fire. There are a number of alternative approaches that should be
evaluated to most cost-effectively meet the agency’s need for
continuity of service.

Configuration Management
Risk can be introduced through unofficial and unauthorized
hardware or software. Another key component of information
resource management is ensuring only authorized hardware and
software are being utilized. There are several control issues to
be addressed.

Maintaining Accurate Records
Records of hardware/software inventories, configurations, and
locations should be maintained and kept up-to-date.

Complying with Terms of Software Licenses
Especially with microcomputer software, illegal copying and
other uses in conflict with licensing agreements are concerns.
The use of software subject to licensing agreements must be
monitored to ensure it is used according to the terms of the
agreement.

Protecting Against Malicious Software and Hardware
The recent occurrences of destructive computer “viruses” point
to the need to ensure that agencies do not allow unauthorized
software to be introduced to their computer environments.
Unauthorized hardware can also contain hidden vulnerabilities.
Management should adopt a strong policy against unauthorized
hardware/software, inform personnel about the risks and
consequences of unauthorized additions to computer systems, and
develop a monitoring process to detect violations of the policy.

Data Security
Management must ensure that appropriate security mechanisms are
in place that allow responsible officials to designate access to
data according to individual computer users’ specific needs.
Security mechanisms should be sufficient to implement individual
authentication of system users, allow authorization to specific
information and transaction authorities, maintain audit trails as
specified by the responsible official, and encrypt sensitive
files if required by user management.

Monitoring and Review
A final aspect of information resource protection to be
considered is the need for ongoing management monitoring and
review. To be effective, a security program must be a continuous
effort. Ideally, ongoing processes should be adapted to include
information protection checkpoints and reviews. Information
resource protection should be a key consideration in all major
computer system initiatives.

Earlier, the need for system audit trails was discussed. Those
audit trails are useful only if management regularly reviews
exception items or unusual activities. Irregularities should be
researched and action taken when merited. Similarly, all
information-related losses and incidents should be investigated.

A positive benefit of an effective monitoring process is an
increased understanding of the degree of information-related risk
in agency operations. Without an ongoing feedback process,
management may unknowingly accept too much risk. Prudent
decisions about trade-offs between efficiency and control can
only be made with a clear understanding of the degree of inherent
risk. Every manager should ask questions and periodically review
operations to judge whether changes in the environment have
introduced new risk, and to ensure that controls are working
effectively.

Personnel Management
Managers must be aware that information security is more a
people issue than a technical issue. Personnel are a vital link
in the protection of information resources, as information is
gathered by people, entered into information resource systems by
people, and ultimately used by people. Security issues should be
addressed with regard to:
People who use computer systems and store information in the
course of their normal job responsibilities
People who design, program, test, and implement critical or
sensitive systems
People who operate computer facilities that process critical or
sensitive data

Personnel Security
From the point of hire, individuals who will have routine access
to sensitive information resources should be subject to special
security procedures. More extensive background or reference
checks may be appropriate for such positions, and security
responsibilities should be explicitly covered in employee
orientations. Position descriptions and performance evaluations
should also explicitly reference unusual responsibilities
affecting the security of information resources.

Individuals in sensitive positions should be subject to job
rotation, and work flow should be designed in such a way as to
provide as much separation of sensitive functions as possible.
Upon decision to terminate or notice of resignation, expedited
termination or rotation to less sensitive duties for the
remainder of employment is a reasonable precaution.

Any Federal computer user who deliberately performs or attempts
to perform unauthorized activity should be subject to
disciplinary action, and such disciplinary action must be
uniformly applied throughout the agency. Any criminal activity
under Federal or state computer crime laws must be reported to
law enforcement authorities.

Training
Most information resource security problems involve people.
Problems can usually be identified in their earliest stages by
people who are attuned to the importance of information
protection issues. A strong training program will yield large
benefits in prevention and early detection of problems and
losses. To be most effective, training should be tailored to the
particular audience being addressed, e.g., executives and policy
makers; program and functional managers; IRM security and audit:
ADP management and operations; end users.

Most employees want to do the right thing, if agency
expectations are clearly communicated. Internal policies can be
enforced only if staff have been made aware of their individual
responsibilities. All personnel who access agency computer
systems should be aware of their responsibilities under agency
policy, as well as obligations under the law. Disciplinary
actions and legal penalties should be communicated.

For Additional Information

National Institute Of Standards and Technology
Computer Security Program Office, A-216 Technology
Gaithersburg, MD 20899
(301) 975-5200

For further information on the management of information
resources, NIST publishes Federal Information Processing
Standards Publications (FIBS PUBS). These publications deal with
many aspects of computer security, including password usage, data
encryption, ADP risk management and contingency planning, and
computer system security certification and accreditation. A list
of current publications is available from:
Standards Processing Coordinator (ADP)
National Computer Systems Laboratory
National Institute of Standards and Technology
Technology Building, B-64
Gaithersburg, MD 20899
Phone: (301) 975-2817
������������������������

The Information Systems Security Monitor Volume 2 Number 2

The Information Systems Security Monitor    

     _______     /--------\      /--------\     \          /|    
        |        |               |              | \       / |    
        |        |               |              |   \   /   |    
        |         \_______        \_______      |     \     |    
        |                 \               \     |           |    
        |                 |                |    |           |    
        |                 |                |    |           |    
        |        \________/       \________/    |           |    
      -------                                      
Dedicated to the pursuit of security awareness............    
================================================================= 
Volume 2 Number 2                                     April 1992  
=================================================================  
////////////////////// In this Issue \\\\\\\\\\\\\\\\\\\\\\\\\\\  

Choosing the Right Password  

Comptroller General Decision on EDI  

Security Hall of Fame  

OAIS Employees Judge Student Contest  

Cyberspace: A Hacker's Response 

Quick Fix Security  

Dear Clyde  

Computer Speak  

What's New  
---------------------------------------------------------------- 

Hacker Lists Passwords Hackers Look For  
Choosing the Right Password!  

Imagine a hacker entering a system with your id and password  
because you did not take the time to choose a good password,  this 
is something that can be completely prevented if people would take 
a few minutes to choose a good password.  You must be creative when 
choosing a password not lazy.  Since a password is usually the  
first line of defense against unauthorized access to a computer  
system, when the first line is broken the rest only take time.  The 
average user usually has a password that is easy to select and easy 
to remember.  Any word that is easy to select or is contained in 
a dictionary is a poor and insecure selection for a password.  The 
reason this makes a poor selection is because these words are the 
first ones an intruder will try when attempting to compromise your 
system.  For instance, if your name is Tom Smith and your logon id 
is TSMITH your password should not contain any variation of these 
two words (Tom & Smith).  A hacker will try TSMITH, SMITHT, 
TOMSMITH, SMITHTOM, TSMITH1, HTIMST, etc. before anything else.  
As far as the length of a password goes its definitely the longer 
the better.  To demonstrate this point I give you the following 
table:  

# of        Possible             Average Time   
Characters  Combinations         To Discover     Example  

1            36                   6 min           q  
2            1,300                4 hrs           bt  
3            47,000               5 days          tyu  
4            1,700,000            6 months        insw  
5            60,000,000           19 years        potnb  
etc...  

The greater the number of possibilities a hacker must sort through, 
the better the chances of a password remaining undiscovered.  

The best passwords are those that contain a combination of letters  
and numbers or are a combination of two or more unrelated words  
i.e. TREEFLOOR, TVBOOK, RADIOSHOE, etc.  Another possibility is to  
select the initials of your two grandmothers combined with the  
number of times you have seen your favorite movie to come up with  
a password that resembles PAWH07, 07WHPA, PA07WH, etc.    

If you think that you have chosen a password that is hard to guess  
or would take too much time to guess keep in mind that hackers have 
automated the process.  There have been programs written for the  
sole purpose of guessing passwords, they take a list similar to the 
one in this article and try each and every one of them  
These are the types of passwords that are hard to guess and will  
most likely not be found in any dictionary or word list.  I am  
enclosing a list of common passwords that most hackers have a  
variation of, under no circumstances should you ever use a word  
contained in this list.  All forms of profanity should also be 
included in this list.100  
666  
6969  
aaa  
abc  
abel  
academia  
academic  
academie  
access  
ada  
adele  
adeline  
adelphe  
admin  
adrian  
aerobic  
aerobics  
agathe  
agnes  
aide  
aime  
aimee  
airplane  
alain  
alban  
albanie  
albany  
albatros  
albatross  
albert  
alex  
alexander  
alexandre  
alf  
algebra  
algebre  
alias  
aliases  
alice  
alida  
alix  
alpha  
alphabet  
alphonse  
ama  
amadeus  
amandine  
ambroise  
amedee  
ami  
amorphe  
amorphous  
amour  
amy  
an  
analog  
analogue  
ananas  
anchor  
ancre  
andre  
andromache  
andy  
angele  
angerine  
anicet  
animals  
animaux  
anne  
annie  
annonciation  
anselme  
answer  
anthelme  
antoine  
antoine-marie  
anvils  
anything  
aout  
apollinaire  
apolline  
apotre  
aquin  
arc  
aria  
ariane  
aristide  
armand  
armel  
arnaud  
arrow  
arsene  
arthur  
ascension  
asd  
asm  
assise  
assomption  
athena  
athenes  
atmosphere  
aubin  
aude  
audrey  
augustin  
automne  
autoroute  
avent  
avila  
avion  
avril  
aymar  
aymard  
aztecs  
aztecs  
azur  
azure  
bacchus  
badass  
bailey  
balance  
banana  
bananas  
banane  
bande  
bandit  
banks  
banque  
baptiste  
barbara  
barber  
barbier  
bariton  
baritone  
barnabe  
barnard  
bart  
barthelemy  
bartman  
basic  
basile  
bass  
basse  
basson  
bassoon  
batch  
batman  
baudouin  
beach  
beater  
beaute  
beauty  
beaver  
beethoven  
belier  
beloved  
benedicte  
benoit  
benz  
beowulf  
berkeley  
berlin  
berline  
berliner  
bernadette  
bernard  
bernardin  
bertille  
bertrand  
beryl  
beta  
everly  
bicameral  
bienheureux  
bienvenue  
bishop  
bitch  
blaise  
bob  
boris  
bradley  
brian  
brice  
brigitte  
broadway  
bruno  
bsd  
bumbling  
burgess  
cad  
cafe  
calude  
camarade  
campanile  
cancer  
cantor  
capricorne  
cardinal  
careme  
carine  
carmel  
carmen  
carole  
carolina  
caroline  
carson  
cartouche  
cascades  
casimir  
cassis  
castle  
castle  
cat  
catherine  
cayuga  
cecile  
celine  
celtics  
cendres  
cerulean  
challenger  
change  
chantal  
charles  
charlotte  
charmant  
charming  
charon  
chat  
chateau  
chem  
chemin  
chemistry  
chess  
chester  
cheval  
chevalier  
chien  
chou  
christ  
christian  
christine  
christophe  
cible  
cigar  
cigare  
citroen  
claire  
clarisse  
class  
classic  
classique  
claude  
clemence  
clement  
clotilde  
cluster  
clusters  
code  
coeur  
coffee  
coke  
colette  
collins  
come  
computer  
comrade  
comrades  
conception  
condo  
condom  
connect  
console  
constant  
constantin  
conversion  
cookie  
cooper  
corinne  
cornelius  
couscous  
create  
creation  
creosote  
crepin  
cretin  
criminal  
croix  
cshrc  
cyrille  
daemon  
dame  
damien  
dancer  
daniel  
danny  
dapper  
data  
dave  
davy  
deb  
debbie  
deborah  
december  
decembre  
default  
defoe  
defunts  
delphine  
deluge  
denis  
denise  
desperate  
develop  
device  
dial  
diane  
didier  
diet  
dieter  
dieu  
digital  
dimanche  
dimitri  
disc  
discovery  
disk  
disney  
dog  
dominique  
donald  
donatien  
dos  
drought  
duncan  
dupond  
dupont  
durand  
dwladys  
eager  
earth  
easier  
easy  
eatme  
eau  
edges  
edinbourg  
edinburgh  
edith  
edmond  
edouard  
edwige  
edwin  
egghead  
eiderdown  
einstein  
elephant  
elisabeth  
elisee  
elizabeth  
ella  
ellen  
email  
emeline  
emerald  
emeraude  
emile  
emilie  
emma  
enclumes  
endeavour  
enemy  
engin  
engine  
engineer  
entreprise  
enzyme  
epiphanie  
erenity  
eric  
ersatz  
establish  
estate  
estelle  
ete  
eternity  
etienne  
euclid  
euclide  
eudes  
eugenie  
evelyn  
evrard  
extension  
eymard  
fabrice  
facile  
fairway  
famille  
felicia  
felicie  
felicite  
fender  
ferdinand  
fermat  
fernand  
ferrari  
fete  
fevrier  
fiacre  
fidele  
fidelite  
fidelity  
field  
file  
filet  
fini  
finite  
firmin  
fishers  
flakes  
fleche  
fleur  
fleurs  
float  
flocon  
flocons  
florent  
florentin  
flower  
flowers  
foolproof  
football  
foresight  
format  
forsythe  
fourier  
fraise  
framboise  
francine  
francois  
francoise  
fred  
frederic  
friend  
frighten  
fulbert  
fun  
function  
fungible  
gabin  
gabriel  
gaetan  
games  
gardner  
garfield  
gaston  
gateau  
gatien  
gatt  
gauss  
gautier  
gemeaux  
genevieve  
geoffroy  
george  
georges  
gerard  
geraud  
germain  
germaine  
gertrude  
ghislain  
gibson  
gilbert  
gildas  
gilles  
ginger  
gisele  
glacier  
gnu  
golf  
golfer  
gontran  
gorgeous  
gorges  
gosling  
gouge  
goutte  
graham  
grahm  
gras  
gregoire  
group  
gryphon  
gucci  
guenole  
guess  
guest  
guillaume  
guitar  
guitare  
gumption  
guntis  
guy  
gwladys  
habib  
hack  
hacker  
hal  
hamlet  
handily  
happening  
harmonie  
harmony  
harold  
harvey  
hawaii  
hebrides  
heinlein  
helene  
hello  
help  
henri  
herbert  
hermann  
hermes  
herve  
hiawatha  
hibernia  
hidden  
hippolyte  
hiver  
homework  
honey  
honore  
honorine  
horse  
horus  
hubert  
hugues  
humbert  
hutchins  
hyacinthe  
hydrogen  
ibm  
ida  
ignace  
igor  
imbroglio  
imbroglio  
immaculee  
imperial  
include  
inconnue  
ines  
info  
ingres  
ingress  
ingrid  
inna  
innocent  
innocuous  
internet  
invite  
irene  
irenee  
irishman  
irlande  
isabelle  
isidore  
isis  
jacqueline  
jacques  
janvier  
japan  
japon  
jean  
jean-baptiste  
jean-claude  
jean-francois  
jean-michel  
jean-pierre  
jean-yves  
jeanclaude  
jeanfrancois  
jeanmichel  
jeanne  
jeanpierre  
jeanyves  
jerome  
jessica  
jester  
jeudi  
jixian  
joel  
johnny  
joseph  
joshua  
jour  
judas  
judicael  
judith  
juggle  
juillet  
juin  
jules  
julia  
julien  
julienne  
juliette  
jumeaux  
jupiter  
juste  
justin  
justine  
kathleen  
kermit  
kernel  
kevin  
key  
kirkland  
kiwi  
knight  
ladle  
lambda  
lamination  
landry  
lapin  
larissa  
larkin  
larry  
laurent  
lazare  
lazarus  
lea  
lebesgue  
lee  
leger  
leland  
leon  
leonce  
leroy  
lewis  
library  
licorne  
light  
lion  
lisa  
lisp  
loch  
lock  
lockout  
louis  
louise  
lourdes  
love  
luc  
lucie  
lucien  
lumiere  
lundi  
lune  
lydie  
macintosh  
mack  
madeleine  
madelene  
maggot  
magic  
magique  
mai  
mail  
maint  
malcolm  
malcom  
manager  
mangue  
marc  
marcel  
marcelle  
marcellin  
mardi  
marguerite  
marie  
marie-madeleine  
marietta  
mariette  
marina  
marius  
mark  
markus  
mars  
marthe  
martial  
martin  
martine  
martinien  
marty  
marvin  
master  
math  
mathilde  
matthias  
matthieu  
maurice  
maxime  
medard  
melaine  
mellon  
memory  
mercredi  
mercure  
mercury  
meres  
merlin  
metro  
mets  
mgr  
michael  
michel  
michelle  
mike  
minimum  
minsky  
mit  
modem  
modeste  
mogul  
moguls  
monique  
mont  
moose  
morley  
morts  
mouse  
mozart  
mutant  
nadege  
nagel  
naissance  
nancy  
napoleon  
narcisse  
nasa  
natacha  
nathalie  
nationale  
nativite  
navette  
nepenthes  
neptune  
ness  
nestor  
net  
network  
new  
news  
newton  
next  
nicolas  
nina  
ninon  
nobody  
noel  
norbert  
notre  
novembre  
noxious  
nuclear  
nutrition  
nyquist  
oceanography  
ocelot  
october  
octobre  
odette  
odile  
odilon  
office  
olive  
olivetti  
olivia  
olivier  
open  
operator  
oracle  
orca  
orwell  
osiris  
outlaw  
oxford  
pacific  
pacifique  
pad  
padoue  
painless  
pakistan  
pam  
paper  
papers  
papiers  
paques  
parfait  
pascal  
pass  
password  
pat  
paterne  
patrice  
patricia  
patrick  
paul  
paule  
paulin  
peche  
pecheur  
pecheurs  
peggy  
pelagie  
pencil  
penguin  
penis  
pentecote  
peoria  
percolate  
peres  
persimmon  
persona  
pete  
peter  
peugeot  
peur  
philip  
philippe  
phoenix  
phone  
pierre  
pizza  
plane  
playboy  
plover  
pluto  
pluton  
plymouth  
poire  
poisson  
poissons  
polynomial  
pomme  
pondering  
porc  
pork  
porsche  
poster  
power  
praise  
precious  
prelude  
presence  
presto  
prevision  
prince  
princeton  
printemps  
prisca  
priv  
private  
privs  
professor  
profile  
program  
prosper  
protect  
protozoa  
prudence  
pub  
public  
pumpkin  
puppet  
quentin  
qwerty  
rabbit  
rainbow  
raindrop  
raissa  
raleigh  
rameaux  
random  
raoul  
rap  
rascal  
raymond  
reagan  
really  
rebecca  
regional  
reine  
remi  
remote  
renaud  
renault  
rene  
reponse  
requin  
reseau  
richard  
rick  
ripple  
risc  
rje  
robert  
robot  
robotics  
rochester  
rodent  
rodolphe  
rodrigue  
roger  
roi  
roland  
rolande  
rolex  
romain  
romano  
romaric  
romeo  
romuald  
ronald  
root  
rosalie  
rose  
rosebud  
roseline  
rosemary  
roses  
rosine  
ruben  
rules  
ruth  
sabine  
sacre  
sade  
sagittaire  
sainte  
sal  
sales  
salome  
samedi  
samson  
sandrine  
saturn  
saturne  
saturnin  
saxon  
scamper  
scheme  
school  
scorpion  
scott  
scotty  
sebastien  
secret  
security  
seigneur  
sensor  
septembre  
serenity  
serge  
service  
sesame  
severin  
sex  
sharc  
shark  
sharks  
sharon  
sheffield  
sheldon  
shell  
shiva  
shivers  
shuttle  
sidoine  
signature  
silvere  
simon  
simple  
simpsons  
singer  
single  
smile  
smiles  
smooch  
smother  
snatch  
snoopy  
soap  
socrate  
socrates  
solange  
somebody  
sophie  
sossina  
sourire  
souris  
souvenir  
sparrows  
spit  
spring  
springer  
squires  
stanislas  
strangle  
stratford  
student  
stuttgart  
subway  
succes  
success  
summer  
sun  
super  
superuser  
support  
supported  
surfer  
suzanne  
swearer  
sylvain  
sylvere  
sylvestre  
sylvie  
symmetry  
sys  
sysadmin  
system  
tangerine  
tanguy  
tape  
target  
tarragon  
tatiana  
taureau  
taylor  
tech  
telephone  
temptation  
tennis  
tentation  
terminal  
terre  
test  
thailand  
thailande  
thecle  
theodore  
theophile  
therese  
thibault  
thibaut  
thierry  
thomas  
tiger  
tigre  
toggle  
tomate  
tomato  
topography  
tortoise  
tortue  
toussaint  
toxic  
toyota  
trails  
transfer  
transfiguration  
travail  
trivial  
trombone  
tty  
tuba  
tubas  
tuttle  
ulrich  
umesh  
unhappy  
unicorn  
unix  
unknown  
uranus  
urbain  
urchin  
util  
utility  
uucp  
valentin  
vasant  
venceslas  
vendredi  
venus  
ver  
veronique  
verseau  
vertige  
vertigo  
vianney  
vicky  
victoire  
victor  
victorien  
vierge  
village  
vincent  
virgin  
virginia  
virginie  
virus  
visitation  
visitor  
viviane  
vivien  
volvo  
wargames  
warren  
water  
weenie  
whatever  
whatnot  
whiting  
whitney  
wholesale  
wilfried  
will  
william  
willie  
winston  
wisconsin  
wizard  
wombat  
woodwind  
word  
work  
wormwood  
wyoming  
xavier  
xaviere  
xfer  
xmodem  
xyz  
yaco  
yang  
yin  
yosemite  
yves  
yvette  
zap  
zimmerman  
zita  
zmodem  
zzz  

Written by "The Butler", a hacker at heart, a Systems Administrator 
in real life who enjoys learning as much as possible about any 
given system including how to circumvent its security measures. He 
has written articles for various hacker magazines that deal with 
computer security. He currently administers a PC Network for a 
medium size business (250 people). He also lectures to various 
groups including Local EDP Auditors Association, User Groups, and 
Private Corporations on how to protect their systems from hackers 
like himself but who use their knowledge for mischievous purposes.  

========================end of article========================  

Dear Clyde                          Responses to   
                                    questions for  
                                    those who are  
                                    searching for  
                                    the truth.  

Send your comments or questions to Clyde c/o the AIS Security 
Branch in Parkersburg, Room 1011, or leave them in Clyde's mailbox 
located on the Security bulletin boards throughout the Parkersburg 
office.  

Dear Clyde,   
What is the proper way to dispose of diskettes which are no longer 
able to be used? Are there security concerns here?  
                       Peggy  
Dear Peggy,   
Yes there are security concerns as the data stored on the diskettes 
may still be readable, if someone wants to take the effort to 
retrieve it. Therefore the diskettes should be disposed of 
properly. Any method of destroying the diskette can be used. 
Cutting it up as you do a credit card that is no longer to be used 
is one method. However the important thing is to make certain the 
disk surface, that is the inner contents of the envelope or plastic 
case, is destroyed.  

(Note: I personally prefer giving the disk several good whacks with 
my sword and lance to render it unusable.)   

Clyde ....... Sir Clyde?  
Rumor has it that Clyde is to be recognized for his continuing 
efforts in the arena of computer security by being knighted. There 
will be more on this in the next issue, stay tuned.  

========================end of article========================  

...........................................................   
             A Journey Behind (further behind)  .       .       .  
  .   
             .   .         .       .         .           ..       
    .   
              .   The Dark Side of CYBERSPACE  .     .       ..   
.  .   
                  .     .           .      .       .       .      
  .   
             Hackers in Their Illusive World:  .  A Response .   
.    .   

...........................................................   

             A Response by: Dispater   
             Editor in Chief of Phrack Inc. Magazine   
             InterNet: phracksub@stormking.com   

First of all, I would like to thank Kim Clancy for providing me 
with the opportunity to reply to her article in the previous issue 
of the ISSM.  I find myself agreeing with her on more issues than 
not.  I read her piece on Cyberspace... Most of the article was 
good, but I felt unclear about what she was saying in the section 
titled "The Dark Side."  So I have attempted to present a few 
things from this hacker's viewpoint and make a few points where I 
have disagreed with her.  The ">" indicates Kim's previous 
writings.   

>...What is scary to me in regard to some of the avenues is   
>the ability for individuals to get to so many different   
>types of information...   

What scares me are the kinds of people who have access to   
the most personal parts of our lives compiled into data   
bases (like Information America) that are for sale to anyone   
who wants to pay the money or has the "power" to access it.   
Why does the government need to know my unlisted phone number?  Is 
it really any insurance agency's right to know that I have a son 
or daughter that is about to turn age 16, and will soon need to buy 
auto insurance?  I think I have the right not to be bothered by an 
onslaught of people that think they have something I want to 
purchase from them. If you really enjoy junk mail and computerized 
telephone sales calls you can thank these kinds of databases.   

>I am not stating that I think information should be   
>shielded from individuals.   

The more diverse sources of information we can all access, the 
better off society will become.  If we look at the past we can see 
how accuracy in books was improved drastically by the creation of 
the printing press.  The scribes of kings and church figures were 
no longer relied upon as authorities of various subject matter.  
Information was made cheap and easily possessed by the common man.  
Therefore if someone disagreed with some book that was printed, he 
and his guild could write their version of what THEY found to be 
true.  This promoted truth, accuracy, a deluge of human 
interaction, and free thought.   

>...I once went to a presentation about hackers.  The   
>presenter told a story about a mother who took her child's   
>computer modem out into the driveway and ran over it after   
>her son had been arrested for hacking...   

What was the parent doing while her child was hacking?   
Another thing we need to clarify is the use of the word   
"child."  These are not often children.  There is a certain   
level of mental development that must occur first.  I don't   
know much about child psychology, but I'd say that most kids   
under the age of 13 would have a bit of difficult time   
understanding computer networking.  Most people in the   
computer underground are at least 16.  If they are not   
16 years old almost every sysop I know, kicks them off the   
system.  The young person should be allowed to explore in areas the  
parent might not agree with as long as he/she is willing to   
talk about it with the parent afterward. Why are required to   
water down and censor all information so that is safe and   
easily understandable to the "little children?"  If there is   
a 12 year old that has network access and is reading USENET's 
ALT.SEX.BONDAGE, I think there is a greater problem involved than 
the type of information the nets carry!!   

>While hackers spend time developing their skills and   
>learning how to master cyberspace they also use cyberspace   
>to share information about what they have learned.   

This is the great benefit of getting involved.  Everyone   
should own a computer because of this reason.   

>Information has been found on how to steal long distance   
>phone calls from the phone company, how to make a pipe bomb   
>and how to perform satanic rituals before sitting down to   
>hack.   

It is not illegal to know how to do any of the previously   
mentioned things.  As you mention later the information can   
also be found in such places like libraries.  We need to   
keep a few things in perspective here.  MOST of the   
information readily available on phone phreaking is so out   
dated, one couldn't hope to implement the use of such   
knowledge without most surely getting caught in an ESS(Electronic  
Switching System environment.  Most of the United State's 
telephones are on such a system.   

Secondly, most of the information available on explosives is   
very crude.  Most of it isn't worth the time it took to   
download.  Actually there is more information available in   
the library on that subject than in all the data bases in   
the world.  I personally think this kind of thing is simply   
stupid.  I will not print that kind of thing in Phrack.   
That kind of information is typed in from books, by people   
who don't have anything else to do.   

In regards to "satanic rituals", it is difficult to make any   
comments about this because in all my years of calling BBS's   
and talking to other hackers, I have never seen such an   
animal.  I have seen *THREE* articles on the Wiccan religion   
which is similar to white witchcraft, but it's not even   
close to anything satanic.  However, other than this   
minuscule tidbit in cyberspace, the only things I've seen   
were things that were written as pranks and for joke   
purposes.  It amazes me that if one person has written   
something or done something it is representative of the   
whole community.  This is definitely not a responsible   
conclusion.  If some people would just open their eyes to   
reality, they would not see a computer underground filled   
with "satanic, child molesting anarchists".   

>I hesitate to write the above because I don't want people   
>to avoid the technology.  Everything I have found is in   
>most libraries, but the accessibility of it through   
>computers makes it much easier to obtain.   

You hesitate with good reason and you are correct about all   
that information being already in your local library.  The   
problem boils down to "digital censorship."  Some people are   
saying it's OK for a library to have the aforementioned   
information, but it's NOT OK for it to be on my computer's   
hard drive.   

In regards to that argument I say it is much easier to get   
the information from a library than the computer.  Let's   
take a look at they facts. First of all, most libraries are   
FREE.  On the other hand the average computer system   
(386/33) costs around $1500.  Your typical 8th grader   
doesn't usually have that kind of cash.   

The problem is that reality and virtual reality is the same   
for some of us.  We will promptly ignore silly rules like   
"it's ok for some people to know certain things, but it's   
not ok for me to know the same bit of information."   
In the information age we are all becoming much more aware   
of each other's presence.  We are finding out that we are   
all very different.  We each have some ideas that can   
easily shock others.  These ideas can and are being   
challenged by the other people we interact with.  Therefore,   
we should NEVER take the step back into the "electronic dark   
age."   

The really funny thing about all this is, everyone in the   
United States IS a part of cyberspace, even though most of   
them don't want to recognize this fact.  If your name is on   
a computer somewhere, you are in cyberspace!  So you'd   
better become aware of your existence.  Use it to learn and   
question why its there!   
========================end of article========================    

OAIS Employees Volunteer to Judge Student Contest  

Every October, the Computer Learning Foundation, a non-profit 
educational foundation serving the United States and Canada, hosts 
Computer Learning Month. During that month, among other numerous 
activities, the foundation hosts numerous contests designed to 
encourage students, educators, and community members to explore new 
areas of using technology and to share their knowledge with others. 
These contests for students provide parents and teachers with an 
activity children can do today to begin thinking and learning about 
what it means to be a responsible user of technology. One of this 
year's contests was a student writing contest focusing on Adult 
Attitudes on the Value of Technology and Ethical Issues. Students 
were to interview one parent and one other adult, write a summary 
of their opinions on the value of technology in our lives and the 
ethical issues involved with using technology, then the students 
evaluated what they thought of the comments and opinions expressed 
by the adults they interviewed.   
  The Bureau of the Public Debt participated in this program with 
several OAIS employees, Gretchen Bergmann, Kim Clancy, Bill Dobson, 
Zephery Ellerson, Joe Kordella, Gary Smith, and Ed Alesius, 
volunteering their time to judge the students entries.  
  While the use of a computer was not required to create the 
critique many submissions showed an adept usage of various word 
processing, desktop publishing and graphics software.  
  This interchange between the professional environment and schools 
proved to be very enlightening.  It is refreshing to see a group 
dedicate its effort to a much needed task, keeping schools up with 
technology and its responsible use.  

========================end of article========================   
QUICK FIX SECURITY 

The following is a listing of some easy to do security controls 
that help a lot....  

 1. Set modem to answer after 4-5 rings.  
 2. Select a dial-up number from a different prefix or out of order 
    from the rest of your office.  
 3. Use call back features.  
 4. Use proprietary software for your communications e.g.,  
    PC Anywhere IV.  
 5. Use special modems for encryption and access control e.g.,  
    Leemah Datacom.  
 6. Disconnect after a certain period of inactivity.  
 7. Do not allow certain userids' to have dial-up access.  
 8. Use caller id and call tracking.  
 9. Display a blank screen when a connection is made so the user 
    has no clue what they have connected to.   

 ========================end of article========================   

COMPUTER SPEAK  
COMPUTER TERMS AND THEIR MEANINGS  
access  n.  The ability of a subject to view, change, or 
communicate with an object in a computer system. Typically, access 
involves a flow of information between the subject and the object 
(for example, a user reads a file, a program creates a directory). 
cyberspace  n.  The world that is created by the connection of 
computers. Travels thru this environment can be vast and undefined 
just as space travel can be. This is the environment Cyberpunks 
call home.  
database  n.  A collection of data items processible by one or more 
programs.  
 phreaking  v.  The art and science of cracking the phone network 
(so as, for example, to make free long-distance calls). By 
extension, security-cracking in any other context (especially, but 
not exclusively, on communications networks).  
virtual reality  n.  1. Computer simulations that use 3-D graphics 
and devices such as the Dataglove to allow the user to interact 
with the simulation. 2. A form of network interaction incorporating 
aspects of role-playing games, interactive theater, improvisational 
comedy, and "true confessions' magazines. In a virtual reality 
session, interaction between the participants is written like a 
shared novel.   
Phrack Inc. Magazine  n.  An electronically published and 
distributed magazine that focuses on technical issues.  

========================end of article========================   

Comptroller General Decision on EDI   

The Comptroller General of the United States has issued a decision 
that electronic data interchange (EDI) technologies, with 
enhancements such as message authentication and digital signatures, 
can create valid legal contractual obligations between the U.S. 
Government and the party with whom the agency contracts.  

Digest
   Contracts formed using Electronic Data Interchange technologies may
constitute valid obligations of the government for purposes of 31 U.S.C.
1501, so long as the technology used provides the same degree of
assurance and certainty as traditional "paper and ink" methods of
contract formation.

Decision
   By letter dated September 13, 1991, the Director, Computer Systems
Laboratory, National Institute of Standards and Technology (NIST), asked
whether federal agencies can use Electronic Data Interchange (EDI)
technologies, such as message authentication codes and digital
signatures, to create valid contractual obligations that can be recorded
consistent with 31 U.S.C.  1501.  For the reasons stated below, we
conclude that agencies can create valid obligations using properly
secured EDI systems.

Background  
  EDI is the electronic exchange of business information between 
parties, usually via a computer, using an agreed upon format.  EDI 
is being used to transmit shipping notices, invoices, bid requests, bid 
quotes and other messages.  Electronic contracting is the use of 
EDI technologies to create contractual obligations.  EDI allows the 
parties to examine the contract, usually on video monitors, but 
sometimes on paper facsimiles, store it electronically (for example on
magnetic tapes, on discs or in special memory chips), and recall 
it from storage to review it on video monitors, reproduce it on paper or
even mail it via electronic means.  Using EDI technologies, it is
possible for an agency to contract in a fraction of the time that
traditional practices take. 
  As NIST pointed out in its request, the "paperless" nature of the
technology has raised the question of whether electronic contracts
constitute obligations which may be recorded against the government. 
NIST is in the process of developing standards for electronic signatures
to be used in various applications,*1 including the formation of
contracts, but has been advised that section 1501 imposes a barrier to
the use of electronic technologies by federal agencies in this regard.

Discussion
   Section 1501 establishes the criteria for recording obligations
against the government.  The statute provides, in pertinent part, as
follows:
       "(a) An amount shall be recorded as an obligation of the United
        States Government only when supported by documentary evidence of-

             (1) a binding agreement between an agency and another person
             (including an agency) that is--

                  (A) in writing, in a way and form, and for a purpose
                  authorized by law. . . ."

31 U.S.C. 1501(a) (1) (A).

   Under this provision, two requirements must be satisfied:  first, the
agreement must bind both the agency and the party with whom the agency
contracts; second, the agreement must be in writing.

Binding Agreement
   The primary purpose of section 1501 (a) (1) is "to require that there
be an offer and an acceptance imposing liability on both parties."  39
Comp. Gen. 829, 831 (1960) (emphasis in original).  Hence the government
may record an obligation under section 1501 only upon evidence that both
parties to the contract willfully express the intent to be bound.  As
explained below, EDI technology provides both the agency and the
contractor the means to electronically "sign" a contract.
   A signature traditionally has provided such evidence.  See generally
65 Comp. Gen. 806, 810 (1986).  Because of its uniqueness, the
handwritten signature is probably the most universally accepted evidence
of an agreement to be bound by the terms of a contract.  See 65 Comp.
Gen. at 810.  Courts, however, have demonstrated a willingness to accept
other notations, not necessarily written by hand.  See, e.g., Ohl & Co.
v. Smith Iron Works, 288 U.S. 170, 176 (1932) (initials); Zacharie v.
Franklin, 37 U.S. (12 Pet.) 151, 161-62 (1838) (a mark);Benedict v.
Lebowitz, 346 F. 2d 120 (2nd Cir. 1965) (typed name); Tabas v. Emergency
Fleet Corporation, 9 F.2d 648, 649 (E.D. Penn. 1926) (typed, printed or
stamped signatures); Berryman v. Childs, 98 Neb. 450, 153 N.W. 486, 488
(1915) (a real estate brokerage used personalized listing contracts which
had the names of its brokers printed on the bottom of the contract in the
space where a handwritten signature usually appears).
   As early as 1951, we recognized that a signature does not have to be
handwritten and that "any symbol adopted as one's signature when affixed
with his knowledge and consent is a binding and legal signature.  B-
104590, Sept. 12, 1951.  Under this theory, we approved the use of
various signature machines ranging from rubber stamps to electronic
encryption devices.  See 33 Comp. Gen. 297 (1954); B-216035, Sept. 20,
1984.  For example, we held that a certifying officer may adopt and use
an electronic symbol generated by an electronic encryption device to sign
vouchers certifying payments.  B-216035, supra.  The electronic symbol
proposed for use by certifying officers, we concluded, embodied all of
the attributes of a valid, acceptable signature:  it was unique to the
certifying officer, capable of verification, and under his sole control
such that one might presume from its use that the certifying officer,
just as if he had written his name in his own hand, intended to be bound.
  EDI technology offers other evidence of an intent to be bound with the
same attributes as a handwritten signature.  We conclude that EDI systems
using message authentication codes which follow NIST's Computer Data
Authentication Standard (Federal Information Processing Standard (FIPS)
113*2 or digital signatures following NIST's Digital Signature Standard,
as currently proposed, can produce a form of evidence that is acceptable
under section 1501.
   Both the message authentication code and the digital signature are
designed to ensure the authenticity of the data transmitted.  They
consist of a series of characters that are cryptographically linked to
the message being transmitted and correspond to no other message.  There
are various ways in which a message authentication code or digital
signature might be generated.  For example, either could be generated
when the sender inserts something known as a "smart card"*3 into a system
and inputs the data he wants to transmit.  Encoded on a circuit chip
located on the smart card is the sender's private key.  The sender's
private key is a sequence of numbers or characters which identifies the
sender, and is constant regardless of the transmission.  The message
authentication code and the digital signature are functions of the
sender's private key and the data just loaded into the system.  The two
differ primarily in the cryptographic methodology used in their
generation and verification.
   After loading his data into the system, the sender notifies the system
that he wants to "sign" his transmission.  Systems using message
authentication codes send a copy of the data to the chip on the smart
card; the chip then generates the message authentication code by applying
a mathematical procedure known a cryptographic algorithm.  Systems using
digital signatures will send a condensed version of the data to the smart
card, which generates the digital signature by applying another
algorithm, as identified in NIST's proposed standard.  The card returns
the just-generated message authentication code or digital signature to
the system, which will transmit it and the data to the recipient.
   Under either approach, when an offeror or a contracting officer
notifies the system that he wants to "sign" a contract being transmitted,
he is initiating the procedure for generating a message authentication
code or digital signature with the intention of binding his company or 
agency, respectively, to the terms of the contract.*4 The code or the
digital signature evidences that intention, as would a handwritten or
other form of signature.  Both, generated using the sender's private key,
are unique to the sender; and, the sender controls access to and use of
his "smart card," where his key is stored.
   They are also verifiable.  When the recipient receives the contract,
either on his computer monitor or in paper facsimile, it will carry,
depending on which approach is used, a notation which constitutes the
message authentication code or the digital signature of the sender,
necessary information to validate the code or the signature and, usually,
the sender's name.  The recipient can confirm the authenticity of the
contract by entering the data that he just received and asking his system
to verify the code or the digital signature.  The system will then use
the information provided by the sender and either verify or reject it.*5
Both approaches use a key to verify the message just received; however,
the digital signature requires application of a different key from that
used to verify a message authentication code.  The change of any data
included in the message as transmitted will result in an unpredictable
change to the message authentication code or the digital signature. 
Therefore, when they are verified, the recipient is virtually certain to
detect any alteration.

Writing
   To constitute a valid obligation under section 1501(a)(1)(A), a
contract must be supported by documentary evidence "in writing."  As NIST
pointed out, some have questioned whether EDI, because of the paperless
nature of the technology, fulfills this requirement.  We conclude that it
does.
   Prior to the enactment of section 1501, originally section 1311 of the
Supplemental Appropriations Act of 1955, *6 there was no "clean cut
definition of obligations."  H.R. Rep. No. 2266, 83rd Cong., 2d Sess. 50
(1954).  Some agencies had recorded questionable obligations, including
obligations based on oral contracts, in order to avoid withdrawal and
reversion of appropriated funds.  See 51 Comp. Gen. 631, 633 (1972). 
Section 1501 was enacted not to restrict agencies to paper and ink in the
formation of contracts, but because, as one court noted, "Congress was
concerned that the executive might avoid spending restrictions by
asserting oral contracts."  United States v. American Renaissance Lines,
494 F.2d 1059, 1062 (D.C. Cir. 1974), cert, denied, 419 U.S. 1020 (1974). 
The purpose of section 1501 was to require that agencies submit evidence
that affords a high degree of certainty and lessens the possibility of
abuse.  See H.R. Rep. No. 2266 at 50.
   While "paper and ink" offers a substantial degree of integrity, it is
not the only such evidence.  Some courts, applying commercial law (and
the Uniform Commercial Code in particular), have recognized audio tape
recordings, for example, as sufficient to create contracts.  See e.g.,
Ellis Canning Company v. Bernstein, 348 F. Supp. 1212 (D. Colo. 1972). 
The court, citing a Colorado statute, stated that the tape recording of
the terms of a contract is acceptable because it is a "reduction to
tangible form." *7  Id. at 1228.  In a subsequent case, a federal Court
of Appeals held that an audio tape recording of an agreement between the
Gainesville City Commission and a real estate developer was sufficient to
bind the Commission.  Londono v. City of Gainesville, 768 F.2d 1223 (11th
Cir. 1985).  The court held that the tape recording constituted a "signed
writing."  Id. at 1228.
   In our opinion, EDI technology, which allows the contract terms to be
examined in human readable form, as on a monitor, stored on electronic
media, recalled from storage and reviewed in human readable form, has an
integrity that is greater than an audio tape recording and equal to that
of a paper and ink contract.  Just as with paper and ink, EDI technology
provides a recitation of the precise terms of the contract and avoids the
risk of error inherent in oral testimony which is based on human
memory.*8  Indeed, courts, under an implied-in-fact contract theory, have
enforced contracts on far less documentation than would be available for
electronic contracts.  See Clark v. United States, 95 U.S. 539 (1877). 
See also Narva Harris Construction Corp. v. United States, 574 F.2d 508
(Ct. Cl. 1978).
   For the purpose of interpreting federal statutes, "writing" is defined
to include "printing and typewriting and reproductions of visual symbols
by photographing, multigraphing, mimeographing, manifolding, or
otherwise."  1 U.S.C. 1 (emphasis added).  Although the terms of
contracts formed using EDI are stored in a different manner than those of
paper and ink contracts, they ultimately take the form of visual symbols. 
We believe that it is sensible to interpret federal law in a manner to
accommodate technological advancements unless the law by its own terms
expressly precludes such an interpretation, or sound policy reasons exist
to do otherwise.  It is evident that EDI technology had not been
conceived nor, probably, was even anticipated at the times section 1501
and the statutory definition of "writing" were enacted.  Nevertheless, we
conclude that, given the legislative history of section 1501 and the
expansive definition of writing, section 1501 and 1 U.S.C. 1 encompass
EDI technology.
   Accordingly, agencies may create valid obligations using EDI systems
which meet NIST standards for security and privacy.

Comptroller General
of the United States
Sept. 13, 1990

General Counsel
U.S. General Accounting Office
441 G. Street, N.W.
Washington, D.C.  20548

Dear Sir:

As you know, National Institute of Standards and Technology (NIST) has
cooperated with the Department of Treasury and the General Accounting
Office to develop an electronic certification system wherein a
cryptographic Message Authentication Code (MAC) is used in place of a
written signature to bind a certifying officer to a payment order. 
Several other agencies have expressed their interest in using this or a
similar system as a substitute for a written signature.  In fulfillment
of our responsibilities under the Computer Security Act of 1987, NIST is
now in the process of developing a public key based Digital Signature
Standard (DSS) which is specifically designed for electronic signature
applications and will provide at least the same degree of security as the
MAC approach.  We have attached the DSS Federal Register Announcement and
draft DSS which is now issued for public comment.

We have often been told that legal impairments exist which prevent
agencies from implementing electronic signatures to bind the federal
government.  The specific statute cited is 31 U.S.C. 1501.  Before
formally recommending these standards for contracting and financial
management applications, I would like to request a General Accounting
Office decision as to whether NIST standards such as Federal Information
Processing Standard (FIPS) 113 and a finalized DSS may be used throughout
the federal government to record obligations under 31 U.S.C. 1501.  If
you need any further information in order to make your decision please
feel free to contact Miles Smid, (301) 975-2938, of my staff.

Sincerely,

James H. Burrows
Director, Computer Systems Laboratory

Enclosures

*1 The Congress has mandated that NIST (formally the National Bureau of
Standards) establish minimum acceptable practices for the security and
privacy of sensitive information in federal computer systems.  Computer
Security Act of 1987, Pub. L. No. 100-235, section 2, 101 Stat. 1724
(1988).

*2 FIPS 113 adopts American National Standards Institute (ANSI) standard
X9.9 for message authentication.  It outlines the criteria for the
cryptographic authentication of electronically transmitted data and for
the detection of inadvertent and/or intentional modifications of the
data.  By adopting the ANSI standard, FIPS 113 encourages private sector
applications of cryptographic authentication; the same standard is being
adopted by many financial institutions for authenticating financial
transactions.

*3 A smart card is the size of a credit card.  It contains one or more
integrated circuit chips which function as a computer.

*4 NIST officials advise us that technology using message authentication
codes and digital signatures will be available to both contractors and
contracting officers for use in government contracting.

*5 For the sake of simplicity, this example does not describe the
complicated system of controls used to ensure that (1) no human knows the
sender's private key and (2) the information received from the sender for
validating the message authentication code or digital signature is
correct and accurate.

*6 Pub. L. No. 663, 68 Stat. 800, 830 (1954).

*7 Other courts, interpreting the laws of other states, have held that a
tape recording is not acceptable.  See Sonders v. Roosevelt, 102 A.D.2d
701, 476 N.Y.S.2d 331 (1984); Roos v. Aloi, 127 Misc.2d 864, 487 N.Y.S.2d
637 (N.Y. Sup. Ct. 1985).

*8 Of course, just as with any contract or other official document, an
agency must take appropriate steps to ensure the security of the
document, for example, to prevent fraudulent modification of the terms. 
Agencies should refer to NIST standards in this regard.  See, e.g., FIPS
113 (regarding message authentication codes).  In addition, agencies
should refer to the GSA regulations regarding the maintenance of
electronic records, see 41 C.F.R. 201-45.2, and to the Federal Rules of
Evidence with regard to managing electronic records to ensure
admissibility, see generally Department of Justice Report, "Admissibility
of Electronically Filed Federal Records as Evidence," Systems Policy
Staff, Justice Management Division (October 1990).

========================end of article========================    

Security Hall of Fame Established  

Clyde's Computer Security Hall of Fame is being established to 
recognize those who contribute above and beyond the normal call of 
duty in their performance of contributing to the advancement and 
enhancement of Public Debt's computer security program.  
  The first inductee to this much sought honor is Bob Settles. Bob 
came to Public Debt immediately upon his graduation from college 
in 1964. Apart from a two year stint in Vietnam, his first 18 years 
were spent with the Internal Audit Staff. Then, in 1982, he was 
selected to manage the AIS Security Branch and has served in that 
capacity ever since. During his tenure as manager, the Branch's 
responsibilities have grown steadily to keep pace with the emphasis 
placed on information systems security throughout the Government. 
Public Debt's security program is now among the most highly 
regarded in the Treasury Department.  
  Bob has recently accepted a Computer Specialist position with the 
Treasury Department at its main office in Washington, D.C.  
  Bob epitomized the best in seasoned management and his departure 
will be keenly felt. We wish him the best in his new position!   

========================end of article========================    

What's New?  

ISSM's gain recognition in international publication  
The Public Debt Computer Security Program and the ISSM's received 
international recognition when an article written by Kim Clancy and 
Joe Kordella was published in ISPNews in the Jan/Feb 1992 edition.  
The article presented the role computer security plays in the 
protection of critical information assets of Public Debt in an 
environment of rapid technological change.  It stressed that the 
ISSM's are key players in the implementation of the security 
program.  

New Security Branch Manager Selected  
The selection of Kim Clancy as the Security Branch Manager 
completes the consolidation of the Branch in Parkersburg.  Kim was 
previously a security analyst in the AIS Security Branch.  Prior 
to that, she was a computer security analyst for the State of 
Arizona, for over three years.  She was also a computer systems 
security officer in the United States Air Force.  

========================end of article========================    

The AIS Security Branch runs an Electronic BBS. Give us a call at  
(304) 420-6083.  An electronic version of the ISSM is posted on the 
board and can be downloaded.  Articles in the electronic version 
may include more detail in that we are not limited by space 
constraints as we are in the paper copy.    

The ISSM is a quarterly publication of the Department of Treasury, 
Bureau of the Public Debt, AIS Security Branch, 200 3rd Street, 
Parkersburg, WV 26101  (304) 420-6368  

Editors:     Kim Clancy  
             Joe Kordella  
             Ed Alesius  
             Mary Clark

Downloaded From P-80 International Information Systems 304-744-2253

The Information Systems Security Monitor Volume 2 Number 1

The Information Systems Security Monitor  

     _______     /--------\      /--------\     \          /|  
        |        |               |              | \       / |  
        |        |               |              |   \   /   |  
        |         \_______        \_______      |     \     |  
        |                 \               \     |           |  
        |                 |                |    |           |  
        |                 |                |    |           |  
        |        \________/       \________/    |           |  
      -------                                    
Dedicated to the pursuit of security awareness............  
================================================================= 
Volume 2 Number 1                                   January 1992 
================================================================= 

////////////////////// In this Issue \\\\\\\\\\\\\\\\\\\\\\\\\\\ 

One Nerd's Approach to Computer Security  

What did Clyde say?  

Digital Signatures Still A Mystery to Many in Government  

Cyberspace  

Dear Clyde  

Computer Speak  

Virus Fighters  

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\////////////////////////////////// 

ONE NERD'S APPROACH TO COMPUTER SECURITY  

Hi, my name is Bill Strouse and I'm a NERD (Network Emergency   
Repair Dude). I've been a Sysop or systems operator now for better 

than a decade and I've learned a great deal about human nature and 

security in general.     

Back in 1980 it dawned on me that if I connected a modem to my   
computer I could access it from anywhere I happened to be. But I 

would have to have some sort of security or others would be   
accessing it, possibly in a destructive way. The solution I decided 

on was to setup a bulletin board system that used a combination of  

a unique name and password for each caller to control what that  

caller had access to. Once I got the system working I found it was 

a great way to keep in touch with friends that also had modems and 

an even better way to get answers on technical problems. Plus the 

latest PD (public domain) software regularly showed up on my hard 

disk. I publicized the number in electronic lists that were    
distributed worldwide and was soon getting calls from all over the 

continent and foreign countries like Sweden, England and Australia.  

I soon had one of the best collections of PD software in the   
country and the phone line was in constant use day and night.    

Along with all the great people I met there were always those few 

who had nothing better to do than try to destroy or disrupt what 

others had built. One of the first things I learned was not to   
allow just anyone the ability to leave public electronic mail.   

Kids would call and leave grossly obnoxious public messages with 

all sorts of foul language. We devised a system whereby a caller 

could only leave a message to the Sysop on the first call then we 

would call them back voice and verify who they were. Most   
importantly we had verified they were connected to a legitimate  

phone number which could be traced to a physical location and    
person. After verification their security level was raised so they 

had full access and an hour of system time a day. One of the next 

lessons I learned was not to allow anyone to upload a program they 

could then execute on the system. A friend, who continually worked 

at busting the security to see if he could find holes uploaded a 

game with a hidden copy of BASIC embedded in the program. When he 

ran the program online he could issue a control code and jump to 

the interpreter which allowed him to walk all over the security  

like it didn't exist! After that all files were uploaded to a   
private area no one but the Sysop had access to till they were   
thoroughly inspected.     

By 1985 I had so many people asking for help with computer related 

problems I went into business for myself as a VAR, or Value Added 

Reseller. Someone who not only sells you the goods but sticks   
around and makes them work for you. Not long after that networking 

looked like it might be the wave of the future. Since a network was 

a shared resource, similar in nature to a bulletin board system and 

even used a name and password for security I was right at home. And 

I learned even more about security.    

Number one. The weakest link in security is the employee using the 

computer! They put their password on a sticky note and paste it on 

their monitor so they don't forget; loan their account to fellow 

employees; use passwords such as "secret", "love", or their social 

security account number (every 14 year old wanna-be hacker has the 

list of most commonly used passwords). They go to lunch and leave 

their workstation logged into accounting records, bring in new   

(virus infected) programs they want to use at work and just    
generally gum up the (security) works. A good employee security  

education program is worth its weight in gold.    

And, security must be physical as well as electronic. I read a book 

about a group of young hackers (Inner Circle) that could not   
gain access to a mainframe because the security was well designed 

so they posted a kid in the lobby of the company with a   
questionnaire. He passed himself off as a high school student who 

had been given an information gathering assignment as a school   
project. Some of the questions asked were "What is your first and 

last name", "Do you use a computer at work", "Are you married",  

"What's your wife's name". Needless to say they were into the   
system within days.    

Mainframe managers are somewhat aware of this and protect their  

iron (computers) from anyone without proper authority but most of 

the LANs (Local Area Networks) I've worked with are in an area   
that's easily accessible by anyone. Remember, something as simple 

as a cup of coffee, or a boot disk with the proper utilities in  

the hands of a disgruntled stockboy can turn your data into random 

1s & 0s and truly ruin your day, if not your career.    

The system I run is called The Ring of Fire after the tectonic   
plate we live on the edge of here in California. Over time it has 

grown to four (4) phone lines and over 350 megabytes of   
downloadable software packages and graphics images. There are   
well over 1,000 regular callers and the system averages about 3,000 

calls a month but the electronic mail is where the real action is.  

The E-mail is shared with other similar computer systems all over 

the US and some foreign countries. Callers can leave a message in 

a conference and it will show up on other systems all over the   

country. Replies are automatically routed back to the originator 

and show up as return mail addressed to that person. Thus, callers 

can converse with a large number of diversely scattered individuals 

at minimal cost (usually a free local phone call). To further   
reduce online time we support SLMR off-line mail reader. With it 

you can download a compressed mail packet of pre-specified   
conferences then read and reply off-line with a full screen   
editor and upload a compressed set of replies.    

All of this runs on a Novell network that spans several computers 

and large hard disks, a read/write CD, Fax server AND all of our 

inhouse workstations. Hopefully, I'll see you online and we can  

continue this as an interactive discussion ;-).    

Author bio:  
          Bill Strouse has been a systems analyst for more    
          than twenty years now and has worked as a con-   
          sultant for IBM, Amdahl, Ford Aerospace and    
          Stanford University's SLAC (Stanford Linear    
          Accelerator).   

          Bill Strouse has been telecommuting since 1980    
          when he started his first electronic bulletin    
          board service, back in the CP/M days.  He has    
          been the system operator  ever since and current   
          ly has one of  Silicon Valley's most popular    
          boards, the Ring-of-Fire, at 408-453-3326 and    
          408-453-2460.  He was President of PRACSA (Public    
          Remote Access Computer Standards Association) for    
          many years before leaving three years ago to    
          found and become President of United Sysop's    
          Association, an organization of bulletin board    
          system operators and users.   

          Mr. Strouse is a president of Stoney River Net-   
          works, an authorized Novell Reseller.  His com-  
          pany has installed many remote communication sys-   
          tems for various clients.  He is also President    
          and Co-founder of the Silicon Valley Novell User    
          Group and serves on the Board of the Northern    
          California Netware User's Association.  Bill is    
          also the editor of NetWare News, the newsletter    
          of the California Netware Users Association.   

-------------------------End of Article---------------------  

WHAT DID CLYDE SAY?  

It's been brought to our attention that everyone that reads the  
ISSM isn't always well versed in computer terminology.  Well, in 

an effort to remedy that situation we will be providing an article 

called "Computer Speak", starting in this issue, that will be  
devoted to getting every reader to understand computer jargon.  
  We appreciate hearing from our readers about any items or topics 

that they would like to see appear in the ISSM. So let's keep  
hearing from you.  Just drop a note to Clyde or call.  

-------------------------End of Article---------------------  

DIGITAL SIGNATURES STILL ARE MYSTERY TO MANY IN GOVERNMENT  
     By Darryl K. Taft   

A fight has erupted over the government proposal of a new   
standard for digital signatures, and questions remain as to just 

what a digital signature and public-key encryption actually are. 

     The National Institute of Standards and Technology has   
proposed a standard for digital signatures that would securely   
verify a message sender's identity.   
     Miles Smid, manager of the security technology group in NIST's 

Computer Systems Laboratory, defined a "key" as a binary number  

used with an algorithm to encipher or decipher data.   
     Public-key encryption requires the use of a matched pair of 

such keys for each user, one that is publicly known and one that 

is private and known only to the user. More traditional data   
encryption methods, like the government's Data Encryption Standard 

(DES), require only one key to encipher and decipher data.   
     Under the old method, "if I were to scramble a message with 

my secret key, the only way you could descramble it would be to use 

my key," Smid said. DES requires exchanging secret encryption keys 

with each party, thus requiring prior relationships.   
     However, rather than using the same key to both encrypt and 

decrypt the data, public-key encryption uses a matched pair of   
encryption and decryption keys. Each key performs the inverse   
function of the other.   
     Thus, a user makes his public-key publicly available, perhaps 

via a directory or certifying authority, and keeps his private key 

secret. To send a private message, an originator scrambles his   
entire message using his intended recipient's public key. Once this 

is done, the message can only be decoded with the recipient's   
private key.   
     Inversely, a sender also can work over a file using his   
private key, and it can only be decoded using that sender's public 

key.   
     This provides the basis for the digital signature, because if 

you can unscramble a signature in a message with someone's public 

key, they had to use their private key to scramble it in the first 

place.   
     The proposed standard, known as the Digital Signature Standard 

(DSS) is based on a digital signature algorithm (DSA) derived from 

a concept known as ElGamal encryption. It is intended for use in 

electronic mail, electronic funds transfer, electronic data   
interchange, software distribution, data storage and other   
applications that require data integrity assurance and data origin 

authentication.   
     NIST, on Aug.30, proposed to adopt the DSS as a Federal   
Information Processing Standard (FIPS). The proposed standard   
specifies a digital signature algorithm based on a public key.   
     The government's DSS is not intended to encrypt the data in 

a message, but primarily to authenticate. The DSS is intended to 

verify the author and verify the integrity of the data in the   
message.   
     Public-key encryption algorithms are based upon what are known 

as "hard problems," Smid said. These hard problems are mathematical 

operations involving very large numbers. The government's proposed 

DSS uses one of a variety of public-key encryption algorithms, Smid 

said.   
     The NIST proposal's scheme differs markedly from that of a  

popular encryption system from RSA Data Security Inc. of Redwood 

City, Calif. The difference lies in the algorithms used to encrypt 

and decrypt data. Smid said the RSA algorithm is based on the   
difficulty of factoring very large numbers. This involves finding 

a number that is the product of two other numbers.   
     Breaking that system for a small number would be pretty   
simple, "but if I give you a large number, like 150 digits, that 

would be difficult. Factoring very large numbers is a difficult  

problem," he said.   
     The algorithm used in the NIST proposal is based upon the   
difficulty of finding discrete logarithms. Essentially, this method 

involves finding the remainder left over when you divide one number 

by another one. Again, when dealing with very large numbers this 

becomes a very difficult problem, Smid said.   

Trap Doors   

     RSA's president, D. James Bidzos, has attacked the NIST   
proposal as one that is not secure and that encourages trap doors. 

Smid said many cryptographers rate the discrete logarithm problem 

as more difficult or at least as difficult as the factoring method 

RSA uses.   
     Ironically, Tahar ElGamal, whose work is recognized in the  

NIST encryption scheme, is RSA's director of engineering.   
     "What NIST has proposed is a modification of the idea. Their 

algorithm is about half from my work and half from theirs. The key 

size is limited to 512 bits, which is questionable," ElGamal said. 

ElGamal added that while he believes the NIST proposal will work, 

he questions its security.   
     To use the DSS, a user need only use the system with his   
everyday mail software.   
     "What you'd see is the regular message under whatever mail  

system you have, but somewhere there would be a place for a digital 

value, from three to 500 bits of data. This would be the sender's 

signature. You'd have to have some software that would be able to 

pull off the signature and verify it," Smid said.   
     Using the DSS, messages appear "in the clear," Smid said   
because the DSS does not account for privacy. The DSS does not   
encrypt the entire message, it adds an encrypted "signature" onto 

the message.   
     The RSA system does allow for privacy -- with or without   
another encryption scheme. The RSA system lets the user "sign" a 

message with his private key and then add privacy by encrypting the 

message with the recipient's public key. In trying RSA Data   
Security's Mailsafe software for MS-DOS on the GCN local area   
network, we found it to work quickly and easily, whether a message 

was just "signed" or signed and "sealed."   

Signed and Sealed   

     Signing the message with the sender's private key put an   
encrypted digital signature at the end of an openly readable   
message. Any person receiving the message with RSA software could 

verify that it had not been changed and that it came from the   
sender who scrambled the signature.   
     Sealing it with the recipient's public key then scrambled the 

entire message so only the recipient could read it with his private 

key.   
     At the receiving end, we decrypted the message first with the 

recipient's private key, then verified the signature with the   
sender's public key.   
     Full encryption and decryption took less than five seconds  

each for a 10K file on AST Research Inc. Premium 386/25 computers. 

Varying hard-drive speeds had no measurable effect at this file  

size.   
     Though all this sounds very good, it appears to be practical 

only in close-knit computing communities. As yet, no third-party 

certification authorities have been established. To use these   
schemes, users must be able to verify that a public-key/private- 

key combination fits the right person. Without a certification   
authority this is difficult in a large network.   
     The U.S. Postal Service is vying to provide that service.   
Without certification of keys, someone could establish a key in  

someone else's name.   
     The 90-day comment period for the NIST proposal ends at the 

end of November, but NIST probably will not formally adopt the   
standard until February, Smid said. The DSS would be mandatory for 

federal users and for private companies protecting government data, 

he said.   
     Though questioning claims that the DSS is less secure than  

RSA's method, Smid acknowledged that the DSS lacks a necessary   
hashing function. A hashing function is a cryptographic algorithm 

used to create a message digest that is unique to each document, 

much like a fingerprint, said Bidzos. This function ensures the  

message has not changed since the sender "signed" it. However, Smid 

said NIST will deliver a hashing function soon.   
     Public-key encryption is not simply a black art that just   
happens. "To use public-key encryption, you need a system that   
knows how to use it," said Robert E. Frank, project leader for   
electronic commerce at the Lawrence Livermore National Laboratory 

in Livermore, Calif.   
     Frank heads a Defense Department funded project to move DOD 

to electronic commerce. One area his group has focused on is   
public-key encryption. The pilot system that Lawrence Livermore has 

developed gives users an option to use either the NIST proposal or 

the RSA method.   
     "Our main objective is to provide a trusted mail capability 

that makes it possible for vendors and government buyers to use the 

security features if they want to, and to use what they're most  

comfortable with," Frank said.   

Reprinted with permission by Government Computer News, October 28, 

1991, page 37.  Copyright 1989, Ziff-Davis Publishing Company  

-------------------------End of Article---------------------  

...........................................................  
A journey behind (way behind)  .        .          .    .  
.   .         .       .         .           ..         .  
 .      CYBERSPACE  .     .       ..     .         .      
     .     .           .      .       .       .       .  
hackers in their illusive world   .        ..   .      .  
...........................................................  
by Kim Clancy  

In the last issue of the ISSM, I explained that I would be  
documenting my journey behind hackers in cyberspace. Let me start 

by saying that cyberspace is fascinating; it is another world that 

quietly but actively exists. I mean ACTIVELY. I have no idea what 

the traffic is of electronic interactions but I can tell you that 

within minutes I can send a message to Japan and get a response. 

I can write this article in West Virginia and send it in electronic 

format to San Francisco. As a matter of fact, almost every guest 

article we have received has been sent to us through cyberspace. 

Within minutes of receiving the article, it is imported into the 

newsletter and finalized. This is a fascinating technology.   

The dark side of cyberspace  

  Alas, while the technology offers major advantages, it also  
offers some very frightening avenues as well. What is scary to me 

in regard to some of the avenues is the ability for individuals  
to get to so many different types of information, individuals that 

may initially be too naive to know what they are stumbling into. 

I am not stating that I think information should be shielded from 

individuals. I am saying that turning people, children for example, 

loose in cyberspace may have some unpleasant results. I once went 

to a presentation about hackers. The presenter told a story about 

a mother who took her child's computer modem out into the driveway 

and ran over it after her son had been arrested for hacking. The 

presenter said that you should never let your child use a modem  
unattended. While hackers spend time developing their skills and 

learning how to master cyberspace they also use cyberspace to share 

information about what they have learned. Information has been  
found on how to steal long distance phone calls from the phone  
company, how to make a pipe bomb and how to perform satanic rituals 

before sitting down to hack. I hesitate to write the above because 

I don't want people to avoid the technology. Everything I have  
found is in most libraries, but the accessibility of it through  
computers makes it much easier to obtain. In an earlier issue of 

the ISSM, we published a code of computer ethics being used by  
schools throughout the nation. If you have purchased a modem for 

your child for Christmas, you may wish to dig that issue out and 

go over that with him or her.  

On a brighter note  

  I thoroughly enjoy cyberspace. Cyberspace has fantastic  
legitimate resources and places to visit that are good for the  
entire family. For example, you can dial up CompuServe and get  
access to encyclopedias. This is a great way for a child to  
research a school project. The AIS Security Branch accesses  
numerous electronic bulletin boards(bbs) that keep us up to date 

on security issues and provides us with a network of security  
professionals. As a matter of fact, we actively participate in  
cyberspace by running our own bbs.   
  There is really no way of knowing where a person will end up once 

he/she starts exploring cyberspace. The technology is addictive and 

before you know it you are constantly searching for more computers 

to call and more people to learn from. Cyberspace is a great world, 

but if you are not careful, it can carry you away. Don't ignore the 

technology, if you don't know about it, you are already behind.  
Dive in, experience it, have a great time. You will be fascinated 

by what you discover.  

-------------------------End of Article---------------------  

          /^\  
      _ /_ \_\         /\      Clyde....dedicated to the pursuit 

    /  /\  \          /  \              of security ...  
  /__/   \__\        |    |  
     @  @            ______      
 __   </   __          |  
 \ \______/ /          |  
  \_______/            |  

DEAR CLYDE...responses to questions for those who are searching for 

             the truth............................................. 

Dear Clyde,   
     How do I select a good password?  
                      Signed, ABCDE  

Dear ABCDE,  
One method is to choose a 5 or 6 character word at random and then 

add 2 or more random characters to it.  This should give you  
something relatively easy to remember with the additional  
characters making it more difficult to compromise.  It is not a  
good practice to choose a word that can be associated with you.  

Send your comments or questions to Clyde c/o the AIS Security  
Branch in Parkersburg, WV, Room 1011, or leave them in Clyde's  
mailbox located on the Security bulletin boards located throughout 

the Parkersburg office.  You may also leave Clyde an email message 

on the AIS Security Branches bbs (304-420-6083)  

-------------------------End of Article---------------------  

//Computer Speak:  Computer terms and their meanings\\  

SYSOP n. The operator (and usually the owner) of a bulletin-board  
system.  

MODEM n. A device that connects a computer and a terminal via a  
telephone line. Short for modulator/demodulator.  

NETWORK n. A data communications system that allows a number of  
systems that allows a number of systems and devices to communicate 

with each other.  

TRAP DOOR alt. trapdoor n. A breach created intentionally in an EDP 

systems for the purpose of collecting, altering, or destroying  
data.  

HARDWARE n. Physical equipment used in data processing.  Such as 

PC, disk drives, mainframe, keyboard, etc.  

SOFTWARE n. Computer programs, procedures, rules, and possibly  
associated documentation.  

-------------------------End of Article---------------------  
^^^^^VIRUS FIGHTERS  

What is a computer virus?    

The term "computer virus" is derived from and analogous to a    
biological virus.  The word virus itself is Latin for poison.    
A computer virus is a computer program that will copy (infect) its 

code into the machine codes of other programs, and when those    
infected programs are run performing some apparently useful    
function, such as a login, it executes its hidden code performing 

an unwanted, usually malicious function.    

How does a computer virus work?    

A program infected with a virus and loaded and executing in the  

main memory of a computer can infect another executable (object) 

program in the computer's disk storage system by secretly    
requesting the computer's operating system to append a copy of the 

virus code to the object program, usually at the start.  The    
infection makes the object program slightly longer.    
When the newly infected program is itself loaded into memory and 

invoked, the virus in it takes control and performs hidden    
functions, such as infecting yet other object programs.  The virus 

may also perform destructive functions before transferring control 

to the original entry point.  The virus code contains a marker so 

that the virus won't attempt to infect a program already infected 

by its own kind: multiple infections would cause an object file to 

grow ever larger, leading to easy detection.    
The same principle works in personal computers, where floppy disks 

play the role of object programs in the description above.  In this 

case, the virus usually attacks the copy of the operating system 

contained on the floppy disk so that the virus is automatically  

invoked whenever the disk's operating system is started.  Since the 

operating system then resides in the PC's main memory, it can    
infect any diskettes inserted into the PC.    

What can be done to protect against viruses in a computer or    
workstation?    

An additional measure of protection can be obtained by care in the 

way one uses a computer.  Analogies with food and drug safety are 

helpful.  Just as one would not consider purchasing food or    
capsules in unsealed containers or from untrusted sources, one can 

refuse to use any unsealed software or software from untrusted   

sources.    

Can the operating procedures followed by those who use a computer 

system lower the risk?    

Yes!  The following are some procedures that would help lower the 

risk:    

. Never insert a diskette that has no manufacturer's seal into your 

  PC.    
. Never use a program borrowed from someone who does not practice 

  digital hygiene to your own standards.    
. Beware of software obtained from public bulletin boards.    
. Purchase programs that check other programs for known viruses. 

. Be wary of public domain software (including virus eradicators!). 

. Monitor the last-modified dates of programs and files.    
. Don't execute programs sent in electronic mail--even your friends 

  may have inadvertently forwarded a virus.    
. Don't let employees bring software from home, unless it is    
  approved and checked to be virus free by user management.  

What are some of the computer virus symptoms?    

When a strange behavior occurs, do not dismiss it as simply a bug.  

Instead, suspect a virus and respond accordingly - acting quickly 

may save your data.  The following are possible symptoms of a viral 

infection:    

. Strange screen graphics or displays.    
. Unexpected musical tones or sound effects.    
. Alteration of text or commands.    
. Unusual behavior on reboot.    
. Reduction in system performance.    
. Unexpected disk access patterns.    
. Changes in file length or alteration times.    
. Bugs in previously reliable software.    
. Bad sectors on floppy disks, or unusually large numbers of bad 

  sectors on hard disks.    
. Reduction in available memory.    
. Unexplained changes in the system clock.    
. Unknown, new files or directories/folders appearing on disk.   

. Problems in time-dependent tasks such as communications or     

  printing.    
. The system will not reset or reboot.    

What to do if you expect a virus.    

. Leave the machine on!  Any evidence of intrusion or      
  infection may be lost if the machine is powered down. Turn off  

  the machine only at the instruction of your management, your    

  security group, or your technical support group.    
. If your desk-top computer is connected to any kind of network, 

  break the network connection logically.    

NOTE: BPD EMPLOYEES MUST CONTACT THE COMMUNICATIONS BRANCH IN THE 

      DIVISION OF PROGRAMS AND COMMUNICATIONS (OAIS) SO THAT THEY 

      MAY BREAK THE PHYSICAL CONNECTION.   

. Let people know about your suspicions.  Alert your own      
  management.    
. Use your regular trouble reporting procedure to notify technical 

  support of your problem.    

Additional information on viruses can be obtained from publications 

available in the AIS Security Branch.  The information above was 

obtained from the publication "Computers Under Attack - Intruders, 

worms, and Viruses" by Peter J. Denning.    

-------------------------End of Article---------------------  

DON'T FORGET, THE AIS SECURITY BRANCH RUNS ITS OWN ELECTRONIC  
BULLETIN BOARD SYSTEM(BBS).  GIVE US A CALL AND LET US KNOW WHAT 
YOU THINK.  THE NUMBER IS 304-420-6083.  

The ISSM is a quarterly publication of the Department of Treasury, 
Bureau of the Public Debt, AIS Security Branch, 200 3rd Street,  
Parkersburg, WV  26101, (304) 420-6363.  The ISSM is also available 
in paper format.  Let us know if you would like a copy or if you 
would like to download a copy of the print file.  The print file 
can be copied to a HP II or III laser printer and you will receive 
a copy with all graphics and formatting.   
Editors:  Bob Settles, Ed Alesius, Kim Clancy, Joe Kordella

Downloaded From P-80 International Information Systems 304-744-2253

Draft of the NIST Computer Security Handbook on Computer and Information Security Policty

* * * * * * * * * * * * *  NOTE * * * * * * * * * * * * * * * * *

This file is a DRAFT chapter intended to be part of the NIST
Computer Security Handbook.  The chapters were prepared by
different parties and, in some cases, have not been reviewed by
NIST.  The next iteration of a chapter could be SUBSTANTIALLY
different than the current version.  If you wish to provide
comments on the chapters, please email them to roback@ecf.ncsl.gov
or mail them to Ed Roback/Room B154, Bldg 225/NIST/Gaithersburg, MD 
20899.  

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

DRAFT               DRAFT               DRAFT          DRAFT

           Chapter 6:  Computer and Information Security Policy

6.1  Introduction to Computer Security Policy

Organizations rely on IT resources today to handle vast amounts of
information.  Because the data can vary widely in type and in
degree of sensitivity, employees need to be able to exercise
flexibility in handling and protecting it.  It would not be
practical or cost-effective to require that all data be handled in
the same manner or be subject to the same protection requirements. 
Without some degree of standardization, however, inconsistencies
can develop that introduce risks. 

Formal IT security policy helps establish standards for IT resource
protection by assigning program management responsibilities and
providing basic rules, guidelines, and definitions for everyone in
the organization.  Policy thus helps prevent inconsistencies that
can introduce risks, and policy serves as a basis for the
enforcement of more detailed rules and procedures.  Ideally, policy
will be sufficiently clear and comprehensive to be accepted and
followed throughout the organization yet flexible enough to
accommodate a wide range of data, activities, and resources. 

Policy formulation is an important step toward standardization of
security activities for IT resources.  IT security policy is
generally formulated from the input of many members of an
organization, including security officials, line managers, and IT
resource specialists.  However, policy is ultimately approved and
issued by the organization's senior management.  In environments
where employees feel inundated with policies, directives,
guidelines and procedures, an IT security policy should be
introduced in a manner that ensures that management's unqualified
support is clear.  The organization's policy is management's
vehicle for emphasizing the commitment to IT security and making
clear the expectations for employee involvement and accountability.

This chapter will discuss IT security policy in terms of the
different types (program-level and issue-specific), components, and
aspects of implementation.  Potential cost and interdependencies
will also be noted. 

6.2  Policy Types:  Program-Level and Issue-Specific

Two types of policy will typically need to be developed to meet an
organization's needs:  program-level and issue-specific.  Program-
level policy's main function is to establish the security program,
assign program management responsibilities, state the
organizationwide IT security goals and objectives, and provide a
basis for enforcement.  Issue-specific policies also need to be
developed, in order to identify and define specific areas of
concern and to state the organization's position and expectations
in relation to them.  Following are discussions on these two basic
types of policy.

6.2.1  Program-level Policy

As discussed above, program-level policy is broad in scope and far-
reaching in applicability.  To make the subject more manageable, an
effective approach to a discussion of program-level IT security
policy is to break general policy into its basic components:
purpose, scope, goals, responsibilities, and enforcement.

6.2.1.1 Components of Program-level Policy

Purpose:  A primary purpose of program-level policy is to establish
the IT security program.  This includes defining the program
management structure, the reporting responsibilities, the roles of
individuals and groups throughout the organization, and the
organizationwide goals of the security program.  (Chapter 5
provides a detailed discussion of security program management and
administration.)

Additionally, program-level policy should serve the purpose of
emphasizing to all employees the importance of IT security and
clarifying the individual employee's role and responsibilities.  IT
security policy may be met with a degree of skepticism unless given
appropriate visibility and support by top management, and that
visibility and support should be clearly and energetically
reflected in the program-level policy and in its emphasis on
employee participation.

The program-level policy should thus firmly establish individual
employee accountability.  Employees should be made aware via the
policy that even if they are not designated IT security program
personnel, they nonetheless have significant IT security
responsibilities.

Scope:  Program-level policy should be of sufficient breadth of
scope to include all of the organization's IT resources, including
facilities, hardware, software, information, and personnel.  In
some instances, it may be appropriate for a policy to name specific
assets, such as major sites, installations, and large systems.  In
addition to such specified assets, it is important to include an
overview of all of the types of IT resources for which the
organization is responsible, such as workstations, Local Area
Networks (LANs), standalone microcomputers, etc.

Goals:  According to the National Research Council's Computers at
Risk, published in 1991, the three security-related needs
universally most emphasized among IT resource experts and the
general computer user community are integrity, availability, and
confidentiality.  These concepts are the focus of many discussions
in this handbook as well.  These concepts should be the basis of
the goals established for an organization in its IT security
policy.  Integrity means assuring that information is kept intact,
and not lost, damaged, or modified in an authorized manner. 
Availability means assuring that information is accessible to
authorized users when needed and that, to the extent possible, IT
systems are safe from accidental or intentional disablement. 
Confidentiality means assuring that information is accessible only
as authorized and that it cannot be acquired by unauthorized
personnel and/or via unauthorized means.  

Goals related to these concepts should be stated in meaningful ways
to employees based on the given environment.  It is important that
the organization's program-level policy reflect goals that are
applicable to the specific environment by targeting the kinds of
activities, information, and terminology that employees are
familiar with. 

For instance, in an organization responsible for maintaining large
but not highly confidential databases,  goals related to reduction
in errors, data loss, or data corruption might be specifically
stressed.  In an organization responsible for maintaining much more
confidential data, however, goals might emphasize increased
assurance against unauthorized disclosure. 

Responsibilities:  As noted in the earlier discussion of Purpose,
program-level policy performs the important function of
establishing the IT security program and assigning program
management responsibilities.  In addition to the security program
management responsibilities, many other responsibilities throughout
the organization should also be discussed in the policy, including
the role of line managers, applications owners, data users, and the
computer systems security group.

In some instances, the relationships among various individuals and
groups may also need to be defined in the program-level policy. 
Such clarification can diminish ambiguity and confusion related to
areas of responsibility or authority.  It might be desirable to
clarify, for example, who is to be responsible for approving the
security measures to be used for new systems or components being
installed:  Should it be the department line manager where the item
will be installed? Or should it be a designated inter-departmental
IT security specialist?  It might even be desirable to indicate
under what circumstances, if any, approval of security measures
implemented would be warranted by the head of the security program.

Overall, the program-level assignment of responsibilities should
cover those activities and personnel who will be integral to the
implementation and continuity of the IT security policy.

Enforcement:  Without a formal, documented IT security policy, it
is not possible for management to proceed with the development of
enforcement standards and mechanisms.  Program-level policy serves
as the basis for enforcement by describing penalties and
disciplinary actions that can result from failure to comply with
the organization's IT security requirements.  Discipline 
commensurate with levels and types of security infractions should
be discussed.  For example, serious offenses, such as theft,
conspiracy, or intentional acts of sabotage, might be designated by
policy as punishable by firing and prosecution.  Lesser
infractions, such as pirating software, might be stated as
punishable by formal written reprimand. 

Consideration should also be given to the fact that nonconformance
to policy can be unintentional on the part of employees.  For
example, nonconformance can often be due to a lack of knowledge or
training.  It can also be the result of inadequate communication
and explanation of the policy.  For these reasons, it is desirable
that, along with enforcement, program-level policy make provisions
for orientation, training, and compliance within a realistic
timeframe. 

6.2.2  Issue-specific Policy

Whereas program-level policy is intended to address the broadest
aspects of IT security and the IT security program framework,
issue-specific policies need to be developed to address particular
kinds of activities and, in some environments, particular systems. 
The types of subjects covered by issue-specific policies are areas
of current  relevance, concern, and, sometimes, controversy  upon
which the organization needs to assert a position.  In this manner,
issue-specific IT security policies help to standardize activities
and reduce the potential risks posed by inadequate and/or
inappropriate treatment of the IT resources.  Issue-specific
policies serve to provide guidelines for the further development of
procedures and practices within the functional elements of an
organization. 

Program-level policy is usually broad enough that it does not
require much modification over time.  Issue-specific policies,
however, are likely to require revision and updating from time to
time, as changes in technology and related activities take place. 
This is largely because as new technologies develop, some issues
diminish in importance while new ones continually appear.   A major
challenge to IT security specialists has long been the fact that
for every new technology there are also new associated problems and
issues to be addressed.

For example, the enormous increase in the use of electronic mail
(E-mail) systems in recent years has introduced many new issues in
communications security, which is one of the topics that will be
briefly discussed later in this section.  Many organizations today
are developing and refining communications security policies in
order to better address such questions as who should have E-mail
access, how will privileges be assigned and monitored, for what
types of activities and information is E-mail sufficiently secure,
and what criteria should be used for the re-sending (forwarding) of
messages among users.  

Another topic of recent notoriety impacting IT security policies is
the threat posed by computer viruses.  New viruses and new methods
of transmitting them are making it necessary that organizations
develop policies regulating activities that were once performed
freely, such as exchanging floppy disks among users, accessing
electronic bulletinboards, and using shareware products. 

As for the discussion of program-level policy, a useful approach is
to first break issue-specific policy into its basic components: 
statement of an issue, statement of the organization's position,
applicability, roles and responsibilities, and points of contact. 
Thereafter, some of the areas that often require issue-specific
policies will be covered.

6.2.2.1  Components of Issue-specific Policy

Statement of an Issue:  In order to formulate a policy on an issue,
the issue must first be defined, with any relevant terms,
distinctions, and conditions delineated.  For example, an
organization might want to develop an issue-specific policy on the
use of "foreign software."   "Foreign software" might be defined to
mean any software, whether applications or data, not approved,
purchased, screened, managed, and owned by the organization. 
Additionally, the applicable distinctions and conditions might then
need to be included, for instance, for software privately owned by
employees but approved for use at work and for software owned and
used by other businesses under contract to the organization. 

Statement of the Organization's Position:  Once the issue is stated
and related terms and conditions delineated, the organization's
position or stance on the issue will need to be clearly stated. To
continue the example of developing an issue-specific policy on the
use of foreign software, this would mean stating whether use of
foreign software as defined is strictly prohibited, whether or not
there are further guidelines for approval and use, or whether case-
by-case decisions will be rendered based on some defined criteria.

Applicability:  Issue-specific policies will also need to include
statements of applicability.  This means clarifying where, how,
when, to whom, and to what a particular policy applies.  For
example, it could be that the hypothetical policy on foreign
software is intended to apply only to the organization's own onsite
resources and employees and is not to be applicable to contractor
organizations with offices at other locations.  Additionally, the
policy's applicability to employees travelling among different
sites and/or working at home who need to transport and use disks at
multiple sites might need to be clarified.

Roles and Responsibilities:  Also included in issue-specific
policies should be the assignment of roles and responsibilities. 
This would mean, to continue with the above example, that if the
policy permits foreign software privately owned by employees to be
used at work with the appropriate approvals, then the approval
authority granting such permission would need to be stated. 
Likewise, it would need to be clarified who would be responsible
for ensuring that only approved foreign software is used on
organizational IT resources and, perhaps, for monitoring users in
regard to foreign software. 

Related to the assignment of roles and responsibilities is the
inclusion of guidelines for procedures and enforcement.  The issue-
specific policy on foreign-software, for example, might include
procedural guidelines for checking disks used by employees at home
or at other locations.  It might also state what the penalties
would be for using unapproved foreign software on the
organization's IT systems.   

Points of Contact:  For any issue-specific policy, the appropriate
individuals in the organization to contact for further information,
guidance, and enforcement should be indicated.  For example, for
some issues the point of contact might be a line manager; for other
issues it might be a facility manager, technical support person, or
system administrator.  For yet other issues, the point-of-contact
might be a security program representative.  Using the above
example once more, employees would need to know whether the point
of contact for questions and procedural information would be
his/her immediate superior, a system administrator, or a computer
security official.

6.2.2.2  Areas Appropriate for Issue-specific Policies

Some of the areas in which management today needs to consider
issue-specific IT security policies are covered in this section. 
These topics are intended to provide examples and serve as sources
for ideas and analysis.  Although many of these topics are standard
to any discussion of IT security, an organization would necessarily
need to tailor its policies relating to them to meet its own unique
needs.

Physical security:  The physical protection of and access to IT
resources and facilities will generally need to be addressed in one
or more specific policies.   In organizations with extensive IT
systems and equipment, this may mean developing policies that
address such issues as who has access to what sites/locations; how
often risks to installations are be analyzed and by whom; what
types of physical access controls and monitoring equipment are put
in place; what responsibilities will be assigned to trained
security officials and what activities and responsibilities will be
required of all employees.  

Personnel Security:  Depending on the types of activities being 
performed, degree of data sensitivity to be encountered, and sheer
numbers of personnel, specific security policies related to
personnel screening, requirements, hiring, training, evaluating,
and firing may need to be developed and administered.  It may be
appropriate that a trained personnel security specialist initiate,
review, approve, and perform all security-related personnel
actions.

Communications Security:  Communications security is a complex
technical specialty unto itself.  In organizations where day-to-day
business relies on communicating routinely with remote locations,
the security of the communications transmissions and lines is
usually an issue that needs to be addressed by policy.  If the data
being transmitted is highly sensitive, then this concern is
magnified, and issue-specific security policies may need to be
developed on a number of activities.  Issues associated with the
use of cryptography and its related options and procedures
(discussed in Chapter 19), the use of modems and dial-in lines, and
precautions against wiretapping are just some of the potential
issues to be addressed.  Additionally, as noted earlier, the
proliferation of E-mail has introduced many security- and privacy-
related issues for which organizations need to document positions
and policies.

Administrative Security:  Administrative security as it applies to
IT system management and oversight activities comprises many
potential security policy issues.  Included are such topics as
input/output controls, training and awareness, security
certification/accreditation, incident reporting, system
configurations and change controls, and system documentation.

Risk Management:  Risk management involves assessing IT resources
in terms of potential threats and vulnerabilities and planning the
means for counteracting those identified risks.  Issues that will
need to be addressed by policies include how, by whom, and when the
assessments should be performed; and what type of documentation
should result. 

Contingency Planning:  Related to Risk Management, Contingency
Planning means planning for the emergency actions to be taken in
the event of damage, failure, and/or other disabling events that
could occur to systems.  Issues that need to be addressed by
policies include determining which systems are most critical and
therefore of highest priority in contingency planning; how the
plans will be tested, how often, and by whom; and who will be
responsible for approving the plans.  

6.3  Policy Implementation

Policy implementation is a process.  Policy cannot merely be
pronounced by upper management in a one-time statement or directive
with high expectations of its being readily accepted and acted
upon.  Rather, just as formulating and drafting policy involves a
process, implementation similarly involves a process, which begins
with the formal issuance of policy.  

6.3.1  Policy Visibility 

Especially high visibility should be afforded the formal issuance
of IT security policy.   This is due to a combination of factors,
including the following:  

*  Nearly all employees at all levels will in some way be affected;
*  Major organizational resources are being addressed; 
*  Many new terms, procedures, and activities will be introduced. 

Providing visibility through such avenues as management
presentations, panel discussions, guest speakers, question/answer
forums, and newsletters can be beneficial, as resources permit. 
Including IT security as a regular topic at staff meetings at all
levels of the organization can also be a helpful tactic. 

As an aspect of providing visibility for IT security policies,
information should also be included regarding the applicable higher
level directives and requirements to which the organization is
responding.  Educating employees as to the requirements specified
by the Computer Security Act and related OMB circulars will help
emphasize the significance and timeliness of computer security, and

it will help provide a rational basis for the introduction of IT
security policies.

6.3.2   Policy Documentation

Once IT security policy has been approved and issued, it may be
initially publicized through memorandums, presentations, staff
meetings, or a variety of means.  As soon as possible, though, it
will also need to be incorporated into formal policy documentation
as well.  The process of documenting policies will usually require
updating existing documentation as well as creating new
documentation. 

Existing Documentation:  IT security will need to be integrated
into many existing activities and practices throughout many levels
of the organization.  This integration will be facilitated by
revising any existing applicable documentation to reflect new
procedures, rules, and requirements.  Included may be the
modification of various existing documents, forms, and plans at all
levels of the organization to reflect the IT policy.   

For example, if IT equipment purchases and/or upgrades have been
reviewed and approved based on documented criteria such as cost,
productivity, maintainability, etc., then security considerations
may need to be introduced into that criteria.  Also, if it has
previously been the documented policy to review the progress and
status of internal IT systems under development, then security-
related concerns should be introduced into that review process. 

New Documentation:  Additionally, the development of many new
documents, such as guidelines, standards, and procedures, may be
required.  This is often true in large organizations performing
many different activities and having many levels of management.  In
such environments, different functional elements may have widely
differing IT systems and needs to accommodate.  It is therefore
generally more practical, to the extent possible, to allow elements
to tailor their implementations of policy to meet their unique
needs.  This can be accomplished through the development of
documents containing more detailed procedures and practices to be
used for specific kinds of systems and activities within 
functional elements. 

For example, organizations will want to issue policies to decrease
the likelihood of data loss due to technology failures and/or
operator errors.  A program-level policy might state something to
the effect that:  "It is the policy of the organization to ensure
against data loss due to accidents or mishaps."  In an area where
extensive writing and editing of lengthy documents is performed,
such as a word processing or technical publications unit, security
documentation might be developed on saving work in-progress much
more often than would usually be done, and/or utilizing automatic
"save" features on IT systems and software.   In a different type
of functional area, however, where, for example, databases are
maintained that do not undergo significant changes very often, the
security documentation might focus on procedures for the database
administrator to use in performing periodic (daily, weekly, etc.)
backups of the system. 

Appropriate visibility should be afforded the IT security policy
through all applicable documentation.  The more integral security
policy is to all other aspects of daily routines, the more quickly
the associated actions and practices will become natural to doing
business.  Ultimately, among the goals of policy are the
assimilation of a common body of knowledge and values and the
demonstration of appropriate corresponding behaviors.  Those goals
will be expedited by making the IT security policy integral to the
organization through all avenues.

6.4  Cost Considerations

There are a number of potential costs associated with developing
and implementing IT security policies.  In some environments, the
major costs may be those incurred through the numerous
administrative and management activities required for drafting,
reviewing, disseminating, and publicizing the policies.  In some
organizations, though, successful policy implementation may require
additional staffing, training, and equipment.  In general, how
costly IT security policy development and implementation are to an
organization will depend upon how much change needs to be
accomplished in order to ensure adequate security and a basic
standardization throughout the organization.

6.5  Interrelationships 

IT security policy can be related to nearly every topic covered in
this handbook on some level.  This is because all of the topics
discussed in the handbook have associated issues that organizations
may need to address via policies.  The topics most directly
related, however, are:  IT security program management and
administration; risk management; personnel; security training and
awareness; contingency planning; and physical and environmental
security. 

6.6   Conclusion

Formulating viable IT security policies is a challenge for an
organization and requires communication and understanding of the
organizational goals and potential benefits to be derived from
policies.  Through a carefully structured approach to policy
development, which includes the delegation of program management
responsibility and an understanding of both program-level and
issue-specific policy components, a coherent set of policies -
integrated into sensible practices and procedures - can be
developed
6.1, para 2:  IT security policy helps to provide basic standards,
guidelines, and rules for everyone in an organization.  

6.2, para 1:  Program-level IT security policy establishes the
security program and assigns program management responsibilities.

6.2.1.1, para 4:  Program-level policy should be sufficiently broad
in scope to include all of the organization's IT resources.

6.2.1.1, para 5:  Program-level IT security policy goals should
stress the universal concepts of integrity, availability, and
confidentiality. 

6.2.2, para 1:  Issue-specific policies address particular
activities, concerns, and, sometimes, systems.

6.2.2, para 4:  New products, developments, and trends often
require the creation of corresponding issue-specific policies.

6.2.2.2, para 1:  Many activities within an organization should be
considered when developing issue-specific policies, including
physical security, personnel, communications, administrative
security, risk management, and contingency planning.

6.3.1, para 1:  IT security policy should be given especially high
visibility in order to help ensure employee awareness and
understanding.

6.3.2, para 4:  Many existing documents of an organization will
need to be revised to reflect IT security policies, and new
documents may also need to be developed.



Draft Chapter from the NIST Computer Security Handbook, on Cryptography

* * * * * * * * * * * * *  NOTE * * * * * * * * * * * * * * * * *

This file is a DRAFT chapter intended to be part of the NIST
Computer Security Handbook.  The chapters were prepared by
different parties and, in some cases, have not been reviewed by
NIST.  The next iteration of a chapter could be SUBSTANTIALLY
different than the current version.  If you wish to provide
comments on the chapters, please email them to roback@ecf.ncsl.gov
or mail them to Ed Roback/Room B154, Bldg 225/NIST/Gaithersburg, MD 
20899.  

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

DRAFT          DRAFT          DRAFT          DRAFT          DRAFT

                          Cryptography

1.  Introduction

Cryptography provides an important tool for the protection of
information and is used in many aspects of computer security.  
For example, it can help provide data confidentiality and
integrity, support sound user authentication and access controls,
and increase the security provided by other technical controls. 
Many people realize that modern cryptography relies upon advanced
mathematics.  Not all understand, however, that users can obtain
the benefits offered by cryptography without an understanding of
its mathematical underpinnings. 

Cryptography's uses are wide
and varied.  They include
traditional uses such as
eavesdropping protection and
newer uses such as ensuring
that computer files are
unchanged or that computer
programs are not infected with
viruses.  

This chapter describes the use
of cryptography as a tool for
satisfying a wide spectrum of
IT security needs and requirements.  It describes fundamental
aspects of the basic cryptographic technologies, and some
specific ways cryptography can be applied to improve security. 
This chapter also explores some of the important issues which
should be considered when incorporating cryptography into IT
systems.  

2.   BASIC CRYPTOGRAPHIC TECHNOLOGIES

Cryptography relies upon two basic components:  an algorithm (or
cryptographic methodology) and
a key.  For instance, in a
system where letters are
substituted for other letters,
the "key" is the chart of
paired letters and the
algorithm is substitution.  In
modern cryptographic systems,
the algorithms are complex mathematical formulae and keys are
strings of bits.  For two parties to communicate they must use
the same algorithm.  In some cases, they must also use the same
key.   Many cryptographic keys must be kept secret.  Sometimes
algorithms are also kept secret.

There are two basic types of cryptographic systems:  secret key
systems (also called symmetric systems) and public key systems
(also called asymmetric systems).  Table 1 summarizes and
compares some of the distinct features of both secret and public
key systems.  Both types of systems offer advantages and
disadvantages.  Often, the two are combined to form a hybrid
system in order exploit the strengths of each type.  In order to
determine which type of cryptography to utilize, an organization
first has to identify its security requirements and operating
environment. Then the organization can determine which type of
cryptography best meets its needs.

2.1  Secret Key Cryptography

Secret key cryptography is
better known than public key
cryptography.  In secret key
cryptography, two (or more)
parties share the same key. 
In secret key cryptography,
the same key is used to
encrypt and decrypt data.  As
the name implies, secret key cryptography relies on keeping the
key secret.  If this key is compromised, the security offered by
cryptography is severely reduced or entirely eliminated.  Secret
key cryptography assumes that the parties who share a key rely
upon each other not to disclose the key and protect it against
modification.  Since both parties share the same key, secret key
cryptography only protects information against third parties.  

Secret key cryptography can be used to protect both
confidentiality and integrity of information.  It can also be
used to support computer security technical controls, such as
user authentication.  

The best known secret key system is the Data Encryption Standard
(DES), published by NIST as Federal Information Processing
Standard (FIPS) 46-1.  Although the adequacy of DES has at times
been questioned, these claims remain unsubstantiated and DES
remains strong.  It is the most widely accepted, publicly
available cryptographic system today.  Besides being the only
published secret key system approved for protection of Federal
unclassified data, DES has been widely adopted by the commercial
sector.  The American National Standards Institute (ANSI) has
adopted DES as the basis for encryption, integrity, access
control, and key management standards.

2.2  Public Key Cryptography

Public key cryptography is a more modern invention than secret
key cryptography.  It is also very different and is not always
easily understood.  Whereas secret key cryptography employs a
single key shared by two (or more) parties, public key
cryptography uses a pair of keys for each party.  One of these is
"public" and one "private."  The public key can be made known to
other parties, perhaps published in an on-line directory.  The
private key must be kept confidential and be known only to its
owner.  (All keys, however, must be protected against
modification.)

Using this type of cryptography, any party can use any other
party's public key to send an encrypted message; however, only
the party with the corresponding private key can decrypt, and
thus read, the message.  For example, it can be used to send an
encrypted confidential message between Person A and Person B. 
Each person has two keys, one public and one private.  Person A
can encrypt a message to Person B.  To do this, he uses Person
B's Public key.  Only Person B can decrypt the message, which
requires use of his private key.  This ensures that only Person B
can read the message, thus providing data confidentiality.  

Public key cryptography can also be used for other purposes.  For
example, consider again Person A sending a message to Person B. 
In this case, however, Person A not only wants to keep the
message confidential but also for Person B to know that the
message really came from Person A.  In this case, Person A can
encrypt the data with both Person A's private key and Person B's
public key.  When the message is received, Person B decrypts the
message using both Person
A's public key and Person
B's private key.  Like the
other example, Person B is
the only one who can decrypt
the message, thus providing
data confidentiality. 
However, in this case only
Person A could have sent it,
since it was encrypted with
Person A's private key. 
There are many variations of
these basic examples, which
are explained in the
Services section below.  

Public key cryptography is
particularly useful in those
situations when the parties
wishing to communicate can
not rely upon each other or
do not share a common key. 
Public key cryptography is
typically used to protect cryptographic keys used by secret key
cryptography and in digital signatures, but also for other
purposes as discussed later in this chapter.

There are several public key cryptographic systems.  One of the
first public key systems, named RSA after its three MIT creators,
Ronald Rivest, Adi Shamir, and Len Adleman, is in wide use and
can provide many different security services.  The Digital
Signature Standard (DSS), which is described later in the
chapter, is another example of a public key system.

2.3  Hybrid Cryptographic Systems

Public and secret key cryptography have relative advantages and
disadvantages, although it may initially seem that public key
cryptography is preferable because of its versatility.  However,
speed is typically a significant advantage for secret key
systems.  Equivalent implementations of secret key cryptography
can run 1,000 to 10,000 times faster than public key
cryptography.

To exploit the advantages of
both secret and public key
cryptography, an IT system can
use both types in a
complementary manner, with
each performing different
functions.  Typically, the
speed advantage of secret key cryptography means that it is used
for encrypting bulk data. 
Public key cryptography is
used for smaller
transmissions, which are
less demanding to the IT
system's resources.  A
practical use of the public
key side of a hybrid system,
for example, is to automate
the distribution of the keys
used by secret key
cryptography.  This is known
as an example of automated
key distribution.  This type
of hybrid system provides
many of the advantages of
both public and secret key
cryptography while
minimizing the
disadvantages.

3.  USES OF CRYPTOGRAPHY

As discussed in the Introduction,
cryptography can be used to provide
for data confidentiality and
integrity.  It can also be used to
determine the originator of a
message (also known as non-
repudiation, see sidebar) and as a
basis for other security controls,
such as identification and
authentication and logical access controls.  (See chapters *****
and ***** respectively.)  These benefits, called security
services by computer security specialists, are obtained through
specific implementations of cryptography (frequently referred to
as security mechanisms).

Once it is determined what security services are required, the
mechanisms that provide that service can be reviewed.  Then the
most cost-effective ones can be selected.  The following
subsections describe some of the common cryptographic
implementations mechanisms, and the benefits that each can
provide.

3.1  Data Encryption

One of the best ways to obtain
cost-effective data
confidentiality if through the
use of encryption.  Encryption
transforms intelligible data
(understandable to either a
human [e.g., a novel] or
machine [e.g., executable
code]), called "plaintext,"
into an unintelligible form,
called "ciphertext."  This
process is reversed through
the process known as
decryption.  Once data is
encrypted, the ciphertext does
not have to be protected
against disclosure, since it
reveals little (except perhaps
length) about the plaintext. 
It does, however, have to be
protected against
modification.  If it is not,
it will not decrypt correctly.

Both secret key and public key cryptography can be used for data
encryption.  Secret key encryption, as noted above, is typically
much faster, but has attendant key distribution difficulties. 
With secret key cryptography, the same key is used to both
encrypt and decrypt data.  With public key cryptography,
selecting which key or keys to use for encryption can be more
complicated as it is based upon the type of security objectives
desired.  Both encryption methods are designed so that only an
authorized party has the key necessary to decrypt the ciphertext,
thus assuring that only intended parties have access to the data.

3.2  Message Authentication Codes

In IT systems, it is not always possible for humans to scan
information to determine if data has been erased, added or
modified.  Even if scanning were possible, the individual may
have no way of knowing what the correct data should be.  For
example, "do" may be changed to "do not"; or $1,000 may be
changed to $10,000.  It is therefore desirable to have an
automated means of detecting both intentional and unintentional
modifications of data.  While error detecting codes have long
been used in communications protocols (e.g., parity bits), these
are easily defeated to allow modifications to go undetected. 
Fortunately, cryptography can be used in a very secure technique
for performing error detection.

A Message Authentication Code (MAC) is a means for performing
error detection using secret key cryptography in order to detect
unauthorized modifications to data.  NIST FIPS 113, Computer Data
Authentication, specifies a standard technique for calculating a
MAC.  Using a secret key, a MAC is calculated from and appended
to the data.  To verify that the data has not been modified at a
later time, any party with access to the correct secret key can
recalculate the MAC.  The new MAC is compared with the original
MAC, and if they are identical, the verifier has confidence that
the data has not been modified by an unauthorized party.  If the
two MACs are different, then an unauthorized modification must be
assumed.  The calculation and verification of a MAC from data
provides for its integrity, since any modification to the data by
an unauthorized party can be detected.

3.3  Electronic Signatures

Today's IT systems are storing and processing more and more
paper-based documents in electronic form.  Having documents in
electronic form permits rapid processing and transmission and
thereby improves overall efficiency.  However, approval of a
written document has traditionally been indicated by a written
signature.  Thus, there is a need for the electronic equivalent
of a written signature which can be recognized as having the same
legal status as a written signature.  

Why not just take a digital picture of a written signature? 
Unfortunately, a digital image of a written signature (also known
as a digitized written signature) does not provide adequate
security.  Such a digitized written signature could easily be
copied from document to document with no way to determine whether
or not it is legitimate.  Use of cryptography, however, provides
a solution.

Cryptography can be used to protect electronic documents from
modification and forgery by enabling the generation of an
electronic signature that is
intrinsically tied to each
component in the electronic
document.  This means that the
change to a single character
in the document results in an
unpredictable change in the
signature.  Therefore, when
the electronic digital signature created via cryptography is
verified, any alteration is highly likely to be detected.

While there are many uses for electronic signatures, they have
particularly important implications for Electronic Data
Interchange (EDI).  For these important business technologies to
succeed, adequate security services are necessary.  The use of
cryptography in general and the use of electronic signatures in
particular is growing and is likely to become even more
widespread as the use of EDI continues to grow.  Discussed below
are the two types of electronic signatures.

3.3.1  Message Authentication Codes

An electronic signature can be implemented using secret key
cryptography.  If a secret key is used to protect data, and the
key used is shared only by the originator and recipient of the
data, then the recipient can authenticate the originator of the
data, provided that the key has not been released to an
unauthorized party or otherwise compromised.  For example, if two
parties share a secret key and one party receives data with a MAC
that is correctly verified using the shared key, that party may
assume that the data was sent by the other party.  This does
assume, however, that the two parties trust each other.  Thus,
through the use of a MAC, in addition to data integrity,
authentication of origin to the receiver of the data is also
obtained.  Such systems have been approved for use by the Federal
government as a replacement for written signatures on certain
electronic documents.

3.3.2  Digital Signatures

Another type of electronic signature called a "digital signature"
can be implemented using public key cryptography.  Data is
electronically signed by applying the originator's private key to
the data.  (The exact mathematical process for doing this is not
important for this discussion.)  Often, the private key is
applied to a shorter form of the data, called a "hash," rather
than to the entire set of data.  The resulting digital signature
can be stored or transmitted along with the data.  The signature
can be verified by any party using the public key of the signer.
This feature is very useful, for example, when distributing
signed copies of virus-free software.  Any recipient can verify
that the program remains virus-free. If the signature verifies
properly, then the verifier has confidence that the data was not
modified after it was signed and that it was signed by the owner
of the public key.  

Now, recall that with secret key cryptography, both the signer
and verifier can calculate the MAC, since they must share the
same key.  With public key cryptography, however, the private key
used to generate the signature is known only to its owner, and
the signature can be verified by a third party by applying the
signer's public key.  A digital signature, therefore, not only
provides for the integrity and the authentication of the source
of data, but also inherently provides for non-repudiation of
origin, whereby the signer cannot falsely deny having signed the
data.  

NIST has proposed a Digital Signature Standard (DSS) which uses
public key cryptography and is appropriate for applications
requiring a public key-based digital signature.  When approved by
the Secretary of Commerce, the DSS will become the Federal
government's public key digital signature technique for all
unclassified data.  In addition, NIST has proposed a Secure Hash
Standard (SHS) to be used in conjunction with DSS for generating
signatures.

3.4  User Authentication

Cryptography can be used to increase security in user
authentication techniques.  Most password techniques store
passwords on a host system in encrypted form to protect them from
disclosure to unauthorized parties.  When authenticating to a
remote computer system via a network, passwords typically travel
over the network in plaintext form where they are vulnerable to
eavesdropping;  again, cryptography could be used to protect the
passwords from disclosure as they travel over the network. 
Cryptography can also allow the use of passwords to be reduced by
replacement with a "cryptographic handshake," particularly for
multiple logins across a network.  For example, the host can
challenge the user with an encrypted random number.  The user can
authenticate himself by responding with the correct decrypted
number, thereby demonstrating that he shares a common key with
the host.  Thus, cryptography can play various useful roles
either as a tool or as the actual basis for user authentication
techniques.

4.  CONSIDERATIONS WHEN IMPLEMENTING CRYPTOGRAPHY

This section explores several of the important issues which
should be considered when integrating cryptography into an IT
system.

4.1  Security of Cryptographic Modules

Cryptography is typically implemented in a "module" comprised of
software, firmware, hardware, or some combination thereof.  This
module contains the cryptographic algorithm and the key(s).  In
order for the module to properly function, it must be protected
from tampering.  Protection may also have to be provided to
protect the key(s) and possibly the algorithm against disclosure. 
Additionally, users and computer systems must be able to rely
upon the proper functioning of the cryptography.  For these
reasons, the module requires some protection.  This is usually
obtained through the secure design, implementation and use of a
cryptographic module.

NIST Proposed FIPS 140-1, Security Requirements for Cryptographic
Modules, specifies the physical and logical security requirements
for a cryptographic module. 
The proposed standard defines
four security levels for
cryptographic modules, with
each level providing a
significant increase in
security over the preceding
level.  The four increasing levels of security allow for cost-
effective solutions that are appropriate for different degrees of
data sensitivity and different applications environments.  The
user is afforded the flexibility to select the best module for
any given type of IT system, thus avoiding the cost of
unnecessarily elaborate security features where they are not
needed.

4.2  Key Management

The proper management of cryptographic keys is essential to the
effective use of cryptography for security.  Ultimately, the
security of information protected by cryptography is directly
dependent upon the protection afforded to the keys.  Key
management involves the procedures, both manual and automated, to
be used throughout the entire life cycle of the keys, which
includes the generation, distribution, storage, entry and use,
and destruction and archiving of the cryptographic keys. 
Protection must be provided to protect all keys from
modification.  Some keys must also be kept secret.  Unique key
management issues must also be addressed by users of both public
key and secret key cryptography.

With secret key cryptography, the secret key(s) must be securely
distributed to the parties wishing to communicate.  Depending
upon the number and location of users, this may not be a trivial
task.  Automated techniques for distributing and generating
cryptographic keys can ease the overhead of key management, but
some resources will still have to be devoted to this task.  FIPS
171, Key Management Using ANSI X9.17, provides key management
solutions for a variety of operational environments.  

Public key cryptography users also must confront key management
issues.  For example, since private keys are ties to specific
users (or positions or organizations), it is necessary to "bind"
a key pair to a specific user.  This is done by a "certificate
issuing authority," which determines the identity of an
individual before "certifying" the public key.  

4.3  Standards 

NIST and other standards organizations have developed numerous
standards for the design, implementation, and use of cryptography
and for its integration into IT systems.  The use of
cryptographic modules that conform to cryptographic standards can
provide significant benefits
to an organization.  Standards
provide solutions that have
been accepted by a wide
community and that have
withstood the scrutiny of
experts.  Standards help
ensure interoperability among different vendors' equipment, thus
allowing an organization to select from among multiple
alternatives in order to find cost-effective equipment.  By using
voluntary standards, Federal government organizations can reduce
costs and protect their investments in technology by buying
off-the-shelf products.  

4.4  Configurations of Cryptographic Modules

Another area that needs to be considered is how the cryptographic
module will interact with the IT system.  Cryptographic modules
can either be configured: off-line or in-line.  In an off-line
configuration, a cryptographic module accepts information from
the IT system, performs the required the cryptographic
operations, and then passes the processed information back to the
IT system.  In an in-line configuration, a cryptographic module
accepts information to be processed from one part of the IT
system, performs the required cryptographic operations, and then
passes the processed information directly to other parts of the
IT system.  

4.5  Networking Issues

The use of a cryptographic module within an IT system that is
used in networking applications may require special
considerations.  In these applications, the suitability of a
cryptographic module may depend on its capability to handle any
special requirements imposed by locally attached communications
equipment or by the network protocols and software.

Another concern arises if encrypted information, MACs, or digital
signatures, which may appear as random data, inadvertently
contain data that may be misinterpreted by the communications
equipment or software as being control information.  In this
case, it may be necessary to filter the encrypted information,
MAC, or digital signature to ensure that it does not contain any
control information that might confuse the communications
equipment or software.  It essential to ensure that the
cryptography satisfies any requirements imposed by the
communications equipment and does not interfere with the proper
and efficient operation of the network.

4.6  Cost Considerations

The cost of employing cryptography to protect IT systems can be
characterized in terms of both direct and indirect costs, as will
be discussed below.  Cost is in part determined by product
availability;  a wide variety of products exists for implementing
cryptography in integrated circuit (IC) chips, add-on boards or
adaptors, and stand-alone units, and many of these products
implement accepted cryptographic systems (e.g., DES) and conform
to other security standards.

4.6.1  Direct Costs

The direct costs of employing cryptography include:

    acquiring or implementing the cryptographic module and
     integrating it into the IT system;  the medium (i.e.,
     hardware, software, firmware or combination thereof) and
     various other issues such as level of security, logical and
     physical configuration, and special processing requirements
     will have an impact on cost;

    managing the cryptography, and, in particular, managing the
     cryptographic keys, which includes key generation,
     distribution, archiving and disposition as well as the
     security measures to protect the keys, as appropriate.

4.6.2  Indirect Costs

The indirect costs of employing cryptography can include:

    a limited decrease in system or network performance,
     resulting from the additional overhead of applying
     cryptographic protection to stored or communicated data;

    changes in the way users interact with the system, resulting
     from more stringent security enforcement.  It should,
     however, be noted that cryptography can be made relatively
     transparent to the users such that the impact is minimal.

5.  INTERDEPENDENCIES

There are many interdependencies between cryptography and other
security controls highlighted in this Handbook.  Cryptography
both depends on other aspects of IT security and also assists in
providing many other security safeguards.

5.1  Physical and Environmental Security

The physical protection of a cryptographic module is important
for protecting the cryptographic system and keys within from
scrutiny and tampering.  In many environments, the cryptographic
module itself must provide high levels of physical security.  In
other environments, a cryptographic module may be employed within
IT systems residing in a secured facility with adequate physical
security for the cryptographic module.

5.2  Identification and Authentication

Cryptography can be used both to protect passwords that are
stored on computer systems, and to protect passwords that are
communicated between computers.  Furthermore, cryptographic-based
authentication techniques may be used in conjunction with
password-based techniques to provide stronger authentication of
users.

5.3  Logical Access Control

In many cases, cryptographic software may be embedded within a
host system, and it may not be feasible to provide extensive
physical protection to the host system.  In these cases, logical
access control may provide a means to isolate the cryptographic
software from other parts of the host system, and hence, protect
the cryptographic software and keys from scrutiny and tampering. 
The use of such controls essentially provides the logical
equivalent of physical protection.

5.4 Audit

Cryptography may play a useful role in performing auditing.  For
example, audit records may need to be communicated from computers
being audited to another computer that collects the audit
information.  In this case, cryptography may be needed to protect
the communicated audit records from disclosure or modification,
or to authenticate the source of the audit record.  Cryptography
may also be needed to protect audit records stored on IT systems
from disclosure or modification.

5.5 Assurances

Assurance that a cryptographic module is properly and securely
implemented is essential to the effective use of cryptography to
protect IT systems.  NIST maintains validation programs for
several of its standards for cryptography.  Vendors can have
their products validated for
conformance to the standard
through a rigorous series of
tests.  Such testing provides
increased assurance that a
module meets stated standards,
and system designers,
integrators, and users
generally have greater confidence that validated products conform
to accepted standards.

6.  CONCLUSION

Cryptography provides an important means for improving the
security of IT systems.  It can be used to provide both data
confidentiality and integrity.  User authentication procedures
can also be strengthened through cryptographic techniques.  Use
of digital signatures, an important cryptographic application,
will speed the use of EDI.  Cryptography, however, can not be
implemented without costs.  Careful study is required to
determine the types of systems and applications best suited to an
organizations's environment.  

7.  REFERENCES

[1]  Data Encryption Standard (DES), National Institute of
     Standards and Technology (U.S.), Federal Information
     Processing Standards Publication (FIPS PUB) 46-1, National
     Technical  Information Service, Springfield, VA, April,
     1977.

[2]  New Directions in Cryptography, IEEE Transactions on
     Information Theory, W. Diffie and M. Hellman, Vol. IT-22,
     No.  6, November 1976, pp.  644-654.

[3]  Public-Key Cryptography, National Institute of Standards and
     Technology Special Publication 800-2, James Nechvatal, April
     1991.

[4]  A Method For Obtaining Digital Signatures and Public-Key
     Cryptosystems, R. Rivest, A. Shamir, and L. Adleman,
     Communications of the ACM, Vol. 21, No. 2, 1978, pp.
     120-126.

[5]  Computer Data Authentication, National Institute of
     Standards and Technology (U.S.), Federal Information
     Processing Standards Publication (FIPS PUB) 113, National
     Technical Information Service, Springfield, VA, May 30,
     1985.

[6]  CSL Bulletin on Advanced Authentication Technology, Computer
     Systems Laboratory, National Institute of Standards and
     Technology, Gaithersburg, MD, November 1991.

[7]  A Proposed Federal Information Processing Standard for
     Digital Signature Standard (DSS), Federal Register Vol. 56,
     No. 169, August 30, 1991.

[8]  Proposed Federal Information Processing Standard for Secure
     Hash Standard (SHS), Federal Register Vol. ??, No. ??,
     January 31, 1992.

[9]  Security Requirements for Cryptographic Modules, National
     Institute of Standards and Technology (U.S.), Draft Federal
     Information Processing Standards Publication (FIPS PUB)
     140-1.

[10] American National Standard for Financial Institution Key
     Management (Wholesale), ANSI X9.17-1985, American Bankers
     Association, Washington, DC.

[11] Key Management Using ANSI X9.17, National Institute of
     Standards and Technology (U.S.), Federal Information
     Processing Standards Publication (FIPS PUB) 171, National
     Technical Information Service, Springfield, VA, April 1992. 

[12] Information Processing Systems - Open Systems
     Interconnection Reference Model - Part 2: Security
     Architecture, International Organization for
     Standardization, ISO 7498/2:1988.

[13] Security Mechanisms in High-Level Network Protocols, V.L.
     Voydock and S.T. Kent, ACM Computing Surveys Vol. 15, No. 2,
     June 1983.
8.  SIDEBAR NOTES

 Cryptography can be used to protect data communicated among
  computers and to
  to protect data and programs stored within computers. (1.)

 Cryptography can be used to control access to computers and
  networks. (1.)

 There are two basic types of cryptography systems:  "secret
  key" and "public key." (2.) 

 The best known secret key system is the Data Encryption
  Standard (DES). (2.1)

 Secret key systems are often used for bulk data encryption and
  public key systems for automated key distribution. (2.3)

 Cryptography can provide security services such as data
  confidentiality, data integrity, data origin authentication,
  non-repudiation, and access control. (3.)

 A Message Authentication Code (MAC) can be used to verify the
  integrity and origin of data. (3.2.2)

 Cryptography can provide the electronic equivalent of a
  written signature. (3.2.3)

 NIST has proposed the Digital Signature Standard.  (3.2.3.2)

 The contents of a cryptographic module should be protected
  from scrutiny and tampering. (4.1)

 NIST Draft FIPS 140-1 defines basic security requirements for
  cryptographic modules. (4.1)

 Key management involves the secure generation, distribution,
  storage, entry and use, and destruction and archiving of
  cryptographic keys. (4.2)

 Applicable security standards provide a common level of
  security and interoperability among users. (4.3)

 NIST maintains validation programs for several of its
  cryptographic standards. (5.5)
junk:

The effective use of cryptography within IT systems requires that
an organization first identify which security services are
needed, based on its security or protection objectives. 
Appropriate mechanisms to attain the objectives can then be
selected.   

3.1  Services

The most common security services that can be achieved through
the use of cryptography include the following:

 Data confidentiality: ensures that data is not disclosed to
  unauthorized parties.

 Data integrity: ensures that data is not modified in an
  unauthorized manner.

 Non-repudiation of origin: provides evidence that the source
  of received data is as claimed, whereby that evidence can be
  verified by a third party.  Or, in other words, that the
  originator of the data cannot falsely deny having originated
  the data.

 Access control: provides protection against unauthorized use
  of IT resources.

3.2  Mechanisms - The Means to Obtaining the Security Service