Forcepoint NGFW 6.5 (FWcPP20E)
Security Target
Version 1.5
October 7, 2019
Prepared for:
Forcepoint
10900-A Stonelake Blvd.
Austin, TX 78759, USA
www.Forcepoint.com
Prepared By:
www.gossamersec.com
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 2 of 49
1. SECURITY TARGET INTRODUCTION........................................................................................................4
1.1 SECURITY TARGET REFERENCE......................................................................................................................4
1.2 TOE REFERENCE............................................................................................................................................4
1.3 TOE OVERVIEW .............................................................................................................................................5
1.4 TOE DESCRIPTION .........................................................................................................................................5
1.4.1 TOE Architecture...................................................................................................................................5
1.4.2 TOE Documentation ..............................................................................................................................9
2. CONFORMANCE CLAIMS............................................................................................................................10
2.1 CONFORMANCE RATIONALE.........................................................................................................................12
3. SECURITY OBJECTIVES ..............................................................................................................................13
3.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ...................................................................13
4. EXTENDED COMPONENTS DEFINITION ................................................................................................14
5. SECURITY REQUIREMENTS.......................................................................................................................15
5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................15
5.1.1 Security audit (FAU)............................................................................................................................16
5.1.2 Communication (FCO) ........................................................................................................................19
5.1.3 Cryptographic support (FCS)..............................................................................................................19
5.1.4 User data protection (FDP).................................................................................................................22
5.1.5 Firewall (FFW)....................................................................................................................................22
5.1.6 Identification and authentication (FIA) ...............................................................................................24
5.1.7 Security management (FMT) ...............................................................................................................26
5.1.8 Protection of the TSF (FPT) ................................................................................................................27
5.1.9 TOE access (FTA)................................................................................................................................28
5.1.10 Trusted path/channels (FTP)...............................................................................................................28
5.2 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................29
5.2.1 Development (ADV).............................................................................................................................30
5.2.2 Guidance documents (AGD)................................................................................................................30
5.2.3 Life-cycle support (ALC) .....................................................................................................................31
5.2.4 Tests (ATE) ..........................................................................................................................................31
5.2.5 Vulnerability assessment (AVA)...........................................................................................................32
6. TOE SUMMARY SPECIFICATION..............................................................................................................33
6.1 SECURITY AUDIT ..........................................................................................................................................33
6.2 COMMUNICATION.........................................................................................................................................34
6.3 CRYPTOGRAPHIC SUPPORT ...........................................................................................................................35
6.3.1 NGFW Engine......................................................................................................................................36
6.3.2 SMC Appliance ....................................................................................................................................36
6.3.3 Cryptographic Support Summary ........................................................................................................37
6.4 USER DATA PROTECTION ..............................................................................................................................39
6.5 FIREWALL.....................................................................................................................................................40
6.6 IDENTIFICATION AND AUTHENTICATION.......................................................................................................42
6.7 SECURITY MANAGEMENT .............................................................................................................................43
6.8 PROTECTION OF THE TSF .............................................................................................................................44
6.9 TOE ACCESS.................................................................................................................................................46
6.10 TRUSTED PATH/CHANNELS ...........................................................................................................................46
7. REQUIREMENT ALLOCATION ..................................................................................................................48
LIST OF TABLES
Table 1 TOE Security Functional Components ......................................................................................................16
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 3 of 49
Table 2 Audit events..................................................................................................................................................18
Table 3 Assurance Components ...............................................................................................................................29
Table 6-1 NGFW Engine Forcepoint NGFW FIPS Object Module 2.0.14 CAVP Certificates ..........................35
Table 6-2 SMC Appliance SMC FIPS Java API 1.0.2 CAVP Certificates ...........................................................36
Table 6-3 SMC Appliance SMC FIPS Object Module 2.0.13 CAVP Certificates................................................36
Table 6-4 Cipher suites to communicate with an External Syslog Server ............................................................37
Table 6-5 Cipher suites to communicate with remote administrators ..................................................................37
Table 6-6 CSPs and Keys ..........................................................................................................................................38
Table 6-7 Protocols & Fields Filtered by the TOE .................................................................................................40
Table 6-8 Connection Tracking Fields.....................................................................................................................41
Table 6-9 Additional Stateful Filtering Rules .........................................................................................................42
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 4 of 49
1. Security Target Introduction
This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST
conformance claims, and the ST organization. The TOE is the NGFW 6.5 provided by Forcepoint. The TOE is being
evaluated as a firewall
The Security Target contains the following additional sections:
• Conformance Claims (Section 2)
• Security Objectives (Section 3)
• Extended Components Definition (Section 4)
• Security Requirements (Section 5)
• TOE Summary Specification (Section 6)
Conventions
The following conventions have been applied in this document:
• Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be
applied to functional requirements: iteration, assignment, selection, and refinement.
o Iteration: allows a component to be used more than once with varying operations. In the ST,
iteration is indicated by a parenthetical number placed at the end of the component. For example
FDP_ACC.1(1) and FDP_ACC.1(2) indicate that the ST includes two iterations of the FDP_ACC.1
requirement.
o Assignment: allows the specification of an identified parameter. Assignments are indicated using
bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a selection
would be identified in italics and with embedded bold brackets (e.g., [[selected-assignment]]).
o Selection: allows the specification of one or more elements from a list. Selections are indicated
using bold italics and are surrounded by brackets (e.g., [selection]).
o Refinement: allows the addition of details. Refinements are indicated using bold, for additions, and
strike-through, for deletions (e.g., “… all objects …” or “… some big things …”).
• Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as
captions.
1.1 Security Target Reference
ST Title – Forcepoint NGFW 6.5 Security Target
ST Version – Version 1.5
ST Date – October 7, 2019
1.2 TOE Reference
TOE Identification – Forcepoint NGFW 6.5 which consists of:
Forcepoint NGFW Security Management Center (SMC) Appliance running software version 6.5.7:
Appliance SMC 1000 G2
Forcepoint NGFW Engine running software version 6.5.4 and including the following models:
Desktop models: 330, 335
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 5 of 49
1U models: 1101, 1105, 2101, 2105,
2U models: 3301, 3305
4U model: 6205
Virtual model: ESXi 6.5
TOE Developer – Forcepoint
Evaluation Sponsor – Forcepoint
1.3 TOE Overview
The Target of Evaluation (TOE) is the Forcepoint NGFW 6.5.
The Forcepoint Next Generation Firewall is a stateful packet filtering firewall. Being a stateful packet filtering
firewall, the NGFW filters network traffic optimized through the use of stateful packet inspection. The NGFW is
intended to be used as a network perimeter security gateway that provides a controlled connection. The NGFW is
centrally managed and generates audit records for security critical events.
1.4 TOE Description
The Forcepoint Next Generation Firewall is a stateful packet filtering firewall. The Forcepoint Next Generation
Firewall (NGFW) system is composed of two physical appliances: the NGFW Engine and the Security Management
Center (SMC) Appliance. The NGFW Engine controls connectivity and information flow between internal and
external connected networks. The SMC Appliance provides administrative functionality supporting the configuration
and operation of NGFW Engines. Throughout the remainder of this document, references to the NGFW Engine are
meant to reference the TOE’s firewall engine, while references to the NGFW are meant to refer to the TOE as a whole.
The NGFW Engine controls connectivity and information flow between internal and external connected networks.
The NGFW Engine also provides a means to keep the internal host’s IP-address private from external users. The
NGFW Engine is intended to be used as a network perimeter security gateway that provides a controlled connection.
The NGFW is assumed to be installed and operated within a physically protected environment, administered by trusted
and trained administrators over a trusted and separate management network. Multiple installations of the NGFW
Engine may be used in combination to provide a company with an overall network topology.
The NGFW Engine contains a hardened Linux operating system (with a 4.9 kernel) executing on a single or multi-
processor Forcepoint hardware platform.
The SMC Appliance (or SMC) contains the Management Server and Log Server. Like the NGFW Engine, the SMC
contains a hardened Linux-based operating system (which uses a 2.6.32 kernel) to support the management capabilities
and allow for the operation and configuration of firewall engines.
1.4.1 TOE Architecture
The Forcepoint Next Generation Firewall (NGFW) system is a distributed TOE consisting of the Security
Management Center (SMC) Appliance and one or more NGFW Engines under the control of the SMC. These NGFW
Engines provide firewall functionality and communicate securely with the SMC using its embedded Forcepoint
NGFW FIPS Object Module 2.0.14 library to provide all cryptographic functionality. The SMC Appliance provides
Management Server, Log Server functionality, and securely manage Engines. As the SMC utilizes both Java and C,
the SMC relies upon both SMC FIPS Java API 1.0.2 with a Java runtime environment and SMC FIPS Object Module
2.0.13 for cryptographic functionality. In the evaluated configuration, the SMC Appliance communicates with NGFW
Engines through a TLS-protected trusted channel.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 6 of 49
Figure 1 TOE Components, Communication Paths and IT Environment.
The NGFW Engines (a.k.a., the Engines) are responsible for performing all firewall packet handling, analysis and
filtering that is provided by the NGFW system as well as securely transmitting audit logs to the SMC’s Log server.
The Management Server portion of the SMC Appliance provides the majority of the administrative capabilities in the
NGFW system through the SMC Client GUI. The SMC Appliance provides a very limited console interface that
allows administrators to verify and update TOE software, to manually set the time, and configure the console timeout.
The NGFW Engines do not have local administrative interfaces, and can only be configured through the SMC
Appliance. The Management Server is responsible for securely transferring the administrator defined configuration
to NGFW Engines as the administrator makes configuration changes (these configuration changes are known as a
'security policy').
The Log Server in the SMC Appliance is responsible for securely collecting audit events from the NGFW Engine
components of the TOE and securely re-transmitting the audit data to an external syslog server. The Management
Server component directly transmits its audit data to an external syslog server.
The administrator interfaces with the TOE mainly through the Client GUI, a Java program provided by Forcepoint.
The administrator may download the GUI from the SMC Appliance using the Java Web Start or alternatively install
it from a Forcepoint provided installation package. The Client GUI (along with the administrator’s workstation on
which the Client is installed), is part of the TOE’s Operational Environment, and the Client GUI interacts with the
Management Server which performs all identification, authentication, and permission enforcement. The Client GUI
can also interact with the Log Server, allowing the administrator to query the NGFW Engine audit records that the
Log Server has aggregated.
The following communication pathways are represented in Figure 1 TOE Components, Communication Paths and
IT Environment.
• Management Server to Log Server communications use the internal loopback interface within the
SMC Appliance. These communications involve the configuration of the Log Server by the
management Server.
• Management and Log Server to External Syslog Server communications use TLS to protect the
audit data transmitted from the Management and Log Server to the external syslog server.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 7 of 49
• NGFW Engine to Log Server communications use the TLS-based trusted channel to protect the
audit data transmitted from the NGFW Engine to the Log Server.
• NGFW Engine to/from Management Server communications use the TLS-based trusted channel
to protect the configuration information exchanged between the Management Server and the NGFW
Engine. Either party in this communication pathway can initiate the communications. Typically, the
Management Server initiates configuration changes by sending updated security policies to the NGFW
Engine. However, the NGFW Engine also polls for configuration changes on a regular basis.
• Client GUI to Management and Log Server communications uses TLS to protect the
communication over which remote administration actions occur.
• The NGFW Engines control connectivity and information flow between internal and external
connected networks that they are protecting.
The cryptographic operations occurring as part of the communication on the SMC Appliance involving the
Management Server and Log Server are performed using the SMC FIPS Java API 1.0.2(library). This provider
provides the encryption, decryption, signing and hashing functions necessary to support the SMC Appliance use of
the trusted channel mechanism and the trusted path mechanism. The SMC Appliance also uses the OpenSSL library
to perform signature verification supporting the TOE trusted update mechanism.
The NGFW Engine utilizes its Forcepoint NGFW FIPS Object Module 2.0.14 to provide the encryption, decryption,
signing and hashing functions necessary to support the NGFW Engine’s trusted update mechanism and its TLS, ITT
secure channel.
1.4.1.1 Physical Boundaries
The TOE is composed of two or more physical components: one or more NGFW Engine appliances and the SMC
Appliance. Each of these appliances have physical network connections to its environment, both to allow TLS
protected management communications between the SMC and its engines, and network connections allowing the
NGFW Engines to monitor and filter network traffic. The SMC Appliance provides all management functionality,
while the NGFW Engines provide all firewall packet filtering.
The TOE is accessed and managed from the Forcepoint Security Management Center Client (6.5) installed on a PC
(admin workstation) in the environment, where the PC is expected to have a network pathway to the SMC Appliance.
The TOE can be configured to forward its audit records to an external syslog server in the environment. All audit
records sent to the external syslog server, are sent from the SMC Appliance. The NGFW Engine does not send audit
data directly to an external syslog server. Instead, a NGFW Engine passes all of its audit data to the Log Server on
the SMC Appliance, which can (if configured) forward the data to the external syslog server.
An administrator can manually set the TOE’s internal clock through the SMC console. The SMC Appliance then
configures the NGFW Engine’s time to be in synch with itself. The NGFW Engine synchronizes only with the SMC.
The NGFW Engine utilizes its Forcepoint NGFW FIPS Object Module 2.0.14 to verify trusted engine software
updates. The SMC Appliance uses its SMC FIPS Java API 1.0.2 Library to provide TLS (which protects the trusted
channel mechanism and the trusted path mechanism) and uses itsSMC FIPS Object Module 2.0.13 to verify SMC
updates.
Each Engine model provides different performance as described in the table below.
Model Form
factor/CPU
Fixed ports 1G copper 10G
Fiber
40G
Fiber
Network
I/O slots
Max FW
throughput
330 Desktop
Atom C3338
8 8 0 0 0 4 Gbps
335 Desktop
Atom C3558
8 8 to 16 0 0 2 7 Gbps
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 8 of 49
1101 1U Pentium
D1508
8x GE RJ45,
2x 10Gbps SFP+
8 to 16 2 to 6 0 1 50 Gbps
1105 1U Xeon D-
1518
8x GE RJ45,
2x 10Gbps SFP+
8 to 16 2 to 6 0 1 60 Gbps
2101 1U Xeon D-
1548
12x GE RJ45,
2x 10Gbps SFP+
12 to 28 2 to 10 0 to 4 2 60 Gbps
2105 1U Xeon D-
1567
12x GE RJ45,
2x 10Gbps SFP+
12 to 28 2 to 10 0 to 4 2 80 Gbps
3301 2U Xeon E5-
2618L v3
2x GE RJ45 2 to 34 0 to 16 0 to 8 4 80 Gbps
3305 2U Xeon E5-
2680 v3
2x GE RJ45,
1x 40Gbps
QSFP+
2 to 34 0 to 16 1 to 9 4 160 Gbps
6205 4U Xeon E5-
2680 v4
2x GE RJ45 2 to 66 0 to 32 1 to 17 8 240 Gbps
ESXi 6.5
on Dell
PowerEdge
R440
Xeon Silver
4114
3x GE RJ45 N/A N/A N/A N/A N/A
The SMC model is as follows:
• SMC 1000 G2 with the Intel Xeon® Silver 4112 2.6GHz, 8.25M cache processor
1.4.1.2 Logical Boundaries
This section summarizes the security functions provided by the NGFW:
- Security audit
- Communication
- Cryptographic support
- Firewall
- Identification and authentication
- Security management
- Protection of the TSF
- TOE access
- Trusted path/channels
1.4.1.2.1 Security audit
The TOE generates audit events for numerous activities including policy enforcement, system management and
authentication. A syslog server in the environment is relied on to store audit records generated by the TOE. The TOE
generates a complete audit record including the IP address of the TOE, the event details, and the time the event
occurred. The time stamp is provided by the TOE’s Linux-based operating system in conjunction with the appliance
hardware. When the syslog server writes the audit record to the audit trail, it applies its own time stamp, placing the
entire TOE-generated syslog protocol message MSG contents into an encapsulating syslog record.
1.4.1.2.2 Communication
The TOE is a distributed solution consisting of the Security Management Center and NGFW Engines. The Security
Management Center can manage one or more NGFW Engines. The TOE uses a registration process to join Engines
to an SMC.
1.4.1.2.3 Cryptographic support
Because the TOE consists of distributed components, each physical component of the TOE must be considered when
discussing the TOE cryptographic support. Both types of components (the SMC and its Engines) of the TOE utilize
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 9 of 49
cryptography to verify trusted updates, for TLS protected management communications between the SMC and its
Engines, and the SMC uses cryptography to support its use of the TLS protocol to protect network communications
with external IT entities.
1.4.1.2.4 Firewall
The TOE provides an information flow control mechanism using a rule base that comprises a set of security policy
rules, i.e., the firewall security policy. The NGFW Engine enforces the firewall security policy on all traffic that
passes through the engine, via its internal or external network Ethernet interfaces.
1.4.1.2.5 Identification and authentication
The TOE requires users to be identified and authenticated before they can use functions mediated by the TOE, with
the exception of reading the login banner, and performing firewall packet filtering operations. The TOE authenticates
administrative users. In order for an administrative user to access the TOE, a user account including a user name and
password must be created for the user.
1.4.1.2.6 Security management
Security management commands are limited to authorized users (i.e., administrators) and available only after they
have provided acceptable user identification and authentication data to the TOE. Administrators access the TOE
remotely using a TLS protected communication channel between the Management Server and the Client GUI (which
runs on a workstation in the IT environment). Administrators can also access the TOE via a local console which
provides limited functionality.
1.4.1.2.7 Protection of the TSF
The TOE provides a variety of means of protecting itself. The TOE performs self-tests that cover the correct operation
of the TOE. It provides functions necessary to securely update the TOE. It’s Linux-based operating system utilizes
a hardware clock to ensure reliable timestamps. It protects sensitive data such as stored passwords and cryptographic
keys so that they are not accessible through the TOE, even to a Security Administrator.
1.4.1.2.8 TOE access
The TOE can be configured to display a logon banner before a user session is established. The TOE also enforces
inactivity timeouts for local and remote sessions.
1.4.1.2.9 Trusted path/channels
The TOE protects interactive communication with administrators using TLS for GUI access, ensuring both integrity
and disclosure protection. If the negotiation of an encrypted session fails, the attempted connection will not be
established.
The TOE protects communication with network peers, such as an external syslog server, using TLS connections to
prevent unintended disclosure or modification of logs.
The TOE protects communications between distributed components using a TLS-based trusted channel. The TOE
uses TLS while registering new Engines with the SMC and once registered, the Engine and SMC use mutually-
authenticated TLS to protect management communications.
1.4.2 TOE Documentation
The following administrator and user guidance is available:
• Forcepoint Next Generation Firewall Common Criteria Evaluated Configuration Guide, 6.5.4 Rev D
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 10 of 49
2. Conformance Claims
This TOE is conformant to the following CC specifications:
• Common Criteria for Information Technology Security Evaluation Part 2: Security functional components,
Version 3.1, Revision 5, April 2017.
• Part 2 Extended
• Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components,
Version 3.1, Revision 5, April 2017.
• Part 3 Conformant
• Package Claims:
• collaborative Protection Profile for Stateful Traffic Filter Firewalls, Version 2.0 + Errata 20180314,
14-March-2018 (FWcPP20E)
• Technical Decisions:
TD # TD Name Applied to this TOE
TD0451
NIT Technical Decision for ITT Comm UUID
Reference Identifier
FCS_TLSS_EXT.1.2 and
FCS_TLSS_EXT.2.2
TD0448
NIT Technical Decision for Documenting
Diffie-Hellman 14 groups
FCS_CKM.2
TD0447
NIT Technical Decision for Using 'diffie-
hellman-group-exchange-sha256' in
FCS_SSHC/S_EXT.1.7
FCS_SSHS_EXT.1.7
TD0425
NIT Technical Decision for Cut-and-paste Error
for Guidance AA
FTA_SSL.3
TD0423
NIT Technical Decision for Clarification about
application of RfI#201726rev2
FIA_X509_EXT.3
TD0412
NIT Technical Decision for
FCS_SSHS_EXT.1.5 SFR and AA discrepancy
FCS_SSHS_EXT.1.5
TD0411
NIT Technical Decision for
FCS_SSHC_EXT.1.5, Test 1 - Server and client
side seem to be confused
Not applied because this
ST does not include
FCS_SSHC_EXT.1
TD0410
NIT technical decision for Redundant assurance
activities associated with FAU_GEN.1
FAU_GEN.1
TD0409
NIT decision for Applicability of FIA_AFL.1 to
key-based SSH authentication
FIA_AFL.1
TD0408
NIT Technical Decision for local vs. remote
administrator accounts
FIA_AFL.1,
FIA_UAU_EXT.2,
FMT_SMF.1
TD0407
NIT Technical Decision for handling
Certification of Cloud Deployments
Not applied because this
TOE does not include any
cloud-based components.
TD0402
NIT Technical Decision for RSA-based
FCS_CKM.2 Selection
FCS_CKM.2
TD0401
NIT Technical Decision for Reliance on external
servers to meet SFRs
FTP_ITC.1
TD0400
NIT Technical Decision for FCS_CKM.2 and
elliptic curve-based key establishment
FCS_CKM.1,
FCS_CKM.2
TD0399
NIT Technical Decision for Manual installation
of CRL (FIA_X509_EXT.2)
FIA_X509_EXT.2
TD0398
NIT Technical Decision for FCS_SSH*EXT.1.1
RFCs for AES-CTR
FCS_SSHS_EXT.1.1
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 11 of 49
TD0397
NIT Technical Decision for Fixing AES-CTR
Mode Tests
FCS_COP.1/
DataEncryption
TD0396
NIT Technical Decision for
FCS_TLSC_EXT.1.1, Test 2
FCS_TLSC_EXT.2.1
TD0395
NIT Technical Decision for Different Handling
of TLS1.1 and TLS1.2
FCS_TLSS_EXT.2.4,
FCS_TLSS_EXT.2.5
TD0394
NIT Technical Decision for Audit of
Management Activities related to Cryptographic
Keys
FAU_GEN.1
TD0343
NIT Technical Decision for Updating
FCS_IPSEC_EXT.1.14 Tests
Not applied because the
TOE does not claim
FCS_IPSEC_EXT.1
TD0342
NIT Technical Decision for TLS and DTLS
Server Tests
FCS_TLSS_EXT.1
TD0341
NIT Technical Decision for TLS wildcard
checking
FCS_TLSC_EXT.2.2
TD0340
NIT Technical Decision for Handling of the
basicConstraints extension in CA and leaf
certificates
FIA_X509_EXT.1.1/Rev
FIA_X509_EXT.1.1/ITT
TD0339
NIT Technical Decision for Making password-
based authentication optional in
FCS_SSHS_EXT.1.2
FCS_SSHS_EXT.1.2
TD0338
NIT Technical Decision for Access Banner
Verification
FTA_TAB.1
TD0337
NIT Technical Decision for Selections in
FCS_SSH*_EXT.1.6
FCS_SSHS_EXT.1.6
TD0336
NIT Technical Decision for Audit requirements
for FCS_SSH*_EXT.1.8
FCS_SSHS_EXT.1.8
TD0335
NIT Technical Decision for FCS_DTLS
Mandatory Cipher Suites
FCS_TLSC_EXT.2.1,
FCS_TLSS_EXT.1.1,
FCS_TLSS_EXT.2.1
TD0334
NIT Technical Decision for Testing SSH when
password-based authentication is not supported
Not applied because the
TOE does not claim
FCS_SSHC_EXT.1
TD0333
NIT Technical Decision for Applicability of
FIA_X509_EXT.3
FIA_X509_EXT.3
TD0324
NIT Technical Decision for Correction of
section numbers in SD Table 1
Applicable to the PP
Supporting Document
TD0323
NIT Technical Decision for DTLS server testing
- Empty Certificate Authorities list
Not applied because the
TOE does not claim
FCS_DTLSS_EXT.2
TD0322
NIT Technical Decision for TLS server testing -
Empty Certificate Authorities list
FCS_TLSS_EXT.2.4,
FCS_TLSS_EXT.2.5
TD0321 Protection of NTP communications
FTP_ITC.1,
FPT_STM_EXT.1
TD0291
NIT technical decision for DH14 and
FCS_CKM.1
FCS_CKM.1
TD0290
Physical interruption of trusted path/channel test
modification
FTP_ITC.1, FTP_TRP.1,
FPT_ITT.1
TD0289 Updated tests for FCS_TLSC_EXT.x.1 test 5e FCS_TLSC_EXT.2.1
TD0281 SSH rekey testing modification FCS_SSHS_EXT.1.8
TD0259
NIT Technical Decision for Support for X509
ssh rsa authentication IAW RFC 6187
FCS_SSHS_EXT.1.5
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 12 of 49
TD0257
Updated tests for FCS_TLSC_EXT.x.2 Tests 1-
4
FCS_TLSC_EXT.2.2
TD0256 Updated tests for FCS_TLSC_EXT.2.5 FCS_TLSC_EXT.2
TD0228 Updated tests for FIA_X509_EXT.1.2
FIA_X509_EXT.1.2/ITT,
FIA_X509_EXT.1.2/Rev
t
2.1 Conformance Rationale
The ST conforms to the FWcPP20E. As explained previously, the security problem definition, security objectives,
and security requirements have been drawn from the PP.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 13 of 49
3. Security Objectives
The Security Problem Definition may be found in the FWcPP20E and this section reproduces only the corresponding
Security Objectives for the operational environment for reader convenience. The FWcPP20E offers additional
information about the identified security objectives, but that has not been reproduced here and the FWcPP20E should
be consulted if there is interest in that material.
In general, the FWcPP20E has defined Security Objectives appropriate for firewalls and as such are applicable to the
Forcepoint Next Generation Firewall TOE.
3.1 Security Objectives for the Operational Environment
OE.ADMIN_CREDENTIALS_SECURE The administrator's credentials (private key) used to access the
TOE must be protected on any other platform on which they reside.
OE.COMPONENTS_RUNNING (applies to distributed TOEs only) For distributed TOEs the Security
Administrator ensures that the availability of every TOE component is checked as appropriate to reduce
the risk of an undetected attack on (or failure of) one or more TOE components. The Security Administrator
also ensures that it is checked as appropriate for every TOE component that the audit functionality is
running properly.
OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g., compilers or
user applications) available on the TOE, other than those services necessary for the operation,
administration and support of the TOE.
OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that traverses
it. It is assumed that protection of this traffic will be covered by other security and assurance measures in
the operational environment.
OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is
provided by the environment.
OE.RESIDUAL_INFORMATION The Security Administrator ensures that there is no unauthorized access
possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.)
on networking equipment when the equipment is discarded or removed from its operational environment.
OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all guidance documentation in
a trusted manner.
OE.UPDATES The TOE firmware and software is updated by an administrator on a regular basis in
response to the release of product updates due to known vulnerabilities.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 14 of 49
4. Extended Components Definition
All of the extended requirements in this ST have been drawn from the FWcPP20E. The FWcPP20E defines the
following extended requirements and since they are not redefined in this ST, the FWcPP20E should be consulted for
more information in regard to those CC extensions.
Extended SFRs:
• FWcPP20E:FAU_STG_EXT.1: Protected Audit Event Storage
• FWcPP20E:FCO_CPC_EXT.1: Component Registration Channel Definition
• FWcPP20E:FCS_RBG_EXT.1: Random Bit Generation
• FWcPP20E:FCS_TLSC_EXT.2: TLS Client Protocol with authentication
• FWcPP20E:FCS_TLSS_EXT.1: TLS Server Protocol
• FWcPP20E:FCS_TLSS_EXT.2: TLS Server Protocol with mutual authentication
• FWcPP20E:FFW_RUL_EXT.1: Stateful Traffic Filtering
• FWcPP20E:FFW_RUL_EXT.2: Stateful Filtering of Dynamic Protocols
• FWcPP20E:FIA_PMG_EXT.1: Password Management
• FWcPP20E:FIA_UAU_EXT.2: Password-based Authentication Mechanism
• FWcPP20E:FIA_UIA_EXT.1: User Identification and Authentication
• FWcPP20E:FIA_X509_EXT.1/ITT: X.509 Certificate Validation
• FWcPP20E:FIA_X509_EXT.1/Rev: X.509 Certificate Validation
• FWcPP20E:FIA_X509_EXT.2: X.509 Certificate Authentication
• FWcPP20E:FIA_X509_EXT.3: X.509 Certificate Requests
• FWcPP20E:FPT_APW_EXT.1: Protection of Administrator Passwords
• FWcPP20E:FPT_SKP_EXT.1: Protection of TSF Data (for reading of all pre-shared, symmetric and private
keys)
• FWcPP20E:FPT_STM_EXT.1: Reliable Time Stamps
• FWcPP20E:FPT_TST_EXT.1: TSF testing
• FWcPP20E:FPT_TUD_EXT.1: Trusted update
• FWcPP20E:FTA_SSL_EXT.1: TSF-initiated Session Locking
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 15 of 49
5. Security Requirements
This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) that
serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope the evaluation effort.
The SFRs have all been drawn from the FWcPP20E. The refinements and operations already performed in the
FWcPP20E are not identified (e.g., highlighted) here, rather the requirements have been copied from the FWcPP20E
and any residual operations have been completed herein. Of particular note, the FWcPP20E made a number of
refinements and completed some of the SFR operations defined in the Common Criteria (CC) and that PP should be
consulted to identify those changes if necessary.
The SARs are also drawn from the FWcPP20E which includes all the SARs for EAL 1. However, the SARs are
effectively refined since requirement-specific 'Assurance Activities' are defined in the FWcPP20E that serve to ensure
corresponding evaluations will yield more practical and consistent assurance than the EAL 1 assurance requirements
alone. The FWcPP20E should be consulted for the assurance activity definitions.
5.1 TOE Security Functional Requirements
The following table identifies the SFRs that are satisfied by the TOE.
Requirement Class Requirement Component
FAU: Security audit FWcPP20E:FAU_GEN.1: Audit Data Generation
FWcPP20E:FAU_GEN.2: User identity association
FWcPP20E:FAU_STG_EXT.1: Protected Audit Event Storage
FCO: Communication FWcPP20E:FCO_CPC_EXT.1: Component Registration Channel
Definition
FCS: Cryptographic support FWcPP20E:FCS_CKM.1: Cryptographic Key Generation
FWcPP20E:FCS_CKM.2: Cryptographic Key Establishment
FWcPP20E:FCS_CKM.4: Cryptographic Key Destruction
FWcPP20E:FCS_COP.1/DataEncryption: Cryptographic Operation
(AES Data Encryption/Decryption)
FWcPP20E:FCS_COP.1/Hash: Cryptographic Operation (Hash
Algorithm)
FWcPP20E:FCS_COP.1/KeyedHash: Cryptographic Operation
(Keyed Hash Algorithm)
FWcPP20E:FCS_COP.1/SigGen: Cryptographic Operation (Signature
Generation and Verification)
FWcPP20E:FCS_RBG_EXT.1: Random Bit Generation
FWcPP20E:FCS_TLSC_EXT.2: TLS Client Protocol with
authentication
FWcPP20E:FCS_TLSS_EXT.1: TLS Server Protocol
FWcPP20E:FCS_TLSS_EXT.2: TLS Server Protocol with mutual
authentication
FDP: User Data Protection FWcPP20E:FDP_RIP.2: Full Residual Information Protection
FFW: Firewall FWcPP20E:FFW_RUL_EXT.1: Stateful Traffic Filtering
FWcPP20E:FFW_RUL_EXT.2: Stateful Filtering of Dynamic
Protocols
FIA: Identification and
authentication
FWcPP20E:FIA_AFL.1: Authentication Failure Management
FWcPP20E:FIA_PMG_EXT.1: Password Management
FWcPP20E:FIA_UAU.7: Protected Authentication Feedback
FWcPP20E:FIA_UAU_EXT.2: Password-based Authentication
Mechanism
FWcPP20E:FIA_UIA_EXT.1: User Identification and Authentication
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 16 of 49
FWcPP20E:FIA_X509_EXT.1/ITT: X.509 Certificate Validation
FWcPP20E:FIA_X509_EXT.1/Rev: X.509 Certificate Validation
FWcPP20E:FIA_X509_EXT.2: X.509 Certificate Authentication
FWcPP20E:FIA_X509_EXT.3: X.509 Certificate Requests
FMT: Security management FWcPP20E:FMT_MOF.1/Functions: Management of security
functions behaviour
FWcPP20E:FMT_MOF.1/ManualUpdate: Management of security
functions behaviour
FWcPP20E:FMT_MTD.1/CoreData: Management of TSF Data
FWcPP20E:FMT_MTD.1/CryptoKeys: Management of TSF data
FWcPP20E:FMT_SMF.1: Specification of Management Functions
FWcPP20E:FMT_SMR.2: Restrictions on Security Roles
FPT: Protection of the TSF FWcPP20E:FPT_APW_EXT.1: Protection of Administrator
Passwords
FWcPP20E:FPT_ITT.1: Basic internal TSF data transfer protection
FWcPP20E:FPT_SKP_EXT.1: Protection of TSF Data (for reading of
all pre-shared, symmetric and private keys)
FWcPP20E:FPT_STM_EXT.1: Reliable Time Stamps
FWcPP20E:FPT_TST_EXT.1: TSF testing
FWcPP20E:FPT_TUD_EXT.1: Trusted update
FTA: TOE access FWcPP20E:FTA_SSL.3: TSF-initiated Termination
FWcPP20E:FTA_SSL.4: User-initiated Termination
FWcPP20E:FTA_SSL_EXT.1: TSF-initiated Session Locking
FWcPP20E:FTA_TAB.1: Default TOE Access Banners
FTP: Trusted path/channels FWcPP20E:FTP_ITC.1: Inter-TSF trusted channel
FWcPP20E:FTP_TRP.1/Admin: Trusted Path
FWcPP20E:FTP_TRP.1/Join: Trusted Path
Table 1 TOE Security Functional Components
5.1.1 Security audit (FAU)
5.1.1.1 Audit Data Generation (FWcPP20E:FAU_GEN.1)
FWcPP20E:FAU_GEN.1.1
The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shut-down of the audit functions;
b) All auditable events for the not specified level of audit; and
c) All administrative actions comprising:
- Administrative login and logout (name of user account shall be logged if individual user
accounts are required for administrators).
- Changes to TSF data related to configuration changes (in addition to the information
that a change occurred it shall be logged what has been changed).
- Generating/import of, changing, or deleting of cryptographic keys (in addition to the
action itself a unique key name or key reference shall be logged).
- Resetting passwords (name of related user account shall be logged).
- [no other actions];
d) Specifically defined auditable events listed in Table 2 Audit events.
Requirement Auditable Events Additional Content
FWcPP20E:FAU_GEN.1
FWcPP20E:FAU_GEN.2
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 17 of 49
FWcPP20E:FAU_STG_EXT.1
FWcPP20E:FCO_CPC_EXT.1 Enabling communications
between a pair of components.
Disabling communications
between a pair of components.
Identities of the endpoints
pairs enabled or disabled.
FWcPP20E:FCS_CKM.1
FWcPP20E:FCS_CKM.2
FWcPP20E:FCS_CKM.4
FWcPP20E:FCS_COP.1/DataEncryption
FWcPP20E:FCS_COP.1/Hash
FWcPP20E:FCS_COP.1/KeyedHash
FWcPP20E:FCS_COP.1/SigGen
FWcPP20E:FCS_RBG_EXT.1
FWcPP20E:FCS_TLSC_EXT.2 Failure to establish a TLS
Session.
Reason for failure.
FWcPP20E:FCS_TLSS_EXT.1 Failure to establish a TLS
Session.
Reason for failure.
FWcPP20E:FCS_TLSS_EXT.2 Failure to establish a TLS
Session.
Reason for failure.
FWcPP20E:FDP_RIP.2 None None
FWcPP20E:FFW_RUL_EXT.1 Application of rules configured
with the 'log' operation.
Indication of packets dropped
due to too much network traffic.
Source and destination
addresses. Source and
destination ports. Transport
Layer Protocol.
TOE Interface.
TOE interface that is unable to
process packets.
Identifier of rule causing
packet drop.
FWcPP20E:FFW_RUL_EXT.2 FTP-related session
establishment
Source and destination
addresses. Source and
destination ports..
FWcPP20E:FIA_AFL.1 Unsuccessful login attempt limit
is met or exceeded.
Origin of the attempt (e.g., IP
address).
FWcPP20E:FIA_PMG_EXT.1
FWcPP20E:FIA_UAU.7 None None
FWcPP20E:FIA_UAU_EXT.2 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FWcPP20E:FIA_UIA_EXT.1 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FWcPP20E:FIA_X509_EXT.1/ITT Unsuccessful attempt to validate
a certificate.
Reason for failure.
FWcPP20E:FIA_X509_EXT.1/Rev Unsuccessful attempt to validate
a certificate.
Reason for failure.
FWcPP20E:FIA_X509_EXT.2 None None
FWcPP20E:FIA_X509_EXT.3 None None
FWcPP20E:FMT_MOF.1/Functions Modification of the behavior of
the transmission of audit data to
an external IT entity, the
handling of audit data, the audit
functionality when Local Audit
Storage Space is full.
FWcPP20E:FMT_MOF.1/ManualUpdate Any attempt to initiate a manual
update.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 18 of 49
FWcPP20E:FMT_MTD.1/CoreData All management activities of
TSF data.
FWcPP20E:FMT_MTD.1/CryptoKeys Management of cryptographic
keys.
FWcPP20E:FMT_SMF.1
FWcPP20E:FMT_SMR.2
FWcPP20E:FPT_APW_EXT.1
FWcPP20E:FPT_ITT.1 Initiation of the trusted channel.
Termination of the trusted
channel. Failure of the trusted
channel functions.
Identification of the initiator
and target of failed trusted
channels establishment
attempt.
FWcPP20E:FPT_SKP_EXT.1
FWcPP20E:FPT_STM_EXT.1 Discontinuous changes to time -
either Administrator actuated or
changed via an automated
process. (Note that no
continuous changes to time need
to be logged. See also
application note on
FPT_STM_EXT.1)
For discontinuous changes to
time: The old and new values
for the time. Origin of the
attempt to change time for
success and failure (e.g., IP
address).
FWcPP20E:FPT_TST_EXT.1
FWcPP20E:FPT_TUD_EXT.1 Initiation of update; result of the
update attempt (success or
failure).
FWcPP20E:FTA_SSL.3 The termination of a remote
session by the session locking
mechanism.
FWcPP20E:FTA_SSL.4 The termination of an interactive
session.
FWcPP20E:FTA_SSL_EXT.1 (if 'lock the session' is selected)
Any attempts at unlocking of an
interactive session. (if 'terminate
the session' is selected) The
termination of a local session by
the session locking mechanism.
FWcPP20E:FTA_TAB.1
FWcPP20E:FTP_ITC.1 Initiation of the trusted channel.
Termination of the trusted
channel. Failure of the trusted
channel functions.
Identification of the initiator
and target of failed trusted
channels establishment
attempt.
FWcPP20E:FTP_TRP.1/Admin Initiation of the trusted path.
Termination of the trusted path.
Failure of the trusted path
functions.
FWcPP20E:FTP_TRP.1/Join Initiation of the trusted path.
Termination of the trusted path.
Failure of the trusted path
functions.
Table 2 Audit events
FWcPP20E:FAU_GEN.1.2
The TSF shall record within each audit record at least the following information:
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 19 of 49
a) Date and time of the event, type of event, subject identity, and the outcome (success or failure)
of the event; and
b) For each audit event type, based on the auditable event definitions of the functional components
included in the cPP/ST, information specified in column three of Table 2 Audit events.
5.1.1.2 User identity association (FWcPP20E:FAU_GEN.2)
FWcPP20E:FAU_GEN.2.1
For audit events resulting from actions of identified users, the TSF shall be able to associate each
auditable event with the identity of the user that caused the event.
5.1.1.3 Protected Audit Event Storage (FWcPP20E:FAU_STG_EXT.1)
FWcPP20E:FAU_STG_EXT.1.1
The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted
channel according to FTP_ITC.1.
FWcPP20E:FAU_STG_EXT.1.2
The TSF shall be able to store generated audit data on the TOE itself.
FWcPP20E:FAU_STG_EXT.1.3
The TSF shall [the Management Server will reject configuration changes that result in
additional audit messages, the Log Server will send an alert to administrator and ultimately stop
accepting new audit message from the Engine, the Engine will stop traffic and transition into
an offline state until audit space is again available]] when the local storage space for audit data is
full.
5.1.2 Communication (FCO)
5.1.2.1 Component Registration Channel Definition (FWcPP20E:FCO_CPC_EXT.1)
FWcPP20E:FCO_CPC_EXT.1.1
The TSF shall require a Security Administrator to enable communications between any pair of
TOE components before such communication can take place.
FWcPP20E:FCO_CPC_EXT.1.2
The TSF shall implement a registration process in which components establish and use a
communications channel that uses [A channel that meets the secure registration channel
requirements in FTP_TRP.1/ Join] for at least TSF data.
FWcPP20E:FCO_CPC_EXT.1.3
The TSF shall enable a Security Administrator to disable communications between any pair of
TOE components.
5.1.3 Cryptographic support (FCS)
5.1.3.1 Cryptographic Key Generation (FWcPP20E:FCS_CKM.1)
FWcPP20E:FCS_CKM.1.1
The TSF shall generate asymmetric cryptographic keys in accordance with a specified
cryptographic key generation algorithm: [
- RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following:
FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.3,
- ECC schemes using 'NIST curves' [ P-256, P-384, P-521] that meet the following: FIPS PUB
186-4, 'Digital Signature Standard (DSS)', Appendix B.4,]. (TD0291 applied)
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 20 of 49
5.1.3.2 Cryptographic Key Establishment (FWcPP20E:FCS_CKM.2)
FWcPP20E:FCS_CKM.2.1
The TSF shall perform cryptographic key establishment in accordance with a specified
cryptographic key establishment method: [
- RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5 as
specified in Section 7.2 of RFC 8017, Public-Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1 (TD0402 applied),
- Elliptic curve-based key establishment schemes that meet the following: NIST Special
Publication 800-56A Revision 2, 'Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography', ].
5.1.3.3 Cryptographic Key Destruction (FWcPP20E:FCS_CKM.4)
FWcPP20E:FCS_CKM.4.1
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key
destruction method
- For plaintext keys in volatile storage, the destruction shall be executed by a [single overwrite
consisting of zeroes, destruction of reference to the key directly followed by a request for
garbage collection];
- For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation of
an interface provided by a part of the TSF that [o logically addresses the storage location of
the key and performs a [single]-pass overwrite consisting of [[a value that does not contain
any CSP]]]
that meets the following: No Standard.
5.1.3.4 Cryptographic Operation (AES Data Encryption/Decryption)
(FWcPP20E:FCS_COP.1/DataEncryption)
FWcPP20E:FCS_COP.1.1/DataEncryption
The TSF shall perform encryption/decryption in accordance with a specified cryptographic
algorithm AES used in [CBC, GCM] mode and cryptographic key sizes [128 bits, 256 bits] that
meet the following: AES as specified in ISO 18033-3, [CBC as specified in ISO 10116, GCM as
specified in ISO 19772].
5.1.3.5 Cryptographic Operation (Hash Algorithm) (FWcPP20E:FCS_COP.1/Hash)
FWcPP20E:FCS_COP.1.1/Hash
The TSF shall perform cryptographic hashing services in accordance with a specified
cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] and message digest sizes [160,
256, 384, 512] that meet the following: ISO/IEC 10118-3:2004.
5.1.3.6 Cryptographic Operation (Keyed Hash Algorithm) (FWcPP20E:FCS_COP.1/KeyedHash)
FWcPP20E:FCS_COP.1.1/KeyedHash
The TSF shall perform keyed-hash message authentication in accordance with a specified
cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384,] and
cryptographic key sizes [160, 256, 384] and message digest sizes [160, 256, 384] bits that meet the
following: ISO/IEC 9797-2:2011, Section 7 'MAC Algorithm 2'.
5.1.3.7 Cryptographic Operation (Signature Generation and Verification) (FWcPP20E:FCS_COP.1/SigGen)
FWcPP20E:FCS_COP.1.1/SigGen
The TSF shall perform cryptographic signature services (generation and verification) in
accordance with a specified cryptographic algorithm [
- RSA Digital Signature Algorithm and cryptographic key sizes (modulus) [2048 bits],
- Elliptic Curve Digital Signature Algorithm and cryptographic key sizes [256 bits]]
that meet the following:
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 21 of 49
[- For RSA schemes: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Section 5.5, using
PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC
9796-2, Digital signature scheme 2 or Digital Signature scheme 3,
- For ECDSA schemes: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Section 6 and
Appendix D, Implementing 'NIST curves' [selection: P-256, P-384, P-521]; ISO/IEC
14888-3, Section 6.4].
5.1.3.8 Random Bit Generation (FWcPP20E:FCS_RBG_EXT.1)
FWcPP20E:FCS_RBG_EXT.1.1
The TSF shall perform all deterministic random bit generation services in accordance with
ISO/IEC 18031:2011 using [Hash_DRBG (any), CTR_DRBG (AES)].
FWcPP20E:FCS_RBG_EXT.1.2
The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy
from [ [one] software-based noise source] with a minimum of [256 bits] of entropy at least equal
to the greatest security strength, according to ISO/IEC 18031:2011Table C.1 'Security Strength
Table for Hash Functions', of the keys and hashes that it will generate.
5.1.3.9 TLS Client Protocol with authentication (FWcPP20E:FCS_TLSC_EXT.2)
FWcPP20E:FCS_TLSC_EXT.2.1
The TSF shall implement [TLS 1.2 (RFC 5246)] and reject all other TLS and SSL versions. The
TLS implementation will support the following ciphersuites:
[Ciphers for FTP_ITC syslog export:
TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492,
TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246,
TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288,
TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
Ciphers for FPT_ITT communications:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
].
FWcPP20E:FCS_TLSC_EXT.2.2
The TSF shall verify that the presented identifier matches the reference identifier according to
RFC 6125.
FWcPP20E:FCS_TLSC_EXT.2.3
The TSF shall only establish a trusted channel if the server certificate is valid. If the server
certificate is deemed invalid, then the TSF shall [not establish the connection].
FWcPP20E:FCS_TLSC_EXT.2.4
The TSF shall [present the Supported Elliptic Curves Extension with the following NIST curves:
[secp256r1, secp384r1, secp521r1] and no other curves] in the Client Hello.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 22 of 49
FWcPP20E:FCS_TLSC_EXT.2.5
The TSF shall support mutual authentication using X.509v3 certificates.
5.1.3.10 TLS Server Protocol (FWcPP20E:FCS_TLSS_EXT.1)
FWcPP20E:FCS_TLSS_EXT.1.1
The TSF shall implement [TLS 1.2 (RFC 5246) and reject all other TLS and SSL versions. The
TLS implementation will support the following ciphersuites:
[TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,].
FWcPP20E:FCS_TLSS_EXT.1.2
The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0, and [TLS
1.1].
FWcPP20E:FCS_TLSS_EXT.1.3
The TSF shall [generate EC Diffie-Hellman parameters over NIST curves [secp256r1,
secp384r1, secp521r1] and no other curves].
5.1.3.11 TLS Server Protocol with mutual authentication (FWcPP20E:FCS_TLSS_EXT.2)
FWcPP20E:FCS_TLSS_EXT.2.1
The TSF shall implement [TLS 1.2 (RFC 5246)] and reject all other TLS and SSL versions. The
TLS implementation will support the following ciphersuites:
[TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289,].
FWcPP20E:FCS_TLSS_EXT.2.2
The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0, and [TLS
1.1].
FWcPP20E:FCS_TLSS_EXT.2.3
The TSF shall [generate EC Diffie-Hellman parameters over NIST curves [secp256r1,
secp384r1, secp521r1] and no other curves].
FWcPP20E:FCS_TLSS_EXT.2.4
The TSF shall support mutual authentication of TLS clients using X.509v3 certificates.
FWcPP20E:FCS_TLSS_EXT.2.5
The TSF shall not establish a trusted channel if the client certificate is invalid. If the client
certificate is deemed invalid, then the TSF shall [not establish the connection].
FWcPP20E:FCS_TLSS_EXT.2.6
The TSF shall not establish a trusted channel if the distinguished name (DN) or Subject
Alternative Name (SAN) contained in a certificate does not match the expected identifier for the
client.
5.1.4 User data protection (FDP)
5.1.4.1 Full Residual Information Protection (FDP_RIP.2)
FDP_RIP.2.1
The TSF shall ensure that any previous information content of a resource is made unavailable
upon the [allocation of the resource to] all objects.
5.1.5 Firewall (FFW)
5.1.5.1 Stateful Traffic Filtering (FWcPP20E:FFW_RUL_EXT.1)
FWcPP20E:FFW_RUL_EXT.1.1
The TSF shall perform Stateful Traffic Filtering on network packets processed by the TOE.
FWcPP20E:FFW_RUL_EXT.1.2
The TSF shall allow the definition of Stateful Traffic Filtering rules using the following network
protocol fields:
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 23 of 49
- ICMPv4
o Type
o Code
- ICMPv6
o Type
o Code
- IPv4
o Source address
o Destination Address
o Transport Layer Protocol
- IPv6
o Source address
o Destination Address
o Transport Layer Protocol
o [no other field]
- TCP
o Source Port
o Destination Port
- UDP
o Source Port
o Destination Port
- and distinct interface.
FWcPP20E:FFW_RUL_EXT.1.3
The TSF shall allow the following operations to be associated with Stateful Traffic Filtering rules:
permit or drop with the capability to log the operation.
FWcPP20E:FFW_RUL_EXT.1.4
The TSF shall allow the Stateful Traffic Filtering rules to be assigned to each distinct network
interface.
FWcPP20E:FFW_RUL_EXT.1.5
The TSF shall:
a) accept a network packet without further processing of Stateful Traffic Filtering rules if it
matches an allowed established session for the following protocols: TCP, UDP, [ICMP] based
on the following network packet attributes:
1. TCP: source and destination addresses, source and destination ports, sequence number, Flags;
2. UDP: source and destination addresses, source and destination ports;
3. ['ICMP: source and destination addresses, type, [code]'].
b) Remove existing traffic flows from the set of established traffic flows based on the following:
[session inactivity timeout].
FWcPP20E:FFW_RUL_EXT.1.6
The TSF shall enforce the following default Stateful Traffic Filtering rules on all network traffic:
a) The TSF shall drop and be capable of [logging] packets which are invalid fragments;
b) The TSF shall drop and be capable of [logging] fragmented packets which cannot be re-
assembled completely;
c) The TSF shall drop and be capable of logging packets where the source address of the network
packet is defined as being on a broadcast network;
d) The TSF shall drop and be capable of logging packets where the source address of the network
packet is defined as being on a multicast network; The TSF shall drop and be capable of
logging network packets where the source address of the network packet is defined as being a
loopback address;
e) The TSF shall drop and be capable of logging network packets where the source or destination
address of the network packet is defined as being unspecified (i.e. 0.0.0.0) or an address
'reserved for future use' (i.e. 240.0.0.0/4) as specified in RFC 5735 for IPv4;
f) The TSF shall drop and be capable of logging network packets where the source or destination
address of the network packet is defined as an 'unspecified address' or an address 'reserved for
future definition and use' (i.e. unicast addresses not in this address range: 2000::/3) as specified
in RFC 3513 for IPv6;
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 24 of 49
g) The TSF shall drop and be capable of logging network packets with the IP options: Loose
Source Routing, Strict Source Routing, or Record Route specified; and
h) [no other rules].
FWcPP20E:FFW_RUL_EXT.1.7
The TSF shall be capable of dropping and logging according to the following rules:
a) The TSF shall drop and be capable of logging network packets where the source address of the
network packet is equal to the address of the network interface where the network packet was
received;
b) The TSF shall drop and be capable of logging network packets where the source or destination
address of the network packet is a link-local address;
c) The TSF shall drop and be capable of logging network packets where the source address of the
network packet does not belong to the networks associated with the network interface where
the network packet was received.
FWcPP20E:FFW_RUL_EXT.1.8
The TSF shall process the applicable Stateful Traffic Filtering rules in an administratively defined
order.
FWcPP20E:FFW_RUL_EXT.1.9
The TSF shall deny packet flow if a matching rule is not identified.
FWcPP20E:FFW_RUL_EXT.1.10
The TSF shall be capable of limiting an administratively defined number of half-open TCP
connections. In the event that the configured limit is reached, new connection attempts shall be
dropped and the drop event shall be [logged].
5.1.5.2 Stateful Filtering of Dynamic Protocols (FWcPP20E:FFW_RUL_EXT.2)
FWcPP20E:FFW_RUL_EXT.2.1
The TSF shall dynamically define rules or establish sessions allowing network traffic to flow for
the following network protocols [FTP].
5.1.6 Identification and authentication (FIA)
5.1.6.1 Authentication Failure Management (FWcPP20E:FIA_AFL.1)
FWcPP20E:FIA_AFL.1.1
The TSF shall detect when an Administrator configurable positive integer within [1-1000]
unsuccessful authentication attempts occur related to Administrators attempting to authenticate
remotely using a password. (TD0408 applied)
FWcPP20E:FIA_AFL.1.2
When the defined number of unsuccessful authentication attempts has been met, the TSF shall
[prevent the offending Administrator from successfully establishing remote session using any
authentication method that involves a password until an Administrator defined time period has
elapsed]. (TD0408 applied)
5.1.6.2 Password Management (FWcPP20E:FIA_PMG_EXT.1)
FWcPP20E:FIA_PMG_EXT.1.1
The TSF shall provide the following password management capabilities for administrative
passwords:
a) Passwords shall be able to be composed of any combination of upper and lower case letters,
numbers, and the following special characters: ['!', '@', '#', '$', '%', '^', '&', '*', '(', ')'] ;
b) Minimum password length shall be configurable to [1] and [65].
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 25 of 49
5.1.6.3 Protected Authentication Feedback (FWcPP20E:FIA_UAU.7)
FWcPP20E:FIA_UAU.7.1
The TSF shall provide only obscured feedback to the administrative user while the authentication
is in progress at the local console.
5.1.6.4 Password-based Authentication Mechanism (FWcPP20E:FIA_UAU_EXT.2)
FWcPP20E:FIA_UAU_EXT.2.1
The TSF shall provide a local [password-based] authentication mechanism to perform local
administrative user authentication. (TD0408 applied)
5.1.6.5 User Identification and Authentication (FWcPP20E:FIA_UIA_EXT.1)
FWcPP20E:FIA_UIA_EXT.1.1
The TSF shall allow the following actions prior to requiring the non-TOE entity to initiate the
identification and authentication process:
- Display the warning banner in accordance with FTA_TAB.1;
- [[passing network traffic through the firewall engine]].
FWcPP20E:FIA_UIA_EXT.1.2
The TSF shall require each administrative user to be successfully identified and authenticated
before allowing any other TSF-mediated actions on behalf of that administrative user.
5.1.6.6 X.509 Certificate Validation (FWcPP20E:FIA_X509_EXT.1/ITT)
FWcPP20E:FIA_X509_EXT.1.1/ITT
The TSF shall validate certificates in accordance with the following rules:
- RFC 5280 certificate validation and certificate path validation supporting a minimum path length
of two certificates.
- The certificate path must terminate with a trusted CA certificate.
- The TSF shall validate a certification path by ensuring that all CA certificates in the certification
path contain the basicConstraints extension with the CA flag set to TRUE. (TD0340 applied)
- The TSF shall validate the revocation status of the certificate using [no revocation method].
- The TSF shall validate the extendedKeyUsage field according to the following rules:
o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with
OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field
o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with
OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field
o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9
with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
FWcPP20E:FIA_X509_EXT.1.2/ITT
The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is
present and the CA flag is set to TRUE.
5.1.6.7 X.509 Certificate Validation (FWcPP20E:FIA_X509_EXT.1/Rev)
FWcPP20E:FIA_X509_EXT.1.1/Rev
The TSF shall validate certificates in accordance with the following rules:
- RFC 5280 certificate validation and certificate path validation supporting a minimum path length
of three certificates.
- The certificate path must terminate with a trusted CA certificate.
- The TSF shall validate a certification path by ensuring that all CA certificates in the certification
path contain the basicConstraints extension with the CA flag set to TRUE. (TD0340 applied)
- The TSF shall validate the revocation status of the certificate using [the Online Certificate
Status Protocol (OCSP) as specified in RFC 6960, a Certificate Revocation List (CRL) as
specified in RFC 5280 Section 6.3, Certificate Revocation List (CRL) as specified in RFC
5759 Section 5]
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 26 of 49
- The TSF shall validate the extendedKeyUsage field according to the following rules:
o Certificates used for trusted updates and executable code integrity verification shall have the
Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.
o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with
OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with
OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9
with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
FWcPP20E:FIA_X509_EXT.1.2/Rev
The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is
present and the CA flag is set to TRUE.
5.1.6.8 X.509 Certificate Authentication (FWcPP20E:FIA_X509_EXT.2)
FWcPP20E:FIA_X509_EXT.2.1
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for
[TLS], and [no additional uses].
FWcPP20E:FIA_X509_EXT.2.2
When the TSF cannot establish a connection to determine the validity of a certificate, the TSF
shall [not accept the certificate].
5.1.6.9 X.509 Certificate Requests (FWcPP20E:FIA_X509_EXT.3)
FWcPP20E:FIA_X509_EXT.3.1
The TSF shall generate a Certification Request as specified by RFC 2986 and be able to provide
the following information in the request: public key and [device-specific information, Common
Name, Organization, Organizational Unit, Country]. (TD0333 applied)
FWcPP20E:FIA_X509_EXT.3.2
The TSF shall validate the chain of certificates from the Root CA upon receiving the CA
Certificate Response.
5.1.7 Security management (FMT)
5.1.7.1 Management of security functions behaviour (FWcPP20E:FMT_MOF.1/Functions)
FWcPP20E:FMT_MOF.1.1/Functions
The TSF shall restrict the ability to [determine the behaviour of, modify the behaviour of] the
functions [transmission of audit data to an external IT entity, handling of audit data, audit
functionality when Local Audit Storage Space is full] to Security Administrators.
5.1.7.2 Management of security functions behaviour (FWcPP20E:FMT_MOF.1/ManualUpdate)
FWcPP20E:FMT_MOF.1.1/ManualUpdate
The TSF shall restrict the ability to enable the functions to perform manual update to Security
Administrators.
5.1.7.3 Management of TSF Data (FWcPP20E:FMT_MTD.1/CoreData)
FWcPP20E:FMT_MTD.1.1/CoreData
The TSF shall restrict the ability to manage the TSF data to Security Administrators.
5.1.7.4 Management of TSF data (FWcPP20E:FMT_MTD.1/CryptoKeys)
FWcPP20E:FMT_MTD.1.1/CryptoKeys
The TSF shall restrict the ability to manage the cryptographic keys to Security Administrators.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 27 of 49
5.1.7.5 Specification of Management Functions (FWcPP20E:FMT_SMF.1)
FWcPP20E:FMT_SMF.1.1
The TSF shall be capable of performing the following management functions:
- Ability to administer the TOE locally and remotely;
- Ability to configure the access banner;
- Ability to configure the session inactivity time before session termination or locking;
- Ability to update the TOE, and to verify the updates using [digital signature] capability prior to
installing those updates;
- Ability to configure the authentication failure parameters for FIA_AFL.1;
- Ability to configure firewall rules;
- [
o Ability to configure audit behavior,
o Ability to configure the cryptographic functionality,
o Ability to configure the interaction between TOE components;
o Ability to set the time which is used for time-stamps;,
o Ability to configure the reference identifier for the peer;].
5.1.7.6 Restrictions on Security Roles (FWcPP20E:FMT_SMR.2)
FWcPP20E:FMT_SMR.2.1
The TSF shall maintain the roles: - Security Administrator.
FWcPP20E:FMT_SMR.2.2
The TSF shall be able to associate users with roles.
FWcPP20E:FMT_SMR.2.3
The TSF shall ensure that the conditions
- The Security Administrator role shall be able to administer the TOE locally;
- The Security Administrator role shall be able to administer the TOE remotely are satisfied.
5.1.8 Protection of the TSF (FPT)
5.1.8.1 Protection of Administrator Passwords (FWcPP20E:FPT_APW_EXT.1)
FWcPP20E:FPT_APW_EXT.1.1
The TSF shall store passwords in non-plaintext form.
FWcPP20E:FPT_APW_EXT.1.2
The TSF shall prevent the reading of plaintext passwords.
5.1.8.2 Basic internal TSF data transfer protection (FWcPP20E:FPT_ITT.1)
FWcPP20E:FPT_ITT.1.1
The TSF shall protect TSF data from disclosure and detect its modification when it is transmitted
between separate parts of the TOE through the use of [TLS].
5.1.8.3 Protection of TSF Data (for reading of all pre-shared, symmetric and private keys)
(FWcPP20E:FPT_SKP_EXT.1)
FWcPP20E:FPT_SKP_EXT.1.1
The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys.
5.1.8.4 Reliable Time Stamps (FWcPP20E:FPT_STM_EXT.1)
FWcPP20E:FPT_STM_EXT.1.1
The TSF shall be able to provide reliable time stamps for its own use.
FWcPP20E:FPT_STM_EXT.1.2
The TSF shall [allow the Security Administrator to set the time].
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 28 of 49
5.1.8.5 TSF testing (FWcPP20E:FPT_TST_EXT.1)
FWcPP20E:FPT_TST_EXT.1.1
The TSF shall run a suite of the following self-tests [during initial start-up (on power on)] to
demonstrate the correct operation of the TSF: [memory checks, KAT tests, and checksums of
TOE binaries].
5.1.8.6 Trusted update (FWcPP20E:FPT_TUD_EXT.1)
FWcPP20E:FPT_TUD_EXT.1.1
The TSF shall provide Security Administrators the ability to query the currently executing version
of the TOE firmware/software and [no other TOE firmware/software version].
FWcPP20E:FPT_TUD_EXT.1.2
The TSF shall provide Security Administrators the ability to manually initiate updates to TOE
firmware/software and [no other update mechanism].
FWcPP20E:FPT_TUD_EXT.1.3
The TSF shall provide means to authenticate firmware/software updates to the TOE using a
[digital signature mechanism] prior to installing those updates.
5.1.9 TOE access (FTA)
5.1.9.1 TSF-initiated Termination (FWcPP20E:FTA_SSL.3)
FWcPP20E:FTA_SSL.3.1
The TSF shall terminate a remote interactive session after a Security Administrator-configurable
time interval of session inactivity.
5.1.9.2 User-initiated Termination (FWcPP20E:FTA_SSL.4)
FWcPP20E:FTA_SSL.4.1
The TSF shall allow Administrator-initiated termination of the Administrator's own interactive
session.
5.1.9.3 TSF-initiated Session Locking (FWcPP20E:FTA_SSL_EXT.1)
FWcPP20E:FTA_SSL_EXT.1.1
The TSF shall, for local interactive sessions, [- terminate the session] after a Security
Administrator-specified time period of inactivity.
5.1.9.4 Default TOE Access Banners (FWcPP20E:FTA_TAB.1)
FWcPP20E:FTA_TAB.1.1
Before establishing an administrative user session the TSF shall display a Security Administrator-
specified advisory notice and consent warning message regarding use of the TOE.
5.1.10 Trusted path/channels (FTP)
5.1.10.1 Inter-TSF trusted channel (FWcPP20E:FTP_ITC.1)
FWcPP20E:FTP_ITC.1.1
The TSF shall be capable of using [TLS] to provide a trusted communication channel between
itself and authorized IT entities supporting the following capabilities: audit server, [no other
capabilities] that is logically distinct from other communication channels and provides assured
identification of its end points and protection of the channel data from disclosure and detection of
modification of the channel data.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 29 of 49
FWcPP20E:FTP_ITC.1.2
The TSF shall permit the TSF or the authorized IT entities to initiate communication via the
trusted channel.
FWcPP20E:FTP_ITC.1.3
The TSF shall initiate communication via the trusted channel for [transmitting audit records to
an audit server].
5.1.10.2 Trusted Path (FWcPP20E:FTP_TRP.1/Admin)
FWcPP20E:FTP_TRP.1.1/Admin
The TSF shall be capable of using [TLS] to provide a communication path between itself and
authorized remote Administrators that is logically distinct from other communication paths and
provides assured identification of its end points and protection of the communicated data from
disclosure and provides detection of modification of the channel data.
FWcPP20E:FTP_TRP.1.2/Admin
The TSF shall permit remote Administrators to initiate communication via the trusted path.
FWcPP20E:FTP_TRP.1.3/Admin
The TSF shall require the use of the trusted path for initial Administrator authentication and all
remote administration actions.
5.1.10.3 Trusted Path (FWcPP20E:FTP_TRP.1/Join)
FWcPP20E:FTP_TRP.1.1/Join
The TSF shall provide a communication path between itself and a joining component that is
logically distinct from other communication paths and provides assured identification of [both
joining component and TSF endpoint] and protection of the communicated data from
modification [and disclosure].
FWcPP20E:FTP_TRP.1.2/Join
The TSF shall permit [the joining component] to initiate communication via the trusted path.
FWcPP20E:FTP_TRP.1.3/Join
The TSF shall require the use of the trusted path for joining components to the TSF under
environmental constraints identified in [the Forcepoint Next Generation Firewall Common
Criteria Evaluated Configuration Guide].
5.2 TOE Security Assurance Requirements
The SARs for the TOE are the components as specified in Part 3 of the Common Criteria. Note that the SARs have
effectively been refined with the assurance activities explicitly defined in association with both the SFRs and SARs.
Requirement Class Requirement Component
ADV: Development ADV_FSP.1: Basic Functional Specification
AGD: Guidance documents AGD_OPE.1: Operational User Guidance
AGD_PRE.1: Preparative Procedures
ALC: Life-cycle support ALC_CMC.1: Labelling of the TOE
ALC_CMS.1: TOE CM Coverage
ATE: Tests ATE_IND.1: Independent Testing - Conformance
AVA: Vulnerability assessment AVA_VAN.1: Vulnerability Survey
Table 3 Assurance Components
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 30 of 49
5.2.1 Development (ADV)
5.2.1.1 Basic Functional Specification (ADV_FSP.1)
ADV_FSP.1.1d
The developer shall provide a functional specification.
ADV_FSP.1.2d
The developer shall provide a tracing from the functional specification to the SFRs.
ADV_FSP.1.1c
The functional specification shall describe the purpose and method of use for each SFR-enforcing
and SFR-supporting TSFI.
ADV_FSP.1.2c
The TSF shall support mutual authentication of TLS clients using X.509v3 certificates.
ADV_FSP.1.3c
The functional specification shall provide rationale for the implicit categorization of interfaces as
SFR-non-interfering.
ADV_FSP.1.4c
The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.
ADV_FSP.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ADV_FSP.1.2e
The evaluator shall determine that the functional specification is an accurate and complete
instantiation of the SFRs.
5.2.2 Guidance documents (AGD)
5.2.2.1 Operational User Guidance (AGD_OPE.1)
AGD_OPE.1.1d
The developer shall provide operational user guidance.
AGD_OPE.1.1c
The operational user guidance shall describe, for each user role, the useraccessible functions and
privileges that should be controlled in a secure processing environment, including appropriate
warnings.
AGD_OPE.1.2c
The operational user guidance shall describe, for each user role, how to use the available interfaces
provided by the TOE in a secure manner.
AGD_OPE.1.3c
The operational user guidance shall describe, for each user role, the available functions and
interfaces, in particular all security parameters under the control of the user, indicating secure
values as appropriate.
AGD_OPE.1.4c
The operational user guidance shall, for each user role, clearly present each type of security-
relevant event relative to the user-accessible functions that need to be performed, including
changing the security characteristics of entities under the control of the TSF.
AGD_OPE.1.5c
The operational user guidance shall identify all possible modes of operation of the TOE (including
operation following failure or operational error), their consequences, and implications for
maintaining secure operation.
AGD_OPE.1.6c
The operational user guidance shall, for each user role, describe the security measures to be
followed in order to fulfill the security objectives for the operational environment as described in
the ST.
AGD_OPE.1.7c
The operational user guidance shall be clear and reasonable.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 31 of 49
AGD_OPE.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.2.2 Preparative Procedures (AGD_PRE.1)
AGD_PRE.1.1d
The developer shall provide the TOE, including its preparative procedures.
AGD_PRE.1.1c
The preparative procedures shall describe all the steps necessary for secure acceptance of the
delivered TOE in accordance with the developer's delivery procedures.
AGD_PRE.1.2c
The preparative procedures shall describe all the steps necessary for secure installation of the TOE
and for the secure preparation of the operational environment in accordance with the security
objectives for the operational environment as described in the ST.
AGD_PRE.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
AGD_PRE.1.2e
The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared
securely for operation.
5.2.3 Life-cycle support (ALC)
5.2.3.1 Labelling of the TOE (ALC_CMC.1)
ALC_CMC.1.1d
The developer shall provide the TOE and a reference for the TOE.
ALC_CMC.1.1c
The TOE shall be labelled with its unique reference.
ALC_CMC.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.3.2 TOE CM Coverage (ALC_CMS.1)
ALC_CMS.1.1d
The developer shall provide a configuration list for the TOE.
ALC_CMS.1.1c
The configuration list shall include the following: the TOE itself; and the evaluation evidence
required by the SARs.
ALC_CMS.1.2c
The configuration list shall uniquely identify the configuration items.
ALC_CMS.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.4 Tests (ATE)
5.2.4.1 Independent Testing - Conformance (ATE_IND.1)
ATE_IND.1.1d
The developer shall provide the TOE for testing.
ATE_IND.1.1c
The TOE shall be suitable for testing.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 32 of 49
ATE_IND.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ATE_IND.1.2e
The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
5.2.5 Vulnerability assessment (AVA)
5.2.5.1 Vulnerability Survey (AVA_VAN.1)
AVA_VAN.1.1d
The developer shall provide the TOE for testing.
AVA_VAN.1.1c
The TOE shall be suitable for testing.
AVA_VAN.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence..
AVA_VAN.1.2e
The evaluator shall perform a search of public domain sources to identify potential vulnerabilities
in the TOE.
AVA_VAN.1.3e
The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to
determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack
potential.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 33 of 49
6. TOE Summary Specification
This chapter describes the security functions:
- Security audit
- Communication
- Cryptographic support
- Firewall
- Identification and authentication
- Security management
- Protection of the TSF
- TOE access
- Trusted path/channels
6.1 Security audit
The TOE generates audit records for all events identified by the requirement. The TOE audit mechanism cannot be
disabled. The TOE’s audit records include the required date, time, type, subject, outcome and event type values.
The startup and shutdown of the audit function is synonymous with the start-up and shutdown of the TOE. The set
of potential audit events and record information include all of the events defined in Table 2 Audit events.
The audit mechanism associated with firewall rules is the “logging” operation which is triggered using the logging
option of a rule in the TOE security policy. The TOE applies the matching mechanism for packet filtering, and for
each match a logging option can be defined that generates an audit record. The TSF selects the audited events based
on the defined logging options. In addition to the logging operation, the TOE provides an audit record when the
TOE security policy (i.e., active file) changes. When the TOE receives a new security policy it generates an audit
record identifying the date, time, and configuration identification. The components of the TOE rely on the clock
provided by hardware and made available through the component’s operating system to provide the timestamp for
audit records. The SMC Management Server generates audit records providing the details on the use of the security
management functions. The NGFW Engine generates audit events pertaining to packet filtering. All other security
relevant audit events are generated by all TOE components.
The NGFW Engine transfers audit records to the SMC Appliance Log Server immediately after generation of the
record. The SMC Appliance Log Server stores Engine records and can also send those audits to an external syslog
server immediately after they have been received. The SMC Appliance Management Server generates audit records,
stores the records locally and can (if configured) send them to an external syslog server immediately after storing the
records. When a connection to the external syslog server fails, the Management Server or Log Server will re-establish
the connection and send NEW audit records to the syslog server.
When the NGFW Engine cannot transfer newly generated audit records to the Log Server (irrespective of the cause),
the Engine will spool the records on disk. Once the NGFW Engine can again transfer audit records to the Log
Server, it transfers the oldest records first and removes those from its spool, continuing until it has transferred all
spooled records. If the NGFW Engine cannot transfer its audit records to the Log Server for an extended period of
time, it may start to exhaust its available spool disk storage space (the size of this spool depends on the size of the
disk in the NGFW Engine model, but the 2105/3305/6205 models provide 48/314/314GB of spool space,
respectively). In such an event the NGFW Engine first sends alerts to notify the administrator that it has nearly
exhausted its log spool, and once it exhausts its spool space, it follows the administrator defined behavior.
The Log Server, which aggregates audit records from NGFW Engines, writes incoming audit entries to the SMC
Appliance disk storage (the Log Server’s audit storage has its own 180GB logical partition in which to store the
records). The proprietary protocol for synchronizing and managing the data between the NGFW Engine and the
SMC Appliance Log Server starts with the Engine notifying the Log Server that there is a new log and then sending
the new log entry to the Log Server. The Log Server stores the audit information as database files which are only
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 34 of 49
accessible to a TOE administrator via the SMC Management Client. Again, only after the Log Server confirms
successful receipt and storage of an audit entry does an Engine remove the audit entry from its spool.
The Log Server itself has a limited amount of disk storage in which to hold its database audit records. If the Log
Server draws close to exhausting this space (specifically if it has fewer than 300MB of space remaining), it will alert
the administrator (by creating an audit alert that the SMC Client displays to the administrator) warning of the low
storage remaining (and the administrator can take action to remove old audit records). Should the Log Server
continue to fill up its storage space and have less than 100MB of space remaining, it will stop accepting new audit
messages from Engines.
The Management Server, like the Log Server, has a finite amount of space to store management audit records
(10GB) on the SMC Appliance’s disk. The Management Server stores its logs in a separate partition (the root
partition), and should the Management Server begin to exhaust this space, it behaves similarly to the Log Server.
When less than 300MB of space remains, the Management Server generates an administrative alert (displayed to the
administrator through the SMC Client), and when less than 100MB of space remains, the Management Server will
no longer allow the administrator to make configuration changes (as such a change would result in an audit message
that the Management Server no longer has sufficient space to safely store) until action is taken by the administrator
to delete local audit data.
As mentioned above, the administrator defines the log spool policy for the NGFW Engines. This specifies the
behavior of the NGFW Engines whenever its local log spool fills. The TOE supports two settings, but requires that
only the following be used when in an evaluated configuration:
• Stop traffic (required in the evaluated configuration): NGFW Engine automatically goes to an offline state
and connections going through NGFW Engine are transferred to other nodes in a cluster (if the Engine were
part of a cluster). Once the spool situation has improved, the Engine/node returns automatically to an online
state.
The TOE also provides a means for the Management Server to prioritize log data. The mechanism is based on the
following log level:
• Alert: generated with an alert status and always stored;
• Essential: always generated even if the NGFW Engine is running out of disk space;
• Stored: stored to the audit log database if alert and essential log entries have already been stored;
• Transient: not stored to database but kept in TOE log cache.
Before applying the selected log spooling policy, the Engine stops producing transient logs. If insufficient, it can
drop all but the essential log entries. As a last resort, the engine applies the selected log spooling policy.
The Security audit function is designed to satisfy the following security functional requirements:
• FAU_GEN.1: The set of potential audit events and record information include all of the events defined in
Table 2 Audit events. The records include the required date, time, type, subject, outcome and event type
values. The TOE also inserts into audit records all of the additional information described by Table 2 Audit
events.
• FAU_GEN.2: Every audit record indicates the SMC user responsible for the action. Additionally, the TOE
records the key name (the string provided by the administrator) as an identifier of any TOE key generated,
imported, changed, or deleted.
• FAU_STG_EXT.1: All audit records generated by the NGFW Engine are transmitted first to the SMC
Appliance’s Log Server and then (if configured by an administrator) forwarded to an external syslog server
using TLS protected syslog. The SMC can forward its audit records to an external syslog server using TLS
protected syslog (if configured by an administrator).
6.2 Communication
The Communication function satisfies the following security functional requirements:
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 35 of 49
• FWcPP20E:FCO_CPC_EXT.1: The TOE utilizes TLS to provide a registration channel between a new
Engine and the SMC. The TOE requires that an administrator first create a new NGFW Engine object from
within the SMC. Upon completion, the SMC generates and provides the administrator with a 45-character
“password” (the SMC generates a unique “password” for each and every registration attempt) as well as the
SHA-512 hash of the SMC’s server TLS certificate. The administrator then inputs this password into the
Engine (via console) and initiates the registration connection from the Engine. The Engine confirms that the
SMC’s TLS certificate SHA-512 hash either matches the administrator pre-configured value (if the
administrator chose to enter it) or displays the hash for the administrator to confirm. Then the SMC
authenticates the Engine by requesting the Engine send the SHA-512 hash of the SMC-generated password.
Once authenticated, the SMC pushes the SMC’s internal CA certificate to the Engine, the Engine creates a
CSR that the SMC’s internal CA uses to issue the Engine a TLS certificate, and the Engine validates the
received TLS certificate. SMC pushes then a policy to the Engine. The policy contains the Log Server
reference identifier.
After completion, the Engine and SMC subsequently communicate through mutually-authenticated TLS
connections.
Finally, note that the TOE, by design, restricts communications between components and only permits
communications between the SMC and Engines, and does not support direct communication between two
Engines.
6.3 Cryptographic support
The TOE utilizes cryptographic support features as part of the TLS protocol mechanism as well as to verify software
(both TOE updates and installed software). Each component of the TOE utilizes the cryptographic module
available to it as follows:
1. NGFW Engine uses cryptography from its 1.0.2r OpenSSL library (which incorporates the Forcepoint
NGFW FIPS Object Module 2.0.14) for TLS connection, CSR generation, Engine integrity testing, and
Engine Trusted Updates
2. SMC Appliance
a. SMC Appliance uses cryptography from its 1.0.2s OpenSSL library (which incorporates the SMC
FIPS Object Module 2.0.13) for password hashing, integrity testing and verification of Trusted
Updates
b. SMC Appliance’s Management and Log Server use cryptography from the SMC FIPS Java API
1.0.2 for the TOE TLS, CSR generation, and password hashing
SFR Algorithm NIST Standard Cert#
FCS_CKM.1 (Key Gen) ECDSA ECC Key Generation FIPS 186-4, ECDSA C852
FCS_CKM.2 (Key
Establishment)
ECC-based Key Exchange SP 800-56A,
KAS ECC
C852
FCS_COP.1/DataEncryption AES 128/256 CBC, GCM FIPS 197, SP 800-38A/D C852
FCS_COP.1/SigGen ECDSA Sign/Verify FIPS 186-4, ECDSA C852
FCS_COP.1/Hash SHA Hashing FIPS 180-4 C852
FCS_COP.1/KeyedHash HMAC-SHA FIPS 198-1 & 180-4 C852
FCS_RBG_EXT.1 (CTR)
(Random)
DRBG Bit Generation SP 800-90A
C852
Table 6-1 NGFW Engine Forcepoint NGFW FIPS Object Module 2.0.14 CAVP Certificates
SFR Algorithm NIST Standard Cert#
FCS_CKM.1 (Key Gen)
RSA IFC Key Generation FIPS 186-4, RSA C1042
ECDSA ECC Key Generation FIPS 186-4, ECDSA C1042
FCS_CKM.2 (Key
Establishment)
RSA-based Key Exchange Vendor affirm 800-56B N/A
ECC-based Key Exchange SP 800-56A,
KAS ECC
C1042
FCS_COP.1/DataEncryption AES 128/256 CBC, GCM FIPS 197, SP 800-38A/D C1042
FCS_COP.1/SigGen RSA Sign/Verify FIPS 186-4, RSA C1042
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 36 of 49
SFR Algorithm NIST Standard Cert#
ECDSA Sign/Verify FIPS 186-4, ECDSA C1042
FCS_COP.1/Hash SHA Hashing FIPS 180-4 C1042
FCS_COP.1/KeyedHash HMAC-SHA FIPS 198-1 & 180-4 C1042
FCS_RBG_EXT.1 (CTR,
Hash)(Random)
DRBG Bit Generation SP 800-90A
C1042
Table 6-2 SMC Appliance SMC FIPS Java API 1.0.2 CAVP Certificates
SFR Algorithm NIST Standard Cert#
FCS_CKM.1 (Key Gen) ECDSA ECC Key Generation FIPS 186-4, ECDSA C851
FCS_CKM.2 (Key
Establishment)
ECC-based Key Exchange SP 800-56A,
KAS ECC
C851
FCS_COP.1/DataEncryption AES 128/256 CBC, GCM FIPS 197, SP 800-38A/D C851
FCS_COP.1/SigGen
ECDSA Sign/Verify FIPS 186-4, ECDSA
C851
FCS_COP.1/Hash SHA Hashing FIPS 180-4 C851
FCS_COP.1/KeyedHash HMAC-SHA FIPS 198-1 & 180-4 C851
FCS_RBG_EXT.1(CTR)
(Random)
DRBG Bit Generation SP 800-90A
C851
Table 6-3 SMC Appliance SMC FIPS Object Module 2.0.13 CAVP Certificates
6.3.1 NGFW Engine
The NGFW Engine uses the Forcepoint NGFW FIPS Object Module 2.0.14 (see Table 6-1) for hashing, HMAC, and
signature related operations.
6.3.2 SMC Appliance
The primary functions of the SMC Appliance are provided by the Management Server and the Log Server (described
in following sections). However, the SMC Appliance performs the verification of trusted updates, independent of the
operation of the Management Server and the Log Server. The operation of the TOE update feature is described in
section 6.8, and the cryptography verifying the validity of the update comes from the SMC Appliance SMC FIPS
Object Module 2.0.13.
The SMC ApplianceSMC FIPS Object Module 2.0.13 does not generate keys, but instead uses cryptography for (local
console) password hashing, for power-up integrity testing, and for signature verification of TOE updates.
The SMC Appliance uses a software noise source, and uses the Linux kernel Random Number Generator (LKRNG)
to provide output to user space (through /dev/random). The SMC Appliance uses /dev/random to instantiate its SMC
FIPS Java API 1.0.2’s SHA-512 HASH_DRBG and generate keys. The SMC FIPS Java API 1.0.2 is used by the
Management Server and Log Server as described below.
6.3.2.1 Management Server
The SMC Appliance’s Management Server builds and signs, custom constructed certificates that are used by the
Management Server within TLS protocol session negotiations. Once the Management Server is initially installed, it
creates a custom constructed ECDSA certificate for itself.
The Management Server utilizes the SMC FIPS Java API 1.0.2 for all encryption, decryption, hashing and signature
operations associated with support for the TLS protocol. That Java library draws from /dev/random to instantiate is
DRBG (a SHA-512 Hash_DRBG) as described in 6.3.2.
The Management Server also generates salts for password hashing and SHA-512 hashes user passwords (both when
creating a new user or when verifying the password of an existing user).
The Management Server communicates directly with an external syslog server to transmit audit records which it
generates. Management Server audit records are not sent through the Log Server, but instead are transmitted directly
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 37 of 49
to an external syslog server. The Management Server communicates with the external syslog server using TLSv1.2
protocol and the cipher suites identified by Table 6-4.
The Management Server also accepts incoming administrative sessions (SMC Client connections) that are protected
by TLS, and uses the cipher suites identified by Table 6-5.
6.3.2.2 Log Server
The SMC Appliance’s Log Server communicates with the NGFW Engine over the dedicated network.
Communication between the Log Server and the Management Server are initiated by the Management Server to
transfer configuration data to the Log Server.
The Log Server utilizes the SMC FIPS Java API 1.0.2 library for all encryption, decryption, hashing and signature
operations associated with support for the TLS protocol.
Communication between the Log Server and external syslog servers will be initiated by the Log Server. All
connections to an external syslog server are protected using the TLSv1.2 protocol. The Log Server is capable of
utilizing the following cipher suites to communicate to an external syslog server.
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_ SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Table 6-4 Cipher suites to communicate with an External Syslog Server
The SMC FIPS Java API 1.0.2 used by the SMC Appliance (and thus used by both the Management and Log Servers)
uses the same /dev/random to instantiate its SMC FIPS Java API 1.0.2’s SHA-512 HASH_DRBG and generate keys
and that is described as part of the SMC Appliance in 6.3.2.
Similar to the Management Server, the Log Server also accepts incoming administrative sessions (SMC Client
connections) that are protected by TLS. Again, the Log Server, like the Management Server, utilizes the below cipher
suites to protect remote administrative sessions. These same ciphers are used for all inter-TOE communication among
the distributed TOE components.
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Table 6-5 Cipher suites to communicate with remote administrators
6.3.3 Cryptographic Support Summary
The following table presents the crypto security parameters (CSPs), secret keys, and private keys provided by the
TOE. The table also identifies when each CSP or key is cleared.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 38 of 49
CSP or Key: Stored in Zeroized upon: Zeroized by:
TLS Host RSA or ECDSA private key On Disk Command Overwriting with pseudo-
random data
TLS pre-master secret In Memory Handshake done Overwriting with zeros
TLS session key In Memory Close of session Overwriting with zeros
Passwords On Disk Command Overwriting once with pseudo-
random data
Table 6-6 CSPs and Keys
The Cryptographic support function is designed to satisfy the following security functional requirements:
• FCS_CKM.1: The SMC Appliance supports asymmetric key generation for key establishment as part of
TLS as described in the section above. The following table details which components act as TLS clients and
servers as well as which ones generate RSA or ECDH keys used during ECDHE_* and TLS_RSA_* TLS
cipher suite negotiation.
TOE Component Client/Server/Both DH key gen? ECDH gen? ECDSA gen? RSA gen?
Mgmt Server Both N/A Yes Yes Yes
Log Server Both N/A Yes Yes Yes
Engine Both N/A Yes Yes Yes
The TOE, when in the evaluated configuration, uses 256-bit encryption mode as the security strength. This
setting causes the TOE to generate an ECDSA P-521 TLS server certificate, and also to use only AES-256
cipher suites for remote administrator connections. (Note that the TOE provides the administrator the
flexibility to use AES-256 or AES-128 cipher suites for the TLS protected syslog export client. The TOE
also provides the administrator the ability to generate or import either an ECDSA [P-256, P-384, or P-521]
or RSA [2048, 3072] key to use for TLS Client or mutual authentication during TLS syslog export).
• FCS_CKM.2: See FCS_CKM.1
• FCS_CKM.4: The TOE components clear keys (TLS) from memory after those keys are no longer needed.
After use on the SMC keys are overwritten with zeros and garbage collector is called. This is performed by
the SMC Java Code and SMC FIPS Java API. After use on the NGFW Engine Keys are overwritten with
zeros. This is performed by the OpenSSL FIPS Object Module.
The TOE uses file system calls to clear persistently stored keys. On the SMC, TLS private keys are stored in
a Java Keystore. To clear these keys the disk must be wiped. This can be done via the installer by selecting
the “Secure wipe with Automatic install”. Data is sourced from /dev/random and then written to the disk.
This is done 3 times for the whole disk.
On the NGFW Engine TLS private keys are stored in a flat file. To clear these keys the disk must be wiped.
This can be done by resetting to factory defaults and choosing a number of overwrites. Data is sourced from
/dev/random and then written to disk.
• FCS_COP.1/DataEncryption: The TOE performs encryption and decryption using AES in either CBC or
GCM mode, and key sizes of either 128 or 256 as described in section 6.3. The crypto modules providing
the AES implementation and the corresponding CAVP certificates are identified in the tables above in section
6.3 (Table 6-1, Table 6-2, and Table 6-3).
• FCS_COP.1/SigGen: The TOE supports the use of RSA with 2048 bit key sizes, and ECDSA with a key
size of 256 bits or greater for cryptographic signatures (specifically NIST curves P-256, P-384, or P-521).
The crypto modules providing the cryptographic signature services are identified in the tables above.
• FCS_COP.1/Hash: The TOE supports cryptographic hashing services using SHA-1, SHA-256, SHA-384,
and SHA-512. The crypto modules providing the cryptographic hashing services are identified in the tables
above.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 39 of 49
• FCS_COP.1/KeyedHash: The TOE supports keyed-hash message authentication using HMAC-SHA-1,
HMAC-SHA-256, and HMAC-SHA-384 using SHA-1/256/384 with 160/256/384-bit keys to produce a
160/256/384 output MAC. The SHA-1/256 and 384 algorithms have block sizes of 512 and 1024-bits
respectively. The crypto modules providing the keyed-hash message authentication with the corresponding
FIPS certificates are identified in the tables above. Keyed Hashing is used for the following purposes with
these key sizes:
- TLS 1.2 master secret 384 bits,
- RSA premaster secret 384 bits,
- ECDHE premaster secret sizes for 256, 384 and 512 bits for P-256, P-384 and P-521, respectively
(note that in TLS_ECDHE_* cipher suites, the TOE offers all three NIST curves and will select
based upon what the peer specifies).
- TOE integrity check (both the NGFW Engine and SMC Appliance check their file system integrity
using HMAC-SHA-256 using a hardcoded 256-bit key), and
- TLS 1.2 will use HMAC-SHA-1, HMAC-SHA-256 and HMAC-SHA-384 with a 160/256/384 bit
key, respectively.
• FCS_RBG_EXT.1: The TOE components perform random bit generation in support of the cryptographic
functions. The SMC uses both an AES-256 CTR_DRBG and a SHA-512 Hash_DRBG while the Engines
use an AES-256 CTR_DRBG (see Table 6-1, Table 6-2, Table 6-3 above which identify the DRBG CAVP
certificates).
• FCS_TLSC_EXT.2: The TOE communicates with both remote audit servers and other distributed TOE
components using the TLS protocol. For TLS communication with remote audit servers, the administrator
can configure a reference identifier of DNS name, IP address, Common Name, Distinguished Name, SHA-
1, SHA-256, SHA-512, and MD5 hash of the peer certificate. When configured with a DNS Name, the TOE
will check the administrator configured value against the certificate’s CN and SAN:DNS identifiers fields by
first comparing the expected value against each SAN:DNS extension present in the certificate (if present),
and if the TOE finds no SAN:DNS extensions, it will then compare the expected value against the certificate’s
CN. For communication with distributed TOE components, the TOE mandates a numerical identifier to be
found in the SAN:DNS extension. This expected numerical identifier is negotiated at the time of registration
of the NGFW Engine to the SMC. The TOE does not support certificate pinning. The administrator need not
(and cannot) explicitly configure anything regarding the ECDHE curves, the TOE always presents P-256, P-
384, and P-521 curves in its client hello. The TOE supports wildcards for TLS communication with a remote
audit server. The TOE does not support wildcards and will always reject them for Distributed TOE
communication.
• FCS_TLSS_EXT.1/2: The TOE provides a TLS interface for GUI administration.
The TOE’s TLS server acts similarly to its TLS client in that the administrator need not (and cannot)
explicitly configure anything regarding the ECDHE curves, the TOE will negotiate P-256, P-384, or P-521
curves based upon what the peer/client specifies it supports in its hello. Similarly the administrator need not
and cannot specify the versions of TLS that the TOE’s server will negotiate, the TOE only negotiates TLS
v1.2 with clients. The TOE also provides a mutually authenticated TLS server interface on the SMC and
Engines to allow for secure, distributed TOE communications between those two components. Aside from
the differences in authentication (mutually authenticated using Internal CA certificates), the TOE’s different
TLS server interfaces use the same cipher suites and curves. When the components exchange certificates as
part of distributed TOE TLS handshake authentication, each side compares the received SAN:DNS to ensure
that it matches the expected identifier of the component (the TOE’s components require the presence of the
SAN:DNS and does not rely upon CN).
6.4 User data protection
The TOE has been designed to ensure that no residual information exists in network packets. When the TOE allocates
a new buffer for either an incoming or outgoing network packet, the new packet data will be used to overwrite any
previous data in the buffer. If an allocated buffer exceeds the size of the packet, any additional space will be
overwritten (padded) with zeros before the packet is forwarded (to the external network or delivered to the appropriate,
internal application).
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 40 of 49
The User data protection function is designed to satisfy the following security functional requirements:
• FDP_RIP.2: The TOE ensures that previous information contents of resources used for new objects are not
discernible in any new object, such as network packets, as described above.
6.5 Firewall
The TOE provides an information flow control mechanism using a rule base that comprises a set of security policy
rules, i.e., the firewall security policy. The NGFW Engine enforces the firewall security policy on all traffic that
passes through the engine, via its internal or external network Ethernet interfaces. The traffic is TCP, UDP, ICMPv4,
ICMPv6, connections over IPv4 and IPv6. The NGFW Engine inspects and filters these protocols based upon their
header fields as defined by their corresponding RFC (See Table 6-7).
The NGFW Engine only permits traffic to pass through that has been explicitly allowed by the firewall security policy,
and implements packet defragmentation to enforce the policy on entire IP packets. Administrators using the
Management Server define the firewall security policy rules.
Protocol Related RFC1
Fields Inspected
ICMPv4 RFC 792 Type, Code
ICMPv6 RFC 4443 Type, Code
IPv4 RFC 791 Source Address, Destination Address,
Transport layer protocol
IPv6 RFC 2460 Source Address, Destination Address,
Transport layer protocol
TCP RFC 793 Source Port, Destination Port
UDP RFC 768 Source Port, Destination Port
Table 6-7 Protocols & Fields Filtered by the TOE
Any network traffic passed by the NGFW Engine must be explicitly allowed by a firewall rule or be part of an
established session allowed by a rule, or it is dropped. This is true even in the case of attempts to flood a TOE interface
(in which case some packets may be dropped, but are never passed violating policy).
All received network packets are processed by the NGFW Engine software module before transmission. The NGFW
software module does stateful filtering of the received network packets according to the configured traffic filtering
rules. Protocol Agents are used for advanced processing of traffic that require special handling such as permitting an
FTP data connection dynamically. The NGFW Engine software denies the traffic if the Protocol Agent cannot process
the traffic. Incoming packets are dropped if a network packet cannot be processed due to insufficient memory. All
incoming network packets are also discarded before the NGFW Engine software module has been loaded, and the
NGFW Engine software module denies all traffic until the module has been configured. Network interfaces and
routing are configured after the NGFW Engine software module has been loaded. If the configured firewall rules
cannot be applied during startup, only the management network interface will be available and traffic through the
firewall will be denied.
The NGFW Engine has been designed to ensure that no residual information exists in network packets. When the
NGFW Engine allocates a new buffer for either an incoming or outgoing network packet, the new packet data will be
used to overwrite any previous data in the buffer. If an allocated buffer exceeds the size of the packet, any additional
space will be overwritten (padded) with zeros before the packet is forwarded (to the external network or delivered to
the appropriate, internal application). The NGFW Engine implements connection tracking to manage the information
flow control decisions for connections (i.e., stateful sessions) rather than packets, providing increased performance
and support for firewall features that require packet information above the IP level (e.g., ICMP, TCP, UDP). The
connection tracking mechanism stores the state information of each connection to allow packets belonging to an
established connection to pass. The connection tracking uses the fields shown in the following table when determining
whether a packet matches an allowed established session for the corresponding protocol. Connection tracking follows
the standard TCP handshaking process (SYN, responding SYN-ACK, followed by ACK) to denote establishment of
1
Compliance with these RFCs is demonstrated by in-house compliance testing.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 41 of 49
a stateful session, and the TOE’s connection tracking will eliminate existing connections immediately, upon
completion of the flow (in the case of TCP and FTP) or upon an inactivity timeout for the session.
Protocol Connection Tracking
TCP Source & Destination Address, Source & Destination Port, Sequence Number, Flags
UDP Source & destination address, source & destination port
ICMP Source and destination address, type, code
FTP TCP data session attributes
Table 6-8 Connection Tracking Fields
Connection tracking works closely with the protocol agents to manage the information flow control decisions based
on information attributes at the different networking layers through the application layer to decide whether a packet
should be granted access or not. The following protocol agents and their security function are within the scope of the
evaluation: FTP (RFC 959).
The FTP Protocol Agent keeps track of the ports used in File Transfer Protocol (FTP) sessions. An FTP session starts
with a control connection (by default, TCP port 21), and the communications continue using a dynamically allocated
port. The FTP Protocol Agent opens the actual ports used in FTP sessions as needed so that the whole range of possible
dynamic ports does not need to be allowed in the policy.
The NGFW Engine follows a specific orderly algorithm to traverse the rule base for matching and filtering the traffic
between its internal and external networks. Any traffic that is not explicitly accepted by the security policy is rejected
by the firewall. The structure of the rule base and the capabilities of its associated protocol agents enable the TSF to
make the information flow control decisions.
Each rule comprises matching criteria and target actions. If the matching criteria is verified (i.e., a comparison
matches) the NGFW Engine applies the target actions. Possible target actions include Allow, Discard and Refuse2.
Access rules with the logging option, can create a log or alert entry each time they match. The logging option is in
addition to the target action of a rule. An administrator can specify that a rule applies to a specific interface by
specifying a zone, adding a given firewall interface to that zone, and then specifying that zone as either a source or
destination address for the rule.
The NGFW Engine compares the information attributes defined in Table 6-7 Protocols & Fields Filtered by the TOE
with the matching criteria of the rule to determine whether to apply the rule. If applied, the target actions are
implemented and the additional capabilities and flow control rules defined in Table 6-9 Additional Stateful Filtering
Rules are applied.
Rules relating to FFW_RULE_EXT.1.6
a) The NGFW Engine denies and allows logging packets which are invalid fragments;
b) The NGFW Engine denies and allows logging fragmented packets which cannot be re-
assembled completely;
c) The NGFW Engine denies and allows logging packets where the source address of the
network packet is defined as being on a broadcast network;
d) The NGFW Engine denies and allows logging packets where the source address of the
network packet is defined as being on a multicast network;
The NGFW Engine denies and allows logging network packets where the source address
of the network packet is defined as being a loopback address;
e) The NGFW Engine denies and allows logging network packets where the source or
destination address of the network packet is defined as being unspecified (i.e. 0.0.0.0) or
an address 'reserved for future use' (i.e. 240.0.0.0/4) as specified in RFC 5735 for IPv4;
f) The NGFW Engine denies and allows logging network packets where the source or
destination address of the network packet is defined as an 'unspecified address' or an
2
Additional target actions of “Continue” and “Jump” described later support complex security policies.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 42 of 49
address 'reserved for future definition and use' (i.e. unicast addresses not in this address
range: 2000::/3) as specified in RFC 3513 for IPv6;
g) The NGFW Engine denies and allows logging network packets with the IP options: Loose
Source Routing, Strict Source Routing, or Record Route specified;
Rules relating to FFW_RULE_EXT.1.7
a) The NGFW Engine denies and logs packets where the source address is equal to the
address of the network interface where the network packet was received;
b) The NGFW Engine denies and logs packets where the source or destination address of the
network packet is a linklocal address;
c) The NGFW Engine denies and logs packets where the source address does not belong to
the networks associated with the network interface where the network packet was
received, as the Engine has an administrator defined set of networks associated with each
configured network interface.
Table 6-9 Additional Stateful Filtering Rules
The rule base is read from top down, and when the first matching rule is encountered the search stops and the TOE
executes the matching rule. There are two exceptions to this:
a) Jump rule - this makes the search jump to a sub-rule base if the jump rule matches. The search will continue
inside the sub-rule base until it either finds a matching rule or comes back empty-handed from the sub-rule
base and continues searching through the main rule base;
b) Continue rule - when it matches, it will set some variables and then the search continues.
The NGFW Engine obtains time values from the local hardware clock when making the security policy decisions
associated with time-based information flows.
During the NGFW Engine boot process, there is a lag between the time when the network interface is operational, and
the time that the Stateful Traffic Filtering functionality is fully functioning. During this time, traffic flow through the
appliance is disabled; and traffic to and from the appliance is controlled by a Default Filter that drops all external
traffic to the appliance.
The TOE can also track and maintain the number of half-open TCP connections, and the administrator can define a
limit of the number of such connections (either for the Engine as a whole or for a specific rule). When the TOE detects
that the threshold has been exceeded, the TOE denies additional SYN packets. The TOE will expire such half-open
TCP connections after fifteen seconds by default, and the administrator can change this default by configuring the
“TCP syn ack seen” timeout.
The Firewall function is designed to satisfy the following security functional requirements:
• FFW_RUL_EXT.1: The NGFW Engine filters network traffic using a rule base that comprises a set of
security policy rules. These rules allow for complex security policies to be defined which control the flow
of network traffic through the NGFW Engine. Controlled network traffic includes at least IPv4, IPv6,
ICMPv4, ICMPv6, TCP and UDP protocols. Additional features of the firewall functionality are described
above. The rule base is read from top down, and when the first matching rule is encountered the search stops
and the TOE executes the matching rule. Any traffic that is not explicitly accepted by the security policy is
rejected by the firewall.
• FFW_RUL_EXT.2: The TOE performs stateful packet filtering on the FTP protocol.
6.6 Identification and authentication
The TOE authenticates local and remote administrative users by means of a local password mechanism. Passwords
can be composed of upper or lower case letters, numbers, and special characters including “!”, “@”, “#”, “$”,“%”,
“^”, “&”, “*”, “(” and “)”. Administrators can specify a minimum length for passwords, and passwords can be
greater than 15 characters.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 43 of 49
Prior to login, the TOE displays a warning banner on both the GUI and local console interface. The TOE supports the
filtering and forwarding of network traffic through the NGFW Engine prior to an administrative user being
authenticated. The TOE requires login prior to allowing any TOE configuration actions.
The Identification and authentication function is designed to satisfy the following security functional requirements:
• FIA_AFL.1: The TOE allows the administrator to specify the maximum number of incorrect logins as well
as lock out period for an administrator who exceeds the maximum configured value. The administrator can
set the number of failed attempts to a value from 1-1000 and the lockout duration from 1-1000 (and choose
from minutes, hours, days). The TOE defaults to 6 incorrect attempts and a 30 minute lock out period. The
local CLI remains available when the remote account is locked out.
• FIA_PMG_EXT.1: Password for local accounts can be composed of upper or lower case letters, numbers,
and special characters as described above. Administrators can specify minimum lengths for passwords with
10 characters being the minimum in the evaluated configuration, and passwords can be greater than 15
characters.
• FIA_UAU.7: All passwords entered by administrators are obscured when entered.
• FIA_UAU_EXT.2: The TOE authenticates administrative users by means of a local password mechanism.
• FIA_UIA_EXT.1: The TOE displays a banner, and filters network traffic prior to administrative login. The
TOE also requires login prior to all administrative actions. The SMC Management Server only accepts
TLSv1.2 connections for management operations.
• FIA_X509_EXT.1/ITT/Rev: The TOE supports OCSP and CRL revocations for X509v3 certificate
validation during negotiation of TLS protected syslog. The TOE does not support revocation for internal
TOE communications between distributed TOE components. Certificates are validated as part of the
authentication process when they are presented to the TOE and when they are loaded into the TOE. The
following fields are verified as appropriate: signature, validity period, extended key usage, issuer’s name,
basic constraints (for CA certs).
• FIA_X509_EXT.2: Certificates are checked and if the TOE cannot establish a connection to determine the
validity of the certificate, the TOE’s behavior varies depending on revocation method (again, note that the
TOE performed revocation checking only when validating a server certificate when establishing a TLS
connection with a remote syslog server and the TOE performs no revocation checking as part of distributed
TOE TLS communications). When handling a certificate bearing OCSP revocation but where the TOE
cannot establish a connection with the OCSP responder, the TOE will not accept the certificate (and thus not
establish the connection). When handling certificates bearing CRL information but where the TOE cannot
establish a connection to the CRL Distribution Point location, the TOE will not accept the certificate as valid.
The TOE constructs the certificate path to a trusted certificate, and then verifies the signature, checks the
revocation status, validity period, issuer’s name, extended key usage and basic constraints for each certificate
starting from the trusted certificate.
• FIA_X509_EXT.3: The TOE generates certificate requests and validates the CA used to sign the certificate.
The TOE includes device-specific information in the form of Subject Alternative Name.
6.7 Security management
The TOE provides an administrator role. User accounts that are associated with the administrator role are considered
Security Administrators. Security Administrators can manage and configure audit configuration data, user and
administrator security attributes (including [re]setting passwords, but not viewing an existing password), warning
banner configuration, and cryptographic support settings. The TOE provides administrators the ability to configure
session inactivity timeouts.
The SMC Appliance offers two administrative interfaces – command line and GUI (the NGFW Engine provides no
administrator access at all). The SMC Appliance offers command line functions which are accessible via the CLI.
The CLI is a text based interface which can be accessed from a directly connected terminal. These command line
functions can be used to query the current SMC Appliance firmware version and update the SMC Appliance’s
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 44 of 49
firmware (an administrator must use the GUI to query and update NGFW Engine software), to manually set the SMC
Appliance’s time, and to configure the SMC CLI session time out.
The SMC Appliance also offers a non-CLI, remote interface for management. This remote interface offers access
through the GUI client using TLS v1.2, and provides all management functionality except those commands available
through the CLI.
The Security management function is designed to satisfy the following security functional requirements:
• FMT_MOF.1/Functions: The TOE allows only authenticated administrators to configure TLS protected
syslog export and to configure the TOE’s behavior when the local audit storage space becomes full.
• FMT_MOF.1/ManualUpdate: Only the administrator can initiate product updates. The administrator
initiates the updates of both the SMC and the Engines through the SMC. Each type of component performs
the required cryptographic signature checks when updating.
• FMT_MTD.1/CoreData: The TOE ensures that only security administrators can login to manage TSF data
and configure TOE services. TSF data include audit data, cryptographic data, authentication data,
configuration data, security attributes, session timeouts, and updates. The TOE requires that the administrator
perform all configuration through the SMC (which then communicates with the Engines under its control)—
the Engines provide no direct interface for administrators in their evaluated configuration.
• FMT_MTD.1/CryptoKeys: The TOE allows only authenticated administrators to configure (import,
generate, delete, change) cryptographic keys.
• FMT_SMF.1: Administrators can configure operations of the TOE through the GUI, including configuring
cryptographic functionality, audit behavior, authentication failure parameters, the reference identifier for the
peer (external syslog server), and services available prior to login. The local command line interface is used
by administrators to verify and install TOE updates, manually set the time, and configure the CLI session
timeout. The administrator can enable the interaction between TOE components (the TOE only allows
communications between the SMC and each of the Engines under its control) as part of the setup process.
The administrator can disable the interaction between TOE components by removing the Engine from the
SMC’s control.
• FMT_SMR.2: The TOE maintains an administrative role for users. Users in this role can perform
administrative actions locally or remotely.
6.8 Protection of the TSF
The Management Server stores passwords with other configuration data in a database and synchronizes this database
with the Linux password database (i.e., /etc/shadow....). Synchronization takes the form of the contents of the database
overwriting the contents of the Linux password database. There is no administrative interface to view or manipulate
the raw configuration database. The only interface to the database is through administrative actions which modify the
contents of the database in a controlled manner. Passwords are salted and hashed using SHA-512 when stored.
The distributed TOE communication between the NGFW Engine and the servers running on the SMC Appliance are
all protected using TLS network connections.
None of the TOE components utilize pre-shared keys or long-lived symmetric keys. The only keys retained by the
components of the TOE are associated with certificates used for TLS. The servers running on the SMC Appliance
store private keys in a password protected Java keystore.
Every appliance that is included as part of the TOE (i.e., NGFW Engines and SMC Appliance) includes its own real-
time hardware-based clock. The time values from this clock are used in audit records. The NGFW Engine receives
its time updates from the SMC Management Server only. The SMC Management Server is responsible for accepting
and propagating clock updates initiated by an administrator. The NGFW Engine always receives its time from the
SMC.
Each component of the TOE includes a set of hardware validation tests which include memory checks (to check for
bad or failing memory) and Known Answer Tests (KAT) for the cryptographic features provided by the NGFW Engine
Forcepoint NGFW FIPS Object Module 2.0.14, SMC Appliance SMC FIPS Object Module 2.0.13, and SMC
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 45 of 49
Appliance SMC FIPS Java API 1.0.2 cryptographic libraries. These KAT tests cover operation of AES, RSA, ECDSA,
DRBG, SHA and HMAC-SHA. For each KAT test, the TOE uses known data as inputs into each cryptographic
function, computes a cryptographic result (e.g., the AES ciphertext or SHA-512 hash), and compares the calculated
result to the expected/known value. If the two do not match, the NGFW Engine will reboot as a result of the error,
while the SMC Appliance will halt its boot as a result of a KAT error or any error in its verification of the HMAC-
SHA-256 checksum of the SMC binaries upon system startup. And in a similar fashion, the NGFW Engine (using its
Forcepoint NGFW FIPS Object Module 2.0.14 implementation) uses a hardcoded key to verify the HMAC-SHA-256
checksum of the whole partition containing TOE binaries and if it finds an error, it halts its boot. These hardcoded
keys are included in the Forcepoint software and the integrity check keys are protected against modifications using
the operating system access control mechanism.
The TOE performs trusted updates for both of its components: the SMC management appliance and NGFW Engines.
To update the TOE software of the NGFW Engine, an administrator can obtain an update from Forcepoint and then
upload the update to the SMC. After the SMC has the update, the SMC will verify the Forcepoint ECDSA P-521 w/
SHA-512 signature on the update package and, only if the signature verifies correctly, the SMC will import that
package, making it available to update administrator specified NGFW Engines with the new software. Once the
administrator selects to upgrade a specific NGFW Engine with a patch, the SMC will transfer that update to the NGFW
Engine, the Engine will also verify the signature on the update (even though the SMC has already verified the update),
the Engine will use that update package (which is an full filesystem image) to write to an internal, alternate
software/system partition, and then, after verifying the checksum of the newly written system partition to check for
write corruptions, the Engine will reboot into that new partition.
To update the SMC itself, the administrator obtains an SMC patch from Forcepoint. The evaluator can make the patch
available to the SMC two different ways, either by saving the patch to an administrator provided USB thumb-drive
which is then mounted to the SMC or by uploading it to the SMC through the GUI. Then using the local console
Command Line Interface (CLI), the administrator executes the ambr_load function to verify a Forcepoint ECDSA P-
521 w/ SHA-512 signature on the patch file. If the signature verifies, then the administrator can issue the ambr_install
command to install the patch, and then the administrator can follow the installation process (which can require a reboot
for upgrades or major new features).
The Protection of the TSF function is designed to satisfy the following security functional requirements:
• FPT_APW_EXT.1: Passwords are stored on the SMC Appliance, and stored (synchronized) in both the
Management Server’s configuration database and in the Linux password database. Both locations store
passwords in a non-plaintext form, and the TOE provides no interfaces to allow administrators to view
plaintext passwords.
• FPT_ITT.1: The TOE utilizes TLS protected communications from Engines to their SMC (log forwarding)
and from the SMC to its Engines (management). The TOE has no other communications between
components.
• FPT_SKP_EXT.1: None of the TOE components utilize pre-shared keys or long-lived symmetric keys. The
only keys retained by the components of the TOE are associated with certificates used for TLS. These keys
are stored in a password protected Java keystore (on the SMC Appliance) and on a RW partition on the
NGFW Engine. Since the NGFW Engine does not support an interface for local administration, this data is
not accessible once stored in the partition.
• FPT_STM.1: Each TOE component includes a hardware-based real-time clock. This clock is used for
timestamps used in audit data, verifying certificate and certificate revocation validity, and measuring session
timeouts. The TOE time can be set by administrator action through console administration of the SMC
Management Server. Time on the NGFW Engine is updated by the SMC Management Server only.
• FPT_TST_EXT.1: The TOE components verify memory operation and checksums of TOE binaries upon
startup as described above.
• FPT_TUD_EXT.1: The administrator can query the current software versions for the SMC software and for
the NGFW Engine software. Administrators can obtain TOE patches from Forcepoint or (in the case of
NGFW Engine patches) by configuring the SMC Management Server to automatically download NGFW
Engine patches. Administrators must initiate the installation of patches to the NGFW Engine and to the SMC
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 46 of 49
Appliance. Patches include signatures to verify the validity of the new software. If the signature on an update
cannot be verified, the update cannot be uploaded into the appliance.
6.9 TOE access
The GUI offered by the SMC Appliance has a configurable banner that is displayed before a user's login. The banner
contents are defined by the administrator through the GUI interface. This same banner is also displayed on the SMC
Appliance local console CLI prior to a user's login.
The SMC Management Server supports timeouts caused by inactivity through the GUI, as well as voluntary
termination of a session (i.e., logout). When an administrator uses the local console’s Command Line Interface (CLI),
the CLI enforces an inactivity timeout value that terminates the session after the administrator-specified time period.
The TOE access function is designed to satisfy the following security functional requirements:
• FTA_SSL.3: The TOE will terminate remote interactive sessions that have been inactive for the defined
interval. The administrator can configure the duration of the inactivity timeout mechanism.
• FTA_SSL.4: Administrators using the GUI or local console (i.e., CLI) can terminate their own session using
the logoff commands provided by these interfaces.
• FTA_SSL_EXT.1: The only local interactive sessions are those offered by the SMC Appliance providing a
command line interface.
• FTA_TAB.1: A Banner is displayed on both interfaces offered by the SMC Appliance (i.e., the GUI and
local console). The NGFW Engine does not offer a direct network interface.
6.10 Trusted path/channels
The only communication that the TOE has with a trusted external IT entity is the syslog channel. This channel is
protected by TLS. For this communication channel, the TOE is acting as the TLS client during the negotiation of the
TLS connection. The TOE proposes the cipher suites listed in the Table 6-4 when configured into its evaluated mode.
The TOE supports the use of a client certificate (which an administrator can obtain from the internal CA, from an
external CA, or can import), as the mechanism to authenticate the TOE to the syslog server. The administrator can
also load trusted CA certificates to which the syslog server’s certificate must chain.
The administrator’s Client GUI is again a Java program providing a graphical user interface only. All decisions on
whether the operation is allowed occur in the Management Server with which the Client GUI communicates. The
Management Server only accepts TLS connections for the Client GUI and accepts the cipher suites listed in Table 6-5
when communicating with the GUI.
The Trusted path/channels function is designed to satisfy the following security functional requirements:
• FTP_ITC.1: The TOE protects syslog communication from the Log Server and from the Management Server
to the external syslog server using the TLSv1.2 protocol.
• FTP_TRP.1/Admin: The SMC Management Server only accepts TLSv1.2 connections for management
operations using the cipher suites identified in Table 6-5..
• FTP_TRP.1/Join: The SMC Management Server only accepts join requests from Engines for which the
Administrator has already created an object and provided the Engine with the SMC generated password.
Furthermore, the SMC protects the registration channel using TLSv1.2 and requires that the registering
Engine prove knowledge of the SMC generated password by exchanging a SHA-512 hash. The SMC
reserves port 3021 for registration and after registration, the components communicate using mutually-
authenticated TLS on different ports (8903, 8907, 8906, 8916, 8917, 3020, 3023), thus preventing reuse of
the registration channel. The TOE components use the ciphersuites identified in Table 6-5 for both the
registration channel and for the distributed TOE trusted channel. Should a registration attempt fail, the
administrator can attempt again, or can generate a new password on the SMC (and input that password into
the Engine), and then attempt registration again.
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 47 of 49
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 48 of 49
7. Requirement Allocation
This section provides a mapping of the distributed TOE components to the SFRs in this ST. This TOE is a
distributed TOE consistent with Use Case 3 as defined in the FWcPP. The following table presents the required
mapping.
Requirement Distributed TOE SFR
Allocation
Distributed TOE Audit
Event Allocation
FWcPP20E:FAU_GEN.1 All All
FWcPP20E:FAU_GEN.2 All None
FWcPP20E:FAU_STG_EXT.1 All None
FWcPP20E:FCO_CPC_EXT.1 All All
FWcPP20E:FCS_CKM.1 All None
FWcPP20E:FCS_CKM.2 All None
FWcPP20E:FCS_CKM.4 All None
FWcPP20E:FCS_COP.1/DataEncryption All None
FWcPP20E:FCS_COP.1/SigGen All None
FWcPP20E:FCS_COP.1/Hash All None
FWcPP20E:FCS_COP.1/KeyedHash All None
FWcPP20E:FCS_RBG_EXT.1 All None
FWcPP20E:FCS_TLSC_EXT.2 All All
FWcPP20E:FCS_TLSS_EXT.1 All All
FWcPP20E:FCS_TLSS_EXT.2 All All
FWcPP20E:FDP_RIP.2 All None
FWcPP20E:FFW_RUL_EXT.1 Engine(s) Engine(s)
Engine(s) Engine(s)
FWcPP20E:FFW_RUL_EXT.2 Engine(s) None
FWcPP20E:FIA_AFL.1 SMC SMC
FWcPP20E:FIA_PMG_EXT.1 SMC None
FWcPP20E:FIA_UAU.7 SMC None
FWcPP20E:FIA_UAU_EXT.2 SMC SMC
FWcPP20E:FIA_UIA_EXT.1 SMC SMC
FWcPP20E:FIA_X509_EXT.1/ITT All All
FWcPP20E:FIA_X509_EXT.1/Rev All All
FWcPP20E:FIA_X509_EXT.2 All None
FWcPP20E:FIA_X509_EXT.3 SMC None
FWcPP20E:FMT_MOF.1/ManualUpdate All All
FWcPP20E:FMT_MTD.1/CoreData All SMC
FWcPP20E:FMT_SMF.1 SMC None
FWcPP20E:FMT_SMR.2 SMC None
FWcPP20E:FPT_APW_EXT.1 SMC None
FWcPP20E:FPT_ITT.1 All All
FWcPP20E:FPT_SKP_EXT.1 All None
FWcPP20E:FPT_TST_EXT.1 All None
FWcPP20E:FPT_TUD_EXT.1 All All
FWcPP20E:FTA_SSL.3 SMC SMC
FWcPP20E:FTA_SSL.4 SMC SMC
FWcPP20E:FTA_SSL_EXT.1 SMC SMC
FWcPP20E:FTA_TAB.1 SMC None
Forcepoint NGFW 6.5 Security Target Version 1.5, October 7, 2019
Page 49 of 49
FWcPP20E:FTP_ITC.1 SMC SMC
FWcPP20E:FTP_TRP.1/Admin SMC SMC
FWcPP20E:FTP_TRP.1/Join All All