Forcepoint LLC
Forcepoint Data Guard
v3.0
Security
Target
Evaluation Assurance Level (EAL): EAL4+
Document Version: 0.8
Prepared for: Prepared by:
Forcepoint LLC Corsec Security, Inc.
10900-A Stonelake Blvd. 13921 Park Center Road
Quarry Oaks 1, Ste. 350 Suite 460
Austin, TX 78759 Herndon, VA 20171
United States of America United States of America
Phone: +1 800 723 1166 Phone: +1 703 267 6050
www.forcepoint.com www.corsec.com
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 2 of 41
Table of Contents
1. Introduction.......................................................................................................................................................4
1.1 Purpose .....................................................................................................................................................4
1.2 Security Target and TOE References.........................................................................................................4
1.3 Product Overview......................................................................................................................................5
1.4 TOE Overview............................................................................................................................................5
1.4.1 TOE Components..............................................................................................................................6
1.5 TOE Environment ......................................................................................................................................7
1.6 TOE Description.........................................................................................................................................8
1.6.1 Physical Scope ..................................................................................................................................8
1.6.2 Logical Scope ....................................................................................................................................9
1.6.3 Product Physical/Logical Features and Functionality not included in the TOE............................. 10
2. Conformance Claims....................................................................................................................................... 11
3. Security Problem............................................................................................................................................. 12
3.1 Threats to Security................................................................................................................................. 12
3.2 Organizational Security Policies............................................................................................................. 12
3.3 Assumptions........................................................................................................................................... 12
4. Security Objectives ......................................................................................................................................... 14
4.1 Security Objectives for the TOE ............................................................................................................. 14
4.2 Security Objectives for the Operational Environment........................................................................... 14
4.2.1 IT Security Objectives.................................................................................................................... 14
4.2.2 Non-IT Security Objectives............................................................................................................ 15
5. Extended Components ................................................................................................................................... 16
6. Security Requirements.................................................................................................................................... 17
6.1 Conventions ........................................................................................................................................... 17
6.2 Security Functional Requirements......................................................................................................... 17
6.2.1 Class FAU: Security Audit............................................................................................................... 18
6.2.2 Class FDP: User Data Protection.................................................................................................... 19
6.2.3 Class FIA: Identification and Authentication................................................................................. 22
6.2.4 Class FMT: Security Management................................................................................................. 22
6.3 Security Assurance Requirements ......................................................................................................... 25
7. TOE Summary Specification............................................................................................................................ 27
7.1 TOE Security Functionality ..................................................................................................................... 27
7.1.1 Security Audit ................................................................................................................................ 27
7.1.2 User Data Protection..................................................................................................................... 29
7.1.3 Identification and Authentication ................................................................................................. 30
7.1.4 Security Management ................................................................................................................... 30
8. Rationale......................................................................................................................................................... 32
8.1 Conformance Claims Rationale.............................................................................................................. 32
8.2 Security Objectives Rationale ................................................................................................................ 32
8.2.1 Security Objectives Rationale Relating to Threats ........................................................................ 32
8.2.2 Security Objectives Rationale Relating to Assumptions................................................................ 33
8.3 Rationale for Extended Security Functional Requirements................................................................... 34
8.4 Rationale for Extended TOE Security Assurance Requirements............................................................ 35
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 3 of 41
8.5 Security Requirements Rationale........................................................................................................... 35
8.5.1 Rationale for Security Functional Requirements of the TOE Objectives....................................... 35
8.5.2 Security Assurance Requirements Rationale ................................................................................ 37
8.5.3 Dependency Rationale .................................................................................................................. 38
9. Acronyms........................................................................................................................................................ 39
List of Figures
Figure 1 – FDG TCP/UDP Data Transfer Architecture.................................................................................................5
Figure 2 – Physical TOE Boundary ..............................................................................................................................8
List of Tables
Table 1 – ST and TOE References ...............................................................................................................................4
Table 2 – TOE Environment Requirements ................................................................................................................7
Table 3 – CC and PP Conformance .......................................................................................................................... 11
Table 4 – Threats ..................................................................................................................................................... 12
Table 5 – Assumptions............................................................................................................................................. 13
Table 6 – Security Objectives for the TOE............................................................................................................... 14
Table 7 – IT Security Objectives............................................................................................................................... 14
Table 8 – Non-IT Security Objectives....................................................................................................................... 15
Table 9 – TOE Security Functional Requirements ................................................................................................... 17
Table 10 – Security Attributes (INPA Interface) ...................................................................................................... 23
Table 11 – Security Attributes (ONPA Interface)..................................................................................................... 23
Table 12 – Security Attributes (Flow)...................................................................................................................... 24
Table 13 – Assurance Requirements....................................................................................................................... 25
Table 14 – Mapping of TOE Security Functionality to Security Functional Requirements...................................... 27
Table 15 – Admin and Flow Log Files....................................................................................................................... 28
Table 16 – Threats: Objectives Mapping................................................................................................................. 32
Table 17 – Assumptions: Objectives Mapping ........................................................................................................ 33
Table 18 – Objectives: SFRs Mapping...................................................................................................................... 35
Table 19 – Functional Requirements Dependencies............................................................................................... 38
Table 20 – Acronyms ............................................................................................................................................... 39
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 4 of 41
1. Introduction
This section identifies the Security Target (ST), Target of Evaluation (TOE), and the ST organization. The Target of
Evaluation (TOE) is the Forcepoint LLC (Forcepoint) Forcepoint Data Guard (FDG) and will hereafter be referred to
as the TOE throughout this document. The TOE is an automated data transfer guard that enables the secure
movement of structured data between multiple separate domains or networks.
1.1 Purpose
This ST is divided into nine sections, as follows:
• Introduction (Section 1) – Provides a summary of the ST contents and describes the organization of other
sections within this document. It also provides an overview of the TOE security functionality and describes
the physical and logical scope for the TOE as well as the ST and TOE references.
• Conformance Claims (Section 2) – Provides the identification of any Common Criteria (CC), Protection
Profile (PP), and Evaluation Assurance Level (EAL) package claims. It also identifies whether the ST contains
extended security requirements.
• Security Problem (Section 3) – Describes the threats, organizational security policies, and assumptions
that pertain to the TOE and its environment.
• Security Objectives (Section 4) – Identifies the security objectives that are satisfied by the TOE and its
environment.
• Extended Components (Section 5) – Identifies new components (extended Security Functional
Requirements (SFRs) and extended Security Assurance Requirements (SARs)) that are not included in CC
Part 2 or CC Part 3.
• Security Requirements (Section 6) – Presents the SFRs and SARs to which the TOE adheres.
• TOE Summary Specification (Section 7) – Describes the security functions provided by the TOE that satisfy
the SFRs and objectives.
• Rationale (Section 8) – Presents the rationale for the security objectives, requirements, and SFR
dependencies as to their consistency, completeness, and suitability.
• Acronyms (Section 9) – Defines the acronyms used within this ST.
1.2 Security Target and TOE References
Table 1 below shows the ST and TOE references.
Table 1 – ST and TOE References
ST Title Forcepoint LLC Forcepoint Data Guard v3.0 Security Target
ST Version Version 0.8
ST Author Corsec Security, Inc.
ST Publication Date March 16, 2020
TOE Reference Forcepoint Data Guard v3.0.0.0 Build Number 9005
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 5 of 41
1.3 Product Overview
FDG is a software product designed to inspect, validate, and filter network traffic using a flexible rules engine that
allows administrators to implement data protection and sharing policies for enterprise data.
FDG is configured for unidirectional or bidirectional automated data transfer to secure the flow of structured data
between multiple separate, typically differently classified, domains or networks. FDG is a software solution that
supports large enterprise systems with low administration costs, making it the ideal choice for large scale
government deployments that require large volume, automated data transfers. Built on top of the Red Hat
Enterprise Linux (RHEL) 7.5 secure operating system (OS) with Security Enhanced Linux (SELinux) modules, FDG
delivers byte-level deep content inspection and data validation and filtering that can be tailored to meet security
policies, requirements, and to mitigate risks specific to each customer environment.
FDG provides a flexible yet exhaustive capability to inspect data streams down to the byte level as required by the
customer security policy. Support is provided for any data transmitted via Transmission Control Protocol (TCP)
and User Datagram Protocol (UDP) over Internet Protocol (IP).
Figure 1 – FDG TCP/UDP Data Transfer Architecture
1.4 TOE Overview
The TOE Overview summarizes the usage and major security features of the TOE. This section provides a context
for the TOE evaluation by identifying the TOE type, describing the TOE, and defining the specific evaluated
configuration.
The TOE is a software-only product that runs on commercially available server hardware and is deployed between
domains or networks of different security or classification levels. The TOE includes only the FDG software
application. The TOE inspects and filters transiting data flows by applying the Lua runtime filtering rules to the
traffic that flows between the NPAs (Network Protocol Adapters). By default, no data can flow between the NPAs
unless the rules allow the flow.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 6 of 41
Administrators implement rules to define unidirectional or bidirectional flow. The rules are based on the Lua
scripting language. The Lua rules provide flexible filtering and data validation. The filtering rules to allow or drop
a data payload can be applied from a high-level (interface, network zone, or protocol) down to the byte level for
deep content inspection.
The TOE generates audit records for configuration changes, successful CLI commands, flow events, and startup
and shutdown of the audit function. An authorized administrator can filter and view the audit records from the
TOE’s CLI.
An administrator can only access the TOE after the administrator is identified by the TOE and assigned the role
associated with the logged in account.
1.4.1 TOE Components
The TOE software is available as a CD (Compact Disk) image, which includes the FDG v3.0 application and all its
components. The TOE is separated into the following components that are described in the sections below:
• Data Flow Manager (DFM)
• Data Filtering Process (DFP)
• Inbound Network Protocol Adaptor (INPA)
• Outbound Network Protocol Adaptor (ONPA)
1.4.1.1 Data Flow Manager
The DFM is the center point to create and monitor the filtering pipeline processes. Processes are created based
on Data Flow definitions. The DFM starts the INPA, DFP, and ONPA processes and monitors the health and status
of these processes. The DFM also provides a CLI to allow administrators control over the DFM and to set the
configuration files for all the components.
Administrators use the TOE’s CLI to configure settings such as allowing traffic to sources and destinations, applying
data flow policies, and to importing the filter rules used to inspect and validate the data flows. The TOE’s CLI also
provides data flow management and monitoring tools to manage the startup and shutdown of filter processing
and retrieval of various data flow transfer and filter statistics.
1.4.1.2 Data Filtering Process
The DFP provides the core filtering capabilities for the TOE. The DFP handles the input/output operations for the
flow data and hosts the Filtering Engine. The Filtering Engine is a customized version of the Lua v5.1.5 runtime
environment, which is embedded in the TOE’s software. Administrators implement rule sets written in Lua’s
scripting language to validate the data flowing through the Filter Engine. The Filter Engine can be used to chain
multiple DFP filters.
The DFP receives data payloads from the INPA and applies filter rules to determine if the data should be passed
or dropped. If the data passes validation, it is passed to the ONPA. The filter rules are constructed using Lua
programming language on top of the FDG filter APIs.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 7 of 41
1.4.1.3 Inbound Network Protocol Adaptor
The INPA receives traffic from the environment. The traffic originates from an external source endpoint over a
UDP or TCP connection. The INPA extracts the data payload and checks the configured data flow policies before
send any of the allowed data to the DFP for filtering. The configuration file for the INPA is updated by the DFM
after a RW administrator makes changes from the CLI.
1.4.1.4 Outbound Network Protocol Adaptor
The ONPA receives its data payload from the DFP and checks the configured data flow policies before sending the
payload to an external destination endpoint using a UDP or TCP connection. The configuration file for the ONPA
is updated by the DFM after a RW administrator makes changes from the CLI.
1.5 TOE Environment
The TOE runs on the RHEL 7.5 OS. RHEL provides core services such as authentication, data storage, SSH (Secure
Shell) for remote authentication, and TCP/IP networking support. FDG runs on top of the RHEL platform using
built-in modules and open-source components to provide enhanced security protection. Some of these
modules/components include:
• SELinux type enforcement: Provides mandatory access control for higher assurance enforcement of
process execution and separation. Access control to and from an external network is enforced based on
the zone ID associated with an administrator-named zone.
• Iptables: Provides packet filtering capabilities to control inbound and outbound access to network services.
The TOE communicates with two external networks. The INPA receives network traffic from the external inbound
network over a TCP or UDP connection and sends the traffic to the DFP for filtering. The ONPA receives the filtered
data from the DFP and sends the data to the external outbound network over a TCP or UDP connection.
Management of the TOE is performed using either a remote SSH connection or the local RHEL console to access
the CLI of the TOE. Table 2 specifies the minimum system requirements for the proper operation of the TOE.
Table 2 – TOE Environment Requirements
Category Requirement
Hardware The minimum hardware requirements include the following:
• At least one network interface card
• A CD drive
• 2 GB1 of memory
• 40 GB of storage
See the minimum hardware requirements for RHEL 7 version 5 listed at https://access.redhat.com/articles/rhel-limits.
Software Red Hat Enterprise Linux (RHEL) 7.5 including the following:
• SELinux
• Iptables
• OpenSSH Server
Networks Inbound and outbound networks are required for the TOE to filter traffic.
1 GB – Gigabyte
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 8 of 41
1.6 TOE Description
This section primarily addresses the physical and logical components of the TOE that are included in the evaluation.
1.6.1 Physical Scope
Figure 2 below illustrates the physical scope and the physical boundary of the overall solution and ties together
all the components of the TOE.
The TOE is a software product which runs on a commercially available hardware server compliant with the
minimum software and hardware requirements as listed in Table 2.
Figure 2 – Physical TOE Boundary
1.6.1.1 TOE Software
The TOE is software-only and includes Forcepoint’s Forcepoint Data Guard application. Forcepoint provides CD
images (in ISO format) that contain the following TOE files:
• fdg-3-0-0-0-9005-GA-2019-02-28.iso – A CD image that contains the TOE software.
• fdg_3-0-0-0-9005_documentation_2019-02-28.iso – A CD image that contains the following:
o fdg_3-0_admin-guide_2019-02-28.pdf
o fdg_3-0_guidance_2019-02-28.pdf .
The CDs containing the TOE software and documentation along with a copy of the Forcepoint Software License
Agreement, product cover letter, and Forcepoint Software Maintenance Agreement (if purchased) are included in
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 9 of 41
the Installation Media Packet. The Installation Media Packet is sealed in a padded envelope then into FedEx or
UPS packaging for shipment. The carrier is contacted for pickup at the Forcepoint site.
1.6.1.2 Guidance Documentation
The TOE documentation CD image contains the following PDF (Portable Document Format) documents, which are
required reading and part of the TOE:
• Forcepoint Data Guard Administrator’s Guide Version 3.0; February 28, 2019
• Forcepoint Guidance Documentation Supplement Version 3.0, February 28, 2019
The Forcepoint Guidance Documentation Supplement provides additional information for setting up the TOE in
compliance with CC requirements.
1.6.2 Logical Scope
The logical boundary of the TOE will be broken down into the following security classes, which are further
described in sections 6 and 7 of this ST. The logical scope also provides the description of the security features of
the TOE. The SFRs implemented by the TOE are usefully grouped under the following Security Function Classes:
• Security Audit
• User Data Protection
• Identification and Authentication
• Security Management
1.6.2.1 Security Audit
Audit functionality is provided by the TOE for generation of audit records for the startup/shutdown of the audit
function, configuration changes, and data flow events. From the TOE’s CLI, administrators may view the following
log files: xguard-admin.log2
and xguard-flow.log.
1.6.2.2 User Data Protection
Information flow control is provided by the TOE with the INPA Information Flow SFP (INPA SFP), ONPA Information
Flow SFP (ONPA SFP) and the Flow SFP. The INPA SFP controls the flow of inbound data from an external network.
The ONPA SFP controls the flow of outbound data to an external network. The Flow SFP controls what is allowed
to pass between the INPA and ONPA after filtering the data in the DFP. By default, no data is allowed to flow
unless the flow is defined and permitted. A RW administrator defines the flow filtering rules using the Lua scripting
language and imports the rules as a Lua file.
1.6.2.3 Identification and Authentication
The TOE requires administrators be identified by their TOE roles before gaining access to any TOE data or
functionality.
1.6.2.4 Security Management
The TOE provides the capability to manage the security functionality, TSF data, and security attributes of the TOE.
The TOE also provides the read-only (RO) and read-write (RW) roles. The read-only role provides limited
capabilities to view TSF data. The read-write role provides full administrative capabilities to manage the TSF. An
2 File names are rendered in italics.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 10 of 41
administrator assigned to the RO role is referred to as a RO administrator. An administrator assigned to the RW
role is referred to as a RW administrator. The unqualified term “administrator”, when not preceded by RO or RW,
refers to both RO administrators and RW administrators.
1.6.3 Product Physical/Logical Features and Functionality not
included in the TOE
Features and functionality that are not part of the evaluated configuration of the TOE are:
• Filtering functionalities provided by the following plug-ins:
o Glasswall Plug-in
o McAfee Plug-In
o XML (Extensible Markup Language) Plug-In
o JSON (JavaScript Object Notion) Plug-In
• Functionality to implement, configure, or add the following:
o CLI Timeout
o Login Banner
o File Integrity
o Web Data Flow
o System Alert Emails
o Log file rotation, exportation
o FDG backup, restoration, reset
o PKI Certificates
o System License
o Set Hostname
o Password Complexity
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 11 of 41
2. Conformance Claims
This section and Table 3 provide the identification for any CC, PP, and EAL package conformance claims. Rationale
is provided for any extensions or augmentations to the conformance claims. Rationale for CC and PP conformance
claims can be found in Section 8.1.
Table 3 – CC and PP Conformance
Common Criteria (CC)
Identification and
Conformance
Common Criteria for Information Technology Security Evaluation, Version 3.1, Release 5, April 2017; CC
Part 2 conformant; CC Part 3 conformant; PP claim (none); Parts 2 and 3 Interpretations of the CEM
(Common Evaluation Methodology) as of 2019-10-8 were reviewed, and no interpretations apply to the
claims made in this ST.
PP Identification None
Evaluation Assurance Level EAL4+ augmented with Flaw Remediation (ALC_FLR.2)
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 12 of 41
3. Security Problem
This section describes the security aspects of the environment in which the TOE will be used and how the TOE is
expected to be employed. It provides the statement of the TOE security environment, which identifies and
explains all:
• Known and presumed threats countered by either the TOE or by the security environment
• Organizational security policies to which the TOE must comply
• Assumptions about the secure usage of the TOE, including physical, personnel, and connectivity aspects
3.1 Threats to Security
This section identifies the threats to the IT (Information Technology) assets against which protection is required
by the TOE or by the security environment. The threat agent is an Attacker who is not an administrator of the TOE,
does not have account credentials, nor direct physical access to the TOE. Attackers possess a level of knowledge
of the TOE, skill level and commensurate to the claimed EAL. The IT assets requiring protection are the TSF3
and
data saved on or transitioning through the TOE. Removal, diminution, and mitigation of the threats are through
the objectives identified in Section 4 Security Objectives. Table 4 below lists the applicable threats.
Table 4 – Threats
Name Description
T.FLOW An attacker may try to gain access to the destination network or to data in transit to the
destination network by bypassing the data flow policies placed on the networks.
T.REVERSE_FLOW An attacker may try to gain access to the data that is sent in reply from the destination network
by bypassing the data flow policies placed on the networks.
T.UNDETECTED_ACTIONS An attacker may take actions that adversely affect the security of the TOE assets and these
actions remain undetected so that their effects cannot be effectively countered.
T.UNPRIVILEGED An underprivileged user may try to change the TOE configuration and compromise its security
functions.
3.2 Organizational Security Policies
An Organizational Security Policy (OSP) is a set of security rules, procedures, or guidelines imposed by an
organization on the operational environment of the TOE. There are no OSPs.
3.3 Assumptions
This section describes the security aspects of the intended environment for the evaluated TOE. The operational
environment must be managed in accordance with assurance requirement documentation for delivery, operation,
and administrator guidance. Table 5 lists the specific conditions that are required to ensure the security of the
TOE and are assumed to exist in an environment where this TOE is employed.
3 TSF – TOE Security Functionality
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 13 of 41
Table 5 – Assumptions
Name Description
A.PLATFORM The TOE is installed on the appropriate, dedicated hardware and the platform contains only the
approved applications needed to support the TOE as per the installation guidance.
A.NETCON The TOE environment provides network connectivity between the TOE and external networks.
A.TIMESTAMP The IT environment provides the TOE with the necessary and reliable timestamps.
A.PHYSICAL The TOE is located within a controlled access facility.
A.PROTECT The TOE software will be protected from unauthorized modification.
A.ADMIN There are one or more competent individuals assigned to manage the TOE and the security of
the information it contains.
A.AUTHENTICATION The platform that the TOE is installed on will provide adequate authentication methods for TOE
administrators.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 14 of 41
4. Security Objectives
Security objectives are concise, abstract statements of the intended solution to the problem defined by the
security problem definition (see Section 3). The set of security objectives for a TOE form a high-level solution to
the security problem. This high-level solution is divided into two part-wise solutions: the security objectives for
the TOE, and the security objectives for the TOE’s operational environment. This section identifies the security
objectives for the TOE and its supporting environment.
4.1 Security Objectives for the TOE
The specific security objectives for the TOE are listed in Table 6 below.
Table 6 – Security Objectives for the TOE
Name Description
O.ACCESS The TOE must enforce an access control policy to provide appropriate access to administrators that view or
manage TOE resources based on their assigned roles.
O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data.
O.AUDIT The TOE must record events of security relevance at the “not specified level” of audit. The TOE must record the
resulting actions of the security functional policies and provide the authorized administrators with the ability to
review the audit trail.
O.IDENTIFY The TOE must be able to identify administrators prior to allowing access to TOE administrative functions and
data.
O.FLOW The TOE must ensure that data will flow only as defined in the Information Flow SFPs.
4.2 Security Objectives for the Operational Environment
This section describes the environmental objectives.
4.2.1 IT Security Objectives
Table 7 below lists the IT security objectives that are to be satisfied by the environment.
Table 7 – IT Security Objectives
Name Description
OE.TIME The TOE environment must provide reliable timestamps to the TOE.
OE.PROTECT The TOE environment must protect itself and the TOE from external access attempts or attempts to intercept
the data transiting the TOE. The TOE environment must provide logical and physical security controls to protect
the network resources and data at the level appropriate to the sensitivity of the data.
OE.PLATFORM The TOE relies upon a trustworthy computing platform for its execution. The hardware and RHEL OS with
SELinux and Iptables modules are installed according to the guidance to provide the functionality necessary to
support the secure operation of the TOE.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 15 of 41
Name Description
OE.NETWORK The TOE environment must be implemented such that the TOE is logically connected to only the defined
external inbound and outbound networks and to no other networks.
OE.AUTHENTICATE The TOE environment must provide user authentication.
4.2.2 Non-IT Security Objectives
Table 8 below lists the non-IT environment security objectives that are to be satisfied without imposing technical
requirements on the TOE. That is, they will not require the implementation of functions in the TOE hardware
and/or software. Thus, they will be satisfied largely through application of procedural or administrative measures.
Table 8 – Non-IT Security Objectives
Name Description
NOE.ADMIN Sites deploying the TOE will provide competent, non-hostile administrators who are appropriately trained and
follow all administrator guidance. Administrators will ensure the system is used securely.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 16 of 41
5. Extended Components
There are no extended SFRs and no extended Security Assurance Requirements (SAR) for the TOE.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 17 of 41
6. Security Requirements
This section defines the SFRs and SARs met by the TOE. These requirements are presented following the
conventions identified in Section 6.1.
6.1 Conventions
There are several font variations used within this ST. Selected presentation choices are discussed here to aid the
Security Target reader.
The CC allows for assignment, refinement, selection and iteration operations to be performed on security
functional requirements. All these operations are used within this ST. These operations are performed as
described in Part 2 of the CC and are shown as follows:
• Completed assignment statements are identified using [italicized text within brackets].
• Completed selection statements are identified using [underlined text within brackets].
• Completed selection statements that include assignment statements are identified using [underlined and
italicized text within brackets].
• Iterations are identified by appending a letter in parentheses following the component title. For example,
FAU_GEN.1(a) Audit Data Generation would be the first iteration and FAU_GEN.1(b) Audit Data
Generation would be the second iteration.
6.2 Security Functional Requirements
This section specifies the SFRs for the TOE. This section organizes the SFRs by CC class. Table 9 identifies all SFRs
implemented by the TOE and indicates the ST operations performed on each requirement.
Table 9 – TOE Security Functional Requirements
Name Description S A R I
FAU_GEN.1 Audit data generation ✓ ✓
FAU_SAR.1 Audit review ✓
FDP_IFC.1(a) Subset information flow control (INPA Interface) ✓ ✓
FDP_IFC.1(b) Subset information flow control (ONPA Interface) ✓ ✓
FDP_IFC.1(c) Subset information flow control (Flow) ✓ ✓
FDP_IFF.1(a) Simple security attributes (INPA Interface) ✓ ✓
FDP_IFF.1(b) Simple security attributes (ONPA Interface) ✓ ✓
FDP_IFF.1(c) Simple security attributes (Flow) ✓ ✓
FIA_UID.2 User identification before any action
FMT_MSA.1(a) Management of security attributes (INPA Interface) ✓ ✓ ✓
FMT_MSA.1(b) Management of security attributes (ONPA Interface) ✓ ✓ ✓
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 18 of 41
Name Description S A R I
FMT_MSA.1(c) Management of security attributes (Flow) ✓ ✓ ✓
FMT_MSA.3(a) Static attribute initialisation (INPA Interface) ✓ ✓ ✓
FMT_MSA.3(b) Static attribute initialisation (ONPA Interface) ✓ ✓ ✓
FMT_MSA.3(c) Static attribute initialisation (Flow) ✓ ✓ ✓
FMT_SMF.1 Specification of management functions ✓
FMT_SMR.1 Security roles ✓
Note: S=Selection; A=Assignment; R=Refinement; I=Iteration
6.2.1 Class FAU: Security Audit
FAU_GEN.1 Audit Data Generation
Hierarchical to: No other components.
Dependencies: FPT_STM.1 Reliable time stamps
FAU_GEN.1.1
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, for the [not specified] level of audit; and
c. [
• Configuration changes
• Commands entered from the CLI
• Flow events
].
FAU_GEN.1.2
The TSF shall record within each audit record at least the following information:
• Date and time of the event, type of event, subject identity (if applicable), and the outcome
(success or failure) of the event; and
• For each audit event type, based on the auditable event definitions of the functional components
included in the PP/ST, [and the following audit fields in the log files:
• Xguard-flow.log and xguard-admin.log fields:
o Severity
o Timestamp
o Hostname
o Component
o Token name (which contains the command arguments)
]
FAU_SAR.1 Audit review
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_SAR.1.1
The TSF shall provide [RW administrators] with the capability to read [all audit information] from the audit
records.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 19 of 41
FAU_SAR.1.2
The TSF shall provide the audit records in a manner suitable for the user to interpret the information.
6.2.2 Class FDP: User Data Protection
FDP_IFC.1(a) Subset information flow control (INPA Interface)
Hierarchical to: No other components.
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1(a)
The TSF shall enforce the [INPA Information Flow SFP] on
[
• Subject: INPA interface
• Information: Inbound data traffic
• Operations: Allow or deny the flow of controlled information to the INPA interface as defined by
the INPA Information Flow SFP
].
FDP_IFC.1(b) Subset information flow control (ONPA Interface)
Hierarchical to: No other components.
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1(b)
The TSF shall enforce the [ONPA Information Flow SFP] on
[
• Subject: ONPA interface
• Information: Outbound data traffic and responses to inbound requests
• Operations: Allow or deny the flow of controlled information from the controlled ONPA interface
as defined by the ONPA Information Flow SFP.
].
FDP_IFC.1(c) Subset information flow control (Flow)
Hierarchical to: No other components.
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1(c)
The TSF shall enforce the [Flow SFP] on
[
• Subject: DFP
• Information: Data flow between the INPA and the ONPA
• Operations: Allow or deny the flow of controlled information between the controlled INPA and
ONPA via the controlled DFP as defined by the Flow SFP.
].
FDP_IFF.1(a) Simple security attributes (INPA Interface)
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialization
FDP_IFF.1.1(a)
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 20 of 41
The TSF shall enforce the [INPA Information Flow SFP] based on the following types of subject and
information security attributes:
[
• Subject – INPA Interface with security attributes:
o Network interface name
o Zone
o IP address
o Subnet mask
• Information – Inbound data traffic with security attributes:
o Protocol type (UDP, TCP)
o Protocol state ( UDP, TCP states: new, established)
]
FDP_IFF.1.2(a)
The TSF shall permit an information flow between a controlled subject and controlled information via a
controlled operation if the following rules hold: [if the configured policies allow the information flow based
on a combination of subject security attributes and information security attributes, then the data is
allowed to flow.].
FDP_IFF.1.3(a)
The TSF shall enforce the [no additional information flow control SFP rules].
FDP_IFF.1.4(a)
The TSF shall explicitly authorize an information flow based on the following rules: [no explicit
authorization rules].
FDP_IFF.1.5(a)
The TSF shall explicitly deny an information flow based on the following rules: [no data can flow until the
INPA is configured].
FDP_IFF.1(b) Simple security attributes (ONPA Interface)
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialization
FDP_IFF.1.1(b)
The TSF shall enforce the [ONPA Information Flow SFP] based on the following types of subject and
information security attributes:
[
• Subject – ONPA Interface with security attributes:
o Network interface name
o Zone
o IP address
o Subnet mask
• Information – Outbound traffic security attributes:
o Destination IP address
o Destination port
o Network interface name
o Protocol type (UDP, TCP)
o Protocol state (UDP, TCP states: new, established)
]
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 21 of 41
FDP_IFF.1.2(b)
The TSF shall permit an information flow between a controlled subject and controlled information via a
controlled operation if the following rules hold: [if the configured policies allow the information flow based
on a combination of subject security attributes and information security attributes, then the data is
allowed to flow.].
FDP_IFF.1.3(b)
The TSF shall enforce the [no additional information flow control SFP rules].
FDP_IFF.1.4(b)
The TSF shall explicitly authorize an information flow based on the following rules: [no explicit
authorization rules].
FDP_IFF.1.5(b)
The TSF shall explicitly deny an information flow based on the following rules: [no data can flow until the
ONPA is configured]].
FDP_IFF.1(c) Simple security attributes (Flow)
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialization
FDP_IFF.1.1(c)
The TSF shall enforce the [Flow SFP] based on the following types of subject and information security
attributes:
[
• Subject – DFP with security attributes
o Service
▪ Service name
▪ Flow type (TCP or UDP)
▪ Directional mode (bidirectional or unidirectional)
▪ Data mode (message (TCP, UDP), stream (UDP))
o Filter
▪ Filter name
▪ Filter type
▪ Filter file name
o Flow
▪ Flow name
▪ Client IP address
▪ Client subnet mask
▪ Source network interface name
▪ Service port (server/listening port facing inbound)
▪ Service name
▪ Filter name
▪ Destination network interface name
▪ Destination IP address:port
• Information – Data traffic with security attributes:
o Source IP address
o Destination IP address
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 22 of 41
o Destination port
o Network interface name
o Protocol type (UDP, TCP)
o Protocol state (UDP, TCP states: New, Established)
].
FDP_IFF.1.2(c)
The TSF shall permit an information flow between a controlled subject and controlled information via a
controlled operation if the following rules hold: [if the configured policies allow the information flow based
on a combination of subject security attributes and information security attributes, then the data is
allowed to flow.].
FDP_IFF.1.3(c)
The TSF shall enforce the [no additional information flow control SFP rules].
FDP_IFF.1.4(c)
The TSF shall explicitly authorize an information flow based on the following rules: [no explicit
authorization rules].
FDP_IFF.1.5(c)
The TSF shall explicitly deny an information flow based on the following rules: [no data can flow until the
service, filter, and flow are defined].
6.2.3 Class FIA: Identification and Authentication
FIA_UID.2 User identification before any action
Hierarchical to: FIA_UID.1 Timing of identification
Dependencies: No dependencies
FIA_UID.2.1
The TSF shall require each user to be successfully identified before allowing any other TSF-mediated
actions on behalf of that user.
6.2.4 Class FMT: Security Management
FMT_MSA.1(a) Management of security attributes (INPA Interface)
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MSA.1.1(a)
The TSF shall enforce the [INPA Information Flow SFP] to restrict the ability to [query, modify, delete] the
security attributes [listed in the INPA Security Attributes column in Table 10] to [the roles and operations
listed in the Role and Operation columns in Table 10].
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 23 of 41
Table 10 – Security Attributes (INPA Interface)
Role Operation INPA Security Attributes
RO Query • Subject – INPA Interface with security attributes:
o Network interface name
o Zone
o IP address
o Subnet mask
• Information – Inbound data with security attributes:
o Protocol type (UDP, TCP)
o Protocol state (UDP, TCP states: new, established)
RW Query, Modify, Delete
FMT_MSA.1(b) Management of security attributes (ONPA Interface)
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MSA.1.1(b)
The TSF shall enforce the [ONPA Information Flow SFP] to restrict the ability to [query, modify, delete] the
security attributes [listed in the ONPA Security Attributes column in Table 11] to [the roles and operations
listed in the Role and Operation columns in Table 11].
Table 11 – Security Attributes (ONPA Interface)
Role Operation ONPA Security Attributes
RO Query • Subject – ONPA Interface with security attributes:
o Network interface name
o Zone
o IP address
o Subnet mask
• Information – Outbound data with security attributes:
o Destination IP address
o Destination port
o Network interface name
o Protocol type (UDP, TCP)
o Protocol state ( UDP, TCP states: new, established)
RW Query, Modify, Delete
FMT_MSA.1(c) Management of security attributes (Flow)
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MSA.1.1(c)
The TSF shall enforce the [Flow SFP] to restrict the ability to [query, modify, delete] the security attributes
[listed in the Flow Security Attributes column in Table 12 and specified in the SFPs] to [the roles and
operations listed in the Role and Operation columns in Table 12].
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 24 of 41
Table 12 – Security Attributes (Flow)
Role Operation Flow Security Attributes
RO Query • Subject – DFP
o Service – Service name, Flow type, Directional mode, Data mode
o Filter – Filter name, Filter type, Filter file name
o Flow – Flow name, Flow type, Client IP address, Client subnet mask, Source network
interface name, Service port, Service name, Filter name, Destination network
interface name, Destination IP address:port
• Information – Data traffic between the INPA and ONPA interfaces
o Source IP address
o Destination IP address
o Destination port
o Network interface name
o Protocol type (UDP, TCP)
o Protocol state (UDP, TCP states: New, Established)
RW Query, Modify, Delete
FMT_MSA.3(a) Static attribute initialization (INPA Interface)
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1(a)
The TSF shall enforce the [INPA Information Flow SFP] to provide [restrictive] default values for security
attributes that are used to enforce the SFP.
FMT_MSA.3.2(a)
The TSF shall allow the [RW administrator] to specify alternative initial values to override the default
values when an object or information is created.
FMT_MSA.3(b) Static attribute initialization (ONPA Interface)
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1(b)
The TSF shall enforce the [ONPA Information Flow SFP] to provide [restrictive] default values for security
attributes that are used to enforce the SFP.
FMT_MSA.3.2(b)
The TSF shall allow the [RW administrator] to specify alternative initial values to override the default
values when an object or information is created.
FMT_MSA.3(c) Static attribute initialization (Flow)
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1(c)
The TSF shall enforce the [Flow SFP] to provide [restrictive] default values for security attributes that are
used to enforce the SFP.
FMT_MSA.3.2(c)
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 25 of 41
The TSF shall allow the [RW administrator] to specify alternative initial values to override the default
values when an object or information is created.
FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No Dependencies
FMT_SMF.1.1
The TSF shall be capable of performing the following management functions:
[
• Assign a role to an account
• Review audit records
• Import Lua files
• Configure the INPA and ONPA Interface security attributes
• Configure the Flow security attributes
].
FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1
The TSF shall maintain the roles [RO and RW].
FMT_SMR.1.2
The TSF shall be able to associate users with roles.
6.3 Security Assurance Requirements
This section defines the assurance requirements for the TOE. Assurance requirements are taken from the CC Part
3 and are EAL4+ augmented with ALC_FLR.2. Table 13 summarizes these requirements.
Table 13 – Assurance Requirements
Assurance Requirements
Class ASE: Security Target evaluation 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
ASE_TSS.1 TOE summary specification
Class ALC: Life Cycle Support ALC_CMC.4 Production support, acceptance procedures and automation
ALC_CMS.4 Problem tracking CM Coverage
ALC_DEL.1 Delivery procedures
ALC_DVS.1 Identification of security measures
ALC_FLR.2 Flaw reporting procedures
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 26 of 41
Assurance Requirements
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
Class ADV: Development ADV_ARC.1 Security architecture description
ADV_FSP.4 Complete functional specification
ADV_IMP.1 Implementation representation of the TSF
ADV_TDS.3 Basic modular design
Class AGD: Guidance documents AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Class ATE: Tests ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: basic design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing – sample
Class AVA: Vulnerability assessment AVA_VAN.3 Focused vulnerability analysis
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 27 of 41
7. TOE Summary Specification
This section presents information to detail how the TOE meets the functional requirements described in previous
sections of this ST.
7.1 TOE Security Functionality
Each of the security requirements and the associated descriptions correspond to a security functionality. Hence,
each security functionality is described by how it specifically satisfies each of its related requirements. This serves
to both describe the security functionality and rationalize that the security functionality satisfies the necessary
requirements. Table 14 lists the security functionality and their associated SFRs.
Table 14 – Mapping of TOE Security Functionality to Security Functional Requirements
TOE Security Functionality SFR ID Description
Security Audit FAU_GEN.1 Audit Data Generation
FAU_SAR.1 Audit review
User Data Protection FDP_IFC.1(a) Subset information flow control (INPA Interface)
FDP_IFC.1(b) Subset information flow control (ONPA Interface)
FDP_IFC.1(c) Subset information flow control (Flow)
FDP_IFF.1(a) Simple security attributes (INPA Interface)
FDP_IFF.1(b) Simple security attributes (ONPA Interface)
FDP_IFF.1(c) Simple security attributes (Flow)
Identification and Authentication FIA_UID.2 User identification before any action
Security Management FMT_MSA.1(a) Management of security attributes (INPA Interface)
FMT_MSA.1(b) Management of security attributes (ONPA Interface)
FMT_MSA.1(c) Management of security attributes (Flow)
FMT_MSA.3(a) Static attribute initialisation (INPA Interface)
FMT_MSA.3(b) Static attribute initialisation (ONPA Interface)
FMT_MSA.3(c) Static attribute initialisation (Flow)
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
7.1.1 Security Audit
The TOE generates audit records for the startup and shutdown of the TOE components. The startup and shutdown
of the TOE components results in the startup and shutdown of the audit functionality. The TOE also generates
audit records for configuration changes, commands entered from the CLI, and flow events. The TOE-generated
audit events are written to the xguard-admin.log and xguard-flow.log files. The xguard-admin.log file contains
audit records for events generated by successful commands entered by administrators from the CLI, and
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 28 of 41
configuration events generated by administrator activity in the DFM module. The xguard-flow.log file includes
startup and shutdown of the audit function events, NPA events and information about the type of flow and flow
metrics.
An administrator can view the log files from the CLI by issuing the log view4
command, followed by either the
admin5
or flow keyword. For example, to view the xguard-admin.log file, a RW administrator enters the log
view admin command and uses optional parameters to view logs in their entirety or to filter what is displayed.
The audit startup and shutdown is logged in the xguard-flow.log file. The startup and shutdown of the TOE
coincides with the startup and shutdown of the auditd function. When the TOE starts up an audit record is
generated with event ID 9000, “evt=9000”, and the message “msg=Starting Forcepoint Data Guard”. When the
TOE shuts down an audit event is generated with event ID9001, “evt=9001”, and the message “msg=Stopping
Forcepoint Data Guard.”. These records can be viewed from the FDG CLI TSFI by a RW administrator using the log
view flow display find evt=9000 or log view flow display find evt=9001 commands.
The TOE environment provides the reliable timestamps for the audit records.
Table 15 describes the fields and token name arguments contained in both the xguard-admin.log and xguard-
flow.log files, except for the Component* field, which is not in the xguard-admin.log file. Any combination of
token name command arguments can be in both files.
Table 15 – Admin and Flow Log Files
Field Name Description
Severity This field identifies the severity of the event.
Timestamp This field identifies the timestamp in MM DD HH:MM:SS Linux UTC format.
Hostname This field identifies the hostname.
Component* This field identifies the component, which can have the following values: xg-in-npa-tcp, xg-out-npa-tcp, xg-in-npa-tcp-
udp, xg-out-npa-udp,
Token name This field identifies the token name, which contains the command arguments.
Token Name
Argument
Description
evt This argument provides the Event ID.
user This argument provides the user name.
uid This argument identifies the user id.
flow This argument provides the flow name.
dir This argument provides the flow direction, either “fwd” or “rev”.
id This argument provides the connection id or file id.
action This argument provides the action.
status This argument provides the status.
server This argument provides the server name.
4 Commands are rendered in bolded Courier New font.
5 Keywords used with commands are rendered in bolded, italicized, Courier New font.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 29 of 41
Field Name Description
cmd This argument provides the command name.
src This argument provides the source IP that an event refers to.
dst This argument provides the destination IP that an event refers to.
spt This argument provides the source port.
dpt This argument provides the destination port.
errno This argument provides the errno number from the sys call.
sterror This argument provides the message describing the errno.
func This argument provides the sys call name.
caller This argument provides the caller of sys call.
fmsg This argument provides the user message.
msg This argument provides the detail message (last one).
name This argument provides the file name.
TOE Security Functional Requirements Satisfied: FAU_GEN.1, FAU_SAR.1.
7.1.2 User Data Protection
The TOE is installed in a secure DENY ALL configuration. The INPA and ONPA interfaces must be configured before
receiving any data and no data is allowed to flow until the DFP’s interface, service, filter, and flow security
attributes are defined. Data is inspected at the TOE boundary by the INPA for a matching IP address and subnet
mask to determine if traffic is passed or dropped. If the traffic is passed, then the data is buffered and is read by
the DFP. The DFP reads the buffered inbound data and applies filtering logic to determine if data is passed to the
ONPA, or is dropped. The DFP filtering decisions are based on a service definition, Lua filter rules, and flow
attributes. A service definition includes the following: service name, flow type (TCP or UDP), directional mode
(unidirectional or bidirectional), and data mode (stream or message). The service definition determines what
filtering rules are applied by the DFP and include the following attributes: assigned filter name, filter type, and
filter file name. The ONPA receives its data payload from the DFP if the IP address and subnet mask security
attributes match, otherwise it is dropped. If allowed to pass the ONPA sends the DFP-filtered data to an external
destination endpoint. If the bidirectional mode is defined, then responses to originating requests are sent from
the ONPA to the DFP. The DFP filters the reverse data. There are default rules for matching related and established
flows that allow for reverse traffic to flow without needing explicit rules. If the Lua rule file does not have the
reverse data flow defined within it, then no reverse data is allowed.
The global configuration file and any affected individual configuration files for INPA, ONPA, and DFP are updated
after a RW administrator makes changes from the CLI. The changes take effect after a restart. A RW administrator
can enter the flow restart command or a restart can be initiated by DFM. Please see section 6.2.2 for the
complete list of INPA, ONPA, and Flow security attributes.
A RW administrator creates Lua files and imports them to the TOE using the import_files command from the
FDG CLI. When a flow enters an interface, it is buffered and passed to the DFP. The DFP uses its internal XG filter
functions to interact with the Lua filters. The DFP processes the buffered data against the filtering rules in the
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 30 of 41
named Lua file. If the buffered data is allowed, the data flows between the NPA interfaces, otherwise the data is
dropped from the flow.
There are default rules for matching related and established flows that allow for reverse traffic to flow without
needing explicit rules. The DFP filters the reverse data. If the Lua rule file does not have the reverse data flow
defined within it, then no reverse data is allowed.
TOE Security Functional Requirements Satisfied: FDP_IFC.1(a), FDP_IFC.1(b), FDP_IFC.1(c), FDP_IFF.1(a),
FDP_IFF.1(b), FDP_IFF.1(c).
7.1.3 Identification and Authentication
No TSF functionality is available to an administrator until the administrator is identified by the TOE. The
administrator enters their credentials at the FDG CLI. After the administrator’s credentials are verified, the TOE
identifies the administrator by associating the administrator’s username with the username of the logged in
account. The administrator assumes the account’s assigned role and the role’s privileges and access to the TOE.
TOE Security Functional Requirements Satisfied: FIA_UID.2.
7.1.4 Security Management
The TOE allows authorized administrators to configure and manage its security functionality from the FDG CLI.
Administrators can connect to the FDG CLI using either a remote SSH connection or a local console connection.
The administrator is assigned the role associated with the logged in account and the TOE grants privileges
associated with the account. There are only two TOE roles: read-write (RW) and read-only (RO). The RW role,
which is assigned to a RW administrator, provides complete administrative access to configure and manage the
TOE. The RO role, which is assigned to a RO administrator, provides read-only access and includes limited
privileges to view configuration data.
The FDG CLI has four modes and each mode has a set of commands for configuration and management of the TOE.
The role assigned to an administrator determines which mode or modes can be accessed. The Standard Mode is
a read-only mode that is limited to read-only commands. Privileged Mode is a mode that provides all available
commands. Configuration Mode is a mode that provides only configuration commands. Configuration Submodes
is a mode that provides only the configuration commands relevant to the feature being configured or managed.
All administrators can access the Standard Mode but only RW administrators can access the other modes.
Only a RW administrator can manage the TOE’s security functionality. From the FDG CLI a RW administrator
performs the following management tasks:
• Assign a role to an account using the user add <user name> <RO|RW> command.
• Review audit records using the log view <admin|flow> command.
• Import Lua files using the import_files <path to Lua file> command.
• Configure the INPA, ONPA, and Flow security attributes using the commands from Chapter 6.2
“Configuring a TCP/UDP Data Flow” in the FDG Admin Guide.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 31 of 41
Please see section 6.2.4 for the INPA, ONPA, and Flow security attributes that are configured by a RW
administrator.
The TOE is installed with the default Admin account. New accounts are added with the default account and
associated with either the RO or RW role.
A RW administrator uses the FDG CLI to configure the security attributes and the data flows. To allow a flow, a
RW administrator must import a Lua file, configure the INPA and ONPA interfaces, and configure the Flow security
attributes listed under the Service, Filter, and Flow bullet points above.
TOE Security Functional Requirements Satisfied: FMT_MSA.1(a), FMT_MSA.1(b), FMT_MSA.1(c), FMT_MSA.3(a),
FMT_MSA.3(b), FMT_MSA.3(c), FMT_SMF.1, FMT_SMR.1.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 32 of 41
8. Rationale
8.1 Conformance Claims Rationale
This Security Target conforms to Part 2 and Part 3 of the Common Criteria for Information Technology Security
Evaluation, Version 3.1 Release 5.
8.2 Security Objectives Rationale
This section provides a rationale for the existence of each threat, policy statement, and assumption that compose
the Security Target. Sections 8.2.1 and 8.2.2 demonstrate the mappings between the threats, policies, and
assumptions to the security objectives are complete. The following discussion provides detailed evidence of
coverage for each threat, policy, and assumption.
8.2.1 Security Objectives Rationale Relating to Threats
Table 16 below provides a mapping of the objectives to the threats they counter.
Table 16 – Threats: Objectives Mapping
Threats Objectives Rationale
T.FLOW
An attacker may try to gain access to
the destination network or to data in
transit to the destination network by
bypassing the data flow policies placed
on the networks.
O.AUDIT
The TOE must record events of security
relevance at the “not specified level” of audit.
The TOE must record the resulting actions of
the security functional policies and provide the
authorized administrators with the ability to
review the audit trail.
O.AUDIT ensures that security relevant events
that may indicate attempts to tamper with the
TOE’s flow policies are recorded.
O.FLOW
The TOE must ensure that data will flow only as
defined in the Information Flow SFPs.
O.FLOW ensures that data flows only as
defined by the Information Flow SFPs, which is
only configurable by a RW administrator and
cannot be bypassed.
T.REVERSE_FLOW
An attacker may try to gain access to
the data that is sent in reply from the
destination network by bypassing the
data flow policies placed on the
networks.
O.AUDIT
The TOE must record events of security
relevance at the “not specified level” of audit.
The TOE must record the resulting actions of
the security functional policies and provide the
authorized administrators with the ability to
review the audit trail.
O.AUDIT ensures that security relevant events
that may indicate attempts to tamper with the
TOE’s flow policies are recorded.
O.FLOW
The TOE must ensure that data will flow only as
defined in the Information Flow SFPs.
O.FLOW ensures that data flows only as
defined by the Information Flow SFPs, which is
only configurable by a RW administrator and
cannot be bypassed.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 33 of 41
Threats Objectives Rationale
T.UNDETECTED_ACTIONS
An attacker may take actions that
adversely affect the security of the TOE
assets and these actions remain
undetected so that their effects cannot
be effectively countered.
O.AUDIT
The TOE must record events of security
relevance at the “not specified level” of audit.
The TOE must record the resulting actions of
the security functional policies and provide the
authorized administrators with the ability to
review the audit trail.
O.AUDIT ensures that security relevant events
for all configuration changes made to the TOE
and data flow events performed by the TOE are
recorded.
T.UNPRIVILEGED
An underprivileged user may try to
change the TOE configuration and
compromise its security functions.
O.ACCESS
The TOE must enforce an access control policy
to provide appropriate access to
administrators that view or manage TOE
resources based on their assigned roles.
O.ACCESS ensures that an attacker cannot
access the TOE, which can only be accessed by
an identified administrator with an assigned
role. The administrator’s role determines what
command line functionality is available to the
administrator.
O.ADMIN
The TOE must include a set of functions that
allow efficient management of its functions
and data.
O.ADMIN ensures that the TOE provides the
management functionality necessary to
manage TOE functions and data.
O.AUDIT
The TOE must record events of security
relevance at the “not specified level” of audit.
The TOE must record the resulting actions of
the security functional policies and provide the
authorized administrators with the ability to
review the audit trail.
O.AUDIT ensures that unauthorized attempts
to access the TOE are recorded.
O.IDENTIFY
The TOE must be able to identify
administrators prior to allowing access to TOE
administrative functions and data.
O.IDENTIFY ensures that all administrators that
attempt to access the TOE are identified as
administrators with permission to use the TOE
before they can perform any actions.
Every threat is mapped to one or more objectives in the table above. This complete mapping demonstrates that
the defined security objectives counter all defined threats.
8.2.2 Security Objectives Rationale Relating to Assumptions
Table 17 below gives a mapping of assumptions and the environmental objectives that uphold them.
Table 17 – Assumptions: Objectives Mapping
Assumptions Objectives Rationale
A.PLATFORM
The TOE is installed on the appropriate,
dedicated hardware and the platform
contains only the approved applications
needed to support the TOE as per the
installation guidance.
OE.PLATFORM
The TOE relies upon a trustworthy computing
platform for its execution. The hardware and
RHEL OS with SELinux and Iptables modules are
installed according to the guidance to provide
the functionality necessary to support the
operation of the TOE.
OE.PLATFORM ensures that the administrator-
installed hardware and RHEL OS with SELinux
modules provide the functionality necessary to
support the TOE.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 34 of 41
Assumptions Objectives Rationale
NOE.ADMIN
Sites deploying the TOE will provide
competent, non-hostile administrators who
are appropriately trained and follow all
administrator guidance. Administrators will
ensure the system is used securely.
The TOE is installed on the appropriate,
dedicated hardware and the platform contains
only the approved software required to
support the TOE.
A.NETCON
The TOE environment provides network
connectivity between the TOE and
external networks.
OE.NETWORK
The TOE environment must be implemented
such that the TOE is appropriately located
within the network to perform its intended
function.
OE.NETWORK satisfies the assumption that the
TOE will be deployed with the appropriate
network connections.
A.TIMESTAMP
The IT environment provides the TOE
with the necessary and reliable
timestamps.
OE.TIME
The TOE environment must provide reliable
timestamps to the TOE.
OE.TIME satisfies the assumption that the
environment provides reliable timestamps to
the TOE.
A.PHYSICAL
The TOE is located within a controlled
access facility.
OE.PROTECT
The TOE environment must protect itself and
the TOE from external access attempts or
attempts to intercept the data transiting the
TOE. The TOE environment must provide
logical and physical security controls to protect
the network resources and data at the level
appropriate to the sensitivity of the data.
OE.PROTECT satisfies the assumption that
physical security is provided within the TOE
environment to provide appropriate protection
to the network resources.
A.PROTECT
The TOE software will be protected
from unauthorized modification.
OE.PROTECT
The TOE environment must protect itself and
the TOE from external access attempts or
attempts to intercept the data transiting the
TOE. The TOE environment must provide
logical and physical security controls to protect
the network resources and data at the level
appropriate to the sensitivity of the data.
OE.PROTECT satisfies the assumption that the
TOE environment provides security controls,
which protect the TOE software from external
interference or tampering.
A.ADMIN
There are one or more competent
individuals assigned to manage the TOE
and the security of the information it
contains.
NOE.ADMIN
Sites deploying the TOE will provide
competent, non-hostile administrators who
are appropriately trained and follow all
administrator guidance. Administrators will
ensure the system is used securely.
NOE.ADMIN satisfies the assumption that the
TOE administrators are non-hostile,
appropriately trained and follow all guidance.
A.AUTHENTICATION
The platform that the TOE is installed
on will provide adequate
authentication methods for TOE
administrators.
OE.AUTHENTICATE
The TOE environment must provide OS
authentication.
OE.AUTHENTICATE satisfies the assumption
that TOE administrators are authenticated by
the OS.
Every assumption is mapped to one or more objectives in the table above. This complete mapping demonstrates
that the defined security objectives uphold all defined assumptions.
8.3 Rationale for Extended Security Functional Requirements
There are no extended security functional requirements defined for this TOE.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 35 of 41
8.4 Rationale for Extended TOE Security Assurance
Requirements
There are no extended TOE security assurance requirements defined for this TOE.
8.5 Security Requirements Rationale
The following discussion provides detailed evidence of coverage for each security objective.
8.5.1 Rationale for Security Functional Requirements of the TOE
Objectives
Table 18 below shows a mapping of the objectives and the SFRs that support them.
Table 18 – Objectives: SFRs Mapping
Objective Requirements Addressing the Objective Rationale
O.ACCESS
The TOE must enforce an access
control policy to provide
appropriate access to
administrators that view or
manage TOE resources based
on their assigned roles.
FAU_SAR.1
Audit review
The requirement supports the O.ACCESS
objective by ensuring that only authorized
administrators with the RW role can view the
audit data.
FMT_MSA.1(a)
Management of security attributes (INPA Interface)
The requirement meets the O.ACCESS objective
by ensuring that only the identified
administrators are allowed role-based access to
the administrative functions to manage the
security behavior of the TOE.
FMT_MSA.1(b)
Management of security attributes (ONPA Interface)
The requirement meets the O.ACCESS objective
by ensuring that only the identified
administrators are allowed role-based access to
the administrative functions to manage the
security behavior of the TOE.
FMT_MSA.1(c)
Management of security attributes (Flow)
The requirement meets the O.ACCESS objective
by ensuring that only the identified
administrators are allowed role-based access to
the administrative functions to manage the
security behavior of the TOE.
FMT_MSA.3(a)
Static attribute initialisation (INPA Interface)
The requirement meets the O.ACCESS objective
by ensuring that only the identified
administrators are allowed role-based access to
the administrative functions to manage the
security behavior of the TOE.
FMT_MSA.3(b)
Static attribute initialisation (ONPA Interface)
The requirement meets the O.ACCESS objective
by ensuring that only the identified
administrators are allowed role-based access to
the administrative functions to manage the
security behavior of the TOE.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 36 of 41
Objective Requirements Addressing the Objective Rationale
FMT_MSA.3(c)
Static attribute initialisation (Flow)
The requirement meets the O.ACCESS objective
by ensuring that only the identified
administrators are allowed role-based access to
the administrative functions to manage the
security behavior of the TOE.
O.ADMIN
The TOE must include a set of
functions that allow efficient
management of its functions
and data.
FMT_MSA.1(a)
Management of security attributes (INPA Interface)
The requirement meets the O.ADMIN objective
by ensuring that the TOE provides the
functionality required to manage the TOE
security attributes.
FMT_MSA.1(b)
Management of security attributes (ONPA Interface)
The requirement meets the O.ADMIN objective
by ensuring that the TOE provides the
functionality required to manage the TOE
security attributes.
FMT_MSA.1(c)
Management of security attributes (Flow)
The requirement meets the O.ADMIN objective
by ensuring that the TOE provides the
functionality required to manage the TOE
security attributes.
FMT_MSA.3(a)
Static attribute initialisation (INPA Interface)
The requirement meets the O.ADMIN objective
by ensuring that the TOE provides restrictive
default values for security attributes and
specifies alternative initial values to override the
default values when an object or information is
created.
FMT_MSA.3(b)
Static attribute initialisation (ONPA Interface)
The requirement meets the O.ADMIN objective
by ensuring that the TOE provides restrictive
default values for security attributes and
specifies alternative initial values to override the
default values when an object or information is
created.
FMT_MSA.3(c)
Static attribute initialisation (Flow)
The requirement meets the O.ADMIN objective
by ensuring that the TOE provides restrictive
default values for security attributes and
specifies alternative initial values to override the
default values when an object or information is
created.
FMT_SMF.1
Specification of management functions
The requirement meets the O.ADMIN objective
by ensuring that the TOE includes administrative
functions to facilitate the management of the
TSF.
FMT_SMR.1
Security roles
The requirement meets the O.ADMIN objective
by ensuring that the TOE associates
administrators with roles to provide access to TSF
management functions and data.
O.AUDIT
The TOE must record events of
security relevance at the “not
specified level” of audit. The
TOE must record the resulting
FAU_GEN.1
Audit Data Generation
The requirement supports the O.AUDIT objective
by ensuring that the TOE generates security
related events, including relevant details about
the event which provide information for the
management of the TSF.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 37 of 41
Objective Requirements Addressing the Objective Rationale
actions of the security
functional policies and provide
the authorized administrators
with the ability to review the
audit trail.
FAU_SAR.1
Audit review
The requirement meets the O.AUDIT objective by
ensuring that the TOE provides the ability to
review logs.
O.FLOW
The TOE must ensure that data
will flow only as defined in the
Information Flow SFPs.
FDP_IFC.1(a)
Subset information flow control (INPA Interface)
The requirement meets the O.FLOW objective by
ensuring that the TOE enforces information flow
control on the INPA and ONPA interfaces based
on the implemented policy.
FDP_IFC.1(b)
Subset information flow control (ONPA Interface)
The requirement meets the O.FLOW objective by
ensuring that the TOE enforces information flow
control on the INPA and ONPA interfaces based
on the implemented policy.
FDP_IFC.1(c)
Subset information flow control (Flow)
The requirement meets the O.FLOW objective by
ensuring that the TOE enforces information flow
control on the DFP based on the implemented
policy.
FDP_IFF.1(a)
Simple security attributes (INPA Interface)
The requirement meets the O.FLOW objective by
ensuring that the TOE enforces the information
flow control SFP on the INPA and ONPA interfaces
based on the security attributes.
FDP_IFF.1(b)
Simple security attributes (ONPA Interface)
The requirement meets the O.FLOW objective by
ensuring that the TOE enforces the information
flow control SFP on the INPA and ONPA interfaces
based on the security attributes.
FDP_IFF.1(c)
Simple security attributes (Flow)
The requirement meets the O.FLOW objective by
ensuring that the TOE enforces the information
flow control SFP on the DFP based on the security
attributes.
O.IDENTIFY
The TOE must be able to
identify administrators prior to
allowing access to TOE
administrative functions and
data.
FIA_UID.2
User identification before any action
The requirement supports the O.IDENTIFY
objective by ensuring that an administrator is
successfully identified before allowing any other
TOE-mediated actions.
8.5.2 Security Assurance Requirements Rationale
EAL4+ was chosen because it is best suited to address the stated security objectives. EAL4+ challenges vendors to
use best (rather than average) commercial practices. EAL4+ allows the vendor to evaluate their product at a
detailed level while benefitting from the Common Criteria Recognition Agreement, which would recognize the
TOE as an EAL2+ evaluation. The chosen assurance level is appropriate for the threats defined in the environment.
At EAL4+, penetration testing is performed by the evaluator assuming an attack potential of Enhanced-Basic.
The augmentation of ALC_FLR.2 was chosen to give greater assurance of the developer’s on-going flaw
remediation processes.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 38 of 41
8.5.3 Dependency Rationale
The SFRs in this ST satisfy all of the required dependencies listed in the Common Criteria, applicable PPs, and SFRs
explicitly stated in this ST. Table 19 lists each requirement to which the TOE claims conformance and indicates
whether the dependent requirements are included. As the table indicates, all dependencies have been met.
Table 19 – Functional Requirements Dependencies
SFR ID Dependencies Dependency Met Rationale
FAU_GEN.1 FPT_STM.1 ✓ Although FPT_STM.1 is not included, timestamps are provided by the operating
environment and this satisfies the dependency requirement.
FAU_SAR.1 FAU_GEN.1 ✓
FDP_IFC.1(a) FDP_IFF.1(a) ✓
FDP_IFC.1(b) FDP_IFF.1(b) ✓
FDP_IFC.1(c) FDP_IFF.1(c) ✓
FDP_IFF.1(a) FDP_IFC.1(a) ✓
FMT_MSA.3(a) ✓
FDP_IFF.1(b) FDP_IFC.1(b) ✓
FMT_MSA.3(b) ✓
FDP_IFF.1(c) FDP_IFC.1(c) ✓
FMT_MSA.3(c) ✓
FIA_UID.2 No dependencies
FMT_MSA.1(a) FDP_IFC.1(a) ✓
FMT_SMF.1 ✓
FMT_SMR.1 ✓
FMT_MSA.1(b) FDP_IFC.1(b) ✓
FMT_SMF.1 ✓
FMT_SMR.1 ✓
FMT_MSA.1(c) FDP_IFC.1(c) ✓
FMT_SMF.1 ✓
FMT_SMR.1 ✓
FMT_MSA.3(a) FMT_MSA.1(a) ✓
FMT_SMR.1 ✓
FMT_MSA.3(b) FMT_MSA.1(b) ✓
FMT_SMR.1 ✓
FMT_MSA.3(c) FMT_MSA.1(c) ✓
FMT_SMR.1 ✓
FMT_SMF.1 No dependencies
FMT_SMR.1 FIA_UID.1 ✓ Although FIA_UID.1 is not included, FIA_UID.2, which is hierarchical to
FIA_UID.1 is included. This satisfies this dependency.
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 39 of 41
9. Acronyms
Table 20 defines the acronyms used throughout this document.
Table 20 – Acronyms
Acronym Definition
API Application Programming Interface
CC Common Criteria
CD Compact Disk
CEM Common Evaluation Methodology
CLI Command Line Interface
CM Configuration Management
DFM Data Flow Manager
DFP Data Flow Process
EAL Evaluation Assurance Level
EULA End User License Agreement
FDG Forcepoint Data Guard
GB Giga Byte
ID Identification
INPA Inbound Network Protocol Adapter
IP Internet Protocol
IT Information Technology
JSON JavaScript Object Notion
NPA Network Protocol Adapter
ONPA Outbound Network Protocol Adapter
OS Operating System
OSP Organizational Security Policy
PDF Portable Document Format
PP Protection Profile
RHEL Red Hat Enterprise Linux
RO Read-only
RW Read-write
SAR Security Assurance Requirement
SELinux Secure Linux
SFR Security Functional Requirement
Security Target, Version 0.8 March 16, 2020
Forcepoint Data Guard v3.0
©2020 Forcepoint LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 40 of 41
Acronym Definition
SSH Secure Shell
ST Security Target
TCP Transport Control Protocol
TOE Target of Evaluation
TSF TOE Security Functionality
TSS TOE Security Specification
UDP User Datagram Protocol
UTC Universal Time Coordinated
XML Extensible Markup Language
Prepared by:
Corsec Security, Inc.
13921 Park Center Road, Suite 460
Herndon, VA 20171
United States of America
Phone: +1 703 267 6050
Email: info@corsec.com
http://www.corsec.com