Partitioning Communication System Protection Profile

Version 0.0

Wed Aug 13 11:28:47 EDT 2003

Prepared By: Objective Interface Systems

Prepared For: IAD/NSA

Foreword

Before the Table of Contents there should be a foreword stating:
a) the reason for the PP,
b) where to send comments for the PP,
c) a revision history of the PP,
d) what authority the PP has, if any (e.g., A DoD standard, an NSA standard, an ANSI standard) and what communities (if any) are referencing the PP.

                       Item

1 - Introduction

1.1 - Identification

1.2 - Protection Profile Overview

1.3 - Organisation (Optional)

1.4 - Related Protection Profiles

2 - TOE Description

3 - TOE Security Environment

3.1 - Secure Usage Assumptions

3.2 - Threats to Security

3.3 - Organisational Security Policies

4 - Security Objectives

4.1 - Security Objectives for the TOE

4.2 - Security Objectives for the Environment

5 - IT Security Requirements

5.1 - TOE Security Functional Requirements

5.2 - TOE Security Assurance Requirements

5.3 - Security Requirements for the IT Environment (Optional)

5.4 - Security Requirements for the Non-IT Environment (Optional)

6 - Rationale

6.1 - Introduction and TOE Description Rationale (Optional)

6.2 - Security Objectives Rationale

6.2.1 - Policies

6.2.2 - Threats

6.3 - Security Requirements Rationale

6.3.1 - Functional Security Requirements Rationale

6.3.2 - Assurance Security Requirements Rationale

6.4 - Dependency Rationale

6.5 - Security Functional Requirements Grounding in Objectives

6.6 - Rationale for Extensions

List of Tables

                       Item

Table - 6-1 Mapping the TOE Security Environment to Security Objectives

Table - 6-2 Tracing of Security Objectives to the TOE Security Environment

Table - 6-3 Functional Component to Security Objective Mapping

Table - 6-4 Functional and Assurance Requirements Dependencies

Table - 6-5 Requirements to Objectives Mapping

Conventions and Terminology

Conventions

[edit]

Terminology

[edit]

[Definitions extracted from CC v. 2.1, supplemented or abridged as necessary.]

Document Organisation

[edit]

Section 1 provides the introductory material for the protection profile

Section 2 provides general purpose and TOE description

Section 3 provides a discussion of the expected environment for the TOE. This section also defines the set of threats that are to be addressed by either the technical countermeasures implemented in the TOE hardware or software or through the environmental controls.

Section 4 defines the security objectives for both the TOE and the TOE environment.

Section 5 contains the functional and assurance requirements derived from the Common Criteria, Part 2 and 3, respectively, that must be satisfied by the TOE.

Section 6 provides a rationale to explicitly demonstrate that the information technology security objectives satisfy the policies and threats. Arguments are provided for the coverage of each policy and threat. The section then explains how the set of requirements are complete relative to the objectives, and that each security objective is addressed by one or more component requirements. Arguments are provided for the coverage of each objective. Next Section 6 provides a set of arguments that address dependency analysis, strength of function issues, and the internal consistency and mutual supportiveness of the protection profile requirements

An acronym list is provided to define frequently used acronyms.

A reference section is provided to identify background material.

1 - Introduction

Provide document management and overview information necessary to operate a protection profile registry.The Introduction should provide background information that enables the reader to gain a high-level understanding of the protection profile.

1.1 - Identification

Title: Partitioning Communication System Protection Profile

Authors:

Vetting Status:

CC Version: 2.1 Final

General Status:

Registration:

Keywords:

1.2 - Protection Profile Overview

[edit]

This Protection Profile (PP) specifies the security functional requirements and the security assurance requirements for a Partitioning Communication System that enforces basic information security policies in a distributed computing environment.

The Partitioning Communication System enforces Data Isolation, Information Flow, Periods Processing and Damage Limitation policies with respect to data communicated between subjects via communcation networks. These security policies can used by distributed IT systems to implement other, application-specific security policies.

A Partitioning Communication System that is evaluated against this PP, and that is utilized correctly, may form a foundation for building larger systems that, as a whole, are Multi Level Secure (MLS). However, the Partitioning Communication System itself only serves as a building block, and the security requirements for the larger MLS system are not addressed in this document.

The Partitioning Communication System depends on an underlying operating system that meets the requirements of, and has been evaluated against, the Partitioning Kernel Protection Profile [citation].

By providing "end-to-end" versions of the security functions offered by a Partitioning Kernel, the Partitioning Communication System facilitates the construction of secure distributed systems; the Partition Communication System makes it possible to take a system built for a single processor and relocate a partition to another processor while preserving enforcement of all security policies.

[List & discussion of end-to-end security functions.]

The security functional requirements and the security assurance requirements discussed in this protection profile are intended to support these [n] functions. In order to provide high assurance of satisfying the [n] functions, there are four characteristics of the Partitioning Communication System that must be supported by the lower level functional and assurance requirements herein:

The Partitioning Communication System must be implemented in such a way that the information flow control security policy is always invoked and the information flows in a timely manner.
The Partitioning Communication System must be non-bypassable and subject to no conditions limiting the enforcement of the information flow control security policy.
The Partitioning Communication System must be tamper-proof, which requires that the communication system's operations be isolated from other activities within the system.
The Partitioning Communication System must be evaluatable, which requires the above security functions to be explicitly defined and the proof of the implementation to be capable of being checked with a freely available theorem proving system. The Kernel must also be sufficiently modular and well designed so that formal methods may be reasonably applied.

This PP does not include many security functions that might be considered to be part of a secure information processing system:

Access control
Audit
Emission Security
[...]

1.3 - Organisation (Optional)

[edit]

1.4 - Related Protection Profiles

[edit]

Partition Kernel Protection Profile

[MILS CORBA Protection Profile?]

[List of ways this PP may differ from Protection Profiles for other systems of this type (whatever that would mean). Some of these can be adapted from the PKPP.

No Users (subjects only).
No Specific Security Function Policy (as Bell and La Padula, Biba, Non-interference).
Partitioning of communication channel capacity (bandwith).
]

[Intended for use in Multi-Level Security (MLS) systems. Also good for...]

2 - TOE Description

[edit]

2.1 Product Type

The Partitioning Communication System is a mechanism that allows communication between the partitions of a Partitioning Kernel Protection Profile-compliant operating system, while providing support for the enforcement of application security policies.

All inter-system communications must go through the PCS. ("On-board" interprocess communication may or may not be mediated by the PCS.) [But, in any case, it could be facilitated by an OS-independent IPC interface layer (that may or may not be considered part of the PCS)]

[Possible diagram: depicts three systems, each with application, PCS and device partitions.]

Subjects' use of communication channels is partitioned such that... one subject's use of the communication system shall not transfer information to other subjects, other than as authorized.

In addition to restricting explicit connections between partitions, the PCS suppresses covert channels that could be introduced by the sharing of inter-system communication paths. [Example: detection of changes in available channel capacity ("bandwidth") by low clearance level subject reveals info about high-level traffic. How this is accomplished, as by the use of an isochronous network protocol, is not specified by this Protection Profile.]

The Partitioning Communication System is intended to be used [on top of a PKPP-compliant OS; Real-time, embedded systems...]

Permits use of CORBA GIOP as well as any application protocol...

Does not contain any application-specific code and can be evaluated once and used without modification in many different systems.

Can be configured to perform data transformations, as encryption, between the application and lower layers;

Includes a configuration manager which verifies the identity of other systems, either at start-up or when re-configuration is initiated (by an authorized partition).

[Also, a component that maps Information Flow and Community of Interest policies into a table of permitted inter-partition connections.]

2.2 TOE Operational Environment

3 - TOE Security Environment

Summarise the security environment in which the TOE will be used and the manner the TOE will be employed.

3.1 - Secure Usage Assumptions

A.NO_PCS_BYPASS:
System Partition Kernel configuration prevents by-pass of PCS.

A.PARTITIONING_KERNEL:
There is a [correct? evaluated?] Partitioning Kernel for the PCS to run on.

A.SHARED_COMM_RMI:
[Possible "risk mitigation" assumptions if some security objectives are optional. An application would need to assure against some covert channels itself if the PCS doesn't use isochronous networking, traffic generation...]

A.TRUSTED_CODE_LOAD:
Partitioning Kernel will correctly load the PCS code into its own partition(s).

A.TRUSTED_CONFIG_LOAD:
Trusted load of configuration data. [or is this not an assumption?]

3.2 - Threats to Security

T.BACK_FLOW:
Acknowledgement of messages sent from subject A to subject B may result in an acknowledgement--negative or positive--that violates information flow policy.

T.CONFIG_CORRUPT:
A malicious or faulty subject may attempt to modify or corrupt configuration data used by the PCS to enforce information flow policy by changing the configuration data used by the PCS. A malicious or faulty subject may also attempt to bypass the information flow policy by using configuration data that, while valid, differs from that being used by another PCS node. [Node? What's a Node?]

T.DOS:
A malicious or faulty subject may attempt to block or delay other subjects from sending or receiving communications by exhausting or monopolizing shared resources or the resources of another PCS node.

T.EAVESDROP:
A malicious or faulty subject may attempt to intercept communications it is not authorized to receive by examining memory other than that which has been prepared for its use by the PCS. [...or by reading network data directly, bypassing the PCS]

T.INFO_CORRUPTED:
A subject may attempt to modify or corrupt information communicated to or from another subject by accessing data used by the PCS.

T.MASQUERADE:
A malicious or faulty subject may attempt to masquerade as another subject by tampering with PCS-internal data structures or by presenting invalid data to PCS interfaces.

T.PCS_TAMPER:
A malicious or faulty subject may attempt to tamper with PCS code or PCS-internal data structures by accessing memory used by the PCS or by presenting invalid data to PCS interfaces.

T.POOR_DESIGN:
Unintentional or intentional errors in requirement specification, design or development of the PCS may occur. [As worded, lacks a threat agent. Might change to a policy.]

T.POOR_IMPLEMENTATION:
Unintentional or intentional errors in implementing the design of the PCS may occur.

T.POOR_TEST:
Incorrect behavior resulting from faulty design or implementation may not be detected by the testing program.

T.TRIANGULATE:
Data used to send or receive messages may reveal the location--on-board or off--of the counterpart subject, or allow one subject to know that the other has moved.

T.UNSANITIZED:
A malicious or faulty subject may attempt to gain unauthorized information from an improperly sanitized or incompletely initialized shared resource.

T.WRONG_CODE:
The code of the PCS may be corrupted, or an incorrect version substituted, prior to being loaded into the computer in which it will execute.

T.WRONG_COMM:
A malicious or faulty subject may attempt to send information to another subject it is not authorized to communicate with. [...either directly or via a covert channel.]

3.3 - Organisational Security Policies

P.COMPATIBLE_CONIFGS:
The MILS Partitioning Communication System shall ensure that communications are permitted only between correctly loaded and configured systems. [This policy is intended to deal with our desire to not assume a correct, enclave-wide load of software and configuration data.]

P.C_OF_I:
[Community of Interest placeholder]

P.DATA_ISOLATION:
The MILS Partitioning Communication System shall ensure that no task anywhere in the enclave will have access to any other partition's data in the entire system, except as authorized by the MILS Partition Kernel or by the Partitioning Communication System information flow policy. [Text is from Vanfleet e-mail. Note we assume communication with non-MILS systems will be via application-level firewalls and bridges and therefore these communications will be outside the scope of our Protection Profile.]

P.INFO_FLOW:
The MILS Partitioning Communication System shall ensure that only explicitly authorized information flows occur. [Add explicit recognition that this includes suppression of covert channels?]

P.NONINTERFERENCE:
The MILS Partitioning Communication System shall ensure that authorized information flows are not prevented by subjects not involved in the transfer. [Need to change this policy's identifier as this doesn't have anything to do with Goguen & Meseguer's noninterference property.]

P.UNIQUE_PARTITION:
The MILS Partitioning Communication System shall ensure that each subject is bound to exactly one partition on one processor, and that each partition is bound to exactly one subject. [The Objectives section must expand on the need to uniquely identify partitions throughout the enclave, and deal with issues of their identity in view of partition creation, lifetime and persistence.]

P.VPN:
[Virtual Private Network placeholder]

4 - Security Objectives

Identify and define the security objectives for the TOE and its environment. Security objectives should reflect the stated intent, be suitable to counter all identified threats, and cover all identified organisational securitypolicies and assumptions.

4.1 - Security Objectives for the TOE

O.CLEAR_RESIDUAL: Clear Residual Information
The PCS shall clear residual information before reassigning a resource to a subsequent subject.

O.CONFIG_MGT: Software Configuration Management
Every delivered version of the PCS shall be uniquely identified and all changes to the PCS and its development environment shall be documented, tracked and controlled. [...this configuration not to be confused with the management of the PK or PCS who-can-talk-to-who configuration.]

O.CONFIG_SUPPORT: Info Flow Configuration Support
[This one would mandate tools to help the application system designer set up the who-can-talk-to-who configurations.]

O.CONFIG_VALIDATION: Info Flow Configuration Validation
[Check, for example, that two nodes have compatible versions of their info-flow configuration data.]

O.C_OF_I: Community of Interest Rules
[Community of Interest placeholder]

O.ENV_TRUSTED_LOAD:
[Should Security Objectives for the Environment be related to policies, threats and assumptions in the Rationale section? They are in the PKPP but CCTookit doesn't seem to think so...]

O.IDENTIFIED_PEER: Confirmed Identification of Peers
[Is who we're talking to who we think we're talking to?]

O.INFORMATION_FLOW: Information Flow Rules
The Partitioning Communication System shall enforce information flow control between partitions and into and out of partitions, as specified in its configuration data. [when it's involved in the communication, anyway.]

O.NO_REPLAY: Prevention of Message Replay
The MILS Partitioning Communication System shall ensure that an authorized information flow can not be initiated or replayed by a subject other than the initial, authorized source.

O.REQUEST_VALIDATE: Validation of Requests of PCS
The Partitioning Communication System shall validate all service requests from subjects to ensure that the subject has permission to issue the requests and the requests will not reduce the Partitioning Communication System's ability to enforce the security policies.

O.RESOURCE_GUARANTEE: PCS Resource Guarantees
[to include memory, CPU and allotted share of communications channel resources]

O.RESOURCE_LIMITS: PCS Resource Limitations
[In particular, limitation of comm. channel use, as we're thinking this will allow reliable blind up-writing.]

O.RESPECT_PRIORITY:
[Something about respecting subject's real-time priority]

O.SELF_PROTECT: Protection of PCS
[PROTECTED_BY_KERNEL? PROTECTED_MEMORY?]

O.SOUND_DESIGN: Sound Design
The design of the Partitioning Communication System shall account for, and be traceable to, all of its functional requirements. [This is a place to hang assurance requirements. Copied from the PKPP.]

O.SOUND_IMPLEMENTATION: Sound Implementation
The implementation of the Partitioning Communication System shall be an accurate instantiation of its design. [Copied from the PKPP.]

O.TESTING: Testing
The Partitioning Communication System shall undergo independent Security Verification Testing, based at least in part on an independent vulnerability analysis. [Again, copied from the PKPP]

O.TRANSMISSION_CONFIDENTIALITY:

O.TRANSMISSION_INTEGRITY:

O.TRANSMISSION_UNOBSERVABLE:
[The term "Unobservable" is from FPR_UNO. I'm thinking of it leading to a requirement for pre-encryption traffic generation, or padding, so that a third party observer can't tell if a subject is sending something or not. ]

O.VPN: Virtual Private Network Rules
[Virtual Private Network placeholder]

Security Objectives:

4.2 - Security Objectives for the Environment

Clearly state and trace security objectives for the environment back to aspects of identified threats not completely countered by the TOE and/or organisational security policies or assumptions not completely met by the TOE

[OE.PARTITIONING_KERNEL]

[OE.TRUSTED_LOAD]

5 - IT Security Requirements

Include an overall summary of the functional and assurance security requirements for the TOE, and environment.

5.1 - TOE Security Functional Requirements

5.1.1 - Cryptographic support (FCS)

5.1.1.1 - Cryptographic key generation (FCS_CKM.1)

The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: cryptographic key generation algorithm] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].^FCS_CKM.1.1

5.1.1.2 - Cryptographic key distribution (FCS_CKM.2)

The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [assignment: cryptographic key distribution method] that meets the following: [assignment: list of standards].^FCS_CKM.2.1

5.1.1.3 - Cryptographic key access (FCS_CKM.3)

The TSF shall perform [assignment: type of cryptographic key access] in accordance with a specified cryptographic key access method [assignment: cryptographic key access method] that meets the following: [assignment: list of standards].^FCS_CKM.3.1

5.1.1.4 - Cryptographic key destruction (FCS_CKM.4)

The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [assignment: cryptographic key destruction method] that meets the following: [assignment: list of standards].^FCS_CKM.4.1

5.1.1.5 - Cryptographic operation (FCS_COP.1)

The TSF shall perform [assignment: list of cryptographic operations] in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].^FCS_COP.1.1

5.1.2 - User data protection (FDP)

5.1.2.1 - Complete information flow control (FDP_IFC.2)

The TSF shall enforce the [assignment: information flow control SFP] on [assignment: list of subjects and information] and all operations that cause that information to flow to and from subjects covered by the SFP.^FDP_IFC.2.1
The TSF shall ensure that all operations that cause any information in the TSC to flow to and from any subject in the TSC are covered by an information flow control SFP.^FDP_IFC.2.2

5.1.2.2 - Simple security attributes (FDP_IFF.1)

The TSF shall enforce the [assignment: information flow control SFP] based on the following types of subject and information security attributes: [assignment: the minimum number and type of security attributes].^FDP_IFF.1.1
The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [assignment: for each operation, the security attribute-based relationship that must hold between subject and information security attributes].^FDP_IFF.1.2
The TSF shall enforce the [assignment: additional information flow control SFP rules].^FDP_IFF.1.3
The TSF shall provide the following [assignment: list of additional SFP capabilities].^FDP_IFF.1.4
The TSF shall explicitly authorise an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly authorise information flows].^FDP_IFF.1.5
The TSF shall explicitly deny an information flow based on the following rules: [assignment: rules, based on security attributes, that explicitly deny information flows].^FDP_IFF.1.6

5.1.2.3 - Limited illicit information flows (FDP_IFF.3)

The TSF shall enforce the [assignment: information flow control SFP] to limit the capacity of [assignment: types of illicit information flows] to a [assignment: maximum capacity].^FDP_IFF.3.1

5.1.2.4 - Partial elimination of illicit information flows (FDP_IFF.4)

The TSF shall enforce the [assignment: information flow control SFP] to limit the capacity of [assignment: non-empty list of types of illicit information flows] to a [assignment: maximum capacity].^FDP_IFF.4.1
The TSF shall prevent the following types of [assignment: non-empty list of types of illicit information flows].^FDP_IFF.4.2

5.1.2.5 - Basic internal transfer protection (FDP_ITT.1)

5.1.2.6 - Transmission separation by attribute (FDP_ITT.2)

The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] to prevent the [selection: disclosure, modification, loss of use] of user data when it is transmitted between physically-separated parts of the TOE.^FDP_ITT.2.1
The TSF shall separate data controlled by the SFP(s) when transmitted between physically-separated parts of the TOE, based on the values of the following: [assignment: security attributes that require separation].^FDP_ITT.2.2

5.1.2.7 - Full residual information protection (FDP_RIP.2)

The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: allocation of the resource to, deallocation of the resource from] all objects.^FDP_RIP.2.1

5.1.3 - Security management (FMT)

5.1.3.1 - Management of security attributes (FMT_MSA.1)

The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to restrict the ability to [selection: change_default, query, modify, delete, ][assignment: other operations] the security attributes [assignment: list of security attributes] to [assignment: the authorised identified roles].^FMT_MSA.1.1

5.1.3.2 - Secure security attributes (FMT_MSA.2)

The TSF shall ensure that only secure values are accepted for security attributes.^FMT_MSA.2.1

5.1.3.3 - Static attribute initialisation (FMT_MSA.3)

The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to provide [selection: restrictive, permissive, other property] default values for security attributes that are used to enforce the SFP.^FMT_MSA.3.1
The TSF shall allow the [assignment: the authorised identified roles] to specify alternative initial values to override the default values when an object or information is created.^FMT_MSA.3.2

5.1.4 - Privacy (FPR)

5.1.4.1 - Unobservability (FPR_UNO.1)

The TSF shall ensure that [assignment: list of users and/or subjects] are unable to observe the operation [assignment: list of operations] on [assignment: list of objects] by [assignment: list of protected users and/or subjects].^FPR_UNO.1.1

5.1.5 - Protection of the TOE Security Functions (FPT)

5.1.5.1 - Abstract machine testing (FPT_AMT.1)

The TSF shall run a suite of tests [selection: during initial start-up, periodically during normal operation, at the request of an authorised user, other conditions] to demonstrate the correct operation of the security assumptions provided by the abstract machine that underlies the TSF.^FPT_AMT.1.1

5.1.5.2 - Failure with preservation of secure state (FPT_FLS.1)

The TSF shall preserve a secure state when the following types of failures occur: [assignment: list of types of failures in the TSF].^FPT_FLS.1.1

5.1.5.3 - Basic internal TSF data transfer protection (FPT_ITT.1)

The TSF shall protect TSF data from [selection: disclosure, modification] when it is transmitted between separate parts of the TOE.^FPT_ITT.1.1

5.1.5.4 - Replay detection (FPT_RPL.1)

The TSF shall detect replay for the following entities: [assignment: list of identified entities].^FPT_RPL.1.1
The TSF shall perform [assignment: list of specific actions] when replay is detected.^FPT_RPL.1.2

5.1.5.5 - Non-bypassability of the TSP (FPT_RVM.1)

The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed.^FPT_RVM.1.1

5.1.5.6 - TSF domain separation (FPT_SEP.1)

The TSF shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects.^FPT_SEP.1.1
The TSF shall enforce separation between the security domains of subjects in the TSC.^FPT_SEP.1.2

5.1.5.7 - Internal TSF consistency (FPT_TRC.1)

The TSF shall ensure that TSF data is consistent when replicated between parts of the TOE.^FPT_TRC.1.1
When parts of the TOE containing replicated TSF data are disconnected, the TSF shall ensure the consistency of the replicated TSF data upon reconnection before processing any requests for [assignment: list of SFs dependent on TSF data replication consistency].^FPT_TRC.1.2

5.1.5.8 - TSF testing (FPT_TST.1)

The TSF shall run a suite of self tests [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions ][assignment: conditions under which self test should occur] to demonstrate the correct operation of the TSF.^FPT_TST.1.1
The TSF shall provide authorised users with the capability to verify the integrity of TSF data. ^FPT_TST.1.2
The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code.^FPT_TST.1.3

5.1.6 - Resource utilisation (FRU)

5.1.6.1 - Limited priority of service (FRU_PRS.1)

The TSF shall assign a priority to each subject in the TSF.^FRU_PRS.1.1
The TSF shall ensure that each access to [assignment: controlled resources] shall be mediated on the basis of the subjects assigned priority.^FRU_PRS.1.2

5.1.6.2 - Maximum quotas (FRU_RSA.1)

The TSF shall enforce maximum quotas of the following resources: [assignment: controlled resources] that [selection: individual user, defined group of users, subjects] can use [selection: simultaneously, over a specified period of time].^FRU_RSA.1.1

5.1.6.3 - Minimum and maximum quotas (FRU_RSA.2)

The TSF shall enforce maximum quotas of the following resources [assignment: controlled resources] that [selection: individual user, defined group of users] can use [selection: simultaneously, over a specified period of time].^FRU_RSA.2.1
The TSF shall ensure the provision of minimum quantity of each [assignment: controlled resource] that is available for [selection: an individual user, defined group of users, subjects] to use [selection: simultaneously, over a specified period of time]^FRU_RSA.2.2

5.1.7 - Trusted path/channels (FTP)

5.1.7.1 - Trusted path (FTP_TRP.1)

The TSF shall provide a communication path between itself and [selection: remote, local] users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from modification or disclosure.^FTP_TRP.1.1
The TSF shall permit [selection: the TSF, local users, remote users] to initiate communication via the trusted path.^FTP_TRP.1.2
The TSF shall require the use of the trusted path for [selection: initial user authentication, ][assignment: other services for which trusted path is required].^FTP_TRP.1.3

5.1.8 - Placeholder Functional Components (FXX)

5.1.8.1 - X (FXX_XXX.1)

5.2 - TOE Security Assurance Requirements

5.2.1 - Configuration management (ACM)

5.2.1.1 - Complete CM automation (ACM_AUT.2)

The CM system shall provide an automated means by which only authorised changes are made to the TOE implementation representation, and to all other configuration items.^ACM_AUT.2.1C
The developer shall use a CM system.^ACM_AUT.2.1D
The CM system shall provide an automated means to support the generation of the TOE.^ACM_AUT.2.2C
The developer shall provide a CM plan.^ACM_AUT.2.2D
The CM plan shall describe the automated tools used in the CM system.^ACM_AUT.2.3C
The CM plan shall describe how the automated tools are used in the CM system.^ACM_AUT.2.4C
The CM system shall provide an automated means to ascertain the changes between the TOE and its preceding version.^ACM_AUT.2.5C
The CM system shall provide an automated means to identify all other configuration items that are affected by the modification of a given configuration item.^ACM_AUT.2.6C

5.2.1.2 - Advanced support (ACM_CAP.5)

The CM system shall provide measures such that only authorised changes are made to the configuration items.^{ACM_CAP.5.10C}
The CM system shall support the generation of the TOE.^{ACM_CAP.5.11C}
The acceptance plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE.^{ACM_CAP.5.12C}
The integration procedures shall describe how the CM system is applied in the TOE manufacturing process.^{ACM_CAP.5.13C}
The CM system shall require that the person responsible for accepting a configuration item into CM is not the person who developed it.^{ACM_CAP.5.14C}
The CM system shall clearly identify the configuration items that comprise the TSF.^{ACM_CAP.5.15C}
The CM system shall support the audit of all modifications to the TOE, including as a minimum the originator, date, and time in the audit trail.^{ACM_CAP.5.16C}
The CM system shall be able to identify the master copy of all material used to generate the TOE.^{ACM_CAP.5.17C}
The CM documentation shall demonstrate that the use of the CM system, together with the development security measures, allow only authorised changes to be made to the TOE.^{ACM_CAP.5.18C}
The CM documentation shall demonstrate that the use of the integration procedures ensures that the generation of the TOE is correctly performed in an authorised manner.^{ACM_CAP.5.19C}
The reference for the TOE shall be unique to each version of the TOE.^ACM_CAP.5.1C
The developer shall provide a reference for the TOE.^ACM_CAP.5.1D
The CM documentation shall demonstrate that the CM system is sufficient to ensure that the person responsible for accepting a configuration item into CM is not the person who developed it.^{ACM_CAP.5.20C}
The CM documentation shall justify that the acceptance procedures provide for an adequate and appropriate review of changes to all configuration items.^{ACM_CAP.5.21C}
The TOE shall be labelled with its reference.^ACM_CAP.5.2C
The developer shall use a CM system.^ACM_CAP.5.2D
The CM documentation shall include a configuration list, a CM plan, an acceptance plan, and integration procedures.^ACM_CAP.5.3C
The developer shall provide CM documentation.^ACM_CAP.5.3D
The configuration list shall describe the configuration items that comprise the TOE.^ACM_CAP.5.4C
The CM documentation shall describe the method used to uniquely identify the configuration items.^ACM_CAP.5.5C
The CM system shall uniquely identify all configuration items.^ACM_CAP.5.6C
The CM plan shall describe how the CM system is used.^ACM_CAP.5.7C
The evidence shall demonstrate that the CM system is operating in accordance with the CM plan.^ACM_CAP.5.8C
The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system.^ACM_CAP.5.9C

5.2.1.3 - Development tools CM coverage (ACM_SCP.3)

The CM documentation shall show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, CM documentation, security flaws, and development tools and related information.^ACM_SCP.3.1C
The developer shall provide CM documentation.^ACM_SCP.3.1D
The CM documentation shall describe how configuration items are tracked by the CM system.^ACM_SCP.3.2C

5.2.2 - Delivery and operation (ADO)

5.2.2.1 - Prevention of modification (ADO_DEL.3)

The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to a user's site.^ADO_DEL.3.1C
The developer shall document procedures for delivery of the TOE or parts of it to the user.^ADO_DEL.3.1D
The delivery documentation shall describe how the various procedures and technical measures provide for the prevention of modifications, or any discrepancy between the developer's master copy and the version received at the user site.^ADO_DEL.3.2C
The developer shall use the delivery procedures.^ADO_DEL.3.2D
The delivery documentation shall describe how the various procedures allow detection of attempts to masquerade as the developer, even in cases in which the developer has sent nothing to the user's site.^ADO_DEL.3.3C

5.2.2.2 - Installation, generation, and start-up procedures (ADO_IGS.1)

The documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE.^ADO_IGS.1.1C
The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE.^ADO_IGS.1.1D

5.2.3 - Development (ADV)

5.2.3.1 - Formal functional specification (ADV_FSP.4)

The functional specification shall describe the TSF and its external interfaces using a formal style, supported by informal, explanatory text where appropriate.^ADV_FSP.4.1C
The developer shall provide a functional specification.^ADV_FSP.4.1D
The functional specification shall be internally consistent.^ADV_FSP.4.2C
The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing complete details of all effects, exceptions and error messages.^ADV_FSP.4.3C
The functional specification shall completely represent the TSF.^ADV_FSP.4.4C
The functional specification shall include rationale that the TSF is completely represented.^ADV_FSP.4.5C

5.2.3.2 - Formal high-level design (ADV_HLD.5)

The high-level design shall justify that the identified means of achieving separation, including any protection mechanisms, are sufficient to ensure a clear and effective separation of TSP-enforcing from non-TSP-enforcing functions.^{ADV_HLD.5.10C}
The high-level design shall justify that the TSF mechanisms are sufficient to implement the security functions identified in the high-level design.^{ADV_HLD.5.11C}
The presentation of the high-level design shall be formal.^ADV_HLD.5.1C
The developer shall provide the high-level design of the TSF.^ADV_HLD.5.1D
The high-level design shall be internally consistent.^ADV_HLD.5.2C
The high-level design shall describe the structure of the TSF in terms of subsystems.^ADV_HLD.5.3C
The high-level design shall describe the security functionality provided by each subsystem of the TSF.^ADV_HLD.5.4C
The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software.^ADV_HLD.5.5C
The high-level design shall identify all interfaces to the subsystems of the TSF.^ADV_HLD.5.6C
The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible.^ADV_HLD.5.7C
The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing complete details of all effects, exceptions and error messages.^ADV_HLD.5.8C
The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems.^ADV_HLD.5.9C

5.2.3.3 - Structured implementation of the TSF (ADV_IMP.3)

The implementation representation shall unambiguously define the TSF to a level of detail such that the TSF can be generated without further design decisions.^ADV_IMP.3.1C
The developer shall provide the implementation representation for the entire TSF.^ADV_IMP.3.1D
The implementation representation shall be internally consistent.^ADV_IMP.3.2C
The implementation representation shall describe the relationships between all portions of the implementation.^ADV_IMP.3.3C
The implementation representation shall be structured into small and comprehensible sections.^ADV_IMP.3.4C

5.2.3.4 - Minimisation of complexity (ADV_INT.3)

The architectural description shall identify the modules of the TSF and shall specify which portions of the TSF enforce the access control and/or information flow control policies.^ADV_INT.3.1C
The developer shall design and structure the TSF in a modular fashion that avoids unnecessary interactions between the modules of the design.^ADV_INT.3.1D
The architectural description shall describe the purpose, interface, parameters, and side-effects of each module of the TSF.^ADV_INT.3.2C
The developer shall provide an architectural description.^ADV_INT.3.2D
The architectural description shall describe how the TSF design provides for largely independent modules that avoid unnecessary interactions.^ADV_INT.3.3C
The developer shall design and structure the TSF in a layered fashion that minimises mutual interactions between the layers of the design.^ADV_INT.3.3D
The architectural description shall describe the layering architecture.^ADV_INT.3.4C
The developer shall design and structure the TSF in such a way that minimises the complexity of the entire TSF.^ADV_INT.3.4D
The architectural description shall show that mutual interactions have been minimised, and justify those that remain.^ADV_INT.3.5C
The developer shall design and structure the portions of the TSF that enforce any access control and/or information flow control policies such that they are simple enough to be analysed.^ADV_INT.3.5D
The architectural description shall describe how the entire TSF has been structured to minimise complexity. ^ADV_INT.3.6C
The developer shall ensure that functions whose objectives are not relevant for the TSF are excluded from the TSF modules.^ADV_INT.3.6D
The architectural description shall justify the inclusion of any non-TSP-enforcing modules in the TSF.^ADV_INT.3.7C

5.2.3.5 - Semiformal low-level design (ADV_LLD.2)

The low-level design shall describe the separation of the TOE into TSP-enforcing and other modules.^{ADV_LLD.2.10C}
The presentation of the low-level design shall be semiformal.^ADV_LLD.2.1C
The developer shall provide the low-level design of the TSF.^ADV_LLD.2.1D
The low-level design shall be internally consistent.^ADV_LLD.2.2C
The low-level design shall describe the TSF in terms of modules.^ADV_LLD.2.3C
The low-level design shall describe the purpose of each module.^ADV_LLD.2.4C
The low-level design shall define the interrelationships between the modules in terms of provided security functionality and dependencies on other modules.^ADV_LLD.2.5C
The low-level design shall describe how each TSP-enforcing function is provided.^ADV_LLD.2.6C
The low-level design shall identify all interfaces to the modules of the TSF.^ADV_LLD.2.7C
The low-level design shall identify which of the interfaces to the modules of the TSF are externally visible.^ADV_LLD.2.8C
The low-level design shall describe the purpose and method of use of all interfaces to the modules of the TSF, providing complete details of all effects, exceptions and error messages.^ADV_LLD.2.9C

5.2.3.6 - Formal correspondence demonstration (ADV_RCR.3)

For each adjacent pair of provided TSF representations, the analysis shall prove or demonstrate that all relevant security functionality of the more abstract TSF representation is correctly and completely refined in the less abstract TSF representation.^ADV_RCR.3.1C
The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided.^ADV_RCR.3.1D
For each adjacent pair of provided TSF representations, where portions of one representation are semiformally specified and the other at least semiformally specified, the demonstration of correspondence between those portions of the representations shall be semiformal.^ADV_RCR.3.2C
For those corresponding portions of representations that are formally specified, the developer shall prove that correspondence.^ADV_RCR.3.2D
For each adjacent pair of provided TSF representations, where portions of both representations are formally specified, the proof of correspondence between those portions of the representations shall be formal.^ADV_RCR.3.3C

5.2.3.7 - Formal TOE security policy model (ADV_SPM.3)

The TSP model shall be formal.^ADV_SPM.3.1C
The developer shall provide a TSP model.^ADV_SPM.3.1D
The TSP model shall describe the rules and characteristics of all policies of the TSP that can be modeled.^ADV_SPM.3.2C
The developer shall demonstrate or prove, as appropriate, correspondence between the functional specification and the TSP model.^ADV_SPM.3.2D
The TSP model shall include a rationale that demonstrates that it is consistent and complete with respect to all policies of the TSP that can be modeled.^ADV_SPM.3.3C
The demonstration of correspondence between the TSP model and the functional specification shall show that all of the security functions in the functional specification are consistent and complete with respect to the TSP model.^ADV_SPM.3.4C
Where the functional specification is semiformal, the demonstration of correspondence between the TSP model and the functional specification shall be semiformal.^ADV_SPM.3.5C
Where the functional specification is formal, the proof of correspondence between the TSP model and the functional specification shall be formal.^ADV_SPM.3.6C

5.2.4 - Guidance documents (AGD)

5.2.4.1 - Administrator guidance (AGD_ADM.1)

The administrator guidance shall describe the administrative functions and interfaces available to the administrator of the TOE.^AGD_ADM.1.1C
The developer shall provide administrator guidance addressed to system administrative personnel.^AGD_ADM.1.1D
The administrator guidance shall describe how to administer the TOE in a secure manner.^AGD_ADM.1.2C
The administrator guidance shall contain warnings about functions and privileges that should be controlled in a secure processing environment.^AGD_ADM.1.3C
The administrator guidance shall describe all assumptions regarding user behaviour that are relevant to secure operation of the TOE.^AGD_ADM.1.4C
The administrator guidance shall describe all security parameters under the control of the administrator, indicating secure values as appropriate.^AGD_ADM.1.5C
The administrator guidance shall describe each type of security-relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.^AGD_ADM.1.6C
The administrator guidance shall be consistent with all other documentation supplied for evaluation.^AGD_ADM.1.7C
The administrator guidance shall describe all security requirements for the IT environment that are relevant to the administrator.^AGD_ADM.1.8C

5.2.4.2 - User guidance (AGD_USR.1)

The user guidance shall describe the functions and interfaces available to the non-administrative users of the TOE. ^AGD_USR.1.1C
The developer shall provide user guidance.^AGD_USR.1.1D
The user guidance shall describe the use of user-accessible security functions provided by the TOE.^AGD_USR.1.2C
The user guidance shall contain warnings about user-accessible functions and privileges that should be controlled in a secure processing environment.^AGD_USR.1.3C
The user guidance shall clearly present all user responsibilities necessary for secure operation of the TOE, including those related to assumptions regarding user behaviour found in the statement of TOE security environment.^AGD_USR.1.4C
The user guidance shall be consistent with all other documentation supplied for evaluation.^AGD_USR.1.5C
The user guidance shall describe all security requirements for the IT environment that are relevant to the user.^AGD_USR.1.6C

5.2.5 - Life cycle support (ALC)

5.2.5.1 - Sufficiency of security measures (ALC_DVS.2)

The development security documentation shall describe all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment.^ALC_DVS.2.1C
The developer shall produce development security documentation.^ALC_DVS.2.1D
The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE.^ALC_DVS.2.2C
The evidence shall justify that the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE.^ALC_DVS.2.3C

5.2.5.2 - Systematic flaw remediation (ALC_FLR.3)

The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE.^ALC_FLR.3.1C
The developer shall document the flaw remediation procedures.^ALC_FLR.3.1D
The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw.^ALC_FLR.3.2C
The developer shall establish a procedure for accepting and acting upon user reports of security flaws and requests for corrections to those flaws.^ALC_FLR.3.2D
The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.^ALC_FLR.3.3C
The developer shall designate one or more specific points of contact for user reports and inquiries about security issues involving the TOE.^ALC_FLR.3.3D
The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users.^ALC_FLR.3.4C
The procedures for processing reported security flaws shall ensure that any reported flaws are corrected and the correction issued to TOE users.^ALC_FLR.3.5C
The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws.^ALC_FLR.3.6C
The flaw remediation procedures shall include a procedure requiring timely responses for the automatic distribution of security flaw reports and the associated corrections to registered users who might be affected by the security flaw.^ALC_FLR.3.7C

5.2.5.3 - Measurable life-cycle model (ALC_LCD.3)

The life-cycle definition documentation shall describe the model used to develop and maintain the TOE, including the details of its arithmetic parameters and/or metrics used to measure the TOE development against the model.^ALC_LCD.3.1C
The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE.^ALC_LCD.3.1D
The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE.^ALC_LCD.3.2C
The developer shall provide life-cycle definition documentation.^ALC_LCD.3.2D
The life-cycle definition documentation shall explain why the model was chosen.^ALC_LCD.3.3C
The developer shall use a standardised and measurable life-cycle model to develop and maintain the TOE.^ALC_LCD.3.3D
The life-cycle definition documentation shall explain how the model is used to develop and maintain the TOE.^ALC_LCD.3.4C
The developer shall measure the TOE development using the standardised and measurable life-cycle model.^ALC_LCD.3.4D
The life-cycle definition documentation shall demonstrate compliance with the standardised and measurable life-cycle model.^ALC_LCD.3.5C
The life-cycle documentation shall provide the results of the measurements of the TOE development using the standardised and measurable life-cycle model.^ALC_LCD.3.6C

5.2.5.4 - Compliance with implementation standards - all parts (ALC_TAT.3)

All development tools used for implementation shall be well-defined.^ALC_TAT.3.1C
The developer shall identify the development tools being used for the TOE.^ALC_TAT.3.1D
The documentation of the development tools shall unambiguously define the meaning of all statements used in the implementation.^ALC_TAT.3.2C
The developer shall document the selected implementation-dependent options of the development tools.^ALC_TAT.3.2D
The documentation of the development tools shall unambiguously define the meaning of all implementation-dependent options.^ALC_TAT.3.3C
The developer shall describe the implementation standards for all parts of the TOE.^ALC_TAT.3.3D

5.2.6 - Tests (ATE)

5.2.6.1 - Rigorous analysis of coverage (ATE_COV.3)

The analysis of the test coverage shall demonstrate the correspondence between the tests identified in the test documentation and the TSF as described in the functional specification.^ATE_COV.3.1C
The developer shall provide an analysis of the test coverage.^ATE_COV.3.1D
The analysis of the test coverage shall demonstrate that the correspondence between the TSF as described in the functional specification and the tests identified in the test documentation is complete.^ATE_COV.3.2C
The analysis of the test coverage shall rigorously demonstrate that all external interfaces of the TSF identified in the functional specification have been completely tested.^ATE_COV.3.3C

5.2.6.2 - Testing: implementation representation (ATE_DPT.3)

The depth analysis shall demonstrate that the tests identified in the test documentation are sufficient to demonstrate that the TSF operates in accordance with its high-level design, low-level design and implementation representation.^ATE_DPT.3.1C
The developer shall provide the analysis of the depth of testing.^ATE_DPT.3.1D

5.2.6.3 - Ordered functional testing (ATE_FUN.2)

The test documentation shall consist of test plans, test procedure descriptions, expected test results and actual test results.^ATE_FUN.2.1C
The developer shall test the TSF and document the results.^ATE_FUN.2.1D
The test plans shall identify the security functions to be tested and describe the goal of the tests to be performed.^ATE_FUN.2.2C
The developer shall provide test documentation.^ATE_FUN.2.2D
The test procedure descriptions shall identify the tests to be performed and describe the scenarios for testing each security function. These scenarios shall include any ordering dependencies on the results of other tests.^ATE_FUN.2.3C
The expected test results shall show the anticipated outputs from a successful execution of the tests.^ATE_FUN.2.4C
The test results from the developer execution of the tests shall demonstrate that each tested security function behaved as specified.^ATE_FUN.2.5C
The test documentation shall include an analysis of the test procedure ordering dependencies.^ATE_FUN.2.6C

5.2.6.4 - Independent testing - complete (ATE_IND.3)

The TOE shall be suitable for testing.^ATE_IND.3.1C
The developer shall provide the TOE for testing.^ATE_IND.3.1D
The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF. ^ATE_IND.3.2C

5.2.7 - Vulnerability assessment (AVA)

5.2.7.1 - Systematic covert channel analysis (AVA_CCA.2)

The analysis documentation shall identify covert channels and estimate their capacity.^AVA_CCA.2.1C
The developer shall conduct a search for covert channels for each information flow control policy.^AVA_CCA.2.1D
The analysis documentation shall describe the procedures used for determining the existence of covert channels, and the information needed to carry out the covert channel analysis.^AVA_CCA.2.2C
The developer shall provide covert channel analysis documentation.^AVA_CCA.2.2D
The analysis documentation shall describe all assumptions made during the covert channel analysis.^AVA_CCA.2.3C
The analysis documentation shall describe the method used for estimating channel capacity, based on worst case scenarios.^AVA_CCA.2.4C
The analysis documentation shall describe the worst case exploitation scenario for each identified covert channel.^AVA_CCA.2.5C
The analysis documentation shall provide evidence that the method used to identify covert channels is systematic.^AVA_CCA.2.6C

5.2.7.2 - Analysis and testing for insecure states (AVA_MSU.3)

The guidance documentation shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation.^AVA_MSU.3.1C
The developer shall provide guidance documentation. ^AVA_MSU.3.1D
The guidance documentation shall be complete, clear, consistent and reasonable.^AVA_MSU.3.2C
The developer shall document an analysis of the guidance documentation.^AVA_MSU.3.2D
The guidance documentation shall list all assumptions about the intended environment.^AVA_MSU.3.3C
The guidance documentation shall list all requirements for external security measures (including external procedural, physical and personnel controls).^AVA_MSU.3.4C
The analysis documentation shall demonstrate that the guidance documentation is complete.^AVA_MSU.3.5C

5.2.7.3 - Strength of TOE security function evaluation (AVA_SOF.1)

For each mechanism with a strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the minimum strength level defined in the PP/ST.^AVA_SOF.1.1C
The developer shall perform a strength of TOE security function analysis for each mechanism identified in the ST as having a strength of TOE security function claim.^AVA_SOF.1.1D
For each mechanism with a specific strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of function metric defined in the PP/ST.^AVA_SOF.1.2C

5.2.7.4 - Highly resistant (AVA_VLA.4)

The documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE.^AVA_VLA.4.1C
The developer shall perform and document an analysis of the TOE deliverables searching for ways in which a user can violate the TSP.^AVA_VLA.4.1D
The documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks.^AVA_VLA.4.2C
The developer shall document the disposition of identified vulnerabilities.^AVA_VLA.4.2D
The evidence shall show that the search for vulnerabilities is systematic.^AVA_VLA.4.3C
The analysis documentation shall provide a justification that the analysis completely addresses the TOE deliverables.^AVA_VLA.4.4C

5.3 - Security Requirements for the IT Environment (Optional)

5.4 - Security Requirements for the Non-IT Environment (Optional)

Identify the IT security requirements that are to be met by the IT environment of the TOE. If the TOE has no asserted dependencies on the IT environment, this section may be omitted.

6 - Rationale

Include an overall summary of rationale.

6.1 - Introduction and TOE Description Rationale (Optional)

Presents the rationale used in the protection profile evaluation.

6.2 - Security Objectives Rationale

Table 6-1 Mapping the TOE Security Environment to Security Objectives

Policy/Threat/Assumptions	Objectives
Security Objectives for the TOE
A.NO_PCS_BYPASS	O.INFORMATION_FLOW
A.PARTITIONING_KERNEL	O.INFORMATION_FLOW
A.SHARED_COMM_RMI	O.INFORMATION_FLOW
A.TRUSTED_CODE_LOAD	O.ENV_TRUSTED_LOAD
A.TRUSTED_CONFIG_LOAD	O.ENV_TRUSTED_LOAD
P.COMPATIBLE_CONIFGS	O.CONFIG_VALIDATION
P.C_OF_I	O.C_OF_I
P.DATA_ISOLATION	O.IDENTIFIED_PEER
P.INFO_FLOW	Security Objectives, O.CLEAR_RESIDUAL, O.IDENTIFIED_PEER, O.INFORMATION_FLOW, O.NO_REPLAY, O.RESOURCE_LIMITS, O.TRANSMISSION_CONFIDENTIALITY, O.TRANSMISSION_UNOBSERVABLE
P.NONINTERFERENCE	O.RESOURCE_GUARANTEE, O.TRANSMISSION_INTEGRITY
P.UNIQUE_PARTITION	O.IDENTIFIED_PEER
P.VPN	O.VPN
T.BACK_FLOW	O.INFORMATION_FLOW
T.CONFIG_CORRUPT	O.CONFIG_SUPPORT
T.DOS	O.RESOURCE_GUARANTEE
T.EAVESDROP	O.CLEAR_RESIDUAL
T.INFO_CORRUPTED	O.SELF_PROTECT
T.MASQUERADE	O.IDENTIFIED_PEER
T.PCS_TAMPER	O.REQUEST_VALIDATE
T.POOR_DESIGN	O.SOUND_DESIGN
T.POOR_IMPLEMENTATION	O.SOUND_IMPLEMENTATION
T.POOR_TEST	O.TESTING
T.TRIANGULATE	O.INFORMATION_FLOW
T.UNSANITIZED	O.CLEAR_RESIDUAL
T.WRONG_CODE	O.CONFIG_MGT
T.WRONG_COMM	O.INFORMATION_FLOW
Security Objectives for the Environment

Table 6-2 Tracing of Security Objectives to the TOE Security Environment

Objectives	Policy/Threat/Assumptions
Security Objectives for the TOE
O.CLEAR_RESIDUAL	P.INFO_FLOW, T.EAVESDROP, T.UNSANITIZED
O.CONFIG_MGT	T.WRONG_CODE
O.CONFIG_SUPPORT	T.CONFIG_CORRUPT
O.CONFIG_VALIDATION	P.COMPATIBLE_CONIFGS
O.C_OF_I	P.C_OF_I
O.ENV_TRUSTED_LOAD	A.TRUSTED_CODE_LOAD, A.TRUSTED_CONFIG_LOAD
O.IDENTIFIED_PEER	P.DATA_ISOLATION, P.INFO_FLOW, P.UNIQUE_PARTITION, T.MASQUERADE
O.INFORMATION_FLOW	A.NO_PCS_BYPASS, A.PARTITIONING_KERNEL, A.SHARED_COMM_RMI, P.INFO_FLOW, T.BACK_FLOW, T.TRIANGULATE, T.WRONG_COMM
O.NO_REPLAY	P.INFO_FLOW
O.REQUEST_VALIDATE	T.PCS_TAMPER
O.RESOURCE_GUARANTEE	P.NONINTERFERENCE, T.DOS
O.RESOURCE_LIMITS	P.INFO_FLOW
O.SELF_PROTECT	T.INFO_CORRUPTED
O.SOUND_DESIGN	T.POOR_DESIGN
O.SOUND_IMPLEMENTATION	T.POOR_IMPLEMENTATION
O.TESTING	T.POOR_TEST
O.TRANSMISSION_CONFIDENTIALITY	P.INFO_FLOW
O.TRANSMISSION_INTEGRITY	P.NONINTERFERENCE
O.TRANSMISSION_UNOBSERVABLE	P.INFO_FLOW
O.VPN	P.VPN
Security Objectives	P.INFO_FLOW
Security Objectives for the Environment

6.2.1 - Policies

P.COMPATIBLE_CONIFGS: The MILS Partitioning Communication System shall ensure that communications are permitted only between correctly loaded and configured systems. [This policy is intended to deal with our desire to not assume a correct, enclave-wide load of software and configuration data.]

In General, P.COMPATIBLE_CONIFGS is addressed by:

O.CONFIG_VALIDATION: Info Flow Configuration Validation
[Check, for example, that two nodes have compatible versions of their info-flow configuration data.]

P.C_OF_I: [Community of Interest placeholder]

In General, P.C_OF_I is addressed by:

O.C_OF_I: Community of Interest Rules
[Community of Interest placeholder]

P.DATA_ISOLATION: The MILS Partitioning Communication System shall ensure that no task anywhere in the enclave will have access to any other partition's data in the entire system, except as authorized by the MILS Partition Kernel or by the Partitioning Communication System information flow policy. [Text is from Vanfleet e-mail. Note we assume communication with non-MILS systems will be via application-level firewalls and bridges and therefore these communications will be outside the scope of our Protection Profile.]

In General, P.DATA_ISOLATION is addressed by:

O.IDENTIFIED_PEER: Confirmed Identification of Peers
[Is who we're talking to who we think we're talking to?]

P.INFO_FLOW: The MILS Partitioning Communication System shall ensure that only explicitly authorized information flows occur. [Add explicit recognition that this includes suppression of covert channels?]

In General, P.INFO_FLOW is addressed by:

Security Objectives:
O.CLEAR_RESIDUAL: Clear Residual Information
The PCS shall clear residual information before reassigning a resource to a subsequent subject.
O.IDENTIFIED_PEER: Confirmed Identification of Peers
[Is who we're talking to who we think we're talking to?]
O.INFORMATION_FLOW: Information Flow Rules
The Partitioning Communication System shall enforce information flow control between partitions and into and out of partitions, as specified in its configuration data. [when it's involved in the communication, anyway.]
O.NO_REPLAY: Prevention of Message Replay
The MILS Partitioning Communication System shall ensure that an authorized information flow can not be initiated or replayed by a subject other than the initial, authorized source.
O.RESOURCE_LIMITS: PCS Resource Limitations
[In particular, limitation of comm. channel use, as we're thinking this will allow reliable blind up-writing.]
O.TRANSMISSION_CONFIDENTIALITY:
O.TRANSMISSION_UNOBSERVABLE: [The term "Unobservable" is from FPR_UNO. I'm thinking of it leading to a requirement for pre-encryption traffic generation, or padding, so that a third party observer can't tell if a subject is sending something or not. ]

P.NONINTERFERENCE: The MILS Partitioning Communication System shall ensure that authorized information flows are not prevented by subjects not involved in the transfer. [Need to change this policy's identifier as this doesn't have anything to do with Goguen & Meseguer's noninterference property.]

In General, P.NONINTERFERENCE is addressed by:

O.RESOURCE_GUARANTEE: PCS Resource Guarantees
[to include memory, CPU and allotted share of communications channel resources]
O.TRANSMISSION_INTEGRITY:

P.UNIQUE_PARTITION: The MILS Partitioning Communication System shall ensure that each subject is bound to exactly one partition on one processor, and that each partition is bound to exactly one subject. [The Objectives section must expand on the need to uniquely identify partitions throughout the enclave, and deal with issues of their identity in view of partition creation, lifetime and persistence.]

In General, P.UNIQUE_PARTITION is addressed by:

O.IDENTIFIED_PEER: Confirmed Identification of Peers
[Is who we're talking to who we think we're talking to?]

P.VPN: [Virtual Private Network placeholder]

In General, P.VPN is addressed by:

O.VPN: Virtual Private Network Rules
[Virtual Private Network placeholder]

6.2.2 - Threats

T.BACK_FLOW: Acknowledgement of messages sent from subject A to subject B may result in an acknowledgement--negative or positive--that violates information flow policy.

In General, T.BACK_FLOW is addressed by:

O.INFORMATION_FLOW: Information Flow Rules
The Partitioning Communication System shall enforce information flow control between partitions and into and out of partitions, as specified in its configuration data. [when it's involved in the communication, anyway.]

T.CONFIG_CORRUPT: A malicious or faulty subject may attempt to modify or corrupt configuration data used by the PCS to enforce information flow policy by changing the configuration data used by the PCS. A malicious or faulty subject may also attempt to bypass the information flow policy by using configuration data that, while valid, differs from that being used by another PCS node. [Node? What's a Node?]

In General, T.CONFIG_CORRUPT is addressed by:

O.CONFIG_SUPPORT: Info Flow Configuration Support
[This one would mandate tools to help the application system designer set up the who-can-talk-to-who configurations.]

T.DOS: A malicious or faulty subject may attempt to block or delay other subjects from sending or receiving communications by exhausting or monopolizing shared resources or the resources of another PCS node.

In General, T.DOS is addressed by:

O.RESOURCE_GUARANTEE: PCS Resource Guarantees
[to include memory, CPU and allotted share of communications channel resources]

T.EAVESDROP: A malicious or faulty subject may attempt to intercept communications it is not authorized to receive by examining memory other than that which has been prepared for its use by the PCS. [...or by reading network data directly, bypassing the PCS]

In General, T.EAVESDROP is addressed by:

O.CLEAR_RESIDUAL: Clear Residual Information
The PCS shall clear residual information before reassigning a resource to a subsequent subject.

T.INFO_CORRUPTED: A subject may attempt to modify or corrupt information communicated to or from another subject by accessing data used by the PCS.

In General, T.INFO_CORRUPTED is addressed by:

O.SELF_PROTECT: Protection of PCS
[PROTECTED_BY_KERNEL? PROTECTED_MEMORY?]

T.MASQUERADE: A malicious or faulty subject may attempt to masquerade as another subject by tampering with PCS-internal data structures or by presenting invalid data to PCS interfaces.

In General, T.MASQUERADE is addressed by:

O.IDENTIFIED_PEER: Confirmed Identification of Peers
[Is who we're talking to who we think we're talking to?]

T.PCS_TAMPER: A malicious or faulty subject may attempt to tamper with PCS code or PCS-internal data structures by accessing memory used by the PCS or by presenting invalid data to PCS interfaces.

In General, T.PCS_TAMPER is addressed by:

O.REQUEST_VALIDATE: Validation of Requests of PCS
The Partitioning Communication System shall validate all service requests from subjects to ensure that the subject has permission to issue the requests and the requests will not reduce the Partitioning Communication System's ability to enforce the security policies.

T.POOR_DESIGN: Unintentional or intentional errors in requirement specification, design or development of the PCS may occur. [As worded, lacks a threat agent. Might change to a policy.]

In General, T.POOR_DESIGN is addressed by:

O.SOUND_DESIGN: Sound Design
The design of the Partitioning Communication System shall account for, and be traceable to, all of its functional requirements. [This is a place to hang assurance requirements. Copied from the PKPP.]

T.POOR_IMPLEMENTATION: Unintentional or intentional errors in implementing the design of the PCS may occur.

In General, T.POOR_IMPLEMENTATION is addressed by:

O.SOUND_IMPLEMENTATION: Sound Implementation
The implementation of the Partitioning Communication System shall be an accurate instantiation of its design. [Copied from the PKPP.]

T.POOR_TEST: Incorrect behavior resulting from faulty design or implementation may not be detected by the testing program.

In General, T.POOR_TEST is addressed by:

O.TESTING: Testing
The Partitioning Communication System shall undergo independent Security Verification Testing, based at least in part on an independent vulnerability analysis. [Again, copied from the PKPP]

T.TRIANGULATE: Data used to send or receive messages may reveal the location--on-board or off--of the counterpart subject, or allow one subject to know that the other has moved.

In General, T.TRIANGULATE is addressed by:

O.INFORMATION_FLOW: Information Flow Rules
The Partitioning Communication System shall enforce information flow control between partitions and into and out of partitions, as specified in its configuration data. [when it's involved in the communication, anyway.]

T.UNSANITIZED: A malicious or faulty subject may attempt to gain unauthorized information from an improperly sanitized or incompletely initialized shared resource.

In General, T.UNSANITIZED is addressed by:

O.CLEAR_RESIDUAL: Clear Residual Information
The PCS shall clear residual information before reassigning a resource to a subsequent subject.

T.WRONG_CODE: The code of the PCS may be corrupted, or an incorrect version substituted, prior to being loaded into the computer in which it will execute.

In General, T.WRONG_CODE is addressed by:

O.CONFIG_MGT: Software Configuration Management
Every delivered version of the PCS shall be uniquely identified and all changes to the PCS and its development environment shall be documented, tracked and controlled. [...this configuration not to be confused with the management of the PK or PCS who-can-talk-to-who configuration.]

T.WRONG_COMM: A malicious or faulty subject may attempt to send information to another subject it is not authorized to communicate with. [...either directly or via a covert channel.]

In General, T.WRONG_COMM is addressed by:

O.INFORMATION_FLOW: Information Flow Rules
The Partitioning Communication System shall enforce information flow control between partitions and into and out of partitions, as specified in its configuration data. [when it's involved in the communication, anyway.]

6.3 - Security Requirements Rationale

Demonstrate that the set of security requirements identified in Section 5 is suitable to meet the security objectives identified in Section 4.

6.3.1 - Functional Security Requirements Rationale

Table 6-3 Functional Component to Security Objective Mapping

Objectives	Requirements
O.CLEAR_RESIDUAL	FDP_RIP.2
O.CONFIG_MGT	ACM_SCP.3, ACM_CAP.5, ACM_AUT.2
O.CONFIG_SUPPORT	AGD_ADM.1, AGD_USR.1, FMT_MSA.1, FMT_MSA.2, FMT_MSA.3
O.CONFIG_VALIDATION	FPT_TRC.1, FPT_ITT.1
O.C_OF_I	FXX_XXX.1
O.ENV_TRUSTED_LOAD	ADO_IGS.1
O.IDENTIFIED_PEER	FPT_ITT.1
O.INFORMATION_FLOW	FDP_IFC.2, FDP_IFF.1, FTP_TRP.1, FDP_IFF.3, FDP_IFF.4, FDP_ITT.2
O.NO_REPLAY	FPT_RPL.1
O.REQUEST_VALIDATE	FTP_TRP.1
O.RESOURCE_GUARANTEE	FRU_RSA.2, FDP_ITT.2
O.RESOURCE_LIMITS	FRU_RSA.2, FRU_RSA.1
O.RESPECT_PRIORITY	FRU_PRS.1
O.SELF_PROTECT	FPT_AMT.1, FPT_FLS.1, FPT_RVM.1, FPT_SEP.1, FPT_TST.1, FTP_TRP.1
O.SOUND_DESIGN	ALC_DVS.2, ALC_LCD.3, ALC_TAT.3, ALC_FLR.3, ADV_FSP.4, ADV_HLD.5, ADV_LLD.2, ADV_SPM.3, ADV_RCR.3, AVA_VLA.4, AVA_SOF.1
O.SOUND_IMPLEMENTATION	ALC_DVS.2, ALC_LCD.3, ALC_TAT.3, ALC_FLR.3, ADV_FSP.4, ADV_HLD.5, ADV_LLD.2, ADV_IMP.3, ADV_INT.3, ADV_RCR.3, AVA_CCA.2, AVA_MSU.3, AVA_VLA.4, AVA_SOF.1, ATE_COV.3, ATE_DPT.3, ATE_FUN.2, ATE_IND.3
O.TESTING	ATE_IND.3, ATE_FUN.2, ATE_COV.3, ATE_DPT.3
O.TRANSMISSION_CONFIDENTIALITY	FCS_COP.1, FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FDP_ITT.1
O.TRANSMISSION_INTEGRITY	FCS_COP.1, FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FDP_ITT.1
O.TRANSMISSION_UNOBSERVABLE	FPR_UNO.1
O.VPN	FXX_XXX.1
Security Objectives	ACM_AUT.2, ACM_CAP.5, ACM_SCP.3, ADO_DEL.3, ADO_IGS.1, ADV_FSP.4, ADV_HLD.5, ADV_IMP.3, ADV_INT.3, ADV_LLD.2, ADV_RCR.3, ADV_SPM.3, AGD_ADM.1, AGD_USR.1, ALC_DVS.2, ALC_LCD.3, ALC_TAT.3, ATE_COV.3, ATE_DPT.3, ATE_FUN.2, ATE_IND.3, AVA_CCA.2, AVA_MSU.3, AVA_SOF.1, AVA_VLA.4

O.CLEAR_RESIDUAL: Clear Residual Information
The PCS shall clear residual information before reassigning a resource to a subsequent subject.

O.CLEAR_RESIDUAL is implemented in the TOE by:

FDP_RIP.2: Full residual information protection

O.CONFIG_MGT is implemented in the TOE by:

ACM_SCP.3: Development tools CM coverage
ACM_CAP.5: Advanced support
ACM_AUT.2: Complete CM automation

O.CONFIG_SUPPORT: Info Flow Configuration Support
[This one would mandate tools to help the application system designer set up the who-can-talk-to-who configurations.]

O.CONFIG_SUPPORT is implemented in the TOE by:

AGD_ADM.1: Administrator guidance
AGD_USR.1: User guidance
FMT_MSA.1: Management of security attributes
FMT_MSA.2: Secure security attributes
FMT_MSA.3: Static attribute initialisation

O.CONFIG_VALIDATION: Info Flow Configuration Validation
[Check, for example, that two nodes have compatible versions of their info-flow configuration data.]

O.CONFIG_VALIDATION is implemented in the TOE by:

FPT_TRC.1: Internal TSF consistency
FPT_ITT.1: Basic internal TSF data transfer protection

O.C_OF_I: Community of Interest Rules
[Community of Interest placeholder]

O.C_OF_I is implemented in the TOE by:

FXX_XXX.1: X

O.ENV_TRUSTED_LOAD: [Should Security Objectives for the Environment be related to policies, threats and assumptions in the Rationale section? They are in the PKPP but CCTookit doesn't seem to think so...]

O.ENV_TRUSTED_LOAD is implemented in the TOE by:

ADO_IGS.1: Installation, generation, and start-up procedures

O.IDENTIFIED_PEER: Confirmed Identification of Peers
[Is who we're talking to who we think we're talking to?]

O.IDENTIFIED_PEER is implemented in the TOE by:

FPT_ITT.1: Basic internal TSF data transfer protection

O.INFORMATION_FLOW is implemented in the TOE by:

FDP_IFC.2: Complete information flow control
FDP_IFF.1: Simple security attributes
FTP_TRP.1: Trusted path
FDP_IFF.3: Limited illicit information flows
FDP_IFF.4: Partial elimination of illicit information flows
FDP_ITT.2: Transmission separation by attribute

O.NO_REPLAY is implemented in the TOE by:

FPT_RPL.1: Replay detection

O.REQUEST_VALIDATE is implemented in the TOE by:

FTP_TRP.1: Trusted path

O.RESOURCE_GUARANTEE: PCS Resource Guarantees
[to include memory, CPU and allotted share of communications channel resources]

O.RESOURCE_GUARANTEE is implemented in the TOE by:

FRU_RSA.2: Minimum and maximum quotas
FDP_ITT.2: Transmission separation by attribute

O.RESOURCE_LIMITS: PCS Resource Limitations
[In particular, limitation of comm. channel use, as we're thinking this will allow reliable blind up-writing.]

O.RESOURCE_LIMITS is implemented in the TOE by:

FRU_RSA.2: Minimum and maximum quotas
FRU_RSA.1: Maximum quotas

O.RESPECT_PRIORITY: [Something about respecting subject's real-time priority]

O.RESPECT_PRIORITY is implemented in the TOE by:

FRU_PRS.1: Limited priority of service

O.SELF_PROTECT: Protection of PCS
[PROTECTED_BY_KERNEL? PROTECTED_MEMORY?]

O.SELF_PROTECT is implemented in the TOE by:

FPT_AMT.1: Abstract machine testing
FPT_FLS.1: Failure with preservation of secure state
FPT_RVM.1: Non-bypassability of the TSP
FPT_SEP.1: TSF domain separation
FPT_TST.1: TSF testing
FTP_TRP.1: Trusted path

O.SOUND_DESIGN is implemented in the TOE by:

ALC_DVS.2: Sufficiency of security measures
ALC_LCD.3: Measurable life-cycle model
ALC_TAT.3: Compliance with implementation standards - all parts
ALC_FLR.3: Systematic flaw remediation
ADV_FSP.4: Formal functional specification
ADV_HLD.5: Formal high-level design
ADV_LLD.2: Semiformal low-level design
ADV_SPM.3: Formal TOE security policy model
ADV_RCR.3: Formal correspondence demonstration
AVA_VLA.4: Highly resistant
AVA_SOF.1: Strength of TOE security function evaluation

O.SOUND_IMPLEMENTATION: Sound Implementation
The implementation of the Partitioning Communication System shall be an accurate instantiation of its design. [Copied from the PKPP.]

O.SOUND_IMPLEMENTATION is implemented in the TOE by:

ALC_DVS.2: Sufficiency of security measures
ALC_LCD.3: Measurable life-cycle model
ALC_TAT.3: Compliance with implementation standards - all parts
ALC_FLR.3: Systematic flaw remediation
ADV_FSP.4: Formal functional specification
ADV_HLD.5: Formal high-level design
ADV_LLD.2: Semiformal low-level design
ADV_IMP.3: Structured implementation of the TSF
ADV_INT.3: Minimisation of complexity
ADV_RCR.3: Formal correspondence demonstration
AVA_CCA.2: Systematic covert channel analysis
AVA_MSU.3: Analysis and testing for insecure states
AVA_VLA.4: Highly resistant
AVA_SOF.1: Strength of TOE security function evaluation
ATE_COV.3: Rigorous analysis of coverage
ATE_DPT.3: Testing: implementation representation
ATE_FUN.2: Ordered functional testing
ATE_IND.3: Independent testing - complete

O.TESTING is implemented in the TOE by:

ATE_IND.3: Independent testing - complete
ATE_FUN.2: Ordered functional testing
ATE_COV.3: Rigorous analysis of coverage
ATE_DPT.3: Testing: implementation representation

O.TRANSMISSION_CONFIDENTIALITY:

O.TRANSMISSION_CONFIDENTIALITY is implemented in the TOE by:

FCS_COP.1: Cryptographic operation
FCS_CKM.1: Cryptographic key generation
FCS_CKM.2: Cryptographic key distribution
FCS_CKM.3: Cryptographic key access
FCS_CKM.4: Cryptographic key destruction
FDP_ITT.1: Basic internal transfer protection

O.TRANSMISSION_INTEGRITY:

O.TRANSMISSION_INTEGRITY is implemented in the TOE by:

FCS_COP.1: Cryptographic operation
FCS_CKM.1: Cryptographic key generation
FCS_CKM.2: Cryptographic key distribution
FCS_CKM.3: Cryptographic key access
FCS_CKM.4: Cryptographic key destruction
FDP_ITT.1: Basic internal transfer protection

O.TRANSMISSION_UNOBSERVABLE: [The term "Unobservable" is from FPR_UNO. I'm thinking of it leading to a requirement for pre-encryption traffic generation, or padding, so that a third party observer can't tell if a subject is sending something or not. ]

O.TRANSMISSION_UNOBSERVABLE is implemented in the TOE by:

FPR_UNO.1: Unobservability

O.VPN: Virtual Private Network Rules
[Virtual Private Network placeholder]

O.VPN is implemented in the TOE by:

FXX_XXX.1: X

Security Objectives:

Security Objectives is implemented in the TOE by:

ACM_AUT.2: Complete CM automation
ACM_CAP.5: Advanced support
ACM_SCP.3: Development tools CM coverage
ADO_DEL.3: Prevention of modification
ADO_IGS.1: Installation, generation, and start-up procedures
ADV_FSP.4: Formal functional specification
ADV_HLD.5: Formal high-level design
ADV_IMP.3: Structured implementation of the TSF
ADV_INT.3: Minimisation of complexity
ADV_LLD.2: Semiformal low-level design
ADV_RCR.3: Formal correspondence demonstration
ADV_SPM.3: Formal TOE security policy model
AGD_ADM.1: Administrator guidance
AGD_USR.1: User guidance
ALC_DVS.2: Sufficiency of security measures
ALC_LCD.3: Measurable life-cycle model
ALC_TAT.3: Compliance with implementation standards - all parts
ATE_COV.3: Rigorous analysis of coverage
ATE_DPT.3: Testing: implementation representation
ATE_FUN.2: Ordered functional testing
ATE_IND.3: Independent testing - complete
AVA_CCA.2: Systematic covert channel analysis
AVA_MSU.3: Analysis and testing for insecure states
AVA_SOF.1: Strength of TOE security function evaluation
AVA_VLA.4: Highly resistant

6.3.2 - Assurance Security Requirements Rationale

Provide rationale for chosen assurance level.

6.4 - Dependency Rationale

Table 6-4 Functional and Assurance Requirements Dependencies

Requirement	Dependencies
Functional Requirements
FCS_CKM.1	FCS_CKM.2, FCS_COP.1, FCS_CKM.4, FMT_MSA.2
FCS_CKM.2	FCS_CKM.1, FCS_CKM.4, FMT_MSA.2
FCS_CKM.3	FCS_CKM.1, FCS_CKM.4, FMT_MSA.2
FCS_CKM.4	FCS_CKM.1, FMT_MSA.2
FCS_COP.1	FCS_CKM.1, FCS_CKM.4, FMT_MSA.2
FDP_IFC.2	FDP_IFF.1
FDP_IFF.1	FDP_IFC.1, FMT_MSA.3
FDP_IFF.3	AVA_CCA.1, FDP_IFC.1
FDP_IFF.4	AVA_CCA.1, FDP_IFC.1
FDP_ITT.1	FDP_IFC.1
FDP_ITT.2	FDP_IFC.1
FMT_MSA.1	FDP_IFC.1,
FMT_MSA.2	ADV_SPM.1, FDP_IFC.1, FMT_MSA.1,
FMT_MSA.3	FMT_MSA.1,
FPT_FLS.1	ADV_SPM.1
FPT_TRC.1	FPT_ITT.1
FPT_TST.1	FPT_AMT.1
Assurance Requirements
ACM_AUT.2	ACM_CAP.3
ACM_CAP.5	ACM_SCP.1, ALC_DVS.2
ACM_SCP.3	ACM_CAP.3
ADO_DEL.3	ACM_CAP.3
ADO_IGS.1	AGD_ADM.1
ADV_FSP.4	ADV_RCR.1
ADV_HLD.5	ADV_FSP.4, ADV_RCR.3
ADV_IMP.3	ADV_INT.1, ADV_LLD.1, ADV_RCR.1, ALC_TAT.1
ADV_INT.3	ADV_IMP.2, ADV_LLD.1
ADV_LLD.2	ADV_HLD.3, ADV_RCR.2
ADV_SPM.3	ADV_FSP.1
AGD_ADM.1	ADV_FSP.1
AGD_USR.1	ADV_FSP.1
ALC_TAT.3	ADV_IMP.1
ATE_COV.3	ADV_FSP.1, ATE_FUN.1
ATE_DPT.3	ADV_HLD.2, ADV_IMP.2, ADV_LLD.1, ATE_FUN.1
ATE_IND.3	ADV_FSP.1, AGD_ADM.1, AGD_USR.1, ATE_FUN.1
AVA_CCA.2	ADV_FSP.2, ADV_IMP.2, AGD_ADM.1, AGD_USR.1
AVA_MSU.3	ADO_IGS.1, ADV_FSP.1, AGD_ADM.1, AGD_USR.1
AVA_SOF.1	ADV_FSP.1, ADV_HLD.1
AVA_VLA.4	ADV_FSP.1, ADV_HLD.2, ADV_IMP.1, ADV_LLD.1, AGD_ADM.1, AGD_USR.1

Justification of Unsupported Dependencies

6.5 - Security Functional Requirements Grounding in Objectives

Table 6-5 Requirements to Objectives Mapping

Requirements	Objectives
ACM_AUT.2	Security Objectives, O.CONFIG_MGT
ACM_CAP.5	Security Objectives, O.CONFIG_MGT
ACM_SCP.3	Security Objectives, O.CONFIG_MGT
ADO_DEL.3	Security Objectives
ADO_IGS.1	Security Objectives, O.ENV_TRUSTED_LOAD
ADV_FSP.4	Security Objectives, O.SOUND_DESIGN, O.SOUND_IMPLEMENTATION
ADV_HLD.5	Security Objectives, O.SOUND_DESIGN, O.SOUND_IMPLEMENTATION
ADV_IMP.3	Security Objectives, O.SOUND_IMPLEMENTATION
ADV_INT.3	Security Objectives, O.SOUND_IMPLEMENTATION
ADV_LLD.2	Security Objectives, O.SOUND_DESIGN, O.SOUND_IMPLEMENTATION
ADV_RCR.3	Security Objectives, O.SOUND_DESIGN, O.SOUND_IMPLEMENTATION
ADV_SPM.3	Security Objectives, O.SOUND_DESIGN
AGD_ADM.1	Security Objectives, O.CONFIG_SUPPORT
AGD_USR.1	Security Objectives, O.CONFIG_SUPPORT
ALC_DVS.2	Security Objectives, O.SOUND_DESIGN, O.SOUND_IMPLEMENTATION
ALC_FLR.3	O.SOUND_DESIGN, O.SOUND_IMPLEMENTATION
ALC_LCD.3	Security Objectives, O.SOUND_DESIGN, O.SOUND_IMPLEMENTATION
ALC_TAT.3	Security Objectives, O.SOUND_DESIGN, O.SOUND_IMPLEMENTATION
ATE_COV.3	Security Objectives, O.SOUND_IMPLEMENTATION, O.TESTING
ATE_DPT.3	Security Objectives, O.SOUND_IMPLEMENTATION, O.TESTING
ATE_FUN.2	Security Objectives, O.SOUND_IMPLEMENTATION, O.TESTING
ATE_IND.3	Security Objectives, O.SOUND_IMPLEMENTATION, O.TESTING
AVA_CCA.2	Security Objectives, O.SOUND_IMPLEMENTATION
AVA_MSU.3	Security Objectives, O.SOUND_IMPLEMENTATION
AVA_SOF.1	Security Objectives, O.SOUND_DESIGN, O.SOUND_IMPLEMENTATION
AVA_VLA.4	Security Objectives, O.SOUND_DESIGN, O.SOUND_IMPLEMENTATION
FCS_CKM.1	O.TRANSMISSION_CONFIDENTIALITY, O.TRANSMISSION_INTEGRITY
FCS_CKM.2	O.TRANSMISSION_CONFIDENTIALITY, O.TRANSMISSION_INTEGRITY
FCS_CKM.3	O.TRANSMISSION_CONFIDENTIALITY, O.TRANSMISSION_INTEGRITY
FCS_CKM.4	O.TRANSMISSION_CONFIDENTIALITY, O.TRANSMISSION_INTEGRITY
FCS_COP.1	O.TRANSMISSION_CONFIDENTIALITY, O.TRANSMISSION_INTEGRITY
FDP_IFC.2	O.INFORMATION_FLOW
FDP_IFF.1	O.INFORMATION_FLOW
FDP_IFF.3	O.INFORMATION_FLOW
FDP_IFF.4	O.INFORMATION_FLOW
FDP_ITT.1	O.TRANSMISSION_INTEGRITY, O.TRANSMISSION_CONFIDENTIALITY
FDP_ITT.2	O.RESOURCE_GUARANTEE, O.INFORMATION_FLOW
FDP_RIP.2	O.CLEAR_RESIDUAL
FMT_MSA.1	O.CONFIG_SUPPORT
FMT_MSA.2	O.CONFIG_SUPPORT
FMT_MSA.3	O.CONFIG_SUPPORT
FPR_UNO.1	O.TRANSMISSION_UNOBSERVABLE
FPT_AMT.1	O.SELF_PROTECT
FPT_FLS.1	O.SELF_PROTECT
FPT_ITT.1	O.IDENTIFIED_PEER, O.CONFIG_VALIDATION
FPT_RPL.1	O.NO_REPLAY
FPT_RVM.1	O.SELF_PROTECT
FPT_SEP.1	O.SELF_PROTECT
FPT_TRC.1	O.CONFIG_VALIDATION
FPT_TST.1	O.SELF_PROTECT
FRU_PRS.1	O.RESPECT_PRIORITY
FRU_RSA.1	O.RESOURCE_LIMITS
FRU_RSA.2	O.RESOURCE_GUARANTEE, O.RESOURCE_LIMITS
FTP_TRP.1	O.INFORMATION_FLOW, O.REQUEST_VALIDATE, O.SELF_PROTECT
FXX_XXX.1	O.VPN, O.C_OF_I

6.6 - Rationale for Extensions

Rationale for Extension FXX_XXX.1 to FXX_XXX

[not provided]

Appendix A - Acronyms

CC - Common Criteria
EAL - Evaluation Assurance Level
IT - Information Technology
PP - Protection Profile
SF - Security Function
SFP - Security Function Policy
SOF - Strength of Function
ST - Security Target
TOE - Target of Evaluation
TSC - TSF Scope of Control
TSF - TOE Security Functions
TSFI - TSF Interface
TSP - TOE Security Policy

Partitioning Communication System Protection Profile

Version 0.0

Wed Aug 13 11:28:47 EDT 2003

Prepared By: Objective Interface Systems

Prepared For: IAD/NSA

Foreword

Table Of Contents

List of Tables

Conventions and Terminology

Conventions

Terminology

Document Organisation

1 - Introduction

1.1 - Identification

1.2 - Protection Profile Overview

1.3 - Organisation (Optional)

1.4 - Related Protection Profiles

2 - TOE Description

2.1 Product Type

2.2 TOE Operational Environment

2.2.1 Multi-Level Clearance

2.2.2 System Support

2.2.3 Hardware Support

2.2.4 Roles

3 - TOE Security Environment

3.1 - Secure Usage Assumptions

3.2 - Threats to Security

3.3 - Organisational Security Policies

4 - Security Objectives

4.1 - Security Objectives for the TOE

4.2 - Security Objectives for the Environment

5 - IT Security Requirements

5.1 - TOE Security Functional Requirements

5.1.1 - Cryptographic support (FCS)

5.1.1.1 - Cryptographic key generation (FCS_CKM.1)

5.1.1.2 - Cryptographic key distribution (FCS_CKM.2)

5.1.1.3 - Cryptographic key access (FCS_CKM.3)

5.1.1.4 - Cryptographic key destruction (FCS_CKM.4)

5.1.1.5 - Cryptographic operation (FCS_COP.1)

5.1.2 - User data protection (FDP)

5.1.2.1 - Complete information flow control (FDP_IFC.2)

5.1.2.2 - Simple security attributes (FDP_IFF.1)

5.1.2.3 - Limited illicit information flows (FDP_IFF.3)

5.1.2.4 - Partial elimination of illicit information flows (FDP_IFF.4)

5.1.2.5 - Basic internal transfer protection (FDP_ITT.1)

5.1.2.6 - Transmission separation by attribute (FDP_ITT.2)

5.1.2.7 - Full residual information protection (FDP_RIP.2)

5.1.3 - Security management (FMT)

5.1.3.1 - Management of security attributes (FMT_MSA.1)

5.1.3.2 - Secure security attributes (FMT_MSA.2)

5.1.3.3 - Static attribute initialisation (FMT_MSA.3)

5.1.4 - Privacy (FPR)

5.1.4.1 - Unobservability (FPR_UNO.1)

5.1.5 - Protection of the TOE Security Functions (FPT)

5.1.5.1 - Abstract machine testing (FPT_AMT.1)

5.1.5.2 - Failure with preservation of secure state (FPT_FLS.1)

5.1.5.3 - Basic internal TSF data transfer protection (FPT_ITT.1)

5.1.5.4 - Replay detection (FPT_RPL.1)

5.1.5.5 - Non-bypassability of the TSP (FPT_RVM.1)

5.1.5.6 - TSF domain separation (FPT_SEP.1)

5.1.5.7 - Internal TSF consistency (FPT_TRC.1)

5.1.5.8 - TSF testing (FPT_TST.1)

5.1.6 - Resource utilisation (FRU)

5.1.6.1 - Limited priority of service (FRU_PRS.1)

5.1.6.2 - Maximum quotas (FRU_RSA.1)

5.1.6.3 - Minimum and maximum quotas (FRU_RSA.2)

5.1.7 - Trusted path/channels (FTP)

5.1.7.1 - Trusted path (FTP_TRP.1)

5.1.8 - Placeholder Functional Components (FXX)

5.1.8.1 - X (FXX_XXX.1)

5.2 - TOE Security Assurance Requirements

5.2.1 - Configuration management (ACM)

5.2.1.1 - Complete CM automation (ACM_AUT.2)

5.2.1.2 - Advanced support (ACM_CAP.5)

5.2.1.3 - Development tools CM coverage (ACM_SCP.3)

5.2.2 - Delivery and operation (ADO)

5.2.2.1 - Prevention of modification (ADO_DEL.3)

5.2.2.2 - Installation, generation, and start-up procedures (ADO_IGS.1)

5.2.3 - Development (ADV)

5.2.3.1 - Formal functional specification (ADV_FSP.4)