[Directives and Handbooks]
NASA Handbook
NHB 2410.9A
Effective Date: June 1, 1993
Expiration Date:
Responsible Office: AO / Chief Information Officer
NASA AUTOMATED INFORMATION SECURITY HANDBOOK
PREFACE
Public law and national policy require Federal agencies to
establish Automated Information Security (AIS) programs to assure
effective management control and adequate levels of protection for
all agency automated information resources.
Automated information system security is becoming an increasingly
important issue for all NASA managers. Rapid advancements in
computer and network technologies and the demanding nature of space
exploration and space research have made NASA increasingly
dependent on automated systems to store, process, and transmit vast
amounts of mission support information. In many cases, automated
processes are integrated functions that directly contribute to the
success of NASA missions. In today's electronically-based society,
the practice of effective AIS management principles is an inherent
function of good business and good professional practice.
The AIS management process covered by this Handbook exemplifies
NASA's efforts to assure that scientific missions and business
functions are carried out in an accurate, safe, accountable, and
efficient manner. This Handbook, in addition to NMI 2410.7,
"Assuring the Security and Integrity of NASA Automated Information
Resources," provides consistent policies, procedures, and guidance
to assure that an aggressive and effective AIS program is
developed, implemented, and sustained. The provisions of this
Handbook apply to all NASA organizations and NASA support
contractors. Generally excluded are contractor research facility
automated information resources not under direct NASA management
control.
This Handbook is intended primarily for use by Program Office AIS
Managers at Headquarters (PO-AISM's) and Center AIS Managers
(C-AISM's) at Field Installations; however, it has been structured
to allow anyone from senior management to technical support
personnel to quickly understand the overall concepts and their
personal relationship to the AIS Program. The intention of
providing implementation flexibility in the guidance portions is to
encourage the exercise of sound judgement by those closest to a
problem. PO-AISM's and C-AISM's are expected to apply common sense
in determining appropriate variations and exceptions that may
become necessary in specific computing environments.
This Handbook is issued in loose-leaf form and will be revised by
page changes. Comments and suggestions concerning this Handbook
should be addressed to the NASA AIS Program Manager, Code JIS, NASA
Headquarters, Washington, DC 20546.
This Handbook cancels NHB 2410.9 dated September 18, 1990.
Jeffrey E. Sutton
Director, Security, Logistics
and Industrial Relations Division
DISTRIBUTION:
SDL 1(SIQ)
Table of Contents
Paragraph Page
CHAPTER 1. PROGRAM OVERVIEW . . . . . . . . . . . . . . . . .1-1
100 INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . .1-1
a. Management Issue . . . . . . . . . . . . . . . . . .1-1
b. Value of Information and Computing Resources . . . .1-1
c. Life Cycle Phases. . . . . . . . . . . . . . . . . .1-1
d. History. . . . . . . . . . . . . . . . . . . . . . .1-1
e. References . . . . . . . . . . . . . . . . . . . . .1-2
f. Terminology. . . . . . . . . . . . . . . . . . . . .1-2
101 PURPOSE . . . . . . . . . . . . . . . . . . . . . . . . .1-3
102 ORGANIZATIONAL SCOPE. . . . . . . . . . . . . . . . . . .1-3
103 SYSTEMS COVERED . . . . . . . . . . . . . . . . . . . . .1-3
104 EXCEPTIONS. . . . . . . . . . . . . . . . . . . . . . . .1-4
105 NASA COMPUTER SYSTEMS ENVIRONMENT . . . . . . . . . . . .1-4
106 IMPORTANCE OF AN EFFECTIVE COMPUTER SECURITY PROGRAM. . .1-4
a. Management Priority. . . . . . . . . . . . . . . . .1-4
b. Public Image . . . . . . . . . . . . . . . . . . . .1-4
c. Increasing Incidents . . . . . . . . . . . . . . . .1-5
107 NASA AIS PROGRAM BACKGROUND . . . . . . . . . . . . . . .1-5
a. Initial Policy . . . . . . . . . . . . . . . . . . .1-5
b. Initial Handbook . . . . . . . . . . . . . . . . . .1-5
c. Summary of Other Milestones. . . . . . . . . . . . .1-5
108 ORIGIN OF NATIONAL POLICY . . . . . . . . . . . . . . . .1-6
a. National Organizations . . . . . . . . . . . . . . .1-6
b. National Documents . . . . . . . . . . . . . . . . .1-6
CHAPTER 2. PROGRAM ORGANIZATION AND MANAGEMENT. . . . . . . .2-1
200 INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . .2-1
201 MANAGEMENT PHILOSOPHIES . . . . . . . . . . . . . . . . .2-1
a. Integration. . . . . . . . . . . . . . . . . . . . .2-1
b. Decentralization . . . . . . . . . . . . . . . . . .2-1
c. Perfection . . . . . . . . . . . . . . . . . . . . .2-1
202 NASA AIS PROGRAM GOAL AND OBJECTIVES. . . . . . . . . . .2-2
a. Goal . . . . . . . . . . . . . . . . . . . . . . . .2-2
b. Objectives . . . . . . . . . . . . . . . . . . . . .2-2
203 PROGRAM ELEMENTS. . . . . . . . . . . . . . . . . . . . .2-2
a. Basic Elements . . . . . . . . . . . . . . . . . . .2-2
b. Sustaining Program Effectiveness . . . . . . . . . .2-5
204 NASA AIS POLICY . . . . . . . . . . . . . . . . . . . . .2-5
205 HEADQUARTERS ROLES AND RESPONSIBILITIES . . . . . . . . .2-6
a. Overview . . . . . . . . . . . . . . . . . . . . . .2-6
b. Multidisciplinary Coordination . . . . . . . . . . .2-6
c. NASA AIS Program Manager . . . . . . . . . . . . . .2-6
d. Headquarters Program Offices . . . . . . . . . . . .2-9
e. Other Headquarters Offices . . . . . . . . . . . . 2-10
206 INDIVIDUAL RESPONSIBILITIES FOR AIS . . . . . . . . . . 2-10
207 PROGRAM ORGANIZATIONAL STRUCTURE. . . . . . . . . . . . 2-12
a. Overview . . . . . . . . . . . . . . . . . . . . . 2-12
b. Headquarters Level . . . . . . . . . . . . . . . . 2-12
c. Center Level . . . . . . . . . . . . . . . . . . . 2-12
208 MANAGEMENT REVIEW AND COMPLIANCE ASSURANCE PROCESS. . . 2-14
a. Headquarters Reviews . . . . . . . . . . . . . . . 2-14
b. Center Reviews . . . . . . . . . . . . . . . . . . 2-14
c. DPI Reviews. . . . . . . . . . . . . . . . . . . . 2-14
CHAPTER 3. CENTER AND DPI REQUIREMENTS. . . . . . . . . . . .3-1
300 CENTER REQUIREMENTS . . . . . . . . . . . . . . . . . . .3-1
a. Designation of Authorities . . . . . . . . . . . . .3-1
b. C-AISM Responsibilities. . . . . . . . . . . . . . .3-1
c. Identifying DPI's. . . . . . . . . . . . . . . . . .3-2
d. Identifying Additional Entities. . . . . . . . . . .3-4
301 DPI REQUIREMENTS. . . . . . . . . . . . . . . . . . . . .3-4
a. Designation of Authorities . . . . . . . . . . . . .3-4
b. DPI-AISO Responsibilities. . . . . . . . . . . . . .3-4
302 MANAGEMENT PROCESS. . . . . . . . . . . . . . . . . . . .3-5
a. Risk Assessments . . . . . . . . . . . . . . . . . .3-5
b. Certifying Requirements. . . . . . . . . . . . . . .3-6
c. Personnel Screening. . . . . . . . . . . . . . . . .3-6
d. Access Protection and Accountability . . . . . . . .3-6
e. Compliance Assurance . . . . . . . . . . . . . . . .3-6
f. Contingency and Disaster Recovery Plans. . . . . . .3-6
g. Approval of Methodologies. . . . . . . . . . . . . .3-7
303 RISK ASSESSMENT PROCESS . . . . . . . . . . . . . . . . .3-7
a. Purpose. . . . . . . . . . . . . . . . . . . . . . .3-7
b. Scope. . . . . . . . . . . . . . . . . . . . . . . .3-7
c. Minimum Requirements . . . . . . . . . . . . . . . .3-7
d. Security Testing . . . . . . . . . . . . . . . . . .3-9
304 PROTECTIVE MEASURES TO PREVENT MISUSE AND ABUSE . . . . 3-11
305 CERTIFICATION PROCESS . . . . . . . . . . . . . . . . . 3-11
a. New or Modified Applications . . . . . . . . . . . 3-12
b. Recertifications . . . . . . . . . . . . . . . . . 3-13
306 MINIMUM LEVEL OF SCREENING FOR NON-FEDERAL ADP PERSONNEL3-13
307 CONTROLLING ACCESS BY FOREIGN NATIONALS . . . . . . . . 3-14
a. Introduction . . . . . . . . . . . . . . . . . . . 3-14
b. Purpose. . . . . . . . . . . . . . . . . . . . . . 3-14
c Categories. . . . . . . . . . . . . . . . . . . . 3-14
d. Sponsors . . . . . . . . . . . . . . . . . . . . . 3-14
e. Submission/Approval of Requests. . . . . . . . . . 3-14
f. Exceptions . . . . . . . . . . . . . . . . . . . . 3-14
308 CONTINGENCY AND DISASTER RECOVERY PLANNING. . . . . . . 3-16
a. Definitions. . . . . . . . . . . . . . . . . . . . 3-16
b. Plan Content . . . . . . . . . . . . . . . . . . . 3-16
309 NETWORK AND COMPUTER SECURITY INCIDENT RESPONSE (CSIR)
CAPABILITY. . . . . . . . . . . . . . . . . . . . . . . 3-17
a. Responsibilities . . . . . . . . . . . . . . . . . 3-17
b. Objectives . . . . . . . . . . . . . . . . . . . . 3-18
c. Procedure Elements . . . . . . . . . . . . . . . . 3-18
d. Non-duty Hours Considerations. . . . . . . . . . . 3-21
310 CSAT. . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
a. Continuous CSAT. . . . . . . . . . . . . . . . . . 3-21
b. Multifaceted Approach. . . . . . . . . . . . . . . 3-21
311 PROCUREMENT OF PRODUCTS AND SERVICES. . . . . . . . . . 3-23
a. Introduction . . . . . . . . . . . . . . . . . . . 3-23
b. NASA Contracting Environment . . . . . . . . . . . 3-23
c. Project Manager Responsibilities . . . . . . . . . 3-23
d. Sponsoring Organization Responsibilities . . . . . 3-23
e. Contracting Officer Responsibilities . . . . . . . 3-23
f. Evaluating Security Capabilities . . . . . . . . . 3-24
g. Contract Administration. . . . . . . . . . . . . . 3-24
h. Requirements for Contractor-Operated DPI's . . . . 3-24
CHAPTER 4. AUTOMATED INFORMATION CATEGORIES AND
SENSITIVITY/CRITICALITY LEVELS . . . . . . . . . . . . . . . .4-1
400 INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . .4-1
a. Information Categories . . . . . . . . . . . . . . .4-1
b. Sensitivity/Criticality Levels . . . . . . . . . . .4-1
401 INFORMATION CATEGORIES. . . . . . . . . . . . . . . . . .4-4
a. Statutes . . . . . . . . . . . . . . . . . . . . . .4-4
b. Derivations. . . . . . . . . . . . . . . . . . . . .4-4
402 SENSITIVITY/CRITICALITY LEVELS. . . . . . . . . . . . . .4-8
a. Introduction . . . . . . . . . . . . . . . . . . . .4-8
b. Automated Information and Applications . . . . . . .4-8
c. Computer Systems . . . . . . . . . . . . . . . . . .4-8
403 PROTECTIVE MEASURE BASELINE CONSIDERATIONS. . . . . . . .4-8
a. Sensitivity/Criticality Level 0. . . . . . . . . . 4-10
b. Sensitivity/Criticality Level 1. . . . . . . . . . 4-10
c. Sensitivity/Criticality Level 2. . . . . . . . . . 4-11
d. Sensitivity/Criticality Level 3. . . . . . . . . . 4-12
CHAPTER 5. AIS PLANNING . . . . . . . . . . . . . . . . . . .5-1
500 INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . .5-1
501 HEADQUARTERS AIS PLANNING . . . . . . . . . . . . . . . .5-1
a. NASA AIS Program Plan. . . . . . . . . . . . . . . .5-1
b. Headquarters Program Office/Institutional Program Office
AIS Plans (PO/IPO-AISPs) . . . . . . . . . . . . . .5-2
502 CENTER AIS PLANNING . . . . . . . . . . . . . . . . . . .5-3
a. Center AIS Plan (C-AISP) . . . . . . . . . . . . . .5-3
b. Content and Format . . . . . . . . . . . . . . . . .5-5
503 DPI AIS PLANNING. . . . . . . . . . . . . . . . . . . . .5-6
a. Purpose. . . . . . . . . . . . . . . . . . . . . . .5-6
b. Content. . . . . . . . . . . . . . . . . . . . . . .5-7
504 DPI CONTINGENCY AND DISASTER RECOVERY PLANS . . . . . . .5-8
505 EXTERNAL REQUESTS FOR REPORTS ON AIS PLANNING ACTIVITY. .5-8
CHAPTER 6. SPECIAL CONSIDERATIONS FOR MICROCOMPUTERS. . . . .6-1
600 INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . .6-1
a. Security Principles. . . . . . . . . . . . . . . . .6-1
b. Security Implications. . . . . . . . . . . . . . . .6-1
602 SPECIAL PROTECTIVE MEASURES FOR MICROCOMPUTERS. . . . . .6-1
a. Technical Protective Measures. . . . . . . . . . . .6-1
b. Administrative Protective Measures . . . . . . . . .6-2
c. Physical Protective Measures . . . . . . . . . . . .6-2
d. Personnel Protective Measures. . . . . . . . . . . .6-2
603 AIS SOFTWARE MANAGEMENT ISSUES. . . . . . . . . . . . . .6-2
a. Imported Software. . . . . . . . . . . . . . . . . .6-2
b. Centers of Excellence. . . . . . . . . . . . . . . .6-2
CHAPTER 7 - PROCESSING NATIONAL SECURITY INFORMATION . . . . .7-1
700 INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . .7-1
a. Background . . . . . . . . . . . . . . . . . . . . .7-1
b. Scope. . . . . . . . . . . . . . . . . . . . . . . .7-1
c. Preceding Chapters . . . . . . . . . . . . . . . . .7-1
d. References . . . . . . . . . . . . . . . . . . . . .7-1
e. Format . . . . . . . . . . . . . . . . . . . . . . .7-1
701 PROGRAM OVERVIEW. . . . . . . . . . . . . . . . . . . . .7-2
a. Issues, Purpose, and Scope . . . . . . . . . . . . .7-2
b. Systems Covered. . . . . . . . . . . . . . . . . . .7-2
c. Exceptions . . . . . . . . . . . . . . . . . . . . .7-2
702 PROGRAM ORGANIZATION AND MANAGEMENT . . . . . . . . . . .7-2
a. Management Philosophies. . . . . . . . . . . . . . .7-2
b. NASA AIS Program Goal and Objectives . . . . . . . .7-2
c. Program Elements . . . . . . . . . . . . . . . . . .7-3
d. NASA AIS Policy. . . . . . . . . . . . . . . . . . .7-3
e. HQ Responsibilities and Structures . . . . . . . . .7-3
703 CENTER AND DPI REQUIREMENTS . . . . . . . . . . . . . . .7-3
a. Center Requirements. . . . . . . . . . . . . . . . .7-3
b. DPI Requirements . . . . . . . . . . . . . . . . . .7-4
c. Management Process . . . . . . . . . . . . . . . . .7-5
d. Security Risk Assessments. . . . . . . . . . . . . .7-5
e. Misuse and Abuse . . . . . . . . . . . . . . . . . .7-5
f. Security Certification . . . . . . . . . . . . . . .7-5
g. Screening Non-Federal Personnel. . . . . . . . . . .7-7
h. Access by Foreign Nationals. . . . . . . . . . . . .7-7
i. Contingency and Disaster Recovery Planning . . . . .7-8
j. CSIR Capability. . . . . . . . . . . . . . . . . . .7-8
k. CSAT . . . . . . . . . . . . . . . . . . . . . . . .7-8
l. Procurement of Products and Services . . . . . . . .7-8
704 AUTOMATED INFORMATION CATEGORIES AND SENSITIVITY/CRITICALITY
LEVELS. . . . . . . . . . . . . . . . . . . . . . . . . .7-8
a. Information Categories . . . . . . . . . . . . . . .7-8
b. Sensitivity/Criticality Levels . . . . . . . . . . .7-8
c. Protective Measure Baseline. . . . . . . . . . . . .7-8
705 AIS PLANNING. . . . . . . . . . . . . . . . . . . . . . 7-10
a. Headquarters AIS Planning. . . . . . . . . . . . . 7-10
b. Center AIS Planning. . . . . . . . . . . . . . . . 7-10
c. DPI AIS Planning . . . . . . . . . . . . . . . . . 7-10
d. External Requests for Reports on Planning Activity 7-10
706 SPECIAL CONSIDERATIONS FOR MICROCOMPUTER PLATFORMS. . . 7-10
707 OTHER SPECIAL CONSIDERATIONS FOR CLASSIFIED PROCESSING. 7-10
a. Security Reviews, Tests, and Reporting . . . . . . 7-10
b. Maintenance Personnel. . . . . . . . . . . . . . . 7-10
c. Visitors . . . . . . . . . . . . . . . . . . . . . 7-11
d. Physical Security. . . . . . . . . . . . . . . . . 7-11
e. Access Control/Password Management System. . . . . 7-13
f. Audit Trails/Logs. . . . . . . . . . . . . . . . . 7-14
g. Hardware and Software Security . . . . . . . . . . 7-14
h. Declassifying Memory, Media and Equipment. . . . . 7-15
i. Clearing Memory, Media and Equipment . . . . . . . 7-16
j. Upgrading. . . . . . . . . . . . . . . . . . . . . 7-16
k. Downgrading. . . . . . . . . . . . . . . . . . . . 7-17
l. Communications and Network Security. . . . . . . . 7-18
m. Maintenance Procedures . . . . . . . . . . . . . . 7-18
n. Modes of Operation . . . . . . . . . . . . . . . . 7-19
o. System High Requirements . . . . . . . . . . . . . 7-19
p. Multi-Level Requirements . . . . . . . . . . . . . 7-20
Appendix A, REFERENCES. . . . . . . . . . . . . . . . . . . .A-1
Appendix B, ABBREVIATIONS . . . . . . . . . . . . . . . . . .B-1
Appendix C, TERMINOLOGY . . . . . . . . . . . . . . . . . . .C-1
Appendix D, DECLASSIFYING AND DESTROYING MEMORY, MEDIA, AND
EQUIPMENT . . . . . . . . . . . . . . . . . . . .D-1
Appendix E, PLAN FORMAT FOR NASA CLASSIFIED SYSTEMS . . . . .E-1
Appendix F, INDEX . . . . . . . . . . . . . . . . . . . . . .F-1
Appendix G, FEDERAL AIS REQUIREMENTS. . . . . . . . . . . . .G-1
CHAPTER 1. PROGRAM OVERVIEW
100 INTRODUCTION
a. Management Issue. Automated Information Security (AIS)
is an increasingly important issue for all NASA managers. Modern
technology and the demands of space research/exploration have made
NASA more and more dependent on computers to store and process vast
amounts of information that support sensitive and mission-critical
functions. NASA's computer and information assets have such great
value that they must be managed to the same extent as the more
traditional organizational assets (i.e., people, money, equipment,
natural resources, and time).
b. Value of Information and Computing Resources. The value
of NASA's information and computing resources and the importance of
NASA missions creates a need for these resources to be adequately
protected to assure ready availability, high integrity, and
confidentiality, as appropriate. The appropriate protection of
automated information must be motivated and supported by the
managers who own or use that information.
c. Life Cycle Phases. Some automated systems are acquired
"off the shelf" and can be used immediately. Others must be
specially designed, developed, and implemented over months or
years. Once an automated system is fully operational, the options
available to provide adequate security are somewhat limited.
However, if security is designed into an automated system, the
safeguard options are vastly increased and the safeguard costs over
the life of the system are substantially reduced. This is true for
computer hardware, system software, and application software.
Therefore, it is important for NASA managers to ensure that
security is appropriately integrated into all phases of the life
cycle development methodology for automated systems, especially in
the early planning stages.
d. History. In the past, NASA computer security guidance
was provided through the following:
(1) NASA Handbook (NHB) 2410.1, "Information Processing
Resources Management." April 1985.
(2) Assorted NASA policy letters, such as:
(a) "Interim Standard for Identification of NASA
Sensitive Automated Information and
Applications," NASA Headquarters (HQ) Code NT
letter, November 1987.
(b) "Responding to and Reporting Automated
Information Security Incidents," NASA HQ Code
NT letter, January 1988.
(3) Assorted NASA guidelines, such as:
(a) "Guidelines for Certification of Existing
Sensitive Systems," July 1982.
(b) "Guidelines for Development of NASA Computer
Security Training Programs," May 1983.
(c) "Guidelines for Developing NASA ADP Security
Risk Management Plans," August 1983.
(d) "Guidelines for Developing NASA ADP Security
Risk Reduction Decision Studies," January
1984.
(e) "NASA ADP Risk Analysis Guidelines," July
1984.
(f) "NASA Guidelines for Assuring the Adequacy and
Appropriateness of Security Safeguards in
Sensitive Applications," September 1984.
(g) "NASA Guidelines for Meeting DOD Accreditation
Requirements for Processing Classified Data,"
March 1985.
(h) "Guidelines for Contingency Planning,"
November 1982.
(i) "Guidelines for Selection of Backup
Strategies," November 1982.
e. References. Appendix A lists the references used in this
Handbook, which expands on NMI 2410.7, "Assuring the Security and
Integrity of NASA Automated Information Resources," and replaces
the following:
(1) NHB 2410.1, Chapter 3.
(2) All prior computer security policy letters.
(3) All of the documents listed in subparagraph d(3).
f. Terminology. Appendix B is a list of abbreviations.
Appendix C provides definitions for most of the AIS related terms
used in this Handbook. Given the number of terms unique to the
computer and/or security disciplines, readers should familiarize
themselves with the definitions in Appendix C before going on to
Chapter 2.
101 PURPOSE
The purpose of this Handbook is to present more specific
guidance on the general computer security management philosophies,
policies, and requirements outlined in NMI 2410.7. This Handbook
is intended to be used by the Center Automated Information Security
Managers (C-AISM's) and HQ Program Office Automated Information
Security Managers (PO-AISM's). This Handbook is not intended to be
site-specific. Headquarters Program Offices and Centers are
encouraged to supplement this Handbook with procedures, duties, and
titles in order to tailor guidance to their unique organizational
structure and automated system environments.
102 ORGANIZATIONAL SCOPE
a. The provisions of this Handbook apply to all NASA and
support contractor organizations as provided by law and/or contract
and as implemented by the appropriate contracting officer.
Generally excluded are contractor or research facility computing
and information resources not under direct NASA management
cognizance or that are merely incidental to a contract (e.g., a
contractor's payroll and personnel system). The managing
organization (i.e., HQ Program Office or Center) may, through the
appropriate contracting officer, elect to include any automated
information resources excluded by this Handbook.
b. Within reason, the provisions of this Handbook should be
applied in university environments (where NASA is supported through
formal agreements such as grants, cooperative agreements,
contracts, and purchase orders.) NASA managers/sponsors of such
activities should take a reasonable approach that will not impose
unnecessary constraints on the open university environment. The
extent of compliance with this Handbook in university environments
needs to be evaluated on a case-by-case basis and may range from
minimal compliance (i.e., for one-time research activities in which
there is no clear indication that NASA is the information owner) to
more stringent compliance (i.e., for universities processing
NASA-owned information on a long-term basis). A risk assessment
should be conducted to identify acceptable risk exposures and
determine how unacceptable risk exposures can reasonably be reduced
to more acceptable levels.
103 SYSTEMS COVERED
This Handbook covers the protection of all NASA automated
information systems, including the information they store, process,
and transmit. It also provides for the continuity of operations of
automated systems and applications.
104 EXCEPTIONS
In certain situations, other protective measures may already
be in place to meet the general requirements contained in this
Handbook. Exceptions from implementing the specifics of this
Handbook may be granted by the managing organization overseeing the
Data Processing Installation's (DPI's) activities. Delegation of
this exception authority shall be no lower than the C-AISM.
PO-AISM's have exception authority for systems under their purview.
NASA Centers and Program Offices cannot grant exceptions to
national level (Office of Management and Budget [OMB], Office of
Personnel Management [OPM], Occupational Safety and Health
Administration [OSHA], National Fire Protection Academy [NFPA],
etc.) requirements. Additionally, exceptions cannot be granted
locally for classified systems, as noted in paragraph 701c.
105 NASA COMPUTER SYSTEMS ENVIRONMENT
NASA represents one of the larger, more complex, and diverse
computing environments in the Federal Government. NASA has an
annual information technology resource budget in the 4 billion
dollar range that supports nine NASA Centers and the Jet Propulsion
Laboratory (JPL). It is recognized that while JPL is not viewed as
a NASA Center, it is a facility performing research and development
for NASA under contract by the California Institute of Technology
(Caltech) and thus NASA policy is applicable to JPL to the extent
provided for in the NASA/Caltech contract. These Centers manage
automated information resources on a decentralized basis at a large
number of DPI's, many of which are operated under contract. The
computer system configurations range from the largest mainframe and
super computers in the world to minicomputers, microcomputers, and
intelligent/engineering work stations. Computing and network
operations support earth and space mission functions for a full
array of processing environments ranging from administrative
computing in office settings to scientific and engineering
computing in academic, research center, production plant, and space
vehicle environments. Providing appropriate protection in such a
diverse environment involves a continuing management process of
balancing user needs for unrestricted access to information with
the sometimes conflicting requirements to control access for
preserving high integrity, ready availability, and confidentiality.
106 IMPORTANCE OF AN EFFECTIVE COMPUTER SECURITY PROGRAM
a. Management Priority. The importance to senior NASA
management of an effective computer security program has been
indicated by past NASA Administrators in policy letters to all NASA
employees. These letters expressed personal expectations for "full
support...cooperation...and an aggressive program ...."
b. Public Image. NASA has high public visibility due to the
nature of its operations. Human safety during manned space flight
and the success of research and missions in space is highly
dependent on the reliability of supporting computer (including
network) resources and the integrity of automated information.
Public and Congressional confidence in the Space Program are
directly keyed to the clarity of NASA's commitment to excellence in
all areas.
c. Increasing Incidents. In recent years all Federal
agencies have experienced an increase in international electronic
intrusions and electronic worm/virus penetrations. These problems
are expected to become more technically complex and more widespread
with advancements in computer and telecommunication technologies.
Therefore, it has become increasingly important to develop Computer
(and Network) Security Incident Response (CSIR) capabilities to
minimize the affects of such incidents. See paragraph 309 for
details of such response capabilities.
107 NASA AIS PROGRAM BACKGROUND
a. Initial Policy. In 1979 NASA formally implemented its
AIS Program by defining and promulgating Agencywide policies
regarding the security and integrity of Agency automated systems.
The main focus was on maintaining continuity of operations and
minimizing the potential for improper use of computing resources.
These policies were issued in accordance with the Office of
Management and Budget (OMB) Circular A-71, Transmittal Memorandum
No. 1, July 27, 1978, "Security of Federal Automated Information
Systems." This memorandum required each Federal agency to
establish an automated information security program.
b. Initial Handbook. NASA's basic automated information
security policy was augmented in 1980 with the publication of
extensive guidelines for implementing automated information
security requirements within the Agency. These guidelines were
published in NHB 2410.1, "Information Processing Resources
Management." NHB 2410.1 was updated in 1982 and again in 1985.
NASA operated under its basic policy (circa 1979) until 1988, when
it published NMI 2410.7, "Assuring the Security and Integrity of
NASA Automated Information Resources." NASA then began
restructuring its AIS Program to bring the agency into compliance
with the Computer Security Act of 1987 and technological advances
in computing and telecommunication systems.
c. Summary of Other Milestones. The Agency has had an
established AIS Program since 1979; a full-time AIS Program Manager
since 1985; Computer (and Network) Security Awareness and Training
(CSAT) since 1983; and management evaluations of Agency automated
information security activities since 1979.
108 ORIGIN OF NATIONAL POLICY
a. National Organizations. As presented in Exhibit 1-1, the
NASA AIS Program is based on public laws promulgated by Congress.
The following organizations then issued national policies,
standards, and guidelines:
(1) The Department of Commerce (DOC).
(2) The National Institute for Standards and Technology
(NIST).
(3) The Office of Management and Budget (OMB).
(4) The Office of Personnel Management (OPM).
(5) The National Security Agency (NSA).
(6) The Department of Defense (DOD).
(7) The General Services Administration (GSA).
(8) Various Presidential committees on computer and
telecommunications systems security.
b. National Documents. National policy and guidance
documents include:
(1) Computer Security Act of 1987 (PL 100-235).
(2) Executive Order 12356.
(3) OMB Circular A-130.
(4) NIST Federal Information Processing Standards
(FIPS) Publications.
(5) DOD guidance on protecting classified information.
(6) NSA guidance on trusted computer systems.
(7) OPM Personnel Letter 732.
(8) GSA Federal Information Resource Management
Regulation (FIRMR).
(9) GSA Federal Information Processing Management
Regulation.
(10) GSA Federal Procurement Regulation (FAR).
(EXHIBIT 1-1. National Policy and Guidance--See hardcopy)
CHAPTER 2. PROGRAM ORGANIZATION AND MANAGEMENT
200 INTRODUCTION
This Chapter covers the NASA AIS Program goal, objectives,
organizational structure and management.
201 MANAGEMENT PHILOSOPHIES
a. Integration. The NASA AIS Program is designed to provide
appropriate, cost-effective protection for sensitive, classified,
mission critical, life support, and high-dollar-value information
and computer/network resources. In this regard, NASA has an
extensive AIS Program that is highly integrated into its management
functions through management points-of-contact, intra-agency
working groups, councils, and committees. These management and
coordinating bodies range from a senior management Security
Coordinating Committee (SCC) and Information Resources Management
(IRM) Council to PO-AISM's, C-AISM's, local Data Processing
Installation AIS Officials (DPI-AISO's), and Computer Security
Coordinators (CSC's) at the system level. A concept of total
systems engineering, Total Quality Management (TQM), and total AIS
integration is applied.
b. Decentralization. Due to NASA's highly decentralized
approach to managing a large number of diverse computer and network
environments nationwide, a decentralized approach for managing
automated information security has been taken. NASA HQ interprets
national policy and guidance and issues general policy and guidance
appropriate for the NASA computer/network environment. Each
Program Office (PO) is responsible for establishing an automated
information security management function which will ensure the
security, integrity, and continuity of operations for automated
information resources directly related to their program missions.
Each Center is responsible for establishing and sustaining an
automated information security program that assures each DPI under
its management cognizance complies with automated information
security requirements that are consistent with the DPI's unique
computer/network environment. Specific protective decisions (e.g.,
cost-effective approaches, benefits to be derived) are made by
management at the IPO, Center, and DPI levels based on risk
assessment activities. Functional security requirements and
technical security specifications are integrated into appropriate
system life cycle phases and appropriate security-related
responsibilities are included in job descriptions and performance
evaluation criteria. Compliance is assured through multiple levels
of top-down management and compliance review activities.
c. Perfection. A state of absolute protection is not
practical nor desirable in most cases. Numerous reasons include
the following:
(1) Absolute protection would make the Agency's systems
virtually unusable by the research community for which the Agency's
mandate, under the Space Act of 1958, is to provide the most useful
information to the widest possible audience.
(2) Some vulnerabilities may not be known, as in the
technically complex cases where vendor-supplied operating systems
contain security flaws.
(3) Computer and network technology is constantly
advancing at a rapid pace. While these advances create new
opportunities for our scientists and engineers, they also offer new
opportunities for those who wish to commit malicious acts.
(4) Protection must be applied in a cost-effective
manner in order to meet Agency responsibilities in its expenditures
of public funds.
202 NASA AIS PROGRAM GOAL AND OBJECTIVES
a. Goal. The goal of the NASA AIS Program is to provide
cost-effective protection that assures high integrity, ready
availability, and confidentiality of NASA automated information
resources. Thus, the main focus in scientific and engineering
environments is to provide appropriate cost-effective protection
and management emphasis that assures appropriate levels of
information integrity and computing resource availability without
unnecessarily impacting innovative productivity or the advancement
of technology. In these environments and in the administrative
environments, where the sensitive or classified nature of
information calls for mandatory or discretionary protection from
unauthorized disclosure, additional consideration must be given for
providing cost-effective protection that assures information
confidentiality.
b. Objectives. The objectives of the NASA AIS Program are
to:
(1) Protect against deliberate or accidental corruption
of NASA automated information.
(2) Protect against deliberate or accidental actions
that cause NASA automated information resources to be unavailable
to users when needed.
(3) Ensure that there in no deliberate or accidental
disclosure of NASA sensitive or classified automated information.
203 PROGRAM ELEMENTS
a. Basic Elements. The basic elements of the NASA AIS
Program are illustrated in Exhibit 2-1. They are to be employed in
appropriate combinations, and at appropriate times throughout a
system's life cycle, to adequately protect sensitive, critical,
valuable, and
(EXHIBIT 2-1. NASA Automated Information Security
Program Logo--See hardcopy)
important NASA automated information resources at acceptable levels
of risk. The NASA AIS Program covers both classified and
unclassified automated information resources.
(1) AIS Policy/Guidance. Automated information security
policies and guides are needed to define the overall framework
(including lines of authority, main points-of-contact, range of
responsibilities, requirements, procedures, and management
processes) for implementing and sustaining an efficient and
cost-effective NASA AIS Program.
(2) AIS Planning. Automated information security
planning must provide a consistent and specific approach for
determining short- and long-range management objectives,
documenting accomplishments, developing security enhancement
proposals, mapping proposals to budget requests, and assuring the
implementation of appropriate cost-effective protective measures.
(3) Sensitivity and Criticality Identification. The
automated information resources used to support NASA missions have
various levels of sensitivity and criticality. These levels need
to be determined, since they are critical to deciding which
protective measures are most appropriate.
(4) Risk Management. NASA managers need to continually
identify and analyze potential threats to NASA's computer/network
environments and reduce risk exposures to acceptable levels. This
process is called risk management.
(5) Protective Measure Baseline. There are numerous
combinations of technical, physical, administrative, and personnel
protective measures available to NASA managers. A baseline of
these protective measures needs to be defined/suggested to
facilitate development of acceptable levels of protection for
computing and information resources managed by NASA or
operated/processed in support of NASA missions.
(6) Certifications/Recertifications. Certifications
and recertifications of automated applications document that
current risk levels are acceptable. They also document the
accountability for the acceptance of residual risks and complete
the evaluation process for protective measures (controls and
validation routines) programmed into automated applications.
(7) Multilevel Compliance Assurance Mechanism.
Management and compliance reviews should be periodically conducted
to sustain optimal security levels at all centers and DPI's.
(8) Incident Response. It is necessary to develop
specific and appropriate responses to the various security
incidents that may occur. It is also necessary to provide feedback
information to senior management on significant incident
situations. This information also supports the tracking of
agencywide trends.
(9) Continuous CSAT. Continuous CSAT is necessary to
elevate and sustain management and personnel awareness and provide
specific guidance to personnel who design, implement, use, or
maintain automated information resources.
b. Sustaining Program Effectiveness. After policies and
procedures have been established and initial security management
tasks have been accomplished at the IPO's, Centers, and DPI's, the
ongoing aspects of risk assessment, recertification, computer
security awareness and training, and compliance review activities
must continually refresh local automated information security
programs and keep them alive. The ongoing aspects of significant
incident reporting and annual submission of automated information
security plans must provide managers at the Center and HQ levels
with sufficient information to continually reassess current program
status and determine future management direction.
204 NASA AIS POLICY
It is NASA policy that:
a. Technical,
b. Personnel,
c. Administrative,
d. Environmental, and
e. Access
protective measures be used, alone or in combination, to
cost-effectively provide an appropriate level of protection for
NASA automated information resources, and especially for automated
information. The rigor of controls must be commensurate with the
sensitivity/criticality level of the information resources to be
protected. Selection of protective measures for a specific
automated information system environment should be based on an
assessment of risks and the existence of reasonable ratios between
the costs/benefits of proposed protective measures and the
sensitivity, criticality, and/or value of the assets requiring
protection. Appropriate emphasis should be placed on:
f. Automated information,
g. Computer hardware, and
h. Computer software
to assure that they are appropriately protected from threats that
include unauthorized:
i. Access,
j. Alteration,
k. Destruction,
l. Removal (e.g., theft),
m. Disclosure,
n. Use/abuse, and
o. Delays
as a result of improper actions or adverse events.
205 HEADQUARTERS ROLES AND RESPONSIBILITIES
A. Overview. There are many organizations that have roles
and responsibilites related to implementing and managing the NASA
AIS Program, although the Head of each Federal agency has ultimate
responsibility.
b. Multidisciplinary Coordination.
(1) Management Disciplines. All traditional management
disciplines and functions must be employed in a coordinated fashion
to effectively manage automated information security. The reason
for this multidisciplinary situation is that, over the years, NASA
has become more electronically based and dependent on automation
technologies to support all aspects of its operations and missions.
(2) Security Disciplines. As shown in Exhibit 2-2,
there are many security-related disciplines, each with its own set
of policies and procedures. Each security discipline is almost
always an entirely separate career field throughout the Federal
Government. Only when all such disciplines are working together,
in a highly coordinated fashion, can the entire security process
function properly and efficiently. Thus, it is important for
automated information security managers at all levels to regularly
coordinate with other security-related disciplines.
c. NASA AIS Program Manager. As shown in Exhibit 2-3, NASA
primary authority for managing an Agencywide AIS Program has been
delegated through the Associate Administrator for Management
Systems and Facilities to the Director, Security, Logistics and
Industrial Relations Division. In addition to the general
requirements of NMI 2410.7:
(1) The Director, Security, Logistics and Industrial
Relations Division, shall:
(a) Designate a management official knowledgeable
in both computing and automated information security principles and
practices to be the NASA AIS Program Manager; and
(b) Apprise Center Directors, through appropriate
Program Associate Administrators, of program management reviews
conducted in response to the
requirements of NMI 2410.7 and this Handbook and make
recommendations for improvements, as appropriate.
(EXHIBIT 2-2. Automated Information Security's Relationship
with Other Security Disciplines--See hardcopy)
(EXHIBIT 2-3. Headquarters Roles and Responsibilities--
See hardcopy)
(2) The NASA AIS Program Manager shall:
(a) Serve as an Agency focal point of coordination
among NASA senior management, HQ Program Offices, Centers, and
external organizations on automated information security matters;
(b) Develop, and coordinate the implementation of
Agency plans, policies, procedures, and guidelines related to the
requirements of NMI 2410.7 and this Handbook;
(c) Conduct program management reviews of Centers
to assess the sustained effectiveness of Center management
oversight processes that have been implemented at DPI's under
Center management cognizance and make recommendations to the
Director, Security, Logistics and Industrial Relations Division,
for improvement, as appropriate.
(d) Coordinate the review and dissemination of
information identifying emerging trends to keep NASA management
informed.
d. Headquarters Program Offices. In addition to the general
requirements of NMI 2410.7, Program Associate Administrators shall:
(1) Promulgate Program Office specific policies,
procedures, and guidelines related to the general requirements of
NMI 2410.7 and this Handbook, as deemed appropriate.
(2) Designate a management official knowledgeable in
both computing and computer/network security methods and practices
to be the PO-AISM. The PO-AISM should serve as a focal point to
coordinate Agencywide activities required in NMI 2410.7 and this
Handbook between the HQ AIS Program Manager and cognizant Program
Office organizations. In cases where multiple organizational
levels or program area applications exist, assistant PO-AISM's
and/or CSC's may be designated to accomplish specific automated
information security responsibilities.
(3) Implement and coordinate an appropriate management
oversight process that ensures awareness and compliance with
applicable portions of NMI 2410.7 and this Handbook in cognizant
organizations.
(4) Assure that Program Office AIS Coordinators (i.e.,
PO-AISC's) are designated at appropriate centers.
(5) Assure that all NASA and appropriate NASA contractor
computing and telecommunications resources processing NASA
information are identified and included under the management of a
DPI.
(6) Assure that, through the contracting officer, all
appropriate contractors are required to comply with applicable
provisions of NMI 2410.7 and this Handbook.
(7) Review and concur on exceptions from implementing
specific requirements of this Handbook.
e. Other Headquarters Offices. Other HQ Offices that play
an integral role include:
(1) Inspector General, which has independent audit and
criminal investigation responsibilities.
(2) NASA Security Office, which has traditional
security responsibilities in the areas of personnel
security, physical security, and national
(including defense-related) security document and
operations control.
(3) Office of Space Communications, which has
Agencywide responsibility for telecommunications
management.
(4) Office of Procurement, which is responsible for
ensuring that appropriate security requirements are
included in NASA procurement policies, regulations,
and procedures for acquiring Federal Information
Processing (FIP) resources.
(5) Management Operations Division, which is
responsible for the NASA Internal Controls Program.
(6) Office of Safety and Mission Quality, which has
responsibilities relating to software engineering
and automated information resources supporting
manned space flight operations.
206 INDIVIDUAL RESPONSIBILITIES FOR AIS
As illustrated in Exhibit 2-4, the situation discussed in
paragraph 205 dictates that virtually everyone in the organization
who manages, designs, programs, operates, or uses NASA automated
information resources has personal job-related responsibilities
that contribute toward meeting the goal and objectives of the NASA
AIS Program. The practice of effective automated information
security management principles typically becomes an integral
function of good business and professional practice when it can be
demonstrated that positive benefits can be derived. For example:
a. Appropriately restricting unauthorized access can greatly
contribute to ensuring information/system integrity,
availability, and confidentiality.
(EXHIBIT 2-4. Who Is Responsible for Automated Information
Security?--See hardcopy)
b. Systems that are well planned and passed through a
quality assurance/certification process are typically
more efficient and have fewer and less costly maintenance
problems in operational use.
c. Technology that is used in a controlled environment can
be expected to have greater reliability.
207 PROGRAM ORGANIZATIONAL STRUCTURE
a. Overview. In order to effectively manage the day-to-day
aspects of an automated information security program in a large and
diverse organization like NASA, a network of designated AIS mangers
must be established at all levels throughout the organization.
Exhibit 2-5 illustrates the relationship between NASA-designated
AIS managers and officials at the HQ, Center, and DPI levels.
b. Headquarters Level.
(1) The NASA AIS Program Manager has a direct working
relationship and communications link with HQ PO-AISM's and C-AISM's
to focus on resolving Agencywide AIS issues.
(2) Each PO-AISM has a direct working relationship and
communication link with their program management personnel at NASA
Centers to focus on resolving AIS issues with respect to their
program missions.
(3) Three PO-AISM's also have institutional
responsibility for a specific grouping of NASA Centers. They are
called Institutional Program Office AIS Managers (IPO-AISM's).
Each IPO-AISM has a direct working relationship and communication
link with the C-AISM's at their assigned centers to focus on
resolving AIS issues that impact multiple centers within a specific
grouping.
c. Center Level. Each C-AISM has a direct working
relationship and communication link with DPI-AISO's to focus on
resolving AIS issues that impact multiple DPI's.
(EXHIBIT 2-5. NASA Automated Information Security Program
Structure, Part 1--See hardcopy)
208 MANAGEMENT REVIEW AND COMPLIANCE ASSURANCE PROCESS
Since automated information security compliance levels have an
inherent tendency to degrade with time, management reviews are
necessary to retain a high level of compliance. Therefore, the
NASA AIS Program will require periodic management reviews at all
levels.
a. Headquarters Reviews. NASA HQ will conduct periodic
management reviews of Centers to evaluate their management and
coordination of AIS programs at DPI's under their management
cognizance.
b. Center Reviews. Centers will conduct periodic
self-assessments and compliance reviews at DPI's under their
management cognizance at least every 1 to 3 years. Review
activities should be commensurate with the value and
sensitivity/criticality of automated information resources. Review
activities should also focus on the following three areas:
(1) Tracking Systems and Random Checks. Tracking
systems are needed to monitor implementation of recommendations
from prior review activities (e.g., audits, compliance reviews,
recertifications, risk assessment's). Random checks and tests
ensure actual implementations of appropriate procedures and that
protective measures do, in fact, reduce identified risk exposures
to acceptable levels.
(2) Security Incidents. Reported security incidents
should be tracked to determine trends, to identify general problem
areas and security needs, and to ensure implementation of
appropriate procedures and protective measures. The result should
be fewer incidents in the future.
(3) Contingency Planning. Contingency and disaster
recovery plans provide overall protection when other safeguarding
features may have failed. Such plans should be in place and
periodically tested. For the most sensitive and critical systems,
contingency and disaster plan testing must be conducted annually.
(4) CSAT. Managers should ensure that continuous CSAT
is conducted at DPI's, as appropriate.
c. DPI Reviews. Each DPI will conduct ongoing
self-assessment review activities to include CSAT, risk
assessments, and recertification reviews.
CHAPTER 3. CENTER AND DPI REQUIREMENTS
300 CENTER REQUIREMENTS
a. Designation of Authorities. In addition to the general
requirements of NMI 2410.7, Center Directors shall:
(1) Promulgate specific Center policies, procedures, and
guidelines related to the general requirements of NMI 2410.7 and
this Handbook, as deemed appropriate; and
(2) Designate, in writing, a management official
knowledgeable in both computing and automated information security
methods and practices to be the C-AISM.
b. C-AISM Responsibilities. The C-AISM shall serve as a
focal point to manage a program that is responsive to the Center
Director and coordinate activities required in NMI 2410.7 and this
Handbook between the HQ AIS Program Manager and cognizant DPI's.
In cases where multiple DPI's exist, Assistant C-AISM's may be
designated to accomplish specific Center automated information
security responsibilities. The C-AISM responsibilities include:
(1) Implementing and coordinating an appropriate,
Center-wide management oversight process that ensures awareness and
compliance with the Center automated information security program.
(2) Assuring that each NASA, and appropriate NASA
contractor, DPI under Center management cognizance develops,
implements, and sustains an effective automated information
security program that ensures awareness and compliance at the DPI
level.
(3) Scheduling and conducting periodic compliance
reviews at cognizant DPI's to assess the adequacy of security
plans, the sustained effectiveness of its automated information
security procedures and program, and to make recommendations for
improvement, as appropriate. Compliance reviews should be
conducted every 1 to 3 years based on the reviewing management's
judgement. Factors to be considered in making this decision
include the reviewing management's perception of the sensitivity,
criticality, and/or value of the computing and information assets
to be protected at each DPI.
(4) Assuring that procedures are implemented for
identifying automated information security incidents that occur at
DPI's under their management cognizance. These procedures shall
ensure that significant automated information security incidents
are reported to their IPO-AISM and the HQ AIS Program Manager
immediately following detection and that significant incident
information received from HQ is disseminated to cognizant DPI's.
(See paragraph 309 for a description of this procedure.)
(5) Assuring that, through the contracting officer, all
appropriate contractors comply with applicable provisions of NMI
2410.7, this Handbook, and Center automated information security
directives.
(6) Coordinating all functional security requirements
with organizations/individuals having procurement, training, or
security-related responsibilities (e.g., those having
responsibilities in personnel security, physical security, national
(including defense-related) security, telecommunications security,
information security, internal management control, auditing,
quality assurance/control, administrative security, emissions
security, and operations security).
(7) Implementing procedures to ensure that all imported
software is reasonably safe for its intended environment and that
all software has been properly registered and/or licensed prior to
implementation. This includes software developed for microcomputer
platforms, mainframe computers, communications systems, networks,
or other automated information systems.
c. Identifying DPI's. As illustrated in Exhibits 2-4 and
3-1, the focus of implementing technical AIS requirements begins at
the Center and DPI levels. Center management is to ensure that all
NASA and appropriate NASA contractor computing and
telecommunication resources processing NASA information are
identified and included under the management of a DPI. A DPI is
established by drawing an imaginary boundary around a logical
grouping of information, computing, and telecommunications
resources for the purpose of managing those resources as an
identifiable entity. C-AISM's are responsible for assuring that
DPI's have been identified. This is accomplished by negotiating
with organizations under the cognizance of Center management to
determine the most logical approach. For example, DPI's might
represent logical groupings of information, computing, and
telecommunications resources within the boundaries of:
(1) A physical structure at a geographic location
(e.g., an entire building or a central computing
facility).
(2) An organizational structure (e.g., HQ or Center
organizational code's).
(3) A combination of these approaches.
(EXHIBIT 3-1. NASA Automated Information
Security Program Structure, Part 2--See hardcopy)
The grouping of automated information resources for automated
information security requirements should be consistent, if
possible, with that used for DPI's as defined in the Information
Technology System Plan (ITSP) submitted annually by each NASA
Center.
d. Identifying Additional Entities. DPI-AISO's are
responsible for determining if identification of additional
entities under the DPI is needed to more effectively manage and
coordinate aspects of the DPI automated information security
program. These entities could represent logical groupings of
information, computing, and telecommunications resources associated
with sub-elements of the DPI organization, major hardware or
software configurations, or clusters of microcomputers.
301 DPI REQUIREMENTS
a. Designation of Authorities. Each NASA (or appropriate
NASA contractor) manager in charge of a NASA Center shall assure
that a management official, knowledgeable in both computing and
automated information security management methods and practices, is
designated as the DPI-AISO. Day-to-day security responsibilities
may be delegated to technical support personnel. In cases where
multiple computer/network systems or program area applications
exist, DPI-AISC's may be designated to accomplish specific
automated information security responsibilities.
b. DPI-AISO Responsibilities. (See Exhibit 3-2.) The
DPI-AISO in coordination with the appropriate C-AISM shall:
(EXHIBIT 3-2--See hardcopy)
(1) Implement and administer a management process
appropriate to the DPI environment to ensure that sensitivity
and/or criticality of information is determined by the application
sponsors/owners and that appropriate administrative, technical,
physical, and personnel protective measures are incorporated into
all new and existing computer systems and applications processing
sensitive or mission-critical information to achieve and sustain an
acceptable level of security. (See paragraph 302 for a description
of this management process.)
(2) Formulate, continually update, and annually review
a DPI automated information security plan that will allow the
appropriate approving (i.e., DPI) or reviewing (e.g., Center and HQ
Program Office) authorities to judge the comprehensiveness and
effectiveness of the DPI automated information security program.
In cases where multiple DPI's, computer systems, or program area
applications exist, multiple plans may be appropriate. The
planning process may also be integrated into Center-level planning
activities as deemed appropriate by the C-AISM. (See paragraph 503
for a description of the required contents of a DPI automated
information security plan.)
(3) Develop and implement protective measures designed
to prevent misuse and abuse of computing resources. (See paragraph
304 for a description of these protective measures.)
(4) Develop and implement a process, as appropriate, for
providing contingency planning and reasonable continuity of
operations for computer systems and computer applications
supporting mission-critical functions. (See paragraph 308 for a
description of this process.)
(5) Develop and implement procedures in coordination
with the C-AISM for identifying automated information security
incidents and reporting significant automated information security
incidents, as described in paragraph 309.
(6) Assure that plans are developed and implemented for
conducting continuous CSAT to ensure that NASA and appropriate NASA
contractor personnel involved in managing, designing, developing,
or maintaining computer applications or who use computer systems,
are aware of their security responsibilities and know how to
fulfill them. This includes being kept aware of vulnerabilities
and being trained in techniques to enhance security. (See
paragraph 310.)
(7) Coordinate all functional security requirements with
organizations/individuals having procurement, training, or
security-related responsibilities, e.g., those having
responsibilities in personnel security, physical security, national
(including defense-related) security, telecommunications security,
information security, internal management control, auditing,
quality assurance, administrative security, emissions security, and
operations security.
302 MANAGEMENT PROCESS
The management process must ensure that the following, as a
minimum, are carried out (see Exhibit 3-3):
(EXHIBIT 3-3--See hardcopy)
a. Risk Assessments. Periodic risk assessments must be
conducted for new and existing DPI's to assure that appropriate,
cost-effective protective measures are incorporated and are
commensurate with the sensitivity, criticality, and value of
associated computer systems, computer applications, and information
processed. (See paragraph 303 for a description of the risk
assessment process.)
b. Certifying Requirements. Procedures must be established
for defining functional security requirements, developing technical
security specifications, conducting security design reviews and
system tests, certifying and recertifying computer applications at
appropriate phases of the system life cycle, and approving
technical security specifications for the acquisition of
computer/network resources or related services. (See paragraph 305
for minimum functional security requirements and certification
procedures.)
c. Personnel Screening. Personnel who participate in
managing, designing, developing, operating, or maintaining computer
applications processing sensitive or mission-critical information,
or who access automated sensitive or mission-critical information,
must be appropriately screened to a level commensurate with the
sensitivity, criticality, or value of the information to be
accessed or handled and the risk and magnitude of loss or harm that
could be caused by the individual. Federal personnel are to be
screened in accordance with the Federal Personnel Manual, Section
732 and NHB 1620.3, "NASA Security Handbook." Guidance on
screening non-Federal personnel is presented in paragraph 306.
d. Access Protection and Accountability. Appropriate
protective measures should be established, to the extent
economically and technically feasible, for maintaining personal
accountability of individual users granted access to sensitive or
mission-critical information on multi-user systems and for ensuring
that they have access to no more information than they are
authorized to access. Access to public automated library systems
must be:
(1) Physically or logically isolated from users with
higher security (i.e., integrity, availability, or confidentiality)
requirements;
(2) Protected by read-only access; and
(3) Protected by current backup copies of all files.
e. Compliance Assurance. Followup procedures must be in
place to assure implementation of protective measures in accordance
with recommendations from compliance review and certification and
recertification activities.
f. Contingency and Disaster Recovery Plans. Appropriate
disaster recovery plans and contingency plans must be established
and maintained to prevent loss of information, minimize
interruption, and provide reasonable continuity of computer and
network services should adverse events occur that would prevent
normal operations.
g. Approval of Methodologies. Automated information
security plans, risk assessments, and security certification
methodologies shall be approved by appropriate management officials
in sponsoring organizations.
303 RISK ASSESSMENT PROCESS
a. Purpose. NASA recognizes the importance of conducting
risk assessments as a basis for making informed management
decisions related to accepting identified risk exposures or
implementing appropriate cost-effective protective measures to
reduce risk exposures to acceptable levels. When used
appropriately, risk assessment is a very effective management tool.
It should serve to provide a systematic approach for:
(1) Determining the relative value, sensitivity, and
criticality of DPI information and computing
resources.
(2) Assessing potential threats and perceived risk
exposure levels.
(3) Identifying existing protective measures.
(4) Identifying and assessing additional protective
alternatives.
(5) Determining acceptability of identified risk
levels.
(6) Documenting the assessment process and resulting
management decisions.
b. Scope. Risk assessments may vary from an informal review
of a small-scale microcomputer installation to a formal, fully
documented analysis (i.e., risk analysis) of a large-scale computer
installation. Since risk assessments can involve many disciplines
and organizations, a team approach is recommended, regardless of
the size of the systems being analyzed. A tremendous amount of
time and effort can be saved by bringing together the right people
with the needed knowledge and experience to review concerns and
make subjective judgements, based on professional experience and
knowledge. In addition to standard risk assessments, Security
Testing may be appropriate for some systems. Security Testing is
discussed in section 303d.
c. Minimum Requirements. DPI's will continue to be given
flexibility for selecting methodologies and implementing risk
assessment programs that are most appropriate for their
computer/network environments. However, the risk assessment process
must ensure, at a minimum, the following (see Exhibit 3-4):
(EXHIBIT 3-4--See hardcopy)
(1) A risk assessment methodology is selected (i.e.,
qualitative, quantitative, or a combination of both) that includes
the following elements and logical steps, as appropriate:
(a) Determination of Risk Assessment Scope. For
example, a risk assessment may consider an entire DPI, including
all hardware, software, and telecommunication aspects, or may be
limited to an assessment of an individual mainframe or
microcomputer system. Regardless of the approach, the scope of the
risk assessment should be planned and maintained within manageable
limits and the level of effort should be commensurate with the
nature of the DPI being assessed. For example, a risk assessment
of a stand-alone microcomputer installation could be done
informally by the owner of the information.
(b) Asset Identification and Value. Identification
of major DPI assets and general approximations of their current
replacement value in order to establish a basis for making informed
decisions on protective measures as described in subparagraph (g).
For example, if it is known that the approximate value of computing
resources within the scope of the risk assessment is about $1
million, it may make sense to spend several hundred dollars or
several thousand dollars to enhance protective measures.
(c) Determination of Potential Impacts. General
determination of collective sensitivity, criticality, and/or value
of information processed or stored at the DPI and potential impacts
if information is misused, altered, destroyed, or disclosed. This
determination should be based on an analysis of individual
functional security requirements (which are prepared by
sponsors/owners) of computer applications processed.
(d) Identification of existing protective measures
(i.e., those already in place). Documentation of specific
vulnerabilities and protection measures should be marked "FOR
OFFICIAL USE ONLY" and be adequately protected. (See NHB 1620.3,
"NASA Security Handbook," Section 1208.)
(e) Identification of existing and potential
threats and hazards and qualitative estimates of risk exposure
and/or quantitative calculations; for example, Annual Loss
Expectancy (ALE) associated with potential adverse events.
(f) Determination of acceptable risk exposures,
and/or determination of alternative protective measures, associated
benefits, and associated costs needed to reduce identified risk
exposures and/or ALE to acceptable levels.
(g) Recommendations for accepting risk exposures
and/or ALE's, or recommendations for additional appropriate
protective measures that are needed to improve security (reducing
risk exposure and/or ALE) based on an analysis of the ratio between
the estimated cost/benefit of proposed protective measures and the
value/sensitivity of information/computing resources requiring
protection. The cost of protective measures should not normally
exceed a reasonable percentage of the value of assets requiring
protection (as identified in subparagraphs (b) and (c)).
(h) Documentation of actions taken or planned as a
result of the risk assessment findings and recommendations.
(i) Followup procedures to assure that all action
planned have been carried out.
(2) Risk assessments are performed:
(a) Prior to construction or operational use of a
new DPI.
(b) Whenever there is a significant change to the
existing DPI.
(c) At periodic intervals, established by the
DPI-AISO, that are commensurate with the sensitivity or criticality
of the information processed by the DPI, but not to exceed 5 years
if no risk assessment has been performed during that time.
(3) The selected risk assessment methodologies and
results are approved by appropriate management officials at the
Center and DPI levels and taken into consideration when certifying
or recertifying computer applications.
(4) Risk assessment results are available for
consideration during the evaluation of internal controls, conducted
in accordance with NMI 1200.7, "NASA's Internal Management Control
System," that apply to DPI's or computer applications processing
sensitive or mission-critical information.
d. Security Testing. In some instances, additional Security
Testing may be warranted.
(1) Purpose. The purpose of an Security Testing is to
identify AIS weaknesses and, when appropriate, to recommend actions
to correct identified weaknesses.
(2) Procedure. Sensitive/critical automated information
systems that are under development should be reviewed to ensure
that risk assessments and other security tests are scheduled and
conducted within the proposed general support environment. Systems
tests are required before sensitive/critical automated information
systems are certified and placed into operational use.
(3) Minimum Security Testing Requirements. Security
Testing must ensure that the following minimal requirements are
met.
(a) System vulnerabilities and flaws are identified
and evaluated for all systems within the scope of the Security
Tests.
(b) Operating level Security Testing for selected
systems should cover flaws known to be in the hardware, operating
system software, and, when practical, application software.
(c) Vendor supplied user identifiers and passwords
are changed from the initial installation defaults.
(d) Privileged user access and password files are
adequately protected.
(e) Field service/maintenance user identifiers are
kept inactive when not in use.
(f) Remote diagnostic facility connections are
secured when not in use.
(g) Network router source and destination
authorizations and restrictions are functioning as expected.
(4) Detection of Weaknesses. If weaknesses or flaws in
the operating system or other components are detected:
(a) Corrective action should be taken as soon as
possible.
(b) System AIS plans and risk assessment
documentation should be updated. Updates should indicate
corrective actions taken and/or scheduled.
(5) No Guarantee. It is important to understand that
Security Testing or other system level evaluations do not guarantee
that AIS problems will not be encountered in the future. Such
tests can only give management and users a greater level of
confidence in a particular automated information system. It is
vital that these evaluations be conducted in an open and positive
manner that keeps DPI managers and systems developers informed of
all planned Security Testing activities.
304 PROTECTIVE MEASURES TO PREVENT MISUSE AND ABUSE
In addition to other appropriate protective measures (such as
those covered in Chapter 4), protective measures to prevent misuse
and abuse of computing resources should include the following (see
Exhibit 3-5):
(EXHIBIT 3-5--See hardcopy)
a. Developing and implementing a procedure, where
technically and economically feasible, to maintain automated
computer system logs of access to multi-user computer systems to
determine whether unauthorized accesses are being attempted. In
addition, more detailed system and network security monitoring may
be appropriate provided the legal requirements (such as, warning
banners upon login) have been met.
b. When there is "probable cause" for concern to NASA
management and prior coordination with appropriate legal and
criminal investigative officials has taken place, reviewing the
contents of computer system files at unannounced intervals by means
of random sampling.
c. Developing and implementing awareness procedures
requiring all personnel who access computer and network systems to
have a working knowledge of automated information security ethics,
responsibilities, policies, and procedures.
d. Ensuring that all actions constituting suspected or
confirmed significant automated information security incidents are
brought to the immediate attention of the appropriate DPI-AISO and
C-AISM; that the extent and cause of any incident is determined;
and that reasonable steps are taken to minimize the probability of
further incidents including additional training, counseling,
disciplinary action, and/or notifying criminal investigative and
law enforcement authorities, as appropriate.
305 CERTIFICATION PROCESS
Certification is required to provide reasonable assurance that
a proposed or significantly changed computer application meets all
applicable requirements and the original design specifications and
that installed protective measures are adequate and functioning
properly prior to operational use. The certification process
should involve all those individuals who have participated (or will
participate) in the sponsoring, planning, designing, programming,
operation, and/or use of the application. Since this process could
involve many organizations and individuals, a team approach is
recommended. A representative from each functional area should be
responsible for witnessing the system test and signing off on his
or her area of responsibility. The primary responsibility for
accomplishing certification tasks in coordination with the DPI-AISO
should reside within the sponsoring/data owner organization. The
DPI-AISO of the Installation in which the application will be
processed should assure that the following process has taken place
prior to operational use:
a. New or Modified Applications. For new or significantly
changed computer applications that process level 2 through level 3
(as defined in Chapter 4) sensitive or mission-critical information
assure that (see Exhibit 3-6):
(EXHIBIT 3-6--See hardcopy)
(1) Functional security requirements are defined by the
system and/or information sponsors/owners based on established
installation procedures that include the following:
(a) Identifying and determining the nature of the
sensitivity and/or criticality of information to be processed as
discussed in Chapter 4 of this Handbook, and determining how the
information may be vulnerable to potential threats (e.g., misuse,
alteration, destruction, or disclosure);
(b) Determining primary and secondary system
security concerns (i.e., integrity, availability, confidentiality);
(c) Determining potential impacts if sensitive or
mission-critical information is misused, altered, destroyed, or
disclosed (e.g., embarrassment, legal liability, missed research
opportunity, and lost dollars);
(d) Determining when an application that supports
a mission-critical function must be back in operation after an
interruption to avoid adversely affecting the mission of the user
or the sponsoring/owner organization; and
(e) Determining general approximation of
replacement values associated with the application/information;
(2) System designers develop technical security
specifications that detail functional security requirements and
describe how specific protective techniques will be employed.
These specifications should be described in technical terms that
system developers and programmers can implement;
(3) Functional security requirements and technical
security specifications are reviewed and approved prior to
acquiring or starting formal development;
(4) Results of risk assessments performed at the DPI in
which the computer application will be processed are taken into
consideration when defining and approving technical security
specifications for computer applications;
(5) Security design reviews and system tests are
conducted and approved prior to operational use of computer
applications; and
(6) Upon successful completion of the system test, the
computer application is certified prior to operational use as
meeting requirements of documented and approved functional security
requirements, technical security specifications, and related DPI
procedures, and that results of the system test demonstrate that
the application, computer system, and DPI protective measures are
adequate and functioning properly.
b. Recertifications. For operational applications, assure
that:
(1) Periodic reviews are conducted and recertifications
are made of the continued adequacy and proper functioning of
protective measures;
(2) The recertification process takes into consideration
all available information (e.g., other reviews and audits that may
have been conducted subsequent to the last certification); and
(3) Recertifications are conducted at least every 3
years, as appropriate. Time intervals should be commensurate with
the sensitivity/criticality of the information processed. If no
significant change has taken place and no deficiencies have been
identified in other review activities, the recertification process
may be less stringent than the initial certification process.
306 MINIMUM LEVEL OF SCREENING FOR NON-FEDERAL ADP PERSONNEL
Individuals participating in the management, design,
development, operation, or maintenance of automated information
assets and associated system protective measures shall receive at
a minimum, a National Agency Check. NHB 1620.3, "NASA Security
Handbook," will provide procedures and information on additional
personnel screening actions that may be required in moderate or
high risk situations for level 2 and level 3 automated systems.
307 CONTROLLING ACCESS BY FOREIGN NATIONALS
a. Introduction. The NASA Office of Policy Coordination and
International Relations has primary responsibilities for
establishing NASA policy on controlling access to NASA facilities
by foreign nationals (i.e., all people who are not citizens or
nationals of the United States). Refer to NMI 1371.3,
"Coordination and Authorization of Foreign Visits to NASA
Facilities," for additional information.
b. Purpose. The following policy and procedure has been
developed from the perspective of the NASA AIS Program by the NASA
Security Office in coordination with the Office of Policy
Coordination and International Relations. It sets forth NASA
guidelines on controlling electronic access by foreign nationals to
NASA computer systems that process sensitive or mission-critical
information.
c Categories. There are two basic categories of foreign
nationals that seek access to NASA automated information systems:
(1) those hired by contractors to perform work tasks in the normal
course of business; and (2) those who seek access pursuant to
international partnership agreements to conduct work on major
multinational projects (e.g., Space Station). Foreign nationals,
under category (1) above, that are hired by contractors in the
normal course of business, need to be investigated and managed much
like other contractor employees. Foreign nationals, under category
(2) above, need to be investigated and managed in a manner
consistent with requirements that are negotiated into international
partnership agreements.
d. Sponsors. Requests for foreign national access to NASA
computer systems must be sponsored by NASA, another or appropriate
U.S. Government agency, or a contractor organization.
e. Submission/Approval of Requests. C-AISM's shall ensure
that appropriate procedures are in place to evaluate requests for
foreign national access. Requests for foreign national access to
NASA computer systems are to be submitted through the appropriate
DPI-AISO (i.e., at the Installation where primary access will
occur) to the Center Security Office for appropriate investigation
and approval. Requests for access by foreign nationals from
designated areas will be reviewed on a case-by-case basis. Refer
to Exhibit 3-7 for additional guidance.
f. Exceptions. Requests for foreign national access which
present unusual concerns for a Center's Security Office should be
coordinated with the NASA Security Office, appropriate HQ Program
Office, and the International Relations Division (Code IP) for
further analysis and concurrence.
(EXHIBIT 3-7. Minimum Information for Foreign National
Access Requests--See hardcopy)
308 CONTINGENCY AND DISASTER RECOVERY PLANNING
a. Definitions. Disaster recovery plans for DPI's and
contingency plans for computer applications shall provide for
minimizing interruptions and reasonable continuity of services if
adverse events occur that prevent normal operations. These
planning activities may be integrated with each other or other
planning activities at the discretion of the C-AISM.
(1) Disaster Recovery Plan. Disaster recovery plans are
documents containing procedures for emergency response, extended
backup operations, and post-disaster recovery should a DPI
experience a partial or total loss of computer and network
resources and physical facilities. The primary objectives of these
plans, in conjunction with computer application contingency plans,
are to provide a reasonable assurance that a DPI can recover from
such incidents, continue to process mission-critical applications
in a degraded mode (i.e., as a minimum, process computer
applications previously identified as most critical), and return to
a normal mode of operation within a reasonable time. Such plans
are a protective measure generally applied based on assessments of
other protective measures already in place, potential risk
exposures, cost and benefits to be derived, and feasibility of
implementation.
(2) Contingency Plans. Contingency plans describe
procedures and identify personnel necessary to respond to abnormal
situations, and ensure that computer application sponsors/owners
can continue to process important applications in the event that
computer support at the primary DPI is interrupted (e.g.,
appropriate automated and/or manual backup capabilities should be
considered). These plans are developed in conjunction with
computer application or data sponsors/owners and maintained at the
primary and backup data processing installation.
b. Plan Content. Contingency and disaster recovery plans
for a DPI should include:
(1) Identifying which applications support
mission-critical functions. This information should be derived
from functional security requirements developed by owners/sponsors.
(2) Potential impacts to the DPI should unnecessary
processing delays occur.
(3) When applications must be back in operation after an
interruption to avoid adversely affecting the critical missions of
the users or the sponsoring/owner organizations. This information
should be derived from functional security requirements developed
by owners/sponsors.
(4) The relative criticality of each application to the
overall mission of the local organization, the Center, HQ Program
Office, or the Federal agency, and establishing priorities to
restore processing support in a logical fashion after an
interruption. The relative ranking of applications should be based
on recommendations from sponsor/owner organizations and approved by
DPI management.
(5) The appropriate amount of documentation. The amount
of documentation detailed in these plans should be commensurate
with the nature of the DPI (e.g., documented in more detail for
large complex DPI's supporting multi-user computer systems and
documented in less detail for small DPI's supporting single-user
computer systems).
(6) Test intervals and providing reasonable assurance
that recovery requirements can be met.
(a) Contingency plans for new applications should
be operationally tested at the supporting DPI during initial system
tests and at time intervals commensurate with the associated risk
of harm or loss that could be experienced. It is the sponsor/owner
organization's responsibility to ensure that a DPI can meet
specified functional security requirements. This includes
identifying and considering alternative processing DPI's or
providing additional funding to enhance protective measures at the
supporting DPI.
(b) Disaster recovery plans should be tested at
least annually using a cost-effective and reasonable approach. For
example, a limited test based on sample test data from the most
critical applications normally provides meaningful results.
(c) Formal written agreements should be established
to ensure that sufficient processing capacity and time will be
available to meet the recovery requirements of computer
applications when backup processing at an alternate DPI is
considered necessary.
(7) Identifying key individuals and developing proper
emergency notification and response procedures.
309 NETWORK AND COMPUTER SECURITY INCIDENT RESPONSE (CSIR)
CAPABILITY
a. Responsibilities.
(1) Each Center is responsible for establishing a
Computer (and Network) Security Incident Response (CSIR)
capability, which is integrated with the Center's Technical Help
Desk facility to provide coverage for local computer systems and
local area networks. The C-AISM will serve as the primary
management point-of-contact and further designate technical support
individuals to serve as technical points-of-contact. C-AISM's will
maintain a listing of all management and technical
points-of-contact at DPI's under their management cognizance.
(2) HQ Program Offices are responsible for establishing
a network security incident response capability for each major
network or communications backbone they manage. The Network
Security Manager (NSM) shall:
(a) Serve as the primary management point of
contact,
(b) Further designate technical support points of
contact, and
(c) Maintain a listing of all contacts.
b. Objectives. This procedure has been developed as a
method for timely reporting of significant computer and network
security incidents, for determining the type of information to be
reported, and for appropriate follow-on activities after initial
notification of an incident. Reports of significant computer and
network security incidents will be used to alert NASA and
appropriate NASA contractor DPI's to computer system
vulnerabilities, unauthorized access to computer systems, and other
problems which could adversely affect any NASA or appropriate NASA
contractor site. Sharing incident information can result in new
vulnerabilities being identified, computer security awareness being
elevated, and risk exposures being minimized. The timely reporting
of significant computer security incidents also serves to alert
NASA management to situations that might affect flight readiness or
receive adverse public attention.
c. Procedure Elements. This procedure provides necessary
steps for reporting significant computer and network security
incidents at DPI's that have implemented (or are in the process of
implementing) the NASA AIS Program. Use of this procedure should
be compatible with incident and emergency response and reporting
procedures that may already be in place.
(1) Immediately after detection of a significant
computer or network security incident (i.e., an incident that could
affect other DPI's under the cognizance of the same Center), the
DPI-AISO must notify the appropriate C-AISM. If it is determined
that the incident could affect other NASA or NASA contractor
installations under the cognizance of the Center, an immediate
notification must be sent to all appropriate technical
points-of-contact. The ultimate objective of this initial notice
is to alert other DPI's to potential problems that may impact them.
The initial notice should provide the following:
(a) A general description of what has occurred.
(b) If appropriate, characterization of
perpetrator('s) thought to be involved (i.e.,
insider, outsider).
(c) What corrective actions are recommended, have
been taken, or are planned.
(2) If the C-AISM determines that the incident is
significant at the Center level (i.e., that it could represent
significant loss, affect mission readiness, affect other Centers,
and/or attract public attention), the C-AISM must:
(a) Immediately notify the NASA AIS Program
Manager and the appropriate IPO-AISM.
(b) Coordinate with all appropriate technical
points-of-contact who support the affected
constituencies (e.g., UNIX, VAX, MS-DOS,
Macintosh, NSI, PSCN, NASCOM, etc.).
(c) Immediately notify other appropriate Center
C-AISM's, who must coordinate with their
affected constituencies.
(3) The C-AISM, in consultation with the Center Security
Office, the Office of Inspector General, the DPI-AISO, and NSM's as
appropriate, must determine what type of support (e.g., technical,
Inspector General, local law enforcement, FBI, legal, physical or
personnel security, classification, and/or public relations) is
required. Names and telephone numbers of persons contacted in
these organizations must be maintained and included in follow-on
reports. Should a classification review determine that an incident
affects a classified environment (and therefore, is itself
classified), all communications between the DPI, Center, Center
Security Office, NASA Security Office, and NASA AIS Program Manager
must be through secure channels. (See Chapter 7.)
(4) After all applicable information has been obtained,
a written follow-on report must be forwarded, through the same NASA
channels, to the NASA AIS Program Manager. This follow-on report
must contain the information shown in Exhibit 3-8.
(5) A copy of these significant automated information
security incident reports must be retained by the C-AISM and
DPI-AISO. The retention period for these records will be
determined by the C-AISM. Factors to be considered in determining
this retention period include the need for availability of this
information during periodic security reviews, risk assessments, and
trend analysis activities.
(6) The NASA AIS Program Manager will serve as the main
point-of-coordination among NASA Center automated information
security management, HQ Program Office automated information
security management, NASA senior management, and external
organizations.
(7) The Center closest to the occurrence of a
significant automated information security incident must assume a
lead role in developing accurate reports of related facts and
coordinating public releases of information with the local Public
Affairs Office, the NASA AIS Program Manager, and the Office of
Public Affairs, Code P.
(EXHIBIT 3-8. Follow-On Incident Report Content
--See hardcopy)
d. Non-duty Hours Considerations. Current listings must be
maintained of emergency situations and designated NASA CSIR
management officials to be notified. The listing must be complete
with after-hours phone numbers and designated alternates for each
official. These procedures should be integrated, as appropriate,
with local procedures for after-hours incident response. Emergency
situations after hours that require immediate HQ involvement should
be directed to the Goddard Space Flight Center (GSFC) Emergency
Console. Calls will then be forwarded to the responsible
management official.
310 CSAT
a. Continuous CSAT. Continuous Computer (and Network)
Security Awareness and Training (CSAT) is required at centers and
DPI's to sustain the effectiveness of the NASA AIS Program.
Employees who understand their responsibilities, the need for
security, and what they must do to promote it are one of the best
safeguards against automated information security incidents.
Therefore, training should be provided on an ongoing basis to
employees and contractors, as appropriate. New employees should
receive awareness training during their initial orientation.
Refresher training should be offered at least annually. Additional
training will be required whenever there are major changes in a
computing environment or the protective measures baseline.
b. Multifaceted Approach. NASA has a multifaceted approach
(e.g., top-down and bottom-up, internal and external sources, etc.)
to CSAT. It is believed that an effective CSAT program must offer
more to personnel than just an hour of classroom training once a
year or a limited selection from NASA-sponsored training
activities. The training should incorporate a variety of
instructional approaches and be appropriate for the target
audience. To this end, NASA sponsors many internal security
conferences, seminars, workshops, and meetings which are considered
part of the overall NASA CSAT Program. NASA encourages personnel
to seek both internal and external CSAT sources to meet specific
job-related needs. Sources available include:
(1) Annual NASA-Specific Conference. The NASA Security
Office sponsors an annual automated information security conference
that is specific to NASA computer/network environments. This
conference provides a forum for and promotes interaction among
(NASA employee and NASA contractor) automated information security
representatives from NASA HQ, centers, and DPI's. It also
facilitates the exchange of technical and management information
related to protecting computer systems and automated information
throughout the NASA community.
(2) Annual C-AISM Working Group Sessions. The NASA
Security Office sponsors at least two C-AISM Working Group Meetings
per year for the purpose of bringing all C-AISM's together to share
current information, solve common problems, and plan future NASA
AIS Program management strategies.
(3) NASA Electronic AIS Bulletin Boards. The Security
Office sponsors NASA bulletin board services on NASAMAIL to share
information related to AIS.
(4) Periodic AIS Articles. Articles on automated
information security are made available on NASAMAIL bulletin
boards. Centers are encouraged to disseminate this information to
cognizant DPI's or extract information to enhance their own
periodic publications that are disseminated to raise security
awareness of current issues.
(5) Ongoing DPI AIS Training. CSAT is required to
sustain the effectiveness of the NASA AIS Program. Flexibility is
given to allow this training to be conducted in a manner that is
cost-effective and appropriate for a DPI. Some options include:
(a) Formal Classroom Training.
(b) Self-Instruction Courses.
(c) Computer-Assisted Instruction (CAI).
Movies (16 mm).
(d) Videotapes.
(e) Newsletters and Bulletins.
(6) Ongoing Training from External Sources. NASA and
NASA contractor personnel are encouraged to evaluate their specific
CSAT needs and seek additional generic and specialized training
from external sources (e.g., OPM, GSA, Department of Agriculture
Graduate School, DOD Computer Institute, National Computer Security
Center, and commercial vendors).
(7) Significant Incident Reporting (Feedback Loop).
Reports of significant incidents are used to alert other Centers
and DPI's to potential threats and other problems that could
adversely affect their operations. Through the sharing of incident
information NASA management can be kept informed, national trends
can be determined, computer security awareness can be elevated, and
potential risk exposures minimized.
(8) Sharing of AIS Tools and Techniques. The NASA AIS
Program has established a network of automated information security
contacts at all organizational levels. Individuals at all levels
are encouraged to establish professional working relationships with
their counterparts for the purpose of improving communications and
sharing effective automated information security tools and
techniques. Such relationships are vital to reduce burden, solve
common automated information security problems, and provide
effective response during significant incident situations. The
NASA Security Office encourages all Centers to continually submit
effective management tools and technical techniques they have
developed for dissemination to other Centers for evaluation and
implementation consideration.
311 PROCUREMENT OF PRODUCTS AND SERVICES
The Office of Procurement (HQ Code H) has primary
responsibility for developing policy and guidance related to NASA
procurements. The following guidance has been developed by the
NASA Security Office from the NASA AIS Program perspective in
coordination with the Office of Procurement.
a. Introduction. Functional security requirements must be
developed by sponsors/owners to integrate appropriate security
protective measures into hardware, software, telecommunications, or
supporting contractor services. Also, detailed technical security
specifications must be developed by designers. These requirements
(e.g., risk assessment, technical hardware/software measures,
design reviews, system tests, certification prior to operational
use, personnel screening, CSAT) must be included in technical
specifications and solicitations/contracts.
b. NASA Contracting Environment. Due to the nature of NASA
operations, NASA has virtually every type of contractual situation
for the acquisition of computer/network products and related
support services. Because of the diverse range of procurement and
contractual situations and the degree of control management that
may exist between NASA and any given contractor, a reasonable
approach must be taken. Procurement and contractual situations
must be evaluated on a case-by-case basis in order to avoid
imposing unnecessary constraints on contractors that are not under
the direct management of NASA.
c. Project Manager Responsibilities. The DPI management
official (e.g., the Project Manager or the Contracting Officer's
Technical Representative (COTR)) is responsible for assuring that
appropriate functional security requirements, technical security
specifications, and methods for evaluating security adequacy are
included in solicitation documents.
d. Sponsoring Organization Responsibilities. Functional
security requirements and technical security specifications shall
be developed and approved by sponsors of the acquisition and
reviewed by the designated DPI-AISO. General guidance for some
types of functional security requirements are included in GSA's
FIRMR. Other DPI-specific requirements will have to be developed
based on the protective techniques selected as the result of a risk
assessment and further guidance, which may be provided by NASA
procurement offices, GSA, and NIST. To the extent feasible,
functional security requirements should be stated in functional
terms (i.e., "what" is needed) relative to security objectives.
This will permit the DPI to benefit from new technology or an
innovative application of existing technology.
e. Contracting Officer Responsibilities. For the
procurement of computing resources or related support services,
contracting officers shall:
(1) Ensure that no action is taken on a request for
proposal or procurement for computing resources or related support
services unless appropriate functional security requirements and
specifications are included in accordance with established DPI
procedures.
(2) Ensure that NASA technical proposal instructions
include a statement requiring a detailed outline and demonstration
of the offeror's automated information security capabilities that
comply with the functional security requirements of the
solicitation and contract.
(3) Include a clause in solicitations and contracts
requiring the contractor to comply with the functional security
requirements set forth in applicable parts of NMI 2410.7 and this
Handbook.
f. Evaluating Security Capabilities. Proposal evaluators
shall review the offeror's proposed approach and witness live test
demonstrations, as appropriate, to evaluate the adequacy of
protective measures and the capability of the offeror to meet the
functional security requirements and technical security
specifications contained in the solicitation and contract.
Exceptions to live test demonstrations will be considered in cases
where it may be determined to be cost prohibitive. Proposal
evaluators shall then certify, if appropriate, the adequacy of the
offeror's compliance. This certification shall be obtained by the
contracting officer before proceeding with the procurement.
g. Contract Administration. C-AISM's and DPI-AISO's shall
conduct in coordination with their Contracting Officer, COTR's,
Project Managers, periodic reviews of contracts in progress to
ensure continued compliance with functional security requirements.
All instances of noncompliance shall be reported to the contracting
officer or designated representative.
h. Requirements for Contractor-Operated DPI's. As indicated
in paragraph 102, the provisions of this Handbook apply to support
contractor organizations as provided by law and/or contract and as
implemented by the appropriate contracting officer. The Center and
DPI management processes should assure that, in contracts for
equipment, software, the operation of DPI's, or related services:
(1) Appropriate functional security requirements and
specifications are included in procurement specifications and/or
statements of work.
(2) Functional security requirements and technical
security specifications are reasonably sufficient for the intended
application; that they comply with established DPI procedures; and
that protective provisions at the acquired DPI are adequate and
functioning properly prior to operational use.
(3) Resource-sharing service agreements provide for
compliance with applicable provisions of NMI 2410.7 and this
Handbook by responsible management officials at the acquired
processing DPI.
CHAPTER 4. AUTOMATED INFORMATION CATEGORIES
AND SENSITIVITY/CRITICALITY LEVELS
400 INTRODUCTION
There are two important concepts covered in this Chapter. The
first concept is that there are reasonably definable "categories"
of information, each with its own unique management and security
concerns. The second is that once automated information has been
categorized, it is necessary to determine a relative sensitivity
and/or criticality level for that information, so appropriate
protective measures can be considered and a protective measures
baseline established for supporting software, hardware, and
telecommunication systems. The technical depth of a risk analysis,
type and frequency of security awareness training, and the
requirement for incident reporting are all examples of areas where
increasing sensitivity level should cause increased emphasis and
resource expenditures.
a. Information Categories. Information categories are
simply logical groupings of information that are based on a legal
requirement, a policy requirement, or a management concern to treat
a category of information in a particular way. An understanding of
these categories is the first step in determining the nature of the
sensitivity and/or criticality of automated information and the
types of protective measures that may be appropriate when the
information is processed by a computer system or transmitted over
a telecommunications network. In order to assist application
sponsors and information owners with the sometimes subjective task
of identifying the nature of sensitive automated information and
identifying automated information that supports mission-critical
functions, NASA has developed a method for categorizing automated
information (as illustrated in Exhibit 4-1). All NASA automated
information falls into one or more of these categories.
b. Sensitivity/Criticality Levels. NASA has established
four hierarchical "levels" of sensitivity/criticality to assist
application sponsors, information owners, system designers, and
system developers (see Exhibit 4-2). All NASA automated
information falls into one of these four sensitivity/criticality
levels, in which each level has a generic set of protective measure
considerations (as illustrated in Exhibit 4-3). The following
paragraphs describe the 13 automated information categories, the
four sensitivity/criticality levels, and the protective measure
considerations for each sensitivity or criticality level.
(EXHIBIT 4-1. NASA Automated Information Categories
--See hardcopy)
(EXHIBIT 4-2. NASA Unclassified Automated Information
Sensitivity/Criticality Levels--See hardcopy)
401 INFORMATION CATEGORIES
a. Statutes. As shown in Exhibit 4-1, NASA has defined 13
categories of information to facilitate managing automated
information. The predominant statutory bases for these categories
are:
(1) Federal Managers Financial Integrity Act of 1982
(Public Law 97-255; 31 U.S.C 66a).
(2) Paperwork Reduction Act of 1980 (Public Law 96-511;
44 U.S.C. 3501).
(3) Freedom of Information Act of 1974 (Public Law
93-502; 5 U.S.C. 552b).
(4) Privacy Act of 1974 (Public Law 93-579; 5 U.S.C.
552a).
b. Derivations. Categories 1-5 are derived from the
statutes indicated above in subparagraph a and apply to all Federal
agencies. Category 6 is derived from guidance in National Security
Decision Directives. Categories 7-12 are derived from assorted
Federal directives. Category 13 is derived from Presidential
Executive Order (EO) 12356. The categories are defined in the
following paragraphs.
(1) Information About Persons (Category 1). This
category includes information related to personnel, medical, and
similar information. All information covered by the Privacy Act of
1974 falls into this category.
(2) Financial, Commercial, and Trade Secret Information
(Category 2). Category 2 includes information from applications
such as financial, procurement, inventory, and decision-making. It
also includes commercial information received in confidence, trade
secrets, and proprietary information.
(3) NASA Internal Operations (Category 3). This incudes
information related to the internal operations of NASA. This
category includes certain personnel rules, bargaining positions,
advance information concerning procurement actions, etc.
(4) Investigatory, Intelligence-Related, and Security
Information (Category 4). This category includes information
related to police intelligence and/or law enforcement
investigations or informants. It also includes some automated
information security information (such as detailed security plans
for the protection of systems and specific automation
vulnerabilities). Note that this category does not include general
plans, policies, or requirements, nor does it include Federal or
national security intelligence information.
(EXHIBIT 4-3. Protective Measure Considerations
(Parts 1 & 2)--See hardcopy)
(5) Other Federal Agency Information (Category 5).
Other Federal agency information includes information whose
gathering and/or maintenance is required by statute or another
Federal agency. Information in this category is not the primary
responsibility of NASA. For example, this category would include
DOD or Department of Energy (DOE) information processed in NASA
computers for DOD or DOE, respectively.
(6) Unclassified National Security-Related Information
(Category 6). This category includes national defense and Federal
intelligence-related information subject to the policy, procedural,
and protective requirements established by the National
Telecommunications and Information Systems Security Committee
(NTISSC). This information may require protection in addition to
that required under NASA guidance. This information is not
classifiable under EO 12356, but requires protection in accordance
with NTISSC policy.
(7) National Resource System Information (Category 7).
This is information related to the protection of a national
resource (such as the Space Shuttle or the Space Station Freedom.)
(8) Mission-Critical Information (Category 8). This is
information that has been designated as critical to the NASA
mission.
(9) Operational Information (Category 9). This is
information that requires protection during operations. It is
usually time-critical information.
(10) Life Critical Information (Category 10). This is
information critical to life support systems (i.e., information
whose inaccuracy, loss or alteration reasonably could be expected
to result in loss of life).
(11) High or New Technology Information (Category 11).
This is information relating to high or new technology prohibited
from disclosure to certain foreign governments, or may require an
export license from the Department of State and/or the Department
of Commerce.
(12) Other Unclassified Information (Category 12). This
is any information that does not logically fall into one or more of
the 11 categories and that is not classified for national security
purposes. Use of this category should be very rare.
(13) Classified National Security-Related Information
(Category 13). This is information classified for national
security purposes (i.e., under EO 12356). All automated
information security actions related to this category are covered
in Chapter 7 of this Handbook.
402 SENSITIVITY/CRITICALITY LEVELS
a. Introduction. The sensitivity levels defined in Exhibit
4-2 are based on the amount of harm or loss that could be
experienced from an adverse event that affects the availability,
integrity, or confidentiality of NASA computing or information
resources. A hypothetical relationship between the automated
information categories and sensitivity/criticality levels is
presented in Exhibit 4-4 for general guidance only. Detailed
analyses should be conducted by information sponsors and owners, on
a case-by-case basis, and should be reviewed by a DPI-AISO before
making any final sensitivity and/or criticality determinations.
The sensitivity/criticality of automated information should also be
periodically re-evaluated, as the influencing factors change.
b. Automated Information and Applications. The sensitivity
and/or criticality of automated information is determined by
applicable sponsors and information owners. A sensitivity and/or
criticality level should also be assigned to each automated
application, based on the sensitivity and/or criticality of the
automated information the application will process. The
sensitivity/criticality level of an automated application is at
least as high as the most sensitive/critical automated information
that will be processed by that application. The internal formulas
or the information editing criteria in the application source code
could raise the sensitivity/criticality level of the application
even higher than the information it handles.
c. Computer Systems. DPI-AISO's should assign each NASA
computer a sensitivity/criticality level, based on the
sensitivity/criticality level of the applications processed on each
computer system. Each computer system should have a
sensitivity/criticality level that is at least as high as that of
the most sensitive/critical application processed. However,
significant replacement costs, unusually large numbers of
applications supported, and/or an unusually large volume of
information processed can raise the sensitivity/criticality level
of a computer system even higher than the sensitivity/criticality
level of the most sensitive/critical application processed on that
system.
403 PROTECTIVE MEASURE BASELINE CONSIDERATIONS
Protective measure considerations for each sensitivity and/or
criticality level are presented as general guidance in the
following paragraphs. The selection or omission of protective
measures should be justified and based on the results of a risk
assessment. DPI's may elect to increase their protection, add
additional protective measures, or establish a mandatory minimum
protective measures baseline, as they deem appropriate. (See
Exhibit 4-3. Also, see paragraph 304.)
(EXHIBIT 4-4. Categories and Sensitivities--See hardcopy)
a. Sensitivity/Criticality Level 0. Sensitivity level 0
systems should provide for adequate protection of information
through the following protective measures:
(1) Access Protection. Whenever a single computer
system is used by more than one person (whether or not that use is
concurrent), physical, procedural, and technical protective
measures should be provided that allow for identification and
authentication of individual users and to prevent access by
unauthorized persons.
(2) Configuration Management. All files should be
cataloged and there should be licenses for all software used. All
licensed software should be registered as requested or required by
the author/vendor prior to operational use. Furthermore, software
should be tested and determined to be reasonably safe (free of
malicious design/code) for use in its intended environment.
(3) Back-up Copies of Software. At least one generation
of backup software should be maintained. Backups of changed
information files should also be maintained.
(4) Physical Access. Physical security (such as, door
locks and cable lock's) should be required when the automated
information resources are unattended.
(5) Personnel Security. All users of computer systems
should be trained in the automated applications they use, proper
software handling procedures, and basic automated information
security practices.
(6) Environmental Measures. Proper environmental
measures (to minimize the impacts of dust, water, temperature,
humidity, and ventilation) should be required. Also, power surge
protection should be required for hardware.
(7) Storage Media. Proper storage bins or containers
should be required for information storage media (e.g., disks,
tapes, etc.).
(8) Communications. The communications links connecting
a computer system to other systems, networks, workstations, or
terminals must be approved by responsible management prior to the
implementation of the connection.
b. Sensitivity/Criticality Level 1. Sensitivity level 1
systems should provide all Sensitivity level 0 protective measures
as well as:
(1) Access Protection. Physical, procedural, or
technical protective measures should be provided that allow
physical and/or logical management of authorization and access to
the system and processing resources.
(2) Configuration Management. A configuration
management process should be developed and maintained that monitors
changes to any security-related and sensitive software, hardware,
or procedure for the system.
(3) Back-Up Copies of Software. At least two
generations of back-ups should be maintained, with the oldest
generation being stored at a location other than the immediate
vicinity of the system.
(4) Physical Access. Systems should be physically
protected to prevent unauthorized access, theft, or destruction.
Physical key locks should be used on microcomputer fixed/hard
disks. Separate physical locks should also be used to prevent
hardware theft.
(5) Network Access. Passwords should be required for
access to or from any network. Use of software that provides error
checking and some error correction capability should be required
when performing file transfers using networks.
(6) Contingency and Disaster Recovery Plans.
Contingency Plans for applications and Disaster Recovery Plans for
computer installations should be developed to provide for minimal
interruptions and reasonable continuity of services. These plans
should be developed in accordance with Paragraph 308.
c. Sensitivity/Criticality Level 2. Sensitivity level 2
systems should implement the protective measures required for
sensitivity levels 0 and 1, in addition to the following:
(1) Access Protective. Physical, procedural, and
technical protective measures should be provided that allow for:
(a) Restriction of the functional capabilities of
individual users.
(b) Ability for individual users to manage access
(e.g., read, modify, or delete) by other
individual users to their information and
applications.
(c) Consideration of encryption of stored data.
(2) Audit Trails. The system should provide for the
generation of journals, or audit logs, of accesses to the system
and to information and applications at the individual user level.
Access to journals and audit logs should be restricted to a
well-defined group of users authorized by DPI management.
(3) Communications. All communication paths for the
system should be described, and a well-defined path should exist
for the initial user identification and authentication processes.
Encryption of data to be transmitted should be evaluated by
sponsors/owners.
(4) Network Access. Written consent, identifying other
network nodes authorized to access the system node, should be
obtained from responsible DPI management prior to enabling any
network connection or interconnection.
(5) Logoff/Time Out Features. The system should logoff
work stations that have not been in communication with the CPU for
a period of time determined by DPI management.
(6) Data Base Management Systems (DBMS's). DBMS's
should provide for the integrity, confidentiality, and availability
of all information resident in the data base. Individuals
responsible for data base administration are responsible for
ensuring that information owners are informed of and concur in all
defined access privileges to and uses of their information.
d. Sensitivity/Criticality Level 3. Sensitivity level 3
systems must implement the minimum protective measures required for
sensitivity levels 0, 1, and 2, in addition to the following:
(1) Access Protective Measures. Access protective
measures must be provided that can at all times restrict and log
individual user access by system resource, application, and
information files. Authorization to access system resources,
applications, and information files must be confirmed by the
information owners and shall be reconfirmed periodically but at
least every 6 months.
(2) Information and Application Labels. Sensitivity
level indicators must be associated with computing resources,
applications, and information while Level 3 sensitive information
is being processed.
(3) Configuration Management. Protective measures must
be in place to allow appropriate data bases to be stored off-line.
(4) Communications. There shall be no uncontrolled
dial-up access or unauthorized connections to external networks.
Management decisions not to use data encryption should be
justified. Threats and risks associated with connections to
wide-area and/or internationally linked networks shall be evaluated
by sponsors/owners, and the resulting management decisions should
be justified.
CHAPTER 5. AIS PLANNING
500 INTRODUCTION
This Chapter presents details of the required automated
information security planning activities. Specifically, it covers
the NASA AIS Program Plan, HQ Program Office Automated Information
Security Plans (PO-AISPs), HQ Institutional Program Office
Automated Information Security Plans (IPO-AISPs), Center Automated
Information Security Plans (C-AISPs), DPI AIS Plans (DPI-AISPs),
and Contingency Plans. The Computer Security Act of 1987 requires
AIS planning at the system level. This chapter prescribes AIS
plans in addition to those required by the Act. A discussion of
how NASA complies with external requests for planning information
is found in paragraph 505.
501 HEADQUARTERS AIS PLANNING
a. NASA AIS Program Plan.
(1) Scope. The NASA AIS Program Plan is Agencywide in
scope. It does not provide detailed planning information for any
particular PO, IPO, Center, computer system, or automated
application.
(2) Purpose. The purpose of the NASA AIS Program Plan
is to document the overall NASA AIS Program goal, objectives,
directions, and strategies for the NASA AIS Program Manager.
(3) Manager. The NASA AIS Program Manager is
responsible for developing, implementing, monitoring, and
evaluating this plan.
(4) Publication/Distribution. The NASA AIS Program Plan
shall be revised annually and integrated into the Agency 5-year IRM
Plan.
(5) Period Covered. The NASA AIS Program Plan addresses
automated information security accomplishments for the past fiscal
year, AIS activities for the current budget year, and planned
strategies for the next budget year. Thus, it covers a total of 3
years.
(6) Relationship with Other Plans.
(a) The NASA AIS Program Plan provides a basis for
responding to requests for NASA AIS Planning information from
national level organizations such as OMB and GSA. PO/IPO-AISP's,
C-AISP's, and
DPI-AISP's must operate within the NASA AIS Program goal and
objectives, as defined in the NASA AIS Program Plan.
(b) Major security activities reported in the PO,
IPO, and Center automated information security plans will be
reflected in the NASA AIS Program Plan.
(7) Content and Format. The content and format for the
NASA AIS Program Plan is shown in Exhibit 5-1.
b. Headquarters Program Office/Institutional Program Office
AIS Plans (PO/IPO-AISP's).
(1) Scope. A PO-AISP covers a major Agency-wide
program activity which uses automa