U. S. DEPARTMENT OF COMMERCE

INFORMATION TECHNOLOGY SECURITY

MANUAL

CHAPTER 10, ATTACHMENT 1
INFORMATION TECHNOLOGY MANAGEMENT HANDBOOK

INFORMATION TECHNOLOGY SECURITY
INTRODUCTION

Information technology is essential for accomplishing government
programs in today's world. Managers and employees at all levels
require timely access to reliable information processing for routine
operations and major decisions. Such availability and reliability is
based on the integrity and protection of the information systems.

The "Computer Security Act of 1987," Public Law 100-235 and
Office of Management and Budget (OMB) Circular A-130 require all
federal agencies to plan for the security of all sensitive IT systems
throughout their life cycle. OMB Circular A-130 also established a
minimum set of controls to be included in federal Information
Technology (IT) security programs. The program must include the
implementation of policies, standards, and procedures which are
consistent with government-wide laws and regulations, to assure an
adequate level of protection for IT systems whether maintained in-
house or commercially. The circular directs agencies to assure:

1. that IT systems operate effectively and accurately;

2. that there are appropriate technical, personnel, administrative,
physical, environmental, and telecommunications safeguards in
IT systems; and

3. that the continuity of the operations of IT systems that support
critical agency functions is preserved.

The Department of Commerce (DOC) complies fully with all federal
statutes and directives on IT security and provides protection
commensurate with the sensitivity of the system or data processed.
The Department has established and implemented an IT security
program which will provide reasonable and acceptable assurance
that sensitive and classified national security IT systems are
performing exactly as specified and doing nothing more; that
sensitive and classified information is provided adequate protection;
that data and software integrity is maintained; and, that unplanned
disruptions of processing will not seriously impact mission
accomplishment.

People, hardware, software, telecommunications, facilities and data
together form an IT system that is highly effective and productive.
However, all IT systems involve certain risks that must be addressed
adequately through proper controls. The policies contained in the
Departmental Administrative Order 212-2, "DOC IT Management
Handbook," Chapter 10, IT Security, represent management's
commitment to assuring confidentiality, integrity, availability and
control of the Department's IT resources.

This "DOC IT Security Manual," is Attachment 1 to Chapter 10 of
the "DOC IT Management Handbook." It combines all policies,
procedures, current detailed guidance and methodologies for
accomplishing the Department's IT security program. This
document is divided into sections which discuss the requirements of
the Department's IT security program for specific subjects. It is
intended to provide individuals assigned IT security responsibilities
and system owners with a more detailed single-source reference
document, which will be up-dated as new policies, procedures,
techniques, methodologies or program requirements are developed
and issued.

Relationship to Other Security Programs

The Office of Security is responsible for: (1) physical security of
facilities and equipment external to computers or telecommunication
lines; (2) all procedural matters relating to national security
information; (3) matters relating to background and security
clearance investigations of personnel; and (4) national emergency
planning. For policies relating to these areas, refer to the
appropriate Departmental directives, i.e., DAO 207- series.

The Office of the Inspector General provides independent oversight
through audit and evaluation of the Department's IT security
program in accordance with the "Inspector General's Act of 1978."
For policies relating to these areas, refer to the appropriate
Departmental directives, i.e., DAO 207-10.
SECTION 1
PROGRAM REQUIREMENTS

A. Purpose:

This section describes the Department of Commerce (DOC)
Information Technology (IT) Security program that complies
fully with all federal laws, regulations and directives and
communicates uniform policies for the protection and control
of IT resources directly or indirectly relating to the activities of
the Department.

This section also describes the policies and responsibilities for
the establishment, implementation, maintenance and oversight
of the IT security program within the Department, for the
protection and control of vital DOC IT resources. Basic
elements of the Department's IT security program requirements
will be identified in relation to assigned responsibilities.

B. Overview:

Security of IT systems, as described in OMB Circular A-130,
requires the protection of automated systems and information
while associated with any automated processing activity, and
the assurance that the systems do exactly what they are
supposed to do and nothing more. IT security requires
management controls to ensure authorized access to the
information in the systems and proper handling of input,
processing, and output.

The implementation of an effective IT security program within
the Department begins with the establishment of the
organizational IT security structure and the assignment of
broad responsibilities.

Individuals appointed to positions with IT security
responsibilities are accountable for compliance with all DOC or
federal laws, regulations and policies related to the assigned
responsibilities.

C. Background and Authority:

The DOC IT Security Program is established in compliance
with the "Computer Security Act of 1987," Public Law 100-235,
OMB Circular A-130, Appendix III, "Security of Federal
Automated Information Systems," National Security Directive
(NSD) 42, "National Policy for the Security of National Security
Telecommunications and Information Systems" and
Departmental Organizational Order DOO 20-14.

D. Scope:

The policies contained in this document are applicable to all
DOC IT resources at all levels of sensitivity, whether
maintained in-house or commercially. These policies are
mandatory on all organizational units, employees, contractors,
and others having access to and/or using the IT resources of the
Department.

These policies apply to all automated technology currently in
existence and to any new automated technology acquired after
the effective date of this policy document.

The IT security program focuses on assuring confidentiality,
integrity and availability of all IT resources necessary for
processing or transmitting the information. The IT security
program consists of a number of different elements, including
some that would normally come under other security programs.
Those elements that are required by the "Computer Security
Act of 1987" or OMB Circular A-130 are considered part of
the DOC IT security program and are included in this IT
Security Manual.

E. Policy:

The policies stated in the "IT Management Handbook" require
that all DOC organizations establish, implement and maintain
an IT security program consistent with the Department and
government-wide laws, regulations, policies, procedures and
standards. The program must include as a minimum, adequate
and appropriate levels of protection for all IT resources within
the organization, including hardware, software, physical and
environmental facilities, telecommunications, administrative,
personnel and data.

All IT systems will be identified and appropriate controls
implemented in the following categories:

1. Management controls;

2. Acquisition/development/installation/implementation
controls;

3. Operational controls;

4. IT security awareness and training; and

5. Technical controls.

Guidance for each of these categories of controls are included
in later sections of this document.

Responsibilities for the DOC IT security program starts at the
Department level and flows down through management of all
organizations to the individual users.

1. The DOC Office for Information Resources Management
is responsible for security of DOC IT resources. Non-IT
security programs (e.g., theft of computer resources,
physical security, personnel security, safeguarding
classified material and Inspector General requirements are
stated in Section G. below.

2. The head of each operating unit is responsible for
adequate protection of the operating unit IT resources.
Staff responsibility for IT security shall be monitored by
the operating unit Senior Official for Information
Resources Management.

3. System owners are responsible for providing adequate and
appropriate levels of protection for the IT resources under
their control to prevent unauthorized disclosure, effective
and accurate processing and continuity of operations for
accomplishment of the organization's mission.

4. Each employee of the Department is responsible for the
adequate protection of IT resources within their control or
possession.

IT security program responsibilities are assigned to the
Department and all operating units in line with the
requirements outlined in section F. below.

F. Responsibilities and Process:

Department Level

The Director for Information Resources Management (IRM) is
responsible for information while being processed and/or
transmitted electronically, and for the security of the resources
associated with these functions. The Director for IRM is the
Designated Approving Authority (DAA) for all IT systems
processing classified national security information within the
Department. This authority cannot be delegated. The Director
for IRM will monitor, evaluate and report, as required, to the
Assistant Secretary for Administration on the status of IT
security within the Department and the adequacy of operating
unit IT Security programs. Within IRM, the authority to
perform these responsibilities, except DAA for classified
systems, will be exercised by the Departmental IT Security
Manager.

The DOC IT Security Manager monitors, evaluates and reports,
as required, to the Director for IRM on the status of IT
security within the Department and the adequacy of the
programs administered by the operating units. The DOC IT
Security Manager will:

1. Develop policies, procedures and guidance establishing,
implementing, maintaining and overseeing requirements
for the Department's IT security program to be followed
by all DOC organizations.

2. Provide guidance and technical assistance to operating
units, including analyzing, evaluating and approving all IT
system security plans and requirements for IT systems
security.

3. Assure DOC IT security oversight through compliance
reviews of operating units and organizations and IT
security verification reviews of individual systems and
participating in Commerce program management
oversight processes.

4. Maintain a tracking system and records concerning
implementation of the required controls and accreditation
status of all DOC IT systems.

5. Establish an IT Security Coordinating Committee and
chair regularly scheduled meetings to discuss and
disseminate information on IT security matters and
concerns.

6. Coordinate the review of all controls for classified IT
systems by the Office of Security and the
Telecommunications Management Division and evaluate
the adequacy of all technical controls for accreditation.

7. Act as the central point of contact for the Department for
IT security related incidents or violations. Investigate or
cause to be investigated any incidents or violations,
maintain records and prepare reports, disseminate
information concerning potential threats and report to the
Office of Security any violations that come under their
area of responsibilities or to the Assistant Inspector
General for Investigations any activity which may
constitute a violation of law or otherwise is reportable to
that office in accordance with DAO 207-10, "Inspector
General Investigations."

8. Coordinate with the Department's Office of Security on
security matters of mutual interest.

Operating Unit Level

Senior IRM Official - Each operating unit Senior IRM Official
shall conduct an IT security program that ensures appropriate
and adequate levels of protection for all IT systems within the
operating unit. The Senior IRM official shall:

1. Be the DAA for all sensitive systems within their
organization. This approval authority may only be
delegated to a senior management official of a subordinate
organizational unit, if that official does not have direct
control over the IT system being accredited. Delegation
of accreditation authority must be requested and approved
in advance by the DOC Director for IRM.

2. Assure ownership is assigned for all IT resources within
the operating unit (i.e., hardware, software, data,
telecommunications, etc.)

3. Appoint an IT Security Officer (ITSO) and alternate for
the operating unit. This individual, or alternate, should
have the staff responsibility for the operating unit IT
Security program.

Operating Unit ITSO - The operating unit ITSO shall serve as
the central point of contact for the operating unit IT security
program with the Departmental IT Security Manager. The
operating unit ITSO shall perform the following functions:

1. Represent the operating unit as a voting member of the
DOC IT Security Coordinating Committee, attend
regularly scheduled meetings to obtain current
information on issues relating to federal or DOC IT
security policies, regulations, guidelines, share information
with the committee about issues or concerns and
participate in special subcommittees working to solve
Department-wide issues.

2. Ensure that an ITSO and alternate are appointed for each
major subordinate organizational component within the
operating unit, if appropriate. These individuals will serve
as the point of contact for their organizational component
IT security program with the operating unit ITSO.

3. Establish and maintain a list of all IT systems within the
operating unit and provide an up-to-date list to the DOC
IT Security Manager annually.

4. Ensure that an IT System Security Officer (ITSSO) has
been appointed for each IT system within the operating
unit.

5. Ensure IT security plans are prepared in the proper
format for all sensitive and classified IT systems owned
and operated by the operating unit. Review and comment
on individual IT security plans, ensuring that all
corrective actions are completed and submit all plans to
the DOC IT Security Manager. Requirements for IT
security plans are contained in Chapter 10, Section 10.2 of
the "DOC IT Management Handbook" and Section 2 of
the "DOC IT Security Manual."

6. Ensure that risk analysis is completed for all sensitive or
classified IT systems within the operating unit.
Requirements for risk analysis are contained in Chapter
10, Section 10.7 of the "DOC IT Management Handbook"
and Section 7 of the "DOC IT Security Manual."

7. Ensure that contingency and disaster recovery plans are
developed for all sensitive or classified IT systems within
the operating unit. Requirements for contingency and
disaster recovery planning are contained in Chapter 10,
Section 10.8 of the "DOC IT Management Handbook"
and Section 8 of the "DOC IT Security Manual."

8. Maintain a tracking system concerning implementation of
the required controls and accreditation status for all
operating unit sensitive and classified IT systems.

9. Act as the central point of contact for accreditation of all
sensitive IT systems within the operating unit. Ensure
that all certification requirements have been met for each
system, prior to accreditation. Certification requirements
are contained in Chapter 10, Section 10.3 of the "DOC IT
Management Handbook" and Section 3 of the "DOC IT
Security Manual." The ITSO will submit an accreditation
status report quarterly to the DOC IT Security Manager.
Accreditation requirements are contained in Chapter 10,
Section 10.4 of the "DOC IT Management Handbook"
and Section 4 of the "DOC IT Security Manual."

10. Conduct, or cause to be conducted, IT security verification
reviews of all operating unit sensitive IT systems every
three years. Requirements for IT security verification
reviews are contained in Chapter 10, Section 10.5 of the
"DOC IT Management Handbook" and Section 5 of the
"DOC IT Security Manual."

11. Ensure that all operating unit personnel are provided
appropriate IT security awareness and training. IT
security awareness and training requirements are
contained in Chapter 10, Section 10.17 of the "DOC IT
Management Handbook" and Section 17 of the "DOC IT
Security Manual."

12. Act as the central point of contact for the operating unit
for any type of IT security related incidents or violations.
Investigate or cause to be investigated any incidents or
violations, maintain records and ensure reports are
submitted to the DOC IT Security Manager and
disseminate information concerning potential threats to
system owners. Requirements for incident and violation
reporting are contained in Chapter 10, Section 10.6 of the
"DOC IT Management Handbook" and Section 6 of the
"DOC IT Security Manual."

13. Ensure that the operating unit has a malicious software
policy in place and the required virus detection and
elimination software and procedures are available to
protect against these threats. Malicious software
protection and reporting requirements are contained in
Chapter 10, Section 10.6.1 of the "DOC IT Management
Handbook" and Section 6.1 of the "DOC IT Security
Manual."

14. Ensure that the operating unit has established a policy
against the illegal duplication of Copyrighted software.
Ensure that all systems are audited for illegal software at
least annually and inventories of all software on each
individual system is maintained to verify that only legal
copies of software are being used. Requirements for
software copyright protection, auditing and reporting are
contained in Chapter 10, Section 10.12.1 of the "DOC IT
Management Handbook" and Section 10.12.1 of the "DOC
IT Security Manual."

15. Coordinate with the operating unit Security Office on
security matters of mutual interest.

In the absence of the ITSO the alternate shall perform all
functions normally assigned to the ITSO for the operating unit
IT security program.

Subordinate Organization ITSO - Not all operating units within
the Department will require this level position. A major
subordinate organization is defined to mean any large
organizational component that has management responsibility
for a number of individual IT systems performing separate
functions (i.e., Line Office, Laboratory, Regional Office.) The
subordinate organization ITSO shall serve as the central point
of contact for the subordinate organization IT security program
with the operating unit ITSO. If this level of position is
determined to be appropriate for the operating unit, the
functions of the ITSO for the subordinate organization will
generally parallel those specified for the ITSO.

System Owner - Responsibility for the protection of IT
resources generally falls into two broad categories: custodial
and owner. The fulfillment of the protection responsibilities of
each is mandatory.

1. All information resources (hardware, software, facilities,
data and telecommunications) will be assigned to an owner
designated in writing, to the Senior IRM Official of the
operating unit. For example, the "owner" of the
resources contained within a general support system may
be the manager of that facility. Resources located within
user areas (i.e., offices or laboratories) may be "owned"
by the manager of those areas. To assist with the
determination of ownership, individual system boundaries
must be established. A system is identified by logical
boundaries being drawn around the various processing,
communications, storage and related resources. They
must be under the same direct management control with
essentially the same function, reside in the same
environment and have the same characteristics and
security needs. Each system will be designated either a
general support system or an application system. Chapter
10, Section 10.2 of the "DOC IT Management Handbook"
and Section 2 of the "DOC IT Security Manual" contain
definitions for general support and application systems.

2. Ownership of information and/or information processing
resources may be assigned to an organization, subordinate
functional element, a position , or a specific individual.
When ownership is assigned to an organizational or
functional element, the head of the unit so designated shall
be considered the resource owner. Some, but not
necessarily all factors to be considered in the
determination of ownership are:

(a) The originator or creator of data.

(b) The organization or individual with the greatest
functional interest.

3. General support system owners are suppliers of data
processing services frequently for applications owned by
other organizations. Typically these systems are
custodians of software, data, input and output produced
by the data processing facility to support one or more
application owners. Custodial responsibility includes the
obligation to comply with applicable security policies and
directives, and to administer application owner specified
controls and safeguards for the data and programs of
those owners. Many of the Department's local area
networks will fit into this category.

4. Each system owner shall be responsible to:

(a) Determine the sensitivity of the resources for which
responsible.

(b) Determine the appropriate level of security required
which is consistent with federal and DOC laws
regulations and directives and protection
requirements of the system for confidentiality,
integrity or available and ensure that an adequate
level of protection is maintained.

(c) Be the certifying official and complete all required
certification actions, issue a certification statement
and prepare an accreditation package which will be
forwarded to the DAA for formal accreditation of
the system, every three years or when major changes
occur to the system, whichever is less. If the
certifying official is at a higher level in the
organization, the system owner will complete all
required certification actions and forward the
accreditation package to the certifying official, who
will issue the certification statement. Chapter 10,
Section 10.3 of the "DOC IT Management
Handbook" and Section 3 of the "DOC IT Security
Manual" contain certification requirements.

(d) Monitor compliance, and periodically re-evaluate
previously specified levels of sensitivity and
protection.

(e) Ensure that all systems are audited for illegal
software at least annually and inventories of all
software on each individual system is maintained to
verify that only legal copies of software are being
used. Requirements for software copyright
protection, auditing and reporting are contained in
Chapter 10, Section 10.12.1 of the "DOC IT
Management Handbook" and Section 10.12.1 of the
"DOC IT Security Manual."

(e) Ensure that each ADP position (including contract
positions) are properly designated in accordance with
position sensitivity criteria and receive appropriate
investigative processing. Refer to Chapter 10,
Section 10.9 of the "DOC IT Management
Handbook, Section 9 of the "DOC IT Security
Manual" and the "DOC Personnel Security Manual"
for further guidance.

(g) Appoint an individual to serve as the IT System
Security Officer (ITSSO) with responsibility to
develop, implement and manage the security of the
system.

ITSSO - The ITSSO for each classified or sensitive system shall
perform the following functions:

1. Advise the IT system owner on matters pertaining to IT
systems security.

2. Develop, implement and manage the execution of the IT
system security program.

3. Prepare, or cause to be prepared an IT system security
plan in the proper format for the IT system.
Requirements for IT security plans are contained in
Chapter 10, Section 10.2 of the "DOC IT Management
Handbook" and Section 2 of the "DOC IT Security
Manual."

4. Conduct, or cause to be conducted, a risk analysis on the
system when there are major changes to the system or
every three years, whichever is less. Requirements for
risk analysis are contained in Chapter 10, Section 10.7 of
the "DOC IT Management Handbook" and Section 7 of
the "DOC IT Security Manual."

5. Ensure that contingency and disaster recovery plans are
developed, maintained in an up-to-date condition and
tested at least annually. Requirements for contingency
and disaster recovery plans are contained in Chapter 10,
Section 10.8 of the "DOC IT Management Handbook"
and Section 8 of the "DOC IT Security Manual."

6. Establish and maintain liaison with any remote facilities
or users served by the IT system, the operating unit ITSO,
or if appropriate, the subordinate organization ITSO.

7. Monitor changes in hardware, software,
telecommunications, facilities and user requirements to
ensure that security is not compromised or degraded.

8. Exercise system responsibility or direct activities for
password management and control.

9. Arrange for IT security awareness training for the system
staff and monitor the user training programs to ensure
that personnel receive security orientation before being
allowed access to sensitive IT resources.

10. Ensure that positions requiring access to classified
information or resources are identified and that
incumbents of these positions receive an appropriate level
of security clearance before access is granted.

11. Investigate known or suspected security incidents or
violations and prepare reports of findings as required in
Chapter 10, Section 10.6 of the "DOC IT Management
Handbook" and Section 6 of the "DOC IT Security
Manual. Verbal and written reports will be made to the
operating unit ITSO through the subordinate ITSO, if
appropriate. Incidents involving a physical security
violation, such as theft or violations of the personnel
security, classified information or industrial security
programs will be referred to the operating unit Office of
Security for investigation.

12. Ensure that the organization abides by the DOC and
operating unit malicious software policies and has the
required virus detection and elimination software and
procedures available to protect against these threats.
Malicious software protection and reporting requirements
are contained in Chapter 10, Section 10.6.1 of the "DOC
IT Management Handbook" and Section 6.1 of the "DOC
IT Security Manual."

13. Audit all the systems within the organization for illegal
software at least annually and maintain inventories of all
software on each individual system to verify that only
legal copies of software are being used. Requirements for
software copyright protection, auditing and reporting are
contained in Chapter 10, Section 10.12.1 of the "DOC IT
Management Handbook" and Section 12.1 of the "DOC
IT Security Manual."

14. Review IT related procurement specifications for
hardware, software or services to ensure that they include
adequate security requirements and/or specifications
which are commensurate with the sensitivity of the system.

15. Conduct, or cause to be conducted, all activities required
for the certification of the system, including preparing the
certification and accreditation packages for final approval
every three years or when major changes occur to the
system, whichever is less. Certification requirements are
contained in Chapter 10, Section 10.3 of the "DOC IT
Management Handbook and Section 3 of the "DOC IT
Security Manual."

16. Coordinate with the operating unit Security Office or local
Security Office on security matters of mutual interest (i.e.,
IT Security).

User Level - The primary purpose of IT systems is to support
the missions of using organizations. User management bears a
great deal of responsibility for their systems and data. In
addition to defining the functions to be performed by the
system, and its security requirements, the user is directly
responsible for the system resources, such as terminals and
printers, located within the user areas. In order to assure
adequate security within the user areas where these resources
are located, user managers will appoint a user ITSSO to be
responsible for the IT security within the user area. This
individual is responsible for implementing and enforcing the
security program at the user's location. The functions of the
user ITSSO generally parallel those specified for the ITSSO.

Each employee of the Department is responsible for the
adequate protection of IT resources within their control or
possession.

SECTION 2
INFORMATION TECHNOLOGY SYSTEM IDENTIFICATION
AND PLANNING

A. Purpose:

The purpose of this section is to establish Department of
Commerce (DOC) policy to plan for adequate levels of security
for each information technology (IT) system from its initial
concept phase throughout its life cycle. The objective of IT
security planning is to improve protection of IT resources. In
order for plans for the protection of the resources to be
adequate, the managers most directly affected by, and
interested in the information or processing capabilities, must be
comfortable that their information and/or processing
capabilities are adequately protected from loss, misuse,
unauthorized access or modification, unavailability, or
undetected activities.

B. Overview:

The purpose of the system security plan is to provide a basic
overview of the security and privacy requirements of the
subject system and the system owner's plan for meeting those
requirements. The system security plan may also be viewed as
documentation of the structured process of planning adequate,
cost-effective security protection for a system. Thus, it must
reflect input from various managers with responsibility
concerning the system, including functional "end users" or
information owners, the system operator and the IT System
Security Officer (ITSSO.)

This document will discuss only the preparation and
maintenance of the actual IT system security plan required by
the "Computer Security Act of 1987", Public Law 100-235 and
the format defined in Office of Management and Budget (OMB)
Bulletin 90-08. However, security planning is a vital part of the
overall IT planning requirements for the system and should be
included in the other IT plans as identified in Chapter 1 of the
"DOC IT Management Handbook."

C. Background and Authority:

The DOC IT security plan requirements are established in
compliance with the "Computer Security Act of 1987," Public
Law 100-235, OMB Circular A-130, Appendix III, "Security of
Federal Automated Information Systems" and OMB Bulletin
90-08, "Guidance for Preparation of Security Plans for Federal
Computer Systems that Contain Sensitive Information."

D. Scope:

The policy contained in this document covers all DOC IT
resources that have been identified as either sensitive or
classified national security systems whether maintained in-house
or commercially.

E. Policy:

The sensitivity level of all IT systems will be determined based
on the sensitivity of the data processed or the importance of the
system to mission accomplishment. All systems must include
security controls that reflect the true importance of the
information processed on the system and/or the government
investment embodied in the components of the IT system. The
sensitivity level of all DOC IT systems will be identified in one
of the following categories:

1. Classified National Security Systems contain information
which requires protection against unauthorized disclosure
in the interest of national security at either the Top
Secret, Secret or Confidential level. Procedural protection
requirements for classified systems are contained in DAO
207-2, "DOC National Security Information Manual."
Technical protection requirements are contained in
Chapter 10, Section 10.19 of the "DOC IT Management
Handbook" and Section 19 of the "DOC IT Security
Manual."

2. Unclassified Sensitive Systems include those that require
some degree of protection for confidentiality, integrity or
availability. This includes systems and data whose
improper use or disclosure could adversely affect the
ability of an agency to accomplish its mission, proprietary
data, records about individuals requiring protection under
the Privacy Act, and data not releasable under the
Freedom of Information Act. If the system is required for
accomplishment of an agency mission it need not contain
any sensitive data.

3. Non-Sensitive Systems are considered "trivial" as they
contain only public data, which has no protection required
for confidentiality or integrity, and the mission of the
agency can be accomplished without the system.

A security plan will be prepared in the format of Attachment
1 to this document, "DOC Guidelines for Developing and
Evaluating Security Plans for Sensitive and Classified Systems,"
and submitted to the Department for all DOC application and
general support systems that have been identified as sensitive
or classified national security systems. All IT systems will be
identified as either application systems or general support
systems:

1. Application Systems - Systems that perform clearly
defined functions for which there are readily identifiable
security considerations and needs. Such a system might
actually comprise many individual application programs
and hardware, software, and telecommunications
components. They can be either a major software
application or a combination of hardware/software where
the only purpose of the system is to support a specific
mission related function. The system may process
multiple individual applications, if all are related to a
single mission function.

F. Responsibilities and Process:

Operating Unit

The Operating Unit Senior Information Resources Management
Official will assure ownership is assigned for all IT resources
within the operating unit (i.e., hardware, software, data,
telecommunications, etc.) This designation of ownership will
become the foundation for determining who is responsible as
"system owner" to define system boundaries, determine
sensitivity levels and prepare and maintain the required
individual IT system security plans.

The Operating Unit IT Security Officer (ITSO) shall serve as
the central point of contact for IT security and coordinate
security plan requirements between the DOC IT Security
Manager and the system owners within the operating unit. The
ITSO shall:

1. Assist the system owners in establishing logical boundaries
for individual systems.

2. Assign each individual IT system a unique six digit
identification number, which will identify the operating
unit and the specific system. The unique identification
number will remain the same for the life of the system.

3. Establish and maintain a list of all IT systems within the
operating unit and provide an up-to-date list to the DOC
IT Security Manager annually.

4. Ensure that an IT System Security Officer (ITSSO) has
been appointed for each IT system within the operating
unit and maintain up-to-date records of these assignments.

5. Ensure IT system security plans are prepared in the
proper format for all sensitive and classified IT systems
owned and operated by the operating unit, including
contractor owned systems, operated on behalf of the
operating unit.

6. Review IT system security plans as submitted, making
appropriate written comments, which will be sent to the
originator for corrective action. Evaluation of the plans
will follow the "DOC Guidelines for Developing and
Evaluating Security Plans for Sensitive and Classified
Systems," Attachment 1, to this document.

7. Forward all corrected IT system security plans to the
DOC IT Security Manager for comment or final approval
and incorporation into the Department's records.

8. Maintain a tracking system concerning implementation of
the required controls and accreditation status for all
operating unit sensitive and classified systems.

9. Ensure that system owners review and update all plans, at
least annually, to incorporate changes or completed
milestone actions. Forwarded updated plans to the DOC
IT Security Manager for review and comment or
approval.

The System Owner will:

1. Evaluate all IT resources and establish logical boundaries
for individual systems. It is important that the boundaries
of a system be properly identified to allow for completion
of the system accreditation as required by OMB Circular
A-130 and the DOC Accreditation policy contained in
Chapter 10, Section 10.4 of the "DOC IT Management
Handbook" and Section 4 of the "DOC IT Security
Manual."

A system is identified by logical boundaries being drawn
around the various processing, communications, storage,
and related resources. They must be under the same
direct management control with essentially the same
function, reside in the same environment and have the
same characteristics and security needs.

A separate system security plan is required if a system
does not meet the criteria for a single system. If each site
is not under the same "direct management control" and
does not reside in the same environment, each site would
be a separate system. Each physical location would have
its own unique environmental considerations. Plans may
be identical except for those items that are unique for the
different hardware, environments and direct management
controls.

To be defined as a single system, all components need not
be physically connected together (e.g., a group of two or
more stand alone personal computers in an office may be
identified as a single system if they meet all the criteria
above.)

2. Appoint an individual to serve as the ITSSO for each IT
system identified. The ITSSO will be responsible for
developing, implementing and managing the security of
the system. Ensure that the ITSSO is adequately trained
to fulfill all responsibilities identified in Chapter 10,
Section 10.1 of the "DOC IT Management Handbook"
and Section 1 of the "DOC IT Security Manual."

3. Establish and maintain a list of all IT systems within the
system owner's area of responsibility and provide a copy
to the operating unit ITSO, as requested.

4. For each individual system identified, prepare an IT
System Security Plan in the format outlined in Attachment
1 of this document, "DOC Guidelines for Developing and
Evaluating Security Plans for Sensitive and Classified
Systems." The guideline provides an outline of all
required sections, with examples that fit into each
category of control. Application systems and general
support systems require different sets of control categories
and it is important to follow the correct format.

The IT system security plan is intended to serve as a
management tool for the system owner in determining the
sensitivity level and protection requirements for the
system. The plan describes the control measures currently
in place and any planned control that are intended to
meet the protection requirements of the system and can
assist in determining whether or not current security
measures are adequate. Properly documented, the plan
can be used as a "mini-risk assessment" which can and
should be used to determine what additional action and/or
resources are required to bring this system in line with
operational and security requirements. The plan should
be used to establish the actual milestones for completing
requirements and can be an excellent internal
management planning and decision-making tool.

Once completed, a security plan will contain detailed
technical information about the system, its security
requirements and the controls implemented to provide
protection against its vulnerabilities. All DOC security
plans should be marked at least "FOR OFFICIAL USE
ONLY" and handled and controlled as sensitive
documents. Security plans for classified systems should be
carefully reviewed for classified content and may require
higher level security classification and markings.

All security plans must be dated. This will allow ease of
tracking modifications and approvals.

5. Forward the completed IT system security plan to the
operating unit ITSO for review and comment. The ITSO
will provide written comments about any changes required
to the plan.

6. Make changes to the IT system security plan, as
requested, and return the plan to the operating unit ITSO
for forwarding to the DOC IT Security Manager.

7. Maintain the IT system security plan in an up-to-date
manner. At least annually, the plan should be reviewed
and updated to incorporate changes to the system or
completed milestone actions. Updated plans should be
forwarded to the operating unit ITSO for review and
comment.

The DOC IT Security Manager will:

1. Maintain a list of all IT systems within the Department to
ensure that all sensitive and classified IT systems have
been accounted for and that the required security plans
have been prepared and submitted.

2. Review all IT system security plans received from the
operating units, making appropriate written comments
which will be sent to the operating unit ITSO for
corrective action. Plans which do not require changes will
be approved and a signed statement of approval will be
issued for incorporation into the system owner's records.

3. Maintain a tracking system and records which will be
used to monitor implementation of the required controls
and accreditation status of all DOC IT systems.

SECTION 3
CERTIFICATION

A. Purpose:

The purpose of this section is to establish Department of
Commerce (DOC) policy for certification of all unclassified
sensitive and classified national security Information
Technology (IT) systems.

B. Overview:

Protection requirements for each of the individual IT systems
within the Department will vary according to the unique
characteristics of the system, environmental concerns, data
sensitivity and mission related criticality of the system or data.
Total protection against all threats may be an unrealistic goal.
Appropriate levels of security must be determined by an
evaluation of the threats, vulnerabilities and risk factors
associated with each system. Cost-effective controls that are
adequate to achieve an acceptable level of risk for the
individual system must then be implemented.

C. Background and Authority:

Certification is a requirement of Office of Management and
Budget (OMB) Circular Number A-130 and the "Computer
Security Act of 1987," Public Law 100-235.

D. Scope:

Certification is a requirement for all sensitive and classified
DOC General Support and Application systems. New IT
systems or those not fully operational shall complete all
certification requirements and be accredited prior to full
implementation.

2. General Support Systems - These consist of hardware and
software that provide general automated data processing
or network support for a variety of users and applications.
Individual applications may be less easily distinguishable
than in the previous category, but such applications may
contain sensitive information, or be critical to the mission
accomplishment of the organization. Even if none of the
individual applications are sensitive, the support system
itself may be considered sensitive if, the aggregate of
applications and support provided are critical to the
mission of the operating unit.

E. Policy:

Initial Certification

Prior to accreditation, each IT system is to undergo appropriate
technical certification evaluations to ensure that it meets all
federal and DOC policies, regulations and standards and that
all installed security safeguards appear to be adequate and
appropriate for the protection requirements of the system.
Certification of the system is based on the documented results
of the design reviews, system tests, and the recommendations of
the testing teams. All systems must include security controls
that reflect the true importance of the information processed on
the system and/or the government investment embodied in the
components of the IT system. Section F., of this document,
identifies the required actions in the certification process.

Interim Certification

The certification process must be flexible enough that it
accommodates the need for operational efficiency as well as
adequate protection of the system. There may be situations
when the need for a system is such that it must be put into
operation before a full certification is possible. In this case, the
Certifying Official can provisionally certify the system for
operation, possibly with some restrictions, pending specific
actions to be completed in a predefined time frame. This
interim certification cannot exceed one year. These actions
should also be included as milestones in the security plan for
the system.

Recertification

Systems will be recertified when substantial changes are made
to the system, when changes in requirements result in the need
to process data of a higher sensitivity, after the occurrence of
a serious security violation which raises questions about the
validity of an earlier certification, and in any case no less
frequently than three years after the previous certification.
Examples of major changes include:

1. Changes in the system or software applications -
Substantial changes which alter the mission, operating
environment or basic vulnerabilities of the system.
Increase or decrease in hardware, application programs,
external users, hardware upgrades, addition of
telecommunications capability, dial-in lines, changes to
program logic of application systems, relocation of system
to new physical environment or new organization. Minor
changes such as, replacement of similar hardware when
capacity does not significantly change, addition of two or
three workstations on a network or small modifications to
an application program (e.g., table headings are changed)
would not require recertification.

2. Changes in protection requirements - Changes in the
sensitivity or classification level of the data being
processed, increase in the mission criticality of the system
or changes in federal or DOC policies.

3. Occurrence of a significant violation - A violation or
incident that calls into question the adequacy of the
system security controls.

4. Audit or evaluation findings - Findings from any security
review that identifies significant unprotected risks. These
could include the system IT security verification review,
physical or information security inspection, internal
control reviews, Office of the Inspector General (OIG)
audits or General Accounting Office (GAO) audits.

F. Responsibilities and Process:

Certification evaluations are conducted by the organization that
owns the system. The official certification document is signed
by a senior management official in the system owning
organization. Chapter 10, Section 10.1 of the "DOC IT
Management Handbook" and Section 1 of the "DOC IT
Security Manual" contain specific information about
designation of ownership of IT systems and data. Owners of
DOC IT systems will complete all required certification actions,
issue a certification statement and prepare an accreditation
package which will be forwarded to the Designated Approving
Authority for formal accreditation of the system. A sample
certification statement and request for accreditation is
contained in Attachment 1 of this document.

The information included in the certification documentation will
contain details about the system, which may identify weaknesses
or vulnerabilities which require protection against disclosure to
persons without an official need to know. Certification
documentation for sensitive systems will be marked at least
"For Official Use Only." Classified IT system certification
documentation will be marked in accordance with appropriate
national security directives and DAO 207-2, "DOC National
Security Information Manual."

Certification Review Team

A Certification Review Team should be established to conduct
the technical evaluation of the system. The Certification
Review Team should get input from all who have involvement
with the system, including: IT security staff; system owner
staff; computer program development staff, if the application
was developed in-house; the computer operations staff, if the
application is run on a computer managed by a separate
organization; and users. Representatives from as many of these
organizations as possible should be included on the Certification
Review Team.

The Certification Review Team will be responsible for
performing all actions required for the certification evaluation,
evaluating the results and preparing a report with
recommendations for the system owner about certification of
the system.

Certification Testing of Security Controls

The technical certification evaluation results are the basis for
the system owner's certification statement in the accreditation
request. The letter should state what methods were used to
perform the certification evaluation.

The first step in the certification process is to determine what
the protection requirements for the IT system should be, based
on the sensitivity or criticality of the individual system. Once
these requirements are defined, cost-effective controls can be
selected and implemented that will provide adequate protection
to achieve an acceptable level of risk.

The goal of the technical certification evaluation is to test
existing controls to determine: (1) if controls function properly;
(2) if controls satisfy performance criteria and provide for
availability, survivability and accuracy; and (3) if the controls
can be easily broken or circumvented. The technical
certification evaluation can be accomplished by two or more of
the following:

System Owner Evaluation and Testing

Security controls installed and implemented require testing to
ensure they meet the defined security requirements for the
system and that they function as expected. System owners
should maintain documented results of these tests, which can be
used as part of the certification review. In addition to specific
tests of individual controls, evaluation of the overall system may
also be performed. These evaluations may take the form of
checklists or other methods that ensure consideration has been
given to all security requirements and controls. Copies of
evaluation results should be included in the certification report
included in the accreditation package. The Department has
developed and approved two separate methodologies which can
be used by the system owner in planning and conducting the
required certification evaluation. Each of these methodologies
provides a structured process that will ensure that all
appropriate actions have been completed and documented. The
system owner should select one of the following methodologies
for the Certification Review Team's use:

1. "Methodology for Certifying Sensitive Computer
Applications," contained in Attachment 2 of this document
is especially suited for large complicated software
applications, for applications which are in-house developed
or involve extensive modifications to customize for
Commerce use, applications with very high sensitivity such
as major financial applications which process high dollar
amounts or are subject to fraud or abuse, or for new
applications without existing security documentation.

2. "Abbreviated Certification Methodology for Sensitive IT
Systems," contained in Attachment 3 of this document is
an abbreviated form of the above methodology. It was
developed to address existing sensitive systems with
extensive documentation already available. It is intended
to handle the certification evaluation requirements of
smaller systems and systems and applications such as
those associated with personal computers or those systems
with only a few users, and turn-key or commercial
systems which were procured against a detailed set of
security specifications. It can be used for completing the
technical certification evaluation requirements for both
application systems and general support systems.

Other Internal Reviews

The results of any security related reviews performed by
evaluation teams internal to the operating unit or the system
owner's organization may be used as part of the certification
evaluation. These reviews may include internal control reviews,
physical or information security inspections or IT security
verification reviews. Corrective actions resulting from any
review findings should be tested and documented. Copies of
review findings and corrective actions taken should be included
in the certification documentation for the accreditation package.

External Reviews

The results of any audits performed by independent external
organizations may also be used as part of the certification
evaluation. These audits or reviews may have been performed
by the OIG, GAO, DOC or commercial Electronic Data
Processing (EDP) audit firms. Implementation of any
corrective actions taken as a result of these audit findings
should be tested and documented. Copies of audit findings and
corrective actions taken should be included in the certification
documentation for the accreditation package.

For classified IT systems, external organizations such as
Department of Defense, National Security Agency, State
Department, Central Intelligence Agency, etc., who have specific
requirements for data under their area of responsibility, may
also perform reviews and inspections. Any authorizations or
approvals provided by these external organizations are
important certification documentation and must be provided
with the request for accreditation.

Risk Analysis

Risk analysis can play a dual role in the evaluation process. It
can be used to help determine important security requirements
for the IT system and also to evaluate the existing and planned
controls for cost-effective risk reduction. Since risk analysis
must be performed throughout the life cycle of the system, it
provides a method for reassessing the risks against system
changes and determining additional controls required to bring
the system to an acceptable level of risk.

ATTACHMENT 1

SAMPLE CERTIFICATION STATEMENT AND REQUEST
FOR ACCREDITATION

MEMORANDUM FOR: (Designated Approving Authority)

FROM: (System Owner)

SUBJECT: Request for Accreditation of DOC IT System
Number ______, "ABC Computer Center"

Attached is the required accreditation documentation for DOC
Information Technology (IT) System Number ______, "ABC
Computer Center." Based on the information contained in these
documents, I certify (with the exceptions or clarifications noted
below) that this system meets all federal and DOC policies,
regulations and standards and that all installed security safeguards
appear to be adequate and appropriate for the sensitivity of this
system.

The methods used to perform the certification evaluation included
testing installed controls, completing a checklist for evaluating
implemented controls against defined security requirements and
implementing additional controls recommended by the Office of
Inspector General (OIG) audit.

(exceptions or clarifications)

Weighing the remaining residual risks against operational
requirements, I recommend that you authorize (continued) operation
of this IT system (under the following restrictions):

(restrictions)
ATTACHMENT 2

(Methodology published in 1988 is still usable, but being revised)

U. S. DEPARTMENT OF COMMERCE

ABBREVIATED CERTIFICATION
METHODOLOGY
GUIDELINES

FOR SENSITIVE AND CLASSIFIED
INFORMATION TECHNOLOGY
SYSTEMS

December 1, 1992

U. S. DEPARTMENT OF COMMERCE
ABBREVIATED CERTIFICATION
METHODOLOGY
FOR SENSITIVE INFORMATION
TECHNOLOGY SYSTEMS

A. INTRODUCTION

It is the policy of the Department of
Commerce (DOC) to comply fully with all
federal statutes and directives on information
technology (IT) security and to provide
protection commensurate with the sensitivity of
the systems or data processed.

Protection requirements for each of the
individual IT systems within the Department
will vary according to the unique
characteristics of the system, environmental
concerns, data sensitivity and mission related
criticality of the system or data. Appropriate
levels of security must be determined by an
evaluation of the threats, vulnerabilities and
risk factors associated with each system. Cost-
effective controls that are adequate to achieve
an acceptable level of risk for the individual
system must then be implemented.

The DOC "Information Technology
Accreditation Policy" issued on July 6, 1992
established the requirement for accreditation of
all unclassified sensitive and classified national
security IT systems. Accreditation is the
authorization and approval, granted to a
sensitive or classified IT system to process, as
an acceptable risk, in an operational
environment. Accreditation is made on the
basis of recommendations from a technical
certification evaluation that the IT system
meets all applicable federal and DOC policies,
regulations, and standards and that all installed
security safeguards appear to be adequate and
appropriate for the sensitivity of the system;
that they are operating correctly; or, that the
system must be operated under certain
specified conditions or constraints.

The technical certification evaluation results
are the basis for the system owner's
certification statement in the accreditation
request.

B. PURPOSE

The purpose of this document is to provide
guidance on appropriate procedures to follow
in performing the technical certification
evaluations of all sensitive and classified
national security systems within the
Department.

The DOC issued a "Methodology for
Certifying Sensitive Computer Applications" in
March 1987. The process described in that
document was required for any new DOC
applications or any modification of existing
applications that handle sensitive information.
It is especially suited for large complicated
applications, for applications which are in-
house developed or involve extensive
modifications to customize for Commerce use,
applications with very high sensitivity such as
major financial applications which process high
dollar amounts or are subject to fraud or abuse,
or for new applications without existing
security documentation. This original
certification methodology should be used for
systems meeting the above criteria.

That methodology has proved to be far too
complex for many of the Department's
systems. The methodology described in this
document is an abbreviated form of this
process, developed to address existing sensitive
systems with extensive documentation already
available. It is intended to handle smaller
systems and applications such as those
associated with personal computers (PCs) or
those systems with only a few users, and turn-
key or commercial systems which were
procured against a detailed set of security
specifications. This abbreviated methodology
stresses the use of existing documentation
wherever possible. It can be used for
completing the technical certification
evaluation requirements for both application
systems and general support systems. The
term "system" used in this document is
intended to mean either of the following, as
appropriate:

1. Application Systems - Systems that
perform clearly defined functions for which
there are readily identifiable security
considerations and needs. Such a system
might actually comprise many individual
application programs and hardware,
software, and telecommunications
components. They can be either a major
software application or a combination of
hardware/software where the only purpose
of the system is to support a specific
mission related function. The system may
process multiple individual applications, if
all are related to a single mission function.

2. General Support Systems - These consist of
hardware and software that provide general
automated data processing or network
support for a variety of users and
applications. Individual applications may
be less easily distinguishable than in the
previous category, but such applications
may contain sensitive information, or be
critical to the mission accomplishment of
the organization. Even if none of the
individual applications are sensitive, the
support system itself may be considered
sensitive if the aggregate of applications
and support provided are critical to the
mission of the operating unit.

C. ABBREVIATED CERTIFICATION
METHODOLOGY

Certification is based on a technical evaluation
of a sensitive system to see how well it meets
its security requirements, including all
applicable federal policies, regulations, and
standards. The results of tests should
demonstrate that the installed security
safeguards are adequate and appropriate for the
system. The certification process is the final
step leading to accreditation of the system.
Sensitive systems will be recertified and
reaccredited when substantial changes are made
to the system, when changes in requirements
result in the need to process data of a higher
sensitivity, after the occurrence of a serious
security violation which raises questions about
the validity of an earlier certification, and in all
cases no less frequently than three years after a
previous certification.

Certification evaluations are conducted by the
organization that owns the system. The
certification team should get input from all
who have involvement with the system,
including:

IT security staff,

system owner staff,

computer program development staff, if the
application was developed in-house, and

the computer operations staff, if the
application is run on a computer managed
by a separate organization.

users

Representatives from as many of these
organizations as possible should be included on
the Certification Review Team.

The certification methodology described in this
document consists of the following steps,
which will be described more fully in the rest
of this document:

Step 1. Assemble a team
Step 2. Collect existing documents
Step 3. Describe the system and its
sensitivity
Step 4. Identify protection requirements
and vulnerabilities
Step 5. Identify security features needed
Step 6. Test the adequacy of controls
Step 7. Evaluate test results
Step 8. Certify the system

Worksheet forms to document each step in the
certification process are provided in Appendix
A.

Definitions

Certification is a technical evaluation of a
sensitive system to see how well it meets
necessary security requirements, such as
appropriate federal policies, regulations, and
standards.

The Certifying Official is a senior manager in
the organization which owns the system. The
system owner is the organization which has
functional responsibility for the system. The
Certifying Official should be a manager who
was responsible for having the system
developed or the functional area that the
system supports, who has a need for the results
produced by the system, and can allocate
resources to correct deficiencies in the security
controls for the system.

The Certification Review Team will collect the
information needed for the certification
process, identify vulnerabilities, develop a list
of needed security features, develop tests of the
adequacy of the features, and evaluate the test
results.

Security features are controls that protect
against the identified vulnerabilities, such as
fire and water alarms, passwords and other
access protection, use of removable media for
data storage, data validation controls, audit
trails, uninterruptable power sources to protect
against electrical outages, personnel screening,
IT security awareness training of users, etc.

A sensitive system is one that requires some
degree of protection for confidentiality,
integrity or availability. This includes data
whose improper use or disclosure could
adversely affect the ability of an agency to
accomplish its mission, proprietary data,
records about individuals requiring protection
under the privacy Act, and data not releasable
under the Freedom of Information Act. If the
system is required for accomplishment of an
agency mission it need not contain any
sensitive data.

Test scenarios are descriptions of the tests to
be performed to check the effectiveness of the
security features incorporated into the system.
They may include validation of password
constraints such as length and composition of
the password, entry of erroneous data to check
data validation controls, review of audit
information produced by the system, review of
contingency plans and risk analyses, etc.

Vulnerabilities are ways in which the system
may be attacked or may fail. They include
susceptibility to physical dangers such as fire
or water, unauthorized access to sensitive data,
entry of erroneous data, denial of timely
service, fraud, etc.

Methodology Approach

Step 1 - Assemble a team: The first step in
the abbreviated process is to assemble a team
to gather the information and documentation
needed to assess and demonstrate the adequacy
of security measures used. The team should
include representatives of IT security,
application owners, software development,
computer systems, and users. For very small
systems the users, software programming staff,
and computer systems staffs may be the same.
The IT security staff provides an outside
viewpoint to ensure that the best IT security
practices are used in protecting sensitive
systems. Where computer system staff,
software programmers, and users are in
separate organizations, it is important that all
points of view are represented in the process,
to ensure that user expectations of protection
needs are addressed, and that software and
computer system constraints are understood.

Step 2 - Collect existing documents needed
for the certification evaluation: These
documents include, but are not limited to:

1. system specifications and
documentation
2. system security plan
3. risk analysis
4. contingency and disaster recovery plans
5. staff records on personnel and the IT
Security Officer identification, training
and position sensitivity levels
6. Internal Control Reviews, security
reviews, etc., if existing

Step 3 - Identify and describe the system to
be certified and describe why it is sensitive:
It is necessary to have a written description of
the purpose of the system, the hardware and
software environment on which the system is
operated, and a description of the sensitivity of
the system, including any special applicable
laws and regulations. This information is
readily available in the Sensitive System
Security Plan for the system being certified. If
the certification is for a software application
system that will be used by others, the
hardware description should address the
hardware needed to operate the system, but the
certification should focus on the software
application program. Complete the blank
sections of Sensitive System Certification
Worksheet 1, System Description and attach a
copy of the approved Sensitive System
Security Plan for the system being evaluated.
The Worksheet identifies the section numbers
in the security plan where detailed information
can be obtained for review.

Step 4 - Identify protection requirements
and vulnerabilities: Review the description of
the protection requirements for the system
under the headings confidentiality, integrity,
and availability in Section II.B. of the
Sensitive System
Security Plan. Enter the levels of protection
required (high, medium, low) in the blanks
provided on Worksheet 1.

Identify vulnerabilities for the system related to
these protection requirements. Most
vulnerabilities will be addressed in the existing
documents collected in Step 2. All sensitive
systems should have a completed risk analysis.
The risk analysis will identify vulnerabilities
and their consequences, such as unauthorized
disclosure of information, loss of data or other
resources, denial of service, decisions based on
erroneous information, etc. System
documentation is another source of information
about the vulnerabilities. The security plan for
the system being evaluated contains
information about specific vulnerabilities and
control measures addressed. The team should
also review any existing Internal Control,
Inspector General (IG) or security review
reports on the system, for additional
information on system vulnerabilities. In
addition to the documentation, the team may
need to interview managers in the user
organization to ascertain their concerns about
the sensitivity of the system and the level of
protection required.

Complete the Sensitive System Certification
Worksheet 2: Identified Vulnerabilities by
listing the identified vulnerabilities.

Step 5 - Identify security features needed:
The team next needs to review existing
documents to identify the controls in place to
address the vulnerabilities identified above.
The risk analysis, security plans, and system
documentation reviewed for vulnerabilities also
contain information on controls used to reduce
those vulnerabilities. System specifications, if
they still exist, will also provide information on
the controls designed into the system. The
team will also need to review the contingency
and disaster recovery plans for the system.
The team should interview the IT System
Security Officer to review installation IT
security procedures. Staff training records will
show the level of IT security training given to
application and computer installation staff.
Staff records should also show the sensitivity
designation of staff positions and any personnel
investigations, required and conducted, for staff
in the affected positions. Complete the
Sensitive System Certification Worksheet 3:
Security Features.

Step 6 - Test adequacy of controls: Once
vulnerabilities and controls have been
identified, the team should selectively check
the adequacy of the controls. Some live tests
may be needed to ensure that documented
controls actually work. Other controls may be
reviewed through other means. Previous
system reviews and system acceptance tests
may contain records of tests previously
performed. It is not necessary to repeat these
tests, if the system has not changed since they
were done. The review of vulnerabilities and
controls should identify any areas not
adequately addressed. Sensitive System
Certification Worksheet 4: Security Tests is
used to list the tests to be performed. Use
Sensitive System Certification Worksheet 5:
Security Test Results to record the results of
the tests.

Step 7 - Evaluate the test results: Once all
tests are completed, a summary of the
evaluation of the tests should be prepared. The
team should then prepare recommendations
about certification. Sensitive System
Certification Worksheet 6: Evaluation and
Recommendations is used to record the
evaluation of test results and the team's
recommendation. The recommendation section
should be signed by all members of the team
and dated.

If the tests results indicate that all
protection requirements have been met, the
team can recommend certification with no
further action required.

The Certification Review Team may
determine from the test results that the
protection requirements were not met for
the system. In that case, the evaluation
discussion of test results should explain the
inadequacy of the controls in place.

The team may alternatively certify that the
basic protection requirements have been
met, but recommend additional features be
required. This latter form of certification
is appropriate for certifying a software
application system which must have certain
operating system or hardware features in
place for approved operation. This may
also be used in recommending interim
accreditation pending installation of some
additional control not currently available.

Step 8 - Certification: The official
Certification document is signed by a senior
management official in the system owning
organization. A sample certification document
is attached as Appendix B.

There may be situations when the need for a
system is such that it must be put into
operation before a full certification is possible.
In this case, the Certifying Official can
provisionally certify the system for operation,
possibly with some restrictions, pending
specific actions to be completed in a
predefined time frame. This interim
certification cannot exceed one year. These
actions should also be included as milestones
in the security plan for the system. The
certification process must be flexible enough
that it accommodates the need for operational
efficiency as well as adequate protection of the
system.

APPENDIX A

SENSITIVE SYSTEM CERTIFICATION
WORKSHEETS

This Appendix contains a set of six worksheets to
assist with documenting the certification evaluation
of the system. Each worksheet is preceded by a
set of instructions and definitions which will
provide guidance for completing the evaluation and
the worksheet.

DIRECTIONS FOR COMPLETING
WORKSHEET 1:
SYSTEM DESCRIPTION

Much of the information requested on Worksheet 1
is contained in the Security Plan for the system.
To avoid having to rewrite this information and
have a ready reference to the needed information,
attach a copy of the Security Plan behind
Worksheet 1. Each worksheet contains blank lines,
where information must be entered. This step is
important to avoid confusion with other system
certification evaluation documentation.

System Name/Title is the name of the system used
in the Security Plan for a sensitive system (Section
I.B of the Security Plan). To avoid confusion with
other certification evaluation documentation this
should be written on all worksheets.

System ID is the unique six digit system
identification number assigned for each sensitive
system in the Department. Again, to avoid
confusion with other certification evaluation
documentation this should be written on all
worksheets.

System Owner is the name of the contact person
in the owning organization who is knowledgeable
about the system and protection requirements. It
may be the person listed as Information Contact
(Section I.G) in the Security Plan. Provide full
address and phone number, including area code, for
the owner.

Developer is the name of the person who is
responsible for developing the software. If this is
a commercial application, put the name of the
organization in this space. If there is no developer
or the developer's name is unknown, put "none" in
this space.

General Description/Purpose is a description of
the function and purpose of the system. This
information is contained in Section I.E of the
Security Plan.

System Environment and Special Considerations
is a description of the computer and software
environment of the system. This information is
contained in Section I.F of the Security Plan.

Sensitivity of Information Handled describes why
the system is sensitive.

Applicable Laws and Regulations lists any
laws and regulations that specifically apply to
this system, such as the Privacy Act. This
information is contained in Section II.A of the
Security Plan.

General Description of Information
Sensitivity is a description of why the system
is sensitive and the nature of that sensitivity.
This information is contained in the
introduction to Section II.B of the Security
Plan.

Description of Protection Requirements
describes what makes the system sensitive. The
descriptions of protection needs for confidentiality,
integrity, and availability are contained in Section
II.B of the Security Plan. Write in the designated
level (high, medium, low) in the blanks provided.
SENSITIVE SYSTEM CERTIFICATION
WORKSHEET 1
SYSTEM DESCRIPTIONSystem Name/TitleSystem
ID:
System Owner

Address: _______________________________
_______________________________
_
__________________________________
_____________________________
Phone: __________________________________
_____________________________General Description/Purpose
(See Section I.E. of attached security plan.)
System Environment and Special Consideration
(See Section I.F. of attached security plan).

Sensitivity of Information Handled:
Applicable Laws and Regulations Affecting the
System
(See Section II.A. of attached security plan.)

General Description of Information Sensitivity
(See Section II.B. of attached security plan.)
Description of Protection Requirements
See Section II.B. of attached security plan and
fill in the designated level (high, medium, low) in
the blanks.

Confidentiality ______

Integrity ______

Availability ______

DIRECTIONS FOR COMPLETING
WORKSHEET 2:
IDENTIFIED VULNERABILITIES

System Name/Title and System ID are the same
as on Worksheet 1.

Description of Identified Vulnerabilities should
include the vulnerabilities that the system may
have prior to putting controls in place. These
should have been identified in the risk analysis.
They might include physical vulnerabilities such as
fire or disk crashes, entry of erroneous data, denial
of service, and unauthorized access to information.
SENSITIVE SYSTEM CERTIFICATION
WORKSHEET 2
IDENTIFIED VULNERABILITIESSystem Name/TitleSystem
ID:

Description of Identified Vulnerabilities
(From Risk Analysis, Security Plan, system
documentation, interviews and other review

DIRECTIONS FOR COMPLETING
WORKSHEET 3:
SECURITY FEATURES

System Name/Title and System ID are the same
as on Worksheet 1.

Description of Security Features is a list of the
security features used to protect this system. They
can be taken from Sections III.C of the Security
Plan and include Management Controls,
Development/Implementation Controls for
application systems,
Acquisition/Development/Installation Controls for
general support systems, Operational Controls,
Security Awareness and Training, Technical
Controls and Complementary Controls Provided by
General Support Systems for application systems or
Controls Over the Security of Applications for
general support systems.

Although, it is not necessary to include the level of
detail contained in the Security Plan, the controls
should be listed to provide a foundation for
selecting tests to be performed to verify if the
controls are adequate and appropriate and are
operating as expected.
SENSITIVE SYSTEM CERTIFICATION
WORKSHEET 3
SECURITY FEATURESSystem Name/TitleSystem
ID:
Description of Security Features:

DIRECTIONS FOR COMPLETING
WORKSHEET 4:
SECURITY TESTS

System Name/Title and System ID are the same
as on Worksheet 1.

Test Scenarios should contain a numbered list of
the tests to be preformed to verify the controls
listed on Worksheet 3. For more detail about the
controls, see Section III.C. of the security plan.

If this is an existing system that has been
in operation for some time, the tests may
selectively test the most critical controls.

If the system is under, or just completed
development, or is a turn-key system, all
security controls should be tested.

If testing has been done for a another
recent review, or during recent acceptance
testing of the system, it may not be
necessary to repeat the tests. It will be
necessary to review records of the prior
tests, and determine if the documentation
of the tests and results are adequate. If it
is determined that it is not justified to
repeat the tests, a statement should be
included on Worksheet 4 explaining the
reason. Also, include enough information
about all supporting documentation
reviewed, to allow it to be located for
future reference. At a minimum, include a
list of tests from the documentation, that
were performed. This list need not contain
as much detail for each individual test as
the referenced documentation.

SENSITIVE SYSTEM CERTIFICATION
WORKSHEET 4
SECURITY TESTSSystem Name/TitleSystem
ID:
Test Scenario:

DIRECTIONS FOR COMPLETING
WORKSHEET 5:
SECURITY TEST RESULTS

System Name/Title and System ID are the same
as on Worksheet 1.

Test Results reports the results of each of the tests
described on Worksheet 4. The numbers on
Worksheet 5 for each test result should agree with
the numbers on Worksheet 4 for the test
description. Indicate whether the was "Passed" or
"Failed".

SENSITIVE SYSTEM CERTIFICATION
WORKSHEET 5
SECURITY TEST RESULTSSystem Name/TitleSystem
ID:
Test Results:

DIRECTIONS FOR COMPLETING
WORKSHEET 6:
EVALUATION AND RECOMMENDATIONS

System Name/Title and System ID are the same
as on Worksheet 1.

Evaluation of Test Results should discuss the
results of the tests and their relationship to assuring
the adequacy of controls.

Under Recommendations check one of the three
responses.

Check Tests indicate that protection
requirements were met if all tests resulted
in correct results.

Check Tests indicate that protection
requirements were not met if some tests
failed and corrections have not been, or
cannot be implemented.

Check Tests indicate that protection
requirements were met; recommend
certification with the following additional
security features required: if there are
additional security controls needed to meet
the protection requirements. This category
should be used when certifying software
applications that require hardware or
operating system features to assure
adequate protection. It should also be used
if an interim certification is being
recommended, pending completion of
specific actions.

Certifying Team Signatures should included
printed names of the certifying team members, a
signature, and a date for each team member.

SENSITIVE SYSTEM CERTIFICATION
WORKSHEET 6
EVALUATION AND RECOMMENDATIONSSystem Name/TitleSyste
m ID:
Evaluation of Test Results:

Recommendations:

_____ Tests indicate that protection
requirements were met.
RECOMMEND CERTIFICATION OF
THIS SYSTEM.

_____ Tests indicate that protection
requirements were not met.
RECOMMEND THAT THIS SYSTEM
NOT BE CERTIFIED.

_____ Tests indicate that protection
requirements were met; recommend
certification with the following
additional security features required:

Certifying Team Signatures

Name Signature
Date

Appendix B

Sample Certification Statement

I have carefully examined the certification
worksheets for DOC Information Technology
System Number _________, "Insert system
name/title", dated ___________________ . Based
on the information contained in this package and
the results of tests conducted on the system, it is
my judgment that satisfactory information
technology controls are in place to adequately
protect the system and that it is operating at an
acceptable level of risk.

I hereby certify DOC IT System Number
________, "Insert system name/title", for a period
not to exceed three years. Should substantial
changes or security incidents occur during that
three year period, which bring the adequacy of the
protection measures for this system into question, a
reevaluation and recertification must be completed
earlier.

Certification Official Name/Title:

_______________________________________
_______
_______________________________________
_______

Signature:
__________________________________________
___ Date: ____________

SECTION 4
ACCREDITATION

A. Purpose:

The purpose of this section is to establish
Department of Commerce (DOC) policy for
accreditation of all unclassified sensitive and
classified national security Information
Technology (IT) systems.

B. Overview:

Accreditation is the authorization and approval,
granted to a sensitive or classified IT system to
process, as an acceptable risk, in an operational
environment. Accreditation is made on the
basis of recommendations from a technical
certification evaluation that the IT system
meets all applicable federal and DOC policies,
regulations, and standards and that all installed
security safeguards appear to be adequate and
appropriate for the sensitivity of the system;
that they are operating correctly; or, that the
system must be operated under certain
specified conditions or constraints.

C. Background and Authority:

Accreditation is a requirement of Office of
Management and Budget (OMB) Circular
Number A-130 and the "Computer Security
Act of 1987," Public Law 100-235.

D. Scope:

The policy contained in this document covers
all DOC IT systems, whether maintained in-
house or commercially.

Accreditation is required for all sensitive and
classified DOC General Support and
Application systems. New IT systems or those
not fully operational shall complete all
requirements and be accredited prior to full
implementation.

E. Policy:

This policy defines the final step in the IT
Security management process that ensures
protection of the vital IT resources within the
Department.

Initial Accreditation

All sensitive and classified DOC IT General
Support or Application systems will be
accredited. The term accreditation describes
the process whereby information pertaining to
the security of a system is developed, analyzed
and submitted for approval to the appropriate
senior management official identified in this
document as the Designated Approving
Authority (DAA). Section F, of this document,
identifies the required steps in the accreditation
process. The DAA will review the
accreditation support documentation and either
concur, thereby declaring that a satisfactory
level of operational security is present or not
concur, indicating that the level of risk either
has not been adequately defined or reduced to
an acceptable level for operational
requirements. The DAA will sign a formal
accreditation statement declaring that the
system appears to be operating at an acceptable
level of risk, or defining any conditions or
constraints that are required for appropriate
system protection. Sample accreditation
statements are contained in Attachment 1 of
this document.

Security of classified IT systems operated by,
or in support of DOC programs is the
responsibility of the Department and these
systems must be accredited in accordance with
the requirements defined in this policy.
Approvals granted by external agencies, i.e.,
Department of State, Department of Defense,
Central Intelligence Agency, etc., are not valid
authority to operate classified IT systems
within the Department. Approvals granted to
these systems by DOC, prior to this policy, are
no longer in effect and new approval to operate
must be granted through the DOC accreditation
process.

Interim Accreditation

Interim authority to operate can be granted for
a fixed period of time, not to exceed one year.
This authority is based on an approved security
plan and is contingent on certain conditions
being met. The interim authority to operate,
while continuing the accreditation process,
permits the IT system to meet its operational
mission requirements while improving its IT
security posture. If the DAA is not satisfied
that the IT system is protected at an acceptable
level of risk, an interim accreditation can be
granted to allow time for implementation of
additional controls. Recommendation or
request for an interim accreditation may be
made by the IT system owner, the operating
unit IT Security Officer (ITSO) or the DAA.
Interim authority to operate is not a waiver of
the requirement for accreditation. The IT
system must meet all requirements and be fully
accredited by the interim accreditation
expiration date. No extensions of interim
accreditation can be granted except by the
DOC Director for Information Resources
Management.

Reaccreditation

Systems will be reaccredited when major
changes occur to the system or every three
years, whichever occurs first. Examples of
major changes include:

1. Changes in the system or software
applications - Substantial changes which
alter the mission, operating environment or
basic vulnerabilities of the system. Increase
or decrease in hardware, application
programs, external users, hardware
upgrades, addition of telecommunications
capability, dial-in lines, changes to program
logic of application systems, relocation of
system to new physical environment or
new organization. Minor changes such as,
replacement of similar hardware when
capacity does not significantly change,
addition of two or three workstations on a
network or small modifications to an
application program (e.g., table headings
are changed) would not require
reaccreditation.

2. Changes in protection requirements -
Changes in the sensitivity or classification
level of the data being processed, increase
in the mission criticality of the system or
changes in federal or DOC policies.

3. Occurrence of a significant violation - A
violation or incident that calls into question
the adequacy of the system security
controls.

4. Audit or evaluation findings - Findings
from any security review that identifies
significant unprotected risks. These could
include the system security verification
review, physical or information security
inspection, internal control reviews, Office
of the Inspector General (OIG) audits or
General Accounting Office (GAO) audits.

Prior to reaccreditation, an on-site IT security
verification review must be conducted by an
evaluation team under the direction of the
DOC IT Security Manager, the operating unit
ITSO or the ITSO of a subordinate
organizational unit (i.e., Line Office, Regional
Office, Laboratory, etc.) The IT security
verification review team may not be under the
direction of personnel from the subordinate
organization having direct control over the IT
system being evaluated. The IT System
Security Officer (ITSSO) for the system under
review should participate as a member of the
IT security verification review team. The
purpose of this review is to ensure that all
controls and vulnerabilities are properly
documented, and that adequate and appropriate
levels of security exist for protection of the
system. Requirements and guidance for
conducting IT serurity verification reviews are
contained in Chapter 10, Section 10.5 of the
"DOC IT Management Handbook" and Section
5 of the "DOC IT Security Manual."

F. Responsibilities and Process:

Classified National Security IT Systems

1. The DOC Director for Information
Resources Management is the DAA for all
classified IT systems within the
Department. This authority can not be
delegated below this level. Accreditation
will be granted only with the
recommendations of the DOC Director,
Office of Security, DOC Chief,
Telecommunications Management Division
and the DOC IT Security Manager.

2. The DOC IT Security Manager will act as
the central point of contact for
accreditation of classified IT systems and
will evaluate the adequacy of all technical
controls protecting these systems. The
DOC IT Security Manager will review all
accreditation documentation, evaluate the
security controls for the IT system and
conduct on-site reviews, if necessary, to
ensure they meet all applicable federal and
DOC policies, regulations and standards
and that they appear to be adequate and
appropriate for protection of the system.
The DOC IT Security Manager will submit
recommendations to the DAA for or
against accreditation. Recommendation
should include any additional controls or
constraints required to meet a satisfactory
level of operational security.

3. The Chief, Telecommunications
Management Division will evaluate all
supporting accreditation documentation and
conduct on-site inspections, when
necessary, to ensure compliance with all
Communications Security (COMSEC) and
emanations (TEMPEST) security
requirements as required by the Chapter 8
of the "DOC IT Management Handbook."

4. The DOC Director, Office of Security will
evaluate all supporting accreditation
documentation and conduct on-site
inspections, when necessary, to ensure
compliance with appropriate national
security directives and DAO 207-2, "DOC
National Security Information Manual."

Unclassified Sensitive IT Systems

1. The Senior Information Resources
Management official in each operating unit
will be the DAA for all sensitive systems
within their organization. This approval
authority may only be delegated to a senior
management official of a subordinate
organizational unit, if that official does not
have direct control over the IT system
being accredited. Delegation of
accreditation authority must be requested
and approved in advance by the DOC
Director for Information Resources
Management.

2. The operating unit ITSO will act as the
central point of contact for accreditation of
all sensitive IT systems within the
organization. The ITSO will review all
accreditation documentation, evaluate the
security controls for the IT system and
conduct on-site reviews, if necessary, to
ensure they meet all applicable federal and
DOC policies, regulations and standards
and that they appear to be adequate and
appropriate for protection of the system.
The ITSO will submit recommendations to
the DAA for or against accreditation.
Recommendations should include any
additional controls or constraints required
to meet a satisfactory level of operational
security.

The operating unit ITSO will submit an
accreditation status report quarterly to the
DOC IT Security Manager, listing
accredited systems by DOC identification
numbers, including interim accreditations,
and the completed date. A copy of all
official accreditation statements will be
forwarded with this list.

IT System Owners

Chapter 10, Section 10.1 of the "DOC IT
Management Handbook" and Section 1 of the
"DOC IT Security Manual" contain specific
information about designation of ownership of
IT systems and data. Owners of DOC IT
systems will complete all required actions and
prepare an accreditation package including all
documentation identified in this section. For
classified IT systems, the accreditation package
will be forwarded to the DOC IT Security
Manager through the ITSO and the Senior
Information Resources Management official for
the operating unit. Sensitive IT system
accreditation packages will be forwarded to the
appropriate ITSO for the operating unit.

The information included in the accreditation
package will contain details about the system,
which may identify weaknesses or
vulnerabilities which require protection against
disclosure to persons without an official need
to know. Accreditation packages for sensitive
systems will be marked at least "For Official
Use Only." Classified IT system accreditation
packages will be marked in accordance with
appropriate national security directives and
DAO 207-2, "DOC National Security
Information Manual."

The following actions shall be completed and
the appropriate documentation prepared and
submitted in the accreditation package to the
appropriate DAA for the IT system:

Request for Accreditation

The system owner will prepare a written
request for approval to operate the IT system
and forward the documentation listed below to
the appropriate DAA. The written request will
include a certification statement that the IT
system has undergone adequate tests to ensure
that it meets all federal and DOC policies,
regulations and standards and that all installed
security safeguards appear to be adequate and
appropriate for the sensitivity of the system.

Approved IT System Security Plan

A detailed IT system security plan will be
prepared by the system owner, in the required
format provided in the "DOC Guidelines for
Developing and Evaluating Security Plans for
Sensitive and Classified Systems," contained in
Section 2 of the "DOC IT Security Manual."
The purpose of the system security plan is to
provide a basic overview of the security and
privacy requirements of the subject system and
the IT system owner's plan for meeting those
requirements. The plan may also be viewed as
documentation of the structured process of
planning adequate, cost-effective security
protection for the system.

The IT system security plan must be forwarded
through the operating unit's ITSO for review
and comment, and once all corrective actions
have been completed, to the DOC IT Security
Manager for final approval. A statement of
approval will be sent to the operating unit
ITSO for forwarding to the IT system owner.
Security plans must be reviewed by the system
owner, at least annually, and changes
submitted, as necessary, to ensure they are up-
to-date.

Chapter 10, Section 10.2 of the "DOC IT
Management Handbook" contains the DOC
policy for IT system security plans. Section 2
of the "DOC IT Security Manual" contains
detailed guidance for preparation of these
plans.

Completed Risk Analysis

IT system owners are responsible for having a
risk analysis conducted for each IT system to
ensure that appropriate, cost effective
safeguards are incorporated into existing and
new systems. A risk analysis will be
conducted prior to approval of design
specifications for new systems, when major
changes occur to the system or every three
years, whichever occurs first. Examples of
major system changes are given in Section E.,
Reaccreditation, of this document.

See Chapter 10, Section 10.7 of the "DOC IT
Management Handbook" and Section 7 of the
"DOC IT Security Manual" for guidance on
conducting the required risk analysis.

Contingency/Disaster Recovery Plans

Each IT system shall develop and maintain, in
an up-to-date state, a contingency and disaster
recovery plan which will provide reasonable
assurance that critical data processing can be
continued, or resumed quickly, if normal
operations are interrupted. The plan for large
systems supporting essential Departmental or
agency functions shall be fully documented and
operationally tested at least annually. Small
systems may develop a more abbreviated and
less formal plan. Policy concerning
contingency/disaster recovery planning is
contained in Chapter 10, Section 10.8 of the
"DOC IT Management Handbook" and Section
8 of the "DOC IT Security Manual."
Additional guidance is contained in Section 7
of the "DOC IT Security Manual."

Software Application Certification Statements

Sensitive application software shall be
thoroughly tested prior to implementation to
verify that the user functions and the required
administrative, technical, and physical
safeguards are present and are effectively
operating as intended. If the system to be
accredited is running major applications
requiring separate certification, system owners
will provide copies of all software application
certification and recertification statements as
part of the accreditation package. General
support system owners running applications
belonging to other organizations are not
required to provide these certification
statements.

Certification Testing of Security Controls

Prior to accreditation, each IT system is to
undergo appropriate technical evaluations to
ensure that it meets all federal and DOC
policies, regulations and standards and that all
installed security safeguards appear to be
adequate and appropriate for the sensitivity of
the system. The technical evaluation results
are the basis for the system owner's
certification statement in the accreditation
request. The letter should state what methods
were used to perform the certification
evaluation. The DOC certification policy is
contained in Chapter 10, Section 10.3 of the
"DOC IT Management Handbook." Section 3
of the "DOC IT Security Manual contains two
approved methodologies for conducting
certification testing.

The following certification evaluation
documentation will be included in the
accreditation package, as applicable:

1. System Owner Certification Reports

Include a copy of the certification review
report that shows: (1) that controls
function properly; (2) that controls satisfy
performance criteria and provide for
availability, survivability and accuracy; and
(3) that the controls cannot be easily
broken or circumvented. Copies of
evaluation results should be included.

2. Other Internal Reviews

3. External Reviews

The results of any audits performed by
independent external organizations may
also be used as part of the certification
evaluation. Copies of audit findings and
corrective actions taken should be included
in the accreditation package.

For classified IT systems, external
organizations such as Department of
Defense, National Security Agency, State
Department, Central Intelligence Agency,
etc., who have specific requirements for
data under their area of responsibility, may
also perform reviews and inspections. Any
authorizations or approvals provided by
these external organizations are important
certification documentation and must be
provided with the request for accreditation.

ATTACHMENT 1

SAMPLE ACCREDITATION STATEMENTS

Full Accreditation:

I have carefully examined the accreditation
package documentation for DOC Information
Technology (IT) System Number ______, "ABC
Computer Center," dated ____________. Based on
my authority and judgment, and weighing the
remaining residual risk against operational
requirements, I authorize (continued) operation of
this system (under the following restrictions).

(restrictions)

I hereby accredit DOC IT System Number ______,
"ABC Computer Center," as an unclassified
sensitive system, for a period not to exceed three
years. Should any major changes occur to this
system during this three year period, a re-
evaluation of the adequacy of its security controls
must be conducted and a reaccreditation requested.

_____________________________________
DAA Signature and Date

Interim Accreditation:

I have carefully examined the accreditation
package documentation for DOC Information
Technology (IT) System Number ______, "ABC
Computer Center," dated __________. Based on
my authority and judgment and the
recommendation of the (System Owner, ITSO or
DAA judgmentt) it does not appear that this system
has reached a satisfactory level of operational
security (or the following actions must be completed or additional controls
implemented prior to full accreditation).

(actions or additional controls required)

I hereby grant an interim accreditation to DOC IT System Number ______, "ABC Computer
Center," for a period not to exceed six months to allow time to (take action or implement
additional controls required). Prior to the expiration of this interim accreditation on
_______________, the accreditation package shall be resubmitted showing that a satisfactory
level of operational security has been reached.

______________________________________
DAA Signature and Date
SECTION 5
INFORMATION TECHNOLOGY SECURITY VERIFICATION REVIEWS

A. Purpose:

The purpose of this section is to establish Department of Commerce (DOC) policy for
conducting information technology (IT) security verification reviews of the
Department's sensitive and classified national security IT systems. The purpose of the
IT security verification review is to provide a level of review and evaluation
independent of the system owner, that will verify that adequate and appropriate levels
of protection are being provided for the individual systems, based on their unique
protection requirements.

B. Overview:

Protection requirements for each of the individual IT systems within the Department
will vary according to the unique characteristics of the system, environmental
concerns, data sensitivity and mission related criticality of the system or data. Total
protection against all threats may be an unrealistic goal. Appropriate levels of security
must be determined by an evaluation of the threats, vulnerabilities and risk factors
associated with each system. Cost-effective controls that are adequate to achieve an
acceptable level of risk for the individual system must then be implemented.

System owners are responsible for completing all DOC and federal requirements for
identifying their sensitive and classified systems, preparing security plans that provide
a basic overview of the security and privacy requirements of the subject system and
the system owner's plan for meeting those requirements, conducting risk assessments,
implementing controls determined to be required and cost-effective, developing
contingency and disaster recovery plans that will ensure availability of the system for
mission accomplishment and completing all requirements for certification and
accreditation of the system. The IT security verification review process provides an
independent means to ensure that the system owner has implemented adequate and
appropriate levels of protection, based on the system's unique requirements. The IT
security verification review process is part of the Department's oversight program.

C. Background and Authority:

The DOC IT security verification review process is established in compliance with the
"Computer Security Act of 1987," Public Law 100-235, OMB Circular A-130,
Appendix III, "Security of Federal Automated Information Systems" and OMB
Bulletin 90-08, "Guidance for Preparation of Security Plans for Federal Computer
Systems that Contain Sensitive Information."

D. Scope:

The policy contained in this document covers all DOC IT resources that have been
identified as either sensitive or classified national security systems whether maintained
in-house or commercially.

E. Policy:

An IT security verification review will be conducted on all DOC sensitive or classified
national security IT systems by an evaluation team under the direction of the DOC IT
Security Manager or the operating unit ITSO or the ITSO of a subordinate
organizational unit every three years. The security plan for the system will be used as
the foundation for the actual review. The review will be conducted in accordance with
the guidance contained in the "DOC Guidelines for Conducting IT Security
Verification Reviews of Sensitive and Classified Systems," Attachment 2 to this
document.

F. Responsibilities and Process:

IT Security Verification Review Team

The IT security verification review team will always be under the direction of the
DOC IT Security Manager or the IT Security Officer (ITSO) at the operating unit
level or a major subordinate organizational unit. This should assure the level of
knowledge about the DOC IT security program requirements is adequate to make
decisions about the appropriateness and adequacy of controls required for the system
under review. Whenever possible, these individuals should participate in the on-site
review as the team leader. When the ITSO is unable to participate in the actual
review, they will appoint an individual who is judged to have sufficient knowledge
about the DOC IT security program to act as the review team leader. Additional team
members should include personnel knowledgeable about physical and environmental
security, personnel security, information security (if system processes classified
national security information), application security, hardware and software,
telecommunications, technical controls, procedural security, contingency and disaster
recovery planning and risk management. Personnel from the Internal Control Review
area within the organization are also suggested as team members. The actual number
of team members may vary and should be limited to the smallest number possible to
cover all areas of concern. The average team will include two to four individuals, but
should be comprised of no less than two people.

Operating units may contract out for IT security verification reviews to be conducted
by commercial consulting firms or other federal organizations. However, care should
be taken in preparing the procurement requests or agreements to ensure that the review
will be conducted in accordance with all DOC policies and standards. The operating
unit ITSO will act as the COTR for the contract, provide all directions for conducting
the review and set standards for written reports.

The team leader will be responsible for notifying the system owner of the planned
review, making specific review assignments to individual team members based on their
expertise, coordinating activities of team members, conducting an in-briefing and an
exit-briefing with the system owners, conducting team meetings as required, making
decisions about what recommendations are appropriate for the individual system and
preparation of the draft and final "IT Security Verification Review Report." The
format and guidance for preparing this report is contained in Attachment 1 of this
document.

Conducting the Review

Written notification should be sent to the system owner two to four weeks in advance
of the review, providing information concerning the purpose of the review, dates of
the review, list of review team members, requesting the assignment of a point of
contact and that the following documentation be made available to the review team.

1. Memorandum officially designating an individual as the IT System Security
Officer (ITSSO)

2. Listing of current personnel (indicate working hours for ADP personnel)

3. Hours of operation of facility

4. Organization charts for highlighting the placement of the individual facilities

5. Applicable floor plans (including building floor plans)

6. Latest risk analyses for the system

7. Reports of external and internal security (both ADP and other) evaluations
completed during the 3 years

8. Hardware inventory (to include minis and micros)

9. Software inventory (include production programs, utility programs,
commercially available software, operating systems, etc.)

10. List of users:

a. within the Department
b. at other federal agencies
c. others

11. Disaster recovery plans

12. Policies, directives, guidelines, etc., pertaining to IT security issued by local
authorities

13. Minutes of any management meetings that address IT security

14. Any other documentation pertaining to IT security

15. Information pertaining to IT security awareness and training including course
content, type of training and number of personnel who have completed or are
scheduled for training

16. Information pertaining to ADP-related position sensitivity and personnel
screening for facility

17. Copies of any contracts for operation and maintenance or other service
agreements related to this system

18. Reports of any internal IT security reviews that may have been conducted

19. Reports of any Internal Control Reviews or any reviews conducted by other
external or internal organizations

20. Discussion of any known needs for guidance or assistance or specific areas of
concern in IT security from either the operating unit, Department or federal
levels

21. Sensitive System Security Plan

22. Certification documentation, if available

The system owner should appoint an individual, usually the ITSSO, to act as the point
of contact for the review team. This individual should participate as an observer in
the review and coordinate interviews or make other arrangements as necessary to assist
the review team. An entrance meeting should be arranged to allow the review team to
explain its mission and review methods to the system owner and staff members.
During the course of the review, the team will discuss their findings and
recommendations with the point of contact or system owner and keep them advised
about the progress of the review.

The security plan for the system will be used as the foundation for the actual review.
The security plan will provide information about the technical and physical system, its
sensitivity level and its protection requirements. The security plan is intended as a
basic overview and will not contain the level of detailed information that the review
team will need in making decisions about its actual security requirements. However,
the plan should be accurate and reflect the actual system description, protection
requirements and controls in place, Verification of the accuracy of the plan is an
important element of the review process. Recommendations to improve the quality of
the security plan should be made during the course of the review. In many cases, the
review team may find that many of their recommendations will concern changes to the
security plan and not to the actual system controls.

Prior to the actual on-site review of the system, all team members should be provided
with a copy of the security plan for the system to be reviewed. The team should meet
to discuss the scope of the review, which will be determined by the size, sensitivity
level, type and complexity of the system as identified in Section I. through Section
III.B. in the security plan. During the actual on-site review, it is recommended that
the team leader be the evaluator to verify the information contained in these sections
of the plan. The team leader should share the results of the verification with all other
team members to ensure that their reviews are based on accurate requirements for the
system. Although it is not necessary for all team members to be experts about what
controls are appropriate for every type system, they should be given enough guidance
about the system under review to avoid wasting too much time asking questions that
are not relevant for the particular system. A very obvious example of this would be if
the system under review is a microcomputer or local area network system, asking
questions relating to a computer room would not be relevant. A less obvious example
would be for a system that contains nothing but public information, asking multiple
questions about confidentiality controls would be a waste of time and might lead to
inappropriate recommendations. Other considerations that would have a bearing on
determining adequate and appropriate protection requirements for a specific system
would include the physical location, environment, category of system,
telecommunication configuration, sensitivity of data, availability requirements and
importance to mission accomplishment.

It is important to understand that the IT security verification review is not intended to
be a risk analysis. Testing of actual controls will be limited to only those necessary to
verify their existence and proper operation. If documentation of prior testing of
controls appears adequate (i.e., risk analysis or system certification documentation)
then further testing would not be conducted. Appropriate tests might include such
things as: (1) having system owner demonstrate access controls on the system (i.e.,
logging into the system to ensure password is blanked, attempting to establish
passwords outside established password constraints, viewing SCREEN WARNING
messages, attempting to access files that should be restricted, etc.); (2) attempting to
access computer room outside normal working hours to ensure doors are locked or
verifying that visitors are challenged. Evaluators are not to attempt penetration of the
computer or to remove any system resources (i.e., equipment, media or printed output,
etc.), as these actions could be considered security violations.

At the conclusion of the review, the "IT Security Verification Review Report" will be
prepared in the format outlined in Attachment 1 of this document. A copy of the draft
report with major findings and recommendations should be provided to the system
owner during the exit-briefing. Within two weeks after the conclusion of the review,
the system owner should provide the review team leader written comments or
questions about the draft report findings and recommendations. The review team
should consider the system owner's concerns and prepare and forward the final report
for the system owner's action.

The information included in the "IT Security Verification Review Report" will contain
details about the system, which may identify weaknesses or vulnerabilities which
require protection against disclosure to persons without an official need to know.
Reports for sensitive systems will be marked at least "For Official Use Only."
Classified IT system reports will be marked in accordance with appropriate national
security directives and DAO 207-2, "DOC National Security Information Manual."

Use of the "IT Security Verification Review Guideline"

The guideline, contained in Attachment 2, provides a structured process for
accomplishment of the required IT security verification review for DOC IT systems.
It was developed following the format required for DOC IT system security plans and
provides detailed questions for each section contained in the plans. Since the purpose
of the IT security verification review is to determine if the individual IT system has
been provided with adequate and appropriate levels of protection based on its unique
protection requirements, many of the questions under specific control areas will not
apply to all IT systems.

An attempt has been made in developing the "IT Security Verification Review
Guideline" to formulate questions that cover the majority of possible security concerns
and requirements that could possibly apply to any DOC sensitive or classified IT
system. The questions are not intended to be all inclusive, and answers provided may
generate other questions. Additional questions may also result from the review of
system documentation and records or as the result of interviews or observations by the
team members. Team members will be required to rely on their judgement about what
is appropriate and adequate protection requirements for the system they are evaluating.
The guideline questions should be reviewed by the evaluator in advance of any
interviews and those determine not be applicable, marked off. The team leader should
be able to assist in determining the appropriate questions or areas to be reviewed.

System Owners

System owners may also find this guideline helpful in performing management control
reviews and the required risk analysis or certification testing of their systems. The
guideline contains extensive questions about all categories of controls and could be
useful in verifying that adequate consideration of appropriate controls has been
included in their risk analysis, certification methodologies or for management control
review ideas. It may also serve as a useful tool in identifying additional controls that
would be appropriate for their systems.
ATTACHMENT 1

INFORMATION TECHNOLOGY SECURITY
VERIFICATION REVIEW REPORT FORMAT

Format

The "Information Technology (IT) Security Verification Review Reports" should be consistent
across all DOC organizations and should contain the following sections:

Cover page

Executive Summary
Introduction

Discussion
Objective
Method

System and Sensitivity Information
System Description/Purpose
System Environment and Special Considerations
General Description of Information Sensitivity

Recommendations

The following sample report was prepared in the appropriate format and contains guidance for
content in each section.

(ORGANIZATION CONDUCTING REVIEW)

INFORMATION TECHNOLOGY SECURITY REVIEW

DOC SYSTEM NUMBER
(OPERATING UNIT)
(SUB ORGANIZATION)

(SYSTEM NAME/TITLE)

(CITY, STATE WHERE SYSTEM IS LOCATED)

(MONTH, YEAR)

EXECUTIVE SUMMARY

Introduction

An Information Technology (IT) Security Verification Review, in conformance with the
requirements of the Computer Security Act of 1987 and Office of Management and Budget
(OMB) Bulletin 90-08, was conducted during the period at the (Operating Unit,
Sub-organization, System Name/Title, in City, State.)

The IT Security Review Team was lead by , (Organization and Title).
(List all other team members by name, organization and title) team members. Each team
member was assigned specific sections of the Sensitive System Security Plan for the
system, to verify and validate the accuracy of the information contained in the plan and to
ensure that the system controls were adequate and appropriate for the system. The review
was conducted in accordance with guidance contained in the "DOC Guidelines for Conducting
Information Technology Security Verification Reviews of Sensitive and Classified Systems".

The IT Security Review was conducted on the DOC IT System Number , "(Name/Title
of System)". The system (describe in general terms the purpose of the system. See Section
I.E. in the security plan.)

The overall IT security profile of this system was (excellent, very good, good, adequate,
inadequate or poor). This paragraph should contain summary information about the findings,
including positive actions, controls or other significant items that the system owner has
implemented to protect the system. Any major problems noted during the course of the
review should be described in general terms or "no major problem were noted".
Recommendations primarily concerned (describe in general categories (i.e., improvements in
administrative procedures, documentation, contingency planning, backup storage, personnel
management and user access control).)

The purpose of this review was to improve IT security specifically and IT resource
management in general at (system name) and to ensure compliance with prescribed IT security
policies and regulations and to identify areas where further security controls may be necessary
to improve the protection of the system.

At the conclusion of the on-site visit, the review team discussed its preliminary findings with
the (system) management and IT security staff personnel who indicated general agreement and
a willingness to implement all recommendations (or major objections). Implementation of the
recommendations will provide assurance that all risks have been identified and appropriate
levels of security exist for protection of the system.

DISCUSSION

Objective

The objectives of this review were to determine the coordination and implementation of
activities conducted by the (system organization) to ensure the protection and integrity of
information resources such as development of security plans for sensitive and classified
systems, ensuring periodic risk assessments are conducted, establishing contingency and
disaster recovery plans, implementing a security awareness and training program, performing
IT security reviews, and certification and accreditation of sensitive systems.

Specific laws, regulations and policies used as guidelines for this review, included:

OMB Circular A-130, Appendix III, "Security of Federal Automated Information
Systems"

Public Law 100-235, the "Computer Security Act of 1987"

Department of Commerce, "Information Technology Handbook, Chapter 10,
Information Technology Security"

OMB Bulletin 90-08, "Guidance for Preparation of Security Plans for Federal
Computer Systems that Contain Sensitive Information"

Department of Commerce, "Guidelines for Conducting Information Technology
Security Verification Reviews of Sensitive and Classified Systems"

This review was conducted to evaluate compliance with federal and Departmental IT security
policies and requirements and assess the system's IT security profile. Review criteria was
based on evaluation of the in-place and planned controls identified in the Sensitive System
Security Plan for this system (DOC System Number ).

Method

The review team's approach in this evaluation was to interview (system name/title)
management and staff personnel, observe operations of the system and the physical facilities
and resources within the buildings and review all IT security program related documentation.
The primary point-of-contact for this system review was (Name and title). Other Staff
members contacted during the review included: (List names and titles).

During the entrance interview with system management and staff personnel, the review team's
mission and methods were explained in detail.
SYSTEM AND SENSITIVITY INFORMATION

SYSTEM DESCRIPTION/PURPOSE

(Copy information contained in Section I.E. of the security plan or correct information after
the conclusion of the review.)

SYSTEM ENVIRONMENT AND SPECIAL CONSIDERATIONS

(Copy information contained in Section I.F. of the security plan or correct information after
the conclusion of the review.)

GENERAL DESCRIPTION OF INFORMATION SENSITIVITY

(Copy information contained in Section II.B. of the security plan or correct information after
the conclusion of the review.) RECOMMENDATIONS

The review was conducted, using the "DOC Guidelines for Conducting Information
Technology Security Verification Reviews of Sensitive and Classified Systems" and the
"Sensitive System Security Plan" for DOC System , as the basis. The review included
on-site inspections of the facilities, computer room environment, hardware configuration, and
interviews of management and computer center personnel The following recommendations are
a result of the review findings:

The security plan for this system should be updated to incorporate any changes resulting from
these recommendations.

Recommendations should be numbered.

Recommendations should be listed by security plan section number. Example
Section III.C.2.b. This will relate each finding and recommendation to a
specific control category. There may be multiple separate recommendations
under a specific section number.

Each finding and recommendation should be discussed with the system owner
during the exit briefing in as much detail as possible by the review team
member making the recommendation. Every effort should be made to discuss
findings with the point of contact or system owner prior to the exit briefing.
This will ensure that all significant facts have been taken into consideration
about any unique situations or requirements affecting the individual system.
Discussion about security requirements during the course of the review also
provides an excellent opportunity to increase IT security awareness and
training.
SECTION 6.1
MALICIOUS SOFTWARE

A. Purpose:

The purpose or this section is to establish Department of Commerce (DOC) policy to
minimize the risk of introducing malicious software into computer systems. It also
provides guidelines for the detection and removal of malicious software from
information technology (IT) systems.

B. Overview:

Malicious software presents an increasingly serious security problem for computer
systems and networks. Malicious software includes viruses and other destructive
programs, such as Trojan horses and network worms. This type or software is often
written as independent programs that appear to provide useful functions but also
contain malicious programs that can be very destructive. It can be quickly spread
through software bulletin boards, shareware, and users unknowingly copying and
sharing these programs in an unauthorized manner. It can also be spread by users
sharing data files and software products. Networks are particularly vulnerable as they
allow very rapid spread of the virus to all systems connected to the network.

A program that is infected with a virus can infect any host in which the program is
used. Because of the insidious nature or a virus, any user may become an unwitting
propagator. Commerce's dependence on networked computer systems, personal
computers (PCs), and office automation makes us susceptible to virus "attacks."

Computer viruses have become a threat to virtually everyone using a computer. A
virus can destroy programs and data by copying itself to other programs. It is then
executed when the infected program is run. It can disable computers and entire
computer networks. It can also cause lost computer time and staff resources to track
and eliminate it.

Most operating units within the Department have been infected with different
computer viruses. In many cases, data was not lost but time and staff resources were
wasted tracking and eliminating these viruses.

PCs are more susceptible to viruses than other types of computers due to their
widespread use. However, viruses can be created for any type of computer.
Malicious programs such as Trojan horses and trap doors were originally written for
mainframe computer systems. Introduction of malicious programs into these larger
systems is usually caused by unauthorized users accessing a system without adequate
controls or by authorized users making unauthorized use of the system.

Sound IT security procedures will help detect and prevent computer viruses and other
malicious programs from spreading or causing damage. The guidelines contained in
this document can be adapted for any type of computer system.

C. Background and Authority:

Due to the widespread threat from computer viruses to all organizations, both private
sector and government, it has become necessary to implement specific measures
designed to reduce this threat and the potential damage caused by virus infections to
DOC IT systems. The DOC malicious software policy is established in compliance
with the "Computer Security Act of 1987," Office of Management and Budget (OMB)
Circular A-130, and the "Computer Fraud and Abuse Act", Public Laws 98-473 and
99-474, 18 U.S.Code 1030.

D. Scope:

This policy covers all IT systems that are used to process Commerce data, including
contractor-owned and/or contractor-operated systems.

This policy applies to all employees, personnel from other organizations, contractor
personnel, and vendors using Commerce systems participating in DOC sponsored
software development, software demonstrations, and the operation and maintenance of
IT systems.

E. Policy:

All DOC organizations will establish and implement a process and procedures to
minimize the risk of introducing viruses and other malicious software, to ensure timely
detection of viral infections, to provide procedures for eliminating viral infections from
the Department's inventory of microcomputers (PCs), and to provide procedures to
minimize the risk from malicious programs to larger systems, or systems where virus
detection software is not yet available.

F. Responsibilities and Process:

Responsibilities

The Director for Information Resources Management is responsible for the
Department's IT security program. This includes establishing IT security policies and
procedures for safeguarding Departmental IT resources.

The Departmental IT Security Manager shall serve as the central point of contact for all
matters relating to IT security for the Department and will be responsible for developing
a process for disseminating information concerning the potential dangers from, and
guidelines for control of, malicious software.

Operating unit IT Security Officers (ITSO) are responsible for:

1. Developing appropriate procedures and issuing instructions for the prevention,
detection, and removal or malicious software consistent with the guidelines
contained herein;

2. Ensuring all personnel within the operating unit are made aware of this policy and
incorporating it into IT security briefings and training programs;

3. Identifying and recommending software packages for the detection and removal of
malicious software;

4. Developing a system for users to report computer viruses and other incidents and
then notifying potentially affected parties of the possible threat;

5. Promptly notifying the Departmental IT Security Manager of all IT security
incidents including malicious software;

6. Providing assistance in determining the source of malicious software and the extent
of contamination;

7. Providing assistance for the removal of malicious software; and

8. Conducting periodic reviews to ensure that proper security procedures are followed,
including those designed to protect against malicious software.

Managers must ensure that employees and contractors follow operating unit procedures
which comply with this policy.

Employees, personnel from other organizations using DOC systems, contractor
personnel, and vendors are responsible for following operating unit procedures for the
protection of IT resources to which they have access. This includes reporting IT
security incidents, involving viruses and other malicious software to their manager or
supervisor and the ITSO for their organization.

Requirements

The requirements defined in this section, when implemented, will minimize the risk
from introduction of viruses and other malicious software to DOC IT systems and
networks. Not all requirements listed will apply to every IT system or network. Each
organization must consciously evaluate the appropriateness of each of the following
policies and implement those that apply to the category for their particular system.

1. Procedures. Each operating unit will establish appropriate procedures for adherence
to this policy based on the criticality, sensitivity, and risks to their IT systems.

Until virus detection software becomes available for all types of IT systems,
the best protection against malicious software attacks is to establish good IT
security procedures to control access to and actions taken on the IT system.

2. Backing up software and data. Employees should back up new software
immediately, retaining the original distribution diskettes in a safe and secure
location. Write-protect original diskettes prior to making back-up copies. If a
virus destroys the working copy, the original software is still available.
Copying copyrighted software material without the vendor's consent is illegal.
If a vendor has not provided pre-approval of backup copies, employees must
have vendor approval to create additional copies. Use only newly-formatted
diskettes for copying software for backup storage. Used disks may already
contain malicious programs which would contaminate the backup copies.

Data files should be backed up frequently and stored off-site or in a secured
environment.

Restore damaged software programs from the original diskettes, not from
regular backups. A virus may have been introduced prior to backup.

3. Outgoing software. A serious impact on the credibility of the Department
would result from being identified as the source of a virus. Therefore, all
software and data leaving the Department must be checked for viruses or other
malicious coding.

Use only new media for making copies for distribution. Where possible, use
a stand-alone computer system when preparing copies for distribution.

PC systems to which access is somewhat open, (i.e., training rooms or user
laboratories, etc.) should never be used as a source of software or files to be
transmitted and/or copied for distribution, without first taking steps to ensure
that the system is free from viruses or other malicious software.

4. Software. All PC machine-readable media will be scanned for malicious software
before initial use. Follow all vendor instructions carefully and write-protect virus
scanning software media prior to use. Scanning software can become contaminated
in the same way as other software. Although software sealed in "shrink-wrapped"
plastic is usually checked by vendors, it is still advisable to scan this software since
there have been reported cases in the Department of software contamination. Write-
protect software prior to scanning to prevent possible contamination from system
and virus scan software being used.

Several reputable software packages are available to detect and/or remove viruses
from machine-readable media. There are also utilities that can search text files for
virus signatures. Most packages are designed for PC systems and local area
networks, but may not be adequate for all PC operating systems. There are very
few available for larger systems.

Requirements to scan for malicious software are to be implemented as soon as
the tools become available for a particular combination of hardware and
software.

Establish controls for local area networks that prevent anyone except the system
administrator or other authorized staff from loading software on file servers. Ensure
that operating system files and other executable files are read-only. If possible,
disable the network mail facility from transferring executable files. This will help
prevent network worm programs from spreading through the network.

Trojan horses and other similar malicious software programs are most often
introduced by insiders and it is not unusual for larger systems to be the target.
The best protection against attacks of this type are to establish good
management procedures. Effective controls include separation of duties,
limiting individual access and allowed actions to what is needed and no more,
formal change control and configuration management procedures, separation
and testing of development versus production software and control over
installation of new software versions. Frequent backups of the system and
data will allow recovery should an incident occur.

5. Authorized software. It is imperative that machine-readable software and data files
be obtained from reliable sources. Viruses are often spread through free or shared
programs, games, demonstration programs, and programs downloaded from bulletin
boards. Employees must not use privately-owned software or take software from
their office without management approval. Commercial software must be obtained
through appropriate procurement channels. In-house developed software must be
done in accordance with established policy within the operating unit and have prior
management approval.

Shareware and freeware software must be obtained only with prior
management approval. Software obtained electronically from bulletin boards
should be downloaded to newly formatted diskettes and not directly to the
computer hard disk. All newly acquired software, regardless of source, is
subject to the scanning requirements in sub-paragraph 4 above.

6. Employee demonstrations. When possible, employees demonstrating DOC products
must be certain that the hardware and software they are using are free of viruses.
Use hardware write-protection mechanisms (i.e., read-only diskettes with write tabs;
write-protect rings for tapes; knock-out rings on cassettes, etc.) to avoid any virus
from infecting the media. If possible, check the hardware for viruses before loading
the demonstration software. Do not allow other software to be used until the
demonstration is completed.

7. Passwords. For larger systems and networks, user identification and passwords are
the primary protection mechanism against malicious software. If the would-be
perpetrators cannot get into the system, they cannot put malicious software on the
system. When possible, all IT systems that are shared resources, including local
area networks and multi-user stand-alone systems shall implement a user
identification and verification system, such as a USERID and password.
Conformance to the requirements of Chapter 10, Section 10.16 of the "DOC IT
Management Handbook," and Section 16 of the "DOC IT Security Manual" in
establishment, structure, individual accountability, periodic changing and removal
are required.

Log files should be reviewed periodically to detect unusual activity. Terminals,
workstations and networked PCs should never be left unattended when logged in.

8. Vendor demonstrations. Vendors will demonstrate their software on stand-alone
hardware, where possible. An employee must scan the stand-alone hardware before
it is used by the vendor to verify that the computer does not contain any viruses.
This shows the Department acted in good faith to prevent infecting the vendor's
software.

An employee will scan the stand-alone hardware when the demonstration is
completed to determine if the vendor software contains a virus and remove it
from the system. The vendor should be notified immediately to prevent
further infections.

In the case of network software demonstrations, the system administrator must
approve and coordinate the demonstrations.

Written certification from the vendor that the demonstration software has been
checked and is free from viruses, should be obtained prior to loading any
vendor software.

9. Hardware. PC hard disk drives, network file servers and other media which will be
used to handle departmental information will be formatted between the time they
are received and put into use. There have been cases of formatted hard disk drives
being received that contained viruses. This requirement also applies to replacement
parts resulting from repair and maintenance of equipment. This requirement may be
waived only if the vendor installing the software provides a written certification that
the system and software have been checked and are virus free.

Never start up (boot) your computer from a diskette unless it is the original
write-protected system master or a trusted copy.

Portable computer systems, such as laptops, that leave Department controlled
areas must be scanned for viruses before and after connecting to systems or
software owned by other organizations.

Never use a local area network file server as a workstation. File servers
should be located in areas where access is restricted during working hours and
locked after hours.

When available and cost effective, virus detection software capable of
continuous monitoring and reporting malicious programs, should be installed
on hard disks to prevent contamination.

Periodic scans of hard disks, using virus detection software, should be
performed for systems without this protection installed.

Lock computers and terminals or disconnect keyboards and store in a secure
location, when not in use, to prevent unauthorized access. Lock doors to
areas containing computers and terminals.

10. Procurement requirement. All procurements for computer software and
hardware will contain a requirement that the vendor have antiviral procedures in
place to ensure that the media supplied is uncontaminated by malicious
software. In the case of small, off-the-shelf procurements where it is not
possible to write antiviral clauses, the software will be scanned with virus
detection software prior to use. Procurements for PC system maintenance
should also require antiviral procedures on the part of the contractor.

Vendors depend on the reputation of their products to ensure future sales.
Reputable vendors are concerned about correcting any flaws in their systems
or products that would make them vulnerable to attack from viruses or other
malicious software, and on occasion issue recommended changes to improve
security of their products. System administrators and managers are to
implement any vendor recommended changes, or security fixes as soon as
possible, after official receipt.

Malicious Software Indicators

If your IT system seems to be acting different than usual, a malicious software incident
may have occurred. Below are a few signs that may indicate that a system has been
infected.

1. Any unexplained messages or graphics on the screen,

2. An increase in the time required to load or execute programs,

3. An increase in the time required for disk accesses or processing from disk,

4. Unusual error messages,

5. Programs or files mysteriously disappearing,

6. Less memory available than usual,

7. Executable files changing size for no apparent reason,

8. Accesses made to non-referenced devices,

9. Data consistently out of balance,

10. File date and time stamps changing for no apparent reason,

11. Obsolete user accounts in use,

12. The presence of unexplained hidden files and/or

13. Unusual network activity.

If your system demonstrates any of the above, it could indicate that malicious software
is present.

Elimination, Recovery and Reporting

If you suspect that your IT system or network has been attacked by a virus or other
malicious software program, do not attempt to fix the problems, but immediately report
it to your supervisor and the ITSO for your operating unit. They will determine the
appropriate action to control the damage and report the incident to the DOC IT Security
Manager. It is important that the particular virus or other malicious software program,
source, and potential for proliferation be identified and controlled.

The initial report to the DOC IT Security Manager should be made within 24 hours of
the incident. This report may be verbal and should include the following information:

Date and time of incident
Location
Equipment type, make and model
Malicious software type
Method of discovery
Virus name (if known)
DOC system number (if known)
Source of malicious software (if known)
Apparent effect

Within ten working days of the incident, a written report will be prepared and sent to
the DOC IT Security Manager of the incident by the operating unit ITSO. This report
will include the following along with all of the above information:

Impact on operation
Severity, including hours devoted to recovery and any additional costs incurred
Proliferation, number of machines or media infected
Action taken - how malicious software was cleared, who was notified, including
outside organizations, and what steps were taken to identify the source

If the problem has not been resolved within ten working days, mark the written report
"Interim" and prepare and forward a "Final" report when the incident is resolved. In
cases where resolution is not possible within 30 days, a written status report describing
the actions taken and planned to resolve the incident must be sent to the DOC IT
Security Manager monthly.

G. Definitions:

Introduction of viruses and other malicious software programs has generated a whole set
of new terms. The following list of definitions is provided to familiarize personnel with
some of these terms.

1. Bacterium. A late bloomer in the infectious terminology jargon is a "bacterium." It
is a program that replicates itself and becomes a parasite on the host system by
preempting processor and memory capacity.

2. Computer virus. A program that "infects" computer systems in much the same way
as a biological virus infects humans. The typical virus "reproduces" by making
copies of itself and inserting them into other programs--either in systems software
or in application programs.

3. Flying Dutchman. A feature of Trojan horse malicious programs that erases all
traces of the programming codes from the computer's memory and eludes any
detection.

4. Logic Bomb. A computer code that is preset to cause a later malfunction when
a specified set of logical conditions occur. For example, a specific social
security number in a payroll system is processed and the logic bomb is
activated, causing an improper amount of money to be printed on the check.

5. Machine-readable media. Media that can convey data to a given sensing device,
e.g., diskettes, disks, tapes, computer memory.

6. Malicious Software. Any of a family of computer programs developed with the
sole purpose of doing harm. Malicious code is usually embedded in software
programs that appear to provide useful functions but, when activated by a user,
cause undesirable results.

7. Scan. To examine computer coding/programs sequentially, part by part. For
viruses, scans are made for virus signatures or potentially unsafe practices. (e.g.,
changes to an executable file, direct writes to specific disk sectors, et al.).

8. Time Bomb. Computer code that is preset to cause a later malfunction after a
specific date, time or a specific number of operations. The "Friday the 13th"
computer virus is an example. This virus infects the system several days or
even months before and lies dormant until the date reaches Friday the 13th.

9. Trap Door. A set of instruction codes embedded in a computer operating
system that permits access while bypassing security controls.

10. Trojan Horse. A program that causes unexpected (and usually undesirable) effects
when willingly installed or run by an unsuspecting user. A person can either
create or gain access to the source code of a common, frequently used program
and then add code so that the program performs a harmful function in addition to
its normal function. These programs are generally deeply buried in the code of the
target program, lie dormant for a preselected period, and are triggered in the same
manner as a logic bomb. A Trojan horse can alter, destroy, or disclose data or
delete files.

11. Virus detection software. Software written to scan machine-readable media
on computer systems. There are a growing number of reputable software
packages available that are designed to detect and/or remove viruses. In
addition, many utility programs can search text files for virus signatures or
potentially unsafe practices.

12. Virus signature. A unique set of characters which identify a particular virus. This
may also be referred to as a virus marker.

13. Worm. A worm is a complete program that propagates itself from system to
system, usually through a network or other communication facility. A worm is
similar to a virus--it is able to infect other systems and programs. A worm differs
from a virus in that a virus replicates itself, which a worm does not. A worm
copies itself to a person's workstation over a network or through a host computer
and then spreads to other workstations. It can easily take over a network as the
"Internet" worm did. Unlike a Trojan horse, a worm enters a system uninvited.

H. References:

Viruses and other malicious software appear to be a growing problem with new strains
of viruses appearing continuously. Users of IT systems should become as familiar with
the subject as possible, in order to protect against this threat. The following documents
published by the National Institute of Standards and Technology are good sources of
additional information:

John Wack and Lisa Carnahan, Computer Viruses and Related Threats: A
Management Guide, NIST Special Publication 500-166, August 1989.

Dennis Steinauer, Security of Personal Computer Systems: A Management
Guide, NBS Special Publication 500-120, January 1985.

An Abbreviated Bibliography for Computer Viruses and Related Security
Issues, NIST, Revised April 18, 1990.
SECTION 4
ACCREDITATION

A. Purpose:

The purpose of this section is to establish Department of Commerce (DOC) policy for
accreditation of all unclassified sensitive and classified national security Information
Technology (IT) systems.

B. Overview:

Accreditation is the authorization and approval, granted to a sensitive or classified IT
system to process, as an acceptable risk, in an operational environment. Accreditation
is made on the basis of recommendations from a technical certification evaluation that
the IT system meets all applicable federal and DOC policies, regulations, and standards
and that all installed security safeguards appear to be adequate and appropriate for the
sensitivity of the system; that they are operating correctly; or, that the system must be
operated under certain specified conditions or constraints.

C. Background and Authority:

Accreditation is a requirement of Office of Management and Budget (OMB) Circular
Number A-130 and the "Computer Security Act of 1987," Public Law 100-235.

D. Scope:

The policy contained in this document covers all DOC IT systems, whether maintained
in-house or commercially.

Accreditation is required for all sensitive and classified DOC General Support and
Application systems. New IT systems or those not fully operational shall complete all
requirements and be accredited prior to full implementation.

E. Policy:

This policy defines the final step in the IT Security management process that ensures
protection of the vital IT resources within the Department.

Initial Accreditation

All sensitive and classified DOC IT General Support or Application systems will be
accredited. The term accreditation describes the process whereby information pertaining
to the security of a system is developed, analyzed and submitted for approval to the
appropriate senior management official identified in this document as the Designated
Approving Authority (DAA). Section F, of this document, identifies the required steps
in the accreditation process. The DAA will review the accreditation support
documentation and either concur, thereby declaring that a satisfactory level of
operational security is present or not concur, indicating that the level of risk either has
not been adequately defined or reduced to an acceptable level for operational
requirements. The DAA will sign a formal accreditation statement declaring that the
system appears to be operating at an acceptable level of risk, or defining any conditions
or constraints that are required for appropriate system protection. Sample accreditation
statements are contained in Attachment 1 of this document.

Security of classified IT systems operated by, or in support of DOC programs is the
responsibility of the Department and these systems must be accredited in accordance
with the requirements defined in this policy. Approvals granted by external agencies,
i.e., Department of State, Department of Defense, Central Intelligence Agency, etc., are
not valid authority to operate classified IT systems within the Department. Approvals
granted to these systems by DOC, prior to this policy, are no longer in effect and new
approval to operate must be granted through the DOC accreditation process.

Interim Accreditation

Interim authority to operate can be granted for a fixed period of time, not to exceed one
year. This authority is based on an approved security plan and is contingent on certain
conditions being met. The interim authority to operate, while continuing the
accreditation process, permits the IT system to meet its operational mission
requirements while improving its IT security posture. If the DAA is not satisfied that
the IT system is protected at an acceptable level of risk, an interim accreditation can be
granted to allow time for implementation of additional controls. Recommendation or
request for an interim accreditation may be made by the IT system owner, the operating
unit IT Security Officer (ITSO) or the DAA. Interim authority to operate is not a
waiver of the requirement for accreditation. The IT system must meet all requirements
and be fully accredited by the interim accreditation expiration date. No extensions of
interim accreditation can be granted except by the DOC Director for Information
Resources Management.

Reaccreditation

Systems will be reaccredited when major changes occur to the system or every three
years, whichever occurs first. Examples of major changes include:

1. Changes in the system or software applications - Substantial changes which alter
the mission, operating environment or basic vulnerabilities of the system. Increase
or decrease in hardware, application programs, external users, hardware upgrades,
addition of telecommunications capability, dial-in lines, changes to program logic
of application systems, relocation of system to new physical environment or new
organization. Minor changes such as, replacement of similar hardware when
capacity does not significantly change, addition of two or three workstations on a
network or small modifications to an application program (e.g., table headings are
changed) would not require reaccreditation.

2. Changes in protection requirements - Changes in the sensitivity or classification
level of the data being processed, increase in the mission criticality of the system
or changes in federal or DOC policies.

3. Occurrence of a significant violation - A violation or incident that calls into
question the adequacy of the system security controls.

4. Audit or evaluation findings - Findings from any security review that identifies
significant unprotected risks. These could include the system security verification
review, physical or information security inspection, internal control reviews, Office
of the Inspector General (OIG) audits or General Accounting Office (GAO) audits.

Prior to reaccreditation, an on-site IT security verification review must be conducted by
an evaluation team under the direction of the DOC IT Security Manager, the operating
unit ITSO or the ITSO of a subordinate organizational unit (i.e., Line Office, Regional
Office, Laboratory, etc.) The IT security verification review team may not be under the
direction of personnel from the subordinate organization having direct control over the
IT system being evaluated. The IT System Security Officer (ITSSO) for the system
under review should participate as a member of the IT security verification review
team. The purpose of this review is to ensure that all controls and vulnerabilities are
properly documented, and that adequate and appropriate levels of security exist for
protection of the system. Requirements and guidance for conducting IT serurity
verification reviews are contained in Chapter 10, Section 10.5 of the "DOC IT
Management Handbook" and Section 5 of the "DOC IT Security Manual."

F. Responsibilities and Process:

Classified National Security IT Systems

1. The DOC Director for Information Resources Management is the DAA for all
classified IT systems within the Department. This authority can not be delegated
below this level. Accreditation will be granted only with the recommendations of
the DOC Director, Office of Security, DOC Chief, Telecommunications
Management Division and the DOC IT Security Manager.

2. The DOC IT Security Manager will act as the central point of contact for
accreditation of classified IT systems and will evaluate the adequacy of all
technical controls protecting these systems. The DOC IT Security Manager will
review all accreditation documentation, evaluate the security controls for the IT
system and conduct on-site reviews, if necessary, to ensure they meet all applicable
federal and DOC policies, regulations and standards and that they appear to be
adequate and appropriate for protection of the system. The DOC IT Security
Manager will submit recommendations to the DAA for or against accreditation.
Recommendation should include any additional controls or constraints required to
meet a satisfactory level of operational security.

3. The Chief, Telecommunications Management Division will evaluate all supporting
accreditation documentation and conduct on-site inspections, when necessary, to
ensure compliance with all Communications Security (COMSEC) and emanations
(TEMPEST) security requirements as required by the Chapter 8 of the "DOC IT
Management Handbook."

4. The DOC Director, Office of Security will evaluate all supporting accreditation
documentation and conduct on-site inspections, when necessary, to ensure
compliance with appropriate national security directives and DAO 207-2, "DOC
National Security Information Manual."

Unclassified Sensitive IT Systems

1. The Senior Information Resources Management official in each operating unit will
be the DAA for all sensitive systems within their organization. This approval
authority may only be delegated to a senior management official of a subordinate
organizational unit, if that official does not have direct control over the IT system
being accredited. Delegation of accreditation authority must be requested and
approved in advance by the DOC Director for Information Resources Management.

2. The operating unit ITSO will act as the central point of contact for accreditation of
all sensitive IT systems within the organization. The ITSO will review all
accreditation documentation, evaluate the security controls for the IT system and
conduct on-site reviews, if necessary, to ensure they meet all applicable federal and
DOC policies, regulations and standards and that they appear to be adequate and
appropriate for protection of the system. The ITSO will submit recommendations
to the DAA for or against accreditation. Recommendations should include any
additional controls or constraints required to meet a satisfactory level of
operational security.

The operating unit ITSO will submit an accreditation status report quarterly to the
DOC IT Security Manager, listing accredited systems by DOC identification
numbers, including interim accreditations, and the completed date. A copy of all
official accreditation statements will be forwarded with this list.

IT System Owners

Chapter 10, Section 10.1 of the "DOC IT Management Handbook" and Section 1 of the
"DOC IT Security Manual" contain specific information about designation of ownership
of IT systems and data. Owners of DOC IT systems will complete all required actions
and prepare an accreditation package including all documentation identified in this
section. For classified IT systems, the accreditation package will be forwarded to the
DOC IT Security Manager through the ITSO and the Senior Information Resources
Management official for the operating unit. Sensitive IT system accreditation packages
will be forwarded to the appropriate ITSO for the operating unit.

The information included in the accreditation package will contain details about the
system, which may identify weaknesses or vulnerabilities which require protection
against disclosure to persons without an official need to know. Accreditation packages
for sensitive systems will be marked at least "For Official Use Only." Classified IT
system accreditation packages will be marked in accordance with appropriate national
security directives and DAO 207-2, "DOC National Security Information Manual."

The following actions shall be completed and the appropriate documentation prepared
and submitted in the accreditation package to the appropriate DAA for the IT system:

Request for Accreditation

The system owner will prepare a written request for approval to operate the IT system
and forward the documentation listed below to the appropriate DAA. The written
request will include a certification statement that the IT system has undergone adequate
tests to ensure that it meets all federal and DOC policies, regulations and standards and
that all installed security safeguards appear to be adequate and appropriate for the
sensitivity of the system.

Approved IT System Security Plan

A detailed IT system security plan will be prepared by the system owner, in the
required format provided in the "DOC Guidelines for Developing and Evaluating
Security Plans for Sensitive and Classified Systems," contained in Section 2 of the
"DOC IT Security Manual." The purpose of the system security plan is to provide a
basic overview of the security and privacy requirements of the subject system and the
IT system owner's plan for meeting those requirements. The plan may also be viewed
as documentation of the structured process of planning adequate, cost-effective security
protection for the system.

The IT system security plan must be forwarded through the operating unit's ITSO for
review and comment, and once all corrective actions have been completed, to the DOC
IT Security Manager for final approval. A statement of approval will be sent to the
operating unit ITSO for forwarding to the IT system owner. Security plans must be
reviewed by the system owner, at least annually, and changes submitted, as necessary,
to ensure they are up-to-date.

Chapter 10, Section 10.2 of the "DOC IT Management Handbook" contains the DOC
policy for IT system security plans. Section 2 of the "DOC IT Security Manual"
contains detailed guidance for preparation of these plans.

Completed Risk Analysis

IT system owners are responsible for having a risk analysis conducted for each IT
system to ensure that appropriate, cost effective safeguards are incorporated into
existing and new systems. A risk analysis will be conducted prior to approval of design
specifications for new systems, when major changes occur to the system or every three
years, whichever occurs first. Examples of major system changes are given in Section
E., Reaccreditation, of this document.

See Chapter 10, Section 10.7 of the "DOC IT Management Handbook" and Section 7 of
the "DOC IT Security Manual" for guidance on conducting the required risk analysis.

Contingency/Disaster Recovery Plans

Each IT system shall develop and maintain, in an up-to-date state, a contingency and
disaster recovery plan which will provide reasonable assurance that critical data
processing can be continued, or resumed quickly, if normal operations are interrupted.
The plan for large systems supporting essential Departmental or agency functions shall
be fully documented and operationally tested at least annually. Small systems may
develop a more abbreviated and less formal plan. Policy concerning
contingency/disaster recovery planning is contained in Chapter 10, Section 10.8 of the
"DOC IT Management Handbook" and Section 8 of the "DOC IT Security Manual."
Additional guidance is contained in Section 7 of the "DOC IT Security Manual."

Software Application Certification Statements

Sensitive application software shall be thoroughly tested prior to implementation to
verify that the user functions and the required administrative, technical, and physical
safeguards are present and are effectively operating as intended. If the system to be
accredited is running major applications requiring separate certification, system owners
will provide copies of all software application certification and recertification statements
as part of the accreditation package. General support system owners running
applications belonging to other organizations are not required to provide these
certification statements.

Certification Testing of Security Controls

Prior to accreditation, each IT system is to undergo appropriate technical evaluations to
ensure that it meets all federal and DOC policies, regulations and standards and that all
installed security safeguards appear to be adequate and appropriate for the sensitivity of
the system. The technical evaluation results are the basis for the system owner's
certification statement in the accreditation request. The letter should state what methods
were used to perform the certification evaluation. The DOC certification policy is
contained in Chapter 10, Section 10.3 of the "DOC IT Management Handbook."
Section 3 of the "DOC IT Security Manual contains two approved methodologies for
conducting certification testing.

The following certification evaluation documentation will be included in the
accreditation package, as applicable:

1. System Owner Certification Reports

Include a copy of the certification review report that shows: (1) that controls
function properly; (2) that controls satisfy performance criteria and provide for
availability, survivability and accuracy; and (3) that the controls cannot be easily
broken or circumvented. Copies of evaluation results should be included.

2. Other Internal Reviews

3. External Reviews

The results of any audits performed by independent external organizations may
also be used as part of the certification evaluation. Copies of audit findings and
corrective actions taken should be included in the accreditation package.

For classified IT systems, external organizations such as Department of Defense,
National Security Agency, State Department, Central Intelligence Agency, etc.,
who have specific requirements for data under their area of responsibility, may
also perform reviews and inspections. Any authorizations or approvals provided
by these external organizations are important certification documentation and must
be provided with the request for accreditation.

ATTACHMENT 1

SAMPLE ACCREDITATION STATEMENTS

Full Accreditation:

I have carefully examined the accreditation package documentation for DOC Information
Technology (IT) System Number ______, "ABC Computer Center," dated ____________.
Based on my authority and judgment, and weighing the remaining residual risk against
operational requirements, I authorize (continued) operation of this system (under the following
restrictions).

(restrictions)

I hereby accredit DOC IT System Number ______, "ABC Computer Center," as an
unclassified sensitive system, for a period not to exceed three years. Should any major
changes occur to this system during this three year period, a re-evaluation of the adequacy of
its security controls must be conducted and a reaccreditation requested.

_____________________________________
DAA Signature and Date

Interim Accreditation:

I have carefully examined the accreditation package documentation for DOC Information
Technology (IT) System Number ______, "ABC Computer Center," dated __________.
Based on my authority and judgment and the recommendation of the (System Owner, ITSO
or DAA judgmentt) it does not appear that this system has reached a satisfactory level of
operational security (or the following actions must be completed or additional controls
implemented prior to full accreditation).

(actions or additional controls required)

______________________________________
DAA Signature and Date
SECTION 5
INFORMATION TECHNOLOGY SECURITY VERIFICATION REVIEWS

A. Purpose:

B. Overview:

Protection requirements for each of the individual IT systems within the Department
will vary according to the unique characteristics of the system, environmental concerns,
data sensitivity and mission related criticality of the system or data. Total protection
against all threats may be an unrealistic goal. Appropriate levels of security must be
determined by an evaluation of the threats, vulnerabilities and risk factors associated
with each system. Cost-effective controls that are adequate to achieve an acceptable
level of risk for the individual system must then be implemented.

System owners are responsible for completing all DOC and federal requirements for
identifying their sensitive and classified systems, preparing security plans that provide a
basic overview of the security and privacy requirements of the subject system and the
system owner's plan for meeting those requirements, conducting risk assessments,
implementing controls determined to be required and cost-effective, developing
contingency and disaster recovery plans that will ensure availability of the system for
mission accomplishment and completing all requirements for certification and
accreditation of the system. The IT security verification review process provides an
independent means to ensure that the system owner has implemented adequate and
appropriate levels of protection, based on the system's unique requirements. The IT
security verification review process is part of the Department's oversight program.

C. Background and Authority:

The DOC IT security verification review process is established in compliance with the
"Computer Security Act of 1987," Public Law 100-235, OMB Circular A-130,
Appendix III, "Security of Federal Automated Information Systems" and OMB Bulletin
90-08, "Guidance for Preparation of Security Plans for Federal Computer Systems that
Contain Sensitive Information."

D. Scope:

The policy contained in this document covers all DOC IT resources that have been
identified as either sensitive or classified national security systems whether maintained
in-house or commercially.

E. Policy:

An IT security verification review will be conducted on all DOC sensitive or classified
national security IT systems by an evaluation team under the direction of the DOC IT
Security Manager or the operating unit ITSO or the ITSO of a subordinate
organizational unit every three years. The security plan for the system will be used as
the foundation for the actual review. The review will be conducted in accordance with
the guidance contained in the "DOC Guidelines for Conducting IT Security Verification
Reviews of Sensitive and Classified Systems," Attachment 2 to this document.

F. Responsibilities and Process:

IT Security Verification Review Team

The IT security verification review team will always be under the direction of the DOC
IT Security Manager or the IT Security Officer (ITSO) at the operating unit level or a
major subordinate organizational unit. This should assure the level of knowledge about
the DOC IT security program requirements is adequate to make decisions about the
appropriateness and adequacy of controls required for the system under review.
Whenever possible, these individuals should participate in the on-site review as the
team leader. When the ITSO is unable to participate in the actual review, they will
appoint an individual who is judged to have sufficient knowledge about the DOC IT
security program to act as the review team leader. Additional team members should
include personnel knowledgeable about physical and environmental security, personnel
security, information security (if system processes classified national security
information), application security, hardware and software, telecommunications, technical
controls, procedural security, contingency and disaster recovery planning and risk
management. Personnel from the Internal Control Review area within the organization
are also suggested as team members. The actual number of team members may vary
and should be limited to the smallest number possible to cover all areas of concern.
The average team will include two to four individuals, but should be comprised of no
less than two people.

Operating units may contract out for IT security verification reviews to be conducted by
commercial consulting firms or other federal organizations. However, care should be
taken in preparing the procurement requests or agreements to ensure that the review will
be conducted in accordance with all DOC policies and standards. The operating unit
ITSO will act as the COTR for the contract, provide all directions for conducting the
review and set standards for written reports.

The team leader will be responsible for notifying the system owner of the planned
review, making specific review assignments to individual team members based on their
expertise, coordinating activities of team members, conducting an in-briefing and an
exit-briefing with the system owners, conducting team meetings as required, making
decisions about what recommendations are appropriate for the individual system and
preparation of the draft and final "IT Security Verification Review Report." The format
and guidance for preparing this report is contained in Attachment 1 of this document.

Conducting the Review

Written notification should be sent to the system owner two to four weeks in advance
of the review, providing information concerning the purpose of the review, dates of the
review, list of review team members, requesting the assignment of a point of contact
and that the following documentation be made available to the review team.

1. Memorandum officially designating an individual as the IT System Security
Officer (ITSSO)

2. Listing of current personnel (indicate working hours for ADP personnel)

3. Hours of operation of facility

4. Organization charts for highlighting the placement of the individual facilities

5. Applicable floor plans (including building floor plans)

6. Latest risk analyses for the system

7. Reports of external and internal security (both ADP and other) evaluations
completed during the 3 years

8. Hardware inventory (to include minis and micros)

9. Software inventory (include production programs, utility programs, commercially
available software, operating systems, etc.)

10. List of users:

a.within the Department
b.at other federal agencies
c.others

11. Disaster recovery plans

12. Policies, directives, guidelines, etc., pertaining to IT security issued by local
authorities

13. Minutes of any management meetings that address IT security

14. Any other documentation pertaining to IT security

15. Information pertaining to IT security awareness and training including course
content, type of training and number of personnel who have completed or are
scheduled for training

16. Information pertaining to ADP-related position sensitivity and personnel screening
for facility

17. Copies of any contracts for operation and maintenance or other service agreements
related to this system

18. Reports of any internal IT security reviews that may have been conducted

19. Reports of any Internal Control Reviews or any reviews conducted by other
external or internal organizations

20. Discussion of any known needs for guidance or assistance or specific areas of
concern in IT security from either the operating unit, Department or federal levels

21. Sensitive System Security Plan

22. Certification documentation, if available

The system owner should appoint an individual, usually the ITSSO, to act as the point
of contact for the review team. This individual should participate as an observer in the
review and coordinate interviews or make other arrangements as necessary to assist the
review team. An entrance meeting should be arranged to allow the review team to
explain its mission and review methods to the system owner and staff members.
During the course of the review, the team will discuss their findings and
recommendations with the point of contact or system owner and keep them advised
about the progress of the review.

Prior to the actual on-site review of the system, all team members should be provided
with a copy of the security plan for the system to be reviewed. The team should meet
to discuss the scope of the review, which will be determined by the size, sensitivity
level, type and complexity of the system as identified in Section I. through Section
III.B. in the security plan. During the actual on-site review, it is recommended that the
team leader be the evaluator to verify the information contained in these sections of the
plan. The team leader should share the results of the verification with all other team
members to ensure that their reviews are based on accurate requirements for the system.
Although it is not necessary for all team members to be experts about what controls are
appropriate for every type system, they should be given enough guidance about the
system under review to avoid wasting too much time asking questions that are not
relevant for the particular system. A very obvious example of this would be if the
system under review is a microcomputer or local area network system, asking questions
relating to a computer room would not be relevant. A less obvious example would be
for a system that contains nothing but public information, asking multiple questions
about confidentiality controls would be a waste of time and might lead to inappropriate
recommendations. Other considerations that would have a bearing on determining
adequate and appropriate protection requirements for a specific system would include
the physical location, environment, category of system, telecommunication
configuration, sensitivity of data, availability requirements and importance to mission
accomplishment.

It is important to understand that the IT security verification review is not intended to
be a risk analysis. Testing of actual controls will be limited to only those necessary to
verify their existence and proper operation. If documentation of prior testing of
controls appears adequate (i.e., risk analysis or system certification documentation) then
further testing would not be conducted. Appropriate tests might include such things as:
(1) having system owner demonstrate access controls on the system (i.e., logging into
the system to ensure password is blanked, attempting to establish passwords outside
established password constraints, viewing SCREEN WARNING messages, attempting to
access files that should be restricted, etc.); (2) attempting to access computer room
outside normal working hours to ensure doors are locked or verifying that visitors are
challenged. Evaluators are not to attempt penetration of the computer or to remove any
system resources (i.e., equipment, media or printed output, etc.), as these actions could
be considered security violations.

At the conclusion of the review, the "IT Security Verification Review Report" will be
prepared in the format outlined in Attachment 1 of this document. A copy of the draft
report with major findings and recommendations should be provided to the system
owner during the exit-briefing. Within two weeks after the conclusion of the review,
the system owner should provide the review team leader written comments or questions
about the draft report findings and recommendations. The review team should consider
the system owner's concerns and prepare and forward the final report for the system
owner's action.

Use of the "IT Security Verification Review Guideline"

The guideline, contained in Attachment 2, provides a structured process for
accomplishment of the required IT security verification review for DOC IT systems. It
was developed following the format required for DOC IT system security plans and
provides detailed questions for each section contained in the plans. Since the purpose
of the IT security verification review is to determine if the individual IT system has
been provided with adequate and appropriate levels of protection based on its unique
protection requirements, many of the questions under specific control areas will not
apply to all IT systems.

System Owners

System owners may also find this guideline helpful in performing management control
reviews and the required risk analysis or certification testing of their systems. The
guideline contains extensive questions about all categories of controls and could be
useful in verifying that adequate consideration of appropriate controls has been included
in their risk analysis, certification methodologies or for management control review
ideas. It may also serve as a useful tool in identifying additional controls that would be
appropriate for their systems.
ATTACHMENT 1

INFORMATION TECHNOLOGY SECURITY
VERIFICATION REVIEW REPORT FORMAT

Format

The "Information Technology (IT) Security Verification Review Reports" should be consistent
across all DOC organizations and should contain the following sections:

Cover page

Executive Summary
Introduction

Discussion
Objective
Method

System and Sensitivity Information
System Description/Purpose
System Environment and Special Considerations
General Description of Information Sensitivity

Recommendations

The following sample report was prepared in the appropriate format and contains guidance for
content in each section.

(ORGANIZATION CONDUCTING REVIEW)

INFORMATION TECHNOLOGY SECURITY REVIEW

DOC SYSTEM NUMBER
(OPERATING UNIT)
(SUB ORGANIZATION)

(SYSTEM NAME/TITLE)

(CITY, STATE WHERE SYSTEM IS LOCATED)

(MONTH, YEAR)

EXECUTIVE SUMMARY

Introduction

An Information Technology (IT) Security Verification Review, in
conformance with the requirements of the Computer Security Act of 1987
and Office of Management and Budget (OMB) Bulletin 90-08, was
conducted during the period at the (Operating Unit, Sub-
organization, System Name/Title, in City, State.)

The IT Security Review Team was lead by ,
(Organization and Title). (List all other team members by name,
organization and title) team members. Each team member was assigned
specific sections of the Sensitive System Security Plan for the
system, to verify and validate the accuracy of the information contained
in the plan and to ensure that the system controls were adequate and
appropriate for the system. The review was conducted in accordance
with guidance contained in the "DOC Guidelines for Conducting
Information Technology Security Verification Reviews of Sensitive and
Classified Systems".

The IT Security Review was conducted on the DOC IT System Number
, "(Name/Title of System)". The system (describe in general terms the
purpose of the system. See Section I.E. in the security plan.)

The overall IT security profile of this system was (excellent, very good,
good, adequate, inadequate or poor). This paragraph should contain
summary information about the findings, including positive actions,
controls or other significant items that the system owner has implemented
to protect the system. Any major problems noted during the course of
the review should be described in general terms or "no major problem
were noted". Recommendations primarily concerned (describe in general
categories (i.e., improvements in administrative procedures,
documentation, contingency planning, backup storage, personnel
management and user access control).)

The purpose of this review was to improve IT security specifically and IT
resource management in general at (system name) and to ensure
compliance with prescribed IT security policies and regulations and to
identify areas where further security controls may be necessary to
improve the protection of the system.

At the conclusion of the on-site visit, the review team discussed its
preliminary findings with the (system) management and IT security staff
personnel who indicated general agreement and a willingness to
implement all recommendations (or major objections). Implementation
of the recommendations will provide assurance that all risks have been
identified and appropriate levels of security exist for protection of the
system.

DISCUSSION

Objective

The objectives of this review were to determine the coordination and
implementation of activities conducted by the (system organization) to
ensure the protection and integrity of information resources such as
development of security plans for sensitive and classified systems,
ensuring periodic risk assessments are conducted, establishing
contingency and disaster recovery plans, implementing a security
awareness and training program, performing IT security reviews, and
certification and accreditation of sensitive systems.

Specific laws, regulations and policies used as guidelines for this review,
included:

OMB Circular A-130, Appendix III, "Security of Federal Automated
Information Systems"

Public Law 100-235, the "Computer Security Act of 1987"

Department of Commerce, "Information Technology Handbook,
Chapter 10, Information Technology Security"

OMB Bulletin 90-08, "Guidance for Preparation of Security Plans
for Federal Computer Systems that Contain Sensitive Information"

Department of Commerce, "Guidelines for Conducting Information
Technology Security Verification Reviews of Sensitive and Classified
Systems"

This review was conducted to evaluate compliance with federal and
Departmental IT security policies and requirements and assess the
system's IT security profile. Review criteria was based on evaluation of
the in-place and planned controls identified in the Sensitive System
Security Plan for this system (DOC System Number ).

Method

The review team's approach in this evaluation was to interview (system
name/title) management and staff personnel, observe operations of the
system and the physical facilities and resources within the buildings and
review all IT security program related documentation. The primary
point-of-contact for this system review was (Name and title). Other Staff
members contacted during the review included: (List names and titles).

During the entrance interview with system management and staff
personnel, the review team's mission and methods were explained in
detail.
SYSTEM AND SENSITIVITY INFORMATION

SYSTEM DESCRIPTION/PURPOSE

(Copy information contained in Section I.E. of the security plan or
correct information after the conclusion of the review.)

SYSTEM ENVIRONMENT AND SPECIAL CONSIDERATIONS

(Copy information contained in Section I.F. of the security plan or
correct information after the conclusion of the review.)

GENERAL DESCRIPTION OF INFORMATION SENSITIVITY

(Copy information contained in Section II.B. of the security plan or
correct information after the conclusion of the review.) RECOMMENDATIONS

The review was conducted, using the "DOC Guidelines for Conducting
Information Technology Security Verification Reviews of Sensitive and
Classified Systems" and the "Sensitive System Security Plan" for DOC
System , as the basis. The review included on-site inspections of
the facilities, computer room environment, hardware configuration, and
interviews of management and computer center personnel The following
recommendations are a result of the review findings:

The security plan for this system should be updated to incorporate any
changes resulting from these recommendations.

Recommendations should be numbered.

Recommendations should be listed by security plan section
number. Example Section III.C.2.b. This will relate each
finding and recommendation to a specific control category.
There may be multiple separate recommendations under a
specific section number.

Each finding and recommendation should be discussed with the
system owner during the exit briefing in as much detail as
possible by the review team member making the
recommendation. Every effort should be made to discuss
findings with the point of contact or system owner prior to the
exit briefing. This will ensure that all significant facts have
been taken into consideration about any unique situations or
requirements affecting the individual system. Discussion about
security requirements during the course of the review also
provides an excellent opportunity to increase IT security
awareness and training.
SECTION 6.1
MALICIOUS SOFTWARE

A. Purpose:

The purpose or this section is to establish Department of Commerce
(DOC) policy to minimize the risk of introducing malicious software
into computer systems. It also provides guidelines for the detection
and removal of malicious software from information technology (IT)
systems.

B. Overview:

Malicious software presents an increasingly serious security problem
for computer systems and networks. Malicious software includes
viruses and other destructive programs, such as Trojan horses and
network worms. This type or software is often written as
independent programs that appear to provide useful functions but
also contain malicious programs that can be very destructive. It can
be quickly spread through software bulletin boards, shareware, and
users unknowingly copying and sharing these programs in an
unauthorized manner. It can also be spread by users sharing data
files and software products. Networks are particularly vulnerable as
they allow very rapid spread of the virus to all systems connected to
the network.

A program that is infected with a virus can infect any host in which
the program is used. Because of the insidious nature or a virus, any
user may become an unwitting propagator. Commerce's dependence
on networked computer systems, personal computers (PCs), and
office automation makes us susceptible to virus "attacks."

Computer viruses have become a threat to virtually everyone using a
computer. A virus can destroy programs and data by copying itself
to other programs. It is then executed when the infected program is
run. It can disable computers and entire computer networks. It can
also cause lost computer time and staff resources to track and
eliminate it.

Most operating units within the Department have been infected with
different computer viruses. In many cases, data was not lost but
time and staff resources were wasted tracking and eliminating these
viruses.

PCs are more susceptible to viruses than other types of computers
due to their widespread use. However, viruses can be created for
any type of computer. Malicious programs such as Trojan horses
and trap doors were originally written for mainframe computer
systems. Introduction of malicious programs into these larger
systems is usually caused by unauthorized users accessing a system
without adequate controls or by authorized users making
unauthorized use of the system.

Sound IT security procedures will help detect and prevent computer
viruses and other malicious programs from spreading or causing
damage. The guidelines contained in this document can be adapted
for any type of computer system.

C. Background and Authority:

Due to the widespread threat from computer viruses to all
organizations, both private sector and government, it has become
necessary to implement specific measures designed to reduce this
threat and the potential damage caused by virus infections to DOC
IT systems. The DOC malicious software policy is established in
compliance with the "Computer Security Act of 1987," Office of
Management and Budget (OMB) Circular A-130, and the
"Computer Fraud and Abuse Act", Public Laws 98-473 and 99-474,
18 U.S.Code 1030.

D. Scope:

This policy covers all IT systems that are used to process Commerce
data, including contractor-owned and/or contractor-operated systems.

This policy applies to all employees, personnel from other
organizations, contractor personnel, and vendors using Commerce
systems participating in DOC sponsored software development,
software demonstrations, and the operation and maintenance of IT
systems.

E. Policy:

All DOC organizations will establish and implement a process and
procedures to minimize the risk of introducing viruses and other
malicious software, to ensure timely detection of viral infections, to
provide procedures for eliminating viral infections from the
Department's inventory of microcomputers (PCs), and to provide
procedures to minimize the risk from malicious programs to larger
systems, or systems where virus detection software is not yet
available.

F. Responsibilities and Process:

Responsibilities

The Director for Information Resources Management is responsible
for the Department's IT security program. This includes
establishing IT security policies and procedures for safeguarding
Departmental IT resources.

The Departmental IT Security Manager shall serve as the central
point of contact for all matters relating to IT security for the
Department and will be responsible for developing a process for
disseminating information concerning the potential dangers from,
and guidelines for control of, malicious software.

Operating unit IT Security Officers (ITSO) are responsible for:

1. Developing appropriate procedures and issuing instructions for
the prevention, detection, and removal or malicious software
consistent with the guidelines contained herein;

2. Ensuring all personnel within the operating unit are made aware
of this policy and incorporating it into IT security briefings and
training programs;

3. Identifying and recommending software packages for the
detection and removal of malicious software;

4. Developing a system for users to report computer viruses and
other incidents and then notifying potentially affected parties of
the possible threat;

5. Promptly notifying the Departmental IT Security Manager of all
IT security incidents including malicious software;

6. Providing assistance in determining the source of malicious
software and the extent of contamination;

7. Providing assistance for the removal of malicious software; and

8. Conducting periodic reviews to ensure that proper security
procedures are followed, including those designed to protect
against malicious software.

Managers must ensure that employees and contractors follow
operating unit procedures which comply with this policy.

Employees, personnel from other organizations using DOC systems,
contractor personnel, and vendors are responsible for following
operating unit procedures for the protection of IT resources to which
they have access. This includes reporting IT security incidents,
involving viruses and other malicious software to their manager or
supervisor and the ITSO for their organization.

Requirements

The requirements defined in this section, when implemented, will
minimize the risk from introduction of viruses and other malicious
software to DOC IT systems and networks. Not all requirements
listed will apply to every IT system or network. Each organization
must consciously evaluate the appropriateness of each of the
following policies and implement those that apply to the category for
their particular system.

1. Procedures. Each operating unit will establish appropriate
procedures for adherence to this policy based on the criticality,
sensitivity, and risks to their IT systems.

Until virus detection software becomes available for all types
of IT systems, the best protection against malicious software
attacks is to establish good IT security procedures to control
access to and actions taken on the IT system.

2. Backing up software and data. Employees should back up
new software immediately, retaining the original distribution
diskettes in a safe and secure location. Write-protect original
diskettes prior to making back-up copies. If a virus destroys
the working copy, the original software is still available.
Copying copyrighted software material without the vendor's
consent is illegal. If a vendor has not provided pre-approval
of backup copies, employees must have vendor approval to
create additional copies. Use only newly-formatted diskettes
for copying software for backup storage. Used disks may
already contain malicious programs which would contaminate
the backup copies.

Data files should be backed up frequently and stored off-site
or in a secured environment.

Restore damaged software programs from the original
diskettes, not from regular backups. A virus may have been
introduced prior to backup.

3. Outgoing software. A serious impact on the credibility of the
Department would result from being identified as the source
of a virus. Therefore, all software and data leaving the
Department must be checked for viruses or other malicious
coding.

Use only new media for making copies for distribution.
Where possible, use a stand-alone computer system when
preparing copies for distribution.

PC systems to which access is somewhat open, (i.e., training
rooms or user laboratories, etc.) should never be used as a
source of software or files to be transmitted and/or copied
for distribution, without first taking steps to ensure that the
system is free from viruses or other malicious software.

4. Software. All PC machine-readable media will be scanned for
malicious software before initial use. Follow all vendor
instructions carefully and write-protect virus scanning software
media prior to use. Scanning software can become contaminated
in the same way as other software. Although software sealed in
"shrink-wrapped" plastic is usually checked by vendors, it is still
advisable to scan this software since there have been reported
cases in the Department of software contamination. Write-protect
software prior to scanning to prevent possible contamination from
system and virus scan software being used.

Several reputable software packages are available to detect and/or
remove viruses from machine-readable media. There are also
utilities that can search text files for virus signatures. Most
packages are designed for PC systems and local area networks,
but may not be adequate for all PC operating systems. There are
very few available for larger systems.

Requirements to scan for malicious software are to be
implemented as soon as the tools become available for a
particular combination of hardware and software.

Establish controls for local area networks that prevent anyone
except the system administrator or other authorized staff from
loading software on file servers. Ensure that operating system
files and other executable files are read-only. If possible, disable
the network mail facility from transferring executable files. This
will help prevent network worm programs from spreading
through the network.

Trojan horses and other similar malicious software programs
are most often introduced by insiders and it is not unusual
for larger systems to be the target. The best protection
against attacks of this type are to establish good
management procedures. Effective controls include
separation of duties, limiting individual access and allowed
actions to what is needed and no more, formal change
control and configuration management procedures,
separation and testing of development versus production
software and control over installation of new software
versions. Frequent backups of the system and data will
allow recovery should an incident occur.

5. Authorized software. It is imperative that machine-readable
software and data files be obtained from reliable sources.
Viruses are often spread through free or shared programs,
games, demonstration programs, and programs downloaded from
bulletin boards. Employees must not use privately-owned
software or take software from their office without management
approval. Commercial software must be obtained through
appropriate procurement channels. In-house developed software
must be done in accordance with established policy within the
operating unit and have prior management approval.

Shareware and freeware software must be obtained only with
prior management approval. Software obtained
electronically from bulletin boards should be downloaded to
newly formatted diskettes and not directly to the computer
hard disk. All newly acquired software, regardless of source,
is subject to the scanning requirements in sub-paragraph 4
above.

6. Employee demonstrations. When possible, employees
demonstrating DOC products must be certain that the hardware
and software they are using are free of viruses. Use hardware
write-protection mechanisms (i.e., read-only diskettes with write
tabs; write-protect rings for tapes; knock-out rings on cassettes,
etc.) to avoid any virus from infecting the media. If possible,
check the hardware for viruses before loading the demonstration
software. Do not allow other software to be used until the
demonstration is completed.

7. Passwords. For larger systems and networks, user identification
and passwords are the primary protection mechanism against
malicious software. If the would-be perpetrators cannot get into
the system, they cannot put malicious software on the system.
When possible, all IT systems that are shared resources,
including local area networks and multi-user stand-alone systems
shall implement a user identification and verification system,
such as a USERID and password. Conformance to the
requirements of Chapter 10, Section 10.16 of the "DOC IT
Management Handbook," and Section 16 of the "DOC IT
Security Manual" in establishment, structure, individual
accountability, periodic changing and removal are required.

Log files should be reviewed periodically to detect unusual
activity. Terminals, workstations and networked PCs should
never be left unattended when logged in.

8. Vendor demonstrations. Vendors will demonstrate their software
on stand-alone hardware, where possible. An employee must
scan the stand-alone hardware before it is used by the vendor to
verify that the computer does not contain any viruses. This
shows the Department acted in good faith to prevent infecting the
vendor's software.

An employee will scan the stand-alone hardware when the
demonstration is completed to determine if the vendor
software contains a virus and remove it from the system.
The vendor should be notified immediately to prevent further
infections.

In the case of network software demonstrations, the system
administrator must approve and coordinate the
demonstrations.

Written certification from the vendor that the demonstration
software has been checked and is free from viruses, should
be obtained prior to loading any vendor software.

9. Hardware. PC hard disk drives, network file servers and other
media which will be used to handle departmental information will
be formatted between the time they are received and put into use.
There have been cases of formatted hard disk drives being
received that contained viruses. This requirement also applies to
replacement parts resulting from repair and maintenance of
equipment. This requirement may be waived only if the vendor
installing the software provides a written certification that the
system and software have been checked and are virus free.

Never start up (boot) your computer from a diskette unless it
is the original write-protected system master or a trusted
copy.

Portable computer systems, such as laptops, that leave
Department controlled areas must be scanned for viruses
before and after connecting to systems or software owned by
other organizations.

Never use a local area network file server as a workstation.
File servers should be located in areas where access is
restricted during working hours and locked after hours.

When available and cost effective, virus detection software
capable of continuous monitoring and reporting malicious
programs, should be installed on hard disks to prevent
contamination.

Periodic scans of hard disks, using virus detection software,
should be performed for systems without this protection
installed.

Lock computers and terminals or disconnect keyboards and
store in a secure location, when not in use, to prevent
unauthorized access. Lock doors to areas containing
computers and terminals.

10. Procurement requirement. All procurements for
computer software and hardware will contain a
requirement that the vendor have antiviral procedures in
place to ensure that the media supplied is
uncontaminated by malicious software. In the case of
small, off-the-shelf procurements where it is not possible
to write antiviral clauses, the software will be scanned
with virus detection software prior to use. Procurements
for PC system maintenance should also require antiviral
procedures on the part of the contractor.

Vendors depend on the reputation of their products to ensure
future sales. Reputable vendors are concerned about
correcting any flaws in their systems or products that would
make them vulnerable to attack from viruses or other
malicious software, and on occasion issue recommended
changes to improve security of their products. System
administrators and managers are to implement any vendor
recommended changes, or security fixes as soon as possible,
after official receipt.

Malicious Software Indicators

If your IT system seems to be acting different than usual, a
malicious software incident may have occurred. Below are a few
signs that may indicate that a system has been infected.

1. Any unexplained messages or graphics on the screen,

2. An increase in the time required to load or execute programs,

3. An increase in the time required for disk accesses or processing
from disk,

4. Unusual error messages,

5. Programs or files mysteriously disappearing,

6. Less memory available than usual,

7. Executable files changing size for no apparent reason,

8. Accesses made to non-referenced devices,

9. Data consistently out of balance,

10. File date and time stamps changing for no apparent reason,

11. Obsolete user accounts in use,

12. The presence of unexplained hidden files and/or

13. Unusual network activity.

If your system demonstrates any of the above, it could indicate that
malicious software is present.

Elimination, Recovery and Reporting

If you suspect that your IT system or network has been attacked by
a virus or other malicious software program, do not attempt to fix
the problems, but immediately report it to your supervisor and the
ITSO for your operating unit. They will determine the appropriate
action to control the damage and report the incident to the DOC IT
Security Manager. It is important that the particular virus or other
malicious software program, source, and potential for proliferation
be identified and controlled.

The initial report to the DOC IT Security Manager should be made
within 24 hours of the incident. This report may be verbal and
should include the following information:

Within ten working days of the incident, a written report will be
prepared and sent to the DOC IT Security Manager of the incident
by the operating unit ITSO. This report will include the following
along with all of the above information:

Impact on operation
Severity, including hours devoted to recovery and any additional
costs incurred
Proliferation, number of machines or media infected
Action taken - how malicious software was cleared, who was
notified, including outside organizations, and what steps were
taken to identify the source

If the problem has not been resolved within ten working days, mark
the written report "Interim" and prepare and forward a "Final"
report when the incident is resolved. In cases where resolution is
not possible within 30 days, a written status report describing the
actions taken and planned to resolve the incident must be sent to the
DOC IT Security Manager monthly.

G. Definitions:

Introduction of viruses and other malicious software programs has
generated a whole set of new terms. The following list of definitions
is provided to familiarize personnel with some of these terms.

1. Bacterium. A late bloomer in the infectious terminology jargon
is a "bacterium." It is a program that replicates itself and
becomes a parasite on the host system by preempting processor
and memory capacity.

2. Computer virus. A program that "infects" computer systems in
much the same way as a biological virus infects humans. The
typical virus "reproduces" by making copies of itself and
inserting them into other programs--either in systems software or
in application programs.

3. Flying Dutchman. A feature of Trojan horse malicious
programs that erases all traces of the programming codes
from the computer's memory and eludes any detection.

4. Logic Bomb. A computer code that is preset to cause a later
malfunction when a specified set of logical conditions occur.
For example, a specific social security number in a payroll
system is processed and the logic bomb is activated, causing
an improper amount of money to be printed on the check.

5. Machine-readable media. Media that can convey data to a given
sensing device, e.g., diskettes, disks, tapes, computer memory.

6. Malicious Software. Any of a family of computer programs
developed with the sole purpose of doing harm. Malicious
code is usually embedded in software programs that appear to
provide useful functions but, when activated by a user, cause
undesirable results.

7. Scan. To examine computer coding/programs sequentially, part
by part. For viruses, scans are made for virus signatures or
potentially unsafe practices. (e.g., changes to an executable file,
direct writes to specific disk sectors, et al.).

8. Time Bomb. Computer code that is preset to cause a later
malfunction after a specific date, time or a specific number of
operations. The "Friday the 13th" computer virus is an
example. This virus infects the system several days or even
months before and lies dormant until the date reaches Friday
the 13th.

9. Trap Door. A set of instruction codes embedded in a
computer operating system that permits access while bypassing
security controls.

10. Trojan Horse. A program that causes unexpected (and usually
undesirable) effects when willingly installed or run by an
unsuspecting user. A person can either create or gain access to
the source code of a common, frequently used program and then
add code so that the program performs a harmful function in
addition to its normal function. These programs are generally
deeply buried in the code of the target program, lie dormant for
a preselected period, and are triggered in the same manner as a
logic bomb. A Trojan horse can alter, destroy, or disclose data
or delete files.

11. Virus detection software. Software written to scan machine-
readable media on computer systems. There are a growing
number of reputable software packages available that are
designed to detect and/or remove viruses. In addition, many
utility programs can search text files for virus signatures or
potentially unsafe practices.

12. Virus signature. A unique set of characters which identify a
particular virus. This may also be referred to as a virus marker.

13. Worm. A worm is a complete program that propagates itself
from system to system, usually through a network or other
communication facility. A worm is similar to a virus--it is able
to infect other systems and programs. A worm differs from a
virus in that a virus replicates itself, which a worm does not. A
worm copies itself to a person's workstation over a network or
through a host computer and then spreads to other workstations.
It can easily take over a network as the "Internet" worm did.
Unlike a Trojan horse, a worm enters a system uninvited.

H. References:

Viruses and other malicious software appear to be a growing
problem with new strains of viruses appearing continuously. Users
of IT systems should become as familiar with the subject as possible,
in order to protect against this threat. The following documents
published by the National Institute of Standards and Technology are
good sources of additional information:

John Wack and Lisa Carnahan, Computer Viruses and
Related Threats: A Management Guide, NIST Special
Publication 500-166, August 1989.

Dennis Steinauer, Security of Personal Computer Systems: A
Management Guide, NBS Special Publication 500-120,
January 1985.

An Abbreviated Bibliography for Computer Viruses and
Related Security Issues, NIST, Revised April 18, 1990.