Military reference books and manuals (2009-2023, Volume 1) - page 13
UNCLASSIFIED//FOR OFFICIAL USE ONLY
v
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
6.3.7 (U) REMOVABLE INFORMATION STORAGE MEDIA
39
6.3.7.1 (U) Label Placement
40
6.3.7.2 (U) Data Descriptor Label
40
6.3.7.3 (U) Classification Markings
40
6.3.7.4 (U) Control and Accounting of Media
40
6.3.7.4.1 (U) Information Storage Media Control
40
6.3.7.4.2 (U) Inspections
40
6.3.7.4.3 (U) Control Procedures
40
6.3.7.4.4 (U) Other Categories of Storage Media
41
6.3.8 (U) HARDWARE LABELING REQUIREMENTS
41
6.3.9 (U) SECURITY TRAINING REQUIREMENTS
41
6.3.9.1 (U) Security Awareness and Training Program
41
6.3.9.1.1 (U) Awareness Level
41
6.3.9.1.2 (U) Performance Level
42
6.3.9.1.3 (U) General Users training
42
6.3.10 (U) Destruction of Media
42
6.3.11 (U) Information Transfer and Accounting Procedures
42
CHAPTER 7 - SECURITY GUIDELINES FOR THE PRIVILEGED USER
43
7.1 (U) PURPOSE
43
7.2 (U) SCOPE
43
7.3 (U) SECURITY TRAINING
43
7.3.1 (U) PRIVILEGED USER TRAINING
43
7.3.2 (U) SECURITY AWARENESS AND TRAINING PROGRAM
44
7.3.2.1 (U) Awareness Level
44
7.3.3.2 (U) Performance Level
44
7.4 (U) LEAST PRIVILEGE IMPLEMENTATION
44
7.5 (U) SCI SYSTEM SECURITY PROCEDURES
44
7.5.1 (U) IDENTIFICATION AND AUTHENTICATION REQUIREMENTS
44
7.5.1.1 (U) Documenting USERIDs and Passwords
44
7.5.1.2. (U) USERID and Password Issuing Authority and Accountability
45
7.5.1.3 (U) Supervisor Authorization
45
7.5.1.4 (U) Access Requirements Validation
45
7.5.1.5 (U) Account Management
45
7.5.1.6 (U) Tactical/Deployable Use of group accounts
45
7.5.2 (U) SYSTEM ACCESS AND REMOVAL PROCEDURES
46
7.5.3 (U) AUDIT TRAIL REQUIREMENTS
46
7.5.3.1 (U) Automated Audit Trail Information Requirements
46
7.5.3.2 (U) Manual Audit Trail Implementation
47
7.5.3.3 (U) Products of Audit Trail Information
47
7.5.3.4 (U) Audit Trail Checks and Reviews
48
7.5.3.5 (U) Audit Trail Records Retention
48
7.5.3.6 (U) Tactical/Deployable Audit Process Requirements
48
7.5.3.6.1 (U) Tactical/Deployable Audit log requirements
48
7.5.4 (U) AUTOMATIC LOG-OUT REQUIREMENTS
48
7.5.5 (U) LIMITED ACCESS ATTEMPTS
48
7.5.6 (U) USE OF WINDOWS SCREEN LOCKS
49
7.5.6.1 (U) Tactical/Deployable Protection for Information against unattended operation
49
7.5.7 (U) TESTING, STRAINING, AND HACKING
49
7.5.8 (U) WARNING BANNERS
49
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
vi
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
7.5.9 (U) NETWORK MONITORING
49
7.5.9.1 (U) Maintenance Monitoring
49
7.5.9.2 (U) Targeted Monitoring
50
CHAPTER 8 - INFORMATION SYSTEMS (IS) INCIDENT REPORTING
51
8.1 (U) PURPOSE
51
8.2 (U) SCOPE
51
8.3 (U) PROCEDURES
51
8.3.1 (U) REPORTING PROCESS
51
8.3.2 (U) TYPES OF IS INCIDENTS AND REPORTS
51
8.3.3 (U) REPORTING INCIDENTS
52
8.3.4 (U) REPORT FORMAT AND CONTENT
53
FIGURE 8.1 (U) SAMPLE INCIDENT REPORT MESSAGE
54
8.3.5 (U) FOLLOW-ON ACTION
54
CHAPTER 9 - INFORMATION SYSTEM (IS) MONITORING ACTIVITIES
55
9.1 (U) PURPOSE
55
9.2 (U) SCOPE
55
9.3 (U) PROCEDURES
55
9.3.1 (U) IS WARNING BANNER
55
FIGURE 9.1. (U) INFORMATION SYSTEM WARNING BANNER.
56
9.3.2 (U) WARNING LABELS
56
FIGURE 9.2. (U) WARNING LABEL.
56
9.3.3 (U) ACTION TO BE TAKEN BEFORE MONITORING
56
9.3.4 (U) REVIEW SYSTEM SPECIFIC SECURITY FEATURES
57
TABLE 9.1. (U) RECOMMENDED INCIDENT RESPONSE ACTIONS
57
TABLE 9.2. (U) SAMPLE MONITORING INVESTIGATION QUESTIONS
57
CHAPTER 10 - MALICIOUS CODE PREVENTION
59
10.1 (U) PURPOSE
59
10.2 (U) SCOPE
59
10.3 (U) DEFINITIONS
59
10.3.1 (U) MALICIOUS CODE
59
10.3.2 (U) MOBILE CODE
59
10.3.3 (U) MALICIOUS MOBILE CODE
59
10.3.4 (U) MOBILE CODE TECHNOLOGIES
60
10.3.4.1 (U) Red Mobile Code
60
10.3.4.2 (U) Yellow Mobile Code
60
10.3.4.3 (U) Green Mobile Code
61
10.3.4.4 (U) Emerging Mobile Code Technologies
61
10.3.4.5 (U) Exempt technologies
61
10.3.5 (U) TRUSTED SOURCE
61
10.3.6 (U) SCREENING
62
10.4 (U) PROCEDURES
62
10.4.1 (U) PREVENTIVE PROCEDURES
62
10.4.2 (U) MALICIOUS CODE DETECTION
62
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
vii
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
10.5 (U) MALICIOUS CODE SECURITY REQUIREMENTS
63
10.5.1 (U) PREVENTATIVE STEPS TO BE TAKEN
63
CHAPTER 11 - SOFTWARE
64
11.1 (U) PURPOSE
64
11.2 (U) DEFINITION
64
11.3 (U) SCOPE
64
11.4 (U) PROCEDURES FOR SOFTWARE AUTHORIZATION
64
11.5 (U) LOW RISK SOFTWARE
64
11.6 (U) HIGH RISK SOFTWARE
64
11.6.1 (U) PUBLIC DOMAIN SOFTWARE
65
11.6.2 (U) DEMONSTRATION SOFTWARE AND MEDIA
65
11.6.3 (U) EMBEDDED SOFTWARE
65
11.6.4 (U) UNAUTHORIZED SOFTWARE
65
11.6.5 (U) IA SOFTWARE AND SECURITY TOOLS
65
CHAPTER 12 - INFORMATION STORAGE MEDIA
66
12.1 (U) PURPOSE
66
12.2 (U) SCOPE
66
12.3 (U) CONTROL AND ACCOUNTING PROCEDURES
66
12.3.1 (U) INFORMATION STORAGE MEDIA CONTROL
66
12.3.1.1 (U) Inspections
66
12.3.1.2 (U) Control Procedures
66
12.3.1.3 (U) Other Categories of Storage Media
66
12.3.2 (U) AUDITS AND REPORTS
67
12.3.3 (U) DESTRUCTION OF MEDIA
67
12.4 (U) MEDIA LABELING PROCEDURES
67
12.4.1 (U) INFORMATION STORAGE MEDIA
67
FIGURE 12.1 - SF 700 SERIES LABELS
68
12.4.1.1 (U) Label Placement
68
12.4.1.2 (U) Data Descriptor Label
68
12.4.2 (U) Tactical/Deployable Labeling media and hardware components
69
12.4.3 (U) CLASSIFICATION MARKINGS
69
CHAPTER 13 - INFORMATION SYSTEMS (IS) MAINTENANCE PROCEDURES
70
13.1 (U) PURPOSE
70
13.2 (U) SCOPE
70
13.3 (U) PROCEDURES
70
13.3.1 (U) MAINTENANCE PERSONNEL
70
13.3.1.1 (U) Maintenance by Cleared Personnel
70
13.3.1.2 (U) Maintenance by Uncleared (or Lower-Cleared) Personnel
70
13.3.2 (U) GENERAL MAINTENANCE REQUIREMENTS
71
13.3.2.1 (U) Maintenance Log
71
13.3.2.2 (U) Location of Maintenance
71
13.3.2.3 (U) Removal of Systems/Components
71
13.3.2.4 (U) Use of Network Analyzers
71
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
viii
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
13.3.2.5 (U) Use of Diagnostics
71
13.3.2.6 (U) Introduction of Maintenance Equipment into a SCIF
71
13.3.3 (U) MAINTENANCE AND SYSTEM SECURITY
72
13.3.4 (U) REMOTE MAINTENANCE REQUIREMENTS/CONSIDERATIONS
72
13.3.4.1 (U) Maintenance Performed with the same Level of Security
72
13.3.4.2 (U) Maintenance Performed with a different Level of Security
72
13.3.4.3 (U) Initiating and Terminating Remote Access
72
13.3.4.4 (U) Keystroke Monitoring Requirements
72
13.3.5 (U) LIFE CYCLE MAINTENANCE
73
CHAPTER 14 - DIGITAL AND MULTI-FUNCTION DEVICES (COPY/PRINT/SCAN/FAX)
74
14.1 (U) PURPOSE
74
14.3 (U) POLICY
74
14.4 (U) PROCEDURES
75
14.4.1 (U) FAX CAPABILITIES
76
14.5 (U) RESPONSIBILITIES
76
14.5.1 (U) THE DAA REPRESENTATIVE SHALL:
76
14.5.2 (U) ISSOS AND/OR INFORMATION SYSTEMS SECURITY MANAGERS SHALL:
76
14.5.3 (U) USERS SHALL:
76
CHAPTER 15 - PORTABLE ELECTRONIC DEVICES
77
15.1 (U) PURPOSE
77
15.3 (U) RISK
77
15.3.1 (U) CLASSIFIED INFORMATION
77
15.4 (U) PROCEDURES
77
15.4.1 (U) APPROVAL REQUIREMENTS
77
15.4.1.1 (U) Personal PEDs
78
15.4.1.2 (U) Government Owned PEDs
78
15.4.1.3 (U) Contractor Business Owned PEDs
78
15.4.2 (U) HANDLING PROCEDURES
78
15.4.2.1 (U) Standard Operating Procedure (SOP) Development
79
15.4.2.2 (U) SOP Approval
79
CHAPTER 16 - SECURITY PROCEDURES FOR INFORMATION SYSTEMS (IS) AND FACSIMILE
(FAX) USE OF THE PUBLIC TELEPHONE NETWORK
80
16.1 (U) PURPOSE
80
16.2 (U) SCOPE
80
16.3 (U) PROCEDURES
80
16.3.1 (U) FAX CONNECTIVITY
80
16.3.1.1 (U) FAX Approval
80
16.3.1.1.1 (U) Unclassified FAX.
81
16.3.1.1.2 (U) Classified FAX
81
16.3.1.1.3 (U) Non-Standard Secure Fax
81
16.3.1.1.4 (U) Procedures
82
16.3.1.1.5 (U) FAX Accreditation
83
16.3.2 (U) COMPUTER-FAX/MODEM CONNECTIVITY
83
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
ix
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
16.3.2.1 (U) Unclassified Computer-FAX/Modem Accreditation Approval
83
16.3.2.2 (U) Physical Disconnect of Unclassified Computer-FAX/Modems
83
16.3.3 (U) COMPUTER-MODEM CONNECTIVITY
83
16.3.3.1 (U) Unclassified Computer-Modem Connectivity
83
16.3.3.1.1 (U) ISP Connectivity
83
16.3.3.1.2 (U) IS to IS Connectivity
83
16.3.3.2 (U) Classified Computer-Modem Connectivity
84
16.3.3.3 (U) Classified Computer-STU-III/STE Data Port Connectivity
84
CHAPTER 17 - INTERCONNECTING INFORMATION SYSTEMS
86
17.1 (U) PURPOSE
86
17.2 (U) SCOPE
86
17.3 (U) DISCUSSION
86
17.3.1 (U) INTERCONNECTED INFORMATION SYSTEMS
86
17.3.2 (U) INTER-DOMAIN CONNECTIONS
86
17.3.3 (U) CONTROLLED INTERFACE
87
17.3.3.1 (U) One-Way Connections
87
17.3.3.1.1 (U) Equal Classification Connections
87
17.3.3.1.2 (U) Low-to-High Connections
87
17.3.3.1.3 (U) High-to-Low Connections
87
17.3.3.1.4 (U) Other Unequal Classification Level Connections
87
17.3.3.2 (U) Dual-Direction Connections
88
17.3.3.3 (U) Multi-Domain Connections
88
17.3.4 (U) REVIEW PROCEDURES
88
17.3.4.1 (U) Reliable Human Review
88
17.3.4.2 (U) Automated Review
88
17.3.5 (U) FOREIGN NATIONAL ACCESS TO SYSTEMS PROCESSING CLASSIFIED INFORMATION
88
CHAPTER 18 - INFORMATION TRANSFER AND ACCOUNTING PROCEDURES
90
18.1 (U) PURPOSE
90
18.2 (U) SCOPE
90
18.3 (U) PROCEDURES
90
18.3.1 (U) RELIABLE HUMAN REVIEW OF DATA
90
18.3.2 (U) MEDIA TRANSFERS IN/OUT OF AN ORGANIZATION
91
18.3.3 (U) DISPOSITION OF EXCESS OR OBSOLETE COTS SOFTWARE
91
18.3.4 (U) HIGH-TO-LOW DATA TRANSFER BY MEDIA
91
18.3.4.1 (U) PL-3 and Below Functionality
92
18.3.4.2 (U) PL-4 and Above Functionality
92
18.3.5 (U) LOW-TO-HIGH DATA TRANSFER BY MEDIA
92
18.3.6 (U) DEMONSTRATION SOFTWARE
93
CHAPTER 19 - MULTI-POSITION SWITCHES
94
19.1 (U) PURPOSE
94
19.2 (U) SCOPE
94
19.3 (U) POLICY
94
19.4 (U) RESPONSIBILITIES
94
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
x
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
19.4.1 (U) DAA REP
94
19.4.2 (U) ISSM
95
19.4.3 (U) ISSO/SYSTEM ADMINISTRATOR
95
19.4.4 (U) USER
95
19.5 (U) IS REQUIREMENTS
95
19.6 (U) PROCEDURES FOR LOGON/SWITCHING BETWEEN SYSTEMS
96
19.6 1 (U) LOGGING ON TO SYSTEMS
96
19.6.2 (U) SWITCHING BETWEEN SYSTEMS
97
19.7 (U) KVM SWITCH USER AGREEMENT
97
FIGURE 19.1 (U) KVM SWITCH USER AGREEMENT FORM.
98
CHAPTER 20 - COLLABORATIVE COMPUTING
99
20.1 (U) PURPOSE
99
20.2 (U) SCOPE
99
20.3 (U) IMPLEMENTATION PROCEDURES
99
20.3.1 (U) COLLABORATIVE COMPUTING ACTIVATION
99
20.3.2 (U) VIDEO CAMERAS/MICROPHONES CONNECTED TO SCI INFORMATION SYSTEMS
100
20.3.3 (U) VIDEO CAMERAS/MICROPHONES CONNECTED TO COLLATERAL/UNCLASSIFIED INFORMATION
SYSTEMS
100
20.3.4 (U) COLLABORATIVE COMPUTING APPROVAL
100
20.3.5 (U) RESPONSIBILITIES
100
CHAPTER 21 - CLEARING, SANITIZING, AND RELEASING COMPUTER COMPONENTS
102
21.1 (U) PURPOSE
102
21.2 (U) SCOPE
102
21.3 (U) RESPONSIBILITIES
102
21.4 (U) REVIEW OF TERMS
102
21.5 (U) PROCEDURES
103
21.5.1 (U) OVERWRITING MEDIA
103
21.5.2 (U) DEGAUSSING MEDIA
103
21.5.2.1 Types of Degausser
103
21.5.2.2 (U) Degausser Requirements
104
21.5.2.3 (U) Use of a Degausser
104
21.5.3 (U) SANITIZING MEDIA
104
TABLE 21.1. (U) SANITIZING DATA STORAGE MEDIA
104
TABLE 21.2. (U) SANITIZING SYSTEM COMPONENTS
105
21.5.4 (U) DESTROYING MEDIA
106
21.5.4.1 (U) Expendable Item Destruction
106
21.5.4.1.1 (U) Shipping Instructions
106
21.5.4.2 (U) Destruction of Hard Disks
107
21.5.4.2.1 (U) Shipping Instructions
107
21.5.4.3 (U) Destruction of Disk Packs
108
21.5.4.4 (U) Optical Storage Media Destruction
108
21.5.5 (U) MALFUNCTIONING MEDIA
108
21.5.6 (U) RELEASE OF MEMORY COMPONENTS AND BOARDS
108
21.5.6.1 (U) Volatile Memory Components
109
21.5.6.2 (U) Non-volatile Memory Components
109
21.5.6.3 (U) Other Non-volatile Media
109
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
xi
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
21.5.6.3.1 (U) Visual Displays
109
21.5.6.3.2 (U) Printer Platens and Ribbons
109
21.5.6.3.3 (U) Laser Printer Drums, Belts, and Cartridges
109
21.5.7 (U) CLEARING SYSTEMS FOR PERIODS PROCESSING
110
21.5.8 (U) RELEASE OF SYSTEMS AND COMPONENTS
110
21.5.8.1 (U) DOCUMENTING IS RELEASE OR DISPOSAL
111
FIGURE 21.1. (U) SAMPLE NSACSS FORM G6522
111
CHAPTER 22 - INFORMATION SYSTEMS (IS) AND NETWORK SECURITY SELF-INSPECTION AID
112
22.1 (U) PURPOSE
112
22.2 (U) SCOPE
112
22.3 (U) APPLICABILITY
112
22.4 (U) PROCEDURES
112
TABLE 22.1 (U) IS AND NETWORK SECURITY SELF-INSPECTION CHECKLIST
113
APPENDIX A - REFERENCES
123
PUBLIC LAWS
123
EXECUTIVE ORDERS
123
NATIONAL PUBLICATIONS
123
DEPARTMENT OF DEFENSE (DoD) PUBLICATIONS
124
DEFENSE INTELLIGENCE AGENCY (DIA) PUBLICATIONS
124
NATIONAL SECURITY AGENCY (NSA)/CENTRAL SECURITY SERVICE (CSS) PUBLICATIONS
124
APPENDIX B - ACRONYMS & ABBREVIATIONS
126
APPENDIX C - GLOSSARY OF TERMS
131
APPENDIX D - SUMMARY OF CHANGES
146
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
EXECUTIVE SUMMARY
(U) The policy of the U.S. Government is that all classified information must be appropriately
safeguarded to assure the confidentiality, integrity, and availability of that information. This
document provides procedural guidance for the protection, use, management, and dissemination of
Sensitive Compartmented Information (SCI), and is applicable to the Department of Defense
(DoD) to include DoD components and Government contractors who process SCI. The
combination of security safeguards and procedures used for Information Systems (IS) shall assure
compliance with DoD 5105.21-M-1, Director, Central Intelligence Directive 6/3 (DCID 6/3),
National Security Agency/Central Security Service (NSA/CSS) Manual 130-1 and the Defense
Intelligence Agency Manual
(DIAM 50-4). The Joint DoDIIS/Cryptologic SCI Information
Systems Security Standards (JDCSISSS) is a technical supplement to both the NSA/CSS Manual
130-1 and DIAM 50-4.
(U) The prime purpose of this document is to provide IS security implementation guidance relative
to the management of SCI and the automated infrastructure used to process this information at the
organizational level.
(U) Nothing in this document shall be construed to countermand or waive provisions of any
Executive Order, National Policy, DoD Directive, or other provisions of regulatory policies or laws
which are beyond the scope of authority of the Directors of the Defense Intelligence Agency (DIA)
and the National Security Agency/Central Security Service (NSA/CSS).
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
1
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 1 - GENERAL INFORMATION
1.1(U) BACKGROUND
The DIA DoDIIS Information Assurance (IA) Program includes the Air Force, Army, Navy, and
National Imagery and Mapping Agency (NIMA) Service Certification Organizations (SCO). The
NSA/CSS Cryptologic Information Assurance (IA) Program includes the Air Force, Army, and
Navy Service Cryptologic Elements (SCE). Together, they identified a requirement to standardize
security procedures used in the management of Sensitive Compartmented Information (SCI)
systems and the information they process. SCI is defined as information and materials requiring
special community controls indicating restricted handling within present and future community
intelligence collection programs and their end products. These special community controls are
formal systems of restricted access established to protect the sensitive aspects of sources, methods,
and analytical procedures of foreign intelligence programs. It was also determined that by
standardizing procedural guidelines, it would significantly improve support to the increasingly
interconnected customer base of the Joint Services. This document describes the protection
philosophy and functional procedures essential in the implementation of an effective IA Program.
Further, it provides implementation guidelines and procedures applicable to the protection, use,
management, and dissemination of SCI; assigns responsibilities; and establishes procedures for the
development, management, and operations of systems and networks used for processing SCI. The
primary purpose of this supplemental guidance is to address day-to-day IS security (ISS) issues and
provide support to those responsible for managing SCI and the automated infrastructure used to
process this information at the organizational level.
1.2 (U) POLICY
U.S. Government policy requires all classified information be appropriately safeguarded to ensure
the confidentiality, integrity, and availability of the information. Safeguards will be applied such that
information is accessed only by authorized persons and processes, is used only for its authorized
purpose, retains its content integrity, is available to satisfy mission requirements, and is marked and
labeled as required. SCI created, stored, processed, or transmitted in or over Information Systems
(ISs) covered by DCI policy and supplementing directives shall be properly managed and protected
throughout all phases of a system’s life cycle. The combination of security safeguards and
procedures shall assure that the system and users are in compliance with DCID 6/3, DoD 5105.21-
M-1, NSA/CSS Manual 130-1, DIAM 50-4, and this supplement (e.g., JDCSISSS). This document
shall not be construed to countermand or waive provisions of any Executive Order, National
Policy, DoD Directive, or other provisions of regulatory policies or laws, which are beyond the
scope of authority of the Directors of the DIA and the NSA/CSS. Any perceived contradictions
with higher-level policy should be forwarded to the appropriate Designated Accrediting Authority
(DAA) Representative (Rep)/Service Certifying Organization (SCO) for resolution.
1.3 (U) SCOPE AND APPLICABILITY
This document contains procedures and identifies standards that shall be applied to all systems
processing SCI under the cognizance of the DoD. This includes the following:
· Office of the Secretary of Defense (OSD)
· the Chairman of the Joint Chiefs of Staff
· the Joint Staff
· the United, Joint Commands and Task Forces
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
2
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· the Defense Agencies and Field Activities
· the Military Departments (including their National Guard and Reserve components)
· NSA/CSS and its Service Cryptologic Elements
· NIMA
· the Inspector General of the DoD
· and Government contractors supporting DoD who process SCI.
This includes systems that are: airborne, mobile, afloat, in-garrison, tactical, mission, administrative,
embedded, portable, Government purchased, Government leased, or on loan from other Government
sources, and Contractor purchased and leased.
Contained also within this document is a collective set of procedures and protection mechanisms for ISs
and networks used in SCI processing that must be enforced throughout all phases of the IS life-cycle, to
include:
· Concept Development
· Design
· Development
· Deployment
· Operations
· Recertification
· Disposal
1.4 (U) REFERENCES, ACRONYMS, AND DEFINITIONS
Appendix A provides a comprehensive list of national, department, and agency publications that are
used in conjunction with this document and augments these reference sources. The acronyms used
in this document are contained in part 1 of Appendix B. The terminology extracted from various IS
related documents are included as part 2 of Appendix B.
1.5 (U) ROLES AND RESPONSIBILITIES
The roles and responsibilities of the personnel involved with IS security are summarized in the
paragraphs below. Personnel in the roles defined below must attend training and certification as
directed by DoD and meet DCID 6/3 prerequisites. Reference appendix C for list of PAAs and
DAAs.
1.5.1 (U) Principal Accrediting Authority (PAA)
The PAA has ultimate security responsibility for his/her organization. This responsibility includes
IA program oversight, development, and implementation. In general, much of this person’s
operational authority is delegated to DAAs. The PAA shall:
· Be a U.S. citizen;
· Be an employee of the United States Government; and
· Hold U.S. Government security clearance/access approvals commensurate with the highest level of
information processed by the system.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
3
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
·
Responsibilities of the PAA shall include:
·
Establish a department or agency IA Security Program.
·
Appoint DAAs.
·
Approve or disapprove further delegation of the DAA’s authority.
·
Ensure that individuals knowledgeable in all areas of security support the DAA such that a
technically correct assessment of the security characteristics of new ISs can be formalized.
·
Ensure the implementation of the requirements set forth in U.S. Government IS security policy.
·
Ensure accountability for the protection of the information under his/her purview.
·
Ensure availability of security education, training, and awareness, to ensure consistency and
reciprocity.
·
Establish a compliance and oversight mechanism to validate the consistent implementation of IS
security policy.
·
When justified, approve the operation of system(s) that do not meet the requirements specified in
DoD and Intelligence Community (IC) IS security documents. However, such approval shall be in
writing, and the PAA granting such approval shall also document, in writing, his/her responsibility
for the resulting residual risk(s) and inform other PAAs responsible for systems interconnected to
this system.
·
Ensure that security is incorporated as an element of the IS life-cycle process.
1.5.2 (U) Data Owner
Responsibilities of the Data Owner shall include, but are not limited to:
· Provide guidance to the PAA/DAA concerning:
· The sensitivity of information under the Data Owner’s purview;
· The PAA/DAA’s decision regarding the Levels-of-Concern for confidentiality, integrity, and
availability; and
· Specific requirements for managing the owner’s data (e.g., incident response, information
contamination to other systems/media, and unique audit requirements).
· Determine whether foreign nationals may access information systems accredited under this manual.
Access must be consistent with DCIDs 6/6, 5/6 and 6/3.
1.5.3 (U) Designated Accrediting Authority (DAA)
The DAA shall:
· Be a U.S. citizen;
· Be an employee of the United States Government; and
· Hold U.S. Government security clearance/access approvals commensurate with the highest level of
information processed by the system.
Responsibilities of the DAA shall include, but are not limited to:
· Ensure each system is properly accredited/certified based on system environment, sensitivity levels
and security safeguards.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
4
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
·
Issue written accreditation/certification statements.
·
Ensure records are maintained for all IS accreditations/certifications under his/her purview to
include use of automated information assurance tools.
·
Ensure all of the appropriate roles and responsibilities outlined in this directive are accomplished for
each IS.
·
Ensure that operational information systems security policies are in place for each system, project,
program, and organization or site for which the DAA has approval authority.
·
Ensure that a security education, training, and awareness program is in place.
·
Ensure that security is incorporated as an element of the life-cycle process.
·
Ensure that the DAA Rep/ SCO members are trained and certified to properly perform their
responsibilities.
·
Provide written notification to the cognizant PAA and Data Owner prior to granting any foreign
national access to the system.
·
Ensure that organizations plan, budget, allocate, and spend adequate resources in support of IS
security.
·
Ensure consideration and acknowledgement of Counter-Intelligence activities during the C&A
process.
·
Report security-related events to affected parties (i.e., interconnected systems), data owners, and
all involved PAAs.
1.5.4 (U) DAA Representative (Rep)/Service Certifying Organization (SCO)
· The DAA Rep(s)/SCO members shall be U.S. citizens and
· Hold U.S. Government security clearance/access approvals commensurate with the highest level of
information processed by the system.
Responsibilities of the DAA Rep/SCO, under the direction of the DAA, shall include:
· Develop and oversee operational information systems security implementation policy and
guidelines.
· Ensure that security testing and evaluation is completed and documented.
· Advise the DAA on the use of specific security mechanisms.
· Maintain appropriate system accreditation documentation.
· Oversee and periodically review system security to accommodate possible changes that may have
taken place.
· Advise the Information Systems Security Managers (ISSMs) and Information System Security
Officers (ISSOs) concerning the levels of concern for confidentiality, integrity, and availability for
the data on a system.
· Evaluate threats and vulnerabilities to ascertain the need for additional safeguards.
· Ensure that a record is maintained of all security-related vulnerabilities and ensure serious or
unresolved violations are reported to the DAA.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
5
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· Ensure that certification is accomplished for each IS.
· Evaluate certification documentation and provide written recommendations for accreditation to the
DAA.
· Ensure all ISSMs and ISSOs receive technical and security training to carry out their duties.
· Assess changes in the system, its environment, and operational need that could affect the
accreditation.
1.5.5 (U) NSA/CSS Senior Information Systems Security Program Manager (SISSPM)
· The SISSPM shall be a U.S. citizen and
· Hold U.S. Government security clearance/access approvals commensurate with the highest level of
information processed by the system.
The SISSPM responsibilities shall include but are not limited to the following:
· Develop metrics, measuring and reporting progress on improving ISS in operational systems and
networks.
· Establish and maintain career development and training for ISS personnel under their purview.
· Serve as the operational representative to the NSA/CSS Information System Security Incident
Board (NISSIB).
· Represent the operational ISS view to the Operational Information Systems Security Steering
Group.
· Direct Field, SCE and regional ISSPMs in actions related to the NSA/CSS Operational IS Security
Program.
· Assist the NISIRT in managing ISS incidents and in implementing fixes to identified vulnerabilities
in operational ISs.
· Promote general operational information systems security awareness.
· Provide technical and policy guidance to ISS Security personnel.
· Provide a forum for information exchange on computer security issues with the Information
Systems Security Managers.
1.5.6
(U) Service Cryptologic Element (SCE) Information Systems Security Program Manager
(ISSPM)
· The SCE ISSPM shall be a U.S. citizen and
· Hold U.S. Government security clearance/access approvals commensurate with the level of
information processed by the system.
The SCE ISSPM responsibilities include:
· Act as liISon on matters concerning IS and Network security to the NSA/CSS Senior Information
Systems Security Program Manager (SISSPM) and to the appropriate military headquarters.
· Ensure the accreditation of all SCE ISs.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
6
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
·
Review all certification/accreditation support documentation for proof of adequate IS and Network
security procedures and, based upon the review, recommend approval or disapproval to the
appropriate DAA.
·
Forward reviewed certification/System Security Plan (SSP) for ISs to the NSA/CSS SISSPM, as
required.
·
Grant interim approval-to-operate and formal accreditation of ISs as authorized by NSA/CSS
DAA.
·
Review requests to bypass, strain, or test security mechanisms, or conduct network monitoring or
keystroke monitoring and obtaining approval/disapproval for SCI requests from the NSA/CSS
SISSPM and approve/disapprove requests for unclassified and collateral systems.
·
Ensure life-cycle security integrity of all SCE ISs.
·
Develop procedures necessary to implement higher level regulations and directives.
·
Provide guidance and policy to all subordinate SCE organizations.
·
Promote the nomination of SCE personnel for NSA/CSS Security Achievement Awards.
·
Manage the SCE IS and Network Security Training Program to include:
·
Ensure all SCE ISSMs and ISSOs attend the National Cryptologic School OIAC-2225 course,
“Operational IS Security” or equivalent.
·
Coordinate the training of nominees with the National Cryptologic School.
·
Publish SCE annual training schedules for the OIAC-2225 course, which is published in October-
November for the following calendar year.
·
Report name, organization, and address of all students to the National Cryptologic School for
certificates of completion.
·
Develop unique SCE courses and materials for training, as necessary.
·
Maintain a level of expertise by attending IS and Network security conferences, symposiums, and
training courses sponsored by other agencies.
·
Augment SCE inspections, both Inspector General (IG) and others, upon request.
·
Review requirements for approving public-domain software before its use on any SCE IS.
1.5.7 (U) Commander/Commanding Officer (CO)/Senior Intelligence Officer (SIO) Responsibility
Commanders/CO/SIOs, in conjunction with their ISSM/ISSOs/System Administrators (SA), will
work together to present a cohesive training program, both for users and IS & network security
personnel. If well developed and effectively implemented, the security program can help mitigate IS
security threats, help prevent the compromise or loss of classified information, and produce users
who act effectively to secure system resources. The responsibilities of the Commander/CO/SIO, as
prescribed in DCID 6/1, paragraph 1.1.16, and DoD 5105.21-M-1, Chapter 1, include:
· Appointment of an ISSM in writing and, where applicable, ensure a copy of orders are forwarded
to the SCE organization’s ISSPM or the DIA DAA Rep/SCO.
· Ensure the establishment and fund of an effective and responsive IS Security (ISS) Program.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
7
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· Participate as an active member of the organization’s CCB or appointment of a representative to
act in their absence.
· Ensure that users and ISS personnel receive DoD-mandated certification training IAW their
responsibilities as part of an approved ISS training program.
· Ensure ISS policies are enforced and implemented.
1.5.8 (U) Information Systems Security Manager (ISSM)
The ISSM is appointed in writing by the authority at a site responsible for information system
security. ISSM responsibilities should not be assigned as collateral duties. The ISSM shall:
· Be a U.S. citizen;
· Hold U.S. Government security clearance/access approvals commensurate with the highest level of
information processed by the system; and
· Attend DAA approved training.
The ISSM responsibilities include:
·
Forward a copy of his/her appointment letter to the DAA Rep/SCO.
·
Develop and maintain a formal IS security program.
·
Implement and enforce IS security policies.
·
Oversee all ISSOs to ensure they follow established IS policies and procedures.
·
Ensure ISSM/ISSO review weekly bulletins and advisories that impact security of site information
systems to include, AFCERT, ACERT, NAVCIRT, IAVA, and DISA ASSIST bulletins.
·
Ensure that periodic testing (monthly for PL-5 systems) is conducted to evaluate the security
posture of the ISs by employing various intrusion/attack detection and monitoring tools (shared
responsibility with ISSOs).
·
Ensure that all ISSOs receive the necessary technical (e.g., operating system, networking, security
management, SysAdmin) and security training to carry out their duties.
·
Assist ISSOs to ensure proper decisions are made concerning the levels of concern for
confidentiality, integrity, and availability of the data, and the protection levels for confidentiality for
the system.
·
Ensure the development of system accreditation/certification documentation by reviewing and
endorsing such documentation and recommending action to the DAA Rep/SCO.
·
Ensure the development of documentation if site accepts IS without all appropriate C & A
documents.
·
Ensure approved procedures are in place for clearing, purging, declassifying, and releasing system
memory, media, and output.
·
Maintain, as required by the DAA Rep/SCO, a repository for all system accreditation/certification
documentation and modifications.
·
Coordinate IS security inspections, tests, and reviews.
·
Investigate and report (to the DAA/DAA Rep and local management) security violations and
incidents, as appropriate.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
8
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
·
Ensure proper protection and corrective measures have been taken when an IS incident or
vulnerability has been discovered.
·
Ensure data ownership and responsibilities are established for each IS, to include accountability,
access and special handling requirements.
·
Ensure development and implementation of an effective IS security education, training, and
awareness program.
·
Ensure development and implementation of procedures IAW configuration management (CM)
policies and procedures for authorizing the use of hardware/software on an IS. Any additions,
changes or modifications to hardware, software, or firmware must be coordinated with the
ISSM/ISSO and appropriate approving authority prior to the addition, change or modification.
·
Develop procedures for responding to security incidents, and for investigating and reporting (to the
DAA Rep/SCO and to local management) security violations and incidents, as appropriate.
·
Serve as a member of the configuration management board, where one exists (however, the ISSM
may elect to delegate this responsibility to the ISSO.)
·
Working knowledge of system functions, security policies, technical security safeguards, and
operational security measures.
·
Access only that data, control information, software, hardware, and firmware for which they are
authorized access and have a need-to-know, and assume only those roles and privileges for which
they are authorized.
1.5.9 (U) Information Systems Security Officer (ISSO)
The ISSO shall:
· Be a U.S. citizen and
· Hold U.S. Government security clearance/access approvals commensurate with the highest level of
information processed by the system.
Responsibilities of the ISSO shall include:
· Ensure systems are operated, maintained, and disposed of in accordance with internal security
policies and procedures as outlined in the accreditation/certification support documentation
package.
· Attend required technical (e.g., operating system, networking, security management, SysAdmin)
and security training relative to assigned duties.
· Ensure all users have the requisite security clearances, authorization, need-to-know, and are aware
of their security responsibilities before granting access to the IS.
· Ensure that proper decisions are made concerning levels of concern for confidentiality, integrity,
and availability of the data, and the protection level of the system.
· Report all security-related incidents to the ISSM.
· Initiate protective and corrective measures when a security incident or vulnerability is discovered,
with the approval of the ISSM.
· Develop and maintain an accreditation/certification support documentation package for system(s)
for which they are responsible.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
9
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
·
Conduct periodic reviews to ensure compliance with the accreditation/certification support
documentation package.
·
Ensure CM for IS software and hardware, to include IS warning banners, is maintained and
documented.
·
Serve as member of the Configuration Management Board if so designated by the ISSM.
·
Ensure warning banners are placed on all monitors and appear when a user accesses a system.
·
Ensure system recovery processes are monitored and that security features and procedures are
properly restored.
·
Ensure all IS security-related documentation is current and accessible to properly authorized
individuals.
·
Formally notify the ISSM and the DAA Rep/SCO when a system no longer processes classified
information.
·
Formally notify the ISSM and the DAA Rep/SCO when changes occur that might affect
accreditation/certification.
·
Ensure system security requirements are addressed during all phases of the system life cycle.
·
Follow procedures developed by the ISSM, IAW CM policies and procedures, for authorizing
software use prior to its implementation on a system. Any changes or modifications to hardware,
software, or firmware of a system must be coordinated with the ISSM and appropriate approving
authority prior to the change.
·
Establish audit trails and ensure their review.
·
Ensure user identification (USERID) and authentication mechanisms of the IS or network are
established.
·
Ensure the most feasible security safeguards and features are implemented for the IS or network.
·
Ensure no attempt is made to strain or test security mechanisms, or perform network line
monitoring, or keystroke monitoring without appropriate authorization.
·
Perform network monitoring for the purpose of identifying deficiencies, but only with approved
software, and after notifying the ISSM and other appropriate authority.
·
Access only that data, control information, software, hardware, and firmware for which they are
authorized access and have a need-to-know, and assume only those roles and privileges for which
they are authorized.
1.5.10 (U) The Program Management Office (PMO)/Program Manager (PM)
· The PM/PMO shall be a U.S. citizen and
· Hold U.S. Government security clearance/access approvals commensurate with the highest level of
information processed by the system.
The responsibilities of the PMO/PM will include:
· Ensure compliance with current IA policies, concepts, and measures when designing, procuring,
adopting, and developing new ISs. This includes systems that are developed under contracts with
vendors or computer services organizations and includes those systems that store, process, and/or
transmit intelligence information.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
10
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
·
Appointment of an Information System Security Engineer (ISSE)/System Design Security Officer
(SDSO) in writing, to ensure system design is developed and implemented with required security
features and safeguards; ensure enhancements to existing systems provide equal or improved
security features and safeguards; consult with the appropriate certifying organization(s) as early as
possible.
·
Ensure that the CM process is addressed and used when new SCI ISs are under development, being
procured, or delivered for operation. An integral part of CM is the System Accreditation process.
Therefore, it is imperative that accreditation authorities be advised of CM decisions. This will
ensure systems are fielded or modified within acceptable risk parameters and the latest security
technology is being incorporated into system designs. This participation is most important at the
Preliminary Design Review (PDR) and the Critical Design Review (CDR).
·
Ensure a risk assessment on the IS while under development and keep the risk assessment current
throughout the acquisition/development portion of the life cycle.
·
Enforce security controls that protect the IS during development.
·
Ensure all steps involved in the acquisition and delivery of a certifiable IS followed. These include:
·
Evaluate interoperability with other systems.
·
Describe the IS mission so that it is clearly understood.
·
Formulate a concept and design for meeting the security requirements.
·
Incorporate security requirements during system development.
·
Develop accreditation support documentation to be fielded with the IS.
·
Ensure the IS undergoes Certification and/or Accreditation (C&A) Testing and Evaluation (T&E)
prior to operation.
·
Coordinate a C&A schedule with the DAA or DAA Rep.
1.5.11 (U) Privileged Users (e.g., System Administrator [SA])
The responsibilities inherent to IS administration are demanding and require a thorough knowledge
of the IS. These responsibilities include various administrative and communications processes that,
when properly carried out, will result in effective IS utilization, adequate security parameters, and
sound implementation of established IA policy and procedures. System administrators shall:
· Be U.S. citizens;
· Be IA trained and certified in compliance with DoD requirements; and
· Hold U.S. Government security clearance/access approvals commensurate with the highest level of
information processed by the system.
In addition to the requirements for a general user, responsibilities of system administration
personnel shall include:
· Implement the IS Security guidance and policies as provided by the ISSM/ISSO.
· Maintain IS and networks to include all hardware and Commercial Off-The-Shelf/Government Off-
The-Shelf software (COTS/GOTS).
· Monitor system performance ensuring that system recovery processes are monitored to ensure that
security features and procedures are properly restored.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
11
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
·
Report all security-related incidents to the ISSM/ISSO.
·
Ensure that all users have the requisite security clearances, authorization, need-to-know, and are
aware of their security responsibilities before granting access to the IS.
·
Perform equipment custodian duties by providing other system unique requirements that may be
necessary. Ensure systems are operated, maintained, and disposed of IAW internal security policies
and procedures outlined in the accreditation/certification support documentation package.
·
Maintain software licenses and documentation.
·
Notify the ISSM/ISSO formally when changes occur that might affect accreditation/certification.
·
Ensure CM for security-relevant IS software and hardware, to include IS warning banners, is
maintained and documented.
·
Monitor hardware and software maintenance contracts.
·
Implement USERID and authentication mechanisms of the IS or network and issue user logon
identifications and passwords.
·
Ensure adequate network connectivity by ensuring that proper decisions are made concerning levels
of concern for confidentiality, integrity, and availability of the data, and the protection level for
confidentiality for the system.
·
Maintain audit trails and conduct reviews and archives as directed by the ISSM/ISSO.
·
Provide backup of system operations.
·
Assist the ISSM/ISSO in developing and maintaining accreditation/certification support
documentation package for system(s) for which they are responsible.
·
Participate in periodic reviews to ensure compliance with the accreditation/certification support
documentation package.
·
Ensure all IS security-related documentation is current and accessible to properly authorized
individuals.
·
Formally notify the ISSM/ISSO when a system no longer processes classified information.
·
Follow procedures developed by the ISSM/ISSO, authorize software use before implementation on
the system.
·
Assist the ISSM/ISSO in maintaining configuration control of the systems and applications
software ensuring the most feasible security safeguards and features are implemented on the IS or
network.
·
Prohibit attempts to strain or test security mechanisms, or perform network line monitoring or
keystroke monitoring without appropriate authorization.
·
Perform network monitoring for the purpose of correcting deficiencies, but only with approved
software, and after notifying the ISSM and other appropriate authority and advising the
ISSM/ISSO of security anomalies or integrity loopholes.
·
Participate in the Information Systems Security incident reporting program and with the approval
of the ISSM/ISSO, initiate protective or corrective measures when a security incident or
vulnerability is discovered.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
12
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
1.5.12 (U) General Users
General users must hold U.S. Government security clearance/access approvals commensurate with
the highest level of information processed by the system. The responsibilities of a general user shall
include:
·
Use the system for official use, only. Appropriate personal use of IS must be approved first by the
individual’s supervisor.
·
Participate, at a minimum, in annual computer security awareness briefings/training.
·
Provide appropriate caveat and safeguard statements on all IS files, output products, and storage
media.
·
Protect ISs and IS peripherals located in his/her respective areas.
·
Secure unattended ISs by invoking screen lock or logging off.
·
Safeguard and report any unexpected or unrecognizable output products to the ISSO/SA as
appropriate. This includes both display and printed products.
·
Safeguard and report the receipt of any media received through any channel to the appropriate
ISSO/SA for subsequent virus inspection and inclusion into the media control procedures.
·
Report all security incidents to the ISSO/SA or ISSM.
·
Protect passwords at the same level as the highest classification of material which the system is
accredited to process.
·
Protect passwords by never writing passwords down and destroy the original password
documentation following initial review.
·
Protect passwords from inadvertent disclosure.
·
Protect all files containing classified data.
·
Notify the system ISSO/SA if he or she suspects that a possible IS and/or network security problem
exists.
·
Ensure access doors, covers, plates and TEMPEST seals are properly installed on ISs to eliminate
security hazards.
·
Protect their authenticators and report any compromise or suspected compromise of an
authenticator to the appropriate ISSO.
1.5.13 (U) Prohibited Activities
In general, there are activities that all users shall not perform on Government systems:
· Use ISs for personal gain, personal profit or illegal activities.
· Release, disclose, or alter information without the consent of the data owner or the disclosure
officer’s approval. Violations may result in prosecution of military members under the Uniform
Code of Military Justice, Article 92 or appropriate disciplinary action for civilian employees.
· Attempt to strain or test security mechanisms, or perform network line monitoring or keystroke
monitoring without proper authorization.
· Attempt to bypass or circumvent computer security features or mechanisms.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
13
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· Modify the system equipment or software or use it in any manner other than its intended purpose.
· Relocate or change IS equipment or the network connectivity of IS equipment without proper
security authorization.
· Introduce malicious code into any IS or network and will comply with rules and regulations for
scanning all magnetic media that he/she introduces, mails, or transports into or out of the
organization.
1.6 (U) CONFIGURATION CONTROL BOARD (CCB) OVERSIGHT
This document is under the purview of a Joint Service CCB consisting of representatives from DIA,
NIMA, NSA/CSS and its SCEs, and the SCOs. Any recommended changes to this document
should be forwarded to the appropriate CCB member.
1.7 (U) OTHER DOCUMENTATION SUPERSESSION
This document supersedes all previous editions of the Joint DoDIIS/Cryptologic SCI Information
Systems Security Standards.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
14
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 2 - LIFE CYCLE SECURITY
2.1 (U) PURPOSE
The Director of Central Intelligence Directive (DCID) 6/3, for the Intelligence Community is used
to provide a system of evaluating the degree of trust needed for an IS processing classified and
sensitive information. It is the basis for specifying security requirements in acquisition
specifications, both for existing and planned systems. The Program Manager
(PM), during
acquisition/development, will require that security be an integral part of any contract used for
acquisition consistent with the security requirements of the system. The PM and IS developers
involved in the acquisition process of new ISs must ensure these new systems function as intended
and are accreditable. They must ensure that systems are designed to meet user requirements, are
developed economically, and contain appropriate security controls and audit trails. C&A
procedures must be precisely followed to ensure new ISs are created and can be readily approved
for operation at an acceptable level of risk. Acquisition procedures must address all aspects of IS
development, to include the security requirements that must be met, the IS security features
required, the IS operating environment, and a plan that properly tracks the process by which IS
definition, development, and security testing are to take place. The purpose of this chapter is to
address acquisition security requirements and includes:
· National security policy requirements as they pertain to system development.
· The responsibilities involved in the accreditation process.
· Levels of Concern and Protection Levels.
· Guidance that appropriate security requirements are identified early in the acquisition process.
2.2 (U) SCOPE
The early and complete identification of security requirements for an Information System is a major
security objective in all phases of the IS life cycle. These guidelines apply to all security personnel
who must consider, improve, or change security throughout the life cycle to ensure continued
adequate protection. These procedures are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
YES
DESIGN PHASE
YES
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
YES
2.3 (U) PROCEDURES
Within each organization, life-cycle security requirements will be related to one of the seven life
cycle phases which apply to all systems: Government owned, leased, or on loan from other
organizations. DAA Reps/SCOs must review and approve detailed system or subsystem security
specifications.
2.3.1 (U) Concepts Development Phase
During the conceptual phase, the Developer, User and DAA determine the criticality of the IS
being planned based on the data sensitivity determined by the data owner. This is accomplished by
conducting sensitivity, risk/threat, interoperability, and economic assessments. The results of these
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
15
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
assessments provide the data necessary to perform the analysis and design of the next phase. These
guidelines apply to all personnel performing acquisition of ISs with the objective of fielding ISs
with the appropriate security requirements identified early in the acquisition process.
2.3.1.1 (U) IS Security Design
The PMO/PM ensures all IS security requirements are incorporated in the Critical Design Review,
the SSP/Systems Security Authorization Agreement
(SSAA) and the Security Concept of
Operations (SECONOPS) (see DCID 6/3, 4.B.1.c.(1)). The PMO/PM and their SDSO/ISSE, will
ensure the IS security design meets the requirements of DCID 6/3.
2.3.1.2 (U) Statement of Work (SOW) Requirements
The SOW will include a DD Form 254 and address contractor related issues pertaining to contractor
personnel security, physical security, contractor ISs in support of the contract, TEMPEST requirements,
and applicable security regulations. A Government official, either the SDSO/ISSE or DAA Rep/SCO, will
coordinate these specific requirements depending on the particular acquisition.
2.3.1.3 (U) Additional Documentation
Additional documentation based on the system’s identified Protection Level to include guide(s) or
manual(s) for the system’s privileged users (test plans, procedures and results) and a general user’s
guide may be required.
2.3.2 (U) Design Phase
The DAA/DAA Rep along with the data owner guidance determines the Levels of Concern (LOC)
for Confidentiality, Integrity and Availability based on the information characteristics determined in
the Concepts Development Phase. The DAA/DAA Rep then determines the required Protection
Level based on the need-to-know, formal access approval(s), and clearance level(s), if applicable,
of system users as compared to the sensitivity, formal compartments, and classification of the data
to be stored, processed, or transmitted on the system. The Levels of Concern and Protection Levels
are:
Security Features
Level of Concern
Protection Levels
Confidentiality
High
(Basic/Medium not used in
PL-1, PL-2, PL-3, PL-
Intelligence ISs)
4, PL-5
Integrity
Basic, Medium, High
Availability
Basic, Medium, High
2.3.2.1 (U) Levels-of-Concern
Based on the characteristics of the information in the IS, a Level-of-Concern must be determined in
each of three categories: confidentiality, integrity, and availability. The available Level-of-Concern
ratings are Basic, Medium or High. The DAA determines the Level-of-Concern separately for each
category based on the following:
· The Confidentiality Level-of-Concern rating for all ISs that process intelligence information is, by
definition, High.
· The Integrity Level-of-Concern is determined by the necessary degree of resistance to unauthorized
modification of the data in the IS. The greater the need for data integrity, the higher the Level of
Concern.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
16
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· The Availability Level-of-Concern rating is based on the need of ready access to the system data.
The greater the need for rapid data availability, the higher the Level-of-Concern.
· A detailed description of the determination and assignment of Levels-of-Concern can be found in
DCID 6/3, section 3.B. and Table 3.1, with even greater detail of each category in Chapters 4
(Confidentiality), 5 (Integrity), and 6 (Availability).
2.3.2.2 (U) Protection Levels
The Protection Level of an IS is the implicit level of trust placed on the procedures and technical
capabilities of the system, and applies only to confidentiality. After determining that the Level-of-
Concern for confidentiality must be high (since the system processes intelligence data), the DAA
must then determine the necessary Protection Level based on:
· Required clearances,
· Formal access approval, and
· Need-to-know of all IS users.
2.3.2.2.1 (U) IS Protection Level Determinations
The DAA/DAA Rep and data owner must explicitly determine the Protection Level for each IS to
be accredited. DCID 6/3, Section 3.C. and Table 4.1 differentiate between the five Protection
Levels (PL1 - PL5). Chapter 4 details the security features required for each Protection Level.
2.3.2.2.2 (U) Security Documentation (SSP/SSAA) Requirements
The LOCs for Integrity and Availability and the PL for Confidentiality are identified using DCID
6/3 Chapters
4-6. During the design phase, the Project Management Office (PMO) ensures
development of the Security Requirements Traceability Matrix
(SRTM) and the continued
development of the SSP/SSAA. This is a living document and should be updated throughout the
IS’s life cycle. It incorporates security documentation requirements found in DCID 6/3 and includes
the mission need, system and environment description, intended system users, system security
requirements, and development schedule. A template for the SSAA can be found in the DoD
Intelligence Information System
(DoDIIS) Security Certification and Accreditation Guide,
Appendix D. A template for the SSP can be found in the NSA/CSS Information System
Certification and Accreditation Process (NISCAP). The initial draft of the SSAA/SSP must be
approved by the DAA Rep/SCO prior to system development. Actions must be taken by the
Program Managers (PM) and SDSO/ISSE to ensure compliance with directives according to DCID
6/3.
2.3.3 (U) Development Phase
Adequate implementation of the necessary security measures is ensured during the development
phase. The SDSO/ISSE, appointed by the PMO, has the major responsibility during the
development phase. SDSO/ISSE ensures a test plan is prepared IAW the SRTM and participates in
all project meetings including site surveys as appropriate. Security support from the certifying
organization is required based on the Protection Level of the IS. Hardware, software,
telecommunications and the entire operational environment must comply with the SSP/SSAA. This
extends beyond the system itself; the proposed or existing facility that will house the system must
be considered to ensure that proper physical security is available. During the development phase,
design reviews may identify security considerations that were overlooked in the initial system
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
17
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
design. If so, the SSAA/SSP must be updated accordingly. If major security considerations are
discovered, the development may return to a previous phase for rework.
2.3.4 (U) Test, Certification and Accreditation Phase
During the test phase, the entire system is critically reviewed to ensure compliance with all specified
measures. Security testing is conducted to certify that the system’s security and contingency
operations are properly implemented. Any shortcomings and/or vulnerabilities are identified, and a
risk analysis is conducted. Based upon the outcome of the risk analysis, a plan addressing the
shortcomings (fixes, work-arounds, etc.) is developed. All this is detailed in a Report, which is used
by the DAA/DAA Rep when making the approval decision. A template for the test report is located
in the DoDIIS Security Configuration and Accreditation Guide, and the NISCAP. Following the
conclusion of security testing, the resolution of any shortcomings, and after the appropriate
DAA/DAA Rep grants certification approval, the system is released for operational use.
2.3.4.1 (U) Time Line for Certification Activities
The timeline for certification activities will be coordinated with the certifying organization. A
minimum 90-day period is the basis for providing enough time for certifiers to properly prepare for
and conduct a system certification evaluation and recommendation to the DAA/DAA Rep. The 90
day timetable begins with the submission of the Request for Certification from the Program
Manager (PM/PMO) to the certifying organization.
90 days
60 days
30 days
0 days
PM Request for Certification/Accreditation
X
SSAA/SSP
X
SCE/SCO approval of SSAA/SSP
X
SRTM & Test Procedures (SFUG if necessary)
X
SCE/SCO approval of Test Procedures
X
SCE/SCO submits Test Report and Test Memo
X
2.3.5 (U) Deployment and Operations Phase
Once the system is operational, the site operations staff and ISSO/ISSM are responsible for
monitoring its security. They do this by controlling changes to the system via strict Configuration
Management. IS users are responsible for operating the system in compliance with the security
guidelines found in the SSAA/SSP. As required by DCID 6/3, the DAA/DAA Rep periodically
reviews the adequacy of system security as required by all applicable regulations for unclassified,
sensitive-unclassified, collateral, and SCI material. This review will take into account any system
modifications and changes, including both hardware and software, to ensure that security
requirements are adequate to meet any identified risks, threats to, or vulnerabilities of the system.
All changes are updated in the SSAA/SSP as they occur. If any changes significantly affect the
system’s security posture, the DAA/DAA Rep is notified so that the need for
recertification/reaccreditation can be determined.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
18
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
DMB
PMO provides
ISSM obtains
SCO/ISSM conducts
grants
Security
approval
PMO provided Test
approval
Certification
from local CCB
Procedures or subset,
to field.
Letter with
to
at their discretion.
security
integrate system
documentation to
into
ISSM.
Test Director
No
(SCO/ISSM)
prepares Test
Findings sent to
PASS
Report with
SCO and PMO.
certification
recommendation.
Yes
Test Report
SCO/ISSM
ISSM updates Site
endorsed
grants
Security
by chain of
approval to
documentation to
command.
operate, with
include new system.
Retained by ISSM
recommendation
and
to add to site
forwarded to SCO.
baseline.
ISSM ensures
ISSM adds
Category II
system to the site
findings are
baseline.
resolved.
Figure: 2.1 - Example process for PL2 DoDIIS IMA after approval to field.
2.3.6 (U) Contingency Planning
Once a system is deployed to a site a contingency plan for emergency response, backup operations,
and post-disaster recovery is to be maintained by the activity as a part of its security program. It
consists of a comprehensive statement of all the actions to be taken before, during, and after a
disaster or emergency condition along with documented and tested procedures. It ensures that
critical resources are available and facilitates the continuity of operations in an emergency situation.
· Backup. Preventing catastrophic loss of data and progress requires that users maintain adequate
backups for their stored data. Besides preventing data loss, backups of data for archiving purposes
allow for proper on-line storage management. All magnetic media must be properly labeled and
protected according to Chapter 13.
· Responsibilities. Each ISSM, or designee, will develop locally needed backup plans. The plans
should consider data-production rates and data-loss risks when under development. The areas of
risk that should be identified and planned for are:
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
19
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
o Immediate Losses. Ensures that the risk of a power failure and the resulting loss of data is
worked at the time of power loss. Develop policy and procedures that reflect these risks.
For example, if one were creating a word-processing document when power loss occurred,
the document would be lost if the user had not made periodic “saves” while creating it.
Some word-processing systems allow the user to make periodic saves automatically (for
example, Word for Windows). Most applications do not have this capability, and the users
must be made aware of this potential problem.
o Media Losses. Develop a local procedure that reflects this risk. If a hard disk were dropped
or contaminated in some way, the disk backups, coupled with periodic incremental backups
between full backups, would allow you to restore the data close to the condition it was in
before the loss. Keep “active backups” for disks that contain often-used applications.
o Archiving Inactive Data. Develop procedures to manage the disk space. For example, old
correspondence might be put onto a disk for archiving purposes. Thus, you could create a
list of all files and file descriptions which could be returned to the active users.
2.3.7 (U) Recertification/Reaccreditation Phase
As required by the DAA/DAA Rep, a system must be recertified/reaccredited whenever security
changes occur in the LOC and PL, technical or non-technical security safeguards, threats to the
system, operational environment, operational concept, interconnections, or any other significant
increases in the level of residual risk. This process includes: a review of existing security
documentation to verify that these documents still accurately represent the system, a reevaluation
of the system vulnerabilities, threat and risk, and a complete security test, or subset of the original
security test will be conducted. Even if no security-significant changes occur,
recertification/reaccreditation of a system must be re-evaluated every three years after the issuance
of an accreditation. Site Based accreditation provides for continued reevaluation.
2.3.8 (U) Disposal Phase
When an IS is no longer needed disposition can occur in several ways.
· purging information residue from an IS or a component
· releasing the IS or a component for reuse within the Intelligence Community
· destroying an IS or a component through authorized channels, or
· the method of shipment for an IS or component.
DAA/DAA Rep and the appropriate data owners must approve all of the above actions. While
emergency destruction of an IS is a possibility that occurs during the normal operational phase, it is
considered a special case during the disposal phase.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
20
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 3 - SIGNALS INTELLIGENCE (SIGINT) SYSTEMS ACCREDITATION PROCESS
AND PROCEDURES
3.1 (U) PURPOSE
This chapter provides certification and accreditation processing guidelines and procedures for
cryptologic information systems that process information under the purview of the Director,
National Security Agency (DIRNSA). It does not apply to intelligence information systems that fall
under the cognizance of other PAA’s such as the Director, Defense Intelligence Agency (DIA).
3.2 (U) SCOPE
These procedures are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
YES
DESIGN PHASE
YES
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
YES
3.3 (U) DISCUSSION
3.3.1 (U) Accreditation
Accreditation is the official management decision to permit operation of an Information System
(IS) in a specified environment at an acceptable level of risk, based on the implementation of an
approved set of technical, managerial, and procedural safeguards.
3.3.2 (U//FOUO) NISCAP
The NSA/CSS Information Systems Certification and Accreditation Process (NISCAP) is the
NSA/CSS structured engineering process for achieving security certification and accreditation for
systems designed to process information under the purview of the DIRNSA. In accordance with
NSA/CSS Manual 130-1, all SIGINT systems must be formally accredited under the NISCAP
before they can be declared operational and allowed to process, store, transmit, or receive data of
any classification. The NISCAP facilitates compliance with the separate Certification and
Accreditation (C&A) policies of the Intelligence Community (IC) and the DoD. This process as
collaborated in the DK1 NISCAP Guide will be followed by Program Managers (PM), System
Developers and all other C&A participants to ensure that systems under development or
undergoing modifications are certifiable and accreditable for use in environments where DIRNSA is
the PAA.
3.3.3 (U) Configuration Management
The accreditation process and associated security concerns are integral to configuration
management enforcement. Therefore, ISSPM, ISSMs or ISSOs will be included in configuration
management decisions to ensure systems are fielded or modified within acceptable risk parameters
and the latest security technology is incorporated into system designs. This participation is very
important at the Preliminary Design Review (PDR) and the Critical Design Review (CDR). Where
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
21
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
there is no formal configuration management process in an acquisition or system modification, the
PM will coordinate all relevant activities with the accreditation authority.
3.4 (U) NISCAP FLOW
Figure 3.1, graphically depicts the NISCAP. As the figure indicates, the process may be initiated
from one of three different logical points: Unit, SCE, and the NSA/CSS.
PL =3, 4 & 5, or I L o C =High, A L o C =H igh
Initial
CA Agent(DK13)
CA System
Contact:
Certification
Certification
-Unit
-SCE
ISSPM
DAARep
DAARep
-N SA/CSS
ISSM
SSP
DAA
o r D AA
Certification
ISSOs
ISSO
R ep
Cert.
A TO
Reaccredit
Ac cred it atio n
and
Phase 0
De cisio n
Phase 1
ISSMs
Pkg
IA TO
Start
System
Phase 4
Phase 1
C ertification:
Phase 2 & 3
PL =1 & 2, wi th
ILoC =Basic/M ed, ALoC =Bas ic/M ed
Figure 3.1 (U) National Security Agency/Central Security Service Information System Certification
And Accreditation Process
3.4.1 (U) General Accreditation Approvals
The NSA/CSS DAA has delegated to the DAA Representatives the authority to accredit systems
that operate at Protection Level 1 (PL 1) or Protection Level 2 (PL 2). This includes granting either
an Approval to Operate (ATO) or an Interim Approval to Operate (IATO). Before a cryptologic IS
can be granted an ATO, a site visit by the DAA/DAA Representative is required. Activities during
the site visit include testing and evaluation of the system’s security safeguards/controls in it’s
operational environment and assessment of the organization’s security procedures. The DAA
representative may use the Site Accreditation Visit Checklist, Appendix F (NSA/CSS NISCAP
Guide) as a guide. If, following the site visit, the DAA/DAA Representative determines that
sufficient security safeguards exist, the system is in compliance with DCID
6/3 security
requirements, and it operates at an acceptable level of risk, a three-year ATO is normally granted.
3.4.2 (U) Interim Approval to Operate (IATO)
The DAA Representative may issue an IATO for a PL 1 or PL 2 system, to allow it to operate until
a site visit can be scheduled, provided sufficient safeguards are documented in the System Security
Plan (SSP). The DAA/DAA Representative may also issue an IATO for a PL 1 or PL 2 system if,
during the site visit, minor security deficiencies are identified and the organization requires time to
implement corrective measures. A follow-up site visit to verify that the deficiencies have been
corrected may or may not be required; this is at the discretion of the DAA/DAA Representative.
Interim approvals to operate may be issued for a period of up to 180 days. If required, the
DAA/DAA Representative may extend the IATO one time for an additional 180 days. The initial
IATO and extension cannot exceed a total of 360 days.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
22
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
3.4.3 (U) Reaccreditation
When security-relevant changes, as determined by the ISSPM, are made to an accredited IS, the
SSP and other NISCAP documentation must be updated by the ISSO/ISSM to reflect the
change(s) and resubmitted by the ISSM to the appropriate DAA Representative. Failure of an ISSO
or ISSM to identify system changes in the SSP and other NISCAP documentation may result in the
system’s accreditation being rescinded. The following are examples of changes that are grounds for
re-accreditation:
· The Central Processing Unit (CPU) and/or operating system changes.
· The IS is relocated to another area or TEMPEST zone.
· The IS Protection Level (PL) changes.
· The Accredited Security Parameter (ASP) changes.
· The IS is connected to another IS or network.
· Users, whose clearances are not commensurate with the classification of the IS, are added
to the network.
3.4.4 (U) Rescinding Accreditations
The DAA/DAA Representative may rescind the accreditation of an Information System (IS), if
violations are identified. There are, however, some system changes that do not constitute the need
for rescinding an accreditation. They are as follows:
· The substitutions of similar components while components are in maintenance. However,
if the original CPU is not returned to the Information System
(IS) when repair is
completed, then an update to the SSP must be accomplished to reflect the correct make,
model, and serial number of the replacement CPU.
· The addition of new terminals (of same configuration), peripheral devices, or relocation of
an Information System (IS) providing the SSP is updated within 90 days to reflect the
system additions or relocation. These actions can only be done with appropriate
coordination (TEMPEST, Physical Security Office, etc.) and with ISSM approval.
3.4.5 (U) Accreditation Three-Year Anniversary Review
Each IS accreditation will be reviewed every three years. The ISSM is responsible for ensuring that
the recertification and reaccreditation of each accredited IS is completed upon its
3-year
anniversary. The SSP and other NISCAP documentation will be updated to reflect any
undocumented changes and will be coordinated with ISSPM and forwarded to the appropriate
DAA/DAA Representative for accreditation.
3.4.6 (U) Information Systems (IS) Exempted from Accreditation under NISCAP
Computers that have never been exposed to, contained, or processed cryptologic information are
exempt from accreditation under NISCAP. The following listed types of equipment/systems may be
exempt provided they have never been exposed to, contained or processed Cryptologic
information:
· Computerized test equipment.
· Computers used in driving drill presses and their operations.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
23
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· Computers used in engraving devices or machines.
3.4.7 (U) TEMPEST
Refer to Chapter 5 for applicable TEMPEST procedures involved with IS accreditation. It is
imperative that all cryptologic ISs operate with appropriate approval and with the security controls
necessary to protect the information they process. The ISSOs, ISSMs, ISSPMs and DAA
Representatives will ensure that certification and accreditation processes and procedures as defined
in NISCAP are followed.
3.5 (U) Requests for Accreditation
Accreditation Process at SCE Sites/Units
ISSO - Develops SSP, inputs data into the
DAA/DAA Representative -
NCAD database and coordinates:
Approval/Disapproval then forwards back to
•
Tempest Review
ISSM.
•
Facility/Physical Area Review
•
Network Manager Review
•
COMSEC Review
•
Preparation of all other required
NISCAP documentation
ISSM - Maintains SSP approval and
provides copy to ISSO
ISSM - Reviews the SSP and NISCAP
documentation for accuracy and
completeness then forwards to HQ Level
ISSO - retains the SSP for systems under
ISSPM.
their security control.
ISSPM - Assigns a number to the SSP
in the NCAD database.
Figure 3.2 Accreditation Process at SCE Sites/Units
3.5.1 (U) Accreditation Requests Initiated at the Unit Level for PL 1 and PL 2 ISs with only
Basic/Medium Integrity Level of Concern (ILoC)/Availability Level of Concern (ALoC)
When an ISSO/SA becomes aware that a new PL 1 or PL 2 Information System has only
Basic/Medium ILoC/ALoC and is going to be obtained through NSA approved acquisition
channels, the following should occur. A NISCAP Phase 1 meeting will be held and a Phase 1
Meeting Checklist (Appendix E of the NISCAP Guide) completed. As the details of the IS become
available, the required NISCAP documentation, which includes an SSP for the new system, is to be
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
24
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
developed by the ISSO, coordinated through appropriate channels (TEMPEST Officer, SCIF
Manager, Physical Security Office), entered into the NSA/CSS Certification Accreditation
Database (NCAD), and forwarded to the ISSM for review. The ISSM ensures that the SSP has
been properly coordinated, and that the SSP and other NISCAP documentation are accurate and
complete. Once entered into the NCAD Database, the SSP and documentation is electronically
forwarded by the ISSM to the appropriate ISSPM who does a final review of the SSP, provides the
SSP a number and forwards it along with the other NISCAP documentation to the DAA
Representative.
3.5.1.1 (U) ISSM review of PL 1 and PL 2 Documentation
It is essential that the ISSM review the PL 1 and PL 2 SSPs and all other NISCAP documentation
before forwarding to the HQ ISSPM to ensure that the SSP is complete and accurate. If, during the
review process, the DAA Representative finds relevant data missing or not clearly defined, he/she
may non-concur and send the SSP and/or other NISCAP documentation back to the ISSM for
correction. This can create delays that impact operational requirements.
3.5.2 (U) Accreditation Requests Initiated at the Unit Level for PL 3, PL 4, PL 5
When an ISSO/System Administrator (SA) becomes aware that a new PL 3, PL 4, PL 5 or High
ILoC/ALoC IS is being planned for fielding under their purview, the following should occur. The
ISSO/SA must inform their ISSM who in turn will inform their ISSPM. The ISSPM will inform
their DAA Representative as well as the NSA/CSS Senior Information Systems Security Program
Manager (SISSPM), Chief DK14. The SISSPM is directly responsible for administrative and
operational actions regarding key component, SCEs and regional ISSPMs. The SISSPM will
provide NISCAP guidance, ensure that the process is properly initiated and ensure that the
Program Management/Project Office is pursuing certification and accreditation of the system in
accordance with NISCAP.
3.5.3 (U) Downward-Directed Accreditation from Program Management/Project Offices
For cryptologic ISs being fielded under the cognizance of a program management or project office,
the fielding office must ensure the fielded system is certifiable and meets regulatory requirements. It
is also the fielding program management or project office’s responsibility to provide the recipient
organization with an SSP and all other required C&A documentation pertinent to the system and its
operation. The organization’s ISSO/ISSM is responsible to add any site or personnel specific
information to complete the SSP and or other documentation and then forward it to the appropriate
DAA Representative. The fielding organization must coordinate Information System specific issues
with the site ISSO/ISSM well in advance of the installation (90 days) if immediate operation is
critical.
To assist and expedite system installation and operation, the Program
Management/ISSO/ISSM will ensure the following guidelines are met:
· The program management/project office fielding the system notifies the recipient organization 90
days prior to scheduled installation and provides accreditation documentation.
· The program management/project office provides prior to, or at time of installation, an
accreditation letter issued by the DAA Representative.
Note: The Commander/Commanding Officer/SIO and/or organization ISSO/ISSM may deny
access, or refuse country clearance, if overseas, to any team installing an IS without proper
certification and accreditation documentation and prior coordination.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
25
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
3.5.4 (U) Accreditation Requests Initiated at a Single-Service Site
When processing SSPs for PL 1 and PL 2 cryptologic Information Systems
(IS), with a
Basic/Medium ILoC/ALoC, located in an organization controlled by one military authority for
SCIF management, TEMPEST, IS and network security, the SSPs will be handled and coordinated
through that authority’s chain of command. Accreditation of PL 1 and PL 2 cryptologic ISs, with
only a Basic/Medium ILoC/ALoC, that belong to a particular SCE can be granted by a NSA
approved DAA Representative. When processing PL 3, PL 4, PL 5, and High ILoC/ALoC
cryptologic ISs, the NSA/CSS SISSPM is to be contacted to ensure that the certification and
accreditation of the system is accomplished in compliance with NISCAP.
3.5.5 (U) Submission of the SSP and NISCAP documentation
A PL 1 or PL 2 cryptologic IS, with a Basic/Medium ILoC/ALoC, cannot be operated without the
approval of the appropriate DAA Representative. PL 3, PL 4, PL 5 and High ILoC/ALoC ISs
require approval by the NSA/CSS DAA/PAA prior to them being operated. An SSP must be
developed, coordinated, entered into NCAD, and all other required NISCAP documentation
submitted to the DAA Representative. The SSP and other NISCAP documentation should be
submitted not later than 60-90 days prior to the desired Initial Operational Capability (IOC). If the
system is in the development stage (NISCAP Phase 2), the SSP and other NISCAP documentation
should be submitted during the development process.
3.5.6 (U) Format and Content
The SSP format, as presented by NCAD, will be used for the submission of all cryptologic
information system SSPs. The format and content of the other NISCAP documentation will be in
accordance with the templates contained in the NISCAP Guide. The minimum Classification of
SSPs and documents for cryptologic Information Systems is CONFIDENTIAL.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
26
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 4 - DODIIS SITE-BASED ACCREDITATION AND SYSTEM CERTIFICATION
4.1 (U) PURPOSE
The DoDIIS Information Assurance Program has two components: The DoDIIS Systems Security
Certification and Accreditation Process and the DoDIIS Site-Based Accreditation Methodology.
This applies to all systems that process, store, or communicate intelligence information under the
purview of the Director, DIA. Note: This chapter does not apply to intelligence information
systems under the cognizance of the Director, NSA/CSS. The DoDIIS Systems Security
Certification and Accreditation (C&A) Process addresses information systems being developed or
undergoing modification that is evaluated prior to being fielded to DoDIIS sites. The DoDIIS
Security Certification and Accreditation Guide describes the process for determining the
appropriate security requirements that the new or modified system must meet, provides information
on the requisite security documentation needed to support system security certification, and
outlines the process for testing and fielding systems within the DoDIIS community. All Information
Systems within DoDIIS will be tested and evaluated prior to achieving approval to operate or being
granted formal certification and fielding to a DoDIIS site. The DoDIIS Site-Based Accreditation
Methodology examines and establishes a baseline of all eligible information systems within a
defined area, and designates this as a “Site”. The Command authority for the site appoints an
ISSM, and that individual, in coordination with the cognizant Certification Organization, manages
all security related issues impacting the site’s accredited baseline. Details of the Site-Based
Accreditation Process can be found in DIAM 50-4.
4.2 (U) SCOPE
These procedures are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
NO
DESIGN PHASE
NO
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
YES
4.3 (U) SYSTEM CERTIFICATION AND ACCREDITATION PROCEDURES:
4.3.1 (U) System Certification and Accreditation Compliance
The DoDIIS Security Certification and Accreditation Guide requires that all ISs be certified and
accredited to ensure the IS meets the documented security requirements and that the security of the
IS, as accredited, is maintained throughout its life cycle. The certification process validates that
appropriate Levels-of-Concern for Integrity and Availability and an appropriate Protection Level
have been selected for the IS from the descriptions in DCID 6/3 and the required safeguards have
been implemented on the IS as described in the associated security documentation. The DoDIIS
security certification and accreditation process has been harmonized with the DoD Information
Technology Security Certification and Accreditation Process (DITSCAP).
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
27
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
4.3.2 (U) System Certification and Accreditation Process
4.3.2.1 (U) Phase 1
Definition - Focuses on understanding the IS requirement, the environment in which the IS will
operate, the users of the IS, the security requirements that apply to the IS, and the level of effort
necessary to achieve accreditation. The objective of Phase 1 is to agree on the intended system
mission, security requirements, C&A boundary, schedule, level of effort, and resources required for
the certification effort. This information is captured in the SSAA/SSP, which is developed by the
PM.
4.3.2.2 (U) Phase 2
Development and Verification - Focuses on the system development activity and ensures that the
system complies with the security requirements and constraints previously agreed during definition
phase.
4.3.2.3 (U) Phase 3
Validation and Testing - Confirms compliance of the IS with the security requirements stated in the
SSAA/SSP. The objective of this phase is to produce the required evidence to support the DAA in
making an informed decision whether or not to grant approval to operate the system with an
acceptable level of residual security risk. This includes system testing (Alpha, Beta-I and Beta-II).
4.3.2.4 (U) Phase 4
Post Accreditation - This phase starts after the system has been certified and accredited for
operation. The Post Accreditation phase includes several activities to ensure an acceptable level of
residual security risk is preserved. These activities include security documentation, configuration
management, compliance validation reviews, and monitoring any changes to the system
environment and operations. Changes to the security configuration of the system will require
security review by the DAA.
4.3.3 (U) DoDIIS Certification and Accreditation for Exercise or Experiment Scenarios
The DoDIIS certification process for exercise/experiment will vary somewhat from the standard
requirements. Lessening of the requirements for exercises/experiments is based on time/risk
limitations, on the limited duration, and consequences from security incidents should be negligible,
since most information being processed will be exercise traffic. Any approval or IATO is for the
duration of the exercise/experiment only. An IATO is not to be construed as an automatic approval
for future operational use, unless otherwise specified by approving authority. The criteria for
determining which requirements apply are based on
1. Simulated Network
(i.e., no live
connections); 2. JWICS live only; and 3. Live JWICS and other networks. The following gives a
break out of the requirements for differing criteria
4.3.3.1 (U) Simulated Network Connectivity
If the exercise/experiment architecture is using simulation network connectivity (i.e., simulated
JWICS (SCI), SIPRNET (Secret), etc.), then the requirements will be as follows:
· SSAA (Abbreviated per SCO/Local ISSM)
· System Architecture/Diagrams
· Local ISSM review (Local ISSMs can review/approve PL2 exercise systems with SCO
concurrence)
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
28
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· SCO concurrence
4.3.3.2 (U) JWICS Connection
If JWICS only connection, above applies in addition to below:
· DIA Concurrence
4.3.3.3 (U) Exercise Use of Multiple Operational Network Connectivity
If the exercise/experiment will be using more than one operational/live network connections with
limited duration, the following requirements apply:
· SSAA (SRTM, Test Procedures, TFM, etc. is abbreviated per SCO/DIA)
· System Architecture/Diagrams
· MOAs if interconnections
· SCO recommendation
· DAA concurrence/approval
4.4 (U) SITE-BASED ACCREDITATION METHODOLOGY
4.4.1 (U) Site-Based Accreditation Methodology Compliance
The DoDIIS Site-Based Accreditation Process uses management techniques to assess risk by
establishing a security domain called a “DoDIIS Site”. This concept incorporates Site Security
Management as a function of the DoDIIS Site’s CM process. A DoDIIS Site Security Baseline
defining the systems infrastructure is required and any changes to the baseline must be documented
in a timely manner. Before a DoDIIS site can establish a Site Security Baseline and be accredited,
all system(s) must go through the security C&A process. The Site Security Baseline begins with the
evaluation and accreditation of all individual ISs at the site. All ISs are then consolidated into this
single management entity and evaluated as part of the security environment in which they operate.
Site-Based Accreditation examines the ability of the organization to maintain a secure site baseline
and environment. The maturity of site security policies, procedures, configuration management,
system integration management, and risk management determines the site’s ability to successfully
establish and control a secure baseline. The certification process has a number of steps which, once
successfully completed, will result in a Site Accreditation by the Director, DIA (DIRDIA), the PAA
for all DoDIIS sites. DIAM 50-4 describes the step-by-step process to perform the Site-Based
Accreditation and identifies documentation required to be maintained at the site. Under Site-Based
accreditation, the responsible DAA Rep/SCO will have already certified intelligence mission
applications entering the site. All other agency systems are considered “Guest” systems at the site
(See below for additional guidance on Guest systems).
4.4.2 (U) The Site-Based Accreditation Process
The Site-Based Accreditation process consists of the following:
4.4.2.1 (U) Initial Site Visit (Initial Site Certification Visit)
A Certification Team will initiate the accreditation process by visiting the site. The purpose of this
visit is to gather important baseline information. This function may be incorporated or combined in
the Site Accreditation and Site Security and Engineering Certification Testing and Evaluation.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
29
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
4.4.2.2 (U) Site Evaluation Visit
This visit is essentially a Site Security and Engineering Certification Testing and Evaluation and
Site Accreditation, and will normally be conducted within 60-90 days following the Initial Site
Certification Visit. However, if the site has its site documentation, baseline, and security posture in
order, it may be performed during the initial visit. It will consist of system security certification
testing and/or security documentation review on each system.
4.4.2.3 (U) Site Compliance Visit (Vulnerability Assessment and Compliance Verification)
This visit includes a vulnerability assessment of the networks, ISs, and linked operational elements.
Assessments may be performed remotely or onsite. During official site visits the DAA Rep/SCO
ensures that the site properly maintains control of the site security baseline. Vulnerability
Assessment and Compliance Verification are normally conducted simultaneously as required.
4.5 (U) CONTRACTOR ACCREDITATION
Contractor facilities will not be site-based. Contractors will submit accreditation documentation
IAW the National Industrial Security Program (NISP) Operating Manual (NISPOM) and the DCID
6/3, Protecting Sensitive Compartmented Information Within Information Systems, Industry
Annex, 12 Apr 02.
4.6 (U) ACCREDITATION REVIEW
The ISSM is responsible for ensuring that the certification/recertification of each accredited IS is
kept current based on the DoDIIS Security Certification and Accreditation Guide. The
accreditation security documentation package will be updated to reflect any changes and will be
coordinated internally and forwarded to the appropriate SCO.
4.6.1 (U) Guest Systems in a SCIF
SCIFs are accredited under the authority of either DIA or NSA. Any system that enters the SCIF that has
not already been certified or accredited by the respective cognizant SCIF authority is considered a Guest
system. These guest systems may be brought into the SCIF only at the discretion of the cognizant authority
and the local SSO/ISSM/ISSO as long as prudent IS Security measures and documentation are in place.
An SSO is responsible for all resident SCI information, including that which exists on IS within a SCIF.
The ISSM/ISSO supports the SSO in all security matters related to IS, and the DAA who accredits SCI
systems within that SCIF is directly associated with the authority that established the SCIF, i.e., the
cognizant DAA. Systems that process SCI under the cognizance of DIA and NSA have clear guidance as
provided within this document. The following are three examples of guest systems:
· SCI or SAPI systems already certified by another PAA;
· SCI systems that have no existing certification; and
· Unclassified systems or systems with classification levels lower than SCI.
4.6.1.2 (U) SCI Systems with Certification
Within the DCID 6/3 community of PAAs, there is common acceptance of system accreditation and
certification for systems that process SCI/SAPIs. These systems may be brought into a SCIF along with
the certification documents provided by the PM/PMO so that the SCIF cognizant DAA may accredit the
systems as they are connected to existing architectures. The ISSM will ensure that appropriate system
documentation from the PM/PMO is available to the DAA/DAA Rep/SCO to support the accreditation
prior to the system installation. If the guest systems will operate independently (not connecting to or
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
30
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
through existing architectures), the SSO/ISSM may accept the systems with accreditation as delivered and
document the presence of these systems on configuration management architectures.
4.6.1.3 (U) SCI Systems without Certification
For SCI systems that do not have existing certification, the PM/PMO will provide appropriate documents
for SCI Security certification and accreditation IAW Chapters 3 or 4.
4.6.1.4 (U) Unclassified or Collateral Systems
Non-SCI systems that are to be operated within a SCIF also require a certification/accreditation. These
systems may be certified/accredited by an appropriate authority other than the cognizant SCI DAA. When
the local Commander/SSO authorizes such systems to enter the SCIF and operate, then a coordinated
policy/agreement should be established that addresses the security and operational interests of the different
DAAs. The PM/PMO will deliver accreditation documentation for the systems to the SSO/ISSM with the
request to install.
When a decision is made to allow GENSER or unclassified systems into a SCIF, a policy/agreement must
be developed and documented by the SSO/ISSM. The SSO and ISSM are responsible for implementing
appropriate security operating procedures before the respective systems/networks are permitted to enter
the SCIF. These procedures will need to address IS security issues not already documented. The following
are recommended issues to be included within the local procedures:
· Define the extent that the SSO/ISSM will have purview over the other DAA’s systems while they
are operated within the SCIF. This is an item that can be addressed in a MOA.
· Define the authority responsible for the respective systems and the SSO who retains oversight
responsibility for SCI data within the SCIF.
· Document the coordination between SSO/ISSM in establishing the SCI controls for systems within
a SCIF.
· Document TEMPEST countermeasures (e.g., update Fixed Facility Checklist and RED/BLACK
separation compliance with Inspectable Space Determination).
· Develop an SOP for managing systems/media that are allowed to enter/depart the facility on a
regular or recurring basis.
4.7 (U) MINIMUM SECURITY REQUIREMENTS
All DoDIIS systems and networks processing SCI will be protected according to DCID 6/3 by the
continuous employment of appropriate administrative, environmental, and technical security
measures. These measures will encompass individual accountability, access control, enforcement of
least privilege, auditing, labeling, and data integrity.
4.7.1 (U) SSAA Content Classification
The minimum classification of a completed SSAA for DoDIIS information systems is
CONFIDENTIAL.
4.8 (U) CERTIFICATION (IATO) AND ACCREDITATION (ATO) AUTHORITY
The following guidance is given and is depicted in table as Figure 4-1 below.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
31
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
4.8.1 (U) Certification and Accreditation Authority for Protection Level 1 and 2
Certification and accreditation authority for Protection Level
1 and 2 information systems is
delegated to the Service Certifying Offices (SCOs). Certification authority for Protection Level 1
and 2 information systems may be further delegated to Site Information Systems Security Managers
(ISSMs) by the SCOs. SCO further delegation of authority shall be limited to systems or system
baselines previously certified and/or accredited by a SCO, DIA, or other PAAs as identified in the
DCID 6/3.
4.8.2 (U) Certification and Accreditation Authority for Protection Level 1, 2 and 3
Certification and accreditation authority for Protection Level 1, 2 and 3 information systems are
hereby delegated to the Chief of the DIA Information Assurance Division (DIA/SYS-4).
· SYS-4A Certifiers are delegated certification (IATO) and accreditation authority (ATO) for PL 1
and 2. (Under normal circumstances, management [i.e., SYS-4 or SYS-4A] should sign all ATOs).
· SYS-4A Certifiers are delegated certification (IATO) authority PL 3.
4.8.3 (U) Certification Authority for Protection Level 4 and 5
Certification authority for Protection Level 4 and 5 information systems is hereby delegated to the
DIA/SYS-4. Certification authority for Protection Level 3 and 4 information systems may be
further delegated by DIA/SYS-4 to the SCOs on a case by case basis.
· SYS-4A Certifiers are delegated certification (IATO) authority for PL 4.
4.8.4 (U) Certification Authority for DoDIIS Site Baselines
Certification authority for DoDIIS Site Baselines is hereby delegated to the Chief of the DIA
Information Assurance Division (DIA/SYS-4) and the SCOs.
· SYS-4A Certifiers are delegated certification (IATO) authority for Site Baselines.
4.8.5 (U) Accreditation Authority for Protection Level 4, 5 and DoDIIS Site Baselines
The DIRECTOR DIA, for Protection Level 4 and 5 information systems and DoDIIS Site
Baselines, retains accreditation authority (ATO).
4.8.6 (U) Interim Approvals To Test (IATT)
All certifiers are authorized to grant Interim Approvals to Test (IATT). IATTs basically give
authorization to test in a controlled environment only (e.g. test lab/controlled site) for a specified
period of time, usually of a short duration. The IATT can be issued for testing in an operational
environment for specific connection(s), data testing, etc.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
32
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
PL1
PL2
PL3
PL4
PL5
Site Base
IATO
ATO
IATO
ATO
IATO
ATO
IATO
ATO
IATO
ATO
IATO
ATO
DIR/DIA
A
A
A
Chief, SYS-4
I
A
I
A
I
A
I
I
I
SYS-4
I
A
I
A
I
I
I
SCO
I
A
I
A
I*
I*
I
ISSM
I*
I*
Figure 4-1: IATO/ATO Authority
· IATO = CERTIFICATION
· ATO = ACCREDITATION
·
* ISSM - PL1 & PL2 certification authority can be delegated by the SCO.
·
* SCO has certification authority for PL3 &PL4 ONLY as delegated by SYS-4 on a case-by-case basis.
·
SYS-4 Note: Generally, all ATOs should go through management for signature, unless operational mission, TDY,
etc., warrants immediacy.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
33
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 5 - TEMPEST
5.1 (U) PURPOSE
Information Systems (ISs), peripherals, associated data communications, and networks which may
be used to process national security or security-related information may need to meet certain
procurement and installation specifications as required by national TEMPEST policies and
procedures applicable to the sensitivity level of the data being processed. This applies to all systems
installed or planned. The objective of this area of security control is to minimize the risk of Hostile
Intelligence Services
(HOIS) exploiting unintentional emanations from intelligence systems.
TEMPEST is a short name referring to investigations and studies of compromising emanations.
5.2 (U) SCOPE
These procedures are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
NO
DESIGN PHASE
YES
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
YES
5.3 (U) DEFINITIONS
·
Certified TEMPEST Technical Authority (CTTA). An experienced, technically qualified U.S.
Government employee who has met established certification requirements IAW National Security
Telecommunications Information Systems Security Committee (NSTISSC)-approved criteria and
has been appointed by a U.S. Government Department or Agency to fulfill CTTA responsibilities
(for example; DIA/DAC-2A).
·
Compromising Emanations. Unintentional intelligence-bearing signals which if intercepted and
analyzed disclose the national security information being transmitted, received, handled, or
otherwise processed by any information processing equipment.
·
Inspectable Space. The three-dimensional space surrounding equipment that processes classified
and/or sensitive information within which TEMPEST exploitation is not considered practical or
where legal authority to identify and/or remove a potential TEMPEST exploitation exists.
·
Routine Changes. Changes that have a minimal effect on the overall TEMPEST security of the
Sensitive Compartmented Information (SCI) Facility (SCIF). Adding a different type of electronic
information processing equipment (unless the equipment added is known to have an unusually large
TEMPEST profile), movement of the equipment within the facility, and minor installation changes
are examples of routine changes.
·
Security Environment Changes. Changes that have a detrimental effect on the facility. Changes to
the inspectable space, addition of a radio transmitter or a modem for external communications,
removal or reduction of an existing TEMPEST countermeasure (Radio Frequency Interference
[RFI] Shielding, Filters, Control/Inspectable space, etc.) would be changes to the security
environment.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
34
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
5.4 (U) TEMPEST COMPLIANCE
All facilities processing SCI will be reviewed by a CTTA for initial TEMPEST accreditation and/or
Inspectable Space according to National Security Telecommunications Information Systems
Security Policy (NSTISSP) 300, National Policy on Control of Compromising Emanations, and
National Security Telecommunications and Information Systems Instruction (NSTISSI) 7000,
TEMPEST Countermeasures for Facilities. The CTTA is authorized to make acceptable risk
determinations for specific facilities when justified.
5.5 (U) ACCREDITATION
5.5.1 (U) TEMPEST Countermeasures Review
A CTTA must conduct or validate all TEMPEST countermeasure reviews. However, the
requirement for a CTTA to conduct or validate such reviews does not imply the need to implement
TEMPEST countermeasures. The recommended countermeasures will be threat driven and based
on risk management principles. The inspectable space, as determined by a CTTA, will be the
primary countermeasure.
5.5.2 (U) General Documentation
The local SCI security official will complete documentation IAW local TEMPEST Manager
requirements. The local TEMPEST Manager will submit documentation IAW service directives. A
record of the TEMPEST security accreditation or inspectable space determination (ISD) will be
retained within the SCIF.
5.5.3 (U) TEMPEST/ISD Accreditation
When an inspectable site houses multiple IS facilities and has a relatively protected and uniform
TEMPEST security environment, the CTTA may grant a TEMPEST site accreditation or ISD for
electronic processing of SCI. Each SCIF within the inspectable site must be evaluated separately on
its own merits and cannot be approved automatically by being inside an inspectable space. The
accreditation/ISD could range from a building to a base/post if all space is inspectable. Compliance
is reported within the SCIF Fixed Facility Checklist IAW DCID 6/9.
5.6 (U) TEMPEST INSTALLATION REQUIREMENTS:
· All computer equipment and peripherals must meet the requirements of National Security
Telecommunications Information Systems Security Advisory Memorandum (NSTISSAM)
TEMPEST/1-92 and be installed IAW NSTISSAM TEMPEST/2-95, RED/BLACK separation
criteria or as determined by a CTTA. The local TEMPEST Manager will oversee all such
installations and coordinate on all accreditation documents resulting from the installation.
· Use all equipment as intended. All TEMPEST access doors, covers, and plates must be closed and
fastened. Unauthorized modifications, even for testing purposes, are strictly forbidden.
· Additional TEMPEST requirements may exist if the equipment is not TEMPEST approved. In such
a case, your local TEMPEST Manager should be contacted for further guidance.
· The local TEMPEST Manager must inspect all equipment installations.
· Special prohibitions and installation requirements exist for all transmitters, modems, and other
networking and communications devices or equipment. Because of the broad range of this
category, coordinate all requests for these devices with your local TEMPEST Manager.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
35
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· Do not consider a RED IS for any network which has any direct connection to a BLACK IS or
other communications medium such as administrative telephone lines except through an approved
cryptographic device.
· Do not use acoustically coupled modems and transmitters or locate them in any secure area without
specific written approval from your DAA.
· You may use non-acoustic wire line modems with stand-alone, dedicated BLACK ISs providing
that all appropriate telephone security requirements are met, consult with your local TEMPEST
Manager.
· Wireless -Infrared (IR) and Radio Frequency (RF) systems. See Chapter 15 for discussion on
restrictions for use within SCIFs.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
36
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 6 - MINIMUM SECURITY REQUIREMENTS FOR USERS
6.1 (U) PURPOSE
The purpose of this chapter is to identify the minimum-security requirements for a user of
Information Systems. This chapter is designed so that it may be used as a general user reference for
IS security training and awareness.
6.2 (U) SCOPE
This chapter identifies the minimum-security requirements for a general user necessary to operate
an IS. These requirements are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
YES
DESIGN PHASE
YES
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
YES
6.3 (U) MINIMUM SECURITY REQUIREMENTS
Users of ISs connected to networks shall use the system for official and appropriate use only.
Personal use of a government IS must be approved by the user’s supervisor IAW local policies.
6.3.1 (U) Identification and Authentication Requirements
Individual accountability is required for all users of IS that process SCI information. An IS user is
identified through a unique USERID and a corresponding authenticator. The uniqueness of the
USERID facilitates auditing and access controls. Group accounts (shared access through a single
USERID) are prohibited unless the DAA approves this as an exception. An authenticator may be
something the user knows, something the user possesses, or some physical characteristic about the
user. The most common authenticator is a password. Users will comply with the following
requirements to access IS:
· Users are required to login to all systems with an assigned USERID and password.
· Users are required to logout of all systems at the end of each workday or for an extended absence.
· Screen locks are mandatory, and require a password for reentry into the system. If an IS is idle for
15 minutes, the screen lock shall be activated automatically. Screen locks are not authorized in lieu
of log-off procedures. Operations may require exceptions, which must be approved by the
ISSPM/SCO.
6.3.2 (U) Password Requirements
The following policy will be used when issuing, controlling, and changing passwords:
· Passwords must be at least eight characters in length and consist of a mix of alphanumeric and
special characters. .
· Only the user must know passwords.
· Users will not share their passwords with other users.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
37
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
·
Passwords will not be easily associated with an individual. Do not use words found in a dictionary.
Do not use nicknames, spouse names, street names, vanity plate names, parts of the SSAN,
telephone number, etc.
·
All passwords must be protected at the same security classification as the accreditation level of the
IS.
·
A password must be changed if it has been compromised or has been in use for six months or less.
·
Never write down passwords. Destroy the original password documentation following initial
review. Never type passwords onto an IS when being observed by other people.
·
Configure the minimum password age for at least 90 days, and the password history, which
determines the number of unique new passwords that have to be associated with a user account
before an old password can be reused, should have a minimum setting of five.
·
Password evaluation tools may be used by sites for security assessment. Approval must be obtained
through the ISSM.
·
The following guidelines will be used when selecting a password:
DO:
·
Include both upper and lower case characters.
·
Include digits and punctuation marks.
·
Include something that can be remembered without writing it down.
·
Consider special-acronyms (e.g. N0tf#swvw - None of this fancy # stuff works very well).
DO NOT:
· Use any form of your logon name (e.g. initials).
· Use first, middle, last or maiden names.
· Use the name of a spouse, child, girl/boy friend.
· Use anything publicly available about you (e.g. address, car license plate number, car make, SSAN,
etc.).
· Use all the same type of characters (e.g. 123245678, AAAAAAAA, etc.).
· Use a word or words from a dictionary.
· Use substitution of characters by switching ones (1) for “ells” (l) or zeros (0) for “ohs” (o).
· Use names or characters from fantasy and science fiction stories (Quagmire, etc.).
6.3.3 (U) IS Warning Banner
All systems are required to display a logon warning banner. When the user logs on to a system, the
user agrees to accept the conditions of the warning. The following applies:
· A logon warning banner is required on all networked and standalone DoD interest computer
systems (Government and contractor).
· The warning banner must be displayed before a successful logon and should include an option that
allows the user to halt the logon process and a keystroke to continue processing. The intent of the
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
38
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
banner is to confirm to the user that all data contained on DoD interest computer systems is subject
to review by law enforcement authorities, DoD security personnel, and/or System Administrator,
IAW Chapter 9. The banner is designed to inform all users, prior to accessing a DoD system, that
by logging in they expressly consent to authorized monitoring.
· ISs supporting DoD operations have very specific warning banner requirements, and must include,
at a minimum, the information shown in Figure 9.1.
· Whenever system administration personnel suspect that a system is being inappropriately used,
either by authorized or unauthorized personnel, or some improper activity is being conducted, the
matter will be reported immediately to the ISSO/ISSM. Refer to Chapter 8 for additional guidance.
6.3.4 (U) Configuration Management Requirements
The following policy will be used for the CM of all systems.
· Modifying, relocating, or reconfiguring the hardware of any computer system must be approved by
the CCB or the CMB for each site. Hardware will not be connected to any system/network without
the express written consent of the ISS0/ISSM and the CMB/CCB. ’
· Modifying, installing, or downloading of any software on any computer system may affect system
accreditation and must be evaluated and approved by the ISSO/ISSM with the local CMB/CCB.
6.3.4.1 (U) Authorized Software
Software that may be authorized includes that which has been:
· Provided officially by another U.S. Government Agency that has equivalent standards.
· Provided under contract to organizations involved with the processing of SCI and related
intelligence information.
· Developed within a Government-approved facility.
· Provided through appropriate procurement channels, i.e. COTS software.
· Distributed through official channels.
6.3.4.2 (U) Unauthorized Software
Types of software that are not authorized include:
· Games (See paragraph 11.6.).
· Public domain software or “shareware” which have been obtained from unofficial channels.
· Software applications that have been developed outside Government approved facilities, such as
those developed on personally owned computers at home or software acquired via non-U.S.
Government “bulletin boards”.
· Personally owned software (either purchased or gratuitously acquired).
· Software purchased using employee funds (from an activity such as a coffee fund).
· Software from unknown sources.
· Illegally copied software in violation of copyright rules.
· Music and video or multimedia compact disks, not procured through official Government channels.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
39
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
6.3.5 (U) Malicious Code Detection
Users of IS play a very important role in the prevention of malicious codes. For details, see Chapter
10. To actively participate in the prevention of malicious codes on an IS, users must be made
aware of, and comply with, basic security requirements. Warnings and advisories frequently provide
guidance on preventing infection from malicious code or viruses—obey these. If a malicious code is
detected or a presence of malicious code is suspected on any IS, immediately report it to the
ISSO/ISSM IAW Chapter 8. Do nothing that might cause the further spread of the malicious code.
6.3.6 (U) Malicious Code Prevention
The user is responsible for ensuring that the following procedures are followed to minimize the risk
of malicious code:
· Will not import or use unauthorized data, media, software, firmware, or hardware on systems.
· Use automated virus scanning applications on all media prior to use. If the media cannot be scanned
then it is considered high risk and cannot be used on any IS without approval from the SCO.
· Avoid hostile mobile code through use of only authorized/verified and registered mobile code.
· Will not knowingly or willfully introduce malicious code into systems.
· Will conduct screening of all incoming data (e.g., E-Mail and attachments) if this process is not
automated.
· Will not use personally owned media (e.g., music, video, or multimedia compact disks) in
Government-owned IS.
· Will immediately report all security incidents and potential threats and vulnerabilities involving
malicious code on ISs to the ISSO/ISSM.
Note: Controlled Interfaces with malicious code scanning capability do not relieve
the
management of the receiving IS from the responsibility of also checking for malicious code.
6.3.7 (U) Removable Information Storage Media
Removable information storage media with an IS will have external labels clearly indicating the
classification of the information and applicable associated markings (e.g., digraphs, trigraphs).
Examples include magnetic tape reels, cartridges, cassettes; removable discs, disc cartridges, disc
packs, diskettes, magnetic cards and electro-optical (e.g., CD) media. Labeling exemption for
operational security (OPSEC) requirements may be granted within local policy with DAA/DAA
Rep concurrence. All removable information storage media will be marked with the appropriate
Standard Form (SF) 700-series classification and descriptor labels (See Chapter 12 for a visual
depiction of each). These are:
· SF 706, Top Secret Label
· SF 707, Secret Label
· SF 708, Confidential Label
· SF 710, Unclassified Label
· SF 711, Data Descriptor (On all magnetic media)
· SF 712, Classified SCI Label (All classification levels)
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
40
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
6.3.7.1 (U) Label Placement
Labels will be affixed to all media in a manner that does not adversely affect operation of the
equipment in which the media is used. Labels may be trimmed to fit the media. Labels for Compact
Disks (CDs) must NOT be placed on the CD itself, but on the CD container or envelope. Record
the accounting number in the “Control” block of the SF 711 and write the same number on the CD
with a Paint-pen, CD label maker or permanent marker. The number should not interfere with the
operation of the CD. Notice: Do not use pens that contain toluene.
6.3.7.2 (U) Data Descriptor Label
The SF 711, Data Descriptor Label, is used to identify the content of a specific media to include
unclassified, collateral-classified, and SCI. A SF 711 is not required if the disk bears the following
information: Organization, office symbol, classification, and media sequence number (if locally
required).
The user fills in the
“Classification”,
“Dissem”,
“Control”, and
“Compartments/Codewords” blocks as appropriate.
6.3.7.3 (U) Classification Markings
All documents residing or processed on information storage media/ISs will be marked IAW DCID
6/3, Controlled Access Program Coordination Office (CAPCO) guidance “Intelligence Community
Classification and Control Markings Implementation Manual”, dated 10 Sep 1999 (Amended 21
March 2002), DoD 5105.21-M-1, dated August 1998, or appropriate Agency/Service regulations.
6.3.7.4 (U) Control and Accounting of Media
For any system that operates with PL-3 or lower functionality, media that is not write-protected
and is placed into that system must be classified at the highest level of information on the system
until reviewed and validated. Media accountability will be based on the determined classification
level of the media.
6.3.7.4.1 (U) Information Storage Media Control
In addition to the labeling of information storage media according to Chapter 12, there is a
requirement to control and account for certain information storage media within functional
categories. The organization Commander/CO/SIO is responsible for development of a unit-level
Standard Operating Procedure (SOP) for control and accountability of media.
6.3.7.4.2 (U) Inspections
The organization must be able to demonstrate positive control and accounting of information
storage media according to its SOP when reviewed by inspection authorities.
6.3.7.4.3 (U) Control Procedures
Control of information storage media should begin upon introduction into the organization
according to the SOP.
·
(U) Information storage media accountability is required for Top Secret BRAVO and permanent
Collateral Top Secret files.
·
(U) Information storage accountability as a security protection measure is eliminated for collateral
classified information (to include Top Secret non-permanent files), all classification levels of Special
Intelligence (SI) (to include GAMMA and ENDSEAL), Talent-Keyhole (TK), and BRAVO
material below Top Secret.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
41
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
·
(U) The respective Program Manager will define requirements for controls of specific Special
Access Program (SAP) information.
6.3.7.4.4 (U) Other Categories of Storage Media
The following major categories of information storage media should be considered for
accountability control in compliance with copyright and licensing with procedures documented in
the SOP:
· COTS and vendor software.
· Government developed software.
· Other organization unique software and data.
6.3.8 (U) Hardware Labeling Requirements
Labels will be displayed on all components of an IS. This includes input/output devices that have
the potential for retaining information, terminals, standalone microprocessors, and word processors
used as terminals, bear conspicuous external labels stating the highest classification level and most
restrictive classification category of the information accessible to the components in the IS. The
labels should be the standard form (SF) 700 series media classification labels or equivalent (see
Chapter 12). The labeling may consist of permanent markings on the component or a sign placed on
the terminal.
6.3.9 (U) Security Training Requirements
An integral part of the IS security program is the mandatory training required by public law. Users
will receive initial training on prescribed IS security restrictions and safeguards prior to accessing
corporate IS assets. General users require system security training to safeguard systems and
information on those systems/networks, contact the local ISSM. As a follow-up to this initial
training, users must be provided, and actively participate in an ongoing security education, training,
and awareness program which will keep them cognizant of system changes and associated security
requirements as they occur. General users training will include but is not limited to the following:
· An awareness of system threats, vulnerabilities, risks, system data, and access controls associated
with the IS being used.
· How to protect the physical area, media, and equipment (e.g., locking doors, care of diskettes).
· How to protect authenticators and operate the applicable system security features (e.g., setting
access control rights to files created by user).
· How to recognize and report security violations and incidents see Chapter 8.
6.3.9.1 (U) Security Awareness and Training Program
The key to protecting Information Systems (ISs) & Networks and the information they process is
the development of an effective Security, Education, Training and Awareness Program. The
program is intended to provide two levels of knowledge:
6.3.9.1.1 (U) Awareness Level
Creates sensitivity to the threats and vulnerabilities of national security information systems, and
recognition of the need to protect data, information and the means of processing them; and builds a
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
42
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
working knowledge of principles and procedures in IA. Awareness level training will be conducted
when:
· In-processing. Site specific information will be briefed based on the mission and the requirement of
the job responsibility.
· Receipt of USERID and Password. Privilege User/ISSO will brief the user on his/her
responsibilities.
· Annual Awareness Refresher Training. Classroom, Briefings, Computer Based Training, or
Seminars will be used and documented to ensure all users comply with this requirement.
6.3.9.1.2 (U) Performance Level
Provides the employee with the skill or ability to design, execute, or evaluate agency IA security
procedures and practices. This level of understanding will ensure that employees are able to apply
security concepts while performing their tasks.
6.3.9.1.3 (U) General Users training
General users training will include but is not limited to the following:
· How to protect the physical area, media, and equipment (e.g., locking doors, care of diskettes).
· How to protect authenticators and operate the applicable system security features (e.g., setting
access control rights to files created by user).
· How to recognize and report security violations and incidents.
· The organization’s policy for protecting information and systems.
6.3.10 (U) Destruction of Media
When destruction of information storage media is required, it must be accomplished IAW approved
procedures and the organization’s media accounting system must be updated to reflect this change.
See Chapter 21, Paragraph 21.5.4 Destroying Media, for additional guidance.
·
(U) Destruction certificates are required for accountable material and will be retained as a
permanent record.
·
(U) Non-accountable material no longer requires destruction certificates.
6.3.11 (U) Information Transfer and Accounting Procedures
Users should be knowledgeable of procedures for the transfer of information or software among
ISs of different classification levels using information storage media. Contact the ISSM for local
procedures. The procedures are intended to protect the confidentiality of information on the media
as well as other data on the end-point IS at different levels, prevent transfers of malicious code
(Chapter 10 is germane), and prevent violation of legal copyright or license rights. For any system
that operates with PL-3 and below functionality, media that is placed into that system must be
classified at the highest level of information on the system until reviewed and validated. See
Chapter 18.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
43
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 7 - SECURITY GUIDELINES FOR THE PRIVILEGED USER
7.1 (U) PURPOSE
The Privileged User is assigned by management personnel (at NSA/CSS the Office of Security
approves Privileged User) and is the single point of contact for the administration of a specifically
defined Information System
(IS). The privileged user is responsible for maintaining the IS
throughout day-to-day operations, ensuring that the system operates within established
accreditation criteria, and keeping the system in an operational mode for general users. System
administration personnel are the primary interface between the users of an IS and the organization’s
Information Systems Security (ISS) management personnel. This chapter provides the privileged
user with the security guidance and procedures necessary to implement an effective System
Administration program.
7.2 (U) SCOPE
These procedures are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
NO
DESIGN PHASE
YES
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
YES
7.3 (U) SECURITY TRAINING
The individual assigned the responsibility for IS administration must be knowledgeable in the basic
security concepts and procedures necessary to effectively monitor IS activity and the environment
in which it operates. Contact the ISSM for applicable training.
7.3.1 (U) Privileged User training
Privileged user training will include but is not limited to the following:
· How to protect the physical area, media, and equipment (e.g. locking doors, care of diskettes, etc.)
· Understand security consequences and costs so that security can be factored into their decisions.
· Have a thorough understanding of the organization’s policy for protecting information and systems,
and the roles and responsibilities of various organizational units with which they may have to
interact.
· Have a thorough understanding of system security regulations and policies.
· Be aware of what constitutes misuse or abuse of system privileges.
· Have an understanding of how to protect passwords, or other authentication devices, and be
familiar with operating system security features of the system.
· Know how to recognize and report potential security vulnerabilities, threats, security violations, or
incidents.
· Understand how to implement and use specific access control products.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
44
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· Have an understanding of how to protect the media and equipment (e.g. system maintenance and
backup, care of diskettes).
· How to protect authenticators and operate the applicable system security features.
7.3.2 (U) Security Awareness and Training Program
The key to protecting ISs and networks and the information they process is the development of an
effective Security, Education, Training and Awareness Program. The program is intended to
provide two levels of knowledge:
7.3.2.1 (U) Awareness Level
Creates sensitivity to the threats and vulnerabilities of national security information systems, and
recognition of the need to protect data, information and the means of processing them; and builds a
working knowledge of principles and procedures in IA. Awareness level training will be conducted
when:
· Inprocessing. Site specific information will be briefed based on the mission and the requirement of
the job responsibility.
· Receipt of USERID and Password. Privilege User/ISSO will brief the user on his/her
responsibilities.
· Annual Awareness Refresher Training. Classroom, Briefings, Computer Based Training, or
Seminars will be used and documented to ensure all users comply with this requirement.
7.3.3.2 (U) Performance Level
Provides the employee with the skill or ability to design, execute, or evaluate agency IA security
procedures and practices. This level of understanding will ensure that employees are able to apply
security concepts while performing their tasks.
7.4 (U) LEAST PRIVILEGE IMPLEMENTATION
Because system administration personnel do not always have to perform functions using their fully
privileged account, therefore they should maintain a separate general user account.
7.5 (U) SCI SYSTEM SECURITY PROCEDURES
SCI IA doctrine requires many security relevant actions to properly implement a secure
environment to protect national interest information. The following procedures outline several
items that apply to all SCI ISs and must be given full consideration by system administration
personnel.
7.5.1 (U) Identification and Authentication Requirements
USERIDs are used for identification of a specific user on the IS to facilitate auditing. Group
accounts are generally prohibited; exceptions to this policy shall be approved by the DAA/DAA
Rep. Passwords (as authenticators) are used to provide an access path for authorized users while
denying access to the unauthorized user. Use the following procedures to generate issue and
control USERIDs and passwords.
7.5.1.1 (U) Documenting USERIDs and Passwords
Document the issuing of USERIDs and passwords IAW established DAA requirements and local
procedures.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
45
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
7.5.1.2. (U) USERID and Password Issuing Authority and Accountability
The ISSM or designee is the official authorized to issue the initial USERID and password to each
user of the system. The ISSM or designee will maintain a current user account roster for each
system for which they are responsible, to include the names of authorized maintenance personnel.
The roster will contain, at a minimum, each user’s:
· Never enter the assigned password of an individual on a form used to establish a user’s account.
The issuing ISSM/SA will distribute the initial password in a secure manner. The requesting
individual must authenticate that a password has been received, and the signed form must be
returned to the ISSM/SA before activation of the account. The form will be retained by the
ISSM/SA for a minimum of one year after access is removed.
· Full name, grade or rank, and Social Security Account Number (SSAN).
· Organization, office symbol, and telephone number.
· USERID.
7.5.1.3 (U) Supervisor Authorization
Obtaining supervisor approval for each individual requiring IS access. The privileged user must
ensure that all individual access authorizations are valid, need-to-know is established and access is
work-related.
7.5.1.4 (U) Access Requirements Validation
The privileged user will provide each functional area within the organization with a current general
user roster
(for that functional area only) and require that the supervisor validate all access
requirements annually at a minimum. The annual validation process will be documented.
7.5.1.5 (U) Account Management
A user account will be deactivated when that account is idle for an extended period (recommend 60
days). The loss of security clearance requires immediate deactivation of the account.
7.5.1.6 (U) Tactical/Deployable Use of group accounts
As group accounts are generally prohibited; exceptions to this policy are as follows:
· Security requirement: Individual accountability for all users requires individual accounts which can
be monitored through automated audit capabilities (see DCID 6/3).
· Operational requirement: Use of group user accounts in a tactical/watchstanding environment
allows rapid interchange between users whose primary focus is quick access to the system without
interruption of functions or capabilities. This also avoids system transients (and potential for errors
on startup) as the system is shut down and restarted for a different user to logon.
· Sample security implementation: Lists do exist for watchstander rotations or battle station
assignments, which could be retained and used to augment activity logs to correlate user identities
to actions as recorded on audit logs. Advanced alternative: Developers provide a simple pop-up
“change USERID” GUI which does not cause the system to shutdown or change operations, but
which simply changes accountability via the new USERID/password for continuing processes for
an individual member of a common functional group.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
46
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
7.5.2 (U) System Access and Removal Procedures
Access and removals from an IS must be documented IAW local procedures.
7.5.3 (U) Audit Trail Requirements
An audit trail capability must exist to obtain formal accreditation of an IS. The audit trail should be
automated, and provide permanent on-line or off-line storage of audit data separate from data files.
Audit reduction tools are highly recommended and are endorsed by DCID
6/3 paragraph
4.B.2.a(6), Audit3. Although there are no specific audit reduction tools recommended, tools such
as PReCis and TNE (Trusted Network Environment) are the type of auditing tools available.
7.5.3.1 (U) Automated Audit Trail Information Requirements
ISs approved for classified processing should contain, at a minimum, the following audit trail
records:
·
Login (Success, Failure) Logout (Success).
o Auditing of successful login and logout events is key to individual accountability.
Unsuccessful login attempts may be evidence of attempted penetration attacks. Logins and
logouts shall be audited by the underlying operating system. In addition, the syslog
mechanism may be used to notify an ISSM/SA of an unsuccessful login attempt.
o Audit data should include date, time, USERID, system ID, workstation ID, and indication
of success or failure.
·
Use of privileged commands. (Failure)
o Privileged commands are commands not required for general use, such as those that manage
security-relevant data and those that manage an application. In UNIX workstations, these
commands include, for example, the SU command, which is used to become the root user.
The UNIX root user has access to all information stored on the system. Such commands
must be accessible only to persons whose responsibilities require their use.
o The ISSM/SA shall select the privileged commands (i.e., commands normally executed by
the root user) to be audited. This event can be audited via the underlying operating system
or application audit.
o Audit data should include date, time, USERID, command, security-relevant command
parameters, and indication of success or failure.
·
Application and session initiation. (Failure)
o The use of application programs and the initiation of communications sessions with local or
remote hosts are audited to provide the ISSM/SA a general history of a user’s actions. An
unsuccessful attempt to use an application or initiate a host session may indicate a user
attempting to exceed his or her access authorizations. This event should be audited via
application audit.
o Audit data should include date, time, USERID, workstation ID, application ID, and
indication of success or failure.
·
Use of print command. (Success)
o The printing of classified and sensitive unclassified information is audited to maintain
accountability for these materials. Print commands and the identity of the printed material
should be audited via application audit.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
47
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
o Audit data should include date, time, USERID, and destination.
·
Discretionary Access Control (DAC) permission modification. (Success, Failure)
o The changing of DAC permissions on files or directories should be audited since it could
result in violations of need-to-know. This event can be audited via the underlying operating
system and/or application audit.
o Audit data should include date, time, user (requester) ID, user/group ID (to whom change
applies), object ID, permissions requested, and indication of success or failure.
·
Export to media. (Success).
o The copying of files to removable media should be audited to maintain accountability of
classified materials. Removable storage media have large capacity and could potentially
disclose large amounts of information. This event can be audited via the underlying
operating system and/or application audit.
o Audit data should include date, time, USERID, source and destination file IDs, system ID,
and device ID.
·
Unauthorized access attempts to files. (Failure)
o An attempt to access files in violation of DAC permissions could indicate user browsing and
must be audited. This event can be audited via the underlying operating system and/or
application audit.
o Audit data should include date, time, USERID, system ID, and file ID.
·
System startup/shutdown. (Success, Failure)
o System startup and shutdown shall be monitored and be auditable. This event should be
audited by the operating system.
o Audit data should include date, time, USERID, system ID, and device ID.
7.5.3.2 (U) Manual Audit Trail Implementation
If Automated Audit Trails are not supported, the ISSM/SA must obtain approval from the
ISSPM/SCO to conduct manual audits. At a minimum, manual audits will include:
· The date.
· Identification of the user.
· Time the user logs on and off the system.
· Function(s) performed.
7.5.3.3 (U) Products of Audit Trail Information
Audit trail products should be handled as follows:
· Classify and protect audit trail information according to the security classification level of
information contained in the audit.
· If hardcopy audit trail products are generated on an IS, print them on continuous paper whenever
possible. If continuous paper is not used, all pages will be numbered with a sequence number on
each printed line. This is required to protect the integrity of the audit trail data.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
48
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· Where possible, to reduce workload, generate summary reports which reflect system abnormalities,
who performed what function, and to what database, rather than listing the entire audit trail.
7.5.3.4 (U) Audit Trail Checks and Reviews
The ISSO/SA will review the audit trail logs (manual and automated), or summary reports, to
verify that all pertinent activity is properly recorded and appropriate action has been taken to
correct and report any identified problems. Paragraphs
7.5.3.1 and
7.5.3.2 list audit trail
requirements. Audit trail logs or summary reports shall be reviewed weekly, at a minimum, or as
directed by the ISSM.
7.5.3.5 (U) Audit Trail Records Retention
Retain Audit Trail records for five years.
7.5.3.6 (U) Tactical/Deployable Audit Process Requirements
ISs which process SCI data may be developed specifically for tactical environments and are implemented
with tactical/deployable features that are contrary to SCI security requirements. The following audit
requirements should be viewed from a mission impact and adhered to accordingly.
· Security requirement: If the Audit process fails, the system is unable to provide monitoring for
unauthorized activities and should not continue operating, but should default to a safe/secure
posture pending restoring the ability to maintain proper audit.
· Mission Critical requirement: Failure of the Audit process should not interfere with continued
normal operation of a system.
· Sample implementation: Allow the system to continue operation if the Audit process fails.
7.5.3.6.1 (U) Tactical/Deployable Audit log requirements
· Security requirement: If the Audit logs fill up and the system is unable to record the monitoring
information for unauthorized activities, it should not continue operating, but should default to a
safe/secure posture pending proper retrieval/storage/archive of the audit data.
· Operational requirement: Full audit logs should not interfere with normal operation of a system.
Audits may fill up due to other than normal activities required to support operations, or a system
administrator being too busy responding to another operational requirement.
· Sample security implementation: Placing operational requirements ahead of security requirements
could result in the Audit process being set for “overwrite oldest if full” or First-In-First-Out (FIFO)
overwrite.
7.5.4 (U) Automatic Log-Out Requirements
The privileged user should implement an automatic logout from the IS when the user leaves his/her
terminal for an extended period of time. This should not be considered a substitute for a user
logging out.
7.5.5 (U) Limited Access Attempts
An IS will be configured to limit the number of consecutive failed access attempts to no more than
five; three is recommended.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
49
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
7.5.6 (U) Use of Windows Screen Locks
Screen locks are mandatory, and require a password for reentry into the system. If an IS is idle for
15 minutes, the screen lock will be automatically activated. Screen locks are not authorized in lieu
of log-off procedures. Operations may require exceptions which must be approved by the
ISSPM/SCO.
7.5.6.1 (U) Tactical/Deployable Protection for Information against unattended operation
· Security requirement: When a terminal is not attended, screen savers, screen locks, and dead man
lockout features provide protection of classified information. These features can interrupt an
operation when a terminal is left in a monitoring mode while other evolutions are taking place.
· Operational requirement: Long term monitoring may be required without continuous user
interaction with a system. Rapid response may require eliminating delays resulting from required
security passwords on screen locks. The need for rapid response could also completely obviate
dead man timeout features.
· Sample security implementation: disable these features for the IS for use in the tactical
environments.
7.5.7 (U) Testing, Straining, and Hacking
SCI IA policy states that testing, straining, hacking, or otherwise attempting to defeat or
circumvent the security measures of an operational IS or network is prohibited without
authorization. The privileged user must ensure that submitting a request through the ISSM to the
DAA Rep/SCO approves such activities. All such approvals must be in writing and limited to an
explicit assessment.
7.5.8 (U) Warning Banners
A logon warning banner is required on all networked and standalone DoD computer systems
(Government and contractor). The warning banner must be displayed and acknowledged before a
successful logon. Refer to Chapter 9 for complete instructions on the implementation of warning
banners.
7.5.9 (U) Network Monitoring
7.5.9.1 (U) Maintenance Monitoring
Privileged users/network technicians may use Local Area Network (LAN) analyzers or “sniffers” to
monitor network traffic provided:
· Reasonable notice has been provided to all users by display of the warning banners (Paragraph
9.3.1).
· The base or post has been certified for monitoring by the Service General Counsel (if required by
the appropriate Service).
· The sniffer or monitor does not intercept any traffic from outside the military base or post.
· The privileged user has received approval from the ISSM/ISSPM to monitor in the normal course
of his or her employment while engaged in activity necessary incident to the rendition of his or her
service or to the protection of the rights or property of the communications network (the provider
of the network service) except that this monitoring is only permitted for service or mechanical
quality control checks.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
50
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· Network traffic monitoring may not last longer than is necessary to observe transmission quality.
· No permanent recording of the network monitoring activity may be made.
· Monitoring traffic on civilian networks is strictly prohibited and may result in criminal and civil
liability under the Computer Fraud and Abuse Act, 18 U.S. Code section 1030 and the Electronic
Communications Privacy Act, 18 U.S. Code Section 2510 and following.
7.5.9.2 (U) Targeted Monitoring
Unauthorized targeted monitoring of a particular individual, machine or group is prohibited. When
service quality or transmission quality monitoring reveals suspicious activity, including hacking or
misuse, monitoring must cease and appropriate officials informed. At a minimum, notify the
Commander/Commanding Officer, or his/her designated representative, and the ISSM. Privileged
users may, of course, always terminate any connection at any time when the safety or property of
the network is endangered. Privileged users shall cooperate with law enforcement and security
officials IAW applicable Service guidelines.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
51
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 8 - INFORMATION SYSTEMS (IS) INCIDENT REPORTING
8.1 (U) PURPOSE
Incidents may result from accidental or deliberate actions on the part of a user or occur outside of
the organization as well. An accidental incident should be handled administratively. Evidence of
criminal activity from a deliberate action should be treated with care, and maintained under the
purview of cognizant law enforcement personnel (see Chapter 9 “Information System Monitoring
Activities” for specific guidance). All management personnel must ensure IS users are aware of the
policy governing unauthorized use of computer resources. When it is suspected that an IS has been
penetrated, or at any time system security is not maintained, it must be reported both within the
organization and to the appropriate external authorities for action. Any use for other than
authorized purposes violates security policy, and may result in disciplinary action under the
Uniform Code of Military Justice (UCMJ) and/or other administrative directives. This chapter
provides procedures for formal incident reporting.
8.2 (U) SCOPE
These procedures are effective in the following life-cycle phases:
CONCEPTS DEVELOPMENT PHASE
NO
DESIGN PHASE
NO
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
YES
8.3 (U) PROCEDURES
Discovery of a viral infection, introduction of malicious code, hacker activity, system
vulnerabilities, or any unusual happenings will be reported immediately to the ISSM and an
investigation initiated. Accidental incidents (for example, a one time brief Web site visit containing
inappropriate content or inappropriate or vulgar usage of mission systems chat features) or other
minor infractions can be handled administratively within the unit. Make every effort to contact the
data owner to obtain specific guidance to afford minimum acceptable protection in cases of spillage
and compromise.
8.3.1 (U) Reporting Process
Incident reporting should be accomplished by each service through their appropriate ISSM or
security channel.
8.3.2 (U) Types of IS Incidents and Reports
The following are examples of incidents that must be reported:
· Data Compromise. Is the compromise or probable compromise of classified information resulting
from the loss of control, improper storage, improper classification, or improper escorting of media,
computer equipment (with memory), computer generated output; human error in reviewing media
for content and classification resulting in compromise; and incorrect setting of a security filter
resulting in compromise.
· Spillage. Information of a higher classification or restrictive in nature intentionally or inadvertently
placed on machines or networks of lower classification or less restrictive policy.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
52
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· External Hacker Activity. Activity where a hacker is operating from an outside location by using
some network and he/she is not physically resident at the location where the activity is being
observed.
· Internal Hacker Activity. Activity where a hacker is operating from within the site where the
activity is being observed.
· Malicious Code. Any potentially hazardous or destructive computer code other than a virus, such
as a logic bomb, worm or Trojan horse. NOTE: malicious code will probably also represent a
vulnerability, as described below.
· Unauthorized Monitoring. Any individual or group of individuals found to be monitoring an IS
without written authority from security officials.
· Unauthorized Software. Software obtained through unofficial channels see paragraph 11.6.4.
· Virus Actual Infection. A known active attack or presence on an IS where the virus has executed
on that system.
· Vulnerability. Any detected lack of protection that may render the system vulnerable to security
breaches. Examples are failure, or potential failure, of a system or network security feature. The
discovery of any computer code, such as a trapdoor, which was originally coded into the operating
system by the software vendor; or code added by software maintenance personnel, that provides an
undocumented entry/exit capability into the system by unauthorized personnel.
8.3.3 (U) Reporting Incidents
Incidents in progress are classified a minimum of CONFIDENTIAL IAW NSA/CSS Classification
Guide 75-98 or DoD 5105.21-M-1. The cognizant intelligence agency (DIA or NSA) should be
notified via secure channels by electrical message (AUTODIN), E-Mail or agency web site as soon
as the unit has knowledge of an incident or specifics. The notification should contain the
information in paragraph 8.3.4.
(see Figure
8.1 for an example of an AUTODIN message).
Initial/interim reporting should begin as soon as possible after knowledge of the incident but should
continue until the incident is resolved. Remember to include information copies of the report to the
DAA Rep/SCO and chain of command (for example, AIA, INSCOM, SSO NAVY, CNSG).
Complete the report according to the format in paragraph 8.3.4 below and send to the appropriate
Service addressees.
· SCEs will report to the Security Health Officer (SHO) desk in the NSA/CSS Information System
Incident Response Team (NISIRT), phone: DSN 644-6988/Commercial (301) 688-6988.
· DoDIIS sites will report to the DIA ADP Command Center, phone: DSN 428-8000/Commercial
(202) 231-8000. For guest systems, reporting should be to both the cognizant SCIF authority and
the guest system DAA Rep/SCO.
Caution: If a hacker is suspected of monitoring the Automatic Digital Network
(AUTODIN)/Defense Message Messaging System
(DMS) message traffic, do not use
AUTODIN/DMS to send the report. Instead, send the report by facsimile to the required
addressees, followed up by a phone call to confirm receipt of the report.
Users playing games on the systems, or fraud waste and abuse issues are incidents and should be
reported and dealt with by the unit’s chain of command.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
53
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
8.3.4 (U) Report Format and Content
When reporting incidents, include the following information in the body of the message (as shown
in sample message, Figure 8.1):
·
Type of Incident. Enter the type of incident report directly from paragraph 8.3.2 above. If there is
any doubt when choosing the “type” of incident, identify the incident as both (or multiple) types in
the same message. Selecting the most appropriate incident type is not nearly as important as
reporting the incident.
·
Date and Time the Incident Occurred. Enter the date and time that the occurrence was first
detected.
·
Name and Classification of the Subject IS. Enter the name of the system identified in the
accreditation documentation, a current description of the hardware and software on the system, and
the highest classification of information processed.
·
Description of the Incident. Clearly describe the incident in detail.
·
Impact of the Incident on Organization Operations. This is usually stated in terms of “denial of
service”, such as having to isolate the IS from a network, thereby closing down operations, etc.
Include the number of hours of system downtime and how many man-hours needed to correct the
problem.
·
Impact of the Incident on National Security. Per DoD 5105.21-M-1, when classified information
has been released to unauthorized persons, you must treat the incident as a security violation. List
the name of the SCI security official to whom you have reported the incident.
·
Man-hours involved in recovery, cleanup, etc. This provides an accurate metric to track incident
recovery man-hours and resources involved. Tracking can include cost estimates related to the
hours/wage grade spent.
·
Point of Contact (POC). Enter the name, rank, organization, office, and telephone number of the
person to be contacted on all subsequent actions concerning this incident.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
54
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
·
R 211234Z FEB 01
FM YOUR UNIT//OFFICE//
TO SSO DIA//SYS-4/DAC-3D//
NSACSS//SHO/L1//
INFO CHAIN OF COMMAND
SCO//OFFICE//
ZEM
C O N F I D E N T I A L
QQQQ
SUBJECT: INCIDENT REPORT ICW JDCSISSS, CHAPTER 8
1.
TYPE OF INCIDENT:
(VIRUS, MALICIOUS CODE,
DATA
COMPROMISE, SUSPECTED PROBLEM)
2. DATE/TIME INCIDENT OCCURRED
3. NAME AND CLASSIFICATION OF VICTIMIZED SYSTEM
4. DESCRIPTION OF INCIDENT: (AS MUCH DETAIL AS NECESSARY
TO ADEQUATELY DESCRIBE THE PROBLEM)
5. IMPACT OF INCIDENT ON ORGANIZATION OPERATIONS
(USUALLY STATED IN TERMS OF DENIAL OF SERVICE, DOWN
TIME OR MISSION IMPACT)
6. IMPACT OF THE INCIDENT ON NATIONAL SECURITY (USUALLY
STATED IN TERMS OF DATA OWNER’S ASSESSMENT OF LEVEL OF
CLASSIFIED INFORMATION AND COMPROMISE PROBABILITY)
7. MAN-HOURS REQUIRED TO COMPLETE RECOVERY
8. ACTIONS TAKEN TO RECOVER
9. REPORTING UNIT POC (NAME, RANK, ORG/OFFICE, PHONE
NUMBERS, E-MAIL ADDRESS)
NNNN
Figure 8.1 (U) Sample Incident Report Message
8.3.5 (U) Follow-On Action
Units will continue to report until the incident is closed. Virus infections that are corrected should
be reported as “closed”, unless further actions are being taken, or reinfection has occurred. The
HQ-level action addressees and Data Owners will determine follow-on actions. Appropriate
PAA/designee will determine course of action for incident cleanup in a near real-time manner. Once
an incident has been resolved (i.e., closed), the incident may be treated as FOUO. The DAA
Rep/SCO will coordinate with the DIA or NISIRT to ensure that the concerns of the latter are
addressed. If an activity from another command or agency is involved, the HQ-level action
addressees will provide proper notification to the same.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
55
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 9 - INFORMATION SYSTEM (IS) MONITORING ACTIVITIES
9.1 (U) PURPOSE
This chapter provides guidance on the DOs and DON’Ts of IS monitoring and applies to all
computer systems and networks. All U.S. Government systems must be protected from intrusion
and exploitation. Therefore, it is mandatory this guidance is implemented. Intrusions may result in
denial of service, misuse, destruction and modification of data or programs, and disclosure of
information. Typically, the personnel and physical security disciplines add credence to the
protection afforded Government systems, especially those that are classified. Occasionally, when
the incident requires further action, some monitoring must be established as an additional tool to
protect the critical system and to identify the perpetrator attempting to violate the security of the
system.
9.2 (U) SCOPE
These procedures are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
YES
DESIGN PHASE
YES
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
NO
9.3 (U) PROCEDURES
In the DoD environment, the policy is to protect classified and unclassified sensitive information
from unauthorized disclosure, destruction and modification. The security policies have been
constructed to meet this objective. Implementation of these security policies begins with a warning
to the user that the system is subject to monitoring. Once this has been done, the user
acknowledges that monitoring may be initiated when appropriately authorized and determined
necessary to provide documentary evidence for a potential prosecution or administrative action.
Extreme care must be taken in a targeted monitoring situation, IAW this chapter, to ensure:
· Evidence is not destroyed.
· Innocent personnel are not implicated.
· The subject does not become aware of a planned monitoring activity.
9.3.1 (U) IS Warning Banner
The DoD General Counsel requires explicit notice to all users that use of Information Systems
constitutes consent to monitoring. User knowledge of monitoring activation can serve as a
deterrent to any malicious act. The following warning banner requirements are to be applied
·
(U) A logon warning banner is required on all networked and standalone DoD interest computer
systems (Government and contractor). The warning banner must be displayed before a successful
logon and should include an option that allows the user to halt the logon process. The intent of the
banner is to confirm to the user that all data contained on DoD interest computer systems is subject
to review by law enforcement authorities, DoD security personnel, and/or System Administrator,
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
56
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
IAW this chapter. The banner is designed to inform all users, prior to accessing a DoD system, that
by logging on they expressly consent to authorized monitoring.
·
(U) ISs supporting DoD operations have very specific warning banner requirements, and must
include, at a minimum, the information shown in Figure 9.1.
·
(U) A warning banner must be placed on an IS so that the IS user must enter a keystroke to
continue processing. Although an appropriate warning banner is displayed, systems administration
personnel will minimize the possibility of accessing user data that is not relevant to the monitoring
being acquired, analyzed, or recorded. Whenever system administration personnel suspect that a
system is being inappropriately used, either by authorized or unauthorized personnel, or some
improper activity is being conducted, the matter will be reported immediately to the ISSM/ISSPM.
NOTICE AND CONSENT BANNER
THIS IS A DEPARTMENT OF DEFENSE (DOD) COMPUTER SYSTEM. THIS
COMPUTER SYSTEM, INCLUDING ALL RELATED EQUIPMENT, NETWORKS AND
NETWORK DEVICES (SPECIFICALLY INCLUDING INTERNET ACCESS), ARE
PROVIDED ONLY FOR AUTHORIZED U.S. GOVERNMENT USE. DOD COMPUTER
SYSTEMS MAY BE MONITORED FOR ALL LAWFUL PURPOSES, INCLUDING TO
ENSURE THAT THEIR USE IS AUTHORIZED, FOR MANAGEMENT OF THE
SYSTEM, TO FACILITATE PROTECTION AGAINST UNAUTHORIZED ACCESS, AND
TO VERIFY SECURITY PROCEDURES, SURVIVABILITY AND OPERATIONAL
SECURITY. MONITORING INCLUDES ACTIVE ATTACKS BY AUTHORIZED DOD
ENTITIES TO TEST OR VERIFY THE SECURITY OF THIS SYSTEM. DURING
MONITORING, INFORMATION MAY BE EXAMINED, RECORDED, COPIED AND
USED FOR AUTHORIZED PURPOSES. ALL INFORMATION, INCLUDING
PERSONAL INFORMATION, PLACED ON OR SENT OVER THIS SYSTEM MAY BE
MONITORED.
USE OF THIS DOD COMPUTER SYSTEM, AUTHORIZED OR UNAUTHORIZED,
CONSTITUTES CONSENT TO MONITORING OF THIS SYSTEM. UNAUTHORIZED
USE MAY SUBJECT YOU TO CRIMINAL PROSECUTION. EVIDENCE OF
UNAUTHORIZED USE COLLECTED DURING MONITORING MAY BE USED FOR
ADMINISTRATIVE, CRIMINAL OR OTHER ADVERSE ACTION. USE OF THIS
SYSTEM CONSTITUTES CONSENT TO MONITORING FOR THESE PURPOSES.
Figure 9.1. (U) Information System Warning Banner.
9.3.2 (U) Warning Labels
In addition to the IS warning banner, a standard U.S. Government warning label must be placed on
the top border edge of each terminal of each IS. Local production of labels is authorized only when
using the text contained in Figure 9.2.
THIS INFORMATION SYSTEM (IS) IS SUBJECT TO MONITORING AT ALL TIMES.
USE OF THIS IS CONSTITUTES CONSENT TO MONITORING.
Figure 9.2. (U) Warning Label.
9.3.3 (U) Action to be Taken Before Monitoring
Do not proceed to monitor an individual (targeted monitoring) without first gaining permission and
guidance from General Counsel and Commander/CO/SIO. Unauthorized targeted monitoring is a
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
57
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
violation of the subject’s rights and may jeopardize the investigation. Authorization for targeted
monitoring must come through the Commander/Commanding Officer in consultation with legal
representation by the Judge Advocate General
(JAG), General Counsel, or an authorized
investigative organization, such as the (Defense Criminal Investigative Service (DCIS), US Army
Criminal Intelligence Department (USACID), US Army Military Intelligence (USAMI), Naval
Criminal Investigative Service (NCIS), or Air Force Office of Special Investigations (AFOSI)). The
ISSM and ISSO/SA will make every effort to take action in Table 9.1 and answer all applicable
questions identified in Table 9.2.
9.3.4 (U) Review System Specific Security Features
The investigators will want full documentation on many aspects of the system being violated. Table
9.2 identifies sample information needed by the Commander/CO/SIO that may be needed in
justifying the investigation. The ISSM and ISSO/SA will make every effort to document the
information in Table 9.2.
Table 9.1. (U) Recommended Incident Response Actions
ITEM
ACTION RECOMMENDED
NUMBER
1
Notify the ISSM.
2
The ISSM will notify the Special Security Officer
(SSO),
Commander/CO/SIO
The Commander/CO/SIO will coordinate with the General Counsel and
3
authorized investigative office for formal guidance.
Follow Chapter 8 for incident reporting
4
Keep a record of actions by the ISSM concerning the incident.
5
Table 9.2. (U) Sample Monitoring Investigation Questions
ITEM
SAMPLE INFORMATION THAT MAY BE NEEDED BY THE
NUMBER
COMMANDER
1
What event(s) triggered suspicion of improper system use?
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
58
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
Does the system have a warning banner? Is the banner displayed prior to
2
the first keystroke?
3
Where is the hardware physically located?
4
What level of classified data is processed on the system?
5
What organization/activity is supported by the system?
6
What connectivities are authorized to the system?
7
What is the function of the system?
8
What security software, if any, is used on the system?
9
Are audit trails running normally and have they been reviewed regularly?
10
Is a copy of the SSAA/SSP available?
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
59
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 10 - MALICIOUS CODE PREVENTION
10.1 (U) PURPOSE
Minimize the risk of malicious code (malicious logic) from being imported to or exported from
Information Systems (ISs). Preventing malicious code is everyone’s responsibility. This chapter
identifies various types of malicious code and provides preventive measures to avoid problems.
10.2 (U) SCOPE
The provisions of this policy apply to all organizations processing SCI, their components, and
affiliates worldwide, as well as all contractor-owned or operated systems employed in support of
SCI designated contracts. This supplement will be specified on all DD Forms 254 as a contractual
requirement. These procedures are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
YES
DESIGN PHASE
YES
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
NO
10.3 (U) DEFINITIONS
10.3.1 (U) Malicious code
Malicious code is that which is intentionally included in hardware, software, firmware or data for
unauthorized purposes. Computer Viruses, Worms, Trojan Horses, Trapdoors, and Logic/Time
Bombs all fall under the definition of malicious code. Computer viruses pose the primary threat to
ISs because of their reproductive capability. Malicious code can arrive through either media that
are introduced to ISs or as mobile code that arrives through connections to other systems and
networks.
10.3.2 (U) Mobile Code
Mobile code is technology that allows for the creation of executable information which can be
delivered to an information system and then directly executed on any hardware/software
architecture that has an appropriate host execution environment. The code can perform positive or
negative actions (malicious). The focus on risk is based on the receipt of executable information
from sources outside a Designated Approval Authority’s area of responsibility or control. Mobile
code is the software obtained from remote systems outside the enclave boundary, transferred across
a network, and then downloaded and executed on a local system without explicit installation or
execution by the recipient.
Refer to the Intelligence Community Chief Information Officer (ICCIO) Intelligence Community
Policy for the Use of Mobile Code in the Intelligence Community System for Information Sharing
(ICSIS) Environment, dated 08 August 2002 for additional guidance.
10.3.3 (U) Malicious Mobile Code
Mobile code is the software designed, employed, distributed, or activated with the intention of
compromising the performance or security of information systems and computers, increasing access
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
60
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
to those systems, providing the unauthorized disclosure of information, corrupting information,
denying service, or stealing resources. Types of mobile code are direct and indirect.
· Direct mobile code can be recognized within the primary transport mechanism, such as a virus
within a file.
· Indirect mobile code may be embedded, such as inside of an attachment to E-Mail.
10.3.4 (U) Mobile Code Technologies
Software technologies that provide the mechanisms for the production and use of mobile code are
grouped into three Risk Categories based on the functions performed by the code, the ability to
control distribution of the code and control of the code during execution.
Mobile Code is categorized based on the assessed risk posed to the IC:
· Red Mobile Code has been assessed as a high risk and shall be prohibited from use unless a
specific exception is granted by the IAPB.
· Yellow Mobile Code has been assessed as a medium risk and shall only be used on a case-
by-case basis after implementing explicit IC-approved mitigations as specified in the
Applications, Services and Protocols Categorization List (ASPCL).
· Green Mobile Code has been assessed as a low risk and shall be permitted for use
throughout the IC.
10.3.4.1 (U) Red Mobile Code
Red Mobile Code can exhibit broad functionality using unmediated access to services and resources
of workstations, hosts and remote systems. Red Mobile Code technologies can pose severe threats
to IC services. Some of these technologies allow differentiation between unsigned and signed code
(i.e., a mechanism used by a trusted source), with capabilities to configure systems so that only
signed code will execute. Examples of Red Mobile Code technologies can be found on the ICCIO
ASPCL Mobile Code Technologies web page listed below.
10.3.4.2 (U) Yellow Mobile Code
Yellow Mobile Code has full functionality using mediated or controlled access to services and
resources of workstations, hosts and remote systems. Yellow Mobile Code technologies may
employ known and documented fine-grain, periodic, or continuous countermeasures or safeguards
against malicious use. Some of these technologies allow differentiation between unsigned and
signed code (i.e., a mechanism used by a trusted source), with capabilities to configure systems so
that only signed code will execute.
Yellow Mobile Code technologies can pose a medium threat to IC information systems. The use of
Yellow Mobile Code technologies, when combined with prudent countermeasures against malicious
use, can afford benefits that outweigh their risks. Yellow Mobile Code may be used through CIs,
and shall only be used with the IC-approved mitigations and countermeasures specified in the
Applications, Services, and Protocols Categorization List
(ASPCL) located at
sp.) Additional mitigations or countermeasures may be applied at the discretion of the DAA.
Examples of Yellow Mobile Code technologies can be found on the ICCIO ASPCL Mobile Code
Technologies web page.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
61
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
10.3.4.3 (U) Green Mobile Code
Green Mobile Code has limited functionality, with no capability for unmediated or uncontrolled
access to services and resources of workstations, hosts and remote systems. Green Mobile Code
technologies may employ known and documented fine-grain, periodic, or continuous
countermeasures or safeguards against malicious use. Protection against these types of mobile code
only requires normal vigilance compared with that required to keep any software configured to
resist known exploits. Green Mobile Code shall be allowed through Controlled Interfaces (CI)
without restriction. Examples of Green Mobile Code technologies can be found on the ICCIO
ASPCL Mobile Code Technologies web page listed above.
10.3.4.4 (U) Emerging Mobile Code Technologies
Emerging technologies refer to any Mobile Code technologies or languages whose capabilities and
threat level have not yet been categorized. Emerging technologies pose uncertain risk to the IC
systems.
Therefore, Any Mobile Code that has not been assessed or validated (i.e., it is not listed in the
ASPCL) shall be automatically considered Red
10.3.4.5 (U) Exempt technologies
Those that are not considered true mobile code. These include:
· XML;
· SMIL;
· QuickTime;
· VRML (exclusive of any associated Java Applets or JavaScript Scripts);
· Web server scripts, links and applets that execute on a server (Java servlets, Java Server Pages,
CGI, Active Server Pages, CFML, PHP, SSI, server-side JavaScript, server-side Lotus Script);
· Local programs and command scripts that exist on a user workstation (binary executables, shell
scripts, batch scripts, Windows Scripting Host (WSH), PERL scripts);
· Distributed object-oriented programming systems that do not go back to the server to execute
objects (CORBA, DCOM); and
· Software patches, updates and self-extracting updates that must be explicitly invoked by a user
(Netscape SmartUpdate, Microsoft Windows Update, Netscape web browser plug-ins, and Linux
Update Manager)
10.3.5 (U) Trusted Source
A trusted source is a source that is adjudged to provide reliable software code or information and
whose identity can be verified by authentication. The following mechanisms are sufficient to
validate the identity of a trusted source:
· a connection via JWICS;
· a connection via the SIPRNET;
· a digital signature over the mobile code itself using either DoD or IC-approved PKI certificate;
· a commercial certificate approved by either the DoD CIO or the IC CIO; or
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
62
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· authentication of the source of the transfer by public key certificate (e.g., S/MIME, SSL server
certificate from an SSL web server).
10.3.6 (U) Screening
Screening is a preventive measure to monitor processes and data to intercept malicious code before
it is introduced to an IS. Screening also includes monitoring IS for the presence of malicious code
which is already present. Malicious code occurs in different forms, which may have different
methods for screening.
10.4 (U) PROCEDURES
The ISSM/ISSO is responsible for ensuring that the following procedures are followed.
10.4.1 (U) Preventive Procedures
Scan all information storage media (e.g., diskettes, compact disks, computer hard drives, etc.) and
E-mail attachments introduced prior to its use on any SCI system. If the media cannot be scanned
then it is considered high risk and cannot be used on any SCI system without approval from the
SCO. Procedures to be followed:
· Use automated scanning applications, e.g., virus scanning, which will monitor media upon
introduction to a system and data being transferred into the IS.
· Check and review the IS operating environment for the presence of malicious code on a frequent
basis.
· Avoid hostile mobile code through use of only authorized/verified and registered mobile code.
· Keep automated scanning processes up to date with the most current recognition signatures.
· Ensure that users will not knowingly or willfully introduce malicious code into systems.
· Ensure that users will not import or use unauthorized data, media, software, firmware, or hardware
on systems.
· Ensure that users will conduct screening of all incoming data (e.g., E-Mail and attachments) if this
process is not automated.
· Ensure that users will not use personal-owned media (e.g., music, video, or multimedia compact
disks) in Government-owned IS.
· Ensure that all users immediately report all security incidents and potential threats and
vulnerabilities involving malicious code on ISs to the ISSM.
· Controlled Interfaces with malicious code scanning capability does not relieve the management of
the receiving IS from the responsibility of also checking for malicious code.
10.4.2 (U) Malicious Code Detection
If a malicious code is detected or a presence of malicious code is suspected on any IS, do the
following:
· Immediately report it to the ISSM for further instruction IAW Chapter 8. Do nothing that might
cause the further spread of the malicious code.
· Take the following corrective actions:
· If found in a file, use approved Anti-virus software to remove a virus from a file.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
63
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· If found on a System, use approved Antivirus software to remove the virus from your system.
· If files are corrupted, then restore affected files from system backups.
10.5 (U) MALICIOUS CODE SECURITY REQUIREMENTS
An integral part of this program is the mandatory training required by public law. Users shall
receive initial training on prescribed IS security restrictions and safeguards prior to accessing
corporate IS assets IAW Chapter 6. User awareness is still the first line of defense, especially since
there is NO ANTI-VIRUS SOFTWARE THAT CAN GUARANTEE 100% PROTECTION
FROM VIRUSES.
10.5.1 (U) Preventative Steps to be Taken
·
Employ user awareness education.
·
Use virus scanning programs to detect viruses that have been placed on diskettes.
·
Never start a PC while a diskette is in the drive.
·
Ensure the CMOS boot-up sequence for PCs is configured to boot-up from the hard drive first
(usually the C: drive) NOT the A: drive.
·
Block receiving/sending of executable code. Blocking files with executable extensions such as
EXE, VBS, SHS etc., contributes to overall anti-virus measures.
·
Adopt procedures to configure email applications to view received files/attachments in a “viewer.”
Viewers normally do not have macro capabilities.
·
Do not use a diskette from an outside source without first scanning it for potential viruses.
·
Do not download data from Internet bulletin boards, etc.
·
Ensure files are being backed up daily.
·
Implement a process to routinely check security bulletins for updates, (i.e., CERT, AFCERT,
NAVCERT, etc.)
·
Whenever possible, disable the automatic execution of all categories of mobile code in email bodies
and attachments.
·
Whenever possible, desktop software shall be configured to prompt the user prior to opening email
attachments that may contain mobile code.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
64
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 11 - SOFTWARE
11.1 (U) PURPOSE
This chapter defines the various types of software applications that may be used on any DoD IS. It
lists software types that are authorized as well as specific types of software that are not authorized.
11.2 (U) DEFINITION
For the purpose of this policy, software should be interpreted to be any information recorded on
any information storage media to include data files, source code and executable code.
11.3 (U) SCOPE
These procedures are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
YES
DESIGN PHASE
YES
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
NO
11.4 (U) PROCEDURES FOR SOFTWARE AUTHORIZATION
Additions or modifications to software on systems which affects system accreditation must be
evaluated by the ISSM through the local CMB/CCB process and coordinated with the DAA
Rep/SCO to gain concurrence.
11.5 (U) LOW RISK SOFTWARE
Low risk software must be approved by the ISSPM/ISSM before introduction to SCI ISs, including
the following guidelines:
· Provided officially by another U.S. Government Agency that has equivalent standards.
· Provided under contract to organizations involved with the processing of SCI and related
intelligence information.
· Developed within a Government-approved facility.
· COTS software provided through appropriate procurement channels.
· Distributed through official channels.
· Acquired from a reputable vendor for official use or evaluation (i.e., maintenance diagnostic
software).
NOTE: In all cases, system and site specific security policy should be considered.
11.6 (U) HIGH RISK SOFTWARE
Certain software is deemed “high risk” and is not authorized for use without approval. The
respective DAA Rep/SCO must approve such software in writing before it may be legally used.
High risk software includes public domain, demonstration software, and embedded software not
obtained through official channels. The DAA Rep/SCO may deem other software high risk.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
65
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
11.6.1 (U) Public Domain Software
Only the DAA (Rep)/SCO may approve the use of public-domain software. Do not confuse public-
domain software with off-the-shelf, or user developed software. A request to use public-domain
software and the subsequent approval requires an extensive evaluation, by approved evaluation
centers, of the particular software source code in search of Trojan Horses, Trapdoors, Viruses, etc.
There is limited capability to perform these required evaluations.
11.6.2 (U) Demonstration Software and Media
Floppy diskettes and removable hard disks used for demonstrations, with the intent of being
returned to a vendor, must be processed on a computer that has never processed or stored
classified data. Otherwise, the demonstration media cannot be released back to the vendor and
should be destroyed. If it is to be returned to the vendor, a fully cleared and indoctrinated individual
must verify that the media was used only in an unclassified computer.
NOTE: Vendor hardware used for software demonstrations must operate in a stand-alone mode. If
use of vendor software for demonstration purposes requires connection to a DoD network
approval must be granted by the appropriate DAA Rep/SCO.
11.6.3 (U) Embedded Software
Game software included as part of a vendor bundled software or software/hardware package shall
be removed from the IS immediately following the installation and testing of the software. Vendor
supplied games occupy valuable disk space and could open the door for Fraud, Waste, and Abuse
(FW&A) charges. Game software provided for use as tutorials may be granted as an exception to
this restriction by the DAA Rep/SCO. All other games software currently on SCI ISs are
considered a violation of this policy and must be removed.
11.6.4 (U) Unauthorized Software
Types of software that are not authorized include:
· Games.
· Public domain software or “shareware” which have been obtained from unofficial channels.
· All software applications which have been developed outside Government approved facilities, such
as those developed on personally owned computers at home or software acquired via non- U.S.
Government “bulletin boards”.
· Personally owned software (either purchased or gratuitously acquired).
· Software purchased using employee funds (from an activity such as a coffee fund).
· Software from unknown sources.
· Illegally copied software in violation of copyright rules.
· Music and video or multimedia compact disks not procured through official Government channels.
11.6.5 (U) IA Software and Security Tools
When employing evaluated and validated IA/IA enabled products, a solution security analysis
should be conducted as part of the certification and accreditation process. Some high risk software
may be required to meet system requirements. For example, to comply with paragraph 4.B.2.a.5.b
of DCID 6/3, intrusion/attack detection and monitoring tools are required to support required
periodic testing by the ISSO/ISSM within their domain.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
66
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 12 - INFORMATION STORAGE MEDIA
12.1 (U) PURPOSE
This chapter outlines the minimum requirements for the control and accounting of information
storage media. The Commander/Commanding Officer is responsible to prescribe the policy for the
level of control and accounting appropriate for information storage media under his/her control.
Also, this chapter outlines the minimum requirements for marking the magnetic media and paper
products. Labeling of magnetic media is similar to labeling paper products. Like paper documents,
all information storage media must be properly marked with the appropriate classification and
handling instructions.
12.2 (U) SCOPE
These procedures are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
NO
DESIGN PHASE
NO
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
NO
12.3 (U) CONTROL AND ACCOUNTING PROCEDURES
This chapter provides guidelines for control and accounting of information storage media. For any
system that operates with PL-3 or lower functionality, media that is not write-protected and is
placed into that system must be classified at the highest level of information on the system until
reviewed and validated. Media accountability will be based on the determined classification level of
the media.
12.3.1 (U) Information Storage Media Control
Per DoD 5105.21-M-1, there is a requirement to control and account for certain information
storage media within functional categories. This chapter tasks the organization
Commander/Commanding Officer with developing a unit-unique SOP for control and
accountability.
12.3.1.1 (U) Inspections
The organization must be able to demonstrate positive control and accounting of information
storage media according to its SOP when being inspected by authorities.
12.3.1.2 (U) Control Procedures
Control of information storage media should begin upon introduction into the organization
according to DoD 5105.21-M-1, and local SOP.
12.3.1.3 (U) Other Categories of Storage Media
The following major categories of information storage media should be considered for
accountability in compliance with copyright and licensing as documented in the SOP:
· COTS and vendor software.
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
67
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
· Government developed software.
· Other organization unique software and data.
12.3.2 (U) Audits and Reports
Each organization will periodically audit the information storage media accountability records for
accuracy. The frequency of audits should depend on the volume of media on hand, the frequency of
changes in the accounting system, criticality of the media, and classification level of data stored
onto the media. Perform other audits at the Commander’s/Commanding Officer’s discretion.
Document the result of these audits in an internal report to remain on file within the organization
for at least one year. Report discrepancies to the ISSM for further reporting to the DAA Rep/SCO
as required. These requirements should be addressed in the organization SOP along with the
following:
·
(U) Inventories/audits will be required for accountable information storage media per DoD
5105.21-M-1.
·
(U) Information storage media holdings will be audited periodically to ensure proper control is
being maintained and media is destroyed when no longer needed.
12.3.3 (U) Destruction of Media
See Chapter 21, for guidance on the proper destruction of media.
12.4 (U) MEDIA LABELING PROCEDURES
To ensure data integrity and protection, information storage media must be administratively labeled
and appropriately protected to prevent the loss of information through poor security procedures.
Likewise, to prevent security compromises, all output products must be appropriately protected.
Proper classification marking of output paper products, microfiche, terminal screen displays and
central processing units (CPUs) must be accomplished and is the responsibility of the user. Each
supervisor is ultimately responsible for the labeling, handling, and storage of both media and paper
products within their assigned area of responsibility.
12.4.1 (U) Information Storage Media
Removable IS storage media and devices shall have external labels clearly indicating the
classification of the information and applicable associated markings (e.g., digraphs, trigraphs).
Labeling exemption for OPSEC requirements may be granted within local policy with DAA/DAA
Rep/SCO concurrence. Examples include magnetic tape reels, cartridges, cassettes; removable
discs, disc cartridges, disc packs, diskettes, magnetic cards and electro-optical (e.g., CD) media. All
removable information storage media and devices will be marked with the appropriate Standard
Form (SF) 700-series classification and descriptor labels as listed and depicted below:
· SF 706, Top Secret Label
· SF 707, Secret Label
· SF 708, Confidential Label
· SF 710, Unclassified Label
· SF 711, Data Descriptor (On all magnetic media)
· SF 712, Classified SCI Label (All classification levels)
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
68
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
SF 706, TOP SECRET (Orange)
SF 712, SCI (Yellow)
Includes ALL classification levels of SCI
SF 707, SECRET (Red)
SF 708, CONFIDENTIAL (Blue)
SF 709, GENERIC CLASSIFIED (Purple)
SF 710, UNCLASSIFIED (Green)
For use on removable media ONLY
Unclassified Information ONLY
SF 711, Data Descriptor Label
Figure 12.1 - SF 700 Series Labels
12.4.1.1 (U) Label Placement
See the Federal Register 2003 and applicable military department regulations for exact placement
procedures. Labels will be affixed to all media in a manner that does not adversely affect operation
of the equipment in which the media is used. Labels may be trimmed to fit the media. Labels for
Compact Disks (CDs) must NOT be placed on the CD itself. Place the labels on the CD container
or envelope. Record the classification and accounting number in the “Control” block of the SF 711
and write the same number on the CD with a Paint-pen, CD label maker or permanent marker. The
number should not interfere with the operation of the CD. Notice: Do not use pens that contain
toluene.
12.4.1.2 (U) Data Descriptor Label
The SF 711, Data Descriptor Label, identifies the content of a specific media to include
unclassified, collateral-classified, and SCI. An SF 711 is not required if the disk bears the following
information: Organization, office symbol, classification, and media sequence number (if locally
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
69
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
required).
The user fills in the
“Classification”,
“Dissem”,
“Control”, and
“Compartments/Codewords” blocks as appropriate.
12.4.2 (U) Tactical/Deployable Labeling media and hardware components
The following labeling requirements should have OPSEC considerations prior to implementing.
· Security requirement: Removable media and IS hardware components should be labeled IAW
Chapter 12.
· Operational requirement: OPSEC requirement to disguise the existence of classified information on
an IS (including specification of compartments).
· Sample security implementation: Reusable deployed hardware sanitized for travel (media removed)
is shipped via commercial carrier to its intended destination, no labels present.
12.4.3 (U) Classification Markings
All documents residing or processed on information storage media/ISs will be marked IAW the
Controlled Access Program Coordination Office (CAPCO) guidance “Intelligence Community
Classification and Control Markings Implementation Manual”, dated 10 Sep 1999 (Amended 21
March 2002), DoD 5105.21-M-1, dated August 1998, or appropriate Agency/Service regulations.
The guidance references are located at:
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
70
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
CHAPTER 13 - INFORMATION SYSTEMS (IS) MAINTENANCE PROCEDURES
13.1 (U) PURPOSE
The purpose of this chapter is to identify security procedures and responsibilities that must be
followed during the maintenance of ISs. ISs are particularly vulnerable to security threats during
maintenance activities. The level of risk is directly associated with the maintenance person’s
clearance status (cleared or uncleared). A maintenance person may be uncleared or may not be
cleared to the level of classified information contained on the IS. Properly cleared personnel
working in the area must maintain a high level of security awareness at all times during IS
maintenance activities. Additionally, the ISSM is responsible for IS maintenance security policy,
including maintenance procedures for all ISs under his or her control.
13.2 (U) SCOPE
These procedures are effective in the following life cycle phases:
CONCEPTS DEVELOPMENT PHASE
YES
DESIGN PHASE
YES
DEVELOPMENT PHASE
YES
DEPLOYMENT PHASE
YES
OPERATIONS PHASE
YES
RECERTIFICATION PHASE
YES
DISPOSAL PHASE
YES
13.3 (U) PROCEDURES
13.3.1 (U) Maintenance Personnel
13.3.1.1 (U) Maintenance by Cleared Personnel
Personnel who perform maintenance on classified systems should be cleared and indoctrinated to
the highest classification level of information processed on the system. Appropriately cleared
personnel who perform maintenance or diagnostics on ISs do not require an escort. However, an
appropriately cleared and, when possible, technically-knowledgeable employee should be present
when maintenance is being performed to assure that the proper security procedures are being
followed.
13.3.1.2 (U) Maintenance by Uncleared (or Lower-Cleared) Personnel
If appropriately cleared personnel are unavailable to perform maintenance, an uncleared or lower-
cleared person may be used provided a fully cleared and technically qualified escort monitors and
records their activities in a maintenance log.
· Uncleared maintenance personnel should be US citizens. Outside the US, where US citizens are not
available to perform maintenance, foreign nationals may be utilized, but only with DAA Rep/ SCO
approval.
· Prior to maintenance by uncleared personnel, the IS will be completely cleared and all nonvolatile
data storage media removed or physically disconnected and secured. When a system cannot be
cleared, ISSM-approved procedures will be enforced to deny the uncleared individual visual and
electronic access to any classified or sensitive data that is contained on the system.
· A separate, unclassified copy of the operating system (e.g., a specific copy other than the copy(s)
used in processing information), including any floppy disks or cassettes that are integral to the
UNCLASSIFIED//FOR OFFICIAL USE ONLY
UNCLASSIFIED//FOR OFFICIAL USE ONLY
71
Joint DoDIIS/Cryptologic SCI Information Systems Security Standards
11 April 2003
operating system, will be used for all maintenance operations performed by uncleared personnel.
The copy will be labeled “UNCLASSIFIED—FOR MAINTENANCE ONLY” and protected IAW
procedures established in the SSAA/SSP. Maintenance procedures for an IS using a non-removable
storage device on which the operating system is resident will be considered and approved by the
ISSM on a case-by-case basis.
13.3.2 (U) General Maintenance Requirements
13.3.2.1 (U) Maintenance Log
A maintenance log must be maintained for the life of the IS. The maintenance log should include
the date and time of maintenance, name of the individual performing the maintenance, name of
escort, and a description of the type of maintenance performed, to include identification of
replacement parts. Maintain this log for the life of the IS.
13.3.2.2 (U) Location of Maintenance
Maintenance should be performed on-site whenever possible. Equipment repaired off-site and
intended for reintroduction into a SCIF may require protection from association with that particular
SCIF or program.
13.3.2.3 (U) Removal of Systems/Components
If systems or system components must be removed from the SCIF for repair, they must first be
purged, and downgraded to the appropriate classification level, or sanitized of all classified data and
declassified IAW ISSM-approved procedures. The ISSM, or designee, must approve the release of
all systems and parts removed from the system, in accordance with Chapter 20.
13.3.2.4 (U) Use of Network Analyzers
Introduction of network analyzers that provide maintenance personnel with a capability to do
keystroke monitoring must be approved by the ISSM, or designee, prior to being introduced into
an IS.
13.3.2.5 (U) Use of Diagnostics
If maintenance personnel bring diagnostic test programs
(e.g., software/firmware used for
maintenance or diagnostics) into a SCIF, the media containing the programs must be checked for
malicious codes before the media is connected to the system, must remain within the SCIF, and
must be stored and controlled at the classification level of the IS. Prior to entering the SCIF,
maintenance personnel must be advised that they will not be allowed to remove media from the
SCIF. If deviation from this procedure is required under special circumstances, then each time the
diagnostic test media is introduced into a SCIF it must undergo stringent integrity checks (e.g.,
virus scanning, checksum, etc.) prior to being used on the IS and, before leaving the facility, the
media must be checked to assure that no classified information has been written on it. Such a
deviation must be approved by the ISSM.
13.3.2.6 (U) Introduction of Maintenance Equipment into a SCIF
All diagnostic equipment or other items/devices carried into a SCIF by maintenance personnel will
be handled as follows:
· Systems and system components being brought into the SCIF shall, as far as practical, be inspected
for improper modification.
UNCLASSIFIED//FOR OFFICIAL USE ONLY