DI-SCRE-82522

Communications Security (COMSEC) Integration Evaluation Document (IED)

Specifies content and format for the COMSEC Integration Evaluation Document, which documents host security requirements, design, and validation for systems integrating NSA High Assurance Devices.

Approval DateApril 10, 2026

AMSC Number10640

Preparing Activity19

Project NumberSCRE-2026-001

OPR—

DTIC ApplicableNo

GIDEP ApplicableNo

Limitation—

Applicable Forms—

Approval Limitation—

Form Version—

DID Formatfree_text

963C CompliantYes

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

Supersedes

—

DI-SCRE-82523

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The COMSEC Integration Evaluation Document (IED) provides information regarding host security functional requirements, functional and physical design details, and requirement validation tasks to ensure appropriate system security requirements are met. Additionally, the COMSEC IED describes and contains security, functional, and software architecture composition, bypass control details, and a fail-safe design analysis.

This Data Item Description (DID) is applicable to all systems integrating National Security Agency (NSA) High Assurance Devices (HADs) and addresses the validation of how HADs are being securely integrated into any host system. Criteria requiring validation are outlined in HAD-specific host integration requirements, as well as the Host Integration Functional Requirements Document for the Design of Satellite Bypass External to the Cryptographic Device (see also reference 2.1. below). For the purposes of this document, the term "system" refers to the entire space vehicle not including the hosted payloads.

This DID contains the format and content preparation instructions for deliverable generation in support of the specific and discrete task requirements for this data item, as described in the contract.

Note: This DID is directly linked to and associated with DI-SCRE-82523, COMSEC Integration Test Report (ITR).

Preparation Instructions

1Reference documentsEmail [email protected] to request access to reference documents:

1.1Cryptographic Modernization Office - Space (CMO-S), United States Space Force Crypto Playbook: Program Management Guide to Satellite Cryptography

1.2Operational Security Doctrine (OSD) associated with the integrated High Assurance Device (HAD)

2Compliance documentsThe COMSEC IED shall demonstrate, describe, and maintain compliance with the applicable sections of each document cited below. Email [email protected] to request access to reference documents:

2.1CMO-S, Host Integration Functional Requirements Document for the Space Vehicle Design of a Bypass External to the Cryptographic Device

2.2National Security Agency, C Technical Report 02-00, Library No. S-247,160: "Fail-Safe Design and Analysis: Revised," 27 January 2000

3FormatThe Contractor's COMSEC IED shall contain narrative content, diagrams, and technical detail addressing each of the topics delineated in the following major sections and subsections. Provide data using the electronic preparation instructions below. The COMSEC IED shall:

3.1Formatting requirementsBe formatted strictly in accordance with the COMSEC IED Template established for this purpose and that is included in this DID.

3.2Classification and portion markingBe appropriately classified and portion marked in accordance with requirements provided in the Contractor's DD Form 254.

3.3Submission formatBe submitted in Microsoft Word format for initial submission and either Microsoft Word format or Adobe PDF format after review and validation for submission to the Government Program Office. Microsoft Word format is preferred as it supports more efficient tracking and management of changes.

3.4Embedded filesNot contain embedded files (i.e., Microsoft Visio drawings). All embedded pictures and diagrams must be converted to a JPG, PNG, TIFF, or GIF.

3.5Title pageInclude a title page that identifies the following:

3.5.1Program Name

3.5.2Contract Number

3.5.3Version/revision and date

3.5.4Contractor Program Manager's name and telephone number and, if applicable, the Government Program Office Point of Contact name and office designator

3.5.5Security Classification

3.5.6Distribution Statement

3.6Revision PageInclude a Revision Page, listing all past changes to the document in reverse chronological order.

3.7Reference and Compliance Documents listInclude a list of Reference and Compliance Documents, to include those cited in 1. and 2. above, and all other documents used to develop the COMSEC IED.

3.8Table of ContentsInclude a Table of Contents.

3.9Abbreviations and acronyms tableInclude a Table defining all the abbreviations and acronyms.

4ContentThe COMSEC IED shall:

4.1Integration Evaluation Document (IED) TemplateBe completed using the Integration Evaluation Document (IED) Template, Version 1.0, included in this DID. Note: Wherever requested information does not apply, identify it as "N/A."

4.2COMSEC IED TemplateThe COMSEC IED Template follows.

1System Requirements and Operational EnvironmentProvide a concise description of the top-level systems architecture, security services, and host integration functional requirements of the system design. This information includes an overview of the integration components and technology, if applicable, of the system to be protected, as well as a description of the operational environment and constraints (e.g., airborne, command post, access by cleared personnel only, etc.), to support the statement of top-level system security requirements and goals. The level of classification for the data protected by the system must also be identified in this section. Include a table listing the applicable host integration functional requirements.

1.1Scope

1.2Overview

1.3High-Level System Architecture

1.4Top-Level System Security Requirements and Goals

2Security Architecture[Note: This section applies to HAD integration as referenced in 2.1., including the use of any internal bypass functions (Cat 1).] Provide a detailed description of the system security design approach and architecture, components, and functions. The following lists the type of supportive information and level of detail to include in this chapter. Note: this is not an exhaustive list; use as an example: a. Commands and Messages (e.g., verbal descriptions, protocols/syntax & formats, parameters & parameter definitions, state transitions, checks, error conditions, responses) b. Data rates c. Memory (e.g., types, usage, mapping, handling - allocation/deallocation, separation & access) d. Communication protocols e. Timing characteristics f. Detailed descriptions of alarm conditions and responses g. Detailed descriptions of check functions For the NSA approved HAD embedded in the design, provide a detailed description of how the security features of that approved product are utilized in the system, including specific configurations, implementations, and modes of operation used. If the embedment is being used to satisfy system integration security requirements, a detailed description of how the host system utilizes and preserves the integrity of the security features of the embedded product is included in this chapter. This must include a detailed description of all interfaces, and how the host handles critical information passed to and from the embedded product. This Chapter of the COMSEC IED also outlines the internal cryptographic bypass policies, if applicable, as well as provides system design details for the security features and components used to support the host integration requirement compliance statements provided in Appendix A. In particular, provide design details for all system integration security functions required by reference 2.1. of this DID. The security architecture also covers redundant processors and comparators implemented to monitor system functions to ensure a robust High Assurance security design. A functional diagram and description of the Security Isolation (formerly the INFOSEC) Boundary, identifying the critical hardware and software components used to comply with the security requirements must be included in this section. For the system security features, provide a functional flow of all system operations to demonstrate how the product encrypts, decrypts, routes, stores and transmits classified data to meet customer mission needs described in Chapter 1. The requirement compliance statements in Appendix A reference the appropriate sections of Chapter 2 to provide the security design details needed to explain compliance.

2.1Operational Security Doctrine (OSD) ComplianceProvide comprehensive statements that outline how the integration implementation meets OSD compliance in accordance with applicable OSD(s) that will be provided to the Contractor, post-award.

3Functional and Physical ArchitectureThis section describes the high-level details of the sub-assemblies associated with the host integration components, and depicts how they will be deployed in its intended mission. Illustrate and describe a superset of functions, including data flows, control and status bypass and TEMPEST considerations in this section. Provide high-level diagrams of the integration components. Include details regarding the associated hardware and mechanical components as they relate to system integration.

4Software ArchitectureDiscuss key characteristics of the software architecture as it relates to the features and functionality required to accomplish mission objectives. This section shows the external software interconnections as well as the relationship between software modules. Topics include detailed information regarding control and status bypass implementation, software updates, boot image, and drivers.

5Fail Safe Design Analysis[Note: This section only applies if the host implements bypass external to the HAD.] This Chapter will document the first two FSDA Steps in the Modernized Process, which is based on a reduced set of the Steps defined in reference 2.2. to this DID. The Step numbers in parenthesis refer to the Step taken from this document that still apply in the Modernized Process: a. Identify the Required Security Services (Step 1) and Data Classification Level (New) b. Determine which Unauthorized Events (as outlined in reference 2.1. to this DID) are applicable and provide rationale for those that are not (Step 4)

5.1Functional/Physical Decomposition (Step 6)This Chapter also provides a functional and physical description/decomposition of the design of the system integrating the HAD, giving the reader an explanation of the hierarchy of functions within the system and how this functional architecture satisfies the top-level requirements identified in Chapter 1. The description logically flows from the system's top-level functions, down through several layers of functional partitioning, to a functional design level where each function represents an individual task that is identified as occurring within or by a specific physical element of the system. The description provides the reader with an explanation of the functional and physical elements of the system (e.g., hardware, tamper approach, software, databases, and communication paths) and their relationships to each other (e.g. Client/Server, sub-element). The description associates the functions identified in this Chapter to specific elements, explaining the interdependencies among the elements in achieving functionality, and provides FSDA Functional-to-Physical System Decomposition as detailed in reference 2.2. to this DID. a. This Chapter deals with the last two Steps of Modernized Fail-Safe Design Analysis that address: 1. Unauthorized Events Analysis & Failure Summary (Steps 7 and 9) 2. Physical Pin-to-Pin Analysis (Step 8) 3. Detailed information related to the content of the Steps specified above is provided in reference 2.2. to this DID.

6Final Covert Channel Analysis Report (CCA)[Note: This section only applies if the host system implements external consistent bypass.] This chapter includes a documented description of the CCA. A covert channel is a method of communicating data through or within a system in violation of the information flow policy using paths that are not intended to carry the data. Covert channels only exist in the context of systems that require information flow policies to be enforced. Covert channels are characterized as either storage or timing channels as defined below. The covert channel analysis must address both types of channels. A storage channel is a covert channel that directly or indirectly writes to a storage location to pass information. The storage location may correspond to data-at-rest, such as a file on disk. Examples of this include using steganography to encode a message in the low order bits of an image or modulating the size of a text file. Alternatively, a storage channel may write to storage locations corresponding to data in transit (e.g., using protocol header fields which may bypass filtering or encryption) with non-fixed values to convey information through a network encryptor or a firewall. The CCA Report must contain the following: a. A description of the covert channel protection policy must be provided that mitigates violations to the information flow requirements. The policy must document how the assurance required for the system is commensurate with the sensitivity of the information protected and risks associated with the technology and operating environment. b. The covert channel protection policy must specify the level of CCA, (i.e., informal, systematic/formal, or exhaustive), required for the target system. * For a systematic CCA, the analysis must describe how it is structured and repeatable. * For an exhaustive CCA the analysis must describe how it is structured, repeatable, and exercises all possible methods for determining the existence of covert channels. c. The covert channel protection policy must specify whether covert channels are to be documented, limited (in terms of capacity), monitored, or eliminated. For a particular system, if multiple mitigations are specified, the distinction must be based on the characteristics of an individual channel. d. The CCA must document the analysis of each information flow policy specified in the system security policy in terms of a potential covert channel. e. The CCA must document the analysis of both the design and implementation of the target system for potential covert channels. Low-level implementation details, including external interface definitions and source code or hardware logic specification must be used as inputs to the analysis. f. The CCA must document the analysis of all bypass policies for potential creation of covert channels. g. The CCA must identify each covert channel and describe a worst-case exploitation scenario for the channel. h. The CCA must identify the characteristics of each channel, including but not limited to: * Categorization (storage or timing) * Capacity estimate (including the method used for estimation) * Direction (ingress, egress, bidirectional) * Encoding (direct or indirect) * Reliability (noisy or noiseless) i. The CCA must describe all assumptions made during the analysis and provide evidence that the level of analysis and mitigation complies with the specified policy. An example of such an assumption would be the relative physical or logical location of the processes participating in the covert communication. For example, for an inline network encryptor, the processes may be hosts residing on the plaintext and ciphertext networks. Alternatively, a covert channel may require malicious code to be executing in the network processors themselves.

7Reference Documents* Operational Security Doctrine (OSD) associated with the integrated High Assurance Device (HAD) * Interface Control Document (ICD) associated with the integrated HAD * User's Guide/Manual associated with the integrated HAD

8Compliance documents* [List all applicable compliance documents]

Appendix ASecurity Design Requirements Compliance and Validation

Appendix BComment and Response MatrixAppendix B of the COMSEC IED tracks comments along with the appropriate Developer responses and changes. These responses must answer the question or comment and reference corresponding locations in the body of the document where the content was updated in response to the comment and marked by change bars. These comments and responses include remedial actions conducted to address deficiencies and remain within the COMSEC IED for each revision.

References

—

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer