© 2023 Cisco Systems, Inc. This document can be reproduced in full without any modifications.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and
2100 Series with FMC/FMCv
Security Target
ST Version 1.1
January 27, 2023
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC/FMCv Security Target
Page 2 of 133
Table of Contents
1 SECURITY TARGET INTRODUCTION .................................................................................10
1.1 ST and TOE Reference................................................................................................. 10
1.2 TOE Overview.............................................................................................................. 10
1.2.1 TOE Product Type ................................................................................................... 11
1.2.2 Supported non-TOE Hardware/ Software/ Firmware ........................................ 12
1.3 TOE DESCRIPTION ...................................................................................................... 12
1.4 TOE Evaluated Configuration..................................................................................... 18
1.5 Physical Scope of the TOE........................................................................................... 19
1.6 Logical Scope of the TOE............................................................................................. 20
1.6.1 Security Audit .......................................................................................................... 20
1.6.2 Communication ....................................................................................................... 21
1.6.3 Cryptographic Support ........................................................................................... 21
1.6.4 Full Residual Information Protection.................................................................... 21
1.6.5 Identification and authentication .......................................................................... 21
1.6.6 Security Management ............................................................................................. 21
1.6.7 Protection of the TSF............................................................................................... 22
1.6.8 TOE Access............................................................................................................... 22
1.6.9 Trusted path/Channels........................................................................................... 22
1.6.10 Filtering.................................................................................................................... 22
1.6.11 Intrusion Prevention System.................................................................................. 23
1.7 Excluded Functionality ............................................................................................... 23
2 Conformance Claims............................................................................................................25
2.1 Common Criteria Conformance Claim....................................................................... 25
2.2 Protection Profile Conformance................................................................................. 25
2.3 Protection Profile Conformance Claim Rationale..................................................... 27
2.3.1 TOE Appropriateness.............................................................................................. 27
2.3.2 TOE Security Problem Definition Consistency...................................................... 27
2.3.3 Statement of Security Requirements Consistency................................................ 27
3 SECURITY PROBLEM DEFINITION.....................................................................................29
3.1 Assumptions ................................................................................................................ 29
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 3 of 133
3.2 Threats ......................................................................................................................... 31
3.3 Organizational Security Policies ................................................................................ 36
4 SECURITY OBJECTIVES .......................................................................................................38
4.1 Security Objectives for the TOE ................................................................................. 38
4.2 Security Objectives for the Environment .................................................................. 41
5 SECURITY REQUIREMENTS................................................................................................43
5.1 Conventions ................................................................................................................. 43
5.2 TOE Security Functional Requirements .................................................................... 43
5.3 SFRs Drawn from NDcPP............................................................................................ 47
5.3.1 Security audit (FAU)................................................................................................ 47
5.3.2 Communication (FCO) ............................................................................................ 52
5.3.3 Cryptographic Support (FCS)................................................................................. 52
5.3.4 Identification and authentication (FIA)................................................................. 60
5.3.5 Security management (FMT).................................................................................. 62
5.3.6 Protection of the TSF (FPT).................................................................................... 64
5.3.7 TOE Access (FTA).................................................................................................... 65
5.3.8 Trusted Path/Channels (FTP)................................................................................ 65
5.4 SFRs Drawn from mod_ips_v1.0................................................................................. 66
5.4.1 Security Audit (FAU)............................................................................................... 66
5.4.2 Security Management (FMT).................................................................................. 69
5.4.3 Intrusion Prevention (IPS) ..................................................................................... 69
5.5 SFRs Drawn from mod_cpp_fw_v1.4e........................................................................ 73
5.5.1 User Data Protection (FDP).................................................................................... 73
5.5.2 Stateful Traffic Filtering (FFW).............................................................................. 73
5.5.3 Security Management (FMT).................................................................................. 75
5.6 SFRs from mod_vpngw_v1.1....................................................................................... 76
5.6.1 Cryptographic Support (FCS)................................................................................. 76
5.6.2 Identification and authentication (FIA)................................................................. 76
5.6.3 Security management (FMT).................................................................................. 76
5.6.4 Packet Filtering (FPF)............................................................................................. 77
5.6.5 Protection of the TSF (FPT).................................................................................... 78
5.6.6 TOE Access (FTA).................................................................................................... 78
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC/FMCv Security Target
Page 4 of 133
5.6.7 Trusted Path/Channels (FTP)................................................................................ 78
5.7 TOE SFR Dependencies Rationale for SFRs Found in NDcPP and PP-modules ..... 79
5.8 Security Assurance Requirements............................................................................. 79
5.8.1 SAR Requirements................................................................................................... 79
5.8.2 Security Assurance Requirements Rationale........................................................ 79
5.9 Assurance Measures.................................................................................................... 79
6 TOE Summary Specification ...............................................................................................81
6.1 TOE Security Functional Requirement Measures..................................................... 81
7 Supplemental TOE Summary Specification Information................................................116
7.1 Intrusion Rule Definition............................................................................................ 116
7.1.1 Intrusion Rule Header........................................................................................... 116
7.1.2 Intrusion Rule Options and Keywords ................................................................ 117
7.2 Tracking of Stateful Firewall Connections .............................................................. 118
7.2.1 Establishment and Maintenance of Stateful Connections.................................. 118
7.2.2 Viewing Connections and Connection States...................................................... 118
7.2.3 Examples................................................................................................................ 122
7.3 Key Zeroization.......................................................................................................... 124
7.4 CAVP Certificate Equivalence................................................................................... 126
8 Annex A: References..........................................................................................................130
9 Annex B: SFR TOE Components Mapping........................................................................131
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 5 of 133
List of Tables
TABLE 1: ACRONYMS .......................................................................................................................................................................................... 7
TABLE 2: ST AND TOE IDENTIFICATION .......................................................................................................................................................10
TABLE 3: IT ENVIRONMENT COMPONENTS...................................................................................................................................................12
TABLE 4: FP2100 SERIES HARDWARE .........................................................................................................................................................13
TABLE 5: FP1000 SERIES HARDWARE .........................................................................................................................................................14
TABLE 6: FMC MODELS....................................................................................................................................................................................15
TABLE 7: UCS HARDWARE...............................................................................................................................................................................16
TABLE 8: HARDWARE MODELS AND SPECIFICATIONS.................................................................................................................................19
TABLE 9: EXCLUDED FUNCTIONALITY...........................................................................................................................................................23
TABLE 10: PROTECTION PROFILES.................................................................................................................................................................25
TABLE 11: TECHNICAL DECISIONS..................................................................................................................................................................25
TABLE 12: TOE ASSUMPTIONS.......................................................................................................................................................................29
TABLE 13: THREATS..........................................................................................................................................................................................31
TABLE 14: ORGANIZATIONAL SECURITY POLICIES......................................................................................................................................36
TABLE 15: SECURITY OBJECTIVES FOR THE TOE.........................................................................................................................................38
TABLE 16: SECURITY OBJECTIVES FOR THE ENVIRONMENT ......................................................................................................................41
TABLE 17: SECURITY FUNCTIONAL REQUIREMENTS...................................................................................................................................43
TABLE 18: AUDITABLE EVENTS ......................................................................................................................................................................47
TABLE 19: AUDITABLE EVENTS ......................................................................................................................................................................67
TABLE 20: ASSURANCE MEASURES.................................................................................................................................................................79
TABLE 21: ASSURANCE MEASURES.................................................................................................................................................................79
TABLE 22: HOW TOE SFRS ARE SATISFIED ................................................................................................................................................81
TABLE 23: SYNTAX DESCRIPTION................................................................................................................................................................118
TABLE 24: CONNECTION STATE TYPES.......................................................................................................................................................120
TABLE 25: CONNECTION STATE FLAGS.......................................................................................................................................................120
TABLE 26: TCP CONNECTION DIRECTIONALITY FLAGS ............................................................................................................................122
TABLE 27: TOE KEY ZEROIZATION.............................................................................................................................................................124
TABLE 28: PROCESSORS, FOM AND CAVP CERT .....................................................................................................................................126
TABLE 29: ALGORITHM CERTIFICATE NUMBERS......................................................................................................................................128
TABLE 30: REFERENCES ................................................................................................................................................................................130
TABLE 31: SFR MAPPING .............................................................................................................................................................................131
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC/FMCv Security Target
Page 6 of 133
List of Figures
FIGURE 1: FP2100 SERIES HARDWARE (2110, 2120, 2130, 2140)..................................................................................................12
FIGURE 2: FP1000 SERIES HARDWARE (1010) ........................................................................................................................................13
FIGURE 3: FP1000 SERIES HARDWARE (1120, 1140)............................................................................................................................13
FIGURE 4: UCS HARDWARE .............................................................................................................................................................................16
FIGURE 5: EXAMPLE TOE DEPLOYMENT.......................................................................................................................................................18
FIGURE 6: AUDIT VIEW .....................................................................................................................................................................................81
FIGURE 7: SYSLOG VIEW ...................................................................................................................................................................................82
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 7 of 133
List of Acronyms
The following acronyms and abbreviations are common and may be used in this Security Target:
Table 1: Acronyms
Acronyms/Abbreviations Definition
ACL Access Control List
AES Advanced Encryption Standard
CC Common Criteria
CEM Common Evaluation Methodology
CM Configuration Management
DHCP Dynamic Host Configuration Protocol
EAL Evaluation Assurance Level
EHWIC Ethernet High-Speed WAN Interface Card
ESP Encapsulating Security Payload
FOM FIPS Object Module
FMC Firepower Management Center
FMCv Firepower Management Center Virtual
FTD Firepower Threat Defense
cpp_nd_v2.2e Collaborative Protection Profile for Network Devices v2.2e
mod_cpp_fw_v1.4e PP-Module for Stateful Traffic Filter Firewalls v1.4e
mod_ips_v1.0 PP-Module for Intrusion Protection Systems (IPS) v1.0
mod_vpngw_v1.1 PP-Module for Virtual Private Network (VPN) Gateways
v1.1
Gbps Gigabits per second
GE Gigabit Ethernet port
HTTPS Hyper-Text Transport Protocol Secure
ICMP Internet Control Message Protocol
IKE Internet Key Exchange
IPS Intrusion Prevention System
IPsec Internet Protocol Security
IT Information Technology
NDcPP Network Device Collaborative Protection Profile
NGFW Cisco Next-Generation Firewall
NGIPS Cisco Next-Generation IPS
OE Operational Environment
OS Operating System
PoE Power over Ethernet
POP3 Post Office Protocol
PP Protection Profile
REST Representational State Transfer
SA Security Association
SFP Small–form-factor pluggable port
SHA Secure Hash Algorithm
SIP Session Initiation Protocol
SSHv2 Secure Shell (version 2)
SSM Security Services Module
SSP Security Services Processor
ST Security Target
TCP Transport Control Protocol
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC/FMCv Security Target
Page 8 of 133
Acronyms/Abbreviations Definition
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Function
TSP TOE Security Policy
UDP User Datagram Protocol
VLAN Virtual Local Area Network
VPN Virtual Private Network
VS Virtualization System
WAN Wide Area Network
WIC WAN Interface Card
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 9 of 133
DOCUMENT INTRODUCTION
Prepared By:
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
This document provides the basis for an evaluation of a specific Target of Evaluation (TOE), the
Firepower Threat Defense (FTD) with Firepower Management Center (FMC). This Security Target
(ST) defines a set of assumptions about the aspects of the environment, a list of threats that the
product intends to counter, a set of security objectives, a set of security requirements, and the IT
security functions provided by the TOE which meet the set of requirements. Administrators of the
TOE will be referred to as administrators, authorized administrators, TOE administrators, semi-
privileged, privileged administrators, and security administrators in this document.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC/FMCv Security Target
Page 10 of 133
1 SECURITY TARGET INTRODUCTION
The Security Target contains the following sections:
 Security Target Introduction [Section 1]
 Conformance Claims [Section 2]
 Security Problem Definition [Section 3]
 Security Objectives [Section 4]
 IT Security Requirements [Section 5]
 TOE Summary Specification [Section 6]
 Supplemental TOE Summary Specification Information [Section 7]
 References [Section 8]
The structure and content of this ST comply with the requirements specified in the Common
Criteria (CC), Part 1, Annex A, and Part 2.
1.1 ST and TOE Reference
This section provides information needed to identify and control this ST and its TOE.
Table 2: ST and TOE Identification
Name Description
ST Title Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC/FMCv
Security Target
ST Version 1.1
Publication Date January 27, 2023
Vendor and ST Author Cisco Systems, Inc.
TOE Reference Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv
TOE Hardware Models • Firepower 1000 Series (1010, 1120, 1140, 1150)
• Firepower 2100 Series (2110, 2120, 2130, 2140)
• Cisco Firepower Management Center (FMC) (FMC1000-K9, FMC2500-K9,
FMC4500-K9, FMC1600-K9, FMC2600-K9 and FMC4600-K9)
• FMCv running on ESXi 6.7 or 7.0 on the Unified Computing System (UCS)
UCSC-C220-M5, UCSC-C240-M5, UCSC-C480-M5, UCS-E160S-M3 and UCS-
E180D-M3
TOE Software Version FTD 7.0 and FMC/FMCv 7.0
Keywords Firewall, VPN Gateway, Router
1.2 TOE Overview
The Cisco Firepower 1000 series and 2100 series are purpose-built, firewall platforms with VPN
capabilities and Intrusion Prevention capabilities provided by Firepower Threat Defense (FTD)
software. The Firepower Management Center (FMC) physical and virtual appliances provide a
centralized management console and event database for the FTD, and aggregates and correlates
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 11 of 133
intrusion, discovery, and connection data from the FTD. In this deployment, the FTD provides VPN,
firewall filtering, network analysis, intrusion detection and access control functionalities. The TOE
includes one or more FTD appliances that are centrally managed by a Firepower Management
Center (FMC) appliance, and together the FMC and FTD appliances form the TOE (Distributed TOE
Use Case 3). The TOE includes the hardware models as defined in Table 2 of section 1.1.
1.2.1 TOE Product Type
The TOE consists of hardware and software that provide connectivity and security services onto
multiple secure devices.
For firewall service, the TOE provides application-aware stateful packet filtering firewalls. A
stateful packet filtering firewall controls the flow of IP traffic by matching information contained in
the headers of connection-oriented or connection-less IP packets against a set of rules specified by
the authorized administrator for firewalls. This header information includes source and destination
host (IP) addresses, source and destination port numbers, and the transport service application
protocol (TSAP) held within the data field of the IP packet. Depending upon the rule and the results
of the match, the firewall either passes or drops the packet. The stateful firewall remembers the
state of the connection from information gleaned from prior packets flowing on the connection and
uses it to regulate current packets. The packet will be denied if the security policy is violated.
In addition to IP header information, the TOE mediates information flows on the basis of other
information, such as the direction (incoming or outgoing) of the packet on any given firewall
network interface. For connection-oriented transport services, the firewall either permits
connections and subsequent packets for the connection or denies the connection and subsequent
packets associated with the connection.
The application-inspection capabilities automate the network to treat traffic according to detailed
policies based not only on port, state, and addressing information, but also on application
information buried deep within the packet header. By comparing this deep-packet inspection
information with corporate policies, the firewall will allow or block certain traffic. For example, it
will automatically drop application traffic attempting to gain entry to the network through an open
port-even if it appears to be legitimate at the user and connection levels-if a business's corporate
policy prohibits that application type from being on the network.
The TOE provides intrusion prevention system (IPS) capabilities by combining the security of a
Next Generation IPS (NGIPS) with the power of access control, malware protection, and URL/IP
filtering (white/black listing) known as Security Intelligence. The TOE monitors incoming and
outgoing network traffic and performs real-time traffic analysis and logging using the industry-
leading Snort® engine. All packets on the monitored network are scanned, decoded, preprocessed
and compared against a set of rules to determine whether inappropriate traffic, such as system
attacks, is being sent over the network. The system generates alerts or blocks the traffic when
deviations of the expected network behavior are detected or when there is a match to a known
attack pattern.
The TOE also provides IPsec connection capabilities. All references within this ST to “VPN”
connectivity refer to the use of IPsec tunnels to secure connectivity to and/or from the TOE, for
example, gateway-to-gateway1 VPN or remote access VPN.
1
This is also known as site-to-site or peer-to-peer VPN.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC/FMCv Security Target
Page 12 of 133
1.2.2 Supported non-TOE Hardware/ Software/ Firmware
The TOE supports the following hardware, software, and firmware in its environment when the
TOE is configured in its evaluated configuration:
Table 3: IT Environment Components
Component Required Usage/Purpose Description for TOE performance
Management
Workstation with
SSH Client
Yes This includes any IT Environment Management workstation with SSH
client installed that is used by the TOE administrator to support TOE
administration through SSHv2 protected channels. Any SSH client that
supports SSHv2 may be used.
Management
Workstation with
Web Browser
Yes This includes any IT Environment Management workstation with a
web browser installed that is used by the TOE administrator to
support TOE administration through TLS/HTTPS protected channels.
Any browser that supports TLSv1.2 may be used.
Audit (syslog)
Server
Yes This includes any syslog server to which the TOE would transmit
syslog messages. Connections to remote audit servers must be
tunneled in IPsec or TLS.
Certification
Authority
Yes This includes any IT Environment Certification Authority on the TOE
network. This can be used to provide the TOE with a valid certificate
during certificate enrollment.
Remote Tunnel
Endpoint
Yes This includes any peer with which the TOE participates in tunneled
communications. Remote tunnel endpoints may be any device or
software client (e.g., Cisco AnyConnect client) that supports IPsec
tunneling. Both VPN clients and VPN gateways can be considered to be
remote tunnel endpoints.
1.3 TOE DESCRIPTION
This section provides an overview and description of the TOE. The TOE is comprised of both
software and hardware. The TOE appliances are comprised of the following: Firepower 1000 Series
(1010, 1120, 1140, 1150), Firepower 2100 Series (2110, 2120, 2130, 2140) and Firepower
Management Center (FMC) (FMC1000-K9, FMC2500-K9, FMC4500-K9, FMC1600-K9, FMC2600-K9,
FMC4600-K9 and FMCv). The software is comprised of the FTD software image Release 7.0 and
FMC (or FMCv) version 7.0.
The models that comprise the TOE have common hardware characteristics. These differing
characteristics affect only non-TSF relevant functionality (such as throughput, processing speed,
number and type of network connections supported, number of concurrent connections supported,
and amount of storage) and therefore support security equivalency of the FTDs in terms of
hardware.
Figure 1: FP2100 Series Hardware (2110, 2120, 2130, 2140)
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 13 of 133
The FP2100 models have the following distinct characteristics:
Table 4: FP2100 Series Hardware
Model FP2110 FP2120 FP2130 FP2140
Number of
Processors
1 1 1 1
Processor(s) Intel Xeon D-1526
(Broadwell)
Intel Xeon D-1528
(Broadwell)
Intel Xeon D-1548
(Broadwell)
Intel Xeon D-1577
(Broadwell)
OCTEON III CN7230
MIPS64
OCTEON III CN7340
MIPS64
OCTEON III
CN7350 MIPS64
OCTEON III
CN7360 MIPS64
Storage 100 GB 100 GB 200 GB 200 GB
Integrated I/O 12 x
10M/100M/1GBASE-
T Ethernet interfaces
(RJ-45), 4 x 1 Gigabit
(SFP) Ethernet
interfaces
12 x
10M/100M/1GBASE-
T Ethernet interfaces
(RJ-45), 4 x 1 Gigabit
(SFP) Ethernet
interfaces
12 x 10M/100M/1GBASE-T Ethernet
interfaces (RJ-45), 4 x 10 Gigabit (SFP+)
Ethernet interfaces
IPsec VPN
Throughput
750 Mbps 1000 Mbps 1500 Mbps 3000 Mbps
Maximum
concurrent
sessions
1 million 1.2 million 2 million 3.0 million
Maximum VPN
Peers
1500 3500 7500 10000
Figure 2: FP1000 Series Hardware (1010)
Figure 3: FP1000 Series Hardware (1120, 1140)
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC/FMCv Security Target
Page 14 of 133
The FP1000 models have the following distinct characteristics:
Table 5: FP1000 Series Hardware
Model FP1010 FP1120 FP1140 FP1150
Number of
Processors
1 1 1 1
Processor(s) Intel Atom C3558
(Goldmont)
Intel Atom C3858
(Goldmont)
Intel Atom C3958
(Goldmont)
Intel Atom C3958
(Goldmont)
Storage 1 x 200 GB 1 x 200 GB 1 x 200 GB 1 x 200 GB
Integrated I/O 8 x RJ45, 4x SFP 8 x RJ45, 4x SFP 8 x RJ45, 4x SFP 8 x RJ-45, 2 x 1Gbps
SFP, 2 x 1/10Gbps
SFP+
IPsec VPN
Throughput
300 Mbps 1 Gbps 1.2 Gbps 1.7 Gbps
Maximum
concurrent
sessions
100K 200K 400K 600K
Maximum VPN
Peers
75 150 400 800
© 2023 Cisco Systems, Inc. This document can be reproduced in full without any modifications.
The FMC hardware components in the TOE have the following distinct characteristics:
Table 6: FMC Models
Model FMC1000-K9 FMC1600-K9 FMC2500-K9 FMC2600-K9 FMC4500-K9 FMC4600-K9
Processor Intel Xeon E5-
2640 v4
(Broadwell)
Intel Xeon Silver
4110 (Skylake)
Intel Xeon E5-2640
v4 (Broadwell)
Intel Xeon Silver
4110 (Skylake)
Intel Xeon E5-2620
v4 (Broadwell)
Intel Xeon Silver
4116 (Skylake)
Memory 32 GB 32 GB 64 GB 64 GB 128 GB 128 GB
Maximum
Number of
FTD devices
Managed
50 50 300 300 750 750
Event
Storage
900 GB
900 GB 1.8 TB 1.8 TB 3.2 TB 3.2 TB
Maximum
Flow Rate
6,000 fps
6,000 fps 10,000 fps 10,000 fps 20,000 fps 20,000 fps
Maximum
Network Map
(hosts/users)
50,000/50,000
50,000/50,000 300,000/300,000 300,000/300,000 600,000/600,000 600,000/600,000
Network
Interfaces
2 x 1Gbps
2 x 1Gbps 2 x 1Gbps 2 x 1Gbps 2 x 1Gbps
2 x 10Gbps
2 x 1Gbps
2 x 10Gbps
The underlying Cisco UCS hardware platforms within the TOE have common hardware characteristics. These differing characteristics
affect only non-TSF relevant functionality (such as throughput, processing speed, number and type of network connections supported,
number of concurrent connections supported, and amount of storage) and therefore support security equivalency of the FMCv in terms of
hardware.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC/FMCv Security Target
Page 16 of 133
Figure 4: UCS Hardware
The UCS hardware components, which provide the platform for the FMCv, in the TOE have the following distinct characteristics:
Table 7: UCS Hardware
Model C220 M5 C240 M5 C480-M5
Number of
Processors
2 2 2-4
Processor Intel® Xeon® Bronze 3104 (Skylake),
Intel® Xeon® Silver 4110 (Skylake)
Intel® Xeon® Gold 6128 (Skylake)
Intel® Xeon® Platinum 8153 (Skylake)
Intel® Xeon® Bronze 3104
(Skylake),
Intel® Xeon® Silver 4110
(Skylake)
Intel® Xeon® Gold 6128 (Skylake)
Intel® Xeon® Platinum 8153
(Skylake)
Intel® Xeon® Bronze 3104 (Skylake),
Intel® Xeon® Silver 4110 (Skylake)
Intel® Xeon® Gold 6128 (Skylake)
Intel® Xeon® Platinum 8153
(Skylake)
Form factor 1RU rack server 2 RU 4 RU
Maximum Memory 3 TB, 24 x DDR4 DIMMs 3 TB, 24 x DDR4 DIMMs 12 TB, 256 x DDR4 DIMMs
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 17 of 133
Embedded Network
Interface Cards
(NICs)
Dual 10GBASE-T Intel x550 Ethernet
ports
Dual 10GBASE-T Intel x550
Ethernet ports
Dual 10GBASE-T Intel x550 Ethernet
ports
Model E160S M3 E180D M2/K9
Number of
Processors
1 1
Processor Intel® Xeon® D-1528 (Broadwell) Intel® Xeon® D-1548 (Broadwell)
Form factor 1 RU 2 RU
Memory 8 – 64 GB 16 – 128 GB
Disk Space 4 TB 4 TB
I/O ● 2 internal Gigabit Ethernet ports (Broadcom 5719)
● 2 external 10 Gigabit Ethernet ports (1000/10000)
(Integrated within Intel Xeon-D CPU)
● 2 internal Gigabit Ethernet ports (Broadcom 5719)
● 2 external 10 Gigabit Ethernet ports (1000/10000) (Integrated
within Intel CPU)
● 1 dedicated management Ethernet port (10/100/1000) for Cisco
IMC
Page 18 of 133
1.4 TOE Evaluated Configuration
The TOE consists of at least one Firepower device (Firepower 1000/2100 series) running the FTD
software and one or more physical FMC devices running the FMC software or virtual devices
running FMCv software as specified in Section 1.5 below. Each instantiation of the TOE has two or
more network interfaces and is able to filter IP traffic to and through those interfaces.
If the TOE is to be remotely administered, the management station must connect using SSHv2.
When the WebUI is used, a remote workstation with a TLS-enabled browser must be available. A
syslog server can also be used to store audit records, and the syslog server must support syslog
over TLS or IPsec.
FTD supports two different TLS clients that send syslog messages to the external syslog server- FTD
TLS client and FTD OS TLS Client. The FTD TLS Client is configured by the FMC and is the main
audit system for audits generated by FTD. It sends audit events such as IPsec and login messages to
the external syslog server. The FTD OS TLS client implementation is configured through the FTD’s
command line and sends audit events such as SSH login, console login, etc. to an external syslog
server.
The TOE is able to filter connections to/from these external using its IP traffic filtering, and can
encrypt traffic where necessary using TLS, SSH, and/or IPsec. The TOE uses X.509v3 certificates to
support authentication for both IPsec and TLS, and the CA server in the Operational environment
can be used to obtain digital certificates.
The communication between the FMC software and the FTD in the Firepower appliance is
protected by TLSv1.2. Digital certificates from a CA server are obtained when certificates are used
as the authentication method for VPN connection. The TOE protects peer-to-peer VPN connections
between itself and VPN peers (connections can be initiated by the TOE or by the peer) using IPsec.
The following figure provides a visual depiction of an example TOE deployment. The TOE boundary
is surrounded with a hashed red line.
Figure 5: Example TOE Deployment
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 19 of 133
The figure includes the following:
TOE components (at least one Firepower 2K/1K appliance running FTD v7.0 and FMC/FMCv device
running FMC v7.0/FMCv 7.0)
VPN Peer (Operational Environment) or another instance of the TOE
VPN Client (Operational Environment) with Cisco AnyConnect Client
Management Workstation (Operational Environment)
CA Server(Operational Environment)
Syslog server (Operational Environment)
1.5 Physical Scope of the TOE
The TOE is a hardware and software solution comprised of the components described in Table 8:
Table 8: Hardware Models and Specifications
TOE Configuration Hardware Configurations Software Version
FP2110
FP2120
FP2130
FP2140
The Cisco FP2100 provides high-
performance firewall and VPN services
and 4-12 Gigabit Ethernet interfaces, and
support for up to 10,000 VPNs.
FTD v7.0
Page 20 of 133
FP1010
FP1120
FP1140
FP1150
The Cisco FP1000 provides high-
performance firewall and VPN services
and support for up to 400 VPNs.
FTD v7.0
FMC1000-K9
FMC2500-K9
FMC4500-K9
FMC1600-K9
FMC2600-K9
FMC4600-K9
See table above FMC v7.0
FMCv FMCv running on ESXi 6.7 or 7.0 on the
Unified Computing System (UCS) UCSC-
C220-M5, UCSC-C240-M5, UCSC-C480-
M5, UCS-E160S-M3 and UCS-E180D-M3
FMCv v7.0
1.6 Logical Scope of the TOE
The TOE is comprised of several security features including stateful traffic firewall, VPN gateway
and IPS capabilities. Each of the security features identified above consists of several security
functionalities, as identified below.
1. Security Audit
2. Communication
3. Cryptographic Support
4. Full Residual Information Protection
5. Identification and Authentication
6. Security Management
7. Protection of the TSF
8. TOE Access
9. Trusted Path/Channels
10. Filtering
11. Intrusion Prevention System
These features are described in more detail in the subsections below.
1.6.1 Security Audit
The TOE provides extensive auditing capabilities. The TOE can audit events related to
cryptographic functionality, identification and authentication, and administrative actions. The TOE
generates an audit record for each auditable event. The administrator configures auditable events,
performs back-up operations, and manages audit data storage. The TOE provides the administrator
with a circular audit trail where the TOE overwrites the oldest audit record with the newest audit
record when space is full. Audit logs are backed up over an encrypted channel to an external audit
server.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 21 of 133
1.6.2 Communication
The TOE allows authorized administrators to control which FTD device is managed by the FMC.
This is performed through a registration process over TLS. The administrator can also de-register a
FTD device if he or she wish to no longer manage it through the FMC.
1.6.3 Cryptographic Support
The TOE provides cryptography in support of other TOE security functionality. The TOE provides
cryptography in support of secure connections using IPsec and TLS, and remote administrative
management via SSHv2 and TLS/HTTPS. The cryptographic random bit generators (RBGs) are
seeded by an entropy noise source.
1.6.4 Full Residual Information Protection
The TOE ensures that all information flows from the TOE do not contain residual information from
previous traffic. Packets are padded with zeros. Residual data is never transmitted from the TOE.
1.6.5 Identification and authentication
The TOE performs two types of authentication: device-level authentication of the remote device
(VPN peers) and user authentication for the authorized administrator of the TOE or for IPsec VPN
clients. Device-level authentication allows the TOE to establish a secure channel with a trusted
peer. The secure channel is established only after each device authenticates the other. Device-level
authentication is performed via IKE/IPsec X509v3 certificate based authentication or pre-shared
key methods while user-level authentication from IPsec VPN clients uses certificate-based
authentication (all IPsec VPN sessions are terminated at the FTD, not the FMC/FMCv).
The TOE provides authentication services for administrative users wishing to connect to the TOEs
secure CLI and GUI administrator interfaces. The TOE requires authorized administrators to
authenticate prior to being granted access to any of the management functionality. The TOE can be
configured to require a minimum password length of 15 characters as well as mandatory password
complexity rules. The TOE also implements a lockout mechanism when the number of unsuccessful
authentication attempts exceeds the configured threshold.
The TOE provides administrator authentication against a local user database. Password-based
authentication can be performed on the serial console or SSH and HTTPS interfaces. The SSHv2
interface also supports authentication using SSH keys.
1.6.6 Security Management
The TOE provides secure administrative services for management of general TOE configuration and
the security functionality provided by the TOE. All TOE administration occurs either through a
secure SSHv2 or TLS/HTTPS session, or via a local console connection. Optionally, the FTD
component also supports tunneling the SSH connections in IPsec VPN tunnels (peer-to-peer, or
remote VPN client). Management of all security functions can be performed via the FMC/FMCv
component of the TOE, while a subset of management functions can be performed on the FTD
component. The TOE provides the ability to securely manage all TOE administrative users; all
identification and authentication; all audit functionality of the TOE; all TOE cryptographic
functionality; the timestamps maintained by the TOE; and the information flow control policies
Page 22 of 133
enforced by the TOE including encryption/decryption of information flows for VPNs. The TOE
supports an “authorized administrator” role, which equates to any account authenticated to an
administrative interface (CLI or GUI, but not VPN), and possessing sufficient privileges to perform
security-relevant administrative actions.
When an administrative session is initially established, the TOE displays an administrator-
configurable warning banner. This is used to provide any information deemed necessary by the
administrator. After a configurable period of inactivity, administrative sessions will be terminated,
requiring administrators to re-authenticate.
1.6.7 Protection of the TSF
The TOE protects against interference and tampering by untrusted subjects by implementing
identification, authentication, and administrator roles to limit configuration to authorized
administrators. The TOE prevents reading of cryptographic keys and passwords.
Additionally, the TOE is not a general-purpose operating system and access to the TOE memory
space is restricted to only TOE functions.
The TOE internally maintains the date and time. This date and time is used as the timestamp that is
applied to audit records generated by the TOE. Administrators can update the TOE’s clock
manually via FMC. Additionally, the TOE performs testing to verify correct operation of the
appliance itself and that of the cryptographic module. Whenever any system failures occur within
the TOE the TOE will cease operation.
1.6.8 TOE Access
When an administrative session is initially established, the TOE displays an administrator-
configurable warning banner. This is used to provide any information deemed necessary by the
administrator. After a configurable period of inactivity, administrator and VPN client sessions will
be terminated, requiring re-authentication. The TOE also supports direct connections from VPN
clients, and protects against threats related to those client connections. The TOE disconnects
sessions that have been idle too long, and can be configured to deny sessions based on IP, time, and
day, and to NAT external IPs of connecting VPN clients to internal network addresses.
1.6.9 Trusted path/Channels
The TOE supports establishing trusted paths between itself and remote administrators using SSHv2
for CLI access on the FTD and FMC and TLS/HTTPS for web UI access on the FMC. The TOE
supports use of TLS and/or IPsec for connections with remote syslog servers. The TOE can
establish trusted paths of peer-to-peer VPN tunnels using IPsec, and VPN client tunnels using IPsec.
Note that the VPN client is in the operational environment.
1.6.10 Filtering
The TOE provides stateful traffic firewall functionality including IP address-based filtering (for IPv4
and IPv6) to address the issues associated with unauthorized disclosure of information,
inappropriate access to services, misuse of services, disruption or denial of services, and network-
based reconnaissance. Address filtering can be configured to restrict the flow of network traffic
between protected networks and other attached networks based on source and/or destination IP
addresses. Port filtering can be configured to restrict the flow of network traffic between protected
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 23 of 133
networks and other attached networks based on the originating (source) and/or receiving
(destination) port (service). Stateful packet inspection is used to aid in the performance of packet
flow through the TOE and to ensure that only packets are only forwarded when they’re part of a
properly established session. The TOE supports protocols that can spawn additional sessions in
accordance with the protocol RFCs where a new connection will be implicitly permitted when
properly initiated by an explicitly permitted session. The File Transfer Protocol is an example of
such a protocol, where a data connection is created as needed in response to an explicitly allowed
command connection. System monitoring functionality includes the ability to generate audit
messages for any explicitly defined (permitted or denied) traffic flow. TOE administrators have the
ability to configure permitted and denied traffic flows, including adjusting the sequence in which
flow control rules will be applied, and to apply rules to any network interface of the TOE.
The TOE also provides packet filtering and secure IPsec tunneling. The tunnels can be established
between two trusted VPN peers as well as between remote VPN clients and the TOE. More
accurately, these tunnels are sets of security associations (SAs). The SAs define the protocols and
algorithms to be applied to sensitive packets and specify the keying material to be used. SAs are
unidirectional and are established per the ESP security protocol. An authorized administrator can
define the traffic that needs to be protected via IPsec by configuring access lists (permit, deny, log)
and applying these access lists to interfaces using VPN policies.
1.6.11 Intrusion Prevention System
The TOE provides intrusion policies consisting of rules and configurations invoked by the access
control policy. The intrusion policies are the last line of defense before the traffic is allowed to its
destination. All traffic permitted by the access control policy is then inspected by the designated
intrusion policy. Using intrusion rules and other preprocessor settings, these policies inspect traffic
for security violations and, in inline deployments, can block or alter malicious traffic.
If the vendor-provided intrusion policies do not fully address the security needs of the organization,
custom policies can improve the performance of the system in the environment and can provide a
focused view of the malicious traffic and policy violations occurring on the network. By creating
and tuning custom policies, the administrators can configure, at a very granular level, how the
system processes and inspects the traffic on the network for intrusions.
Using Security Intelligence, the administrators can blacklist—deny traffic to and from—specific IP
addresses, URLs, and DNS domain names, before the traffic is subjected to analysis by the access
control rules. Optionally, the administrators can use a “monitor-only” setting for Security
Intelligence filtering.
1.7 Excluded Functionality
The following functionality is excluded from the evaluation.
Table 9: Excluded Functionality
Excluded Functionality Exclusion Rationale
Telnet for management purposes Telnet passes authentication credentials in clear
text and is disabled by default.
Page 24 of 133
Firepower Device Manager (FDM) Firepower Device Manager is a web-based local
manager. Use of FDM is beyond the scope of this
Common Criteria evaluation.
Filtering of non-IP traffic provided by the
EtherType option when configuring information
flow policies is excluded from the evaluated
configuration
Use of non-IP traffic filtering is beyond the scope
of this Common Criteria evaluation.
Smart Call Home. The Smart Call Home feature
provides personalized, e-mail-based and web-
based notification to customers about critical
events involving their individual systems.
Use of Smart Call Home is beyond the scope of
this Common Criteria evaluation.
Shell Access The shell access is only allowed for pre-
operational installation, configuration, and post-
operational maintenance and troubling shooting.
NTP The TOE does not depend on clock updates from
NTP servers.
Timeout Exemption Option The use of the “Exempt from Browser Session
Timeout” setting is not permitted. This allows a
user to be exempted from the inactivity timeout
feature.
REST API This feature is not evaluated as part of the
evaluation. REST API relies on HTTPS as the
underlying communication protocol and can be
used to build a management interface. This
feature is not tested and is out of scope.
Clustering This feature is not tested and is out of scope.
The services in the table above are disabled in the evaluated configuration. Any functionality of the
TOE that has not been discussed in Section 6 of this document is not included in the evaluation. The
exclusion of this functionality does not affect compliance to collaborative Protection Profile for
Network Devices (cpp_nd_v2.2e), PP-Module for Stateful Traffic Filter Firewalls
(mod_cpp_fw_v1.4e), PP-Module for Virtual Private Network (VPN) Gateways (mod_vpngw_v1.1)
and PP-Module for Intrusion Protection Systems (IPS), Version 1.0 (MOD_IPS_V1.0).
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 25 of 133
2 CONFORMANCE CLAIMS
2.1 Common Criteria Conformance Claim
The TOE and ST are compliant with the Common Criteria (CC) Version 3.1, Revision 5, dated: April
2017. For a listing of Assurance Requirements claimed see section 5.8.
The TOE and ST are CC Part 2 extended and CC Part 3 conformant.
2.2 Protection Profile Conformance
The TOE and ST are conformant with the Protection Profiles as listed in the table below:
Table 10: Protection Profiles
Protection Profile Version Date
PP-Configuration for Network Device, Intrusion Prevention
Systems (IPS), Stateful Traffic Filter Firewalls, and Virtual Private
Network (VPN) Gateways (CFG_NDcPP-IPS-FW-VPNGW_V1.0)
1.0 18 May 2021
The PP-Configuration includes the following components:
• Base-PP: Collaborative Protection Profile for Network Devices,
(CPP_ND_V2.2E)
2.2e 23 March 2020
• PP-Module: PP-Module for Intrusion Prevention Systems (IPS),
(MOD_IPS_V1.0)
1.0 11 May 2021
• PP-Module for Stateful Traffic Filter Firewalls,
(MOD_CPP_FW_1.4E)
1.4 + Errata
20200625
25 June 2020
• PP-Module for Virtual Private Network (VPN) Gateways,
(MOD_VPNGW_V1.1)
1.1 18 June 2020
The TOE and ST are conformant with the Protection Profiles as listed in Table above. The following
NIAP Technical Decisions (TD) have also been applied:
Table 11: Technical Decisions
TD # TD Name Protection Profiles
Applied to this TOE
TD0670 NIT Technical Decision for Mutual and
Non-Mutual Auth TLSC Testing
CPP_ND_V2.2E FCS_TLSC_EXT.2.1
TD0639 NIT Technical Decision for Clarification for
NTP MAC Keys
CPP_ND_V2.2E Not applied because this ST
does not include
FCS_NTP_EXT.1
TD0638 NIT Technical Decision for Key Pair
Generation for Authentication
CPP_ND_V2.2E FCS_CKM.1
Page 26 of 133
TD0636 NIT Technical Decision for Clarification of
Public Key User Authentication for SSH
CPP_ND_V2.2E Not applied because this ST
does not include
FCS_SSHC_EXT.1
TD0635 NIT Technical Decision for TLS Server
and Key Agreement Parameters
CPP_ND_V2.2E FCS_TLSS_EXT.1.3
TD0634 NIT Technical Decision for Clarification
required for testing IPv6
CPP_ND_V2.2E FCS_TLSC_EXT.1.2
TD0633 NIT Technical Decision for IPsec IKE/SA
Lifetimes Tolerance
CPP_ND_V2.2E FCS_IPSEC_EXT.1.7,
FCS_IPSEC_EXT.1.8
TD0632 NIT Technical Decision for Consistency
with Time Data for vNDs
CPP_ND_V2.2E FPT_STM_EXT.1.2
TD0631 NIT Technical Decision for Clarification of
public key authentication for SSH Server
CPP_ND_V2.2E FCS_SSHS_EXT.1,
FMT_SMF.1
TD0597 VPN GW IPv6 Protocol Support MOD_VPNGW_v1.1 FPF_RUL_EXT.1.6
TD0595 Administrative corrections to IPS PP-
Module
MOD_IPS_V1.0 FAU_GEN.1.1/IPS
TD0592 NIT Technical Decision for Local Storage
of Audit Records
CPP_ND_V2.2E FAU_STG
TD0591 NIT Technical Decision for Virtual TOEs
and hypervisors
CPP_ND_V2.2E A.LIMITED_FUNCTIONALI
TY
TD0590 Mapping of operational environment
objectives
MOD_VPNGW_v1.1 OE.CONNECTIONS
TD0581 NIT Technical Decision for Elliptic curve-
based key establishment and NIST SP
800-56Arev3
CPP_ND_V2.2E FCS_CKM.2
TD0580 NIT Technical Decision for clarification
about use of DH14 in NDcPPv2.2e
CPP_ND_V2.2E FCS_CKM.1.1, FCS_CKM.2.1
TD0572 NiT Technical Decision for Restricting
FTP_ITC.1 to only IP address identifiers
CPP_ND_V2.2E FTP_ITC.1
TD0571 NiT Technical Decision for Guidance on
how to handle FIA_AFL.1
CPP_ND_V2.2E FIA_AFL.1
TD0570 NiT Technical Decision for Clarification
about FIA_AFL.1
CPP_ND_V2.2E FIA_AFL.1
TD0569 NIT Technical Decision for Session ID
Usage Conflict in FCS_DTLSS_EXT.1.7
CPP_ND_V2.2E FCS_TLSS_EXT.1
TD0564 NiT Technical Decision for Vulnerability
Analysis Search Criteria
CPP_ND_V2.2E AVA_VAN.1
TD0563 NiT Technical Decision for Clarification of
audit date information
CPP_ND_V2.2E FAU_GEN.1
TD0556 NIT Technical Decision for RFC 5077
question
CPP_ND_V2.2E FCS_TLSS_EXT.1
TD0555 NIT Technical Decision for RFC Reference
incorrect in TLSS Test
CPP_ND_V2.2E FCS_TLSS_EXT.1
TD0551 NIT Technical Decision for Incomplete
Mappings of OEs in FW Module
v1.4+Errata
MOD_CPP_FW_v1.4e Sections 5.3.2 and 5.3.4
TD0549 Consistency of Security Problem
Definition update for MOD_VPNGW_v1.0
and MOD_VPNGW_v1.1
MOD_VPNGW_v1.1 Assumption –
A.CONNECTIONS
TD0547 NIT Technical Decision for Clarification
on developer disclosure of AVA_VAN
CPP_ND_V2.2E AVA_VAN.1
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 27 of 133
TD0546 NIT Technical Decision for DTLS -
clarification of Application Note 63
CPP_ND_V2.2E Not applied because this ST
does not include
FCS_DTLSC_EXT.1.1
TD0545 NIT Technical Decision for Conflicting FW
rules cannot be configured (extension of
RfI#201837)
MOD_CPP_FW_v1.4e FFW_RUL_EXT.1.8
TD0538 NIT Technical Decision for Outdated link
to allowed-with list
CPP_ND_V2.2E Section 2 of PP
TD0537 NIT Technical Decision for Incorrect
reference to FCS_TLSC_EXT.2.3
CPP_ND_V2.2E FCS_TLSC_EXT.2.3
TD0536 NIT Technical Decision for Update
Verification Inconsistency
CPP_ND_V2.2E AGD_OPE.1
TD0528 NIT Technical Decision for Missing EAs for
FCS_NTP_EXT.1.4
CPP_ND_V2.2E Not applied because this ST
does not include
FCS_NTP_EXT.1
TD0527 Updates to Certificate Revocation Testing
(FIA_X509_EXT.1)
CPP_ND_V2.2E FIA_X509_EXT.1/REV,
FIA_X509_EXT.1/ITT
2.3 Protection Profile Conformance Claim Rationale
2.3.1 TOE Appropriateness
The TOE provides all of the functionality at a level of security commensurate with that identified in
the:
• collaborative Protection Profile for Network Devices (cpp_nd_v2.2e)
• PP-Module: PP-Module for Intrusion Protection Systems (IPS), (mod_ips_v1.0)
• PP-Module for Stateful Traffic Filter Firewalls (mod_cpp_fw_v1.4e); and
• PP-Module for Virtual Private Network (VPN) Gateways (mod_vpngw_v1.1)
2.3.2 TOE Security Problem Definition Consistency
The Assumptions, Threats, and Organization Security Policies included in the Security Target
represent the Assumptions, Threats, and Organization Security Policies specified in the
NDcPPv2.2e, mod_ips_v1.0, mod_cpp_fw_v1.4e and mod_vpngw_v1.1 for which conformance is
claimed verbatim. All concepts covered in the Protection Profile Security Problem Definition are
included in the Security Target Statement of Security Objectives Consistency.
The Security Objectives included in the Security Target represent the Security Objectives specified
in the U.S. Government Protection Profile for Security Requirements for Network Devices for which
conformance is claimed verbatim. All concepts covered in the Protection Profile’s Statement of
Security Objectives are included in the Security Target.
2.3.3 Statement of Security Requirements Consistency
The Security Functional Requirements included in the Security Target represent the Security
Functional Requirements specified in cpp_nd_v2.2e, mod_ips_v1.0, mod_cpp_fw_v1.4e and
mod_vpngw_v1.1 for which conformance is claimed verbatim and several additional Security
Functional Requirements are included as a result. All concepts covered the Protection Profile’s
Page 28 of 133
Statement of Security Requirements are included in the Security Target. Additionally, the Security
Assurance Requirements included in the Security Target are identical to the Security Assurance
Requirements included in section 7 of the NDcPP.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 29 of 133
3 SECURITY PROBLEM DEFINITION
This chapter identifies the following:
 Significant assumptions about the TOE’s operational environment.
 IT related threats to the organization countered by the TOE.
 Environmental threats requiring controls to provide sufficient protection.
 Organizational security policies for the TOE as appropriate.
This document identifies assumptions as A.assumption with “assumption” specifying a unique
name. Threats are identified as T.threat with “threat” specifying a unique name. Organizational
Security Policies (OSPs) are identified as P.osp with “osp” specifying a unique name.
3.1 Assumptions
The specific conditions listed in the following subsections are assumed to exist in the TOE’s
environment. These assumptions include both practical realities in the development of the TOE
security requirements and the essential environmental conditions on the use of the TOE.
Table 12: TOE Assumptions
Assumption Assumption Definition
Reproduced from cpp_nd_v2.2e
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 and/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 will not include any requirements on physical tamper
protection or other physical attack mitigations. The cPP will 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.
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
Page 30 of 133
Assumption Assumption Definition
network entity, is not covered by the ND cPP. It is assumed that this
protection will be covered by cPPs and PP modules for particular
types of Network Devices (e.g., firewall).
A.TRUSTED_ADMINSTRATOR 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 being 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.COMPONENTS_RUNNING For distributed TOEs it is assumed that the availability of all TOE
components is checked as appropriate to reduce the risk of an
undetected attack on (or failure of) one or more TOE components. It
is also assumed that in addition to the availability of all components
it is also checked as appropriate that the audit functionality is
running properly on all TOE components.
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.
A.VS_TRUSTED_ADMINISTRATOR The Security Administrators for the VS are assumed to be trusted
and to act in the best interest of security for the organization. This
includes not interfering with the correct operation of the device. The
Network Device is not expected to be capable of defending against a
malicious VS Administrator that actively works to bypass or
compromise the security of the device.
A.VS_REGULAR_UPDATES The VS software is assumed to be updated by the VS Administrator
on a regular basis in response to the release of product updates due
to known vulnerabilities.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 31 of 133
Assumption Assumption Definition
A.VS_ISOLATON For vNDs, it is assumed that the VS provides, and is configured to
provide sufficient isolation between software running in VMs on the
same physical platform. Furthermore, it is assumed that the VS
adequately protects itself from software running inside VMs on the
same physical platform.
A.VS_CORRECT_CONFIGURATION For vNDs, it is assumed that the VS and VMs are correctly configured
to support ND functionality implemented in VMs.
Reproduced from mod_ips_v1.0 and mod_vpngw_v1.1
A.CONNECTIONS It is assumed that the TOE is connected to distinct networks in a
manner that ensures that the TOE security policies will be enforced
on all applicable network traffic flowing among the attached
networks.
3.2 Threats
The following table lists the threats addressed by the TOE and the IT Environment. The assumed
level of expertise of the attacker for all the threats identified below is Enhanced-Basic.
Table 13: Threats
Threat Threat Definition
Reproduced from cpp_nd_v2.2e
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
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.
Page 32 of 133
Threat Threat Definition
T.UNTRUSTED_COMMUNICATIONS
_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.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 33 of 133
Threat Threat Definition
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.
Reproduced from mod_ips_v1.0
T.NETWORK_DISCLOSURE[IPS] Sensitive information on a protected network might be
disclosed resulting from ingress-or egress-based actions.
T.NETWORK_ACCESS[IPS] Unauthorized access may be achieved to services on a
protected network from outside that network, or alternately
services outside a protected network from inside the protected
network. If malicious external devices are able to communicate
with devices on the protected network via a backdoor then
those devices may be susceptible to the unauthorized
disclosure of information.
T.NETWORK_MISUSE[IPS] Access to services made available by a protected network might
be used counter to Operational Environment policies. Devices
located outside the protected network may attempt to conduct
inappropriate activities while communicating with allowed
public services. E.g. manipulation of resident tools, SQL
injection, phishing, forced resets, malicious zip files, disguised
executables, privilege escalation tools and botnets.
T.NETWORK_DOS[IPS] Attacks against services inside a protected network, or
indirectly by virtue of access to malicious agents from within a
protected network, might lead to denial of services otherwise
available within a protected network.
Reproduced from the mod_cpp_fw_v1.4e
T.NETWORK_DISCLOSURE[FW] An attacker may attempt to “map” a subnet to determine the
machines that reside on the network, and obtaining the IP
addresses of machines, as well as the services (ports) those
machines are offering. This information could be used to mount
attacks to those machines via the services that are exported.
T.NETWORK_ACCESS[FW] With knowledge of the services that are exported by machines
on a subnet, an attacker may attempt to exploit those services
by mounting attacks against those services.
T.NETWORK_MISUSE[FW] An attacker may attempt to use services that are exported by
machines in a way that is unintended by a site’s security
policies. For example, an attacker might be able to use a service
to “anonymize” the attacker’s machine as they mount attacks
against others.
Page 34 of 133
Threat Threat Definition
T.MALICIOUS_TRAFFIC [FW] An attacker may attempt to send malformed packets to a
machine in hopes of causing the network stack or services
listening on UDP/TCP ports of the target machine to crash.
Reproduced from the mod_vpngw_v1.1
T.DATA_INTEGRITY[VPN] Devices on a protected network may be exposed to threats
presented by devices located outside the protected network,
which may attempt to modify the data without authorization. If
known malicious external devices are able to communicate
with devices on the protected network or if devices on the
protected network can establish communications with those
external devices then the data contained within the
communications may be susceptible to a loss of integrity.
T. NETWORK_ACCESS[VPN] Devices located outside the protected network may seek to
exercise services located on the protected network that are
intended to only be accessed from inside the protected network
or only accessed by entities using an authenticated path into
the protected network. Devices located outside the protected
network may, likewise, offer services that are inappropriate for
access from within the protected network.
From an ingress perspective, VPN gateways can be configured
so that only those network servers intended for external
consumption by entities operating on a trusted network (e.g.,
machines operating on a network where the peer VPN
gateways are supporting the connection) are accessible and
only via the intended ports. This serves to mitigate the potential
for network entities outside a protected network to access
network servers or services intended only for consumption or
access inside a protected network.
From an egress perspective, VPN gateways can be configured so
that only specific external services (e.g., based on destination
port) can be accessed from within a protected network, or
moreover are accessed via an encrypted channel. For example,
access to external mail services can be blocked to enforce
corporate policies against accessing uncontrolled e-mail
servers, or, that access to the mail server must be done over an
encrypted link.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 35 of 133
Threat Threat Definition
T. NETWORK_DISCLOSURE[VPN] Devices on a protected network may be exposed to threats
presented by devices located outside the protected network,
which may attempt to conduct unauthorized activities. If known
malicious external devices are able to communicate with
devices on the protected network, or if devices on the protected
network can establish communications with those external
devices (e.g., as a result of a phishing episode or by inadvertent
responses to email messages), then those internal devices may
be susceptible to the unauthorized disclosure of information.
From an infiltration perspective, VPN gateways serve not only
to limit access to only specific destination network addresses
and ports within a protected network, but whether network
traffic will be encrypted or transmitted in plaintext. With these
limits, general network port scanning can be prevented from
reaching protected networks or machines, and access to
information on a protected network can be limited to that
obtainable from specifically configured ports on identified
network nodes (e.g., web pages from a designated corporate
web server). Additionally, access can be limited to only specific
source addresses and ports so that specific networks or
network nodes can be blocked from accessing a protected
network thereby further limiting the potential disclosure of
information.
From an exfiltration perspective, VPN gateways serve to limit
how network nodes operating on a protected network can
connect to and communicate with other networks limiting how
and where they can disseminate information. Specific external
networks can be blocked altogether or egress could be limited
to specific addresses and/or ports. Alternately, egress options
available to network nodes on a protected network can be
carefully managed in order to, for example, ensure that
outgoing connections are encrypted to further mitigate
inappropriate disclosure of data through packet sniffing.
Page 36 of 133
Threat Threat Definition
T.NETWORK_MISUSE[VPN] Devices located outside the protected network, while permitted
to access particular public services offered inside the protected
network, may attempt to conduct inappropriate activities while
communicating with those allowed public services. Certain
services offered from within a protected network may also
represent a risk when accessed from outside the protected
network.
From an ingress perspective, it is generally assumed that
entities operating on external networks are not bound by the
use policies for a given protected network. Nonetheless, VPN
gateways can log policy violations that might indicate violation
of publicized usage statements for publicly available services.
From an egress perspective, VPN gateways can be configured to
help enforce and monitor protected network use policies. As
explained in the other threats, a VPN gateway can serve to limit
dissemination of data, access to external servers, and even
disruption of services – all of these could be related to the use
policies of a protected network and as such are subject in some
regards to enforcement. Additionally, VPN gateways can be
configured to log network usages that cross between protected
and external networks and as a result can serve to identify
potential usage policy violations.
T.REPLAY_ATTACK[VPN] If an unauthorized individual successfully gains access to the
system, the adversary may have the opportunity to conduct a
“replay” attack. This method of attack allows the individual to
capture packets traversing throughout the network and send
the packets at a later time, possibly unknown by the intended
receiver. Traffic is subject to replay if it meets the following
conditions:
• Cleartext: an attacker with the ability to view
unencrypted traffic can identify an appropriate
segment of the communications to replay as well in
order to cause the desired outcome.
• No integrity: alongside cleartext traffic, an attacker can
make arbitrary modifications to captured traffic and
replay it to cause the desired outcome if the recipient
has no means to detect these modifications.
3.3 Organizational Security Policies
The following table lists the Organizational Security Policies imposed by an organization to address
its security needs.
Table 14: Organizational Security Policies
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 37 of 133
Policy Name Policy Definition
Reproduced from cpp_nd_v2.2e
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.
Reproduced from mod_ips_v1.0
P.ANALYZE Analytical processes and information to derive conclusions about potential
intrusions must be applied to IPS data and appropriate response actions taken.
Page 38 of 133
4 SECURITY OBJECTIVES
This section identifies the security objectives of the TOE and the IT Environment. The security
objectives identify the responsibilities of the TOE and the TOE’s IT environment in meeting the
security needs.
 This document identifies objectives of the TOE as O.objective with objective specifying a
unique name. Objectives that apply to the IT environment are designated as OE.objective
with objective specifying a unique name.
4.1 Security Objectives for the TOE
The following table, Security Objectives for the TOE, identifies the security objectives of the TOE.
These security objectives reflect the stated intent to counter identified threats and/or comply with
any security policies identified. An explanation of the relationship between the objectives and the
threats/policies is provided in the rationale section of this document.
Table 15: Security Objectives for the TOE
TOE Objective TOE Security Objective Definition
Reproduced from mod_ips_v1.0
O.IPS_ANALYZE Entities that reside on or communicate across
monitored networks must have network activity
effectively
analyzed for potential violations of approved network
usage. The TOE must be able to effectively analyze
data collected from monitored networks to reduce the
risk of unauthorized disclosure of information,
inappropriate access to services, and misuse of
network resources.
O.IPS_REACT The TOE must be able to react in real-time as
configured by the Security Administrator to terminate
and
block traffic flows that have been determined to violate
administrator-defined IPS policies.
O.SYSTEM_MONITORING To be able to analyze and react to potential network
policy violations, the IPS must be able to collect and
store essential data elements of network traffic on
monitored networks.
O.TOE_ADMINISTRATION To address the threat of unauthorized administrator
access that is defined in the Base-PP, conformant
TOEs will provide the functions necessary for an
administrator to configure the IPS capabilities of the
TOE.
Reproduced from mod_cpp_fw_v1.4e
O.RESIDUAL_INFORMATION The TOE shall implement measures to ensure that any
previous information content of network packets sent
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 39 of 133
TOE Objective TOE Security Objective Definition
through the TOE is made unavailable either upon
deallocation of the memory area containing the
network packet or upon allocation of a memory area
for a newly arriving network packet or both.
O.STATEFUL_TRAFFIC_FILTERING The TOE shall perform stateful traffic filtering on
network packets that it processes. For this the TOE
shall support the definition of stateful traffic filtering
rules that allow to permit or drop network packets. The
TOE shall support assignment of the stateful traffic
filtering rules to each distinct network interface. The
TOE shall support the processing of the applicable
stateful traffic filtering rules in an administratively
defined order. The TOE shall deny the flow of network
packets if no matching stateful traffic filtering rule is
identified.
Reproduced from mod_vpngw_v1.1
O.ADDRESS_FILTERING To address the issues associated with unauthorized
disclosure of information, inappropriate access to
services, misuse of services, disruption or denial of
services, and network-based reconnaissance, compliant
TOE’s will implement Packet Filtering capability. That
capability will restrict the flow of network traffic
between protected networks and other attached
networks based on network addresses of the network
nodes originating (source) and/or receiving
(destination) applicable network traffic as well as on
established connection information.
O.AUTHENTICATION To further address the issues associated with
unauthorized disclosure of information, a compliant
TOE’s authentication ability (IPSec) will allow a VPN
peer to establish VPN connectivity with another VPN
peer. VPN endpoints authenticate each other to ensure
they are communicating with an authorized external IT
entity.
O.CRYPTOGRAPHIC_FUNCTIONS To address the issues associated with unauthorized
disclosure of information, inappropriate access to
services, misuse of services, disruption of services, and
network-based reconnaissance, compliant TOE’s will
implement a cryptographic capabilities. These
capabilities are intended to maintain confidentiality
and allow for detection and modification of data that is
transmitted outside of the TOE.
O.FAIL_SECURE There may be instances where the TOE’s hardware
malfunctions or the integrity of the TOE’s software is
compromised, the latter being due to malicious or non-
Page 40 of 133
TOE Objective TOE Security Objective Definition
malicious intent. To address the concern of the TOE
operating outside of its hardware or software
specification, the TOE will shut down upon discovery of
a problem reported via the self-test mechanism and
provide signature-based validation of updates to the
TSF.
O.PORT_FILTERING To further address the issues associated with
unauthorized disclosure of information, etc., a
compliant TOE’s port filtering capability will restrict
the flow of network traffic between protected networks
and other attached networks based on the originating
(source) and/or receiving (destination) port (or
service) identified in the network traffic as well as on
established connection information.
O.SYSTEM_MONITORING To address the issues of administrators being able to
monitor the operations of the VPN gateway, it is
necessary to provide a capability to monitor system
activity. Compliant TOEs will implement the ability to
log the flow of network traffic. Specifically, the TOE will
provide the means for administrators to configure
packet filtering rules to ‘log’ when network traffic is
found to match the configured rule. As a result,
matching a rule configured to ‘log’ will result in
informative event logs whenever a match occurs. In
addition, the establishment of security associations
(SAs) is auditable, not only between peer VPN
gateways, but also with certification authorities (CAs).
O.TOE_ADMINISTRATION TOEs will provide the functions necessary for an
administrator to configure the packet filtering rules, as
well as the cryptographic aspects of the IPsec protocol
that are enforced by the TOE.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 41 of 133
4.2 Security Objectives for the Environment
All of the assumptions stated in section 3.1 are considered to be security objectives for the
environment. The following are the Protection Profile non-IT security objectives, which, in addition
to those assumptions, are to be satisfied without imposing technical requirements on the TOE. That
is, they will not require the implementation of functions in the TOE hardware and/or software.
Thus, they will be satisfied largely through application of procedural or administrative measures.
Table 16: Security Objectives for the Environment
Environment Security Objective IT Environment Security Objective Definition
Reproduced from cpp_nd_v2.2e
OE.PHYSICAL Physical security, commensurate with the value of the TOE and
the data it contains, is provided by the environment.
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. Note: For vNDs the TOE includes only
the contents of the its own VM, and does not include other VMs
or the VS.
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.COMPONENTS_RUNNING For distributed TOEs the Security Administrator ensures that
the availability of every TOE component is checked as
appropriate to reduce the risk of an undetected attack on (or
failure of) one or more TOE components. The Security
Administrator also ensures that it is checked as appropriate for
every TOE component that the audit functionality is running
properly.
Page 42 of 133
Environment Security Objective IT Environment Security Objective Definition
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. For vNDs, this
applies when the physical platform on which the VM runs is
removed from its operational environment.
OE.VM_CONFIGURATION For vNDs, the Security Administrator ensures that the VS and
VMs are configured to
• reduce the attack surface of VMs as much as possible
while supporting ND functionality (e.g., remove
unnecessary virtual hardware, turn off unused inter-
VM communications mechanisms), and
• correctly implement ND functionality (e.g., ensure
virtual networking is properly configured to support
network traffic, management channels, and audit
reporting).
The VS should be operated in a manner that reduces the
likelihood that vND operations are adversely affected by
virtualization features such as cloning, save/restore,
suspend/resume, and live migration. If possible, the VS should
be configured to make use of features that leverage the VS’s
privileged position to provide additional security functionality.
Such features could include malware detection through VM
introspection, measured VM boot, or VM snapshot for forensic
analysis.
Reproduced from mod_ips_v1.0
OE.CONNECTIONS TOE administrators will ensure that the TOE is installed in a
manner that will allow the TOE to effectively enforce its
policies on network traffic of monitored networks.
Reproduced from mod_vpngw_v1.1
OE.CONNECTIONS TOE is connected to distinct networks in a manner that ensures
that the TOE security policies will be enforced on all applicable
network traffic flowing among the attached networks.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 43 of 133
5 SECURITY REQUIREMENTS
This section identifies the Security Functional Requirements for the TOE. The Security Functional
Requirements included in this section are derived from Part 2 of the Common Criteria for
Information Technology Security Evaluation, Version 3.1, Revision 5, dated: April 2017 and all
international interpretations.
5.1 Conventions
The CC defines operations on Security Functional Requirements: assignments, selections,
assignments within selections and refinements. This document uses the following font conventions
to identify the operations defined by the CC:
• Assignment: Indicated with italicized text;
• Refinement made by PP author: Indicated with bold text;
• Selection: Indicated with underlined text;
• Iteration: Indicated by appending the iteration number in parenthesis, e.g., (1), (2), (3).
• Where operations were completed in the cpp_nd_v2.2e, mod_cpp_fw_v1.4e, mod_ips_v1.0
and mod_vpngw_v1.1 itself, the formatting used there has been retained.
Extended SFRs are identified by having a label ‘EXT’ after the requirement name for TOE SFRs.
Formatting conventions outside of operations and iterations matches the formatting specified
within the PP and the PP modules themselves. In addition, SFRs copied verbatim from
mod_cpp_fw_v1.4e will have an extension [FW], SFRs copied from mod_vpngw_v1.1 will have
extension [VPN] and SFRs copied from mod_ips_v1.0 will have extension [IPS] to distinguish them
from the NDcPP. These SFRs that have an extension of [FW], [IPS] or [VPN] do not exist in
NDcPPv2.2e. Changes have been made to the base cPP SFRs as necessary to support the Intrusion
Prevention, firewall and VPN functionality based on mod_ips_v1.0, mod_cpp_fw_v1.4e and
mod_vpngw_v1.1.
Except where noted, all aspects of SFRs are applicable to entire TOE (FTD and FMC). Where specific
functionality is only implemented in either FTD or FMC, the applicable subcomponent is identified
in an application note, or in embedded qualifiers within the text of the SFR. Application notes clarify
distinctions where the TOE includes multiple implementations of a functionality and those
implementations differ in their minimum support of the functionality. Thus, the SFR is stating the
combined functionality of the TOE.
5.2 TOE Security Functional Requirements
This section identifies the Security Functional Requirements for the TOE. The TOE Security
Functional Requirements that appear in the following table are described in more detail in the
following subsections.
Table 17: Security Functional Requirements
Class Name Component Identification Component Name
Reproduced from cpp_nd_v2.2e
FAU: Security Audit FAU_GEN.1 Audit Data Generation
FAU_GEN.2 User identity association
Page 44 of 133
Class Name Component Identification Component Name
FAU_GEN_EXT.1 Security Audit Generation
FAU_STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.4 Protected Local Audit Event Storage for
Distributed TOEs
FAU_STG_EXT.5 Protected Remote Audit Event Storage
for Distributed TOEs
FCO: Communication FCO_CPC_EXT.1 Component Registration Channel
Definition
FCS: Cryptographic
Support
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_IPSEC_EXT.1 IPsec 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
FIA: Identification and
Authentication
FIA_AFL.1 Authentication Failure Management
FIA_PMG_EXT.1 Password Management
FIA_UIA_EXT.1 User Identification and Authentication
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 45 of 133
Class Name Component Identification Component Name
FIA_UAU_EXT.2 Password-based Authentication
Mechanism
FIA_UAU.7 Protected Authentication Feedback
FIA_X509_EXT.1/ITT X.509 Certificate Validation
FIA_X509_EXT.1/Rev X.509 Certificate Validation
FIA_X509_EXT.2(1) X.509 Certificate Authentication
FIA_X509_EXT.2(2) X.509 Certificate Authentication
FIA_X509_EXT.3 X.509 Certificate Requests
FMT: Security
Management
FMT_MOF.1/ManualUpdate 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: Protection of the
TSF
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_STM_EXT.1 Reliable Time Stamps
FPT_TST_EXT.1 TSF Testing
FPT_TUD_EXT.1 Trusted Update
FPT_ITT.1 Basic internal TSF data transfer
protection
FPT_ITT.1/Join Basic internal TSF data transfer
protection – Registration Channel
FTA: TOE Access 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
Page 46 of 133
Class Name Component Identification Component Name
FTP: Trusted
path/channels
FTP_ITC.1 Inter-TSF Trusted Channel
FTP_TRP.1/Admin Trusted Path
Reproduced from mod_ips_v1.0
FAU: Security Audit FAU_GEN.1/IPS[IPS] Audit Data Generation (IPS)
FAU_SAR.1[IPS] Audit Review
FAU_SAR.2[IPS] Restricted Audit Review
FAU_SAR.3[IPS] Selectable Audit Review
FAU_STG.1/IPS[IPS] Protected Audit Trail Storage (IPS Data)
FMT: Security
Management
FMT_SMF.1/IPS[IPS] Specification of Management Functions
(IPS)
IPS: Intrusion Prevention IPS_ABD_EXT.1[IPS] Anomaly-Based IPS Functionality
IPS_IPB_EXT.1[IPS] IP Blocking
IPS_NTA_EXT.1[IPS] Network Traffic Analysis
IPS SBD_EXT.1[IPS] Signature-Based IPS Functionality
Reproduced from mod_cpp_fw_v1.4e
FDP: User Data
Protection
FDP_RIP.2[FW] Full Residual Information Protection
FFW: Stateful Traffic
Filtering
FFW_RUL_EXT.1[FW] Stateful Traffic Filtering
FFW_RUL_EXT.2[FW] Stateful Filtering of Dynamic Protocols
FMT: Security
Management
FMT_SMF.1/FFW[FW] Specification of Management Functions
Reproduced from mod_vpngw_v1.1
FCS: Cryptographic
Support
FCS_CKM.1/IKE[VPN] Cryptographic Key Generation (for IKE
Peer Authentication)
FIA: Identification and
Authentication
FIA_PSK_EXT.1[VPN] Pre-Shared Key Composition
FMT: Security
Management
FMT_SMF.1/VPN[VPN] Specification of Management Functions
(VPN Gateway)
FPF: Packet Filtering FPF_RUL_EXT.1[VPN] Rules for Packet Filtering
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 47 of 133
Class Name Component Identification Component Name
FPT: Protection of the
TSF
FPT_FLS.1/SelfTest[VPN] Fail Secure (Self-Test Failures)
FPT_TST_EXT.3[VPN] Self-Test with Defined Methods
FTA: TOE Access FTA_SSL.3/VPN[VPN] TSF-Initiated Termination (VPN
Headend)
FTA_TSE.1[VPN] TOE Session Establishment
FTA_VCM_EXT.1[VPN] VPN Client Management
FTP: Trusted
path/channels
FTP_ITC.1/VPN[VPN] Inter-TSF Trusted Channel (VPN
Communications)
5.3 SFRs Drawn from NDcPP
5.3.1 Security audit (FAU)
5.3.1.1 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; and
c) All administrative actions comprising:
• Administrative login and logout (name of user account shall be logged if individual
user accounts are required for Administrators).
• Changes to TSF data related to configuration changes (in addition to the information
that a change occurred it shall be logged what has been changed).
• Generating/import of, changing, or deleting of cryptographic keys (in addition to the
action itself a unique key name or key reference shall be logged).
• Resetting passwords (name of related user account shall be logged).
• [no other actions];
d) Specifically defined auditable events listed in Table 18.
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 18.
Table 18: Auditable Events
Page 48 of 133
SFR Auditable Event Additional Audit
Record Contents
Reproduced from NDcPP
FAU_GEN.1 None. None.
FAU_GEN.2 None. None.
FAU_GEN_EXT.1 None. None.
FAU_STG_EXT.1 None. None.
FAU_STG_EXT.4 None. None.
FAU_STG_EXT.5 None. None.
FCO_CPC_EXT.1 • Enabling communications
between a pair of
components.
• Disabling
communications between
a pair of components.
Identities of the endpoint
pairs enabled or disabled.
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_IPSEC_EXT.1 Failure to establish an IPsec
SA.
Session Establishment with
peer
Reason for failure.
Entire packet contents of
packets
transmitted/received
during session
establishment.
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
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 the identification
and authentication
mechanism.
Origin of the attempt (e.g.,
IP address).
FIA_UAU_EXT.2 All use of the identification
and authentication
mechanism.
Origin of the attempt (e.g.,
IP address).
FIA_UAU.7 None. None.
FIA_X509_EXT.1/ITT • Unsuccessful attempt to
validate a certificate
• Reason for failure of
certificate validation
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 49 of 133
SFR Auditable Event Additional Audit
Record Contents
• Any addition,
replacement or removal
of trust anchors in the
TOE's trust store
• Identification of
certificates added,
replaced or removed as
trust anchor in the
TOE's trust store
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(1) None. None.
FIA_X509_EXT.2(2) None. None.
FIA_X509_EXT.3 None. None.
FMT_MOF.1/ManualUpdate Any attempt to initiate a
manual update
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_ITT.1 • Initiation of the trusted
channel.
• Termination of the
trusted channel.
• Failure of the trusted
channel functions.
Identification of the
initiator and target of failed
trusted channels
establishment attempt
FPT_ITT.1/Join • 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
FPT_TST_EXT.1 None. None.
FPT_TUD_EXT.1 Initiation of update; result of
the update attempt (success
or failure)
No additional information.
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).
Page 50 of 133
SFR Auditable Event Additional Audit
Record Contents
FTA_SSL_EXT.1 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.
• Failures of the trusted
path functions.
None.
Reproduced from the mod_cpp_fw_v1.4e
FDP_RIP.2[FW] None. None.
FFW_RUL_EXT.1[FW] Application of rules
configured with the ‘log’
operation
Source and destination
addresses
Source and destination
ports
Transport Layer Protocol
TOE Interface
FFW_RUL_EXT.2[FW] Dynamical definition of rule
Establishment of a session
None.
FMT_SMF.1/FFW[FW] All management activities of
TSF data(including creation,
modification and deletion of
firewall rules).
None.
Reproduced from the mod_vpngw_v1.1
FCS_CKM.1/IKE[VPN] None. None.
FIA_PSK_EXT.1[VPN] None. None.
FMT_SMF.1/VPN[VPN] None. None.
FPF_RUL_EXT.1[VPN] Application of rules
configured with the ‘log’
operation
Source and destination
addresses
Source and destination
ports
Transport Layer Protocol
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 51 of 133
SFR Auditable Event Additional Audit
Record Contents
FPT_FLS.1/SelfTest[VPN] None. None.
FPT_TST_EXT.3[VPN] None. None.
FTA_SSL.3/VPN[VPN] None. None.
FTA_TSE.1[VPN] None. None.
FTA_VCM_EXT.1[VPN] None. None.
FTP_ITC.1/VPN[VPN] None. None.
5.3.1.2 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.
5.3.1.3 FAU_GEN_EXT.1 Security Audit Generation
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.
5.3.1.4 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 be a distributed TOE that stores audit data on the following TOE components:
[FMC, FTD]
• The TOE shall be a distributed TOE with storage of audit data provided externally for the
following TOE components: [FTD transmits its audit data to FMC].]
FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the following rule:
[the newest audit record will overwrite the oldest audit record]] when the local storage space for
audit data is full.
5.3.1.5 FAU_STG_EXT.4 Protected Local Audit Event Storage for Distributed
TOEs
FAU_STG_EXT.4.1 The TSF of each TOE component which stores security audit data locally shall
perform the following actions when the local storage space for audit data is full:
[
FMC: overwrite previous audit records according to the following rule: [oldest records are
overwritten]
FTD: overwrite previous audit records according to the following rule: [oldest records are overwritten]
]
Page 52 of 133
5.3.1.6 FAU_STG_EXT.5 Protected Remote Audit Event Storage for Distributed
TOEs
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 [FPT_ITT.1]
5.3.2 Communication (FCO)
5.3.2.1 FCO_CPC_EXT.1 Communication Partner Control
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 [
• A channel that meets the secure channel requirements in [FPT_ITT.1/Join]].
for at least TSF data.
FCO_CPC_EXT.1.3 The TSF shall enable a Security Administrator to disable communications
between any pair of TOE components.
5.3.3 Cryptographic Support (FCS)
5.3.3.1 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].
5.3.3.2 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: [
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 53 of 133
• RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5 as
specified in Section 7.2 of RFC 3447, “Public-Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1”;
• 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 Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography” and [groups listed in RFC 3526]
] that meets the following: [assignment: list of standards].
5.3.3.3 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], destruction of reference to the key directly followed by a
request for garbage collection];
• For plaintext keys in non-volatile storage, the destruction shall be executed by the
invocation of an interface provided by a part of the TSF that [
o logically addresses the storage location of the key and performs a [[one]-pass]
overwrite consisting of [zeroes]];
o instructs a part of the TSF to destroy the abstraction that represents the key]
that meets the following: No Standard.
5.3.3.4 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, GCM] and [no other] mode and cryptographic
key sizes [128 bits, 256 bits], and [no other cryptographic key sizes] that meet the following:
AES as specified in ISO 18033-3, [CBC as specified in ISO 10116, GCM as specified in ISO 19772]
and [no other standards].
5.3.3.5 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,
3072 bits]
• Elliptic Curve Digital Signature Algorithm and cryptographic key sizes [256, 384, and
521 bits]
Page 54 of 133
]
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 RSASSAPKCS2v1_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
].
5.3.3.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)
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.
5.3.3.7 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 and 512 bits] and message digest sizes [160,
256, 384, 512] bits that meet the following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”.
5.3.3.8 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.
5.3.3.9 FCS_IPSEC_EXT.1 IPsec Protocol
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 [transport mode, tunnel mode].
FCS_IPSEC_EXT.1.4 The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using
the cryptographic algorithms [AES-CBC-128(RFC 3602), AES-CBC-256 (RFC 3602), AES-GCM-
128(RFC 4106), AES-GCM-256 (RFC 4106)] and [no other algorithm] together with a Secure Hash
Algorithm (SHA)-based HMAC [HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512]
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 55 of 133
FCS_IPSEC_EXT.1.5 The TSF shall implement the protocol: [
• IKEv2 as defined in RFC 5996 and [with mandatory support for NAT traversal as specified in
RFC 5996, section 2.23)], and [RFC 4868 for hash functions]
].
FCS_IPSEC_EXT.1.6 The TSF shall ensure the encrypted payload in the [IKEv2] protocol uses the
cryptographic algorithms [AES-CBC-128, AES-CBC-256 (specified in RFC 3602), AES-GCM-128, AES-
GCM-256 (specified in RFC 5282)].
FCS_IPSEC_EXT.1.7 The TSF shall ensure that [
• IKEv2 SA lifetimes can be configured by a Security Administrator based on
[
o length of time, where the time values can be configured within [120 to
2,147,483,647 seconds. The default is 86,400 seconds which is 24] hours
]
].
FCS_IPSEC_EXT.1.8 The TSF shall ensure that [
• IKEv2 Child SA lifetimes can be configured by a Security Administrator based on
[
o number of bytes;
o length of time, where the time values can be configured within [120-2,147,483,647
seconds. The default is 28,800 seconds which is 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 g^x mod p) using the random bit generator specified in FCS_RBG_EXT.1, and
having a length of at least [512] bits.
FCS_IPSEC_EXT.1.10 The TSF shall generate nonces used in [IKEv2] exchanges of length [
o at least 128 bits in size and at least half the output size of the negotiated
pseudorandom function (PRF) hash
] .
FCS_IPSEC_EXT.1.11 The TSF shall ensure that all IKE protocols implement DH Group(s)
• 19 (256-bit Random ECP), 20 (384-bit Random ECP) according to RFC 5114 and
[
• [14 (2048-bit MODP)] according to RFC 3526,
]
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 [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 [IKEv2 CHILD_SA] connection.
Page 56 of 133
FCS_IPSEC_EXT.1.13 The TSF shall ensure that all IKE protocols perform peer authentication using
[RSA, ECDSA] that use X.509v3 certificates that conform to RFC 4945 and [Pre-shared Keys].
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: Distinguished Name (DN), [SAN: Fully Qualified
Domain Name (FQDN)].
Application Note
In FCS_IPSEC_EXT.1.7, IKEv2 SA can be limited by time only. IKEv2 Child SA can be limited by time or
number of kilobytes. The time is in number of seconds.
In FCS_IPSEC_EXT.1.8, the valid range in kilobytes is 10-2,147,483,647 (10KB to 2TB).
5.3.3.10FCS_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.
5.3.3.11FCS_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, [6668].
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following user 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
[262126] 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-cbc, aes256-cbc,
AEAD_AES_128_GCM, AEAD_AES_256_GCM].
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication
implementation uses [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, AEAD_AES_128_GCM, AEAD_AES_256_GCM] 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, ecdh-sha2-nistp256
(FTD-only)] and [ecdh-sha2-nistp384 (FTD-only), ecdh-sha2-nistp521 (FTD-only)] are the only
allowed key exchange methods used for the SSH protocol.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 57 of 133
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.
5.3.3.12FCS_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: [
Relevant to syslog over TLS from FTD TLS Client (No mutual authentication):
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 (TLSv1.2, TLSv1.1)
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 (TLSv1.2, TLSv1.1)
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289) (TLSv1.2 only)
Relevant to FPT_ITT.1 (No mutual authentication):
• TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 (TLSv1.2 only)
• TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 (TLSv1.2 only)
• TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 (TLSv1.2 only)
• TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 (TLSv1.2 only)
• TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288 (TLSv1.2 only)
• TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 (TLSv1.2 only)
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 (TLSv1.2 only)
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 (TLSv1.2 only)
Relevant to syslog over TLS from FTD OS TLS Client (No Mutual authentication):
Page 58 of 133
• TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 (TLSv1.2, TLSv1.1)
• TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 (TLSv1.2, TLSv1.1)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 (TLSv1.2, TLSv1.1)
Relevant to syslog over TLS from FMC/FMCv (With Mutual authentication):
• TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 (TLSv1.2, TLSv1.1)
• TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 (TLSv1.2, TLSv1.1)
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 (TLSv1.2, TLSv1.1)
] and no other ciphersuites.
FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches [the reference
identifier per RFC 6125 section 6, the identifier per RFC 5280 Appendix A using [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 [
• 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.
Application Note
FCS_TLSC_EXT.1 is applicable to two TLS clients that send syslog messages to the syslog server- FTD
TLS client, that is configured by the FMC and is the main audit system for audits generated by FTD. It
sends audit events such as IPsec and login messages to the external syslog server and Mutual
authentication is not supported; and the FTD OS TLS client, that is configured through the FTD’s
command line and sends audit events to an external syslog server such as SSH login, console login, etc.
and Mutual authentication is not supported.
The selection of – “the identifier per RFC 5280 Appendix A using [id-at-title]”in FCS_TLSC_EXT.1.2 is
only applicable to the TLS connection that is relevant to FPT_ITT.1.
5.3.3.13FCS_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.
Application Note
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 59 of 133
FCS_TLSC_EXT.2 is applicable to the TLS client in FMC/FMCv that is used for transmission of syslog
over TLS.
5.3.3.14FCS_TLSS_EXT.1 TLS Server Protocol
FCS_TLSS_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246)] and reject all other TLS and SSL
versions. The TLS implementation will support the following ciphersuites: [
Relevant to FPT_ITT.1:
• TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 (TLSv1.2 only)
• TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 (TLSv1.2 only)
• TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 (TLSv1.2 only)
• TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 (TLSv1.2 only)
• TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288 (TLSv1.2 only)
• TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 (TLSv1.2 only)
Relevant to FTP_TRP.1/Admin (applicable to FMC/FMCv only):
• TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 (TLSv1.2 only)
• TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 (TLSv1.2 only)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 (TLSv1.2 only)
] 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 [TLS 1.1].
FCS_TLSS_EXT.1.3 The TSF shall perform key establishment for TLS using [RSA with key size [2048
bits]; ECDHE curves [secp256r1, secp384r1, secp521r1] and no other curves].
FCS_TLSS_EXT.1.4 The TSF shall support [session resumption based on session tickets according to
RFC 5077]
Page 60 of 133
5.3.4 Identification and authentication (FIA)
5.3.4.1 FIA_AFL.1 Authentication Failure Management
FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within [1 to
99 (FMC), 1 to 10 (FTD)] 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 remote Administrator from successfully establishing remote session
using any authentication method that involves a password until [unlocking] is taken by an
Administrator].
5.3.4.2 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: [“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”,
“(“, “)”, “ ” ‘ ` (double or single quote/apostrophe), + (plus), - (minus), = (equal), , (comma), .
(period), / (forward-slash), \ (back-slash), | (vertical-bar or pipe), : (colon), ; (semi-colon),
< > (less-than, greater-than inequality signs), [ ] (square-brackets), { } (braces or curly-
brackets ),^ (caret), _ (underscore), and ~ (tilde)]];
b) Minimum password length shall be configurable to between [8] and [32] characters.
5.3.4.3 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 action on behalf of that administrative
user.
5.3.4.4 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.
5.3.4.5 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.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 61 of 133
5.3.4.6 FIA_X509_EXT.1/ITT X.509 Certificate Validation
FIA_X509_EXT.1.1/ITT The TSF shall validate certificates in accordance with the following rules:
• RFC 5280 certificate validation and certificate path validation supporting a minimum path
length of two certificates.
• The certificate path must terminate with a trusted CA certificate designated as a trust
anchor.
• 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 [no revocation method].
• The TSF shall validate the extendedKeyUsage field according to the following rules:
o Server certificates presented for TLS shall have the Server Authentication purpose (id-
kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
o Client certificates presented for TLS shall have the Client Authentication purpose (id-
kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose
(id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
FIA_X509_EXT.1.2/ITT The TSF shall only treat a certificate as a CA certificate if the
basicConstraints extension is present and the CA flag is set to TRUE.
5.3.4.7 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 certificate path validation supporting a minimum
path length of three certificates.
• The certificate 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 basicConstraints extension with the CA flag set to TRUE.
• The TSF shall validate the revocation status of the certificate using [the Online Certificate
Status Protocol (OCSP) as specified in RFC 6960 (FTD-only), a Certificate Revocation List
(CRL) as specified in RFC 5759 Section 5].
• 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.
Page 62 of 133
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.
5.3.4.8 FIA_X509_EXT.2(1) X.509 Certificate Authentication
FIA_X509_EXT.2.1(1) The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for [TLS], and [no additional uses].
FIA_X509_EXT.2.2(1) When the TSF cannot establish a connection to determine the validity of a
certificate, the TSF shall [accept the certificate].
5.3.4.9 FIA_X509_EXT.2(2) X.509 Certificate Authentication
FIA_X509_EXT.2.1(2) The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for IPsec and [no other protocols], and [no additional uses].
FIA_X509_EXT.2.2(2) When the TSF cannot establish a connection to determine the validity of a
certificate, the TSF shall [not accept the certificate].
5.3.4.10FIA_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.5 Security management (FMT)
5.3.5.1 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 update to Security Administrators.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 63 of 133
5.3.5.2 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.
5.3.5.3 FMT_MTD.1/CryptoKeys Management of TSF Data
FMT_MTD.1.1/CryptoKeys The TSF shall restrict the ability to [[manage]] the [cryptographic keys
and certificates used for VPN operation] to [Security Administrators].
5.3.5.4 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 and [no other]
capability prior to installing those updates;
• Ability to configure the authentication failure parameters for FIA_AFL.1;
• Ability to manage the cryptographic keys;
• Ability to configure the cryptographic functionality;
• Ability to configure the lifetime for IPsec SAs;
• Ability to import X.509v3 certificates to the TOE’s trust store;
• [
o Ability to configure the interaction between TOE components;
o Ability to manage the trusted public keys database;
o Ability to re-enable an Administrator account;
o Ability to set the time which is used for time-stamps;
o Ability to configure the reference identifier for the peer;
]
5.3.5.5 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;
Page 64 of 133
• The Security Administrator role shall be able to administer the TOE remotely;
are satisfied.
5.3.6 Protection of the TSF (FPT)
5.3.6.1 FPT_SKP_EXT.1 Protection of TSF Data (for Reading of All Symmetric
Keys)
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and
private keys.
5.3.6.2 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.
5.3.6.3 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.4 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)] to demonstrate the correct operation of the TSF: noise source health tests, [FIPS 140-2
standard power-up self-tests and firmware integrity test].
5.3.6.5 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 [the most recently installed version of the TOE
firmware/software].
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 a means to authenticate firmware/software updates to
the TOE using a digital signature mechanism and [no other mechanisms] prior to installing
those updates.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 65 of 133
5.3.6.6 FPT_ITT.1: Basic Internal TOE TSF data transfer protection
FPT_ITT.1.1 The TSF shall protect TSF data from disclosure and detect its modification when it is
transmitted between separate parts of the TOE through the use of [TLS].
5.3.6.7 FPT_ITT.1/Join: Basic Internal TOE TSF data transfer protection –
Registration Channel
FPT_ITT.1.1/Join The TSF shall protect TSF data from disclosure and detect its modification when
it is transmitted between separate parts of the TOE through the use of [TLS].
5.3.7 TOE Access (FTA)
5.3.7.1 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.
5.3.7.2 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.
5.3.7.3 FTA_SSL.4 User-initiated Termination
FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s
own interactive session.
5.3.7.4 FTA_TAB.1 Default TOE Access Banners
FTA_TAB.1.1 Before establishing an administrative user session the TSF shall display a Security
Administrator-specified advisory notice and consent warning message regarding use of the TOE.
5.3.8 Trusted Path/Channels (FTP)
5.3.8.1 FTP_ITC.1 Inter-TSF Trusted Channel
FTP_ITC.1.1 The TSF shall be capable of using [IPsec (FTD only), TLS] to provide a trusted
communication channel between itself and authorized IT entities supporting the following
capabilities: audit server, [VPN communications] that is logically distinct from other
Page 66 of 133
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: transmit audit data via syslog over IPsec or TLS;
• VPN client: VPN connections from VPN client using IPsec;
].
5.3.8.2 FTP_TRP.1/Admin Trusted Path
FTP_TRP.1.1/Admin The TSF shall be capable of using [SSH, TLS (FMC only), HTTPS (FMC only),
IPsec (FTD only)] 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 communicated 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 SFRs Drawn from mod_ips_v1.0
5.4.1 Security Audit (FAU)
5.4.1.1 FAU_GEN.1/IPS[IPS] Audit Data Generation (IPS)
FAU_GEN.1.1/IPS[IPS] The TSF shall be able to generate an IPS audit record of the following
auditable IPS events:
a) Start-up and shut-down of the IPS functions;
b) All IPS auditable events for the [not specified] level of audit; and
c) [All dissimilar IPS events;
d) All dissimilar IPS reactions;
e) Totals of similar events occurring within a specified time period;
f) Totals of similar reactions occurring within a specified time period.
g) The events in the IPS Events table.
h) [no other auditable events]
FAU_GEN.1.2/IPS[IPS] The TSF shall record within each IPS auditable event record at least the
following information:
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 67 of 133
a) Date and time of the event, type of event and/or reaction, subject identity, and the outcome
(success or failure) of the event; and;
b) For each IPS auditable event type, based on the auditable event definitions of the functional
components included in the PP/ST, [information specified in column three of the IPS Events table].
Table 19: Auditable Events
SFR Auditable Event Additional Audit Record Contents
FMT_SMF.1/IPS[IPS] Modification of an IPS policy
element.
Identifier or name of the modified IPS
policy element (e.g. which signature or
known-good/known-bad list was
modified).
IPS_ABD_EXT.1[IPS] Inspected traffic matches an
anomaly-based IPS policy.
Source and destination IP addresses.
The content of the header fields that were
determined to match the policy.
TOE interface that received the packet.
Aspect of the anomaly-based IPS policy rule
that triggered the event (e.g. throughput,
time of day, frequency, etc.).
Network-based action by the TOE (e.g.
allowed, blocked, sent reset to source IP,
sent blocking notification to firewall).
IPS_IPB_EXT.1[IPS] Inspected traffic matches a list of
known-good or known-bad
addresses applied to an IPS policy.
Source and destination IP addresses (and, if
applicable, indication of whether the source
and/or destination address matched the
list).
TOE interface that received the packet.
Network-based action by the TOE (e.g.
allowed, blocked, sent reset).
IPS_NTA_EXT.1[IPS] Modification of which IPS policies
are active on a TOE interface.
Enabling/disabling a TOE interface
with IPS policies applied.
Modification of which mode(s)
is/are active on a TOE interface.
Identification of the TOE interface.
The IPS policy and interface mode (if
applicable).
IPS_SBD_EXT.1[IPS] Inspected traffic matches a
signature-based IPS rule with
logging enabled.
Name or identifier of the matched
signature.
Source and destination IP addresses.
The content of the header fields that were
determined to match the signature.
TOE interface that received the packet.
Network-based action by the TOE (e.g.
allowed, blocked, sent reset).
5.4.1.2 FAU_SAR.1[IPS] Audit Review
FAU_SAR.1.1[IPS] Refinement: The TSF shall provide [authorized administrators] with the
capability to read [IPS data] from the audit records IPS events.
Page 68 of 133
FAU_SAR.1.2[IPS] Refinement: The TSF shall provide the audit records IPS data in a manner
suitable for the user administrators to interpret the information.
5.4.1.3 FAU_SAR.2[IPS] Restricted Audit Review
FAU_SAR.2.1[IPS] The TSF shall prohibit all users administrators read access to the audit records
IPS data, except those that have been granted explicit read-access.
5.4.1.4 FAU_SAR.3[IPS] Selectable Audit Review
FAU_SAR.3.1[IPS] The TSF shall provide the ability to apply [filtering and sorting] of audit IPS data
based on [filtering parameters: risk rating, time period, source IP address, destination IP address and
[other filtering parameters described in the TSS]]; and sorting parameters: event ID, event type, time,
signature ID, IPS actions performed, and [[other sorting parameters described in the TSS]].
5.4.1.5 FAU_STG.1/IPS[IPS] Protected Audit Trail Storage (IPS Data)
FAU_STG.1.1/IPS[IPS] The TSF shall protect the stored audit records IPS data from unauthorized
deletion.
FAU_STG.1.2/IPS[IPS] The TSF shall be able to [prevent] unauthorized modifications to the stored
audit records IPS data in the audit trail.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 69 of 133
5.4.2 Security Management (FMT)
5.4.2.1 FMT_SMF.1/IPS[IPS] Specification of Management Functions (IPS)
FMT_SMF.1.1/IPS[IPS] The TSF shall be capable of performing the following management
functions: [
• Enable, disable signatures applied to sensor interfaces, and determine the behavior of
IPS functionality
• Modify these parameters that define the network traffic to be collected and analyzed:
o Source IP addresses (host address and network address)
o Destination IP addresses (host address and network address)
o Source port (TCP and UDP)
o Destination port (TCP and UDP)
o Protocol (IPv4 and IPv6)
o ICMP type and code
• Update (import) signatures
• Create custom signatures
• Configure anomaly detection
• Enable and disable actions to be taken when signature or anomaly matches are
detected
• Modify thresholds that trigger IPS reactions
• Modify the duration of traffic blocking actions
• Modify the known-good and known-bad lists (of IP addresses or address ranges)
• Configure the known-good and known-bad lists to override signature-based IPS
policies]
5.4.3 Intrusion Prevention (IPS)
5.4.3.1 IPS_ABD_EXT.1[IPS] Anomaly-Based IPS Functionality
IPS_ABD_EXT.1.1[IPS] The TSF shall support the definition of [anomaly (‘unexpected’) traffic
patterns] including the specification of [
• frequency;
• [preprocessor detection rules for anomaly detected in headers and protocols]]
and the following network protocol fields:
Page 70 of 133
• [all packet header and data elements defined in IPS_SBD_EXT.1]
Application Note
Although the term “threshold” is used in the TSS, the TOE’s definition of “threshold” matches the
definition of frequency in the mod_ips_v1.0. Therefore, “frequency”, rather than “threshold” has been
selected in the IPS_ABD_EXT.1.1 requirement.
IPS_ABD_EXT.1.2[IPS] The TSF shall support the definition of anomaly activity through [manual
configuration by administrators].
IPS_ABD_EXT.1.3[IPS] The TSF shall allow the following operations to be associated with anomaly-
based IPS policies:
• In any mode, for any sensor interface: [
o allow the traffic flow]
• In inline mode: [
o allow the traffic flow
o block/drop the traffic flow
o and [no other actions]
5.4.3.2 IPS_IPB_EXT.1[IPS] IP Blocking
IPS_IPB_EXT.1.1[IPS] The TSF shall support configuration and implementation of known-good and
known-bad lists of [source, destination] IP addresses and [no additional address types]
IPS_IPB_EXT.1.2[IPS] The TSF shall allow [Security Administrators] to configure the following IPS
policy elements: [known-good list rules, known-bad list rules, IP addresses, [Domain names and
URLs]].
5.4.3.3 IPS_NTA_EXT.1[IPS] Network Traffic Analysis
IPS_NTA_EXT.1.1[IPS] The TSF shall perform analysis of IP-based network traffic forwarded to the
TOE’s sensor interfaces, and detect violations of administratively-defined IPS policies.
IPS_NTA_EXT.1.2[IPS] The TSF shall process (be capable of inspecting) the following network
traffic protocols:
• [Internet Protocol (IPv4), RFC 791
• Internet Protocol version 6 (IPv6), RFC 2460
• Internet control message protocol version 4 (ICMPv4), RFC 792
• Internet control message protocol version 6 (ICMPv6), RFC 2463
• Transmission Control Protocol (TCP), RFC 793
• User Data Protocol (UDP), RFC 768]
IPS_NTA_EXT.1.3[IPS] The TSF shall allow the signatures to be assigned to sensor interfaces
configured for promiscuous mode, and to interfaces configured for inline mode, and support
designation of one or more interfaces as ‘management’ for communication between the TOE and
external entities without simultaneously being sensor interfaces.
• Promiscuous (listen-only) mode: [Giga Ethernet];
• Inline (data pass-through) mode: [Giga Ethernet];
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 71 of 133
• Management mode: [Giga Ethernet];
• [
o no other interface types].
5.4.3.4 IPS_SBD_EXT.1[IPS] Signature-Based IPS Functionality
IPS_SBD_EXT.1.1[IPS] The TSF shall support inspection of packet header contents and be able to
inspect at least the following header fields:
• IPv4: Version; Header Length; Packet Length; ID; IP Flags; Fragment Offset; Time to Live
(TTL); Protocol; Header Checksum; Source Address; Destination Address; and IP Options and
[no other field].
• IPv6: Version; payload length; next header; hop limit; source address; destination address;
routing header; and [no other field].
• ICMP: Type; Code; Header Checksum; and [ID, sequence number, [no other field]].
• ICMPv6: Type; Code; and Header Checksum.
• TCP: Source port; destination port; sequence number; acknowledgement number; offset;
reserved; TCP flags; window; checksum; urgent pointer; and TCP options.
• UDP: Source port; destination port; length; and UDP checksum.
IPS_SBD_EXT.1.2[IPS] The TSF shall support inspection of packet payload data and be able to
inspect at least the following data elements to perform string-based pattern-matching:
• ICMPv4 data: characters beyond the first 4 bytes of the ICMP header.
• ICMPv6 data: characters beyond the first 4 bytes of the ICMP header.
• TCP data (characters beyond the 20 byte TCP header), with support for detection of:
i) FTP (file transfer) commands: help, noop, stat, syst, user, abort, acct, allo, appe, cdup, cwd,
dele, list, mkd, mode, nlst, pass, pasv, port, pass, quit, rein, rest, retr, rmd, rnfr, rnto, site, smnt,
stor, stou, stru, and type.
ii) HTTP (web) commands and content: commands including GET and POST, and
administrator-defined strings to match URLs/URIs, and web page content.
iii) SMTP (email) states: start state, SMTP commands state, mail header state, mail body
state, abort state.
iv) [no other types of TCP payload inspection];
• UDP data: characters beyond the first 8 bytes of the UDP header;
• [no other types of packet payload inspection]
IPS_SBD_EXT.1.3[IPS] The TSF shall be able to detect the following header-based signatures (using
fields identified in IPS_SBD_EXT.1.1) at IPS sensor interfaces:
a) IP Attacks
i) IP Fragments Overlap (Teardrop attack, Bonk attack, or Boink attack)
ii) IP source address equal to the IP destination (Land attack)
b) ICMP Attacks
i) Fragmented ICMP Traffic (e.g. Nuke attack)
ii) Large ICMP Traffic (Ping of Death attack)
Page 72 of 133
c) TCP Attacks
i) TCP NULL flags
ii) TCP SYN+FIN flags
iii) TCP FIN only flags
iv) TCP SYN+RST flags
d) UDP Attacks
i) UDP Bomb Attack
ii) UDP Chargen DDoS Attack
IPS_SBD_EXT.1.4[IPS] The TSF shall be able to detect all the following traffic-pattern detection
signatures, and to have these signatures applied to IPS sensor interfaces:
a) Flooding a host (DoS attack)
i) ICMP flooding (Smurf attack, and ping flood)
ii) TCP flooding (e.g. SYN flood)
b) Flooding a network (DoS attack)
c) Protocol and port scanning
i) IP protocol scanning
ii) TCP port scanning
iii) UDP port scanning
iv) ICMP scanning
IPS_SBD_EXT.1.5[IPS] The TSF shall allow the following operations to be associated with
signature-based IPS policies:
• In any mode, for any sensor interface: [
o allow the traffic flow;]
• In inline mode:
o block/drop the traffic flow;
o and [
▪ allow all traffic flow;
]
IPS_SBD_EXT.1.6[IPS] The TSF shall support stream reassembly or equivalent to detect malicious
payload even if it is split across multiple non-fragmented packets
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 73 of 133
5.5 SFRs Drawn from mod_cpp_fw_v1.4e
5.5.1 User Data Protection (FDP)
5.5.1.1 FDP_RIP.2[FW] Full Residual Information Protection
FDP_RIP.2.1[FW] The TSF shall ensure that any previous information content of a resource is
made unavailable upon the [allocation of the resource to] all objects.
5.5.2 Stateful Traffic Filtering (FFW)
5.5.2.1 FFW_RUL_EXT.1[FW] Stateful Traffic Filtering
FFW_RUL_EXT.1.1[FW] The TSF shall perform stateful traffic filtering on network packets
processed by the TOE.
FFW_RUL_EXT.1.2[FW] The TSF shall allow the definition of stateful traffic filtering rules using the
following network protocol fields:
• ICMPv4
o Type
o Code
• ICMPv6
o Type
o Code
• IPv4
o Source address
o Destination Address
o Transport Layer Protocol
• IPv6
o Source address
o Destination Address
o Transport Layer Protocol
o [no other field]
• TCP
o Source Port
o Destination Port
• UDP
o Source Port
o Destination Port
and distinct interface.
FFW_RUL_EXT.1.3[FW] The TSF shall allow the following operations to be associated with Stateful
Traffic Filtering rules: permit or drop with the capability to log the operation.
FFW_RUL_EXT.1.4[FW] The TSF shall allow the Stateful Traffic Filtering rules to be assigned to
each distinct network interface.
Page 74 of 133
FFW_RUL_EXT.1.5[FW] The TSF shall:
a) accept a network packet without further processing of Stateful Traffic Filtering rules if it
matches an allowed established session for the following protocols: TCP, UDP, [no other
protocols] based on the following network packet attributes:
1. TCP: source and destination addresses, source and destination ports, sequence
number, Flags;
2. UDP: source and destination addresses, source and destination ports;
3. [no other protocols].
b) Remove existing traffic flows from the set of established traffic flows based on the
following: [session inactivity timeout, completion of the expected information flow].
FFW_RUL_EXT.1.6[FW] The TSF shall enforce the following default Stateful Traffic Filtering rules
on all network traffic:
a) The TSF shall drop and be capable of [logging] packets which are invalid fragments;
b) The TSF shall drop and be capable of [logging] fragmented packets which cannot be
re-assembled completely;
c) The TSF shall drop and be capable of logging packets where the source address of
the network packet is defined as being on a broadcast network;
d) The TSF shall drop and be capable of logging packets where the source address of
the network packet is defined as being on a multicast network;
e) The TSF shall drop and be capable of logging network packets where the source
address of the network packet is defined as being a loopback address;
f) The TSF shall drop and be capable of logging network packets where the source or
destination address of the network packet is defined as being unspecified (i.e.
0.0.0.0) or an address “reserved for future use” (i.e. 240.0.0.0/4) as specified in RFC
5735 for IPv4;
g) The TSF shall drop and be capable of logging network packets where the source or
destination address of the network packet is defined as an “unspecified address” or
an address “reserved for future definition and use” (i.e. unicast addresses not in this
address range: 2000::/3) as specified in RFC 3513 for IPv6;
h) The TSF shall drop and be capable of logging network packets with the IP options:
Loose Source Routing, Strict Source Routing, or Record Route specified; and
i) [[Other traffic dropped by default and able to be logged:
i. Slowpath Security Checks – The TSF shall reject and be capable of logging the
detection of the following network packets:
1. In routed mode when the TOE receives a through-the-box:
a. L2 broadcast packet (MAC address FF:FF:FF:FF:FF:FF)
b. IPv4 packet with destination IP address equal to 0.0.0.0
c. IPv4 packet with source IP address equal to 0.0.0.0
2. In routed or transparent mode when the TOE receives a through-the-
box IPv4 packet with any of:
a. first octet of the source IP address equal to zero
b. network part of the source IP address equal to all 0's
c. network part of the source IP address equal to all 1's
d. source IP address host part equal to all 0's or all 1's
e. source IP address and destination IP address are the same
(“land.c” attack)
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 75 of 133
ii. LAND Attack: The TSF shall reject and be capable of logging network packets
with the IP source address equal to the IP destination, and the destination port
equal to the source port.
iii. ICMP Error Inspect and ICMPv6 Error Inspect - The TSF shall reject and be
capable of logging ICMP error packets when the ICMP error messages are not
related to any session already established in the TOE.
iv. ICMPv6 condition - The TSF shall reject and be capable of logging network
packets when the appliance is not able to find any established connection
related to the frame embedded in the ICMPv6 error message.
v. ICMP Inspect bad icmp code - The TSF shall reject and be capable of logging
network packets when an ICMP echo request/reply packet was received with a
malformed code(non-zero)]].
FFW_RUL_EXT.1.7[FW] The TSF shall be capable of dropping and logging according to the
following rules:
a) The TSF shall drop and be capable of logging network packets where the source address of
the network packet is equal to the address of the network interface where the network
packet was received;
b) The TSF shall drop and be capable of logging network packets where the source or
destination address of the network packet is a link-local address;
c) The TSF shall drop and be capable of logging network packets where the source address of
the network packet does not belong to the networks associated with the network interface
where the network packet was received.
FFW_RUL_EXT.1.8[FW] The TSF shall process the applicable stateful traffic filtering rules in an
administratively defined order.
FFW_RUL_EXT.1.9[FW] The TSF shall deny packet flow if a matching rule is not identified.
FFW_RUL_EXT.1.10[FW] The TSF shall be capable of limiting an administratively defined number
of half-open TCP connections. In the event that the configured limit is reached, new connection
attempts shall be dropped and the drop event shall be [counted].
5.5.2.2 FFW_RUL_EXT.2[FW] Stateful Filtering of Dynamic Protocols
FFW_RUL_EXT.2.1[FW] The TSF shall dynamically define rules or establish sessions allowing
network traffic to flow for the following network protocols [FTP].
5.5.3 Security Management (FMT)
5.5.3.1 FMT_SMF.1/FFW[FW] Specification of Management Functions
FMT_SMF.1.1/FFW[FW] The TSF shall be capable of performing the following management
functions:
• Ability to configure firewall rules
Page 76 of 133
5.6 SFRs from mod_vpngw_v1.1
5.6.1 Cryptographic Support (FCS)
5.6.1.1 FCS_CKM.1/IKE[VPN] Cryptographic Key Generation (for IKE Peer
Authentication)
FCS_CKM.1.1/IKE[VPN] The TSF shall generate asymmetric cryptographic keys used for IKE
peer authentication in accordance with a specified cryptographic key generation algorithm: [
• FIPS PUB 186-4, “Digital Signature Standard (DSS)”; Appendix B.3 for RSA schemes;
• FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for ECDSA
schemes and implementing “NIST curves” P-256, P-384 and [P-521]
]
and
[no other key generation algorithms]
and specified cryptographic key sizes [equivalent to, or greater than, a symmetric key strength of 112
bits].
5.6.2 Identification and authentication (FIA)
5.6.2.1 FIA_PSK_EXT.1[VPN] Pre-Shared Key Composition
FIA_PSK_EXT.1.1[VPN] The TSF shall be able to use pre-shared keys for IPsec and [no other
protocols].
FIA_PSK_EXT.1.2[VPN] The TSF shall be able to accept text-based pre-shared keys that:
• are 22 characters and [[up to 127 characters]];
• composed of any combination of upper and lower case letters, numbers, and special
characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”).
FIA_PSK_EXT.1.3[VPN] The TSF shall condition the text-based pre-shared keys by using [SHA1,
SHA-256, SHA-512, [SHA-384]].
FIA_PSK_EXT.1.4[VPN] The TSF shall be able to [accept] bit-based pre-shared keys.
5.6.3 Security management (FMT)
5.6.3.1 FMT_SMF.1/VPN[VPN] Specification of Management Functions (VPN
Gateway)
FMT_SMF.1.1/VPN[VPN] The TSF shall be capable of performing the following management
functions: [
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 77 of 133
• Definition of packet filtering rules;
• Association of packet filtering rules to network interfaces;
• Ordering of packet filtering rules by priority;
[
• No other capabilities
]]
5.6.4 Packet Filtering (FPF)
5.6.4.1 FPF_RUL_EXT.1[VPN] Packet Filtering
FPF_RUL_EXT.1.1[VPN] The TSF shall perform Packet Filtering on network packets processed by
the TOE.
FPF_RUL_EXT.1.2[VPN] The TSF shall allow the definition of Packet Filtering rules using the
following network protocols and protocol fields:
• IPv4(RFC 791)
o Source address
o Destination Address
o Protocol
• IPv6(RFC 2460)
o Source address
o Destination Address
o Next Header (Protocol)
• TCP(RFC 793)
o Source Port
o Destination Port
• UDP(RFC 768)
o Source Port
o Destination Port
FPF_RUL_EXT.1.3[VPN] The TSF shall allow the following operations to be associated with Packet
Filtering rules: permit and drop with the capability to log the operation.
FPF_RUL_EXT.1.4[VPN] The TSF shall allow the Packet Filtering rules to be assigned to each
distinct network interface.
FPF_RUL_EXT.1.5[VPN] The TSF shall process the applicable Packet Filtering rules (as determined
in accordance with FPF_RUL_EXT.1.4) in the following order: Administrator-defined.
FPF_RUL_EXT.1.6[VPN] The TSF shall drop traffic if a matching rule is not identified.
Page 78 of 133
5.6.5 Protection of the TSF (FPT)
5.6.5.1 FPT_FLS.1/SelfTest[VPN] Fail Secure
FPT_FLS.1.1/SelfTest[VPN] The TSF shall shut down when the following types of failures occur:
[failure of the power-on self-tests, failure of integrity check of the TSF executable image, failure of
noise source health tests]
1.1.1.1 FPT_TST_EXT.3[VPN]: Self-Test with Defined Methods
FPT_TST_EXT.3.1[VPN] The TSF shall run a suite of the following self-tests [[when loaded for
execution]] to demonstrate the correct operation of the TSF: [integrity verification of stored
executable code].
FPT_TST_EXT.3.2[VPN] The TSF shall execute the self-testing through [a TSF-provided
cryptographic service specified in FCS_COP.1/SigGen].
5.6.6 TOE Access (FTA)
5.6.6.1 FTA_SSL.3/VPN[VPN] TSF-initiated Termination (VPN Headend)
FTA_SSL.3.1/VPN[VPN] The TSF shall terminate a remote VPN client session after an
[Administrator-configurable time interval of session inactivity].
5.6.6.2 FTA_TSE.1[VPN] TOE Session Establishment
FTA_TSE.1.1[VPN] The TSF shall be able to deny establishment of a remote VPN client session
based on [location, time, day, [no other attributes].
5.6.6.3 FTA_VCM_EXT.1[VPN] VPN Client Management
FTA_VCM_EXT.1.1[VPN] The TSF shall assign a private IP address to a VPN client upon successful
establishment of a security session.
5.6.7 Trusted Path/Channels (FTP)
5.6.7.1 FTP_ITC.1/VPN[VPN] Inter-TSF Trusted Channel (VPN Communications)
FTP_ITC.1.1/VPN[VPN] The TSF shall be capable of using IPsec to provide a communication
channel between itself and authorized IT entities supporting VPN communications 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/VPN[VPN] The TSF shall permit [the authorized IT entities] to initiate communication
via the trusted channel.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 79 of 133
FTP_ITC.1.3/VPN[VPN] The TSF shall initiate communication via the trusted channel for [remote
VPN gateways/peers].
5.7 TOE SFR Dependencies Rationale for SFRs Found in NDcPP and PP-
modules
The NDcPP and PP modules contain all the requirements claimed in this Security Target. As such
the dependencies are not applicable since the PP itself has been approved.
5.8 Security Assurance Requirements
5.8.1 SAR Requirements
The TOE assurance requirements for this ST are taken directly from the NDcPP which are derived
from Common Criteria Version 3.1, Revision 5. The assurance requirements are summarized in the
table below.
Table 20: Assurance Measures
Assurance Class Components Components Description
DEVELOPMENT ADV_FSP.1 Basic Functional Specification
GUIDANCE DOCUMENTS AGD_OPE.1 Operational User Guidance
AGD_PRE.1 Preparative User Guidance
LIFE CYCLE SUPPORT ALC_CMC.1 Labeling of the TOE
ALC_CMS.1 TOE CM Coverage
TESTS ATE_IND.1 Independent Testing - Conformance
VULNERABILITY
ASSESSMENT
AVA_VAN.1 Vulnerability Analysis
5.8.2 Security Assurance Requirements Rationale
This Security Target claims conformance to the NDcPP. This target was chosen to ensure that the
TOE has a basic to moderate level of assurance in enforcing its security functions when instantiated
in its intended environment which imposes no restrictions on assumed activity on applicable
networks. The ST also claims conformance to mod_ips_v1.0, mod_cpp_fw_v1.4e and
mod_vpngw_v1.1, which includes refinements to assurance measures for the SFRs defined in the
two aforementioned modules including augmenting the vulnerability analysis (AVA_VAN.1) with
specific vulnerability testing.
5.9 Assurance Measures
The TOE satisfies the identified assurance requirements. This section identifies the Assurance
Measures applied by Cisco to satisfy the assurance requirements. The table below lists the details.
Table 21: Assurance Measures
Page 80 of 133
Component How requirement will be met
ADV_FSP.1 The functional specification describes the external interfaces of the TOE; such as the
means for a user to invoke a service and the corresponding response of those services.
The description includes the interface(s) that enforces a security functional requirement,
the interface(s) that supports the enforcement of a security functional requirement, and
the interface(s) that does not enforce any security functional requirements. The
interfaces are described in terms of their purpose (general goal of the interface), method
of use (how the interface is to be used), parameters (explicit inputs to and outputs from
an interface that control the behavior of that interface), parameter descriptions (tells
what the parameter is in some meaningful way), and error messages (identifies the
condition that generated it, what the message is, and the meaning of any error codes).
The development evidence also contains a tracing of the interfaces to the SFRs described
in this ST.
AGD_OPE.1 The Administrative Guide provides the descriptions of the processes and procedures of
how the administrative users of the TOE can securely administer the TOE using the
interfaces that provide the features and functions detailed in the guidance.
AGD_PRE.1 The Installation Guide describes the installation, generation, and startup procedures so
that the users of the TOE can put the components of the TOE in the evaluated
configuration.
ALC_CMC.1 The Configuration Management (CM) document(s) describes how the consumer (end-
user) of the TOE can identify the evaluated TOE (Target of Evaluation). The CM
document(s), identifies the configuration items, how those configuration items are
uniquely identified, and the adequacy of the procedures that are used to control and
track changes that are made to the TOE. This includes details on what changes are
tracked, how potential changes are incorporated, and the degree to which automation is
used to reduce the scope for error.
ALC_CMS.1
ATE_IND.1 Cisco provides the TOE for testing.
AVA_VAN.1 Cisco provides the TOE for testing.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 81 of 133
6 TOE SUMMARY SPECIFICATION
6.1 TOE Security Functional Requirement Measures
This chapter identifies and describes how the Security Functional Requirements identified above
are met by the TOE.
Table 22: How TOE SFRs Are Satisfied
TOE SFRs How the SFR is Satisfied
Security Functional Requirements Drawn from NDcPP
FAU_GEN.1,
FAU_GEN_EXT.1,
FAU_STG_EXT.1,
FAU_STG_EXT.4,
FAU_STG_EXT.5
Auditing is the recording of events within the system. The TOE generates log records for a
wide range of security relevant and other events as they occur. The events that can cause an
audit record to be logged include starting the audit function2, any use of an administrator
command or action via the CLI and web interfaces, and all of the required auditable events
identified in Table 18. For more information about the required audit events, please refer to
Table 18 and the operational user guide (also known as the CC Supplemental User guide).
The FMC component of the TOE can generate an audit record for each user interaction with
the web interface and each command in the CLI interface. The FTD component of the TOE can
generate traffic events as part of the access control (firewall), IPS and VPN policies and these
event records are stored in logs separate from the audit logs for performance and security
reasons. For more details about which auditable events are mapped to which SFRs, refer to
Table 31.
FMC and FTD log auditing information for all user activity in a read-only format. Modifications
are not allowed by the interfaces and only authorized administrators can delete the audit logs.
Audit logs are presented in a standard event view that allows administrators to view, sort,
and filter audit log messages based on any item in the audit view. The audit view contains
columns with information field for each audit event such as time, user, subsystem, message,
and source IP. Please see the figure below for example.
Figure 6: Audit View
The following fields are recorded for each audit event in the audit view:
2
Note that the audit function cannot be disabled other than shutting down the entire system.
Page 82 of 133
TOE SFRs How the SFR is Satisfied
• Time: The time and date that the appliance generated the audit record.
• User: The user name of the user that triggered the audit event.
• Subsystem: The menu path the user followed to generate the audit record. For
example, “System > Monitoring > Audit” is the menu path to view the audit log.
• Message: The action the user performed. For example, “Page View” signifies that the
user simply viewed the page indicated in the Subsystem, while “Save” means that the
user clicked the Save button on the page.
• Source IP: The IP address of the host used by the user.
Figure 7: Syslog View
The user can also view the audit log using the command “show audit-log” or “show syslog” via
the CLI interface. All GUI actions and CLI commands are recorded in the audit log and can only
be viewed by authorized administrators. To distinguish between the two, the Subsystem field
will identify “Command Line” for commands and the Message field will identify the executed
command.
In general, the logged audit records identify the date and time, the identity of the actor (e.g.,
user, daemon, or network host) responsible for the event, the subsystem that triggers the
event, an indication of whether the event succeeded, failed or had some other outcome (if
applicable), and the source IP (if applicable). The logged audit records also include event-
specific content that includes at least all of the content required in table above.
The TOE (FMC) includes an internal log database implementation that can be used to store
and review audit records locally. However, the internal log only stores a default of 100,000
entries in the local database (to configure the size, go to System > Configuration > Database,
and click on “Audit Event Database”). When the audit log is full, the oldest audit records are
overwritten by the newest audit records. In addition, the TOE (FMC) also includes a local
syslog storage in /var/log/messages and these logs are viewable through the FMC GUI. The
contents are stored in flat files which are rotated automatically. Similar to the audit log, when
the syslog is full, the oldest syslog messages are overwritten by the newest one.
For audit log, the events are stored in partitioned event tables. The TOE will prune (i.e.,
delete) the oldest partition whenever the oldest partition can be pruned without dropping the
number of events count below the configured event limit. Note this limit defaults to 10,000 if
you set it any lower. For example, if you set the limit to 10,000 events, the events count may
need to exceed 15,000 events before the oldest partition can be deleted. For syslog, the logs
are stored in /var/log/messages and are rotated daily or when the log file size exceeds 25 MB.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 83 of 133
TOE SFRs How the SFR is Satisfied
After the maximum number of backlog files is reached, the oldest is deleted and the numbers
on the other backlogs file are incremented.
To prevent the losing of critical audit records, the administrators can configure the system to
transmit all the audit events (i.e., audit log and syslog) in real-time over a secure TLS
connection or an IPsec connection (FTD-only) to an external audit server in the operational
environment. When an audit event is generated, it is sent to the local storage and external
audit server simultaneously. This ensures that current audit events can be viewed locally
while all events, new or old, are stored off-line as required by the NDcPP.
Note that the protection of the audit records stored at the external audit server is the
responsibility of the operational environment. The TOE is only responsible for the secure
communication channel. It is recommended that the audit server is physically or logically
separated (e.g., VLANs) from the other networks.
The TOE can be configured to export syslog records to an administrator-specified, external
syslog server. The TOE can be configured to encrypt the communications with an external
syslog server using IPsec or TLS. FMC transmits syslog over TLS and FTD transmits syslog
over TLS and IPsec.
The audit records are also stored locally and when the local storage is full, the newest data
will overwrite the oldest data. On FMC, log messages (those generated locally and those
forwarded from FTD) are stored locally on FMC in a database. Different message types are
stored separately in local databases, and each local store has a separately configurable size
limit (configurable in FMC via System > Configuration > Database). Audit events recording
FMC administrator actions are stored in the Audit Event Database, network traffic events
transmitted from FTD to FMC are stored in separate databases on FMC: firewall events
(triggered by Access Control Policy rules) are stored in Connection Database; VPN events are
stored in the VPN Troubleshooting Database; and the IPS events are stored in Intrusion Event
Database.
Messages generated by FTD, including FTD system messages, firewall events, and VPN events
are stored locally on FTD and are immediately transmitted from FTD to an external syslog
server. As mentioned in the preceding paragraph, the firewall, VPN and IPS events are directly
sent to FMC for retention in the FMC databases via secure TLS channel (Note: The IPS events
are not stored locally on FTD but are transmitted to an external syslog server via the FMC. IPS
events generated on FTD are temporarily stored locally on FTD in a database prior to
transmission to FMC). If the connection between FTD and FMC is interrupted, the IPS
messages are transmitted once connectivity is restored. As the system, firewall event and VPN
event messages are generated by FTD, they are immediately transmitted from FTD to a remote
syslog server and stored in a local buffer (buffer size configurable from 4096-52428800
bytes) which overwrites old messages with new ones when storage limits are reached. The
local logs are viewable from the FTD CLI shell by using “show logging”.
For audit messages related to management of cryptographic keys, the audit message details
include the name of the certificate associated with the key.
Network interfaces have bandwidth limitations, and other traffic flow limitations that are
configurable. When an interface has exceeded a limit for processing traffic, traffic will be
dropped, and audit messages can be generated.
For more information on the required auditable events and the actual logs themselves, please
refer to the Preparative Procedures & Operational User Guide for the Common Criteria
Certified Configuration.
The following high-level events are auditable by the TOE:
Page 84 of 133
TOE SFRs How the SFR is Satisfied
Auditable Event Rationale
Modifications to the group
of users that are part of the
authorized administrator
role.
All changes to the configuration (and hence all
security relevant administrator actions) are logged
when the logging level is set to at least the
'notifications' level. These changes would fall into
the category of configuration changes such as
enabling or disabling features and services. The
identity of the administrator taking the action and
the user being affected (assigned to the authorized
administrator role) are both included within the
event.
All use of the user
identification mechanism.
Events will be generated for attempted
identification/ authentication, and the username
attempting to authenticate will be recorded in the
event.
Any use of the
authentication mechanism.
Events will be generated for attempted
identification/ authentication, and the username
attempting to authenticate will be recorded in the
event along with the origin or source of the
attempt.
The reaching of the
threshold for unsuccessful
authentication attempts
and the subsequent
restoration by the
authorized administrator
of the user’s capability to
authenticate.
Failed attempts for authentication will be logged,
and when the threshold is reached, it will also be
logged.
All changes to the configuration are logged when
the logging level is set to at least the 'notifications'
level. Changes to restore a locked account would
fall into the category of configuration changes.
All decisions on requests
for information flow.
In order for events to be logged for information
flow requests, the 'log' keyword may need to be in
each line of an access control list. The presumed
addresses of the source and destination subjects
are included in the event.
Success and failure, and
the type of cryptographic
operation
Attempts for VPN connections are logged (whether
successful or failed). Requests for encrypted
session negotiation are logged (whether successful
or failed). The identity of the user performing the
cryptographic operation is included in the event.
Failure to establish and/or
establishment/termination
of an IPsec session
Attempts to establish an IPsec tunnel or the failure
of an established IPsec tunnel is logged as well as
successfully established and terminated IPsec
sessions with peer.
Establishing session with
CA and IPsec peer
The connection to CA’s or any other entity (e.g.,
CDP) for the purpose of certificate verification or
revocation check is logged. In addition, the TOE
can be configured to capture the packets’ contents
during the session establishment.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 85 of 133
TOE SFRs How the SFR is Satisfied
Changes to the time. Changes to the time are logged with old and new
time values.
Use of the functions listed
in any SFR pertaining to
audit.
All changes to the configuration are logged when
the logging level is set to at least the 'notifications'
level. These changes would fall into the category of
configuration changes.
Loss of connectivity with
an external syslog server.
Loss of connectivity with an external syslog server
is logged as a terminated or failed cryptographic
channel.
Initiation of an update to
the TOE.
TOE updates are logged as configuration changes.
Termination of local and
remote sessions.
Note that the TOE does not
support session locking, so
there is no corresponding
audit.
Termination of a local and remote session is
logged. This also includes termination of remote
VPN session as well. The user may initiate or the
system may terminate the session based idle
timeout setting.
Initiation, termination and
failures in trusted channels
and paths.
Requests for encrypted session negotiation are
logged (whether successful or failed). Similarly,
when an established cryptographic channel or path
is terminated or fails a log record is generated.
This applies to HTTPS, TLS, IPsec, and SSH.
Successful SSH rekey SSH rekey event is logged.
Application of rules
configured with the ‘log’
operation
Logs are generated when traffic matches ACLs that
are configured with the log operation.
Indication of packets
dropped due to too much
network traffic
Logs are generated when traffic that exceeds the
settings allowed on an interface is received.
FAU_GEN.2 The TOE ensures each action performed by the administrator at the CLI and FMC web UI is
logged with the administrator’s identity and as a result events are traceable to a specific user.
FCO_CPC_EXT.1 In order for TOE components to communicate as part of a distributed TOE System, they
must successfully complete a registration process. Each TOE component comes with a
manufacture’s TLS certificate. To start the registration process, the administrator must
enable or register the TOE components. On the FMC, the administrator must go to Device
Management UI and click on “Add Device”. At the same time, the administrator must go to
the FTD CLI, and click or enter “Configure Manager Add”. The administrator must specify
the peer hostname or IP address and the registration key used for the initial authentication.
During the registration process, the manufacture’s TLS certificates are used to setup the
initial TLS channel on the internal trusted management network. If the authentication
succeeded, the resident CA on the FMC will sign and issue a TLS certificate along with the
Page 86 of 133
TOE SFRs How the SFR is Satisfied
private key to the FTD which will be used for subsequent TLS channel. To disable or de-
register FTD, the administrator must initiate a “Delete Device” on the FMC Device
Management UI and then perform a “Configure Manager Delete” action on the FTD CLI. This
will destroy (i.e., zeroize) the TLS certificate and private key. Once this has occurred, no
farther communication can happen without another registration process.
FCS_CKM.1, FCS_CKM.2,
FCS_CKM.4, FCS_COP.1/
DataEncryption,
FCS_COP.1/SigGen,
FCS_COP.1/Hash,
FCS_COP.1/ KeyedHash,
and FCS_RBG_EXT.1
Each FMC and each FTD appliance utilize a cryptographic module (i.e., Cisco FIPS Object
Module) to provide supporting cryptographic functions. When the term “TOE” is used in this
section, it refers to each appliance.
The algorithm implementations have been tested in accordance to validation suites set by the
Cryptographic Algorithm Validation Program (CAVP) and tested on specific processors. Refer
to section 7.4 of this document for the listings of CAVP certificate for each TOE component for
each SFR.
The algorithms supported for keyed-hash message authentication are HMAC-SHA-1 (block
size – 512 bits), HMAC-SHA-256 (block size – 512 bits), HMAC-SHA-384 (block size – 1024
bits) and HMAC-SHA-512 (block size – 1024 bits) with key sizes 160, 256, 384 and 512 bits
and message digest sizes of 160, 256, 384 and 512 bits respectively.
The TOE supports RSA and ECDSA in the evaluated configuration. RSA and ECDSA digital
signature are used in TLS connections and SSH connections (RSA only). The TOE can be
configured to use RSA and ECDSA to authenticate IPsec connections.
Key generation for asymmetric keys on all models of the TOE implements ECDSA with NIST
curve sizes P-256, P-384, and P-521 according to FIPS PUB 186-4, “Digital Signature Standard
(DSS)”, Appendix B.4 and RSA with key sizes 2048 and 3072 bits according to FIPS PUB 186-4,
“Digital Signature Standard (DSS)”, Appendix B.3. Asymmetric cryptographic keys used for
IKE peer authentication are generated according to FIPS PUB 186-4, Appendix B.3 for RSA
schemes and Appendix B.4 for ECDSA schemes. The TOE does not implement any
functionality defined as ‘shall not/should/should not’ and does not omit any functionality
related to ‘shall/should’ statements in Appendix B.3 and B.4. There are no TOE-specific
extensions, processing or alternative implementations that are not included in the
Appendices.
Key establishment for asymmetric keys on the TOE implements RSA-based (RSAES-PKCS1-
v1_5 as specified in Section 7.2 of RFC 3447), ECDSA-based and DH-based key establishment
schemes as specified in NIST SP 800-56A “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”. In addition, the TOE also supports DH
group 14 key establishment scheme that meets standard RFC 3526, section 3 for
interoperability. The TOE's software implementation uses the prime number and generator
value specified in RFC 3526 Section 3 when generating parameters for the DH Group 14 key
exchange.
Scheme SFR Services
RSA
FCS_TLSS_EXT.1,
FCS_IPSEC_EXT.1, FCS_SSHS_EXT.1,
FCS_TLSC_EXT.1,
FCS_TLSC_EXT.2
HTTPS Remote
Administration, SSH
Remote Administration,
syslog over IPsec,
Distributed TOE
Communication, Syslog
over TLS.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 87 of 133
TOE SFRs How the SFR is Satisfied
ECC (P-256,
P-384, P-521)
FCS_TLSC_EXT.1,
FCS_TLSC_EXT.2,
FCS_IPSEC_EXT.1
Syslog over TLS, Syslog
over IPsec
ECC (P-256,
P-384, P-521)
FCS_TLSS_EXT.1
HTTPS Remote
Administration
Diffie-Hellman (Group
14)
FCS_SSHS_EXT.1
FCS_IPSEC_EXT.1
SSH Remote
Administration, IKE
communication.
The TOE uses a platform-based random bit generator that complies with ISO/IEC 18031:2011
using CTR_DRBG (AES-256) Deterministic Random Bit Generation (DRBG) operating in FIPS
mode. In addition, the DRBG is seeded by an entropy source that is at least 256-bit value
derived from various highly sensitive and proprietary noise sources described in the
proprietary Entropy Design document.
Additionally, the TOE is designed to zeroize secret and private keys when they are no longer
required by the TOE. The table in section 7.3 identifies the applicable secret and private keys
and summarizes how they are deleted. The secret keys used for symmetric encryption, private
keys, and CSPs used to generate keys, are zeroized immediately after use (for IPsec VPN
functions, within FTD only), or on system shutdown (for all other functions). For plaintext
keys unrelated to IPsec VPN: the TOE destroys the reference to the keys stored in volatile
memory directly followed by a request for garbage collection; the TOE destroys the
abstraction that represents the key for keys stored in non-volatile storage the TSF.
FCS_HTTPS_EXT.1
FCS_TLSC_EXT.1
FCS_TLSC_EXT.2
FCS_TLSS_EXT.1
The TOE implements HTTP over TLS (or HTTPS) to support remote administration on FMC,
TLS clients to support secure syslog connections, and TLS server and clients to support
FPT_ITT.1. A remote administrator can connect over HTTPS to the TOE with their web
browser. FTD supports two different TLS clients that send syslog messages to the external
syslog server- FTD TLS client and FTD OS TLS Client.
When CC mode is enabled, the TOE is restricted to only support TLSv1.2 for HTTPS sessions
and client/server communications between TOE components and both TLSv1.1 and TLSv1.2
for syslog communications with AES 128- or 256-bit symmetric ciphers in CBC and GCM
modes, in conjunction with SHA, RSA, and ECDSA. The FMC HTTPS/TLS interface only
supports TLSv1.2. The TOE implements HTTPS according to RFC 2818 by using a TLSv1.2
session to secure the HTTP connection. The following TLS cipher suites are implemented by
the TOE in CC mode:
• Relevant to FTP_ITC and FCS_TLSC_EXT.1, FTD TLS client, that is configured by the
FMC and is the main audit system for audits generated by FTD. It sends audit events
such as IPsec and login messages to the external syslog server and mutual
authentication is not supported. Listed in Section 5.3.3.12.
• Relevant to FTP_ITC and FCS_TLSC_EXT.2, FTD OS TLS client, that is configured
through the FTD’s command line and sends audit events to an external syslog server
such as SSH login, console login, etc. and mutual authentication is not supported.
Listed in Section 5.3.3.12.
• Relevant to FTP_ITC and FCS_TLSC_EXT.2, for syslog over TLS from FMC/FMCv
(client only) as listed in Section 5.3.3.12 of this document. Mutual authentication is
supported.
Page 88 of 133
TOE SFRs How the SFR is Satisfied
• Relevant to FPT_ITT, FCS_TLSC_EXT.1, and FCS_TLSS_EXT.1 (client and server
between FMC and FTD) are as listed in sections 5.3.3.12 and 5.3.3.14 of this
document.
• Relevant to FTP_TRP.1/Admin and FCS_TLSS_EXT.1 (server only) are as listed in
section 5.3.3.14 of this document (FMC only)
While the cryptographic modules of the TOE support additional cipher suites (for example,
RSA_3DES_EDE_CBC_SHA, RSA_DES_CBC_SHA, RSA_RC4_128_MD5, RSA_RC4_128_SHA, etc.),
they are all disabled while operating in CC mode. If the TLS client does not support TLSv1.2,
the TLS connection will fail and the administrators will not establish a HTTPS web-based
session with the TOE.
The Key establishment parameters for each of the TLS connections in the TOE are as follows –
1. FMC/FMCv (HTTPS/TLS)- 2048-bit RSA, and ECDHE secp256r1, secp384r1 and
secp521r1
2. FMC/FMCv and FTD (ITT) – 2048-bit RSA, and ECDHE secp256r1, secp384r1 and
secp521r1
When in CC mode and the TOE acts as a TLS client (e.g., connection to the syslog server), the
TOE will verify the server Subject Alternative Name (SAN) against the reference identity
(wildcard is supported as required in section 6 of RFC 6125 and per RFC 5280 Appendix A.
RFC 5280 is supported for the TLS connection between the distributed TOE components (FMC
and FTD) and the attribute type “id-at-title” is used by the TOE client to match the presented
identifier with the configured identifier). If verification fails, the TLS connection will not be
established. The following NIST curves are presented with the Client Hello by default –
secp256r1, secp384r1 and secp521r1. Mutual authentication must be configured with the
client-side X.509v3 certificate with RSA 2048-bits (or higher) and SHA-256 (or higher). The
key agreement parameters of the server key exchange message are specified in the RFC 5246
(section 7.4.3) for TLSv1.2 and RFC 4346 (section 7.4.3) for TLSv1.1. The TOE conforms to
both RFCs.
The FMC and FTD must successfully complete a registration process to communicate, which
requires administrative actions on the FMC and corresponding administrative actions on the
FTD. The administrative actions on FMC and FTD require the administrator to input a
“registration key” that the two devices will use to authenticate their initial TLS
communications. During the registration process, the FMC and FTD confirm they have a
matching registration key and use their initial self-signed TLS certificates to uniquely identify
themselves to each other (each device certificate signed by FMC, including its own, contains a
unique identifier stored as an ‘id-at-title’ attribute, which FMC and FTD each as the unique
reference identifier for each other). If the authentication succeeds, the local CA within the
FMC will sign and issue a new TLS certificate for the FTD and send (over the existing TLS
session) the FTD’s new identity certificate and associated keys, and the FMC’s root CA cert,
and the FMC’s root CA certificate and the device certificates which it signed will be used to
authenticate all subsequent TLS sessions between the two devices. If device registration fails
due to mismatched registration keys, or incorrect IP address or hostname, the information on
the FMC and/or FTD needs to be corrected and the registration from FMC reinitiated.
TLS session resumption is supported for the following TLS connection of the TOE – the WebUI
of the FMC/FMCv. The session tickets used for TLS session resumption are encrypted using
symmetric algorithms consistent with FCS_COP.1/DataEncryption claims in this ST – AES
used in CBC and GCM modes and key sizes of 128 and 256 bits. The session tickets adhere to
the structural format provided in section 4 of RFC 5077.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 89 of 133
TOE SFRs How the SFR is Satisfied
FCS_IPSEC_EXT.1,
FCS_IPSEC_EXT.1[VPN]
FTD only
The IPsec implementation provides VPN peer-to-peer, VPN site-to-site, and VPN client to
TOE (i.e., remote access) capabilities. The VPN site-to-site tunnel allows for example the
TOE acting as a VPN gateway and another TOE to establish an IPsec tunnel to secure the
passing of user data. Another configuration is the peer-to-peer configuration where the
TOE can be set up with an IPsec tunnel with a VPN peer to secure the session between the
TOE and the VPN peer. The VPN client to TOE configuration is where a remote VPN client
connects into the TOE in order to gain access to an authorized private network.
Authenticating with the TOE would give the VPN client a secure IPsec tunnel to connect
over the internet into their private network.
The TOE implements IPsec to provide both X509v3 certificate and pre-shared key-based
authentications and encryption services to prevent unauthorized viewing or modification of
data as it travels over the external network. The TOE implementation of the IPsec standard
(in accordance with the RFCs noted in the SFR) uses the Encapsulating Security Payload
(ESP) protocol to provide authentication, encryption and anti-replay services. In addition,
the TOE supports both transport and tunnel modes. Transport mode is only supported for
peer-to-peer IPsec connection while tunnel mode is supported for all VPN connections
including remote access.
IPsec Internet Key Exchange, also called IKE, is the negotiation protocol that lets two peers
agree on how to build an IPsec Security Association (SA). In the evaluated configuration,
only IKEv2 is supported. The IKEv2 protocols implement Peer Authentication using the RSA
and ECDSA algorithms with X.509v3 certificates, or pre-shared keys. IKEv2 separates
negotiation into two phases: SA and Child SA. IKE SA creates the first tunnel, which protects
later IKE negotiation messages. The key negotiated in IKE SA enables IKE peers to
communicate securely in IKE Child SA. During Child SA IKE establishes the IPsec SA. IKE
maintains a trusted channel, referred to as a Security Association (SA), between IPsec peers
that is also used to manage IPsec connections, including:
• The negotiation of mutually acceptable IPsec options between peers (including
peer authentication parameters, either signature based or pre-shared key based),
• The establishment of additional Security Associations to protect packet flows using
Encapsulating Security Payload (ESP), and
The agreement of secure bulk data encryption AES keys for use with ESP. After the two
peers agree upon a policy, the security parameters of the policy are identified by an SA
established at each peer, and these IKE SAs apply to all subsequent IKE traffic during the
negotiation
The TOE implements IPsec using the ESP protocol as defined by RFC 4303, using the
cryptographic algorithms AES-CBC-128, AES-CBC-256, AES-GCM-128 and AES-GCM-256
(both specified by RFCs 3602 and 4106) along with SHA-based HMAC algorithms, and using
IKEv2, as specified for FCS_IPSEC_EXT.1.5, to establish security associations. NAT traversal
is supported in IKEv2 by default.
The IKE SA exchanges use only main mode and the IKE SA lifetimes are able to be limited to
24 hours for Phase 1 (SAs) and 8 hours for Phase 2 (Child SAs). Administrators can
configure the mode for each IPsec tunnel, as in the following examples:
Page 90 of 133
TOE SFRs How the SFR is Satisfied
Devices > VPN > Site To Site or Devices > VPN > Remote Access
IKE Options (click on IKE tab)
IKEv2 Mode
Tunnel mode — (default) Encapsulation mode is set to tunnel mode. Tunnel mode applies
ESP encryption and authentication to the entire original IP packet (IP header and data),
hiding the ultimate source and destination addresses and becoming the payload in a new IP
packet.
Transport preferred — Encapsulation mode is set to transport mode with an option to
fallback to tunnel mode if the peer does not support it. In Transport mode only the IP
payload is encrypted, and the original IP headers are left intact.
Transport required — Encapsulation mode is set to transport mode only, falling back to
tunnel mode is not allowed. If the endpoints cannot successfully negotiate transport mode,
due to one endpoint not supporting it, the VPN connection is not made.
Lifetime (seconds) – The number of seconds a security association exists before expiring is
in the range between 120 and 2,147,483,647 seconds. The default is 28,800 seconds.
Lifetime (kbytes) – The volume of traffic (in kilobytes) that can pass between IPsec peers
using a given security association before it expires. The range is 10-2,147,483,647 (10KB to
2TB) and the default is 4,608,000 kilobytes. No specification allows infinite data.
In the evaluated configuration, use of “confidentiality only” (i.e. using ESP without
authentication) for IPsec connections is prohibited. The TOE allows the administrator to
define the IPsec proposal for any IPsec connection to use specific encryption methods and
authentication methods as in the following objects (where strike-through indicates options
that are supported by the product but prohibited from use in the CC evaluated
configuration):
Objects > Object Management > VPN > IKEv2 IPsec Proposal
Choose Add IKEv2 IPsec Proposal
Enter a Name
Enter a Description
Choose ESP Hash method from {sha-1 | sha-256 | sha-384 | sha-512 | null}
Choose ESP Encryption method from {aes | aes-256 | aes-gcm | aes-gcm-256 | aes-gmac |
aes-gmac-192 | aes-gmac-256}
Note: When AES-GCM is used for encryption, the ESP integrity selection will be “null”
because GCM mode provides integrity. AES-GMAC is not allowed in the evaluated
configuration.
The IKEv2 protocols supported by the TOE implement the following DH groups: 14 (2048-
bit MODP), 19 (256-bit Random ECP) and 20 (384-bit Random EC), and use the RSA and
ECDSA algorithms for Peer Authentication. The following examples are used to specify the
DH Group used for SAs:
Objects > Object Management > VPN > IKEv2 Policy
Choose Add IKEv2 Policy
Enter a Name
Enter a Description
Enter a Priority
Enter the Lifetime of the SA in seconds. You can specify a value from 120 to 2,147,483,647
seconds. The default is 86400.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 91 of 133
TOE SFRs How the SFR is Satisfied
Choose Integrity Algorithms from [md5 | sha | sha256 | sha384 | sha512]
Choose Encryption Algorithm from [null | des | 3des | aes | aes-192 | aes-256 | aes-gcm |
aes-gcm-192 | aes-gcm-256]
Choose PRF Algorithm from {sha | sha256 | sha384 | sha512}
Add a DH Group from {14 | 19 | 20 | 24}
The secret ‘x’ generated is 64 bytes long (or 512 bits), is the same across all the DH groups,
and is generated with the DRBG specified in FCS_RBG_EXT.1. This is almost double the size
of the highest comparable strength value which is 384 bits. The TOE generates nonces used
in IKEv2 exchanges, of at least 128 bits in size and at least half the output size of the
negotiated pseudorandom function (PRF) hash.
The TOE has a configuration option to deny tunnel if the phase 2 SA is weaker than the
phase 1. The crypto strength check is enabled via the Enable Security Association (SA)
Strength Enforcement checkbox.
The TOE can be configured to authenticate IPsec connections using RSA and ECDSA
signatures. When using RSA and ECDSA signatures for authentication, the TOE and its peer
must be configured to obtain certificates from the same certification authority (CA).
Devices > VPN > Site To Site or Devices > VPN > Remote Access
IKE Options (click on IKE tab)
Policy - Choose a predefined IKEv2 policy object or create a new one to use.
Authentication Type
• Pre-shared Manual Key — Manually assign the pre-shared key that is used for
this VPN. Specify the Key and then re-enter it in Confirm Key to confirm.
When this option is chosen for IKEv2, the Enforce hex-based pre-shared key
only check box appears, check if desired. If enforced, you must enter a valid hex
value for the key, an even number of 2-256 characters, using numerals 0-9, or A-F.
• Certificate — When you use Certificates as the authentication method for VPN
connections, peers obtain digital certificates from a CA server in your PKI
infrastructure, and trade them to authenticate each other.
To configure an IKEv2 connection to use a RSA or ECDSA signature, select the authenticate
type Certificate.
To define rules for matching the DN or FQDN of the IPsec peer certificate:
First, create a certificate map via FMC (Objects > Object Management > VPN > Certificate
Map), and add a rule to the certificate map to match the “Alternative Subject” field of the
certificate to a value (FQDN/DN)
Next, associate the certificate map with the tunnel, depending on tunnel type:
• Peer-to-peer VPN (Devices > VPN > Site To Site > Add VPN > Firepower Threat
Defense Device > add a node > Certificate Map)
• Remote Access VPN (Devices > VPN > Remote Access > Advanced > Certificate Maps >
check “Use the configured rules to match a certificate to a Connection Profile > Add
Mapping > Certificate Map Name)
Pre-shared keys can be configured on the TOE for IPsec connection authentication.
However, pre-shared keys are only supported when using IKEv2 for peer-to-peer VPNs. The
text-based pre-shared keys can be composed of any combination of upper and lower case
Page 92 of 133
TOE SFRs How the SFR is Satisfied
letters, numbers, and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“,
“)”, “?”, space “ “, tilde~, hyphen-, underscore_, plus+, equal=, curly-brackets{}, square-
brackets[], vertical-bar(pipe)|, forward-slash/, back-slash\, colon:, semi-colon;, double-
quote“, single-quote‘, angle-brackets<>, comma,, and period.. The text-based pre-shared
keys can be 1-127 characters in length and is conditioned by a“prf” (pseudo-random
function) configurable by the administrator. The bit-based pre-shared keys can be entered
as HEX value as well. When using pre-shared keys for authentication, the IPsec endpoints
must both be configured to use the same key.
A crypto map (the Security Policy Definition) set can contain multiple entries, each with a
different access list. The crypto map entries are searched in a top-down sequence - the TOE
attempts to match the packet to the crypto access control list (ACL) specified in that entry.
The crypto ACL can specify a single address or a range of address and the crypto map can be
applied to an inbound interface or an outbound interface. When a packet matches a permit
entry in a particular access list, the method of security in the corresponding crypto map of
that interface is applied. If the crypto map entry is tagged as ipsecisakmp, IPsec is triggered.
The traffic matching the permit crypto ACLs would then flow through the IPSec tunnel and be
classified as PROTECTED. Traffic that does not match a permit crypto ACL or match a deny
crypto ACL in the crypto map, but is permitted by other ACLs on the interface is allowed to
BYPASS the tunnel. Traffic that does not match a permit crypto ACL or match a deny crypto
ACL in the crypto map, and is also blocked by other non-crypto ACLs on the interface would
be DISCARDED.
FCS_SSHS_EXT.1 The TOE supports SSHv2 with the following encryption algorithms - aes128-cbc, aes256-cbc,
AEAD_AES_128_GCM, AEAD_AES_256_GCM, in conjunction with HMAC-SHA1, HMAC-SHA-256,
HMAC-SHA-512, AEAD_AES_128_GCM and AEAD_AES_256_GCM for integrity and authenticity,
and RSA with diffie-hellman-group14-sha1 (supported by FTD and FMC), ecdh-sha2-nistp256
(supported only by FTD), ecdh-sha2-nistp384 (supported only by FTD), and ecdh-sha2-
nistp521 (supported only by FTD) for the key exchange method. While DES and 3DES, HMAC-
MD5 and HMAC-MD5-96, and diffie-hellman-group-1 and other diffie-hellman-exchange
groups are all implemented, they are disabled while the TOE is operating in CC Mode. In
addition, SSHv1 is also disabled by default for security reasons. If the SSH client does not
support the Approved algorithms or SSH version, the SSH connection will fail and the
administrators will not establish an SSHv2 CLI session with the TOE. The TOE supports SSH
host key authentication using rsa-sha2-256 and rsa-sha2-512 algorithms and SSH user public
key-based authentication using ecdsa-sha2-nistp256. The TOE ensures and verifies that the
SSH client’s presented public key matches one that is stored within the TOE’s SSH server’s
authorized keys file. The TOE also supports password-based user authentication for SSH.
The TOE uses OpenSSH implementation version 7.6p1 to support the SSHv2 connections. The
authentication timeout period is 90 seconds allowing clients to retry only 3 times. In addition,
both public-key (RSA) and password-based authentication can be configured with password-
based being the default method used. Whenever the timeout period or authentication retry
limit is reached, the TOE closes the applicable TCP connection and releases the SSH session
resources. As SSH packets are being received, the TOE uses a buffer to build all packet
information. Once complete, the packet is checked to ensure it can be appropriately
decrypted. However, if it is not complete when the buffer becomes full (256 Kbytes) the
packet will be dropped. Note that the TOE manages a tracking mechanism for each SSH
session so that it can initiate a new key exchange when either approximately 1 hour of time or
1GB of data is reached. An audit event is generated when a successful SSH rekey occurs when
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 93 of 133
TOE SFRs How the SFR is Satisfied
either of the thresholds mentioned occurs. SSH connections will be dropped if the TOE
receives a packet larger than 262126 bytes.
FIA_AFL.1 FMC
FMC provides the administrator the ability to specify the maximum number (can be set
differently per account on FMC) of unsuccessful authentication attempts via SSH or WebUI
(default is five attempts, configurable from 1-99) before the offending account is locked. The
configured limit is the maximum number of allowed consecutive failures, thus the defined
number of unsuccessful consecutive authentication attempts that results in locking of
accounts is one more than the maximum number of allowed consecutive failures. Only an
authorized administrator (with the ‘administrator’ role) can unlock a locked account. By
default, the predefined ‘admin’ account is exempt from becoming locked, but that default is
overridden when CC mode is enabled. If all admin accounts become locked for any reason,
FMC can be accessed locally using password recovery procedures.
FTD
The FTD CLI provides the administrator the ability to specify the maximum number of
unsuccessful authentication attempts (configurable from 1-10) before the offending account
is locked. Only an authorized administrator (with the ‘administrator’ role) can unlock a locked
account. If all admin accounts become locked for any reason, FTD can be accessed locally
using password recovery procedures.
FIA_PMG_EXT.1 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 as listed in the SFR. Minimum password length is settable by the Authorized
Administrator, and support passwords of 8 to 32 characters. Password composition rules
specifying the types and number of required characters that comprise the password are
settable by the Authorized Administrator. Passwords can be configured with a maximum
lifetime, configurable by the Authorized Administrator. New passwords can be required to
contain a minimum of 4-character changes from the previous password.
FIA_UIA_EXT.1,
FIA_UAU_EXT.2
The TOE requires all users to be successfully identified and authenticated before allowing any
TSF mediated actions to be performed. All the TOE components support authentication of
Security Administrators according to FIA_UIA_EXT.1 and FIA_UAU_EXT.2. Administrative
access to the TOE is facilitated through the TOE’s CLI (SSH (password-based and public key-
based) or local console in FTD and FMC), or web GUI in FMC. The TOE mediates all
administrative actions through the CLI and GUI. The TOE presents a warning banner in
accordance with FTA_TAB.1 requirement prior to initiating the identification authentication
mechanism for those attempting to access the TOE. Once a potential administrative user
attempts to access an administrative interface either locally or remotely, the TOE prompts the
user for a username and password. Only after the administrative user presents the correct
authentication credentials will access to the TOE administrative functionality be granted. No
access is allowed to the administrative functionality of the TOE until an administrator is
successfully identified and authenticated.
The TOE provides an automatic lockout when a user attempts to authenticate and enters
invalid credentials. After a defined number of authentication attempts fail exceeding the
Page 94 of 133
TOE SFRs How the SFR is Satisfied
configured allowable attempts, the user is locked out until an authorized administrator can
unlock the user account.
The TOE provides local password-based authentication mechanisms to FMC and FTD. The
process for authentication is the same for administrative access whether administration is
occurring via a directly connected console cable or remotely via SSHv2 (password-based or
public key-based) or TLS. 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 password associated with the user account. The TOE then either grants
administrative access (if the combination of username and password is correct) or indicates
that the login was unsuccessful. The TOE does not provide indication of whether the
username or password was the reason for an authentication failure.
FIA_UAU.7 When logging in, the TOE will not echo passwords such that passwords are not inadvertently
displayed to the user and any other users that might be able to view the login display. The
TOE replaced the entered password character with a “*” character or not show any character
at all. This depends on where the user is logging in from, for example, using web GUI versus
the SSH client. If the authentication fails, the TOE is designed to not indicate either the
username and/or password were incorrect. The error message would just state access denied
or unable to authorize access. No other information about the failed login in can be
ascertained from the error message.
Note also that should a user have their session terminated (e.g., due to inactivity), they are
required to successfully re-authenticate, by re-entering their identity and authentication data,
in order to gain access to their session. The authentication data is not cached by the TOE for
any reason.
FIA_X509_EXT.1/ITT
FIA_X509_EXT.1/Rev
FIA_X509_EXT.2(1)
FIA_X509_EXT.2(2)
FIA_X509_EXT.3
The TOE support X.509v3 certificates as defined by RFC 5280. Public key infrastructure (PKI)
credentials, such as private keys and certificates are stored securely. The identification and
authentication, and authorization security functions protect an unauthorized user from
gaining access to the storage.
The validity check for the certificates takes place at session establishment and/or at time of
import depending on the certificate type. For example, server certificate is checked at session
establishment while CA certificate is checked at both. The TOE conforms to standard RFC
5280 for certificate and path validation (i.e., peer certificate checked for expiration, peer
certificate checked if signed by a trusted CA in the trust chain, peer certificate checked for
unauthorized modification, peer certificate checked for revocation).
The TOE can generate a RSA key pair that can be embedded in a Certificate Signing Request
(CSR) created by the TOE. The CSR can be generated at the UI. The TOE can then send the CSR
manually to a Certificate Authority (CA) for the CA to sign and issue a certificate. Once the
certificate has been issued, the administrator can import the X.509v3 certificate into the TOE.
Integrity of the CSR and certificate during transit are assured through the use of digital
signature (signing the hash of the TOE’s public key contained in the CSR and certificate). CRL
is configurable and can be used for certificate revocation check (for FTP_ITC only, thus
relevant only to FIA_X509_EXT.1/Rev, not relevant to FIA_X509_EXT.1/ITT as no revocation
checking is used for communications between TOE components). Checking is also done for
the ‘basicConstraints’ extension and the ‘cA’ flag to determine whether they are present and
set to TRUE. If they are not, the CA certificate is not accepted as a trust anchor.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 95 of 133
TOE SFRs How the SFR is Satisfied
FMC only supports CRL, while FTD supports use of both CRL and OCSP (including verification
of the OCSP signing purpose in the certificate that signs the OCSP response). FTD supports
CRL for other purposes, i.e., for validation of syslog server certificates for both the TLS
connections to TLS servers.
The administrators can configure a trust chain by importing the CA certificate(s) that signed
and issued the server (syslog) certificate. This will tell the TOE which CA certificate(s) to use
during the validation process. If the TOE does not find the trusted root CA, the TLS
connections (FTD TLS client and FTD OS TLS client) to the syslog server will fail. When the
TOE cannot establish a connection for the validity check using CRL or the OCSP responder for
verification, the FTD IPsec connections will not accept the certificate when transmitting
messages to the syslog server, while all FTD and FMC TLS connections will accept the
certificate and the trusted channel will be established. When communicating with peers, the
TOE uses the default certificate that is configured through the FMC and one that matches the
peer’s request. For more information, please refer to the CC Supplemental User Guide.
FMT_MOF.1/
ManualUpdate
The TOE restricts the ability to enable, disable, determine and modify the behavior of all of the
security functions of the TOE to authorized administrators. The TOE provides the ability for
authorized administrators to initiate TOE update, access TOE data, such as audit data,
configuration data, security attributes, information flow rules, and session thresholds.
FMC
Only accounts with ‘administrator’ privilege can upload patches to FMC and initiate
installation of patches to FMC or FTD devices (the FMC WebUI is used to manually initiate
updates to FMC and FTD). Only accounts with ‘administrator’ privilege can update system
configuration settings related to:
• local logging and remote logging
• clock settings
• account management including account lockout settings and unlocking accounts (for
FMC accounts only)
• login banners
• cryptographic functionality including SSH (FMC and FTD), TLS (FMC), and IPsec
(FTD)
• generation of CSRs, and import or delete X.509v3 certificates
• firewall functionality
• VPN functionality
• IPS functionality
FTD
Only accounts with ‘config’ privilege can update system configuration settings related to:
• account management including account lockout settings and unlocking accounts (for
FTD accounts only)
FMT_MTD.1/CoreData The TOE provides a web-based GUI (using HTTPS) management interface and CLI or shell
(using SSH or serial connection) (FMC provides the Web GUI and CLI, while the FTD provides
a CLI) for all TOE administration, including the policy rule sets, user accounts and roles, and
audit functions. The ability to manage various security attributes, system parameters and all
TSF data is controlled and limited to those users who have been assigned the appropriate
Page 96 of 133
TOE SFRs How the SFR is Satisfied
administrative role and privileges associated with those roles. Note that all users created are
TOE administrators
Predefined User Roles
The TOE supports the following predefined user roles:
• Administrators can set up the appliance’s network configuration, manage user
accounts, and configure system policies and system settings. The Administrator Role
provides access to analysis and reporting features, rule and policy configuration,
system management, and all maintenance features. Users with the Administrator role
have ALL access rights.
Note: The only TOE user role is “Administrator”. This role is granted when a new user account
is created and cannot be changed.
In addition to the all-powerful “Administrator” role, these additional roles help with the
management of the IPS policies and functionality-
• “IPS Administrator” (or Administrator): Have all privileges and access
• “IPS Analyst” (or Intrusion Admin): Have all access to intrusion policies, IPS policies
and network analysis privileges but cannot deploy policies
• Access Admin: Have all access to access control policies but cannot deploy policies
• Discovery Admin: Have all access to network discovery, application detection, and
correlation features but cannot deploy policies
• Security Analyst: Have all access to security event analysis feature
The web-based GUI is available on the FMC. The web-based GUI on the FMC is highly
recommended for daily management of the FMC and its managed FTD. Local access to the
shell which allows access to the underlying operating system is allowed in the CC evaluated
configuration for the initial configuration only. For normal daily operations, the web GUI is
still the recommended method.
FMT_MTD.1/CryptoKeys The TOE only provides the ability for authorized administrators to access TOE data, such as
audit data, configuration data, security attributes (such as cryptographic keys and certificates
used in VPN), routing tables, and session thresholds.
FMT_SMF.1
FMT_SMF.1/FFW[FW]
FMT_SMF.1/VPN[VPN]
The TOE includes the functions necessary to administer the TOE locally and remotely via the
administrative interfaces of the FTD (SSH CLI, local console) and FMC (WebUI, SSH CLI, local
console). All the management functions that are available to be performed on the TOE local
console can also be performed remotely via SSH. No access or service is provided prior to
identification and authentication, beyond viewing the login banner.
FMC
FMC administrators can perform the following functions:
• Login locally via console CLI, and remotely via SSH CLI or TLS WebUI
• Configure the access banner (via WebUI)
• Configure session inactivity time limits (via WebUI)
• Update the FMC and FTD TOE components and verify updates using digital signature
prior to installing updates (via WebUI)
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 97 of 133
TOE SFRs How the SFR is Satisfied
• Configure authentication failure parameters (via WebUI)
• Manage cryptographic keys (via WebUI)
• Configure cryptographic functionality (via WebUI)
• Configure lifetime for IPsec SAs (via WebUI)
• Import X.509v3 certificates (via WebUI)
• Configure interaction between TOE components (via WebUI)
• Re-enable an administrator account (via WebUI)
• Set the time which is used for time-stamps (via WebUI)
• Configure the reference identifier for the peer (via WebUI)
• Configure firewall rules (via WebUI)
• Define packet filtering rules for VPNs (via WebUI)
• Manage the trusted public keys database
• Associate packet filtering rules to network interfaces for VPNs (via WebUI)
• Configure ordering/sequencing of packet filtering rules (via WebUI)
FTD
FTD administrators can perform the following functions:
• Login locally via console CLI, and remotely via SSH CLI
• Configure authentication failure parameters
• Import X.509v3 certificates (for syslog servers only)
• Configure interaction between TOE components
• Re-enable an administrator account
• Configure the reference identifier for the peer (for syslog servers only)
• Manage the trusted public keys database
FMT_SMR.2 The TOE includes one evaluated role which corresponds to the required ‘Security
Administrator’ described in Section 5.3.5.5.
FPT_SKP_EXT.1 The TOE is designed to not to disclose or store plaintext passwords (e.g., passwords are never
recorded in the audit records or display during authentication process). The passwords are
stored hashed using Approved SHA-512 with a 32-bit salt value. Only ‘root’ user account with
access to the shell can view the hashed passwords and this is prohibited in the evaluated
configuration. The same is true for cryptographic keys such as encryption symmetric keys and
private keys. The public keys can be viewed but cannot be modified without detection. Note
that access to public keys is restricted to administrators.
FPT_APW_EXT.1 The TOE is designed to not to disclose or store plaintext passwords (e.g., passwords are never
recorded in the audit records or display during authentication process). The passwords are
stored hashed using Approved SHA-512 with a 32-bit salt value. Only ‘root’ user account with
access to the shell can view the hashed passwords and this is prohibited in the evaluated
configuration. The same is true for cryptographic keys such as encryption symmetric keys and
private keys. The public keys can be viewed but cannot be modified without detection. Note
that access to public keys is restricted to administrators.
FPT_STM_EXT.1 The FMC provides a source of date and time information for the TOE, used in audit
timestamps, in validating service requests, and for tracking time-based actions related to
Page 98 of 133
TOE SFRs How the SFR is Satisfied
session management including timeouts for inactive administrative sessions (FTA_SSL_EXT.*),
and renegotiating SAs for IPsec tunnels (FCS_IPSEC_EXT.1). This function can only be accessed
from within the configuration exec mode via the privileged mode of operation or using the
appropriate role. The clock function is reliant on the system clock provided by the underlying
hardware. FMC and FMCv’s clock can be configured manually by the administrators. The FTD
must be configured by the administrator to synchronize its clock with the FMC clock.
FPT_TST_EXT.1 The TOE runs a suite of self-tests during initial start-up (power-on-self-tests or POST) to
verify its correct operation. When CC mode is enabled on the FMC and FTD, additional
cryptographic tests and software integrity test will be run during start-up. The self-testing
includes cryptographic algorithm tests (known-answer tests) that feed pre-defined data to
cryptographic modules and confirm the resulting output from the modules match expected
values, and firmware integrity tests that verify the digital signature of the code image using
RSA-2048 with SHA-512. The cryptographic algorithm testing verifies proper operation of
encryption functions, decryption functions, signature padding functions, signature hashing
functions, and random number generation. The firmware integrity testing verifies the FTD
and FMC images have not been tampered with or corrupted. If any of these self-tests fails, the
TOE will cease operation.
Noise source health tests are run both periodically and at start-up on the FTD to determine
the functional health of the noise source. These tests are specifically designed to catch
catastrophic losses in the overall entropy associated with the noise source. Tests are run on
the raw noise output, before the application of any conditioners. If a noise source fails the
health test either at start-up or after the device is operational, the platform will be shut down.
Whenever a failure (e.g., POST or integrity test fails) occurs within the FTD that results in the
FTD ceasing operation, the FTD securely disables its interfaces to prevent the unintentional
flow of any information to or from the FTD and reloads. So long as the failures persist, the FTD
will continue to reload. This functionally prevents any failure from causing an unauthorized
information flow. There are no failures that circumvent this protection.
FPT_TUD_EXT.1 The TOE components (FMC and FTD) have specific versions that can be queried by an
administrator. When updates are made available by Cisco, an administrator can obtain and
manually install those updates.
Digital signatures (RSA), with key sizes of 2048 and 3072 bits, are used to verify
software/firmware update files (to ensure they have not been modified from the originals
distributed by Cisco) before they are used to update the applicable TOE components. The
update process will fail if the digital signature verification process fails. Updates can be
downloaded from https://software.cisco.com with a Cisco.com account. The appropriate
software image is then downloaded to the administrator’s workstation, then uploaded to FMC
(FTD updates are uploaded to FMC then pushed from FMC to FTD). Software update files are
verified using digital signatures (RSA) automatically at the time they are uploaded to FMC.
Update files will fail to be stored on the device if they fail validation.
On FMC, the FMC and FTD updates can uploaded and installed by navigating to System >
Updates. Several upload files can remain stored locally on FMC and installed to FMC or FTD at
a later time. When updates are initiated, they are applied immediately, and the FMC or FTD
will reload automatically with the new software version. That same page also shows the
currently running version on FMC. To view the currently running version of any FTD,
navigate to Devices > Device Management > then select the device > click on the ‘Device’ tab.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 99 of 133
TOE SFRs How the SFR is Satisfied
FPT_ITT.1, FPT_ITT.1/Join The communication between the FMC and FTD is protected by TLSv1.2. TLS provides
authentication, key exchange, encryption and integrity protection of all data transmitted
between the TOE components.
FTA_SSL_EXT.1, FTA_SSL.3,
FTA_SSL.4
An administrator can configure maximum inactivity times for both local and remote
administrative sessions. When a session is inactive (i.e., no session input) for the configured
period of time the TOE will terminate the session, requiring the administrator to log in again
to establish a new session when needed. The inactivity times are set at a default of 60
minutes, but an Administrator can configure the inactivity time for the FMC and FTD through
the FMC WebUI.
An administrator is able to exit out of both local and remote administrative sessions of the
FMC and FTD, effectively terminating the session so it cannot be re-used and will require
authentication to establish a new session.
FTA_TAB.1 The TOE provides administrators with the capability to configure advisory banner or warning
message(s) that will be displayed prior to completion of the logon process at the local console
or via any remote connection (e.g., SSH or HTTPS). The TOE displays an advisory notice and a
consent warning message for each administrative method of access:
• FMC/FMCv: Console, SSH, and WebUI
• FTD: The FTD CLI (SSH) and console
FTP_ITC.1 The TOE uses IPsec and/or TLS to protect communications between itself and remote entities
for the following purposes:
• The TOE protects transmission of audit records when sending syslog message to a
remote audit server by transmitting the messages:
o From FMC/FMCv as a TLS client, using X.509v3 certificates for assured
identification of the syslog server and with mutual authentication supported.
o From FTD as a TLS client (FTD TLS Client), that is configured by the FMC and is
the main audit system for audits generated by FTD. It sends audit events such as
IPsec and login messages to the external syslog server and Mutual authentication
is not supported.
o From FTD as a TLS client (FTD OS TLS Client), that is configured through the
FTD’s command line and sends audit events to an external syslog server such as
SSH login, console login, etc. and Mutual authentication is not supported.
o From FTD to an external syslog server over IPsec
• The TOE (FTD only) protects peer-to-peer VPN connections between itself and VPN
peers (connections can be initiated by the TOE or by the peer) using IPsec, using
X.509v3 certificates for assured identification of the peer.
• The TOE (FTD Only) protects VPN connections inbound from VPN clients using IPsec,
using X.509v3 certificates for assured identification of the VPN client. Note that the
remote VPN client is in the operational environment.
Page 100 of 133
TOE SFRs How the SFR is Satisfied
FTP_TRP.1/Admin The TOE uses SSHv2 or HTTPS to provide the trusted path (with protection from disclosure
and modification) for all remote administration sessions. Optionally, the FTD supports
tunneling the SSH connection in IPsec VPN tunnels (remote VPN client). Remote
administration of FMC can be performed using SSH or TLS/HTTPS. Remote administration
through the CLI of FTD is via SSH.
Drawn from the mod_ips_v1.0
FAU_GEN.1/IPS[IPS]
FAU_SAR.1[IPS]
FAU_SAR.2[IPS]
FAU_SAR.3[IPS]
FAU_STG.1[IPS]
FTD and FMC
For each possible intrusion identified by the system, the TOE will generate an event log, also
referred to as an intrusion event and event types are not combined. Each event log will
include a record of the date, time, type of exploit, and contextual information about the source
of the attack and its target. For packet-based events, a copy of the packet or packets that
triggered the event is also recorded. Managed Sensors will transmit their events to the FMC
where the administrators can view the aggregated data and gain a greater understanding of
the attacks against the entire network. The administrators can also deploy the managed
Sensors in inline allowing them to configure the Sensors to drop or modify packets that are
harmful.
The web-based UI is the only way to view the intrusion events (Analysis > Intrusions >
Events). The list below describes the intrusion event information that can be viewed,
searched, filtered, and sorted by the system. In addition, basic contents such as date, time, and
type can also be used to filter and sort. Note only Administrators and Intrusion Admins have
access to the intrusion events.
Access Control Policy
The access control policy associated with the intrusion policy where the intrusion,
preprocessor, or decoder rule that generated the event is enabled.
Access Control Rule
The access control rule that invoked the intrusion policy that generated the event. Default
Action indicates that the intrusion policy where the rule is enabled is not associated with a
specific access control rule but, instead, is configured as the default action of the access
control policy.
This field is blank if intrusion inspection was associated with neither an access control rule
nor the default action, for example, if the packet was examined by the default intrusion policy.
Application Protocol
The application protocol, if available, which represents communications between hosts
detected in the traffic that triggered the intrusion event.
Application Risk
The risk associated with detected applications in the traffic that triggered the intrusion event:
Very High, High, Medium, Low, and Very Low. Each type of application detected in a
connection has an associated risk; this field displays the highest risk of those.
Count
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 101 of 133
TOE SFRs How the SFR is Satisfied
The number of events that match the information that appears in each row. Note that the
Count field appears only after you apply a constraint that creates two or more identical rows.
This field is not searchable.
Destination Continent
The continent of the receiving host involved in the intrusion event.
Destination Country
The country of the receiving host involved in the intrusion event.
Destination IP
The IP address used by the receiving host involved in the intrusion event.
Destination Port / ICMP Code
The port number for the host receiving the traffic. For ICMP traffic, where there is no port
number, this field displays the ICMP code.
Destination User
The User ID for any known user logged in to the destination host.
Device
The managed Sensor where the access control policy was deployed.
Domain
The domain of the Sensor that detected the intrusion. This field is only present if you have
ever configured the Firepower Management Center for multitenancy.
Egress Interface
The egress interface of the packet that triggered the event. This interface column is not
populated for a passive interface.
Egress Security Zone
The egress security zone of the packet that triggered the event. This security zone field is not
populated in a passive deployment.
Generator
The component that generated the event.
Ingress Interface
The ingress interface of the packet that triggered the event. Only this interface column is
populated for a passive interface.
Ingress Security Zone
The ingress security zone of the packet that triggered the event. Only this security zone field is
populated in a passive deployment.
Inline Result
Actions
Intrusion Policy
Page 102 of 133
TOE SFRs How the SFR is Satisfied
The intrusion policy where the intrusion, preprocessor, or decoder rule that generated the
event was enabled.
Message
The explanatory text for the event. For rule-based intrusion events, the event message is
pulled from the rule.
Priority
The event priority as determined by the Cisco Talos Security Intelligence and Research Group
(Talos). The priority corresponds to either the value of the priority keyword or the value for
the classtype keyword.
For other intrusion events, the priority is determined by the decoder or preprocessor. Valid
values are high, medium, and low.
Protocol (search only)
The name or number of the transport protocol used in the connection.
Signature ID
The signature used to generate the event.
Snort ID (search only)
Specify the Snort ID (SID) of the rule that generated the event or, optionally, specify the
combination Generator ID (GID) and SID of the rule, where the GID and SID are separated
with a colon (:) in the format GID:SID.
Source Continent
The continent of the sending host involved in the intrusion event.
Source Country
The country of the sending host involved in the intrusion event.
Source IP
The IP address used by the sending host involved in the intrusion event.
Source Port / ICMP Type
The port number on the sending host. For ICMP traffic, where there is no port number, this
field displays the ICMP type.
Source User
The User ID for any known user logged in to the source host.
The intrusion events cannot be modified but they can be deleted by the Administrators or
Intrusion Admins who have restricted access. When the intrusion events storage is full, the
newest data will overwrite the oldest data.
There is a feature called Threshold where the administrators can control the number of
events that are generated per rule over time. They can limit notification to the specified
number of event instances per time period or provide notification once per time period after a
specified number of event instances. The administrator must specify if the event instances
will be tracked by source or destination IP address, the count or the number of event
instances, and the number of seconds for the time period for which event instances are
tracked.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 103 of 133
TOE SFRs How the SFR is Satisfied
Note the IPS function cannot be disabled unless the whole system is shutdown. The TOE also
will generate all of the required auditable events identified in Table 19 (for FMT_SMF.1/IPS
and IPS_NTA_EXT.1 only). All other events in the table are addressed by intrusion events, not
auditable events. Please see the CC Supplemental User Guide for more details.
The TOE can be configured to generate intrusion events. In addition, all management
functions are audited as well. There are certain header fields that should not be used to
trigger intrusion events (in Inline mode or Passive mode). Logging events related to these
fields would generate a deluge of intrusion audit records that would prevent IPS analysts
from figuring out what security incidents occur in their monitored network. In addition,
logging these fields will provide no benefits. Per mod_ips_v1.0, the following fields can be
inspected and if in inline mode, dropped or modified (i.e., normalized):
- All checksum fields
- TCP Reserved field
- TCP Urgent Pointer field
In inline mode, the TOE can count invalid checksum packets that are dropped. The TOE can
also count the packets that gets normalized or dropped because of failed normalization.
FMT_SMF.1/IPS[IPS] FMC and FTD
The Administrators can deploy intrusion policy with intrusion rules to any interface. An
interface, however, can only have one policy applied to that interface. The Administrators can
also import vendor-defined signatures from Cisco, create their own intrusion rules, create
rules to define which traffic is inspected and analyzed, enable anomaly rules/detections,
modify thresholds and threshold duration, and configure white-list/black-list. The IPS
Analysts (Intrusion Admins) Administrators can create, modify, or delete intrusion policies
but only the IPS Administrators can deploy the policies. Here are the security roles in
addition to the all-powerful “Administrator” role.
• “IPS Administrator” (or Administrator): Have all privileges and access
• “IPS Analyst” (or Intrusion Admin): Have all access to intrusion policies, IPS policies and
network analysis privileges but cannot deploy policies
• Access Admin: Have all access to access control policies but cannot deploy policies
• Discovery Admin: Have all access to network discovery, application detection, and
correlation features but cannot deploy policies
• Security Analyst: Have all access to security event analysis feature
IPS_ABD_EXT.1[IPS]
IPS_IPB_EXT.1[IPS]
IPS_NTA_EXT.1[IPS]
IPS_SBD_EXT.1[IPS]
FTD Only
The TOE provides network analysis and intrusion policies as part of the FTD’s intrusion
detection and prevention system. The term “intrusion detection” generally refers to the
process of passively analyzing network traffic for potential intrusions and storing attack data
for security analysis. The term “intrusion prevention” includes the concept of intrusion
detection but adds the ability to block or alter malicious traffic as it travels across the
network.
In an intrusion detection/prevention deployment, the TOE examines packets as such:
Page 104 of 133
TOE SFRs How the SFR is Satisfied
• A network analysis policy governs how traffic is decoded and preprocessed so it can be
further evaluated, especially for anomalous traffic that might signal an intrusion attempt.
• An intrusion policy uses intrusion and preprocessor rules (sometimes referred to
collectively as intrusion rules) to examine the decoded packets for attacks based on patterns
or signatures.
Without decoding and preprocessing, the TOE could not appropriately evaluate traffic for
intrusions because protocol differences would make pattern matching impossible. Network
analysis policies govern the traffic-handling tasks:
1. Security Intelligence uses reputation intelligence to quickly block connections to or from
IP addresses, URLs, and domain names and is an early phase of access control.
2. Before traffic can be inspected by intrusion policies
Security Intelligence lists and feeds are collections of IP addresses, domain names, and URLs
that you can use to quickly filter traffic that matches an entry on a list or feed.
• A list is a static collection that can be managed manually.
• A feed is a dynamic collection that updates on an interval.
Security Intelligence lists/feeds are grouped into:
• DNS (Domain names)
• Network (IP addresses)
• URLs
Predefined global Block lists and Allow lists for domains (DNS), IP addresses (Networks), and
URLs are available by default and the Administrators can build on the list. Blacklist
and Whitelist options are available on IP address, URL, and DNS requests. Using these rules to
block or allow an item adds the item to the appropriate default Global list. By default, Access
control and DNS policies use these Global lists. These lists can be applied on a per-policy basis
A network analysis policy governs packet processing in phases. First the system decodes
packets through the first three TCP/IP layers, then continues with normalizing,
preprocessing, and detecting protocol anomalies:
• The packet decoder converts packet headers and payloads into a format that can be
easily used by the preprocessors and later, intrusion rules. Each layer of the TCP/IP stack
is decoded in turn, beginning with the data link layer and continuing through the network
and transport layers. The packet decoder also detects various anomalous behaviors in
packet headers.
• The inline normalization preprocessor reformats (i.e., normalizes) traffic to minimize
the chances of attackers evading detection. It prepares packets for examination by other
preprocessors and intrusion rules and helps ensure that the packets the system processes
are the same as the packets received by the hosts on your network.
• Various network and transport layers preprocessors detect attacks that exploit IP
fragmentation, perform checksum validation, and perform TCP and UDP session
preprocessing.
o Various application-layer protocol decoders normalize specific types of packet data
into formats that the intrusion rules engine can analyze. Normalizing application-layer
protocol encodings allows the system to effectively apply the same content-related
intrusion rules to packets whose data is represented differently, and to obtain
meaningful results. Conformance to protocols has been verified via compliance testing.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 105 of 133
TOE SFRs How the SFR is Satisfied
o The Modbus and DNP3 SCADA preprocessors detect traffic anomalies and provide
data to intrusion rules. The operations associated with the anomaly-based IPS policies
are allow the traffic flow for any sensor interface in any mode and allow the traffic flow
and block/drop the traffic flow in inline mode. Administrators can define strings to
match URLs/URIs, and web page content for pattern-matching.
o Several preprocessors allow administrators to detect specific threats, such as
IP/TCP/UDP/ICMP port scans, ICMP/TCP flooding, DoS attacks and other rate-based
attacks (“frequency”). The administrator can configure threshold3 that mimics normal
expected frequency and configure the TOE to detect and drop events exceeding the
configured thresholds.
When the system identifies a possible intrusion, it generates an intrusion or preprocessor
event (sometimes collectively called intrusion events). Managed Sensors transmit their events
to the Firepower Management Center, where the administrators can view the aggregated data
and gain a greater understanding of the attacks against their network assets. In an inline
deployment, managed Sensors can also drop packets that are known to be harmful.
Each intrusion event in the database includes an event header and contains information about
the event name and classification; the source and destination IP addresses; ports; the process
that generated the event; and the date and time of the event, as well as contextual information
about the source of the attack and its target. For packet-based events, the TOE also logs a copy
of the decoded packet header and payload for the packet or packets that triggered the event.
The packet decoder, the preprocessors, and the intrusion rules engine can all cause the TOE to
generate an event. For examples,
• If the packet decoder (configured in the network analysis policy) receives an IP packet that
is less than 20 bytes, which is the size of an IP datagram without any options or payload, the
decoder interprets this as anomalous traffic. If, later, the accompanying decoder rule in the
intrusion policy that examines the packet is enabled, the system generates a preprocessor
event.
• If the IP defragmentation preprocessor encounters a series of overlapping IP fragments, the
preprocessor interprets this as a possible attack and, when the accompanying preprocessor
rule is enabled, the system generates a preprocessor event.
• Within the intrusion rules engine, most intrusion rules are written so that they generate
intrusion events when triggered by packets. Please see section 7.1 for more details on Snort
rule.
Until the administrator deploy new policies to the network interface, rules in the currently
deployed intrusion policies behave as follows:
• Disabled rules remain disabled.
• Rules set to Generate Events continue to generate events when triggered.
• Rules set to Drop and Generate Events continue to generate events and drop offending
packets when triggered.
The administrator can set thresholds for individual rules, per intrusion policy, to limit the
number of times the system logs and displays an intrusion event based on how many times
3
Although the term “threshold” is used in the TSS, the TOE’s definition of “threshold” matches the definition of
frequency in the mod_ips_v1.0. Therefore, “frequency”, rather than “threshold” has been selected in the
IPS_ABD_EXT.1.1 requirement.
Page 106 of 133
TOE SFRs How the SFR is Satisfied
the event is generated within a specified time period. This can prevent the TOE from being
overwhelmed with a large number of identical events.
The TOE can also be configured to use intrusion rules to detect various attacks such as
Teardrop, Bonk, Ping of Death, etc. The administrators can use pre-defined rule or create
custom rule to detect these attacks and many more. Please reference the CC Supplemental
User Guide for more details.
The administrator can configure the Sensor in either a passive or inline deployment. In a
passive (promiscuous) IPS deployment, the Sensor monitors traffic flowing across a network
using a switch SPAN or mirror port. The SPAN or mirror port allows for traffic to be copied
from other ports on the switch. This provides the system visibility within the network without
being in the flow of network traffic. When configured in a passive deployment, the system
cannot take certain actions such as blocking or shaping traffic. The administrator can
configure one or more physical ports (Gigabit ethernet interfaces) on a managed Sensor as
passive interfaces and deploy the intrusion policy to that interface via security zone (i.e., the
interface is added to the zone). In an inline IPS deployment, the administrator configures the
Sensor transparently on a network segment by binding two ports together. The administrator
can configure one or more physical ports (Gigabit ethernet interfaces) on a managed Sensor
as inline interfaces then assign a pair of inline interfaces to an inline set. The intrusion policy
is then deployed to that inline set via security zone. The management interface (typically
eth0) is separate from the other data monitoring interfaces (used as passive or inline) on the
Sensor. It is used to set up and register the Sensor to the FMC.
Security Functional Requirements Drawn from mod_cpp_fw_v1.4e
FDP_RIP.2[FW] FTD Only
The TOE ensures that packets transmitted through the TOE do not contain residual
information from previous packets. Packets that are not the required length (for the
temporary memory storage location, or for the minimum transmission unit size on the egress
interface) use zeros for padding so residual data is never transmitted from the TOE. Packet
handling within memory buffers ensures new packets cannot contain portions of previous
packets by ensuring that when packets are written to memory locations those memory
locations are padded with zeros as necessary to fill the allocated memory size, so no residual
data exists within that memory range when the packet is read for transmission. This applies
to data plane traffic and even administrative session traffic.
FFW_RUL_EXT.1.1[FW]
FFW_RUL_EXT.1.2[FW]
FTD Only
The TOE provides stateful traffic filtering of IPv4 and IPv6 network traffic. Administratively-
defined traffic filter rules (access-lists or Objects > Object Management > Access Control
Lists > Extended) can be applied to any interface to filter traffic based on IP parameters
including source and destination address, transport layer protocol, type and code, TCP and
UDP port numbers. The TOE allows establishment of communications between remote
endpoints, and tracks the state of each session (e.g. initiating, established, and tear-down),
and will clear established sessions after proper tear-down is completed as defined by each
protocol, or when session timeouts are reached.
To track the statefulness of sessions to/from and through the firewall, the TOE maintains a
table of connections in various connection states and connection flags. The TOE updates the
table (adding, and removing connections, and modifying states as appropriate) based on
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 107 of 133
TOE SFRs How the SFR is Satisfied
configurable connection timeout limits, and by inspecting fields within the packet headers.
For further explanation of connection states, see section 7.1.
The proper session establishment and termination followed by the TOE is as defined in the
following RFCs:
• RFC 792 (ICMPv4)
• RFC 4443 (ICMPv6)
• RFC 791 (IPv4)
• RFC 2460 (IPv6)
• TCP, RFC 793, section 2.7 Connection Establishment and Clearing
• UDP, RFC 768 (not applicable, UDP is a “stateless” protocol)
During initialization/startup (while the TOE is booting) the configuration has yet to be loaded,
and no traffic can flow through any of its interfaces. No traffic can flow through the TOE
interfaces until the POST has completed, and the configuration has been loaded. If any aspect
of the POST fails during boot, the TOE will reload without forwarding traffic. If a critical
component of the TOE, such as the clock or cryptographic modules, fails while the TOE is in an
operational state, the TOE will reload, which stops the flow of traffic. If a component such as a
network interface, which is not critical to the operation of the TOE, but may be critical to one
or more traffic flows, fails while the TOE is operational, the TOE will continue to function,
though all traffic flows through the failed network interface(s) will be dropped.
When traffic exceeds the maximum rate the TOE can handle, the TOE drops the excess traffic
and ensures that no traffic that wouldn’t pass stateful traffic filtering rules will be passed
through.
FFW_RUL_EXT.1.2 [FW] FTD Only
The TOE supports filtering of the following protocols and enforces proper session
establishment, management, and termination as defined in each protocol’s RFC, using the
following filtering options configured via FMC:
To filter ICMPv4 or ICMPv6 Type and Code:
• Policies > Access Control > Access Control > Add Rule >
a. Zones (mapped to interfaces) > Available Zones > click either “Add to
Source” or “Add to Destination”
b. Networks > select IPv4 networks> add to source and/or destination
c. Ports > Selected Destination Ports > Protocol > ICMP > select type and
code
To filter ICMPv6 Type and Code: As explained above for ICMPv4, but under “Networks” select
IPv6 addresses.
To filter IPv4 Source address, Destination Address, and Transport Layer Protocol:
• Policies > Access Control > Access Control > Add Rule >
a. Zones (mapped to interfaces) > Available Zones > click either “Add to
Source” or “Add to Destination”
b. Networks > select IPv4 networks > add to source and/or destination
c. Ports > select a pre-named port, or create a new named protocol+port >
add to source and/or destination
Page 108 of 133
TOE SFRs How the SFR is Satisfied
To filter IPv6 Source Address, Destination Address, and Transport Layer Protocol: As
explained above for IPv4, but under “Networks” select IPv6 addresses.
To filter TCP Source Port and/or Destination Port: As explained above for IPv4 or IPv6, and
under “Ports” select “TCP” and a port under either or both of “Selected Source Ports” and/or
“Selected Destination Ports.”
To filter UDP Source Port and/or Destination Port: As explained above for IPv4 or IPv6, and
under “Ports” select “UDP” and a port under either or both of “Selected Source Ports” and/or
“Selected Destination Ports.”
• Addresses, type of service, fragmentation data, size and padding, and IP options including
loose source routing, strict source routing, and record route as defined in RFC 791 (IPv4),
and RFC 2460 (IPv6);
• Port numbers, sequence and acknowledgement numbers, size and padding, and control
bits such as SYN, ACK, FIN, and RST as defined in RFC 793 (TCP);
• Port numbers, and length as defined in RFC 768 (UDP); and
• Session identifiers, sequence numbers, types, and codes as defined in RFC 792 (ICMPv4),
and RFC 4443 (ICMPv6).
Cisco confirms proper implementation of the RFCs through interoperability testing with Cisco
and 3rd party products and through protocol compliant testing.
The TOE can also support deeper packet inspection and enforce additional RFC compliance
beyond session management, but such traffic inspection functionality is not defined within
the NDcPP and is therefore beyond the scope of this CC certification.
FFW_RUL_EXT.1.3[FW],
FFW_RUL_EXT.1.4[FW]
FTD Only
Each traffic flow control rule on the TOE is defined as either a “permit” rule, or a “deny” rule,
and any rule can also contain the keyword “log” which will cause a log message to be
generated when a new session is established because it matched the rule. The TOE can be
configured to generate a log message for the session establishment or an attempt at session
establishment of any permitted or denied traffic (in this case, attempt to establish a session).
When a rule is created to explicitly allow a protocol which is implicitly allowed to spawn
additional sessions, the establishment of spawned sessions is logged as well.
Access Control Lists (ACLs) are only enforced after they’ve been applied to a network
interface. Any network interface can have an ACL applied to it. Interfaces can be referred to
by their identifier (e.g. GigabitEthernet 0/1).
The interface types that can be assigned to an interface are:
• Physical interfaces
o Ethernet
o GigabitEthernet
o TenGigabitEthernet
o Management
• Port-channel interfaces (designated by a port-channel number)
• Subinterface (designated by the subinterface number)
The default state of an interface depends on the type and the context mode:
• For the “system” context in single mode or multiple context mode, interfaces have the
following default states:
o Physical interfaces = Disabled
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 109 of 133
TOE SFRs How the SFR is Satisfied
o Subinterfaces = Enabled. However, for traffic to pass through the
subinterface, the physical interface must also be enabled.
• For any non-system context (in multiple context mode): All allocated interfaces
(allocated to the context by the system context) are enabled by default, no matter
what the state of the interface is in the system context. However, for traffic to pass
through the interface, the interface also has to be enabled in the system context. If
you shut down an interface in the system context, then that interface is down in all
contexts to which that interface has been allocated.
In interface configuration mode, the administrator can configure hardware settings (for
physical interfaces), assign a name, assign a VLAN, assign an IP address, and configure many
other settings, depending on the type of interface and the security context mode.
For an enabled interface to pass traffic, the following interface configuration mode commands
must be used (in addition to explicitly permitting traffic flow by applying and access-group to
the interface): “nameif”, and, for routed mode, “ip address”. For subinterfaces, also configure
the “vlan” command.
FFW_RUL_EXT.1.5[FW] FTD Only
All traffic that goes through the TOE is inspected using the Adaptive Security Algorithm and
either is allowed through or dropped. A simple packet filter can check for the correct source
address, destination address, and ports, but it does not check that the packet sequence or
flags are correct. A filter also checks every packet against the filter, which can be a slow
process.
A stateful firewall like the TOE, however, takes into consideration the state of a packet:
• Is this a new connection?
If it is a new connection, the TOE has to check the packet against access control lists and
perform other tasks to determine if the packet is allowed or denied. To perform this check,
the first packet of the session goes through the "session management path," and depending on
the type of traffic, it might also pass through the "control plane path."
The session management path is responsible for the following tasks:
– Performing the access list checks
– Performing route lookups
– Allocating NAT translations (xlates)
– Establishing sessions in the "fast path"
The TOE creates forward and reverse flows in the fast path for TCP traffic; the TOE also
creates connection state information for connectionless protocols like UDP, so that they can
also use the fast path.
• Is this an established connection?
If the connection is already established, the TOE does not need to re-check packets against the
ACL; matching packets can go through the "fast" path based on attributes identified in
FFW_RUL_EXT.1.5. The fast path is responsible for the following tasks:
– IP checksum verification
– Session lookup
Page 110 of 133
TOE SFRs How the SFR is Satisfied
– TCP sequence number check
– NAT translations based on existing sessions
– Layer 3 and Layer 4 header adjustments
Existing traffic flows are removed from the set of established traffic flows when the session
inactivity timeout hits or the completion of the expected information flow.
FFW_RUL_EXT.1.6[FW],
FFW_RUL_EXT.1.7[FW]
FTD Only
The TOE can be configured to implement default denial of various malformed
packets/fragments, and other illegitimate network traffic, and can be configured to log that
such packets/frames were dropped.
The following traffic will be denied/dropped by the TOE, and when auditing of such actions
has been enabled by an administrator the TOE will generate audit messages when the action
occurs:
a) Packets which are invalid fragments (The TOE will count the number packets that were
dropped because the packets included invalid fragments. Invalid fragments include:
overlapping fragments (‘teardrop’ attack); and invalid IP fragment size (‘ping of death’
attack).)
b) Fragments that cannot be completely re-assembled (The TOE will count the number of
packets that fail to be reassembled. Packets that fail to be reassembled include those that
exceed any of the thresholds (configured globally, or per-interface) for fragment reassembly,
including limits for: the maximum number of fragments allowed for a single packet (chain
size); the maximum number of fragments the TOE will hold in its IP reassembly database
waiting for reassembly (size limit); and the maximum number of seconds to wait for all
fragments of a packet to be received (timeout limit).)
c) Packets where the source address is defined as being on a broadcast network
d) Packets where the source address is defined as being on a multicast network
e) Packets where the source address is defined as being a loopback address
f) The TSF shall reject and be capable of logging network packets where the source or
destination address of the network packet is defined as being unspecified (i.e. 0.0.0.0) or an
address “reserved for future use” (i.e. 240.0.0.0/4) as specified in RFC 5735 for IPv4;
g) The TSF shall reject and be capable of logging network packets where the source or
destination address of the network packet is defined as an “unspecified address” or an
address “reserved for future definition and use” (i.e. unicast addresses not in this address
range: 2000::/3) as specified in RFC 3513 for IPv6;
h) Packets with the IP options: Loose Source Routing, Strict Source Routing, or Record Route
specified
i) Other packets defined in FFW_RUL_EXT.1.6:
o In routed mode when the TOE receives a through-the-box:
▪ L2 broadcast packet (MAC address FF:FF:FF:FF:FF:FF)
▪ IPv4 packet with destination IP address equal to 0.0.0.0
▪ IPv4 packet with source IP address equal to 0.0.0.0
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 111 of 133
TOE SFRs How the SFR is Satisfied
o In routed or transparent mode when the TOE receives a through-the-box IPv4
packet with any of:
▪ first octet of the source IP address equal to zero
▪ network part of the source IP address equal to all 0's
▪ network part of the source IP address equal to all 1's
▪ source IP address host part equal to all 0's or all 1's
▪ source IP address and destination IP address are the same (“land.c”
attack)
o LAND Attack – Network packets with IP source address the same as the
destination IP and the destination port the same as the source port.
o ICMP Error Inspect and ICMPv6 Error Inspect (ICMP error packets when the
ICMP error messages are not related to any session already established in the
TOE).
o ICMPv6 condition (when the appliance is not able to find any established
connection related to the frame embedded in the ICMPv6 error message).
o ICMP Inspect bad icmp code (when an ICMP echo request/reply packet was
received with a malformed code(non-zero)).
The following traffic will be denied/dropped by the TOE by the default action (deny/drop) of
each Access Control Policy, and if logging is enabled for the default action the TOE will
generate audit messages when the action occurs:
a) Packets where the source address is equal to the address of the network interface where
the network packet was received.
b) Packets where the source or destination address of the network packet is a link-local
address.
c) Packets where the source address does not belong to the networks associated with the
network interface where the network packet was received, including a description of how the
TOE determines whether a source address belongs to a network associated with a given
network interface.
FFW_RUL_EXT.1.8[FW] FTD Only
TOE administrators have control over the sequencing of access control entries (ACEs) within
an access control list (ACL) to be able to set the sequence in which ACEs are applied within
any ACL. The entries within an ACL are always applied in a top-down sequence, and the first
entry that matches the traffic is the one that’s applied, regardless of whether there may be a
more precise match for the traffic further down in the ACL. By changing the
ordering/numbering of entries within an ACL, the administrator chances the sequence in
which the entries are compared to network traffic flows.
FFW_RUL_EXT.1.9[FW] FTD Only
An implicit “deny-all” rule is applied to all interfaces to which any traffic filtering rule has
been applied. The implicit deny-all rule is executed after all admin-defined rules have been
executed, and will result in dropping all traffic that has not been explicitly permitted, or
Page 112 of 133
TOE SFRs How the SFR is Satisfied
explicitly denied. If an administrator wants to log all denied traffic, a rule entry should be
added that denies all traffic and logs it, e.g. “access-list sample-acl deny ip any any log”.
FFW_RUL_EXT.1.10[FW] FTD Only
The TOE administrators can configure the maximum number of half-open TCP connections
allowed by configuring a Network Analysis Policy to include SYN Attack Prevention with
desired limits. After the configured limit is reached, the TOE will act as a proxy for the server
and generates a SYN-ACK response to new client SYN request. When the TOE receives an ACK
back from the client, it can then authenticate that the client is real and allow the connection to
the server. If an ACK is not received in the configurable time frame, the session is closed,
resource is returned to the free pool, and it will be counted. The default idle time until a TCP
half-open connection closes is 10 minutes.
FFW_RUL_EXT.2[FW] FTD Only
The TOE supports numerous TCP and UDP protocols that require dynamic establishment of
secondary network sessions including FTP and the establishment of the sessions along with
the dynamical definition of the rule are treated as auditable events. The TOE will manage
establishment and teardown of the following protocols in accordance with the RFC for each
protocol:
• FTP (File Transfer Protocol) is a TCP protocol supported in either active or passive mode:
o In active mode the client initiates the control session, and the server initiates the
data session to a client port provided by the client;
o For active FTP to be allowed through the TOE, the firewall rules must explicitly
permit the control session from the client to the server, and “inspect ftp” must be
enabled. The TOE will then explicitly permit a control session to be initiated from
the client to the server, and implicitly permit data sessions to be initiated from
the server to the client while the control session is active.
o In passive (PASV) mode, the client initiates the control session, and the client also
initiates the data session to a secondary port provided to the client by the server.
For passive FTP to be permitted through the TOE, the firewall rules must explicitly permit the
control session from the client to the server, and “inspect ftp” must be enabled with the
“match passive-ftp” option enabled. That feature will cause the TOE to look for the PASV or
EPSV commands in the FTP control traffic and for the server’s destination port, and
dynamically permit the data session.
Drawn from mod_vpngw_v1.1
FCS_CKM.1/IKE [VPN] See FCS_CKM.1
FIA_PSK_EXT.1[VPN] FTD Only
The TOE supports use of IKEv2 pre-shared keys for authentication of IPsec tunnels. Pre-
shared keys can be entered as ASCII character strings, or HEX values. The text-based pre-
shared keys can be composed of any combination of upper and lower case letters, numbers,
and special characters. The TOE supports keys that are from 1 character in length up to 127 in
length. The text-based pre-shared key is conditioned by one of the prf functions (HMAC-SHA-
1, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512) configured by the administrator.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 113 of 133
TOE SFRs How the SFR is Satisfied
FPF_RUL_EXT.1[VPN] FTD Only
An authorized administrator can define the traffic that needs to be protected by FTD by
configuring access lists (permit, deny, log), applying these access lists to VPN policies (peer-
to-peer and remote access VPN policies), and then assigning those policies to FTDs.
Therefore, traffic may be selected on the basis of the source and destination address, and
optionally the Layer 4 protocol and port.
The TOE enforces information flow policies on network packets that are received by TOE
interfaces and leave the TOE through other TOE interfaces. When network packets are
received on a TOE interface, the TOE verifies whether the network traffic is allowed or not
and performs one of the following actions, pass/not pass information, as well as optional
logging.
The TOE implements rules that define the permitted flow of traffic between interfaces of the
TOE for unauthenticated traffic. These rules control whether a packet is transferred from one
interface to another based on:
1. Presumed address of source
2. Presumed address of destination
3. Transport layer protocol (or next header in IPv6)
4. Service used (UDP or TCP ports, both source and destination)
5. Network interface on which the connection request occurs
These rules are supported for the following protocols: RFC 791(IPv4); RFC 2460 (IPv6); RFC
793 (TCP); RFC 768 (UDP). TOE compliance with these protocols is verified via regular quality
assurance, regression, and interoperability testing.
The TOE supports all IPv4 protocols excluding Protocol 2 (IGMP) which is not routable and
thus will not be forwarded by the TOE.
The TOE supports the following 15 IPv6 protocols:
• Transport Layer Protocol 4 - IPv4 encapsulation
• Transport Layer Protocol 6 - Transmission Control
• Transport Layer Protocol 8 - Exterior Gateway Protocol
• Transport Layer Protocol 9 - any private interior gateway
• Transport Layer Protocol 17 - User Datagram
• Transport Layer Protocol 41 - IPv6 encapsulation
• Transport Layer Protocol 46 - Reservation Protocol
• Transport Layer Protocol 47 - General Routing Encapsulation
• Transport Layer Protocol 49 - BNA
• Transport Layer Protocol 58 - ICMP for IPv6
• Transport Layer Protocol 59 - No Next Header for IPv6
• Transport Layer Protocol 88 - TCF
• Transport Layer Protocol 89 - EIGRP
Page 114 of 133
TOE SFRs How the SFR is Satisfied
• Transport Layer Protocol 105 - SCPS Transport Layer Protocol
• Transport Layer Protocol 112 - Virtual Router Redundancy Protocol
All other IPv6 protocols from the RFC Values for IPv4 and IPv6 table in the MOD VPNGW SD
v1.1 are dropped by default by the TOE.
Packets will be dropped unless a specific rule has been set up to allow the packet to pass
(where the attributes of the packet match the attributes in the rule and the action associated
with the rule is to pass traffic). Rules are enforced on a first match basis from the top down. As
soon as a match is found the action associated with the rule is applied.
These rules are entered in the form of access lists at the CLI (via ‘access list’ and ‘access group’
commands). These interfaces reject traffic when the traffic arrives on an external TOE
interface, and the source address is an external IT entity on an internal network;
These interfaces reject traffic when the traffic arrives on an internal TOE interface, and the
source address is an external IT entity on the external network;
These interfaces reject traffic when the traffic arrives on either an internal or external TOE
interface, and the source address is an external IT entity on a broadcast network;
These interfaces reject traffic when the traffic arrives on either an internal or external TOE
interface, and the source address is an external IT entity on the loopback network;
These interfaces reject requests in which the subject specifies the route for information to
flow when it is in route to its destination; and
For application protocols supported by the TOE (e.g., DNS, HTTP, SMTP, and POP3), these
interfaces deny any access or service requests that do not conform to its associated published
protocol specification (e.g., RFC). This is accomplished through protocol filtering proxies that
are designed for that purpose.
Otherwise, these interfaces pass traffic only when its source address matches the network
interface originating the traffic to the network interface corresponding to the traffic’s
destination address.
During the boot cycle, the TOE first powers on hardware, loads the image, and executes the
power on self-tests. Until the power on self tests successfully complete, the interfaces to the
TOE are deactivated. Once the tests complete, the interfaces become active and the rules
associated with the interface become immediately operational. There is no state during
initialization/ startup that the access lists are not enforced on an interface.
During initialization/startup (while the TOE is booting) the configuration has yet to be loaded,
and no traffic can flow through any of its interfaces. No traffic can flow through the TOE
interfaces until the POST has completed, and the configuration has been loaded. If any aspect
of the POST fails during boot, the TOE will reload without forwarding traffic. If a critical
component of the TOE, such as the clock or cryptographic modules, fails while the TOE is in an
operational state, the TOE will reload, which stops the flow of traffic. If a component such as a
network interface, which is not critical to the operation of the TOE, but may be critical to one
or more traffic flows, fails while the TOE is operational, the TOE will continue to function,
though all traffic flows through the failed network interface(s) will be dropped.
FPT_FLS.1/SelfTest[VPN] Noise source health tests are run both periodically and at start-up to determine the functional
health of the noise source. These tests are specifically designed to catch catastrophic losses in
the overall entropy associated with the noise source. Tests are run on the raw noise output,
before the application of any conditioners. If a noise source fails the health test either at start-
up or after the device is operational, the platform will be shut down.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 115 of 133
TOE SFRs How the SFR is Satisfied
Whenever a failure (e.g., POST or integrity test fails) occurs within the TOE that results in the
TOE ceasing operation, the TOE securely disables its interfaces to prevent the unintentional
flow of any information to or from the TOE and reloads. So long as the failures persist, the
TOE will continue to reload. This functionally prevents any failure from causing an
unauthorized information flow. There are no failures that circumvent this protection.
FPT_TST_EXT.3 [VPN]
See FPT_TST_EXT.1
FTA_SSL.3/VPN[VPN] FTD Only
When a remote VPN client session reaches a period of inactivity, its connection is terminated
and it must re-establish the connection with new authentication to resume operation. This
period of inactivity is set by the administrator using Objects > Object Management > Group
Policy > Session Settings > Idle Timeout in the VPN configuration. The Group Policy is then
tied to a Connection Profile.
FTA_TSE.1[VPN] FTD Only
The TOE allows for creation of ACLs that restrict VPN connectivity based client’s IP address
(location). These ACLs allow customization of all of these properties to allow or deny access
(Objects > Object Management > Group Policy > Traffic Filter Fields > Access List Filter).
In addition, the administrator can create Group Policy tied to Connection Profile (Objects >
Object Management > Group Policy > Session Settings > Access Hours) which can be used
to restrict access based on date and time.
FTA_VCM_EXT.1[VPN] FTD Only
The TOE provides the option to assign the remotely connecting VPN client an internal
network IP address. The Objects > Object Management > Address Pools can be used to
define the range of IP and IPv6 addresses to be available for use.
FTP_ITC.1.1[VPN] See FTP_ITC.1
Page 116 of 133
7 SUPPLEMENTAL TOE SUMMARY SPECIFICATION INFORMATION
7.1 Intrusion Rule Definition
An intrusion rule is a set of keywords and arguments that the system uses to detect attempts to
exploit vulnerabilities on your network. As the system analyzes network traffic, it compares packets
against the conditions specified in each rule. If the packet data matches all the conditions specified
in a rule, the rule triggers. If a rule is an alert rule, it generates an intrusion event. If it is a pass rule,
it ignores the traffic. For a drop rule in an inline deployment, the system drops the packet and
generates an event. The administrator can view and evaluate intrusion events from the FMC web
interface.
All rules contain two logical sections: the rule header and the rule options. The rule header
contains:
• the rule's action or type
• the protocol
• the source and destination IP addresses and netmasks
• direction indicators showing the flow of traffic from source to destination
• the source and destination ports
The rule options section contains:
• event messages
• keywords and their parameters and arguments
• patterns that a packet’s payload must match to trigger the rule
• specifications of which parts of the packet the rules engine should inspect
The following diagram illustrates the parts of a rule:
For example,
7.1.1 Intrusion Rule Header
Every rule has a rule header containing parameters and arguments. The following illustrates parts
of a rule header:
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 117 of 133
Action (alert) – generates an intrusion event when triggered and operations (allow, block/drop)
associated with policies.
Protocol (tcp) – Tests TCP traffic only. ICMPv4, ICMPv6, IPv4, IPv6, TCP, and UDP protocols are
supported.
Source IP ($EXTERNAL_NET) – Tests traffic coming from any host that is not on your internal
network.
Source Port (any) – Tests traffic coming from any port on the originating host.
Operate (->) – Tests external traffic destined for the web servers on your network.
Destination IP ($HTTP_SERVERS) - Tests traffic to be delivered to any host specified as a web server
on your internal network. Both IP and IPv6 addresses and ranges are supported.
Destination Port ($HTTP_PORTS) - Tests traffic delivered to an HTTP port on your internal network.
7.1.2 Intrusion Rule Options and Keywords
Rule options follow the rule header and are enclosed inside a pair of parentheses. There may be one
option or many and the options are separated with a semicolon. If you use multiple options, these
options form a logical AND. The action in the rule header is invoked only when all criteria in the
options are true. In general, an option may have two parts: a keyword and an argument.
The message keyword: Specify meaningful text that appears as a message when the rule triggers.
The ack keyword: Specify the acknowledgement value. For example, (flags: A; ack: 0; msg: "TCP
ping detected";)means receive a TCP packet with the A flag set and the acknowledgement contains a
value of 0.
The content keyword: Specify data pattern inside a packet. The pattern may be presented in the
form of an ASCII string or as binary data in the form of hexadecimal characters.
The offset keyword: Specify a certain offset from the start of the data part of the packet to search.
The dsize keyword: Specify the length of the data part of a packet.
The flags keyword: Find out which flag bits are set inside the TCP header of a packet.
The fragbits keyword: Find out which three frag bits (Reserved, Don’t Frag, More Frag) in the IP
headers.
The fragoffset keyword: Tests the offset of a fragmented packet.
The itype keyword: Specify the ICMP type.
The icode keyword: Specify the ICMP code.
The ipopts keyword: Specify the IP Options. Record Route, Loose Source Routing, Strict Source
Routing.
The ip_proto keyword: Specify the IP protocol number.
The id keyword: Specify the IP header fragment identification field
Page 118 of 133
The nocase keyword: Its only purpose is to make a case insensitive search of a pattern within the
data part of a packet. It is used in conjunction with the content keyword.
The seq keyword: Specify the sequence number of a TCP packet.
The window keyword: Specify the TCP window size.
The flow keyword: Apply a rule on TCP sessions to packets flowing in a particular direction.
The tos keyword: Detect a specific value in the Type of Service (TOS) field of the IP header.
The ttl keyword: Detect Time to Live value in the IP header of the packet.
7.2 Tracking of Stateful Firewall Connections
7.2.1 Establishment and Maintenance of Stateful Connections
As network traffic enters an interface of the TOE, the TOE inspects the packet header information to
determine whether the packet is allowed by access control lists, and whether an established
connection already exists for that specific traffic flow. The TOE maintains and continuously updates
connection state tables to keep tracked of establishment, teardown, and open sessions. To help
determine whether a packet can be part of a new session or an established session, the TOE uses
information in the packet header and protocol header fields to determine the session state to which
the packet applies as defined by the RFC for each protocol.
7.2.2 Viewing Connections and Connection States
To display the connection state for the designated connection type, use the show conn command in
privileged EXEC mode. This command supports IPv4 and IPv6 addresses. The syntax is:
show conn [count | [all] [detail] [long] [state state_type] [protocol {tcp | udp}] [scansafe]
[address src_ip[-src_ip] [netmask mask]] [port src_port[-src_port]] [address dest_ip[-dest_ip]
[netmask mask]] [port dest_port[-dest_port]] [user-identity | user [domain_nickname\]user_name
| user-group [domain_nickname\\]user_group_name] | security-group]
The show conn command displays the number of active TCP and UDP connections, and provides
information about connections of various types. By default, the output of “show conn” shows only
the through-the-TOE connections. To include connections to/from the TOE itself in the command
output, add the all keyword, “show conn all”.
Table 23: Syntax Description
address (Optional) Displays connections with the specified source or destination IP
address.
all (Optional) Displays connections that are to the device or from the device, in
addition to through-traffic connections.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 119 of 133
count (Optional) Displays the number of active connections.
dest_ip (Optional) Specifies the destination IP address (IPv4 or IPv6). To specify a range,
separate the IP addresses with a dash (-). For example:
10.1.1.1-10.1.1.5
dest_port (Optional) Specifies the destination port number. To specify a range, separate the
port numbers with a dash (-). For example:
1000-2000
detail (Optional) Displays connections in detail, including translation type and interface
information.
long (Optional) Displays connections in long format.
netmask mask (Optional) Specifies a subnet mask for use with the given IP address.
port (Optional) Displays connections with the specified source or destination port.
protocol {tcp | udp} (Optional) Specifies the connection protocol, which can be tcp or udp.
scansafe (Optional) Shows connections being forwarded to the Cloud Web Security server.
security-group (Optional) Specifies that all connections displayed belong to the specified security
group.
src_ip (Optional) Specifies the source IP address (IPv4 or IPv6). To specify a range,
separate the IP addresses with a dash (-). For example:
10.1.1.1-10.1.1.5
src_port (Optional) Specifies the source port number. To specify a range, separate the port
numbers with a dash (-). For example:
1000-2000
state state_type (Optional) Specifies the connection state type.
user
[domain_nickname\]
user_name
(Optional) Specifies that all connections displayed belong to the specified user.
When you do not include the domain_nickname argument, the TOE displays
information for the user in the default domain.
user-group
[domain_nickname\\]
user_group_name
(Optional) Specifies that all connections displayed belong to the specified user
group. When you do not include the domain_nickname argument, the TOE displays
information for the user group in the default domain.
user-identity (Optional) Specifies that the TOE display all connections for the Identity Firewall
feature. When displaying the connections, the TOE displays the user name and IP
address when it identifies a matching user. Similarly, the TOE displays the host
name and an IP address when it identifies a matching host.
The connection types that you can specify using the show conn state command are defined in the
table below. When specifying multiple connection types, use commas without spaces to separate
the keywords.
Page 120 of 133
Table 24: Connection State Types
Keyword Connection Type Displayed
up Connections in the up state.
conn_inbound Inbound connections.
ctiqbe CTIQBE connections
data_in Inbound data connections.
data_out Outbound data connections.
finin FIN inbound connections.
finout FIN outbound connections.
h225 H.225 connections
h323 H.323 connections
http_get HTTP get connections.
mgcp MGCP connections.
nojava Connections that deny access to Java applets.
rpc RPC connections.
service_module Connections being scanned by an SSM.
sip SIP connections.
skinny SCCP connections.
smtp_data SMTP mail data connections.
sqlnet_fixup_data SQL*Net data inspection engine connections.
tcp_embryonic TCP embryonic connections.
vpn_orphan Orphaned VPN tunneled flows.
When using the detail option, the TOE displays information about the translation type and
interface information using the connection flags defined in the table below.
Table 25: Connection State Flags
Flag Description
a awaiting outside ACK to SYN
A awaiting inside ACK to SYN
b TCP state bypass. By default, all traffic that passes through the FTD is inspected using the
Adaptive Security Algorithm and is either allowed through or dropped based on the security
policy. In order to maximize the firewall performance, the FTD checks the state of each packet
(for example, is this a new connection or an established connection?) and assigns it to either the
session management path (a new connection SYN packet), the fast path (an established
connection), or the control plane path (advanced inspection). TCP packets that match existing
connections in the fast path can pass through the adaptive security appliance without
rechecking every aspect of the security policy. This feature maximizes performance.
B initial SYN from outside
C Computer Telephony Interface Quick Buffer Encoding (CTIQBE) media connection
d dump
D DNS
E outside back connection. This is a secondary data connection that must be initiated from the
inside host. For example, using FTP, after the inside client issues the PASV command and the
outside server accepts, the FTD preallocates an outside back connection with this flag set. If the
inside client attempts to connect back to the server, then the FTD denies this connection
attempt. Only the outside server can use the preallocated secondary connection.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 121 of 133
f inside FIN
F outside FIN
g Media Gateway Control Protocol (MGCP) connection
G connection is part of a group
The G flag indicates the connection is part of a group. It is set by the GRE and FTP Strict fixups to
designate the control connection and all its associated secondary connections. If the control
connection terminates, then all associated secondary connections are also terminated.
h H.225
H H.323
i incomplete TCP or UDP connection
I inbound data
k Skinny Client Control Protocol (SCCP) media connection
K GTP t3-response
m SIP media connection
M SMTP data
O outbound data
p replicated (unused)
P inside back connection
This is a secondary data connection that must be initiated from the inside host. For example,
using FTP, after the inside client issues the PORT command and the outside server accepts, the
FTD preallocates an inside back connection with this flag set. If the outside server attempts to
connect back to the client, then the FTD denies this connection attempt. Only the inside client
can use the preallocated secondary connection.
q SQL*Net data
r inside acknowledged FIN
R If TCP: outside acknowledged FIN for TCP connection
If UDP: UDP RPC2
Because each row of “show conn” command output represents one connection (TCP or UDP),
there will be only one R flag per row.
s awaiting outside SYN
S awaiting inside SYN
t SIP transient connection
For a UDP connection, the value t indicates that it will timeout after one minute.
T SIP connection
For UDP connections, the value T indicates that the connection will timeout according to the
value specified using the “timeout sip” command.
U up
V VPN orphan
W WAAS
X Inspected by the service module, such as a CSC SSM.
y For clustering, identifies a backup owner flow.
Page 122 of 133
Y For clustering, identifies a director flow.
z For clustering, identifies a forwarder flow.
Z Cloud Web Security
A single connection is created for multiple DNS sessions, as long as they are between the same two
hosts, and the sessions have the same 5-tuple (source/destination IP address, source/destination
port, and protocol). DNS identification is tracked by app_id, and the idle timer for each app_id runs
independently. Because the app_id expires independently, a legitimate DNS response can only pass
through the TOE within a limited period of time and there is no resource build-up. However, when
the show conn command is entered, you will see the idle timer of a DNS connection being reset by
a new DNS session. This is due to the nature of the shared DNS connection and is by design.
When the TOE creates a pinhole to allow secondary connections, this is shown as an incomplete
conn by the show conn command. Incomplete connections will be cleared from the connections
table when they reach their timeout limit, and can be cleared manually by using the “clear conn”
command. When there is no TCP traffic for the period of inactivity defined by the timeout conn
command (by default, 1:00:00), the connection is closed and the corresponding conn flag entries
are no longer displayed.
If a LAN-to-LAN/Network-Extension Mode tunnel drops and does not come back, there might be a
number of orphaned tunnel flows. These flows are not torn down as a result of the tunnel going
down, but all the data attempting to flow through them is dropped. The show conn command
output shows these orphaned flows with the V flag.
Table 26: TCP connection directionality flags
Flag Description
B Initial SYN from outside
a Awaiting outside ACK to SYN
A Awaiting inside ACK to SYN
f Inside FIN
F Outside FIN
s Awaiting outside SYN
S Awaiting inside SYN
7.2.3 Examples
The following is sample output from the show conn command. This example shows a TCP session
connection from inside host 10.1.1.15 to the outside Telnet server at 10.10.49.10. Because there is
no B flag, the connection is initiated from the inside. The "U", "I", and "O" flags denote that the
connection is active and has received inbound and outbound data.
hostname# show conn
54 in use, 123 most used
TCP out 10.10.49.10:23 in 10.1.1.15:1026 idle 0:00:22, bytes 1774, flags UIO
UDP out 10.10.49.10:31649 in 10.1.1.15:1028 idle 0:00:14, bytes 0, flags D-
TCP dmz 10.10.10.50:50026 inside 192.168.1.22:5060, idle 0:00:24, bytes 1940435, flags UTIOB
TCP dmz 10.10.10.50:49764 inside 192.168.1.21:5060, idle 0:00:42, bytes 2328346, flags UTIOB
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 123 of 133
TCP dmz 10.10.10.51:50196 inside 192.168.1.22:2000, idle 0:00:04, bytes 31464, flags UIB
TCP dmz 10.10.10.51:52738 inside 192.168.1.21:2000, idle 0:00:09, bytes 129156, flags UIOB
TCP dmz 10.10.10.50:49764 inside 192.168.1.21:0, idle 0:00:42, bytes 0, flags Ti
TCP outside 192.168.1.10(20.20.20.24):49736 inside 192.168.1.21:0, idle 0:01:32, bytes 0, flags Ti
TCP dmz 10.10.10.50:50026 inside 192.168.1.22:0, idle 0:00:24, bytes 0, flags Ti
TCP outside 192.168.1.10(20.20.20.24):50663 inside 192.168.1.22:0, idle 0:01:34, bytes 0, flags Ti
TCP dmz 10.10.10.50:50026 inside 192.168.1.22:0, idle 0:02:24, bytes 0, flags Ti
TCP outside 192.168.1.10(20.20.20.24):50663 inside 192.168.1.22:0, idle 0:03:34, bytes 0, flags Ti
TCP dmz 10.10.10.50:50026 inside 192.168.1.22:0, idle 0:04:24, bytes 0, flags Ti
TCP outside 192.168.1.10(20.20.20.24):50663 inside 192.168.1.22:0, idle 0:05:34, bytes 0, flags Ti
TCP dmz 10.10.10.50:50026 inside 192.168.1.22:0, idle 0:06:24, bytes 0, flags Ti
TCP outside 192.168.1.10(20.20.20.24):50663 inside 192.168.1.22:0, idle 0:07:34, bytes 0, flags Ti
The following is sample output from the show conn detail command. This example shows a UDP
connection from outside host 10.10.49.10 to inside host 10.1.1.15. The D flag denotes that this is a
DNS connection. The number 1028 is the DNS ID over the connection.
hostname# show conn detail
54 in use, 123 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
B - initial SYN from outside, b - TCP state-bypass or nailed, C - CTIQBE media,
D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, M - SMTP data, m - SIP media, n - GUP
O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection,
q - SQL*Net data, R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,
V - VPN orphan, W - WAAS,
X - inspected by service module
TCP outside:10.10.49.10/23 inside:10.1.1.15/1026, flags UIO, idle 39s, uptime 1D19h, timeout 1h0m, bytes 1940435
UDP outside:10.10.49.10/31649 inside:10.1.1.15/1028, flags dD, idle 39s, uptime 1D19h, timeout 1h0m, bytes 1940435
TCP dmz:10.10.10.50/50026 inside:192.168.1.22/5060, flags UTIOB, idle 39s, uptime 1D19h, timeout 1h0m, bytes 1940435
TCP dmz:10.10.10.50/49764 inside:192.168.1.21/5060, flags UTIOB, idle 56s, uptime 1D19h, timeout 1h0m, bytes 2328346
TCP dmz:10.10.10.51/50196 inside:192.168.1.22/2000, flags UIB, idle 18s, uptime 1D19h, timeout 1h0m, bytes 31464
TCP dmz:10.10.10.51/52738 inside:192.168.1.21/2000, flags UIOB, idle 23s, uptime 1D19h, timeout 1h0m, bytes 129156
TCP outside:10.132.64.166/52510 inside:192.168.1.35/2000, flags UIOB, idle 3s, uptime 1D21h, timeout 1h0m, bytes 357405
TCP outside:10.132.64.81/5321 inside:192.168.1.22/5060, flags UTIOB, idle 1m48s, uptime 1D21h, timeout 1h0m, bytes 2083129
TCP outside:10.132.64.81/5320 inside:192.168.1.21/5060, flags UTIOB, idle 1m46s, uptime 1D21h, timeout 1h0m, bytes 2500529
TCP outside:10.132.64.81/5319 inside:192.168.1.22/2000, flags UIOB, idle 31s, uptime 1D21h, timeout 1h0m, bytes 32718
TCP outside:10.132.64.81/5315 inside:192.168.1.21/2000, flags UIOB, idle 14s, uptime 1D21h, timeout 1h0m, bytes 358694
Page 124 of 133
TCP outside:10.132.64.80/52596 inside:192.168.1.22/2000, flags UIOB, idle 8s, uptime 1D21h, timeout 1h0m, bytes 32742
TCP outside:10.132.64.80/52834 inside:192.168.1.21/2000, flags UIOB, idle 6s, uptime 1D21h, timeout 1h0m, bytes 358582
TCP outside:10.132.64.167/50250 inside:192.168.1.35/2000, flags UIOB, idle 26s, uptime 1D21h, timeout 1h0m, bytes 375617
7.3 Key Zeroization
The following table describes the key zeroization referenced by FCS_CKM.4 provided by the TOE.
DRAM (dynamic random access memory) is volatile memory and NVRAM (non-volatile random
access memory) is non-volatile “flash” memory.
Table 27: TOE Key Zeroization
Critical Security Parameters
(CSPs)
Zeroization Cause and Effect
Diffie-Hellman Shared Secret Automatically zeroized after completion of DH exchange, by calling a
specific API within the two crypto modules, when module is shutdown, or
reinitialized.
Storage: DRAM
Overwritten with: 0x00
Diffie Hellman Private and Public
Exponent
Automatically zeroized upon completion of DH exchange, by calling a
specific API within the two crypto modules, and when module is
shutdown, or reinitialized.
Storage: DRAM
Overwritten with: 0x00
skeyid Session Encryption Key and IKE Session Authentication Key.
Automatically zeroized after IKE session terminated.
Storage: DRAM
Overwritten with: 0x00
skeyid_d Session Encryption Key and IKE Session Authentication Key.
Automatically zeroized after IKE session terminated.
Storage: DRAM
Overwritten with: 0x00
IKE Session Encryption Key Session Encryption Key and IKE Session Authentication Key.
Automatically zeroized after IKE session terminated.
Storage: DRAM
Overwritten with: 0x00
IKE Session Authentication Key Session Encryption Key and IKE Session Authentication Key.
Automatically zeroized after IKE session terminated.
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 125 of 133
Critical Security Parameters
(CSPs)
Zeroization Cause and Effect
Storage: DRAM
Overwritten with: 0x00
ISAKMP Preshared Zeroized using the following command:
# no crypto isakmp key
Storage: NVRAM
Overwritten with: 0x00
IKE RSA and ECDSA Private and
Public Keys
Automatically overwritten when a new key is generated or zeroized using
the following commands:
# crypto key zeroize rsa
# crypto key zeroize ec
Storage: NVRAM
Overwritten with: 0x00
IPsec Encryption Key Automatically zeroized when IPsec session terminated.
Storage: DRAM
Overwritten with: 0x00
IPsec Authentication Key Automatically zeroized when IPsec session terminated.
Storage: DRAM
Overwritten with: 0x00
SSHv2 Private and Public Key Automatically zeroized upon generation of a new key
Storage: NVRAM
Overwritten with: 0x00
SSHv2 Session Key Automatically zeroized when the SSH session is terminated.
Storage: NVRAM
Overwritten with: 0x00
All CSPs Zeroized on-demand on all file systems via the “erase” command.
Storage: NVRAM
Overwritten with: 0x00
Page 126 of 133
Critical Security Parameters
(CSPs)
Zeroization Cause and Effect
TLS Server Private Key Zeroized when the HTTPS server is no longer in use.
Storage: NVRAM
Overwritten with: 0x00
7.4 CAVP Certificate Equivalence
The TOE models and processors included in the evaluation are shown in the following table. The
TOE includes multiple cryptographic modules across the range of TOE components. These modules
are commonly referred to as FOM (FIPS Object Models). The CAVP-certified FOM of the TOE are
listed in the table below (Table 28) along with the CPU for which they were certified, and the TOE
component on which they’re used. The table on the following page Table 29 lists the CAVP
certificate numbers for each FOM for each applicable SFR.
Table 28: Processors, FOM and CAVP Cert
CPU Family CPU Model
(Microarchitecture)
FOM Physical
Appliances
CAVP
Certificate#
FTD
Intel Xeon D Intel Xeon D-1526
(Broadwell)
CiscoSSL FOM
(Single Pass)
Cryptographic
Implementation
7.3sp
FP 2110 A2585
Intel Xeon D-1528
(Broadwell)
FP 2120
Intel Xeon D-1548
(Broadwell)
FP 2130
Intel Xeon D-1577
(Broadwell)
FP 2140
Intel Atom C3000 Intel Atom C3558
(Goldmont)
FP 1010
Intel Atom C3858
(Goldmont)
FP 1120
Intel Atom C3958
(Goldmont)
FP 1140
FP 1150
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 127 of 133
CPU Family CPU Model
(Microarchitecture)
FOM Physical
Appliances
CAVP
Certificate#
FMC
Intel Xeon E5-
2600 v4
Intel Xeon E5-2620 v4
(Broadwell)
CiscoSSL FOM
(Single Pass)
Cryptographic
Implementation
7.3sp
FMC4500 A2585
Intel Xeon E5 2640 v4
(Broadwell)
FMC1000 and
FMC2500
Intel Xeon
Scalable
Intel Xeon Silver 4110
(Skylake)
FMC1600 and
FMC2600
Intel Xeon Silver 4116
(Skylake)
FMC4600
FMCv
Intel Xeon
Scalable w/
Linux 4 on ESXi
6.7/7.0
Intel XeonBronze 3104
(Skylake) w/ Linux 4 on
ESXi 6.7/7.0
CiscoSSL FOM-
Virtual 7.3sp
UCSC-C220-M5,
UCSC-C240-M5
and UCSC-C480-
M5
A2952
Intel Xeon Silver 4110
(Skylake) w/ Linux 4 on
ESXi 6.7/7.0
UCSC-C220-M5,
UCSC-C240-M5
and UCSC-C480-
M5
Intel Xeon® Gold 6128
(Skylake) w/ Linux 4 on
ESXi 6.7/7.0
UCSC-C220-M5,
UCSC-C240-M5
and UCSC-C480-
M5
Intel Xeon Platinum 8153
(Skylake) w/ Linux 4 on
ESXi 6.7/7.0
UCSC-C220-M5,
UCSC-C240-M5
and UCSC-C480-
M5
Page 128 of 133
CPU Family CPU Model
(Microarchitecture)
FOM Physical
Appliances
CAVP
Certificate#
Intel Xeon D w/
Linux 4 on ESXi
6.7/7.0
Intel Xeon D-1528
(Broadwell) w/ Linux 4 on
ESXi 6.7/7.0
UCS-E160S-M3
Intel Xeon D-1548
(Broadwell) w/ Linux 4 on
ESXi 6.7/7.0
UCS-E180D-M3
Table 29: Algorithm Certificate Numbers
Algorithm SFR
CiscoSSL FOM
(Single Pass)
Cryptographic
Implementation
7.3sp (FTD)
CiscoSSL FOM
(Single Pass)
Cryptographic
Implementation
7.3sp (FMC)
CiscoSSL FOM-
Virtual 7.3sp
(FMCv)
AES
CBC 128/256
GCM 128/256
FCS_COP.1/DataEncryption A2585 A2585 A2952
RSA
2048/3072 bits
Signature Gen & Verify
Key Gen & Verify
FCS_COP.1/SigGen
FCS_CKM.1
FCS_CKM.1/IKE
A2585 A2585 A2952
ECDSA curves P-256, P-
384 and P-521
Key Sizes – 256, 384 and
521 bits
Signature Gen & Verify
Key Gen and Verify
FCS_COP.1/SigGen
FCS_CKM.1
FCS_CKM.1/IKE
A2585 A2585 A2952
Hashing
SHA-1, SHA-256, SHA-
384, SHA-512
FCS_COP.1/Hash A2585 A2585 A2952
Keyed Hash FCS_COP.1/KeyedHash A2585 A2585 A2952
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 129 of 133
HMAC-SHA-1,
HMAC-SHA-256
HMAC-SHA-384
HMAC-SHA-512
DRBG (Key Size – 256)
CTR_DRBG(AES)
FCS_RBG_EXT.1 A2585 A2585 A2952
KAS ECC FCS_CKM.2 A2585 A2585 A2952
Page 130 of 133
8 ANNEX A: REFERENCES
The following documentation was used to prepare this ST:
Table 30: References
Identifier Description
[CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1:
Introduction and general model, dated April 2017, Version 3.1 Revision 5, CCMB-
2017-04-001
[CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2:
Security functional components, dated April 2017, Version 3.1 Revision 5, CCMB-
2017-04-002
[CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3:
Security assurance components, dated April 2017, Version 3.1 Revision 5, CCMB-
2017-04-003
[CEM] Common Methodology for Information Technology Security Evaluation –
Evaluation Methodology, dated April 2017, Version 3.1 Revision 5, CCMB-2017-04-
004
[800-38A] NIST Special Publication 800-38A Recommendation for Block 2001 Edition
Recommendation for Block Cipher Modes of Operation Methods and Techniques
December 2001
[800-56A] NIST Special Publication 800-56A, March, 2007
Recommendation for Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography (Revised)
[800-56B] NIST Special Publication 800-56B Recommendation for Pair-Wise, August 2009
Key Establishment Schemes Using Integer Factorization Cryptography
[FIPS 140-2] FIPS PUB 140-2 Federal Information Processing Standards Publication
Security Requirements for Cryptographic Modules May 25, 2001
[FIPS PUB 186-4] FIPS PUB 186-3 Federal Information Processing Standards Publication Digital
Signature Standard (DSS) July 2013
[FIPS PUB 198-1] Federal Information Processing Standards Publication The Keyed-Hash Message
Authentication Code (HMAC) July 2008
[800-90] NIST Special Publication 800-90A Recommendation for Random Number
Generation Using Deterministic Random Bit Generators January 2012
[FIPS PUB 180-4] FIPS PUB 180-4 Federal Information Processing Standards Publication Secure
Hash Standard (SHS) March 2012
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 131 of 133
9 ANNEX B: SFR TOE COMPONENTS MAPPING
This TOE is a distributed TOE consistent with Use Case 3 as defined in the NDcPP. The following
mapping shows which SFRs are supported by which TOE components:
Table 31: SFR Mapping
Requirement Description Distributed
TOE SFR
Allocation
Distributed TOE
Audit
Generation
Reproduced from NDcPP
FAU_GEN.1 Audit Data Generation All All
(startup/shutdown,
and admin actions)
FAU_GEN.2 User Identity Association All N/A
FAU_GEN_EXT.1 Security Audit Generation All All
FAU_STG_EXT.1 Protected Audit Event Storage All N/A
FAU_STG_EXT.4 Protected Local Audit Event
Storage for Distributed TOEs
All N/A
FAU_STG_EXT.5 Protected Remote Audit Event
Storage for Distributed TOEs
All N/A
FCO_CPC_EXT.1 Communication Partner Control All All
FCS_CKM.1 Cryptographic Key Generation All N/A
FCS_CKM.2 Cryptographic Key Establishment All N/A
FCS_CKM.4 Cryptographic Key Destruction All N/A
FCS_COP.1/DataEncryption Cryptographic Operation (AES
Data Encryption/Decryption)
All N/A
FCS_COP.1/SigGen Cryptographic Operation
(Signature Verification)
All N/A
FCS_COP.1/Hash Cryptographic Operation (Hash
Algorithm)
All N/A
FCS_COP.1/KeyedHash Cryptographic Operation (Keyed
Hash Algorithm)
All N/A
FCS_HTTPS_EXT.1 Protocol Feature Dependent FMC FMC
FCS_IPSEC_EXT.1 IPsec Protocol FTD FTD
FCS_RBG_EXT.1 Random Bit Generation All N/A
FCS_SSHS_EXT.1 SSH Server Protocol All All
FCS_TLSC_EXT.1 TLS Client All All
FCS_TLSC_EXT.2 TLS Client with authentication FMC N/A
FCS_TLSS_EXT.1 TLS Server All All
FIA_AFL.1 Authentication Failure
Management
All All
FIA_PMG_EXT.1 Password Management All N/A
FIA_UIA_EXT.1 User Identification and
Authentication
All All
FIA_UAU_EXT.2 Password-based Authentication
Mechanism
All All
FIA_UAU.7 Protected Authentication
Feedback
All N/A
FIA_X509_EXT.1/ITT
FIA_X509_EXT.1/Rev
X.509 Certification Validation All All
Page 132 of 133
FIA_X509_EXT.2(1)
FIA_X509_EXT.2(2)
X.509 Certificate Authentication All N/A
FIA_X509_EXT.3 Certificate Requests All N/A
FMT_MOF.1/ManualUpdate Trusted Update - Management of
Security Functions behaviour
All All
FMT_MTD.1/CoreData Management of TSF Data All N/A
FMT_MTD.1/CryptoKeys Management of TSF Data All N/A
FMT_SMF.1 Specification of Management
Functions
FMC (full)
FTD (subset)
(See TSS for
details.)
All
FMT_SMR.2 Restrictions on Security Roles All N/A
FPT_SKP_EXT.1 Protection of TSF Data (for
reading of all symmetric keys
All N/A
FPT_APW_EXT.1 Protection of Administrator
Passwords
All N/A
FPT_TST_EXT.1 Testing (Extended) All N/A
FPT_ITT.1
FPT_ITT.1/Join
Basic internal TSF data transfer
protection
All All
FPT_STM_EXT.1 Reliable Time Stamps All All
FPT_TUD_EXT.1 Trusted Update All All
FTA_SSL_EXT.1 TSF-Initiated Session Locking All All
FTA_SSL.3 TSF-initiated Termination All All
FTA_SSL.4 User-Initiated Termination All All
FTA_TAB.1 Default TOE Access Banner All N/A
FTP_ITC.1 Inter-TSF Trusted Channel All All
FTP_TRP.1/Admin Trusted Path All All
Reproduced from mod_ips_v1.0
FAU_GEN.1/IPS[IPS] Audit Data Generation (IPS) All All
FAU_SAR.1[IPS] Audit Review (IPS Data) FMC N/A
FAU_SAR.2[IPS] Restricted Audit Review (IPS
Data)
FMC N/A
FAU_SAR.3[IPS] Selectable Audit Review (IPS
Data)
FMC N/A
FAU_STG.1[IPS] Protected Audit Trail Storage (IPS
Data)
FMC N/A
FMT_SMF.1/IPS[IPS] Specification of Management
Functions (IPS)
All All
IPS_ABD_EXT.1[IPS] Anomaly-Based IPS Functionality FTD FTD
IPS_IPB_EXT.1[IPS] IP Blocking FTD FTD
IPS_NTA_EXT.1[IPS] Network Traffic Analysis All FMC
IPS SBD_EXT.1[IPS} Signature-Based IPS Functionality FTD FTD
Reproduced from mod_cpp_fw_v1.4e
FDP_RIP.2[FW] Full Residual Information
Protection
FTD N/A
FFW_RUL_EXT.1[FW] Stateful Traffic Filtering FTD FTD
FFW_RUL_EXT.2[FW] Stateful Filtering of Dynamic
Protocols
FTD FTD
FMT_SMF.1/FFW[FW] Specification of Management
Functions
FMC FMC
Cisco FTD (NGFW) 7.0 on Firepower 1000 and 2100 Series with FMC and FMCv Security Target
Page 133 of 133
Reproduced from mod_vpngw_v1.1
FCS_CKM.1/IKE[VPN] Cryptographic Key Generation (for
IKE Peer Authentication)
FTD N/A
FIA_PSK_EXT.1[VPN] Pre-Shared Key Composition FTD N/A
FMT_SMF.1/VPN [VPN] Specification of Management
Functions (VPN Gateway)
All N/A
FPF_RUL_EXT.1[VPN] Packet Filtering FTD FTD
FPT_FLS.1/SelfTest[VPN] Fail Secure FTD N/A
FPT_TST_EXT.3[VPN] Extended: TSF Testing FTD N/A
FTA_SSL.3[VPN] TSF-initiated Termination FTD N/A
FTA_TSE.1[VPN] TOE Session Establishment FTD N/A
FTA_VCM_EXT.1[VPN] VPN Client Management FTD N/A
FTP_ITC.1/VPN[VPN] Inter-TSF Trusted Channel FTD N/A