FORT FOX HARDWARE DATA DIODE
Classification PUBLIC
Component: ASE_CCL.1, ASE_ECD.1, ASE_INT.1, ASE_OBJ.2, ASE_REQ.2, ASE_SPD.1,
ASE_TSS.1
Project no./Ref. no. PR-070112
Date January 29, 2010
Version 1.07 Public
Author Bartek Gedrojc
Business Unit Fox Crypto
Pages 20
Security Target
Common Criteria FFHDD – EAL4+
PUBLIC 2/20
PUBLIC
This document is public.
Misuse of this document or any of its information is prohibited and will be prosecuted to the maximum penalty
possible. Fox-IT cannot be held responsible for any misconduct or malicious use of this document by a third party or
damage caused by its contained information.
Fox-IT BV
Olof Palmestraat 6
2616 LM Delft
P.O. box 638
2600 AP Delft
The Netherlands
Phone: +31 (0)15 284 7999
Fax: +31 (0)15 284 7990
Email: fox@fox-it.com
Internet: www.fox-it.com
Copyright © 2009 BV
All rights reserved. No part of this document shall be reproduced, stored in a retrieval system or transmitted by any
means without written permission of Fox-IT. Violations will be prosecuted by applicable law. The general service
conditions of Fox-IT BV. apply to this documentation.
Trademark
Fox-IT and the Fox-IT logo are trademarks of Fox-IT BV.
All other trademarks mentioned in this document are owned by the mentioned legacy body or organization.
PUBLIC 3/20
Document Management
Version management
Project name: Common Criteria FFHDD – EAL4+
Customer: Fox-IT
Subject: Security Target
Date: January 29, 2010
Version: 1.07 Public
Status: Final
Author(s): Bartek Gedrojc
This version replaces all previous version of this document.
Distribution list
Version Distribution Name/function/remarks
Review management
Review by Function Date Version
Change management
Version Date By Remarks Approval
0.01-0.13 August 29, 2008 Bartek Gedrojc Initial Draft version
0.14 September 3, 2008 Bartek Gedrojc Comments Dirk-Jan Out
0.15 September 16,
2008
Bartek Gedrojc Minor changes
0.16 September 19,
2008
Bartek Gedrojc Minor changes
0.17 September 30,
2008
Bartek Gedrojc Minor changes
0.18 December 19, 2008 Bartek Gedrojc Changed layout
0.19 January 20, 2009 Bartek Gedrojc FFHDD1 = FFHDD2
0.20 January 22, 2009 Bartek Gedrojc Typos
1.0 January 23, 2009 Bartek Gedrojc Final Version
1.01 February 23, 2009 Bartek Gedrojc Changes after comments Brightsight
1.02 February 23, 2009 Bartek Gedrojc Added appendix C
1.03 February 25, 2009 Bartek Gedrojc Added motivation for SARs
1.04 March 27, 2009 Bartek Gedrojc Removed appendix C
1.05 June 9, 2009 Bartek Gedrojc Updated FDP_IFF.1
1.06 August 21, 2009 Bartek Gedrojc Final updates after comments
1.07 November 2, 2009 Bartek Gedrojc Removed “Please destroy all previous..”
1.07 Public January 29, 2010 Bartek Gedrojc 1.07 is made Public
Related documents
Version Date Description Remarks
PUBLIC 4/20
PUBLIC 5/20
Table of Contents
Document Management ............................................................................................................... 3	
  
1	
   Security Target Introduction (ASE_INT.1) ................................................................................. 7	
  
1.1	
   Security Target Reference................................................................................................. 7	
  
1.2	
   TOE Reference ................................................................................................................ 7	
  
1.3	
   TOE Overview ................................................................................................................. 7	
  
1.4	
   TOE Description............................................................................................................... 9	
  
1.4.1	
   Physical Scope .......................................................................................................... 9	
  
1.4.2	
   Logical Scope ............................................................................................................ 9	
  
1.5	
   Document Overview........................................................................................................10	
  
2	
   Conformance Claim (ASE_CCL.1)............................................................................................11	
  
2.1	
   CC Conformance Claim....................................................................................................11	
  
2.2	
   Protection Profile Claim, Package Claim .............................................................................11	
  
2.3	
   Conformance Rationale....................................................................................................11	
  
3	
   Security Problem Definition (ASE_SPD.1).................................................................................12	
  
3.1	
   Threats .........................................................................................................................12	
  
3.2	
   Organizational Security Policies ........................................................................................12	
  
3.3	
   Assumptions ..................................................................................................................12	
  
4	
   Security Objectives (ASE_OBJ.2) ............................................................................................13	
  
4.1	
   Security Objective for the Target Of Evaluation...................................................................13	
  
4.2	
   Security Objectives for the Operational Environment ...........................................................13	
  
4.3	
   Security Objective Rationale.............................................................................................13	
  
5	
   Security Requirements (ASE_REQ.2).......................................................................................14	
  
5.1	
   Security Functional Requirements (SFRs)...........................................................................14	
  
5.1.1	
   FDP_IFC.2 Complete Information Flow Control..............................................................14	
  
5.1.2	
   FDP_IFF.1 Simple Security Attributes ..........................................................................14	
  
5.2	
   Security Assurance Requirements (SARs)...........................................................................15	
  
5.3	
   Extended Component Definition (ASE_ECD.1).....................................................................15	
  
5.4	
   Security Requirements Rationale ......................................................................................15	
  
6	
   TOE Summary Specification (ASE_TSS.1) ................................................................................16	
  
References................................................................................................................................17	
  
APPENDIX.................................................................................................................................18	
  
A	
   Security Objective Rationale ...............................................................................................18	
  
B	
   Security Requirements Rationale .........................................................................................20	
  
PUBLIC 6/20
List of Figures
Figure 1: Fort Fox Hardware Data Diode Concept ............................................................................ 7	
  
Figure 2: The TOE as a single 19” rack component .......................................................................... 9	
  
Figure 3: TOE front panel with Fox-IT logo (Top) and SINA logo (Bottom) .......................................... 9	
  
Figure 4: Fort Fox Hardware Data Diode Functional Block Diagram ...................................................10	
  
List of Tables
Table 1: Assurance Requirements ................................................................................................15	
  
Table 2: Mapping Threats/Assumptions to Objectives......................................................................18	
  
Table 3: Threats/Objectives Rationale...........................................................................................18	
  
Table 4: Assumptions/Objectives Rationale ...................................................................................19	
  
Table 5: Mapping Requirements to Objectives................................................................................20	
  
Table 6: Security Requirements/Objectives Rationale......................................................................20	
  
PUBLIC 7/20
1 Security Target Introduction (ASE_INT.1)
1.1 Security Target Reference
ST Title Fort Fox Hardware Data Diode Security Target
ST Version 1.07
ST Status Final
ST Classification Internal
Author Bartek Gedrojc (Fox-IT)
Advisor Dirk-Jan Out (Brightsight)
Evaluation Assurance Level EAL4+, augmented with AVA_VAN.5 and ALC_DVS.2
Publication Data January 29, 2010
Number of pages 20
Common Criteria Version 3.1, Revision 2, September 2007
1.2 TOE Reference
Developer Name Fox-IT
TOE Name Fort Fox Hardware Data Diode (FFHDD)
TOE Version Number FFHDD2
1.3 TOE Overview
The Target of Evaluation (TOE) is the Fort Fox Hardware Data Diode (FFHDD) developed by Fox-IT, and
will hereafter be referred to as the TOE throughout this document. The TOE is a unidirectional network,
as shown in figure 1, allowing data to travel only in one direction.
The one way physical connection of the TOE allows information to be transferred optically from a low
security classified network (Low Security Level) to a higher security classified network (High Security
Level), without compromising the confidentiality of the information on the High Security Level. To ensure
signals can only pass in one direction, but not vice versa, the TOE deploys a light source and
corresponding photocell. Fiber-optic cables are used to minimize the electromagnetic radiation when the
TOE input is connected to the Low Security Level Server and the TOE output is connected to the High
Security Level Server.
Once manufactured, there is no way to alter the function of the TOE. When the TOE Low Security Level
side is connected to a Low Security Level Server and the High Security Level side is connected to a High
Security Level server as is indicated in figure 1 the TOE and corresponding servers can be deployed in the
following scenarios:
Internet Information from the Low Security Level (Internet) may be transferred to the High
Security Level enabling the gathering of information from around the world. This is
achieved by using a standard file-transfer communication protocol.
PUBLIC 8/20
E-mail Using a ‘normal’ electronic mail gateway, e-mails can be transmitted from the Low
Security Level and received at the High Security Level. Therefore, users can read their
emails without going to a different Security Level.
Intercept Mobile telephone service providers are frequently required to intercept telecom traffic
data. Intercepted signals on the Low Security Level are transformed into digital data and
packaged in low-level UDP network packets to the High Security Level for analysis by the
police or intelligence agencies.
Updates Windows and virus updates can be deployed in a High Security Level after being copied
from the Low Security Level.
Printing Information located on a Low Secure Level can be transmitted to a printer located in a
High Secure Level.
The standard setup for using the TOE is to have an information flow from the Low Security Level side,
through the TOE to the High Security Level side, but not the other way around. This enables users to
write information on the High Security Level side without being able to extract information from the High
Security Level side.
An alternative setup is to have an information flow from the High Security Level side, through the TOE to
the Low Security Level side, but not the other way around. This enables users to read information from
the High Security Level side without being able to control or input information on the High Security Level
side. The following example describes a scenario based on an alternative setup:
Industrial Processes Processes on the High Security Level side that provide the Low Security Level side
with real-time process information for monitoring purposes, without letting users
being able to influence these critical industrial processes on the High Security
Level side.
Fort Fox
Hardware
Data Diode
TOE
Internet
Low Security Level
security classified network
High Security Level
higher security classified network
Low Security
Level Server
High Security
Level Server
Figure 1: Fort Fox Hardware Data Diode Concept
PUBLIC 9/20
1.4 TOE Description
1.4.1 Physical Scope
The Target of Evaluation (TOE) consists of a single 19” rack component, see figure 2. The TOE contains
physical hardware and does not contain any logic, firmware or software. The TOE allows information to
flow through the device in a single direction from the Bidirectional Input (Low Security Level Transceiver)
to the Unidirectional Output (High Security Level Transceiver). This is the only function performed by the
TOE.
Figure 2: The TOE as a single 19” rack component
Figure 3 shows the two available front panels for the TOE, the Fox--IT front panel and the SINA front
panel.
Figure 3: TOE front panel with Fox-IT logo (Top) and SINA logo (Bottom)
The preparative procedures [4] describe all necessary steps for secure accepting and installing the
delivered TOE.
This ST will position the TOE in a standard setup where information flows from the Low Security Level
side, through the TOE, to the High Security Level side. Placing the TOE in an alternative setup will not
change anything to the physical scope of the TOE nor will it change anything to the security function of
the TOE.
1.4.2 Logical Scope
Figure 4 shows the TOE (Fort Fox Hardware Data Diode) functional block diagram consisting of two
discrete fiber optical transceivers. The data transfer is implemented in hardware, of the physical Open
System Interconnection (OSI) reference model, to guarantee complete unidirectionality.
The TOE has two operational interfaces to establish one-way communication, the Bidirectional Input and
Unidirectional Output port. At the Low Security Level Transceiver light is carried into the Bidirectional
Input port and converted, with the aid of a photocell, into an electrical signal. The electrical signal
spreads through the TOE to the High Security Level Transceiver. The High Security Level Transceiver
receives the electrical signal and converts this, using a light source, into light. Finally, the light is offered,
PUBLIC 10/20
through the Unidirectional Output port, to the High Security Level Network. The Unidirectional Output
port is incapable of input and therefore lacks the ability of converting light into an electrical signal.
Consequently, an electrical signal is unable to propagate to the Low Security Level Transceiver and
therefore incapable to create a covert channel.
Fiber optics is used to transport signals from and to the TOE Bidirectional Input and Unidirectional Output
ports. Electrical signals only transport signals inside the TOE, which is completely enclosed by an
aluminum casing. This approach minimizes the electromagnetic emanation and the tempest security
threat.
Unidirectional communication does not work with a network protocol that requires a handshake
(acknowledgement). To establish a communication link between the Low Security Level side and the Low
Security Level Transceiver, a Bidirectional Input port is initiated. Data, information, or communication
originating at the Output (High Security Level) is physically unable to flow to the Bidirectional Input port
(Low Security Level) via the TOE, therefore there is no back channel which could be used as a covert
channel. Any network protocol could be used to implement the communication if no handshaking across
the TOE is required e.g. the User Datagram Protocol (UDP) can provide a unidirectional flow of
information.
Figure 4: Fort Fox Hardware Data Diode Functional Block Diagram
1.5 Document Overview
The ST has been developed in accordance with the requirements of the Common Criteria (CC) part 3,
Class ASE: Security Target Evaluation [3] and Annex A: Specification of Security Targets, of the CC part
1 [1]. The ST contains the following sections:
Section 1 ST introduction, provides the identification material for the ST and the TOE, it provides an
overview and description of the TOE.
Section 2 Conformance claims, describes how the ST conforms to the CC.
Section 3 Security problem definition, defines the security problem that is to be addressed.
Section 4 Security objectives, are a concise and abstract statement of the intended solution to the
problem.
Section 5 Extended components definition, describes new components if the security requirements
are not based on components from the CC.
Section 6 Security requirements, describes the Security Functional Requirements (SFRs) and the
Security Assurance Requirements (SARs).
Section 7 TOE summary specification, provides potential consumers of the TOE with a description of
how the TOE satisfies all the SFRs.
Fort Fox Hardware Data Diode
Low Security
Level
Transceiver
High Security
Level
Transceiver
Unidirectional
Output
Bidirectional
Input
Low
Security
Level
Network
High
Security
Level
Network
PUBLIC 11/20
2 Conformance Claim (ASE_CCL.1)
2.1 CC Conformance Claim
This Security Target and TOE claim conformance to [1,2,3]. This ST is CC Part 2 conformant and CC Part
3 conformant.
2.2 Protection Profile Claim, Package Claim
This Security Target claims conformance to assurance package EAL4 augmented by AVA_VAN.5 and
ALC_DVS.2.
2.3 Conformance Rationale
None
PUBLIC 12/20
3 Security Problem Definition (ASE_SPD.1)
3.1 Threats
The following threats are the assumed threat to the TOE, which could cause it to fail its security
objective:
T.TRANSFER A user or process on the High Security Level network that accidentally or
deliberately breaches the confidentiality of some High Security Level information
by transmitting data through the TOE to the Low Security Level network.
3.2 Organizational Security Policies
There are no Organizational Security Policies or rules with which the TOE must comply.
3.3 Assumptions
The TOE will be connected between two networks of different levels known as the High Security Level
network and the Low Security Level network. The assumptions made about the intended environment
are:
A.PHYSICAL The intended operation environment shall store and operate the TOE in
accordance with the requirements of the High Security Level side.
A.NETWORK The TOE is the only method of interconnecting the Low Security Level network
and High Security Level network. This prevents a threat agent from circumventing
the security being provided by the TOE through an untrustworthy product.
PUBLIC 13/20
4 Security Objectives (ASE_OBJ.2)
4.1 Security Objective for the Target Of Evaluation
The TOE is intended to protect the asset, of High Security Level information, in accordance with the
following objectives:
O.CONFIDENTIALITY The information on the High Security Level side destination is kept confidential
from the Low Security Level source.
4.2 Security Objectives for the Operational Environment
All of the secure usage assumptions are considered to be security objectives of the environment. These
objectives are satisfied though the application of procedural or administrative measures.
OE.PHYSICAL The intended operation environment shall be capable of storing and operating the
TOE in accordance with the requirements of the High Security Level side.
OE.NETWORK The TOE is the only method of interconnecting the Low Security Level network
and High Security Level network.
4.3 Security Objective Rationale
Appendix A presents the security objective rationale.
PUBLIC 14/20
5 Security Requirements (ASE_REQ.2)
5.1 Security Functional Requirements (SFRs)
The TOE uses two subjects: Input and Output. These represent the input and output of the TOE. These
subjects have no attributes.
This statement of SFRs does not define other subjects, objects, operations, security attributes or external
entities.
5.1.1 FDP_IFC.2 Complete Information Flow Control
Dependencies: FDP_IFF.1 Simple security attributes.
FDP_IFC.2.1 The TSF shall enforce the FFHDD policy on [[Input, Output], all information]
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 TOE to
flow to and from any subject in the TOE are covered by an information flow
control SFP.
5.1.2 FDP_IFF.1 Simple Security Attributes
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialization1
FDP_IFF.1.1 The TSF shall enforce the FFHDD policy based on the following types of subject
and information security attributes: [[Input [], Output []], all information
[]].
FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
information may flow from Input to Output.
FDP_IFF.1.3 <refined away>
FDP_IFF.1.4 <refined away>
FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following rules:
information may not flow from Output to Input.
1
The dependency to FMT_MSA.3 is not applicable as there are no security attributes to initialize.
PUBLIC 15/20
5.2 Security Assurance Requirements (SARs)
The security assurance requirements for the TOE are the Evaluation Assurance Level 4 (EAL 4 –
Methodically designed, tested and reviewed), augmented with the additional vulnerability assessment
classes ALC_DVS.2 – Sufficiency of Security Measures and AVA_VAN.5 – Advanced methodical
vulnerability analysis. Evaluation Assurance Level 4 is chosen while this is the highest evaluation level
that is mutually recognized by the Common Criteria Recognition Arrangement (CCRA). To indicate that
the TOE is resilient against the highest threat level the Evaluation Assurance Level 4 is augmented with
AVA_VAN.5, which is equivalent to the highest Evaluation Assurance Levels. For a detailed description of
these components, please refer to the Part 3 of the Common Criteria [3] directly. These requirements are
listed in the following table:
Table 1: Assurance Requirements
Assurance Class Assurance Component
ADV_ARC.1 – Security architecture description
ADV_FSP.4 – Complete functional specification
ADV_IMP.1 – Implementation representation of the TSF
ADV: Development
ADV_TDS.3 – Basic modular design
AGD_OPE.1 – Operational user guidance
AGD: Guidance documents
AGD_PRE.1 – Preparative procedures
ALC_CMC.4 – Production support, acceptance procedures and automation
ALC_CMS.4 – Problem tracking CM coverage
ALC_DEL.1 – Delivery procedures
ALC_DVS.2 – Sufficiency of Security Measures
ALC_LCD.1 – Development defined life-cycle model
ALC_TAT.1 – Well-defined development tools
ASE_CCL.1 – Conformance claims
ASE_ECD.1 – Extended components definition
ASE_INT.1 – ST introduction
ASE_OBJ.2 – Security objectives
ASE_REQ.2 – Derived security requirements
ASE_SPD.1 – Security problem definition
ALC: Life-cycle support
ASE_TSS.1 – TOE summary specification
ATE_COV.2 – Analysis of coverage
ATE_DPT.2 – Testing: security enforcing modules
ATE_FUN.1 – Functional testing
ATE: Test
ATE_IND.2 – Independent testing - sample
AVA: Vulnerability assessment AVA_VAN.5 – Advanced methodical vulnerability analysis
5.3 Extended Component Definition (ASE_ECD.1)
All security requirements in this ST are based on components from CC Part 2 [2] and CC Part 3 [3],
therefore there are no Extended Component Definitions.
5.4 Security Requirements Rationale
Appendix B presents the security requirements rationale.
PUBLIC 16/20
6 TOE Summary Specification (ASE_TSS.1)
The TOE addresses two Security Functional Requirements, FDP_IFC.2 and FDP_IFF.1, which is described
in section 1.4.2 of this document.
PUBLIC 17/20
References
[1] Common Criteria for Information Technology Security Evaluation.
Part 1: Introduction and General Model, Version 3.1, Revision 1, September 2006.
http://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R1.pdf
[2] Common Criteria for Information Technology Security Evaluation.
Part 2: Security Functional Components, Version 3.1, Revision 2, September 2007.
http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R2.pdf
[3] Common Criteria for Information Technology Security Evaluation.
Part 3: Security Assurance Components, Version 3.1, Revision 2, September 2007.
http://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R2.pdf
[4] Common Criteria Fox-IT.
Fort Fox Hardware Data Diode – Delivery Procedures, Preparative Procedures and Operational
User Guidance (AGD-ALC_DEL.1), version 1.04, May 7, 2009.
FFHDD-AGD-ALC_DEL.1.pdf
PUBLIC 18/20
APPENDIX
A Security Objective Rationale
This section presents the rationale for the matter in which the security objectives address the threats and
assumptions associated with the TOE.
Table 2 demonstrates how all threats and assumptions are covered by at least one of the security
objectives of the TOE, and that each security objective covers at least one threat or assumption.
Table 3 demonstrates how the objectives of the TOE and the TOE environment counter the threats
identified in section 3.1.
Table 4 demonstrates how the objectives of the TOE and the TOE environment address the assumptions
identified in section 3.3.
Table 2: Mapping Threats/Assumptions to Objectives
Threats
and
Assumptions
Objectives
T.TRANSFER
A.PHYSICAL
A.NETWORK
O.CONFIDENTIALITY X
OE.PHYSICAL X X
OE.NETWORK X
Table 3: Threats/Objectives Rationale
Threats Objectives Rationale
T.TRANSFER O.CONFIDENTIALITY
OE.PHYSICAL
The threat that data will be transferred from the High
Security Level network to the Low Security Level
network through the TOE is partially reduced by
O.CONFIDENTIALITY
O.CONFIDENTIALITY achieves this by explicitly
prohibiting any flows from the High Security Level
network through the TOE to the Low Security Level,
including flows that might take place through the use
of covert channel. Thus both explicit and implicit flows
are covered.
OE.PHYSICAL ensures that the TOE is operated and
stored within a physically secure environment that, at
minimum, meets the requirements for the High
Security Level. This mitigates the risk that
unauthorized personnel have access to the TOE at any
time.
O.CONFIDENTIALLY and OE.PHYSICAL collectively
serve to counter the threat of T.TRANSFER.
PUBLIC 19/20
Table 4: Assumptions/Objectives Rationale
Threats Objectives Rationale
A.PHYSICAL OE.PHYSICAL A.PHYSICAL assumes that the intended environment
will be capable of storing and operating the TOE, in
accordance with the requirements of the High Security
Level network. Information systems have different
requirements for the storage of computer equipment
used for processing information of different security
levels.
They may also be a requirement for protecting critical
system resources within secured rooms. The TOE is
critical to all the users and requires no administrator
control after is has been installed. It is the system
management staff responsibility to protect it from
accidental or deliberate tampering causing its
functionality to be bypassed.
OE.PHYSICAL ensures that the TOE is operated and
stored within a physically secure environment that, at
minimum, meets the requirements for the High
Security Level side. This mitigates the risk that
unauthorized personnel have access to the TOE at any
time.
A.NETWORK OE.NETWORK OE.NETWORK ensures that the TOE is the only method
of interconnecting the Low and High Security Level
networks. If an untrustworthy product is used to
connect the Low Security Level network to the High
Security Level network it may result in a compromise
of High Security Level information and thus
circumvent the security being provided by the TOE.
PUBLIC 20/20
B Security Requirements Rationale
Table 5 provides a mapping between the security requirements and the objectives that have been defined
in section 4. Table 6 provides a detailed rationale of this mapping.
Table 5: Mapping Requirements to Objectives
Objectives
SFRs
O.CONFIDENTIALITY
FDP_IFC.2 X
FDP_IFF.1 X
Table 6: Security Requirements/Objectives Rationale
Objectives Security Functional
Requirements
Rationale
O.CONFIDENTIALITY FDP_IFC.2 Information
flow control policy
FDP_IFF.1 Simple
Security Attributes
O.CONFIDENTIALITY is achieved through the diode
functionality implemented in the TOE, which serves to
enforce the FDP_IFC.2 and FDP_IFF.1 requirements.
FDP_IFC.2 defines that the policy of the Unidirectional
flow SFP: User data cannot flow from the High Security
Level port to the Low Security level port, while user
data can flow from the Low Security Level port via the
TOE.
FDP_IFF.1 identifies the rules for the TOE that is
required to enforce the Unidirectional Flow SFP.
FDP_IFF.1 is based on the TOE interface port attributes
and user data security attributes. These attributes are
defined through FDP_IFF.1 and are required to achieve
the SFP rules and the O.CONFIDENTIALITY objective.
FDP_IFF.1 requires that all Low Security Level
information be allowed to flow from the Low Security
Level input interface port to the High Security Level
output interface port. Additionally, FDP_IFF.1 requires
that no information flow from the High Security Level
output interface port to the Low Security Level input
interface port. This is how the FDP_IFF.1 and FDP_IFC.2
help achieve the O.CONFIDENTIALITY objective.