Source: http://www.isf.rl.af.mil:8001/IRD/isisjitf/isis/amhs/isad/amhs4.html

Approved by:
S. Hersch, MDA AMHS Program Mgr

Approved by:
LtCol J. Schepley
Electronics Systems Center
AMHS Program Manager

Approved by:
H. Williams, MDA AMHS QA Mgr

Approved by:
G. Gies, MDA AMHS Chief Engineer

Prepared by:
J. Evans, AMHS Development Mgr.

Submitted by:
McDonnell Douglas Aerospace (MDA)
8201 Greensboro Drive, McLean, VA, 22102

Developed for:
Electronic Systems Center (ESC)
Air Force Materiel Command (AFMC)

1. Purpose

2. AMHS Architecture

3. Identification of Named Objects

4. Identification of AMHS Subjects

5. Assumptions

6. Access Controls 6

    6.1  Information Labels 
    6.2  Discretionary Access Controls (DAC) 
    6.3  Mandatory Access Controls (MAC) 
    6.4  Release Marking Controls(RMAC) 

7. Integrity

A. Increment 1 AMHS Security Requirements

Figure 2-1 AMHS Context Diagram 2

Figure 3-1 Taxonomy of Mappings Between Named Objects
(AMHS Objects) and Files.

1.PURPOSE

The purpose of the Informal Security Policy Model (ISPM) is extracted from Section 4 of Deborah J. Bodeau, Security Models in the System Design and Development Process, March 1986, MITRE Working Paper WP 26652.

"There is a need for clear communications about security among the organizations and individuals involved in developing and accrediting an application system. An informal security model provides a possible means of facilitating such communications. ...

"An informal model can facilitate communications about security in three ways. First, an informal security model can be constructed early in system development. Thus, it can provide a basis for discussions about specific design issues. When an informal model is constructed early, it will be based primarily on security policy and the general approach to system design, but can incorporate information about COTS or other existing software that will be part of the system. That is, it can mix generalities about the security policy with specifics about the behavior of COTS software. ...

"Second, an informal model is written with the goal of providing understanding of the security-relevant characteristics of the proposed system, rather than providing a basis for proving theorems. Thus, it can be written in natural language, supplemented by mathematical language and diagrams where appropriate. This makes it accessible to a broader audience than a formal model, which requires some degree of mathematical sophistication of its audience. Since an informal model can be more widely read, it can provide the basis for discussion and reasoning about the proposed system design. This discussion can include representatives of the user, acquisition support organizations, the contractor, and the DAA(s). Reasoning about the informal model includes determining whether the system it describes enforces the security policy. ...

"Finally, an informal model can be adaptive: it can change over the course of system development to incorporate changes in design, interpretations of general policy statements, and details about specific system behavior as they become available. As these details and changes are incorporated, the resulting version of the informal model can be checked against the security policy. ..."

Accordingly, this informal model provides a basis for discussing the security-relevant characteristics of the DoDIIS AMHS in terms of the hardware and software architecture, including the integrated COTS products that have a bearing on security enforcement. It is presented in natural language at an appropriate level of abstraction. Design and implementation details are provided only to the extent that they enhance presentation and reasoning about the security attributes of the AMHS.

Figure 2-1 provides a context for discussing the AMHS and its environment. The figure shows the site LAN which interconnects a number of user workstations and intelligence application servers. The AMHS server is one of the intelligence application servers on the site LAN.

The AMHS provides communications links for the site to external sources. Specifically, the AMHS links to:

• Communications Support Processor (CSP)
• AGT Gateguard
• Associated Press (AP)
• United Press International (UPI)
• Reuters
• Foreign Broadcast Information Service (FBIS).

Formal AUTODIN messages arrive to and are sent from the site via the CSP. This communication link is read/write. Formal message traffic can also be received from the Local Digital Message Exchange (LDMX) network through the AGT Gateguard front end system. The Gateguard supports a receive only capability. Wire service traffic arrives over the AP, UPI, Reuters, and FBIS links. These links are receive only.

The AMHS is a distributed application that follows the client/server paradigm. The server software resides on the AMHS server. (From the standpoint of this model, the AMHS server is a single processor. However, its physical implementation is on multiple processors (1-3) on the DEC 2100, the number depending on the site size). The client software resides on the user workstations.

Two COTS products are key to AMHS security and are considered in this informal security policy model. The first is OSF/1, the operating system (OS) for the AMHS server. OSF/1 provides protection features at the OS-level mandated for compartmented mode systems. The AMHS design uses these OS-level protections to provide necessary safeguards for the AMHS.

The second key COTS product is TOPIC. TOPIC is a text retrieval engine that includes a system profiling mechanism. TOPIC system profiles are applied as safeguards to enforce site discretionary access control policies for both message distribution and retrospective search. The TOPIC software is distributed, part executing on the AMHS server, and part executing as client software on the user workstations.

THE AMHS SUPPORTS THREE NAMED OBJECTS. EACH OF THESE IS STORED AND MAINTAINED ON THE AMHS SERVER.

Named Object	Description	Organization
Messages	Messages are ASCII text . They arrive via one of the communication links (i.e., CSP, AP, AGT Gateguard, UPI, Reuters, and FBIS), or are created by users for transmission to CSP and on to AUTODIN.	1 message per file.
Profiles	Profiles are implemented within TOPIC. They consist of "Profile TOPICs" (in the form of concept trees) and "Profile Maps" (in the form of weights and thresholds).	Many profiles per multiple files.
	The AMHS supports three sets of profiles:
	** System Profiles, used to enforce the site's Discretionary Access Control Policy.
	** Installed User Profiles, installed by the profile administrator and used to determine profile-based message distribution.
	** Uninstalled User Profiles, used for retrospective searches.
Message Queues	Message Queues are implemented within TOPIC (and are known within TOPIC as "Hot Document Lists").	Many message queues per multiple files.

These objects are AMHS named objects. While AMHS V2.x no longer has CMW requirements, compartmented mode design attributes have been retained in the porting effort from the MLS+ system to the ported OSF/1 V2.x system. Since CMW features have been retained in the AMHS, it is worth understanding how the AMHS named objects map to CMW protected objects (i.e., files). The mappings, however, do not affect the system high nature of AMHS V2.x.

Figure 3-1 presents, in matrix form, a taxonomy of the possible mappings. The matrix also shows where each of the named objects fits into the taxonomy.

The matrix shows that Messages are "simple" named objects, with a straightforward one-to-one mapping to CMW files. As a result, CMW security attributes such as sensitivity labels, information labels, and read/write/execute bits are automatically available for Messages.

Taxonomy of Mappings between Named Objects and Files		Can named objects share the same file?
		No	Yes
Are named objects split across more than one file?	No	* AMHS Messages * These named objects are simple, storing 1 object per file.	* no AMHS named objects * These named objects are combined, storing many objects per file.
	Yes	* no AMHS named objects * These named objects are dispersed, requiring many files to store a single object.	***AMHS Message Queues * ***AMHS Profiles * These named objects are complex, and have no clean mapping to CMW-protected objects.

The matrix further shows that Message Queues and Profiles are complex objects, with a many-to-many mapping to CMW files. As a result, CMW security attributes do not have a straightforward mapping to Message Queues and Profiles.

The AMHS supports two types of subjects: (1) users (and processes acting on their behalf), and (2) processes operating independent of any user (i.e. daemon processes). The AMHS supports five user roles:

		AMHS Users
*	Generic User	Intelligence Analysts use AMHS message handling capabilities in support of their individual missions.
*	Message Administrator	The Message Administrator assigned to each organization reviews incoming record messages that have been distributed by address to that organization. The Message Administrator determines further distribution to other Analysts.
*	Profile Administrator	The Profile Administrator manages the site's collection of "profiles," consisting of both user and system profiles, and assists users in constructing user profiles.
*	System Administrator	The System Administrator monitors, maintains, and controls the configuration, performance, and operation of the AMHS.
*	Information System Security Officer(ISSO)	The ISSO controls access to AMHS capabilities and security relevant data, manages user accounts, and monitors the effectiveness of security controls.

In addition, one process acting on behalf of the user is significant from the security perspective:

		AMHS Processes Operating on a User's Behalf
*	TOPIC Client	The TOPIC Client is a process that operates on the user's behalf. It resides on the user workstation, and provides the mechanism for reviewing Message Queues, displaying messages, and formulating retrospective queries.

The AMHS supports a number of daemon processes, both on the AMHS servers and the user workstations. With regards to system security, the most significant daemon processes are:

		AMHS Server Daemon Processes
*	Document Feed	The AMHS includes a Document Feed daemon for each external communication link (i.e., CSP, AP, UPI, Reuters, and FBIS). Whenever a new message arrives (on its communications link), Document Feed receives the message, stores it on disk in the document database, and notifies the TOPIC Partition Builder that a new message has arrived.
*	TOPIC Partition Builder	The TOPIC Partition Builder maintains certain indexes and internal data structures for groups or "partitions" of messages. When notified of a new message, it "adds" the message to the partition by updating its indexes and internal data structures; it then notifies the TOPIC Server.
*	TOPIC Server	The TOPIC Server controls the flow of TOPIC processing. It passes messages onto the TOPIC Profiler for profiling, fields requests from TOPIC Clients, and schedules partition mergers.
*	TOPIC Profiler	The TOPIC Profiler compares messages against user and system profiles. An entry is made in a user's Incoming Message Queue (TOPIC "Hot Document List") whenever the message "hits" that user's profile, without being excluded by the system profiles.

6.1 Information Labels

Information labels are not required for the AMHS V2.x system.

6.2 Discretionary Access Controls (DAC)

The site's Discretionary Access Control policy applies to profile-based distribution (of message traffic and free text) and retrospective searches (of the message database). The site's DAC policy is captured in the System Profiles (Assumption A5: Valid System Profiles).

DAC System Profiles: TOPIC supports System Profiles through an entry called the "Access Profile" within the "User Preferences File". During initialization, the TOPIC Client reads the User Preferences File and then sets the System Profiles to the specified Access Profile. The various system profiles, and their mappings to users (and User Preferences Files), are managed by the Profile Administrator.

DAC Enforcement for Profile-Based Distribution: Profile-based distribution is accomplished in a two step process. The TOPIC Profiler performs the first step, applying user profiles to the incoming stream of message traffic. The TOPIC Client performs the second step, applying System Profiles to the results of the first step. In this way, profile-based distribution is always subject to System Profiles and always complies with the site's DAC policy.

DAC Enforcement for Retrospective Searches: Retrospective searches are initiated by the user through the TOPIC Client. The user formulates a search query via an (uninstalled) user profile. Before beginning the search, the TOPIC Client logically "ands" the search query and the user's System Profile, assuring that the search results are appropriately constrained. Thus, retrospective searches always comply with the site's DAC policy.

6.3 Mandatory Access Controls (MAC)

Mandatory Access Controls are not required for AMHS 2.x.

6.4 Release Marking Controls (RMAC)

Release Marking Controls are not required for AMHS 2.x.

The AMHS similarly assures the integrity for outbound AUTODIN messages during message composition, coordination, and release. The AMHS calculates and stores a CRC-16 during message composition. If the message composer changes any CRC-16 protected parts of the message, the AMHS recomputes the CRC-16.

Coordinators do not receive messages, only a pointer to a message that resides in the composer's or releaser's queues. In outbound processing a CRC is done whenever the message is moved from one directory to another.If the release authority changes any portion a message during message release, the AMHS recomputes its CRC-16. After the final change and CRC-16 recomputation, the release authority may release the message. The AMHS then transmits the message along with its associated CRC-16 to the CSP in order that message integrity may be verified by CSP.

CRC-16 is not used for AP, UPI, Reuters, or FBIS messages.

[End]