Image Product Library [IPL]

 

Proposed

NIMA Library Guard

Concept of Operations

DRAFT

Proposed NIMA Library Guard CONOPS

Draft

20 January 1998

1.0 Introduction

1.1 Purpose

1.2 Scope

1.3 Methodology

1.4 Assumptions

1.5 Background or Problem Definition

2.0 Production and Dissemination Environment

2.1 Overview of Current Imagery Production Process

2.2 Production Process Systems

2.2.1 Imagery Processors

2.2.2 Exploitation Workstations

2.2.3 Libraries and Databases

2.3 Imagery Production Process

3.0 Concept of Operations

3.1 Guard System Concepts

3.2 Guard Process

3.2.1 SCI channels

3.2.2 US Secret Channels

3.3 Guard Specifics

3.3.1 Site Location

3.3.2 Data Supported

3.3.3 File Integrity

3.3.4 Users Interface

3.3.5 Server Interface

3.3.6 Guard Interfaces

3.4 Sample Scenarios

3.4.1 Low Side User Queries for imagery file information

3.4.2 Low Side User Transfers data

3.4.3 High Side User Queries for imagery file information

3.4.4 High Side User Exports Data

3.4.5 High Side User Establishes retrieval profile within a Low side Library

3.4.6 Low Side User Establishes retrieval profile within a High side Library

3.4.7 Low Side Library Passes Image Manifest Message to a High side Host

3.4.8 High Side Host Generates a Work Allocation Message in response to IMM

3.4.9 Exceptions

3.5 Data Transfers

3.5.1 High to Low

3.5.2 Low to High

4.0 Security

4.1 Mode of Operation

4.1.1 Sensitivity of Data Processed

4.1.2 Clearance Levels/Formal Access Approvals/Need-to-Know

4.2 Data Transfer Process

4.3 Audit

5.0 Glossary

1.0 Introduction

1.1 Purpose

This document provides users and developers a Concept of Operations (CONOPS) for the National Imagery and Mapping Agency (NIMA) Library Guard, enabling them to under-stand the operational and security concepts behind the transfer of files between security levels. It provides a description of the Guard System and of how production and end users will use its capabilities. Finally, it provides a planning basis for the development of command, agency, and individual United States Imagery and Geospatial Standards (USIGS) site CONOPS as they relate to the NIMA Library Guard.

1.2 Scope

This document provides a top-level description of the operational concept for the NIMA Library Guard System, a trusted system for transferring files between servers and server interfaces at different security levels. It centers on the types of files that will be transferred and the circumstances of their transfer. It does not address other USIGS initiatives related to collection, processing, dissemination, exploitation, global communications, and site infrastructure except as they affect the NIMA Library Guard System.

1.3 Methodology

This CONOPS focuses on the imagery process and where in the process Guard System functions occur. Specific design and implementation features are deliberately omitted to give the developer the greatest latitude. The specific piece of hardware that might perform a given function is, for this same reason, not stated. Section 3.2 describes the flow of imagery files from collectors to database libraries. Section 3.5 describes this flow in scenarios from the users’ perspectives.

1.4 Assumptions

This CONOPS is based on the following assumptions:

a. There are two levels of Guard System users: Users of library data, e.g. imagery analysts, and managers of the Guard System, e.g. Guard System Administrators and Guard Security Managers.

b. Users of library data request and access data through applications on their library servers or client workstations. These applications access Guard Transfer Services. Users do not access Guard Transfer Services directly.

c. Only Guard System Administrators and Guard Security Managers (GSA/GSM) will have accounts on the Guard. They will be able to update or change both security and administrative Guard options.

d. USIGS Interoperability Profile (UIP) compliant systems follow the standards and specifications listed in the UIP, making them common and interoperable.

e. The Guard System will provide a connection between TS SCI (SI/TK) and US Secret Collateral LANs or UIP compliant imagery or database servers.

f. All systems are accredited to operate at their respective security levels.

g. All files and messages, regardless of their classification, will be handled as if they are the highest classification of the system. For example, Secret Collateral files residing on a TS SCI server will be handled as TS SCI files.

h. Each file and formatted message intended to transfer through the Guard System must have a security classification designator associated with it. The designator may be assigned by a trusted system for raw data or by an analyst. This process places the ‘person in the loop’ at the exploitation phase of imagery production; in manual guards, the reviewing person is part of the transfer process.

i. The Guard System must be able to verify a file’s integrity, i.e., that a file has not been modified or become corrupted since its classification was associated with it, or since an authorized modification was made. For ease of terminology in this document, the term ‘seal’ will be used to describe the means of protecting files to achieve this end.

j. Initial version of the Guard will process National Imagery Transmission Format (NITF) formatted files. Future versions will process other formats, including, for example, Tagged Image File Format (TIFF), Graphics Interchange Format (GIF), Tape Format Requirements Document (TFRD), and Geospatial data. Data from legacy systems must be converted to an approved format to be accepted for transfer. A discussion of integrity seals for the NITF standard is included at Attachment 1.

1.5 Background or Problem Definition

Most imagery is currently transmitted, processed, transferred and exploited within SCI enclaves; most imagery is, however, classified Secret Collateral. The Secret Collateral user community would like access to these files in a Secret Collateral environment. Currently the transfer of Secret Collateral files from a TS SCI system to a Secret Collateral system requires the services of a human reviewer to ensure SCI information is not compromised; a guard and a firewall provide added security for intrusion protection.

NIMA’s goal is to provide this transfer through an automated guard system, enabling users to access all Secret Collateral imagery products on Secret Collateral systems. To provide this service, an automated Guard System must be able to determine the classification of each file, and to verify that the file has been neither modified nor corrupted since its classification was determined, i.e. that the file’s integrity is intact. To provide this verification, the Guard System must provide a means of determining the integrity of a file. The automated Guard System encompasses the first system or analyst to process an image and is distributed throughout the entire imagery production process. The process usually associated with a Guard, the actual transfer of files between two different security levels, is called the Guard Transfer Process. In this CONOPS, the Guard System will provide users with a trusted process, referred to in this document as a ‘seal’, that associates all security significant attributes of a file in such a way that if any security relevant attributes are modified, (i.e., the file’s integrity is destroyed), the Guard System can detect the loss of integrity. The Guard System, then, confirms that this seal is intact.

The Library Guard System includes the components that perform the following functions:

1) association of classification with imagery, imagery products, and other files,

2) association of changes to image files (including, for example, changes made to headers, subheaders, text, symbols and graphics) with the individual making those changes,

3) verification of the integrity of the associated changes and the accountability of the change originator,

4) verification of the file’s classification and,

5) provision of intrusion protection.

The Library Guard System also includes the security process: the Security Policy, the User Security Operating Instructions, and the process that labels and seals each file. This process that labels and seals files is at the heart of the Library Guard system; it enables the Guard System to determine if a file’s integrity is intact. The Guard System will allow files with their integrity intact and with the correct classification to pass through to the other side. A firewall function keeps knowledge of the network architecture and addresses on each side of the guard from systems and users on the other side.

The USIGS Interoperability Profile (UIP) is the approved interface standard for USIGS systems. This document, boarded Aug. 97, points to the standards that define the interoperability details of interfaces between library elements. A message format or computer system that is UIP compliant meets the precise options and parameters of the interoperability standard.

2.0 Production and Dissemination Environment

2.1 Overview of Current Imagery Production Process

At the highest level of abstraction, the imagery production process is similar for all types of imagery. Imagery data is collected (e.g., by satellite or airplane) and sent to an initial processor; from this processor the data is sent through a dissemination system to a library or database. The imagery files are copied from the database to an exploitation system where intelligence products are generated; the resulting imagery products are returned to the database. Authorized users can access the images they need from this database. This entire process takes place within SCI enclaves for most types of imagery, even though most imagery is at the Secret Collateral level. The following figure depicts this process.

There are several places Secret Collateral imagery can be labeled and sealed within the SCI environment, and several places the sealed Secret Collateral imagery can be separated from the SCI environment. Secret Collateral imagery can be labeled and sealed at the processor, at the exploitation workstation, and at the library. Secret Collateral imagery can be transferred from the SCI environment between the collector and the processor, between the processor and the database or library, between the database or library and the exploitation system, and between the database or library and the user. These possibilities are discussed in the next paragraph.

2.2 Production Process Systems

A file must be sealed when its classification is first determined and the classification label is associated with the file; the association is usually made by entering the classification in the file’s header or metadata. When the classification is entered by an automated process (as described in paragraph 2.2.1 below), the file must be sealed by an associated automated process. When the classification is entered by the analyst, as part of the exploitation process described in paragraph 2.2.2 for example, the file must be sealed automatically as part of the save and store process. This section discusses the possible locations for the application that seals new and edited products.

2.2.1 Imagery Processors

For imagery coming from collateral collectors, the classification is associated with the file at the processor. An application to seal the file at the processor provides the earliest possible time and location for this protection.

 

2.2.2 Exploitation Workstations

Analysts determine an imagery product’s classification during the exploitation process by the data they add to the metadata or other layers. A seal added by the system when the product is saved would ensure all products would be sealed before being stored on the server.

 

2.2.3 Libraries and Databases

All Secret Collateral files will be sealed before they reach a library or database, therefore file integrity will be assured for all Secret Collateral files in TS SCI and Secret Collateral libraries and databases.

2.3 Imagery Production Process

The imagery production process differs from one production center to another. A detailed description of a specific production center will be included in a future version of the CONOPS. Also included with the description will be a discussion of the Guard functions and where they could reside.

3.0 Concept of Operations

This CONOPS describes a secure, automated process to transfer imagery and imagery products between TS SCI (SI/TK) and US Secret systems.

3.1 Guard System Concepts

a. The Guard System will transfer imagery and imagery products from one security classification level to another without requiring a person in the review process at the time of the information transfer. (The review process takes place earlier in production process as indicated in paragraph 1.4.h) The Guard System will confirm the integrity of the classification of each file and of the information stored with the file. Confirming a file’s integrity is part of a larger integrity process. The process for developing and maintaining the integrity of information, which is analogous with the Guard System, encompasses the first system or analyst to process an image and is distributed throughout the entire imagery production process. The following figure depicts the Security Guard Architecture.

b. The trusted computer that is connected to and actually transfers data between the TS SCI (SI/TK) systems and the Secret Collateral systems will be physically located on the TS SCI side.

c. Each Guard will be able to transfer data to, and receive data from, a specific, known set of ISSM or Guard System Administrator designated UIP compliant servers or server interfaces. Servers not a part of this known set must process data requests and file transfers through servers that are. Each Guard must authenticate the source of the data it receives, however this limitation on the number of systems permitted to send and receive data from each Guard will ease the burden of authenticating the source.

d. The Guard System will ensure, through a firewall application, that users and servers in one security level have no knowledge of user ids, server IP addresses, or the network architecture at another security level.

3.2 Guard Process

As described in Section 2, imagery files move from collector to processor to database/library to exploitation system to database/library to customer. Secret Collateral data and files can be transferred from the TS SCI environment to the Secret Collateral environment at several different points in the imagery production process. Section 3.2.1 describes the data flow of Secret Collateral files within the TS SCI environment and between the TS SCI and Secret Collateral environments. TS SCI imagery products and files, being of a higher classification than the low side, will be rejected by the Guard as described in Paragraphs 3.2.1.7.b and 3.4.9. Section 3.2.2 describes the data flow of Secret Collateral files within the Secret Collateral environment and between the Secret Collateral environment and the TS SCI environment.

3.2.1 SCI channels

Imagery data flows from collectors to a TS SCI processor, from the processor to TS SCI communication elements, and from the communication elements to an SCI library, storage database, or exploitation system. Regardless of their classification, all files are handled as if they are TS SCI. In this environment, the process to seal a file will reside on both the processor and on the exploitation workstation. It is this process that enables the Guard System to determine file integrity. Both the process and the operating system on which it resides must be trusted. The possible locations for this process are described in the following paragraphs. For each location, the process is described by who is involved in the process, what is going to happen, the precondition of the file, the guard function that will take place, and the post condition of the file.

3.2.1.1 The TS SCI processor receives data from a collector, determines the data’s classification based on the classification of the collector, enters the classification in a header field, seals the file, and sends it to a dissemination system for delivery to an exploitation system database.

Upon receiving imagery from a collector, the TS SCI processor adds data, including classification, to the metadata header of each file. Data from a Secret Collateral collector is labeled US Secret by the processor. The files are sealed as soon as the classification process is complete, providing a means of confirming their security classification, i.e. file integrity, in an SCI environment.

Who:

What:

Precondition:

Guard system functions:

Post condition:

The TS SCI processor

Adds security classification label and seals the file

Unexploited Secret Collateral imagery data with no header data or meta data

Add classification label

Seal file to establish basis for determining file integrity

Imagery data with header or meta data and a seal on the file

3.2.1.2 The TS SCI processor neither adds header data nor seals the files it receives from the collectors. The file is sent through a dissemination system to a TS SCI library or database.

a. Data is passed from the TS SCI collector to the TS SCI processor.

Who:

What:

Precondition:

Guard system functions:

Post condition:

 

The processor

Neither header data nor seal are added

Unexploited imagery data with no header data or meta data

None performed

Unexploited imagery data with no header data, no metadata, and no seal on the file. Unlabeled files in an SCI system are considered to be TS SCI.

 

3.2.1.3 Analyst exploits Secret Collateral imagery and saves the new imagery product as Secret Collateral.

a. An analyst is notified, whether from a specific query or an automatic distribution, that an unexploited Secret Collateral file is available in a library. The analyst requests and receives a copy of the file, exploits the file, adding data to the metadata, text or symbol layer of the file, determines that the classification of the exploited file, now an imagery product, is still Secret Collateral, and labels this new imagery product as Secret Collateral. The seal in invalid until the file is re-sealed in step b.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Imagery analyst, exploitation system

Adds data to one or more layers of the file and determines the security classification of each layer and of the file.

Imagery file is unexploited with a Secret Collateral classification and seal from the processor.

Change classification label

The file is now an imagery product with a classification label of Secret Collateral and a seal that is no longer valid.

b. The analyst saves the imagery product to the library as Secret Collateral. The initial, unexploited file remains unchanged.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Imagery analyst, exploitation system database

The exploitation system automatically seals the file before saving it with the changes.

The imagery product has a security classification label of Secret Collateral and a seal that is no longer valid.

Seal file to establish basis for determining file integrity

The file is now a product with a Secret Collateral classification label and a new (valid) seal.

3.2.1.4 Analyst exploits TS SCI imagery and saves the new imagery product as Secret Collateral.

a. An analyst receives a copy of an unexploited TS SCI file from a library, whether from a specific query or an automatic distribution. As part of the exploitation process, the analyst adds data to, or deletes data from, one or more layers of the file and determines that the classification of the new product is Secret Collateral.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Imagery analyst, exploitation system

The analyst adds data to one or more layers of the file.

Imagery file is unexploited with a classification of TS SCI.

Add security classification label

The file is now an imagery product with a security classification label of Secret Collateral.

b. The analyst saves the file to the library as a Secret Collateral imagery product. The initial, unexploited TS SCI file remains unchanged. The exploited product is US Secret.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Imagery analyst, exploitation system

The exploitation system automatically seals the file before saving it with the changes

The imagery product has a security classification of Secret Collateral but is not sealed.

Seal file to establish basis for determining file integrity

The file is now an imagery product with a Secret Collateral classification label and a seal

 

3.2.1.5 Analyst edits exploited TS SCI imagery product.

a. The analyst receives a copy of a TS SCI product from a library, edits one or more layers, and confirms that the product classification is Secret Collateral.

Who:

What:

 

Precondition:

Guard system functions:

Post condition:

Imagery analyst, exploitation system

The analyst adds data to, or deletes data from, one or more layers of the file, determines the classification is Secret Collateral, and changes the classification to Secret Collateral.

Imagery product has a TS SCI security classification and a seal

Enter file classification

The new product has a Secret Collateral classification and a seal that is no longer valid.

b. The analyst saves the edited file to the library as a new Secret Collateral imagery product.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Imagery analyst, exploitation system

The exploitation system automatically seals the file before saving it as a new product

New imagery product with a Secret Collateral classification label and a seal that is no longer valid.

Seal file to establish basis for determining file integrity.

The file is now a new product with a Secret Collateral classification label and a valid seal

3.2.1.6 Analyst edits a Secret Collateral exploited imagery product and saves it as the same product or as a new product with the same classification.

a. The analyst exploits a Secret Collateral product from a library, edits one or more layers, and confirms that the product classification is still Secret Collateral.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Imagery analyst, exploitation system

The analyst adds data to one or more layers of the file and determines the classification is still Secret Collateral

Imagery product has a Secret Collateral classification and a valid seal

Confirm file classification

The edited product has a Secret Collateral classification and a seal that is no longer valid.

b. The edited file is saved to the library as a new Secret Collateral imagery product.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Imagery analyst, exploitation system

The exploitation system automatically seals the file before saving it as a new product

Edited imagery product with a Secret Collateral classification label and a seal that is no longer valid

Seal file to establish basis for determining file integrity

The file is now a new product with a Secret Collateral classification label and a valid seal.

c. The edited file is saved back to the library as the same file.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Imagery analyst, exploitation system

The analyst saves the file with the changes. The exploitation system automatically seals the file before saving it.

The edited imagery product has the correct security classification and a seal that is no longer valid.

Seal file to maintain basis for determining file integrity

The edited product has a Secret Collateral classification label and a valid sealed

3.2.1.7 File transits through the Guard Transfer Process.

a. Only sealed Secret Collateral or lower products and files will be able to pass through the Guard Transfer Process from TS SCI servers to Secret Collateral servers.

Who:

What:

Precondition:

Guard system functions:

 

Post condition:

Guard filter

The Guard Transfer Process will review the classification of the product and validate the file’s integrity seal

Imagery product has a Secret Collateral classification and a valid integrity seal

Check seal to determine file integrity is intact

Check classification label to verify classification level

Pass file through

The file is now located on a Secret Collateral server.

b. Failure Mode. Files with a classification level higher than the Guard’s low side, or those whose integrity can’t be verified, will be rejected by the Guard.

Who:

What:

Precondition:

Guard system functions:

 

Post condition:

 

Guard filter

The Guard rejects files whose classification is higher than the low side or whose integrity is not intact.

Imagery product has a classification higher than the Guard’s low side, no classification, or an invalid integrity seal.

Check seal to determine file integrity is intact;

Check classification label to verify classification level;

Reject file.

The file has been rejected, its header information sent to a designated directory. A status message has been sent to the file’s source and to the Guard Security Manager.

3.2.2 US Secret Channels

Secret Collateral imagery data flows from collector to processor to Secret Collateral dissemination port. The processor automatically creates the file format and the security classification field. This field associates the Secret Collateral classification with the file. Because classification and other data are added to the file at this point, the file must be sealed before it is sent to a dissemination port for distribution.

3.2.2.1 Sealed Secret Collateral files from paragraph 3.2.1.1 above pass through the Guard Transfer Process to a Secret Collateral system.

Who:

What:

 

Precondition:

Guard system functions:

 

Post condition:

Guard filter

The Guard Transfer Process will review the classification of the product and determine that the file’s integrity has been maintained.

Imagery product has a classification and an integrity seal.

Check seal to determine file integrity is intact

Check classification label to verify classification level

Pass file through

The file is now located on a Secret Collateral server. It has a classification label and a seal.

 

3.2.2.2 Sealed Secret Collateral files from paragraph 3.2.1.1 above are passed through a firewall directly to a Secret Collateral dissemination system for distribution to a Secret Collateral network. (The Guard Transfer Process is not involved.)

Who:

What:

Precondition:

Guard system functions:

 

Post condition:

Imagery Processor, Secret Collateral Firewall

The processor sends Secret Collateral imagery files through a firewall to a Secret Collateral dissemination system.

Imagery file has a classification and an integrity seal

Check seal to determine file integrity is intact

Check classification label to verify classification level

Pass file through firewall

The file is now located on a Secret Collateral server. It has a classification label and a seal

 

3.2.2.3 Secret Collateral files enter the Secret Collateral system directly through a Secret Collateral dissemination system or through a tape transfer.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Secret Collateral files

Files are entered into Secret Collateral systems

Files are Secret Collateral. They are not sealed and they have no security classification label.

None

Files reside on a Secret Collateral server. They have no security classification label and no seal.

 

3.2.2.4 Analysts exploit the sealed Secret Collateral files in a Secret Collateral environment.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Imagery analyst, exploitation system

The analyst exploits the file, adding to or deleting information from the metadata, symbols or text layers of the file.

An imagery product or file with a Secret Collateral classification label.

Confirm classification.

The file is now a new product with a Secret Collateral classification label.

The exploited product will be sealed when it is saved.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Analyst, Exploitation system

The file is automatically sealed when the analyst saves.

An imagery product or file with a Secret Collateral classification label.

Seal file.

The file has a seal confirming its integrity.

3.2.2.5 Analysts exploit the files entering the Secret Collateral servers directly.

Who:

What:

Precondition:

Guard system functions:

Post condition:

Analysts, Exploitation system

The file is exploited

An imagery product or file; it may or may not have a Secret Collateral classification label.

Enter classification label, seal file.

The file has a security classification label and a seal confirming its integrity.

3.2.2.6 Sealed Secret Collateral files are sent through a Guard Transfer Process to a TS SCI server.

Who:

What:

 

Precondition:

Guard system functions:

 

Post condition:

Secret Collateral File, Guard filter

The Guard Transfer Process will review the classification of the product and determine that the file’s integrity has been maintained

Imagery product has a classification and an integrity seal

Check seal to determine file integrity is intact

Check classification label to verify classification level

Pass file through

The file is now located on a TS SCI server. It has a classification label and an integrity seal

3.3 Guard Specifics

3.3.1 Site Location

The Library Guard at each site will be physically located in a TS SCI facility, connected to the local TS SCI LAN. The low side of the Guard will connect to the local US Secret LAN.

3.3.2 Data Supported

a. File Formats: Only UIP compliant formats will be supported; NITF formatted files will be the first format supported. TFRD files are supported as part of the imagery production process; they will be supported by the Guard in a later version.

b. Query Formats: Requests for files can be submitted through the guard in the UIP compliant format. This format permits queries to be sent through the Guard without using electronic mail. (This format will be supported only if inter-classification level queries are permitted.)

c. Query Response Formats: A list of files meeting the query conditions will be returned in a UIP compliant format. Small preview pictures, or thumbnail images, for the files meeting the query conditions will be returned when requested. (This format will be supported only if inter-classification level queries are permitted.)

d. Status messages: The Guard will send and receive UIP compliant status messages indicating the status of file transfers.

e. Profile Change Format: Users receive notification of new imagery based on individual notification profiles. Requests for notification profile changes will be submitted in a UIP compliant format.

e. Electronic Mail: Electronic Mail will not be supported.

3.3.3 File Integrity

A process for establishing and maintaining the integrity of the information in each file provides assurance that a file has not been modified since its classification was determined and the classification was entered into the appropriate data field or otherwise associated with the file. The Guard will check the classification of the file and verify that the file’s integrity is intact. Files with a classification no higher than the classification of the low side and with intact integrity will be passed. Files with a classification higher than the low side, or files whose integrity can’t be verified, will be rejected by the Guard.

3.3.4 Users Interface

3.3.4.1 System Administrators. (These accounts will be restricted to console access.)

a. Information System Security Manager (ISSM). The ISSM, or designee, at each location will be responsible for maintaining the Library Guard in an accreditable state. The ISSM determines the systems with which the Guard can communicate. Other ISSM functions are TBD.

b. Network Security Officer (NSO). The NSO will work with the ISSM to maintain the Library Guard and the networks to which it is connected in an accreditable state.

c. Guard System Administrators: Guard System Administrators at each site will be responsible for TBD.

d. Configuration Management. During development of the Guard, configuration control will be the responsibility of the developer. Upon completion, configuration management will become the responsibility of a cognizant authority. The ISSM must be involved in all CM decisions.

3.3.4.2 Imagery Library Users

a. Neither low side nor high side users will be able to log into the Guard. The Guard and all systems on the other side, whether the other side is high or low, are invisible to all users. Except as indicated in paragraph 3.3.4.1 above, users will not be able to log into the Guard, nor through the Guard to servers on the other side. Users will not be able to directly browse or query a server on the other side of the Guard. (A query response, if queries are permitted between TS SCI and US Secret servers, may look like a browse, but will in fact be a response to a query passed between applications on the high and low servers.)

b. All user communications to the other side of the Guard, including file transfers and requests for imagery, will be processed by applications on UIP compliant servers or server interfaces, e.g. workstations. No user will communicate directly with the Guard.

3.3.5 Server Interface

a. The Guard will accept UIP formatted requests and files from servers and server interfaces that are part of its known set. Applications on these servers and server interfaces will send data to the Guard for delivery to a server or server interface on the other side. All imagery files and products will include a classification label and an integrity seal.

b. The Guard will deliver UIP formatted requests and files to servers and server interfaces that are part of its known set. Applications on the destination servers and server interfaces will receive data.

c. Users will log on to their own servers or server interfaces and use those applications to send requests and files through the Guard to the other side.

d. Users will log on to their own servers or server interfaces and use those applications to receive files from the other side.

3.3.6 Guard Interfaces

a. The Library Guard will connect two networks, usually the local US Secret LAN and the local TS SCI LAN. The systems that will interface with the Guard will be connected to one of these networks. These systems include, but are not limited to, the NIL, CILs, IPLs, exploitation workstations, and Integrated Production Cell (IPC). Standard network communication protocols will be used.

b. Possible Library Guard locations and how that might affect the interface will be discussed here.

d. Networks. The Library Guard provides a connection between TS SCI and US Secret networks. The local TS SCI LAN supports TS SCI libraries, workstations and TS SCI LANs and connects to the JWICS network. The local US Secret LAN supports US Secret libraries, workstations and US Secret LANs and connects to the SIPRNET. Only cleared US users have access to these two networks.

3.4 Sample Scenarios

Scenarios distinguish between automatic file notification based on a user’s retrieval profile and a user’s query request. To the Guard, however, file transfers all look the same regardless of how they are initiated. The users don’t directly access the Guard, but send queries and request files through applications on their servers.

In these scenarios, data and formatted messages that will be accepted by the Guard are defined as follows:

Query - A UIP formatted request for data. Queries can contain parameters from metadata fields, including classification, location, and time.

Response - A query response will be one of two types. The first is a list of files meeting the query definition. The second is a group of thumbnail images for the files that meet the query definition.

File - An imagery file, imagery product, or data file selected by the user from the list above.

Retrieval Profile - A UIP formatted message with parameters for requested data. Notification of new files is sent to users automatically based on this profile.

IMM - The Imagery Manifest Message, a list of all imagery files received from a dissemination element, is sent to the SCI host for evaluation.

WAM - The Work Allocation Message, sent from the SCI host in response to an IMM, instructs a server to send imagery files to specific workstations and servers for exploitation. Because this message is generated by an SCI system, some fields, as determined by the ISSM, must be deleted by the Guard to ensure no SCI information is transmitted. The data in these fields are not evaluated.

3.4.1 Low Side User queries for imagery file information

a. The query goes to another low side server/library.

No Guard

b. The query goes to a high side server/library.

Guard Required

- Query goes low to high

- Response goes high to low

c. The query goes to both low side and high side servers.

Guard Required as above

3.4.2 Low Side User Transfers data

a. A file is sent from a low side server (source) to a low side server (destination)

No Guard required

b. A file is selected from a low side server (source) and is transferred to a high side server (destination)

Guard Required

- Selection request (no guard)

- File goes low to high

c. A file is selected from a high side server (source) and transferred to a low side server (destination)

Guard Required

- Selection request goes low to high

- File goes high to low

3.4.3 High Side User queries for imagery file information

a. A query goes to another high side server/library.

No Guard

b. A query goes through to a low side server/library.

Guard Required

- Query goes high to low

- Response goes low to high

c. A query goes to high and low servers.

Guard required as above.

3.4.4 High Side User Exports Data

a. A file is transferred from a high side server (source) to a high side server (destination)

No Guard required

c. A file is selected from a low side server (source) and transferred to a high side server (destination)

Guard Required

- Selection request goes high to low

- File goes low to high

3.4.5 High Side User establishes retrieval profile within a Low side Library

a. A formatted profile message is sent to a low side server.

Guard Required

- Message goes high to low

b. Imagery files are automatically sent from the low side server to the user’s high side server.

Guard Required

- Data goes low to high

3.4.6 Low Side User establishes retrieval profile within a High side Library

a. A formatted profile message is sent to a high side server.

Guard Required

- Profile message goes low to high

b. Notification of files is automatically sent from the high side server.

Guard Required

- Notification message goes high to low

3.4.7 Low Side Library passes Image Manifest Message to a High side Host

a. A low side library receives low side data and sends an IMM to the high side host.

Guard Required

- Message goes low to high

 

3.4.8 High Side Host generates a Work Allocation Message in response to IMM

a. A WAM goes to the low side library.

Guard Required

- WAM goes high to low

b. Based on the WAM, imagery files are sent from the low side server to a low side server.

No Guard Required

c. Based on the WAM, imagery files are sent from the low side server to a high side server.

Guard Required

- Data goes low to high

3.4.9 Exceptions

The Guard will review files as indicated in paragraph 3.6 below, and reject files that fail to meet one or more of its criteria. A formatted message will be sent to the sender and/or the system administrator when a file is rejected. The file header information will be recorded in an audit file and sent to a designated directory for review. The file itself will be discarded.

3.56 Data Transfers

The Guard will accept formatted files and data for consideration, reviewing the following fields before letting them pass.

Source Files must come from a system on its approved list.

Destination Files must be going to a system on its approved list.

Classification The file must be no higher than the low side of the Guard.

Integrity Check The file must not have been modified since it was last saved and sealed.

Work Allocation Messages passing from high to low The Guard will delete data from specific fields as directed by the high side ISSM.

Text fields In future version, the Guard may search text fields for ‘dirty’ words as directed by the high side ISSM.

3.56.1 High to Low

The following data types will be passed through the Guard from high to low:

UIP Formatted Queries for a high to low query

List of files matching a query for a low to high query

Thumbnails matching a query for a low to high query

Files matching a low to high query

Work Allocation Messages

UIP Formatted Profile information

Notification of new files matching profile information

Generic status message, i.e., "file not found"

3.56.2 Low to High

The following data types will be passed through the Guard low to high:

UIP Formatted Queries for low to high queries

List of files matching a query for a high to low query

Thumbnails matching a query for a high to low query

Files matching a high to low query

Status messages

Imagery Manifest Message

UIP Formatted Profile information

Notification of new files matching profile information

4.0 Security

Security Guard certification and accreditation process will be discussed here. Sites must accredit their own location and implementation of the Guard.

4.1 Mode of Operation

The Library Guard, connected to both high and low networks, will operate in a multi-level secure mode.

4.1.1 Sensitivity of Data Processed

No data higher than the low side network should be sent to the Guard. Data received by the Guard that is higher than that will be rejected.

4.1.2 Clearance Levels/Formal Access Approvals/Need-to-Know

TBD

4.2 Data Transfer Process

4.2.1 The Library Guard will check the security classification of the data to be transferred, the classification of the sending port, and the classification of the receiving port. If the data is a higher classification than the classification of the lowest port, the Guard will reject it. The Guard will also verify the file integrity. If the file’s integrity cannot be verified, the file will be rejected.

4.2.2 Work Allocation Messages (WAM) are created by legacy SCI systems that cannot be modified to delete fields in messages going to US Secret systems. The Guard will have to delete some fields to ensure no information higher than US Secret is sent. The data in these fields will not be evaluated against a table; they will be deleted outright.

 

 

4.3 Audit

The audit file will be accessible to the Guard Network Security Officer and others as designated by the NSO or ISSM. The audit file will include the following:

Each file transaction - sending and receiving system, file size, type of file, date/time, classification

Each rejected file - sending and receiving system, file size, type of file, date/time, classification, reason for rejection

System administration functions - adding users, editing tables,

policy modifications

5.0 Acronyms and Glossary

CIL Command Information Library

CONOPS Concept of Operations

Firewall A firewall function keeps knowledge of the network architecture and addresses on each side of the guard from systems and users on the other side.

GIF Graphics Interchange Format

IMM Imagery Manifest Message

IPC Integrated Production Cell

IPL Image Product Library

ISSM Information System Security Manager

JWICS Joint Worldwide Intelligence Communications System

A world wide TS SCI network

NIL National Information Library

NIMA National Imagery and Mapping Agency

NITF National Imagery Transmission Format

NSO Network Security Officer

SIPRNET Secret Internet Protocol Router Network

A world wide US Secret network.

TFRD Tape Format Requirements Document

Thumbnails Preview images

TIFF Tagged Image File Format

UIP USIGS Interoperability Profile

USIGS United States Imagery and Geospatial Information Systems

The USIGS Interoperability Profile (UIP) is the approved interface standard for USIGS systems.

WAM Work Allocation Messages

 

 

 

 

 

 

 

 

 

 

 

Attachment 1

Integrity Seals for the

National Imagery Transmission Format (NITF)

Standard

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This document was submitted as a Request for Change (RFC 95-051) to the NITF Standard March 1, 1995 but was never approved. It remains an excellent description of the file format and the integrity seal concept and application.