## **DEPARTMENTAL INFORMATION RESOURCE MANAGEMENT MANUAL (DIRMM) DOT ORDER 1350.2**

U.S. DEPARTMENT OF TRANSPORTATION

OFFICE OF THE SECRETARY

DOT H 1350.250

GUIDE TO ESTABLISHING AN INFORMATION SYSTEM PROTECTION PROGRAM

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. GOALS

4\. REFERENCES

5\. OVERVIEW OF INFORMATION SYSTEM PROTECTION

A. Background

B. The GAO Study

6\. RISK MANAGEMENT

A. Five Principles of Risk Management

B. Sixteen Successful Practices

7\. INFORMATION SYSTEM PROTECTION ELEMENTS

A. Information Systems Security Plan

B. Risk Assessment

C. Continuity of Operations

D. Certification/Accreditation

E. Incident Handling

F. Personnel Security

G. Physical/Environmental Security

H. Information System Security Awareness, Training and Education

PURPOSE

The purpose of the 1350.250 series of Guides is to provide guidance in
the

establishment of an Information System Protection Program for the
Department

of Transportation (DOT) and its Operating Administrations. The series
consists

of this document, which contains an overview of the entire Risk
Management

planning process, and individual documents that treat each major
planning area

in depth. These supplemental documents include:

1350.251 - Departmental Guide to Developing an Information System
Security

Plan

1350.252 - Departmental Guide to Risk Assessment Planning

1350.253 - Departmental Guide to Continuity of Operations Planning

1350.254 - Departmental Guide to Certification/Accreditation of
Information

Systems

1350.255 - Departmental Guide to Incident Handling Planning

1350.256 - Departmental Guide to Personnel Security Planning

1350.257 - Departmental Guide to Physical/Environmental Security
Planning

1350.258 - Departmental Guide to Developing an Information System
Security

Awareness/Training/Education Program

SCOPE

The provisions of this document apply to all DOT employees, volunteers
and

contractor support personnel.

GOALS

The DOT Information Systems Security Program is designed to:

Satisfy Federal Requirements

Protect Information Technology

Provide Information System Security Awareness and Training

Provide Information System Security Program Planning Guidance

REFERENCES

All references and terms used in this document are listed and explained
in DOT

H 1350.2.1, ISS References/Definitions, dated March 3, 1999.

OVERVIEW OF INFORMATION SYSTEM PROTECTION

Background

Recent break-ins to U.S. government and university computer systems

demonstrate just how vulnerable even the most sophisticated
organizations

can be to technological assaults. While the new attacks caused no
apparent

damage to information or to the systems, these incidents are unfortunate

reminders that the potential exists for severe damage. Systems are at
risk

from fraud, user errors, accidents and natural disasters, as well as
from

sabotage and other malicious acts.

It is a fact of life that organizations are becoming increasingly
dependent

on interconnected information systems to conduct business and to provide

information and services to their customers. While the vulnerabilities
of

systems are getting increasing attention, the General Accounting Office

(GAO) studied organizations that had successfully adopted superior
security

programs to improve their information security.

The GAO Study

For many years, the GAO had found weaknesses in the information systems
of

federal agencies. Many agencies had not instituted information security

programs to establish controls for their systems and to monitor those

controls for their effectiveness. To gain a broader understanding of how

security programs can be successfully implemented, GAO studied the

management practices of eight nonfederal organizations. The focus was on
the

management framework that the organizations had established rather than
on

specific controls that had been adopted.

The nonfederal organizations studied by the GAO manage the same types of

risks as federal organizations. Both federal and nonfederal
organizations

are concerned with protecting the confidentiality, integrity and

availability of information. Secure information systems are essential to

providing high-quality services to customers, avoiding fraud and
disclosure

of sensitive information, promoting efficient business operations, and

complying with laws and regulations. All of the organizations studied
had

reoriented their security programs to make them visible, integral
components

of their business operations.

The GAO findings have been published in an exposure draft executive
guide

entitled Information Security Management, Learning from Leading

Organizations. The GAO discussed its findings with several government

organizations concerned with federal security policies, including the

National Institute of Standards and Technology (NIST).

RISK MANAGEMENT

Risk management is the process of assessing risk, taking steps to reduce

risk to an acceptable level, and maintaining that level of risk.
Managers

analyze risks for many aspects of their business; they consider
alternatives

and implement plans to maximize returns on their investments. A risk

management process for information systems enables managers and their

organizations to build an in-depth knowledge about their systems and how

they are interrelated.

Risk management is a vital element of a comprehensive information
security

program. Several NIST publications deal with this topic (See DOT H

1350.2.1).

Five Principles of Risk Management

The GAO identified five principles of risk management, which had been

adopted by the organizations studied:

Assess risk and determine needs

Establish a central management focus

Implement appropriate policies and related controls

Promote awareness

Monitor and evaluate policy and control effectiveness

The successful organizations applied these principles by linking them
into a

cycle of activity that enabled the organizations to address risks on an

ongoing basis. The success of security programs depended upon the

recognition and understanding of the senior executives that their

information systems were subject to risks and that these risks affected

their business operations. After assessing risks of their business

operations, the organizations established policies and selected
controls.

They emphasized increased awareness of users to the policies and
controls.

They monitored the effectiveness of the policies and controls and used
the

results to determine if modifications of policies and controls were
needed.

Central security management offices coordinated this cycle of
activities.

All organizations studied said that risk considerations and related

cost-benefit tradeoffs were a primary focus of their security programs.

Security was not an end in itself, but a set of policies and controls

designed to support business operations.

Sixteen Successful Practices

The GAO found that there were general practices associated with each
risk

management principle and that these practices were common to the

organizations studied.

1\) Principle: Assess the risk and determine needs.

Practice 1. Recognize information resources as essential organizational

assets that must be protected. The efforts of high-level executives to

understand and manage risks helped to ensure that security was taken

seriously at lower levels in the organization and that security programs
had

adequate resources. Security specialists kept managers at all levels

informed of emerging security issues. For some organizations, the
high-level

interest was driven by an incident that demonstrated system
vulnerabilities.

Some organizations were exploring new ways to improve operational
efficiency

and services to customers through information technology and were
concerned

about the security of these new systems.

Practice 2. Develop practical risk assessment procedures that link
security

to business needs. While the organizations explored a variety of risk

management methodologies, they were generally satisfied with relatively

simple risk assessment practices that could be adopted by different

organizational units and that involved both technical people and those
with

knowledge of business operations. In one organization, simple automated

checklists were used. Another organization established standard
procedures

for requesting and granting new network connections, requiring
documentation

of the business need for the connection and the risks associated with
it.

None of the organizations tried to quantify the risks precisely because
of

the difficulty of identifying such data.

Practice 3. Hold program and business managers accountable. The

organizations studied felt that business managers should be held
accountable

for managing the information security risks associated with their

operations, just as they are held accountable for other business risks.

Security specialists in these organizations had an advisory role,
including

keeping management informed about risks. Similarly, program managers in

federal agencies are also considered to be in the best position to
determine

which of their information resources are the most sensitive and to
assess

the impact of security problems.

Practice 4. Manage risk on a continuing basis. The organizations studied

emphasized continuous attention to security. The continuity of attention

helped to ensure that controls were appropriate and effective, and that

individuals who used and maintained information systems complied with
the

organizational policies. For federal organizations, the Office of
Management

and Budget has developed policies that promote a risk-based approach.
These

policies have been issued in Circular A130, Appendix III, Security of

Federal Automated Information Resources.

2\) Principle: Establish a central management focal point.

Practice 5. Designate a central group to carry out key activities.
Central

security groups served as catalysts for ensuring that information
security

risks are considered in planned and ongoing operations. These groups

provided advice and expertise to all organizational levels and kept
managers

informed about security issues. They developed organization-wide
policies

and guidance; educated users about information security risks;
researched

potential threats, vulnerabilities and control techniques; tested
controls;

assessed risks; and identified needed policies.

Practice 6. Provide the central group with ready and independent access
to

senior executives. The organizations studied knew that security concerns

could be at odds with the desires of business managers and system
developers

to develop new computer applications quickly and to avoid controls which

might impede efficiency and convenience. Elevating security concerns to

higher management levels helped to ensure that the risks were understood
and

taken into account when decisions were made.

Practice 7. Designate dedicated funding and staff. Unlike many federal

agencies, the organizations studied defined budgets that enabled them to

plan and set goals for information security programs. The budgets
covered

central staff salaries, training, and security software and hardware. In

these organizations, information security responsibilities had been
clearly

defined for the groups carrying out the security programs, and dedicated

staff resources had been provided to carry out these responsibilities.

Practice 8. Enhance staff professionalism and technical skills. The

organizations studied had taken steps to provide personnel involved in

information security programs with the skills and knowledge that they

needed. Staff expertise was updated frequently to keep skills and
knowledge

current. Staff members attended technical conferences and specialized

courses, connected with other professionals in the field, and reviewed

technical literature and bulletins. Special training courses were
provided

for system administrators who are the first line of defense against
security

intrusions and often in the best position to notice unusual activities.

Because of the strong demand for security professionals, these
organizations

made special efforts to attract and keep expert staff members.

3\) Principle: Implement appropriate policies and related controls.

Practice 9. Link policies to business risks. The organizations studied

stressed the importance of up-to-date policies that made sense to users
and

others who were expected to understand them. A current and comprehensive
set

of policies is a key element in an effective security program. These

policies must be adjusted on a continuing basis to respond to newly

identified risks. The policies of the organizations studied paid
particular

attention to user behavior. In today\'s interconnected network
environment,

users can accidentally disclose sensitive information to many people
through

electronic mail or introduce damaging viruses that are then transmitted
to

other computers in the organization\'s networks.

Practice 10. Distinguish between policies and guidelines. Policies
generally

outlined fundamental requirements that managers considered to be
mandatory,

while guidelines contained more detailed rules for implementing the

policies. By distinguishing between the two, the organizations studied
were

able to emphasize the most important elements of information security
while

providing flexibility to unit managers in implementing policies.

Practice 11. Support policies through the central security group. The

organizations studied had central security management groups responsible
for

writing policies in partnership with other organizational officials. The

central groups provided explanations, guidance, and support to the
various

units in the organization. This practice encouraged business managers to

support centrally developed policies that addressed organizational needs
and

were practical to implement.

4\) Principle: Promote awareness.

Practice 12. Continually educate users and others on risks and related

policies. The central security management groups worked to improve

everyone\'s understanding of the risks associated with information
systems

and of the policies and controls in place. They encouraged compliance
with

policies and awareness on the part of users of the risks involved in

disclosing sensitive information or passwords.

Practice 13. Use attention-getting and user-friendly techniques. The

techniques used included intranet Web sites that explained policies,

standards, procedures, alerts and special notices; awareness videos with

messages from top managers about the security program; interactive

presentations by security staff with various user groups; security
awareness

days; and products with security related slogans.

5\) Principle: Monitor and evaluate policy and control effectiveness.

Practice 14. Monitor factors that affect risk and indicate security

effectiveness. The organizations studied directly tested the
effectiveness

of their controls. Most organizations relied primarily on auditors to
carry

out this function. This enabled the security organizations to maintain
their

role as advisors. The central security management groups kept track of
audit

findings and the organization\'s progress in implementing corrective
actions.

In some cases, the central security management groups conducted their
own

tests, and some organizations allowed designated individuals to try to

penetrate systems. The testing of controls enabled the organizations to

identify unknown vulnerabilities and to eliminate or reduce them. All of
the

organizations monitored compliance with policies, mostly through
informal

feedback to the central security group from system administrators. All
of

the organizations kept summary records of actual security incidents to

measure the types of violations and the damage suffered from the
incidents.

The records were valuable input for risk assessments and budget
decisions.

Many of the organizations expressed an interest in developing better

techniques to measure the benefits and costs of security policies and

controls.

Practice 15. Use results to direct future efforts and hold managers

accountable. Organization officials said that monitoring encourages

compliance with information security policies, but the full benefits of

monitoring are not achieved unless results are used to improve the
security

program. Results can be used to hold managers accountable for their

information security responsibilities.

Practice 16. Be alert to new monitoring tools and techniques. Security

managers of the organizations studied said that they continually looked
for

new tools to test the security of their systems. They found current

professional literature and involvement with professional organizations

useful in learning about the latest monitoring tools and research
efforts.

INFORMATION SYSTEM PROTECTION ELEMENTS

The process for planning an efficient and effective Information System

Protection Program consists of several discrete, yet interrelated
elements,

as shown in Figure 1.

Figure 1, Information System Protection Elements

Information Systems Security Plan

The purpose of the security plan is to provide an overview of the system
and

describe the controls in place or planned for meeting security
requirements.

The system security plan also delineates responsibilities and expected

behavior of all individuals who access the system. This plan is a
required

portion of the Certification and Accreditation process.

Refer to DOT H 1350.251 - Departmental Guide to Preparing an Information

Systems Security Plan for additional information and guidance.

Risk Assessment

A risk assessment is a process for measuring the compliance of an

organization with applicable security requirements. It identifies the

overall risks that could adversely affect a system, thereby compromising

sensitive data or the ability of the organization to fulfill its
mission. A

risk assessment also identifies and analyzes those threats and

vulnerabilities that could adversely affect the system, evaluates
in-place

security safeguards, and recommends new or improved security safeguards
to

reduce and/or eliminate the risk of loss or damage to system assets or

disruption of system services. It also provides an assessment of risk as

part of a risk-based approach in determining adequate security for the

system. The risk assessment is a crucial element of the overall Risk

Management process.

Refer to DOT H 1350.252 - Departmental Guide to Risk Assessment Planning
for

additional information and guidance.

Continuity of Operations

Continuity of Operations planning addresses how to keep an
organization\'s

critical functions operating in the event of emergencies, disruptions,
or

disasters. Such events include power outages, hardware failures,
malicious

attacks, fires, or storms. If an event is very destructive, it is often

called a disaster. Like other government agencies, DOT depends on the

availability of accurate and timely information to manage a broad range
of

programs and budgets with far-reaching effects. Virtually all vital DOT

information is processed in some form by computers. Hence a key aspect
in

DOT\'s overall risk management program must be the ability to respond to

unplanned, adverse situations that may destroy, damage, degrade, or

compromise information systems data or computer processing capabilities
so

that essential operations may continue. Ensuring that this ability
exists,

and is indeed viable (proven via periodic testing) is the major function
of

continuity of operations planning.

Refer to DOT H 1350.253 - Departmental Guide to Continuity of Operations

Planning for additional information and guidance.

Certification/Accreditation

System security accreditation is the formal authorization by the
accrediting

official for system operation and an explicit acceptance of risk. It is

usually supported by a review of the system, including its management,

operational, and technical controls. This review may include a detailed

technical evaluation, security evaluation, risk assessment, audit, or
other

such review. If the life cycle process is being used to manage a project

(such as a system upgrade), it is important to recognize that the

accreditation is for the entire system, not just for the new addition.

The best way to view computer security accreditation is as a form of
quality

control. It forces managers and technical staff to work together to find
the

best fit for security, given technical constraints, operational
constraints,

and mission requirements. The accreditation process obliges managers to
make

critical decisions regarding the adequacy of security safeguards. A
decision

based on reliable information about the effectiveness of technical and

non-technical safeguards and the residual risk is more likely to be a
sound

decision.

After deciding on the acceptability of security safeguards and residual

risks, the accrediting official should issue a formal accreditation

statement. While most flaws in system security are not severe enough to

remove an operational system from service or to prevent a new system
from

becoming operational, the flaws may require some restrictions on
operation

(e.g., limitations on dial-in access or electronic connections to other

organizations). In some cases, an interim accreditation may be granted,

allowing the system to operate requiring review at the end of the
interim

period, presumably after security upgrades have been made.

Refer to DOT H 1350.254 - Departmental Guide to
Certification/Accreditation

of Information Systems for additional information and guidance.

Incident Handling

Incident handling is closely related to contingency planning as well as

support and operations. An incident handling capability may be viewed as
a

component of contingency planning, because it provides the ability to
react

quickly and efficiently to disruptions in normal processing. Broadly

speaking, contingency planning addresses events with the potential to

interrupt system operations. Incident handling can be considered that

portion of contingency planning that responds to malicious technical

threats. The primary benefits of an incident handling capability are

containing and repairing damage from incidents, and preventing future

damage. An incident handling capability also assists an organization in

preventing (or at least minimizing) damage from future incidents.
Incidents

can be studied internally to gain a better understanding of the

organization\'s threats and vulnerabilities so more effective safeguards
can

be implemented.

Refer to DOT H 1350.254 - Departmental Guide to Incident Handling
Planning

for additional information and guidance.

Personnel Security

Many important issues in computer security involve human users,
designers,

implementers, and managers. A broad range of security issues relates to
how

these individuals interact with computers, and the access and
authorities

they need to do their job. Personnel security addresses issues
concerning

the staffing of positions that interact with computer systems, the

administration of users on a system (including considerations for

terminating employee access), and special considerations that may arise
when

contractors or the public have access to systems.

Refer to DOT H 1350.255 - Departmental Guide to Personnel Security
Planning

for additional information and guidance.

Physical/Environmental Security

The term physical and environmental security refers to those measures
taken

to protect systems, buildings, and related supporting infrastructure
against

threats associated with their physical environment. Physical and

environmental security controls include three broad areas:

The physical facility (usually the building, other structure, or vehicle

housing the system and network components). The physical characteristics

of these structures and vehicles determine the level of such physical

threats as fire, roof leaks, or unauthorized access.

The facility\'s general geographic operating location determines the

characteristics of natural threats, which include earthquakes and

flooding; man-made threats such as burglary or interception of

transmissions; and damaging nearby activities, including toxic chemical

spills, and electromagnetic interference from emitters such as radar.

Supporting facilities are those services that underpin the operation of

the system. The system\'s operation usually depends on supporting

facilities such as electric power, heating and air conditioning, and

telecommunications.

Refer to DOT H 1350.256 - Departmental Guide to Physical/Environmental

Security Planning for additional information and guidance.

Information System Security Awareness, Training and Education

The major causes of loss due to an organization\'s own employees are
errors

and omissions, fraud, and actions by disgruntled employees. One
principal

purpose of security awareness, training, and education is to reduce
errors

and omissions. However, it can also reduce fraud and unauthorized
activity

by disgruntled employees by increasing employees\' knowledge of their

accountability and the penalties associated with such actions.

Awareness stimulates and motivates those being trained to care about

security and to remind them of important security practices. Explaining
what

happens to an organization, its mission, customers, and employees if

security fails motivates people to take security seriously. The purpose
of

training is to teach people the skills that will enable them to perform

their jobs more securely. This includes teaching people what they should
do

and how they should (or can) do it. Training can address many levels,
from

basic security practices to more advanced or specialized skills. It can
be

specific to one computer system or generic enough to address all
systems.

Security education is more in-depth than security training and is
targeted

for security professionals and those whose jobs require expertise in

security.

Refer to DOT H 1350.257 - Departmental Guide to Developing an
Information

System Security Awareness/Training/Education Program for additional

information and guidance.

Chapter 11- DIRMM U.S. DEPARTMENT OF TRANSPORTATION

OFFICE OF THE SECRETARY

DOT H 1350.251

DEPARTMENTAL GUIDE TO

DEVELOPING AN INFORMATION

SYSTEMS SECURITY PLAN

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. GOALS

4\. REFERENCES

5\. OVERVIEW OF INFORMATION SYSTEM SECURITY PLANNING

6\. SECURITY PLAN DEVELOPMENT

A. Step 1. System Analysis

\(1\) System Boundaries

\(2\) System Categories

B. Step 2. Definition of Overall System Information

C. Step 3. Management Controls

D. Step 4. Operational Controls

\(1\) Major Application Operational Controls

\(2\) General Support System Operational Controls

E. Step 5. Technical Controls

\(1\) Major Application Technical Controls

\(2\) General Support System Technical Controls

DEPARTMENTAL GUIDE TO DEVELOPING AN

INFORMATION SYSTEMS SECURITY PLAN

PURPOSE

The purpose of this Guide is to provide Department of Transportation
(DOT) and

their Operating Administration managers, ISSO's and network
administrators

with a step-by-step approach for preparing an Information Systems
Security

Plan. This Plan should provide an overview of the security requirements
of an

information system, describe the controls in place or planned for
meeting

those requirements, and delineate responsibilities and expected behavior
of

all individuals who access the system.

SCOPE

The provisions of this Guide apply to the Department of Transportation
(DOT),

its Secretarial Offices and Operating Administrations.

GOALS

The Goal of system security planning is to improve protection of
information

technology (IT) resources. All federal systems have some level of
sensitivity

and require protection as part of good management practice. This
protection,

in turn, must be documented in an Information Systems Security Plan.

REFERENCES

The DOT Departmental Information Resources Management Manual (DIRMM) DOT
H

1350.2 implements statutory and regulatory Information Resources
Management

(IRM) and security requirements for the Department. It also calls for
ensuring

the confidentiality, integrity, and availability of information
contained,

processed, or transmitted in/on sensitive systems. Refer to DOT H
1350.2.1

REGULATORY AND GUIDANCE DOCUMENTS for specific references.

OVERVIEW OF INFORMATION SYSTEM SECURITY PLANNING

The completion of information system security plans is a requirement of
the

Office of Management and Budget (OMB) Circular A-130, Management of
Federal

Information Resources, A-130 Appendix III, Security of Federal Automated

Information Resources, and Public Law 100-235, Computer Security Act of
1987.

The level of detail included within the plan should be consistent with
the

criticality and value of the system to the organization's mission (i.e.,
a

more detailed plan is required for systems critical to the
organization's

mission). The security plan should fully identify and describe the
controls

currently in place or planned for the system and should include a list
of

rules of behavior.

OMB Circular A-130, Appendix III, does not distinguish between sensitive
and

non-sensitive systems. Rather, consistent with the Computer Security Act
of

1987, the Circular recognizes that federal automated information systems
have

varied sensitivity and criticality. All federal systems have some level
of

sensitivity, and therefore require protection as part of good management

practice. The generic term \"system\" is used in this document to mean
either a

major application or a general support system.

As defined in OMB Circular A-130, Appendix III, a major application is
an

application \"that requires special attention to security due to the
risk and

magnitude of harm resulting from the loss, misuse, or unauthorized
access to

or modification of its information\". A major application may be
comprised of

many hardware, software, and telecommunications components. These
components

may include software applications or combinations of hardware and
software

that support a specific mission-related function; they may also include

facilities, procedures, and operators.

A general support system, on the other hand, normally includes hardware,

software, information, data, applications, communications, facilities,

operational rules and procedures, and people. It provides support for a

variety of users and applications. Examples of general support systems
include

local area networks (LANs), Virtual Private Networks (VPNs), Regional

Backbones, Metropolitan Area Networks (MANs) and communications
networks.

All applications and systems must be covered by system security plans if
they

are categorized as a major application or a general support system.
Specific

security plans for other applications are not required because the
security

controls for those applications or systems would be provided by the
general

support systems in which they operate. For example, a department-wide

Financial Management System would be a major application requiring its
own

security plan. A local program designed to track expenditures against an

office budget might not be considered a major application and would be
covered

by a general support system security plan for an office automation
system or a

LAN. Standard commercial off-the-shelf software (such as word processing

software, electronic mail software, utility software, or other general-

purpose software) would not typically be considered a major application
and

would be covered by the plans for the general support system on which
they are

installed.

SECURITY PLAN DEVELOPMENT

Information system security planning, and its documentation in an
Information

Systems Security Plan, involves the derivation of a detailed description
of

the system and its components, an identification of the system's
sensitivity,

identification of the applicable protection requirements, and a list of
the

security measures or controls that are currently being used or will be
used to

protect the system's components. The information system security
planning

process is covered in five steps:

Step 1 -- System Analysis.

Step 2 -- Definition of Overall System Information.

Step 3 -- Management Controls.

Step 4 -- Operational Controls.

Step 5 -- Technical Controls.

Each of these steps is described in detail in the following paragraphs.

A. Step 1. System Analysis

Before beginning the development of the Plan itself, a systems analysis
must

be performed, in order to define the system 'boundaries', i.e. what
specific

elements are included within the system and what ones are not. Once this
has

been accomplished, and the boundaries defined, the nature of the system,

either a major application or a general support system must be
ascertained.

This difference is significant, in that there are differences between
the

operational and technical controls for major applications and general
support

systems, and hence those sections of the Security Plan dealing with
these

areas will be quite different. Rules of behavior will also be different
for

the two types of systems.

1\. System Boundaries

Defining what constitutes an information system, for the purposes of
this

guide, requires an analysis of both system boundaries and organizational

responsibilities. An information system is identified by constructing

logical boundaries around a set of processes, communications, storage
and

related resources. The elements within these boundaries constitute a
single

system, requiring its own security plan. Each element of the system must
be

under the same direct management control, have the same function or
mission

objective, have essentially the same operating characteristics and
security

needs, and reside in the same general operating environment.

It is important to note that all components of a system need not be

physically connected to each other. A group of stand-alone personal

computers (PCs) in an office, a group of PCs placed in employees' homes

under defined telecommuting program rules a group of portable PCs
provided

to employees who require mobile computing capability for their jobs, and
a

system with multiple identical configurations that are installed in

locations with the same environmental and physical safeguards, are all

examples of non-physically interconnected information systems.

In cases where an enterprise possesses multiple similar systems, i.e.

systems differing only in terms of which organization within that
enterprise

is responsible for each one, or similar systems located in different

physical environments (e.g., air traffic control systems), it is
appropriate

and recommended to use plans that are identical except for those
particular

areas of difference. This approach provides consistent levels of
protection

for similar information systems.

2\. System Categories

Once the system boundaries have been established, the system must be

categorized as either a major application or as a general support
system.

Major Application - All DOT applications have value and require some
level

of protection. Certain applications, because of the information they

contain, process, or transmit or because of their criticality to the DOT

mission, require special management oversight. These applications are

designated as major applications. Determination as to which applications
are

major applications is generally a matter of management judgment.
However,

each application, whether major or not, should be covered by a security

plan. The application will either be covered individually, if it has
been

designated as a major application, or within the security plan of a
general

support system if not. Note that management must ensure that the
security

requirements of non-major applications are discussed as part of the
security

plan for the applicable general support systems. Also, a system may be

designated as a major application even though it is also supported by a

system that has been designated as a general support system.

General Support System - A general support system consists of
interconnected

information resources, all under the same direct management control,
which

share common functionality. A general support system normally includes

hardware, software, information, data, applications, communications,

facilities, and people and provides support for a variety of users
and/or

applications. Note that a major application can run on a general support

system In such cases, the Security Plan developed for the general
support

system plan should reference the associated major application Security
Plan

(or Plans, if multiple major applications are run) in its General

Description/Purpose.

B. Step 2. Definition of Overall System Information

The first section of an Information Systems Security Plan consists of
that set

of information necessary to describe the system. This information
includes:

System Identification, including the System Name, Responsible
Organization,

and Information and Security Contacts.

System Operational Status

General System Description and Purpose

System Environment

System Interconnection and Information Sharing

Sensitivity of Information Handled

Although similar in nature, the specific types of information necessary
to

describe the system will differ, depending on whether the system is a
major

application or general support system. Figure 1 contains a template for
major

application system information, while Figure 2 does the same for a
general

support system.

Figure 1, Template for Overall Information - Major Application

Figure 2, Template for Overall Information -- General Support System

Sensitivity of information, is a key requirement of the security plan,
\-\--

identifying the sensitivity of the information processed by the system.
This

may be accomplished by determining the type and relative importance of
the

protection needed for the system.

A system may need protection for one or more of the following:

Confidentiality. The system contains information that requires
protection

from unauthorized disclosure.

Integrity. This system contains information that must be protected from

unauthorized, unanticipated, or unintentional modification; and for
which

the ability to detect attempts to modify data is important.

Availability. The system contains information or provides services which

must be available on a timely basis to meet mission requirements or to
avoid

substantial losses.

The type and relative importance of system protection needed may be
matrixed,

as shown below. High indicates a critical concern of the organization.
Medium

indicates an important concern, but not necessarily paramount in the

organization\'s priorities. Low indicates the need for some minimal
security

protection.

Protection Requirements Level of Protection Needed

High Medium Low

Confidentiality

Integrity

Availability

Note that the overall protection level designation of an application
should be

equal to or higher than the highest security level designation of any
data it

processes or systems it runs.

This security level designation determines the minimum set of security

safeguards required to protect sensitive data files, and to ensure the

operational continuity of critical processing capabilities. A \"High\"

designation requires formal certification. A \" Medium\" designation
normally

requires formal certification, and a \"Low\" designation normally does
not

require formal certification.

NOTE: DOT systems are categorized as:

1). classified (level 1),

2). sensitive (level 2), or

3). non-sensitive (level 3).

High, medium, and low are subdivisions of sensitive (level 2) systems.

C. Step 3. Management Controls

With the definition of overall system information completed, the next
step in

the process of developing an Information Systems Security Plan is the

description of management controls (in place or planned) that are
intended to

meet the protection requirements of the major application or general
support

system. Management Controls addresses security topics that can be

characterized as managerial in nature. They are techniques and concerns
that

are normally addressed by management in an organization\'s computer
security

program. In general, they focus on the management of the computer
security

program and the management of risk within the organization. Management

controls focus on the management of the computer security system and the

management of risk for a system.

The types of control measures must be consistent with the need for
protection

of the major application or general support system.

The areas which must be addressed within the Management Controls section
of

the Plan include:

1\. Risk Assessment and Management -- OMB Circular A-130 no longer
requires

the preparation of a formal risk analysis. It does, however, require an

assessment of risk as part of a risk-based approach to determining
adequate,

cost-effective security for a system. Refer to DOT H 1350.252
Departmental

Guide to Risk Assessments for a detailed treatment of this subject. If
no

risk assessment has been performed on the major application or general

support system, the Plan must include a milestone date (month and year)
for

the completion of one. If a risk assessment has been performed, but is
more

than three years old or there have been major changes to the system or

functions, the Plan must include a milestone date (month and year) for

completion of a new or updated risk assessment. Assessing the risk to a

system should be an ongoing activity to ensure that new threats and

vulnerabilities are identified and appropriate security measures are

implemented.

2\. Review of Security Controls -- OMB Circular A-130 requires that at
least

every three years an independent review of the security controls for
each

major application be performed. For general support systems, OMB
Circular

A-130 requires that the security controls be reviewed by an independent

audit or self review at least every three years. Hence, in this section,
it

is necessary to describe the type of review and findings conducted on
the

general support system or major application within the last three years.

The objective of these reviews is to provide verification that the
controls

selected and/or installed provide a level of protection commensurate
with

the acceptable level of risk for the system. The determination that the

level of risk is acceptable must be made relative to the system
requirements

for confidentiality, integrity and availability as well as the
identified

threats.

3\. Rules of Behavior --A set of rules of behavior must be established
for

each major application and general support system. The security required
by

the rules should be only as stringent as necessary to provide adequate

security for the system and the information it contains. The acceptable

level of risk should form the basis for determining the rules. The rules
of

behavior should clearly delineate responsibilities and expected behavior
of

all individuals with access to the system, and should state the
consequences

of inconsistent behavior or noncompliance. Rules of Behavior shall also

include appropriate limits on interconnections to other systems and
define

service provision and restoration priorities. They should cover such
matters

as work at home, dial-in access, connection to the Internet, use of

copyrighted works, unofficial use of government equipment, the
assignment

and limitation of system privileges, and individual accountability. The

rules should be in writing and form the basis for security awareness and

training. In this section of the Plan, include either the rules
themselves,

or a reference to an Appendix containing them.

4\. Planning for Security in the Life Cycle --In this section of the
Plan,

determine which phase(s) of the life cycle the system, or parts of the

system, are in. There are many models for the IT system life cycle but
most

contain five basic phases: Initiation, development/acquisition,

implementation, operation, and disposal. Although a computer security
plan

can be developed for a system at any point in the life cycle, the

recommended approach is to draw up the plan at the beginning of the
computer

system life cycle. The purpose of this section is to identify how
security

has been handled during the applicable life cycle phase.

5\. Accreditation --System security accreditation is the formal
authorization

by the accrediting (management) official for system operation and an

explicit acceptance of risk. It is usually supported by a review of the

system, including its management, operational, and technical controls.

Accreditation provides a form of quality control and is required under
OMB

Circular A-130. It forces managers and technical staff to find the best
fit

for security, given technical constraints, operational constraints, and

mission requirements. By authorizing processing in a system, a manager

accepts the risk associated with it. Refer to DOT H 1350.253
Departmental

Guide to Certification/Accreditation of Information Systems for a
detailed

treatment of this subject.

A Template for the Management Controls section of the Information
Systems

Security Plan is contained in Figure 3. Note that this Template is the
same

for both major applications and general support systems.

D. Step 4. Operational Controls

With management controls established, the next step is to treat the
subject of

operational controls. Operational controls address security methods that
focus

on mechanisms that primarily are implemented and executed by people (as

opposed to systems). These controls are put in place to improve the
security

of a particular system (or group of systems). They often require
technical or

specialized expertise -- and often rely upon management activities as
well as

technical controls In this section of the Plan, describe the operational

control measures (in place or planned) that are intended to meet
protection

requirements. Note that operational controls differ, depending on
whether the

system is a major application, or a general support system. Hence the

preparation of this section of the Plan should follow the guidelines for

either major application operational controls or general support system

operational controls, as presented in the following paragraphs.

1\. Major Application Operational Controls

For major applications, the main areas of operational controls to be
addressed

within the Plan include:

Major Application Personnel Security --The greatest harm/disruption to a

major application comes from the actions of individuals, both
intentional

and unintentional. All too often, such systems experience disruption,

damage, loss, or other adverse impact due to the well-intentioned
actions

of individuals authorized to use or maintain them. Refer to DOT H
1350.256

Departmental Guide to Personnel Security Planning for additional

information on this subject. Figure 4 details the personnel security

information to be placed within this section of the Plan.

Major Application Physical and Environmental Protection --Physical and

environmental security controls must be implemented to protect the

facility housing system resources, the system resources themselves, and

the facilities used to support their operation. Refer to DOT H 1350.257

Departmental Guide to Physical/Environmental Security Planning for

additional supporting data. In this section of the Plan, briefly
describe

the physical and environmental controls in place for the major

application. Specific areas which must be addressed include access

controls, fire safety factors, failure of supporting utilities,
structural

collapse, plumbing leaks, interception of data, and portable/mobile

systems. Figure 5 identifies the physical/environmental factors to be

considered within this section of the Plan.

7\. MANAGEMENT CONTROLS

7.1 Risk Assessment and Management

Describe the risk assessment methodology used to identify the threats

and vulnerabilities of the system. Include the date the review was

conducted. If there is no system risk assessment, include a milestone

date (month and year) for completion of the assessment.

7.2 Review of Security Controls

List any independent security reviews conducted on the system in the

last three years.

Include information about the type of security evaluation performed,

who performed the review, the purpose of the review, the findings, and

the actions taken as a result.

7.3 Rules of Behavior

A set of rules of behavior in writing must be established for each

system. The rules of behavior should be made available to every user

prior to receiving access to the system. It is recommended that the

rules contain a signature page to acknowledge receipt.

The rules of behavior should clearly delineate responsibilities and

expected behavior of all individuals with access to the system. They

should state the consequences of inconsistent behavior or

noncompliance. They should also include appropriate limits on

interconnections to other systems.

Attach the rules of behavior for the system as an appendix and

reference the appendix number in this section or insert the rules into

this section.

7.4 Planning for Security in the Life Cycle

Determine which phase(s) of the life cycle the system or parts of the

system are in. Describe how security has been handled in the life cycle

phase(s) that the system is currently in.

Initiation Phase

Reference the sensitivity assessment which is described in Section

3.7, Sensitivity of Information Handled.

Development/Acquisition Phase

During the system design, were security requirements identified?

Were the appropriate security controls with associated evaluation and

test procedures developed before the procurement action?

Did the solicitation documents (e.g., Request for Proposals) include

security requirements and evaluation/test procedures?

Did the requirements permit updating security requirements as new

threats/vulnerabilities are identified and as new technologies are

implemented?

If this is a purchased commercial application or the application

contains commercial, off-the-shelf components, were security

requirements identified and included in the acquisition

specifications?

Implementation Phase

Were design reviews and systems tests run prior to placing the system

in production? Were the tests documented? Has the system been

certified?

Have security controls been added since development?

Has the application undergone a technical evaluation to ensure that it

meets applicable federal laws, regulations, policies, guidelines, and

standards?

Include the date of the certification and accreditation. If the system

is not authorized yet, include date when accreditation request will be

made.

Operation/Maintenance Phase

The security plan documents the security activities required in this

phase.

Disposal Phase

Describe in this section how information is moved to another system,

archived, discarded, or destroyed. Discuss controls used to ensure the

confidentiality of the information.

Is sensitive data encrypted?

How is information cleared and purged from the system?

Is information or media purged, overwritten, degaussed or destroyed?

7.5 Accreditation

Provide the date of accreditation, name, and title of management

official authorizing processing in the system.

If not accredited, provide the name and title of manager requesting

approval to operate and date of request.

Figure 3, Template for Management Controls

8\. OPERATIONAL CONTROLS

8.1 Personnel Security

Have all positions been reviewed for sensitivity level?

Have individuals received background screenings appropriate for the

position to which they are assigned.

Is user access restricted to the minimum necessary to perform the job?

Is there a process for requesting, establishing, issuing, and closing

user accounts?

Are critical functions divided among different individuals (separation

of duties)?

What mechanisms are in place for holding users responsible for their

actions?

What are the friendly and unfriendly termination procedures?

Figure 4, Major Application Personnel Security Template

8.2 Physical and Environmental Protection

Discuss the physical protection in the area where application

processing takes place (e.g., locks on terminals, physical barriers

around the building and processing area, etc.)

Factors to address include physical access, fire safety, failure of

supporting utilities, structural collapse, plumbing leaks,

interception of data, mobile and portable systems.

Figure 5, Major Application Physical/Environmental Protection Template

Major Application Production, Input/Output Controls - This section of
the

Information Systems Security Plan for a major application should contain
a

description of the controls used for the marking, handling, processing,

storage, and disposal of input and output information and media, as well
as

labeling and distribution procedures for the information and media. The

controls used to monitor the installation of, and updates to,
application

software should be listed. In this section, provide a synopsis of the

procedures in place that support the operations of the application.
Figure 6

contains a sampling of topics that should be reported in this section.

Major Application Continuity of Operations Planning - Procedures are

required that will permit the organization to continue essential
functions

if information technology support is interrupted. Development of these

procedures is treated in detail in DOT H 1350.254 Departmental Guide to

Continuity of Operations Planning. These procedures (contingency plans
and

continuity plans) should be coordinated with the backup contingency, and

recovery plans of any general support systems, including networks used
by

the major application. The contingency plans should ensure that
interfacing

systems are identified and contingency/disaster planning coordinated. In

this section of the Security Plan, briefly describe the procedures that

would be followed to ensure the application continues to be processed if
the

supporting IT systems were unavailable. If a formal Continuity of
Operations

Plan (COOP) has been completed, reference that plan. A copy of the COOP
may

be attached as an appendix. Figure 7 contains some of the questions to
be

considered in this section.

8.3 Production, Input/Output Controls

User Support - Is there a help desk or group that offers advice and

can respond to security incidents in a timely manner? Are there

procedures in place documenting how to recognize, handle, and report

incidents and/or problems?

Procedures to ensure unauthorized individuals cannot read, copy,

alter, or steal printed or electronic information

Procedures for ensuring that only authorized users pick up, receive,

or deliver input and output information and media

Audit trails for receipt of sensitive inputs/outputs

Procedures for restricting access to output products

Procedures and controls used for transporting or mailing media or

printed output

Internal/external labeling for sensitivity (e.g., Privacy Act,

Proprietary)

External labeling with special handling instructions (e.g.,

log/inventory identifiers, controlled access, special storage

instructions, release or destruction dates)

Audit trails for inventory management

Media storage vault or library-physical, environmental protection

controls/procedures

Procedures for sanitizing electronic media for reuse (e.g.,

overwriting or degaussing)

Procedures for controlled storage, handling, or destruction of spoiled

media or media that cannot be effectively sanitized for reuse

Procedures for shredding or other destructive measures for hardcopy

media when no longer required

Figure 6, Major Application Production, Input/Output Controls Template

8.4 Continuity of Operations Planning

Is a tested COOP in place to permit continuity of mission-critical

functions in the event of a catastrophic event?

Are tested COOPs in place for all supporting IT systems and networks?

Are formal written emergency operating procedures posted or located to

facilitate their use in emergency situations?

How often are COOPs tested?

Are all employees trained in their roles and responsibilities relative

to the COOP?

Include descriptions of the following controls:

Any agreements for backup processing (e.g., hotsite contract with a

commercial service provider).

Documented backup procedures including frequency (daily, weekly,

monthly) and scope (full backup, incremental backup, and differential

backup).

Location of stored backups (off-site or on-site).

Generations of backups kept.

Coverage of backup procedures, e.g., what is being backed up.

Figure 7, Major Application Continuity of Operations Planning Template

Major Application Software Maintenance Controls -- Application software

maintenance controls are used to monitor the installation of, and
updates

to, application software to ensure that the software functions as
expected

and that a historical record is maintained of application changes. This

helps ensure that only authorized software is installed on the system.
Such

controls may include a software configuration policy that grants
managerial

approval to modifications and requires that changes be documented. Other

controls include products and procedures used in auditing for or
preventing

illegal use of shareware or copyrighted software. Software maintenance

procedures may also be termed version control, change management, or

configuration management. Figure 8 contains questions that should be

addressed in responding to this section.

Major Application Data Integrity/Validation Controls - Data integrity

controls are used to protect data from accidental or malicious
alteration or

destruction and to provide assurance to the user that the information
meets

expectations about its quality and that it has not been altered.
Validation

controls refer to tests and evaluations used to determine compliance
with

security specifications and requirements. In this section of the Plan,

describe any controls that provide assurance to users that the
information

has not been altered and that the system functions as expected. The

questions in Figure 9 are examples of some of the controls that fit in
this

category.

8.5 Application Software Maintenance Controls

Was the application software developed in-house or under contract?

Does the government own the software? Was it received from another

agency?

Is the application software a copyrighted commercial off-the-shelf

product or shareware? Has it been properly licensed and enough copies

purchased for all systems?

Is there a formal change control process in place and if so, does it

require that all changes to the application software be tested and

approved before being put into production?

Are test data live data or made-up data?

Are all changes to the application software documented?

Are test results documented?

How are emergency fixes handled?

Are there organizational policies against illegal use of copyrighted

software, shareware?

Are periodic audits conducted of users? computers to ensure only legal

licensed copies of software are installed?

What products and procedures are used to protect against illegal use

of software?

Are software warranties managed to minimize the cost of upgrades and

cost-reimbursement or replacement for deficiencies?

Figure 8, Major Application Software Maintenance Controls Template

8.6 Data Integrity/Validation Controls

Is virus detection and elimination software installed? If so, are

there procedures for updating virus signature files, automatic and/or

manual virus scans, and virus eradication and reporting?

Is reconciliation routines used by the system, i.e., checksums, hash

totals, record counts? Include a description of the actions taken to

resolve any discrepancies.

Is password crackers/checkers used?

Is integrity verification programs used by applications to look for

evidence of data tampering, errors, and omissions?

Are intrusion detection tools installed on the system?

Is system performance monitoring used to analyze system performance

logs in real time to look for availability problems, including active

attacks, and system and network slowdowns and crashes?

Is penetration testing performed on the system? If so, what procedures

are in place to ensure they are conducted appropriately?

Is message authentication used in the application to ensure that the

sender of a message is known and that the message has not been altered

during transmission?

Figure 9, Major Application Data Integrity/Validation Controls Template

Major Application Documentation - Documentation is a security control in

that it explains how software/hardware is to be used and formalizes
security

and operational procedures specific to the system. Documentation for a

system includes descriptions of the hardware and software, policies

standards, procedures, and approvals related to automated information
system

security in the application and the support system(s) on which it is

processed, to include backup and contingency activities, as well as

descriptions of user and operator procedures. Ensure that documentation
is

coordinated with the general support system and/or network manager(s) to

ensure that adequate application and installation documentation are

maintained to provide continuity of operations. In this section of the
Plan,

list the documentation maintained for the application, as shown in
Figure

10\.

8.7 Documentation

Documentation for a system includes descriptions of the hardware and

software, policies, standards, procedures, and approvals related to

automated information system security in the application and the support

systems(s) on which it is processed, to include backup and contingency

activities, as well as descriptions of user and operator procedures.

List the documentation maintained for the application (vendor

documentation of hardware/software, functional requirements, security

plan, general system security plan, application program manuals, test

results documents, standard operating procedures, emergency

procedures, contingency plans, user rules/procedures, risk assessment,

certification/accreditation statements/documents, verification

reviews/site inspections.)

Figure 10, Major Application Documentation Template

Major Application Security Awareness and Training - The Computer
Security

Act requires federal agencies to provide for the mandatory periodic
training

in computer security awareness and accepted computer security practices
for

all employees who are involved with the management, use, or operation of
a

federal computer system within or under the supervision of the federal

agency. This includes contractors as well as employees of the agency.
OMB

Circular A-130, Appendix III enforces such mandatory training by
requiring

its completion prior to granting access to the system and through
periodic

refresher training for continued access. Additional information
regarding

security awareness and training may be found in DOT H 1350.258
Departmental

Guide to Developing an Information System Security

Awareness/Training/Education Program. Refer to Figure 11 for the types
of

information required in this section of the Plan. Note that Contractor

employees are required to receive the same level of information systems

security awareness and training as federal employees. Hence this
training

requirement should be included as appropriate in all contracts.

Figure 11, Major Application Security Awareness and Training Template

2\. General Support System Operational Controls

For general support systems, the main areas of operational controls to
be

addressed within the Plan include:

General Support System Personnel Controls - The greatest harm/disruption
to

a major application comes from the actions of individuals, both
intentional

and unintentional. All too often, such systems experience disruption,

damage, loss, or other adverse impact due to the well-intentioned
actions of

individuals authorized to use or maintain them. Refer to DOT H 1350.256

Departmental Guide to Personnel Security Planning for additional
information

on this subject. Figure 12 details the personnel security information to
be

placed within this section of the Plan.

8\. OPERATIONAL CONTROLS

8.1 Personnel Controls

Have all positions been reviewed for sensitivity level?

Have individuals received background screenings appropriate for the

position to which they are assigned.

Is user access restricted to the minimum necessary to perform the job?

Is there a process for requesting, establishing, issuing, and closing

user accounts?

Are critical functions divided among different individuals (separation

of duties)?

What mechanisms are in place for holding users responsible for their

actions?

What are the friendly and unfriendly termination procedures?

Figure 12, General Support System Personnel Controls Template

General Support System Physical and Environmental Protection - Physical
and

environmental security controls must be implemented to protect the
facility

housing system resources, the system resources themselves, and the

facilities used to support their operation. Refer to DOT H 1350.257

Departmental Guide to Physical/Environmental Security Planning for

additional supporting data. In this section of the Plan, briefly
describe

the physical and environmental controls in place for the major
application.

Specific areas which must be addressed include access controls, fire
safety

factors, failure of supporting utilities, structural collapse, plumbing

leaks, interception of data, and portable/mobile systems. Figure 13

identifies the physical/environmental factors to be considered within
this

section of the Plan.

8.2 Physical and Environmental Protection

Discuss the physical protection for the system. Describe the area

where processing takes place (e.g., locks on terminals, physical

barriers around the building and processing area, etc.)

Factors to address include physical access, fire safety, failure of

supporting utilities, structural collapse, plumbing leaks,

interception of data, mobile and portable systems.

Figure 13, General Support System Physical and Environmental Protection

Template

General Support System Production, Input/Output Controls -- In this
section

of the Plan, describe the controls used for the marking, handling,

processing, storage, and disposal of input and output information and
media,

as well as labeling and distribution procedures for the information and

media. The controls used to monitor the installation of, and updates to

software should be listed. Also in this section, provide a synopsis of
the

procedures in place that support the general support system. Figure 14

contains a sampling of topics that should be reported in this section.

General Support System Continuity of Operations Planning - Procedures
are

required that will permit the organization to continue essential
functions

if information technology support is interrupted. Development of these

procedures is treated in detail in DOT H 1350.254 Departmental Guide to

Continuity of Operations Planning. General support systems require

appropriate emergency, backup, and contingency plans. These plans should
be

tested regularly to assure the continuity of support in the event of
system

failure. Also, these plans should be known to users and coordinated with

their plans for major applications. In this section of the Security
Plan,

briefly describe the procedures that would be followed to ensure the

application continues to be processed if the supporting IT systems were

unavailable. If a formal Continuity of Operations Plan (COOP) has been

completed, reference that plan. A copy of the COOP may be attached as an

appendix. Figure 15 contains some of the questions to be considered in
this

section.

8.3 Production, Input/Output Controls

User support - Is there a help desk or group that offers advice?

Procedures to ensure unauthorized individuals cannot read, copy,

alter, or steal printed or electronic information

Procedures for ensuring that only authorized users pick up, receive,

or deliver input and output information and media

Audit trails for receipt of sensitive inputs/outputs

Procedures for restricting access to output products

Procedures and controls used for transporting or mailing media or

printed output

Internal/external labeling for sensitivity (e.g., Privacy Act,

Proprietary)

External labeling with special handling instructions (e.g.,

log/inventory identifiers, controlled access, special storage

instructions, release or destruction dates)

Audit trails for inventory management

Media storage vault or library-physical, environmental protection

controls/procedures

Procedures for sanitizing electronic media for reuse (e.g.,

overwriting or degaussing)

Procedures for controlled storage, handling, or destruction of spoiled

media or media that cannot be effectively sanitized for reuse

Procedures for shredding or other destructive measures for hardcopy

media when no longer required

Figure 14, General Support System Production, Input/Output Controls
Template

8.4 Continuity of Operations Planning

Is a tested COOP in place to permit continuity of mission-critical

functions in the event of a catastrophic event?

Is a tested COOP in place for all supporting IT systems and networks?

Are formal written emergency operating procedure posted or located to

facilitate their use in emergency situations?

How often is the COOP tested?

Are all employees trained in their roles and responsibilities relative

to the COOP?

Include descriptions of the following controls.

Any agreements for backup processing (e.g., hotsite contract with a

commercial service provider).

Documented backup procedures including frequency (daily, weekly,

monthly) and scope (full backup, incremental backup, and differential

backup).

Location of stored backups (off-site or on-site).

Generations of backups kept.

Coverage of backup procedures, e.g., what is being backed up.

Figure 15, General Support System Continuity of Operations Planning
Template

General Support System Hardware and System Software Maintenance Controls
-

These controls are used to monitor the installation of, and updates to,

hardware, operating system software, and other software to ensure that
the

hardware and software function as expected, and that a historical record
is

maintained of application changes. These controls may also be used to
ensure

that only authorized software is installed on the system. Such controls
may

include a hardware and software configuration policy that grants
managerial

approval (re-authorize processing to modifications and requires that
changes

be documented. Other controls include products and procedures used in

auditing for, or preventing, illegal use of shareware or copyrighted

software. In this section, provide several paragraphs on the hardware
and

system software maintenance controls (in place or planned), as shown in

Figure 16.

8.5 Hardware and System Software Maintenance Controls

Restriction/controls on those who perform maintenance and repair

activities.

Special procedures for performance of emergency repair and

maintenance.

Procedures used for items serviced through on-site and off-site

maintenance (e.g., escort of maintenance personnel, sanitization of

devices removed from the site).

Procedures used for controlling remote maintenance services where

diagnostic procedures or maintenance is performed through

telecommunications arrangements.

Version control that allows association of system components to the

appropriate system version.

Procedures for testing and/or approving system components (operating

system, other system, utility, applications) prior to promotion to

production.

Impact analyses to determine the effect of proposed changes on

existing security controls to include the required training for both

technical and user communities associated with the change in

hardware/software.

Change identification, approval, and documentation procedures.

Procedures for ensuring contingency plans and other associated

documentation are updated to reflect system changes.

Are test data \"live\" data or made-up data?.

Are there organizational policies against illegal use of copyrighted

software or shareware?

Figure 16, General Support System Hardware and System Software
Maintenance

Controls Template

General Support System Integrity Controls - Integrity controls are used
to

protect the operating system, applications, and information in the
system

from accidental or malicious alteration or destruction, and to provide

assurance to the user that the information meets expectations about its

quality and that it has not been altered. In this section of the Plan,

describe any controls that provide assurance to users that the
information

has not been altered and that the system functions as expected. The

questions shown in Figure 17 are examples of some of the controls that
fit

in this category.

General Support System Documentation - Documentation is a security
control

in that it explains how software/hardware is to be used and formalizes

security and operational procedures specific to the system.
Documentation

for a system includes descriptions of the hardware and software,
policies,

standards, procedures, and approvals related to automated information
system

security on the support system, including backup and contingency
activities,

as well as descriptions of user and operator procedures. In this section
of

the Plan, list the documentation maintained for the application, as
shown in

Figure 18.

8.6 Integrity Controls

Is virus detection and elimination software installed? If so, are

there procedures for updating virus signature files, automatic and/or

manual virus scans, and virus eradication and reporting?

Is reconciliation routines used by the system, i.e., checksums, hash

totals, record counts? Include a description of the actions taken to

resolve any discrepancies.

Is password crackers/checkers used?

Is integrity verification programs used by applications to look for

evidence of data tampering, errors, and omissions?

Are intrusion detection tools installed on the system?

Is system performance monitoring used to analyze system performance

logs in real time to look for availability problems, including active

attacks, and system and network slowdowns and crashes?

Is penetration testing performed on the system? If so, what procedures

are in place to ensure they are conducted appropriately?

Is message authentication used in the system to ensure that the sender

of a message is known and that the message has not been altered during

transmission?

Figure 17, General Support System Integrity Controls Template

8.7 Documentation

Documentation for a system includes descriptions of the hardware and

software, policies, standards, procedures, and approvals related to

automated information system security of the system to include backup

and contingency activities, as well as descriptions of user and operator

procedures.

List the documentation maintained for the system (vendor documentation

of hardware/software, functional requirements, security plan, program

manuals, test results documents, standard operating procedures,

emergency procedures, contingency plans, user rules/procedures, risk

assessment, authorization for processing, verification reviews/site

inspections).

Figure 18, General Support System Documentation Template

General Support System Security Awareness & Training - The Computer
Security

Act requires federal agencies to provide for the mandatory periodic
training

in computer security awareness and accepted computer security practices
for

all employees who are involved with the management, use, or operation of
a

federal computer system within or under the supervision of the federal

agency. This includes contractors as well as employees of the agency.
OMB

Circular A-130, Appendix III enforces such mandatory training by
requiring

its completion prior to granting access to the system and through
periodic

refresher training for continued access. Additional information
regarding

security awareness and training may be found in DOT H 1350.258
Departmental

Guide to Developing an Information System Security

Awareness/Training/Education Program. Refer to Figure 19 for the types
of

information required in this section of the Plan. Note that Contractor

employees are required to receive the same level of information systems

security awareness and training as federal employees. Hence this
training

requirement should be included as appropriate in all contracts.

General Support System Incident Response Capability - A computer
security

incident is an adverse event in a computer system or network caused by a

failure of a security mechanism or an attempted or threatened breach of

these mechanisms. Refer to DOT H 1350.255 Departmental Guide to Incident

Handling Planning for additional information on this subject. When faced

with an incident, an organization should be able to respond quickly in a

manner that both protects its own information and helps to protect the

information of others that might be affected by the incident. OMB
Circular

A-130 requires each agency to ensure that there is a capability to
provide

help to users when a security incident occurs in the system and to share

information concerning common vulnerabilities and threats. In this
section

of the Plan, describe the incident handling procedures in place for the

general support system. Figure 20 illustrates some areas of
consideration.

8.8 Security Awareness & Training

The awareness program for the system (posters, booklets, and trinkets)

Type and frequency of general support system training provided to

employees and contractor personnel (seminars, workshops, formal

classroom, focus groups, role-based training, and on-the job training)

The procedures for assuring that employees and contractor personnel

have been provided adequate for training

Figure 19, General Support System Security Awareness & Training Template

8.9 Incident Response Capability

Are there procedures for reporting incidents handled either by system

personnel or externally?

Are there procedures for recognizing and handling incidents, i.e.,

what files and logs should be kept, who to contact, and when?

Who receives and responds to alerts/advisories, e.g., vendor patches,

exploited vulnerabilities?

What preventive measures are in place, i.e., intrusion detection

tools, automated audit logs, penetration testing?

Figure 20, General Support System Incident Response Capability Template

E. Step 5. Technical Controls

The final step in the development of the Information Systems Security
Plan is

the compilation of system technical controls. Technical controls focus
on

security controls that the computer system executes. The controls can
provide

automated protection from unauthorized access or misuse, facilitate
detection

of security violations, and support security requirements for
applications and

data. The implementation of technical controls, however, always requires

significant operational considerations and should be consistent with the

management of security within the organization. In this section of the
Plan,

describe the technical control measures (in place or planned) that are

intended to meet the protection requirements of the system, As with

operational controls, technical controls differ, depending on whether
the

system is a major application, or a general support system. Hence the

preparation of this section of the Plan should also follow the
guidelines for

either major application operational controls or general support system

operational controls, as presented in the following paragraphs.

1\. Major Application Technical Controls

For major applications, the technical controls to be addressed within
the Plan

include:

Major Application Identification and Authentication - Identification and

Authentication is a technical measure that prevents unauthorized people
(or

unauthorized processes) from entering an IT system. Access control
usually

requires that the system be able to identify and differentiate among
users.

For example, access control is often based on least privilege, which
refers

to the granting to users of only those accesses minimally required to

perform their duties. User accountability requires the linking of
activities

on an IT system to specific individuals and, therefore, requires the
system

to identify users. Identification is the means by which a user provides
a

claimed identity to the system. The most common form of identification
is

the user ID. Authentication is the means of establishing the validity of
a

user's claimed identity to the system. There are three means of

authenticating a user\'s identity which can be used alone or in
combination:

something the individual knows (a secret \-- e.g., a password, Personal

Identification Number (PIN), or cryptographic key); something the
individual

possesses (a token \-- e.g., an ATM card or a smart card); and something
the

individual is (a biometrics \-- e.g., characteristics such as a voice

pattern, handwriting dynamics, or a fingerprint). In this section of the

plan, briefly describe how the major application identifies access to
the

system, and the major application's authentication control mechanisms
(refer

to Figure 21).

9\. TECHNICAL CONTROLS

9.1 Identification and Authentication

Describe the major application's authentication control mechanisms.

Describe the method of user authentication (password, token, and

biometrics)

Provide the following if an additional password system is used in the

application:

\- password length (minimum, maximum)

\- allowable character set,

\- password aging time frames and enforcement approach,

\- number of generations of expired passwords disallowed for use

\- procedures for password changes (after expiration and

forgotten/lost)

\- procedures for handling password compromise

Indicate the frequency of password changes, describe how changes are

enforced, and identify who changes the passwords (the user, the

system, or the system administrator).

Describe how the access control mechanism support individual

accountability and audit trails (e.g., passwords are associated with a

user ID that is assigned to a single person).

Describe the self-protection techniques for the user authentication

mechanism (passwords are encrypted, automatically generated, are

checked against a dictionary of disallowed passwords, passwords are

encrypted while in transmission).

State the number of invalid access attempts that may occur for a given

user id or access location (terminal or port) and describe the actions

taken when that limit is exceeded.

Describe the procedures for verifying that all system-provided

administrative default passwords have been changed.

Describe the procedures for limiting access scripts with embedded

passwords (e.g., scripts with embedded passwords are prohibited,

scripts with embedded passwords are only allowed for batch

applications).

Describe any policies that provide for bypassing user authentication

requirements, single-sign-on technologies (e.g., host-to-host,

authentication servers, user-to-host identifiers, and group user

identifiers) and any compensating controls.

Describe any use of digital or electronic signatures and the standards

used. Discuss the key management procedures for key generation,

distribution, storage, and disposal

Figure 21, Major Application Identification and Authentication Template

Major Application Logical Access Controls - Logical access controls
include

those system-based mechanisms used to specify who or what (e.g., in the
case

of a process) is to have access to a specific system resource, and the
type

of access that is permitted. In this section of the Plan, discuss the

controls in place to authorize or restrict the activities of users and

system personnel within the major application. Describe hardware or
software

features that are designed to permit only authorized access to or within
the

application, to restrict users to authorized transactions and functions,

and/or to detect unauthorized activities (e.g., access control lists).
Areas

that should be considered are listed in Figure 22.

9.2 Logical Access Controls

For users and system personnel:

Discuss the controls in place to authorize or restrict the activities

of users and system personnel within the application. Describe

hardware or software features that are designed to permit only

authorized access to or within the application, to restrict users to

authorized transactions and functions, and/or to detect unauthorized

activities (i.e., access control lists \[ACLs\]).

How are access rights granted? Are privileges granted based on job

function?

Describe the application's capability to establish an ACL or register.

Describe how application users are restricted from accessing the

operating system, other applications, or other system resources not

needed in the performance of their duties.

Describe controls to detect unauthorized transaction attempts by

authorized and/or unauthorized users. Describe any restrictions to

prevent users from accessing the system or applications outside of

normal work hours or on weekends.

Indicate after what period of user inactivity the system automatically

blanks associated display screens and/or after what period of user

inactivity the system automatically disconnects inactive users or

requires the user to enter a unique password before reconnecting to

the system or application.

Indicate if encryption is used to prevent access to sensitive files as

part of the system or application access control procedures.

Describe the rationale for electing to use or not use warning banners

and provide an example of the banners used. Where appropriate, state

whether the Dept. of Justice, Computer Crime and Intellectual

Properties Section, approved the warning banner.

If the public accesses the major application, discuss the additional

security controls used to protect the integrity of the application and

the confidence of the public in the application. Such controls include

segregating information made directly accessible to the public from

official agency records. Others might include

Some form of identification and authentication

Access control to limit what the user can read, write, modify, or

delete

Controls to prevent public users from modifying information on the

system

Digital signatures

CD-ROM for on-line storage of information for distribution

Put copies of information for public access on a separate system

Prohibit public to access ?live? databases

Verify that programs and information distributed to the public are

virus-free

Audit trails and user confidentiality

System and data availability

Legal considerations

Figure 22, Major Application Logical Access Controls Template

Major Application Audit Trails - Audit trails maintain a record of
system

activity by system or application processes and by user activity. In

conjunction with appropriate tools and procedures, audit trails can
provide

a means to help accomplish several security-related objectives,
including

individual accountability, reconstruction of events, intrusion
detection,

and problem identification. In this section of the Plan describe the
audit

trail mechanisms in place for the major application. A list of
applicable

elements is contained in Figure 23.

9.3 Audit Trails

Does the audit trail support accountability by providing a trace of

user actions?

Are audit trails designed and implemented to record appropriate

information that can assist in intrusion detection?

Does the audit trail include sufficient information to establish what

events occurred and who (or what) caused them? (type of event, when

the event occurred, user id associated with the event, program or

command used to initiate the event.)

Is access to online audit logs strictly enforced?

Is the confidentiality of audit trail information protected if, for

examples, it records personal information about users?

Describe how frequently audit trails are reviewed and whether there

are guidelines.

Does the appropriate system-level or application-level administrator

review the audit trails following a known system or application

software problem, a known violation of existing requirements by a

user, or some unexplained system or user problem?

Figure 23, Major Application Audit Trails Template

2\. General Support System Technical Controls

For general support systems, the technical controls to be addressed
within the

Plan include:

General Support System Identification and Authentication -
Identification

and Authentication is a technical measure that prevents unauthorized
people

(or unauthorized processes) from entering an IT system. Access control

usually requires that the system be able to identify and differentiate
among

users. For example, access control is often based on least privilege,
which

refers to the granting to users of only those accesses minimally
required to

perform their duties. User accountability requires the linking of
activities

on an IT system to specific individuals and, therefore, requires the
system

to identify users. Identification is the means by which a user provides
a

claimed identity to the system. The most common form of identification
is

the user ID. Authentication is the means of establishing the validity of
a

user's claimed identity to the system. There are three means of

authenticating a user\'s identity which can be used alone or in
combination:

something the individual knows (a secret \-- e.g., a password, Personal

Identification Number (PIN), or cryptographic key); something the
individual

possesses (a token \-- e.g., an ATM card or a smart card); and something
the

individual is (a biometrics \-- e.g., characteristics such as a voice

pattern, handwriting dynamics, or a fingerprint). In this section of the

plan, briefly describe how the general support system identifies access
to

the system, and the general support system's authentication control

mechanisms (refer to Figure 24).

General Support System Logical Access Controls - Logical access controls
are

the system-based mechanisms used to specify who or what (e.g., in the
case

of a process) is to have access to a specific system resource and the
type

of access that is permitted. In this section, discuss the controls in
place

to authorize or restrict the activities of users and system personnel
within

the general support system. Describe hardware or software features that
are

designed to permit only authorized access to or within the system, to

restrict users to authorized transactions and functions, and/or to
detect

unauthorized activities (e.g., access control lists). Areas that should
be

considered are listed in Figure 25. In addition, documentation for a
system

should include a standardized log-on banner. Public Law 99-474 requires
that

a warning message be displayed, notifying unauthorized users that they
have

accessed a U.S. Government computer system and unauthorized use can be

punished by fines or imprisonment.

General Support System Audit Trails - Audit trails maintain a record of

system activity by system or application processes and by user activity.
In

conjunction with appropriate tools and procedures, audit trails can
provide

a means to help accomplish several security-related objectives,
including

individual accountability reconstruction of events, intrusion detection,
and

problem identification. In this section of the Plan, describe the audit

trail mechanisms in place. A list of items to consider is provided in
Figure

26\.

9\. TECHNICAL CONTROLS

9.1 Identification and Authentication

Describe the method of user authentication (password, token, and

biometrics).

If a password system is used, provide the following specific

information:

Allowable character set;

Password length (minimum, maximum);

Password aging time frames and enforcement approach;

Number of generations of expired passwords disallowed for use;

Procedures for password changes;

Procedures for handling lost passwords, and

Procedures for handling password compromise.

Procedures for training users and the materials covered.

Indicate the frequency of password changes, describe how password

changes are enforced (e.g., by the software or System Administrator),

and identify who changes the passwords (the user, the system, or the

System Administrator).

Describe any biometrics controls used. Include a description of how

the biometrics controls are implemented on the system.

Describe any token controls used on this system and how they are

implemented.

Describe the level of enforcement of the access control mechanism

(network, operating system, and application).

Describe how the access control mechanism supports individual

accountability and audit trails (e.g., passwords are associated with a

user identifier that is assigned to a single individual).

Describe the self-protection techniques for the user authentication

mechanism (e.g., passwords are transmitted and stored with one-way

encryption to prevent anyone \[including the System Administrator\] from

reading the clear-text passwords, passwords are automatically

generated, passwords are checked against a dictionary of disallowed

passwords).

State the number of invalid access attempts that may occur for a given

user identifier or access location (terminal or port) and describe the

actions taken when that limit is exceeded.

Describe the procedures for verifying that all system-provided

administrative default passwords have been changed.

Describe the procedures for limiting access scripts with embedded

passwords (e.g., scripts with embedded passwords are prohibited,

scripts with embedded passwords are only allowed for batch

applications).

Describe any policies that provide for bypassing user authentication

requirements, single-sign-on technologies (e.g., host-to-host,

authentication servers, user-to-host identifier, and group user

identifiers) and any compensating controls.

If digital signatures are used, the technology must conforms with FIPS

186, Digital Signature Standard and FIPS 180-1, Secure Hash Standard

issued by NIST, unless a waiver has been granted. Describe any use of

digital or electronic signatures.

Figure 24, General Support System Identification and Authentication
Template

9.2 Logical Access Controls

Discuss the controls in place to authorize or restrict the activities

of users and system personnel within the system. Describe hardware or

software features that are designed to permit only authorized access

to or within the system, to restrict users to authorized transactions

and functions, and/or to detect unauthorized activities (i.e., access

control lists (ACLs).

How are access rights granted? Are privileges granted based on job

function?

Describe the system's capability to establish an ACL or register.

Describe how users are restricted from accessing the operating system,

other applications, or other system resources not needed in the

performance of their duties.

Describe controls to detect unauthorized transaction attempts by

authorized and/or unauthorized users.

Describe any restrictions to prevent user from accessing the system or

applications outside of normal work hours or on weekends.

Indicate after what period of user inactivity the system automatically

blanks associated display screens and/or after what period of user

inactivity the system automatically disconnects inactive users or

requires the user to enter a unique password before reconnecting to

the system or application.

Indicate if encryption is used to prevent access to sensitive files as

part of the system or application access control procedures.

Describe the rationale for electing to use or not use warning banners

and provide an example of the banners used. Where appropriate, state

whether the Dept. of Justice, Computer Crime and Intellectual

Properties Section, approved the warning banner.

Figure 25, General Support System Logical Access Controls Template

9.3 Audit Trails

Does the audit trail support accountability by providing a trace of

user actions?

Are audit trails designed and implemented to record appropriate

information that can assist in intrusion detection?

Does the audit trail include sufficient information to establish what

events occurred and who (or what) caused them? (type of event, when

the event occurred, user id associated with the event, program or

command used to initiate the event.)

Is access to online audit logs strictly enforced?

Is the confidentiality of audit trail information protected if, for

example, it records personal information about users?

Describe how frequently audit trails are reviewed and whether there

are guidelines.

Does the appropriate system-level or application-level administrator

review the audit trails following a known system or application

software problem, a known violation of existing requirements by a

user, or some unexplained system or user problem?

Figure 26, General Support System Audit Trails Template

Chapter 11- Departmental Guide to Certification/Accreditation of
Information Systems, DIRMM U.S. DEPARTMENT OF TRANSPORTATION

OFFICE OF THE SECRETARY

DOT H 1350.253

DEPARTMENTAL GUIDE TO

CERTIFICATION/ACCREDITATION

OF INFORMATION SYSTEMS

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. REFERENCES

4\. BACKGROUND

a\. The Certification Process

b\. The Accreditation Process

5\. CERTIFICATION

a\. Assign A Project Leader

b\. Initiate A Project Charter

c\. Documentation Review

d\. Design Reviews and System Tests and Evaluation

e\. Certification Document

f\. Periodic Reviews and Recertification

6\. ACCREDITATION PROCESS

a\. The Steps

b\. Document Collection / Review

c\. Package Preparation / Submission

d\. Security Plan (General Support Systems)

e\. Security Plan (Major Application)

7\. CERTIFICATION AND ACCREDITATION REPORTS

a\. An Annual Review and Training Session

APPENDIX 1A: RULES OF BEHAVIOR (GENERAL SUPPORT SYSTEM)

APPENDIX 1-B RULES OF BEHAVIOR (MAJOR APPLICATION)

1\. Introduction

2\. Responsibilities

3\. Other Policies and Procedures

4\. Application Rules

5\. Analysis Techniques

6\. Data Flow Diagram

7\. Data Model

8\. APPLICATION SECURITY SPECIFICATIONS

a\. Sample Data and Process Specifications

b\. Computer System Security Specifications

c\. Audit Specifications

PURPOSE

Information systems must be given a level of protection commensurate
with their

importance to the overall Departmental mission and with the mission
risks

introduced by using this information technology. The importance of the

information system is based on both intangibles, such as the value of
the

information being processed, and tangibles, such as the value of
physical

facilities. Information systems will be placed into categories, each
with its

own unique management and security concerns. Information system (IS)
security

levels are used to define the protection requirements for Department of

Transportation (DOT) information and information systems. Once
information has

been categorized, the appropriate IS security level for that information
must be

determined. This is required to assure that appropriate protective
measures can

be are applied This guide provides a detailed approach for certification
and

accreditation also known as \"Approval to Operate\". This is required in

accordance with Office of Management and Budget (OMB) Circular A-130
Appendix

III and the Computer Security Act of 1987 and applies to all General
Support

Systems or Major Applications.

SCOPE

This guide applies to all information technology (IT) systems or major

applications owned, leased, operated or connected to by the Department
of

Transportation (DOT).

REFERENCES

See DOT 1530.2.1 Definitions and Terms.

BACKGROUND

The Department of Transportation (DOT) on a daily basis uses computer
systems to

manage, process, transmit and store information related to a broad range
of

programs. This information is critical to accomplishing the mission of
DOT thus

its integrity, availability and confidentiality must be assured. The
security of

DOT general support systems (systems) and major applications
(applications) is

vital to provide timely and accurate services, deter fraud, waste, and
abuse,

protect the privacy of individuals, and avoid embarrassment to the
Government.

The Certification and Accreditation process is a two-phase process.
These

processes are:

CERTIFICATION: Which involves implementation and testing information
system

security safeguards for a system or application. This process is
followed by,

ACCREDITATION (Authority to Operate): Is the process by which a system
owner

applies for a formal declaration by an agency official that a system or

application meets the applicable Federal policies, regulation and
standards.

That the implemented security safeguards are adequate to assure the
integrity,

availability and confidentiality of the information being processed,

transmitted or stored consistent with the level of sensitivity of that

information.

The Certification Process

OMB Circular A-130, Appendix III, requires Federal agencies to establish
a

process to assure that adequate security is provided for all
Departmental

information collected, processed, transmitted, stored, or disseminated
in

systems and applications. This certification process requires:

Security specification: Define and approve security safeguard
requirements and

specifications prior to starting formal system or application
development or

procurement.

Design reviews and system tests: Verify that selected / implemented
Management,

Operational and Technical Controls mitigate those risks which are deemed
to be

unacceptable.

Certification: Upon completion of the system test, an agency official
certifies

that the system or application meets applicable Federal policies,
regulations

and standards, and that the results of the tests demonstrate the
installed

security safeguards are adequate for the system or application.

Periodic review and re-certification: Agencies are required to conduct
periodic

audits or reviews of systems or applications and reevaluate the adequacy
of

security safeguards at least every 3 years. This allows for emerging

technologies to be used in the best interest of the Department or
Operating

Administration (OA).

The Accreditation Process

The authorization of a system or application to process, store or
disseminate

information, granted by a management official, provides an important
quality

control, the Department refers to this authorization as \"Authority to
Operate\".

By authorizing processing, storage, or dissemination on a system or by
an

application a manager accepts the risk associated with it. Here there is
a

distinct difference between a General Support System and a Major
Application.

The \"Authority to Operate\" should be reviewed at least every 3 years.

General Support Systems: Both the security official and the authorizing

management official have responsibilities. In general the security
official will

direct or perform security tasks, where the authorizing official will
normally

have general responsibility for the Department or OA supported by the
system.

Major Application: A major application is authorized by the management
official

responsible for the function supported by the application. This
authorization

should be reviewed at least every three years or more often, dependent
on the

level of risk and magnitude of harm. This review should also take into

consideration the risks from the general support systems used by the
application

or where the application is hosted.

CERTIFICATION

The process for certifying systems or applications should be properly
planned,

initiated, and managed. This section highlights the steps for this
process.

Assign A Project Leader

A successful certification process starts with the assignment of a
certification

project leader. The project leader is normally the organization's
information

systems security officer (ISSO). For new and significantly modified
systems or

applications, the project leader performs certification work in
conjunction with

the system application development team.

Initiate A Project Charter

The security charter includes the scope of work to be performed by the

participants, the resources needed, the work plan or schedule, and the
sponsor.

The project charter is the basis for obtaining formal authorization to
proceed,

acquiring resources, orienting project participants, and reaching a
consensus

within the organization of the project scope and context. This document
may be

part of the overall application development charter.

The project leader should circulate the charter to all organizational
components

that will be involved in the certification process.

Documentation Review

The project team reviews existing security documents for the target
system or

application and those host systems to which the system or application
connects

to, to help determine safeguards that are in place, planned, or not
applicable.

These documents include:

1\) Security Plan: A computer security plan summarizes security and
privacy

requirements of the system or application under consideration and
describes

the controls in place or planned for meeting those requirements. The
plan also

delineates responsibilities and expected behavior of all individuals who

access the system. The OMB recommended format includes four basic
sections:

System Identification, Management Controls, Operational Controls, and

Technical Controls. Security Plans and their content will be discussed
in more

detail in the accreditation section.

2\) Risk Assessment: The analysis of threats, vulnerabilities, assets
and

safeguards, as they affect systems or applications determines their
risk. If

the system or application has not had a risk assessment completed, this
fact

should be cited. The project charter, identified in paragraph 5b above
should

be expanded to reflect this added need. See DOT 1350.252 \"Departmental
Guide

to Risk Assessment Planning\" for a more detailed discussion on risk

assessments.

3\) System Test and Evaluation (ST&E): The ST&E is a critical element of

certification process. This element tests the effectiveness of
safeguards that

have been implemented to protect the system or application. If a ST&E
has been

done previously, this document should be reviewed and updated where
necessary.

4\) Contingency/Disaster Recovery Plan: An existing plan may be updated
to

meet the requirement. If none exits, it should be documented in the
security

plan as a \"planned\" safeguard and included in the
Certification/Accreditation

Statement as a planned action. See DOT 1350-254

5\) Audits, Reviews and Re-Certifications: Systems and applications must
be

re-certified at least every three years. Review of this documentation
may

identify limitations on the system or application that may not be
general

knowledge or detected previously.

6\) Management Reviews: These include departmental and OA Information

Resource Management (IRM) reviews and related activities.

7\) Inspector General (IG) Audit Reviews: The IG conducts several audits
and

reviews each year, including computer security audits. Review of this

documentation may identify limitations on the system or application that
may

not be general knowledge or detected previously.

8\) Systems Life-Cycle Technical Documents: These are prepared to
support the

development, operation, and maintenance of the system that should be
reviewed

to support the certification review. These Include among others:

Functional Requirements Analysis

Design Specifications

Hardware and Software Configuration

Testing and Acceptance Documentation

Systems Manual and User Manual

Design Reviews and System Tests and Evaluation

Design reviews and system tests are methods of determining the cost as
well as

the technical efficiency of safeguards for a system or application.
These

reviews should be conducted prior to filing for a final \"Authority to
Operate\".

This is to assure that the system or application has made an effort to
mitigate

their \"unacceptable risk\" and that the safeguards implemented are
mission

enhancing and effective.

1\) Design Reviews

The purpose of the design review is to ensure that all safeguards have
been

incorporated into the application system during the design phase.

The purpose of the design phase is to determine how best to satisfy

requirements. The primary security goal is to ensure that system
requirements

are adequately incorporated into the design specifications, including
controls

that ensure auditability.1 the design team determines how the system
will

work, addressing the components, subsystems, and modules. An application

system is usually technology environment component that is composed of

multiple systems, various hardware, software, and networking elements.

Application security must therefore be implemented from a comprehensive,

system-wide viewpoint. Components of a major application system may
include

multiple applications, a database management system (DBMS), a host
computer,

and a network.

Security requirements may be designed into the system in various ways.
For

example, authentication control, or passwords, may depend entirely on
the

operating system controls or a combination of DBMS, computer operating
system,

and the network operating system controls. When the desired hardware and

software combinations do not provide sufficient security, special
products may

be added to the system, such as RACF or Top Secret for mainframes,
WatchDog

Director or Net-DAC for networks, or PC-DAC for PC's.

To facilitate a design review, as required by OMB Circular A-130, the

documentation should show where and how the security specifications are

implemented. The design review is the last reasonable opportunity to
identify

weak points in the security plan. Omissions or inadequacies in the
security

feature if the design that is not identified in the design review may
require

costly software modifications.

2\) SYSTEM TESTS

System testing is the means by which the effectiveness of implemented

safeguards can be tested, validated and reported. These test results
will also

allow managers the ability determine if the return on investment for a

specific safeguard is economically feasible.

Testing could include both static and dynamic procedures, such as:

a\) Static evaluation techniques which include:

Conduct of tests for each security safeguard

Conduct of penetration studies to find security flaws

Review of code compliance with design specifications

b\) Dynamic testing means the operation of the application system with
test

data and the comparison of the actual results with expected or known
results.

c\) Specifications, Tests, And Results

Specifications and tests should be as specific as possible. A proven
method is

to use a specification/test/result process, as illustrated below.

1\. Specification: Identify sensitive application positions and screen

incumbents

Test Results: \*Sensitive positions are properly identified , but

incumbents have not been screened.

2 Specification: Conduct a risk analysis of the host computer facility.

Test procedure: Review the risk analysis documentation for quality and

completeness.

Test results: \* Risk analysis completed 3 years ago, but the facility

received major networking capabilities 18 months ago with no risk
analysis

update.

3 Specification: Identify and provide security training to all users,

technical staff, and management personnel directly involved with this

application system.

Test procedure: Review training records and spot check five individuals.

Test results: \* Security awareness training in progress. Training
records

are incomplete and only two of five individuals received security

training.

4 Specification: Implement a contingency plan for the application
system.

Test procedure: Review plan for adequacy, including offsite backups,

alternate location, and software tests.

Test results: \* An adequate contingency plan exists, but backups are
not

stored offsite, and software tests have not been conducted.

5 Specification: Implement password protection for the application
system.

Test procedure: Determine whether the password system meets the

recommended criteria of FIPS PUB 112 for the designated level of system

sensitivity (i.e., medium).

Test results: \* The password system does not meet minimum guidelines:

group passwords exits, a 6-month lifetime for passwords is not enforced,

obsolete accounts and passwords are on the system.

In the above samples the five asterisked (\*) test results indicate that
the

specification is not implemented fully. These asterisked test results
may affect

the certifiability of the system, because OMB requires an agency
official to

certify that the system meets all applicable Federal policies,
regulations and

standards, and that the results of the test demonstrate the installed
security

safeguards are adequate for the application.

These asterisked items should be corrected immediately, if possible, or
they

should be listed on the certification statement as \"restrictions\" or
\"corrective

actions.\" The process for accomplishing the formal statement is
addressed in the

next section, Certification.

CERTIFICATION DOCUMENT

When the certifying officials are satisfied that the system or
application has

adequate safeguards, a certification report is prepared and a
certification

statement is signed. When the ST&E is completed this information will be

incorporated into the General Support System or Major Application
Security Plan.

Restrictions and corrective actions are listed on the statement. See the
sample

Certification Statement on the following page.

If the certifying officials are not satisfied that the application
system has

adequate safeguards, a deferral certification statement may be executed.
A

sample Certification Deferral statement is also provided following the

certification statement.

SAMPLE GENERAL SUPPORT SYSTEM

CERTIFICATION STATEMENT

Dated: (Enter Date Here)

(I / We) certify that having carefully reviewed the following listed
documents:

1\. (System Name) Security Plan, dated (Enter Date)

2\. Risk Assessment, dated (Enter Date)

3\. System Test and Evaluation Report, dated (Enter Date)

4\. Continuity of Operations Plan, dated (Enter Date)

5\. Contingency Plan, dated (Enter Date)

6\. Other Ancillary System Documentation

a\. (List by Name and Date of Document) e.g. Network Diagrams,

b\. (List by Name and Date of Document) e.g. System Design Review,

c\. (List by Name and Date of Document) e.g. Rules of Behavior,

d\. (List by Name and Date of Document) e.g. memorandums of
Understanding,

etc.

(I / We) certify that the safeguards designed, developed, and
implemented (have

/ have not) reasonably demonstrated through the test results to (provide
/ not

provide) the necessary security to reduce the risk of operating the

aforementioned system to an acceptable level.

Based on this review (I / We) (recommend / do not recommend / recommend
with

comment) that the aforementioned system be submitted for Authority to
Operate.

(Restrictions or Comments, if any) (This section can recommend
corrective action

to be taken to include a schedule for these actions to take place.)

(Signature / Title of Certifying Official)

(Signature / Title of System Owner)

(Signature / Title of Security Officer)

SAMPLE MAJOR APPLICATION

CERTIFICATION STATEMENT

Dated: (Enter Date Here)

(I / We) certify that having carefully reviewed the following listed
documents:

1\. (Application Name) Security Plan, dated (Enter Date)

2\. Risk Assessment, dated (Enter Date)

3\. System Test and Evaluation Report, dated (Enter Date)

4\. Continuity of Operations Plan, dated (Enter Date)

5\. Contingency Plan, dated (Enter Date)

6\. Other Ancillary System Documentation

a\. (List by Name and Date of Document) e.g. ERD's

b\. (List by Name and Date of Document) e.g. Application Design Review,

c\. (List by Name and Date of Document) e.g. Rules of Behavior,

d\. (List by Name and Date of Document) e.g. Memorandums of
Understanding,

etc.

(I / We) certify that the safeguards designed, developed, and
implemented (have

/ have not) reasonably demonstrated through the test results to (provide
/ not

provide) the necessary security to reduce the risk of operating the

aforementioned application to an acceptable level.

Based on this review (I / We) (recommend / do not recommend / recommend
with

comment) that the aforementioned application be submitted for Authority
to

Operate.

(Restrictions or Comments, if any) (This section can recommend
corrective action

to be taken to include a schedule for these actions to take place.)

(Signature / Title of Certifying Official)

(Signature / Title of System Owner)

(Signature / Title of Security Officer)

PERIODIC REVIEWS AND RECERTIFICATION

Appendix III, OMB Circular A-130 states that:

Review of Security Controls. The security of a system will degrade over
time, as

the technology evolves and as people and procedures change. Reviews
should

assure that management, operational, personnel, and technical controls
are

functioning effectively. Security controls may be reviewed by an
independent

audit or a self review. The type and rigor of review or audit should be

commensurate with the acceptable level of risk that is established in
the rules

for the system and the likelihood of learning useful information to
improve

security. Technical tools such as virus scanners, vulnerability
assessment

products (which look for known security problems, configuration errors,
and the

installation of the latest patches), and penetration testing can assist
in the

on-going review of different facets of systems. However, these tools are
no

substitute for a formal management review at least every three years.
Indeed,

for some high-risk systems with rapidly changing technology, three years
will be

too long.

Depending upon the risk and magnitude of harm that could result,
weaknesses

identified during the review of security controls should be reported as

deficiencies in accordance with OMB Circular No. A-123, \"Management

Accountability and Control\" and the Federal Managers\' Financial
Integrity Act.

In particular, if a basic management control such as assignment of

responsibility, a workable security plan, or management authorization
are

missing, then consideration should be given to identifying a deficiency.

ACCREDITATION PROCESS

The accreditation process is where all the information concerning the
system or

application is compiled to depict the true status of its security
posture. Given

that not all risks can be completely mitigated and that some risks will
not be

addresses because it is economically not efficient to do so, this is
where

everything about the system or application is discussed. The purpose for
this

presentation of information is to allow the Authorizing Official the
ability to

make a sound, well informed determination as to the ability of the
system or

application to operate, while still ensuring confidentiality,
availability and

integrity of the information processed, stored or disseminated therein.

THE STEPS

The accreditation process consists of two basic steps. The goal of the
process

is to provide to the accreditation or approving authority all the
information

that is needed to make an informed decision as to the suitability of the
system

or application to protect the availability, integrity and
confidentiality of the

information that is processed, stored, or disseminated. The three steps
are:

Document Collection / Review

Package Preparation / Submission

Document Collection / Review

The collection and review of many documents is key to completing an

accreditation package. These documents will identify the system or
application,

it's design, associated threats, vulnerabilities, assets, and risks.

Additionally, these documents will identify how a system or application
will

continue to be mission productive in the event of a disaster. These and
many

more items will aid the approval authority in determining if a system or

application can be given an authority to operate. Some of these
documents

include but are not limited to:

1\. Security Plan - Special consideration should be paid to the security
plan

during the review. There are many facets to the plan which must be
addressed.

There is also a difference between the General Support System Security
Plan

and the Major Application Security Plan. (See paragraph d and e below)

2\. Risk Assessment,

3\. System Test and Evaluation Report,

4\. Continuity of Operations Plan,

5\. Contingency Plan,

6\. Other Ancillary Documentation e.g. ERD's, Application Design Review,
Rules

of Behavior, Memorandums of Understanding, etc.

Package Preparation / Submission

Once all of the documentation has been reviewed and the reviewing
official,

security official, and / or management has decided that all of the
required

documentation is present, and meets the standards set forth in Federal

regulations, policies, procedures and standards. Then the information
should be

forwarded to the Approving Authority for determination as to whether or
not

Authority to Operate will be granted.

SECURITY PLAN (General Support Systems)

1\. SYSTEM IDENTIFICATION

System Name/Title

Responsible Organization

Information Contact(s)

Assignment of Security Responsibility

System Operational Status (If more than one status is selected, list
which

part of the system is covered under each status.)

General Description/Purpose

System Environment

System Interconnection/Information Sharing

Applicable Laws or Regulations Affecting the System

General Description of Information Sensitivity

2\. MANAGEMENT CONTROLS

a\. Risk Assessment and Management

b\. Review of Security Controls

c\. Rules of Behavior (See Appendix A)

d\. Planning for Security in the Life Cycle - Determine which phase(s)

of the life cycle the system or parts of the system are in. Describe how

security has been handled in the lifecycle phase(s) that the system is

currently in.

e\. Authorize Processing

3\. OPERATIONAL CONTROLS

Personnel Security

Physical and Environmental Protection

Production, Input / Output Controls - Describe the controls used for the

marking, handling, processing, storage, and disposal of input and output

information and media, as well as labeling and distribution procedures
for

the information and media. The controls used to monitor the installation
of,

and updates to, software should be listed. In this section, provide a

synopsis of the procedures in place that support the system. Below is a

sampling of topics that should be reported in this section.

Contingency Planning - Briefly describe the procedures (contingency
plan)

that would be followed to ensure the system continues to process all

critical applications if a disaster were to occur. If a formal
contingency

plan has been completed, reference the plan. A copy of the contingency
plan

can be attached as an appendix.

Hardware and System Software Maintenance Controls

Integrity Controls

Documentation - Documentation for a system includes descriptions of the

hardware and software, policies, standards, procedures, and approvals

related to automated information system security of the system to
include

backup and contingency activities, as well as descriptions of user and

operator procedures.

Security Awareness & Training

Incident Response Capability

4\. TECHNICAL CONTROLS

Identification and Authentication

Logical Access Controls

Audit Trails

SECURITY PLAN (Major Application)

1\. APPLICATION IDENTIFICATION

Application Name/Title

Responsible Organization

Information Contact(s)

Assignment of Security Responsibility

Application Operational Status (If more than one status is selected,
list

which part of the Application is covered under each status.)

General Description/Purpose

Application Environment

Application Interconnection/Information Sharing

Applicable Laws or Regulations Affecting the Application

General Description of Information Sensitivity

2\. MANAGEMENT CONTROLS

Risk Assessment and Management

Review of Security Controls

Rules of Behavior (See Appendix A)

Planning for Security in the Life Cycle - Determine which phase(s) of
the

life cycle the Application, or parts of the Application are in. Describe
how

security has been handled in the life cycle phase(s) the Application is

currently in.

Authorize Processing

3\. OPERATIONAL CONTROLS

Personnel Security

Physical and Environmental Protection

Production, Input/Output Controls - Describe the controls used for the

marking, handling, processing, storage, and disposal of input and output

information and media, as well as labeling and distribution procedures
for

the information and media. The controls used to monitor the installation
of,

and updates to, application software should be listed. In this section,

provide a synopsis of the procedures in place that support the
operations of

the application. Below is a sampling of topics that should be reported
in

this section.

Contingency Planning - Briefly describe the procedures (contingency
plan)

that would be followed to ensure the application continues to be
processed

if the supporting IT systems were unavailable. If a formal contingency
plan

has been completed, reference the plan. A copy of the contingency plan
can

be attached as an appendix.

Application Software Maintenance Controls

Data Integrity/Validation Controls

Documentation - Documentation for a Application includes descriptions of
the

hardware and software, policies, standards, procedures, and approvals

related to automated information system security in the application and
the

support systems(s) on which it is processed, to include backup and

contingency activities, as well as descriptions of user and operator

procedures.

Security Awareness and Training

4\. TECHNICAL CONTROLS

Identification and Authentication

Logical Access Controls

Public Access Controls

If the public accesses the major application, discuss the additional

security controls used to protect the integrity of the application and
the

confidence of the public in the application. Such controls include

segregating information made directly accessible to the public from
official

agency records. Others might include:

Audit Trails

CERTIFICATION AND ACCREDITATION REPORTS

Accrediting officials are the agency officials who have authority to
accept a

system or application's security safeguards and issue an accreditation
statement

that records the decision. Within DOT, the accrediting official is known
as the

Designated Approval Authority (DAA). The DAA must also possess authority
to

allocate resources to achieve acceptable security and to remedy security

deficiencies. Without this authority, such individuals cannot
realistically take

responsibility for the accreditation decision. In general, this requires
the

Accreditation Authority to include a senior official and perhaps the
line

manager for the application in question. For some very sensitive
applications,

the Senior Executive Officer is appropriate as a DAA. In general, the
more

sensitive the applications, the higher the DAAs are in an organization.
DAAs

should consult the agency general counsel to determine their personal

liabilities.\"

An Annual Review and Training Session

The ideal way to conduct a re-certification is to hold an annual
application

system meeting in which management, security, and end-user personnel
review the

security of the system. This approach provides a way to satisfy both the

security needs/updates of the system and the training/orientation needs
of the

individuals who are associated with the system. The process can be as
simple as

review the CSSP, item by item, for additions, changes, and deletions.
Group

members should carefully review current procedures for the following:

1\. Authentication and access controls: review current authentication
and

access procedures to determine whether they meet specifications,

2\. Audits/accountability: review current procedures and audits to
determine

whether they meet specifications, and

3\. Backups/contingency planning: review actual copy of contingency plan
and

status of key items to determine whether they meet specifications.

TABLE V-1: References for Basic Security Functions

This table is extracted from Federal documents to illustrate the major
statutory

and regulatory references for the basic computer security functions.

Basic Security Functions Computer Security Act 1987 OMB Circ. A-130A-123

A-127FPMFIRMRPA/FOIANIST Pubs

Policy

Implement and maintain security program; assign responsibilities

Security Plans

Identify sensitive system; implement security plans 800-18

Applications Security

Certify applications; re-certify every 3 years. Develop and maintain

contingency plans.

73, 102

87

Installation Security

Conduct risk analysis every 3 years.

Prepare acquisition specifications.

Maintain disaster recover plans. X

X

X 31,65

87

Personnel Security

Designate sensitive positions and screen incumbents

Security Awareness and Training

Train Federal and contractor personnel. X X 800-16

Reporting

Report security weaknesses in A-123 Report to President X X

\* The Computer Security Act of 1987 is implemented through OMB
Bulletins and

other regulatory material. NIST Special Publication 800-18 outlines the
contents

of security plans.

APPENDIX A: RULES OF BEHAVIOR

APPENDIX 1A: Rules of Behavior (General Support System)

Hypothetical Government Agency's (HGA)

Backbone Local Area Network

The rules of behavior contained in this document are to be followed by
all users

of the HGA Local Area Network (LAN). Users will be held accountable for
their

actions on the LAN. If an employee violates HGA policy regarding the
rules of

the LAN, they may be subject to disciplinary action at the discretion of
HGA

management. Actions may range from a verbal or written warning, removal
of

system access for a specific period of time, reassignment to other
duties, or

termination, depending on the severity of the violation.

Work at home. HGA Personnel Policy Directive 97-03, dated March 10,
1997,

authorizes Division Directors to designate specific employees (e.g.,
critical

job series, employees on maternity leave, employees with certain medical

conditions) as eligible for working at home. Any work at home
arrangement

should:

be in writing;

identify the time period the work at home will be allowed;

identify what government equipment and supplies will be needed by the

employee at home, and how that equipment and supplies will be
transferred

and accounted for;

identify if telecommuting will be needed and allowed (this issue should
be

discussed between the requesting organization, Information Resources

Management Division (IRMD), and the SECURITY OFFICE; see Dial-in access

section below); and

be reviewed by HGA\'s personnel office prior to commencement.

Dial-in access. No dial-in access is used to access LAN servers.
However, if a

justifiable need occurs, the IRM Division Director may authorize dial-in
access

to a LAN server. It is understood that dial-in access would pose
additional

security risks, but may become necessary for certain job functions. If
dial-in

access is allowed, IRMD and the SECURITY OFFICE will regularly review

telecommunications logs and HGA phone records, and conduct spot-checks
to

determine if HGA business functions are complying with controls placed
on the

use of dial-in lines. All dial-in calls will use one-time passwords.

Connection to the Internet. Some HGA personnel have access to the
Internet.

Access to the Internet should be closely controlled by the SECURITY
OFFICE. HGA

divisions, staff managers, and technicians should know that only
HGA-authorized

Internet connections will be allowed, and that all connections must
conform to

HGA's security and communications architecture.

Protection of copyright licenses (software) -- LAN and PC users are not
to

download LAN-resident software. Audit logs will be reviewed to determine
whether

employees attempt to access LAN servers on which valuable, off-the-shelf

software resides, but to which users have not been granted access. Audit
logs

will also show users' use of a \"copy\" command; this may indicate
attempts to

illegally download software. Unauthorized copying of PC-based software
is also

prohibited.

Unofficial use of government equipment -- Users should be aware that
personal use

of information resources -- LAN and PC -- is not authorized.

Use of passwords -- Users are to use passwords of a length specified by
the LAN

system administrators -- a mix of six (6) alpha and numeric characters,
they are

to keep passwords confidential and are not to share passwords with
anyone.

System privileges -- Users are given access to the LAN based on a need
to perform

specific work. Users are to work within the confines of the access
allowed and

are not to attempt access to systems or applications to which access has
not

been authorized.

Individual accountability -- Users will be held accountable for their
actions on

the LAN. This is stressed during computer security awareness training
sessions

Restoration of service -- The availability of the LAN is a concern to
all users.

All users are responsible for ensuring the restoration of services in
the event

the LAN is unoperational.

I acknowledge receipt of, understand my responsibilities, and will
comply with

the rules of behavior for the HGA Backbone LAN.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_Signature of User / Date

APPENDIX 1-B Rules of Behavior (MAJOR APPLICATION)

HYPOTHETICAL GOVERNMENT AGENCY'S (HGA)

FINANCIAL INFORMATION SYSTEM

INTRODUCTION

The following rules of behavior are to be followed by all users of the
HGA's

Financial Information System (HFIS). The rules clearly delineate

responsibilities of and expectations for all individuals with access to
the

HFIS. Non-compliance of these rules will be enforced through sanctions

commensurate with the level of infraction. Actions may range from a
verbal or

written warning, removal of system access for a specific period of time,

reassignment to other duties, or termination, depending on the severity
of the

violation.

RESPONSIBILITIES

The Chief, Financial Information Systems Branch, is responsible for
ensuring an

adequate level of protection is afforded to the FIS, through an
appropriate mix

of technical, administrative, and managerial controls. The Branch Chief
develops

policies and procedures, ensures the development and presentation of
user and

contractor awareness sessions, and inspects and spot checks to determine
that an

adequate level of compliance with security requirements exists. The
Branch Chief

is responsible for periodically conducting vulnerability analyses to
help

determine if security controls are adequate. Special attention will be
given to

those new and developing technologies, systems, and

OTHER POLICIES AND PROCEDURES

The rules are not to be used in place of existing policy, rather they
are

intended to enhance and further define the specific rules each user must
follow

while accessing HFIS. The rules are consistent with the policy and
procedures

described in the following directives:

HGA IRM Computer Security Handbook. The newly revised Handbook, dated
April 4,

1998, contains computer security guidance on a wide range of topics,
i.e.,

personnel security, incident handling, access control mechanisms. This
document

contains responsibilities for the SECURITY OFFICE, HGA managers, and
users.

HFIS Access Control Management Directive. This directive, dated May 6,
1997,

contains responsibilities for HFIS data owners and application
administrators.

Draft HFIS Access Control Management Directive. The draft HFIS Access
Control

Management Directive contains specific responsibilities for the security

officer.

Letter for External (non-HGA) Users. A letter for Non-HGA users which
transmits

the applicable HGA policies should be provided to all non-HGA users
while using

HFIS, or when using HGA systems and applications in general. These

responsibilities should be included in training HGA provides for agency
security

points of contact, and should be included in interagency agreements or
other

formal agreements or documents between HGA and other organizations.

APPLICATION RULES

4.1 Work at home. HGA Personnel Policy Directive 97-03, dated March 10,
1997,

authorizes Division Directors to designate specific employees (e.g.,
critical

job series, employees on maternity leave, employees with certain medical

conditions) as eligible for working at home. Any work-at-home
arrangement

should:

be in writing;

identify the time period the work at home will be allowed;

identify what government equipment and supplies will be needed by the

employee at home, and how that equipment and supplies will be
transferred

and accounted for;

identify if telecommuting will be needed and allowed (this issue should
be

discussed between the requesting organization, Information Resources

Management Division (IRMD), and the SECURITY OFFICE; see Section 4.2);
and

be reviewed by HGA\'s personnel office prior to commencement.

4.2 Dial-in access. The IRM Division Director may authorize dial-in
access to

HFIS. It is understood that dial-in access poses additional security
risks, but

may become necessary for certain job functions. If dial-in access is
allowed,

IRMD and the security office will regularly review telecommunications
logs and

HGA phone records, and conduct spot-checks to determine if HGA business

functions are complying with controls placed on the use of dial-in
lines. All

dial-in calls will use one-time passwords. If dial-in access is allowed
to other

applications on the system on which HFIS resides, the managers of those

applications should also determine if such access could pose a risk to
HFIS

data.

4.3 Connection to the Internet. Some HGA personnel have access to the
Internet.

HGA should ensure that the user authentication required for access is
adequate

to protect HFIS programs and data. If such access is allowed, HGA should

carefully document all external connections to ensure access to HFIS is
limited

to controlled points of entry.

4.4 Protection of software copyright licenses. All copyright licenses
associated

with the COTS HFIS software are complied with by HGA personnel, as well
as by

contractors responsible for developing and maintaining HFIS. HGA
requires that

all copyright licenses for all PC-based and LAN-based software used by
HFIS

program personnel and contractor personnel are understood and that these

personnel comply with the license requirements. End users, supervisors,
and

function managers are ultimately responsible for this compliance.

4.5 Unofficial use of government equipment. Users should be aware that
personal

use of information resources is not authorized.

I acknowledge receipt of, understand my responsibilities, and will
comply with

the rules of behavior for the HFIS.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_Signature of User / Date

APPENDIX B: MATRIX OF MINIMUM SECURITY SPECIFICATIONS

APPENDIX B: MATRIX OF MINIMUM SECURITY SPECIFICATIONS

This Appendix is a list of safeguards that fit under controls.

Explanation: This matrix is used to identify a minimum set of safeguards
that

should be implemented to protect classified and sensitive application
systems

and general support systems. The safeguards listed below are similar to
those

listed in Section 4.2.2 of the DOT Guide for Local Area Network
(LAN)/Wide Area

Network (WAN) Security.

Justification for non-implementation of these safeguards should be based
on the

results of a formal risk analysis, risk assessment, and cost-benefit
analysis.

Directions: Scan the Xs and Os beneath each security level designation.
An X

means that the security safeguard listed to the left is a requirement.
An O

means that the security safeguard is optional.

SECURITY LEVEL

CONTROLS Classified

(Level 1) High Sensitivity

(Level 2) Moderate Sensitivity

(Level 2) Low Sensitivity

(Level 2)

MANAGEMENT CONTROLS

1.Establish a detailed risk management program

2.Ensure that all personnel positions have been assigned security level

designations

3.Conduct periodic security level designation reviews

4.Ensure that all personnel, including contractors, have received

appropriate clearances.

5.Maintain a list of all \"classified,\" \"Special-Sensitive,\" and

\"Critical-Sensitive\" clearances granted.

6.Conduct formal risk analyses (Host computer/network).

7.Conduct application risk assessment.

8.Prepare and document application rules of behavior

9.Maintain accurate inventory of all hardware and software.

SECURITY AWARENESS AND TRAINING

1.Establish an employee security awareness and training program.

2.Provide specialized security training

DEVELOPMENT/IMPLEMENTATION CONTROLS

1.Prepare security specifications.

2.Conduct application design review and system testing.

3.Conduct a security review and prepare a certification report

OPERATIONAL CONTROLS

1.Ensure that a complete and current set of documentation exists for all

operating systems.

2.Establish controls over the handling of sensitive data, including

labeling materials and controlling the availability and flow of data.

3.Require that all sensitive material be stored in a secure location
when

not in use.

4.Dispose of unneeded sensitive hard copy documents and erase sensitive

data from storage media in a manner that will prevent unauthorized use.

5.Prepare and maintain lists of persons authorized to access facilities

and automated information systems processing sensitive data.

6.Establish procedures for controlling access to facilities and
automated

information systems processing sensitive data.

7.Furnish locks and other protective measures on doors and windows to

prevent unauthorized access to computer and support areas.

8.Install emergency (panic) hardware on \"emergency exit only\" doors.

Ensure that emergency exits are appropriately marked.

9.Specify fire-rated walls, ceilings, and doors for construction of new

computer facilities or modification of existing facilities.

10.Install smoke/fire detection systems with alarms in the computer

facility. When feasible, connect all alarms to a control alarm panel

within the facility and to a manned guard station or fire station.

11.Install fire suppression equipment in the computer facility that may

include area sprinkler systems with protected control valves, and/or
fire

extinguishers.

12.Provide emergency power shut down controls to shut down AIS equipment

and air conditioning systems in the even of fire or other emergencies.

Include protective covers for emergency controls to prevent accidental

activation.

13.Provide waterproof covers to protect computers and other electronic

equipment from water damage.

14.Establish a fire emergency preparedness plan to include training of

fire emergency response teams, development and testing of an evacuation

plan, and on site orientation visits for the local fire department.

15.Establish contingency plan and information back-up plan.

16.Establish emergency power program

17.Configuration management and application software maintenance

18.SDLC documentation

TECHNICAL CONTROLS

1.Require use of current passwords and log on codes to protect sensitive

automated information systems data from unauthorized access.

2.Establish procedures to register and protect secrecy of passwords and

log on codes, including the use of a non-print, feature.

3.Limit the number of unsuccessful attempts to access an automated

information system or a database.

4.Develop means whereby the user's authorization can be determined.
(This

may include answer back capability.)

5.Establish an automated audit trail capability to record user

activity.

6.Implement methods, which may include the establishment of encryption,
to

secure data being transferred between two points

7.Ensure that the operating system contains controls to prevent

unauthorized access to the executive or control software system.

8.Ensure that the operating system contains controls that separate user

and master modes of operations.

9.Record occurrences of non-routine user/operator activity (such as

unauthorized access attempts and operator overrides) and report to the

organizational ISSO.

10.Ensure that the operating system provides methods to protect

operational status and subsequent restart integrity during and after

shutdown.

11.Install software feature(s) that will automatically lock out the

terminal if it is not used for a predetermined period of lapsed inactive

time, for a specified time after normal closing time, or if a password
is

not entered correctly after a specified number of times.

12.Ensure that the operating system contains controls to secure the

transfer of data between all configuration devices.

13.Secure communication lines

15.Ensure that VIRUS protection procedures are in place and users are

trained in virus prevention

16.Implement required access control procedures for public use of the

system.

17.Review security and effectiveness of FIREWALLS

18.Prepare written authorization for interconnection with other systems

and sharing of sensitive information

APPENDIX C: DEVELOPING SPECIFICATIONS FOR NEW APPLICATIONS

(REQUIREMENTS ANALYSIS)

OMB requires agencies to \"define and approve security requirements and

specifications prior to acquiring or starting formal development of the

applications.\" This appendix describes procedures for evaluating
security

specifications during the requirement analysis stage for new
applications.

Systems development normally progresses through life-cycle stages, such
as

planning, analysis, construction, and implementation. The requirement
analysis

stage reveals the detailed data requirements and information processes
that must

be protected.

ANALYSIS TECHNIQUES

The basic challenge in developing an application system is to understand
the

interrelationships between the processes and data. In the analysis
phase,

developers use structured techniques (e.g., graphical models) to
breakdown and

reorganize the elements of the information system's organization. The
major data

flows indicate the inputs and outputs of the system. As the context
diagram is

constructed, the development team should review the overall sensitivity
of the

system and its inputs and outputs. The team should annotate the diagram,
using

abbreviations for confidentiality, integrity and availability (e.g., C,
I, and

A\) and high, medium, or low (e.g., H, M, L). For example, the team must
decide

how to categorize requisitions, realizing that the unauthorized
disclosure of

estimated cost data for a major contract could give an unfair advantage
to a

prospective bidder. As the development work progresses, the team
normally

adjusts the annotated context diagram, as needed.

DATA FLOW DIAGRAM

The team divides the application system (context diagram) into its major

sub-functions, using a data flow diagram This functional decomposition

continues, creating as many data flow diagrams as needed, or until a
process can

no longer are decomposed. As the data flow diagrams are built, the team
reviews

each process for type and level of sensitivity and annotates the
diagrams

accordingly.

DATA MODEL

Most application projects require some type of modeling technique to
identify

and structure the data. A common technique is the entity relationship
diagram

(ERD). ERDs help to identify groups of information or entities, the
attributes

or data elements that belong to each entity, and the relationships among
the

entities. Entities can be any object, for example a place, thing, event
or

subject, about which information is kept. Entities can also consist of
groups of

data, such as standard forms, in which information is kept. As the
entity

relationship diagrams are built, the development team can review each
entity and

its attributes (data fields) for type and level of sensitivity, and
annotate the

diagrams accordingly. In the process of grouping data elements within
the

entities to eliminate redundancy (called normalization), the issue of

sensitivity is important. Certain data fields may be highly sensitive,
such as

vendor bid data, and the team may want to \"fence\" these data fields by
putting

them into a separate entity for the implementation of more restrictive
security

controls.

APPLICATION SECURITY SPECIFICATIONS

Next, review the annotated process and data models to get an overall
picture of

the sensitivity requirements. Make a summary matrix of the components
with high

(level 3) or moderate (level 2) sensitivity, confidentiality6,
integrity, or

availability.

A matrix of the process and data components may look like the following:

TABLE B-1: Matrix of Sensitive Components

COMPONENTSSENSITIVITY

C I A

Process Contracts

Develop RFP Low Low Moderate

Issue RFP Low Low Moderate

Evaluate Bids High High Moderate

Award Contract High High Moderate

Vendor Proposal Data:

Contract Line Item No. Low Low Moderate

Vendor ID No. Low Low Moderate

Description High High Moderate

Cost High High Moderate

Overall Sensitivity High High Moderate

In this \"sample\" review, the team determined that the \"Evaluate
Bids\" and \"Award

Contract\" processes and the vendor-supplied description and cost data
are the

high sensitivity elements in this application system. The other
processes and

data were judged to have either medium or low sensitivity.

Sample Data and Process Specifications

Sample security specifications for the processes described in the above

example include:

1\. Separate duties, designate sensitive positions, screen incumbents

2\. Limit access to sensitive processes to authorized persons

3\. Use automated editing, validation, and error-checking controls

4\. Control computer input and output documents and waste paper

Security specifications for data are designed to protect the application
data

within the computer. Therefore, the data specifications are access
oriented.

Some sample specifications for the sensitive data are:

5\. User access controls (read, write, modify, and delete). For example,

access will be limited as follows:

Contract supervisor:Read, write, modify, and delete

Contracting Officer:Read, write, modify, and delete

Data entry clerk:Read and write

Database administrator:Full system access (Contract office employee)

Programmer:No access to operational system

6\. Encryption capability for files within the application. Note that
when

cryptographic protection is needed for sensitive unclassified data,
Federal

agencies are required to use the NIST-approved Data encryption Standard

(DES). NIST has validated only hardware and firmware implementations of
DES

in commercially available security products.

The foregoing sample security specifications provide confidentiality and

integrity protections for the processes and data. Availability
protection is

provided through the development and implementation of emergency,
backup, and

contingency requirements. A contingency plan is required to ensure that
users

can continue to perform essential functions in the event their
information

technology support is interrupted.

Computer System Security Specifications

The analysis team should now specify the minimum information system
security

requirements. These safeguards may be at the application level or the
database

level and some may be at the operating system or network levels,
depending on

the actual hardware and software configurations that are selected and
designed

for the system. For example:

1\. User identification and authentication controls

2\. Password management -- length, time expiration

3\. Automatic password encryption and non-display feature

4\. Automatic log off after three attempts and \"timeouts\" if no
activity for

a specified number of minutes

5\. User dial-in access controls

Audit Specifications

Audit controls provide a system monitoring and recording capability to
retain or

reconstruct a chronological record of system activities such as logon
attempts,

access to files and changes to data. \"In financial applications, a
transaction

must be capable of being traced from its initiation, though all the
intermediate

processing steps, to the resulting financial statement. Similarly,
information

in the financial statements must be traceable to its origin. Such
capability is

also essential in non-financial systems or applications.\"1

In specifying the audit requirements, the first step is to determine
what needs

to be audited and when. The goal is to provide a comprehensive and
manageable

audit program. The audit requirements are therefore grouped as follows
for our

example:

1\. Exception reporting

a\. User logon failures (after three unsuccessful attempts)

b\. Unauthorized transaction attempts

2\. Event records -- to identify all transactions entering or exiting
the

application

3\. Journal records -- to maintain a complete daily backup for an audit

history (which may also be part of the contingencies and disaster
recovery

planning)

a\. Configuration Management

Major application systems are dependent upon system life cycle
management, to

include configuration management, good programming practices, and
effective

computer operations procedures. Problems that affect security includes

procedural errors and omissions, deliberate traps inserted into code,
inadequate

testing and documentation, and flaws in the implementation of security
controls.

Configuration management procedures should include:

1\. Peer review of code to ensure conformance to design requirements,

2\. Software library controls to limit access to application or system

software,

3\. Documentation of security-related code to facilitate review and
testing,

4\. Separation of duties to limit access to operational code,

5\. Isolation of critical code for protection and auditing,

6\. Procedures to manage different software versions, and

7\. Compliance with system development life cycle requirements.

The security specifications become part of the documentation for the
requirement

analysis, such as the functional requirements and data requirement
documents.

1 NBS Special Publication 500-153, April 1988

Chapter 11- Departmental Guide to Continuity of Operations Planning,
DIRMM U.S.

DEPARTMENT OF TRANSPORTATION

OFFICE OF THE SECRETARY

DOT H 1350.254

DEPARTMENTAL GUIDE TO

CONTINUITY OF OPERATIONS PLANNING

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. GOALS

4\. REFERENCES

5\. OVERVIEW OF CONTINUITY OF OPERATIONS PLANNING

6\. CONTINUITY OF OPERATIONS PLANNING PROCESS

A. Step 1. Identify Mission- or Business-Critical Functions.

B. Step 2. Identify Resources That Support Critical Functions.

C. Step 3. Anticipate Potential Contingencies or Disasters.

D. Step 4. Select Continuity Of Operations Planning Strategies.

E. Step 5. Document Continuity Of Operations Planning Strategies.

F. Step 6. Test and Revise Strategy.

APPENDIX A: IT SYSTEM CRITICALITY QUESTIONNAIRE

APPENDIX B: IT SYSTEM CRITICAL RESOURCES INVENTORY OUTLINE

APPENDIX C: CONTINUITY OF OPERATIONS PLAN MODEL

DEPARTMENTAL GUIDE TO CONTINUITY OF OPERATIONS PLANNING

PURPOSE

The purpose of this Guide is to provide Department of Transportation
(DOT) and

their Operating Administration managers, ISSO's and network
administrators

with a step-by-step approach for preparing a Contingency Plan, which
address

short term losses, or a Continuity Plan, which addresses long term
losses, for

their systems. These completed plans will allow the organization to
address

the steps to be taken in order to maintain the operation of their
critical

functions, in the event of contingencies, losses, disruptions or
disasters.

SCOPE

The provisions of this Guide apply to the Department of Transportation
(DOT),

its Secretarial Offices and Operating Administrations.

GOALS

The Goal of continuity of operations planning is to provide reasonable
methods

to conduct prevention, response, resumption, recovery or restoration
services,

should events occur which prevent normal operations. The contingency and

continuity plans must be fully documented and operationally tested

periodically, at a frequency commensurate with the risk and magnitude of
loss

or harm that could result from disruption or denial of service. At a
minimum,

these plans should be tested on an annual basis.

REFERENCES

The DOT Departmental Information Resources Management Manual (DIRMM) DOT
H

1350.2 implements statutory and regulatory Information Resources
Management

(IRM) and security requirements for the Department. It also calls for
ensuring

the confidentiality, integrity, and availability of information
contained,

processed, or transmitted in/on sensitive systems. Refer to DOT H
1350.2.1

REGULATORY AND GUIDANCE DOCUMENTS for specific references.

OVERVIEW OF CONTINUITY OF OPERATIONS PLANNING

Like other government agencies, DOT depends on the availability of
accurate

and timely information to manage a broad range of programs and budgets
with

far-reaching effects. Virtually all-vital information is processed in
some

form by computers. Hence a key aspect in DOT's overall risk management
program

must be the ability to respond to unplanned, adverse situations that may

destroy, damage, degrade, or compromise information systems data or
computer

processing capabilities so that essential operations may continue.
Ensuring

that this ability exists, and is indeed viable (proven via periodic
testing)

is the major function of continuity of operations planning.

OMB Circular A-130 requires continuity of operations planning for every

information system. This includes both contingency planning
(short-term), and

continuity planning (longer-term), in order to rapidly and effectively
deal

with the potential disruption of critical mission and business
functions. To

avert these disruptions, or minimize their damage, organizations must
take

proactive steps to develop a Continuity of Operations Plan (COOP). The

Contingency portion of the COOP focuses on minimal, day-to-day outages
(server

down, localized short-term connectivity loss, etc.), while the
Continuity

portion deals with long term or disaster scenarios. The COOP contains

operational recovery issues, ranging from arrangements for a limited
backup

capability (needed files, programs, paper stocks, pre-printed forms,
etc.) to

relocation to a different facility in the event of a total failure. The
goal

is to protect lives, limit damage to property, and minimize the impact
on

operations, including information systems processing activities.

CONTINUITY OF OPERATIONS PLANNING PROCESS

Continuity of operations planning involves more than planning for a move

offsite if a disaster destroys a data center. It also addresses how to
keep an

organization's critical functions operating in case of disruptions,
either

long or short term in duration. The continuity planning process is
covered in

six steps:

Step 1 - Identify Mission- or Business-Critical Functions.

Step 2 - Identify Resources that support Critical Functions.

Step 3 - Anticipate Potential Contingencies or Disasters.

Step 4 - Select Continuity Of Operations Planning Strategies.

Step 5 - Document Continuity Of Operations Strategies.

Step 6 - Test and Revise Strategies.

Each of these steps is described in detail in the following paragraphs.

A. Step 1. Identify Mission- or Business-Critical Functions.

The definition of an organization's critical mission or business
function is

called a business plan. Because the development of the business plan
will be

used to support the continuity of operations planning process, it is

necessary, not only to identify critical missions and business
processes, but

also to set priorities and time criticalities for them. The system owner
is

responsible for ensuring the completion of the business plan and for

prioritizing the resumption, recovery or restoration needs for the

organization's critical functions. Because a fully redundant capability
for

each function is prohibitively expensive for most organizations, certain

functions will not be performed in case of a disaster. If appropriate

priorities have not been set, it could make a difference in the
organization's

ability to survive a disaster.

1\. Mission Statement. Government departments, divisions, and offices
generally

have a formal statement concerning the mission to be performed. These

statements may be contained in departmental policies or directives,
handbooks,

or public information guides. Regardless of the source, the criticality

determination process starts with an overall mission statement which

identifies what the office is responsible for doing. For example, as its

primary mission, an office or IT System within the United States Coast
Guard

(USCG) may be responsible for licensing the vessels for commercial and
charter

fishing (see Figure 1).

2\. Office Functions. The mission statement is usually a generalized

description of why an office exists. It does not describe what function
an

office performs to accomplish the mission. Using this same example, the

commercial/charter fishing boat office may be required to process
applications

for licenses, investigate and inspect the firms, develop and issue
regulatory

guidelines, etc. Special requirements affecting the performance of the

function or relating to the information involved (e.g., Privacy Act

protection) should also be noted.

Figure 1, Mission Statement Example

3\. Functional Activities Listing. The process continues by developing a
list

of all functions performed by the office in support of the mission. In

parallel with this listing, it is also necessary to identify those
functions

that require support from IT Systems, and the extent of that dependency
(i.e.,

is the function totally dependent on IT System support, is only some
portion

that can be quantified dependent on such support, or could the function
be

performed manually with little or no loss of efficiency). Any special

requirements affecting the performance of the function or relating to
the

information involved should also be noted. These could include the
sensitivity

of data, or whether there is a specific timeframe when data is more
critical

than other times.

Appendix A, Tab A contains an Office Mission/Functionality Matrix
Template

that is designed to aid in this definition process. A sample matrix,
which has

been filled in based on the USCG example given above, is contained in
Figure

2\.

4\. Criticality Matrix. The next element is the development of a
criticality

matrix. Criticality guidelines must be developed which identify those
office

functions that deal with aspects that are critical to any government
agency,

and the time frames that must be associated with those factors.
Developing a

matrix, similar to that used for determining sensitivity and protection

requirements in system security plans, is one approach to determining IT

System criticality. Most DOT offices and operating administrations are
not

involved with the more obviously critical factors, such as saving lives
or

national defense. They will have to develop an office-specific list of

critical functions. The primary objective is to identify only those
essential

functions that, if not performed, will cause the greatest loss to the
office

in terms of the inability to operate, the expenditure of additional
funds

(other than those directly associated with restoring the office after a

disaster), or embarrassment to the Federal Government, DOT or the
operating

administration.

In the event that there are no specifically identifiable critical
factors, the

COOP planner and senior office officials must develop a list of
criticality

guidelines that will assist in prioritizing all office functions. These

guidelines should permit each function to be evaluated in terms of the

importance of the function in accomplishing the mission of the office,
and how

quickly this function must be performed. The longer the function can do

without IT support, the less critical is the supporting information
system,

\-\-- hence criticality is a function of time.

Figure 2, Sample Office Mission/Functionality Matrix

Tab C in Appendix A contains a sample Office Function Criticality
Matrix. To

help illustrate the process, Figure 3 shows the Matrix filled out for
the USCG

example.

5\. Criticality Determination. The next part of the process is to
compare the

functional activities against the criticality determinations and
corresponding

time frames. In a COOP, functions that do not require IT support (e.g.,
the

deliberations of an adjudication board) are still critical. A COOP is

concerned with all essential functions and may go beyond those functions

requiring only IT processing. All office functions are compared against
the

criticality determinations and time factors, and against each other. The

result is a prioritized list of essential activities, based on
criticality,

and reflected in terms of the maximum time frame that these essential

functions are not performed before the office fails to accomplish its
mission.

In the COOP, functions that do not require ITsupport may be separately

identified by the COOP planner. The prioritized list of IT
system-supported

functional activities is then based on the time frame the supporting
system

can be unavailable due to lost, damaged or destroyed data and/or
hardware.

Figure 3, Office Function Criticality Matrix Example

This distinction has been added to account for situations in which

less-than-catastrophic damage to the primary site has occurred. The
matrix can

be further modified to identify specific systems, applications, and/or

databases if a function is supported by more than one, or if a given
system,

application, or database is more critical to the effective completion of
a

given function.

B. Step 2. Identify Resources That Support Critical Functions.

After critical missions and business functions are identified,
supporting

resources should be identified, as well as the timeframes in which each

resource is used, and the effect of unavailable resources on the
missions. It

is important to note that the COOP resources inventory must consist of
only

those physical resources and support services necessary for an office to

perform the essential parts of its mission. The COOP does not plan for
the

immediate or even eventual replacement of all existing resources at an

alternate site. Rather, it is intended to implement a viable and
effective

office in an alternate location for an undetermined period of time to
perform

only those functions essential to the mission.

In addition to precisely identifying the minimum levels of resources
required

to activate a temporary office, the resources inventory must also
identify who

is responsible for each category of items, where the existing items are

located (and if backup supplies already exist, where they are located
and in

what quantity), what and where is the source of replacement or
re-supply, and

in some instances, what is the cost and time frame for replacement. The

resources inventory is not a static document, even during development.
As COOP

planning progresses, preparatory actions will instigate the modification
or

expansion of certain inventory data.

Continuity of operations planning should address all the resources
needed to

perform a function, including:

1\. Human Resources. Human resources include both operational/support
personnel

and system users. Some functions require personnel with special
expertise or

training, while others require lesser skill levels.

2\. Processing Capability. Traditionally, contingency planning has
focused on

processing power. Although the need for data center backup remains
vital,

today\'s other processing alternatives are also important. Local area
networks

(LANs), minicomputers, workstations, and personal computers in all forms
of

centralized and distributed processing may be performing critical tasks.

3\. Automated Applications and Data. DOT information systems run
applications

that process data. Without current electronic versions of both
applications

and data, computerized processing may not be possible. If the processing
is

being performed on alternate hardware, the applications must be
compatible

with the alternate hardware, operating systems and other software
(including

version and configuration), and numerous other technical factors.

4\. Computer-Based Services. DOT uses many different kinds of
computer-based

services to perform its functions. The two most important are normally

communications services and information services. Communications can be

further categorized as data and voice; however, in many organizations
these

are managed by the same service. Information services include any source
of

information outside of the organization. Many of these sources have now
become

automated, including on-line government and private databases, the
Internet

and external EMail.

5\. Physical Infrastructure. Physical infrastructure elements include a
safe

working environment and appropriate equipment and utilities. This can
include

office space, heating, cooling, venting, power, water, sewage, other

utilities, desks, telephones, fax machines, personal computers,
terminals,

courier services, file cabinets, and many other items. In addition,
computers

also need space and utilities, such as electricity. Electronic and paper
media

used to store applications and data may also have specific physical

requirements.

6\. Documents and Papers. The performance of many DOT functions relies
on vital

records and various documents, papers, or forms. These records could be

important because of a legal need, or because they are the only record
of the

information. Records can be maintained on paper, microfiche, microfilm,

magnetic media, or optical disk.

Appendix B contains a Critical Resources Inventory Outline that may be
used to

assist in the identification of critical resources. Also see the
following

tables for a methodology of matrixing this information. As showing in
the

table the \"QTY 1, QTY 2, QTY 3, etc\" fields can be used to identify
the

quantity of personnel, services, supplies, equipment, etc. needed as the

criticality timeline continues. This will also aid in budgeting for a
period

of coverage to ensure that a percentage of the resources are available.

Supplies Worksheet

Item Description Color Model / Serial Number Unit Cost Qty 1 Qty 2 Qty 3

Qty 4 Qty 5 Total Needed Total Cost

0 \$ -

Software Requirements Worksheet

Make Version Unit Cost Qty 1 Qty 2 Qty 3 Qty 4 Qty 5 Total Needed Total

Cost

0 \$ -

Hardware Requirements Worksheet

Make Model Unit Cost Qty 1Qty 2Qty 3Qty 4Qty 5Total Needed Total Cost

0 \$ -

C. Step 3. Anticipate Potential Contingencies or Disasters.

Although it is impossible to anticipate everything that can go wrong,
this

step involves identifying a likely range of problems. Developing
scenarios can

help an organization to prepare a plan that addresses a wide range of
possible

mishaps. Scenarios should include small and large disruptions that
require

both short-term (contingency) and long-term (continuity) solutions.

D. Step 4. Select Continuity Of Operations Planning Strategies.

This step considers the use of contingency and continuity plans to
recover

needed resources. When alternative strategies are evaluated, current
controls

for preventing and minimizing losses should be considered. Because no
one set

of controls can prevent all losses in a cost-effective manner,
prevention and

recovery efforts should be coordinated. Risk assessment can also help

determine an optimal strategy. A contingency planning strategy normally

consists of five parts: prevention, response, resumption, recovery, or

restoration of services. Prevention refers to those measures taken to

forestall a disruption of service (e.g., preventive maintenance, virus

prevention, etc.). Emergency response encompasses the initial actions
taken to

protect lives and limit damage. Resumption refers to the steps taken to

continue support for critical functions. Recovery concerns the
re-activation

of a greater scope of business processes and services beyond the most

time-sensitive processes. Restoration is the return to normal
operations. The

longer it takes to restore normal operations, the longer the
organization will

have to operate in the resumption or recovery mode. The selection of a

strategy needs to be based on practical considerations, including
feasibility

and cost. Different categories of resources should be considered:

1\. Human Resources. During a major continuity plan implementation,
people will

be under significant stress and may panic. If the continuity plan is

implemented as the result of a regional disaster, their first concerns
will

probably be their family and property. In addition, many people will be
either

unwilling or unable to come to work. Additional hiring or temporary
services

can be used. However, the use of additional personnel may introduce
security

vulnerabilities. Whereas in the implementation of the contingency plan
can in

some cases be seamless and there could be no difficulty of a Human
Resource

nature.

Remember, continuity of operations planning, especially for an emergency

response, normally places the highest emphasis on the protection of
human

life.

2\. Processing Capability. For less serious contingencies, processing

capabilities can be restored from backups or original media, by
repairing

equipment components, or by purchasing new equipment. Federal agencies
have

the authority to issue Purchase Orders to quickly acquire needed
equipment and

supplies in limited quantities. This authority is usually limited
between

\$25,000 and \$50,000, but is sufficient to acquire \"off-the-shelf\"
hardware and

software. Essential hardware could be acquired by Purchase Orders in one
of

two ways: purchase of replacement or upgraded equipment and lease of
essential

equipment for a limited period of time. The outright purchase of
identical

replacement hardware is the most obvious use of the Purchase Order
option.

However, the purchase of upgraded equipment is a reasonable alternative,
given

the fact that the existing equipment may not be economically
salvageable. On

the other hand, the short-term lease of essential equipment to augment
or

temporarily replace existing equipment during salvage operations
provides a

cost-effective alternative. There is however a risk involved with the
leasing

of equipment that must be addressed in both the contingency and
continuity

plans. That risk is the fact that those systems must be thoroughly
scrubbed to

ensure the protection of information that has been stored or processed
on

these machines. Although these two options could offset the lack of
facilities

and equipment at the time of a disaster, they are subject to the
disadvantages

of high cost and long preparation time. In a widespread disaster, the

requirements for space, hardware, communications, etc., could
temporarily

exceed the demand. These two options must also be used in combination
because

neither provides for both facilities (to include associated utilities
and

communications) and equipment, furnishings, and supplies.

Also for less serious contingencies, planners should consider the use of
an

overall in-house backup strategy. In-house backup is the use of
under-utilized

facilities and/or additional equipment (i.e., older equipment still
on-hand

and/or new equipment awaiting installation) controlled by the affected

activity or by its superior or subordinate activities. In-house backup

maximizes the use of suitable space and equipment, or space and
equipment that

is capable of being upgraded in a very short period of time to support

continuity of operations activities. DOT activities are required to
identify

and make available under-utilized IT equipment to other agencies under
normal

conditions. Although not usually done with PCs/LANs, the principle is
similar.

This same equipment could be earmarked for use in a continuity of
operations

situation. Pre-determined backup equipment alternatives (e.g., leasing)
would

have to be included in the plan to allow for the fact that the in-house

equipment may not be available at the time of the disaster.

For a serious contingency or continuity event, however, the strategies
for

ensuring processing capability are normally grouped into five
categories:

\(a\) Hot Site. A hot site is a building already equipped with
processing

capability and other services. Operational standby facilities require a

subscription contract and charge various fees. Normally, a three or

five-year contract is negotiated and includes a specific hardware and

software configuration with detailed communications requirements, which
must

be updated whenever changes occur. Subscription fees are determined by
these

requirements. The reduction in costs for the minimum essential
capabilities

required by a COOP is not significant and may not be warranted for

continuity of operations. Another potential drawback for the IT user is
that

these services are relatively new and not widely dispersed. Therefore, a
Hot

Site facility may not be conveniently located.

\(b\) Cold Site. A Cold Site is a building for housing processors that
can be

easily adapted for use. Such a facility may be owned by DOT or a DOT

operating administration, owned by another government agency (e.g., DOD,

GSA, etc.), or Government-leased for one or more departments or
operating

administrations. In the event of a disaster situation, the affected

office(s), in conjunction with hardware vendors, acquires and installs
the

essential AIS hardware, software, and communications. Cold Sites are
more

practical for AIS-type operations since a shell facility may be owned by
DOT

or the facility can be virtually any office space with sufficient
electrical

power, communications line capability (installed or capable of being

installed during a disaster situation), and regular air conditioning.
AIS

hardware is more readily available, more easily shipped, and more easily

installed.

A Cold Site may also be supported by a special equipment contract (if
not

already in-place as part of a standard hardware maintenance agreement).

There are a number of hardware vendors who offer guaranteed delivery and

set-up within 24 hours. Although the maintenance costs are somewhat less

than an operational standby, they represent a continuing expense. For IT

activities, consideration should be given to leasing essential computer

equipment and peripherals to augment equipment salvaged from the primary

site or to temporarily replace essential hardware until the primary site
can

be restored without additional disruption to IT configuration. Leasing

eliminates the on-going maintenance costs of a special equipment
contract,

but does not provide for the guarantees that appropriate equipment will
be

available when needed or within required time frames. As described
earlier

leasing also creates the problem of data security, as special
precautions

must be taken to ensure that all data that has been stored or processed
on

the system has been removed from the leased equipment. This practice

requires more than a simple deletion of the data as deleted files can be

detected, identified and restored. The site availability time frame,
which

includes hardware, communications, and equipment installation, may not
meet

organizational or system requirements as set forth in the contingency or

continuity plans.

\(c\) Redundant Site. A redundant site is a site equipped and configured

exactly like the primary site

\(d\) Reciprocal Agreement. A reciprocal agreement is a formal agreement
that

allows two organizations to back up each other. The agreement is usually

with an external agency, for the two to provide backup AIS processing

support to one another in the event of a disruption in primary
processing

support. The external office, division, operating administration, or

department is not in the business of providing IT processing support,
but

agrees to provide reciprocal support in recognition of mutual backup

requirements.

Although low development and maintenance costs are the principal
advantage

to this alternative; consideration must be given to establishing an

agreement with an organization that will not be affected by the same

disaster. Reaching an agreement with another activity, such as a
counterpart

office in another division or operating administration, provides no

effective continuity of operations capability if that activity is
affected

by the same disaster. The activities establishing a mutual assistance

agreement should be geographically separated.

This does not preclude reaching an agreement with another DOT activity.

Satisfactory agreements can be reached between superior and subordinate

levels (e.g., DOT and one of its operating administrations) or between

equivalent levels (e.g., two operating administrations), so long as the

geographical separation of sites is achieved. This in-house arrangement

would mitigate operational/legal problems resulting from the failure of
one

party to execute the agreement because the aggrieved party could appeal
to a

common superior.

The biggest disadvantage of the mutual assistance agreement is that,
\"Their

disaster becomes your disaster.\" Many of the disadvantages noted above

identify areas of hardship and general inconvenience to both activities.

Without a specific system, site, and pair of organizations in mind, it
is

difficult to evaluate a mutual assistance agreement alternative
completely

and fairly.

Remember that mutual assistance agreements are not considered viable

solutions without a formal agreement outlining all conditions and signed
by

individuals in positions of authority to uphold the agreement.

\(e\) Hybrids. Any combinations of the above, such as having a hot site
as a

backup in case a redundant or reciprocal agreement site is damaged by a

separate contingency.

In addition to these five alternatives, another approach readily
available

to IT environments is to allow employees to work at home (telecommute).

Personally owned PCs and modem connectivity have become commonplace.
Even

limited use of this alternative would ease the continuity of operations

burden by reducing or eliminating the need to provide suitable office
space

and to acquire hardware and/or software assets. In addition to reduced

costs, it offers the advantage of immediate availability. Also, it can
be

thoroughly tested. However, there are disadvantages, too. Not all
employees

can be expected to have suitable hardware and/or software or modem

connectivity. Technical and maintenance support to privately owned
property

poses legal difficulties and limits sustainability, while information

security and anti-viral protection are significant problem areas.

Figure 4 presents a set of evaluation characteristics that may be used
to help

weigh the alternatives for handling Processing Capability.

Evaluation Characteristic Planning Considerations

Compatibility Hardware, software, and communications that are or would

have to be installed at the alternate site must be the same as or

compatible with original equipment supported.

Accessibility The alternate site must be readily accessible, but not so

close as to share the same disaster.

Reliability The alternate site must be capable of supporting the

operations of the affected office(s) 24 hours a day, seven days a week.

Maintenance for site equipment, hardware and communications should be

on-site or on-call.

Capacity The alternate site and facility/computer equipment must have

sufficient floor space, heating/cooling/power, communications lines, and

memory capacity to support the suite of equipment required.

Security The physical security at the alternate site must be sufficient

to protect the sensitivity of the information and data.

Time to prepare There must be sufficient time to prepare for the

disaster, including time to prepare/convert data and software, prepare

the site, prepare/store supplies, forms and documentation,

obtain/install power and communications circuits, and prepare and test

the COOP.

Support & assistance There must be on-site technical support and

assistance to set-up and configure the hardware, software, and

communications.

Cost Cost factors can be subdivided into three categories:

Preparation costs include cost of any equipment or LAN/WAN.

Maintenance costs include hardware, software, or telecommunications

maintenance/lease fees.

Execution costs are incurred in declaring a disaster and executing the

COOP, including rent, travel, and per diem.

Figure 4, Processing Capability Evaluation

3\. Automated Applications and Data. Normally, the primary contingency
and

continuity strategy for applications and data is regular backup and
secure

offsite storage. Important issues to be addressed include the frequency
of

backups, the frequency of offsite storage, and the manner of
transporting

backups. Office policy should require the AIS or LAN administrator to

maintain separate master copies of all operating system and specific

application program software, update these masters immediately upon

implementation of approved changes, and store these masters in a secure

off-site location, together with copies of all applicable hardcopy

documentation and operating manuals. A similar policy should require the

appropriate individual(s) to prepare backup copies of all electronic
files

on a regular (e.g., not less than weekly) basis, to maintain copies of
all

required references and hardcopy files, and to store the backup copies
in a

secure off-site location. In an AIS environment, the volume of

equipment/supplies to be stored is relatively small based on the nature
of

the media involved (diskettes and 8 mm cartridge tapes). The DOT Data
Center

makes provisions to store these types of materials in support of DOT

activities. This provides a ready solution for magnetic media. Hardcopy
data

could be stored on a permanent retention basis in local operating

administration, DOT, or general Federal storage facilities.

4\. Computer-Based Services. Communications is also a key discriminator
in

selecting an appropriate COOP alternative. Incompatible communications

and/or insufficient lines will disqualify a site or option. The COOP
planner

must ensure that adequate compatible communications are available at the

alternate site, or that they can be provided during a disaster
situation. If

not already present, an agreement with the communications vendor must be

negotiated. This agreement must cover all necessary voice, data, and
image

communications. Separate agreements must also be negotiated with
equipment

vendors for modems, facsimile machines, telephones, encryption devices
and

keys, if required.

Service providers may offer contingency services. Voice communications

carriers often can reroute calls to a new location, and data
communications

carriers can also reroute traffic. Local voice service may be carried
via

cellular phones. If one service is down, it may be possible to use
another.

Resuming normal operations may require rerouting of communications.

5\. Physical Infrastructure. Arrangements must be made for processing

capability support, office space, furniture, and more. If the COOP calls
for

moving offsite, procedures need to be developed to ensure a smooth

transition back to the primary operating facility or to a new permanent

location. A related alternative available to Federal agencies is the
U.S.

Government\'s procurement system. The General Services Administration
(GSA)

has the responsibility of acquiring additional office space on an \"as

required\" basis for Federal agencies, and the responsibility of
managing

standing contracts for goods and services. Because minimal space is
required

for continuity of operations activities, this capability permits fairly

rapid acquisition of space without the \"overhead\" costs of rents or

subscription fees.

6\. Documents and Papers. The primary contingency strategy is usually
backup

onto magnetic, optical, microfiche, or other medium and offsite storage.
A

supply of forms and other needed papers can be stored offsite. Backup

storage space should be located close enough to the primary site for

convenience in placing items into storage on a regular basis, but not so

close that it will be affected by the same disaster. On-site (i.e., same

office/building) storage is not acceptable.

E. Step 5. Document Continuity Of Operations Planning Strategies.

With continuity of operations strategies well defined, the next step is
to

create the COOP itself. The COOP needs to be written, kept up-to-date as
the

system and other factors change, and stored in a safe place. A written
plan is

critical during a continuity of operations event, especially if the
person who

developed the plan is unavailable. It should clearly state in simple
language

the sequence of tasks to be performed in the event of a contingency so
that

someone with minimal knowledge could immediately begin to execute the
plan. It

is generally helpful to store up-to-date copies of the COOP in several

locations, including any off-site locations, such as alternate
processing

sites or backup data storage facilities. A model COOP is contained
within

Appendix C of this Guide. The structure of the COOP includes:

Plan Overview -- consisting of an introduction, statement of policy,

objectives, scope, assumptions, recovery strategy and plan
administration

responsibilities.

Continuity Process Overview -- outlines the four major stages of the
process

(emergency response, resumption, recovery and restoration), including
the

central activities and objectives of each stage, and the relationships
among

stages.

Continuity Team Organization -- defines the specific organization set up
to

work towards survival and the resumption of time-sensitive business

operations. The teams associated with this plan represent office
functional

units and/or or support functions developed to respond, resume, recover
or

restore operations of the facility. Each team is comprised of
individuals

with specific responsibilities or tasks that must be completed to fully

execute the plan. Figure 5 presents a representative example of a
Continuity

Team Organization Structure.

Figure 5, Representative Continuity Team Organization Structure

Plan Maintenance -- including both scheduled and unscheduled
maintenance, as

well as a periodic re-evaluation process. Scheduled maintenance consists
of

quarterly reviews and updates as well as annual structured walk-through

and/or tactical exercises (as described in the Plan Exercise section
below).

The purpose of the plan review is to determine whether changes are
required

to strategies, tasks, procedures, the continuity organization, and

notification procedures. The majority of unscheduled maintenance
activities

occur as the result of major changes to service level agreements,
hardware

configurations, networks, production processing, etc. The Continuity
Plan

maintenance process should also include a periodic re-evaluation of the

minimum hardware capacity required to provide short-term response,

resumption, recovery and restoration capability. The re-evaluation
process

must address the capacity growth requirements associated with the
increase

of transaction processing volumes of the production application systems,
as

well as the addition of new systems to the production environment.

Plan Exercise -- consisting of the various types and scope of exercises

designed to test and evaluate the COOP. Exercises should be conducted
when a

major revision to the plan has been completed, when additional
production

systems are implemented, when significant changes in systems,
applications

and/or data communications have occurred, and when the preparedness
level of

continuity teams must be verified. Exercises may include structured

walk-throughs, tactical exercises, live production exercises,
simulations

and announced/unannounced exercises.

The details for plan execution reside in Appendices to the COOP itself.

These Appendices contain the specific data required by the various Teams
in

order to perform their designated roles during each stage of the
process.

Appendices include:

Priority Contact List -- including employee names and contact
information.

Employee/Contractor Notification List -- containing a directed list of
who is

to contact who regarding the communication of continuity information
(see

Figure 6).

Figure 6, Sample Notification List

Team Member Roster -- identifies the specific individuals belonging to
each

Team, and their contact information, as shown in Figure 7.

Team Task List with Dependencies -- consists of a detailed, step-by-step

listing of each task to be performed by the members of the various

continuity teams. Where a specific task must await action by a member of

another team, this is so noted, and the task/responsible individual is

identified. This area is key to the entire COOP. Figure 8 contains an

example of a portion of a Team Task List. Each task is also separately

identified by a unique number that identifies both the team and the
order of

execution. Additionally, the task sheets contain room to check off task

completion, and the expected/actual times to complete.

Enterprise Process Configuration -- lists, for each IT System or
Process, the

associated software, equipment, supplies, network Information and

responsible Teams, as illustrated in Figure 9.

Vendor Representatives -- contains a listing of all applicable vendor
contact

information, including local representatives and focal points within the

organization. An example is shown in Figure 10.

Figure 7, Team Member Roster Example

Location Information -- contains the location of all off-site storage,

alternate operating locations (hot or cold sites) record repositories,
etc.

Driving instructions and personnel focal point contact information is
also

included for each location.

Vital Records -- includes a listing of all necessary documents, manuals,

diskettes, CD-ROMs and all other media necessary to implementing the
COOP.

F. Step 6. Test and Revise Strategy.

A COOP should be tested in order to train personnel, and to keep the
plan in

step with changes to the environment. The extent and frequency of
testing will

vary among organizations and systems. There are several types of
testing:

1\. Review. This is a simple test to check the accuracy of the COOP. For

instance, a reviewer can check the accuracy of contact telephone
numbers,

building and room numbers, and whether the listed individuals are still
in

the organization.

2\. Analysis. An analysis may be performed on the entire plan or parts
of

it. The analyst may mentally follow the strategies in the COOP and look
for

flaws in the logic or process used by the plan's developers. The analyst
may

also interview functional managers, resource managers, and their staff
to

detect missing or unworkable pieces of the plan.

Figure 8, Team Task List Example

Figure 9, Enterprise Process Configuration List Example

Figure 10, Sample Vendor Representative List

3\. Simulation & Test. Simulation and test consists of various types and
scope

of exercises designed to test and evaluate the COOP. In the Structured

Walk-through, a disaster scenario is established, and the teams

\"walk-through\" their assigned tasks. This is a role-playing activity
that

requires the participation of at least the team leaders and their
alternates.

A Tactical Exercise is a simulated exercise, conducted in a \"war game\"
format.

All members of the continuity organization are required to participate
and

perform their tasks and procedures under announced or surprise
conditions. The

exercise monitor provides information throughout the exercise to
simulate

events following an actual disaster. In a Live Production application
system

exercise, an operating system is brought to live status on the alternate

processor(s), and the data communications network is switched to the
alternate

site. All resources, other than the computer and communications hardware

needed to support this exercise, must be retrieved from the off-site
storage

facility. A simulation requires the execution of notification, operating

procedures, the use of equipment hardware/software, possible use of
alternate

site(s), and operations to ensure proper performance. Simulation
exercises can

and may be used in conjunction with checklist exercises for
identification of

required plan modification and staff training.

Announced exercises are scheduled exercises generally involving actual

resumption of computer processing at the alternate computer facility.

Production processing is usually not interrupted, but may be planned for

actual resumption and validation at the \"Hot Site.\" This type of test
usually

involves the entire continuity organization, including selected users
along

with operations and technical staff. Unannounced exercises are surprise

technical exercises that require processing to be actually recovered at
the

alternate site. Production processing continues in parallel and is not

interrupted. This type of test generally involves only a small portion
of the

continuity organization and few, if any, users

To ensure that testing is performed in a cost-effective manner, while
still

accomplishing the objective of validating the COOP, a separate test
plan, with

specific scenarios and outlines of acceptable responses, should be
developed

and followed by the management representatives, such as the team
conducting

the test.

Regardless of the type of testing performed, documentation of the test
must be

forwarded to the ISSO and maintained on file within the organization
until

Senior Management or System Owners review the documentation.

Because the plan will become dated as time passes and resources change,

responsibility for keeping the COOP current should be specifically
assigned.

Maintenance of the plan can be incorporated into procedures for change

management so that upgrades to hardware and software are reflected in
the plan.

APPENDIX A: IT SYSTEM CRITICALITY QUESTIONNAIRE

A.1. GENERAL

A key aspect in the continuity of operations planning process is to
identify

what functions and AIS IT supporting systems are performed and to
determine how

critical these functions are to the overall mission. Information
sensitivity and

criticality are not the same. Not all functions are critical or critical

one-hundred percent of the time. An effective COOP will allow for these

situations by identifying all functions, establishing criticality
criteria, and

then prioritizing the functions and supporting AISIT systems. Only the
most

critical functions and systems (i.e., mission essential functions) are

considered in continuity of operations planning.

A.2. PROCEDURES

Sample forms for accomplishing the following procedures are attached as
Tabs A

and B to this Appendix.

A.2.1 Mission Statement: Enter the office mission statement provided by
the

senior official responsible for the overall operations of the affected
office.

(See Tab A.) Remember, this is a general mission statement, not a
listing of

office functions, i.e., why does this particular office exist?

A.2.2 Functional Activities Listing: List all of the functional
activities, as

identified by the senior office official and key end-users, that the
office

performs to accomplish the mission. (See Tab A.) Ensure that all
functions are

listed and a record of OAIS IT support and other special requirements is

developed.

A.2.3 Criticality Matrix: Development of the criticality matrix is a
two-part

process:

First, determine why any of the office functions are critical.

\- List key criticality factors or guidelines developed by the senior

office official.

\- Enter each function and supporting system, identified in the
Functional

Activities Listing, next to the appropriate criticality factor.

\- Determine, in terms of time (minutes, hours, days), how long the
system

supporting that function can be \"out of service\" before mission
failure

occurs.

\- If there are a number of similar functions and systems for the same

factor, consider weighting the factors. The total of factor weights will

determine the priority order of factors. The priority order of functions

will be determined by the time frames in which each must be
re-established.

Second, develop the final Office Function Criticality Matrix (See Tab
B.).

Enter individual functions in descending priority order based on their

criticality time frames. In an IT environment, it is necessary to
account

for less-than-catastrophic situations. Therefore, the time frames of the

loss, damage, or destruction of data and/or hardware must be considered

separately.

Third, determine which of the critical functions are absolutely
essential to

accomplishing the office mission. These functions and systems will be
the

only ones supported under the COOP.

MISSION STATEMENT:

Functional Activity IT

Support

Required IT

Dependency

Level (%)Special

Requirements

YES NO0-2526-

5051-

7576-

100 Sensitive

(Y/N)Periodic

(Time)

TAB A: OFFICE MISSION/FUNCTIONALITY MATRIX

CRITICALITY FACTORS/TIME FRAMES

FACTOR

FUNCTION TIME FRAME

I

M

M

E

D

I

A

T

E S

H

O

R

T

T

E

R

M M

E

D

I

U

M

T

E

R

M L

O

N

G

T

E

R

M C

O

N

T

I

N

U

O

U

S P

E

R

I

O

D

I

C

LIFE SAVING

NATIONAL

DEFENSE

PUBLIC SAFETY

LAW

ENFORCEMENT

FINANCIAL

MANDATED

EXTERNAL

SUPPORT

INTERNAL

SUPPORT

ROUTINE

ACTIVITIES

SPECIAL TASKS

OTHER

TAB B: CRITICALITY FACTORS/TIME FRAMES

FUNCTION CRITICALITY MATRIX

Functional

System/

Application Criticality Adverse

Situation

(Data/

Hardware)

HIGH

\- Hrs\*MEDIUM

\- Hrs\*LOW

\> Hrs\*

Lost

Damaged

Destroyed

Lost

Damaged

Destroyed

Lost

Damaged

Destroyed

Lost

Damaged

Destroyed

Lost

Damaged

Destroyed

Lost

Damaged

Destroyed

TAB C: OFFICE FUNCTION CRITICALITY MATRIX

APPENDIX B: IT SYSTEM CRITICAL RESOURCES INVENTORY OUTLINE

B.1 GENERAL

The COOP must provide for the re-establishment of only those office
assets

necessary to support essential operations. Determining the specific
resource

requirements begins with a critical review of existing resources.
Following the

inventory, the COOP planner, office senior official, and key end-users
must

determine the minimum resources required to establish a viable,
effective office

in an alternate location for an undetermined period of time.

B.2 INVENTORY PROCEDURES

There is no specific format for developing a critical resources
inventory. In

terms of physical property, the existing property inventory provides
most, but

not all, of the information required. There are key items of information
that

must be included in the resources inventory.

B.2.1 Facilities: The inventory must specify the current location(s) of
all

office functions and the minimum floor space required. (NOTE: COOP site
floor

space will not equal existing floor space, but must provide for the
minimum

essential requirement.) If the office receives routine support from
other

activities within the same division or operating administration (e.g.,
copier

support, mailroom), that will be required but will not be readily
available,

provisions for obtaining for this support must be taken into account.

B.2.2 Hardware: The inventory must provide a full description of all IT
hardware

and peripherals, a specific location, and a description of any special
features

or requirements. If known, the inventory should also provide replacement
cost or

original purchase/lease cost. Finally, the inventory must indicate the

criticality factor and time frame for each item, as well as the
replacement

source.

B.2.3 Software/Applications: The inventory must provide a full
description of

all IT operating system software and applications, specific
location/systems,

the individual responsible for the software, use or list of functions
supported,

source, replacement cost, and a description of backup procedures and
backup

storage location. The inventory must also indicate the criticality
factor and

time frame for each item.

B.2.4 Databases: The inventory must provide identifying information on
each

database, specify the owner and/or individual responsible, describe
backup

procedures and locations, and describe its use(s) and application(s)
supported.

The inventory must also indicate the criticality factor and time frame
for each

item.

B.2.5 Documentation: The inventory must provide a full description of
each item

of required documentation (including hardcopy information), identify the

individual responsible for the documentation, describe backup procedures
and

identify backup location(s), and denote if the document is critical to
office

operations.

B.2.6 Communications: The inventory must fully identify all
communications

networks (i.e., line identifiers, condition types, speed, types/periods
of

service, protocols, protection features, connectivity, and vendor). It
must also

indicate criticality and time frame for each circuit.

B.2.7 Environmental/Utilities Support: The inventory must identify and
describe

special environmental support equipment, all utilities connectivity to
include

backup and UPS power, and any special physical security provisions that
are

critical to essential operations. The description should include
technical

specifications, identification of vendor, replacement cost/time (if
known), and

indicate criticality in terms of AIS hardware support requirements.

B.2.8 Furnishings: The inventory must specify the type and quantity of
required

furnishings. (NOTE: Furnishings should be kept to the absolute minimum
in terms

of quantity and type.) It must identify replacement vendor(s) and
cost/time (if known).

B.2.9 Supplies and Forms: Special IT supplies and forms, as well as a
limited

quantity of routine office supplies, must be identified in the
inventory. The

inventory should describe the use of any special supplies and forms,
identify

the responsible individual, the location of both normal operating stocks
and

backup supply, description of the item, and vendor or resupplier.

B.2.10 Technical/Maintenance Support: The inventory must identify
special

technical and maintenance support minimum requirements, identify
suppliers,

identify and describe existing support agreements, and/or describe
procedures

and responsible individuals for obtaining needed support.

B.2.11 Personnel: Personnel are not normally listed in the resources
inventory

except in terms of staffing requirements. In developing a COOP, staffing
should

be kept to the absolute minimum necessary to perform essential
functions. Key

individuals are identified by name and assigned duties as part of the
continuity

of operations team.

Inventory format is at the discretion of the COOP planner. However, it
should

detail requirements as discussed above and should be inserted into the
COOP.

APPENDIX C: CONTINUITY OF OPERATIONS PLAN MODEL

CONTINUITY OF OPERATIONS PLAN (COOP)

FOR

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]

CITY, STATE/ZIP

EXECUTIVE SUMMARY

THE PURPOSE OF THE EXECUTIVE SUMMARY IS TO PROVIDE A BRIEF OVERVIEW OF
THE

CONTENTS OF THE PLAN AND TO BRING KEY DECISION POINTS TO THE ATTENTION
OF THE

SENIOR OFFICIAL. ENSURE THAT THESE DECISIONS ARE CLEARLY OUTLINED FOR
THE

DECISION MAKER WHEN THE DRAFT PLAN IS SUBMITTED FOR APPROVAL. FOLLOWING
APPROVAL

OF THE DRAFT PLAN, THESE DECISIONS WILL BE STATED AS FACTS.

The objective of this Continuity of Operations Plan (COOP) is to ensure
that the

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] has sufficient resources to continue
essential

operations should computer operations be affected by an adverse event
such as

fire, severe storm, power disturbance/interruption. This objective is

accomplished by detailing the preparatory actions necessary to support
the COOP

and by providing an action plan to be used should an adverse event
occur. To

reach this objective, the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] Continuity
of Operations Plan

will identify a team who will be activated during a catastrophic event
and will

be responsible for ensuring that Information Technology (IT) functions
are

operational under emergency conditions, until the primary site has
become

operational or the office relocates to an alternate site, in accordance
with the

applicable Disaster Recovery Plan.

The following functions and supporting IT systems are critical to the
mission of

the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]. These functions must become
operational within

NUMBER OF HOURS after a catastrophic event resulting in the failure of
the IT

systems or damage to \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] office areas:

· INSERT CRITICAL FUNCTIONS/SYSTEMS FROM OFFICE FUNCTION CRITICALITY
MATRIX

This COOP has tentatively identified TEMPORARY SITE as the temporary
office

site. Currently, the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] does not have
formal arrangements

in place for fulfilling its IT processing and communications
requirements at a

temporary site. Thus, should a disaster occur which would render the

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] primary facility inoperative, the
critical functions of

the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] would cease, and any chance of a
prompt resumption

of IT processing activity would be greatly diminished. The following IT
systems

and general resources are critical to the accomplishment of the
\[\[\[\[\[\[OFFICE

NAME\]\]\]\]\]\] mission:

INSERT SELECTED HARDWARE, SOFTWARE/DATABASE, AND COMMUNICATIONS
RESOURCES

FROM THE CRITICAL RESOURCES INVENTORY

It is recommended that:

· Consideration be given to identifying and formally designating a
temporary

site with compatible AIS processing and communications systems, and that
this

site be the TEMPORARY SITE, OFFICE, OPERATING ADMINISTRATION, AGENCY, OR
OTHER

LOCATION;

· Consideration be given to identifying and formally designating a
backup

storage facility for the secure storage of critical backup software and

database media, supporting documentation and files, and certain critical

supplies, and that this site be the IDENTIFY BACKUP STORAGE LOCATION;
and

Consideration be given to identifying, designating, and pre-positioning
the

critical software, databases, documentation, files, and supplies
identified in

this plan.

Table of Contents

PLAN OVERVIEW

INTRODUCTION

STATEMENT OF POLICY

OBJECTIVES

SCOPE

ASSUMPTIONS

RECOVERY STRATEGY

PLAN ADMINISTRATION

CONTINUITY PROCESS OVERVIEW

INTRODUCTION

EMERGENCY RESPONSE

INCIDENT ALERT

SAMPLE INCIDENT ALERT SCRIPT

NOTIFICATION GUIDELINES

OBJECTIVES

RESUMPTION

OBJECTIVES

COMMAND CENTER

RECOVERY

OBJECTIVES

COMMAND CENTER

RESTORATION

OBJECTIVES

CONTINUITY TEAM ORGANIZATION

OVERVIEW

ACTIVATION OF THE PLAN

TEAM ROLES AND RESPONSIBILITIES

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] MANAGEMENT

DATA CENTER RECOVERY MANAGEMENT

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] RESTORATION MANAGEMENT

REPORTING STRUCTURE

PLAN MAINTENANCE

INTRODUCTION

SCHEDULED MAINTENANCE

UNSCHEDULED MAINTENANCE

RESUMPTION AND RECOVERY CONFIGURATION

PLAN EXERCISE

INTRODUCTION

TYPE AND SCOPE OF EXERCISES

Structured Walk-Through

Tactical

Live Production

Simulation

Announced And Unannounced

When to Exercise

Responsibility for Establishing Exercise Scenarios

Exercise Scenarios

Exercise Evaluation

Reviewing Exercise Results

Schedule of Exercises

Education and Training

PLAN OVERVIEW

INTRODUCTION

This Continuity Of Operations Plan (COOP) for the \[\[\[\[\[\[OFFICE
NAME\]\]\]\]\]\] was

developed to assist in preventing events which might disrupt
\[\[\[\[\[\[OFFICE

NAME\]\]\]\]\]\] business operations and services, where possible, and
to minimize the

potential impact on the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] of any
unavoidable disruption.

This Plan recognizes the possibility that individuals may execute
resumption and

recovery operation with limited prior exposure to or knowledge of the
entire

plan in detail. Therefore, the plan\'s development focused on the
following

issues:

heightened awareness of management and employees

advanced preparation to minimize impact potential; and,

training in the execution of pre-defined and pre-assigned
responsibilities and

tasks.

The \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] COOP includes the strategies,
actions, and

procedures to resume the business operations and functions located at:

Department of Transportation (DOT)

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]

Office Address

This chapter of the Plan document contains a statement of management
policy. It

identifies the plan\'s objectives, its scope and limitations, the
assumptions

made during its development and guidelines for administering the plan's

contents.

STATEMENT OF POLICY

DOT and \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] recognize and acknowledge
that the protection of

its assets and business operations is a major responsibility to its
employees

and to the communities it serves. Therefore, it is a policy of DOT and

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] that a viable COOP be established
and maintained to

ensure high levels of service quality and availability. It is also a
policy of

DOT and \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] to protect life, information
and equipment,

respectively, in that order. To this end, procedures have been developed
to

support the resumption of time-sensitive business operations and
functions in

the event of their disruption at \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\].
\[\[\[\[\[\[OFFICE

NAME\]\]\]\]\]\] is committed to supporting service resumption and
recovery efforts at

alternate facilities, if required. Likewise, \[\[\[\[\[\[OFFICE
NAME\]\]\]\]\]\] and its

management are responsible for developing and maintaining a viable COOP
that

conforms to acceptable insurance, regulatory and ethical practices and
is

consistent with the provisions and direction of DOT strategic and
tactical

plans.

OBJECTIVES

The objective of a COOP is to assist \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]
in resuming

time-sensitive business

operations and services, its technology, and its support operations in a
timely

and organized manner to continue as a viable and stable entity.

The primary objectives of this COOP are:

To provide a tested vehicle which, when executed, will permit and
support an

efficient, timely resumption of the interrupted business operations.

To ensure the continuity of the services provided from the affected
facility

To minimize inconvenience and potential disruption to other business

functions.

To minimize the impact to DOT's public image and adverse financial
effects of

an outage.

This COOP also seeks to minimize the following:

The number and frequency of \'ad hoc\' decisions which must be made
following a

disaster.

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]'s dependence on the participation of
any specific

person or group of persons.

The need to develop and implement new procedures once the disaster has

occurred.

The loss of data and information, recognizing that some loss is
inevitable.

Confusion and exposure to errors, omissions and unnecessary duplication
of

effort.

The total elapsed time to execute response, recovery and restoration

processes.

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]

PLAN OBJECTIVES

With these general objectives in mind, the \[\[\[\[\[\[OFFICE
NAME\]\]\]\]\]\] COOP has been

developed to accomplish the following, specific objectives:

To resume technology operations and support for time-sensitive DOT
business

operations in the event existing technology processing has been rendered

inoperable at the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\].

To reduce the operational effects of a disaster on DOT time-sensitive
business

operations through a set of pre-defined and flexible procedures to be
used in

directing recovery operations.

To resume production processing of the most time-sensitive
\[\[\[\[\[\[OFFICE

NAME\]\]\]\]\]\] computer systems, network services and applications
within 7

calendar days following the disruptive event.

To resume production processing of less time-sensitive
\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]

computer systems and applications within 8 to 30 calendar days following
the

disruptive event.

To resume full processing capability, including test and development
work, for

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] technology and operations within 30
to 45 calendar

days following the event as permitted by the restoration effort.

To resume and maintain adequate service levels to DOT customers.

To provide a proper work environment for displaced staff while the

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] and its contents is being restored.

To ensure that normal \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] business
operations are restored

in a timely manner.

To provide \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] with a viable,
well-maintained plan.

SCOPE

The scope of this plan includes time-sensitive and less time-sensitive

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] business functions, automated
technology, and support

areas of \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] located at \[\[\[OFFICE
LOCATION\]\]\]. This Plan

will be activated in the event that the \[\[\[OFFICE LOCATION\]\]\] or a
portion of it

is involved in an emergency or is declared unusable for normal
operation.

This Plan addresses business resumption and recovery in a disaster
situation as

indicated above. It does not address building emergency and evacuation

procedures or on-site resumption and recovery procedures. Actions
related to the

physical restoration process, in terms of primary site restoration,
recovery

de-activation, migration and re-establishment of normal operations,

termination/shutdown of recovery operations at alternate sites and
post-recovery

operations are addressed in the tasks of the teams. This Plan was based
on DOT

management approval of those applications and associated support
functions

identified as time-sensitive. The time-sensitivity of the applications
and

services delivered from \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] was
documented during the

pre-planning process known as a business plan analysis. The business
plan

analysis identified the time-sensitive business operations, automated
technology

processes, time-sensitive support operations and tolerable outage
periods for

which and after which disruptions could result in significant losses to
DOT. The

resulting application recovery priorities on which this plan is based
are

documented in the report 'Computing Processes by Criticality' included
in the

plan's appendices.

ASSUMPTIONS

The purpose of this section is to define the assumptions that were made

in developing the plan for

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\].

Disaster: A disaster is considered to be any event that would render the

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] facility unusable or inaccessible
for a period of time

estimated to exceed 2 business days.

Worst-Case Interruption: \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] facilities
are totally

unusable or inaccessible and there is no salvageable equipment, data,

documentation, etc.

Less-Severe Interruption: Although the plan is designed for the worst
case,

the ability to resume operations from less serious interruptions is
inherent

within the plan because of the plan's structure by time-sensitive
application,

information system and support area.

Localized Emergencies: In circumstances involving a localized event
(i.e.

limited to

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]), equipment vendors and local
utility companies should

normally be able to install replacement computer and communications
hardware

and telephone circuits in \'x\' to \'x\' calendar days. This assumes
that

replacement service/equipment orders are placed on an \"emergency\"
basis at the

time of the event. It also assumes that \[\[\[\[\[\[OFFICE
NAME\]\]\]\]\]\] can quickly

obtain and prepare suitable alternate site(s) to serve as an interim or

temporary resumption and recovery centers for its business operations
and

information processing centers, in a period of 3 to 5 days.

Regional Emergencies: In the event of a regional emergency, such as an

earthquake or a tornado, the time to acquire the necessary computer
equipment

and data circuits could require weeks. This will be due to multiple

organizations contending for the same emergency resources and services.

Regional emergencies which cause wide-spread disruption of public
utilities

such as electricity, water and network services may also cause
additional

delays in re-establishing DOT \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]
business and technology

operations without pre-identified and pre-conditioned/contractual
alternate

backup sites.

Alternate Operating Sites: This plan assumes that \[\[\[\[\[\[OFFICE
NAME\]\]\]\]\]\] will

have access to and use of sufficient physical sites within the DOT
environment

to meet its application recovery time objectives. Sites currently
considered

eligible \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] temporary recovery
locations are listed in

the report 'Location Information' located in the plan appendices. The

pre-positioning of redundant equipment, environmental conditioning and
access

to the DOT WAN necessary to accomplish application recovery is addressed
in

\[Appendix ?\]

Plan Documentation: The level of documentation in the plan assumes and

requires that \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] management and staff
are familiar with

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] \'s business operations, its
automated technology and

the requirements of the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] COOP.

Available Personnel: Sufficient management and staff, familiar with and

trained in the procedures and tasks in this plan, will be available
subsequent

to the interrupting event t execute their recovery responsibilities and
to

support the restoration effort. \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]
personnel understand

that, following a major interruption of services/operations, it will not
be a

matter of \"business as usual\" but \"survival\".

Vital Records: All business documentation, files that would be necessary
for

resumption and recovery purposes are backed up and stored/located safely
away

from the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] using a rotation schedule
that minimizes data

loss.

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] Computer Data: All computer files
required to

implement resumption of the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] current
operating

environments, and/or that support time-sensitive business operations are

backed up daily. This information is rotated to a safe offsite location

according to a schedule that minimizes data loss and the effort to
reconstruct

production environments. The type of backups and the timing of the
off-site

rotation and retention are approved by DIT management and are considered

sufficient to minimize the re-entry/re-construction of data and the

recreation/forward recovery of files to current status.

Backup Storage Locations: All backup items for resumption and recovery
are

stored on-site and off-site or can be easily and quickly obtained or
created

from other identified sources. The backups stored on-site are in a
series of

fire resistant safes that are located within the \[\[\[\[\[\[OFFICE
NAME\]\]\]\]\]\] data

center boundaries. The backups stored off-site are in a secured location
that

is sufficiently distant from the primary site so they will be unaffected
by

most interrupting events. These stored backups are considered to be the
only

resources available to implement resumption. This plan assumes that the

locations (other than the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]) where
backups are stored

were not affected by the emergency incident/situation and can be
accessed by

DOT personnel.

Internal and External Contacts: All information necessary to complete
the

internal and external contacts quickly and accurately during resumption
is

documented and maintained in the plan.

Application Recovery Time Frames: The time frame in which each
time-sensitive

application and supporting computer/network system has been set by DOT

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] Management, is current with the
needs of \[\[\[\[\[\[OFFICE

NAME\]\]\]\]\]\]'s clients and is available within this plan. The
resumption of each

application is greatly dependent on the availability of
\[\[\[\[\[\[OFFICE

NAME\]\]\]\]\]\] personnel, its information files, and its access to the
IT systems

and data files. Actual time-frames for resumption and recovery may be

influenced by the availability of alternate operating sites, hardware
and

software, current backup files, and the reload time requirements of the
IT

System architectures.

RECOVERY STRATEGY

Loss of functionality at \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] will have a
significant impact

on application and data delivery throughout DOT. The \[\[\[\[\[\[OFFICE
NAME\]\]\]\]\]\]

COOP has been developed to respond effectively to a significant outage
by using

a pre-defined method for utilizing various facility, staff and technical

resources. This method, known as the recovery strategy, has been
selected to

help ensure that \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] will accomplish the
resumption and

recovery of business functions within stated time frames at required
levels of

service. Serous consideration has been given to selecting a recovery
strategy

that is workable as well as cost efficient. This Plan's recovery
strategy

anticipates the availability of other DOT/Federal Agency locations for
use as

alternate processing and network termination sites. (A prioritized list
of

eligible locations is provided in the 'Location Information' report in
the

Action Plan section of this document.) The sites were selected for their
ability

to support the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]'s technical
infrastructure requirements

while providing the best possible access to the DOT WAN. Selected
\[\[\[\[\[\[OFFICE

NAME\]\]\]\]\]\] continuity teams will relocate to the selected sites
and begin

preparing them for use as alternate processing locations should a
business

disruption require the activation of this plan. Where pre-positioned
equipment

and services are in place, \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] teams
will activate those

resources as soon as possible. Where additional equipment and other
services are

needed to upgrade a site to full utilization, these items will be
acquired and

installed on an emergency basis. Configuration details for current
\[\[\[\[\[\[OFFICE

NAME\]\]\]\]\]\] Nodes, Servers and network management device are
included in this

plan to help expedite this \"acquire time of disaster\" strategy as are
the

current inventory of DOT contracts for which emergency requisitions will
be

drafted (see Action Plan Appendices).

PLAN ADMINISTRATION

The scope of administration duties and responsibilities includes, but is
not

limited to, the continued endorsement of the plan through the mandatory,

documented review of the plan by \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]
management and team

members, on no less than an annual basis. A report on the plan\'s
administration

is to be presented/submitted to DOT Sr. Management annually or as
otherwise

required. The \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] ISSO is responsible
for the administration

of the plan. The ISSO will ensure that DOT and \[\[\[\[\[\[OFFICE
NAME\]\]\]\]\]\] standards

and procedures are developed to address plan administration needs. The
ISSO will

also include any relevant, related documentation in the Plan. As
custodian and

administrator of the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] COOP, the ISSO
must have a thorough

knowledge of all Plan contents. As a further safeguard, the ISSO should
never be

the sole person in the organization with extensive knowledge of the
structure

and contents of the Plan; an alternate COOP Coordinator should be a full

participant in all Plan maintenance and exercise activities.
Responsibility for

maintaining specific sections of the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]
COOP resides with

each Team Leader in accordance with the Team\'s objectives and
functional

responsibilities for Response, Resumption, Recovery and Restoration.
Team

Leaders must ensure compliance with these documented procedures for Plan

administration. Each \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] employee,
regardless of their role

as a team member, is responsible for providing updated personal contact

information to the ISSO as changes occur.

Each \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] employee is responsible for the
maintenance of

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]'s capability to respond and resume
operation following a

disaster. Some individuals will have more direct responsibility than
others

will. Nevertheless, each individual must be aware of the necessity for
the

preservation of such a continuity capability and must perform to the
utmost to

ensure that the response, resumption, recovery or restoration capability
is

truly viable. Should a plan review necessitate changes or updates, the
ISSO is

responsible for implementing the changes and issuing updated Plan
documentation.

Individuals in responsible management positions will be called upon
periodically

to provide information necessary for maintaining a viable plan and an
exercised

continuity capability.

CONTINUITY PROCESS OVERVIEW

INTRODUCTION

This section outlines the four major stages of the continuity process as
it

applies to this plan. It

describes the central activities and objectives of each stage and the

relationships among stages. Actual circumstances of the business
interruption or

disaster will determine whether a particular stage is initiated and how
long it

will take to complete. This section provides guidelines and explains
continuity

process. The information needed to implement each stage is located in
the Action

Plan section of this document.

EMERGENCY RESPONSE

Following the notification of the emergency incident or situation, a
team of key

\[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\] personnel, the Assessment team, will
first assemble at

the incident site and immediately begin to

assess and evaluate the altered business environment for DOT
\[\[\[\[\[\[OFFICE

NAME\]\]\]\]\]\].

The primary objectives of the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]
Assessment team are:

To establish an immediate and controlled DOT presence at the incident
site;

To conduct a preliminary assessment of incident impact, known injuries,
extent

of damage, and disruption to the \[\[\[\[\[\[OFFICE NAME\]\]\]\]\]\]'s
services and

business operations;

To notify the \[\[\[OFFICE NAME\]\]\] Management team;

To determine if and/or when access to the \[\[\[OFFICE NAME\]\]\]
facilities will be

allowed; and

To provide the \[\[\[OFFICE NAME\]\]\] Management team with the facts
necessary to

make informed decisions regarding subsequent recovery activity.

It must be noted that response to an emergency does not necessarily or

automatically translate into the declaration of a disaster and the

implementation of a full resumption operation.

Activation of the \[\[\[OFFICE NAME\]\]\] disaster recovery portion of
the COOP

requires significant expenditures of time, personnel and financial
resources.

The \[\[\[OFFICE NAME\]\]\] Management team will determine whether or
not the

expenditure of resources are warranted and to what extent they are
justified

based on the information and recommendations provided by the Assessment
Team.

Refer to the Action Plan portion of this document for contact lists,
team

assignments, and checklists of specific tasks to be performed. The
flowchart on

the following page provides a graphical overview of the Emergency
Response

process.

Figure 1: Emergency Response Process

INCIDENT ALERT

Initial notification of an incident or situation is expected to come
directly

from a \[\[\[OFFICE NAME\]\]\] staff member. Other potential sources of
incident

notification might be the police, the fire company, security service,
the news

media, etc. In any case, if you are the first employee to become aware
of an

emergency situation at the \[\[\[OFFICE NAME\]\]\], it is important that
you contact

the members of the \[\[\[OFFICE NAME\]\]\] Assessment team about the
emergency

incident as soon as possible. They will begin emergency response
activities and

alert the \[\[\[OFFICE NAME\]\]\] Management team. Initial attempts to
contact the

\[\[\[OFFICE NAME\]\]\] Management teams should not exceed two hours.
After that time,

the Assessment Team leader should list the names of individuals could
not be

contacted and assign someone else to continue the notification process
and/or to

temporarily assume the individuals assigned responsibilities.

SAMPLE INCIDENT ALERT SCRIPT

The following format is suggested for all individuals
receiving/providing

notification of an emergency incident or situation:

If you receive a call notifying you of an emergency incident or
situation,

write down the message. Repeat the message back to the caller to verify
its

accuracy.

Request that the individual making the notification meet the
\[\[\[OFFICE NAME\]\]\]

Assessment Team at the incident site. Provide an estimated time of
arrival.

If you are the first person notified, contact \[\[\[OFFICE NAME\]\]\]
Facilities

Management to verify the reported emergency incident or notification.

Notify the \[\[\[OFFICE NAME\]\]\] Assessment Team. Refer to the Action
Plan for

contact information.

Read the information received to each person you call, briefly stating
the

nature of the problem and the time of the reported incident. Do not
speculate

on injuries or damage to avoid possible confusion.

Instruct each person you contact to proceed to the pre-determined
emergency

meeting site or other designated location. Determine each person\'s
estimated

time of arrival.

Instruct all individuals contacted to avoid making comments to news
media,

customers, vendors, etc. An official DOT-designated spokesperson will
provide

the news releases to the press, news media, etc.

Give instructions to each contacted individual as to what is expected of
them,

(e.g. report to the emergency response site, stand by for further

instructions, etc.). Activate only the employees needed immediately and

prepare a notification list and contact schedule for other individuals
if

required.

Maintain a record of all calls attempted and completed. Report the

notification results to the WWC Management Team

NOTIFICATION GUIDELINES

All Team Leaders and Team Members have been assigned call tree
responsibilities

that should

be followed during the emergency notification. The \[\[\[OFFICE
NAME\]\]\] Management

Team will determine if DOT sites with time-sensitive functions should be

notified and a disaster situation declared based on the preliminary
assessment

of the situation. If the emergency notification procedures are
initiated, each

Team Leader will be responsible for contacting their Alternate Team
Leader and

Team Members with specific instructions. If the Team Leader is not
available,

the Alternate Team Leader will assume the Team Leader's
responsibilities. In the

event the Alternate Team Leader is also not available, the \[\[\[OFFICE
NAME\]\]\]

Management Team will assign someone to complete the notifications until
the

Primary or Alternate Team Leaders become available and resume their

responsibilities. It is important that all key personnel be notified of
the

disaster as soon as possible to begin business resumption operations.
The

Employee/Contractor Notification List has the telephone numbers for the

essential personnel to be notified in predetermined sequence.

OBJECTIVES

The objectives for the continuity organization during emergency response
are as

follows:

Complete emergency response, notification and mobilization duties as
directed

by the \[\[\[OFFICE NAME\]\]\] Management Team.

Ensure the \[\[\[OFFICE NAME\]\]\] Management Team is contacted and
appraised of

situation\'s status and activity.

Obtain reports of personnel injury or related matters from Facilities or

Security and/or local authorities.

Perform assessment(s) and evaluation(s) until the extent of impact or
damage

can be determined.

Document the results of the preliminary assessment(s) and evaluation(s)
and

submit the report to the \[\[\[OFFICE NAME\]\]\] Management Team with

recommendations to terminate the emergency response activities or
activate

subsequent plan operations.

Terminate or expand/extend the operation as directed by the \[\[\[OFFICE
NAME\]\]\]

Management team.

RESUMPTION

During the Resumption stage of the continuity process, \[\[\[OFFICE
NAME\]\]\] will

use its pre-defined alternate sites to reestablish processing and
network

capability for the most time sensitive DOT applications. The
\[\[\[OFFICE NAME\]\]\]

Management Team will initiate this plan if they determine that the
interruption

is significant enough to warrant its activation. Note that resumption
activities

may be executed concurrently with emergency response actions.

Key elements of the resumption phase include:

Establishing and organization a Command Center from which to manage
resumption

activities.

Activating and mobilizing the continuity teams needed resume
time-sensitive

application restoration.

Evaluating alternate site equipment and network service for the
necessary

enhancements to support time-sensitive application recovery.

Mobilizing and activating the support teams needed to support
enhancement and

use of the alternate site(s).

Notifying and informing \[\[\[OFFICE NAME\]\]\] clients and DOT
Management of the

situation.

Alerting employees and close contractors not assigned to the continuity

organization, vendors and other key organizations to the situation and
the

their role during resumption and recovery.

Once mobilized, the Support teams will be instructed in their reporting
and

action requirements. The necessary site assessments, evaluations and the

initiation of salvage operations will be completed once the Command
Center is

established. Additional alerts to supporting vendors, management and
customers

will also be conducted from the Command Center.

Based on the information/recommendations provided by the \[\[\[OFFICE
NAME\]\]\]

Assessment & Salvage team, the \[\[\[OFFICE NAME\]\]\] Management team
will determine

whether or not the expenditure of the above resources are warranted, to
what

extent they are justified, and what actions will be taken.

OBJECTIVES

The objectives that will become the major focus of the Resumption stage
are:

To prepare for and/or implement the procedures necessary to facilitate
and

support the resumption process and subsequent restoration operations, as

required.

To mobilize and activate the continuity teams responsible for
reactivating

critical applications.

To alert employees, vendors and other internal and external individuals
and

organizations.

To begin implementing procedures to re-establish time-sensitive
processes and

applications. This may include relocating to a temporary facility,

re-establishing communications at an alternate site, etc.

COMMAND CENTER

A Command Center headquarters will be established if management decides
to

continue and escalate situation from emergency response to resumption

operations. The site for the Command Center headquarters site should be

identified in advance. Initial activities performed at the Command
Center are

described below:

If the \[\[\[OFFICE NAME\]\]\] facility can be accessed, further
assessments and

evaluations of the on-site conditions, the damage impact and extent of
the

emergency incident/situation will be completed.

Use of the command center may be confined to management meetings and the

cancellation of the resumption operation if the facility (e.g., work
areas,

fixed assets, files, equipment, voice communications, etc.) are
unaffected and

the emergency incident/situation problems can be resolved without major
impact

to service delivery.

If the information about the emergency incident/situation problems is

inconclusive, the command center will be used as a meeting site until
the

assessments are completed.

If the emergency incident/situation is such that the resumption
operation

needs to be continued or further escalated, and/or a disaster declared,
the

command center should be organized and the appropriate support and
resumption

teams notified and activated as required.

RECOVERY

The Recovery stage of the continuity process concerns the re-activation
of a

greater scope of business processes and services beyond the most
time-sensitive

processes. \[\[\[OFFICE NAME\]\]\] Management will initiate recovery
stage operations

if the estimate of total outage indicate the need to expand service
delivery

using alternative locations and resources. If, for example, the impact
on the

\[\[\[OFFICE NAME\]\]\] facility is expected to take more than 30 days
to resolve, the

recovery stage may be initiated at alternative sites and the appropriate

resources devoted to those applications. Alternatively, if it is
estimated that

15 days would be needed to restore \[\[\[OFFICE NAME\]\]\] to full
function, \[\[\[OFFICE

NAME\]\]\] Management might initiate a parallel effort to resume less

time-sensitive operations at \[\[\[OFFICE NAME\]\]\], while planning the
migration of

resumption activities from the alternate site to the \[\[\[OFFICE
NAME\]\]\] facility.

Consequently, recovery, resumption and restoration stage activities may
be

conducted with some parallelism as dictated by the situation.

OBJECTIVES

The objectives for recovery stage operations include:

Maintaining a Command Center, which provides sufficient support for
resumption

and recovery operations.

Mobilizing and activating additional continuity teams to facilitate the

recovery of less time-sensitive business operations.

Maintaining an adequate level of Support team coverage to support all
business

operations.

Maintaining an adequate level of technology team coverage to sustain

information processing service demand as they grow in scope.

Maintaining communication with the continuity organization, clients and
senior

management.

COMMAND CENTER

The level of support maintained at the Command Center headquarters
during

recovery will be determined by the \[\[\[OFFICE NAME\]\]\] Management
team based upon:

the scope of the disaster,

the number of business operations and/or applications affected,

the level of support required for the recovery of business operations;
and

the perception of on-going risks and/or exposures.

RESTORATION

When local officials allow access to the building, the \[\[\[OFFICE
NAME\]\]\]

Management team will initiate the Restoration phase of this plan. The

Restoration stage builds on the assessments performed in the emergency
response

stage with the goal of returning the impacted facility to its
pre-disaster

capabilities. In circumstances where the original facility was assessed
as

beyond repair, this stage will involve the acquisition and outfitting of
new

permanent facilities.

The restoration process will include the assessment of:

environmental contamination of the affected areas;

structural integrity of the building; and

the damage to furniture, fixtures and equipment.

Restoration will begin in earnest when solid estimates of contamination,

structural damage and asset loss can be obtained and personnel resources
can be

dedicated to the management and coordination of the process. This phase
may be

executed sequential to, or concurrent with, the Resumption and/ or
Recovery

stages.

OBJECTIVES

In addition to maintaining a Command Center that provides sufficient
support for

resumption and restoration operations, objectives of the Restoration
stage are

to:

maintain an adequate level of support team coverage to support all
business

operations,

maintain an adequate technology teams coverage to sustain information

processing operations,

maintain communication with the continuity organization,

clean and/or decontamination of the building,

repair and/or restore the building or construct/acquire of a new
facility,

replace the contents of the building and,

coordinate the relocation and/or migration of business operations,
support and

technology departments from temporary facilities to the repaired or new

facility.

CONTINUITY TEAM ORGANIZATION

OVERVIEW

In the event of a disaster, the normal organization of DOT \[\[\[OFFICE
NAME\]\]\]

will shift to that of the continuity organization. Department will shift
from

the current organizational, \"business as usual\", structure to an
organization

working towards survival and the resumption of time-sensitive business

operations. The teams associated with this plan represent \[\[\[OFFICE
NAME\]\]\]

functional units and/or or support functions developed to respond,
resume,

recover or restore operations of the \[\[\[OFFICE NAME\]\]\] facility.
Each team is

comprised of individuals with specific responsibilities or tasks that
must be

completed to fully execute the plan. A primary and alternate team leader
who is

responsible to the plan owner leads each team. Each team is a sub-unit
of the

continuity organization. Each team is structured to provide dedicated,
focused

support, in the areas of its particular experience and expertise, for
specific

response, resumption and recovery tasks, responsibilities, and
objectives. A

high degree of interaction among all teams will be required to execute
this

plan. Each team\'s eventual goal is the resumption/recovery and the
return to

stable and normal business operations and technology environments. Each
team

leader will report status and progress updates its management team
throughout

the continuity process. Close coordination must be maintained with
\[\[\[OFFICE

NAME\]\]\] Management and each of the other teams throughout the
resumption and

recovery operations.

The primary responsibilities of the continuity organization are:

To protect employees and information assets until normal business
operations

are resumed.

To ensure that a viable capability exists to respond to an incident.

To manage all response, resumption, recovery and restoration activities.

To support and communicate with DOT staff and other locations within the

enterprise.

To accomplish rapid and efficient resumption of time-sensitive
technology and

business operations.

To ensure all insurance and regulatory requirements are satisfied.

To exercise impact resumption and recovery expenditure decisions.

To streamline the reporting of resumption and recovery progress between
the

teams and both \[\[\[OFFICE NAME\]\]\] and DOT Management.

During Emergency Response, the primary responsibilities of the
continuity

organization are:

To establish an immediate and controlled company presence at the
incident site

To conduct a preliminary assessment of incident impact, known injuries,
extent

of damage, and disruption to the enterprise's services and business

operations.

To determine if and/or when access to the Wilton Woods facility will be

allowed.

To provide Executive Management with the facts necessary to make
informed

decisions regarding subsequent resumption and recovery activity.

During Resumption, the primary responsibilities of the continuity
organization

are:

To establish and organize a control center for the resumption
operations.

To notify and appraise team leaders of the situation.

To mobilize and activate the operations teams necessary to facilitate
the

resumption process;

To alert employees, vendors and other internal and external individuals
and

organizations.

During Recovery, the primary responsibilities of the continuity
organization

are:

To prepare for and/or implement procedures to facilitate and support the

recovery of less time-sensitive business operations.

To mobilize additional continuity teams and support organizations as
required.

To maintain an information flow regarding the status of recovery
operations

among employees, vendors and other internal and external individuals and

organizations.

During Restoration, the primary responsibilities of the continuity
organization

are:

To manage salvage, repair and/or refurbishment efforts at the affected

facility.

To prepare procedures necessary to the relocation or migration of
business

operations to the new or repaired facility.

To implement procedures necessary to mobilize operations, support and

technology department relocation or migration.

To manage the relocation/migration effort as well as perform employee,
vendor,

and customer notification before, during and after relocation or
migration.

ACTIVATION OF THE PLAN

Activation of FCPS DIT plan will be executed when an emergency occurs
that

necessitates a response beyond the scope of standard daily operating
procedures.

Only the following selected personnel may activate this entire plan, or
any

phase thereof, and/or declare a disaster situation for DOT \[\[\[OFFICE
NAME\]\]\].

The \[\[\[OFFICE NAME\]\]\] Management team will decide whether or not
to activate the

Plan and/or declare a disaster. Their decision will be based on a
preliminary

assessment of the business interruption incident, including any physical

impairment to the facility. Pending their decision, emergency
notification of

DOT \[\[\[OFFICE NAME\]\]\] personnel will be initiated and the entire
plan, or any

phase thereof, will be activated, as directed.

Technology teams focused on restoring data center based applications
will be

activated only as directed by the \[\[\[OFFICE NAME\]\]\] Management
team. Each team

consists of unique procedures, tasks, contact and resource information.

Applications will be restored according to established priorities.

\[\[\[OFFICE NAME\]\]\] unit restoration teams will be activated only as
directed by

the \[\[\[OFFICE NAME\]\]\] Continuity Management team based on the
impact of the

disruption. Business unit restoration priorities will be established in

response to the disruption. Business unit staff will focus on supporting
data

center and application recovery priorities. Team procedures, resources
and

procedures are included along with specific business unit attachments
(e.g.

resource and notification information) and action tasks.

TEAM ROLES AND RESPONSIBILITIES

Following the Response phase of the plan, \[\[\[OFFICE NAME\]\]\] has
organized into

teams to execute its resumption and recovery activities on behalf of
DOT. To

accomplish the tasks assigned, each team will draw upon the expertise of

supporting organizations both internal and external, as necessary. This
section

of the plan identifies the major groups of teams required to accomplish

recovery. Each team has a minimum of a leader and one or more members

representing the skills appropriate to the team's role. Team
leaders/alternates

must be thoroughly familiar with the responsibilities not only of their
team,

but also of all the teams with which they must interact. A detailed list
of

teams and their current team members are located in the Action Plan.

The roles and responsibilities of each major group of teams are outlined
below.

\[\[\[OFFICE NAME\]\]\] MANAGEMENT

Approve the activation of the plan or the declaration of a disaster.

Approve expenditures as required.

Coordinate with DOT Management on the issuance of related news releases
to the

press and media.

Monitor all activities with the Recovery and Restoration Management
teams.

Provide executive management direction and counsel to activated teams as

required.

Coordinate all personnel matters and issues involving employee
fatalities and

injuries and notifications to employees\' families and dependents with
DOT

management. This may also include professional counseling and financial

support for employees.

Review progress and status with DOT Management.

Manage the resumption and recovery of all \[\[\[OFFICE NAME\]\]\]
business

operations and service delivery.

Establish and organize a business resumption headquarters at an
alternate

site. Organize the business resumption Command Center.

Direct and support team leaders. Make assignments, as appropriate.

Ensure that a damage assessment and salvage operation is conducted at
the

primary site.

Control the activation of the business resumption procedures.

Coordinate the eventual restoration/relocation of the primary site.

Report resumption and recovery progress to DOT Management.

DATA CENTER RECOVERY MANAGEMENT

Contact key personnel required for resumption of time-sensitive
functions.

Alert all personnel and instruct them to report to their designated
areas, as

required.

Perform tasks to resume time-sensitive functions, as required.

Work with support teams to obtain support required for service delivery.

Report the status of resumption activity to the \[\[\[OFFICE NAME\]\]\]
Management

team.

Manage all administrative activities associated with the resumption and

recovery operations.

Notify alternate backup sites and/or vendors of disaster declaration.

Identify and coordinate procurement for equipment and services for
alternate

site installation.

Identify and retrieve all backup files from off-site storage.

Request assistance to establish data and telecommunications if
necessary.

Execute IT Systems resumption procedures.

Manage IT Systems operations at the alternate and primary sites if
necessary.

\[\[\[OFFICE NAME\]\]\] RESTORATION MANAGEMENT

Coordinate salvage and/or reconstruction of the \[\[\[OFFICE NAME\]\]\]
facility if

appropriate.

Coordinate the acquisition and outfitting of a new permanent site if
necessary

Identify and coordinate procurement for equipment and services for the

permanent site.

Work with DOT support teams to obtain required services to restore and
outfit

a permanent \[\[\[OFFICE NAME\]\]\] data center and office location.

Manage preparation of a migration plan from the alternate site to the

permanent site.

Coordinate migration and move-in logistics with the \[\[\[OFFICE
NAME\]\]\]

Management, Data Center Recovery teams and with DOT support services.

REPORTING STRUCTURE

The following chart is a graphic representation of the reporting
structure for

the \[\[\[OFFICE NAME\]\]\] continuity organization that reflects the
overall team

organization and reporting structure that will be employed during
response,

resumption, recovery and restoration processes.

\[INSERT \[\[\[OFFICE NAME\]\]\] CONTINUITY ORGANIZATION HERE\]

PLAN MAINTENANCE

INTRODUCTION

COOP maintenance procedures are divided into two general categories:
scheduled

and unscheduled. Scheduled maintenance is time-driven, where unscheduled

maintenance is event-driven.

SCHEDULED MAINTENANCE

Scheduled maintenance consists of quarterly reviews and updates as well
as

annual structured walk-through and/or tactical exercises (as described
in the

Plan Exercise section of this document). The purpose of the plan review
is to

determine whether changes are required to procedures, the continuity

organization, and notification procedures. The ISSO is responsible for

initiating scheduled maintenance activities in consultation with the
\[\[\[OFFICE

NAME\]\]\] Management Team. The ISSO shall initiate quarterly continuity
plan

reviews in the X week of the Y month of each quarter. He/she shall
notify all

continuity organization team leaders and alternate team leaders to
review the

response, resumption, recovery and restoration task lists, contact
information

and procedures for changes that may be required. Other DIT staff members
may be

invited to satisfy the needs of a specific review session. The reviews
address

events that have occurred within each team\'s area of responsibility
that may

affect the response, resumption, recovery and restoration capability.
Teams

shall submit required changes to the ISSO not later than the end of the
X week

of the Y month of each quarter. The ISSO shall incorporate all changes
to the

plan, distribute updated copies of the plan.

UNSCHEDULED MAINTENANCE

Certain maintenance requirements are unpredictable. The majority of
unscheduled

changes occur as the result of major changes to service level
agreements,

hardware configurations, networks, production processing, etc.

Examples of items that may trigger the need for unscheduled maintenance
include:

Changes in data processing architectures, hardware, or environmental
changes

Major changes in operating system(s) or utility software programs

Major changes in the design of a production database

Major changes in communications, systems network design or
implementation

Changes in off-site storage facilities and methods of cycling items,
etc.

Improvements or physical changes to the current computer center
structure

Changes in the business or operating environment

Enterprise organizational changes that effect the continuity teams

New application systems development

Discontinuation of an application systems from processing schedules

Transfers, promotions or resignations of individuals on the emergency

notification list or continuity organization teams

Significant modification of basic functions, data flow requirements, or

accounting requirements within an application system

The ISSO must be made aware of all changes to the COOP resulting from

unscheduled maintenance. The ISSO shall then notify all continuity
organization

team leaders and alternate team leaders to review the plan for changes
that may

be required as a result of the item that has triggered the review. Team
leaders

will submit actual change data to the ISSO. The ISSO will team up with
the

person submitting the change and either update the COOP or assign the
update

responsibility to the affected continuity team(s). Cross-team
coordination

should be completed within two weeks of the review. Once this is done,
the ISSO

is responsible for any required updates to the plan, which result from
the

review. The ISSO shall print hard copies of the plan, and distribute
copies.

RESUMPTION AND RECOVERY CONFIGURATION

The Continuity Plan maintenance process should include a periodic
re-evaluation

of the minimum hardware capacity required to provide short-term
response,

resumption, recovery and restoration capability. The re-evaluation
process must

address the capacity growth requirements associated with the increase of

transaction processing volumes of the production application systems, as
well as

the addition of new systems to the production environment. Based on the
existing

configuration and requirements, it is assumed that the most effective

configuration for supporting long-term recovery and restoration will be
the

installation of the computer hardware required to support normal or
near-normal

levels of processing in a temporary computer center. Special attention
must be

paid to ensure continuing compatibility of existing equipment with that
which is

installed at the alternate site.

PLAN EXERCISE

INTRODUCTION

Documentation and periodic reviews of the \[\[\[OFFICE NAME\]\]\]
Continuity Plan are

reassuring. However, proof and confidence that the plan will work only
results

from completion of a successful exercise of the tactical strategies and

procedures. Exercises of the \[\[\[OFFICE NAME\]\]\] Continuity Plan are
designed to

determine:

The state of readiness of the continuity organization to respond to and
cope

with a disaster involving the data processing resources.

Whether backed up data and documentation stored off-site are adequate to

support the resumption business operations

Whether the inventories, tasks, and procedures are adequate to support
the

resumption of business operations

Whether the WWC Continuity Plan has been properly maintained and updated
to

reflect the actual resumption, recovery and restoration needs

TYPE AND SCOPE OF EXERCISES

A comprehensive program of exercises varying in scope and level of
detail will

help ensure the effectiveness of the \[\[\[OFFICE NAME\]\]\] Continuity
Plan. Examples

of the types of exercises that may be incorporated in \[\[\[OFFICE
NAME\]\]\]'s

exercise program are outlined below.

Structured Walk-Through

In the Structured Walk-through, a disaster scenario is established, and
the

teams \"walk-through\" their assigned tasks. This is a role-playing
activity that

requires the participation of at least the team leaders and their
alternates.

The scenario will be made available in advance of the exercise to allow
team

members to review their assigned tasks in response to the exercise
scenario.

During the Structured Walk-through, the WWC Continuity Plan is checked
for any

errors or omissions. At the end of the Structured Walk-through any
changes to

the plan that are found to be necessary are implemented.

Tactical

A Tactical Exercise is a simulated exercise, conducted in a \"war game\"
format.

All members of the continuity organization are required to participate
and

perform their tasks and procedures under announced or surprise
conditions. The

exercise monitor provides information throughout the exercise to
simulate events

following an actual disaster. Generally, a disaster scenario is
established and

provided to all the business continuity team leaders, alternate team
leaders,

and team members located in a large conference room or utilizing

video-conferencing. Each team executes its exercise objectives and
interacts

with other teams as they complete their actions.

A \"speeded up\" clock is usually employed in order to complete three
days\'

actions in one working day and requires the teams to respond to the
scenario

information in near real time.

An eight-hour exercise will usually simulate forty-eight to seventy-two
hours of

resumption activity. As in the Structured Walk-through, the plan is
checked for

any errors or omissions. At the end of the Tactical Exercise, any
changes to the

plan that are found to be necessary are implemented.

Live Production

In a Live Production application system exercise, an operating system is
brought

to live status on the alternate processor(s), and the data
communications

network is switched to the alternate site. All resources, other than the

computer and communications hardware needed to support this exercise,
must be

retrieved from the off-site storage facility. This exercise continues to

validate the switching capability of the data communications network,
and then

to the production processing of selected applications systems, including
User

Login and application system data currency checks. A Live Production
exercise

will normally be conducted on a weekend when there is a lesser
requirement to

provide continued service to the user community. Assurance of overall

recoverability can only be achieved through the conduct of a complete
Live

Production Application System Exercise. A Live Production exercise
should be

conducted once a year as the final exercise of resumption and recovery

capability.

Simulation

This type of exercise requires the execution of notification, operating

procedures, the use of equipment hardware/software, possible use of
alternate

site(s), and operations to ensure proper performance. Simulation
exercises can

and may be used in conjunction with checklist exercises for
identification of

required plan modification and staff training. Examples of procedures
verified

during a simulation exercise include Emergency Procedures, Use of
Alternative

Methods, Telecommunications Backups, Agent/Vendor/Customer
Notifications,

Hardware Capacity and Performance, Software Transportability, Alternate
Site

Access, Team Mobilization, Off-Site File and Information Retrieval,
Input Data

Retrieval, etc.

Announced And Unannounced

Announced exercises are scheduled exercises generally involving actual

resumption of computer processing at the alternate computer facility.
Production

processing is usually not interrupted, but may be planned for actual
resumption

and validation at the \"Hot Site.\" This type of test usually involves
the entire

continuity organization, including selected users along with operations
and

technical staff.

Unannounced exercises are surprise technical exercises that require
processing

to be actually recovered at the alternate site. Production processing
continues

in parallel and is not interrupted. This type of test generally involves
only a

small portion of the continuity organization and few, if any, users.

When to Exercise

Exercises should be conducted when:

a major revision to the plan has been completed;

additional production systems are implemented;

when significant changes in systems, applications and/or data
communications

has occurred; and

the preparedness level of continuity teams must be verified.

Responsibility for Establishing Exercise Scenarios

The ISSO is responsible for making plan exercise recommendations to the

\[\[\[OFFICE NAME\]\]\] Management Team and/or enterprise business
continuity

officials. Such recommendations include rationale for the exercise, the
benefits

expected to be derived from the exercise, and the specific objectives to
be

accomplished. A strategy will be developed for each exercise.
Development of

procedures that measure the effectiveness of the \[\[\[OFFICE NAME\]\]\]
Continuity

Plan will address the following plan elements:

Notification

Organization

Resources

Operations

For all exercises, each major plan element may be evaluated
independently, or

these elements may be exercised as integral parts of the overall plan.

Exercise Scenarios

Exercise scenarios are normally developed to accomplish the objectives

established by Executive Management. Some considerations in developing
exercise

scenarios include:

Re-exercising the plan segments that were determined to be deficient in
past

exercises.

Exercising time-sensitive application systems that have never been
recovered

or restored, or have not been recently exercised.

Involving those continuity organization team members that need more
training

and preparation to maintain familiarity with their functions.

Ensuring that each exercise involves the use of only off-site storage
and

inventory items to ensure the completeness and accuracy of the off-site

inventory.

Deciding whether the exercise and associated parameters will be openly

announced or will be a surprise. This decision is usually made at the

discretion of the enterprise business continuity officials.

Exercise Evaluation

An unbiased evaluation team should evaluate the results of each
exercise. This

team should be made up of \[\[\[OFFICE NAME\]\]\] or external personnel
(such as

external auditors) who are removed from any participation in the
exercise. The

evaluation team should be focused entirely on the validity, currency and

capability of the plan to recover and restore DOT time-sensitive
application

systems at the alternate computing facility.

The Exercise Evaluation Team is charged with the following
responsibilities:

Familiarization with the overall \[\[\[OFFICE NAME\]\]\] Continuity
Plan.

Understanding thoroughly the objectives of the exercise to be conducted.

Monitoring and observing all the activities of the teams involved in the

exercise.

Ensuring that exercise objectives are met, from the \[\[\[OFFICE
NAME\]\]\] and

client points of view.

Documenting findings related to the strengths and weaknesses observed
during

the exercise.

Each member of the continuity organization that participates in the
exercise

(team leader, alternate team leader, and team members) will be asked to
evaluate

the exercise's effectiveness, success and value.

Reviewing Exercise Results

Team leaders and the ISSO will document exercise results as soon as
possible,

but not later than two weeks after completion of an announced or
unannounced

exercise. Selected members of the business continuity organization will
review

exercise results and resolve weaknesses and problems. The ISSO will
chair the

review and coordinate appropriate changes/updates to the plan. The
results of

the review will be presented to \[\[\[OFFICE NAME\]\]\] Management and
the enterprise

business continuity officials.

Schedule of Exercises

The \[\[\[OFFICE NAME\]\]\] Management team will schedule exercises.
Exercises will be

scheduled with consideration to seasonal production and business cycles,
the

number of processing systems or platforms in production and the time
required to

exercise both time-sensitive processes and full production systems.

Education and Training

Awareness of the need for and the process of maintaining a viable
continuity

capability are essential. This awareness is achieved through formal
education

and training sessions conducted on a regular basis. This provides a way
of

ensuring that the necessary understanding of the business continuity
program and

processes are understood by the personnel responsible for maintaining
and

executing the plan.

The objectives of \[\[\[OFFICE NAME\]\]\] Continuity Plan training are
to:

Train the key employees and management who are required to help maintain
the

plan in a constant state of readiness

Train the key employees and management who are required to execute
various

plan segments in the event of an extended computer outage

Heighten planning awareness for those employees not directly involved in

maintaining and/or executing the plan

The ISSO will schedule Educational seminars addressing business
continuity in

general and the \[\[\[OFFICE NAME\]\]\] Continuity Plan in particular on
a regular

basis. These seminars will include overviews of the:

Continuity strategy, priorities and time frames.

Business continuity organization structure and responsibilities.

\[\[\[OFFICE NAME\]\]\] COOP structure and contents.

Data Preservation methodologies and practices.

Plan administration, maintenance, and exercises.

Chapter 11- Departmental Guide to Incident Handling Planning U.S.
DEPARTMENT OF

TRANSPORTATION

OFFICE OF THE SECRETARY

DOT H 1350.255

DEPARTMENTAL GUIDE TO

INCIDENT HANDLING

PLANNING

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. GOALS

4\. REFERENCES

5\. OVERVIEW OF INCIDENT HANDLING

6\. INFORMATION SYSTEM SECURITY INCIDENTS

A. Intrusion

B. Malicious Code

C. Fraud and Theft

D. Errors and Omissions

F. Loss, Theft, or Damage

G. Denial of Service

7\. INCIDENT HANDLING PLANNING

A. Incident Prevention

B. Incident Detection

\(1\) System and Network Logging Functions

\(2\) Detection Tools

\(3\) Detection Techniques

C. Incident Reporting and Communication

\(1\) Incident Reporting

\(2\) Communication

D. Incident Response

\(1\) Collect/Protect Information

\(2\) Contain The Incident

\(3\) Correct The Root Problem

\(4\) Return To Normal Operation

E. Lessons Learned

\(1\) Post Mortem Analysis

\(2\) Lessons Learned Implementation

\(3\) Risk Assessment

8\. COMPUTER SECURITY INCIDENT RESPONSE TEAM

ATTACHMENT A

SECURITY INCIDENT HANDLING PLAN TEMPLATE

DEPARTMENTAL GUIDE TO

INCIDENT HANDLING PLANNING

PURPOSE

The purpose of this Guide is to provide Department of Transportation
(DOT)

and their Operating Administration managers, ISSO's and network

administrators with a step-by-step approach for developing an Incident

Handling capability within their organizations, and Incident Response
Teams

capable of responding effectively and efficiently to information system

security \"incidents\".

SCOPE

The provisions of this Guide apply to the Department of Transportation

(DOT), its Secretarial Offices and Operating Administrations.

GOALS

The Goal of incident handling planning is to provide reasonable methods
for

limiting the possibility of an adverse effect on a DOT Information
System

due to the occurrence of an information system security incident, and
for

facilitating the rapid and successful investigation of an incident,
should

one occur.

REFERENCES

The DOT Departmental Information Resources Management Manual (DIRMM) DOT
H

1350.2 implements statutory and regulatory Information Resources
Management

(IRM) and security requirements for the Department. It also calls for

ensuring the confidentiality, integrity, and availability of information

contained, processed, or transmitted in/on sensitive systems. Refer to
DOT H

1350.2.1 REGULATORY AND GUIDANCE DOCUMENTS for specific references.

OVERVIEW OF INCIDENT HANDLING

An information system security incident is an event that has actual---or
the

potential for---adverse effects on computer or network operations. Such

incidents can result in fraud, waste, or abuse; can compromise
information;

or can cause loss or damage to property or information. An incident can

result from a computer virus, other malicious code, employee
malfeasance, or

a system intruder, either an insider or an outsider. Although it is
known

that hackers and malicious code can pose serious threats to systems and

networks, actual incidents of such damage cannot be predicted. Security

incidents, such as break-ins and service disruptions, on larger networks

(e.g., the Internet), have harmed the computing capabilities or various

organizations.

Incident handling is closely related to Continuity Of Operations
planning,

as described in DOT H 1350.254 Developmental Guide To Continuity Of

Operations Planning. In fact, an incident handling capability may be
viewed

as a component of Continuity Of Operations planning, because it provides
the

ability to react quickly and efficiently to disruptions in normal

processing. Broadly speaking, Continuity Of Operations planning
addresses

events with the potential to interrupt system operations. Incident
handling

can be considered that portion of contingency planning that responds to

malicious technical threats.

When left unchecked, malicious software can significantly harm an

organization\'s computing, depending on the technology and its
connectivity.

An incident handling capability provides a way for users to report

incidents, and the appropriate response and assistance to be provided to
aid

in recovery. Technical capabilities (e.g., trained personnel, intrusion

detection, and virus identification software) are prepositioned, ready
to be

used as necessary. Moreover, the organization will have already made

important contacts with other supportive sources (e.g., legal,
technical,

and managerial) to aid in containment, identification and recovery
efforts.

Like most Federal Agencies, DOT uses large LANs internally and also
connects

to public networks, such as the Internet. By doing so, DOT increases its

exposure to threats from intruder activity. An incident handling
capability

can provide enormous benefits by allowing a rapid response to suspicious

activity and coordinating incident handling with responsible agencies,

offices and individuals, as necessary. Intruder activity, whether
hackers or

malicious code, can often affect many systems located at many different

network sites; thus, handling the incidents can be logistically complex
and

can require information from outside the organization. By planning
ahead,

such contacts can be pre-established, and the speed of response
improved,

thereby containing and minimizing damage.

An incident handling capability also assists DOT in preventing (or at
least

minimizing) damage from future incidents. Incidents can be studied

internally to gain a better understanding of current threats and

vulnerabilities, so that more effective safeguards can be implemented.

Additionally, through outside contacts (established by the incident
handling

capability) early warnings of threats and vulnerabilities can be
provided.

Mechanisms will already be in place to warn users of these risks.

Finally, having an incident handling capability allows DOT organizations
to

learn from the incidents that they have experienced. Data about past

incidents (and the corrective measures taken) can be collected and
analyzed

for patterns. Vulnerabilities can also be identified via this process.

Knowledge about the types of threats that are occurring and the presence
of

vulnerabilities can aid in identifying security solutions. This
information

will also prove useful in creating a more effective training and
awareness

program, and thus help reduce the potential for losses.

INFORMATION SYSTEM SECURITY INCIDENTS

A. Intrusion

This is the deliberate attempt by an individual (insider / outsider) to
gain

unauthorized access into a system. Unauthorized access encompasses a
range

of incidents from improperly logging into a user\'s account (e.g., when
a

hacker logs in to a legitimate user\'s account) to unauthorized access
to

files and directories stored on a system or storage media by obtaining

superuser privileges. Unauthorized access could also entail access to

network data by planting an unauthorized \"sniffer\" program or device
to

capture all packets traversing the network at a particular point.

B. Malicious Code

Malicious code attacks include attacks by programs such as viruses,
Trojan

horse programs, worms, and scripts used by crackers/hackers to gain

privileges, capture passwords, and/or modify audit logs to exclude

unauthorized activity. Malicious code is particularly troublesome in
that it

is typically written to masquerade its presence and, thus, is often

difficult to detect. Self-replicating malicious code such as viruses and

worms can furthermore replicate rapidly, thereby making containment an

especially difficult problem.

C. Fraud and Theft

Information systems can be exploited for fraud and theft both by
automating

traditional methods of fraud and by using new methods. Systems that
control

access to any resource are targets (e.g., time and attendance systems,

financial systems, inventory systems, and long-distance telephone
systems).

Information system fraud and theft can be committed by insiders or

outsiders. Insiders are responsible for most incidents of fraud.

D. Errors and Omissions

Errors and omissions can be caused during the creation or modification
of

data.

E. Employee Sabotage and Abuse

Employees are most familiar with their employer's information systems
and

know which actions might cause the most damage, mischief, or sabotage.

Common examples of information system-related sabotage include:

\(1\) Destroying hardware or facilities.

\(2\) Planting logic bombs that destroy programs or data.

\(3\) Intentionally entering data incorrectly.

\(4\) Crashing systems.

\(5\) Intentionally deleting data.

\(6\) Intentionally changing data.

F. Loss, Theft, or Damage

Computer equipment, software, and data may be misplaced, stolen, or

physically damaged.

G. Denial of Service

The information system is not available for use to authorized personnel
due

to deliberate or accidental interference with system operations.

Perpetrators and malicious code can disrupt system services in many
ways,

including erasing a critical program, \"mail spamming\" (flooding a user

account with electronic mail), and altering system functionality by

installing a Trojan horse program.

INCIDENT HANDLING PLANNING

Incident handling planning may be accomplished as a five-step process,

consisting of:

Step 1 -- Identifying measures that help to prevent incidents from
occurring,

such as the use of anti-virus software, firewalls, and other tools and

practices.

Step 2 -- Defining measures that can detect the occurrence of an
incident,

such as intrusion detection monitoring systems, firewalls, router tables
and

anti-virus software.

Step 3 -- Establishing procedures for reporting and communicating an

incident. This reporting procedure should notify all affected parties
should

an incident be detected, including parties both within and external to
the

affected organization.

Step 4 -- Defining processes and measures for responding to a detected

incident, in order to minimize damage, isolate the problem, resolve it,
and

restore the affected system(s) to normal operation. This also includes
the

creation of a Computer Security Incident Response Team (CSIRT) trained
and

responsible for incident response.

Step 5 -- Developing a procedure for identifying and implementing
lessons

learned regarding the incident.

A Template for a Security Incident Handling Plan is contained in
Attachment

A of this Guide.

A. Incident Prevention

Preventing security incidents from occurring is a primary objective of
the

entire security planning process. The operational and technical controls

emplaced as part of the Risk Management process, and detailed in the

Information System Security Plan are designed to prevent the occurrence
of the

types of incidents described in Section 6 above. Refer to DOT H 1350.251

Departmental Guide to Developing an Information System Security Plan for
more

details on operational and technical controls for incident prevention.

B. Incident Detection

If an organization is not adequately prepared to detect the signs that
an

incident has occurred, is occurring, or is about to occur, it may be
difficult

or impossible to later determine if the organization's information
system(s)

have been compromised. Failure to identify the occurrence of an incident
can

leave the organization vulnerable in a number of ways:

Damage affecting multiple systems both inside and outside of the

organization due to an inability to react in time to prevent the spread
of

the incident.

Negative exposure that can damage the organization's reputation and

stature.

Possible legal liability for failing to exercise an adequate standard of

due care when the organization's information system(s) is used to

inadvertently or intentionally \"attack\" other organizations.

Damage to data, systems and networks due to not taking timely action to

contain and control an incident, resulting in loss of productivity,

increased costs, etc.

1\. System and Network Logging Functions

Collecting data generated by system, network, application and user

activities is essential for analyzing the security of these assets, and
for

incident detection. Log files contain information about what activities
have

occurred over time on the system. These files are often the only record
of

suspicious behavior, and may be used not only to detect an incident, but

also to help with system recovery, aid in investigation, serve as
evidence,

and back up insurance claims. Incident detection planning should include

identifying the types of logs and logging mechanisms available for each

system asset, and the data recorded within each log. If vendor-provided

logging mechanisms are insufficient to capture the data required, they

should be supplemented with tools that capture the additional
information.

Logging functions should always be enabled.

2\. Detection Tools

It is important to supplement system and network logs with additional
tools

that watch for signs that an incident has occurred, or has been
attempted.

These include tools that monitor and inspect system resource use,
network

traffic and connections, and user account and file access; tools that
scan

for viruses; tools that verify file and data integrity; tools to probe
for

system and network vulnerabilities; and tools to reduce, scan, monitor
and

inspect log files. Examples of detection tools include:

Tools that report system events, such as password cracking, or the

execution of unauthorized programs.

Tools that report network events, such as access during non-business

hours, or the use of Internet Relay Chat (IRC), a common means of

communication used by intruders.

Tools that report user-related events, such as repeated login attempts,
or

unauthorized attempts to access restricted information.

Tools that verify data, file and software integrity, including
unexpected

changes to the protections of files, or improperly set access control

lists on system tools.

Tools that examine systems in detail on a periodic basis, to check log

file consistency or known vulnerabilities.

3\. Detection Techniques

The general approach for incident detection is based on three simple
steps,

\-\-- observe/monitor information systems for signs of unusual activity,

investigate anything thought to be unusual, and if something is found
that

cannot be explained by authorized activity, immediately initiate

predetermined incident response procedures.

Recommended practices include:

Ensuring that the software used to examine systems has not been

compromised

Looking for unexpected changes to directories or files

Inspecting system and network logs

Reviewing notifications from system and network monitoring mechanisms

Inspecting processes for unexpected behavior

Investigating unauthorized hardware attached to the organization's
network

Looking for signs of unauthorized access to physical resources

Reviewing reports by users and external contacts about suspicious system

and network events and behavior

C. Incident Reporting and Communication

Designated organization personnel, as well as personnel outside of the

organization cannot execute their responsibilities if they are not
notified in

a timely manner that an incident is occurring or has occurred, and if
they are

not kept informed as the incident progresses. In addition, there are
types of

incidents wherein the public communications aspects, if mishandled,
could

result in serious negative publicity or loss of reputation. Hence it is

important that incident reporting and information dissemination
procedures be

established and periodically reinforced, so that all personnel are aware
of

how they are to participate when an incident occurs.

1\. Incident Reporting

Incident handling planning should specify who should be notified in the

event of an intrusion, who does the notifying of whom, and in what
order.

The order of notification may depend on the type of incident, or on
other

circumstance. Parties to be notified include: (NOTE: These are not

identified in any specific order)

The Information Systems Security Officer (ISSO)

The CSIRT, if one exists

Public Relations

System and Network Administrators

Responsible Senior Management

Human Resources

Legal Counsel

Law Enforcement Groups

System/Network Users

Other CSIRTS outside of the organization and/or DOT

2\. Communication

Communication aspects include:

Defining specific roles and responsibilities for each contact within the

organization, including their range of authority.

Specifying how much information should be shared with each class of

contact, and whether or not sensitive information needs to be removed or

filtered prior to sharing it.

Identifying who to notify and when to notify them by using specified

communication mechanisms (e.g.phone, e-mail, fax, pager, etc.), and

whether or not these mechanisms need to be secure.

Identifying who has the authority to initiate information disclosure

beyond that specified in DOT policy.

D. Incident Response

Planning for incident response should include the collection and
protection of

all relevant information, containing the incident, correcting the root
problem

leading to the incident, and, finally, returning the system to normal

operation.

1\. Collect/Protect Information

All information regarding an information system security incident should
be

captured and securely stored. This may include system and network log
files,

network message traffic, user files, intrusion detection tool results,

analysis results, system administrator logs and notes, backup tapes,
etc. In

particular, if the incident leads to a prosecution, such as for an

intruder/hacker, disgruntled employee or a thief, it is necessary to
have

complete, thorough and convincing evidence that has been protected
through a

verifiable and secure chain-of-custody procedure. In order to achieve
this

level of information protection and accountability, it is necessary
that:

All evidence is accounted for at all times

The passage of evidence from one party to the next is fully documented

The passage of evidence from one location to the next is fully
documented

Ensure that all critical information is duplicated and preserved both
onsite

and offsite in a secure location.

2\. Contain The Incident

Containment consists of short-term, tactical actions whose purpose it is
to

remove access to compromised systems, limit the extent of current damage
to

the system, and prevent additional damage from occurring. The specific
steps

to be followed depend upon the type of incident (intrusion, virus,
theft,

etc.), and whether the incident is ongoing (e.g., an intrusion) or is
over

(e.g., a theft of equipment). Considerations in planning for containment

include:

Defining the acceptable level of risk to business processes and the

systems and networks that support them, and to what extent these

processes, systems and networks must remain operational, even during a

major security incident

Methods for performing a rapid, overall assessment of the situation as
it

currently exists (scope, impact, damage, etc.)

Determining whether to quickly inform users that an incident has
occurred,

or is occurring, that could affect their ability to continue work

Identifying the extent to which containment actions might destroy or
mask

information required to later assess the cause of the incident

If the incident is ongoing, identifying the extent to which containment

actions might alert the perpetrator (e.g., an intruder, thief or other

individual with malicious intent)

Determining the applicability of existing Continuity Of Operations

Planning (refer to DOT H 1350.254 Departmental Guide to Continuity Of

Operations Planning)

Identifying when to involve senior management in containment decisions,

especially when containment includes shutting systems down or

disconnecting them from a network

Identifying who has the authority to make decisions in situations not

covered by existing containment policy

Containment strategies include temporarily shutting down a system,

disconnecting it from a network, disabling system services, changing

passwords, disabling accounts, changing physical access mechanisms, etc.

Specific strategies should be developed for serious incidents, such as:

Denial of service due to e-mail \"spamming\" (sending a large volume of

electronic messages to a targeted recipient) or \"flooding\" (filling a

channel with garbage, thereby denying others the ability to communicate

across it)

Programmed threats, such as new viruses not yet detected and eliminated
by

anti-virus software, or malicious applets, such as those using ActiveX
or

Java

The scanning, probing or mapping of systems by intruders planning on

future system hacking attempts

Major password compromises (e.g., an intruder with a password sniffer

tool), requiring the need to change all user or account passwords at a

specific site or at a specific organizational level

In general, the containment objective should be to provide a reasonable

security solution until sufficient information has been gathered to take

more appropriate actions to address the vulnerabilities exploited during
the

incident.

3\. Correct The Root Problem

Elimination of the root cause of a security incident oftentimes requires
a

great deal of analysis, followed by specific corrective actions, such as
the

improvement of detection mechanisms, changes in reporting procedures,

enhanced protection mechanisms (such as firewalls), more sophisticated

physical access controls, improved awareness and training, or specific

changes to security policy and procedures.

4\. Return To Normal Operation

Restoring a compromised information system, and returning it to normal

operation should ideally be accomplished only after the root cause of
the

incident has been corrected. Doing so prevents the same or similar type
of

incident from occurring again, or at least ensures that a recurring
incident

will be detected in a more timely fashion. However, business reality may

require that the system may have to be restored to operation before a
full

analysis can be conducted, and all corrections made. Such a risk needs
to be

carefully managed and monitored, recognizing that the system remains

vulnerable to another occurrence of the same type of incident. Thus an

important part of the incident handling planning process is determining
the

requirements and timeframe for returning specific information systems to

normal operation. The determination to return a system to normal
operation

prior to fully resolving the root problem should require the involvement
of

senior management.

Restoration steps include:

Using the latest trusted backup to restore user data. Users should
review

all restored data files to ensure that they have not been affected by
the

incident.

Enabling system and application services. Only those services actually

required by the users of the system should be enabled initially.

Reconnecting the restored system to its local area network. Validate the

system by executing a known series of tests, where prior test results
are

available for comparison.

Being alert for problem recurrence. A recurrence of a viral or intrusion

attack is a real possibility. Once a system has been compromised,

especially by an intruder, the system will likely become a target for

future attacks.

E. Lessons Learned

It is important to learn from the successful and unsuccessful actions
taken in

response to security incidents. Capturing and disseminating what worked
well

and what did not will help to reduce the possibility for similar
incidents,

and thus improve the overall information system security posture of DOT.

Otherwise, DOT systems and applications will continue to operate at
risk, and

will likely fall victim to the same or similar type of incident again.

Establishing a lessons learned capability includes the following steps:

1\. Post Mortem Analysis

A post mortem analysis and review meeting should be held within three to

five days of the completion of the incident investigation. Waiting too
long

could result in people forgetting critical information. Questions to be

asked include:

Did detection and response procedures work as intended? If not, why not?

Are there any additional procedures that would have improved the ability

to detect the incident?

What improvements to existing procedures and/or tools would have aided
in

the response process?

What improvements would have enhanced the ability to contain the
incident?

What correction procedures would have improved the effectiveness of the

recovery process?

What updates to policies and procedures would have allowed the response

and/or recovery processes to operate more smoothly?

How could user and/or system administrator preparedness be improved?

How could communication throughout the detection and response processes
be

improved?

The results of these and similar questions should be incorporated into a

report for senior management review/comment.

2\. Lessons Learned Implementation

As applicable, new and/or improved methods resulting from lessons
learned

should be included within current security plans, policies and
procedures.

In addition, there are public, legal and vendor information sources that

should be periodically reviewed regarding intruder trends, new virus

strains, new attack scenarios and new tools that could improve the

effectiveness of DOT response processes.

3\. Risk Assessment

If the severity or impact of the incident was severe, a new risk
assessment

for the affected information system should be considered. Refer to DOT H

1350.252 Departmental Guide to Risk Assessments for additional guidance.

COMPUTER SECURITY INCIDENT RESPONSE TEAM

A Computer Security Incident Response Team (CSIRT), oftentimes shortened
to

Computer Incident Response Team (CIRT) is a group of professionals
within

the organization, who are trained and chartered to respond to a serious

security incident. The CSIRT has both an investigative and a
problem-solving

component, and should include management personnel with the authority to

act, technical personnel with the knowledge and expertise to rapidly

diagnose and resolve problems, and communications personnel able to keep
the

appropriate individuals and organizations properly informed as to the
status

of the problem, and develop public image/crisis control strategies, as

necessary.

The composition of the CSIRT, and the circumstances under which it is

activated must be clearly defined, in advance, as part of the incident

handling planning process. The Team should be available and on call in

emergency situations, and possess the authority to make decisions in
real

time. Procedures that define the circumstances under which the CSIRT is

activated must be clear and unambiguous. Activation for every simple

incident, such as an employee's data entry error, can be wasteful and

time-consuming. On the other hand, if a serious incident, such as an

intrusion attack, is in progress, then delaying the activation of the
Team

could result in serious damage to the organization. Activation should

therefore be considered only when information systems must be protected

against serious compromise, \-\-- an unexpected, unplanned situation
that

requires immediate, extraordinary and fast action to prevent a serious
loss

of organizational assets and/or mission capability. The individual
within

the organization authorized to activate the CSIRT should also be clearly

identified.

The planning process should also consider which Team members will be
needed

for different kinds and levels of incidents, and how they are to be

contacted when an emergency occurs. Finally, the members of the CSIRT
need

to be adequately trained to handle their duties rapidly and effectively.

Training should include both the procedures to be followed in responding
to

a serious security incident, and the specific technical skills that

individual Team members might require in order to adequately perform
their

assigned tasks. Periodic simulations of security incidents should be

considered, as an additional method for maintaining Team effectiveness.

ATTACHMENT A - SECURITY INCIDENT HANDLING PLAN TEMPLATE - \[ TO BE
SUPPLIED \]

Chapter 11- Departmental Guide to Personnel Security PlanningU.S.
DEPARTMENT OF

TRANSPORTATION

OFFICE OF THE SECRETARY

DOT H 1350.256

DEPARTMENTAL GUIDE TO

PERSONNEL SECURITY PLANNING

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. GOALS

4\. REFERENCES

5\. OVERVIEW OF PERSONNEL SECURITY

6\. STAFFING

A. Position Definition

B. Determining Position Sensitivity

C. Screening

D. Employee Training and Awareness

6\. USER ADMINISTRATION

A. User Account Management

B. Audit and Management Reviews

C. Detecting Unauthorized/Illegal Activities

D. Friendly Termination

E. Unfriendly Termination

7\. CONTRACTOR ACCESS CONSIDERATIONS

8\. PUBLIC ACCESS CONSIDERATIONS

DEPARTMENTAL GUIDE TO

PERSONNEL SECURITY PLANNING

PURPOSE

The purpose of this Guide is to provide Department of Transportation
(DOT) and

their Operating Administration managers, ISSO's and network
administrators

with a step-by-step approach for developing a personnel security
capability

within their organizations.

SCOPE

The provisions of this Guide apply to the Department of Transportation
(DOT),

its Secretarial Offices and Operating Administrations.

GOALS

The Goal of personnel security planning is to improve the security of
DOT

information systems by guarding against potential damage caused by the

intentional or unintentional actions of employees, contractors or the
general

public.

REFERENCES

The DOT Departmental Information Resources Management Manual (DIRMM) DOT
H

1350.2 implements statutory and regulatory Information Resources
Management

(IRM) and security requirements for the Department. It also calls for
ensuring

the confidentiality, integrity, and availability of information
contained,

processed, or transmitted in/on sensitive systems. Refer to DOT H
1350.2.1

Regulatory and Guidance Documents for specific references.

OVERVIEW OF PERSONNEL SECURITY

Most security problems, whether accidental or malicious, begin with
people. Of

these people, by far, most of them come from within the organization.
The

foundation for dealing with people problems, therefore, is to try to
eliminate

the potential for problems before they happen. In order to address
personnel

security in a proactive fashion, plans should be created for the
staffing of

positions that interact with DOT information systems, the administration
of

users on such systems (including considerations for terminating employee

access), and special considerations that may arise when contractors or
the

public have access to DOT information systems.

There are 2 major elements of personnel security that must be considered

during the planning activity, \-\-- Staffing and User Administration.
The

staffing process generally involves at least four steps and can apply
equally

to general users as well as to application managers, system management

personnel, and security personnel. These four steps include defining the
job,

(normally involving the development of a position description),
determining

the sensitivity of the position, filling the position (which involves

screening applicants and selecting an individual), and training the new

individual. Effective administration of users\' access to DOT
information

systems is also essential in implementing an overall Information System

Security Program. User account management focuses on identification,

authentication, and access authorizations. This is augmented by the
process of

auditing (periodically verifying the legitimacy of current accounts and
access

authorizations). Finally, there are considerations involved in the
timely

modification or removal of access and associated issues for employees
who are

reassigned, promoted, or terminated, or who retire.

In addition to these two major elements, personnel security planning
should

also take into account security considerations when Contractors are
allowed

access to DOT information systems, and, similarly, when the public is
granted

access to certain information, generally via the Internet.

STAFFING

An organization\'s staffing process should pay particular attention to
security

at each point in the hiring and employee orientation process. To do
this,

specific security controls should be incorporated within the overall
staffing

process, as defined in the ensuing paragraphs.

A. Position Definition

Early in the process of defining a position, security issues should be

identified and addressed. Once a position has been broadly defined, the

responsible supervisor should determine the type of computer access
needed for

the position. There are two general security rules to apply when
granting

access, \-\-- separation of duties and least privilege.

Separation of Duties - refers to dividing roles and responsibilities so

that a single individual cannot subvert a critical process. For example,

in financial systems, no single individual should normally be given

authority to issue checks. Rather, one person initiates a request for a

payment and another authorizes that same payment. In effect, checks and

balances need to be designed into both the process as well as the

specific, individual positions of personnel who will implement the

process.

Least Privilege - refers to the security objective of granting users
only

those accesses they need to perform their official duties. Data entry

clerks, for example, may not have any need to run analysis reports of

their database. However, least privilege does not mean that all users
will

have extremely little functional access; some employees will have

significant access if it is required for their position. However,
applying

this principle may limit the damage resulting from accidents, errors, or

unauthorized use of system resources. It is important to make certain
that

the implementation of least privilege does not interfere with the
ability

to have personnel substitute for each other without undue delay. Without

careful planning, access control can interfere with contingency plans.

B. Determining Position Sensitivity

Various levels of sensitivity are assigned to positions in the federal

government. Determining the appropriate sensitivity level is based upon
such

factors as the type and degree of harm (e.g., disclosure of private

information, interruption of critical processing, computer fraud) the

individual can cause through misuse of the information system, as well
as

more traditional factors (such as access to classified information and

fiduciary responsibilities). The responsible manager should determine
the

position sensitivity, based on the duties and access levels, so that

appropriate cost-effective screening can be completed.

It is important to carefully select the appropriate position
sensitivity,

since controls in excess of the sensitivity of the position waste
resources,

while too little control may result in unacceptable risks to the system.

C. Screening

Background screening helps to determine whether a particular individual
is

suitable for a given position. In the federal government, the screening

process is formalized through a series of background checks conducted

through a central investigative office within the organization or
through

another organization (e.g., the Office of Personnel Management). Within
the

Federal Government, the most basic screening technique involves a check
for

a criminal history, checking FBI fingerprint records, and other federal

indices. More extensive background checks examine other factors, such as
a

person\'s work and educational history, personal interview, history of

possession or use of illegal substances, and interviews with current and

former colleagues, neighbors, and friends. The exact type of screening
that

takes place depends upon the sensitivity of the position and applicable
DOT

implementing regulations. The prospective employee's manager does not

conduct screening; rather, agency security and personnel officers should
be

consulted for agency-specific guidance.

D. Employee Training and Awareness

Once an employee has been hired, it is important to perform sufficient

indoctrination in the area of information protection to ensure a clear

understanding of the policies to be adhered to, the procedures for

adherence, and what happens in the case of non adherence. In many

organizations, this information is not made clear from the outset, and
is

the basis for misunderstanding on all sides. Proper training is also

necessary to assure that the employee is competent to carry out the

procedures required to implement protection policies. Refer to DOT H

1350.258 Departmental Guide to Developing an Information System Security

Awareness/Training/Education Program for additional guidance on this
issue.

USER ADMINISTRATION

Effective administration of users\' computer access is essential to
maintaining

information system security. Hence effective personnel security planning

should ensure effective administration of users\' computer access, \-\--

including user account management, auditing and the timely modification
or

removal of access. The following should be considered:

A. User Account Management

Management of user accounts includes processes for requesting,
establishing,

issuing, and closing user accounts; tracking users and their respective
access

authorizations; and managing these functions.

Establishing a user account typically begins with a request from the
user\'s

supervisor to the system administrator (SA) for a system account. If a
user is

to have access to a particular major application, this request may be
sent

through the application manager to the SA. This will ensure that the
systems

office receives formal approval from the application manager for the
employee

to be given access. The request will normally state the level of access
to be

granted, perhaps by function or by specifying a particular user profile.

The SA will then use the account request to create an account for the
new

user. The access levels of the account will be consistent with those
requested

by the user's supervisor, and by various application managers. Next,
employees

will be given their account information, including the account
identifier

(e.g., user ID) and a means of authentication (e.g., password or smart

card/PIN). Note that when employees are given their account, the process

should include training and awareness on information security issues
(Refer to

DOT H 1350.258 Departmental Guide to Developing an Information System
Security

Awareness/Training/Education Program). In addition, users should be
asked to

review a set of rules and regulations for system access.

When user accounts are no longer required, the user's supervisor should
inform

the SA and the appropriate application manager(s), so that these
accounts can

be removed in a timely manner. Further termination issues are discussed
in

Paragraphs D and E of this Section.

It is important to note that access and authorization administration is
a

continuing process. New user accounts are continually being added, while

others are deleted. In addition, permissions may change, \-\-- sometimes

permanently, sometimes only temporarily. New applications may be added,

upgraded, and removed, with changing lists of authorized users. Tracking
this

information to keep it up to date is essential to allow users access to
only

those functions necessary to accomplish their assigned responsibilities.

One significant aspect of user account management involves keeping user
access

authorizations up to date. Access authorizations are typically changed
under

two types of circumstances, \-\-- a change in job role, either
temporarily

(e.g., while covering for an employee on sick leave) or permanently
(e.g.,

after an in-house transfer), and termination (discussed in Paragraphs D
and E

of this Section).

Users often are required to perform duties outside their normal scope
during

the absence of others. This requires additional access authorizations.

Although necessary, such extra access authorizations should be granted

sparingly and monitored carefully, consistent with the need to maintain

separation of duties for internal control purposes. Also, they should be

removed promptly when no longer required.

Permanent changes are usually necessary when employees change positions
within

an organization. In this case, the process of granting account
authorizations

will occur again. At this time, however, is it also important that
access

authorizations of the prior position be removed. Many instances of

\"authorization creep\" have occurred with employees continuing to
maintain

access rights for previously held positions within the organization.
This

practice is inconsistent with the principle of least privilege.

B. Audit and Management Reviews

It is necessary to periodically review user account management on a
system.

Reviews should examine the levels of access each individual has,
conformity

with the concept of least privilege, whether all accounts are still
active,

whether management authorizations are up-to-date, whether required
training

has been completed, and so forth. These reviews can be conducted on at
least

two levels, \-\-- on an application-by-application basis, or on a system
wide

basis. A good practice is for application managers (and data owners, if

different) to review all access levels of all application users every
month.

Whereas the SA can verify that users only have those accesses that their

managers have specified, because access requirements may change over
time, it

is important to involve the application manager, who is often the only

individual in a position to know current access requirements.

C. Detecting Unauthorized/Illegal Activities

Mechanisms besides auditing and analysis of audit trails should be used
to

detect unauthorized and illegal acts. Rotating employees in sensitive

positions, which could expose a scam that required an employee's
presence or

periodic re-screening of personnel are methods that can be used.

D. Friendly Termination

Friendly termination refers to the removal of an employee from the

organization when there is no reason to believe that the termination is
other

than mutually acceptable. Since terminations can be expected regularly,
this

is usually accomplished by implementing a standard set of procedures for

outgoing or transferring employees. These are part of the standard
employee

\"out-processing,\" and are put in place to ensure that system accounts
are

removed in a timely manner. This normally includes:

removal of access privileges, computer accounts, authentication tokens,

the control of keys,

the briefing on the continuing responsibilities for confidentiality and

privacy,

return of property, and

continued availability of data. In both the manual and the electronic

worlds, this may involve documenting procedures or filing schemes, such

as how documents are stored on the hard disk, and how are they backed

up. Employees should be instructed whether or not to \"clean up\" their
PC

before leaving. If cryptography is used to protect data, the

availability of cryptographic keys to management personnel must be

ensured.

E. Unfriendly Termination

Unfriendly termination involves the removal of an employee under
involuntary

or adverse conditions. This may include termination for cause, Reduction
in

Force (RIF), involuntary transfer, resignation for \"personality
conflicts,\"

and situations with pending grievances. The tension in such terminations
may

multiply and complicate security issues. Additionally, all of the issues

involved in friendly terminations are still present, but addressing them
may

be considerably more difficult.

The greatest threat from unfriendly terminations is likely to come from

those personnel who are capable of changing code or modifying the system
or

applications. For example, systems personnel are ideally positioned to
wreak

considerable havoc on systems operations. Without appropriate
safeguards,

personnel with such access can place logic bombs (e.g., a hidden program
to

erase a disk) in code that will not even execute until after the
employee\'s

departure. Backup copies can be destroyed. There are even examples where

code has been \"held hostage.\" But other employees, such as general
users,

can also cause damage. Errors can be input purposefully, documentation
can

be mis-filed, and other \"random\" errors can be made. Correcting these

situations can be extremely resource intensive. Given the potential for

adverse consequences, organizations should do the following:

System access should be terminated as quickly as possible when an

employee is leaving a position under less than friendly terms. If an

employee is to be fired, system access should be removed at the same

time (or just before) the employee is notified of his/her dismissal.

When an employee notifies an organization of a resignation and it can be

reasonably expected that it is on unfriendly terms, system access should

be immediately terminated.

During the \"notice of termination\" period, it may be necessary to
assign

the individual to a restricted area and function. This may be

particularly true for employees capable of changing programs or

modifying the system or applications.

In some cases, physical removal from the offices may be necessary.

CONTRACTOR ACCESS CONSIDERATIONS

DOT utilizes contractors and consultants to assist with a wide variety
of

information technology taskings. In cases where these individuals
perform

their taskings at a DOT facility, access to DOT information systems is
often a

necessity. Hence consultant/contractor access must be accounted for in
the

personnel security planning process. In addition, these individuals must
be

made aware of applicable DOT security policy and procedures, by
providing them

with DOT H 1350.273 Guide to Information Protection for Contractors.

PUBLIC ACCESS CONSIDERATIONS

Like other federal agencies, DOT utilizes electronic methods, such as
the

Internet, for electronic dissemination of information to the public.
When DOT

systems are made available for access by the public (or a large or
significant

subset thereof), it triggers additional security issues, based upon the

increased risk. Public access systems are subject to a threat from
hacker

attacks on the confidentiality, availability, and integrity of
information

processed by a system. Besides increased risk of hackers, public access

systems can also be subject to insider malice. For example, an
unscrupulous

user, such as a disgruntled employee, may try to introduce errors into
data

files intended for distribution in order to embarrass or discredit the

organization. Attacks on public access systems could have a substantial
impact

on the organization\'s reputation and the level of public confidence due
to the

high visibility of public access systems. Other security problems may
arise

from unintentional actions by untrained users. Hence, when opening up a
system

to public access, additional precautions may be necessary because of the

increased threats.

Chapter 11- Departmental Guide to Physical/Environmental Security
Planning, DIRMM U.S.

DEPARTMENT OF TRANSPORTATION

OFFICE OF THE SECRETARY

DOT H 1350.257

DEPARTMENTAL GUIDE TO

PHYSICAL/ENVIRONMENTAL

SECURITY PLANNING

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. GOALS

4\. REFERENCES

5\. OVERVIEW OF PHYSICAL/ENVIRONMENTAL SECURITY

6\. PHYSICAL ACCESS CONTROLS

7\. FIRE SAFETY CONTROLS

8\. PROTECTING SUPPORTING UTILITIES

9\. PREVENTING STRUCTURAL COLLAPSE

10\. PREVENTING PLUMBING LEAKS

11\. GUARDING AGAINST INTERCEPTION OF DATA

12\. PROTECTING PORTABLE AND MOBILE SYSTEMS

DEPARTMENTAL GUIDE TO

PHYSICAL/ENVIRONMENTAL SECURITY PLANNING

PURPOSE

The purpose of this Guide is to provide Department of Transportation
(DOT) and

their Operating Administration managers, ISSO's and network
administrators

with a step-by-step approach for developing both a physical and
environmental

security capability within their organizations.

SCOPE

The provisions of this Guide apply to the Department of Transportation
(DOT),

its Secretarial Offices and Operating Administrations.

GOALS

The Goal of physical/environmental security planning is to provide
protection

for the DOT facility housing information system resources, the system

resources themselves, and the facilities used to support their
operation.

REFERENCES

The DOT Departmental Information Resources Management Manual (DIRMM) DOT
H

1350.2 implements statutory and regulatory Information Resources
Management

(IRM) and security requirements for the Department. It also calls for
ensuring

the confidentiality, integrity, and availability of information
contained,

processed, or transmitted in/on sensitive systems. Refer to DOT H
1350.2.1

Regulatory and Guidance Documents for specific references.

OVERVIEW OF PHYSICAL/ENVIRONMENTAL SECURITY

Physical/Environmental Security refers to measures taken to protect
systems,

buildings, and related supporting infrastructure against threats
associated

with their physical environment. Such threats, and the measures taken to

mitigate them, depend on three sets of characteristics:

Physical Characteristics -- The basic physical characteristics of the
DOT

facility housing the information system or systems determine the level
of

such physical threats as fire, roof leaks, or unauthorized access. In

particular, whether the facility is fixed (e.g., a building), or mobile

(e.g., an airplane) is of particular significance in terms of deriving
the

appropriate security measures.

Geographical Characteristics -- The particular location of the DOT
facility

housing the information system or systems determines the characteristics
of

natural threats (including earthquakes and flooding), man-made threats
(such

as burglary, civil disorders, or interception of transmissions and

emanations), and damaging nearby activities (including toxic chemical

spills, explosions, fires, and electromagnetic interference from
emitters

such as radar).

Characteristics of Supporting Facilities -- The operation of DOT
information

systems usually depends on supporting facilities such as electric power,

heating and air conditioning, and telecommunications. The failure or

substandard performance of these facilities may interrupt operation of
the

system and may cause physical damage to system hardware or stored data.

Properly applied, Physical/Environmental security controls can prevent
losses

due to interruptions in computer services, physical damage, unauthorized

disclosure of information, loss of control over system integrity, and
theft.

These Physical/Environmental security controls encompasses seven primary
areas

1\. Physical Access Controls

Physical access controls restrict the entry and exit of personnel (and
often

equipment and media) from an area, such as an office building, suite,
data

center, or room containing a local area network (LAN) server.

2\. Fire Safety Controls

Building fires are a particularly important security threat because of
the

potential for complete destruction of hardware and data, the risk to
human

life, and the pervasiveness of the damage. Smoke, corrosive gases, and
high

humidity from a localized fire can damage systems throughout an entire

building. Fire safety controls guard against the start of fires, ensure

early detection should a fire start, and assist in rapid fire
extinguishing.

3\. Protecting Supporting Utilities

A failure of electric power, heating or air-conditioning systems, water,

sewage, and other utilities will usually cause a service interruption
and

may damage system hardware. Systems and the people who operate them

therefore need to have a reasonably well-controlled operating
environment,

with appropriate safeguards that would mitigate such failure

4\. Preventing Structural Collapse

Buildings housing information systems may be subjected to a load greater

than they can support. Most commonly this is a result of an earthquake,
a

snow load on the roof beyond design criteria, an explosion that
displaces or

cuts structural members, or a fire that weakens structural members

5\. Preventing Plumbing Leaks

Plumbing leaks are not an everyday occurrence. However, should such a
leak

occur, the resulting water damage could seriously disrupt facility
operations

6\. Guarding Against Interception of Data

Depending on the type of data processed by an information system, there
may

be a significant risk if that data is intercepted. There are three
primary

methods of data interception: direct observation, interception of data

transmission, and electromagnetic interception

7\. Protecting Mobile and Portable Systems

The analysis and management of risk usually has to be modified if a
system

is installed in a vehicle or is portable, such as a laptop computer. The

system in a vehicle will share the risks of the vehicle, including
accidents

and theft, as well as regional and local risks

PHYSICAL ACCESS CONTROLS

Issues to be considered in deriving a set of physical access controls
include:

Addressing physical access controls not only the for areas containing

system hardware, but also for locations containing wiring used to
connect

elements of the system, supporting services (such as electric power),

backup media, and any other elements required for the system\'s
operation.

Considering both normal access and surreptitious access when evaluating

methods for restricting physical access. Restricting normal access may

include barriers that isolate each area, entry points in the barriers,
and

screening measures at each of the entry points (e.g., badges or card-key

devices). Physical modifications to barriers can reduce the
vulnerability

to surreptitious entry. Intrusion detectors, such as closed-circuit

television cameras, motion detectors, and other devices, can detect

intruders in unoccupied spaces.

Using DOT employees. Staff members who work in a restricted area can
serve

an important role in providing physical security, as they can be trained

to challenge people they do not recognize.

Ensuring that maintenance and service personnel are properly escorted
and

supervised by a DOT employee with enough background, training or

qualifications to understand the risks associated with the work being

done, and provide assurance that only authorized access to sensitive

information or assets takes place.

Ensuring that signs or other information revealing the purpose or
location

of restricted zones as they relate to sensitive information systems are

not posted in areas accessible to the general public such as lobbies,

waiting rooms or reception areas.

Remembering that physical and environmental controls are also closely

linked to the activities of the local guard force, fire house, life
safety

office, and medical office. These organizations should be consulted for

their expertise in planning controls for the information systems

environment.

In addition, it is important to review the effectiveness of physical
access

controls in each area, both during normal business hours and at other
times \--

particularly when an area may be unoccupied. Effectiveness depends on
both the

characteristics of the control devices used (e.g., keycard-controlled
doors)

and the implementation and operation. Statements to the effect that
\"only

authorized persons may enter this area\" are not particularly effective.

Organizations should determine whether intruders can easily defeat the

controls, the extent to which strangers are challenged, and the
effectiveness

of other control procedures. Factors like these modify the effectiveness
of

physical access controls.

FIRE SAFETY CONTROLS

Issues to be considered in developing plans for fire safety controls
include:

Identifying and neutralizing potential ignition sources. Fires begin

because something supplies enough heat to cause other materials to burn.

Typical ignition sources are failures of electric devices and wiring,

carelessly discarded cigarettes, improper storage of materials subject
to

spontaneous combustion, improper operation of heating devices, and, of
course, arson.

Isolating and properly storing potential fuel sources. If a fire is to

grow, it must have a supply of fuel, material that will burn to support

its growth, and an adequate supply of oxygen. Once a fire becomes

established, it depends on the combustible materials in the facility

(referred to as the fire load) to support its further growth. The more

fuel per square meter, the more intense the fire will be. In addition,
if

the facility is well maintained and operated so as to minimize the

accumulation of fuel sources, the fire risk will be further minimized.

Planning for reliable, effective means of fire detection. The more
quickly

a fire is detected, all other things being equal, the more easily it can

be extinguished, thereby minimizing damage to the facility. It is also

important to accurately pinpoint the location of the fire.

Providing rapid access to sufficient means of fire extinguishment. A
fire

will burn until it consumes all of the fuel in the building or until it
is

extinguished. Fire extinguishment may be automatic, as with an automatic

sprinkler system or a chemical discharge system. Alternatively, it may
be

performed by people using portable extinguishers, cooling the fire site

with a stream of water, limiting the supply of oxygen with a blanket of

foam or powder, or breaking the combustion chemical reaction chain.

PROTECTING SUPPORTING UTILITIES

Issues to be considered in developing plans for protecting utilities
that

support an organization's information systems include:

Identifying the failure modes of each utility (air conditioning,
electric

power distribution, heating plants, water, sewage, and other utilities)

required for system operation or staff comfort.

Calculating the Mean Time Between Failure (MTBF) for each major element

comprising these utilities. This serves as an indicator for how often to

expect a failure that could affect facility operations. If the results
are

unacceptable, consider ways to either replace high MTBF items with more

reliable ones (cost permitting), or stock an adequate level of spares.

Calculating the Mean Time To Repair (MTTR) for each major element.

Remember, until the utility is repaired, users may be denied access to

vital information system data, or be without important communication

links. Consider added training for maintenance personnel, or

pre-positioned spares to reduce MTTR if possible.

Determining the need for dual-redundant or backup utilities for critical

system support (such as Uninterruptable Power Supplies).

Ensuring that emergency lighting exists in computer rooms.

Ensuring that supporting utilities such as power distribution panels,

communications and telephone closets, and air conditioning systems, when

located outside restricted zones established within the facility are

appropriately secured by such measures as locks.

Considering the screening or filtering of external openings for air

conditioning systems to protect against the insertion of hazardous
objects

or the intrusion of pollutants.

Ensuring, if possible, that utility service lines (water, gas, oil,
etc.)

that provide support to facilities enter the building underground or are

physically protected by other means, such as enclosing exposed lines in

conduit, installing barriers around water and gas mains or meters, and

locking fuel tank inlet pipes.

PREVENTING STRUCTURAL COLLAPSE

Issues to be considered in developing plans for preventing the
structural

collapse of an organization's facility include:

Determining, for a building in the construction planning stage, the

likelihood of structural collapse due to environmental factors such as
an

earthquake or snow load and, if probabilities warrant, ensuring that

adequate precautions are taken regarding structural design strengths.

Determining, for a building in the construction planning stage, the

likelihood of structural collapse due to natural or man-made disasters,

such as a major fire, gas explosion or sabotage, again ensuring that

adequate precautions are taken regarding structural design strengths.

Determining, for an existing building, the likelihood that of any of
these

factors could result in structural collapse, given the existing facility

design. If probabilities and design weaknesses warrant, consider, \-\--
at a

minimum, \-\-- Continuity Of Operations (COOP) planning that
incorporates

hot or cold site utilization (refer to DOT H 1350.254 Departmental Guide

to Continuity of Operations Planning). In the worst case, a change of

facilities should be seriously considered.

PREVENTING PLUMBING LEAKS

Issues to be considered in developing plans for preventing plumbing
leaks

include:

Locating plumbing lines that might endanger system hardware. These lines

include hot and cold water, chilled water supply and return lines, steam

lines, automatic sprinkler lines, fire hose standpipes, and drains. If a

building includes a laboratory or manufacturing spaces, there may be
other

lines that conduct water, corrosive or toxic chemicals, or gases.

Considering the relocation of potentially damaging lines. As a rule,

analysis often shows that the cost to relocate threatening lines is

difficult to justify. However, the location of shutoff valves and

procedures that should be followed in the event of a failure must be

specified. Operating and security personnel should have this information

immediately available for use in an emergency. In some cases, it may be

possible to relocate system hardware, particularly distributed LAN

hardware.

GUARDING AGAINST INTERCEPTION OF DATA

Issues to be considered in developing plans for guarding against the

interception of data include:

Eliminating problems due to direct observation, whereby system terminal

and workstation display screens may be observed by unauthorized persons,

by relocating susceptible displays.

Guarding against interception of data transmissions. If an intruder can

gain access to data transmission lines, it may be feasible to tap into
the

lines and read the data being transmitted. Network monitoring tools can
be

used to capture data packets. Of course, the intruder cannot control
what

is transmitted, and so may not be able to immediately observe data of

interest. However, over a period of time there may be a serious level of

disclosure. Local area networks typically broadcast messages.

Consequently, all traffic, including passwords, could be retrieved.

Interceptors could also transmit spurious data on tapped lines, either
for

purposes of disruption or for fraud.

Preventing electromagnetic interception. Systems routinely radiate

electromagnetic energy that can be detected with special-purpose radio

receivers. Successful interception depends on the signal strength at the

receiver location; the greater the separation between the system and the

receiver, the lower the success rate. TEMPEST shielding, of either

equipment or rooms, can be used to minimize the spread of
electromagnetic

signals. The signal-to-noise ratio at the receiver, determined in part
by

the number of competing emitters will also affect the success rate. The

more workstations of the same type in the same location performing

\"random\" activity, the more difficult it is to intercept a given

workstation\'s radiation. On the other hand, the trend toward wireless

(i.e., deliberate radiation) LAN connections may increase the likelihood

of successful interception.

PROTECTING PORTABLE AND MOBILE SYSTEMS

Issues to be considered in developing plans for protecting portable and
mobile systems include:

Guarding against compromise or damage due to accident or theft of the

system's means of transport (e.g., automobile, truck, airplane).

Guarding against theft of portable and mobile systems. As they tend to
be

small and relatively lightweight, they share an increased risk of theft.

In addition, portable systems can be \"misplaced\", damaged or left

unattended by careless users. Secure storage of laptop computers is
often

required when they are not in use.

Considering storing valuable or important data on a medium that can be

removed from the portable/mobile system when it is unattended, or to

encrypt the data.

Chapter 11- Guide to Protecting Information Technology U.S. DEPARTMENT
OF TRANSPORTATION, OFFICE OF THE SECRETARY

DOT H 1350.260

GUIDE TO PROTECTING

INFORMATION TECHNOLOGY

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. GOALS

4\. REFERENCES

5\. OVERVIEW OF THE DOT INFORMATION SYSTEM SECURITY PROGRAM

6\. ROLES & RESPONSIBILITIES

7\. ISS PROGRAM IMPLEMENTATION

A. Draft Security Plan

B. Risk Assessment

C. Risk Mitigation

D. System Certification

E. Final Security Plan

F. System Accreditation

8\. ISS PROGRAM ADMINISTRATION

9\. ISS PROGRAM MAINTENANCE AND UPDATE

ATTACHMENT A - SYSTEM OWNER'S SECURITY HANDBOOK

ATTACHMENT B - INFORMATION SYSTEMS SECURITY OFFICER HANDBOOK

1\. INTRODUCTION

1.1 Purpose

1.2 References

2\. OPERATIONAL ENVIRONMENT

3\. ISSO AREAS OF RESPONSIBILITY

3.1 Security Regulations and Policies

3.3 Mission Needs

3.3 Physical Security Requirements

3.4 Continuity of Operations Plans

3.5 Declassification And Downgrading Of Data And Equipment

3.6 Administrative Security Procedures

3.6.1 Personnel Security

3.6.2 Security Incident Handling

3.7 Security Awareness and Training

3.8 Security Configuration Management

3.9 Access Control

3.9.1 Facility Access

3.9.2 Identification and Authentication (I&A)

3.9.3 Data Access

3.10 Risk Management

3.11 Audits

3.11.1 Audit Trails

3.11.2 Auditing Responsibilities

3.12 Certification and Accreditation

ATTACHMENT C - SYSTEM ADMINISTRATOR'S SECURITY HANDBOOK

GUIDE TO PROTECTING

INFORMATION TECHNOLOGY

PURPOSE

The purpose of this Guide is to provide guidance in implementing,

administrating, maintaining and updating the Information System
Protection

Program defined within the DOT H 1350.250 series of Guides for the
Department

of Transportation (DOT) and its Operating Administrations.

SCOPE

The provisions of this document apply to all DOT employees, volunteers
and

contractor support personnel.

GOALS

The goal of this document is to improve the security of DOT Information

Systems by providing those DOT employees responsible for implementing
the

Information System Protection Program with the guidance necessary for

effective Program implementation, administration, maintenance and
updating.

REFERENCES

All references and terms used in this document are listed and explained
in DOT

H 1350.2.1, ISS References/Definitions, dated March 3, 1999.

OVERVIEW OF THE DOT INFORMATION SYSTEM SECURITY PROGRAM

DOT H 1350.2 defines the overall Information System Security Program
within DOT

and its Operating Administrations as a hierarchy of five major elements:

Policy -- Consists of the purpose, goals and scope of the DOT
Information

System Security (ISS) Program. This element also includes the
identification

of the key roles and responsibilities for the successful safeguarding of
DOT

information. Policy is documented within DOT H 1350.2

Terms - Provides a description of the references used in the
establishment of

the ISS Program, as well as the definition of terms commonly used
throughout

the program documentation. Terms are documented within DOT H 1350.2-2.

Planning -- This element incorporates all of the planning required to
establish

an ISS Program. Specific topics include Information System Security
Plans,

Risk Assessments, Certification/Accreditation, Continuity of Operations,

Incident Handling, Personnel Security, Physical/Environmental Security
and

Awareness/Training/Education. Planning guidance is contained within the
DOT H

1350.250 series of documents.

Requirements - This element focuses on the implementation,
administration,

maintenance and updating of the ISS Program, as planned, including the

specific responsibilities of the key implementers/administrators, and
their

interactions with each other. Guidance is contained within this document
(DOT

H 1350.260).

Training - The primary key to a successful ISS Program is the Awareness
and

Training of owners, managers, administrators and users of the system.

Awareness and training guidance is contained within the DOT H 1350.270
series

of documents.

In an overall sense, the objective of the DOT ISS Program is to define,

develop, implement, administer, maintain and update, as necessary, those

security controls necessary and sufficient to provide an acceptable
level of

security risk, at an acceptable level of cost, for each DOT Information

System. Security controls may be categorized as:

1\. Management Controls - Management Controls addresses security topics
that

can be characterized as managerial in nature. They are techniques and
concerns

that are normally addressed by management in an organization\'s computer

security program. In general, they focus on the management of the
computer

security program and the management of risk within the organization.

Management controls focus on the management of the computer security
system

and the management of risk for a system.

2\. Operational Controls - Operational controls address security methods
that

focus on mechanisms that primarily are implemented and executed by
people (as

opposed to systems). These controls are put in place to improve the
security

of a particular system (or group of systems). They often require
technical or

specialized expertise -- and often rely upon management activities as
well as

technical controls.

3\. Technical Controls - Technical controls focus on security controls
that the

computer system executes. The controls can provide automated protection
from

unauthorized access or misuse, facilitate detection of security
violations,

and support security requirements for applications and data. The

implementation of technical controls, however, always requires
significant

operational considerations and should be consistent with the management
of

security within the organization.

ROLES & RESPONSIBILITIES

In the generic case, there are three individuals with specific security
concerns

and responsibilities associated with each DOT Information System:

Information System Owner -- possesses overall responsibility for a DOT
Major

Application or General Support System. The System Owner's security role
and

responsibilities lie primarily in the area of Management Controls.
Detailed

security guidance for System Owners may be found in Attachment A, System

Owner's Security Handbook.

Information System Security Officer (ISSO) -- reporting to the System
Owner,

possesses overall responsibility for Information System Security. The
ISSO

therefore must be concerned with all three types of security controls,
with a

special focus on Operational Controls. Detailed guidance for ISSOs may
be

found in Attachment B, ISSO Handbook.

Information System Administrator (ISA) -- reporting to the System Owner,

possesses day-to-day operational responsibility for a Major Application
or

General Support System. The ISA's security role and responsibilities lie

primarily in the area of Technical Controls. Detailed guidance for ISAs
may be

found in Attachment C, ISA Security Handbook.

Roles and responsibilities for each of these individuals are summarized
in

Table 1.

In addition to the abovementioned individuals, other DOT employees and

organizations play a role in protecting DOT Information Systems, such as

Property Managers of Secretarial Offices or Operating Administrations,
the

Director of the Office of Security and Administrative Management,
Acquisition

and Contracting Officers, etc. Refer to DOT H 1350.2 (DIRMM) for a
complete

listing of the responsibilities of these individuals.

POSITION IMPLEMENTATION ADMINISTRATION MAINTENANCE UPDATE

System OwnerReview/Approve Security Plans

Set Implementation Priorities

Provide Overall Leadership and Direction

Verify Implementation

Execute all necessary MOUs

Analyze Patterns of Non-Compliance

Ensure Execution of Awareness & Training Programs

Monitor Effectiveness of Security Policy & Procedures

Ensure Annual Maintenance of Remediation Plans

Assess Impacts of Proposed Updates

Approve Update Plans & Schedules

ISSOLead the Establishment of the ISS Program

Ensure the Integration of Mgmt, Operational & Technical Controls

Prepare Applicable MOUs with System Owners

Ensure that New Systems meet Security Requirements

Ensue that Personnel are Cleared and have Appropriate Access

Schedule Awareness & Training Sessions

Participate in CSIRT Activities

Periodic Checks w/DOT ISSO and other Orgs regarding New Security Issues

Perform Periodic Risk Assessments

Perform Periodic Certification of Sensitive & Classified Systems

Schedule & Perform Periodic Testing of COOP & Incident Handling

Evaluate Need for Update based on Maintenance Activities, Policy

Changes, etc.

Update Security Plan as Req'd

Lead ISS Program Update Activities

ISAProperly Configure HW & SW

Set Appropriate Security Features & Controls

Assist in Computer Security Incident Response Team (CSIRT)

Implementation

Assist in Implementing Physical Controls

Implement Backup Procedures

Periodically Review Security Features & Control Settings

Periodically Check w/HW & SW Vendors Regarding Security Problems,

Patches, etc.

Participate in CSIRT

Monitor System Operation

Notify ISSO of Suspected misuse or misconduct

Establish, Manage and Close User Accounts

Ensure that Backups are Performed

Participate in Periodic Certification of Sensitive & Classified Systems

Participate in COOP & Incident Handling Testing

Install Security Patches & other Fixes as Appropriate

Assist in Preparation of COOP Updates

Periodic Update of AntiVirus SW

TABLE 1, Summary of Roles & Responsibilities

ISS PROGRAM IMPLEMENTATION

The DOT ISS Program Implementation process flow, culminating in
Information

System Accreditation and \"Authority to Operate\" is shown in Figure 1
below.

FIGURE 1, DOT ISS Implementation Process

Guidance in planning each step in the process is contained within the
DOT H

1350.250 series of document.

A. Draft Security Plan

The first step in the implementation process is the creation of a draft

System Security Plan, using the form and format presented in DOT H
1350.251

Departmental Guide to Developing an Information System Security Plan.
The

Plan should provide an overview of the security requirements of the

Information System, describe the controls in place or planned for
meeting

those requirements, and delineate responsibilities and expected behavior
of

all individuals who access the system. Initially, not all areas of the
Plan

may be definable, but as the implementation process progresses, these
areas

may be backfilled. The intent is that the Security Plan be a 'living

document', that will always reflect the current security posture of the

Information System (Major Application or General Support System) it was

originally created for.

B. Risk Assessment

Risk Assessment is a formalized process for identifying, analyzing and

interpreting the risks associated with an Information System, as defined
in

DOT H 1350.252 Departmental Guide to Risk Assessments. Its purpose is to

provide management with a clear picture of the current overall security

posture of the target System, and provide the data necessary for them to

make informed decisions regarding the need for additional Risk
Mitigation.

C. Risk Mitigation

Categories of Risk Mitigation include Management, Operational and
Technical

Controls. The specific controls required within each category will
depend on

the results of the Risk Assessment, and the ensuing management decisions

regarding which risks require mitigation, and which risks can reasonably
be

assumed.

D. System Certification

System Certification includes the process of reviewing all existing
System

Security documentation and performing a System Test & Evaluation (ST&E)
of

all system safeguards and countermeasures identified in the System
Security

Plan, followed by a Certification that all such documentation and

countermeasures have been validated and proven to be effective. Should
the

documentation review or ST&E uncover a problem with a particular system

safeguard, that problem must be attended to prior to receiving

Certification. Refer to DOT H 1350.253 Departmental Guide to

Certification/Accreditation of Information Systems for additional
guidance on System Certification.

E. Final Security Plan

With System Certification achieved, the System Security Plan is then
updated

to reflect all in-place Management, Operational and Technical Controls,
as

well as the responsibilities and expected behavior of all individuals
who

access the System. The Final Plan becomes the key document comprising
the

Accreditation Package reviewed by the Designated Accreditation
Authority.

F. System Accreditation

The final step in the implementation process is to obtain System

Accreditation from the DOT Designated Accreditation Authority (DAA). In

order for the DAA to evaluate the overall security posture of the
System,

he/she will review a prepared Accreditation Package, containing all

information and documents necessary to make a sound, well-informed

determination of the General Support System or Major Application to
operate,

while still ensuring the confidentiality, availability and integrity of
the

information processed, stored or disseminated therein. Refer to DOT H

1350.253 Departmental Guide to Certification/Accreditation of
Information

Systems for specific guidance in preparing an Accreditation Package.
Once the DAA has reviewed the Package, and signed an Accreditation
Statement, the Information System is given an 'Authority To Operate'.

ISS PROGRAM ADMINISTRATION

Emplacing an Information System Security Program for a DOT Major
Application or

a General Support System is necessary, but not sufficient to ensure
continuing

protection of that System. Once put in place, the Program requires
continuing

administration, as well as maintenance and updates. The lead individual
for ISS

Program Administration is the ISSO, supported by the ISA as appropriate,
both

reporting to the System Owner. Note that if an ISSO is assigned more
than one

Major Application or General Support System, he/she may be required to
interface

with multiple ISAs in administering the organization's ISS Program.

ISS Program Administration encompasses both the \"everyday\" planned
tasks

associated with Information Protection (e.g., opening and closing user
accounts,

scheduling a security training course, handling the disposal of
sensitive waste)

and the unplanned security incidents and emergencies which require
immediate

attention (e.g., the activation of the CSIRT, or the COOP). Normal

administrative duties include:

Personnel -- Personnel security administration includes the control of
access

to equipment and data, as well as the hiring and termination of
employees.

Of particular significance in this regard is the issue of employee

termination. Termination of an employee, whether friendly or unfriendly,
is

a traumatic experience for most organizations. Friendly termination
refers

to the removal of an employee from the organization when there is no
reason to believe that the termination is other than mutually
acceptable.

Unfriendly termination, on the other hand, involves the removal of an

employee under involuntary or adverse conditions. Especially in the
latter

case, the potential for damage to an organization's information

infrastructure can be extremely high. Processes for handling
terminations

are discussed in DOT H 1350.256 Departmental Guide to Personnel Security
Planning.

Equipment -- Equipment security administration, includes configuration

management, physical access control and equipment inventory tracking. It

also includes the protection of System elements against damage and

destruction caused by disasters such as a major fire or loss of
supporting

utilities (refer to DOT H 1350.257 Departmental Guide to

Physical/Environmental Security Planning).

Data -- Data security administration includes the storage and control of

access to sensitive data, the proper identification/marking of data,

processes for data transportation (both within and outside of the

organization), scheduled backup of data and its subsequent storage and

retrieval, and the proper disposal of data (including data on magnetic

media). Since many of these areas are the responsibility of the System
user,

they are discussed in detail in DOT H 1350.272 Guide to Information
Protection for Users.

For a detailed description of ISS Program Administration activities, in
terms of

System Owner, ISSO and ISA duties and responsibilities, refer to the
appropriate

Sections within Attachment A (System Owner's Security Handbook),
Attachment B

(ISSO Handbook) and Attachment C (ISA's Security Handbook) to this
Guide.

ISS PROGRAM MAINTENANCE AND UPDATE

In order to ensure that the level of Information Protection remains as
high as

when the ISS Program was first initiated, System Owners, ISSOs and ISAs
must

institute an aggressive set of proactive maintenance and update
procedures.

Focusing solely on reacting to security issues, incidents and problems,
while

absolutely necessary, is not sufficient by itself to cope with the
ever-changing

environment under which DOT Information Systems must operate. Proactive
measures

emphasize:

Periodic Test & Evaluation of Existing Security Practices and Procedures
--

Specific security practices and procedures (e.g., COOP, Incident
Handling,

Security Awareness Techniques) require periodic test & evaluation, not
only

to maintain consistent levels of training, but also to assess continuing

applicability and effectiveness, in light of planned and unplanned
changes

to the overall system environment.

Continual Evaluation of Announced Changes, Updates and Enhancements to

Existing Security Products -- Equipment manufacturers are constantly
seeking

ways to improve their security products, and to correct problems that
may

have been uncovered during actual product use. ISAs and ISSOs must
maintain

an awareness of both existing and planned changes, assess the impact of

these changes on current System Technical and/or Operational Controls,
and

provides System Owners with recommendations regarding product updates.

Evaluation of 'Lessons Learned' -- The ability of existing System
Security

Controls to adequately handle actual security incidents, issues and
problems

requires continual evaluation by System Owners, ISSOs and ISAs. It is

important to be able to identify what works well, and what doesn't work

within the existing ISS Program, and be able to learn from both. The ISS

program should include the ability to archive lessons learned from

day-to-day ISS Program Administration, which may then be periodically

assessed by the appropriate individual or individuals. Note that
assessment

should be done both on a case-by-case basis, and by grouping like
incidents.

The latter technique helps to identify trends that might not otherwise
be

evident from the review of a single security incident.

Periodic Review of New Security Technology -- In addition to other
proactive

measures, both the ISSO and ISA should periodically review public, legal
and

vendor information sources regarding intruder trends, new virus strains,
new

attack scenarios and new tools that could improve the effectiveness of
DOT security controls.

In addition to proactive maintenance/update practices, there are
specific

\"trigger\" events that require the initiation of maintenance and/or
update

actions. These include:

Planned Changes to Information System Architecture and/or Operation --

Whenever a significant change is contemplated for a Major Application or

General Support System, \-\-- where significant is defined as
potentially

impacting the effectiveness of existing Security Controls, \-\-- the
ISSO must

initiate a new Risk Assessment. Should the results of the Risk
Assessment

indicate the need for changes to the existing ISS Program, the

recommendations should be presented to senior management for action.

Identified Security Shortfall -- A major security incident, or an
emergency

(man-made or natural) requiring the initiation of the COOP will often

uncover problems with the existing security posture of the affected

Information System. If the severity or impact of the incident or
emergency

was severe, a new risk assessment for the Information System should be

considered. In other cases, a change to policy or procedures, or the

addition of a new security tool may be sufficient to mitigate the
uncovered

risk. In either case, the ISSO should take the lead in responding to
such

\"trigger\" events.

Periodic Review of \"Authority to Operate\" -- The \"Authority to
Operate\"

granted by the DAA should be reviewed at least every three years (or
sooner,

depending on the level of risk and the potential magnitude of harm).
This

review becomes, in effect, a total reaccreditation, including risk

assessment, risk mitigation, and recertification processes. In such

instances, the same process utilized for the original accreditation
should

be followed. A successful reaccreditation should result in a renewed

\"Authority to Operate\".

ATTACHMENT A - SYSTEM OWNER'S SECURITY HANDBOOK

ATTACHMENT B - INFORMATION SYSTEMS SECURITY OFFICER HANDBOOK

INTRODUCTION

1.1 Purpose

This Attachment provides specific guidance to Department of
Transportation

(DOT) Information System Security Officers (ISSOs) for implementing and

maintaining the security of their assigned Information System(s).

1.2 References

All references and terms used in this document are listed and explained
in DOT

H 1350.2.1, ISS References/Definitions, dated March 3, 1999.

OPERATIONAL ENVIRONMENT

In order to implement an effective Information System Protection
Program, the

ISSO must have a clear understanding of that System's operating
environment, to

include the overall mission, floor layout, hardware configuration,
software,

type of information processed, user organizations and security
clearances,

operating mode, interconnections to other systems/networks of users,
their

security personnel, and associated responsibilities. The ISSO should
refer to

the appropriate Information Systems Security Plan for detailed data
regarding

the System's operating environment, to include the System's mission,
floor

layout, software, information types, user organizations, operating mode
and

interconnections to other systems and/or networks.

ISSO AREAS OF RESPONSIBILITY

This Section defines the ISSO's areas of responsibility, as regards the

security of assigned information systems, in accordance with DOT H
1350.2 and

NCSC-TG-027 (the Turquoise Book). The ISSO should remember, however,
that the

responsibility for information security rests with all users of DOT

information systems, and not just with its security personnel. Refer to
DOT H

1350.2 (DIRMM), Section 7.i for a specific listing of ISSO
responsibilities.

3.1 Security Regulations and Policies

The ISSO shall be aware of all directives, regulations, policies, and

guidelines that address the protection of classified information, as
well as

sensitive unclassified information. The ISSO shall also participate in
the

development or revision of System-specific security safeguards and local

operating procedures that are based on the above regulations. The
overall

system security document is the Information System Security Plan, which

contains all necessary security procedures, instructions, operating
plans, and

guidance.

The ISSO shall also provide input to other security documents, for
example,

security incident reports, equipment/software inventories, operating

instructions, technical vulnerability reports, and contingency plans.

3.2 Mission Needs

The ISSO shall understand the goals and objectives of his/her
organization,

and the security resources required to support the accomplishment of
these

goals. Requirements may be identified by analyzing current capabilities,

available resources, facilities, funding, and technology base, and by

determining whether they are sufficient to fulfill the organization's
mission.

If not, mission needs should be evaluated and prioritized and a
remediation

plan developed to address these needs. Because security requirements
should be

included in the mission needs and current assets assessment, it is
important

for the ISSO to become involved in the mission definition process.

3.3 Physical Security Requirements

In general, physical security addresses the security of the facility
that

houses the components of the assigned Information System(s), the
personnel

that operate it, and the information processed thereon. Physical
security also

addresses contingency plans, and the maintenance and destruction of
storage

media and equipment. These physical safeguards must meet the minimum

requirements established for the highest classification of data stored
at the

site. The ISSO, in coordination with DOT security personnel, is
responsible

for ensuring that all necessary physical safeguards are in place.

3.4 Continuity of Operations Plans

A Continuity of Operations Plan (COOP) documents emergency response,
backup

operations, and post-disaster recovery procedures. The ISSO provides
technical

contributions concerning the overall security plans, to ensure the

availability of critical resources and to facilitate system availability
in an

emergency situation. It is also important that all responsibilities
under the

plan are adequately documented, communicated, and tested at a minimum,
twice

per annum. Specific ISSO responsibilities during an emergency in which
the

COOP has been invoked are detailed within that document.

3.5 Declassification And Downgrading Of Data And Equipment

Declassification is a procedure and an administrative action to remove
the

security classification of the subject media. Downgrading is a procedure
and

an administrative action to lower the security classification of the
subject

media. The procedural aspect of declassification is the actual purging
of the

media and removal of any labels denoting classification, possibly
replacing

them with labels denoting that the storage media is unclassified. The

procedural aspect of downgrading is the actual purging of the media and

removal of any labels denoting the previous classification, replacing
them

with labels denoting the new classification. The administrative aspect
is

realized through the submission to the appropriate authority of a
decision

memorandum to declassify or downgrade the storage media.

Even if the assigned Information System(s) carries only SBU data, the
ISSO

should nonetheless be familiar with declassification and downgrading

procedures. Should it ever become necessary to handle classified data,
the

ISSO must ensure that:

Purging, declassification, and downgrading procedures are developed and

implemented

Procedures are followed for purging, declassifying, downgrading, and

destroying storage media.

Procedures are followed for marking, handling, and disposing of the

computer, its Peripherals, and removable/non-removable storage media.

Any special software needed to overwrite the site-unique storage media
is

developed or acquired.

Any special hardware, such as degaussers, is available.

3.6 Administrative Security Procedures

Administrative security includes the preparation, distribution, and

maintenance of plans, instructions, guidelines, and operating procedures

regarding security of information systems. It is the responsibility of
the

ISSO to assist in the development of system administrative procedures,
if

required, and to conduct periodic reviews to ensure compliance.

3.6.1 Personnel Security

One component of administrative security is personnel security. In
general, it

is the ISSO's responsibility to:

Ensure that all personnel and, when required, specified maintenance

personnel who install, operate, maintain, or use the system, hold the
proper

security clearances and access authorizations.

Ensure that all Information System users, including maintenance
personnel,

are educated as regards applicable security requirements and

responsibilities.

Maintain a record of valid security clearances, physical access

authorizations, and System access authorizations for personnel using the

System.

Ensure that maintenance contractors who work on the system are
supervised by

an authorized, knowledgeable person.

The ISSO is responsible for performing the following tasks whenever any
System

user\'s access is terminated. Prompt action is required, \-\--
particularly if

the termination or knowledge of the pending termination might provoke a
user

to retaliate.

The ISSO performs the following in support of this task:

Removes the user from all access lists, both manual and automated.

Ensures that the ISA has assigned the user's files to a supervisor,

eliminating the access by the user but allowing the supervisor to
maintain

availability.

Ensures that the ISA has removed the individual\'s ID and password from
all

systems.

Ensures that the individual has turned in all keys, tokens, or cards
that

allow access to the System.

Ensures that the combinations that the individual possessed for any

combination locks associated with the System and its physical space are

changed.

3.6.2 Security Incident Handling

A security incident occurs whenever DOT information is compromised, when
there

is a risk of compromise of such information, when recurring or
successful

attempts to obtain unauthorized access to the System is detected, or
where

misuse of the System is suspected.

The ISSO creates a reporting mechanism, as part of the security incident

reporting procedure, for System users to keep them informed of

security-relevant activity that they may observe on the System. This
reporting

mechanism shall not use the System itself to report security-relevant
activity

about the System.

The mechanism, at a minimum, includes the following:

Description of incident.

Identification of the individual reporting the security incident.

Identification of the loss, potential loss, access attempt, or misuse.

Identification of the perpetrator (if possible).

Notification of appropriate security and management personnel and civil

authorities, if required.

Reestablishment of protection, if needed.

Restart of operations, if the system had been taken down to facilitate
the

investigation

The ISSO performs the following in support of this task:

Prepares procedures for monitoring and reacting to system security
warning

messages and reports.

Develops, reviews, revises, and submits for approval to the DAA and
System

Owner procedures for reporting, investigating, and resolving security

incidents.

Immediately reports security incidents through the appropriate security
and

management channels. The ISSO submits an analysis of the security
incident

to the appropriate CSIRT authority for corrective and disciplinary
actions.

Performs an initial evaluation of security problems, and, if necessary,

temporarily denies access to affected systems. The ISSO ensures that the

Information System Administrator (ISA) evaluates, reports, and documents

System security problems and vulnerabilities.

Partially or completely suspends operations if any incident is detected
that

affects security of operations. This would include any system failure.

(Note: this may be unrealistic if the system performs a critical
operational

mission. Alternative procedures may be required in this situation. The
DAA

must weigh the risk of a security incident against the potential damage
in

shutting down the System.)

Ensures that all cases of actual or suspected compromise of classified
or

SBU passwords are investigated.

Ensures that occurrences within the System that may affect the integrity
and

security of the data being processed are investigated. If the system

malfunctions, it is important to account for the data.

Assists the investigating officials in analyzing actual or suspected

compromises of classified or SBU information, if applicable.

3.7 Security Awareness and Training

Because personnel are an integral part of the security protection
surrounding

the assigned Information System(s), they must understand the
vulnerabilities,

threats, and risks inherent with System usage. Therefore, information
system

security shall be included in briefings given to all new personnel. To

reinforce this initial training and to introduce new concepts, periodic

training and security awareness programs should be conducted. The ISSO
shall

continue training to keep current in security products and procedures.
The

ISSO is responsible for ensuring that:

All personnel (including management) have computer security awareness

training and have read applicable sections of the Information System

Security Plan and DOT H 1350.272 Guide to Information Protection for

Users. This includes training in security procedures and the use of

security products.

All users are educated regarding password management (e.g., generating

unique passwords, keeping passwords adequately protected, not sharing

passwords, and changing passwords on a regular basis).

Users understand the importance of monitoring their successful and

unsuccessful logins, if possible. If these do not correspond to the
user\'s

actual usage, the user should know the proper procedures for reporting
the

discrepancy.

Note that new personnel could include contractors newly assigned to work
at a

DOT facility. Such individuals should become familiar with DOT H
1350.273

Guide to Information Protection for Contractors.

The ISSO can keep users informed about security in many different ways.
Some

approaches include:

Periodically display messages when the user logs on to the System.

Develop and distribute security awareness posters to foster interest.

Disseminate new security information about the System and issue reminder

notices about protection procedures.

Issue memos or e-mail to notify users of changes.

Provide \"hands-on\" demonstrations of System security features and

procedures.

Security awareness and training is one of the most important features
that an

ISSO can implement. When security is kept prevalent in an individual's
mind

through regular awareness and training, those individuals are more
likely to

follow the appropriate standards and guidelines.

3.8 Security Configuration Management

Configuration management controls changes to system software, hardware,
and

documentation throughout the life of the System. This includes the
design,

development, testing, distribution, and operation of modifications and

enhancements to the existing System. The ISSO or other designated
individual

aware of the security issues shall be included in the configuration
management

process to ensure that implemented changes do not compromise security.
It is

particularly important for the ISSO to review and monitor proposed
changes to

the System as defined in the security architecture. Appropriate tests
should

be conducted to show that the System functions properly after changes
are made

to it. Configuration management tasks that are the responsibility of the
ISSO

are as follows:

Maintain an inventory of security-relevant hardware and
security-relevant

software and their locations.

Maintain documentation detailing the System hardware and software

configuration and all security features that protect it.

Evaluate the effect on security of proposed centrally developed and

distributed and site-unique modifications to software and applications.

Submit comments to appropriate personnel.

Identify and analyze System malfunctions. Prepare security incident

reports.

Assist in the development of System development notifications and System

change proposals.

Monitor DAA-approved site procedures for controlling changes to the

current System.

Ensure that any System connectivity is in response to a valid
operational

requirement.

Ensure that continuing tests of the site security features are
performed,

and maintain documentation of the results.

Coordinate System security changes with the System Owner and ISA. Review

all site configuration changes and System component changes or

modifications, to ensure that System security is not compromised.

Review physical inventory reports of security-relevant System equipment.

The ISSO ensures that the design and development of new System
equipment, or

the maintenance or replacement of existing equipment includes security

features that will support certification and accreditation or

re-accreditation. In support of this effort, informal reviews with the
System

Owner and/or ISA can help identify potential problems, thus enabling
potential

security risks to be identified early. Before installing any new system

release, the ISSO shall complete sufficient testing to verify that the
system

meets the documented and approved security specifications and does not
violate

existing security policy. The ISSO shall, at a minimum, observe the
testing of

new releases. Specific ISSO tasks include:

Ensure that all security-relevant development and planning activities
are

reviewed and approved.

Participate in the acquisition planning process for proposed
acquisitions

to ensure that DOT security policy has been considered. This applies to

both the acquisition of new systems or the upgrade of existing systems.

Ensure that security features are in place (by testing) to prevent

applications programs from bypassing security features or from accessing

sensitive areas of the system.

Develop procedures to prevent the installation of software from

unauthorized or questionable sources.

Ensure that System support personnel know how to install and maintain

security features.

3.9 Access Control

In this Section, access is considered from three different perspectives:

physical access to the Information System facility (facility access),
logical

access to the System (identification and authentication), and logical
access

to the System's data files and other objects (data access). Each of
these

perspectives is discussed separately in the following paragraphs.

3.9.1 Facility Access

Procedures shall be developed for controlling access to the System
Computer

Room and the System\'s resources. In accordance with applicable security

policy, System access shall be denied to any user, customer, or visitor
who

has not been granted specific authorization. General guidance for the
ISSO

includes:

Establish procedures to ensure that only personnel who have a
need-to-know

have access to classified or sensitive but unclassified information.

Establish procedures to ensure that only personnel who have the proper

clearances and formal access approval are allowed physical access to the

System Computer Room. All individuals who have routine access to the

Computer Room should be properly cleared and have a valid operational

requirement for access.

Deny access to any user, customer, or visitor who is unauthorized or

suspected of violating security procedures.

Ensure all visitors are signed-in and escorted, if necessary. Visitors
shall

be under visual observation by an authorized person.

Keep records of maintenance performed in the System Computer Room.

Establish and implement procedures to control System equipment coming
into

and going out of the Computer Room and telephone closets.

Ensure that an authorized, knowledgeable person supervises maintenance

contractors who work on the System.

3.9.2 Identification and Authentication (I&A)

The identification component of an I&A system consists of a set of
unique user

identifiers. Authentication involves verifying the identity of a user.
If a

user\'s identifier does not remain unique, a subsequent user may gain
the

access rights of a previous user on the system. General guidance to the
ISSO

includes:

Ensure that the databases required to support the I&A function are

accessible only by the ISSO.

Obtain a list of all identifications (IDs) preset at the factory. Change

or delete all user IDs and passwords that come with vendor software to

prevent unauthorized access.

Default passwords shall be checked and changed, as necessary, during

System installation and modification, when the ISSO first assumes

responsibility for the System, and after any maintenance to the System.

Together with the ISA, develop and administer a password management
system

that includes the generation of System passwords and the development of

procedures for addressing password loss or compromise.

Ensure that only authorized persons execute System utility programs and

routines that bypass security checks or controls.

Maintain a System user list that contains the name, user ID, access
level,

and whether the user is to have operator or administrative privileges.

3.9.3 Data Access

The focus of data access procedures is to prevent disclosure of
information to

unauthorized individuals. General guidance for the ISSO includes:

Ensure that the System-specific discretionary access control policy is

defined and implemented. The policy should define the standards and

regulations that the ISSO must implement to ensure that data is
disclosed

only to authorized individuals.

Control access to all functions that can affect the security or
integrity

of the System. Access of this type shall be kept to the absolute minimum

number of personnel.

Ensure that any required access control software subsystems or other

security subsystems are installed and operated in a manner that supports

the security policy of the System.

3.10 Risk Management

Risk management identifies, measures, and minimizes the effect of
uncertain

events on System resources. Risk management determines the value of the
data,

what protection already exists, and how much more protection the System
needs.

The process includes risk analysis, cost benefit analysis, safeguard
selection

and implementation, appropriate security tests, and systems review. Risk

management is an ongoing process that will reaffirm the validity of
previous

analysis. The ISSO supports the risk management process by performing
the

following tasks:

Assist in the development of the risk management plan.

Perform a risk assessment and analysis every three years, at a minimum,
by

analyzing threats to and vulnerabilities of the System Facility and

vulnerabilities in relationship to the sensitivity of the information on

the System. Document the results and prepare appropriate
countermeasures.

(This is expanded below.)

Ensure that a contingency plan is in place for continuity of operations
in

an emergency situation, and that the developed plans are tested
annually,

at a minimum.

Ensure that approved countermeasures are implemented.

Periodically review the risk assessment for new threats due to a changed

configuration or changes in the operational environment, and review

contingency plans to ensure that they are still applicable.

Ensure that risk analysis, security tests, TEMPEST tests, and other

inspections are conducted as required. Maintain a file of working papers

concerning risk analysis, security tests and other facets of the risk

management program.

Maintain a file of all site security-related waivers.

The ISSO documents and reports detected computer security technical

vulnerabilities. The report includes information regarding technical
solutions

or administrative procedures implemented to reduce the risk. Each ISSO

administers the technical vulnerability reporting program and:

Reports identified technical vulnerabilities. As a further way of
sharing

information about vulnerabilities, maintains contact with other system

security officers and with other users of the same type of system.

Assumes responsibility for recommending any necessary and feasible
action

to reduce risks presented by the vulnerabilities.

Develops local procedures for reporting and documenting technical

vulnerabilities, and ensures that all users and operators receive
training

for carrying-out the procedures.

Ensures that vulnerability information is properly classified and

protected.

3.11 Audits

The ISSO has the primary responsibility to conduct security audits for

operational systems as well as for systems under development. Monitoring
of

variances in security procedures is also important and is best
controlled by

the ISSO. As part of variance monitoring, the ISSO reviews any relevant
audit

trail data from the system. Finally, the ISSO provides senior management
with

reports on the effectiveness of security policy, with identification of

weaknesses and recommendations for improvements.

3.11.1 Audit Trails

The audit trail provides a record of System security-related activity
and

allows the ISSO and the ISA to monitor activities on the System. To be
an

effective security tool, the audit trail should be able to monitor, for

example, successful and unsuccessful access attempts, file accesses,
type of

transaction, and password changes. If manual audits are necessary, the
ISSO

shall document random checks made to verify that users are recording
system

usage. Audit trail files must be protected to prevent unauthorized
changes or

destruction.

3.11.2 Auditing Responsibilities

Appropriate audit trail data shall be reviewed by the ISSO. System audit

reports can provide detailed information on network traffic and provide

summary accounting information on each user ID, account, or process. The

responsibilities of the ISSO include:

Review specifications for inclusion of audit trail reduction tools that
will

assist in audit trail analysis.

Select security events to be audited. Ensure that the audit trail is

reviewed and have the capability to audit every access to controlled
system

resources (e.g., very sensitive files).

Archive audit data.

Develop and implement audit and review procedures to ensure that all
System

functions are implemented in accordance with applicable policies and

programs. Existing policies and programs usually establish the minimum

amount of material that shall be audited.

Conduct audits and maintain documentation on the results.

Supervise review of security audit parameters. Develop, review, revise,

submit for approval, and implement procedures for monitoring and
reacting to

security warning messages and reports.

Conduct random checks to verify compliance with the security procedures
and

requirements of the site.

Gather information from audit trails to create profiles of system users.

Observe user patterns such as the terminal usually used, files accessed,

normal hours of access, and permissions usually requested, to determine

which actions are unusual and should be investigated.

Review user access reports generated by the audit trail, in compliance
with

policies and practices.

In addition, the ISSO shall review audit trail reports for anomalies:

Look for multiple unsuccessful logon attempts. This could be an
indication

of an inexperienced user, a user who has recently changed passwords and

forgotten the new one, or an attempted intrusion.

Look for an attempt by a user, who is already logged in, to log in again
to

the same system from a second computer. This could be caused by an

inadvertent failure to log out, an intentional logon to both computers,
or

could be an attempted intrusion.

Be alert to individuals logging in after normal hours. This may mean the

user has a deadline to meet and is working overtime, or that an intruder
is

attempting access.

Look for high numbers of unsuccessful file accesses. This could be
prompted

by the user's failure to remember file names, or by an attempted
intrusion.

Look for unexplained changes in system activity.

Look for covert channel activity.

3.12 Certification and Accreditation

System certification is the technical evaluation of the System\'s
security

features, including non-System security features (e.g., administrative

procedures and physical safeguards), against a specified set of security

requirements. The objective is to determine how well the System design
and

implementation meet this pre-defined set of security requirements.

Certification is performed as part of the accreditation process. System

accreditation is the formal management decision made by the DAA to
implement a

System in a specific operational environment at an acceptable level of
risk.

The certification package specifies the following in support of
accreditation:

Security mode.

Set of administrative, environmental, and technical security safeguards.

Operational environment.

Interconnections to other Major Applications or General Support Systems.

Vulnerabilities as well as procedural and physical safeguards.

The ISSO is frequently responsible for the following list of tasks in

preparation for the accreditation of a System:

Assist in preparing the accreditation material required by the DAA.

Assist in the evaluation of the accreditation package.

Assist in the site surveys.

Prepare a statement to the DAA about the certification report. The
report

should include a description of the System ans its mission; the results

from the testing, document reviews, and hardware and software reviews;

remaining system vulnerabilities; and any additional controls or

environmental requirements that may be necessary.

Ensure that the System maintains the system security baseline through

audits.

Notify the System Owner and the DAA (or the DAA\'s representative) of
all

configuration changes that may change the System\'s security baseline.

ATTACHMENT C - SYSTEM ADMINISTRATOR'S SECURITY HANDBOOK

Chapter 11- Guide for Information Protection
Awareness/Training/Education, DIRMM U.S.

DEPARTMENT OF TRANSPORTATION

OFFICE OF THE SECRETARY

DOT H 1350.270

GUIDE FOR

INFORMATION PROTECTION

AWARENESS/TRAINING/EDUCATION

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. GOALS

4\. REFERENCES

5\. OVERVIEW OF INFORMATION PROTECTION AWARENESS/TRAINING/EDUCATION

A. Background

B. Information Technology Security Learning Continuum

6\. SECURITY AWARENESS/TRAINING/EDUCATION

A. Awareness

B. Training

C. Education

GUIDE FOR INFORMATION PROTECTION

AWARENESS/TRAINING/EDUCATION

PURPOSE

The purpose of the 1350.270 series of Guides is to provide specific
guidance

on Information Protection awareness, training and education to the
Department

of Transportation (DOT) and its Operating Administrations. The series
consists

of this document, which contains an overview of the entire

awareness/training/education process, and individual documents that
treat each

major area in depth. These supplemental documents include:

1350.271 --Guide to Information Protection for Senior Management

1350.272 -- Guide to Information Protection for Users

1350.273 -- Guide to Information Protection for Contractors

1350.274 -- Guide to Information Protection Computer-Based Training

1350.275 -- Federal Information Protection Resources

SCOPE

The provisions of this document apply to all DOT employees, volunteers
and

contractor support personnel.

GOALS

The goal of this document is to improve the security of DOT Information

Systems by making DOT senior management, system users and contractors
aware of

the need for, and means of protecting system resources. This task is

accomplished in three phases \-\-- security awareness, training and
education.

REFERENCES

All references and terms used in this document are listed and explained
in DOT

H 1350.2.1, ISS References/Definitions, dated March 3, 1999.

OVERVIEW OF INFORMATION PROTECTION AWARENESS/TRAINING/EDUCATION

Background

The Computer Security Act requires federal agencies to provide for the

mandatory periodic training in computer security awareness and accepted

computer security practices for all employees who are involved with the

management, use, or operation of a federal computer system within or
under

the supervision of the federal agency. This includes contractors as well
as

employees of the agency.

The Computer Security Act also charged the National Institute of
Standards

and Technology (NIST), together with the U.S. Office of Personnel
Management

(OPM), with developing and issuing guidelines for Federal computer
security

training. This requirement was satisfied by NIST\'s issuance of Computer

Security Training Guidelines\" (Special Publication \[SP\] 500- 172), in

November 1989. In January 1992, OPM issued a revision to the Federal

personnel regulations, which made these voluntary guidelines mandatory.
This

regulation, Employees Responsible for the Management or Use of Federal

Computer Systems, requires Federal agencies to provide training as set
forth

in the NIST guidelines.

OMB Circular A-130, Appendix III, issued in 1996, enforced such
mandatory

training by requiring its completion prior to granting access to the
system,

and through periodic refresher training for continued access. OMB
Circular

A-130 also required NIST to update SP 500-172, and as a result, NIST
created

SP 800-16, Information Technology Security Training Requirements: A
Role-

and Performance-Based Model.

Information Technology Security Learning Continuum

SP 800-16 presents a new conceptual framework for providing IT security

training. This framework includes the IT security training requirements

appropriate for today's distributed computing environment and provides

flexibility for extension to accommodate future technologies and the
related

risk management decisions. Figure 1 illustrates this new concept.

Figure 1. The Information Technology Security Learning Continuum

The Security Learning Continuum flows from the bottom of the model
towards

the top. At the lowest level, all agency managers, employees and
contractors

require security awareness. Training (represented by the two bracketed

layers \"Security Basics and Literacy\" and \"Roles and Responsibilities

Relative to IT Systems\") is required for individuals whose role in the

organization indicates a need for special knowledge of IT security
threats,

vulnerabilities, and safeguards. The \"Security Basics and Literacy\"
category

is a transitional stage between \"Awareness\" and \"Training.\" It
provides the

foundation for subsequent training by providing a universal baseline of
key

security terms and concepts. After \"Security Basics and Literacy,\"
training

becomes focused on providing the knowledge, skills, and abilities
specific

to an individual's IT system roles and responsibilities.

At this level, training recognizes the differences between beginning,

intermediate, and advanced skill requirements. Finally, the \"Education
and

Experience\" layer applies to those individuals who have made IT
security

their chosen profession. This top level focuses on developing the
ability

and vision to perform complex multi-disciplinary activities and the
skills

needed to further the IT security profession, and to keep pace with
threat

and technology changes.

In essence, Awareness is the \"What\", Training is the \"How\", and
Education is

the \"Why\" of Information Protection.

Security Awareness/Training/Education

DOT H 1350.258, Departmental Guide to Developing an Information System

Security Awareness/Training/Education Program, provides overall guidance
for

DOT management in planning and establishing security

awareness/training/education programs. In the 1350.270 series of Guides,
the

emphasis is on security awareness/training/education program
implementation.

To successfully implement an awareness and training program, it is
important

to gain the support of both management and employees. Consideration
should

be given to using motivational techniques to show management and
employees

how their participation in the program will benefit DOT. In addition,
since

IT is an ever-changing field, efforts should be made to keep abreast of

changes in it, as well as changes in security requirements. An

awareness/training/education program that meets an organization\'s needs

today may become ineffective when the organization starts to use a new

application or changes its environment, such as by connecting to the

Internet. Likewise, an awareness program can become obsolete if laws or

organization policies change.

Finally, it should be recognized that it is often difficult to measure
the

effectiveness of an awareness or training program. Nevertheless, an

evaluation should always be attempted, in order to ascertain how much

information is retained, to what extent computer security procedures are

being followed, and general employee attitudes toward computer security.
The

results of such an evaluation should help identify and correct problems.

Some evaluation methods (which can be used in conjunction with one
another)

include student evaluations, observing how well employees follow
recommended

security procedures, testing employees on material covered, and
monitoring

the number and kind of computer security incidents reported before and
after

the program is implemented

Awareness

Awareness stimulates and motivates those being trained to care about

security and to remind them of important security practices. Explaining
what

happens to an organization, its mission, customers, and employees if

security fails, motivates people to take security more seriously.
Awareness

must be used to reinforce the fact that security supports the mission of
the

organization, by protecting valuable resources. If employees view
security

as just bothersome rules and procedures, they are more likely to ignore

them. In addition, they may not make needed suggestions about improving

security, nor recognize and report security threats and vulnerabilities.

Awareness can take on different forms for particular audiences.
Appropriate

awareness for management officials might stress management\'s pivotal
role in

establishing organizational attitudes toward security. Appropriate
awareness

for other groups, such as system programmers or information analysts,
should

address the need for security as it relates to their job. Note that

contractor employees are required to receive the same level of automated

information systems security awareness as federal employees. Hence
security

awareness requirements should be included, as appropriate, in all DOT

contracts. Remember, in today\'s systems environment, almost everyone in
an

organization may have access to system resources, and therefore may have
the

potential to cause harm.

Awareness is a concern for DOT senior management, users (including
managers)

and contractors. Refer to DOT H 1350.271 Guide to Information Protection
for

Senior Management, DOT H 1350.272 Guide to Information Protection for
Users,

and DOT H 1350.273 Guide to Information Protection for Contractors for

additional information and guidance.

Training

The purpose of training is to teach people the skills that will enable
them

to perform their jobs more securely. This includes teaching people both
what

they should do and how they should (or can) do it. Training can address
many

levels, from basic security practices to more advanced or specialized

skills. It can be specific to one computer system or generic enough to

address all systems. A security training program normally includes
training

classes, either strictly devoted to security, or as added special
sections

or modules within existing training classes. Training may be computer-
or

lecture-based (or both), and may include hands-on practice and case
studies.

Computer-based Training (CBT), in particular, is an important technique
for

learning about Information Protection, and forms the backbone of DOT's

approach to training. Refer to DOT H 1350.274 Guide to Information

Protection Computer-Based Training for additional information on DOT's
CBT

Program.

Education

Security education is more in-depth than security training and is
targeted

for security professionals and those employees whose jobs require
specific

expertise in security disciplines. Most federal agencies, including DOT,
do

not develop and present their own set of Information Protection
Education

classes. There are organizations within the federal government that are

dedicated to providing these services, which is a much more efficient
and

cost-effective approach. Refer to DOT H 1350.275 Federal Information

Protection Resources for information concerning these organizations, the

classes they make available, and specific dates and locations of each
class.

Chapter 11- Guide to Information Protection for Users, DIRMM U.S.
DEPARTMENT OF

TRANSPORTATION

OFFICE OF THE SECRETARY

DOT H 1350.272

GUIDE TO

INFORMATION PROTECTION

FOR USERS

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. GOALS

4\. REFERENCES

5\. OVERVIEW -- THE NEED FOR INFORMATION PROTECTION

A. Background

B. What Information Protection Means To You

6\. DOT SYSTEM USER RESPONSIBILITIES

A. Procedural Security

B. Data Security

C. Communications Security

1\) Use of the Internet

2\) Use of E-mail

D. Physical Security

7\. PERSONAL LIABILITY

GUIDE TO INFORMATION PROTECTION

FOR USERS

PURPOSE

The purpose of this Guide is to provide DOT employees, including
managers,

technical staff and administrative staff, with an increased level of
awareness

of the importance of information system security, and provide specific

guidelines for safeguarding data and information as a part of performing

day-to-day workplace activities.

SCOPE

The provisions of this document apply to all DOT employees, volunteers
and

contractor support personnel.

GOALS

The goal of this document is to improve the security of DOT Information

Systems by motivating system users to not only be aware of the need for

protecting system resources, but also to identify specific means of
protecting

system resources that relate to their job.

REFERENCES

All references and terms used in this document are listed and explained
in DOT

H 1350.2.1, ISS References/Definitions, dated March 3, 1999.

OVERVIEW -- THE NEED FOR INFORMATION PROTECTION

Background

Hundreds of Information Systems operate within DOT, processing both
classified

and sensitive but unclassified (SBU) information. These systems are
vulnerable

to attacks by insiders, computer hackers, hostile intelligence agents,
thieves,

and individuals with malicious intent. Increasing reliance of most DOT

activities on computers and computer networks has made security of these
assets

a major issue, both in terms of the safeguarding of the systems
themselves, and

most importantly, the data being transported, processed and/or stored on
them.

DOT's Information Protection Program, as defined in the 1350.2 Series of
Guides,

is a unified approach to protecting classified and SBU information, and
has been

established to consolidate and focus DOT efforts in securing that
information,

and its associated systems and resources. A key element of this Program
consists

of Information Protection awareness, training and education. Awareness

stimulates and motivates those being trained to care about security and
to

remind them of important security practices. The purpose of training is
to teach

people those skills that will enable them to perform their jobs more
securely.

This includes teaching people both what they should do and how they
should (or

can) do it. Security education is more in-depth than security training
and is

targeted for security professionals and those employees whose jobs
require

specific expertise in security disciplines.

What Information Protection Means To You

As a DOT employee, you have been entrusted with departmental
information. With

this trust comes the responsibility and obligation to ensure that the

information is used only for its intended business purpose. The
responsibility

is great. We use information on a day-to-day basis that if misused,
could prove

embarrassing to the government, public corporations or individuals, or
lead to

litigation.

It is, therefore, very important that you understand and comply with all
DOT

security policies and procedures. Failure to do so may subject you to

disciplinary action and penalties under the law. DOT Information System
Security

policy and procedures may be found in DOT H 1350.2 DOT Information
Resources

Management Manual (DIRMM), and in this Guide. Before you begin your use
of DOT

Information Systems, be sure that you understand and comply with all
security

requirements. Ask your Information Systems Security Officer (ISSO) if
you have

any questions.

The remainder of this Guide describes what you need to know to be an
active

participant in the DOT information systems security program.

DOT SYSTEM USER RESPONSIBILITIES

At DOT, Information is one of our most valuable assets, and needs to be

protected from loss, unauthorized changes, and disclosure. It appears in
many

forms, such as:

Mainframe computer data

PC data,

Magnetic media, such as diskettes,

Printed documents,

Microfilm and microfiche, and

Conversation.

The information you use every day must be protected. Whether you work
with paper

documents or data on a PC, or spend most of your day on the phone, you
are part

of DOT's information systems security program. By preventing errors,
security

makes your job easier because you won\'t have to spend time fixing
mistakes. Good

security helps to keep your DOT missions and systems healthy by ensuring
that

the information you work with is accurate. Incorrect information can
cause DOT

to lose the confidence of the public it supports.

For ease of organization, user system security responsibilities have
been

divided into four areas: procedural security, data security,
communications

security and physical security. These are described in the following
paragraphs.

A. Procedural Security

Procedural security dictates how you operate and maintain your
individual

system, to include:

Obtaining an information systems security briefing from your ISSO before

using your equipment for the first time.

Ensuring that your equipment is maintained with care (e.g., used
properly,

kept clean, etc.). The processing environment must also be kept as clean

as possible.

Operating your equipment according to your organization's reference

manuals and posted security instructions.

Ensuring that your ISSO has approved and certified all software packages

before they are used. Personal copies of software are prohibited in the

workplace for use on Government-owned equipment.

Ensuring that no additional equipment is attached to your system without

the knowledge and written permission of your ISSO.

Honoring software copyright restrictions. No unauthorized copies of

copyrighted software may be made for office or personal use. Copyrighted

software may not be borrowed or removed from the workplace.

Not loading copyrighted software onto other systems unless authorized in

vendor agreements, approved by your supervisor, and agreed to, in
writing,

by your ISSO.

Protecting against disaster by ensuring that backup copies of
application

programs and data files are available for use. Update your backup copies

of data files regularly, and store them in a secure location separate
from

your equipment Generally, information should be duplicated if you could

not afford to lose it, it would cost too much to recreate it, or it
would

take too much time to recreate. If you are still concerned about what

should be duplicated, contact your supervisor for guidance as to exactly

what needs to be duplicated.

Safeguarding assigned user passwords. Do not reveal your passwords to

anyone, and do not store them in plain text on your equipment. If you
are

able to choose your own password(s), refer to Figure 1 for some helpful

\"dos\" and \"don'ts\".

Reporting compromised passwords to your ISSO immediately.

Protecting equipment. Keep food, drink and electrical appliances away
from

your equipment.

Protecting your equipment and data when unattended. Always log off your

system, or turn it off before leaving it unattended.

Protecting against viruses. Never bring unauthorized or personal
software

to work, and do not share diskettes unless absolutely necessary for the

mission. If you suspect that your system is infected with a virus that
has

not been detected by the internal virus protection software, notify your

ISSO immediately.

Reporting immediately any suspected system misuse or abuse to your ISSO.

Safeguarding your equipment should you need to use it outside of the

office. This is not recommended as a common practice. Personal computers

may be stolen or damaged when they are removed from the office. If you

must take equipment home, remember to get written approval from your

manager. Also, check out the process for restitution if the computer is

damaged while in your possession. Your Operating Administration\'s
policy

may require replacement of damaged or lost equipment. If your Operating

Administration has a home-use system be sure you have a building

equipment/property pass. Make sure you use a surge protector on borrowed

equipment, and use extra care to protect the equipment from loss or
theft.

Limiting your personal use of DOT equipment. DOT employees are permitted

limited use of DOT office equipment for personal needs if the use does
not

interfere with official business, does not result in loss of employee

productivity, and involves minimal additional expense to DOT. This
limited

personal use of DOT office equipment should take place only during your

non-work time. Note that this privilege to use DOT office equipment for

non-DOT purposes may be revoked or limited at any time by appropriate
DOT

officials. Note also that this privilege does not extend to modifying
DOT

equipment, including loading personal software or making configuration

changes.

Not using DOT office equipment to maintain or support a personal private

business. Examples of this prohibition include employees using a

government computer and Internet connection to run a travel business or

investment service. This ban on using DOT office equipment to support a

personal private business also includes your using DOT office equipment
to

assist relatives, friends, or other persons in such activities.

Bringing your home computer in to work is not recommended. If you are

allowed to do so, remember that your Operating Administration insurance

policy probably won\'t reimburse you for your equipment if anything
happens

to it. Also, if the equipment is stolen, your Operating Administration

will not replace it. Remember, although the computer is yours, the

information on it belongs to your Operating Administration, and must be

protected.

Here are some password choices to AVOID:

Your name, nickname, or initials,

Your user identification code (user ID),

Special dates, especially those that appear on your driver\'s

license, or on a calendar you carry in your purse or wallet,

Consecutive keys on a keyboard, e.g., QWERTY or FGHJKL,

All the same character, e.g., CCCCCC or 9999999,

Your telephone number, employee number, or social security number,

and

Words that appear in a dictionary.

Here are some suggestions for choosing a GOOD password:

Combine letters and numbers such as the name and birthdate of a

relative or friend, e.g., LISA105,

Take the first or last letters from each word of a phrase, e.g.

IWADASN (It Was A Dark And Stormy Night) or EDESOEFT (wE holD thesE

truthS tO bE selF evidenT),

Remove all vowels from a common word or words, e.g. TPSCRT (ToP

SeCReT), and

Make it as long as possible. Passwords should be at least 8

characters long.

Figure 1, Password \"Dos\" and \"Don'ts\"

B. Data Security

Sensitive and mission-critical information requires protection from

disclosure, alteration and loss. You should:

Protect data files. Establish and periodically review access privileges
for

each sensitive file.

Protect data storage media. Lock up removable media and equipment that

contains fixed media.

Not attempt to access any data on any system connected to a LAN, unless
such

access has been specifically authorized.

Label diskettes with the contents of the data stored on them, and the
name

of the application program used. Handle diskettes carefully to avoid
damage.

If you pass a diskette or other electronic media along to someone else,

reformat it first. Just deleting information does not mean that the

information has been erased. If the diskette contains highly sensitive
data,

it should never be passed along. There will be some data that can be
read

even after you have formatted the diskette.

Not process data that exceeds the accredited sensitivity level of the
LAN.

If a question exists as to accreditation level of the LAN that a user is

operating on, this information should be obtained from your supervisor
or

ISSO.

Dispose of waste containing sensitive information as if it were
classified

waste (e.g., burning or shredding). Check with your manager or
supervisor

about the approved method for disposing of trash. If your office has
such a

program, place the document in a special collection bin for sensitive
trash.

Someone else will collect it and make sure it\'s gets destroyed
properly. If

you have other media to dispose of, e.g. CD's or diskettes, check with
your

manager, supervisor or ISSO on the proper disposal methodology.

Not allow any person outside your office to access system or data unless

that person has a \"need-to-know\" that has been verified by your ISSO.

Inspect data files for tampering. If you suspect that someone has
tampered

with your files or the data in them, report it immediately to your ISSO.

Be careful when answering questions from outside individuals. Refer any

requests for information from the media (reporters) to the appropriate

people in your Operating Administration. This may be an office in charge
of

public affairs/relations or senior managers. When asked to complete a
survey

or questionnaire, ask your supervisor whether this is all right. If you

receive calls from employment search companies or vendors, take the

individual\'s name and number and pass this along to your supervisor. Do
not

allow such people to have a copy of your Operating Administration\'s
list of

employees or the DOT telephone book. This would only encourage them to
make

calls which others in your Operating Administration may not welcome.

Be wary about speaking on the telephone. When speaking on the phone, you

could easily be fooled into thinking you are talking to a person with a
real

need for some information. Be careful not to give out valuable
information

to the wrong person. Try to verify the identity of the caller. If you
can\'t

do this by asking some key question, then tell the caller, \"I will need
to

call you back on this.\" Verify the caller\'s need to know the requested

information. Be careful not to give out more information than requested.

Also, be aware of who is in the area that could overhear your
conversation.

C. Communications Security

Government telecommunications systems and information systems connected
to a

network are subject to periodic security testing and monitoring, to
ensure

that proper communications security (COMSEC) procedures are being
observed.

Therefore, use of any system with any network connection constitutes
consent

to security testing and COMSEC monitoring. An example of a Warning
Banner used

to reinforce this restriction is shown in Figure 2. As regards DOT
networks

and connected information systems, you must:

Ensure that information transmitted by modem (telecommunications) is not

classified or sensitive, and the transmission of the information type
has

been approved by your ISSO. If in doubt as to what is sensitive, consult

with your ISSO.

Turn off your system, or disconnect it from the LAN when not in use. An

active system connected to a network can be accessed, and files,

applications and even the operating system can possibly be changed
without

your knowledge.

Ensure that systems used to process 'For Official Use Only' (FOUO)

information are not left unattended.

Ensure that, in the event that you suspect that a system has been

penetrated, you should immediately contact your ISSO.

\*\*WARNING\*\*WARNING\*\*WARNING\*\*

This is a DOT computer system. DOT computer systems are provided for the

processing of Official U.S. Government information only. All data

contained on DOT computer systems may be monitored, intercepted,

recorded, read, copied, or captured in any manner and disclosed in any

manner, by authorized personnel. THERE IS NO RIGHT OF PRIVACY IN THIS

SYSTEM. System personnel may give to law enforcement officials any

potential evidence of crime found on DOT computer systems. USE OF THIS

SYSTEM BY ANY USER, AUTHORIZED OR UNAUTHORIZED, CONSTITUTES CONSENT TO

THIS MONITORING, INTERCEPTION, RECORDING, READING, COPYING, OR CAPTURING

and DISCLOSURE.

\*\*WARNING\*\*WARNING\*\*WARNING\*\*

Figure 2, Warning Banner Example

1\. Use of the Internet

The Internet is an important tool for communicating with others outside
of

DOT. But while it offers enormous benefits in terms of increased access
to

information, it also generates a plethora of professional
responsibilities

and legal issues. As an Internet user, you are therefore accountable for
the

following use standards:

Use DOT Resources for Authorized Business Functions -- It is relatively

easy for users to perceive the Internet as a public resource. You must

remember that DOT systems are available for authorized work only, \-\--
that

is, activities sanctioned by management and position functions. If you
are

uncertain about Internet use, ask your manager for specific guidance.

Avoid Offensive Material -- The Internet provides easy, efficient access
to

vast quantities of valuable information; however, it can also serve as a

conduit for information that could be considered offensive. Access to

offensive material cannot be completely filtered without impacting

performance and cost. It is therefore your responsibility to maintain a

professional work environment at all times, \-\-- immune from
harassment,

intimidation and insult.

Respect Intellectual Property -- The Internet was originally established
as

an academic resource; it was designed to facilitate uninhibited exchange

of information. Today, it exists in a more diverse and competitive

environment. Easy access to information through the Internet begets easy

reuse of information derived from Internet sources. Unknowing users
expose

themselves and DOT to liability when electronic information is reused

without regard for ownership. You should be aware of your legal
obligation

to recognize and respect the intellectual property of others. Any
original

work of authorship may be the subject of copyright protection, and can

only be copied or distributed with the permission of the copyright
owner.

Such copyright-protected subject matter includes literary text or

information, software, and graphical or pictorial works.

Safeguard Private and Personal Information -- You have a responsibility
to

respect the privacy of others, and to safeguard personal information
about

others that has been entrusted to you for legitimate work purposes. You

should not access files belonging to another user without permission,
nor

should you transmit private or personal information over insecure,
public

networks.

Obtain Public Release Authorization -- Technical information posted to

public services requires pre-publication authorization. Who authorizes

publication depends on the type of information involved. You should
always

solicit specific pre-publication guidance from your management.

Distinguish Opinion from Government Position -- If you wish to express
an

opinion on work-related subjects, you should obtain management approval,

and attach an explicit disclaimer that states the following: \"The views

expressed are those of the author, and do not reflect the official
policy

or position of the Department of Transportation, or the U.S.
Government\".

You should always express your own opinion judiciously, and refrain from

expressing personal opinion on subjects that are not work-related, such
as

politics, religion and hobbies.

Protect Information Assets -- Competitive advantage and financial
success

rely heavily on timely access to accurate information, and on protection

of sensitive information. While Internet use offers enormous advantages,

there are significant security issues associated with Internet

communications. Secure system design and other security controls help

thwart active outsider threats to computer resources, but have minimal

effect on unintentional insider threats caused by human errors,
accidents

and omissions. You may unintentionally expose Government information

systems to malicious intrusion by hackers and viruses, as well as other

security risks, needlessly impacting performance. You are therefore

responsible for implementing the security provisions shown in Figure 3.

Enforce CyberEthics -- You are required to enforce the highest standards
of

business ethics, regardless of the work environment, and to report known

and suspected violations of Government policy.

For additional guidance concerning DOT Internet policy, refer to DOT H

1350.2 (DIRMM), Chapter 14-4 Interim DOT Internet Resources Policy.

Note that it is the policy of the Government to monitor Internet use.

Similarly, electronic files may be searched by Government Officials.
Refer

to Section 7 of this Guide for a discussion of DOT user personal
liability.

2\. Use of E-mail

Electronic Mail (e-mail) is an official medium for transmitting official

correspondence, both within and outside of DOT. Official correspondence
is

defined as correspondence having as its objective the accomplishment of
DOT

missions or assignments, or the dissemination of information having
direct

bearing on the accomplishment of DOT missions, or relating to DOT

activities. If uncertain as to what constitutes official correspondence,
you

should consult with your manager for guidance. In general, you should
adhere

to the standards detailed above as regards the overall use of e-mail
within

DOT. For additional guidance concerning DOT e-mail policy, refer to DOT
H

1350.2 (DIRMM), Chapter 14-3 Electronic Mail Policy.

National Security Information is not authorized on any public system;

information systems processing classified information require Security

Accreditation prior to use.

Proprietary information and intellectual property shall not be
transmitted

over external networks unprotected; similarly, sensitive information

regarding DOT products or activities shall not be posted to open

environments, such as public news groups and bulletin boards, nor

discussed via Internet chat sessions.

Data, files and/or software from unknown or suspect sources shall not be

downloaded to Government systems.

Software that is legitimately downloaded from external sources shall be

scanned for malicious code prior to use on any Government system.

User passwords shall be protected from disclosure and changed often.

Internet access should always be accomplished through a Firewall. Access

by dual-homed devices, e.g., devices that are simultaneously connected

physically or logically to both an internal LAN and the Internet is

strictly forbidden.

DOT users shall not misrepresent themselves.

Figure 3, Internet Security Provisions

It is important to understand that e-mail is provided to DOT users for

business use. However, DOT e-mail systems may be used for incidental
personal

purposes provided that such use does not:

Directly or indirectly interfere with DOT e-mail services,

Burden DOT with noticeable incremental cost, or

Interfere with DOT user's employment or other obligations to the
Government.

Note that you may not use DOT e-mail facilities to harass, abuse or
offend

others. Engaging in any outside fund-raising activity, endorsing any
product

or service, participating in any lobbying activity, or engaging in any

prohibited partisan political activity via e-mail is also prohibited.
Note

also that transmission of classified information is expressly forbidden
on any

mail system within DOT unless that system has obtained proper security

accreditation. Check with your ISSO if you are unsure as to what level
of

sensitivity data you are permitted to transmit via e-mail.

You should be alert to two types of e-mail problems: Spoofed/Forged
e-mail and

e-mail Spamming/Bombing. E-mail spoofing may occur in different forms,
but all

have a similar result: a user receives e-mail that appears to have
originated

from one source when it actually was sent from another source. E-mail
spoofing

is often an attempt to trick the user into making a damaging statement
or

releasing sensitive information (such as passwords). Examples of spoofed

e-mail that could affect the security of DOT include:

E-mail claiming to be from a system administrator requesting users to
change

their passwords to a specified string and threatening to suspend their

account if they do not do this.

E-mail claiming to be from a person in authority requesting users to
send

them a copy of a password file or other sensitive information.

E-mail \"bombing\" is characterized by abusers repeatedly sending an
identical

e-mail message to a particular address. E-mail \"spamming\" is a variant
of

bombing; it refers to sending e-mail to hundreds or thousands of users
(or to

lists that expand to that many users). E-mail spamming can be made worse
if

recipients reply to the e-mail, causing all the original addressees to
receive

the reply. It may also occur innocently, as a result of sending a
message to

mailing lists and not realizing that the list explodes to thousands of
users,

or as a result of an incorrectly set-up responder message.

If you are in receipt of suspect e-mail, alert your ISSO immediately.

D. Physical Security

Physical security limits access to the information processing
environment, and

provides security for a user's own system, including its hardware,
software

and the data it processes. You should:

Protect your work area. Recognize, politely challenge, and assist people
who

do not belong in your area.

Limit access to your own equipment. Recognize those who are authorized
to

use, service and repair your system.

During non-working hours, and when offices are left unattended, lock
doors

to offices and rooms that house information systems equipment.

Ensure that system hardware and software are hand-receipted by serial
number

to users. Hardware and software must have an accountability chain back
to

the Property Manager.

Challenge persons carrying information systems equipment out of an
office or

building.

Not allow any information systems hardware to be moved from its
accredited

location without the knowledge and approval of your ISSO. This includes

turning in equipment for maintenance.

Remember, anyone not currently working in your office is a visitor. Use

caution when disclosing information in front of any visitor. This
includes

former employees of your Operating Administration, vendors and
salespeople,

and members of the public or other federal agencies.

PERSONAL LIABILITY

Finally, you should be aware that Federal law provides for punishment
consisting

of a fine under Title 18, U.S. Code and up to 10 years in jail for the
first

offense for anyone who:

Knowingly accesses an information system without authorization, or
exceeds

authorized access, and obtains information that requires protection
against

unauthorized disclosure. (Note that the offense is for the access, and
not

necessarily any disclosure).

Intentionally, without authorization, accesses a government information
system

and, in so doing, affects the use of the government's operation of that

system.

Intentionally accesses a government information system without
authorization,

and alters, damages or destroys information or prevents authorized use
of the

system.

Accesses a government information system without authorization, or
exceeds

authorized access, and obtains anything of value.

The above prohibitions and punishments apply to mere attempts, even if

unsuccessful, to commit the listed crimes. Multiple accesses or multiple

attempts constitute multiple offenses for the purposes of determining

punishment.

Chapter 11- Guide to Information Protectino for ContractorsU.S.
DEPARTMENT OF

TRANSPORTATION

OFFICE OF THE SECRETARY

DOT H 1350.273

GUIDE TO

INFORMATION PROTECTION

FOR CONTRACTORS

TABLE OF CONTENTS

1\. PURPOSE

2\. SCOPE

3\. GOALS

4\. REFERENCES

5\. OVERVIEW -- THE NEED FOR INFORMATION PROTECTION

A. Background

B. What Information Protection Means To You

6\. DOT CONTRACTOR RESPONSIBILITIES

A. Procedural Security

B. Data Security

C. Communications Security

1\) Use of the Internet

2\) Use of E-mail

D. Physical Security

7\. PERSONAL LIABILITY

PURPOSE

The purpose of this Guide is to provide DOT contractors with an
increased

level of awareness of the importance of information system security, and

provide specific guidelines for safeguarding data and information as a
part of

performing day-to-day workplace activities in support of DOT.

SCOPE

The provisions of this document apply to all DOT contractors.

GOALS

The goal of this document is to improve the security of DOT Information

Systems by motivating contractors to not only be aware of the need for

protecting DOT system resources, but also to identify specific means of

protecting DOT system resources that relate to their job.

REFERENCES

All references and terms used in this document are listed and explained
in DOT

H 1350.2.1, ISS References/Definitions, dated March 3, 1999.

OVERVIEW -- THE NEED FOR INFORMATION PROTECTION

Background

Hundreds of Information Systems operate within DOT, processing both
classified

and sensitive but unclassified (SBU) information. These systems are
vulnerable

to attacks by insiders, computer hackers, hostile intelligence agents,
thieves,

and individuals with malicious intent. Increasing reliance of most DOT

activities on computers and computer networks has made security of these
assets

a major issue, both in terms of the safeguarding of the systems
themselves, and

most importantly, the data being transported, processed and/or stored on
them.

DOT's Information Protection Program, as defined in the 1350.2 Series of
Guides,

is a unified approach to protecting classified and SBU information, and
has been

established to consolidate and focus DOT efforts in securing that
information,

and its associated systems and resources. A key element of this Program
consists

of Information Protection awareness, training and education. Awareness

stimulates and motivates those being trained to care about security and
to

remind them of important security practices. The purpose of training is
to teach

people the skills that will enable them to perform their jobs more
securely.

This includes teaching people both what they should do and how they
should (or

can) do it. Security education is more in-depth than security training
and is

targeted for security professionals and those employees whose jobs
require

specific expertise in security disciplines.

What Information Protection Means To You

As a DOT contractor, you have been entrusted with departmental
information. With

this trust comes the responsibility and obligation to ensure that the

information is used only for its intended business purpose. The
responsibility

is great. We use information on a day-to-day basis that if misused,
could prove

embarrassing to the government, public corporations or individuals, or
lead to

litigation.

It is, therefore, very important that you understand and comply with all
DOT

security policies and procedures. Failure to do so may subject you to

disciplinary action and penalties under the law. DOT Information System
Security

policy and procedures are found in DOT H 1350.2 and in this Guide.
Before you

begin your use of DOT Information Systems, be sure that you understand
and

comply with all security requirements set forth in your company's
contract with

DOT. Contact your company's Facility Security Officer (FSO) if you have
any

questions concerning these requirements.

The remainder of this Guide describes what you need to know to be an
active

participant in the DOT information systems security program.

DOT CONTRACTOR RESPONSIBILITIES

At DOT, information is one of our most valuable assets, and needs to be

protected from loss, unauthorized changes, and disclosure. It appears in
many

forms, such as:

Mainframe computer data,

PC data,

Magnetic media, such as diskettes,

Printed documents,

Microfilm and microfiche, and

Conversation.

The information you use every day must be protected. Whether you work
with

paper documents or data on a PC, or spend most of your day on the phone,
you

are part of DOT's information systems security program. By preventing
errors,

security makes your job easier because you won\'t have to spend time
fixing

mistakes. Good security helps to keep DOT missions and systems healthy,
by

ensuring that the information you work with is accurate. Incorrect
information

can cause DOT to lose the confidence of the public it supports. If that
were

to happen, your company's contract, and hence your job could be
affected.

For ease of organization, contractor system security responsibilities
have

been divided into four areas: procedural security, data security,

communications security and physical security. These are described in
the

following paragraphs.

A. Procedural Security

Procedural security dictates how you operate and maintain the DOT system
that

you have been assigned to, and includes:

Obtaining an information systems security briefing from the applicable
DOT

ISSO, as well as your company's FSO, before using your assigned
equipment

for the first time.

Ensuring that your assigned equipment is maintained with care (e.g.,
used

properly, kept clean, etc.). The processing environment must also be
kept as

clean as possible. Remember, contractually your assigned equipment is

Government-Furnished Property (GFP), and under the terms of your
company's

contract, you and your company are responsible for keeping it in good

working order.

Operating your equipment according to the organization's reference
manuals

and posted DOT security instructions.

Ensuring that the appropriate DOT ISSO has approved and certified all

software packages before they are used. Personal copies of software are

prohibited in the workplace for use on Government-owned equipment.

Ensuring that no additional equipment is attached to your assigned
system

without the knowledge and written permission of the appropriate DOT
ISSO.

Honoring software copyright restrictions. No unauthorized copies of

copyrighted software may be made for office or personal use. Copyrighted

software may not be borrowed or removed from the workplace.

Not loading copyrighted software onto another system unless authorized
in

vendor agreements, approved by supervisor, and in writing, by the

appropriate DOT ISSO.

Protecting against disaster by ensuring that backup copies of
application

programs and data files are available for use. Update your backup copies
of

data files regularly, and store them in a secure location separate from
your

equipment. Generally, information should be duplicated if you could not

afford to lose it, it would cost too much to recreate it, or it would
take

too much time to recreate. If you are still concerned about what should
be

duplicated, ask your supervisor for guidance as to exactly what needs to
be

duplicated.

Safeguarding assigned passwords. Do not reveal your passwords to anyone,

either at your company or at DOT, and do not store them in plain text on

your equipment. If you are able to choose your own password(s), refer to

Figure 1 for some helpful \"dos\" and \"don'ts\".

Reporting compromised passwords to the appropriate DOT ISSO immediately.

Protecting equipment. Keep food, drink and electrical appliances away
from

your assigned equipment.

Protecting your assigned equipment, and the data it contains, when

unattended. Always log off your system, or turn it off before leaving it

unattended.

Protecting against viruses. Never bring unauthorized company or personal

software to work, and do not share diskettes unless absolutely
necessary. If

you suspect that your assigned system is infected with a virus that has
not

been detected by the internal virus protection software, notify the

appropriate DOT ISSO immediately.

Reporting immediately any suspected system misuse or abuse to the

appropriate DOT ISSO.

Safeguarding your assigned equipment should you need to use it outside
of

the office. This is not recommended as a common practice for DOT
employees,

much less for DOT contractors. Personal computers may be stolen or
damaged

when they are removed from the office. If you must take equipment home,

remember to get written approval from your company supervisor, as well
as

from DOT. Also, check out the process for restitution if the computer is

damaged while in your possession. Your company's policy may require

replacement of damaged or lost equipment. If applicable, be sure you
have a

building equipment/property pass. Make sure you use a surge protector on

borrowed DOT equipment, and use extra care to protect that equipment
from

loss or theft.

Limiting your personal use of DOT equipment. DOT contractors working
on-site

at DOT office locations are permitted limited use of DOT office
equipment

for personal needs if the use does not interfere with official business,

does not result in loss of contractor productivity, and involves minimal

additional expense to DOT. This limited personal use of DOT office
equipment

should take place only during your non-work time. Note that this
privilege

to use DOT office equipment for non-DOT purposes may be revoked or
limited

at any time by appropriate DOT officials. Note also that this privilege
does

not extend to modifying DOT equipment, including loading personal
software

or making configuration changes.

Not using DOT office equipment to maintain or support a personal private

business. Examples of this prohibition include employees using a
government

computer and Internet connection to run a travel business or investment

service. This ban on using DOT office equipment to support a personal

private business also includes your using DOT office equipment to assist

relatives, friends, or other persons in such activities.

Bringing your company computer in to work at DOT is not allowed, unless

special arrangements are made with DOT.

B. Data Security

Sensitive and mission-critical information requires protection from

disclosure, alteration and loss. You should:

Protect data files. Establish and periodically review access privileges
for

each sensitive file.

Protect data storage media. Lock up removable media and equipment that

contains fixed media.

Not attempt to access any data on any system connected to a DOT LAN,
unless

such access has been specifically authorized.

Label diskettes with the contents of the data stored on them, and the
name

of the application program used. Handle diskettes carefully to avoid
damage.

If you pass a diskette or other electronic media along to someone else,

reformat it first. Just deleting information does not mean that the

information has been erased. If the diskette contains highly sensitive
data,

it should never be passed along. There will be some data that can be
read

even after you have formatted the diskette.

Not process data that exceeds the accredited sensitivity level of the
LAN.

If you have a question regarding the accreditation level of the LAN you
are

operating on, check with the appropriate DOT ISSO for guidance.

Dispose of waste containing sensitive information as if it were
classified

waste (e.g., burning or shredding). Check with the appropriate DOT
manager

or ISSO about the approved method for disposing of trash. If the office
you

are working in has such a program, place the document in a special

collection bin for sensitive trash. Someone else will collect it and
make

sure it\'s gets destroyed properly. If you have other media to dispose
of,

e.g. CD's or diskettes, check with the appropriate DOT ISSO on the
proper

disposal methodology.

Not allow any person outside your office to access your system or its
data

unless that person has a \"need-to-know\" that has been verified by the

appropriate DOT ISSO.

Here are some password choices to AVOID:

Your name, nickname, or initials,

Your user identification code (user ID),

Special dates, especially those that appear on your driver\'s license,

or on a calendar you carry in your purse or wallet,

Consecutive keys on a keyboard, e.g., QWERTY or FGHJKL,

All the same character, e.g., CCCCCC or 9999999,

Your telephone number, employee number, or social security number, and

Words that appear in a dictionary.

Here are some suggestions for choosing a GOOD password:

Combine letters and numbers such as the name and birthdate of a

relative or friend, e.g., LISA105,

Take the first or last letters from each word of a phrase, e.g.

IWADASN (It Was A Dark And Stormy Night) or EDESOEFT (wE holD thesE

truthS tO bE selF evidenT),

Remove all vowels from a common word or words, e.g. TPSCRT (ToP

SeCReT), and

Make it as long as possible. Passwords should be at least 8 characters

long.

Figure 1, Password \"Dos\" and \"Dont\'s\"

Inspect data files for tampering. If you suspect that someone has
tampered

with your files or the data in them, report it immediately to the

appropriate DOT ISSO.

Be careful when answering questions from outside individuals. Refer any

requests for information from the media (reporters) to the appropriate
DOT

manager. When asked to complete a survey or questionnaire, ask your
company

supervisor whether this is all right. If you receive calls from
employment

search companies or vendors, take the individual\'s name and number and
pass

this along to your company supervisor. Do not allow such people to have
a

copy of any DOT list of employees or DOT telephone book. This would only

encourage them to make calls that DOT may not welcome.

Be wary about speaking on the telephone. When speaking on the phone, you

could easily be fooled into thinking you are talking to a person with a
real

need for some information. Be careful not to give out valuable
information

to the wrong person. Try to verify the identity of the caller. If you
can\'t

do this by asking some key question, then tell the caller, \"I will need
to

call you back on this.\" Verify the caller\'s need to know the requested

information. Be careful not to give out more information than requested.

Also, be aware of who is in the area that could overhear your
conversation.

C. Communications Security

Government telecommunications systems and information systems connected
to a

network are subject to periodic security testing and monitoring, to
ensure

that proper communications security (COMSEC) procedures are being
observed.

Therefore, use of any system with any network connection constitutes
consent

to security testing and COMSEC monitoring. An example of a Warning
Banner used

to reinforce this restriction is shown in Figure 2. As regards DOT
networks

and connected information systems, you must:

Ensure that information transmitted by modem (telecommunications) is not

classified or sensitive, and the transmission of the information type
has

been approved by the appropriate DOT ISSO. If in doubt as to what is

sensitive, consult with the ISSO and your company FSO.

Turn off your system, or disconnect it from the LAN when not in use. An

active system connected to a network can be accessed, and files,

applications and even the operating system can possibly be changed
without

your knowledge.

Ensure that systems used to process 'For Official Use Only' (FOUO)

information are not left unattended.

Ensure that, in the event that you suspect that a system has been

penetrated, you immediately contact the appropriate DOT ISSO.

\*\*WARNING\*\*WARNING\*\*WARNING\*\*

This is a DOT computer system. DOT computer systems are provided for the

processing of Official U.S. Government information only. All data

contained on DOT computer systems may be monitored, intercepted,

recorded, read, copied, or captured in any manner and disclosed in any

manner, by authorized personnel. THERE IS NO RIGHT OF PRIVACY IN THIS

SYSTEM. System personnel may give to law enforcement officials any

potential evidence of crime found on DOT computer systems. USE OF THIS

SYSTEM BY ANY USER, AUTHORIZED OR UNAUTHORIZED, CONSTITUTES CONSENT TO

THIS MONITORING, INTERCEPTION, RECORDING, READING, COPYING, OR CAPTURING

and DISCLOSURE.

\*\*WARNING\*\*WARNING\*\*WARNING\*\*

Figure 2, Warning Banner Example

1\. Use of the Internet

The Internet is an important tool for communicating with others outside
of

DOT. But while it offers enormous benefits in terms of increased access
to

information, it also generates a plethora of professional
responsibilities

and legal issues. As an Internet user working at DOT, you are therefore

accountable for the following use standards:

Use DOT Resources for Authorized Business Functions -- It is relatively

easy for users to perceive the Internet as a public resource. You must

remember that DOT systems are available for authorized work only, \-\--
that

is, activities sanctioned by management and position functions. If you
are

uncertain about Internet use, ask your company supervisor for specific

guidance.

Avoid Offensive Material -- The Internet provides easy, efficient access
to

vast quantities of valuable information; however, it can also serve as a

conduit for information that could be considered offensive. Access to

offensive material cannot be completely filtered without impacting

performance and cost. It is therefore your responsibility to maintain a

professional work environment at all times, \-\-- immune from
harassment,

intimidation and insult.

Respect Intellectual Property -- The Internet was originally established
as

an academic resource; it was designed to facilitate uninhibited exchange

of information. Today, it exists in a more diverse and competitive

environment. Easy access to information through the Internet begets easy

reuse of information derived from Internet sources. Unknowing
contractors

expose themselves, their company and DOT to liability when electronic

information is reused without regard for ownership. You should be aware
of

your legal obligation to recognize and respect the intellectual property

of others. Any original work of authorship may be the subject of
copyright

protection, and can only be copied or distributed with the permission of

the copyright owner. Such copyright-protected subject matter includes

literary text or information, software, and graphical or pictorial
works.

Check with your company FSO for more information.

Safeguard Private and Personal Information -- You have a responsibility
to

respect the privacy of others, and to safeguard personal information
about

others that has been entrusted to you for legitimate work purposes. You

should not access files belonging to another user without permission,
nor

should you transmit private or personal information over insecure,
public

networks.

Obtain Public Release Authorization -- Technical information posted to

public services requires pre-publication authorization. Who authorizes

publication depends on the type of information involved. You should
always

solicit specific pre-publication guidance from your company supervisor
and

DOT.

Distinguish Opinion from Government Position -- If you wish to express
an

opinion on work-related subjects, you should obtain approval from DOT as

well as your company supervisor, and attach an explicit disclaimer that

states the following: \"The views expressed are those of the author, and
do

not reflect the official policy or position of the Department of

Transportation, or the U.S. Government\". You should always express your

own opinion judiciously, and refrain from expressing personal opinion on

subjects that are not work-related, such as politics, religion and

hobbies.

Protect Information Assets -- Competitive advantage and financial
success

rely heavily on timely access to accurate information, and on protection

of sensitive information. While Internet use offers enormous advantages,

there are significant security issues associated with Internet

communications. Secure system design and other security controls help

thwart active outsider threats to computer resources, but have minimal

effect on unintentional insider threats caused by human errors,
accidents

and omissions. You may unintentionally expose Government information

systems to malicious intrusion by hackers and viruses, as well as other

security risks, needlessly impacting performance. You are therefore

responsible for implementing the security provisions shown in Figure 3.

Enforce CyberEthics -- You are required to enforce the highest standards
of

business ethics, regardless of the work environment, and to report known

and suspected violations of Government policy to the appropriate DOT
ISSO.

National Security Information is not authorized on any public system;

information systems processing classified information require Security

Accreditation prior to use.

Proprietary information and intellectual property shall not be
transmitted

over external networks unprotected; similarly, sensitive information

regarding DOT products or activities shall not be posted to open

environments, such as public news groups and bulletin boards, nor

discussed via Internet chat sessions.

Data, files and/or software from unknown or suspect sources shall not be

downloaded to Government systems.

Software that is legitimately downloaded from external sources shall be

scanned for malicious code prior to use on any Government system.

User passwords shall be protected from disclosure and changed often.

Internet access should always be accomplished through a Firewall. Access

by dual-homed devices, e.g., devices that are simultaneously connected

physically or logically to both an internal DOT LAN and the Internet is

strictly forbidden.

DOT contractors shall not misrepresent themselves.

Figure 3, Internet Security Provisions

For additional guidance concerning DOT Internet policy, refer to DOT H

1350.2 (DIRMM), Chapter 14-4 Interim DOT Internet Resources Policy.

Note that it is the policy of the Government to monitor Internet use.

Similarly, electronic files may be searched by Government Officials.
Refer

to Section 7 of this Guide for a discussion of DOT contractor personal

liability.

2\. Use of E-mail

Electronic Mail (e-mail) is an official medium for transmitting official

correspondence, both within and outside of DOT. Official correspondence
is

defined as correspondence having as its objective the accomplishment of
DOT

missions or assignments, or the dissemination of information having
direct

bearing on the accomplishment of DOT missions, or relating to DOT

activities. If uncertain as to what constitutes official correspondence,
you

should consult with your company supervisor for guidance. In general,
you

should adhere to the standards detailed above, as well as your own
company

standards, as regards the overall use of e-mail within DOT. For
additional

guidance concerning DOT e-mail policy, refer to DOT H 1350.2 (DIRMM),

Chapter 14-3 Electronic Mail Policy.

Note that you may not use DOT e-mail facilities to harass, abuse or
offend

others. Engaging in any outside fund-raising activity, endorsing any
product

or service, participating in any lobbying activity, or engaging in any

prohibited partisan political activity via e-mail is also prohibited.
Note

also that transmission of classified information is expressly forbidden
on

any mail system within DOT unless that system has obtained proper
security

accreditation. Check with the appropriate DOT ISSO if you are unsure as
to

what level of sensitivity data you are permitted to transmit via e-mail

while at DOT. It is important to understand that e-mail is provided to

on-site DOT contractors for business use only.

You should be alert to two types of e-mail problems: Spoofed/Forged
e-mail

and e-mail Spamming/Bombing. E-mail spoofing may occur in different
forms,

but all have a similar result: a user receives e-mail that appears to
have

originated from one source when it actually was sent from another
source.

E-mail spoofing is often an attempt to trick the user into making a
damaging

statement or releasing sensitive information (such as passwords).
Examples

of spoofed e-mail that could affect the security of DOT include:

E-mail claiming to be from a system administrator requesting users to

change their passwords to a specified string and threatening to suspend

their account if they do not do this.

E-mail claiming to be from a person in authority requesting users to
send

them a copy of a password file or other sensitive information.

E-mail \"bombing\" is characterized by abusers repeatedly sending an

identical e-mail message to a particular address. E-mail \"spamming\" is
a

variant of bombing; it refers to sending e-mail to hundreds or thousands

of users (or to lists that expand to that many users). E-mail spamming
can

be made worse if recipients reply to the e-mail, causing all the
original

addressees to receive the reply. It may also occur innocently, as a
result

of sending a message to mailing lists and not realizing that the list

explodes to thousands of users, or as a result of an incorrectly set-up

responder message.

If you are in receipt of suspect e-mail, alert the appropriate DOT ISSO

immediately.

D. Physical Security

Physical security limits access to the information processing
environment, and

provides security for a contractor's assigned system, including its
hardware,

software and the data it processes. You should:

Protect your work area. Recognize, politely challenge, and assist people
who

do not belong in your area.

Limit access to your assigned equipment. Recognize those who are
authorized

to use, service and repair that system.

Challenge persons carrying information systems equipment out of an
office or

DOT building.

Not allow any information systems hardware to be moved from its
accredited

location without the knowledge and approval of the appropriate DOT ISSO.

This includes turning in equipment for maintenance.

Remember, anyone not currently working in your DOT office is a visitor.
Use

caution when disclosing information in front of any visitor.

PERSONAL LIABILITY

Finally, you should be aware that Federal law provides for punishment

consisting of a fine under Title 18, U.S. Code and up to 10 years in
jail

for the first offense for anyone who:

Knowingly accesses an information system without authorization, or
exceeds

authorized access, and obtains information that requires protection
against

unauthorized disclosure. (Note that the offense is for the access, and
not

necessarily any disclosure).

Intentionally, without authorization, accesses a government information

system and, in so doing, affects the use of the government's operation
of

that system.

Intentionally accesses a government information system without

authorization, and alters, damages or destroys information or prevents

authorized use of the system.

Accesses a government information system without authorization, or
exceeds

authorized access, and obtains anything of value.

The above prohibitions and punishments apply to mere attempts, even if

unsuccessful, to commit the listed crimes. Multiple accesses or multiple

attempts constitute multiple offenses for the purposes of determining

punishment. Be sure that you discuss these matters thoroughly with your

company FSO.