protection profile for partitioning communications systems...

Draft PCS Protection Profile Draft

Protection Profile for Partitioning Communications Systems in Environ-

ments Requiring High Robustness

Objective Interface Draft V0.85, xx December 2005

Copyright © 2005 Objective Interface Systems, Inc.

This document has been sent by Objective Interface Systems to recipient. Re-distribution of this docu-ment is limited to other individuals in recipient's organization.

Work funded by: United States Air Force Research Laboratory, Objective Interface Systems, Lockheed Martin, Raytheon Company and the J-UCAS program

Comments on this document should be directed to: <[email protected]>. The comments should include the page number, section number, detailed comment and recommendations.

1


Table of Contents 1. Introduction ..............................................................................................................................................................7

1.1. Identification......................................................................................................................................................7

1.2. Protection Profile Overview...............................................................................................................................7

1.3. Mutual Recognition of Common Criteria Certificates .......................................................................................8

1.4. Conventions .......................................................................................................................................................8

1.5. Glossary ...........................................................................................................................................................13

1.6. Organization.....................................................................................................................................................16

1.7. Related Protection Profile ................................................................................................................................16

2. Target of Evaluation (TOE) Description .................................................................................................................17

2.1. Product Type....................................................................................................................................................17

2.2. TOE Concepts..................................................................................................................................................18

2.2.1. TOE Operational Environment ................................................................................................................19

2.2.2. Partitioned Information Flow Policy (PIFP) ............................................................................................20

2.2.3. Partitioned Information Flow Policy Channels ........................................................................................20

2.2.4. Configuration Data...................................................................................................................................21

2.2.5. TOE Configuration Changes....................................................................................................................22

2.2.6. Trust Anchors...........................................................................................................................................23

2.3. Trusted Delivery ..............................................................................................................................................24

2.4. Trusted Recovery.............................................................................................................................................24

2.5. Evaluation Considerations ...............................................................................................................................26

2.5.1. Security Management...............................................................................................................................26

2.5.2. TOE Component Development Diversity ................................................................................................26

2.6. General TOE Functionality..............................................................................................................................27

2.7. Use of High Robustness...................................................................................................................................27

3. TOE Security Environment .....................................................................................................................................28

3.1. Threats to Security ...........................................................................................................................................28

3.2. Security Policy.................................................................................................................................................30

3.3. Security Usage Assumptions ...........................................................................................................................31

2


4. Security Objectives..................................................................................................................................................33

4.1. TOE Security Objectives .................................................................................................................................33

4.2. Environment Security Objectives ....................................................................................................................36

5. TOE Security Functional Requirements ..................................................................................................................38

5.1. Security audit (FAU)........................................................................................................................................38

5.1.1. Security Audit Automatic Response (FAU_ARP) ...................................................................................38

5.1.2. Security audit data generation (FAU_GEN) ............................................................................................38

5.1.3. Security audit event selection (FAU_SEL) ..............................................................................................42

5.2. Cryptographic support (FCS)...........................................................................................................................43

5.2.1. Cryptographic key management (FCS_CKM).........................................................................................43

5.2.2. Cryptographic operation (FCS_COP) ......................................................................................................43

5.3. User data protection (FDP) ..............................................................................................................................43

5.3.1. Information flow control policy (FDP_IFC) ............................................................................................43

5.3.2. Information flow control functions (FDP_IFF)........................................................................................44

5.3.3. Internal TOE transfer (FDP_ITT) ............................................................................................................45

5.3.4. Residual information protection (FDP_RIP)............................................................................................45

5.4. Identification and authentication (FIA)............................................................................................................45

5.4.1. User attribute definition (FIA_ATD) .......................................................................................................45

5.5. Security Management (FMT)...........................................................................................................................46

5.5.1. Management of Security Functions Behavior (FMT_MOF)....................................................................47

5.5.2. Management of Security Attributes (FMT_MSA) ...................................................................................47

5.5.3. Management of TSF Data (FMT-MTD) ..................................................................................................48

5.6. Privacy (FPR) ..................................................................................................................................................49

5.6.1. Unobservability (FPR_UNO)...................................................................................................................49

5.7. Protection of the TSF (FPT).............................................................................................................................49

5.7.1. Explicit: Configuration Change (FPT_CFG) ...........................................................................................49

5.7.2. Establishment of Secure State (FPT_ESS_EXP) .....................................................................................50

5.7.3. Fail secure (FPT_FLS).............................................................................................................................51

5.7.4. Internal TOE TSF data transfer (FPT_ITT) .............................................................................................51

5.7.5. Trusted Recovery (FPT_RCV).................................................................................................................51

3


5.7.6. Replay detection (FPT_RPL) ...................................................................................................................52

5.7.7. Explicit: TOE Restart (FPT_RST) ...........................................................................................................52

5.7.8. Request Validation (FPT_RVD_EXP).....................................................................................................53

5.7.9. Reference mediation (FPT_RVM) ...........................................................................................................53

5.7.10. Domain separation (FPT_SEP) ..............................................................................................................53

5.7.11. State synchrony protocol (FPT_SSP).....................................................................................................53

5.7.12. Time stamps (FPT_STM) ......................................................................................................................53

5.7.13. TSF Self Test (FPT_TST) ......................................................................................................................54

5.8. Resource utilization (FRU) ..............................................................................................................................54

5.8.1. TSF Predictable Resource Utilization (FRU_PRU_EXP)........................................................................54

5.8.2. Resource allocation (FRU_RSA) .............................................................................................................55

6. TOE Security Assurance Requirements ..................................................................................................................56

6.1. Configuration Management (ACM).................................................................................................................58

6.1.1. CM Automation (ACM_AUT).................................................................................................................58

6.1.2. CM Capabilities (ACM_CAP) .................................................................................................................58

6.1.3. CM Scope (ACM_SCP)...........................................................................................................................60

6.2. Delivery and Operation (ADO)........................................................................................................................61

6.2.1. Delivery (ADO_DEL)..............................................................................................................................61

6.2.2. Installation, Generation and Start-Up (ADO_IGS) ..................................................................................63

6.3. Development (ADV)........................................................................................................................................63

6.3.1. Architectural Design (ADV_ARC)..........................................................................................................63

6.3.2. Composition Information (ADV_CMP) ..................................................................................................64

6.3.3. Functional Specification (ADV_FSP)......................................................................................................64

6.3.4. High-Level Design (ADV_HLD).............................................................................................................65

6.3.5. Information Availability (ADV_IFA) ......................................................................................................66

6.3.6. Implementation Representation (ADV_IMP) ..........................................................................................67

6.3.7. Trusted Initialization (ADV_INI) ............................................................................................................68

6.3.8. TSF Internals (ADV_INT).......................................................................................................................70

6.3.9. Low-Level Design (ADV_LLD)..............................................................................................................73

6.3.10. Representation Correspondence (ADV_RCR).......................................................................................74

4


6.3.11. Security Policy Modeling (ADV_SPM).................................................................................................75

6.4. Guidance Documents (AGD)...........................................................................................................................76

6.4.1. Administrator Guidance (AGD_ADM)....................................................................................................76

6.4.2. User Guidance (AGD_USR)....................................................................................................................78

6.5. Life Cycle Support (ALC) ...............................................................................................................................78

6.5.1. Development Security (ALC_DVS) ........................................................................................................78

6.5.2. Flaw Remediation (ALC_FLR) ...............................................................................................................79

6.5.3. Life Cycle Definition (ALC_LCD)..........................................................................................................80

6.5.4. Tools and Techniques (ALC_TAT) .........................................................................................................81

6.6. Ratings Maintenance (AMA)...........................................................................................................................82

6.6.1. Assurance Maintenance Plan (AMA_AMP)............................................................................................82

6.7. Testing (ATE) ..................................................................................................................................................83

6.7.1. Coverage (ATE_COV).............................................................................................................................83

6.7.2. Depth (ATE_DPT) ...................................................................................................................................83

6.7.3. Functional Tests (ATE_FUN)..................................................................................................................84

6.7.4. Independent Testing (ATE_IND).............................................................................................................84

6.8. Vulnerability Analysis (AVA) .........................................................................................................................85

6.8.1. Covert Channel Analysis (AVA_CCA) ...................................................................................................85

6.8.2. Misuse (AVA_MSU) ...............................................................................................................................86

6.8.3. Strength of TOE Security Functions (AVA_SOF)...................................................................................87

6.8.4. Vulnerability Analysis (AVA_VLA) .......................................................................................................87

7. Rationale..................................................................................................................................................................90

7.1. Security Objectives Rationale..........................................................................................................................90

7.1.1. Policies .....................................................................................................................................................90

7.1.2. Threats......................................................................................................................................................90

7.1.3. Assumptions.............................................................................................................................................90

7.2. Security Requirements Rationale.....................................................................................................................90

7.2.1. Functional Requirements Rationale .........................................................................................................90

7.2.2. Assurance Requirements Rationale..........................................................................................................90

7.3. Dependency Rationale .....................................................................................................................................91

5


7.4. Security Functional Requirements Grounding in Objectives...........................................................................91

8. Works Cited.............................................................................................................................................................92

6


1. Introduction This section contains overview information necessary to allow a Protection Profile (PP) to be registered through a Protection Profile Registry. The PP identification provides the labeling and descriptive information necessary to identify, catalogue, register, and cross-reference a PP. The “Protection Profile Overview” summarizes the profile in narrative form and provides sufficient information for a potential user to determine whether the PP is of interest. The Protection Profile Overview can also be used as a stand-alone abstract for PP catalogues and registers. The “Con-ventions” section provides the notation, formatting, and conventions used in this protection profile. The “Glossary of Terms” section gives a basic definition of terms, which are specific to this PP. The “Document Organization” sec-tion briefly explains how this document is organized.

1.1. Identification Title:

Protection Profile for Partitioning Communications Systems in Environments Requiring High Robustness

Registration:

draft, not currently registered

Keywords:

Partitioning Communications System (PCS), Multiple Independent Levels of Security (MILS), Separation Kernel (SK), COTS, Middleware, Channel, Network, high robustness, information flow control

1.2. Protection Profile Overview This “Protection Profile for Partitioning Communications Systems in Environments Requiring High Robustness” specifies the security functional and assurance requirements for a configurable Partitioning Communications System (PCS). A Partitioning Communications System's primary security function is to extend the single node security pol-icy enforcement provided by the MILS Separation Kernel to a distributed computing environment where a high de-gree of robustness is required. Partitioning Communications Systems conformant with this Protection Profile (PP) depend on an underlying operating system kernel that has been certified to meet the requirements of the “U.S. Gov-ernment Protection Profile for Separation Kernels in Environments Requiring High Robustness [SKPP]”. This pro-tection profile is based on the “Common Criteria for Information Technology Security Evaluations, Version 2.2.”

Products conforming to this PP are called “Partitioning Communications Systems” because they partition communi-cations according to user-configurable security policies. These policies can be used to support IT policies with a scope beyond those enforced by the PCS, such as policies requiring separation by community of interest. Other poli-cies may require that data be processed by non-bypassable downgrading or guarding applications before release. A correctly used Partitioning Communications System which has been evaluated against this PP forms a foundation for building larger systems that are Multi Level Secure (MLS). However, the PCS itself only serves as a building block. The security requirements for the MLS system as a whole are not addressed in this document.

This PP uses Department of Defense (DoD) and National Information Assurance (IA) guidance and policies as a basis to establish the requirements for National Security Systems1. Products demonstrating conformance to this pro-tection profile become candidates for use in National Security Systems. However, conformance to this protection profile, by itself, does not offer sufficient confidence that national security information is appropriately protected in

1National Security systems are systems that contain classified information or involve intelligence activities, involve cryptologic activities related to national security, involve command or control of military forces, involve equipment that is an integral part of a weapon or weapon system, or involve equipment that is critical to the direct fulfillment of military or intelligence missions.

7


the context of a larger system in which the conformant product is integrated. Designers of such systems must apply appropriate systems security engineering principles and techniques to afford acceptable protection for national secu-rity information. In particular, it is the responsibility of the system designer to articulate support for a coherent ap-plication-level security policy in the Partitioning Communications System's configuration data, as well as to ensure that the configuration data itself is coherent and self-consistent. It is only with well-formed configuration data that the Partitioning Communications System can be expected to enforce mission critical security policies. Such policies may include those that are associated with the management of information classified at different sensitivity or en-clave levels based on degrees of confidentiality, integrity, or releasability.

Conformant products may also be suitable for non-DoD government and commercial mission-critical applications, given similarly well-formed configuration data. The judgment as to whether a given instantiation of configuration data is coherent, as well as being well formed with respect to some application-level security policy is beyond the scope of this protection profile.

The conformant product includes the support tools and procedures used to securely generate and distribute the con-figuration data required by the Separation Kernel. Specific assurance requirements are allocated to those support tools and procedures.

1.3. Mutual Recognition of Common Criteria Certificates The assurance requirements contained in this PP are equivalent to the Evaluation Assurance Level 6 (EAL6) as de-fined in version 2.2 of the Common Criteria (CC) with augmentation. The augmented assurances are in the areas of development, independent testing, systematic flaw remediation, and maintenance of assurance. COTS Partitioning Communications Systems meeting the requirements of this profile provide a high level of robustness. Under the “Arrangement on the Mutual Recognition of Common Criteria Certificates in the field of Information Technology Security” document, only CC certificates at or below EAL4 are mutually recognized. Because this profile exceeds the limits imposed by the “Arrangement on the Mutual Recognition of Common Criteria Certificates in the field of Information Technology Security” document, the US will recognize only certificates issued by the US evaluation scheme to meet this profile. Other national schemes are likewise under no obligation to recognize US certificates with assurance components exceeding EAL4.

1.4. Conventions The notation, formatting, and conventions used in this protection profile (PP) are consistent with version 2.2 of the Common Criteria for Information Technology Security Evaluation. Font style and clarifying information conven-tions were developed to aid the reader.

The CC permits four functional component operations: assignment, iteration, refinement, and selection to be per-formed on functional requirements. These operations are defined in Common Criteria version 2.2, Part 1, Section 4.4.1.3.2, paragraph 169 as:

a. Assignment: allows the specification of parameters;

b. Refinement: allows the addition of details.

c. Selection: allows the specification of one or more items from a list; and

d. Iteration: allows a component to be used more than once with varying operations;

Assignments or selections left to be specified by the developer in subsequent security target documentation are itali-cized and identified between brackets (“[ ]”). In addition, when an assignment or selection has been left to the dis-cretion of the developer, the text “assignment:” or “selection:” is indicated within the brackets. Assignments or se-lection created by the PP author (for the developer to complete) are bold, italicized, and between brackets (“[ ]”). CC selections completed by the PP author are underlined and CC assignments completed by the PP author are bold.

Refinements are identified with “Refinement:” right after the short name. They permit the addition of extra detail when the component is used. The underlying notion of a refinement is that of narrowing. There are two types of nar-

8


rowing possible: narrowing of implementation and narrowing of scope2. Additions to the CC text are specified in bold.

Deletions of the CC text are identified in the “End Notes” with a bold number after the element (“8”).

Iterations are identified with a number inside parentheses (“(#)”). These follow the short family name and allow components to be used more than once with varying operations.

Explicit Requirements are allowed to create requirements should the Common Criteria not offer suitable require-ments to meet the PP needs. The naming convention for explicit requirements is the same as that used in the CC. To ensure these requirements are explicitly identified, the ending “_EXP” is appended to the newly created short name. However, most of the explicit requirements are based on existing CC requirements. To make it easier for the PP reader to view any changes from existing CC elements, the added text is written in bold text.

Application Notes are used to provide the reader with additional requirement understanding or to clarify the author's intent. These are italicized and usually appear following the element needing clarification.

Table 1 provides examples of the conventions (explained in the above paragraphs) for the permitted operations.

Table 1. Functional Requirements Operation Conventions

Convention Purpose Operation

Bold The purpose of bolded text is used to alert the reader that additional text has been added to the CC. This could be an assignment that was completed by the PP author or a refinement to the CC statement.

Examples:

FDP_IFC.2.1 The TSF shall enforce Information Flow Control policy on subjects and all resources that cause information to flow to and from subject covered by the SFP.

FAU_GEN.1.1 Refinement: The TSF shall be able to generate audit data for the following auditable events:

(Completed) Assignment

or

Refinement

Italics The purpose of italicized text is to inform the reader of an assignment or selection operation to be com-pleted by the developer or ST au-thor. It has been left as it appears in

Assignment (to be completed by developer or ST author)

or

Selection (to be completed by

2US interpretation #0362: Scope of Permitted Refinements

9


Convention Purpose Operation the CC requirement statement.

Examples:

FAU_ARP.1.1 The TSF shall take [assignment: list of least disruptive actions] upon detection of a potential security violation.

FDP_RIP.2.1 The TSF shall ensure that any previous in-formation content of a re-source is made unavailable upon the [selection: alloca-tion of the resource to, deal-location of the resource from] all exported resources

developer or ST author)

Underline The purpose of underlined text is to inform the reader that a choice was made from a list provided by the CC selection operation statement.

Example:

FAU_SEL.1.1 The TSF shall be able to include or exclude auditable events from the set of audited events based on the following attributes:

a. subject identity,

b. event type,

c. success of auditable security events, and

d. failure of auditable se-curity events.

Selection (completed by PP author)

Parenthesis

(Iteration #)

The purpose of using parenthesis and an iteration number is to inform the reader that the author has se-lected a new field of assignments or selections with the same require-ment and that the requirement will be used multiple times. Iterations are performed at the component level. The component behavior name includes information specific to the iteration between parenthesis.

Iteration 1 (of component)

Iteration 2 (of component)

10


Convention Purpose Operation

Example:

5.4.1.1 Explicit: Manage-ment of TSF Data (for Con-figuration Data) (FMT_MTD_EXP.1)

FMT_MTD_EXP.1.1(1) The TSF shall restrict the ability to select and activate the TSF policy configuration data to authorized subjects.

5.4.1.1 Explicit: Manage-ment of TSF Data (for General TSF Data) (FMT_MTD_EXP.1(2))

FMT_MTD_EXP.1.1(2)The TSF shall prevent modifica-tion of TSF policy configura-tion data.

Explicit: (_EXP) The purpose of using Explicit: be-fore the family or component be-havior name is to alert the reader and to explicitly identify a newly created component. To ensure these requirements are explicitly identi-fied, the “_EXP” is appended to the newly created short name and the component and element names are bolded.

Example:

5.4.1.1 Explicit: Manage-ment of Security Func-tions Behavior (FMT_MOF_EXP.1)

FMT_MOF_EXP.1.1 The TSF shall restrict the ability to enable and disable audit generation to the configura-tion data.

Explicit Requirement

Endnotes The purpose of endnotes is to alert the reader that the author has de-leted Common Criteria text. An endnote number is inserted at the end of the requirement, and the endnote is recorded on the last page

Refinement

11


Convention Purpose Operation of the section. The endnote state-ment first states that a deletion was performed and then provides the rationale. Following is the family behavior or requirement in its origi-nal and modified form. A strike-through is used to identify deleted text and bold for added text. A text deletion rationale is provided.

Examples:

Text as shown:

FAU_SAA.1.2 Refinement: The TSF shall monitor the accumulation or combination of the following events known to indicate a potential security violation: [assign-ment: subset of defined au-ditable events]. 1

Endnote statement:

A deletion of CC text was performed in FAU_SAA.1.2. Rationale: The words “en-force the following rules for monitoring audited events: a)” were deleted for clarity and flow of the requirement. Additionally the assignment was moved from the middle of the requirement to the end for clarity and flow of the requirement.

FAU_SAA-1.2 Refinement: The TSF shall enforce the following rules for monitoring audited events: a) monitor the accumulation or combi-nation of [assignment: sub-set of defined auditable events] the following events known to indicate a potential security violation: [assignment: subset of de-fined auditable events].

12


1.5. Glossary This profile includes terms from the Common Criteria by reference. Other terms are described in this section to aid in the understanding and application of the requirements.

Administrator Any person authorized to configure, install, integrate, or maintain the TOE or its data. An administrator is one of several trusted individuals. See Trusted Individ-ual.

Agent An active entity outside the TSC. Active entities within the TSC are considered to be subjects (see Subject).

Channel A logical connection between a sending subject and one or more receiving sub-jects.

Configuration Function The procedures and automated mechanisms employed to generate the TSF con-figuration data and corresponding integrity seals.

Configuration Data Configuration data provides various control information to the TOE. This data is used by the initialization function to determine the operational configuration of the TOE and to establish the TSF in an initial secure state. Once established in its initial secure state, the TSF uses the configuration data to maintain a se-cure state during runtime.

The configuration data is considered TSF data because it is relied on by the TSF for secure execution of the TOE. The configuration data includes, but is not lim-ited to, the following descriptions:

• Partitioned Information Flow Policy

The configuration data must be protected from modification to ensure the integ-rity of the TOE configuration and initial secure state of the TSF.

Covert Channel An unintended and/or unauthorized communications path that can be used to transfer information in a manner that violates a security policy. Covert channels allow transfer of information through indirect access by subjects to internal re-sources; whereas, a transfer of information in violation of the security policy through exported resource(s) would be a TSF flaw.

Delivery, Trusted Procedures and automated mechanisms employed to deliver a copy of the TOE from the TOE developer to the customer, such that the customer copy is assured to be the same as the developer's master copy.

Initialization Function The procedures and automated mechanisms that establish the TSF in an initial secure state.

The initialization function includes the TOE mechanism that brings the TSF data into the TSF security domain.

Load Function The procedures and automated mechanisms to convert the software implementa-tion and/or configuration data in a TSF useable form. The load function can take different forms, including: placement of the implementation or configuration in-formation onto suitable media (e.g., CD, ROM or flash memory); or compilation of configuration data as part of the TSF implementation. The load function may also include the insertion or installation of the media into the TOE hardware at either the TOE developer or customer site.

13


Maintenance Mode A TOE runtime mode resulting from the detection of a failure or imminent fail-ure in which some or all security functions are non-operational and user inter-vention is required to recover the TSF to an operational secure state.

Node A hardware entity running a single separation kernel. Different nodes may be tightly coupled (e.g. via shared memory) or loosely coupled (e.g. via a message oriented interface), but each node runs a distinct separation kernel which pro-tects resources unique to that node.

Operational Configuration change The operational configuration of the TOE is determined by the set of configura-tion data used to establish the TOE in its initial secure state and to enforce the Partitioned Information Flow Policy during a continuous runtime session of the TOE (i.e., from startup to shutdown).

A change of the operational configuration can consist of a change to the behav-ior of the Partitioned Information Flow Policy enforcement mechanisms, a change to the definition of the initial secure state, or both. The change of opera-tional configuration can occur statically (required) or dynamically (optional).

Operational Mode A runtime mode in which all TSF security functions are available.

Partitioned Information Flow Policy (PIFP)

The policy enforced by the TSF that provides for controlled information flows between partitions, and optionally, between subjects and exported resources al-located to those partitions. The TOE may be configured to support one or multi-ple immutable Partitioned Information Flow Policies (PIFPs).

Note that the PIFP defines only the authorized flows between partitions and be-tween the subjects and exported resources allocated to those partitions. The PIFP does not define the size and locations of partitions or the allocation of subjects and exported resources to partitions. (See Configuration Data).

Partition A region of access-controlled memory. Region definition and access control are enforced by the Separation Kernel (SK)'s TSF as defined in its TSF data. Subjects that cause information flow and the Partitioning Communications Sys-tem (PCS) which enforces the TSP for those flows typically reside in different partitions.

Partitioning Communications System (PCS)

An IT system composed of some combination of hardware and/or software which provides communications mechanisms to subjects running in separate partitions on potentially different nodes while enforcing security policies on those communications.

Principle of Least Privilege This principle requires that each subject and TSF internal module be granted the most restrictive set of privileges needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.

Residual Information Protection (RIP)

Protection of information that has been logically deleted or released, which is not available to the user but may still be present within the system and may be recoverable. It also applies to protection of resources that are serially reused by different subjects within the system.

14


Note that residual information protection applies to all resources in the TOE: those exported by the TSF as well as those internal to the TSF. See Resource; Resource, Exported; Resource, Internal.

Resource; Resource, Exported; Resource, Internal

Resources are the totality of all hardware, firmware and software and data that are executed, utilized, created, protected or exported by the TSF.

Exported resources are those resources to which an explicit reference is possible via a TSF interface (e.g., the programming or configuration interface).

Internal resources are those resources used exclusively by the TSF, and which have no explicit reference via a TSF interface.

Secure State The meaning of “secure state” is dependent on the TSP model. “Secure state” in this protection profile means that

1. the TSF data is consistent and uncorrupted, and the TSF can correctly en-force the policy represented by the TSP model, and

2. all TSF actions and transitions subsequent to an initial secure state

a. are allowed by the TSP model, or,

b. are successfully rolled back to some previous secure state, or,

c. result in a transition of the TSF to an initial secure state.

Secure State, Initial The initial secure state is the secure state arrived at after a successful initializa-tion.

Security Domain A security domain (also referred to as a protection domain), is a bounded and protected set of resources.

The security domain of the TSF is distinct from (i.e., non-overlapping) the secu-rity domains of subjects and other entities external to the TSF.

The security domain of a subject includes the exported resources that the par-ticular subject is allowed to use. Since subjects may access resources in parti-tions other than their own, security domains are orthogonal to partitions.

The security domains of different subjects are distinct except for controlled shar-ing explicitly allowed by the TSF.

Separation Kernel (SK) A hardware and/or software mechanism whose primary function is to separate multiple partitions and control information flow between and within the parti-tions within a single node. See the SK PP [SKPP].

Subject An active entity within the TSC that causes operations to be performed. A sub-ject is an abstraction created by the TSF and exported at the TSFI.

Trusted Individual A person who performs procedures upon which the security of the TOE and the processes used to develop the TOE may depend. The roles and responsibilities of these persons may include those that develop, configure, install, operate and maintain the TOE, as required for a specific TOE type developed to execute in specific operational environments and contexts. See Administrator.

15


The requirements for establishing the trustworthiness of trusted individuals are allocated to the environment. See the security objective OE.TRUSTED_INDIVIDUAL.

1.6. Organization Section one provides the introductory material for the protection profile.

Section two describes the Target of Evaluation in terms of its envisaged usage and connectivity.

Section three defines the expected TOE security environment in terms of the threats to its security, the security as-sumptions made about its use, and the security policies that must be followed.

Section four identifies the security objectives derived from the threats and policies.

Section five identifies and defines the security functional requirements from the CC that must be met by the TOE in order for the functionality-based objectives to be met.

Section six identifies the TOE security assurance requirements.

Section seven provides a rationale to explicitly demonstrate that the information technology security objectives sat-isfy 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 ad-dressed by one or more component requirements. Argument are provided for the coverage of each objective.

Section eight identifies background material used as reference to create this profile.

1.7. Related Protection Profile The following Protection Profile describes requirements for systems that either underlie or provide support for the Partitioning Communications System:

• U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness [SKPP]

16


2. Target of Evaluation (TOE) Description 2.1. Product Type This protection profile specifies requirements for a TOE comprised of a Partitioning Communications System in an environment consisting of a Separation Kernel3 and the underlying hardware for use in National Security Systems and other systems responsible for protecting highly sensitive information. The Partitioning Communications System enables policy-constrained communications between subjects running on one or more nodes in a distributed system. Demonstration of these capabilities to the rigor of high robustness verification objectives requires the PCS be mini-mized in size and complexity with respect to functionality, architecture, and design. This protection profile focuses on core functional capabilities that include:

• management of shared communications resources to provide trustworthy channel separation

• management of shared communications resources to provide usage quotas by channel

• protection of data confidentiality

• protection against traffic analysis

• authentication of nodes and subjects

• verification of data integrity

The TOE provides to its subjects high assurance separation and information flow control properties that are both tamperproof and non-bypassable. The PCS makes it possible to design systems in an essentially location-agnostic manner with respect to communications security. System designers using a PCS should be able to locate partitions on different nodes without fear of introducing new threats to data confidentiality or integrity due to communications between those nodes. Threats to availability may be introduced depending upon the underlying communications mechanism; a PCS is not the appropriate tool to address availability threats at the physical layer of the network, or to enforce quotas on communications resources that it does not completely control.

By providing distributed versions of the security policies locally enforced by a Separation Kernel, the PCS facilitates the construction of secure distributed systems. Because of the strong requirements levied by this Protection Profile, the PCS becomes an ideal building block for implementing trustworthy distributed systems. Examples of compo-nents which could be built using a PCS and an SK include secure foundational middleware (CORBA, DDS, web services), distributed trusted downgraders, guards, multilevel secure reference monitors and others.

The PCS is not a complete middleware solution. A PCS does not provide features such as Remote Procedure Call (RPC) facilities or interface definition languages (IDL) that are traditionally associated with middleware technolo-gies. The PCS is intended to be a light-weight facility to enable secure, distributed communications upon which many higher-level technologies may be layered, such as RPC or IDL.

Figure 1, “Allocation of TOE Components” depicts the components that comprise the TOE, illustrates the relation-ship of the TOE to the security functions provided by the Environment, and indicates which of TOE components comprise the TSF. Although all components are not part of the TSF, they each serve a role in establishing the TSF in its initial secure state from which the TSF is able to continuously enforce the defined policy. There are TOE assur-ance requirements allocated to each of these non-TSF components (refer to Section 6). The functional requirements for the TSF are found in Section 5. The role of these non-TSF functions in support of establishment of the TSF in its initial secure state is as follows:

3See U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness

17


• Trusted Delivery. The TOE developer employs trusted mechanisms and procedures to deliver the TOE to the customer (e.g., system integrator, application developer or end user). Trusted delivery is used for the initial ver-sion distribution as well as for the distribution of updates. See Figure 4, “PCS Trusted Delivery Scenario”.

• Configuration. A trusted individual employs evaluated TOE procedures and tools to generate the machine-readable configuration data and a corresponding integrity seal. The integrity seal is applied to the configuration data after the configuration data is verified by a trusted individual. At a minimum, the configuration tool must translate human-readable (e.g., ASCII) characters into machine-readable (e.g., binary) format. A trusted individ-ual verifies the accuracy of the generated configuration data either through manual inspection or with the support of TOE automated tools.

Figure 1. Allocation of TOE Components

2.2. TOE Concepts The TOE achieves isolation of information flows by virtualization of communications resources, some of which may be shared. Each flow encompasses a resource set that appears to be entirely its own (see Figure 2, “Virtualiza-tion of Communications Resources”). To achieve this objective for resources that can only transfer one program data unit at a time, such as Ethernet, the TOE must ensure that the temporal usage patterns from different flows are not apparent to each other (e.g., through “periods processing”). Other resources may be simultaneously accessible to subjects in multiple flows. For such cases, the TOE might achieve isolation by allocating distinct portions of the resource to different flows. Furthermore, TOE utilization of its own internal resources must also preserve the desired isolation properties.

Figure 2. Virtualization of Communications Resources

18


The TOE provides separation through enforcement of explicit policy rules. These policy rules define the information flows that are authorized between subjects. The set of policy rules are referred to as the Partitioned Information Flow Policy (PIFP). By default, the TOE enforces a restrictive PIFP which has the property that there can be no in-formation flow.

This default restrictive behavior of the TOE may be changed by specifying explicit rules for authorized information flows between subjects (see the section called “Partitioned Information Flow Policy (PIFP)”). These rules, along with other attributes of the TOE (security function behavior and TOE configuration) are specified in configuration data that is accessed by the TOE during initialization. The configuration data is created using tools and procedures as part of the TOE. The TOE relies on the configuration data for the following information:

• definition of the authorized information flows

• designation of authorized subjects

• definition of audit function behavior

2.2.1. TOE Operational Environment

The Partitioning Communications System both provides and relies upon interfaces provided by external IT entities. With the exception of interfaces which provide services guaranteed to be trustworthy by the separation kernel, the

19


PCS must protect itself against threats to the TSF and subject data stemming from the use or availability of those interfaces.

The most obvious interfaces presented to potentially malicious agents are those which connect the PCS to inter-node networks. These interfaces are unique in that the Separation Kernel is not able to provide guarantees which satisfy the authentication, integrity, or confidentiality requirements of the PCS. The PCS must treat all data received via the inter-node communications interface as coming from a potentially hostile source.

Less obvious potentially hostile interfaces are those provided by the separation kernel which connect the PCS to client subjects on the same node. Only data provided by the SK via these interfaces may be trusted; all TSF-relevant data provided by local subjects must be verified by the PCS before use. However, this interface still poses less risk than inter-node communications interfaces because significant classes of attacks are presumed to be dealt with by the SK. Examples of these attacks include man in the middle and identity spoofing (when the identity is provided by the SK).

Additionally, the interface represented by the static configuration data is implicitly trusted. Once the PCS has vali-dated that its current configuration data has not been modified since creation by an authorized entity, the PCS must assume that configuration to be correct. This requires that the administrator creating the configuration data is both trustworthy and capable of generating appropriate configuration data.

Finally, the physical operational environment of the PCS is assumed to be protected and the environment is required to counter any threats stemming from physical attacks.

2.2.2. Partitioned Information Flow Policy (PIFP)

A precise statement of the PIFP4 can be found in the section called “Glossary”. An information flow among subjects is essentially an abstraction implemented by the TSF from resources under its control. Configuration data contains the description of how (e.g., in which mode information is allowed to flow among subjects.

Information flow in the TOE may be initiated by the TSF (e.g., appending TSF status or audit data to an exported resource) or by a subject. Subjects invoke information flow in the TOE via “controlled operations.” A single con-trolled operation may cause one or more flows, each of which characterizes information moving between the invok-ing subject and a unique exported resource. Thus, an information “flow” is defined as a [subject, exported resource, mode] triplet. Note that the exported resource may in fact be another subject.

The PIFP is based on the following fundamental principles:

1. The scope of the PIFP includes all subjects and exported resources; there are no subjects or exported resources exempt from the policy;

2. It is possible for a given controlled operation to result in the initiation of multiple information flows. For such a case, each flow that is initiated by the controlled operation must be explicitly authorized to take place. Should at least one flow that is invoked by a controlled operation not be authorized, then the controlled operation is not allowed to execute and none of the flows associated with the controlled operation will occur.

2.2.3. Partitioned Information Flow Policy Channels

The primary abstraction provided by the Partitioning Communications System is the channel. A channel is a one-way logical connection from a single source subject to one or more destination subjects existing on the same or dif-ferent nodes. The PCS mediates subjects' interactions via channels according to two security policies: the channel connectivity policy and the resource management policy.

4Refer to the FDP_IFC and FDP_IFF components in Section 5 for requirements details.

20


The channel connectivity policy describes the allowable connections between subjects within a distributed system. Essentially, this policy is an access control policy limiting which subjects may directly communicate via channels provided by the Partitioning Communications System. The resource management policy describes how the shared communications resources used to implement channels are to be allocated between channels and the extent to which channels may influence each other (either cooperatively or inadvertently) through the use of shared resources. When the resource policy does not allow different channels to influence each other, no use of a channel by a subject should be observable by a subject examining the result of actions performed on any other channel which is specified to be separated from the first channel.

Figure 3, “An example security policy” illustrates a combined channel connectivity and resource management pol-icy. Every arrow in the graph is intended to represent a logical, one-way connection from a single source subject to one or more destination subjects. The use of resource groups demonstrates a convention for a policy requiring the complete communications resource separation of channels belonging to different groups. While the degree of re-source-based interaction within the groups is left unspecified, a more detailed policy could place further restrictions on the interactions within a group. It is important to note that no requirement for subject-level (as opposed to parti-tion-level) separation kernel access control granularity is intended to be implied by this example. A product confor-mant with this PP may describe bindings to endpoints at either the subject or partition level, as supported by the un-derlying separation kernel. See the SK PP [SKPP] for further discussion of subjects and partitions.

Figure 3. An example security policy

The representation format for the channel connectivity and resource management policies used by a PCS is inten-tionally unspecified. Conformant products may use any form of specification, either explicit or derived, so long as that specification is unambiguous and allows a human examiner (possibly with tool support) to determine whether any given potential connection would be allowed by the policy, and every resource allocation rule specified by the policy. If tool support is necessary to create or evaluate a policy, than that tool shall be considered part of the TOE and evaluated along with the rest of the TOE.

2.2.4. Configuration Data

The configuration data is used to establish the configuration of the TOE and to place the TSF in an initial secure state from which the TSF maintains secure state throughout the execution of the TOE. The specific content and for-mat of the configuration data is dependent on the attributes required to completely define an instance of the PIFP enforced, and on the attributes associated with TOE design and implementation choices.

21


The security policy configuration data of the PCS consists of a combination of the channel connectivity and resource management policies. The complete configuration data for the system does not need to exist on each node in the system. However, a subset of the configuration data sufficient for a node to determine that its configuration is con-sistent with the configurations of other nodes it may communicate with must be stored on that node. Before the PCS performs communications between subjects on different nodes, the PCS must ensure that the nodes participating in the communication have consistent configuration data.

Multiple partial configurations are consistent if their use by compliant PCS nodes can not result in violations of the complete policies of which the partial policies are subsets. PCS implementations are free to perform the consistency analysis of partial configurations prior to system initialization (as opposed to at run time when other nodes are en-countered) as long as the analysis results are delivered to the TOE in a trustworthy manner. See O.TRUSTED_DELIVERY [32].

2.2.5. TOE Configuration Changes

This protection profile defines the TOE configuration as a set of attributes that support the enforcement of policy (PIFP) and define the TOE configuration. The TOE configuration is statically defined and maintained during an execution session. An execution session is defined as the set of states from secure start-up to secure shutdown of the TOE. In support of system-level requirements for flexible networking, reliability, and availability, it may be neces-sary to change the TOE configuration. A configuration change is defined as a change in the behavior of the PIFP enforcement function, a change in the TOE configuration, or perhaps both. A configuration change can occur with or without support from the TOE. For those cases where the TOE supports the ability to change configuration, the TOE must be capable of maintaining multiple configuration data sets (where the configuration data is the sum of all defined configuration data sets), and must provide the means for an authorized subject to invoke the change from one configuration data set to another.

The initiation of change from one configuration data set to another can be implemented as an offline, or as a static or dynamic change capability. These characteristics and the assurance issues of each are as follows.

2.2.5.1. Offline Initiation of Change

The TOE is initialized with one configuration data set which defines the current configuration.

The TSF provides the capability for an authorized subject to shut down the TOE. Before reinitialization, an adminis-trator or mechanism outside of the TOE may load a different configuration data set which will become the current configuration as a result of the next TSF initialization.

2.2.5.2. Static Initiation of Change

In addition to the capabilities of assurance issues of the Offline Initiation of Change, a TOE Static Change includes the following.

The TOE is initialized with one or more configuration data sets, one of which defines the current configuration. The TSF provides the capability for an authorized subject to designate one of the configuration data sets as the next cur-rent configuration, which will become the current configuration as a result of the next TSF initialization.

A static configuration change requires the TOE to execute the configuration change by first transitioning to a secure halted state after which the TOE initializes with a different configuration data set5. This profile requires the TOE to implement at least a static change capability.

The additional assurance issues associated with this configuration change capability is to ensure that only an author-ized subject may request the configuration change and that the TOE properly executes the change request.

5The same mechanism may be used to support a simple reinitialization where the TOE shuts down and restarts in the same configuration.

22


2.2.5.3. Dynamic Initiation of Change

There can be varying degrees of dynamicity, each with corresponding implementation complexities and resultant assurance issues. The profile provides the option for the TOE developer to implement a dynamic change capability and provides a minimal dynamic change capability as a selection operation (see discussion in next paragraph). Should the TOE developers choose to implement more dynamicity in the configuration change capability, then they incur the responsibility to document any additional security requirements in the Security Target such that the Secu-rity Target ASE criteria are met. Furthermore, they must provide the rationale to demonstrate that the added func-tional requirements continue to meet the foundational objectives of this profile, and are complete and consistent with the functional requirements of this profile.

The functional properties and assurance issues associated with dynamic configuration change are as follows:

• Minimal Dynamic Change: In addition to the capabilities and assurance issues of Static Change, a Minimal Dynamic Change includes the following:

The configuration change takes place during the same runtime session in which the change was designated (ver-sus after the next TSF initialization that includes a halted state).

The additional assurance issue associated with this capability is that the TSF continuously maintains a secure state before, during, and after any configuration change, to include preserving all of its other security characteris-tics, such as those relating to covert channels and the invoking of exported functions via a TSFI.

• Moderate Dynamic Change: In addition to the capabilities and assurance issues of the Minimal Dynamic Change, a TOE Moderate Dynamic Change includes both of the following.

The TSF provides the capability for a trusted authorized subject to perform ad hoc runtime configuration changes within explicit constraints that are enforced by the TSF. The ad hoc changes are those that are not de-fined in the configuration data sets with which the TSF has been initialized. These changes include, but are not limited to, creating and destroying information flows. Depending upon the underlying Separation Kernel, these changes may also include "over the air" loading of images into partitions.

A set of policy constraints, defined as part of the policy definition, limits the type of policy transitions and new PIFP definitions (e.g., prohibiting configurations that would allow information flows between certain “types” of partitions, subjects and exported resources) that are achievable through ad hoc configuration changes. The policy constraints are defined in the configuration data or in the TSF itself.

The additional assurance issue associated with this capability is to ensure that ad hoc policy change requests and change constraints are consistent with the organization's policy intents, including those for partitioning and in-formation flow. Additionally, the authorized subject that performs these changes must be trusted with respect to the TSF. Effectively, it is an extension of the TSF since it shares in the enforcement of policy.

• Full Dynamic Change: In addition to the capabilities and assurance issues of the Moderate Dynamic Change, a TOE Full Dynamic Change includes the following.

The TSF allows changes to any aspect of the configuration (e.g., an empty change constraint would have this af-fect).

The additional assurance issue associated with this capability is that, without any change constraints it may be difficult for the TOE vendor to provide a convincing definition of “secure transition” in the SFP model.

2.2.6. Trust Anchors

To provide guarantees of confidentiality and authentication, the PCS requires a mechanism for establishing trustwor-thy shared secrets and performing mutual authentication. This mechanism is often referred to as the system's "trust anchor". Example mechanisms which provide trust anchors include statically shared secrets, distributed webs of trust (the PGP model), and centralized Public Key Infrastructures (PKI) (the model for most secure email and web

23


identity schemes in use today). Because no single mechanism will be appropriate for all use cases, the choice of a trust anchor is unspecified in this protection profile. That choice is deferred to the authors of Security Targets. Fur-thermore, because each scheme has a unique set of threats and countermeasures, this Protection Profile does not attempt to address threats related to the choice of trust anchor. A Security Target claiming conformance with this Protection Profile must address the threats, policies, and assumptions derived from the use of that scheme.

Addressing the issues stemming from the choice of the trust anchor may be worthy of a protection profile in its own right. Certainly this is the case for PKI-based systems whose complex concerns (i.e. certificate revocation lists) are not unique to the PCS, but instead span any system which uses a PKI. Security Target authors should make an effort to use the appropriate high-robustness protection profile for their trust mechanism if such a profile exists. Use of an existing protection profile is desirable for the added confidence it provides.

2.3. Trusted Delivery The components of the TOE may be distributed in various ways, both for the initial delivery and for subsequent up-dates. This protection profile requires that the TOE include procedures and/or tools to verify that the on-site version of the TOE matches the master version (see “Trusted Delivery” in Figure 4, “PCS Trusted Delivery Scenario”). Such a verification tool may be configured to execute on the TOE (but not as part of the TSF) or on other hardware, but in either case the tool and the hardware that it runs on are evaluated as part of the TOE. Verification of the TOE and configuration data occur again as part of initialization. Figure 4, “PCS Trusted Delivery Scenario” shows how applications and TOE configuration data may be installed by the TOE developer and/or by various entities within the customer environment. However, the TOE as well as any separately delivered TOE components must be deliv-ered to the customer environment by means of trusted delivery. The end result is that the “user” will have a complete and verified TOE, with verified configuration data and installed applications. If TOE components were modified after trusted delivery, then the TOE would not be in an evaluated configuration.

Figure 4. PCS Trusted Delivery Scenario

2.4. Trusted Recovery The TOE cycles between one of three modes of operation: Halted, Operational, or Maintenance. Similarly, the TOE could be in either a secure state or an insecure state. Table 2 summarizes the possible mode/state combinations:

24


Table 2. Possible mode/state combinations

Secure Insecure

Operational X X

Maintenance X n/a

Halted X n/a

Figure 5, “TOE Recovery State Diagram” illustrates a generic recovery scenario involving these modes and states. A successful initialization brings the TOE to an operational secure state. For failures that require preservation of secure state, as specified by FPT_FLS.1, the TOE must remain in the operational secure state while handling the failures. Recovery may occur directly within the operational secure state, or indirectly via the (secure) maintenance mode. The implementation of the fail-secure mechanism is ST-specific.

For failures that do not require preservation of secure state under FPT_FLS.1, the TOE may temporarily enter an operational insecure state. That is, between the time that a security failure first occurs and the time that the TSF can detect it and respond, the conservative assumption is that the failure introduces insecurity. This insecure state is ephemeral because the TOE will return to the operational secure state if the failure is either directly recoverable, or indirectly recoverable via the (secure) maintenance mode.

In maintenance mode, some or all of the TSF interface functions (TSFIs) are unavailable. This restriction to a de-graded or a completely non-operational runtime functionality may enable the TSF to establish and maintain a secure state during the remaining recovery sequence. This protection profile does not require interaction with a trusted in-dividual to return from maintenance mode to secure operational mode, as some other protection profiles might (see Version 2.2 of the Common Criteria, Volume 2, paragraph 1238). The implementation of maintenance mode is ST-specific.

Figure 5. TOE Recovery State Diagram

25


2.5. Evaluation Considerations 2.5.1. Security Management

The TOE may be structured or configured to function within a larger system as an embedded or a non-embedded component. In the non-embedded TOE, authorized individuals are expected to monitor, maintain, or otherwise man-age the TOE. In the embedded TOE, it is possible that the TOE must be fully autonomous and all security manage-ment functions and decisions must be performed by the TOE without human intervention. From an evaluation standpoint, the key difference is the degree of autonomy with which the security management functions operate and the additional assurances required to achieve highly robust autonomous execution. This protection profile was de-veloped with the expectation that the TOE operates in an autonomous manner without authorized administrators who oversee its execution. As a result, there are no requirements for administrative roles, the identification and au-thentication of users and the allocation of administrative roles to security management functions. Should the TOE support administrative roles, those requirements must be added to the Security Target.

2.5.2. TOE Component Development Diversity

The TOE may include multiple hardware or software components that have been created by different developers. While this heterogeneous diversity is not a conceptual problem for evaluation, it may present constraints on the exe-cution of the evaluation process, such as the order of the evaluation of components. Even if different developers create the various components for a given TOE, each TOE component must be evaluated to the requirements of this protection profile as part of that TOE.

Similarly, the modular and component structure of each TOE instance may differ significantly. The TOE may con-sist of separate initialization and runtime components; separate hardware independent and hardware dependent com-ponents; as well as the cross product of these two dichotomies. This structure will be a critical factor in the TOE evaluation, especially with regard to whether a module or component is determined to be in the TSF, the TOE, or in the IT environment. Initialization components are not part of the TSF but are subject to evaluation scrutiny, whereas all other runtime components are part of the TSF.

This protection profile applies to both embedded and non-embedded TOEs, as well as homogeneously- and hetero-geneously-developed TOEs. However, it is outside of the scope of this protection profile to address how the evalua-tion process or methodology is affected by these differences. This protection profile takes a standard approach to address different or unique requirements for different TOE configurations, as follows:

• When possible, differences in the criteria are first addressed through use of the CC-defined operations of as-signment, selection, iteration, and refinement;

• In the cases where the CC-defined operations do not suffice, the CC-defined explicitly stated requirements model is used;

• Where there are differences in the implications of the criteria, those differences are addressed by the Application Notes that follow the criteria.

When the TOE is used in composition with other components or products to make up a larger system environment, it is the responsibility of the larger system's designers to articulate support for a coherent application-level security policy in the TOE configuration data, as well as to ensure that the configuration data itself is coherent and self-consistent. It is only with well-formed configuration data that the TOE can be expected to enforce mission critical policies. The judgment as to whether a given instantiation of configuration data is self-consistent, or well-formed with respect to the intended application-level security policy, is beyond the scope of this protection profile and be-yond the scope of the evaluation of the TOE.

26


2.6. General TOE Functionality A conformant TOE must include the following security features:

• Information flow control to enforce strict communications isolation with the exception of explicit interactions allowed via TSF (configuration) data

• Cryptographic services which provide mechanisms to protect the integrity of TSF code and data as it resides within the TOE and when it is transmitted to other trusted external components; and

• Initialization into a secure state and trusted recovery from a failure to a secure state

• Failure detection and response; and

• Generation of audit data in support of other middleware and application level audit services.

Among the requirements not levied in this PP are:

• User interfaces for operational mode, maintenance mode, or initialization;

• Identification and Authentication which mandates authorized users to be uniquely identified and authenticated by the TSF;

• Discretionary Access Control (DAC) which restricts access to objects based on the identity of subjects and/or groups to which they belong, and allows authorized users to specify protection for objects that they control;

• Cryptographic services for applications to encrypt, decrypt, hash, and digitally sign data as it resides within the system and is transmitted to other systems;

• Complete physical protection mechanisms, which must be provided by the environment.

2.7. Use of High Robustness A high robustness TOE is considered necessary protection for environments where the likelihood of an attempted compromise is high, and the value of the protected resources is high. This implies that the motivation of the threat agents will be high. Note that this also implies that the resources and expertise of the threat agents may be high, be-cause highly sophisticated threat agents may be motivated to use great expertise and extensive resources in an envi-ronment where high robustness is suitable.

An alternative perspective to thinking of the robustness level in terms of “likelihood of attempted compromise” is to consider the damage to the organization that would result if a TOE compromise were to occur. These two notions (likelihood of compromise and damage resulting from compromise) are parallel notions. They both are intrinsically linked to the value of the data being processed. The more valuable/sensitive the data, the greater the likelihood that an adversary will attempt to compromise the TOE, similarly the greater the damage to the organization that would result from such compromise.

27


3. TOE Security Environment This section defines the expected TOE security environment in terms of threats, security assumptions, and the secu-rity policies that must be followed for the high robustness TOE.

3.1. Threats to Security T.ADMIN_ERROR

An administrator may incorrectly install or configure the TOE (including the misapplication of the protections af-forded by the PIFP), or install a corrupted TOE resulting in ineffective security mechanisms.

T.ALTERED_DELIVERY

The TOE may be corrupted or otherwise modified during delivery such that the on-site version does not match the master distribution version.

T.CORRUPT_EXTERNAL

An agent may attempt to corrupt subject or TSF data while it is being transmitted between nodes.

T.COVERT_COMM_EXTERNAL

An agent may attempt to illicitly gain information by observing the presence or absence of messages transmitted over inter-node communication channels used by the TOE.

T.COVERT_COMM_INTERNAL

A subject may attempt to violate the TSP by communicating with another subject using an unintended communica-tions path.

T.CRYPTO_COMPROMISE

A subject may cause key, data or executable code associated with the cryptographic functionality to be inappropri-ately accessed (viewed, modified, or deleted), thus compromising the cryptographic mechanisms and the data pro-tected by those mechanisms.

T.EAVESDROP_EXTERNAL

An agent may attempt to view subject data in violation of the TSP by reading network data directly.

T.EAVESDROP_INTERNAL

A subject may attempt to illicitly access subject data by examining resources which have not been prepared for its use by the TOE.

T.INCORRECT_BOOT

The TSF implementation and TSF data are not correctly transferred into the TSF's execution domain.

T.INCORRECT_CONFIG

The TSF configuration data is not an accurate and complete reflection of the organizational security policy enforce-ment intentions with respect to information flow, and with respect to the intended runtime configuration of the TOE.

28


T.INCORRECT_LOAD

The TSF code and/or configuration data (e.g. trust anchors) are not correctly converted into a TSF-useable form.

T.INCORRECT_CORRUPTED

A subject may attempt to modify data communicated to another subject by modifying that data while it is within a SK partition belonging to the TOE.

T.INSECURE_STATE

The TOE may be placed in an insecure state as a result of erroneous initialization, erroneous reconfiguration or re-start, or as a result of an unsuccessful recovery from a system failure or discontinuity.

T.INVALID_REQUEST

A subject or agent may attempt to cause the TOE to corrupt itself or subject data under its control by passing syntac-tically or semantically invalid requests to the TOE.

T.MASQUERADE

A subject or agent may attempt to masquerade as another subject by presenting invalid data to TOE interfaces, threatening subject data.

T.POOR_DESIGN

Unintentional or intentional errors in requirements specification or design of the TOE may occur, leading to flaws that may be exploited by a subject.

T.POOR_IMPLEMENTATION

Unintentional or intentional errors in implementation of the TOE design may occur, leading to flaws that may be exploited by a subject.

T.POOR_TEST

Lack of or insufficient evaluation and runtime tests to demonstrate that all TOE security functions operate correctly (including in a fielded TOE) may result in incorrect TOE behavior being discovered.

T.RESIDUAL_DATA

A subject may gain unauthorized access to data through reallocation of TOE resources from one subject to another.

T.RESOURCE_EXHAUSTION

A subject may block others from resources via a resource exhaustion attack.

T.TSF_COMPROMISE

A subject may cause TSF data or executable code to be inappropriately accessed (viewed, modified, or deleted).

T.UNAUTHORIZED_ACCESS

A subject may gain access to resources or services for which it is not authorized according to the TOE security pol-icy.

29


T.UNSANITIZED

A subject may attempt to gain unauthorized information from an improperly sanitized or incompletely initialized shared resource.

T.WRONG_COMM

A subject may attempt to send information to a subject or agent it is not authorized to communicate with.

3.2. Security Policy The following organizational security policies are addressed by PP compliant TOEs:

P.ACCOUNTABILITY

The TOE shall provide the capability to make available information regarding the occurrence of security relevant events.

P.CRYPTOGRAPHY

The TOE shall use NIST FIPS validated cryptography as a baseline with additional NSA-approved methods for key management (i.e., generation, access, distribution, destruction, handling, and storage of keys) and for cryptographic operations (i.e., encryption, decryption, signature, hashing, key exchange, and random number generation services).

P.DAMAGE_ASSESMENT

The TOE shall support damage assessment following a failure by generating audit information for storage by a sys-tem logging component.

P.DAMAGE_LIMITATION

The TOE shall limit fault propagation either by detecting and responding to errors or as a byproduct of its regular operation.

P.DOCUMENTED_PROCESS

All processes related to the life cycle of the TOE shall be documented, and the documented processes shall be fol-lowed.

P.INDEPENDENT_TESTING

The TOE must undergo independent testing.

P.INFO_FLOW

The TOE shall ensure that only those information flows explicitly authorized by the TSP may occur.

P.LEAST_PRIVILEGE

The TOE shall be designed such that the principle of least privilege is applied to limit the damage that can result from accident, error, or unauthorized use.

P.RATINGS_MAINTENANCE

A plan for procedures and processes to maintain the TOE's rating must be in place to maintain the TOE's rating once it is evaluated.

30


P.SELECT_POLICY

The TOE shall provide the capability to select the set of configuration data to be used upon startup, restart, or recon-figuration of the TOE.

The TOE shall ensure that for each initialization of the TOE, the runtime configuration of the TOE is consistent with the intent defined by the configuration data.

P.SYSTEM_INTEGRITY

The TOE shall provide the ability to periodically validate its correct operation.

P.USER_GUIDANCE

The TOE shall provide documentation regarding the correct use of the TOE security features.

P.VULNERABILITY_ANALYSIS_AND_TEST

The TOE must undergo independent vulnerability analysis and penetration testing by NSA to demonstrate that the TOE is resistant to an attacker possessing a high attack potential.

3.3. Security Usage Assumptions The specific conditions below are assumed to exist in a PP-compliant TOE environment:

A.CHANNELS

It is assumed that the applications executing on the same node as the TOE are trusted with assurance commensurate with the value of the IT assets protected by the TOE to address any residual risks associated with covert channels in the TOE.

A.NO_BYPASS

It is assumed that the configuration of the underlying separation kernel prevents subjects from communicating with subjects on other nodes without invoking the TOE.

A.PHYSICAL_PROTECTION

It is assumed that the non-IT environment provides the TOE with appropriate physical security commensurate with the value of the IT assets protected by the TOE.

A.REAL-TIME_KERNEL

It is assumed that the TOE runs under the control of an operating system that supports predictable worst-case bounds (real-time) processor scheduling.

A.SEPARATION_KERNEL

It is assumed that the TOE runs under the control of a trustworthy operating system that meets the requirements de-scribed by the U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robust-ness .

A.TRUSTED_CODE_LOAD

It is assumed that the separation kernel will correctly load the TOE's code and static data (e.g. trust anchors) into the correct partition(s), or inform the TOE if unrecoverable errors prevent correct loading.

31


A.TRUSTED_FLOWS

If a subject is allowed by the configuration data to cause information flow, it is assumed that the subject is trusted with assurance commensurate with the value of the IT assets to which it has access.

A.TRUSTWORTHY_ADMIN

It is assumed that any individual allowed to perform procedures upon which the security of the TOE may depend is both capable and trusted with assurance commensurate with the value of the IT assets.

32


4. Security Objectives This section defines the security objectives for the TOE and its environment. These objectives are suitable to counter all identified threats and cover all identified organizational security policies and assumptions. The security objec-tives allocated to the TOE are identified with “O.” preceding the name of the objective. The security objectives allo-cated to the environment are identified with “OE.” preceding the name of the objective.

4.1. TOE Security Objectives O.ACCESS

The TOE will ensure that subjects gain only authorized access to the resources that it controls.

O.ADMIN_GUIDANCE

The TOE will provide administrators with the necessary information for secure management of the TOE.

O.AUDIT_GENERATION

The TOE will provide the capability to detect and generate audit records for security relevant auditable events.

O.CHANGE_MANAGEMENT

The configuration of, and all changes to, the TOE and its development evidence will be analyzed, tracked, and con-trolled throughout the TOE's development.

O.CORRECT_CONFIG

The TOE will provide procedures and mechanisms to generate the TSF configuration data such that the TSF con-figuration data accurately reflects the organizational security policy enforcement intentions regarding information flow and the runtime configuration of the TOE.

O.CORRECT_LOAD

The TOE will provide procedures and mechanisms to correctly convert the TSF code and/or configuration data into a TSF-useable form.

O.CORRECT_TSF_OPERATION

The TOE will provide a capability to test the TSF to verify the correct operation of the TSF during all operational states and modes.

O.CONFIG_VALIDATION

The TOE shall verify that all systems have internally consistent configuration data, and that all communicating sys-tems have compatible versions of their configuration data before performing any inter-node communications in re-sponse to a request by a subject.

O.CONNECTIVITY_ENFORCEMENT

The TOE shall enforce the channel connectivity TSP specified in its configuration data.

O.COVERT_CHANNEL_ANALYSIS

The TOE will undergo appropriate covert channel analysis by NSA to demonstrate that the TOE either eliminates covert channels or satisfies covert channel mitigation metrics.

33


O.CRYPTOGRAPHIC_PROTECTION

The TOE will support separation of the cryptography from the rest of the TSF.

O.DEVELOPMENT_CONFIG_MGT

Every delivered version of the TOE, and its evaluation evidence shall be uniquely identified and all changes to these items and their development environments shall be documented, tracked and controlled.

O.DOCUMENTED_PROCESS

All processes related to the life cycle of the TOE shall be documented, and the documented processes shall be fol-lowed.

O.FAIL_SECURE

The TOE shall ensure that violations of the channel connectivity or resource management SFP's do not occur due to detectable failures.

O.FUNCTIONAL_TESTING

The TOE will undergo independent security functional testing that demonstrates the TSF satisfies the security func-tional requirements.

O.IDENTIFIED_PEER

The TOE shall verify the identity of a subject or node before applying any TSP which is conditional upon subject or node identity.

O.INSTALL_GUIDANCE

The TOE will be delivered with the appropriate installation guidance to establish and maintain TOE security.

O.INTERNAL_LEAST_PRIVILEGE

The TOE will be structured to achieve the principle of least privilege among TSF modules.

O.MANAGE

The TOE will provide all the functions necessary to support the administrative users and authorized subjects in their management of the TOE configuration and configuration data, and restrict these functions from use by unauthorized subjects.

O.NO_REPLAY

The TOE shall detect and discard any message which is captured from an inter-node communications channel and replayed to the TOE.

O.PROTECT

The TOE will provide mechanisms to protect services and exported resources.

O.RATINGS_MAINTENANCE

Procedures and processes to maintain the TOE's rating will be documented.

34


O.RECOVERY

The TOE will provide procedures and/or mechanisms that can be used in the event of failure, faults, or discontinuity, to recover and transition the TSF to a secure state without protection compromise.

O.REFERENCE_MONITOR

The TOE will maintain a domain for its own execution that protects itself and its resources from external interfer-ence, tampering, or unauthorized disclosure.

O.REQUEST_VALIDATE

The TOE shall validate all requests to ensure that requests are semantically valid and will not cause the TOE to cor-rupt itself or violate the TSP.

O.RESOURCE_MANAGEMENT

The TOE shall enforce the resource management SFP by:

• Enforcing resource usage quotas specified by the SFP

• Preventing the use of one logical channel from influencing the observable behavior of another logical channel when those channels are required to be separated by the SFP

O.SECURE_STATE

The TOE will provide mechanisms to transition the TSF to a secure state without protection compromise during start-up, restart or reconfiguration.

O.SOUND_DESIGN

The TOE will be designed using sound design principles and techniques. The TOE design, design principles and design techniques will be adequately and accurately documented.

O.SOUND_IMPLEMENTATION

The implementation of the TOE shall be an accurate instantiation of its design.

O.TESTING

The TOE shall undergo rigorous and independent testing based at least in part on an independent vulnerability analysis.

O.TRANSMISSION_CONFIDENTIALITY

The TOE shall ensure that confidentiality is maintained for data transmitted between nodes.

O.TRANSMISSION_INTEGRITY

The TOE shall verify the integrity of

• all user data

• all TSF data whose integrity is necessary for the enforcement of the TSPs

when that data is transmitted between nodes.

35


O.TRANSMISSION_UNOBSERVABLE

The TOE shall prevent the presence or absence of communication between two subjects from being observable to agents having the ability to examine inter-node communications.

O.TRUSTED_DELIVERY

The integrity of the implementation of the TOE shall be protected during the initial distribution and subsequent up-dates, and verified to ensure that the on-site copy of the implementation is identical to the master distribution ver-sion.

O.TSF_INTEGRITY

The TOE will be able to verify the integrity of the TSF code and data.

O.USER_GUIDANCE

The TOE will provide users with the necessary information for secure use of the TOE.

O.VULNERABILITY_ANALYSIS_TEST

The TOE will undergo independent vulnerability analysis and penetration testing by NSA to demonstrate the design and implementation of the TOE does not allow attackers with high attack potential to violate the TOE's security policies.

4.2. Environment Security Objectives OE.COVERT_CHANNELS

Applications executing on the same node as the TOE will be trusted with assurance commensurate with the value of the IT assets protected by the TOE should there be concerns regarding the residual risk associated with covert chan-nels.

OE.NO_BYPASS

The configuration of the underlying separation kernel prevents subjects from communicating with subjects or agents on separate nodes without invoking the TOE.

OE.PHYSICAL

Physical security will be provided for the TOE by the non-IT environment commensurate with the value of the IT assets protected by the TOE.

OE.REAL-TIME_KERNEL

The TOE runs under the control of an operating system that supports predictable worst-case bounds (real-time) processor scheduling.

OE.SEPARATION_KERNEL

The TOE runs under the control of a trustworthy operating system that meets the requirements described by the U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness.

OE.TRUSTED_CODE_LOAD

The separation kernel will correctly load the TOE's code and static data (e.g. trust anchors) into the correct parti-tion(s), or inform the TOE if unrecoverable errors prevent correct loading.

36


OE.TRUSTED_FLOWS

If a subject is allowed by the configuration data to cause information flow, that subject must be trusted with assur-ance commensurate with the value of the IT assets to which it has access.

OE.TRUSTED_INDIVIDUAL

Any individual allowed to perform procedures upon which the security of the TOE may depend must be trusted with assurance commensurate with the value of the IT assets.

37


5. TOE Security Functional Requirements This section contains the requirements for the TOE trusted security functions (TSF). The requirements are applied against the TOE in conjunction with the underlying hardware that supports it. The requirements contained in this section are either selected from Part 2 of the CC or are explicitly stated in accordance with the CC rules for explic-itly stated requirements (refer to CC Part III APE_SRE). Table 3 lists the explicitly stated functional requirements in this section.

Table 3. Explicitly Stated Functional Requirements

Explicit Component Component Behavior Name

placeholder placeholder

5.1. Security audit (FAU) 5.1.1. Security Audit Automatic Response (FAU_ARP)

5.1.1.1. Security Alarms (FAU_ARP.1)

FAU_ARP.1.1

Refinement: The TSF shall take [assignment: list of the actions to take] upon detection of any failure of the TSF self-tests.1

Application Note:

The TSF must take some action. The ST author is to fill in the open assignment with the list of actions that are avail-able for the TOE's intended use, with particular attention to providing the ability for the TOE to support system-level requirements for fault/failure detection and response. Acceptable actions include a means to notify the IT envi-ronment or explicit action taken by the TSF (e.g., shutdown, reconfiguration).

5.1.2. Security audit data generation (FAU_GEN)

5.1.2.1. Security Audit Data Generation (FAU_GEN.1)

FAU_GEN.1.1-NIAP-0410

The TSF shall be able to generate an audit record of the following auditable events:

a. Start-up and shutdown of the audit functions;

b. All auditable events listed in Table 4, “Auditable Events”.

c. [selection: [assignment: events at a basic level of audit introduced by the inclusion of additional SFRs], [assignment: events commensurate with a basic level of audit introduced by the inclusion of explicit re-quirements], no additional events].

Application Note:

For the first assignment in the selection, the ST author augments the table (or lists explicitly) the audit events asso-ciated with the basic level of audit for any SFRs that the ST author includes in the ST that are not included in this PP.

38


Likewise, for the second assignment the ST author includes audit events that may arise due to the inclusion of any explicit requirements in the ST that are not already in the PP. Because “basic” audit is not defined for such re-quirements, the ST author will need to determine a set of events that are commensurate with the type of information that is captured at the basic level for similar requirements.

It is acceptable for the ST author to choose “no additional events”, if the ST author has not included additional re-quirements, or has included additional requirements that do not have a basic level (or commensurate level) of audit associated with them. In determining whether or not added functionality should have auditable events, the ST author is to assess the added functionality in terms of its conceptual relationship with the core functionality expressed in this PP and their corresponding requirements for auditable events. As an example: FAU_SEL.1 requires that the set of auditable events be statically determined prior to execution of the TSF and that the set of auditable events are not modifiable during runtime. Sine there is no capability to modify the audit behavior at runtime, there is no require-ment to audit changes to the runtime behavior. However, should the ST author provide the capability for authorized subjects to modify the behavior of the audit mechanism during runtime, then any such runtime modification consti-tutes an auditable event.

Application Note:

In regard to the requirement for generating an “audit record”: the TSF is required to provide the audit information in a defined form that allows interpretation by some review process not implemented as part of the TOE. This audit information structure is what is referred to in the requirement as the “audit record.” The structuring of audit re-cords is to be documented in the administrative guidance. The TSF is expected to identify each auditable event and to capture data that characterizes each auditable event as defined in Table 4. The TSF is not required to notify the IT environment of the existence of the audit data and the TSF is not required to “push” the information to the IT environment.

Application Note:

It is common that for the purposes of engineering analysis, embedded system components record operational and health and status data to support post-operational analysis and debugging. This data is referred to as instrumenta-tion. This data is not necessarily security relevant, that is, not associated with enforcement of the security policy by the TSF. The audit data generation requirements in this PP should not be confused with instrumentation require-ments levied by applications.

Table 4. Auditable Events

Security Functional Requirement Audit events prompted by requirement

Security Alarms (FAU_ARP.1) • Actions taken due to failure of TSF self tests

Audit Data Generation (FAU_GEN.1) (None)

Selective Audit (FAU_SEL.1) (None)

Cryptographic key generation (FCS_CKM.4) (None)

Cryptographic operation (FCS_COP.1) (None)

Complete Information Flow Control (for Information Flow Control Policy)

(None)

39


Security Functional Requirement Audit events prompted by requirement (FDP_IFC.2(1))

Complete Information Flow Control (for Information Flow Control Policy) (FDP_IFC.2(2))

(None)

Simple Security Attributes (FDP_IFF.1)

• Establishment of connections between subjects • The loss of a connection between subjects (either due to intentional

closing, destruction, fault, or failure)

Application Note:

The TSF is not required to audit each instance of an information flow between subjects. The TSF is required to provide the capability to audit the establishment and destruction of each connection between subjects.

Partial Elimination of illicit Information Flows (FDP_IFF.4) • The use of identified illicit information flow channels

Transmission separation by attribute (FDP_ITT.2) (None)

Integrity Monitoring (FDP_ITT.3) • Detection of a user data integrity error

Full Residual Information Protection (FDP_RIP_EXP.2) (None)

User identification before any action (FIA_UID.2) • Failure of a user to present valid identification

Explicit: Management of Security At-tributes (FMT_MSA_EXP.1) (None)

Explicit: Management of TSF Data (for Modification of Flow Policy Configura-tion Data) (FMT_MTD_EXP.1)

(None)

Secure TSF Data (FMT_MTD.3) • All rejected values of TSF data

Unobservability (FPR_UNO.1) (None)

Fail Secure (FPT_FLS.1) • Failures detected by the FMT_TST.1 tests

Explicit: Inter-TSF Detection of Modifi- • The detection of modification of transmitted TSF data

40


Security Functional Requirement Audit events prompted by requirement cation (FPT_ITI_EXP.1) • The action taken upon detection of modification of transmitted TSF

data

TSF Data integrity monitoring (FPT_ITT.3) • Detection of a TSF data integrity error

Automated Recovery (FPT_RCV.2) • The fact that a failure or service discontinuity occurred • Resumption of the regular option • Type of failure or service discontinuity

Function Recovery (FPT_RCV.4) • If possible, the impossibility to return to a secure state after failure of

a security function • If possible, the detection of a failure of a security function

Syntactic and semantic validation of re-quests (FPT_RVD_EXP.1) • Detection of syntactically or semantically invalid requests

Replay detection (FPT_RPL.1) • Detection of replayed user data • Detection of replayed TSF data

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

TSF domain separation (FPT_SEP.3) (None)

Mutual trusted acknowledgement (FPT_SSP.2)

• Failure to receive a requested acknowledgement from another por-tion of the TSF

Reliable time stamps (FPT_STM.1) (None)

Explicit: TSF Testing (FPT_TST_EXP.1) • Failures of TSF self tests and the results of the tests

Explicit: Maximum Quotas (for System Memory) (FRU_RSA.1(1))

• Attempt to consume memory in excess of the quota limit • Rejection of allocation operation due to system memory limits

Explicit: Maximum Quotas (for Process-ing Time) (FRU_RSA.1(2))

• Attempt to consume processing time in excess of the quota limit • Rejection of allocation operation due to processing time limits

41


Application Note:

The use of the word “None” in Table 4, “Auditable Events” means that there are no requirements for auditing events associated with the functions/mechanisms that implement the stated Security Functional Requirement.

FAU_GEN.1.2-NIAP-0410

The TSF shall record within each audit record at least the following information:

a. Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and

b. For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST,

• the identity of the resource;

Application Note:

It is acceptable for the TSF to provide a timestamp that reflects the date and time of the event as a relative time within the TOE. This is acceptable so long as the IT environment is able to correlate that timestamp to date and time of day and the IT environment is able to establish event sequences based upon timestamp values. The administrative documentation should discuss the structure of the timestamp and how it is properly interpreted.

Application Note:

Audit information associated with security functions that are included in the ST but are note included in this PP should be contained within the audit record.

5.1.3. Security audit event selection (FAU_SEL)

5.1.3.1. Selective Audit (FAU_SEL.1)

FAU_SEL.1.1

The TSF shall be able to include or exclude auditable events from the set of audited events based on the following attributes:

• resource identity,

• subject identity,

• event type,

• success of auditable security events

• failure of auditable security events

• [selection: [assignment: list of additional attributes specific to the audit capabilities of the implemen-tation], no additional attributes].

Application Note:

The following clarification is provided in regards to the use of the words “audited” and “auditable” above. As used above “auditable events” refers to the totality of events that the TSF is capable of auditing at runtime. The set of “audited events” should be read as the “set of all events to be audited” and refers to the subset of auditable events for which the TSF will generate an audit event should the indicated event occur during runtime. The TSF is not re-

42


quired to provide a run-time capability for management of the audit function behavior. It is acceptable for the TSF to provide the means for the audit function behavior to be specified by the configuration data, and for that behavior to remain in effect and unchanged until such time that the TOE is initialized with a different set of audit configura-tion data.

5.2. Cryptographic support (FCS) 5.2.1. Cryptographic key management (FCS_CKM)

5.2.1.1. Cryptographic Key Generation (FCS_CKM.1)

FCS_CKM.1.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: crypto-graphic key sizes] that meet the following: requirements from FIPS pub 140-2 [fips140-2]

5.2.1.2. Cryptographic Key Distribution (FCS_CKM.2)

FCS_CKM.2.1

The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [assignment: cryptographic key distribution method] that meets the following: requirements from FIPS pub 140-2 [fips140-2]

5.2.1.3. Cryptographic Key Destruction (FCS_CKM.4)

FCS_CKM.4.1

The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [as-signment: cryptographic key destruction method] that meets the following: requirements from FIPS pub 140-2 [fips140-2]

5.2.2. Cryptographic operation (FCS_COP)

5.2.2.1. Cryptographic Operation (FCS_COP.1)

FCS_COP.1.1

The TSF shall perform encryption, decryption, authentication, and integrity verification in accordance with a speci-fied cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [assignment: cryp-tographic key sizes] that meet the following: requirements from FIPS pub 140-2 [fips140-2].

5.3. User data protection (FDP) 5.3.1. Information flow control policy (FDP_IFC)

5.3.1.1. Complete Information Flow Control Complete information flow control (FDP_IFC.2)

FDP_IFC.2.1(1)

The TSF shall enforce the channel connectivity SFP defined by the TOE's configuration data on all inter-subject communications performed by the TOE and all operations that cause that information to flow to and from subjects covered by the SFP.

43


FDP_IFC.2.1(2)

The TSF shall enforce the resource management SFP defined by the TOE's configuration data on all inter-subject communications performed by the TOE and all operations that cause that information to flow to and from subjects covered by the SFP.

FDP_IFC.2.2

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.

5.3.2. Information flow control functions (FDP_IFF)

5.3.2.1. Simple Security Attributes (FDP_IFF.1)

FDP_IFF.1.1-NIAP-0407

The TSF shall enforce the Partitioned Information Flow SFP based on the flow(s) invoked by a controlled opera-tion, and the following types of subject and exported resource security attributes associated with the controlled op-eration:

• The identity of the subject invoking the flow of information

• The identity of the node to which the subject is assigned

• The identity of the exported resource involved in the flow of information

• The identity of the node to which the exported resource is assigned


The TSF shall permit a controlled operation if, for each flow associated with the controlled operation, the following rules hold: the identity of the subject has been verified, the information flow is compliant with channel connectivity SFP , the information flow is compliant with the resource management SFP .


Refinement: The TSF shall enforce the following separation rule: If a controlled operation results in a flow not explicitly authorized by the configuration data per the rules defined in FDP_IFF.1.2, then deny the operation.


The TSF shall provide no additional capabilities


The TSF shall explicitly authorize an information flow based on the following rules: no explicit authorization rules.


The TSF shall explicitly deny an information flow based on the following rules: no explicit denial rules.

5.3.2.2. Partial Elimination of Illicit Information Flows (FDP_IFF.4)

FDP_IFF.4.1

The TSF shall enforce the Partitioned Information Flow SFP defined by the TOE's configuration data to limit the capacity of [assignment: covert timing channels between subjects] to a [assignment: maximum capacity].

44


FDP_IFF.4.2

The TSF shall prevent illicit information flows that may be present due to: shared use of communication resources by multiple subjects, acknowledgment of messages sent via permitted one-way connections.

5.3.3. Internal TOE transfer (FDP_ITT)

5.3.3.1. Transmission Separation by Attribute (FDP_ITT.2)

FDP_ITT.2.1

The TSF shall enforce the channel connectivity and resource management policies specified in the TOE's configura-tion data to prevent the disclosure of user data when it is transmitted between physically-separated parts of the TOE.

FDP_ITT.2.2

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: channel connectivity and resource management policy attributes stored in configuration data.

5.3.3.2. Integrity Monitoring (FDP_ITT.3)

FDP_ITT.3.1

The TSF shall enforce the channel connectivity and resource management SFP's to monitor user data transmitted between physically-separated parts of the TOE for the following errors: any changes to transmitted data.

FDP_ITT.3.2

Upon detectIon of a data integrity error, the TSF shall prevent the delivery of the data.

5.3.4. Residual information protection (FDP_RIP)

5.3.4.1. Full Residual Information Protection (FDP_RIP.2)

FDP_RIP.2.1

The TSF shall ensure that any previous information content of a resource is made unavailable upon the [selection: allocation of the resource , deallocation of the resource]

Application Note:

This requirement applies to all TOE resources - those internal to the TSF as well as those exported by the TSF.

5.4. Identification and authentication (FIA) 5.4.1. User attribute definition (FIA_ATD)

5.4.1.1. Explicit: Subject and Exported Resource Attribute Definition (FIA_ATD_EXP.1)

FIA_ATD_EXP.1.1

For each subject, the TSF configuration data shall include the following list of security attributes:

• Identity of the subject

• Identity of the node or partition to which the subject is bound

45


• Subject authorizations

• Information flow authorizations

• [assignment: list of additional subject security attributes]

FIA_ATD_EXP.1.2

For each non-subject exported resource, the TSF configuration data shall include the following list of security attrib-utes:

• Identity of the exported resource

• Identity of the node or partition to which the exported resource is bound

• [assignment: list of additional exported resource security attributes]

Application Note:

The configuration data fulfills the function that is typically performed by an individual authorized to define users and to grant authorization to users for interaction with exported resources.

5.4.1.2. Explicit: Subject and Resource Attribute Binding (FIA_USB_EXP.1)

FIA_USB_EXP.1.1

Upon initialization or reconfiguration of the TOE, the TSF shall associate the internal representation of all security attributes defined for each subject with that subject as specified in the configuration data.

FIA_USB_EXP.1.2

Upon initialization or reconfiguration of the TOE, the TSF shall associate the internal representation of all security attributes defined for each non-subject exported resource with that non-subject exported resource as specified in the configuration data.

Application Note:

The concept of user-subject binding applies to the TOE in the sense that the TSF is required to perform the binding of resource attributes defined in the configuration data to the internal representation of those attributes for each subject and non-subject exported resource when they are created during TOE initialization.

5.5. Security Management (FMT) Application Note:

This PP addresses security management of the TOE with the assumption that the TOE is an embedded component with no capability for direct interaction between authorized individuals and the TSF during runtime. As a result, this profile does not define security management roles, I&A of individuals, and the association of authenticated users to security management roles.

This profile requires that the TOE must, by design, provide inherent support for the various type of security man-agement functions that are typically performed by authorized individuals (e.g., trusted initialization, definition of initialization parameters, policy definition and enforcement attributes governing subject/resource interaction, TSF function behavior, fault detection and response, trusted recovery, and TOE reconfiguration). This profile expects that the combination of off-line TOE tools and procedures and TSF functionality will serve to implement the totality of the required security management functions.

46


Application Note:

The security management components contained in this profile define the minimal set of required capability, consis-tent with terms defined in the Glossary and discussion of the TOE found in Section 2, “Target of Evaluation (TOE) Description”. In this regard, the profile requires that the TOE provides capabilities for a set of static configuration definitions to be generated; requires the TOE to initialize into a secure state based upon one of those static configu-ration definition sets; requires that authorized subjects are able to invoke a change from the current configuration to a new configuration, and requires that the Partitioned Information Flow SFP enforcement attributes be defined completely by each instance of configuration data. The management functions associated with these capabilities are found in this section.

Application Note:

This profile allows the TOE developer to provide a minimal dynamic reconfiguration change capability in addition to the required static configuration change capability. Should the TOE developer wish to implement greater dy-namicity in the reconfiguration capability, then it is their responsibility to express those detailed requirements of that capability in the Security Target. The Security Target must address both the functional requirements for the dynamic configuration change capability as well any residual requirement to ensure that the reconfiguration capa-bility is consistent with the objectives of this profile and does in fact satisfy them.

5.5.1. Management of Security Functions Behavior (FMT_MOF)

5.5.1.1. Refined: Management of Security Functions (FMT_MOF.1)

FMT_MOF_EXP.1.1;1

The TSF shall restrict the ability to invoke a reconfiguration of the TOE to authorized subjects.

FMT_MOF_EXP.1.1;2

The TSF shall restrict the ability to initiate TSF self-test to authorized subjects.

FMT_MOF_EXP.1.1;3

The TSF shall restrict the ability to verify the results of TSF self test to authorized subjects.

Application Note:

The configuration data alone provides the designation of those subject with authorization to invoke a reconfigura-tion of the TOE, those subjects with authorization to initiate TSF self-tests, and those subjects with authorization to verify the results of TSF self tests.

5.5.2. Management of Security Attributes (FMT_MSA)

5.5.2.1. Explicit: Management of Security Attributes (FMT_MSA_EXP.1)

FMT_MSA_EXP.1.1

The TSF shall assign the following authorizations: ability to invoke a TOE reconfiguration, ability to invoke TSF self-tests, ability to verify results of TSF self-tests, [assignment: list of additional authorizations that may be as-signed to subjects] to subject as specified by the configuration data.

FMT_MSA_EXP.1.2

The TSF shall only assign authorization to subjects as specified by the configuration data.

47


Application Note:

FPT_TST allows authorized subject to invoke and verify the TSF self-tests. Should that capability be implemented, this requirement support designation of those subjects authorized to perform those functions.

5.5.2.2. Static Policy Attribute Initialization (FMT_MSA.3)

FMT_MSA.3.1

The TSF shall enforce the Partitioned Information Flow SFP to provide restrictive default values for security attrib-utes that are used to enforce the SFP.

FMT_MSA.3.2

The TSF shall allow only the configuration data to specify alternative values to override the default restrictive val-ues.

Application Note:

“Default restrictive values” means that there can be no default authorized information flows.

Application Note:

This requirement applies to the creation of subject and exported resources that occurs during the initialization of the TOE (to include initialization as a cold start, as part of a reconfiguration, or as part of a trusted recovery).

5.5.3. Management of TSF Data (FMT-MTD)

5.5.3.1. Explicit: Management of TSF Data (for Modification of Flow Policy Configuration Data) (FMT_MTD_EXP.1)

FMT_MTD_EXP.1.1

The TSF shall maintain TOE configuration data.

FMT_MTD_EXP.1.2

The TSF shall prevent modification of the TOE configuration data.

Application Note:

The TOE is required to maintain configuration data consistent with its capability to reconfigure. The configuration data defines the TOE configuration and the initial secure state of the TOE. It must be protected from modification to preserve the integrity of the TOE secure state upon a shutodwn and restart of the TOE into the same configuration or some other configuration.

5.5.3.2. Secure TSF Data (FMT_MTD.3)

FMT_MTD.3.1

Refinement: The TSF shall ensure that only valid values are accepted for TSF data.

Application Note:

Valid implies that the values fall within the defined range for the TSF data (e.g., an audit enable/disable indicator must be within range of a Boolean type).

48


5.6. Privacy (FPR) 5.6.1. Unobservability (FPR_UNO)

5.6.1.1. Unobservability (FPR_UNO.1)

FPR_UNO.1.1

The TSF shall ensure that subjects or agents not party to a communication are unable to observe the operation of communications activity on behalf of or by participating subjects .

5.7. Protection of the TSF (FPT) 5.7.1. Explicit: Configuration Change (FPT_CFG)

5.7.1.1. Explicit:" Configuration Change (FPT_CFG_EXP.1)

FPT_CFG_EXP.1.1

When requested by an authorized subject, the TSF shall initiate a change in TOE configuration.

FPT_CFG_EXP.1.2

The TSF shall provide a static configuration change capability and [selection: minimal dynamic configuration change capability, other than minimal dynamic configuration change capability, no other configuration change ca-pability].

FPT_CFG_EXP.1.3

The TSF static configuration capability shall halt the TOE prior to establishing the TOE in the new configuration defined by one of the configuration data sets.

FPT_CFG_EXP.1.4

The TSF minimal dynamic change capability shall establish the TOE in the new configuration as defined by one of the configuration data sets.

FPT_CFG_EXP.1.5

The TSF other than minimal dynamic change capability shall enforce the following rules when establishing the TOE in a new configuration [assignment: rules defining the degree of dynamicity of configuration change to include the rules for initiating the change in configuration].

FPT_CFG_EXP.1.6

The TSF shall preserve secure state during any change of TOE configuration.

Application Note:

Refer to Section 2, “Target of Evaluation (TOE) Description” for discussion of configuration change definitions and options for implementation.

Application Note:

The TOE is required to be capable of performing a static configuration change when switching from one configura-tion to another. As an option, the minimal dynamic configuration change capability may be implemented. It differs

49


from the static change capability only in the sense that the TOE is not required to be halted when switching between configuration data sets.

Application Note:

More dynamic “other than minimal” dynamic configuration change capabilities are allowed so long as the associ-ated controls are implemented and associated assurances are provided that the configuration change preserves a secure state. The Security Target must fully address the functional requirements and assurances associated with such a dynamic implementation of TOE configuration change. It is beyond the scope of this Protection Profile to provide a “worked example.” The intent of this profile is to allow such dynamicity of configuration change so long as the core security properties of the TOE (as expressed by the Security Objectives) are continuously met.

Application Note:

For the static and minimal dynamic configuration change capability, it is acceptable for an authorized subject to request the TSF to reconfigure into the same configuration (i.e., the new configuration is the same configuration that the TOE is currently in).

5.7.2. Establishment of Secure State (FPT_ESS_EXP)

5.7.2.1. Explicit: Establishment of Secure State (FPT_ESS_EXP.1)

FPT_ESS_EXP.1.1

The TSF shall be established in a secure state as defined by the selected configuration data set.

FPT_ESS_EXP.1.2

The TSF shall enforce the Partitioned Information Flow Policy (PIFP) as specified by the selected configuration data set.

FPT_ESS_EXP.1.3

The TSF shall determine that it is in a secure state upon completion of the TOE initialization function and prior to authorizing any information flows governed by the Partitioned Information Flow Policy (PIFP).

Application Note:

FPT_ESS_EXP.1.1 expresses the requirement that the TOE be established in a secure state - which is not a function of the TSF but is still a function levied on the TOE. There are assurance criteria that supports the need for a trusted initialization capability.

Application Note:

FPT_ESS.EXP.1.2 expresses the requirement for the TSF to use the configuration data to establish the rules for PIFP enforcement. Note that the FDP_IFC/IFF requirements address only the existence of that function, and not how it is configured to enforce policy.

Application Note:

FPT_ESS.EXP.1.3 expresses the need for the TSF to verify that the TOE is in a secure state prior to allowing any information flows to occur.

50


5.7.3. Fail secure (FPT_FLS)

5.7.3.1. Failure with Preservation of Secure State (FPT_FLS.1)

FPT_FLS.1.1

The TSF shall preserve a secure state when the following types of failures occur: [assignment: list of types of fail-ures that are detected by tests defined in FPT_TST.1 and to which the TOE can respond and preserve a secure op-erational state].

Application Note:

Preservation of secure state means that the TSF is able to detect and transition into an operational insecure state during which the TSP may or may not still be enforced, and then to recover into a secure state where the TSP is en-forced.

Application Note:

The ST author is to provide the list of failures that can be detected and to which the TSF can respond and preserve a secure operational state.

Application Note:

TSF failure modes vary and may include “hard” failures such as those associated with hardware or unrecoverable software failures, and “soft” failures such as intermittent hardware errors and recoverable software errors. The TSF is not expected to protect itself against all types of hardware errors. For example, a radiation induced change of a single bit in a memory access control register could result in an incorrect (but valid) memory location being accessed. This would not always be detected by the hardware.

5.7.4. Internal TOE TSF data transfer (FPT_ITT)

5.7.4.1. TSF data integrity monitoring (FPT_ITT.3)

FPT_ITT.3.1

The TSF shall be able to detect modification of data, substitution of data, deletion of data, [assignment: or other in-tegrity errors] for TSF data transmitted between separate parts of the TOE.

FPT_ITT.3.2

Upon detection of a data integrity error, the TSF shall take the following actions: prevent the data from being used by the TSF.

5.7.5. Trusted Recovery (FPT_RCV)

5.7.5.1. Automated Recovery (FPT_RCV.2)

FPT_RCV.2.1

Refinement: When automated recovery from a failure or service discontinuity is not possible, the TSF shall enter a maintenance mode where the ability to return the TOE to an operational secure state is provided.

Application Note:

The word “operational” has been inserted to make it clear that the desired secure state is a secure state in opera-tional mode as opposed to a secure state in maintenance mode. See Section 1.5, “Glossary” for the description of maintenance mode and operational mode.

51


Application Note:

There is no requirement that the TSF supports the recovery action to transition from the maintenance mode to the operational mode.

FPT_RCV.2.2

Refinement: The TSF shall ensure the return of the TOE to a operational secure state using automated procedures for the following procedures for the following failures/service discontinuities:

• All TOE restarts in response to a power failure,

• [selection: [assignment: list of additional failures/service discontinuities], no other failures/service discon-tinuities].

5.7.5.2. Function Recovery (FPT_RCV.4)

FPT_RCV.4.1

The TSF shall ensure that all SFs that affect the security state and [assignment: list of failure scenarios] have the property that the SF either completes successfully, or for the indicated failure scenarios, recovers to a consistent and secure state.

5.7.6. Replay detection (FPT_RPL)

5.7.6.1. Replay detection (FPT_RPL.1)

FPT_RPL.1.1

The TSF shall detect replay for the following entities: user data transmitted between nodes , TSF data transmitted between nodes .

FPT_RPL.1.2

The TSF shall perform actions to prevent delivery or use of the data when replay is detected.

5.7.7. Explicit: TOE Restart (FPT_RST)

5.7.7.1. Explicit: TOE Restart (FPT_RST_EXP.1)

FPT_RST_EXP.1.1

When requested by an authorized subject, the TSF shall restart the TOE without any change to the TOE configura-tion.

FPT_RST_EXP.1.2

The TSF shall preserve secure state during a restart of the TOE.

Application Note:

This requirement is for a simple restart of the TOE. Refer to FPT_CFG_EXP.1 for requirements that address the reconfiguration of the TOE.

52


5.7.8. Request Validation (FPT_RVD_EXP)

5.7.8.1. Syntactic and semantic validation of requests (FPT_RVD_EXP.1)

FPT_RVD_EXP.1.1

The TOE shall validate all requests to ensure that requests are semantically valid and will not cause the TOE to cor-rupt itself or violate the TSP.

5.7.9. Reference mediation (FPT_RVM)

5.7.9.1. Non-Bypassability of the TSF (FPT_RVM.1)

FPT_RVM.1.1

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

5.7.10. Domain separation (FPT_SEP)

5.7.10.1. TSF domain separation (FPT_SEP.3)

FPT_SEP.3.1

The TSF shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects.

FPT_SEP.3.2

The TSF shall enforce separation between the security domains of subjects in the TSC.

FPT_SEP.3.3

The TSF shall maintain the part of the TSF that enforces the access controls and/or information flow control SFPs in a security domain for its own execution that protects them from interference and tampering by the remainder of the TSF and by subjects untrusted with respect to the TSP.

5.7.11. State synchrony protocol (FPT_SSP)

5.7.11.1. Mutual trusted acknowledgement (FPT_SSP.2)

FPT_SSP.2.1

The TSF shall acknowledge, when requested by another part of the TSF, the receipt of an unmodified TSF data transmission.

FPT_SSP.2.2

The TSF shall ensure that the relevant parts of the TSF know the correct status of transmitted data among its differ-ent parts, using acknowledgments.

5.7.12. Time stamps (FPT_STM)

5.7.12.1. Reliable Time Stamps (FPT_STM.1)

FPT_STM.1.1

The TSF shall be able to provide reliable time stamps for its own use.

53


Application Note:

It is the responsibility of the ST author to provide a definition and metric for the term “reliable time stamp” and to provide evidence that the implementation meets the defined definition and metric. The definition and metric should be documented in the administrative guidance for the TOE. The rationale in the ST should be used to substantiate the chosen definition and metric.

Application Note:

It is not required that “time” be maintained or provided as “time of day”. It is acceptable for the TOE to maintain and provide time as being “relative to” some TOE event (e.g., relative to TOE initialization), such that it is possible to determine the ordering of events associated with the chosen unit of time. For example, a monotonically increasing counter with a defined metric for each increment of the counter represents one acceptable implementation of this requirement.

5.7.13. TSF Self Test (FPT_TST)

5.7.13.1. Explicit: TSF Testing (FPT_TST_EXP.1)

FPT_TST_EXP.1.1

The TSF shall run a suite of self tests during the initial start-up, during reconfiguration, during automated recovery and [assignment: conditions under which self test should occur during normal operation] to demonstrate the correct operation of the TSF's implementation.

Application Note:

See Annex J of the CC, Part 2, for an explanation of TSF's implementation.

FPT_TST_EXP.1.2

The TSF shall verify, or provide the capability for an authorized subject to verify, the integrity of TSF configuration data and [assignment: list of additional TSF data upon which the TSF depends to enforce its security policies cor-rectly].

FPT_TST_EXP.1.3

The TSF shall verify, or provide the capability for an authorized subject to verify, the integrity of stored TSF execu-table code.

5.8. Resource utilization (FRU) 5.8.1. TSF Predictable Resource Utilization (FRU_PRU_EXP)

5.8.1.1. Explicit: TSF Predictable Resource Utilization (FRU_PRU_EXP.1)

FRU_PRU_EXP.1.1

The TSF shall exhibit predictable and worst-case bounded usage of execution time and memory.

Application Note:

Suspending a service request to implement a scheduling policy is not construed as nondeterministic or unpredictable TOE behavior.

54


5.8.2. Resource allocation (FRU_RSA)

5.8.2.1. Minimum and maximum quotas (FRU_RSA.2)

FRU_RSA.2.1

The TSF shall enforce maximum quotas of the following resources: sharable communications resources that chan-nels and subjects can use simultaneously.

FRU_RSA.2.2

The TSF shall ensure the provision of minimum quantity of each proportional share of communications resources that is available for channels and subjects to use simultaneously.

55


6. TOE Security Assurance Requirements This section contains the detailed security assurance requirements for Partitioning Communications Systems support systems in environments requiring high robustness. The requirements contained in this section are either selected from Part 3 of the CC or have been explicitly stated (with short names ending in “_EXP”. Table 5 lists the explicitly stated assurance requirements.

Table 5. Explicit Assurance Requirements

Explicit Component Component Behavior Name

placeholder placeholder

The combination of assurance components is equivalent to an Evaluation and Assurance Level 6 with augmentation (EAL6+). The augmented assurances required are in the areas of development, independent testing, systematic flaw remediation and maintenance of assurance. The intended TOE environment and the value of the information proc-essed by this environment establish the need for the TOE to be evaluated at this EAL level6. These security assur-ance requirements are summarized in Table 6. Note that flaw remediation (ALC_FLR) has been chosen even though the CC chose not to assign this component to any specific EAL level. The maintenance of assurance (AMA) class was deleted in the transition from CC version 2.1 to CC version 2.2. The AMA assurance requirements are desired, so following CC conventions, the AMA class from CC version 2.1 has been included into this profile as explicit requirements.

With respect to development requirements in the ADV classes, a structured document such as the Common Criteria is sufficient to meet the requirements for semiformal specification.

Table 6. Summary of Assurance Components by Evaluation Assurance Level

Assurance Class Assurance Fam-ily EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7

ACM AUT 1 1 2 2

ACM CAP 1 2 3 4 4 5 5

ACM SCP 1 2 3 3 3

ADO DEL_EXP 1 1 2 2 (2) 3

ADO IGS 1 1 1 1 1 1 1

ADV ARC_EXP (1) (1) (1) (1)

ADV CMP_EXP (1) (2) (2) (2) (2) (2)

ADV FSP_EXP (1) (2) (3) (3) (4) (5) (6)

6Refer to the “Mutual Recognition of Common Criteria Certificates” section 1.3 to read conditions for the CC certificate to be mutually recog-nized for PPs with EALs higher than 4.

56


Assurance Class Assurance Fam-ily EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7

ADV HLD_EXP (1) (2) (2) (3) (4) (4)

ADV IFA_EXP (1)

ADV IMP_EXP (1) (1) (2) (3)

ADV INT_EXP (2) (3) (4)

ADV LLD_EXP (1) (2) (3) (4)

ADV RCR (1) (1) (2) (2) (2) (3)

ADV SPM (1) (3) (3) (3)

AGD ADM_EXP 1 1 1 1 1 (1) 1

AGD USR 1 1 1 1 1 1 1

ALC DVS 1 1 1 2 2

ALC FLR (3)

ALC LCD 1 2 2 3

ALC TAT 1 2 3 3

AMA AMP_EXP (1)

ATE COV 1 2 2 2 3 3

ATE DPT 1 1 2 2 3

ATE FUN 1 1 1 1 2 2

ATE IND 1 2 2 2 2 2 3

AVA CCA_EXP 1 (2) 2

AVA MSU 1 2 2 3 3

AVA SOF 1 1 1 1 1 1

AVA VLA 1 1 2 3 4 4

57


6.1. Configuration Management (ACM) 6.1.1. CM Automation (ACM_AUT)

6.1.1.1. CM Automation (ACM_AUT.2)

ACM_AUT.2.1.D

The developer shall use a CM system.

ACM_AUT.2.2D

The developer shall provide a CM plan.

ACM_AUT.2.1C

The CM system shall provide an automated means by which only authorised changes are made to the TOE imple-mentation representation, and to all other configuration items.

ACM_AUT.2.2C

The CM system shall provide an automated means to support the generation of the TOE.

ACM_AUT.2.3C

The CM plan shall describe the automated tools used in the CM system.

ACM_AUT.2.4C

The CM plan shall describe how the automated tools are used in the CM system.

ACM_AUT.2.5C

The CM system shall provide an automated means to ascertain the changes between the TOE and its preceding ver-sion.

ACM_AUT.2.6C

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.1E

The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

6.1.2. CM Capabilities (ACM_CAP)

6.1.2.1. CM Capabilities (ACM_CAP.5)

ACM_CAP.5.1D

The developer shall provide a reference for the TOE.

ACM_CAP.5.2D

The developer shall use a CM system.

58


ACM_CAP.5.3D

The developer shall provide CM documentation.

ACM_CAP.5.1C

The reference for the TOE shall be unique to each version of the TOE.

ACM_CAP.5.2C

The TOE shall be labeled with its reference.

ACM_CAP.5.3C

The CM documentation shall include a configuration list, a CM plan, an acceptance plan, and integration proce-dures.

ACM_CAP.5.4C

The configuration list shall describe the configuration items that comprise the TOE.

ACM_CAP.5.5C

The CM documentation shall describe the method used to uniquely identify the configuration items.

ACM_CAP.5.6C

The CM system shall uniquely identify all configuration items.

ACM_CAP.5.7C

The CM plan shall describe how the CM system is used.

ACM_CAP.5.8C

The evidence shall demonstrate that the CM system is operating in accordance with the CM plan.

ACM_CAP.5.9C

The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system.

ACM_CAP.5.10C

The CM system shall provide measures such that only authorised changes are made to the configuration items.

ACM_CAP.5.11C

The CM system shall support the generation of the TOE.

ACM_CAP.5.12C

The acceptance plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE.

ACM_CAP.5.13C

The integration procedures shall describe how the CM system is applied in the TOE manufacturing process.

59


ACM_CAP.5.14C

The CM system shall require that the person responsible for accepting a configuration item into CM is not the per-son who developed it.

ACM_CAP.5.15C

The CM system shall clearly identify the configuration items that comprise the TSF.

ACM_CAP.5.16C

The CM system shall support the audit of all modifications to the TOE, including the originator, date, and time in the audit trail.

ACM_CAP.5.17C

The CM system shall be able to identify the master copy of all material used to generate the TOE.

ACM_CAP.5.18C

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.19C

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.20C

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.21C

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.1E


6.1.3. CM Scope (ACM_SCP)

6.1.3.1. Development Tools CM coverage (ACM_SCP.3)

ACM_SCP.3.1D

The developer shall provide a list of configuration items for the TOE.

ACM_SCP.3.1C

The list of configuration items shall include the following: implementation representation; security flaws; develop-ment tools and related information; and the evaluation evidence required by the assurance components in the ST.

60


ACM_SCP.3.1E


6.2. Delivery and Operation (ADO) 6.2.1. Delivery (ADO_DEL)

6.2.1.1. Delivery (ADO_DEL_EXP.2)

ADO_DEL_EXP.2.1D

The developer shall document procedures for delivery of the TOE or parts of it to the user.

ADO_DEL_EXP.2.2D

The developer shall use the delivery procedures.

ADO_DEL_EXP.2.3D

The developer shall use independent channels to deliver the TOE code and to deliver the cryptographic keying mate-rials used to verify the delivery of the code.

ADO_DEL_EXP.2.4D

The developer shall use cryptographic signature services in accordance with the NIST-approved digital signature algorithm [selection: Digital Signature Algorithm (DSA) with a key size (modulus) of 2048 bits or greater, RSA Digital Signature Algorithm (rDSA with odd e) with a key size (modulus) of 2048 bits or greater, Elliptic Curve Digital Signature Algorithm (ECDSA) with a key size of 256 bits or greater] that meets the following:

a. Case: Digital Signature Algorithm

FIPS PUB 186-28, Digital Signature Standard, for signature creation and verification processing; and ANSI Standard X9.42-2001, Public Key Cryptography for the Financial Services Industry: Agreement of Sym-metric Keys Using Discrete Logarithm Cryptography for generation of the domain parameters8.

b. Case: RSA Digital Signature Algorithm (with odd e)

ANSI X9.31-1998 (May 1998), Digital Signatures Using Reversible Public Key Cryptography For the Fi-nancial Services Industry (rDSA)9.

c. Case: Elliptic Curve Digital Signature Algorithm

ANSI X9.62-1998 (10 Oct 1999), Public Key Cryptography for the Financial Services Industry: Elliptic Curve Digital Signature Algorithm (ECDSA)

Application Note:

A key size of 2048 bits is acceptable.

8FIPS PUB 186-3 is under development. It will incorporate the signature creation and verification processing of FIPS PUB 186-2, and the genera-tion of domain parameters of ANSI X9.42. FIPS PUB 186-3 shall be used here when it is finalized and approved. 8Any pseudorandom RNG used in these schemes for generating private values shall be seeded by a nondeterministic RNG (both types of RNGs meeting requirements RNG requirements in this PP).

9Any pseudorandom RNG used in these schemes for generating private values shall be seeded by a nondeterministic RNG (both types of RNGs meeting requirements RNG requirements in this PP).

61


Application Note:

For elliptic curve-based schemes the key size refers to the log2 of the order of the base point. As the preferred ap-proach for cryptographic signature, elliptic curves will be required within a TBD time frame after all the necessary standards and other supporting information are fully established.

ADO_DEL_EXP.2.5D

The developer shall use cryptographic hashing functions that employ a NIST-approved hash implementation of the Secure Hash algorithm and message digest size of at least 256 bits that meets the following: FIPS PUB 180-2.

ADO_DEL_EXP.2.1C

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_EXP.2.2C

The delivery documentation shall describe how the various procedures and mechanisms provide for the detection of modifications, or any discrepancy between the developer's master copy and the version received at the user site.

ADO_DEL_EXP.2.3C

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_EXP.2.4C

The delivery documentation shall describe how independent delivery channels are used to deliver the TOE code and to deliver the cryptographic keying materials used to verify the delivery of the code.

ADO_DEL_EXP.2.5C

The delivery documentation shall describe how to use the cryptographic mechanisms used to detect modification of the code of the TOE during the initial delivery and subsequent updates.

ADO_DEL_EXP.2.6C

The delivery documentation shall describe how to use the cryptographic mechanisms used to verify the integrity of the code of the TOE to ensure that the on-site version matches the master distribution version.

Application Note:

It is assumed that the “cryptographic seal” of the TOE code will be verified when the TOE code is received from the TOE developer and protected appropriately at the user's site prior to loading into non-volatile memory for inclusion into the hosting hardware. However, for IT environments that cannot guarantee physical protection, additional pro-cedures to re-check the integrity of the TOE code prior to loading should be provided by the IT environment.

ADO_DEL_EXP.2.7C

The delivery documentation shall describe how to use the cryptographic mechanisms that interact with the TOE to verify and guarantee delivery from the intended source.

ADO_DEL_EXP.2.1E


62


ADO_DEL_EXP.2.2E

The evaluator shall determine that the procedures provided result in a trusted delivery.

6.2.2. Installation, Generation and Start-Up (ADO_IGS)

6.2.2.1. Installation, Generation and Start-Up (ADO_IGS.1)

Application Note:

This section is intended to address the requirements for configuring the TOE to be in a TOE Evaluated Configura-tion (TEC). Requirements for administrator guidance to correctly use TOE mechanisms to achieve an initial secure state are addressed in AGD_ADM.

ADO_IGS.1.1D

The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE.

ADO_IGS.1.1C

The installation, generation and start-up documentation shall describe all the steps necessary for secure installation, generation and start-up of the TOE.

ADO_IGS.1.1E


ADO_IGS.1.2E

The evaluator shall determine that the installation, generation, and start-up procedures result in a secure configura-tion.

6.3. Development (ADV) 6.3.1. Architectural Design (ADV_ARC)

6.3.1.1. Explicit: Architectural Design (ADV_ARC_EXP.1)

ADV_ARC_EXP.1.1D

The developer shall provide the architectural design of the TSF.

ADV_ARC_EXP.1.1C

The presentation of the architectural design of the TSF shall be informal.

ADV_ARC_EXP.1.2C

The architectural design shall be internally consistent.

ADV_ARC_EXP.1.3C

The architectural design shall describe the design of the TSF self-protection mechanisms.

63


ADV_ARC_EXP.1.4C

The architectural design shall describe the design of the TSF in detail sufficient to determine that the security en-forcing mechanisms cannot be bypassed.

ADV_ARC_EXP.1.5C

The architectural design shall justify that the design of the TSF achieves the self-protection function.

ADV_ARC_EXP.1.6C

The architectural design shall justify that the design of the TSF achieves the principle of least privilege specified in adv_int.

ADV_ARC_EXP.1.1E


ADV_ARC_EXP.1.2E

The evaluator shall analyze the architectural design and other available TSF evidence to determine that FPT_SEP and FPT_RVM are accurately implemented in the TSF.

6.3.2. Composition Information (ADV_CMP)

6.3.2.1. Composition Information (ADV_CMP_EXP.2)

ADV_CMP_EXP.2.1D

The developer shall provide composition information addressed to system integrators.

ADV_CMP_EXP.2.1C

The composition information shall describe the name, purpose, parameters, parameter definitions, and manner of use of all IT environment interfaces provided for use by the TSF.

ADV_CMP_EXP.2.2C

The composition information shall describe how each TSFI can be invoked to use the IT environment interfaces.

ADV_CMP_EXP.2.1E


6.3.3. Functional Specification (ADV_FSP)

6.3.3.1. Explicit: Formal Functional Specification With Indirect Error Mapping (ADV_FSP_EXP.6)

ADV_FSP_EXP.6.1D

The developer shall provide a functional specification.

ADV_FSP_EXP.6.1C

The functional specification shall completely represent the TSF.

64


ADV_FSP_EXP.6.2C

The functional specification shall be internally consistent.

ADV_FSP_EXP.6.3C

The functional specification shall describe the external TSF interfaces (TSFI) using a formal style, supported by informal, explanatory text where appropriate.

ADV_FSP_EXP.6.4C

The functional specification shall designate each external TSFI as security enforcing or security supporting.

ADV_FSP_EXP.6.5C

The functional specification shall describe the purpose and method of use of each external TSFI.

ADV_FSP_EXP.6.6C

The functional specification shall identify and describe all parameters associated with each external TSFI.

ADV_FSP_EXP.6.7C

The functional specification shall describe all effects and all exceptions associated with each external TSFI.

ADV_FSP_EXP.6.8C

The functional specification shall describe all error messages resulting from the effects and exceptions associated with each external TSFI.

ADV_FSP_EXP.6.9C

The functional specification shall indicate the TSFI associated with each indirect error message.

ADV_FSP_EXP.6.1E


ADV_FSP_EXP.6.2E

The evaluator shall determine that the functional specification is an accurate and complete instantiation of the uservisible TOE security functional requirements.

6.3.4. High-Level Design (ADV_HLD)

6.3.4.1. Explicit: Semiformal High-Level Design (ADV_HLD_EXP.4)

ADV_HLD_EXP.4.1D

The developer shall provide the high-level design of the TOE

ADV_HLD_EXP.4.1C

The high-level design shall describe the structure of the TOE in terms of subsystems.

ADV_HLD_EXP.4.2C

The high-level design shall be internally consistent.

65


ADV_HLD_EXP.4.3C

The presentation of the high-level design of the TSF shall be in semiformal style, supported by informal, explana-tory text where appropriate.

ADV_HLD_EXP.4.4C

The high-level design shall describe the design of the TOE in sufficient detail to determine what subsystems of the TOE are parts of the TSF.

ADV_HLD_EXP.4.5C

The high-level design shall provide a description of the security functionality to be provided by the IT Environment.

ADV_HLD_EXP.4.6C

The high-level design shall identify all subsystems in the TSF, and designate them as either security enforcing or security supporting.

ADV_HLD_EXP.4.7C

The high-level design shall describe the structure of all subsystems of the TSF.

ADV_HLD_EXP.4.8C

The high-level design shall describe the design of all behavior for all subsystems of the TSF.

ADV_HLD_EXP.4.9C

The high-level design shall describe any interactions between the subsystems of the TSF.

ADV_HLD_EXP.4.1E


ADV_HLD_EXP.4.2E

The evaluator shall determine that the high-level design is an accurate and complete instantiation of all user-visible TOE security functional requirements, with the exception of FPT_SEP and FPT_RVM.

6.3.5. Information Availability (ADV_IFA)

6.3.5.1. Explicit: Availability of Interface Information (ADV_IFA_EXP.1)

ADV_IFA_EXP.1.1D

The developer shall provide the composition information to system integrators.

ADV_IFA_EXP.1.2D

The developer shall provide the TSF functional specification to system integrators.

ADV_IFA_EXP.1.3D

The developer shall provide the TSF test coverage analysis and TSF test procedure descriptions to the system inte-grators.

66


ADV_IFA_EXP.1.4D

The developer shall provide an Integrators' Disclosure Agreement.

ADV_IFA_EXP.1.1C

The Integrators' Disclosure Agreement shall identify the documentation comprising the composition information; TSF functional specification, TSF test coverage analysis, and TSF test procedure descriptions to be supplied under the terms of the agreement.

ADV_IFA_EXP.1.2C

The Integrators' Disclosure Agreement shall specify terms under which the TSF functional specification, TSF test coverage analysis, and TSF test procedure descriptions will be made available to system integrators.

ADV_IFA_EXP.1.3C

The terms specified in the Integrators' Disclosure Agreement shall not place onerous requirements on system inte-grators in order to obtain the TSF functional specification and TSF test coverage analysis.

ADV_IFA_EXP.1.1E


ADV_IFA_EXP.1.2E

The evaluator shall confirm that the documentation comprising the composition information, TSF functional specifi-cation, TSF test coverage analysis, and TSF test procedure descriptions identified in the Integrators' Disclosure Agreement completely and accurately reflects the evidence supplied by the developer during the evaluation of the TOE.

6.3.6. Implementation Representation (ADV_IMP)

6.3.6.1. Explicit: Verified Implementation of the TSF (ADV_IMP_EXP.3)

ADV_IMP_EXP.3.1D

The developer shall provide the implementation representation for the entire TSF.

ADV_IMP_EXP.3.2D

The developer shall provide any additional information necessary to interpret the implementation representation supplied.

ADV_IMP_EXP.3.3D

The developer shall supply the implementation of the software portions of the TSF.

ADV_IMP_EXP.3.4D

The developer shall provide implementation information for the software portions of the TSF implementation.

ADV_IMP_EXP.3.5D

The developer shall supply tools, and their associated documentation, used to debug the software portions of the TSF implementation.

67


ADV_IMP_EXP.3.1C

The implementation representation shall unambiguously define the TSF to a level of detail such that the TSF can be generated without further design decisions, and are suitable so that they could be directly transformed to the imple-mentation itself.

ADV_IMP_EXP.3.2C

The additional information shall describe any conventions, directives, or other constructs necessary to determine the portions of the implementation representation that will be used when the implementation representation is trans-formed into the implementation itself.

ADV_IMP_EXP.3.3C

The implementation information shall describe the format of the external representation of the implementation.

ADV_IMP_EXP.3.4C

The implementation information shall map the implementation representation to the external representation of the implementation.

ADV_IMP_EXP.3.5C

The implementation information shall provide a detailed description of the process(es) by which the external repre-sentation of the implementation is loaded and executed.

ADV_IMP_EXP.3.6C

The documentation of the tools used for debugging shall be sufficient to allow use of the debugging tools for inves-tigating the behavior of the TSF.

ADV_IMP_EXP.3.1E


ADV_IMP_EXP.3.2E

The evaluator shall determine that the implementation representation is an accurate and complete instantiation of the TOE security functional requirements.

ADV_IMP_EXP.3.3E

The evaluator shall confirm, through use of the supplied debugging tools and direct examination of the implementa-tion, that the implementation provided is an accurate and complete instantiation of the TOE security functional re-quirements.

6.3.7. Trusted Initialization (ADV_INI)

6.3.7.1. Explicit: Trusted Initialization (ADV_INI_EXP.1)

ADV_INI_EXP.1.1

The TOE shall provide procedures and/or mechanisms to ensure that the TSF configuration data reflects the user's intention regarding information flow.

68


ADV_INI_EXP.1.2

The TOE shall provide cryptographic mechanisms using TSF provided cryptographic functions to detect modifica-tion of the TSF configuration data after it is created.

ADV_INI_EXP.1.3D

The TOE shall provide cryptographic mechanisms using TSF provided cryptographic functions to verify the integ-rity of the TSF configuration data prior to loading into non-volatile memory for inclusion into the hosting hardware.

ADV_INI_EXP.1.4D

The TOE shall provide cryptographic mechanisms using TSF provided cryptographic functions to detect modifica-tion of the code of the TOE during the initial delivery and subsequent updates.

ADV_INI_EXP.1.5D

The TOE shall provide cryptographic mechanisms using TSF provided cryptographic functions to verify the integ-rity of the code of the TOE to ensure that the on-site version matches the master distribution version.

ADV_INI_EXP.1.6D

The TOE shall provide cryptographic mechanisms to guarantee delivery from the intended source.

ADV_INI_EXP.1.7D

The TOE shall provide a mechanism to initialize the TSF to an initial secure state.

ADV_INI_EXP.1.8D

The TOE shall provide an initialization mechanism to provide restrictive defaults for all security attributes that are not explicitly set by the administrator.

ADV_INI_EXP.1.9D

The TOE shall provide an initialization mechanism that shall [assignment: list of the actions to take] upon detection of the following conditions: [assignment: list of detectable initialization errors and failures that prevent the estab-lishment of an initial secure state for the TSF.].

Application Note:

This requirement is intended to provide assurance that the initialization code is capable of detecting and handling anomalies during the initialization process during which the initial secure state is not yet established.

ADV_INI_EXP.1.10D

The TOE shall provide a load mechanism to correctly convert the TSF code and/or configuration data into a TSF usable form.

ADV_INI_EXP.1.1E

The evaluator shall determine that the configuration data generation mechanisms provided result in a correct con-figuration data.

ADV_INI_EXP.1.2E

The evaluator shall determine that the delivery mechanisms provided result in a trusted delivery.

69


ADV_INI_EXP.1.3E

(deleted)

ADV_INI_EXP.1.4E

The evaluator shall determine that the initialization mechanisms provided result in an initial secure state of the TOE.

ADV_INI_EXP.1.5E

The evaluator shall determine that the load mechanism provided result in a correct conversion of the TSF code and/or configuration data into a TSF-useable form.

6.3.8. TSF Internals (ADV_INT)

6.3.8.1. Explicit: Minimization of Complexity (ADV_INT_EXP.4)

ADV_INT_EXP.4.1D

The developer shall design and structure the TSF using modular decomposition.

ADV_INT_EXP.4.2D

The developer shall use sound software engineering principles to achieve the modular decomposition of the TSF.

ADV_INT_EXP.4.3D

The developer shall design the modules such that they exhibit good internal structure and are not overly complex.

ADV_INT_EXP.4.4D

The developer shall design all TSF modules such that they exhibit only functional, sequential, or communicational cohesion, with limited exceptions.

ADV_INT_EXP.4.5D

The developer shall design all TSF modules such that they exhibit only call coupling, with limited exceptions of common coupling.

ADV_INT_EXP.4.6D

The developer shall implement TSF modules using coding standards that result in good internal structure that is not overly complex.

ADV_INT_EXP.4.7D

The developer shall design and structure the TSF in a layered fashion that minimizes mutual dependencies between the layers of the design.

ADV_INT_EXP.4.8D

The developer shall design and structure the TSF such that interactions between layers are initiated from a higher layer in the hierarchy down to a lower layer in the hierarchy with limited exceptions.

ADV_INT_EXP.4.9D

The developer shall ensure that unused or redundant code are excluded from the TSF, with limited exceptions.

70


ADV_INT_EXP.4.10D

The developer shall ensure that code that is not relevant for enforcing or supporting the TSP(s) are excluded from the TSF modules, with limited exceptions.

ADV_INT_EXP.4.11D

The developer shall provide a software architectural description.

ADV_INT_EXP.4.12D

The developer shall design and structure the TSF in such a way that the principle of least privilege is achieved with respect to TSF modules.

ADV_INT_EXP.4.1C

The software architectural description shall identify all the modules of the TSF.

ADV_INT_EXP.4.2C

The TSF modules shall be identical to those described by the low level design (ADV_LLD.1.4C).

ADV_INT_EXP.4.3C

The software architectural description shall describe the process used for modular decomposition.

ADV_INT_EXP.4.4C

The software architectural description shall describe how the TSF design is a reflection of the modular decomposi-tion process.

ADV_INT_EXP.4.5C

The software architectural description shall include the coding standards used in the development of the TSF.

ADV_INT_EXP.4.6C

The software architectural description shall provide a justification, on a per module basis, of any deviations from the coding standards.

ADV_INT_EXP.4.7C

The software architectural description shall include a coupling analysis that describes intermodule coupling for all TSF modules.

ADV_INT_EXP.4.8C

The software architectural description shall provide a justification, on a per module basis, for any coupling or cohe-sion exhibited by modules of the TSF, other than those permitted.

ADV_INT_EXP.4.9C

The software architectural description shall provide a justification, on a per module basis, that the modules of the TSF are not overly complex.

ADV_INT_EXP.4.10C

The software architectural description shall describe the layering architecture and shall describe the services that each layer provides.

71


ADV_INT_EXP.4.11C

The software architectural description shall identify the modules contained in each layer.

ADV_INT_EXP.4.12C

The software architectural description shall identify all interactions between layers of the TSF.

ADV_INT_EXP.4.13C

The software architectural description shall provide a justification of interactions that are initiated from a lower layer to a higher layer.

ADV_INT_EXP.4.14C

The software architectural description shall show that mutual dependencies have been minimized, and justify those that remain.

ADV_INT_EXP.4.15C

The software architectural description shall describe how the entire TSF has been structured to minimize complex-ity.

ADV_INT_EXP.4.16C

The software architectural description shall justify the inclusion of any unused or redundant code in the TSF.

ADV_INT_EXP.4.17C

The software architectural description shall justify the inclusion of any non-TSP-enforcing modules in the TSF.

ADV_INT_EXP.4.18C

The software architectural description shall describe how the entire TSF has be structured to achieve least privilege.

ADV_INT_EXP.4.1E


ADV_INT_EXP.4.2E

The evaluator shall perform a cohesion analysis for the modules that substantiates the type of cohesion claimed for a subset of TSF modules.

ADV_INT_EXP.4.3E

The evaluator shall perform a complexity analysis for all TSF modules.

ADV_INT_EXP.4.4E

The evaluator shall confirm that the entire TSF has been structured to achieve least privilege.

72


6.3.9. Low-Level Design (ADV_LLD)

6.3.9.1. Explicit: Semi-Formal Low-Level Design (ADV_LLD_EXP.4)

ADV_LLD_EXP.4.1D

The developer shall provide the low-level design of the TSF.

ADV_LLD_EXP.4.1C

The presentation of the low-level design shall be semi-formal style, supported by informal, explanatory text where appropriate.

ADV_LLD_EXP.4.2C

The presentation of the low-level design shall be separate from the implementation representation.

ADV_LLD_EXP.4.3C

The low-level design shall be internally consistent.

ADV_LLD_EXP.4.4C

The low-level design shall identify and describe data that are common to more than one module, where any of the modules is a security-enforcing module.

ADV_LLD_EXP.4.5C

The low-level design shall describe the TSF in terms of modules.

ADV_LLD_EXP.4.6C

The low-level design shall describe each module in terms of its purpose, interfaces, return values from those inter-faces, called interfaces to other modules, and global variables.

ADV_LLD_EXP.4.7C

For each module, the low-level design shall provide an algorithmic description detailed enough to represent the TSF implementation.

Application Note:

An algorithmic description contains sufficient detail such that two different programmers would produce function-ally-equivalent code, although data structures, programming methods, etc. may differ.

ADV_LLD_EXP.4.1E


ADV_LLD_EXP.4.2E

The evaluator shall determine that the low-level design is an accurate and complete instantiation of all TOE security functional requirements, with the exception of FTP_SEP and FPT_RVM.

73


6.3.10. Representation Correspondence (ADV_RCR)

6.3.10.1. Explicit: Formal Correspondence Demonstration (ADV_RCR_EXP.3)

Application Note:

The developer must either demonstrate or prove correspondence, as described in the requirements below, commen-surate with the level or rigor of presentation style. For example, correspondence must be proven when correspond-ing representations are formally specified.

ADV_RCR_EXP.3.1D

The developer shall provide a correspondence between all the SFRs specified in the ST and the TSFIs specified in the functional specification.

ADV_RCR_EXP.3.2D

The developer shall provide a correspondence between the TSFIs and all the subsystems defined in the high-level design.

ADV_RCR_EXP.3.3D

The developer shall provide a correspondence between the subsystems and the modules defined in the low-level design.

ADV_RCR_EXP.3.4D

The developer shall provide a correspondence between the modules and the implementation representation.

ADV_RCR_EXP.3.5D

The developer shall provide a correspondence analysis that the SFRs are completely and accurately realized by the TSFI.

ADV_RCR_EXP.3.1C

The correspondence shall indicate where the functionality presented at the more abstract TSF representation is re-flected in the less abstract TSF representation.

ADV_RCR_EXP.3.2C

The correspondence analysis between the SFRs and the TSFI shall be formal.

ADV_RCR_EXP.3.1E


ADV_RCR_EXP.3.2E

The evaluator shall determine the accuracy of the proofs of correspondence by selectively verifying the formal analysis.

74


6.3.11. Security Policy Modeling (ADV_SPM)

6.3.11.1. Explicit: Formal TOE Security Policy Model (ADV_SPM_EXP.3)

ADV_SPM_EXP.3.1D

The developer shall provide a TSP model.

ADV_SPM_EXP.3.2D

The developer shall demonstrate correspondence between the functional specification and the following policies of the TSP model: [assignment: list of semiformally-stated policies TSP model].

ADV_SPM_EXP.3.3D

The developer shall prove correspondence between the functional specification and the following policies of the TSP model: [assignment: list of formally-stated policies TSP model].

ADV_SPM_EXP.3.1C

The TSP model shall formally describe the rules and characteristics of all policies of the TSP that can be formally modeled and shall semiformally describe the rules and characteristics of other policies of the TSP.

ADV_SPM_EXP.3.2C

The TSP model shall include a rationale that demonstrates that it is consistent and complete with respect to all poli-cies of the TSP.

ADV_SPM_EXP.3.3C

The demonstration of correspondence between the TSP model and the functional specification shall show that all of the TSFI in the functional specification are consistent and complete with respect to the TSP model.

ADV_SPM_EXP.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_EXP.3.5C

Where the functional specification is formal, the proof of correspondence between the semiformally-stated portions of the TSP model and the functional specification shall be semiformal.

ADV_SPM_EXP.3.6C

Where the functional specification is formal, the proof of correspondence between the formally-stated portions of the TSP model and the functional specification shall be formal.

ADV_SPM_EXP.3.1E


75


6.4. Guidance Documents (AGD) 6.4.1. Administrator Guidance (AGD_ADM)

6.4.1.1. Explicit: Administrator Guidance (AGD_ADM_EXP.1)

AGD_ADM_EXP.1.1D

The developer shall provide administrator guidance addressed to system administrative personnel.

AGD_ADM_EXP.1.1C

The administrator guidance shall describe the administrative functions and interfaces available to the administrator

of the TOE.

AGD_ADM_EXP.1.2C

The administrator guidance shall describe how to administer the TOE in a secure manner.

AGD_ADM_EXP.1.3C

The administrator guidance shall contain warnings about functions and privileges that should be controlled in a se-cure processing environment.

AGD_ADM_EXP.1.4C

The administrator guidance shall describe all assumptions regarding user behavior that are relevant to secure opera-tion of the TOE.

AGD_ADM_EXP.1.5C

The administrator guidance shall describe all security parameters under the control of the administrator, indicating secure values as appropriate.

AGD_ADM_EXP.1.6C

The administrator guidance shall describe each type of security-relevant event relative to the administrative func-tions that need to be performed, including changing the security characteristics of entities under the control of the TSF.

AGD_ADM_EXP.1.7C

The administrator guidance shall be consistent with all other documentation supplied for evaluation.

AGD_ADM_EXP.1.8C

The administrator guidance shall describe all security requirements for the IT environment that are relevant to the administrator.

AGD_ADM_EXP.1.9C

The administrator guidance shall document procedures necessary for the correct generation of the TSF configuration data.

AGD_ADM_EXP.1.10C

The administrator guidance shall describe the steps necessary for correct generation of the TSF configuration data.

76


AGD_ADM_EXP.1.11C

The administrator guidance shall document procedures to grant to each subject in the TSC the most restrictive set of authorizations and information flows needed for the performance of authorized tasks.

AGD_ADM_EXP.1.12C

The administrator guidance shall describe the steps necessary for granting to each subject in the TSC the most re-strictive set of authorizations and information flows needed for the performance of authorized tasks.

AGD_ADM_EXP.1.13C

The administrator guidance shall document procedures necessary for using the load mechanism to convert the TSF code and/or data into a TSF-usable form.

AGD_ADM_EXP.1.14C

The administrator guidance shall describe the steps necessary for using the load mechanism to convert the TSF code and/or data into a TSF-usable form.

AGD_ADM_EXP.1.15C

The administrator guidance shall document procedures necessary for using the initialization mechanisms to bring the TSF into an initial secure state.

AGD_ADM_EXP.1.16C

The administrator guidance shall describe the steps necessary for using the initialization mechanisms to bring the TSF into an initial secure state.

AGD_ADM_EXP.1.1E


AGD_ADM_EXP.1.2E

The evaluator shall determine that the configuration generation procedures result in TSF configuration data that re-flects the user's intention regarding partitioning and information flow.

AGD_ADM_EXP.1.3E

The evaluator shall determine that the TOE is configured to grant to each subject in the TSC the most restrictive set of authorizations and information flows needed for the performance of authorized tasks.

AGD_ADM_EXP.1.4E

The evaluator shall determine that the load procedures result in a form of the TSF code and/or data that is useable by the TSF.

AGD_ADM_EXP.1.5E

The evaluator shall determine that the boot and initialization procedures result in an initial secure state of the TSF.

77


6.4.2. User Guidance (AGD_USR)

6.4.2.1. User Guidance (AGD_USR.1)

AGD_USR.1.1D

The developer shall provide user guidance.

AGD_USR.1.1C

The user guidance shall describe the functions and interfaces available to the non-administrative users of the TOE.

AGD_USR.1.2C

The user guidance shall describe the use of user-accessible security functions provided by the TOE.

AGD_USR.1.3C

The user guidance shall contain warnings about user-accessible functions and privileges that should be controlled in a secure processing environment.

AGD_USR.1.4C

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.5C

The user guidance shall be consistent with all other documentation supplied for evaluation.

AGD_USR.1.6C

The user guidance shall describe all security requirements for the IT environment that are relevant to the user.

AGD_USR.1.1E


6.5. Life Cycle Support (ALC) 6.5.1. Development Security (ALC_DVS)

6.5.1.1. Sufficiency of Security Measures (ALC_DVS.2)

ALC_DVS.2.1D

The developer shall produce development security documentation.

ALC_DVS.2.1C

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.

78


ALC_DVS.2.2C

The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE.

ALC_DVS.2.3C

The evidence shall justify that the security measures provide the necessary level of protection to maintain the confi-dentiality and integrity of the TOE.

ALC_DVS.2.1E


6.5.2. Flaw Remediation (ALC_FLR)

6.5.2.1. Systematic Flaw Remediation (ALC_FLR.3)

ALC_FLR.3.1D

The developer shall provide flaw remediation procedures addressed to TOE developers.

ALC_FLR.3.2D

The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws.

ALC_FLR.3.3D

The developer shall provide flaw remediation guidance addressed to TOE users.

ALC_FLR.3.1C

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.2C

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.3C

The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws.

ALC_FLR.3.4C

The flaw remediation procedures documentation shall describe the methods used to provide flaw information, cor-rections and guidance on corrective actions to TOE users.

ALC_FLR.3.5C

The flaw remediation procedures shall describe a means by which the developer receives from TOE users reports and enquiries of suspected security flaws in the TOE.

79


ALC_FLR.3.6C

The procedures for processing reported security flaws shall ensure that any reported flaws are corrected and the cor-rection issued to TOE users.

ALC_FLR.3.7C

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.8C

The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE.

ALC_FLR.3.9C

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.10C

The flaw remediation guidance shall describe a means by which TOE users may register with the developer, to be eligible to receive security flaw reports and corrections.

ALC_FLR.3.11C

The flaw remediation guidance shall identify the specific points of contact for all reports and enquiries about secu-rity issues involving the TOE.

ALC_FLR.3.1E


6.5.3. Life Cycle Definition (ALC_LCD)

6.5.3.1. Standardized Life-Cycle Model (ALC_LCD.2)

ALC_LCD.2.1D

The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE.

ALC_LCD.2.2D

The developer shall provide life-cycle definition documentation.

ALC_LCD.2.3D

The developer shall use a standardised life-cycle model to develop and maintain the TOE.

ALC_LCD.2.1C

The life-cycle definition documentation shall describe the model used to develop and maintain the TOE.

ALC_LCD.2.2C

The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE.

80


ALC_LCD.2.3C

The life-cycle definition documentation shall explain why the model was chosen.

ALC_LCD.2.4C

The life-cycle definition documentation shall explain how the model is used to develop and maintain the TOE.

ALC_LCD.2.5C

The life-cycle definition documentation shall demonstrate compliance with the standardised life-cycle model.

ALC_LCD.2.1E


6.5.4. Tools and Techniques (ALC_TAT)

6.5.4.1. Compliance with Implementation Standards - All Parts (ALC_TAT.3)

ALC_TAT.3.1D

The developer shall identify the development tools being used for the TOE.

ALC_TAT.3.2D

The developer shall document the selected implementation-dependent options of the development tools.

ALC_TAT.3.3D

The developer shall describe the implementation standards for all parts of the TOE.

ALC_TAT.3.1C

All development tools used for implementation shall be well-defined.

ALC_TAT.3.2C

The documentation of the development tools shall unambiguously define the meaning of all statements used in the implementation.

ALC_TAT.3.3C

The documentation of the development tools shall unambiguously define the meaning of all implementation-dependent options.

ALC_TAT.3.1E


ALC_TAT.3.2E

The evaluator shall confirm that the implementation standards have been applied.

81


6.6. Ratings Maintenance (AMA) 6.6.1. Assurance Maintenance Plan (AMA_AMP)

6.6.1.1. Explicit: Assurance Maintenance Plan (AMA_AMP_EXP.1)

AMA_AMP_EXP.1.1D

The developer shall provide an AM Plan.

AMA_AMP_EXP.1.1C

The AM Plan shall identify the assurance baseline.

AMA_AMP_EXP.1.2C

The AM Plan shall contain or reference a brief description of the TOE, including the security functionality it pro-vides.

AMA_AMP_EXP.1.3C

The AM Plan shall characterize the types of changes to the assurance baseline that are covered by the plan.

AMA_AMP_EXP.1.4C

The AM Plan shall describe the planned TOM release-cycle.

AMA_AMP_EXP.1.5C

The AM Plan shall identify the planned schedule of AM audits and the conditions for the end of maintenance.

AMA_AMP_EXP.1.6C

The AM Plan shall justify the planned schedule of AM audits and the conditions for the end of maintenance.

AMA_AMP_EXP.1.7C

The AM Plan shall identify the processes that are necessary for assigning, and ensuring currency of knowledge of, individual(s) assuming the role of security analyst.

AMA_AMP_EXP.1.8C

The AM Plan shall define the relationship between the security analyst and the development of the evidence.

AMA_AMP_EXP.1.9C

The AM Plan shall identify the qualifications that are necessary for the individual(s) identified as the security ana-lyst.

AMA_AMP_EXP.1.10C

The AM Plan shall describe the procedures by which changes to the assurance baseline will be identified.

AMA_AMP_EXP.1.11C

The AM Plan shall describe the procedures that are necessary to be applied to the TOM to maintain the assurance established for the certified TOE.

82


AMA_AMP_EXP.1.12C

The AM Plan shall describe the controls and mechanisms that are necessary to ensure that the procedures docu-mented in the AM Plan are followed.

AMA_AMP_EXP.1.1E


6.7. Testing (ATE) 6.7.1. Coverage (ATE_COV)

6.7.1.1. Rigorous Analysis of Coverage (ATE_COV.3)

ATE_COV.3.1D

The developer shall provide an analysis of the test coverage.

ATE_COV.3.1C

The analysis of the test coverage shall demonstrate the correspondence between the tests identified in the test docu-mentation and the TSF as described in the functional specification.

ATE_COV.3.2C

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.3C

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.1E


6.7.2. Depth (ATE_DPT)

6.7.2.1. Testing: Low Level Design (ATE_DPT.2)

ATE_DPT.2.1D

The developer shall provide the analysis of the depth of testing. Content and presentation of evidence elements

ATE_DPT.2.1C

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 and low-level design.

ATE_DPT.2.1E


83


6.7.3. Functional Tests (ATE_FUN)

6.7.3.1. Ordered Functional Testing (ATE_FUN.2)

ATE_FUN.2.1D

The developer shall test the TSF and document the results.

ATE_FUN.2.2D

The developer shall provide test documentation.

ATE_FUN.2.1C

The test documentation shall consist of test plans, test procedure descriptions, expected test results and actual test results.

ATE_FUN.2.2C

The test plans shall identify the security functions to be tested and describe the goal of the tests to be performed.

ATE_FUN.2.3C

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.4C

The expected test results shall show the anticipated outputs from a successful execution of the tests.

ATE_FUN.2.5C

The test results from the developer execution of the tests shall demonstrate that each tested security function be-haved as specified.

ATE_FUN.2.6C

The test documentation shall include an analysis of the test procedure ordering dependencies.

ATE_FUN.2.1E


6.7.4. Independent Testing (ATE_IND)

6.7.4.1. Independent Testing - Complete (ATE_IND.3)

ATE_IND.3.1D

The developer shall provide the TOE for testing.

ATE_IND.3.1C

The TOE shall be suitable for testing.

84


ATE_IND.3.2C

The developer shall provide an equivalent set of resources to those that were used in the developer's functional test-ing of the TSF.

ATE_IND.3.1E


ATE_IND.3.2E

The evaluator shall test a subset of the TSF as appropriate to confirm that the TOE operates as specified.

ATE_IND.3.3E

The evaluator shall execute all tests in the test documentation to verify the developer test results.

6.8. Vulnerability Analysis (AVA) 6.8.1. Covert Channel Analysis (AVA_CCA)

6.8.1.1. Explicit: Systematic Covert Channel Analysis (AVA_CCA_EXP.2)

AVA_CCA_EXP.2.1D

The developer shall conduct a search for covert channels for each partition flow control policy.

AVA_CCA_EXP.2.2D

For the cryptographic module, the developer shall conduct a search for covert channels for the leakage of critical cryptographic security parameters whose disclosure would compromise the security provided by the module.

AVA_CCA_EXP.2.3D

The developer shall provide covert channel analysis documentation.

AVA_CCA_EXP.2.1C

The analysis documentation shall identify covert channels and estimate their capacity.

AVA_CCA_EXP.2.2C

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_EXP.2.3C

The analysis documentation shall describe all assumptions made during the covert channel analysis.

AVA_CCA_EXP.2.4C

The analysis documentation shall describe the method used for estimating channel capacity, based on worst case scenarios.

AVA_CCA_EXP.2.5C

The analysis documentation shall describe the worst case exploitation scenario for each identified covert channel.

85


AVA_CCA_EXP.2.6C

The analysis documentation shall provide evidence that the method used to identify covert channels is systematic.

AVA_CCA_EXP.2.1E

The NSA evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

AVA_CCA_EXP.2.2E

The NSA evaluator shall confirm that the results of the covert channel analysis show that the TOE meets its func-tional requirements.

AVA_CCA_EXP.2.3E

The NSA evaluator shall selectively validate the covert channel analysis through testing.

6.8.2. Misuse (AVA_MSU)

6.8.2.1. Analysis and Testing for Insecure States (AVA_MSU.3)

AVA_MSU.3.1D

The developer shall provide guidance documentation.

AVA_MSU.3.2D

The developer shall document an analysis of the guidance documentation.

AVA_MSU.3.1C

The guidance documentation shall identify all\ possible modes of operation of the TOE (including operation follow-ing failure or operational error), their consequences and implications for maintaining secure operation.

AVA_MSU.3.2C

The guidance documentation shall be complete, clear, consistent and reasonable.

AVA_MSU.3.3C

The guidance documentation shall list all assumptions about the intended environment.

AVA_MSU.3.4C

The guidance documentation shall list all requirements for external security measures (including external proce-dural, physical and personnel controls).

AVA_MSU.3.5C

The analysis documentation shall demonstrate that the guidance documentation is complete.

AVA_MSU.3.1E


86


AVA_MSU.3.2E

The evaluator shall repeat all configuration and installation procedures, and other procedures selectively, to confirm that the TOE can be configured and used securely using only the supplied guidance documentation.

AVA_MSU.3.3E

The evaluator shall determine that the use of the guidance documentation allows all insecure states to be detected.

AVA_MSU.3.4E

The evaluator shall confirm that the analysis documentation shows that guidance is provided for secure operation in all modes of operation of the TOE.

AVA_MSU.3.5E

The evaluator shall perform independent testing to determine that an administrator or user, with an understanding of the guidance documentation, would reasonably be able to determine if the TOE is configured and operating in a manner that is insecure.

6.8.3. Strength of TOE Security Functions (AVA_SOF)

6.8.3.1. Strength of TOE Security Function Evaluation (AVA_SOF.1)

Application Note:

The security functions, for which strength of functions claims are made, are identified in the fcs class.

AVA_SOF.1.1D

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.1C

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.2C

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.1E


AVA_SOF.1.2E

The evaluator shall confirm that the strength claims are correct.

6.8.4. Vulnerability Analysis (AVA_VLA)

6.8.4.1. Highly Resistant (AVA_VLA.4)

ava_VLA.4.1D

The developer shall perform a vulnerability analysis.

87


AVA_VLA.4.2D

The developer shall provide vulnerability analysis documentation.

AVA_VLA.4.1C

The vulnerability analysis documentation shall describe the analysis of the TOE deliverables performed to search for ways in which a user can violate the TSP.

AVA_VLA.4.2C

The vulnerability analysis documentation shall describe the disposition of identified vulnerabilities.

AVA_VLA.4.3C

The vulnerability analysis documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE.

AVA_VLA.4.4C

The vulnerability analysis documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks.

AVA_VLA.4.5C

The vulnerability analysis documentation shall show that the search for vulnerabilities is systematic.

AVA_VLA.4.6C

The vulnerability analysis documentation shall provide a justification that the analysis completely addresses the TOE deliverables.

AVA_VLA.4.1E


AVA_VLA.4.2E

The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure the identi-fied vulnerabilities have been addressed.

AVA_VLA.4.3E

The evaluator shall perform an independent vulnerability analysis.

AVA_VLA.4.4E

The evaluator shall perform independent penetration testing, based on the independent vulnerability analysis, to de-termine the exploitability of additional identified vulnerabilities in the intended environment.

AVA_VLA.4.5E

The evaluator shall determine that the TOE is resistant to penetration attacks performed by an attacker possessing a high attack potential.

88


AVA_VLA.4.6E

Refinement: The NSA evaluator shall perform an independent vulnerability analysis and conduct independ-ent penetration testing.

89


7. Rationale 7.1. Security Objectives Rationale 7.1.1. Policies

Table 7. Rationale For Objectives Derived From Policies

Policy Objectives Addressing the Policy Rationale

Placeholder Placeholder Placeholder

7.1.2. Threats

Table 8. Rationale For Objectives Derived From Threats

Threat Objectives Addressing the Threat Rationale

Placeholder Placeholder placeholder

7.1.3. Assumptions

Table 9. Rationale For Objectives Derived From Assumptions

Assumption Objectives Addressing the As-sumption

Rationale


7.2. Security Requirements Rationale 7.2.1. Functional Requirements Rationale

Table 10. Rationale For the Mapping of SFR's to Objectives

Objective SFR Rationale

Placeholder Placeholder

7.2.2. Assurance Requirements Rationale

The assurance requirements for high robustness as mapped to the Common Criteria are in a state of transition. Fu-ture versions of this protection profile are likely to change to more closely reflect the current consensus on the ap-propriate use of the Common Criteria to achieve high robustness.

90


Table 11. Mapping of Assurance Requirements to Objectives

Objective Assurance Requirements


7.3. Dependency Rationale Not all of the SFR dependencies described in part two of the Common Criteria are satisfied by this protection pro-file. Table 12, “ Rationale for the exclusion of SFR dependencies ” provides a listing of these missing dependencies and rationale for their exclusion.

Table 12. Rationale for the exclusion of SFR dependencies

Source SFR Missing dependency Rationale for dependency exclusion


7.4. Security Functional Requirements Grounding in Objectives Table 13. Grounding of SFR's in Objectives

SFR Objectives addressed by the SFR


91


8. Works Cited [ccmutual] “Arrangement on the Mutual Recognition of Common Criteria Certificates in the field of Information

Technology Security”. May 2000.

[ccv22] “Common Criteria for Information Technology Security Evaluation”. Common Criteria Editorial Board. Version 2.2. January 2004.

[fips140-2] “Security Requirements For Cryptographic Modules”. Information Technology Laboratory, National In-stitute of Standards and Technology . FIPS PUB 140-2. 25 May 2001.

[SKPP] “U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness”. Information Assurance Directorate, U.S. National Security Agency. Version 0.621. 1 July 2004.

92