Page 1 of 49
FortiAnalyzer 6.2
Security Target
Version 1.7
December 2022
Document prepared by
www.lightshipsec.com
Fortinet Security Target
Page 2 of 49
Document History
Version Date Author Description
1.0 15 Dec 2021 L Turner Release for certification
1.1 16 May 2022 M Ibrishimova Addressed OR10
1.2 25 July 2022 M Ibrishimova Added new build
1.3 16 Aug 2022 M Ibrishimova Added new TD
1.4 25 Aug 2022 M Ibrishimova Addressed OR11
1.5 8 Nov 2022 M Ibrishimova Addressed OR comments.
1.6 24 Nov 2022 M Ibrishimova Addressed OR12.
1.7 12 Dec 2022 M Ibrishimova Addressed OR13.
Fortinet Security Target
Page 3 of 49
Table of Contents
1 Introduction ........................................................................................................................... 5
1.1 Overview ........................................................................................................................ 5
1.2 Identification ................................................................................................................... 5
1.3 Conformance Claims...................................................................................................... 5
1.4 Terminology.................................................................................................................... 6
2 TOE Description.................................................................................................................... 7
2.1 Type ............................................................................................................................... 7
2.2 Usage ............................................................................................................................. 7
2.3 Security Functions / Logical Scope................................................................................ 9
2.4 Physical Scope............................................................................................................. 11
3 Security Problem Definition............................................................................................... 12
3.1 Threats ......................................................................................................................... 12
3.2 Assumptions................................................................................................................. 14
3.3 Organizational Security Policies................................................................................... 15
4 Security Objectives............................................................................................................. 15
5 Security Requirements....................................................................................................... 16
5.1 Conventions ................................................................................................................. 16
5.2 Extended Components Definition................................................................................. 17
5.3 Functional Requirements ............................................................................................. 17
5.4 Assurance Requirements............................................................................................. 32
6 TOE Summary Specification.............................................................................................. 33
6.1 Security Audit ............................................................................................................... 33
6.2 Cryptographic Support ................................................................................................. 34
6.3 Identification and Authentication .................................................................................. 38
6.4 Security Management .................................................................................................. 41
6.5 Protection of the TSF ................................................................................................... 42
6.6 TOE Access ................................................................................................................. 44
6.7 Trusted Path/Channels ................................................................................................ 44
7 Rationale.............................................................................................................................. 46
7.1 Conformance Claim Rationale ..................................................................................... 46
7.2 Security Objectives Rationale ...................................................................................... 46
7.3 Security Requirements Rationale................................................................................. 46
Annex A: Extended Components Definition............................................................................. 49
List of Tables
Table 1: Evaluation identifiers ......................................................................................................... 5
Table 2: NIAP Technical Decisions ................................................................................................. 5
Table 3: Terminology....................................................................................................................... 7
Table 4: CAVP Certificates............................................................................................................ 10
Table 5: TOE models..................................................................................................................... 11
Table 6: Threats............................................................................................................................. 12
Table 7: Assumptions .................................................................................................................... 14
Table 8: Organizational Security Policies...................................................................................... 15
Table 9: Security Objectives for the Operational Environment ..................................................... 15
Table 10: Summary of SFRs ......................................................................................................... 17
Table 11: Audit Events .................................................................................................................. 19
Fortinet Security Target
Page 4 of 49
Table 12: Assurance Requirements .............................................................................................. 32
Table 13: Key Agreement Mapping............................................................................................... 34
Table 14: HMAC Characteristics ................................................................................................... 36
Table 15: Keys............................................................................................................................... 42
Table 16: Passwords ..................................................................................................................... 43
Table 17: NDcPP SFR Rationale .................................................................................................. 46
Fortinet Security Target
Page 5 of 49
1 Introduction
1.1 Overview
1 This Security Target (ST) defines the Fortinet FortiAnalyzer 6.2 Target of Evaluation
(TOE) for the purposes of Common Criteria (CC) evaluation.
2 Fortinet FortiAnalyzer integrates network logging, analysis, and reporting into a
single system, delivering increased knowledge of security events throughout a
network.
1.2 Identification
Table 1: Evaluation identifiers
Target of Evaluation Fortinet FortiAnalyzer 6.2.8
Build: v6.2.8-build9589
Security Target Fortinet FortiAnalyzer 6.2 Security Target, v1.7
1.3 Conformance Claims
3 This ST supports the following conformance claims:
a) CC version 3.1 revision 5
b) CC Part 2 extended
c) CC Part 3 conformant
d) collaborative Protection Profile for Network Devices, v2.2e
e) NIAP Technical Decisions per Table 2
Table 2: NIAP Technical Decisions
TD # Name Rationale if n/a
TD0527 Updates to Certificate Revocation Testing
(FIA_X509_EXT.1)
TD0528 NIT Technical Decision for Missing EAs for
FCS_NTP_EXT.1.4
N/A – NTP not
claimed
TD0536 NIT Technical Decision for Update Verification
Inconsistency
TD0537 NIT Technical Decision for Incorrect reference to
FCS_TLSC_EXT.2.3
TD0538 NIT Technical Decision for Outdated link to allowed-with
list
TD0546 NIT Technical Decision for DTLS - clarification of
Application Note 63
The TOE does not
claim
FCS_DTLS_EXT.1
Fortinet Security Target
Page 6 of 49
TD # Name Rationale if n/a
TD0547 NIT Technical Decision for Clarification on developer
disclosure of AVA_VAN
TD0555 NIT Technical Decision for RFC Reference incorrect in
TLSS Test
TD0556 NIT Technical Decision for RFC 5077 question
TD0563 NiT Technical Decision for Clarification of audit date
information
TD0564 NiT Technical Decision for Vulnerability Analysis Search
Criteria
TD0569 NIT Technical Decision for Session ID Usage Conflict in
FCS_DTLSS_EXT.1.7
TD0570 NiT Technical Decision for Clarification about FIA_AFL.1
TD0571 NiT Technical Decision for Guidance on how to handle
FIA_AFL.1
TD0572 NiT Technical Decision for Restricting FTP_ITC.1 to only
IP address identifiers
TD0580 NIT Technical Decision for clarification about use of DH14
in NDcPPv2.2e
TD0581 NIT Technical Decision for Elliptic curve-based key
establishment and NIST SP 800-56Arev3
TD0591 NIT Technical Decision for Virtual TOEs and hypervisors
TD0592 NIT Technical Decision for Local Storage of Audit
Records
TD0631 NIT Technical Decision for Clarification of public key
authentication for SSH Server
TD0632 NIT Technical Decision for Consistency with Time Data
for vNDs
TD0633 NIT Technical Decision for IPsec IKE/SA Lifetimes
Tolerance
N/A. The TOE does
not claim IPSec
TD0634 NIT Technical Decision for Clarification required for
testing IPv6
TD0635 NIT Technical Decision for TLS Server and Key
Agreement Parameters
Fortinet Security Target
Page 7 of 49
TD # Name Rationale if n/a
TD0636 NIT Technical Decision for Clarification of Public Key User
Authentication for SSH
N/A. The TOE does
not claim
FCS_SSHC_EXT.1
TD0638 NIT Technical Decision for Key Pair Generation for
Authentication
TD0639 NIT Technical Decision for Clarification for NTP MAC
Keys
N/A. The TOE does
not claim NTP.
TD0670 NIT Technical Decision for Mutual and Non-Mutual Auth
TLSC Testing
1.4 Terminology
Table 3: Terminology
Term Definition
CC Common Criteria
EAL Evaluation Assurance Level
NDcPP collaborative Protection Profile for Network Devices
PP Protection Profile
TOE Target of Evaluation
TSF TOE Security Functionality
2 TOE Description
2.1 Type
4 The TOE is a network device that provides centralized network security logging and
reporting.
2.2 Usage
2.2.1 Deployment
5 Figure 1 shows an example deployment of the TOE (enclosed in red) which accepts
inbound logs from multiple downstream Fortinet devices. TOE users are provided
with an aggregate view of how applications, web usage, and potentially malicious
behavior affect a network.
Fortinet Security Target
Page 8 of 49
Figure 1: Example FortiAnalyzer deployment
2.2.2 Modes
6 The FortiAnalyzer operates in two modes:
a) Analyzer mode. The default mode that supports all FortiAnalyzer features,
such as Event Monitor and Reports. This mode is used to aggregate logs from
one or more Collectors.
b) Collector mode. When a FortiAnalyzer is configured to work in the Collector
mode, its primary task becomes forwarding logs of the connected devices to
an Analyzer and archiving the logs. The Collector retains the logs in their
original (binary) format for uploading. In this mode, most features, including
Event Monitor and Reports, are disabled.
7 The TOE was configured in the Analyzer mode for the Common Criteria evaluation.
Fortinet Security Target
Page 9 of 49
2.2.3 Interfaces
8 The TOE interfaces are shown in Figure 2.
Figure 2: TOE interfaces
9 The TOE interfaces are as follows:
a) CLI. Administrative CLI via direct serial connection or SSH.
b) GUI. Administrative web GUI via HTTPS.
c) Log Forwarding. Forwarding of logs and TOE audit events to a Remote Audit
Server, which is another FortiAnalyzer, via TLS
2.3 Security Functions / Logical Scope
10 The TOE provides the following security functions:
a) Protected Communications. The TOE protects the integrity and
confidentiality of communications as noted in section 2.2.3 above.
b) Secure Administration. The TOE enables secure management of its security
functions, including:
i) Administrator authentication with passwords
ii) Configurable password policies
iii) Role Based Access Control
iv) Access banners
v) Management of critical security functions and data
vi) Protection of cryptographic keys and passwords
c) Trusted Update. The TOE ensures the authenticity and integrity of software
updates through digital signatures.
Fortinet Security Target
Page 10 of 49
d) System Monitoring. The TOE generates logs of security relevant events. The
TOE stores logs locally and is capable of sending log events to a remote audit
server.
e) Self-Test. The TOE performs a suite of self-tests to ensure the correct
operation and enforcement of its security functions.
f) Cryptographic Operations. The TOE implements a cryptographic module
that uses the Fortinet Entropy Token hardware noise source for entropy.
Relevant Cryptographic Algorithm Validation Program (CAVP) certificates are
shown in Table 4.
Table 4: CAVP Certificates
Algorithm Capability Certificate
AES GCM C2013
C1985
C1908
A1062
A1962
A2401
AES CBC
AES CTR
SHA1, SHA-256, SHA-384, SHA-512
RSA KeyGen (186-4)
RSA SigGen (186-4)
RSA SigVer (186-4)
ECDSA KeyGen (186-4)
ECDSA SigGen (186-4)
ECDSA SigVer (186-4)
HMAC-SHA1, HMAC-SHA-256, HMAC-SHA-384, HMAC-
SHA-512
CTR_DRBG
KAS FFC Component
KAS ECC Component
11 The logical scope of the TOE comprises the security functions defined in section 2.3
2.3.1 Functions not included in the TOE Evaluation
12 The FortiAnalyzer appliances are capable of a variety of functions and configurations
which are not covered by the NDcPP. Only the security functions defined in section
2.3 have been examined as part of this evaluation.
13 For the TOE to be in the evaluated configuration, the following functions must not be
enabled/used
a) Syslog server logging support
Fortinet Security Target
Page 11 of 49
b) SNMP
c) HTTP
d) telnet
e) Remote authentication (e.g. RADIUS, LDAP, TACACS+)
f) High Availability (HA) clustering
g) Ability to manage the TOE via the FortiManger
14 Note: While the Analyzer mode was the tested mode, Fortinet attests that operating
in the Collector mode does not affect the evaluated functionality.
15 Note: While the aggregation of logs from external systems was not tested during the
evaluation, this functionality is permitted to be enabled/used.
2.4 Physical Scope
16 The physical boundary of the TOE includes the FortiAnalyzer (FAZ) hardware and
software, and the Fortinet Entropy Token – a USB token hardware noise source.
The FAZ models in scope are shown in Table 5.
17 The TOE is shipped to the customer via commercial courier.
Table 5: TOE models
Model CPU Differences (Storage / Log Speed*),
*Collector Sustained Rate
FAZ-800F Intel i3-6100 Skylake 4x 4TB | 12,000/sec
FAZ-1000F Intel Xeon Bronze 3106 Skylake 8x 4TB | 30,000/sec
FAZ-2000E Intel Xeon E5-2620v3 Haswell 12x 3TB | 45,000/sec
FAZ-3000F Intel Xeon E5-2630v3 Haswell 16x 4TB | 60,000/sec
FAZ-3500G Intel Xeon Gold 5118 Skylake 24x 4TB | 90,000/sec
FAZ-3700F Intel Xeon E5-2640v4 Broadwell 60x 4TB SAS | 150,000/sec
2.4.1 Guidance Documents
18 The TOE includes the following guidance documents:
a) NDcPP Common Criteria and FIPS 140-2 Technote FortiAnalyzer 6.2, PDF
Doc version 1.7, December 12, 2022
b) Fortinet FortiAnalyzer 6.2.8 Administration Guide, PDF Doc No. 05-628-
547780-20210901
c) Fortinet FortiAnalyzer 6.2.8 CLI Reference, PDF Doc No. 05-628-539013-
20210513
d) Fortinet FortiManager & FortiAnalyzer 6.2.7 Event Log Reference, PDF Doc
No. 02-627-549533-20201118
e) Fortinet FortiAnalyzer Hardware Guides:
Fortinet Security Target
Page 12 of 49
i) FortiAnalyzer-800F QuickStart Guide, Doc No. 05-560-443238-
20200902
ii) FortiAnalyzer 1000F QuickStart Guide, Doc No 02-60-559470-
20210125
iii) FortiAnalyzer-2000E Information, Doc No. 05-540-294825-20210105
iv) FortiAnalyzer-3000F Information, Doc No. 05-540-293346-20170905
v) FortiAnalyzer 3500G QuickStart Guide, January 08, 2020
vi) FortiAnalyzer-3700F Information, Doc No. 05-541-382365-20210105
19 Guides are available at: http://docs.fortinet.com/fortianalyzer
2.4.2 Non-TOE Components
20 The TOE operates with the following components in the environment:
a) Audit Server. The TOE is capable of sending audit events to another
FortiAnalyzer.
b) CRL Server. The TOE uses a CRL server for certificate management.
c) Registered Devices. The TOE supports collection of logs from Fortinet
devices, such as:
i) FortiGate
ii) FortiManager
iii) FortiClient
iv) FortiWeb
v) FortiMail
vi) FortiAuthentication
3 Security Problem Definition
21 The Security Problem Definition is reproduced from section 4 of the NDcPP.
3.1 Threats
Table 6: Threats
Identifier Description
T.UNAUTHORIZED_
ADMINISTRATOR_
ACCESS
Threat agents may attempt to gain Administrator access to the
Network Device by nefarious means such as masquerading as an
Administrator to the device, masquerading as the device to an
Administrator, replaying an administrative session (in its entirety, or
selected portions), or performing man-in-the-middle attacks, which
would provide access to the administrative session, or sessions
between Network Devices. Successfully gaining Administrator access
allows malicious actions that compromise the security functionality of
the device and the network on which it resides.
T.WEAK_
CRYPTOGRAPHY
Threat agents may exploit weak cryptographic algorithms or perform a
cryptographic exhaust against the key space. Poorly chosen
encryption algorithms, modes, and key sizes will allow
Fortinet Security Target
Page 13 of 49
Identifier Description
attackers to compromise the algorithms, or brute force exhaust the key
space and give them unauthorized access allowing them to read,
manipulate and/or control the traffic with minimal effort.
T.UNTRUSTED_
COMMUNICATION_
CHANNELS
Threat agents may attempt to target Network Devices that do not use
standardized secure tunnelling protocols to protect the critical network
traffic. Attackers may take advantage of poorly designed protocols or
poor key management to successfully perform man-in-the-middle
attacks, replay attacks, etc. Successful attacks will result in loss of
confidentiality and integrity of the critical network traffic, and potentially
could lead to a compromise of the Network Device itself.
T.WEAK_
AUTHENTICATION_
ENDPOINTS
Threat agents may take advantage of secure protocols that use weak
methods to authenticate the endpoints – e.g. a shared password that
is guessable or transported as plaintext. The consequences are the
same as a poorly designed protocol, the attacker could masquerade
as the Administrator or another device, and the attacker could insert
themselves into the network stream and perform a man-in-the-middle
attack. The result is the critical network traffic is exposed and there
could be a loss of confidentiality and integrity, and potentially the
Network Device itself could be compromised.
T.UPDATE_
COMPROMISE
Threat agents may attempt to provide a compromised update of the
software or firmware which undermines the security functionality of the
device. Non-validated updates or updates validated using non-secure
or weak cryptography leave the update firmware vulnerable to
surreptitious alteration.
T.UNDETECTED_
ACTIVITY
Threat agents may attempt to access, change, and/or modify the
security functionality of the Network Device without Administrator
awareness. This could result in the attacker finding an avenue (e.g.,
misconfiguration, flaw in the product) to compromise the device and
the Administrator would have no knowledge that the device has been
compromised.
T.SECURITY_
FUNCTIONALITY_
COMPROMISE
Threat agents may compromise credentials and device data enabling
continued access to the Network Device and its critical data. The
compromise of credentials includes replacing existing credentials with
an attacker’s credentials, modifying existing credentials, or obtaining
the Administrator or device credentials for use by the attacker.
T.PASSWORD_
CRACKING
Threat agents may be able to take advantage of weak administrative
passwords to gain privileged access to the device. Having privileged
access to the device provides the attacker unfettered access to the
network traffic, and may allow them to take advantage of any trust
relationships with other Network Devices.
T.SECURITY_
FUNCTIONALITY_
FAILURE
An external, unauthorized entity could make use of failed or
compromised security functionality and might therefore subsequently
use or abuse security functions without prior authentication to access,
change or modify device data, critical network traffic or security
functionality of the device.
Fortinet Security Target
Page 14 of 49
3.2 Assumptions
Table 7: Assumptions
Identifier Description
A.PHYSICAL_
PROTECTION
The Network Device is assumed to be physically protected in its
operational environment and not subject to physical attacks that
compromise the security or interfere with the device’s physical
interconnections and correct operation. This protection is assumed to
be sufficient to protect the device and the data it contains. As a result,
the cPP does not include any requirements on physical tamper
protection or other physical attack mitigations. The cPP does not
expect the product to defend against physical access to the device
that allows unauthorized entities to extract data, bypass other controls,
or otherwise manipulate the device. For vNDs, this assumption applies
to the physical platform on which the VM runs.
A.LIMITED_
FUNCTIONALITY
The device is assumed to provide networking functionality as its core
function and not provide functionality/services that could be deemed
as general purpose computing. For example, the device should not
provide a computing platform for general purpose applications
(unrelated to networking functionality).
If a virtual TOE evaluated as a pND, following Case 2 vNDs as
specified in Section 1.2, the VS is considered part of the TOE with only
one vND instance for each physical hardware platform. The exception
being where components of a distributed TOE run inside more than
one virtual machine (VM) on a single VS. In Case 2 vND, no non-TOE
guest VMs are allowed on the platform.
Application Note: Changed by TD0591
A.NO_THRU_
TRAFFIC_
PROTECTION
A standard/generic Network Device does not provide any assurance
regarding the protection of traffic that traverses it. The intent is for the
Network Device to protect data that originates on or is destined to the
device itself, to include administrative data and audit data. Traffic that
is traversing the Network Device, destined for another network entity,
is not covered by the NDcPP. It is assumed that this protection will be
covered by cPPs and PP-Modules for particular types of Network
Devices (e.g., firewall).
Fortinet Security Target
Page 15 of 49
Identifier Description
A.TRUSTED_
ADMINISTRATOR
The Security Administrator(s) for the Network Device are assumed to
be trusted and to act in the best interest of security for the
organization. This includes appropriately trained, following policy, and
adhering to guidance documentation. Administrators are trusted to
ensure passwords/credentials have sufficient strength and entropy and
to lack malicious intent when administering the device. The Network
Device is not expected to be capable of defending against a malicious
Administrator that actively works to bypass or compromise the security
of the device.
For TOEs supporting X.509v3 certificate-based authentication, the
Security Administrator(s) are expected to fully validate (e.g. offline
verification) any CA certificate (root CA certificate or intermediate CA
certificate) loaded into the TOE’s trust store (aka ‘root store’, ‘ trusted
CA Key Store’, or similar) as a trust anchor prior to use (e.g. offline
verification).
A.REGULAR_
UPDATES
The Network Device firmware and software is assumed to be updated
by an Administrator on a regular basis in response to the release of
product updates due to known vulnerabilities.
A.ADMIN_
CREDENTIALS_
SECURE
The Administrator’s credentials (private key) used to access the
Network Device are protected by the platform on which they reside.
A.RESIDUAL_
INFORMATION
The Administrator must ensure 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.
3.3 Organizational Security Policies
Table 8: Organizational Security Policies
Identifier Description
P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use,
legal agreements, or any other appropriate information to which users
consent by accessing the TOE.
4 Security Objectives
22 The security objectives are reproduced from section 5 of the NDcPP.
Table 9: Security Objectives for the Operational Environment
Identifier Description
OE.PHYSICAL Physical security, commensurate with the value of the TOE and the
data it contains, is provided by the environment.
Fortinet Security Target
Page 16 of 49
Identifier Description
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.TRUSTED_ADMIN Security Administrators are trusted to follow and apply all guidance
documentation in a trusted manner. For vNDs, this includes the VS
Administrator responsible for configuring the VMs that implement ND
functionality.
For TOEs supporting X.509v3 certificate-based authentication, the
Security Administrator(s) are assumed to monitor the revocation status
of all certificates in the TOE’s trust store and to remove any certificate
from the TOE’s trust store in case such certificate can no longer be
trusted.
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.
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.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.
5 Security Requirements
5.1 Conventions
23 This document uses the following font conventions to identify the operations defined
by the CC:
a) Assignment. Indicated with italicized text.
b) Refinement. Indicated with bold text and strikethroughs.
c) Selection. Indicated with underlined text.
d) Iteration. Indicated by adding a string starting with “/” (e.g.
“FCS_COP.1/Hash”).
e) Assignment within a Selection: Indicated with italicized and underlined text.
24 Note: Operations performed within the Security Target are denoted within brackets
[]. Operations shown without brackets are reproduced from the NDcPP.
Fortinet Security Target
Page 17 of 49
5.2 Extended Components Definition
25 Refer to Annex A: Extended Components Definition.
5.3 Functional Requirements
Table 10: Summary of SFRs
Requirement Title
FAU_GEN.1 Audit Data Generation
FAU_GEN.2 User Identity Association
FAU_STG_EXT.1 Protected Audit Event Storage
FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_CKM.4 Cryptographic Key Destruction
FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption)
FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification)
FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)
FCS_HTTPS_EXT.1 HTTPS Protocol
FCS_RBG_EXT.1 Random Bit Generation
FCS_SSHS_EXT.1 SSH Server Protocol
FCS_TLSC_EXT.1 TLS Client Protocol Without Mutual Authentication
FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication
FCS_TLSS_EXT.1 TLS Server Protocol Without Mutual Authentication
FIA_AFL.1 Authentication Failure Management
FIA_PMG_EXT.1 Password Management
FIA_UIA_EXT.1 User Identification and Authentication
FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU.7 Protected Authentication Feedback
Fortinet Security Target
Page 18 of 49
Requirement Title
FIA_X509_EXT.1/Rev X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.3 X.509 Certificate Requests
FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour
FMT_MOF.1/Functions Management of security functions behaviour
FMT_MTD.1/CoreData Management of TSF Data
FMT_MTD.1/CryptoKeys Management of TSF Data
FMT_SMF.1 Specification of Management Functions
FMT_SMR.2 Restrictions on Security Roles
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared, symmetric
and private keys)
FPT_APW_EXT.1 Protection of Administrator Passwords
FPT_TST_EXT.1 TSF Testing
FPT_TUD_EXT.1 Trusted Update
FPT_STM_EXT.1 Reliable Time Stamps
FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL.3 TSF-initiated Termination
FTA_SSL.4 User-initiated Termination
FTA_TAB.1 Default TOE Access Banners
FTP_ITC.1 Inter-TSF trusted channel
FTP_TRP.1/Admin Trusted Path
5.3.1 Security Audit (FAU)
FAU_GEN.1 Audit Data Generation
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following
auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not specified level of audit;
Fortinet Security Target
Page 19 of 49
c) All administrative actions comprising:
o Administrative login and logout (name of user account shall
be logged if individual user accounts are required for
Administrators).
o 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).
o 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).
o Resetting passwords (name of related user account shall be
logged).
o [No other actions];
d) Specifically defined auditable events listed in Table 11.
Table 11: Audit Events
Requirement Auditable Events Additional Audit Record
Contents
FAU_GEN.1 None. None.
FAU_GEN.2 None. None.
FAU_STG_EXT.1 None. None.
FCS_CKM.1 None. None.
FCS_CKM.2 None. None.
FCS_CKM.4 None. None.
FCS_COP.1/DataEncryption None. None.
FCS_COP.1/SigGen None. None.
FCS_COP.1/Hash None. None.
FCS_COP.1/KeyedHash None. None.
FCS_HTTPS_EXT.1 Failure to establish a HTTPS
Session.
Reason for failure
FCS_RBG_EXT.1 None. None.
FCS_SSHS_EXT.1 Failure to establish an SSH
session
Reason for failure
FCS_TLSC_EXT.1 Failure to establish a TLS
Session
Reason for failure
Fortinet Security Target
Page 20 of 49
Requirement Auditable Events Additional Audit Record
Contents
FCS_TLSC_EXT.2 None. None.
FCS_TLSS_EXT.1 Failure to establish a TLS
Session
Reason for failure
FIA_AFL.1 Unsuccessful login attempts
limit is met or exceeded.
Origin of the attempt (e.g., IP
address).
FIA_PMG_EXT.1 None. None.
FIA_UIA_EXT.1 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU_EXT.2 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU.7 None. None.
FIA_X509_EXT.1/Rev Unsuccessful attempt to
validate a certificate
Any addition, replacement or
removal of trust anchors in
the TOE's trust store.
Reason for failure of
certificate validation.
Identification of certificates
added, replaced or removed
as trust anchor in the TOE's
trust store.
FIA_X509_EXT.2 None. None.
FIA_X509_EXT.3 None. None.
FMT_MOF.1/ManualUpdate Any attempt to initiate a
manual update
None.
FMT_MOF.1/Functions None. None.
FMT_MTD.1/CoreData None. None.
FMT_MTD.1/CryptoKeys None. None.
FMT_SMF.1 All management activities of
TSF data
None.
FMT_SMR.2 None. None.
FPT_SKP_EXT.1 None. None.
FPT_APW_EXT.1 None. None.
FPT_TST_EXT.1 None. None.
Fortinet Security Target
Page 21 of 49
Requirement Auditable Events Additional Audit Record
Contents
FPT_TUD_EXT.1 Initiation of update; result of
the update attempt (success
or failure)
None.
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).
FTA_SSL_EXT.1 (if
“terminate the session” is
selected)
The termination of a local
session by the session
locking mechanism.
None.
FTA_SSL.3 The termination of a remote
session by the session
locking mechanism.
None.
FTA_SSL.4 The termination of an
interactive session.
None.
FTA_TAB.1 None. None.
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.
FTP_TRP.1/Admin Initiation of the trusted path.
Termination of the trusted
path.
Failure of the trusted path
functions.
None.
FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity, and the
outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of
the functional components included in the cPP/ST, information
specified in column three of Table 2 Table 11.
Fortinet Security Target
Page 22 of 49
FAU_GEN.2 User Identity Association
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.
FAU_STG_EXT.1 Protected Audit Event Storage
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.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. In
addition [The TOE shall consist of a single standalone component that
stores audit data locally]
FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the
following rule: [overwrite oldest record first]] when the local storage
space for audit data is full.
5.3.2 Cryptographic Support (FCS)
FCS_CKM.1 Cryptographic Key Generation
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
• FFC Schemes using ‘safe-prime’ groups that meet the following:
“NIST Special Publication 800-56A Revision 3, Recommendation for
Pair-Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography” and [RFC 3526]
]and specified cryptographic key sizes [assignment: cryptographic key
sizes] that meet the following: [assignment: list of standards].
FCS_CKM.2 Cryptographic Key Establishment
FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance
with a specified cryptographic key establishment method: [
• Elliptic curve-based key establishment schemes that meet the
following: NIST Special Publication 800-56A Revision 3,
“Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography”;
• FFC Schemes using “safe-prime” groups that meet the following:
‘NIST Special Publication 800-56A Revision 3, “Recommendation for
Fortinet Security Target
Page 23 of 49
Pair-Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography” and [groups listed in RFC 3526]
] that meets the following: [assignment: list of standards].
Application note: Changed by TD0581 and TD0580.
FCS_CKM.4 Cryptographic Key Destruction
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]];
• 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 overwrite consisting of [zeroes]].
• that meets the following: No Standard.
FCS_COP.1/DataEncryption Cryptographic Operation (AES Data
Encryption/Decryption)
FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with
a specified cryptographic algorithm AES used in [CBC, CTR, 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, CTR as specified in ISO 10116, GCM as specified in ISO 19772].
FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and
Verification)
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 or greater],
• Elliptic Curve Digital Signature Algorithm and cryptographic key sizes
[256 bits or greater]
] that meet the following: [
• 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” [P-
256, P-384, P-521]; ISO/IEC 14888-3, Section 6.4.]
FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
Fortinet Security Target
Page 24 of 49
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 cryptographic key sizes [assignment: cryptographic key
sizes] and message digest sizes [160, 256, 384, 512] bits that meet
the following: ISO/IEC 10118-3:2004.
FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)
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, HMAC-SHA-512] and cryptographic
key sizes [160, 256, 384, 512] and message digest sizes [160, 256,
384, 512] bits that meet the following: ISO/IEC 9797-2:2011, Section 7
“MAC Algorithm 2”.
FCS_HTTPS_EXT.1 HTTPS Protocol
FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC
2818.
FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS using TLS.
FCS_HTTPS_EXT.1.3 If a peer certificate is presented, the TSF shall [not require client
authentication] if the peer certificate is deemed invalid.
FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using [CTR_DRBG (AES)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source
that accumulates entropy from [[one] platform-based noise source] with a
minimum of [256 bits] of entropy at least equal to the greatest security
strength, according to ISO/IEC 18031:2011 Table C.1 “Security Strength
Table for Hash Functions”, of the keys and hashes that it will generate.
FCS_SSHS_EXT.1 SSH Server Protocol
FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFC(s)
4251, 4252, 4253, 4254, [4344, 6668, 8308 section 3.1, 8332].
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following authentication methods as described in RFC 4252: public key-
based, [password based].
FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater
than [262144] bytes in an SSH transport connection are dropped.
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the
following encryption algorithms and rejects all other encryption
algorithms: [aes128-ctr, aes256-ctr].
Fortinet Security Target
Page 25 of 49
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses [ssh-rsa, rsa-sha2-256, rsa-sha2-512] as its public
key algorithm(s) and rejects all other public key algorithms
FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses
[hmac-sha1, hmac-sha2-256, hmac-sha2-512] as its MAC algorithm(s)
and rejects all other MAC algorithm(s).
FCS_SSHS_EXT.1.7 The TSF shall ensure that [diffie-hellman-group14-sha1] and [no other
methods] are the only allowed key exchange methods used for the SSH
protocol.
FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections, the same session
keys are used for a threshold of no longer than one hour, and each
encryption key is used to protect no more than one gigabyte of data.
After any of the thresholds are reached, a rekey needs to be performed.
FCS_TLSC_EXT.1 TLS Client Protocol Without Mutual Authentication
FCS_TLSC_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)]
and reject all other TLS and SSL versions. The TLS implementation will
support the following ciphersuites: [
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC
3268
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC
3268
• TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC
5246
• TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC
5246
• 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_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_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_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined
in RFC 5289
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined
in RFC 5289] and no other ciphersuites.
Fortinet Security Target
Page 26 of 49
FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches [the reference
identifier per RFC 6125 section 6,IPv4 address in SAN, and no other
attribute types].
FCS_TLSC_EXT.1.3 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the server certificate is invalid. The TSF
shall also [
• Not implement any administrator override mechanism]
FCS_TLSC_EXT.1.4 The TSF shall [present the Supported Elliptic Curves/Supported Groups
Extension with the following curves/groups: [secp256r1, secp384r1,
secp521r1] and no other curves/groups] in the Client Hello.
FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication
FCS_TLSC_EXT.2.1 The TSF shall support TLS communication with mutual authentication
using X.509v3 certificates.
FCS_TLSS_EXT.1 TLS Server Protocol Without Mutual Authentication
FCS_TLSS_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)]
and reject all other TLS and SSL versions. The TLS implementation will
support the following ciphersuites:[
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC
3268
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC
3268
• TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC
5246
• TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC
5246
• 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_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_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_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined
in RFC 5289
Fortinet Security Target
Page 27 of 49
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined
in RFC 5289
] and no other ciphersuites.
FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL
3.0, TLS 1.0 and [none].
FCS_TLSS_EXT.1.3 The TSF shall perform key establishment for TLS using [Diffie-Hellman
parameters with size [2048], ECDHE curves [secp256r1, secp384r1,
secp521r1] and no other curves]
FCS_TLSS_EXT.1.4 The TSF shall support [session resumption based on session IDs
according to RFC4346 (TLS1.1) or RFC5246 (TLS1.2), session
resumption based on session tickets according to RFC 5077]
5.3.3 Identification and Authentication (FIA)
FIA_AFL.1 Authentication Failure Management
FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer
within [1 - 10] unsuccessful authentication attempts occur related to
Administrators attempting to authenticate remotely using a password.
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 a remote session using any authentication
method that involves a password until an Administrator defined time
period has elapsed].
FIA_PMG_EXT.1 Password Management
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 between [6] and
[128] characters.
FIA_UIA_EXT.1 User Identification and Authentication
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;
• [no other actions]
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.
Fortinet Security Target
Page 28 of 49
FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2.1 The TSF shall provide a local [password-based] authentication
mechanism to perform local administrative user authentication.
FIA_UAU.7 Protected Authentication Feedback
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.
FIA_X509_EXT.1/Rev X.509 Certificate Validation
FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules:
• RFC 5280 certificate validation and certification path validation
supporting a minimum path length of three certificates.
• The certification path must terminate with a trusted CA certificate
designated as a trust anchor.
• The TSF shall validate a certification path by ensuring that all CA
certificates in the certification path contain the basic Constraints
extension with the CA flag set to TRUE.
• The TSF shall validate the revocation status of the certificate using [a
Certificate Revocation List (CRL) as specified in RFC 5280 Section
6.3]
• 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.
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
FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to
support authentication for [HTTPS, TLS], and [no additional uses].
FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of
a certificate, the TSF shall [accept the certificate].
Fortinet Security Target
Page 29 of 49
FIA_X509_EXT.3 X.509 Certificate Requests
FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request as specified by RFC 2986
and be able to provide the following information in the request: public key
and [Common Name, Organization, Organizational Unit, Country].
FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon
receiving the CA Certificate Response
5.3.4 Security Management (FMT)
FMT_MOF.1/ManualUpdate Management of Security Functions Behaviour
FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to
perform manual updates to Security Administrators.
FMT_MOF.1/Functions Management of security functions behaviour
FMT_MOF.1.1/Functions The TSF shall restrict the ability to [modify the behaviour of] the
functions [transmission of audit data to an external IT entity] to Security
Administrators
FMT_MTD.1/CoreData Management of TSF Data
FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to
Security Administrators.
FMT_MTD.1/CryptoKeys Management of TSF data
FMT_MTD.1.1/CryptoKeys The TSF shall restrict the ability to manage the cryptographic
keys to Security Administrators.
FMT_SMF.1 Specification of Management Functions
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;
• [
o Ability to configure audit behaviour (e.g. changes to storage
locations for audit; changes to behaviour when local audit
storage space is full);
Fortinet Security Target
Page 30 of 49
o Ability to set the time which is used for time-stamps;
o Ability to modify the behaviour of the transmission of audit
data to an external IT entity;
o Ability to manage the TOE’s trust store and designate
X509v3 certificates as trust anchors;
o Ability to import X509v3 certificates to the TOE’s trust store;
o Ability to manage the cryptographic keys;
o Ability to configure the cryptographic functionality;]
FMT_SMR.2 Restrictions on Security Roles
FMT_SMR.2.1 The TSF shall maintain the roles:
• Security Administrator.
FMT_SMR.2.2 The TSF shall be able to associate users with roles.
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.3.5 Protection of the TSF (FPT)
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all pre-shared,
symmetric and private keys)
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys,
and private keys.
FPT_APW_EXT.1 Protection of Administrator Passwords
FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-plaintext form.
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext administrative passwords.
FPT_TST_EXT.1 TSF testing
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up
(on power on), at the request of the authorized user] to demonstrate the
correct operation of the TSF: [
• Firmware integrity tests
• Configuration integrity tests
• Cryptographic algorithm tests
Fortinet Security Target
Page 31 of 49
• DRBG tests
• BIOS tests
• Boot loader image verification]
FPT_TUD_EXT.1 Trusted update
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].
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].
FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates
to the TOE using a [digital signature] prior to installing those updates.
FPT_STM_EXT.1 Reliable Time Stamps
FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use.
FPT_STM_EXT.1.2 The TSF shall [allow the Security Administrator to set the time].
5.3.6 TOE Access (FTA)
FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [
• terminate the session]
after a Security Administrator-specified time period of inactivity.
FTA_SSL.3 TSF-initiated Termination
FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security
Administrator-configurable time interval of session inactivity.
FTA_SSL.4 User-initiated Termination (Refinement)
FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the
Administrator’s own interactive session.
FTA_TAB.1 Default TOE Access Banners (Refinement)
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.
Fortinet Security Target
Page 32 of 49
5.3.7 Trusted path/channels (FTP)
FTP_ITC.1 Inter-TSF trusted channel (Refinement)
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.
FTP_ITC.1.2 The TSF shall permit the TSF or the authorized IT entities to initiate
communication via the trusted channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [audit
server].
FTP_TRP.1 /Admin Trusted Path (Refinement)
FTP_TRP.1.1/Admin The TSF shall be capable of using [SSH, HTTPS] 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.
FTP_TRP.1.2 /Admin The TSF shall permit remote Administrators to initiate communication
via the trusted path.
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.4 Assurance Requirements
26 The TOE security assurance requirements are summarized in Table 12.
Table 12: Assurance Requirements
Assurance Class Assurance Components
Security Target (ASE) Conformance Claims (ASE_CCL.1)
Extended Components Definition (ASE_ECD.1)
ST Introduction (ASE_INT.1)
Security Objectives for the Operational Environment (ASE_OBJ.1)
Stated Security Requirements (ASE_REQ.1)
Security Problem Definition (ASE_SPD.1)
Fortinet Security Target
Page 33 of 49
Assurance Class Assurance Components
TOE Summary Specification (ASE_TSS.1)
Development (ADV) Basic Functional Specification (ADV_FSP.1)
Guidance Documents (AGD) Operational User Guidance (AGD_OPE.1)
Preparative Procedures (AGD_PRE.1)
Life Cycle Support (ALC) Labelling of the TOE (ALC_CMC.1)
TOE CM Coverage (ALC_CMS.1)
Tests (ATE) Independent Testing - Conformance (ATE_IND.1)
Vulnerability Assessment (AVA) Vulnerability Survey (AVA_VAN.1)
27 In accordance with section 7.1 of the NDcPPv2.2e, the following refinement is made
to ASE:
a) ASE_TSS.1.1C Refinement: The TOE summary specification shall describe
how the TOE meets each SFR. In the case of entropy analysis, the TSS is
used in conjunction with required supplementary information on
Entropy.
6 TOE Summary Specification
28 The following describes how the TOE fulfils each SFR included in section 5.3.
6.1 Security Audit
6.1.1 FAU_GEN.1
29 The TOE generates the audit records specified at FAU_GEN.1 containing the
following fields:
a) Date. The year, month, and day when the event occurred in the format:
YYYY-MM-DD
b) Time. The hour, minute and second of when the event occurred.
c) Log ID. A ten-digit number that identifies the log type. The first two digits
represent the log type, and the following two digits represent the log subtype.
The last five digits is the message ID number.
d) Type. The section of the system where the event occurred.
e) Subtype. The subtype of each log message.
f) Priority. The severity level, or priority, or the event. There are six priority
severity levels.
g) User. The name of the associated user.
h) Msg. Explains the activity or event that the FortiAnalyzer unit recorded.
30 The following information is logged as a result of the Security Administrator
generating/importing or deleting cryptographic keys:
Fortinet Security Target
Page 34 of 49
a) Generate CSR. Action and key reference.
b) Import Certificate. Action and key reference.
c) Import CA Certificate. Action and key reference.
6.1.2 FAU_GEN.2
31 The TOE includes the user identity in audit events resulting from actions of identified
users.
6.1.3 FAU_STG_EXT.1
32 The TOE is a standalone TOE. The Security Administrator can configure the TOE to
send logs to another FortiAnalyzer. Log events can be sent via syslog or CEF in
real-time or according to a daily schedule defined by the administrator. Logs are
protected with TLS as described by FCS_TLSC_EXT.1 and FCS_TLSC_EXT.2.
33 The amount of disk space used for log storage is configurable, but is dependent on
the total available FortiAnalyzer disk space which varies depending on TOE model
as shown in Differences column of Table 5.
34 When the local audit store is full, the TOE will overwrite audit records starting with
the oldest audit record.
35 Only authorized administrators may view audit records and no capability to modify
the audit records is provided.
6.2 Cryptographic Support
6.2.1 FCS_CKM.1
36 The TOE supports key generation for the following asymmetric schemes:
a) RSA 2048-bit. Used in SSH and TLS.
b) ECC P-256/P-384/P-521. Used in TLS.
c) FFC safe-prime groups. Diffie-Hellman used in TLS and SSH
6.2.2 FCS_CKM.2
37 The TOE supports the following key establishment schemes:
a) ECC schemes. Used in TLS ciphersuites with ECDH key exchange. TOE is
both sender and receiver.
38 Table 13 below identifies the scheme being used by each service.
Table 13: Key Agreement Mapping
Scheme SFR Service
ECC FCS_TLSS_EXT.1 Administration
FCS_TLSC_EXT.1/2 Audit Server
FFC FCS_SSHS_EXT.1 Administration
FCS_TLSS_EXT.1 Administration
Fortinet Security Target
Page 35 of 49
Scheme SFR Service
FCS_TLSC_EXT.1/2 Audit Server
b) FFC schemes. Used in SSH and TLS. The TOE uses safe-prime groups that
meet NIST Special Publication 800-56A Revision 3 “Recommendation for
Pair-Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography” and [RFC 3526]
i) Group 14 per RFC 3526 section 3
6.2.3 FCS_CKM.4
39 Keys held in volatile memory are zeroized after use by overwriting the key storage
area with zeroes. Keys held in flash memory may be destroyed using a Command
Line Interface (CLI) command to overwrite the entire flash memory an administrator
specified number of times (between 1 and 10) with zeroes. This command is used
when a device is reset or taken out of operation. Table 15 shows the origin, storage
location and destruction details for cryptographic keys and passwords. Unless
otherwise stated, the keys are generated by the TOE.
6.2.4 FCS_COP.1/DataEncryption
40 The TOE provides symmetric encryption and decryption capabilities using 128 and
256 bit AES in CBC GCM, and CTR mode. AES is implemented in the following
protocols: TLS and SSH (CTR only)
41 The relevant NIST CAVP certificate numbers are listed Table 4.
6.2.5 FCS_COP.1/SigGen
42 The TOE provides cryptographic signature generation and verification services
using:
a) RSA Signature Algorithm with key size of 2048 and greater,
b) ECDSA Signature Algorithm with NIST curves P-256, P-384, P-521
43 These RSA and ECDSA signature verification services are used in the TLS
protocols. Additionally, RSA signature verification is used for the SSH protocol (ssh-
rsa) and TOE firmware integrity checks.
44 The relevant NIST CAVP certificate numbers are listed in Table 4.
6.2.6 FCS_COP.1/Hash
45 The TOE provides cryptographic hashing services using SHA-1, SHA-256, SHA-384,
and SHA-512.
46 SHA is implemented in the following parts of the TSF:
a) TLS and SSH signature generation and integrity verification;
b) Digital signature verification as part of trusted update validation; and
c) Hashing of passwords in non-volatile storage for integrity protection.
47 The relevant NIST CAVP certificate numbers are listed in Table 4.
Fortinet Security Target
Page 36 of 49
6.2.7 FCS_COP.1/KeyedHash
48 The TOE provides keyed-hashing message authentication services using HMAC-
SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
49 HMAC is implemented in the following protocols: TLS and SSH.
50 The characteristics of the HMACs used in the TOE are given in Table 14.
Table 14: HMAC Characteristics
Algorithm Block Size Key Size Digest Size
HMAC-SHA-1 512 bits 160 bits 160 bits
HMAC-SHA-256 512 bits 256 bits 256 bits
HMAC-SHA-384 1024 bits 384 bits 384 bits
HMAC-SHA-512 1024 bits 512 bits 512 bits
51 The relevant NIST CAVP certificate numbers are listed in Table 4.
6.2.8 FCS_HTTPS_EXT.1
52 The TOE web GUI is accessed via an HTTPS connection using the TLS
implementation described by FCS_TLSS_EXT.1. The TOE does not use HTTPS in a
client capacity. The TOE’s HTTPS protocol complies with RFC 2818.
53 RFC 2818 specifies HTTP over TLS. The majority of RFC 2818 is spent on
discussing practices for validating endpoint identities and how connections must be
setup and torn down. The TOE web GUI operates on an explicit port designed to
natively speak TLS: it does not attempt STARTTLS or similar multi-protocol
negotiation, which is described in section 2.3 of RFC 2818. The web server uses a
variant of OpenSSL which attempts to send closure Alerts prior to closing a
connection in accordance with section 2.2.2 of RFC 2818.
6.2.9 FCS_RBG_EXT.1
54 The TOE implements an entropy collection system from the hardware based Fortinet
Entropy Token. The noise source, which is derived from wide-band radio frequency
(RF) white noise, is pooled and conditioned prior to being used.
55 The TOE contains a CTR_DRBG that is seeded from the hardware entropy source.
Entropy from the noise source is extracted 5120 bits at a time, conditioned and used
to seed the DRBG with 256 bits of full entropy.
56 Additional detail is provided the proprietary Entropy Description.
6.2.10 FCS_SSHS_EXT.1
57 The TOE implements SSH in compliance with RFCs 4251 through 4254 and 6668,
8308, 8332.
58 The TOE supports password-based or public key (ssh-rsa, rsa-sha2-256 and rsa-
sha2-512) authentication.
59 The TOE establishes a user identity by verifying that the non-TOE client uses its
private key to send a request to the TOE that only the private key holder can sign
and send. The TOE verifies the non-TOE sender using the stored public key.
Fortinet Security Target
Page 37 of 49
60 The TOE examines the size of each received SSH packet. If the packet is greater
than 256KB, it is automatically dropped.
61 The TOE utilises AES-CTR-128 and AES-CTR-256 for SSH encryption.
62 The TOE provides data integrity for SSH connections via HMAC-SHA1, HMAC-
SHA2-256 and HMAC-SHA2-512.
63 The TOE supports Diffie-Hellman Group 14 SHA-1 (diffie-hellman-group14-sha1) for
SSH key exchanges
64 The TOE will re-key SSH connections after 1 hour or after an aggregate of 1
gigabyte of data has been exchanged (whichever occurs first).
6.2.11 FCS_TLSC_EXT.1
65 The TOE operates as a TLS client for the trusted channel with the FAZ Audit Server.
66 TLS 1.1 and 1.2 are allowed and ciphersuites are restricted to the following
a) TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
b) TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
c) TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246
d) TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
e) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
f) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
g) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
h) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
i) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
j) TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
k) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
l) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
67 Ciphersuites are not user-configurable.
68 The reference identifier for the FAZ Audit Server is configured by the administrator
using the CLI. The reference identifiers must be either a DNS name or IPv4.
69 When the TLS client receives an X.509 certificate from the server, the client will
compare the reference identifier with the established Subject Alternative Names
(SANs) in the certificate. If a SAN is available and does not match the reference
identifier, then the verification fails and the channel is terminated. Otherwise, the
reference identifier verification passes and additional verification actions can
proceed. The TOE supports wildcards for DNS names in the SAN and CN. IP
addresses are supported in the SAN. When the SAN is not available, the TOE
makes use of the CN, which only supports DNS.
70 The TLS client does not support certificate pinning.
71 The TLS client will transmit the Supported Elliptic Curves extension in the Client
Hello message by default with support for the following curves/groups: secp256r1,
secp384r1, and secp521r1. The non-TOE server can choose to negotiate the elliptic
curve from this set for any of the mutually negotiable elliptic curve ciphersuites.
Fortinet Security Target
Page 38 of 49
6.2.12 FCS_TLSC_EXT.2
72 The TOE supports presentation of an X.509v3 client certificate for authentication as
required by the FAZ Audit Server.
6.2.13 FCS_TLSS_EXT.1
73 The TOE operates as a TLS server for the web GUI trusted path.
74 The server only allows TLS protocol versions 1.1 and 1.2 (rejecting any other
protocol version, including SSL 2.0, SSL 3.0 and TLS 1.0 and any other unknown
TLS version string supplied) and is restricted to the following ciphersuites by default:
a) TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
b) TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
c) TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246
d) TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
e) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
f) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
g) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
h) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
i) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
j) TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
k) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
l) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
75 Ciphersuites are not user-configurable.
76 The TLS server is capable of negotiating ciphersuites that include DHE, and ECDHE
key agreement schemes. The DHE key agreement parameters are restricted to 2048
and are hardcoded into the server. ECDHE key agreement parameters are restricted
to ECDHE curves secp256r1, secp384r1, secp521r1.
77 The TLS server supports session tickets. Session tickets adhere to the structural
format provided in section 4 of RFC 5077. Session tickets are encrypted according
to the TLS negotiated symmetric encryption algorithm.
78 Session resumption and establishment require session IDs only.
6.3 Identification and Authentication
6.3.1 FIA_PMG_EXT.1
79 The TOE supports the local definition of users with corresponding passwords. The
passwords can be composed of any combination of upper and lower case letters,
numbers, and special characters “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”.
80 The minimum password length is settable by the Administrator and can range from 6
to 128 characters.
Fortinet Security Target
Page 39 of 49
6.3.2 FIA_UIA_EXT.1
81 The TOE requires all users to be successfully identified and authenticated. The TOE
warning banner may be viewed prior to authentication
6.3.3 FIA_UAU_EXT.2
82 Administrative access to the TOE is facilitated through one of several interfaces
a) Directly connecting to the TOE appliance
b) Remotely connecting to each appliance via SSHv2
c) Remotely connecting to appliance GUI via HTTPS
83 Regardless of the interface at which the administrator interacts, the TOE prompts the
user for a credential. Only after the administrative user presents the correct
authentication credentials will they be granted access to the TOE administrative
functionality. No TOE administrative access is permitted until an administrator is
successfully identified and authenticated.
84 The TOE provides a local password based authentication mechanism.
85 The process for authentication is the same for administrative access whether
administration is occurring via direct connection or remotely. At initial login, the
administrative user is prompted to provide a username. After the user provides the
username, the user is prompted to provide the administrative credential associated
with the user account (e.g. password or SSH public/private key response). The TOE
then either grants administrative access (if the combination of username and
credential is correct) or indicates that the login was unsuccessful. The TOE does not
provide a reason for failure in the cases of a login failure.
6.3.4 FIA_UAU.7
86 For all authentication at the local CLI the TOE displays only “*” characters when the
administrative password is entered so that the password is obscured.
6.3.5 FIA_AFL.1
87 The TOE is capable of tracking authentication failures of remote administrators.
88 When a user account has sequentially failed authentication the configured number of
times (default 3) the account will be locked for a Security Administrator defined time
period (default 60 seconds).
89 The administrator can configure the maximum number of failed attempts, and the
time-period for which the account is locked using the web GUI or CLI.
90 The local console does not implement the lockout mechanism.
6.3.6 FIA_X509_EXT.1/Rev
91 The TOE performs X.509 certificate validation at the following points:
a) TOE TLS client validation of server X.509 certificates;
b) When certificates are loaded into the TOE, such as when importing CA’s,
certificate responses and other device-level certificates (such as the web
server certificate presented by the TOE TLS web GUI).
92 In all scenarios, certificates are checked for several validation characteristics:
Fortinet Security Target
Page 40 of 49
a) If the certificate ‘notAfter’ date is in the past, then this is an expired certificate
which is considered invalid;
b) The certificate chain must terminate with a trusted CA certificate;
c) Server certificates consumed by the TOE TLS client must have a
‘serverAuthentication’ extendedKeyUsage purpose;
93 A trusted CA certificate is defined as any certificate loaded into the TOE trust store
that has, at a minimum, a ‘basicConstraints’ extension with the CA flag set to
‘TRUE’.
94 Certificate revocation checking for the above scenarios is performed using a
Certificate Revocation List (CRL) on both the leaf and the intermediate CA
certificates.
95 The X.509 certificates for each of the given scenarios are validated using the
certificate path validation algorithm defined in RFC 5280, which can be summarized
as follows:
a) The public key algorithm and parameters are checked
b) The current date/time is checked against the validity period and revocation
status is checked
c) Issuer name of X matches the subject name of X+1
d) Name constraints are checked
e) Policy OIDs are checked
f) Policy constraints are checked, issuers are ensured to have CA signing bits
g) Path length is checked
h) Critical extensions are processed
96 If, during the entire trust chain verification activity, any certificate under review fails a
verification check, then the entire trust chain is deemed untrusted and the TLS
connection is terminated.
6.3.7 FIA_X509_EXT.2
97 As X.509 certificates are not used for trusted updates, firmware integrity self-tests, or
client authentication, the code-signing and clientAuthentication purpose is not
checked in the extendedKeyUsage for related certificates.
98 The TOE has a trust store where root CA and intermediate CA certificates can be
stored. The trust store is not cached: if a certificate is deleted, it is immediately
untrusted. If a certificate is added to the trust store, it is immediately trusted for its
given scope.
99 As part of the verification process, CRL is used to determine whether the certificate
is revoked or not. If the CRL cannot be obtained, then the TOE will accept the
certificate in this case.
100 Instructions for configuring the trusted IT entities to supply appropriate X.509
certificates are captured in the guidance documents.
6.3.8 FIA_X509_EXT.3
101 For the Certificate Signing Request, a CN is required and may be a DNS name.
SANs are optional and may be IP address or DNS name.
Fortinet Security Target
Page 41 of 49
6.4 Security Management
6.4.1 FMT_MOF.1/ManualUpdate
102 The TOE restricts the ability to perform software updates to Security Administrators.
6.4.2 FMT_MOF.1/Functions
103 The TOE restricts the ability to modify (enable/disable) transmission of audit records
to an external audit server (another FAZ) to Security Administrators.
6.4.3 FMT_MTD.1/CoreData
104 The TOE implements role based access control based on pre-defined profiles that
are assigned when creating a user. Users are required to login before being
provided with access to any administrative functions.
105 Management of TSF data via the CLI or web GUI is restricted to Security
Administrators.
6.4.4 FMT_SMR.2
106 The TOE supports the following pre-defined administrative user profiles
a) Restricted_User. Restricted user profiles have no access to system settings,
and have read-only access to FAZ functions.
b) Standard_User. Standard user profiles have no access to system settings,
but have read/write access to FAZ functions.
c) Super_User. Super user profiles have all system and device privileges
enabled. This profile equates to the Security Administrator role defined in this
Security Target.
6.4.5 FMT_MTD.1/CryptoKeys
107 The TOE restricts the ability to modify, delete, generate, import, or otherwise
manage SSH keys, TLS, and any configured X.509 certificates or private keys to
Security Administrators.
6.4.6 FMT_SMF.1
108 The TOE may be managed via the CLI (console & SSH) or GUI (HTTPS). The
specific management capabilities include:
a) Ability to administer the TOE locally and remotely
b) Ability to configure the access banner
c) Ability to configure the session inactivity time before session termination or
locking
d) Ability to update the TOE and to verify the updates
e) Ability to configure the authentication failure parameters
f) Ability to configure audit behavior (the admins can configure the log space
size, and maximum log file size)
g) Ability to modify the behaviour of the transmission of audit data to an external
IT entity - enable/disable remote logging.
h) Ability to manage the cryptographic keys
Fortinet Security Target
Page 42 of 49
i) Ability to configure the cryptographic functionality
j) Ability to set the time which is used for time-stamps
k) Ability to manage the TOE’s trust store and designate X509v3 certificates as
trust anchors
l) Ability to import X509v3 certificates to the TOE’s trust store
6.5 Protection of the TSF
6.5.1 FPT_SKP_EXT.1
109 The TOE prevents the reading of all pre-shared keys, symmetric keys and private
keys stored within the TOE boundary.
110 Key storage and destruction methods are described in Table 15.
Table 15: Keys
Key Generation/
Algorithm
Storage Zeroization
TLS Private Key RSA (2048 bits) or
ECDSA (P-256, P-
384, P-521)
Flash -
plaintext
Overwritten with zeroes by erase-disk
command.
TLS Public Key RSA (2048 bits) or
ECDSA (P-256, P-
384, P-521)
Flash -
plaintext
n/a – public key
DH Keys used
for TLS
DH (2048 bits) RAM -
plaintext
Overwritten with zeroes upon termination
of the session or reboot of the appliance
ECDH Keys
used for TLS
ECC P-256, P-384,
P-521
RAM -
plaintext
Overwritten with zeroes upon termination
of the session or reboot of the appliance
AES key used
for TLS
AES-128
AES-256
RAM -
plaintext
Overwritten with zeroes upon termination
of the session or reboot of the appliance
Firmware
Update Key
(Public Key)
Preconfigured
RSA (2048 bits)
Flash -
plaintext
n/a – public key
SSH Private
Key (host key)
RSA (2048 bits) Flash -
plaintext
Overwritten with zeroes by erase-disk
command.
SSH Public Key RSA (2048 bits) Flash -
plaintext
n/a – public key
SSH Session
Key
AES-128
AES-256
RAM -
plaintext
The keys (including re-keyed keys) are
overwritten with zeroes when no longer
required or reboot of the appliance
Fortinet Security Target
Page 43 of 49
6.5.2 FPT_APW_EXT.1
111 Passwords are protected as describe in Table 16.
Table 16: Passwords
Password Generation/Algorith
m
Storage Zeroization
Locally stored
administrator
passwords
User generated Flash -
SHA-256
hash
Overwritten with zeroes by erase-disk
command.
6.5.3 FPT_TST_EXT.1
112 The Fortinet family of appliances provides a secure initialization procedure to ensure
the integrity of the image and correct cryptographic functioning of the product prior to
any information flowing. The product starts from a powered down state and no
signals on the wire. The device then powers on and undergoes the following
initialization process:
a) Bootstrap and Boot Loader
b) Verification of the kernel, firmware and software images using 2048 bit RSA
signature.
c) Loading and Initialization of:
i) Kernel;
ii) Firmware;
iii) Cryptographic known answer tests;
iv) Entropy gathering and DRBG initialization; and
v) Cryptographic module.
113 These tests ensure the correct operation of the functionality of the TOE, the CPU
and BIOS and verify that the correct TOE image is being used. The cryptographic
functionality will not be available if the tests fail, and any operation of the TOE
supported by this functionality will not be available. If the CPU, or BIOS tests fail, the
device will not complete the boot up operation. If the boot loader image verification
fails, the boot up operation will fail. When the device completes the boot up
operation, this is evidence that the self-tests have passed, and that the TOE, and the
cryptographic functions are operating correctly.
6.5.4 FPT_TUD_EXT.1
114 The administrator may query the current version of the TOE via the GUI or CLI.
115 Updates to the TOE are applied in accordance with the following process:
116 The administrator downloads the upgrade image/package from the Fortinet website.
117 Once downloaded, the administrator must transfer the image to the TOE via a
trusted path (e.g. the web interface).
118 Upon initiating the update process, the TOE will attempt to verify the integrity and
authenticity of the update package. This is achieved via the verification of a 2048-bit
RSA signature that is applied to the package by the Fortinet development team.
Fortinet Security Target
Page 44 of 49
119 If the signature cannot be verified, or the integrity of the package cannot be
confirmed, the upgrade will fail and an audit log generated accordingly.
120 If the signature is verified correctly and the integrity of the package is confirmed, the
upgrade will be applied and the TOE restarted.
6.5.5 FPT_STM_EXT.1
121 The TOE incorporates an internal clock that is used to maintain date and time. The
Security Administrator sets the date and time during initial TOE configuration and
may change the time during operation.
122 The TOE makes use of time for the following:
a) Audit record timestamps
b) Session timeouts (lockout enforcement)
c) Certificate validation
6.6 TOE Access
6.6.1 FTA_SSL_EXT.1
123 The Security Administrator may configure the TOE to terminate an inactive local
administrative session following a specified period of time. The timeout value is set
to five minutes by default.
6.6.2 FTA_SSL.3
124 The Security Administrator may configure the TOE to terminate an inactive remote
CLI or Web GUI session following a specified period of time. The timeout value is set
to five minutes by default.
6.6.3 FTA_SSL.4
125 Administrative users may manually terminate their own sessions at any time.
6.6.4 FTA_TAB.1
126 The TOE displays an administrator configurable message to users prior to
authentication.
127 TOE Administrators may access the TOE remotely (via the HTTPS/TLS web GUI or
SSH) or locally (via the serial/console port)
6.7 Trusted Path/Channels
6.7.1 FTP_ITC.1
128 The TOE supports secure communication with the following IT entities:
a) Audit server (another FAZ) per FCS_TLSC_EXT.1 and per FCS_TLSC_EXT.2
129 This connection is protected via TLS as described in the related SFRs.
6.7.2 FTP_TRP.1/Admin
130 The TOE provides the following trusted paths for remote administration:
a) CLI over SSH per FCS_SSHS_EXT.1
Fortinet Security Target
Page 45 of 49
b) Web GUI over HTTPS per FCS_HTTPS_EXT.1.1
Fortinet Security Target
Page 46 of 49
7 Rationale
7.1 Conformance Claim Rationale
131 The following rationale is presented with regard to the PP conformance claims:
a) TOE type. As identified in section 2.1, the TOE is a network device, consistent
with the NDcPP.
b) Security problem definition. As shown in section 3, the threats, OSPs and
assumptions are reproduced directly from the NDcPP.
c) Security objectives. As shown in section 4, the security objectives are
reproduced directly from the NDcPP.
d) Security requirements. As shown in section 5, the security requirements are
reproduced directly from the NDcPP. No additional requirements have been
specified.
7.2 Security Objectives Rationale
132 All security objectives are drawn directly from the NDcPP.
7.3 Security Requirements Rationale
133 All security requirements are drawn directly from the NDcPP. Table 17 presents a
mapping between threats and SFRs as presented in the NDcPP.
Table 17: NDcPP SFR Rationale
Identifier SFR Rationale
T.UNAUTHORIZED_
ADMINISTRATOR_ACCESS
• The Administrator role is defined in FMT_SMR.2 and the
relevant administration capabilities are defined in
FMT_SMF.1 and FMT_MTD.1/CoreData, with optional
additional capabilities in FMT_MOF.1/Services and
FMT_MOF.1/Functions
• The actions allowed before authentication of an
Administrator are constrained by FIA_UIA_EXT.1, and
include the advisory notice and consent warning message
displayed according to FTA_TAB.1
• The requirement for the Administrator authentication
process is described in FIA_UAU_EXT.2
• Locking of Administrator sessions is ensured by
FTA_SSL_EXT.1 (for local sessions), FTA_SSL.3 (for
remote sessions), and FTA_SSL.4 (for all interactive
sessions)
• The secure channel used for remote Administrator
connections is specified in FTP_TRP.1/Admin
• (Malicious actions carried out from an Administrator session
are separately addressed by T.UNDETECTED_ACTIVITY)
Fortinet Security Target
Page 47 of 49
Identifier SFR Rationale
• (Protection of the Administrator credentials is separately
addressed by T.PASSWORD_CRACKING).
T.WEAK_CRYPTOGRAPHY
• Requirements for key generation and key distribution are
set in FCS_CKM.1 and FCS_CKM.2 respectively
• Requirements for use of cryptographic schemes are set in
FCS_COP.1/DataEncryption, FCS_COP.1/SigGen,
FCS_COP.1/Hash, and FCS_COP.1/KeyedHash
• Requirements for random bit generation to support key
generation and secure protocols (see SFRs resulting from
T.UNTRUSTED_COMMUNICATION_CHANNELS) are set
in FCS_RBG_EXT.1
• Management of cryptographic functions is specified in
FMT_SMF.1
T.UNTRUSTED_
COMMUNICATION_
CHANNELS
• The general use of secure protocols for identified
communication channels is described at the top level in
FTP_ITC.1 and FTP_TRP.1/Admin; for distributed TOEs the
requirements for inter-component communications are
addressed by the requirements in FPT_ITT.1
• Requirements for the use of secure communication
protocols are set for all the allowed protocols in
FCS_DTLSC_EXT.1, FCS_DTLSC_EXT.2,
FCS_DTLSS_EXT.1, FCS_DTLSS_EXT.2,
FCS_HTTPS_EXT.1, FCS_IPSEC_EXT.1,
FCS_SSHC_EXT.1, FCS_SSHS_EXT.1,
FCS_TLSC_EXT.1, FCS_TLSC_EXT.2, FCS_TLSS_EXT.1,
FCS_TLSS_EXT.2
• Optional and selection-based requirements for use of public
key certificates to support secure protocols are defined in
FIA_X509_EXT.1, FIA_X509_EXT.2, FIA_X509_EXT.3
T.WEAK_
AUTHENTICATION_
ENDPOINTS
• The use of appropriate secure protocols to provide
authentication of endpoints (as in the SFRs addressing
T.UNTRUSTED_COMMUNICATION_CHANNELS) are
ensured by the requirements in FTP_ITC.1 and
FTP_TRP.1/Admin; for distributed TOEs the authentication
requirements for endpoints in inter-component
communications are addressed by the requirements in
FPT_ITT.1
• Additional possible special cases of secure authentication
during registration of distributed TOE components are
addressed by FCO_CPC_EXT.1 and FTP_TRP.1/Join.
T.UPDATE_COMPROMISE • Requirements for protection of updates are set in
FPT_TUD_EXT.1
• Additional optional use of certificate-based protection of
signatures can be specified using FPT_TUD_EXT.2,
supported by the X.509 certificate processing requirements
in FIA_X509_EXT.1, FIA_X509_EXT.2 and
FIA_X509_EXT.3
Fortinet Security Target
Page 48 of 49
Identifier SFR Rationale
• Requirements for management of updates are defined in
FMT_SMF.1 and (for manual updates) in
FMT_MOF.1/ManualUpdate, with optional requirements for
automatic updates in FMT_MOF.1/AutoUpdate
T.UNDETECTED_ACTIVITY • Requirements for basic auditing capabilities are specified in
FAU_GEN.1 and FAU_GEN.2, with timestamps provided
according to FPT_STM_EXT.1 and if applicable, protection
of NTP channels in FCS_NTP_EXT.1.
• Requirements for protecting audit records stored on the
TOE are specified in FAU_STG.1
• Requirements for secure transmission of local audit records
to an external IT entity via a secure channel are specified in
FAU_STG_EXT.1
• Optional additional requirements for dealing with potential
loss of locally stored audit records are specified in
FAU_STG_EXT.2/LocSpace, and FAU_STG.3/LocSpace
• If (optionally) configuration of the audit functionality is
provided by the TOE then this is specified in FMT_SMF.1,
and confining this functionality to Security Administrators is
required by FMT_MOF.1/Functions.
T.SECURITY_
FUNCTIONALITY_
COMPROMISE
• Protection of secret/private keys against compromise is
specified in FPT_SKP_EXT.1
• Secure destruction of keys is specified in FCS_CKM.4
• If (optionally) management of keys is provided by the TOE
then this is specified in FMT_SMF.1, and confining this
functionality to Security Administrators is required by
FMT_MTD.1/CryptoKeys
• (Protection of passwords is separately covered under
T.PASSWORD_CRACKING)
T.PASSWORD_CRACKING • Requirements for password lengths and available
characters are set in FIA_PMG_EXT.1
• Protection of password entry by providing only obscured
feedback is specified in FIA_UAU.7
• Actions on reaching a threshold number of consecutive
password failures are specified in FIA_AFL.1
• Requirements for secure storage of passwords are set in
FPT_APW_EXT.1.
T.SECURITY_
FUNCTIONALITY_FAILURE
• Requirements for running self-test(s) are defined in
FPT_TST_EXT.1
P.ACCESS_BANNER • An advisory notice and consent warning message is
required to be displayed by FTA_TAB.1
Fortinet Security Target
Page 49 of 49
Annex A: Extended Components Definition
134 See appended PDF extract of NDcPP extended components definition.
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 129 of 174
C. Extended ComponentDefinitions
This appendix contains the definitions for the extended requirements that are used in the cPP,
including those used in Appendices A and B.
(Note: formatting conventions for selections and assignments in this Appendix are those in
[CC2].)
C.1 Security Audit (FAU)
C.1.1 Security Audit Data Generation (FAU_GEN_EXT)
Family Behaviour
This component defines the requirements for components in a distributed TOE to generate
security audit data.
Component levelling
FAU_GEN_EXT.1 Security audit data shall be generated by all components in a distributed
TOE
Management: FAU_GEN_EXT.1
The following actions could be considered for the management functions in FMT:
a) The TSF shall have the ability to configure the cryptographic functionality.
Audit: FAU_GEN_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) No audit necessary.
C.1.1.1 FAU_ GEN_EXT.1 Security Audit Data Generation for Distributed TOE
Components
FAU_GEN_EXT.1 Security Audit Data Generation
Hierarchical to: No other components.
Dependencies: None.
FAU_GEN_EXT Security Audit Data Generation 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 130 of 174
FAU_GEN_EXT.1.1. The TSF shall be able to generate audit records for each TOE
component. The audit records generated by the TSF of each TOE component shall include the
subset of security relevant audit events which can occur on the TOE component.
C.1.2 Protected Audit Event Storage (FAU_STG_EXT)
Family Behaviour
This component defines the requirements for the TSF to be able to securely transmit audit data
between the TOE and an external IT entity.
Component levelling
FAU_STG_EXT.1 Protected audit event storage requires the TSF to use a trusted channel
implementing a secure protocol.
FAU_STG_EXT.2 Counting lost audit data requires the TSF to provide information about audit
records affected when the audit log becomes full.
FAU_STG_EXT.3 Action in case of possible audit data loss requires the TSF to generate a
warning before the audit trail exceeds the local storage capacity.
FAU_STG_EXT.4 Protected Local audit event storage for distributed TOEs requires the TSF
to use a trusted channel to protect audit transfer to another TOE component.
FAU_STG_EXT.5 ProtectedRemote audit event storage for distributed TOEs requires the TSF
to use a trusted channel to protect audit transfer to another TOE component.
Management: FAU_STG_EXT.1, FAU_STG_EXT.2, FAU_STG_EXT.3,
FAU_STG_EXT.4, FAU_STG_EXT.5
The following actions could be considered for the management functions in FMT:
a) The TSF shall have the ability to configure the cryptographic functionality.
FAU_STG_EXT Protected Audit Event Storage
1
2
3
4
5
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 131 of 174
Audit: FAU_STG_EXT.1, FAU_STG_EXT.2, FAU_STG_EXT.3, FAU_STG_EXT.4.
FAU_STG_EXT.5
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) No audit necessary.
C.1.2.1 FAU_ STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1 Protected Audit Event Storage
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FTP_ITC.1 Inter-TSF Trusted Channel
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
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. In
addition [selection:
• The TOE shall consist of a single standalone component that stores audit data locally,
• The TOE shall be a distributed TOE that stores audit data on the following TOE
components: [assignment: identification of TOE components],
• The TOE shall be a distributed TOE with storage of audit data provided externally for
the following TOE components: [assignment: list of TOE components that do not store
auditdata locally and the otherTOEcomponentsto which they transmittheirgenerated
audit data].
FAU_STG_EXT.1.3 The TSF shall [selection: drop new audit data, overwrite previous audit
records according to the following rule: [assignment: rule for overwriting previous audit
records], [assignment: other action]] when the local storage space for audit data is full.
C.1.2.2 FAU_ STG_EXT.2 Counting Lost Audit Data
FAU_STG_EXT.2 Counting Lost Audit Data
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG_EXT.1 External Audit Trail Storage
FAU_STG_EXT.2.1 The TSF shall provide information about the number of [selection:
dropped, overwritten, [assignment: other information]] audit records in the case where the
local storage has been filled and the TSF takes one of the actions defined in
FAU_STG_EXT.1.3.
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 132 of 174
C.1.2.3 FAU_ STG_EXT.3 Action in Case ofPossible Audit Data Loss
FAU_STG_EXT.3 Action in Case ofPossible Audit Data Loss
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG_EXT.1 External Audit Trail Storage
FAU_STG_EXT.3.1/LocSpace The TSF shall generate a warning to inform the
Administrator before the audit trail exceeds the local audit trail storage capacity.
C.1.2.4 FAU_ STG_EXT.4 Protected Local Audit Event Storage for Distributed TOEs
FAU_STG_EXT.4 Protected Audit Event Storage
Hierarchical to: No other components.
Dependencies: FAU_GEN_EXT.1 Security Audit data generation for
Distributed TOE Components
[FPT_ITT.1 Intra-TSF Trusted Channel or
FTP_ITC.1 Inter-TSF Trusted Channel]
FAU_STG_EXT.4.1 The TSF of eachTOE component which stores security audit data locally
shall perform the following actions when the local storage space for audit data is full:
[assignment: table of components and for each component its action chosen according to the
following: [selection: drop new audit data, overwrite previous audit records according to the
following rule: [assignment: rule for overwriting previous audit records], [assignment: other
action]]].
C.1.2.5 FAU_ STG_EXT.5 Protected Remote Audit Event Storage for Distributed
TOEs
FAU_STG_EXT.5 Protected Audit Event Storage
Hierarchical to: No other components.
Dependencies: FAU_GEN_EXT.1 Security Audit data generation for
Distributed TOE Components
[FPT_ITT.1 Intra-TSF Trusted Channel or
FTP_ITC.1 Inter-TSF Trusted Channel]
FAU_STG_EXT.5.1 Each TOE component which does not store security audit data locally
shall be able to buffer security audit data locally until it has been transferred to another TOE
component that stores or forwards it. All transfer of audit records between TOE components
shall use a protected channel according to [selection: FPT_ITT.1, FTP_ITC.1].
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 133 of 174
C.2 Cryptographic Support (FCS)
C.2.1 Random Bit Generation (FCS_RBG_EXT)
C.2.1.1 FCS_RBG_EXT.1 Random Bit Generation
Family Behaviour
Components in this family address the requirements for random bit/number generation. This is
a new family defined for the FCS class.
Component levelling
FCS_RBG_EXT.1 Random Bit Generation requires random bit generation to be performed in
accordance with selected standards and seeded by an entropy source.
Management: FCS_RBG_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen
Audit: FCS_RBG_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) Minimal: failure of the randomization process
FCS_RBG_EXT.1 Random Bit Generation
Hierarchical to: No other components
Dependencies: No other components
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services
in accordance with ISO/IEC 18031:2011 using [selection: Hash_DRBG (any), HMAC_DRBG
(any), CTR_DRBG (AES)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source
that accumulates entropy from [selection: [assignment: number of software-based sources]
software-based noise source, [assignment: numberof platform-based sources] platform-based
noise source] with a minimum of [selection: 128 bits, 192 bits, 256 bits] of entropy at least
FCS_RBG_EXT RandomBit Generation 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 134 of 174
equal to the greatest security strength, according to ISO/IEC 18031:2011 Table C.1 “Security
Strength Table for Hash Functions”, of the keys and hashes that it will generate.
C.2.2 Cryptographic Protocols (FCS_DTLSC_EXT, FCS_DTLSS_EXT,
FCS_HTTPS_EXT, FCS_IPSEC_EXT, FCS_NTP_EXT, FCS_SSHC_EXT,
FCS_SSHS_EXT, FCS_TLSC_EXT, FCS_TLSS_EXT)
C.2.2.1 FCS_DTLSC_EXT DTLS Client Protocol
Family Behaviour
The component in this family addresses the ability for a client to use DTLS to protect data
between the client and a server using the DTLS protocol.
Component levelling
FCS_DTLSC_EXT.1 DTLS Client requires that the client side of DTLS be implemented as
specified.
FCS_DTLSC_EXT.2 DTLS Client requires that the client side of the DTLS implementation
include mutual authentication.
Management: FCS_DTLSC_EXT.1, FCS_DTLSC_EXT.2
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_DTLSC_EXT.1, FCS_DTLSC_EXT.2
The following actions should be considered for audit if FAU_GEN Security audit data
generation is included in the PP/ST:
a) Failure of DTLS session establishment
b) DTLS session establishment
c) DTLS session termination
FCS_DTLSC_EXT.1 DTLS Client Protocol
Hierarchical to: No other components
Dependencies: FCS_CKM. 1DataEncryption1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_DTLSC_EXT DTLS Client Protocol
1
2
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 135 of 174
FCS_COP.1/DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1/SigGen1SigGen Cryptographic operation
(Signature Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FCS_DTLSC_EXT.1.1 The TSF shall implement [selection: DTLS 1.2 (RFC 6347),DTLS 1.0
(RFC 4347)] supporting the following ciphersuites:
● [assignment: List of optional ciphersuites and reference to RFC in which each is
defined].
FCS_DTLSC_EXT.1.2 The TSF shall verify that the presented identifier matches [selection:
the reference identifier per RFC 6125 section 6, IPv4 address in CN or SAN, IPv6 address in
the CN or SAN, IPv4 address in SAN, IPv6 address in the SAN, the identifier per RFC 5280
Appendix A using [selection: id-at-commonName, id-at-countryName, id-at-dnQualifier, id-
at-generationQualifier, id-at-givenName, id-at-initials, id-at-localityName, id-at-name, id-at-
organizationalUnitName, id-at-organizationName, id-at-pseudonym, id-at-serialNumber, id-
at-stateOrProvinceName, id-at-surname, id-at-title] and no other attribute types].
FCS_DTLSC_EXT.1.3 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the server certificate is invalid. The TSF shall also [selection:
• Not implement any administrator override mechanism
• require administrator authorization to establish the connection if the TSF fails to
[selection: match the reference identifier, validate certificate path,validate expiration
date, determine the revocation status] of the presented server certificate
].
FCS_DTLSC_EXT.1.4 The TSF shall [selection: not present the Supported Elliptic
Curves/Supported Groups Extension, present the Supported Elliptic Curves/Supported Groups
Extension with the following curves/groups: [selection: secp256r1, secp384r1, secp521r1,
ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] and no other curves/groups] in the
Client Hello.
FCS_DTLSC_EXT.2 DTLS Client Support for Mutual Authentication
Hierarchical to: No other components
Dependencies: FCS_CKM.1/DataEncryption Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 136 of 174
FCS_COP.1/DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_DTLSC_EXT.1 DTLS Client Protocol
FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FCS_DTLSC_EXT.2.1 The TSF shall support mutual authentication using X.509v3
certificates.
FCS_DTLSC_EXT.2.2 The TSF shall [selection: terminate the DTLS session,silently discard
the record] if a message received contains an invalid MAC.
FCS_DTLSC_EXT.2.3 The TSF shall detect and silently discard replayed messages for:
• DTLS records previously received;
• DTLS records too old to fit in the sliding window.
C.2.2.2 FCS_DTLSS_EXT DTLS Server Protocol
Family Behaviour
The component in this family addresses the ability for a server to use DTLS to protect data
between a client and the server using the DTLS protocol.
Component levelling
FCS_DTLSS_EXT.1 DTLS Server requires that the server side of TLS be implemented as
specified.
FCS_DTLSS_EXT.2: DTLS Server requires that mutual authentication be included in the
DTLS implementation.
Management: FCS_DTLSS_EXT.1, FCS_DTLSS_EXT.2
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
FCS_DTLSS_EXT DTLS ServerProtocol
1
2
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 137 of 174
Audit: FCS_DTLSS_EXT.1, FCS_DTLSS_EXT.2
The following actions should be considered for audit if FAU_GEN Security audit data
generation is included in the PP/ST:
a) Failure of DTLS session establishment.
b) DTLS session establishment
c) DTLS session termination
FCS_DTLSS_EXT.1 DTLS Server Protocol
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1//DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1//SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FCS_DTLSS_EXT.1.1 The TSF shall implement [selection: DTLS 1.2 (RFC 6347), DTLS 1.0
(RFC 4347)] supporting the following ciphersuites:
● [assignment: List of optional ciphersuites and reference to RFC in which each is
defined]
FCS_DTLSS_EXT.1.2 The TSF shall deny connections from clients requesting [assignment:
list of protocol versions].
FCS_DTLSS_EXT.1.3 The TSF shall not proceed with a connection handshake attempt if the
DTLS Client fails validation.
FCS_DTLSS_EXT.1.4 The TSF shall perform key establishment for TLS using [selection:
RSA with key size [selection: 2048 bits, 3072 bits, 4096 bits], Diffie-Hellman parameters with
size [selection: 2048 bits, 3072 bits, 4096 bits, 6144 bits, 8192 bits], Diffie-Hellman groups
[selection: ffdhe2048, ffdhe3072,ffdhe4096, ffdhe6144, ffdhe8192, no othergroups],ECDHE
curves [selection: secp256r1, secp384r1, secp521r1] and no other curves].
FCS_DTLSS_EXT.1.5 The TSF shall [selection: terminate the DTLS session, silently discard
the record] if a message received contains an invalid MAC.
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 138 of 174
FCS_DTLSS_EXT.1.6 The TSF shall detect and silently discard replayed messages for:
• DTLS records previously received.
• DTLS Records too old to fit in the sliding window.
FCS_DTLSS_EXT.1.7 The TSF shall support [selection: no session resumption or session
tickets,session resumption based on session IDsaccordingto RFC4346 (TLS1.1)orRFC5246
(TLS1.2), session resumption based on session tickets according to RFC 5077].
FCS_DTLSS_EXT.2 DTLS Server Support for Mutual Authentication
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_DTLSS_EXT.1 DTLS Server Protocol
FCS_DTLSS_EXT.2.1 The TSF shall support mutual authentication of DTLS clients using
X.509v3 certificates.
FCS_DTLSS_EXT.2.2 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the client certificate is invalid. The TSF shall also [selection:
• Not implement any administrator override mechanism
• require administrator authorization to establish the connection if the TSF fails to
[selection: match the reference identifier,validate certificate path, validate expiration
date, determine the revocation status] of the presented client certificate
].
FCS_DTLSS_EXT.2.3 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.
C.2.2.3FCS_HTTPS_EXT.1 HTTPS Protocol
Family Behaviour
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 139 of 174
Components in this family define the requirements for protecting remote management sessions
between the TOE and a Security Administrator. This family describes how HTTPS will be
implemented. This is a new family defined for the FCS Class.
Component levelling
FCS_HTTPS_EXT.1 HTTPS requires that HTTPS be implemented according to RFC 2818
and supports TLS.
Management: FCS_HTTPS_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_HTTPS_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) There are no auditable events foreseen.
FCS_HTTPS_EXT.1 HTTPS Protocol
Hierarchical to: No other components
Dependencies: [FCS_TLSC_EXT.1 TLS Client Protocol, or
FCS_TLSS_EXT.1 TLS Server Protocol]
FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPSprotocol that complies with RFC
2818.
FCS_HTTPS_EXT.1.2 The TSF shall implement the HTTPS protocol using TLS.
FCS_HTTPS_EXT.1.3 If a peer certificate is presented, the TSF shall [selection: notestablish
the connection, request authorization to establish the connection, [assignment: other action]]
if the peer certificate is deemed invalid.
C.2.2.4 FCS_IPSEC_EXT.1 IPsec Protocol
Family Behaviour
Components in this family address the requirements for protecting communications using
IPsec.
FCS_HTTPS_EXT HTTPSProtocol 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 140 of 174
Component levelling
FCS_IPSEC_EXT.1 IPsec requires that IPsec be implemented as specified.
Management: FCS_IPSEC_EXT.1
The following actions could be considered for the management functions in FMT:
a) Maintenance of SA lifetime configuration
Audit: FCS_IPSEC_EXT.1
The following actions should be considered for audit if FAU_GEN Security audit data
generation is included in the PP/ST:
a) Decisions to DISCARD, BYPASS, PROTECT network packets processed by the
TOE.
b) Failure to establish an IPsec SA
c) IPsec SA establishment
d) IPsec SA termination
e) Negotiation “down” from an IKEv2 to IKEv1 exchange.
FCS_IPSEC_EXT.1 Internet Protocol Security (IPsec) Communications
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_IPSEC_EXT.1.1 The TSF shall implement the IPsec architecture as specified in RFC
4301.
FCS_IPSEC_EXT.1.2 The TSF shall have a nominal, final entry in the SPD that matches
anything that is otherwise unmatched and discards it.
FCS_IPSEC_EXT.1.3 The TSF shall implement [selection: tunnel mode, transport mode].
FCS_IPSEC_EXT IPsec Protocol 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 141 of 174
FCS_IPSEC_EXT.1.4 The TSF shall implement the IPsec protocol ESP as defined by RFC
4303 using the cryptographic algorithms [selection: AES-CBC-128 (RFC 3602),AES-CBC-192
(RFC 3602), AES-CBC-256 (RFC 3602), AES-GCM-128 (RFC 4106), AES-GCM-192 (RFC
4106), AES-GCM-256 (RFC 4106),] together with a Secure Hash Algorithm (SHA)-based
HMAC [selection: HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, no
HMAC algorithm].
FCS_IPSEC_EXT.1.5 The TSF shall implement the protocol: [selection:
• IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFCs 2407, 2408, 2409,
RFC 4109, [selection: no other RFCs for extended sequence numbers, RFC 4304 for
extended sequence numbers], and [selection: no other RFCs for hash functions,RFC
4868 for hash functions];
• IKEv2 as defined in RFCs 5996 [selection: with no support for NAT traversal, with
mandatory support for NAT traversal as specified in RFC 5996, section 2.23)], and
[selection: no other RFCs for hash functions,RFC 4868 forhash functions]].
FCS_IPSEC_EXT.1.6 The TSF shall ensure the encrypted payload in the [selection: IKEv1,
IKEv2] protocol uses the cryptographic algorithms [selection: AES-CBC-128, AES_CBC-192
AES-CBC-256 (specified in RFC 3602), AES-GCM-128, AES-GCM-192, AES-GCM-256
(specified in RFC 5282)].
FCS_IPSEC_EXT.1.7 The TSF shall ensure that [selection:
• IKEv1 Phase 1 SA lifetimes can be configured by a Security Administrator based on
[selection:
o number of bytes;
o length of time, where the time values can be configured within [assignment:
integer range including 24] hours;
];
• IKEv2 SA lifetimes can be configured by a Security Administrator based on [selection:
o number of bytes;
o length of time, where the time values can be configured within [assignment:
integer range including 24] hours
]
].
FCS_IPSEC_EXT.1.8 The TSF shall ensure that [selection:
• IKEv1 Phase 2 SA lifetimes can be configured by a Security Administrator based on
[selection:
o number of bytes;
o length of time, where the time values can be configured within [assignment:
integer range including 8] hours;
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 142 of 174
];
• IKEv2 Child SA lifetimes can be configured by a Security Administrator based on
[selection:
o number of bytes;
o length of time, where the time values can be configured within [assignment:
integer range including 8] hours;
]
].
FCS_IPSEC_EXT.1.9 The TSF shall generate the secret value x used in the IKE Diffie-
Hellman key exchange (“x” in gx mod p) using the random bit generator specified in
FCS_RBG_EXT.1, and having a length of at least [assignment: (one or more) number(s) of
bits that is at least twice the security strength of the negotiated Diffie-Hellman group] bits.
FCS_IPSEC_EXT.1.10 The TSF shall generate nonces used in [selection: IKEv1, IKEv2]
exchanges of length [selection:
• according to the security strength associated with the negotiated Diffie-Hellman
group;
• at least 128 bits in size and at least half the output size of the negotiated
pseudorandomfunction (PRF) hash
].
FCS_IPSEC_EXT.1.11 The TSF shall ensure that IKE protocols implement DH Group(s)
[selection:
• [selection: 14 (2048-bit MODP), 15 (3072-bit MODP), 16 (4096-bit MODP), 17
(6144-bit MODP), 18 (8192-bit MODP)] according to RFC 3526,
• [selection: 19 (256-bit RandomECP), 20 (384-bit RandomECP), 21 (521-bit Random
ECP), 24 (2048-bit MODP with 256-bit POS)] according to RFC 5114.
].
FCS_IPSEC_EXT.1.12 The TSF shall be able to ensure by default that the strength of the
symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the
[selection: IKEv1 Phase 1, IKEv2 IKE_SA] connection is greater than or equal to the strength
of the symmetric algorithm (in terms of the number of bits in the key) negotiated to protect the
[selection: IKEv1 Phase 2, IKEv2 CHILD_SA] connection.
FCS_IPSEC_EXT.1.13 The TSF shall ensure that all IKE protocols perform peer
authentication using [selection: RSA, ECDSA] that use X.509v3 certificates that conform to
RFC 4945 and [selection: Pre-shared Keys, no other method].
FCS_IPSEC_EXT.1.14 The TSF shall only establish a trusted channel if the presented
identifier in the received certificate matches the configured reference identifier, where the
presented and reference identifiers are of the following fields and types: [selection: SAN: IP
address,SAN:Fully Qualified Domain Name (FQDN),SAN: userFQDN, CN: IP address,CN:
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 143 of 174
Fully Qualified Domain Name (FQDN), CN: user FQDN, Distinguished Name (DN)] and
[selection: no other reference identifier type, [assignment: other supported reference identifier
types]].
C.2.2.5 FCS_NTP_EXT.1 NTP Protocol
Family Behaviour
The component in this family addresses the ability for a TOE to protect NTP time
synchronization traffic.
Component levelling
FCS_NTP_EXT.1 Requires NTP to be implemented as specified
Management: FCS_NTP_EXT.1
The following actions could be considered for the management functions in FMT:
a) Ability to configure NTP
Audit: FCS_NTP_EXT.1
The following actions should be considered for audit if FAU_GEN Security audit data
generation is included in the PP/ST:
a) No audit requirements are specified.
FCS_NTP_EXT.1 NTP Protocol
Hierarchical to: No other components
Dependencies: FCS_COP.1 Cryptographic operation
[FCS_DTLSC_EXT.1 DTLSC Client Protocol or
FCS_IPSEC_EXT.1 IPsec Protocol]
FCS_NTP_EXT.1.1 The TSF shall use only the following NTP version(s) [selection: NTP v3
(RFC 1305), NTP v4 (RFC 5905)].
FCS_NTP_EXT.1.2 The TSF shall update its system time using [selection:
• Authentication using [selection: SHA1, SHA256, SHA384, SHA512, AES-CBC-128,
AES-CBC-256] as the message digest algorithm(s);
FCS_NTP_EXT NTP Protocol 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 144 of 174
• [selection: IPsec, DTLS] to provide trusted communication between itself and an NTP
time source.
].
FCS_NTP_EXT.1.3 The TSF shall not update NTP timestamp from broadcast and/or
multicast addresses.
FCS_NTP_EXT.1.4 The TSF shall support configuration of at least three (3) NTP time
sources in the Operational Environment.
C.2.2.6 FCS_SSHC_EXT.1 SSH Client
Family Behaviour
The component in this family addresses the ability for a client to use SSH to protect data
between the client and a server using the SSH protocol.
Component levelling
FCS_SSHC_EXT.1 SSH Client requires that the client side of SSH be implemented as
specified.
Management: FCS_SSHC_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_SSHC_EXT.1
The following actions should be considered for audit if FAU_GEN Security audit data
generation is included in the PP/ST:
a) Failure of SSH session establishment
b) SSH session establishment
c) SSH session termination
FCS_SSHC_EXT.1 SSH Client Protocol
Hierarchical to: No other components
Dependencies: FCS_CKM.1Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_SSHC_EXT SSH Client Protocol 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 145 of 174
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_SSHC_EXT.1.1 The TSF shall implement the SSH protocol in accordance with: RFCs
4251, 4252, 4253, 4254, [selection: 4256, 4344, 5647, 5656, 6187,6668, 8268, 8308 section
3.1, 8332].
FCS_SSHC_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports
the following authentication methods as described in RFC 4252: public key-based, [selection:
password-based,no othermethod].
FCS_SSHC_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater
than [assignment: number of bytes] bytes in an SSH transport connection are dropped.
FCS_SSHC_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the
following encryption algorithms and rejects all other encryption algorithms: [assignment: list
of encryption algorithms].
FCS_SSHC_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses [selection: ssh-rsa, rsa-sha2-256,rsa-sha2-512, ecdsa-sha2-nistp256,
x509v3-ssh-rsa,ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, x509v3-ecdsa-sha2-nistp256,
x509v3-ecdsa-sha2-nistp384, x509v3-ecdsa-sha2-nistp521, x509v3-rsa2048-sha256] as its
public key algorithm(s) and rejects all other public key algorithms
FCS_SSHC_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses
[assignment: list of data integrity MAC algorithms] as its data integrity MAC algorithm(s) and
rejects all other MAC algorithm(s).
FCS_SSHC_EXT.1.7 The TSF shall ensure that [assignment: list of key exchange methods]
are the only allowed key exchange methods used for the SSH protocol.
FCS_SSHC_EXT.1.8 The TSF shall ensure that within SSH connections, the same session
keys are used for a threshold of no longer than one hour, and each encryption key is used to
protect no more than one gigabyte of data. After any of the thresholds are reached, a rekey
needs to be performed.
FCS_SSHC_EXT.1.9 The TSF shall ensure that the SSH client authenticates the identity of
the SSH server using a local database associating each host name with its corresponding public
key and [selection: a list of trusted certification authorities, no other methods] as described in
RFC 4251 section 4.1.
C.2.2.7 FCS_SSHS_EXT.1 SSH Server Protocol
Family Behaviour
The component in this family addresses the ability for a server to offer SSH to protect data
between a client and the server using the SSH protocol.
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 146 of 174
Component levelling
FCS_SSHS_EXT.1 SSH Server requires that the server side of SSH be implemented as
specified.
Management: FCS_SSHS_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_SSHS_EXT.1
The following actions should be considered for audit if FAU_GEN Security audit data
generation is included in the PP/ST:
a) Failure of SSH session establishment
b) SSH session establishment
c) SSH session termination
FCS_SSHS_EXT.1 SSH Server Protocol
Hierarchical to: No other components
Dependencies: FCS_CKM.1Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol in accordance with: RFCs
4251, 4252, 4253, 4254, [selection: 4256, 4344, 5647, 5656, 6187,6668, 8268, 8308 section
3.1, 8332].
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports
the following authentication methods as described in RFC 4252: public key-based, [selection:
password-based,no othermethod].
FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater
than [assignment: number of bytes] bytes in an SSH transport connection are dropped.
FCS_SSHS_EXT SSH ServerProtocol 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 147 of 174
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the
following encryption algorithms and rejects all other encryption algorithms: [assignment:
encryption algorithms].
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses [selection: ssh-rsa, rsa-sha2-256,rsa-sha2-512, ecdsa-sha2-nistp256,
x509v3-ssh-rsa,ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, x509v3-ecdsa-sha2-nistp256,
x509v3-ecdsa-sha2-nistp384, x509v3-ecdsa-sha2-nistp521, x509v3-rsa2048-sha256] as its
public key algorithm(s) and rejects all other public key algorithms.
FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses
[assignment: list of MAC algorithms] as its MAC algorithm(s) and rejects all other MAC
algorithm(s).
FCS_SSHS_EXT.1.7 The TSF shall ensure that [assignment: list of key exchange methods]
are the only allowed key exchange methods used for the SSH protocol.
FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections, the same session
keys are used for a threshold of no longer than one hour, and each encryption key is used to
protect no more than one gigabyte of data. After any of the thresholds are reached, a rekey
needs to be performed.
C.2.2.8 FCS_TLSC_EXT TLS Client Protocol
Family Behaviour
The component in this family addresses the ability for a client to use TLS to protect data
between the client and a server using the TLS protocol.
Component levelling
FCS_TLSC_EXT.1 TLS Client requires that the client side of TLS be implemented as
specified.
FCS_TLSC_EXT.2 TLS Client requires that the client side of the TLS implementation include
mutual authentication.
Management: FCS_TLSC_EXT.1, FCS_TLSC_EXT.2
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_TLSC_EXT.1, FCS_TLSC_EXT.2
FCS_TLSC_EXT TLS Client Protocol
1
2
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 148 of 174
The following actions should be considered for audit if FAU_GEN Security audit data
generation is included in the PP/ST:
a) Failure of TLS session establishment
b) TLS session establishment
c) TLS session termination
FCS_TLSC_EXT.1 TLS Client Protocol without Mutual Authentication
Hierarchical to: No other components
Dependencies: FCS_CKM. 1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FCS_TLSC_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1
(RFC 4346)] and reject all other TLS and SSL versions. The TLS implementation will support
the following ciphersuites:
● [assignment: list of optional ciphersuites and reference to RFC in which each is
defined] and no other ciphersuites.
FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches [selection: the
reference identifier per RFC 6125 section 6, IPv4 address in CN or SAN, IPv6 address in the
CN or SAN, IPv4 address in SAN, IPv6 address in the SAN, the identifier per RFC 5280
Appendix A using [selection: id-at-commonName, id-at-countryName, id-at-dnQualifier, id-
at-generationQualifier, id-at-givenName, id-at-initials, id-at-localityName, id-at-name, id-at-
organizationalUnitName, id-at-organizationName, id-at-pseudonym, id-at-serialNumber, id-
at-stateOrProvinceName, id-at-surname, id-at-title] and no other attribute types].
FCS_TLSC_EXT.1.3 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the server certificate is invalid. The TSF shall also [selection:
• Not implement any administrator override mechanism
• require administrator authorization to establish the connection if the TSF fails to
[selection: match the reference identifier, validate certificate path,validate expiration
date, determine the revocation status] of the presented server certificate
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 149 of 174
].
FCS_TLSC_EXT.1.4 The TSF shall [selection: not present the Supported Elliptic
Curves/Supported Groups Extension, present the Supported Elliptic Curves/Supported Groups
Extension with the following curves/groups: [selection: secp256r1, secp384r1, secp521r1,
ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] and no other curves/groups] in the
Client Hello.
FCS_TLSC_EXT.2 TLS Client Support for Mutual Authentication
Hierarchical to: No other components
Dependencies: FCS_CKM.1Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_TLSC_EXT.1 TLS Client Protocol without mutual
authentication
FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FCS_TLSC_EXT.2.1 The TSF shall support TLS communication with mutual authentication
using X.509v3 certificates.
C.2.2.9 FCS_TLSS_EXT TLS Server Protocol
Family Behaviour
The component in this family addresses the ability for a server to use TLS to protect data
between a client and the server using the TLS protocol.
Component levelling
FCS_TLSS_EXT.1 TLS Server requires that the server side of TLS be implemented as
specified.
FCS_TLSS_EXT TLS ServerProtocol
1
2
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 150 of 174
FCS_TLSS_EXT.2: TLS Server requires the mutual authentication be included in the TLS
implementation.
Management: FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
The following actions should be considered for audit if FAU_GEN Security audit data
generation is included in the PP/ST:
a) Failure of TLS session establishment
b) TLS session establishment
c) TLS session termination
FCS_TLSS_EXT.1 TLS Server Protocol without Mutual Authentication
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FCS_TLSS_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246),TLS 1.1 (RFC
4346)] and reject all other TLS and SSL versions. The TLS implementation will support the
following ciphersuites:
● [assignment: list of optional ciphersuites and reference to RFC in which each is
defined] and no other ciphersuites.
FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL
3.0, TLS 1.0 and [selection: TLS 1.1, TLS 1.2, none].
FCS_TLSS_EXT.1.3 The TSF shall perform key establishment for TLS using [selection: RSA
with key size [selection: 2048 bits, 3072 bits, 4096 bits], Diffie-Hellman parameters with size
[selection: 2048 bits, 3072 bits, 4096 bits, 6144 bits, 8192 bits], Diffie-Hellman groups
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 151 of 174
[selection: ffdhe2048, ffdhe3072, ffdhe4096,ffdhe6144, ffdhe8192, no other groups],ECDHE
curves [selection: secp256r1,secp384r1,secp521r1]and no other curves]].
FCS_TLSS_EXT.1.4 The TSF shall support [selection: no session resumption or session
tickets,session resumption based on session IDsaccording to RFC 4346 (TLS1.1) or RFC 5246
(TLS1.2), session resumption based on session tickets according to RFC 5077].
FCS_TLSS_EXT.2 TLS Server Support for Mutual Authentication
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Establishment
FCS_COP.1/DataEncryption Cryptographic operation (AES
Data encryption/decryption)
FCS_COP.1/SigGen Cryptographic operation (Signature
Generation and Verification)
FCS_COP.1/Hash Cryptographic operation (Hash Algorithm)
FCS_COP.1/KeyedHash Cryptographic operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_TLSS_EXT.1 TLS Server Protocol without mutual
authentication
FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.2 X.509 Certificate Authentication
FCS_TLSS_EXT.2.1 The TSF shall support TLS communication with mutual authentication
of TLS clients using X.509v3 certificates.
FCS_TLSS_EXT.2.2 When establishing a trusted channel, by default the TSF shall not
establish a trusted channel if the client certificate is invalid. The TSF shall also [selection:
• Not implement any administrator override mechanism
• require administrator authorization to establish the connection if the TSF fails to
[selection: match the reference identifier,validate certificate path, validate expiration
date, determine the revocation status] of the presented client certificate
].
FCS_TLSS_EXT.2.3 The TSF shall not establish a trusted channel if the identifier contained
in a certificate does not match an expected identifier for the client. If the identifier is a Fully
Qualified Domain Name (FQDN), then the TSF shall match the identifiers according to RFC
6125, otherwise the TSF shall parse the identifier from the certificate and match the identifier
against the expected identifier of the client as described in the TSS.
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 152 of 174
C.3 Identification and Authentication (FIA)
C.3.1 Password Management (FIA_PMG_EXT)
Family Behaviour
The TOE defines the attributes of passwords used by administrative users to ensure that strong
passwords and passphrases can be chosen and maintained.
Component levelling
FIA_PMG_EXT.1 Password management requires the TSF to support passwords with varying
composition requirements, minimum lengths, maximum lifetime, and similarity constraints.
Management: FIA_PMG_EXT.1
No management functions.
Audit: FIA_PMG_EXT.1
No specific audit requirements.
C.3.1.1 FIA_PMG_EXT.1 Password Management
FIA_PMG_EXT.1 Password Management
Hierarchical to: No other components.
Dependencies: No other components.
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: [selection: “!”, “@”, “#”, “$”,
“%”, “^”, “&”, “*”, “(“, “)”, [assignment: other characters]];
b) Minimum password length shall be configurable to between [assignment: minimum
number of characters supported by the TOE] and [assignment: number of characters
greater than or equal to 15] characters.
C.3.2 User Identification and Authentication (FIA_UIA_EXT)
Family Behaviour
The TSF allows certain specified actions before the non-TOE entity goes through the
identification and authentication process.
FIA_PMG_EXT PasswordManagement 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 153 of 174
Component levelling
FIA_UIA_EXT.1 User Identification and Authentication requires Administrators (including
remote Administrators) to be identified and authenticated by the TOE, providing assurance for
that end of the communication path. It also ensures that every user is identified and
authenticated before the TOE performs any mediated functions
Management: FIA_UIA_EXT.1
The following actions could be considered for the management functions in FMT:
a) Ability to configure the list of TOE services available before an entity is identified and
authenticated
Audit: FIA_UIA_EXT.N
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) All use of the identification and authentication mechanism
b) Provided user identity, origin of the attempt (e.g. IP address)
C.3.2.1 FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1 User Identification and Authentication
Hierarchical to: No other components.
Dependencies: FTA_TAB.1 Default TOE Access Banners
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;
• [selection: no other actions, automated generation of cryptographic keys, [assignment:
list of services, actions performed by the TSF in response to non-TOE requests]].
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.
C.3.3 User authentication (FIA_UAU_EXT)
Family Behaviour
Provides for a locally based administrative user authentication mechanism
FIA_UIA_EXT UserIdentificationand Authentication 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 154 of 174
Component levelling
FIA_UAU_EXT.2 The password-based authentication mechanism provides administrative
users a locally based authentication mechanism.
Management: FIA_UAU_EXT.2
The following actions could be considered for the management functions in FMT:
a) None
Audit: FIA_UAU_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) Minimal: All use of the authentication mechanism
C.3.3.1 FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2 Password-based Authentication Mechanism
Hierarchical to: No other components.
Dependencies: No other components.
FIA_UAU_EXT.2.1 The TSF shall provide a local [selection: password-based, SSH public
key-based, certificate-based, [assignment: otherauthentication mechanism(s)]] authentication
mechanism to perform local administrative user authentication.
C.3.4 Authentication using X.509 certificates (FIA_X509_EXT)
Family Behaviour
This family defines the behaviour, management, and use of X.509 certificates for functions to
be performed by the TSF. Components in this family require validation of certificates
according to a specified set of rules, use of certificates for authentication for protocols and
integrity verification, and the generation of certificate requests.
FIA_UAU_EXT Password-based AuthenticationMechanism 2
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 155 of 174
Component levelling
FIA_X509_EXT.1 X509 Certificate Validation, requires the TSF to check and validate
certificates in accordance with the RFCs and rules specified in the component.
FIA_X509_EXT.2 X509 Certificate Authentication, requires the TSF to use certificates to
authenticate peers in protocols that support certificates, as well as for integrity verification and
potentially other functions that require certificates.
FIA_X509_EXT.3 X509 Certificate Requests, requires the TSF to be able to generate
Certificate Request Messages and validate responses.
Management: FIA_X509_EXT.1, FIA_X509_EXT.2, FIA_X509_EXT.3
The following actions could be considered for the management functions in FMT:
a) Remove imported X.509v3 certificates
b) Approve import and removal of X.509v3 certificates
c) Initiate certificate requests
Audit: FIA_X509_EXT.1, FIA_X509_EXT.2, FIA_X509_EXT.3
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) Minimal: No specific audit requirements are specified.
C.3.4.1 FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.1 X.509 Certificate Validation
Hierarchical to: No other components
Dependencies: FIA_X509_EXT.2 X.509 Certificate Authentication
FIA_X509_EXT.1.1 The TSF shall validate certificates in accordance with the following
rules:
• RFC 5280 certificate validation and certification path validation.
• The certification path must terminate with a trusted CA certificate designated as a trust
anchor.
FIA_X509_EXT X509 Certificate
1
2
3
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 156 of 174
• 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.
• The TSF shall validate the revocation status of the certificate using [selection: 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, no revocation method]
• The TSF shall validate the extendedKeyUsage field according to the following rules:
[assignment: rules that govern contents of the extendedKeyUsage field that need to be
verified].
FIA_X509_EXT.1.2 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.
C.3.4.2 FIA_X509_EXT.2 X509 Certificate Authentication
FIA_X509_EXT.2 X.509 Certificate Authentication
Hierarchical to: No other components
Dependencies: FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to
support authentication for [selection: DTLS, HTTPS, IPsec, TLS, SSH, [assignment: other
protocols], no protocols], and [selection: code signing for system software updates
[assignment: other uses], no additional uses].
FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of
a certificate, the TSF shall [selection: allow the Administrator to choose whether to accept the
certificate in these cases, accept the certificate, not accept the certificate].
C.3.4.3FIA_X509_EXT.3 X.509 Certificate Requests
FIA_X509_EXT.3 X.509 Certificate Requests
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FIA_X509_EXT.1 X.509 Certificate Validation
FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request as specified by RFC 2986
and be able to provide the following information in the request: public key and [selection:
device-specific information, Common Name, Organization, Organizational Unit, Country,
[assignment: other information]].
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 157 of 174
FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon
receiving the CA Certificate Response.
C.4 Protection of the TSF (FPT)
C.4.1 Protection of TSF Data (FPT_SKP_EXT)
Family Behaviour
Components in this family address the requirements for managing and protecting TSF data,
such as cryptographic keys. This is a new family modelled after the FPT_PTD Class.
Component levelling
FPT_SKP_EXT.1 Protection of TSF Data (for reading all symmetric keys), requires preventing
symmetric keys from being read by any user or subject. It is the only component of this family.
Management: FPT_SKP_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FPT_SKP_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) There are no auditable events foreseen.
C.4.1.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys)
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys)
Hierarchical to: No other components.
Dependencies: No other components.
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys,
and private keys.
FPT_SKP_EXT ProtectionofTSFData 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 158 of 174
C.4.2 Protection of Administrator Passwords (FPT_APW_EXT)
C.4.2.1 FPT_APW_EXT.1 Protection of Administrator Passwords
Family Behaviour
Components in this family ensure that the TSF will protect plaintext credential data such as
passwords from unauthorized disclosure.
Component levelling
FPT_APW_EXT.1 Protection of Administrator passwords requires that the TSF prevent
plaintext credential data from being read by any user or subject.
Management: FPT_APW_EXT.1
The following actions could be considered for the management functions in FMT:
a) No management functions.
Audit: FPT_APW_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) No audit necessary.
FPT_APW_EXT.1 Protection of Administrator Passwords
Hierarchical to: No other components
Dependencies: No other components.
FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-plaintext form.
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext administrative passwords.
C.4.3 TSF Self-Test (FPT_TST_EXT)
C.4.3.1 FPT_TST_EXT.1 TSF Testing
Family Behaviour
Components in this family address the requirements for self-testing the TSF for selected correct
operation.
FPT_APW_EXT Protection ofAdministratorPasswords 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 159 of 174
Component levelling
FPT_TST_EXT.1 TSF Self-Test requires a suite of self-tests to be run during initial start-up in
order to demonstrate correct operation of the TSF.
Management: FPT_TST_EXT.1
The following actions could be considered for the management functions in FMT:
a) No management functions.
Audit: FPT_TST_EXT.1
The following actions should be considered for audit if FAU_GEN Security audit data
generation is included in the PP/ST:
a) Indication that TSF self-test was completed
b) Failure of self-test
FPT_TST_EXT.1 TSF Testing
Hierarchical to: No other components.
Dependencies: No other components.
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [selection: during
initial start-up (on power on), periodically during normal operation, at the request of the
authorised user, at the conditions [assignment: conditions under which self-tests should
occur]] to demonstrate the correct operation of the TSF: [assignment: list of self-tests run by
the TSF].
C.4.4 Trusted Update (FPT_TUD_EXT)
Family Behaviour
Components in this family address the requirements for updating the TOE firmware and/or
software.
Component levelling
FPT_TUD_EXT.1 Trusted Update requires management tools be provided to update the TOE
firmware and software, including the ability to verify the updates prior to installation.
FPT_TST_EXT TSFSelf Test 1
FPT_TUD_EXT TrustedUpdate
1
2
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 160 of 174
FPT_TUD_EXT.2 Trusted update based on certificates applies when using certificates as part
of trusted update and requires that the update does not install if a certificate is invalid.
Management: FPT_TUD_EXT.1, FPT_TUD_EXT.2
The following actions could be considered for the management functions in FMT:
a) Ability to update the TOE and to verify the updates
b) Ability to update the TOE and to verify the updates using the digital signature
capability (FCS_COP.1/SigGen) and [selection: no other functions, [assignment:
other cryptographic functions (or other functions) used to support the update
capability]]
c) Ability to update the TOE, and to verify the updates using [selection: digital
signature, published hash,no othermechanism] capability prior to installing those
updates
Audit: FPT_TUD_EXT.1, FPT_TUD_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) Initiation of the update process.
b) Any failure to verify the integrity of the update
C.4.4.1 FPT_TUD_EXT.1 Trusted Update
FPT_TUD_EXT.1 Trusted Update
Hierarchical to: No other components
Dependencies: FCS_COP.1/SigGen Cryptographic operation (for
Cryptographic Signature and Verification), or
FCS_COP.1/Hash Cryptographic operation (for cryptographic
hashing)
FPT_TUD_EXT.1.1 The TSF shall provide [assignment: Administrators] the ability to query
the currently executing version of the TOE firmware/software and [selection: the most recently
installed version of the TOE firmware/software; no other TOE firmware/software version].
FPT_TUD_EXT.1.2 The TSF shall provide [assignment: Administrators] the ability to
manually initiate updates to TOE firmware/software and [selection: support automatic
checking for updates, support automatic updates, no otherupdate mechanism].
FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software
updates to the TOE using a [selection: X.509 certificate, digital signature, published hash]
prior to installing those updates.
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 161 of 174
C.4.4.2 FPT_TUD_EXT.2 Trusted Update Based on Certificates
FPT_TUD_EXT.2 Trusted Update Based on Certificates
Hierarchical to: No other components
Dependencies: FPT_TUD_EXT.1
FPT_TUD_EXT.2.1 The TSF shall check the validity of the code signing certificate before
installing each update.
FPT_TUD_EXT.2.2 If revocation information is not available for a certificate in the trust
chain that is not a trusted certificate designated as a trust anchor, the TSF shall [selection: not
install the update, allow the Administrator to choose whether to accept the certificate in these
cases].
FPT_TUD_EXT.2.3 If the certificate is deemed invalid because the certificate has expired,
the TSF shall [selection: allow the Administrator to choose whether to install the update in
these cases, not accept the certificate].
FPT_TUD_EXT.2.4 If the certificate is deemed invalid for reasons other than expiration or
revocation information being unavailable, the TSF shall not install the update.
C.4.5 Time stamps (FPT_STM_EXT)
Family Behaviour
Components in this family extend FPT_STM requirements by describing the source of time
used in timestamps.
Component levelling
FPT_STM_EXT.1 Reliable Time Stamps is hierarchic to FPT_STM.1: it requires that the TSF
provide reliable time stamps for TSF and identifies the source of the time used in those
timestamps.
Management: FPT_STM_EXT.1
The following actions could be considered for the management functions in FMT:
a) Management of the time
b) Administrator setting of the time.
Audit: FTA_SSL_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
FPT_STM_EXT Time Stamps 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 162 of 174
a) Discontinuous changes to the time.
C.4.5.1FPT_STM_EXT.1 Reliable Time Stamps
FPT_STM_EXT.1 Reliable Time Stamps
Hierarchical to: No other components
Dependencies: No other components.
FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use.
FPT_STM_EXT.1.2 The TSF shall [selection: allow the Security Administrator to set the
time, synchronise time with an NTP server].
C.5 TOE Access (FTA)
C.5.1 TSF-initiated Session Locking (FTA_SSL_EXT)
Family Behaviour
Components in this family address the requirements for TSF-initiated and user-initiated
locking, unlocking, and termination of interactive sessions.
The extended FTA_SSL_EXT family is based on the FTA_SSL family.
Component levelling
FTA_SSL_EXT.1 TSF-initiated session locking, requires system initiated locking of an
interactive session after a specified period of inactivity. It is the only component of this family.
Management: FTA_SSL_EXT.1
The following actions could be considered for the management functions in FMT:
c) Specification of the time of user inactivity after which lock-out occurs for an
individual user.
Audit: FTA_SSL_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
b) Any attempts at unlocking an interactive session.
FTA_SSL_EXT TSF-initiated sessionlocking 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 163 of 174
C.5.1.1 FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1 TSF-initiated Session Locking
Hierarchical to: No other components
Dependencies: FIA_UAU.1 Timing of authentication
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [selection:
• lock the session -disable any activity of the Administrator’sdata access/displaydevices
other than unlocking the session, and requiring that the Administrator re-authenticate
to the TSF prior to unlocking the session;
• terminate the session]
after a Security Administrator-specified time period of inactivity.
C.6 Communication (FCO)
C.6.1 Communication Partner Control (FCO_CPC_EXT)
Family Behaviour
This family is used to define high-level constraints on the ways that partner IT entities
communicate. For example, there may be constraints on when communication channels can be
used, how they are established, and links to SFRs expressing lower-level security properties of
the channels.
Component levelling
FCO_CPC_EXT.1 Component Registration Channel Definition, requires the TSF to support a
registration channel for joining together components of a distributed TOE, and to ensure that
the availability of this channel is under the control of an Administrator. It also requires
statement of the type of channel used (allowing specification of further lower-level security
requirements by reference to other SFRs).
Management: FCO_CPC_EXT.1
No separate management functions are required. Note that elements of the SFR already specify
certain constraints on communication in order to ensure that the process of forming a
distributed TOE is a controlled activity.
Audit: FCO_CPC_EXT.1
The following actions should be auditable if FCO_CPC_EXT.1 is included in the PP/ST:
FCO_CPC_EXT Communication PartnerControl 1
collaborative Protection Profile for Network Devices
v2.2e, 23-March-2020 Page 164 of 174
a) Enabling communications between a pair of components as in FCO_CPC_EXT.1.1
(including identities of the endpoints).
b) Disabling communications between a pair of components as in FCO_CPC_EXT.1.3
(including identity of the endpoint that is disabled).
If the required types of channel in FCO_CPC_EXT.1.2 are specified by using other SFRs then
the use of the registration channel may be sufficiently covered by the audit requirements on
those SFRs: otherwise a separate audit requirement to audit the use of the channel should be
identified for FCO_CPC_EXT.1.
C.6.1.1FCO_CPC_EXT.1 Component Registration Channel Definition
FCO_CPC_EXT.1 Component Registration Channel Definition
Hierarchical to: No other components.
Dependencies: No other components.
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.
FCO_CPC_EXT.1.2 The TSF shall implement a registration process in which components
establish and use a communications channel that uses [assignment: list of different types of
channel given in the form of a selection] for at least [assignment: type of data for which the
channel must be used].
FCO_CPC_EXT.1.3 The TSF shall enable a Security Administrator to disable
communications between any pair of TOE components.