Palo Alto Networks
PA-220 Series, PA-400
Series, PA-800 Series, PA-
3200 Series, PA-3400 Series,
PA-5200 Series, PA-5400
Series, PA-5450, PA-7000
Series, and VM Series Next-
Generation Firewall with
PAN-OS 10.2
Security Target
Version: 1.0
Date: February 6, 2023
PAN OS 10.2 Security Target Palo Alto Networks
Page ii of v
Palo Alto Networks, Inc.
www.paloaltonetworks.com
© 2023 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks
can be found at https://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be
trademarks of their respective companies.
PAN OS 10.2 Security Target Palo Alto Networks
Page iii of v
Table of Contents
1. SECURITY TARGET INTRODUCTION ...............................................................................................................1
1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION .........................................................................................1
1.2 CONFORMANCE CLAIMS.................................................................................................................................4
1.3 CONVENTIONS................................................................................................................................................6
1.3.1 Terminology .........................................................................................................................................6
1.3.2 Acronyms..............................................................................................................................................7
2. PRODUCT DESCRIPTION.................................................................................................................................9
2.1 TOE OVERVIEW ...........................................................................................................................................10
2.2 TOE ARCHITECTURE.....................................................................................................................................12
2.2.1 Physical Boundaries ..........................................................................................................................13
2.2.2 Logical Boundaries ............................................................................................................................24
2.3 TOE DOCUMENTATION ...............................................................................................................................25
2.4 EXCLUDED FUNCTIONALITY..........................................................................................................................26
3. SECURITY PROBLEM DEFINITION...............................................................................................................27
4. SECURITY OBJECTIVES ..................................................................................................................................28
4.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ....................................................................28
5. IT SECURITY REQUIREMENTS ......................................................................................................................30
5.1 EXTENDED REQUIREMENTS ..........................................................................................................................30
5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS ..............................................................................................30
5.2.1 Security Audit (FAU) .........................................................................................................................32
5.2.2 Cryptographic Support (FCS) ...........................................................................................................36
5.2.3 User Data Protection (FDP) .............................................................................................................44
5.2.4 Identification and Authentication (FIA)...........................................................................................44
5.2.5 Security Management (FMT)............................................................................................................46
5.2.6 Protection of the TSF (FPT)..............................................................................................................47
5.2.7 TOE Access (FTA)..............................................................................................................................49
5.2.8 Trusted Path/Channels (FTP)...........................................................................................................50
5.2.9 Stateful Traffic Filtering (FFW) ........................................................................................................51
5.2.10 Packet Filtering (FPF)........................................................................................................................54
5.3 TOE SECURITY ASSURANCE REQUIREMENTS......................................................................................................55
6. TOE SUMMARY SPECIFICATION .................................................................................................................56
6.1 SECURITY AUDIT...........................................................................................................................................56
6.2 CRYPTOGRAPHIC SUPPORT...........................................................................................................................57
6.3 USER DATA PROTECTION .............................................................................................................................67
6.4 IDENTIFICATION AND AUTHENTICATION.......................................................................................................67
6.5 SECURITY MANAGEMENT .............................................................................................................................70
6.6 PROTECTION OF THE TSF.............................................................................................................................72
6.7 TOE ACCESS ................................................................................................................................................74
6.8 TRUSTED PATH/CHANNELS..........................................................................................................................74
6.9 STATEFUL TRAFFIC FILTERING.......................................................................................................................75
6.10 PACKET FILTERING....................................................................................................................................81
7. PROTECTION PROFILE CLAIMS ...................................................................................................................83
PAN OS 10.2 Security Target Palo Alto Networks
Page iv of v
8. RATIONALE.......................................................................................................................................................84
PAN OS 10.2 Security Target Palo Alto Networks
Page v of v
LIST OF FIGURES
Figure 1: TOE Architecture .....................................................................................................................................12
LIST OF TABLES
Table 1 TOE Platforms.............................................................................................................................................17
Table 2 Excluded Features ......................................................................................................................................26
Table 3 TOE Security Functional Components.....................................................................................................30
Table 4 Auditable Events (Network Device, Firewall).........................................................................................33
Table 5 Auditable Events (VPN Gateway).............................................................................................................35
Table 6 Assurance Components .............................................................................................................................55
Table 7 Cryptographic Functions ...........................................................................................................................57
Table 8 FIPS 186-4 Conformance ..........................................................................................................................60
Table 9 Private Keys and CSPs ...............................................................................................................................61
Page 1 of 84
1. Security Target Introduction
This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions,
ST conformance claims, and the ST organization. The TOE is the next-generation firewall running PAN-OS
v10.2.3-h2 provided by Palo Alto Networks Inc.
The next-generation firewall includes the PA-220, PA-220R, PA-410, PA-440, PA-450, PA-460, PA-820,
PA-850, PA-3220, PA-3250, PA-3260, PA-3410, PA-3420, PA-3430, PA-3440, PA-5220, PA-5250, PA-
5260, PA-5280, PA-5410, PA-5420, PA-5430, PA-5450, PA-7050, and PA-7080 appliances and the virtual
appliances in the VM-Series VM-50, VM-100, VM-200, VM-300, VM-500, VM-700, VM-1000-HV which
are used to manage enterprise network traffic flows using function specific processing for networking,
security, and management. The next-generation firewalls identify which applications are flowing across the
network, irrespective of port, protocol, or location.
The focus of this evaluation is on the TOE functionality supporting the claims in the collaborative Protection
Profile for Network Devices [NDcPP], PP-Module for Stateful Traffic Filter Firewalls [FW-Module], and PP-
Module for Virtual Private Network (VPN) Gateways [VPNGW-Module] as amended by CSfC Selections for
VPN Gateways [CSfC]. The CSfC Selections for VPN Gateways are specified in the following NSA’s website:
https://www.nsa.gov/Portals/70/documents/resources/everyone/csfc/components-list/selections/vpn-
gateways.pdf
The only capabilities covered by the evaluation are those specified in the aforementioned Protection
Profiles, all other capabilities are not covered in the evaluation. The security functionality specified in
[NDcPP], the [FW-Module], and the [VPNGW-Module] includes protection of communications between
TOE components and trusted IT entities, identification and authentication of administrators, auditing of
security-relevant events, ability to verify the source and integrity of updates to the TOE, the implementation
of firewall-related security features, the termination of IPsec VPN tunnels, and specifies CAVP-validated
cryptographic mechanisms.
The Security Target contains the following additional sections:
• Product Description (Section 2)
• Security Problem Definition (Section 3)
• Security Objectives (Section 4)
• IT Security Requirements (Section 5)
• TOE Summary Specification (Section 6)
• Protection Profile Claims (Section 7)
• Rationale (Section 8).
1.1 Security Target, TOE and CC Identification
ST Title – Palo Alto Networks PA-220 Series, PA-400 Series, PA-800 Series, PA-3200 Series, PA-3400
Series, PA-5200 Series, PA-5400 Series, PA-5450, PA-7000 Series, and VM Series Next-Generation Firewall
with PAN-OS 10.2 Security Target
ST Version – Version 1.0
ST Date – February 6, 2023
TOE Identification – Palo Alto Networks PA-220 Series, PA-400 Series, PA-800 Series, PA-3200 Series, PA-
3400 Series, PA-5200 Series, PA-5400 Series, PA-5450, PA-7000 Series, and VM Series, Next-Generation
Firewall with PAN-OS v10.2. The specific Firewall appliance models include:
1. PA-220 Series
Page 2 of 84
a. PA-220
b. PA-220R
2. PA-400 Series
a. PA-410
b. PA-440
c. PA-450
d. PA-460
3. PA-800 Series
a. PA-820
b. PA-850
4. PA-3200 Series
a. PA-3220
b. PA-3250
c. PA-3260
5. PA-3400 Series
a. PA-3410
b. PA-3420
c. PA-3430
d. PA-3440
6. PA-5200 Series
a. PA-5220
b. PA-5250
c. PA-5260
d. PA-52801
7. PA-5400 Series
a. PA-5410
b. PA-5420
c. PA-5430
8. PA-54502
9. PA-7000 Series3
a. PA-7050
1
PA-5280 can operate in Express or Secure mode. Secure mode just means it’s 5G-ready and requires a license
upgrade.
2
PA-5450 firewall supports the following cards: PA-5400 MPC-A, PA-5400 NC-A, and PA-5400 DPC-A.
3
Palo Alto Networks PA-7000 Series firewalls support different Network Processing Cards (NPC) and Switch
Management Cards (SMC): PAN-PA-7050-SMC-B, PAN-PA-7080-SMC-B, PAN-PA-7000-LFC-A, PAN-PA-
7000-100G-NPC-A-K2-EXP, PAN-PA-7000-100G-NPC-A-K2-SEC, and PAN-PA-7000-100G-NPC.
Page 3 of 84
b. PA-7080
10. VM-Series
a. VM-50
b. VM-100
c. VM-200
d. VM-300
e. VM-500
f. VM-700
g. VM-1000-HV
The Palo Alto VM-Series is supported on the following hypervisors:
• VMware
o VMware ESXi with vSphere 7.0
• Linux KVM
o Ubuntu: 18.04 LTS
o Ubuntu: 20.04 LTS
• Microsoft Hyper-V Server 2012 R2, Server 2016, or Server 2019 ---- The VM-Series firewall can
be deployed on a server running Microsoft Hyper-V. Hyper-V is packaged as a standalone
hypervisor, called Hyper-V Server 2019, or as an add-on/role for Windows Server 2019.
Evaluation testing included the following:
VMware ESXi 7.0:
• Dell PowerEdge R740 Processor: Intel Xeon Gold 6248 (Cascade Lake microarchitecture) with
Broadcom 57416 NIC
• Memory: 128 GB RDIMM
Microsoft Hyper-V Server 2019:
• Dell PowerEdge R740 Processor: Intel Xeon Gold 6248 (Cascade Lake microarchitecture) with
Broadcom 57416 NIC
• Memory: 128 GB RDIMM
Linux KVM 4 Ubuntu 20.04:
• Dell PowerEdge R740 Processor: Intel Xeon Gold 6248 (Cascade Lake microarchitecture) with
Broadcom 57416 NIC
• Memory: 128 GB RDIMM
Evaluation testing included the following hardware and processors:
• PA-3260: Cavium Octeon CN7360 MIPS64 (DP) / Intel Pentium D1517 (MP)
• PA-5450: Intel Xeon D-2187NT (DP/MP)
• PA-7080: Cavium Octeon CN7890 MIPS64 (DP) / Intel Core i7-2715QE (MP)
TOE Developer – Palo Alto Networks, Inc.
Evaluation Sponsor – Palo Alto Networks, Inc.
CC Identification – Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5,
April 2017
Page 4 of 84
1.2 Conformance Claims
This ST and the TOE it describes are conformant to the following CC specifications:
PP-Configuration for Network Devices, Stateful Traffic Filter Firewalls, and Virtual Private Network (VPN)
Gateways, Version 1.2, March 31, 2022 [CFG_NDcPP-FW-VPNGW_V1.2] consisting of the following
components:
• collaborative Protection Profile for Network Devices, Version 2.2e, 23 March 2020 [NDcPP]
• PP-Module for Stateful Traffic Filter Firewalls, Version 1.4 + Errata 20200625, 25 June 2020 [FW-
Module]
• PP-Module for Virtual Private Network (VPN) Gateways, Version 1.2, 31 March 2022 [VPNGW-
Module]
The following NIAP Technical Decisions4
apply to this [NDcPP] and have been accounted for in the ST
development and the conduct of the evaluation:
• TD0527 – Updates to Certificate Revocation Testing (FIA_X509_EXT.1)
o This TD is applicable to the TOE but relates solely to evaluation activities so it does not affect the
ST.
• TD0528 – NIT Technical Decision for Missing EAs for FCS_NTP_EXT.1.4
o This TD is not applicable to the TOE because FCS_NTP_EXT.1 is not claimed.
• TD0536 – NIT Technical Decision for Update Verification Inconsistency
o This TD is applicable to the TOE but relates solely to evaluation activities so it does not affect the
ST.
• TD0537 – NIT Technical Decision for Incorrect reference to FCS_TLSC_EXT.2.3
o This TD is applicable to the TOE but relates solely to evaluation activities so it does not affect the
ST.
• TD0538 – NIT Technical Decision for Outdated link to allowed-with list
o This TD is applicable to the TOE, but it is a semantic issue with the claimed PP that was corrected.
It does not affect the ST or the evaluation of the TOE.
• TD0546 – NIT Technical Decision for DTLS - clarification of Application Note 63
o This TD is not applicable to the TOE; it relates to FCS_DTLSC_EXT.1, which is not claimed by the
ST.
• TD0547 – NIT Technical Decision for Clarification on developer disclosure of AVA_VAN
o This TD is applicable to the TOE.
• TD0555 – NIT Technical Decision for RFC Reference incorrect in TLSS Test
o This TD is applicable to the TOE but relates entirely to test evaluation activities so it does not
affect the ST.
• TD0556 – NIT Technical Decision for RFC 5077 question
o This TD is applicable to the TOE but relates entirely to test evaluation activities so it does not
affect the ST.
• TD0563 – NIT Technical Decision for Clarification of audit date information
o This TD is applicable to the TOE but relates entirely to an application note that clarifies the intent
of FAU_GEN.1.2. It does not affect the ST.
• TD0564 – NIT Technical Decision for Vulnerability Analysis Search Criteria
4
The following TDs are not applicable: 453, 451, 447, and 411.
Page 5 of 84
o This requirement is applicable to the TOE but relates entirely to the evaluation of AVA_VAN.1. It
does not affect the ST because the additional ST evidence required to address this TD is already
addressed by TD0547.
• TD0569 – NIT Technical Decision for Session ID Usage Conflict in FCS_DTLSS_EXT.1.7
o This TD is applicable to the TOE but relates entirely to test evaluation activities so it does not
affect the ST. Note specifically that while the title of the TD references FCS_DTLSS_EXT.1, which
the ST does not claim, the TD also affects FCS_TLSS_EXT.1, which is within the TOE’s logical
boundary.
• TD0570 – NIT Technical Decision for Clarification about FIA_AFL.1
o This TD is applicable to the TOE but relates entirely to clarifying how the PP reader should
interpret FIA_AFL.1. It does not affect the ST.
• TD0571 – NIT Technical Decision for Guidance on how to handle FIA_AFL.1
o This TD is applicable to the TOE but relates entirely to clarifying how the PP reader should
interpret the requirements that relate to FIA_AFL.1. It does not affect the ST.
• TD0572 – NIT Technical Decision for Restricting FTP_ITC.1 to only IP address identifiers
o This TD is applicable to the TOE but relates entirely to guidance on the interpretation of
mandatory and allowable reference identifiers for cases where the TSF must validate the identifier
of a presented X.509 certificate. It does not affect the ST.
• TD0580 – NIT Technical Decision for clarification about use of DH14 in NDcPPv2.2e
o The TD affects a selection in FCS_CKM.2.
• TD0581 – NIT Technical Decision for Elliptic curve-based key establishment and NIST SP 800-
56Arev3
o The TD adds a selection to FCS_CKM.2 that the ST has applied.
• TD0591 – NIT Technical Decision for Virtual TOEs and hypervisors
o The TD applies to virtual network devices and affected the assumptions.
• TD0592 – NIT Technical Decision for Local Storage of Audit Records
o This TD is applicable to the TOE. The TD modifies introductory text to remove a contradictory
statement about local audit storage.
• TD0631 – NIT Technical Decision for Clarification of Public Key Authentication for SSH Server
o This TD is applicable to the TOE; the wording of FCS_SSHS_EXT.1.2 is updated and the required
selection is added to FMT_SMF.1.1,
• TD0632 – NIT Technical Decision for Consistency with Time Data for vNDs
o This TD is applicable to the TOE. It adds a selection to FPT_STM_EXT.1.2.
• TD0633 – NIT Technical Decision for IPsec IKE/SA Lifetimes Tolerance
o This TD is applicable to the TOE.
• TD0634 – NIT Technical Decision for Clarification Required for Testing IPv6
o This TD is applicable to the TOE but affects test evaluation activities only; it does not affect the
ST.
• TD0635 – NIT Technical Decision for TLS Server and Key Agreement Parameters
o This TD is applicable to the TOE but affects test evaluation activities only; it does not affect the
ST.
• TD0636 – NIT Technical Decision for Clarification of Public Key User Authentication for SSH
o This TD is not applicable to the TOE because the TOE does not claim SSH client functionality.
• TD0638 – NIT Technical Decision for Key Pair Generation for Authentication
o This TD is not applicable to the TOE but it’s not a distributed TOE.
Page 6 of 84
The following NIAP Technical Decisions apply to [FW-Module] and/or [VPNGW-Module] and have been
accounted for in the ST development and the conduct of the evaluation:
• TD0545: NIT Technical Decision for Conflicting FW rules cannot be configured (extension of
Rfl#201837)
o The TD updates test evaluation activities that apply to the TOE.
• TD0551: NIT Technical Decision for Incomplete Mappings of OEs in FW Module v1.4+Errata
o This TD is applicable to the TOE but does not affect the ST or evaluation activities. The TD updates
Security Problem Definition mappings and rationale in the [FW-Module]
• TD0656: NIT Technical Decision for Missing EAs for VPN GW Optional Headend SFRs
o This TD is not applicable to the TOE. The TOE does not claim the optional SFRs in [VPNGW-
Module]
• TD0657: NIT Technical Decision for IPSEC_EXT.1.6 GCM Support for VPN GW
o This TD is applicable to the TOE. The TD fixes typo in the CBC and GCM markings in [VPNGW-
Module].
Common Criteria for Information Technology Security Evaluation Part 2: Security functional components,
Version 3.1, Revision 5, April 2017.
• Part 2 Extended
Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components,
Version 3.1 Revision 5, April 2017.
• Part 3 Conformant.
1.3 Conventions
The following conventions have been applied in this document:
• Security Functional Requirements – Part 2 of the CC defines the approved set of operations that
may be applied to functional requirements: iteration, assignment, selection, and refinement.
• All operations performed in this ST are identified according to conventions described in [NDcPP],
[FW-Module], and [VPNGW-Module].
• The ST author does not change operations that have been completed by the PP authors nor undo
the formatting. For example, if the text is italicized, bolded, or underlined by the PP author, the ST
author will not undo it. In this way operations have been identified.
• Selection/Assignment operations completed by the PP author remain as described in the [NDcPP]
[FW-Module], and [VPNGW-Module].
• Selection/Assignment operations completed by the ST author were bolded to show that it was
completed by the ST author and not taken as-is from the PP.
• Iteration operations completed by the ST author are identified with (1), (2), and (next number) with
descriptive text following the name (e.g. FCS_HTTPS_EXT.1(1) HTTPS Protocol (TLS Server)).
• Refinement operations completed by the ST author are identified in BOLD text.
1.3.1 Terminology
The following terms and abbreviations are used in this ST:
Page 7 of 84
Authentication
Profile
Define the authentication service that validates the login credentials of administrators
when they access TOE.
Role-Based
Access Control
Define the privileges and responsibilities of administrative users (administrators). Every
administrator must have a user account that specifies a role and authentication method.
Security Policy Provides the firewall rule sets that specify whether to block or allow network
connections.
Security
Profile
A security profile specifies protection rules to apply when processing network traffic.
The profiles supported by the TOE include the IPsec crypto Security profile, IKE
Network profile, and Vulnerability profile.
Security Zone A grouping of TOE interfaces. Each TOE interface must be assigned to a zone before it
can process traffic.
Virtual System Virtual systems are separate, logical firewall instances within a single physical Palo Alto
Networks firewall. Virtual systems allow the TOE administrator to customize
administration, networking, and security policies for network traffic belonging to
specific user groupings (such as departments or customers).
1.3.2 Acronyms
AES Advanced Encryption Standard
API Application Programming Interface
CBC Cipher-Block Chaining
CC Common Criteria
CEM Common Evaluation Methodology
CM Configuration Management
CLI Command Line Interface
DH Diffie-Hellman
DMZ Demilitarized Zone
DRBG Deterministic Random Bit Generator
DP Data Plane
EEPROM Electrically Erasable Programmable Read-Only Memory
FIPS Federal Information Processing Standard
FSP Functional Specification
FTP File Transfer Protocol
GCM Galois/Counter Mode
GUI Graphical User Interface
HMAC Hashed Message Authentication Code
HTTPS Hypertext Transfer Protocol Secure
ICMP Internet Control Message Protocol
IKE Internet Key Exchange
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IPsec Internet Protocol Security
MP Management Plane
NAT Network Address Translation
NIST National Institute of Standards and Technology
PP Protection Profile
REST Representational State Transfer
RSA Rivest, Shamir and Adleman (algorithm for public-key cryptography)
Page 8 of 84
SA Security Association
SAR Security Assurance Requirement
SFR Security Functional Requirement
SHA Secure Hash Algorithm
SSH Secure Shell
SSL Secure Socket Layer
ST Security Target
TLS Transport Layer Security
TOE Target of Evaluation
TSF TOE Security Functions
UDP User Datagram Protocol
URL Uniform Resource Locator
VLAN Virtual Local Area Network
VM Virtual Machine
VPN Virtual Private Network
VPNGW Virtual Private Network Gateway
Page 9 of 84
2. Product Description
Palo Alto Networks provides a wide suite of enterprise-level next-generation firewalls, with a diverse range
of security features for the enterprise network.
The Palo Alto next-generation firewalls are network firewall appliances and virtual appliances on specified
hardware used to manage enterprise network traffic flow using function-specific processing for networking,
security, and management. The next-generation firewalls let the administrator specify security policies based
on an accurate identification of each application seeking access to the protected network. The next-
generation firewall uses packet inspection and a library of applications to distinguish between applications
that have the same protocol and port, and to identify potentially malicious applications that use non-
standard ports. The next-generation firewall also supports the establishment of Virtual Private Network
(VPN) connections to other next-generation firewalls or third-party security devices.
The products below are considered trusted IT products in the operational environment and only the secure
communication (FTP_ITC.1) between the firewalls and the products are claimed and validated in this
evaluation. The product descriptions below are provided for completeness only.
• GlobalProtect safeguards the mobile workforce by inspecting all traffic using the organization’s
next-generation firewalls that are deployed as internet gateways, whether at the perimeter, in the
DMZ, or in the cloud. Laptops, smartphones and tablets with the GlobalProtect app automatically
establish a secure TLS/IPsec VPN connection to the next-generation firewall with the best
performance for a given location, thus providing the organization with full visibility of all network
traffic, for applications, and across all ports and protocols. By eliminating the blind spots in mobile
workforce traffic, the organization maintains a consistent view into applications.
Page 10 of 84
2.1 TOE Overview
The Target of Evaluation (TOE) is comprised of one instance of the Palo Alto Networks next-generation
firewall that includes the Palo Alto Networks PA-220, PA-220R, PA-410, PA-440, PA-450, PA-460, PA-820,
PA-850, PA-3220, PA-3250, PA-3260, PA-3410, PA-3420, PA-3430, PA-3440, PA-5220, PA-5250, PA-
5260, PA-5280, PA-5410, PA-5420, PA-5430, PA-5450, PA-7050, and PA-7080 appliances and the virtual
appliances in the VM-Series VM-50, VM-100, VM-200, VM-300, VM-500, VM-700, VM-1000-HV with
PAN-OS v10.2. The next-generation firewall provides policy-based application visibility and control to
protect traffic flowing through the enterprise network.
The next-generation firewalls are network firewall appliances and virtual appliances on specified hardware
used to manage enterprise network traffic flow using function-specific processing for networking, security,
and management. The next-generation firewalls let the administrator specify security policies based on an
accurate identification of each application seeking access to the protected network. The next-generation
firewall uses packet inspection and a library of applications to distinguish between applications that have
the same protocol and port, and to identify potentially malicious applications that use non-standard ports.
The next-generation firewall also supports the establishment of Virtual Private Network connections to
other next-generation firewalls or third-party security devices.
A next-generation firewall is typically installed between an edge router or other device facing the Internet
and a switch or router connecting to the internal network. The Ethernet interfaces on the firewall can be
configured to support various networking environments, including: Layer 2 switching and VLAN
environments; Layer 3 routing environments; transparent in-line deployments; and combinations of the
three. The scope of the evaluation does not cover Layer 2 switching, VLAN, and transparent in-line
deployments.
The next-generation firewalls provide granular control over the traffic allowed to access the protected
network. They allow an administrator to define security policies for specific applications, rather than rely on
a single policy for connections to a given port number. For each identified application, the administrator can
specify a security policy to block or allow traffic based on the source and destination zones, source and
destination addresses, or application services. The next-generation firewalls also support the following types
of policy:
• Application-based policies (e.g., FTP)
• User Identification Agent (UIA) - the TOE uses user-specific information provided by UIA in the
operational environment for security policy enforcement. The UIA automatically collects user-
specific information and provides mapping information between IP addresses and network users,
and provides these information to the TOE which then uses mappings in its security policy
enforcement. The user ID can be an attribute specified in the TOE security policies upon which they
are enforced. The UIA works with both IPv4 addresses and IPv6 addresses.
Security policies can include specification of one or more security profiles, which provide additional
protection and control. Security profiles are configured and applied to firewall policy. Each security policy
can specify one or more of the following security profiles:
• Vulnerability Protection profiles
• DoS Protection profiles
• IKE Crypto Security profiles
• IPsec Crypto Security profiles
The next-generation firewall products provide the following features:
• Application-based policy enforcement — the product uses a traffic classification technology named
App-ID to classify traffic by application content irrespective of port or protocol. Protocol and port
can be used in conjunction with application identification to control what ports an application is
Page 11 of 84
allowed to run on. High risk applications can be blocked, as well as high-risk behavior such as file-
sharing or FTP.
• Threat prevention — the firewall includes threat prevention capabilities (i.e., Vulnerability Protection
profile) that can protect the network from viruses, worms, spyware, and other malicious traffic. In
the context of this evaluation, this feature is used to block malicious malformed, fragmented
packets. The protection from viruses, worm, and spyware using signatures are out of scope (i.e., not
evaluated).
• DoS Protection – the firewall is designed to protect against flooding attack within the protected
network. The DoS Protection profile also specifies the maximum connection per second (CPS) rate
and how long a blocked IP address remains on the Block IP list.
• IKE Crypto Security profiles - specify protocols and algorithms for identification, authentication, and
encryption (IKEv1 or IKEv2, Phase 1).
• IPsec Crypto Security profiles - specify protocols and algorithms for authentication and encryption
in VPN tunnels based on IPSec SA negotiation (Phase 2).
• Management — each firewall can be managed through a Graphical User Interface (GUI), API, or CLI.
The interface provides an administrator with the ability to establish policy controls, provide the
means to control what applications network users are allowed access to, and to control logging.
When configured in a FIPS-CC mode of operation, the GUI and API are secured using HTTP over
TLS (HTTPS) and CLI is secured using SSH.
Firewall Policy Enforcement
The App-ID classification technology uses four classification techniques to determine exactly what
applications are traversing the network irrespective of port number. As traffic flows through the TOE, App-
ID identifies traffic using the following classification engines.
• Application Protocol/Port: App-ID identifies the protocol (such as FTP) and the port number of the
traffic. Protocol/Port information is primarily used for policy enforcement, such as allowing or
blocking a specific application over a specific protocol or port number, but is sometimes used in
classification, such as ICMP traffic where the protocol is the primary classification method used.
• Application Protocol Decoding: App-ID’s protocol decoders determine if the application is using a
protocol as a normal application transport (such as HTTP for web browsing applications), or if it is
only using the apparent protocol to hide the real application protocol (for example, Yahoo! Instant
Messenger might hide inside HTTP).
Threat Prevention
The next-generation firewall includes a real-time threat prevention engine that inspects the traffic traversing
the network for a wide range of threats. The threat prevention engine scans for all types of threats with a
uniform signature format and can identify and block a wide range of threats across a broad set of applications
in a single pass. The threats that can be detected by the threat prevention engine include: viruses; spyware
(inbound file scanning, and connections to infected web sites); application vulnerability exploits; and
phishing/malicious URLs. In the context of this evaluation, this feature is used to block malicious malformed,
fragmented packets.
App-ID and Threat Prevention Signature Updates
App-ID and threat prevention signatures (collectively known as content updates) may be updated
periodically using the dynamic updates feature of the firewall. The TOE can be configured to contact Palo
Alto Networks’ updates.paloaltonetworks.com to download new content updates as they are made
available. The connection to the updates.paloaltonetworks.com is secured with TLS using FIPS-approved
algorithms. The threat prevention signatures themselves are out of scope (i.e., not evaluated).
Page 12 of 84
Management
The next-generation firewall provides both direct and remote connections for the Web/CLI/API
Management interface. The Web, API, and command interfaces provide administrators with the ability to
manage, configure and monitor the TOE.
Common Criteria Mode of Operation
The TOE is compliant with the capabilities outlined in this Security Target only when operated in Common
Criteria mode (now referred to as FIPS-CC mode). FIPS-CC mode is a special operational mode in which the
FIPS and CC requirements for self-tests as well as X.509 certificates checks are enforced. In this mode, only
CC Approved cryptographic algorithms and key sizes are available.
2.2 TOE Architecture
The firewalls’ architecture is divided into two subsystems: the control plane and the data plane. The control
plane provides system management functionality while the data plane handles all data processing on the
network; both reside on the firewall appliance. The TOE relies on the User Identification Agent installed on
a separate dedicated PC in the operational environment to retrieve user-specific information that is uses for
policy enforcement.
The following diagram depicts both the TOE and the User Identification Agent:
Figure 1: TOE Architecture
The control plane includes a multi-core CPU, with dedicated memory and a hard drive for local log,
configuration, and software storage. The data plane includes three components—the network processor, the
security processor, and the stream signature processor—each with its own dedicated memory and hardware
processing.
Page 13 of 84
In summary, the functionality provided by each component of the system is as follows:
Control Plane (also known as Management Plane)
The control plane provides all device management functionality, including:
o All management interfaces – provide a both direct and remote connection for the Web Interface
GUI/API and CLI on SSH.
o Configuration management of the device, such as controlling the changes made to the device
configuration, as well as the compilation and pushing to the Data Plane of a configuration change.
o Logging infrastructure for traffic, threat, alarm, configuration, and system logs.
o Administration controls, including administrator authentication and audit trail information for
administrators logging in, logging out, and configuration changes.
o Interactions with the UIA to retrieve the user to IP address mapping information that is used for
policy enforcement (via the Data Plane).
Data Plane (DP)
The data plane provides all data processing and security detection and enforcement, including:
o All networking connectivity, packet forwarding, switching, routing, and network address translation
o Application identification, using the content of the applications, not just port or protocol
o Application decoding, threat scanning for all types of threats and threat prevention
o Policy lookups to determine what security policy to enforce and what actions to take, including
logging
o Denial of Service (DoS) protection including TCP Sync flooding attack
o Logging, with all logs sent to the control plane for processing and storage
Site-to-site IPsec VPN supports IPv4 or IPv6 site-to-site connections. That is, you can establish IKE and
IPsec Security Associations (SAs) between IPv4 or IPv6 endpoints. The web interface can be used to enable,
disable, restart, or refresh an IKE gateway or an IPsec VPN tunnel to simplify troubleshooting.
VM-Series
The VM-Series on specified hardware supports the exact same next-generation firewall and advanced threat
prevention features that are available in the physical form factor appliances, allowing an administrator to
safely enable applications flowing into, and across private, public and hybrid cloud computing environments.
Each VM-Series virtual appliance in its evaluated configuration is installed on a hardware platform as
specified in Section 1.1 that includes a VMware, Linux KVM, or Microsoft Hyper-V hypervisor and an Intel
Core or Xeon processor based on the Skylake, Cascade Lake, Ivy Bridge, Haswell, or Broadwell
microarchitectures that implement Intel Secure Key, and Network Interface Controllers supported by the
Server.
2.2.1 Physical Boundaries
The TOE consists of the following components:
• Hardware appliance-includes the physical port connections on the outside of the appliance cabinet
and a time clock that provides the time stamp used for the audit records.
• Virtualized Firewalls installed on specified hardware - the VM-Series supports the exact same next-
generation firewall and advanced threat prevention features available in the physical form factor
appliances, allowing an administrator to safely enable applications flowing into, and across your
private, public and hybrid cloud computing environments. The VM software and the appliances are
Page 14 of 84
both included in the TOE. The time clock, as well as CPU, ports, etc., are provided by VM
environment (hypervisor) hosting the PAN-OS VMs. VMs are deployed in the system using Intel
CPUs.
• PAN-OS v10.2 – the software/firmware component that runs the appliance. For VMs PAN-OS is
software and for hardware appliances PAN-OS is firmware. PAN-OS is built on top of a Linux kernel
and runs along with NGINX (the web server that Palo Alto Networks uses), crond, syslogd, and
various vendor-developed applications that implement PAN-OS capabilities. PAN-OS provides the
logical interfaces for network traffic. PAN-OS runs on both the Control Plane and the Data Plane
and provides all firewall functionalities provided by the TOE, including the threat prevention
capabilities as well as the identification and authentication of users and the management functions.
PAN-OS provides unique functionality on the two planes based on the applications that are
executing. The Control Plane provides a GUI Web management interface to access and manage the
TOE functions and data. The Data Plane provides the external interface between the TOE and the
external network to monitor network traffic so that the TSF can enforce the TSF security policy.
The physical boundary of the TOE comprises the firewall appliance (PA-220, PA-220R, PA-410, PA-440,
PA-450, PA-460, PA-820, PA-850, PA-3220, PA-3250, PA-3260, PA-3410, PA-3420, PA-3430, PA-3440,
PA-5220, PA-5250, PA-5260, PA-5280, PA-5410, PA-5420, PA-5430, PA-5450, PA-7050, and PA-7080);
and the virtual appliances on specified hardware in the VM-Series VM-50, VM-100, VM-200, VM-300, VM-
500, VM-700, VM-1000-HV. The next-generation firewall models differ in their performance capability,
but they provide the same security functionality.
Virtual systems are supported by default (without an additional license) on the PA-3220, PA-3250, PA-3260,
PA-3410, PA-3420, PA-3430, PA-3440, PA-5220, PA-5250, PA-5260, PA-5280, PA-5410, PA-5420, PA-
5430, PA-5450, PA-7050, and PA-7080. The PA-220 and PA-800 cannot support virtual systems. Virtual
systems specify a collection of physical and logical firewall interfaces that should be isolated. Each virtual
system contains its own security policy and its own set of logs that will be kept separate from all other virtual
systems.
The firewall appliance attaches to a physical network and includes the following ports and processors:
• PA-220: 8 RJ-45 10/100/1000 ports for network traffic (Ethernet ports); 1 RJ-45 port to access the
device GUI through an Ethernet interface (management ports); and 1 RJ-45 port for connecting a
serial console (management console port); 1 USB (disabled in FIPS-CC mode except for power), 1
Micro USB Console (self-test output only in FIPS-CC mode), and DC Power input. Processor: Cavium
Octeon CN7130 MIPS64 (DP/MP)
• PA-220R: 6 RJ-45 10/100/1000 ports for network traffic (Ethernet ports); 1 RJ-45 port to access
the device GUI through an Ethernet interface (management ports); and 1 RJ-45 port for connecting
a serial console (management console port), 1 USB (disabled in FIPS-CC mode except for power), 1
Micro USB Console (self-test output only in FIPS-CC mode), and DC Power input. Processor: Cavium
Octeon CN7130 MIPS64 (DP/MP)
• PA-410: 7 RJ-45 10/100/100 ports for network traffic (Ethernet ports); 1 RJ-45 port to access the
device GUI through an Ethernet interface (management ports); and 1 RJ-45 port for connecting a
serial console (management console port); 2 USB (disabled in FIPS-CC mode except for power) and
Power input. Processor: Intel Atom C3634L (DP/MP)
• PA-440/PA-450/PA-460: 8 RJ-45 10/100/100 ports for network traffic (Ethernet ports); 1 RJ-45
port to access the device GUI through an Ethernet interface (management ports); and 1 RJ-45 port
for connecting a serial console (management console port); 2 USB (disabled in FIPS-CC mode except
for power), 1 Micro USB Console (self-test output only in FIPS-CC mode), and Power input.
Processor: Intel Atom C3558R (DP/MP) for 440 and Intel Atom C3758R (DP/MP) for 450 and 460.
• PA-820: 4 RJ-45 10/100/1000 ports for network traffic (Ethernet ports); 8 Small Form-Factor
Pluggable (SFP) Gbps ports for network traffic; 1 RJ-45 port to access the device GUI through an
Ethernet interface (management ports); and 1 RJ-45 port for connecting a serial console
Page 15 of 84
(management console port); 1 USB (disabled in FIPS-CC mode except for power), 1 Micro USB
Console (self-test output only in FIPS-CC mode), and 100-240V Power input. Processor: Cavium
Octeon CN7240 MIPS64 (DP/MP)
• PA-850: 4 RJ-45 10/100/1000 ports for network traffic (Ethernet ports); 4/8 SFP; 0/4 SFP+
connectors for network traffic; 1 RJ-45 port to access the device GUI through an Ethernet interface
(management ports); and 1 RJ-45 port for connecting a serial console (management console port);
1 USB (disabled in FIPS-CC mode except for power), 1 Micro USB Console (self-test output only in
FIPS-CC mode), and 100-240V Power input. Processor: Cavium Octeon CN7240 MIPS64 (DP/MP)
• PA-3220/PA-3250: 12 RJ-45 10/100/1000 ports for network traffic. 8 Small Form-Factor
Pluggable (SFP) ports for network traffic. 1 RJ-45 port to access the device management interfaces
through an Ethernet interface. 1 RJ-45 port for connecting a serial console. 2 RJ-45 ports for high-
availability (HA) control and synchronization, 1 USB (disabled in FIPS-CC mode except for power),
1 Micro USB Console (self-test output only in FIPS-CC mode), and 2 Power inputs. Processor:
Cavium Octeon CN7350 MIPS64 (DP) / Intel Pentium D1517 (MP)
• PA-3260: 12 RJ-45 10/100/1000 ports for network traffic. 8 Small Form-Factor Pluggable (SFP)
ports for network traffic. 1 RJ-45 port to access the device management interfaces through an
Ethernet interface. 1 RJ-45 port for connecting a serial console. 2 RJ-45 ports for high-availability
(HA) control and synchronization , 1 USB (disabled in FIPS-CC mode except for power), 1 Micro USB
Console (self-test output only in FIPS-CC mode), and 2 Power inputs. Processor: Cavium Octeon
CN7360 MIPS64 (DP) / Intel Pentium D1517 (MP)
• PA-3410/PA-3420: 12 RJ-45 10/100/1000 ports for network traffic. 10 Small Form-Factor
Pluggable (SFP) ports for network traffic. 1 RJ-45 port to access the device management interfaces
through an Ethernet interface. 1 RJ-45 port for connecting a serial console. 4 RJ-45 ports for high-
availability (HA) control and synchronization, 1 USB (disabled in FIPS-CC mode except for power),
1 Micro USB Console (self-test output only in FIPS-CC mode), and 2 Power inputs. Processor: Intel
Atom 5332 (PA-3410) and Intel Atom 5342 (PA-3420)
• PA-3430/PA-3440: 12 RJ-45 10/100/1000 ports for network traffic. 10 Small Form-Factor
Pluggable (SFP) ports for network traffic, and 2 zQSFP+ ports. 1 RJ-45 port to access the device
management interfaces through an Ethernet interface. 1 RJ-45 port for connecting a serial console.
4 RJ-45 ports for high-availability (HA) control and synchronization, 1 USB (disabled in FIPS-CC
mode except for power), 1 Micro USB Console (self-test output only in FIPS-CC mode), and 2 Power
inputs. Processor: Intel Atom 5352 (PA-3430) and Intel Atom 5362 (PA-3440)
• PA-5220: 4 100/1000/10G Cu, 16 1G/10G SFP/SFP+, 4 40G QSFP+ for network traffic; 2 RJ-45
port to access the device management interfaces through an Ethernet interface; 1 RJ-45 port for
connecting a serial console, 1 40G QSFP+ HA for high-availability (HA) control and synchronization,
1 USB (disabled in FIPS-CC mode except for power), and 2 100-240V Power inputs. Processor:
Cavium Octeon CN7885 MIPS64 (DP) / Intel Xeon D1548 (MP)
• PA-5250: 4 100/1000/10G Cu, 16 1G/10G SFP/SFP+, 4 40G/100G QSFP28 for network traffic; 2
RJ-45 port to access the device management interfaces through an Ethernet interface; 1 RJ-45 port
for connecting a serial console, 1 40G/100G QSFP28 for high-availability (HA) control and
synchronization, 1 USB (disabled in FIPS-CC mode except for power), and 2 100-240V Power
inputs. Processor: Cavium Octeon CN7890 MIPS64 (DP) / Intel Xeon D1567 (MP)
• PA-5260/PA-5280: 4 100/1000/10G Cu, 16 1G/10G SFP/SFP+, 4 40G/100G QSFP28 for network
traffic; 2 RJ-45 port to access the device management interfaces through an Ethernet interface; 1
RJ-45 port for connecting a serial console, 1 40G/100G QSFP28 for high-availability (HA) control
and synchronization, 1 USB (disabled in FIPS-CC mode except for power), and 2 100-240V Power
inputs. Processor: Cavium Octeon CN7890 MIPS64 (DP) / Intel Xeon D1567 (MP)
• PA-5410/PA-5420/PA-5430: 8 100/1000/10G Cu, 12 1G/10G SFP/SFP+, 4 40G/100G QSFP28
for network traffic; 2 RJ-45 port to access the device management interfaces through an Ethernet
Page 16 of 84
interface; 1 RJ-45 port for connecting a serial console, 2 40G/100G QSFP28 for high-availability
(HA) control and synchronization, 1 USB (disabled in FIPS-CC mode except for power), and 2 100-
240V Power inputs. Processor: AMD EPYC 7352 (PA-5410), AMD EPYC 7452 (PA-5420), and AMD
EPYC 7642 (PA-5430)
• PA-5450: For network connectivity, the PA-5450 requires at least one NC (PA-5400-NC-A). Each
PA-5400-NC-A offers multiple connectivity ports as listed: 100/1000/10G Cu (4), 1G/10G
SFP/SFP+ (12), and 40G/100G QSFP28 (2), and 2 Power inputs. For packet and security processing,
the PA-5450 uses DPCs (PA-5400-DPC-A). The MPC (PAN-PA-5400-MPC-A) acts as a dedicated
point of contact for controlling all aspects of the PA-5450 and has 2 HA ports, 1 RJ-45 Console
port, 2 Management ports, 1 USB (disabled in FIPS-CC mode except for power) and 1 Micro USB
Console (self-test output only in FIPS-CC mode). Processor: Intel Xeon D-2187NT (DP/MP)
• PA-7050: 12 gig copper ports for network traffic, 8 Small Form-Factor Pluggable (SFP) ports for
network traffic and 4 SFP+ ports for network traffic per blade OR 2 Quad Small Form-Factor
Pluggable (QSFP) for network traffic per blade and 12 SFP+ ports for network traffic per blade (6
blades max). 1 RJ-45 port to access the device management interfaces through an Ethernet
interface. 1 RJ-45 port for connecting a serial console. 2 QSFP ports for high-availability (HA) control
and synchronization, 1 USB (disabled in FIPS-CC mode except for power), and 4 100-240V Power
inputs. Processor: Cavium Octeon CN7890 MIPS64 (DP) / Intel Core i7-2715QE (MP)
• PA-7080: 12 gig copper ports for network traffic, 8 Small Form-Factor Pluggable (SFP) ports for
network traffic and 4 SFP+ ports for network traffic per blade OR 2 Quad Small Form-Factor
Pluggable (QSFP) for network traffic per blade and 12 SFP+ ports for network traffic per blade (10
blades max). 1 RJ-45 port to access the device management interfaces through an Ethernet
interface. 1 RJ-45 port for connecting a serial console. 2 QSFP ports for high-availability (HA) control
and synchronization, 1 USB (disabled in FIPS-CC mode except for power), and 8 100-240V Power
inputs. Processor: Cavium Octeon CN7890 MIPS64 (DP) / Intel Core i7-2715QE (MP)
In the evaluated configuration, the TOE can be managed by:
• A computer either directly connected or remotely connected to the Management port via an RJ-45
Ethernet cable. The Management port is an out-of-band management port that provides access to
the GUI/API via HTTPS or CLI via SSH. The computer is part of the operational environment and
required to have a web browser (for accessing the GUI) and SSH client (for accessing the CLI).
Traffic logs, which record information about each traffic flow or problems with the network traffic, are
logged locally by default. However, the product offers the capability to send the logs as SNMP traps, Syslog
messages, or email notifications. Traffic logging and the use of email notifications and the SNMP and SMTP
servers have not been subject to testing in the evaluated configuration.
The operational environment includes the following:
• Syslog server
• VPN gateway peer(s)
• Palo Alto Networks GlobalProtect application
• Workstation
o Web browsers - Chrome (version 96 or later), Firefox (version 94.0.2 or later), Safari
(version 12.0.3 or later on Mac, and version 5.1.7 or later on Windows and iOS), and
Microsoft Edge (Release 42 or later) browser.
o SSHv2 client
The operational environment includes a domain controller and the User Identification Agent is installed on
one or more PCs in the operational environment, and is supported on Windows Server 2012, Windows
Server 2012 R2, Windows Server 2016, and Windows Server 2019.
Page 17 of 84
Table 1 TOE Platforms
Product
Identification
Illustration Description
PA-220 • 500 Mbps firewall throughput
(App-ID enabled
• 150 Mbps threat prevention
throughput
• 100 Mbps IPsec VPN throughput
• 64,000 max sessions
• 4,200 new sessions per second
• 250 IPsec VPN tunnels/tunnel
interfaces
• 15 security zones
• 250 max number of policies
PA-220R • 500/560 Mbps firewall
throughput (App-ID enabled
• 150/260 Mbps threat prevention
throughput
• 100 Mbps IPsec VPN throughput
• 64,000 max sessions
• 4,200 new sessions per second
• 250 IPsec VPN tunnels/tunnel
interfaces
• 15 security zones
• 250 max number of policies
PA-410 • 1.7/1.3 Gbps Firewall
throughput (HTTP/appmix)
• 0.6/0.7 Gbps Threat Prevention
throughput (HTTP/appmix)
• 0.93 Gbps IPsec VPN
throughput
• 64,000 max sessions
• 13,000 New sessions per second
PA-440 • 3.0/2.4 Gbps Firewall
throughput (HTTP/appmix)
• 0.9/1.0 Gbps Threat Prevention
throughput (HTTP/appmix)
• 1.6 Gbps IPsec VPN throughput
• 200,000 max sessions
• 39,000 New sessions per second
PA-450 • 3.8/3.2 Gbps Firewall
throughput (HTTP/appmix)
• 1.6/1.7 Gbps Threat Prevention
throughput (HTTP/appmix)
• 2.2 Gbps IPsec VPN throughput
• 300,000 max sessions
• 52,000 New sessions per second
Page 18 of 84
Product
Identification
Illustration Description
PA-460 • 5.2/4.7 Gbps Firewall
throughput (HTTP/appmix)
• 2.4/2.6 Gbps Threat Prevention
throughput (HTTP/appmix)
• 3.1 Gbps IPsec VPN throughput
• 400,000 max sessions
• 74,000 New sessions per second
PA-820 • 1.9 Gbps firewall throughput
(App-ID enabled)
• 780 Mbps threat prevention
throughput
• 500 Mbps IPsec VPN throughput
• 192,000 max sessions
• 9,500 new sessions per second
• 1000 IPsec VPN tunnels/tunnel
interfaces
• 5 virtual routers
• 40 security zones
• 1,500 max number of policies
PA-850 • 1.9 Gbps firewall throughput
(App-ID enabled)
• 780 Mbps threat prevention
throughput
• 500 Mbps IPsec VPN throughput
• 192,000 max sessions
• 9,500 new sessions per second
• 1000 IPsec VPN tunnels/tunnel
interfaces
• 5 virtual routers
• 40 security zones
• 1,500 max number of policies
PA-3220 • 4.6/4.6 Gbps firewall
throughput (App-ID enabled)
• 2.2/2.6 Gbps Threat Prevention
throughput
• 2.5 Gbps IPsec VPN throughput
• 1,000,000 max sessions
• 57,000 new sessions per second
• 4,000 IPsec VPN tunnels/tunnel
interfaces
• 1,024 SSL VPN Users
• 10 virtual routers
• 1/6 virtual systems (base/max)
• 200 security zones
• 2,500 max number of policies
PA-3250 • 6/7 Gbps firewall throughput
(App-ID enabled)
Page 19 of 84
Product
Identification
Illustration Description
• 2.6/3.1 Gbps Threat Prevention
throughput
• 3.2 Gbps IPsec VPN throughput
• 2,000,000 max sessions
• 84,000 new sessions per second
• 6,000 IPsec VPN tunnels/tunnel
interfaces
• 2,048 SSL VPN Users
• 10 virtual routers
• 1/6 virtual systems (base/max)
• 200 security zones
• 5,000 max number of policies
PA-3260 • 8.4/10 Gbps firewall throughput
(App-ID enabled)
• 3.9/4.7 Gbps Threat Prevention
throughput
• 4.8 Gbps IPsec VPN throughput
• 3,000,000 max sessions
• 118,000 new sessions per
second
• 6,000 IPsec VPN tunnels/tunnel
interfaces
• 2,048 SSL VPN Users
• 10 virtual routers
• 1/6 virtual systems (base/max)
• 200 security zones
• 5,000 max number of policies
PA-3410 • 14.5/11.6 Gbps Firewall
throughput (HTTP/appmix)
• 5.2/5.9 Gbps Threat Prevention
throughput (HTTP/appmix)
• 6.8 Gbps IPsec VPN throughput
• 1.4 M max sessions
• 145,000 new sessions per
second
• 1/11 virtual systems (base/max)
PA-3420 • 20.8/16.9 Gbps Firewall
throughput (HTTP/appmix)
• 7.6/8.7 Gbps Threat Prevention
throughput (HTTP/appmix)
• 9.9 Gbps IPsec VPN throughput
• 2 M max sessions
• 205,000 new sessions per
second
• 1/11 virtual systems (base/max)
Page 20 of 84
Product
Identification
Illustration Description
PA-3430 • 25.5/20.5 Gbps Firewall
throughput (HTTP/appmix)
• 9.2/10.5 Gbps Threat
Prevention throughput
(HTTP/appmix)
• 12.2 Gbps IPsec VPN
throughput
• 2.5 M max sessions
• 240,000 new sessions per
second
• 1/11 virtual systems (base/max)
PA-3440 • 30.2/24 Gbps Firewall
throughput (HTTP/appmix)
• 11/12.8 Gbps Threat Prevention
throughput (HTTP/appmix)
• 14.5 Gbps IPsec VPN
throughput
• 3 M max sessions
• 268,000 new sessions per
second
• 1/11 virtual systems (base/max)
PA-5220 • 17/20 Gbps firewall throughput
(HTTP/appmix)
• 8/9 Gbps Threat Prevention
throughput (HTTP/appmix)
• 8 Gbps IPsec VPN throughput
• 4,000,000 max sessions
• 150,000 New sessions per
second
• 20 virtual routers
• 10/20 Virtual systems
(base/max)
PA-5250 • 39/40 Gbps firewall throughput
(HTTP/appmix)
• 18/23 Gbps Threat Prevention
throughput (HTTP/appmix)
• 16 Gbps IPsec VPN throughput
• 8,000,000 max sessions
• 284,000 New sessions per
second
• 125 virtual routers
• 25/125 Virtual systems
(base/max)
PA-5260 • 60/67 Gbps Firewall throughput
(HTTP/appmix)
Page 21 of 84
Product
Identification
Illustration Description
• 28/33 Gbps Threat Prevention
throughput (HTTP/appmix)
• 24 Gbps IPsec VPN throughput
• 32,000,000 max sessions
• 390,000 New sessions per
second
• 225 virtual routers
• 25/225 Virtual systems
(base/max)
PA-5280 • 60/67 Gbps Firewall throughput
(HTTP/appmix)
• 28/33 Gbps Threat Prevention
throughput (HTTP/appmix)
• 24 Gbps IPsec VPN throughput
• 64,000,000 max sessions
• 390,000 New sessions per
second
• 225 virtual routers
• 25/225 Virtual systems
(base/max)
PA-5410 • 45.2/36.7 Gbps Firewall
throughput (HTTP/appmix)
• 22/23.5 Gbps Threat Prevention
throughput (HTTP/appmix)
• 21 Gbps IPsec VPN throughput
• 4.1 M max sessions
• 246,000 new sessions per
second
• 10/20 virtual systems
(base/max)
PA-5420 • 53.7/47.5 Gbps Firewall
throughput (HTTP/appmix)
• 28.8/30.5 Gbps Threat
Prevention throughput
(HTTP/appmix)
• 28.7 Gbps IPsec VPN
throughput
• 6.2 M max sessions
• 315,000 new sessions per
second
• 15/65 virtual systems
(base/max)
Page 22 of 84
Product
Identification
Illustration Description
PA-5430 • 63/59.4 Gbps Firewall
throughput (HTTP/appmix)
• 37.6/40.9 Gbps Threat
Prevention throughput
(HTTP/appmix)
• 42 Gbps IPsec VPN throughput
• 8.3 M max sessions
• 366,000 new sessions per
second
• 25/125 virtual systems
(base/max)
PA-5450 • 200/200 Gbps Firewall
throughput (HTTP/appmix)
• 120/148 Gbps Threat
Prevention throughput
(HTTP/appmix)
• 79 Gbps IPsec VPN throughput
• 100,000,000 max sessions
• 3.5M New sessions per second
• 25/225 Virtual systems
(base/max)
PA-7050 • 380/430 Gbps firewall
throughput
• 366 Gbps Threat Prevention
throughput (DSRI enabled)
• 176/210 Gbps Threat
Prevention throughput
• 144 Gbps IPsec VPN
throughput
• 192 M max sessions
• 2.9 M new sessions per second
• 25/225 virtual systems
(base/max)
PA-7080 • 630/720 Gbps firewall
throughput
• 610 Gbps Threat Prevention
throughput (DSRI enabled)
• 294/350 Gbps Threat
Prevention throughput
• 240 Gbps IPsec VPN
throughput
• 320 M max sessions
• 4.8 M new sessions per second
• 25/225 virtual systems
(base/max)
Virtual Appliances
Page 23 of 84
Product
Identification
Illustration Description
VM-50 • 50,000 max sessions
• 250 security rules
• 1,000 dynamic IP addresses
• 15 Security zones
• 250 IPsec VPN tunnels
• 250 TLS VPN tunnels
VM-100 • 250,000 max sessions
• 1,500 security rules
• 2,500 dynamic IP addresses
• 40 Security zones
• 1,000 IPsec VPN tunnels
• 500 TLS VPN tunnels
VM-200 • 250,000 max sessions
• 1,500 security rules
• 2,500 dynamic IP addresses
• 40 Security zones
• 1,000 IPsec VPN tunnels
• 500 TLS VPN tunnels
VM-300 • 800,000 max sessions
• 10,000 security rules
• 100,000 dynamic IP addresses
• 40 Security zones
• 2,000 IPsec VPN tunnels
• 2,000 TLS VPN tunnels
VM-500 • 2,000,000 max sessions
• 10,000 security rules
• 100,000 dynamic IP addresses
• 200 Security zones
• 4,000 IPsec VPN tunnels
• 6,000 TLS VPN tunnels
VM-700 • 10, 000,000 max sessions
• 20,000 security rules
• 100000 dynamic IP addresses
• 200 Security zones
• 8,000 IPsec VPN tunnels
• 12,000 TLS VPN tunnels
VM-1000-HV • 800,000 max sessions
• 10,000 security rules
• 100,000 dynamic IP addresses
• 40 Security zones
• 2,000 IPsec VPN tunnels
• 2,000 TLS VPN tunnels
Page 24 of 84
2.2.2 Logical Boundaries
This section summarizes the security functions provided by the TOE:
• Security Audit
• Cryptographic Support
• User Data Protection
• Identification and Authentication
• Security Management
• Protection of the TSF
• TOE Access
• Trusted Path/Channels
• Stateful Traffic Filtering
• Packet Filtering
2.2.2.1 Security Audit
The TOE is designed to be able to generate logs with the required content (e.g., date/time, username, event
type, etc.) for a wide range of security relevant events including the events specified in [NDcPP], [FW-
Module], and [VPNGW-Module]. The TOE can be configured to store the logs locally and be configured to
send the logs securely to a designated external log server.
2.2.2.2 Cryptographic Support
The TOE implements NIST-validated cryptographic algorithms that provide key management, random bit
generation, encryption/decryption, digital signature and cryptographic hashing and keyed-hash message
authentication features in support of higher-level cryptographic protocols, including IPsec, SSH, HTTPS, and
TLS. Note that to be in the evaluated configuration, the TOE must be configured in FIPS-CC mode, which
ensures the TOE’s configuration is consistent with the FIPS standard.
2.2.2.3 User Data Protection
The TOE is designed to ensure that it does not inadvertently reuse data found in network traffic.
2.2.2.4 Identification and Authentication
The TOE requires all users accessing the TOE user interfaces to be successfully identified and authenticated
before they can access any security management functions available in the TOE. The TOE offers network
accessible (HTTPS, SSH, IPsec) and direct connections to the GUI and SSH for interactive administrator
sessions and HTTPS for XML and REST API.
The TOE supports the local (i.e., on device) definition and authentication of administrators with username,
password or public-key, and role (set of privileges), which it uses to authenticate the user and to associate
that user with an authorized role. In addition, the TOE can authenticate users using X.509v3 certificates and
can be configured to lock a user out after a configurable number of unsuccessful authentication attempts.
2.2.2.5 Security Management
The TOE provides a GUI, CLI, or API (XML and REST) to access the security management functions. Security
management commands are limited to administrators and are available only after they have provided
acceptable user identification and authentication data to the TOE. The TOE provides access to the
GUI/API/CLI locally via direct RJ-45 Ethernet cable connection and remotely using an HTTPS/TLS, IPsec, or
SSHv2 client.
The TOE provides a number of management functions and restricts them to users with the appropriate
privileges. The management functions include the capability to configure the login banner, configure the
idle timeout, configure IKE/IPsec VPN gateways, and other management functions. The TOE provides pre-
defined Security Administrator, Audit Administrator, and Cryptographic Administrator roles. These
Page 25 of 84
administrator roles are all considered Security Administrator as defined in the [NDcPP] for the purposes of
this ST.
2.2.2.6 Protection of the TSF
The TOE implements a number of features designed to protect itself to ensure the reliability and integrity
of its security features.
It protects particularly sensitive data such as stored passwords and cryptographic keys so that they are not
accessible even by an administrator. It also provides its own timing mechanism to ensure that reliable time
information is available (e.g., for log accountability).
The TOE includes functions to perform self-tests so that it can detect when it is failing and transition to a
secure, maintenance state. It also includes a mechanism to verify TOE updates to prevent malicious or other
unexpected changes in the TOE.
2.2.2.7 TOE Access
The TOE can be configured to display an administrator-defined advisory banner before establishing an
administrative user session and to terminate both local and remote interactive sessions after a configurable
period of inactivity. It also provides users the capability to terminate their own interactive sessions.
2.2.2.8 Trusted Path/Channels
The TOE protects interactive communication with remote administrators using SSH, HTTP over TLS
(HTTPS), or IPsec. SSH, TLS, and IPsec ensure both integrity and disclosure protection. Note: HTTPS traffic
can be tunneled through IPsec secure channel.
The TOE protects communication with external log server with IPsec or TLS; and remote VPN
gateways/peers using IPsec to prevent unintended disclosure or modification of the transferred data.
2.2.2.9 Stateful Traffic Filtering
The TOE provides a stateful traffic filter firewall for layers 3 and 4 (IP and TCP/UDP) network traffic
optimized through the use of stateful packet inspection.
An administrator can configure the TOE to control the type of information that is allowed to pass through
the TOE. The administrator defines the security zone and applies security policies to network traffic
attempting to traverse the TOE to determine what actions to take.
The TOE groups interfaces into security zones. Each zone identifies one or more interfaces on the TOE.
Separate zones must be created for each type of interface (Layer 2, Layer 3, or virtual wire), and each
interface must be assigned to a zone before it can process traffic. Security policies provide the firewall rule
sets that specify whether to block or allow network connections, based on the source and destination zones,
and addresses, and the application service (such as UDP port 67 or TCP port 80). Security policy rules are
processed in sequence, applying the first rule that matches the incoming traffic.
2.2.2.10 Packet Filtering
The TOE 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. An administrator can configure
security policies that determine whether to block, allow, or log a session based on traffic attributes such as
the source and destination security zone, the source and destination IP address, the application, user, and
the service.
2.3 TOE Documentation
Palo Alto Networks Inc. offers a series of documents that describe the installation of Palo Alto Networks
NGFW as well as guidance for subsequent use and administration of the applicable security features.
Page 26 of 84
For PAN-OS v10.2, these documents include:
• Palo Alto Networks Common Criteria Evaluated Configuration Guide (CCECG) for PAN-OS 10.2
• PAN-OS® Administrator’s Guide Version 10.2, Last Revised October 25, 2022
• VM-Series Deployment Guide Version 10.2, Last Revised November 11, 2022
• PAN-OS CLI Quick Start Version 10.2, Last Revised February 25, 2022
• PAN-OS Web Interface Help Version 10.2, Last Revised October 23, 2022
• PAN-OS and Panorama API Usage Guide Version 10.2, Last Revised November 14, 2022
2.4 Excluded Functionality
The list below identifies features or protocols that are not evaluated or must be disabled, and the rationale
why. Note that this does not mean the features cannot be used in the evaluated configuration (unless
explicitly stated so). It means that the features were not evaluated and/or validated by an independent third
party and the functional correctness of the implementation is vendor assertion. Evaluated functionality is
scoped exclusively to the security functional requirements specified in Security Target. In particular, only
the following protocols implemented by the TOE have been tested, and only to the extent specified by the
security functional requirements: TLS, HTTPS, SSH, IKE/IPsec. The features below and Normal mode are
out of scope.
Table 2 Excluded Features
Feature Description
Telnet and HTTP Management
Protocols
Telnet and HTTP are disabled by default and cannot be enabled
in the evaluated configuration. Telnet and HTTP are insecure
protocols which allow for plaintext passwords to be
transmitted. Use SSH, IPsec, and HTTPS only as the
management protocols to manage the TOE.
External Authentication Servers The NDcPP does not require external authentication servers.
Shell and Console Access The shell and console access are only allowed for pre-
operational installation, configuration, and post-operational
maintenance and trouble shooting.
TLS and SSH Decryption Policies The TLS and SSH decryption policies are not evaluated and
therefore, these features are out of scope.
Anti-Virus, Anti-Spyware, Anti-
Malware Security Policies
The Anti-Virus, Anti-Spyware, Anti-Malware security policies
(i.e., profiles) are not evaluated and therefore, there features
are out of scope.
File Blocking, DLP, and URL
Filtering Security Policies
The File Blocking, DLP (Data Loss Prevention), and URL
Filtering security policies/profiles are not evaluated and
therefore, these features are out of scope.
API request over HTTP By default, the TOE supports API requests over HTTPS or
HTTPS tunneled over IPsec. API request over HTTP is
disabled and cannot be enabled in the evaluated
configuration.
Any features not associated with
SFRs in claimed [NDcPP], [FW-
Module], and [VPNGW-Module]
NDcPP forbids adding additional requirements to the Security
Target (ST). If additional functionalities or products are
mentioned in the ST, it is for completeness only.
Page 27 of 84
3. Security Problem Definition
This security target includes by reference the Security Problem Definition (composed of organizational
policies, threat statements, and assumption) from [NDcPP], [FW-Module], and [VPNGW-Module].
In general, the [NDcPP], [FW-Module], and [VPNGW-Module] have presented a Security Problem Definition
appropriate for network infrastructure devices, such as firewalls, routers, managers and as such is applicable
to the Palo Alto TOE. NOTE: A.COMPONENTS_RUNNING is not applicable because this is not a distributed
TOE.
Page 28 of 84
4. Security Objectives
Like the Security Problem Definition, this security target includes by reference the Security Objectives from
the [NDcPP], [FW-Module], and [VPNGW-Module]. The security objectives for the operational environment
are reproduced below since these objectives characterize technical and procedural measures each consumer
must implement in their operational environment.
In general, the [NDcPP], [FW-Module], and [VPNGW-Module] has presented Security Objectives
appropriate for network infrastructure devices, such as is applicable to the Palo Alto TOE. NOTE:
OE.COMPONENTS_RUNNING is not applicable because this is not a distributed TOE.
4.1 Security Objectives for the Operational Environment
OE.PHYSICAL Physical security, commensurate with the value of the
TOE and the data it contains, is provided by the
environment.
OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g.,
compilers or user applications) available on the TOE, other
than those services necessary for the operation,
administration and support of the TOE.
OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that
traverses it. It is assumed that protection of this traffic will
be covered by other security and assurance measures in
the operational environment.
OE.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.TRUSTED_ADMIN Security Administrators are trusted to follow and apply all
guidance documentation in a trusted manner.
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.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.
Page 29 of 84
OE.CONNECTIONS 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.
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 virtualisation
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.
Page 30 of 84
5. IT Security Requirements
This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements
(SARs) that serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope
the evaluation effort.
The SFRs have all been drawn from the [NDcPP], [FW-Module] and [VPNGW-Module].
The SARs are the set of SARs specified in the PP-Configuration for Network Devices, Stateful Traffic Filter
Firewalls, and Virtual Private Network (VPN) Gateways.
5.1 Extended Requirements
All the extended requirements in this ST have been drawn from the [NDcPP], [FW-Module], [VPNGW-
Module]. The [NDcPP], [FW-Module], and [VPNGW-Module] define all the extended SFRs (*_EXT) and since
they are not redefined in this ST, those PPs and Modules should be consulted for more information regarding
those CC extensions.
5.2 TOE Security Functional Requirements
The following table identifies the SFRs that are satisfied by the Palo Alto TOE.
Table 3 TOE Security Functional Components
Requirement
Class
Requirement Component Location
FAU: Security
Audit
FAU_GEN.1: Audit Data Generation NDcPP
FAU_GEN.1/VPN: Audit Data Generation (VPN
Gateway)
VPNGW
FAU_GEN.2: User Identity Association NDcPP
FAU_STG_EXT.1: Protected Audit Event Storage NDcPP
FCS:
Cryptographic
Support
FCS_CKM.1: Cryptographic Key Generation NDcPP
FCS_CKM.1/IKE: Cryptographic Key Generation (for
IKE Peer Authentication)
VPNGW
FCS_CKM.2: Cryptographic Key Establishment NDcPP
FCS_CKM.4: Cryptographic Key Destruction NDcPP
FCS_COP.1/DataEncryption: Cryptographic Operation
(AES Data Encryption/Decryption)
NDcPP
FCS_COP.1/SigGen: Cryptographic Operation
(Signature Generation and Verification)
NDcPP
FCS_COP.1/Hash: Cryptographic Operation (Hash
Algorithm)
NDcPP
FCS_COP.1/KeyedHash: Cryptographic Operation
(Keyed Hash Algorithm)
NDcPP
FCS_RBG_EXT.1: Random Bit Generation NDcPP
FCS_HTTPS_EXT.1(1): HTTPS Protocol (Default) NDcPP
Page 31 of 84
Requirement
Class
Requirement Component Location
FCS_HTTPS_EXT.1(2): HTTPS Protocol (Configure
Mutual Authentication)
FCS_SSHS_EXT.1: SSH Server Protocol NDcPP
FCS_TLSC_EXT.1: TLS Client Protocol without Mutual
Authentication
NDcPP
FCS_TLSC_EXT.2: TLS Client Support for Mutual
Authentication
NDcPP
FCS_TLSS_EXT.1: TLS Server Protocol without Mutual
Authentication
NDcPP
FCS_TLSS_EXT.2: TLS Server Support for Mutual
Authentication
NDcPP
FCS_IPSEC_EXT.1: IPsec Protocol NDcPP
FDP: User Data
Protection
FDP_RIP.2: Full Residual Information Protection FW
FIA: Identification
and
Authentication
FIA_AFL.1: Authentication Failure Management NDcPP
FIA_PMG_EXT.1: Password Management NDcPP
FIA_UIA_EXT.1: User Identification and Authentication NDcPP
FIA_UAU_EXT.2: Password-based Authentication
Mechanism
NDcPP
FIA_UAU.7: Protected Authentication Feedback NDcPP
FIA_X509_EXT.1/Rev: X.509 Certificate Validation NDcPP
FIA_X509_EXT.2: X.509 Certificate Authentication NDcPP
FIA_X509_EXT.3: X.509 Certificate Requests NDcPP
FMT: Security
Management
FMT_MOF.1/ManualUpdate: Management of Security
Functions Behaviour
NDcPP
FMT_MOF.1/Services: Management of Security
Functions Behaviour
NDcPP
FMT_MTD.1/CryptoKeys: Management of TSF Data NDcPP
FMT_MTD.1/CoreData: Management of TSF Data NDcPP
FMT_SMF.1: Specification of Management Functions NDcPP
FMT_SMF.1/FFW: Specification of Management
Functions
FW
FMT_SMF.1/VPN: Specification of Management
Functions
VPNGW
FMT_SMR.2: Restrictions on Security Roles NDcPP
FPT: Protection
of the TSF
FPT_SKP_EXT.1: Protection of TSF Data (for reading of
all pre-shared, symmetric and private keys)
NDcPP
Page 32 of 84
Requirement
Class
Requirement Component Location
FPT_APW_EXT.1: Protection of Administrator
Passwords
NDcPP
FPT_FLS.1/SelfTest Fail Secure (Self-test Failures) VPNGW
FPT_STM_EXT.1: Reliable Time Stamps NDcPP
FPT_TST_EXT.1: TSF Testing NDcPP
FPT_TST_EXT.3: Self-Test with Defined Methods VPNGW
FPT_TUD_EXT.1: Trusted Update NDcPP
FTA: TOE Access FTA_SSL_EXT.1: TSF-initiated Session Locking NDcPP
FTA_SSL.3: TSF-initiated Termination NDcPP
FTA_SSL.4: User-initiated Termination NDcPP
FTA_TAB.1: Default TOE Access Banners NDcPP
FTP: Trusted
Path/Channels
FTP_ITC.1: Inter-TSF Trusted channel NDcPP
FTP_ITC.1/VPN: Inter-TSF Trusted channel (VPN
Communications)
VPNGW
FTP_TRP.1/Admin: Trusted Path NDcPP
FFW: Stateful
Traffic Filter
Firewall
FFW_RUL_EXT.1: Stateful Traffic Filtering FW
FFW_RUL_EXT.2: Stateful Filtering of Dynamic
Protocols
FW
FPF: Packet
Filtering
FPF_RUL_EXT.1: Rules for Packet Filtering VPNGW
5.2.1 Security Audit (FAU)
FAU_GEN.1 – Audit Data Generation
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not specified level of audit; 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 4
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
Page 33 of 84
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 4.
Table 4 Auditable Events (Network Device, Firewall)
Requirement Auditable Events Additional Audit Record
Contents
FAU_GEN.1 None. None.
FAU_GEN.2 None. None.
FAU_STG_EXT.1 None. None.
FCS_CKM.1 None. None.
FCS_CKM.2 None. None.
FCS_CKM.4 None. None.
FCS_COP.1/DataEncryption None. None.
FCS_COP.1/SigGen None. None.
FCS_COP.1/Hash None. None.
FCS_COP.1/KeyedHash None. None.
FCS_RBG_EXT.1 None. None.
FCS_HTTPS_EXT.1(1)
FCS_HTTPS_EXT.1(2)
Failure to establish an HTTPS
session.
Reason for failure
FCS_SSHS_EXT.1 Failure to establish a 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
FCS_TLSS_EXT.2 Failure to authenticate the client Reason for failure
FCS_IPSEC_EXT.1 Failure to establish an IPsec SA Reason for failure
FDP_RIP.2 None. None.
FIA_AFL.1 Unsuccessful login attempts limit
is met or exceeded.
Origin of the attempt (e.g., IP
address)
FIA_PMG_EXT.1 None. None.
FIA_UIA_EXT.1 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU_EXT.2 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU.7 None. None.
FIA_X509_EXT.1/Rev Unsuccessful attempt to validate a
certificate
Reason for failure of
certificate validation
Identification of certificates
added, replaced or removed as
Page 34 of 84
Requirement Auditable Events Additional Audit Record
Contents
Any addition, replacement or
removal of trust anchors5
in the
TOE's trust store
trust anchor in the TOE's trust
store
FIA_X509_EXT.2 None. None.
FIA_X509_EXT.3 None. None.
FMT_MOF.1/ManualUpdate Any attempt to initiate a manual
update
None.
FMT_MOF.1/Services None. None.
FMT_MTD.1/CryptoKeys None. None.
FMT_MTD.1/CoreData None. None.
FMT_SMF.1 All management activities of TSF
data
None.
FMT_SMF.1/FFW All management activities of TSF
data (including creation,
modification, and deletion of
firewall rules).
None.
FMT_SMR.2 None. None.
FPT_SKP_EXT.1 None. None.
FPT_APW_EXT.1 None. None.
FPT_TST_EXT.1 None. None.
FPT_TUD_EXT.1 Initiation of update; result of the
update attempt (success or failure)
None.
FPT_STM_EXT.1 Discontinuous changes to time -
either Administrator actuated or
changed via an automated process.
(Note that no continuous changes
to time need to be logged. See also
application note on
FPT_STM_EXT.1)
For discontinuous changes to
time: The old and new values
for the time. Origin of the
attempt to change time for
success and failure (e.g., IP
address).
FTA_SSL_EXT.1 (if “terminate
the session” is selected)
The termination of a local session
by the session locking mechanism.
None.
FTA_SSL.3 The termination of a remote
session by the session locking
mechanism.
None.
FTA_SSL.4 The termination of an interactive
session.
None.
FTA_TAB.1 None. None.
FTP_ITC.1 Initiation of the trusted channel. Identification of the initiator
and target of failed trusted
5
Importing CA certificate(s) or generating CA certificate(s) internally will implicitly set them as trust anchor.
Page 35 of 84
Requirement Auditable Events Additional Audit Record
Contents
Termination of the trusted
channel.
Failure of the trusted channel
functions.
channels establishment
attempt.
FTP_TRP.1/Admin Initiation of the trusted path.
Termination of the trusted path.
Failures of the trusted path
functions.
None.
FFW_RUL_EXT.1 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 Dynamical definition of rule,
Establishment of a session
None
Application Note: This SFR is defined in [NDcPP] but was modified per guidance in [FW-
Module].
FAU_GEN.1/VPN – Audit Data Generation (VPN Gateway)
FAU_GEN.1.1/VPN 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) Indication that TSF self-test was completed
c) Failure of self-test
d) All auditable events for the [not specified] level of audit; and
e) [auditable events defined in Table 5]
FAU_GEN.1.2/VPN 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 (if applicable), 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, [additional information defined in
Table 5].
Table 5 Auditable Events (VPN Gateway)
Requirement Auditable Events Additional Audit Record
Contents
FAU_GEN.1/VPN No events specified. N/A
FCS_CKM.1/IKE No events specified. N/A
FMT_SMF.1/VPN All administrative actions No additional information.
FPF_RUL_EXT.1 Application of rules configured
with the ‘log’ operation
Source and destination
addresses
Page 36 of 84
Requirement Auditable Events Additional Audit Record
Contents
Source and destination ports
Transport layer protocol
FPT_FLS.1/SelfTest No events specified. N/A
FPT_TST_EXT.3 No events specified. N/A
FTP_ITC.1/VPN 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
channel establishment
attempt.
FAU_GEN.2 – User Identity Association
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to associate
each auditable event with the identity of the user that caused the event.
FAU_STG_EXT.1 – Protected Audit Event Storage
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity
using a trusted channel according to FTP_ITC.1.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself [
• TOE shall consist of a single standalone component that stores audit data
locally].
FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the following rule:
[overwrite oldest records first]] when the local storage space for audit data is full.
5.2.2 Cryptographic Support (FCS)
FCS_CKM.1 – Cryptographic Key Generation
FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a
specified cryptographic key generation algorithm: [
• RSA schemes using cryptographic key sizes of 2048-bit or greater that meet
the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix
B.3;
• ECC schemes using “NIST curves” [P-256, P-384, P-521] that meet the
following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4;
• FFC schemes using cryptographic key sizes of 2048-bit or greater that meet
the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix
B.1
• 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].
Page 37 of 84
] and specified cryptographic key sizes [assignment: cryptographic key sizes]
that meet the following: [assignment: list of standards].112 bits.
FCS_CKM.1/IKE – Cryptographic Key Generation (for IKE Peer Authentication)
FCS_CKM.1.1/IKE 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].
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: [
• 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”;
• Finite field-based key establishment schemes that meets the following: NIST
Special Publication 800-56A Revision 2, “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].
Application Note: This SFR has been modified by TD0580 and TD0581.
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 [a pseudo-random pattern using the TSF’s
RBG]];
• 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
[[three]-pass] overwrite consisting of [[a different alternating
patterns that does not contain any CSP]];
Page 38 of 84
that meets the following: No Standard.
FCS_COP.1/DataEncryption – Cryptographic Operation (AES Data Encryption/Decryption)
FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with a
specified cryptographic algorithm AES used in [GCM, CBC] and [CTR] mode and
cryptographic key sizes [128 bits, 256 bits], and [192 bits] that meet the following:
AES as specified in ISO 18033-3, [CBC as specified in ISO 10116, GCM as specified
in ISO 19772] and [CTR as specified in ISO 10116].
Application Note: This SFR is defined in [NDcPP] but was modified per guidance in
[VPNGW-Module].
Application Note 2: The 192 bits AES key size is used in CBC mode only and for IPsec
only.
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, 4096 bits],
• Elliptic Curve Digital Signature Algorithm and cryptographic key sizes [256
bits, 384 bits, 521 bits]
] and cryptographic key sizes [assignment: cryptographic key sizes]
that meet the following: [
• For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Section 5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or
RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital
Signature scheme 3,
• For ECDSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Section 6 and Appendix D, Implementing “NIST curves” [P-256, P-384, P-
521]; ISO/IEC 14888-3, Section 6.4
].
FCS_COP.1/Hash – Cryptographic Operation (Hash Algorithm)
FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance with a specified
cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] and cryptographic
key sizes [assignment: cryptographic key sizes] and message digest sizes [160, 256,
384, 512] bits that meet the following: ISO/IEC 10118-3:2004.
FCS_COP.1/KeyedHash – Cryptographic Operation (Keyed Hash Algorithm)
FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in accordance
with a specified cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256, HMAC-
SHA-384, HMAC-SHA-512, implicit] and cryptographic key sizes [160, 256, 384,
512] and message digest sizes [160, 256, 384, 512] bits that meet the following:
ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”.
Page 39 of 84
FCS_RBG_EXT.1 – Random Bit Generation
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using [CTR_DRBG (AES)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that
accumulates entropy from [[one] platform-based noise source] with a minimum of
[256 bits] of entropy at least equal to the greatest security strength, according to
ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash Functions”, of
the keys and hashes that it will generate.
FCS_HTTPS_EXT.1(1) – HTTPS Protocol (Default)
FCS_HTTPS_EXT.1.1(1) The TSF shall implement the HTTPS protocol that complies with RFC 2818.
FCS_HTTPS_EXT.1.2(1) The TSF shall implement HTTPS using TLS.
FCS_HTTPS_EXT.1.3(1) If a peer certificate is presented, the TSF shall [not require client authentication] if
the peer certificate is deemed invalid.
Application Note: By default, the TOE acting as a HTTPS server does not perform
mutual authentication for HTTPS client/user.
FCS_HTTPS_EXT.1(2) – HTTPS Protocol (Configure Mutual Authentication)
FCS_HTTPS_EXT.1.1(2) The TSF shall implement the HTTPS protocol that complies with RFC 2818.
FCS_HTTPS_EXT.1.2(2) The TSF shall implement HTTPS using TLS.
FCS_HTTPS_EXT.1.3(2) If a peer certificate is presented and the TSF is configured to perform mutual
authentication, the TSF shall [not establish the connection] if the peer certificate is
deemed invalid.
Application Note: When the HTTPS server is configured for mutual authentication, the
TLS client/user certificate must be valid or the TOE will not establish a HTTPS session.
FCS_SSHS_EXT.1 – SSH Server Protocol
FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol in accordance with: RFCs 4251, 4252,
4253, 4254, [4344, 5647, 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].
Application Note: This SFR was modified by TD0631.
FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [256K]
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: [aes128cbc,
aes256-cbc, aes128-ctr, aes256-ctr, aes128-gcm@openssh.com, aes256-
gcm@openssh.com].
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH public-key based authentication implementation
uses [ssh-rsa] as its public key algorithm(s) and rejects all other public key
algorithms.
Page 40 of 84
FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses [hmac-sha1,
hmac-sha2-256, hmac-sha2-512, implicit] 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] and
[ecdh-sha2-nistp384, ecdh-sha2-nistp521] are the only allowed key exchange
methods used for the SSH protocol.
FCS_SSHS_EXT.1.8 The TSF ensure that within SSH connections, the same session keys are used for a
threshold of no longer than one hour, and each encryption key is used to protect
no more than one gigabyte of data. After any of the thresholds are reached, a rekey
needs to be performed.
FCS_TLSC_EXT.1 - TLS Client Protocol without Mutual Authentication
FCS_TLSC_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246)] and reject all other TLS and SSL
versions. The TLS implementation will support the following ciphersuites:
[
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
• TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246
• TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC
5289
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC
5289
].
FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifiers of the following types: [the
reference identifier per RFC 6125, IPv4 address in CN or SAN] are matched to
reference identifiers.
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].
Page 41 of 84
FCS_TLSC_EXT.1.4 The TSF shall [present the Supported Elliptic Curves/Supported Groups Extension
with the following NIST curves: [secp256r1, secp384r1, secp521r1] and no other
curves] in the Client Hello.
FCS_TLSC_EXT.2 - TLS Client Support for Mutual Authentication
FCS_TLSC_EXT.2.1 The TSF shall support TLS communication with mutual authentication using
X.509v3 certificates.
Application Note: Mutual authentication is supported for the TOE to syslog server
TLSv1.2 connection, if configured.
FCS_TLSS_EXT.1 - TLS Server Protocol without Mutual Authentication
FCS_TLSS_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] and reject all
other TLS and SSL versions. The TLS implementation will support the following
ciphersuites:
[
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC
5289
].
FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0,
and [none].
FCS_TLSS_EXT.1.3 The TSF shall perform key establishment for TLS using [Diffie-Hellman parameters
with size [2048 bits], ECDHE curves [secp256r1, secp384r1] and no other curves]].
Application Note: For the management and GlobalProtect (GP) connections, the TOE is
the TLS server.
FCS_TLSS_EXT.1.4 The TSF shall support [session resumption based on session tickets according to RFC
5077].
FCS_TLSS_EXT.2 - TLS Server Support for Mutual Authentication
FCS_TLSS_EXT.2.1 The TSF shall support TLS communication with mutual authentication of TLS clients
using X.509v3 certificates.
Page 42 of 84
FCS_TLSS_EXT.2.2 When establishing a trusted channel, by default the TSF shall not establish a trusted
channel if the client certificate is invalid. The TSF shall also [
• Not implement any administrator override mechanism
].
FCS_TLSS_EXT.2.3 The TSF shall not establish a trusted channel if the identifier contained in a
certificate does not match an expected identifier for the client. If the identifier is a
Fully Qualified Domain Name (FQDN), then the TSF shall match the identifiers
according to RFC 6125, otherwise the TSF shall parse the identifier from the
certificate and match the identifier against the expected identifier of the client as
described in the TSS.
Application Note: Mutual authentication is supported for the management session (if
configured) and TOE to GP connection (if configured).
FCS_IPSEC_EXT.1 – IPsec Protocol
Application Note: This SFR is defined in [NDcPP] but several elements were modified
per guidance in [VPNGW-Module].
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 [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, AES-CBC-256 (specified in RFC 3602), AES-
GCM-128, AES-GCM-256 (specified in RFC 4106)] and [AES-CBC-192 (specified in
RFC 3602)] together with a Secure Hash Algorithm (SHA)-based HMAC [HMAC-
SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512].
FCS_IPSEC_EXT.1.5 The TSF shall implement the protocol: [
• IKEv1, using Main Mode for Phase 1 exchanges, as defined in RFCs 2407, 2408,
2409, RFC 4109, [RFC 4304 for extended sequence numbers], and [no other
RFCs for hash functions];
• 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 [IKEv1, IKEv2] protocol uses the
cryptographic algorithms [AES-CBC-128, AES-CBC-192, AES-CBC-256 (specified in
RFC 3602)].
FCS_IPSEC_EXT.1.7 The TSF shall ensure that [
• IKEv1 Phase 1 SA lifetimes can be configured by an Security
Administrator based on
[
o length of time, where the time values can configured within [1 to
8760] hours;
];
Page 43 of 84
• IKEv2 SA lifetimes can be configured by an Security Administrator based
on
[
o length of time, where the time values can configured within [1 to
8760] hours
]].
FCS_IPSEC_EXT.1.8 The TSF shall ensure that [
o IKEv1 Phase 2 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 [1
to 8760] hours;
];
o 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 [1
to 8760] hours;
]].
FCS_IPSEC_EXT.1.9 The TSF shall generate the secret value x used in the IKE Diffie-Hellman key
exchange (“x” in gx
mod p) using the random bit generator specified in
FCS_RBG_EXT.1, and having a length of at least [224 (for DH Group 14), 256 (for
DH Group 19), 384 (for DH Group 20)] bits.
FCS_IPSEC_EXT.1.10 The TSF shall generate nonces used in [IKEv1, IKEv2] exchanges of length
[
• 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 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,
• [no other DH Groups] according to RFC 5114]
].
FCS_IPSEC_EXT.1.12 The TSF shall be able to ensure by default that the strength of the symmetric
algorithm (in terms of the number of bits in the key) negotiated to protect the
[IKEv1 Phase 1, IKEv2 IKE_SA] connection is greater than or equal to the strength
of the symmetric algorithm (in terms of the number of bits in the key) negotiated
to protect the [IKEv1 Phase 2, IKEv2 CHILD_SA] connection.
Page 44 of 84
FCS_IPSEC_EXT.1.13 The TSF shall ensure that all IKE protocols perform peer authentication using a [RSA,
ECDSA] that use X.509v3 certificates that conform to RFC 4945 and [no other
method].
FCS_IPSEC_EXT.1.14 The TSF shall only establish a trusted channel if the presented identifier in the
received certificate matches the configured reference identifier, where the
presented and reference identifiers are of the following fields and types:
Distinguished Name (DN), [CN: IP address, CN: Fully Qualified Domain Name
(FQDN)].
Application Note: FCS_IPSEC_EXT.1.4, .1.11, and .1.14 are defined in the [NDcPP] but
have been modified based on [VPNGW-Module].
5.2.3 User Data Protection (FDP)
FDP_RIP.2 – Full Residual Information Protection
FDP_RIP.2 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.2.4 Identification and Authentication (FIA)
FIA_AFL.1 – Authentication Failure Management
FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within [1-10]
unsuccessful authentication attempts occur related to Administrators attempting to
authenticate remotely using a password.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the TSF
shall [prevent the offending remote Administrator from successfully establishing remote
session using any authentication method that involves a password until an Administrator
defined time period has elapsed].
FIA_PMG_EXT.1 – Password Management
FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for
administrative passwords:
1. Passwords shall be able to be composed of any combination of upper and
lower case letters, numbers, and the following special characters: [“!”, “@”,
“#”, “$”, “%”, “^”, “&”, “*”, “(”, “)”, [“'”, “+”, “,”, “-”, “.”, “/”, “:”, “;”, “<”, “=”, “>”, “[”,
“\”, “]”, “_”, “`”, “{”, “}”, and “~”]];
2. Minimum password length shall be configurable to between [8] and [15]
characters.
FIA_UIA_EXT.1 – User Identification and Authentication
FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE entity to
initiate the identification and authentication process:
• Display the warning banner in accordance with FTA_TAB.1;
• [[ICMP Request/Response]].
FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully identified and
authenticated before allowing any other TSF-mediated actions on behalf of that
administrative user.
Page 45 of 84
FIA_UAU_EXT.2 – Password-based Authentication Mechanism
FIA_UAU_EXT.2.1 The TSF shall provide a local [password-based, certificate-based, SSH public key-
based] authentication mechanism to perform local administrative user
authentication.
FIA_UAU.7 – Protected Authentication Feedback
FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the
authentication is in progress at the local console.
FIA_X509_EXT.1/Rev – X.509 Certificate Validation
FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules:
• RFC 5280 certificate validation and certificate path validation supporting a
minimum path length of three certificates.
• The certificate path must terminate with a trusted CA certificate 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, a Certificate
Revocation List (CRL) as specified in RFC 5280 Section 6.3, 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.
o OCSP certificates presented for OCSP responses shall have the OCSP
Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the
extendedKeyUsage field.
FIA_X509_EXT.1.2/Rev The TSF shall only treat a certificate as a CA certificate if the basicConstraints
extension is present and the CA flag is set to TRUE.
FIA_X509_EXT.2 – X.509 Certificate Authentication
FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for IPsec and [TLS], and [no additional uses].
Application Note: This SFR is defined in [NDcPP] but was modified per guidance in
[VPNGW-Module].
Page 46 of 84
FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a
certificate, the TSF shall [not accept the certificate].
Application Note: For the syslog connection, the behavior is to not accept the server
certificate and fail the connection (not configurable).
FIA_X509_EXT.3 – X.509 Certificate Requests
FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request as specified by RFC 2986 and be able
to provide the following information in the request: public key and [Common Name,
Organization, Organizational Unit, Country].
FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon receiving the
CA Certificate Response.
Application Note: FIA_X509_EXT.3 is mandated by [VPNGW-Module].
5.2.5 Security Management (FMT)
FMT_MOF.1/ManualUpdate - Management of Security Functions Behaviour
FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to perform manual
update to Security Administrators.
FMT_MOF.1/Services - Management of Security Functions Behaviour
FMT_MOF.1.1/ServicesThe TSF shall restrict the ability to start and stop the functions services to Security
Administrators.
FMT_MTD.1/CryptoKeys – Management of TSF Data
FMT_MTD.1.1/CryptoKeys The TSF shall restrict the ability to [[manage]] the [cryptographic keys and
certificates used for VPN operation] to [Security Administrators].
Application Notes: This SFR is defined in [NDcPP] but was modified per guidance in
[VPNGW-Module].
FMT_MTD.1/CoreData – Management of TSF Data
FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to Security
Administrators.
FMT_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;
[
o Ability to manage the cryptographic keys;
Page 47 of 84
o Ability to configure the cryptographic functionality;
o Ability to configure the lifetime for IPsec SAs;
o Ability to import X.509v3 certificates to the TOE’s trust store;
o Ability to start and stop services
o Ability to configure audit behaviour (e.g. changes to storage locations for
audit; changes to behavior when local audit storage space is full);
o Ability to configure the list of TOE-provided services available before an entity
is identified and authenticated, as specified in FIA_UIA_EXT.1;
o Ability to configure thresholds for SSH rekeying;
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;
o Ability to manage the TOE’s trust store and designate X509v3 certificates as
trust anchors;
o Ability to manage the trusted public keys database
].
Application Note: This SFR was modified by TD0631.
FMT_SMF.1/FFW – Specification of Management Functions
FMT_SMF.1.1/FFW The TSF shall be capable of performing the following management functions:
• Ability to configure firewall rules;
FMT_SMF.1/VPN – Specification of Management Functions
FMT_SMF.1.1/VPN The TSF shall be capable of performing the following management functions: [
• Definition of packet filtering rules;
• Association of packet filtering rules to network interfaces;
• Ordering of packet filtering rules by priority; [
• No other capabilities]].
FMT_SMR.2 – Restrictions on Security Roles
FMT_SMR.2.1 The TSF shall maintain the roles:
• Security Administrator.
FMT_SMR.2.2 The TSF shall be able to associate users with roles.
FMT_SMR.2.3 The TSF shall ensure that the conditions
• The Security Administrator role shall be able to administer the TOE locally;
• The Security Administrator role shall be able to administer the TOE remotely;
are satisfied.
5.2.6 Protection of the TSF (FPT)
FPT_SKP_EXT.1 – Protection of TSF data (for reading of all pre-shared, symmetric and private keys)
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric key, and private
keys.
Page 48 of 84
FPT_APW_EXT.1 – Protection of Administrator Passwords
FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-plaintext form.
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext administrative passwords.
FPT_FLS.1/SelfTest – Fail Secure (Self-test Failures)
FPT_FLS.1.1/SelfTest 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].
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].
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, [
• AES Encrypt Known Answer Test
• AES Decrypt Known Answer Test
• AES GCM Encrypt Known Answer Test
• AES GCM Decrypt Known Answer Test
• AES CCM Encrypt Known Answer Test
• AES CCM Decrypt Known Answer Test
• RSA Sign Known Answer Test
• RSA Verify Known Answer Test
• RSA Encrypt/Decrypt Known Answer Test
• ECDSA Sign Known Answer Test
• ECDSA Verify Known Answer Test
• HMAC-SHA-1 Known Answer Test
• HMAC-SHA-256 Known Answer Test
• HMAC-SHA-384 Known Answer Test
• HMAC-SHA-512 Known Answer Test
• SHA-1 Known Answer Test
• SHA-256 Known Answer Test
• SHA-384 Known Answer Test
• SHA-512 Known Answer Test
• DRBG SP800-90A Known Answer Tests
• SP 800-90A Section 11.3 Health Tests
• DH Known Answer Test
• ECDH Known Answer Test
• SP 800-135 KDF Known Answer Tests
• Firmware Integrity Test
].
Application Note: This SFR is defined in [NDcPP] but was modified per guidance in
[VPNGW-Module].
Page 49 of 84
FPT_TST_EXT.3 – Self-Test with Defined Methods
FPT_TST_EXT.3.1 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 The TSF shall execute the self-testing through [a TSF-provided cryptographic service
specified in FCS_COP.1/SigGen].
FPT_TUD_EXT.1 – Trusted Update
FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the currently
executing version of the TOE firmware/software and [no other TOE
firmware/software version].
FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually initiate updates
to TOE firmware/software and [no other update mechanism].
FPT_TUD_EXT.1.3 The TSF shall provide a means to authenticate firmware/software updates to the
TOE using a digital signature mechanism and [no other mechanisms] prior to
installing those updates.
Application Note: This SFR is defined in [NDcPP] but was modified per guidance in
[VPNGW-Module].
5.2.7 TOE Access (FTA)
FTA_SSL_EXT.1 – TSF-initiated Session Locking
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [terminate the session] after a Security
Administrator-specified time period of inactivity.
FTA_SSL.3 – TSF-initiated Termination
FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security Administrator-
configurable time interval of session inactivity.
FTA_SSL.4 – User-initiated Termination
FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s own
interactive session.
FTA_TAB.1 – Default TOE Access Banners
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.
Page 50 of 84
5.2.8 Trusted Path/Channels (FTP)
FTP_ITC.1 – Inter-TSF Trusted Channel
FTP_ITC.1.1 The TSF shall be capable of using [TLS] to provide a trusted communication channel
between itself and authorized IT entities supporting the following capabilities: audit server,
[GlobalProtect] that is logically distinct from other communication channels and provides
assured identification of its end points and protection of the channel data from disclosure
and detection of modification of the channel data.
FTP_ITC.1.2 The TSF shall permit the TSF or the authorized IT entities to initiate communication via the
trusted channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [
• Transmitting audit records to an audit server using IPsec or TLS,
].
Application Note: The connection to the audit server (over TLS) can be tunneled over IPsec using
the VPN connection identified below.
FTP_ITC.1/VPN – Inter-TSF Trusted Channel (VPN Communications)
FTP_ITC.1.1/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 The TSF shall permit [the authorized IT entities] to initiate communication via the
trusted channel.
FTP_ITC.1.3/VPN The TSF shall initiate communication via the trusted channel for [remote VPN
gateways or peers].
FTP_TRP.1/Admin – Trusted Path
FTP_TRP.1.1/Admin The TSF shall be capable of using [SSH, HTTPS, IPsec] to provide a communication
path between itself and authorized remote Administrators that is logically distinct from
other communication paths and provides assured identification of its end points and
protection of the communicated data from disclosure and provides detection of
modification of the channel data.
FTP_TRP.1.2/Admin The TSF shall permit remote Administrators to initiate communication via the
trusted path.
FTP_TRP.1.3/Admin The TSF shall require the use of the trusted path for initial Administrator
authentication and all remote administrative actions.
Page 51 of 84
5.2.9 Firewall (FFW)
FFW_RUL_EXT.1 – Stateful Traffic Filtering
FFW_RUL_EXT.1.1 The TSF shall perform Stateful Traffic Filtering on network packets processed by
the TOE.
FFW_RUL_EXT.1.2 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 [IPv6 Extension header type [Next Header, Hdr Ext Len, Header Specific
Data, Option Type, Opt Data Len, Option Data, Routing Type]]
• TCP
o Source Port
o Destination Port
• UDP
o Source Port
o Destination Port.
and distinct interface.
FFW_RUL_EXT.1.3 The TSF shall allow the following operations to be associated with Stateful Traffic
Filtering rules: permit or drop with the capability to log the operation.
FFW_RUL_EXT.1.4 The TSF shall allow the Stateful Traffic Filtering rules to be assigned to each distinct
network interface.
FFW_RUL_EXT.1.5 The TSF shall:
a) accept a network packet without further processing of Stateful Traffic Filtering rules if
it matches an allowed established session for the following protocols: TCP, UDP,
[ICMP] based on the following network packet attributes:
1. TCP: source and destination addresses, source and destination ports,
sequence number, Flags;
Page 52 of 84
2. UDP: source and destination addresses, source and destination ports;
3. [ICMP: source and destination addresses, type, [code]].
b) Remove existing traffic flows from the set of established traffic flows based on the
following: [session inactivity timeout, completion of the expected information flow].
FFW_RUL_EXT.1.6 The TSF shall enforce the following default Stateful Traffic Filtering rules on all
network traffic:
a) The TSF shall drop and be capable of [logging] packets which are invalid
fragments;
b) The TSF shall drop and be capable of [logging] fragmented packets which cannot
be re-assembled completely;
c) The TSF shall drop and be capable of logging packets where the source address of
the network packet is defined as being on a broadcast network;
d) The TSF shall drop and be capable of logging packets where the source address of
the network packet is defined as being on a multicast network;
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) [[
o block both inbound and outbound IPv6 Site Local Unicast addresses
(FEC0::/10)
o block IPv6 Jumbo Payload datagrams (Option Type 194).
o drop all inbound and outbound IPv6 packets containing a Hop-by-Hop
header with option type values intended for Destination Options
o block RFC 6598 "Carrier Grade NAT" IP address block of 100.64.0.0/10
o drop all inbound IPv6 packets for which the layer 4 protocol and ports
(undetermined transport) cannot be located.
o drop all inbound IPv6 packets with a Type 0 Routing header
o drop all inbound IPv6 packets with a Type 1 or Types 3 through 255
Routing Header.
o drop all inbound IPv6 packets containing undefined header
extensions/protocol values.
o drop fragmented IPv6 packets when any fragment overlaps another.
Page 53 of 84
o drop all inbound IPv6 packets containing more than one Fragmentation
Header within an IP header chain.
o drop all inbound and outbound IPv6 packets containing a Hop-by-Hop
header with option type values intended for Destination Options.
o block IPv6 multicast addresses (FF00::/8) as a source address
]].
FFW_RUL_EXT.1.7 The TSF shall be capable of dropping and logging according to the following rules:
a) The TSF shall drop and be capable of logging network packets where the source
address of the network packet is equal to the address of the network interface
where the network packet was received;
b) The TSF shall drop and be capable of logging network packets where the source or
destination address of the network packet is a link-local address;
c) The TSF shall drop and be capable of logging network packets where the source
address of the network packet does not belong to the networks associated with
the network interface where the network packet was received.
FFW_RUL_EXT.1.8 The TSF shall process the applicable Stateful Traffic Filtering rules in an
administratively defined order.
FFW_RUL_EXT.1.9 The TSF shall deny packet flow if a matching rule is not identified.
FFW_RUL_EXT.1.10 The TSF shall be capable of limiting an administratively defined number of half-
open TCP connections. In the event that the configured limit is reached, new
connection attempts shall be dropped and the drop event shall be [counted, logged].
FFW_RUL_EXT.2 – Stateful Filtering of Dynamic Protocols
FFW_RUL_EXT.2.1 The TSF shall dynamically define rules or establish sessions allowing network traffic
to flow for the following network protocols [FTP].
Page 54 of 84
5.2.10 Packet Filtering (FPF)
FPF_RUL_EXT.1 – Rules for Packet Filtering
FPF_RUL_EXT.1.1 The TSF shall perform Packet Filtering on network packets processed by the TOE.
FPF_RUL_EXT.1.2 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 The TSF shall allow the following operations to be associated with Packet Traffic
Filtering rules: permit and drop with the capability to log the operation.
FPF_RUL_EXT.1.4 The TSF shall allow the packet filtering rules to be assigned to each distinct
network interface.
FPF_RUL_EXT.1.5 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 The TSF shall drop traffic if a matching rule is not identified.
Page 55 of 84
5.3 TOE Security Assurance Requirements
The security assurance requirements for the TOE are included by reference to [NDcPP], [FW-Module] and
[VPNGW-Module].
Table 6 Assurance Components
Requirement Class Requirement Component
ADV: Development ADV_FSP.1 Basic functional specification
AGD: Guidance Documents AGD_OPE.1: Operational user guidance
AGD_PRE.1: Preparative procedures
ALC: Life-Cycle Support ALC_CMC.1 Labelling of the TOE
ALC_CMS.1 TOE CM coverage
ASE: Security Target Evaluation ASE_INT.1: ST introduction
ASE_CCL.1: Conformance claims
ASE_SPD.1: Security problem definition
ASE_OBJ.1: Security objectives for the operational
environment
ASE_ECD.1: Extended components definition
ASE_REQ.1: Stated security requirements
ASE_TSS.1: TOE summary specification
ATE: Tests ATE_IND.1 Independent testing - conformance
AVA: Vulnerability Assessment AVA_VAN.1 Vulnerability survey
Consequently, the evaluation activities specified in the following Supporting Documents apply to the TOE
evaluation:
• Supporting Document Mandatory Technical Document: Evaluation Activities for Network Device
cPP, December-2019, Version 2.2
• Supporting Document Mandatory Technical Document: Evaluation Activities for Stateful Traffic
Filter Firewalls PP-Module, June-2020, Version 1.4 + Errata 20200625
• Supporting Document Mandatory Technical Document: PP-Module for Virtual Private Network
(VPN) Gateways Version 1.2, 2022-03-31
Page 56 of 84
6. TOE Summary Specification
This chapter describes the security functions:
• Security Audit
• Cryptographic Support
• User Data Protection
• Identification and Authentication
• Security Management
• Protection of the TSF
• TOE Access
• Trusted Path/Channels
• Stateful Traffic Filtering
• Packet Filtering
6.1 Security Audit
FAU_GEN.1
FAU_GEN.1/VPN
The TOE is designed to be able to generate log records for security relevant and other
events as they occur. The events that can cause an audit record to be logged include
starting and stopping the audit function (also startup and shutdown of system), any use
of an administrator command via the Web Interface, API, or CLI, as well as all of the
events identified in Table 4 (which corresponds to the audit events specified in the Error! R
eference source not found. and [FW-Module]) and Table 5 (which corresponds to the
audit events specified in the [VPNGW-Module]).
All log records include the following contents: date/time, event type, user ID (i.e.,
username, IP address) or component (i.e., ssh, syslog), and description of the event
including success or failure. For user-initiated actions, the User ID is included in the log
records. For cryptographic key operations, the key name—or certificate name if the key
is embedded in certificate or certificate request—is also logged. Furthermore, based on
the event, the description of the event will include additional information as required in
Table 4. Refer to the CC AGD [CCECG] for the complete list of mandated audit logs and
contents.
FAU_GEN.2 The TOE identifies the responsible user for each event based on the specific username
and/or network entity (identified by source IP address) that caused the event.
FAU_STG_EXT.1 The audit trail generated by the standalone TOE comprises several logs, which are locally
stored in the TOE file system on the hard disk:
• Configuration logs—include events such as when an administrator configures
the security policies, user management, cryptographic functions, audit functions
(e.g., enable syslog over TLS connection), and when an administrator configures
which events gets audited.
• System logs—include events such as user login and logout, session
establishment, termination, and failures.
• Traffic logs—record the traffic flow events
• Threat logs—record the detection and blocking of threats
The size of each log file is administrator configurable by specifying the percentage of
space allocated to each log type on the hard disk. If the log size is reduced, the TOE
removes the oldest logs when the changes are committed. When a log reaches the
maximum size, the TOE starts overwriting the oldest log entries with the new log entries.
Maximum disk space is platform dependent, and it depends on the hard disk drive
Page 57 of 84
installed on the system. By default, the TOE allocates 1-5% to system log, 1-5% to
configuration log, 20-35% to traffic log, and 10-20% to threat log. For example, for a
120GB drive approximately 100GB is allocated for logging. Platform capabilities range
from a limit of 3-4GB for the PA-220 which has a 16GB flash drive and up for the larger
platforms (for example, PA-5220 has 1.70 TB drive).
The standalone TOE stores the audit records locally and protects them from
unauthorized deletion by allowing only users in the pre-defined Audit Administrator role
to access the audit trail with delete privileges. The pre-defined Audit Administrator role
is part of the Security Administrator role as defined by the Error! Reference source not f
ound.. The TOE does not provide an interface where a user can modify the audit records,
thus it prevents modification to the audit records.
The standalone TOE can be configured to send generated audit records to an external
Syslog server in real-time using TLSv1.2 or IPsec. When configured to send audit records
to a syslog server, audit records are also written to the external syslog as they are written
locally to the internal logs.
6.2 Cryptographic Support
FCS_CKM.1
FCS_CKM.1/IKE
FCS_CKM.2
FCS_COP.1/*
FCS_RBG_EXT.1
The TOE includes NIST-validated cryptographic algorithms provided by Palo Alto
Networks Crypto Module supporting the cryptographic functions below. The
following functions have been certified in accordance with the identified standards.
Table 7 Cryptographic Functions
Functions Standards Certificates
Asymmetric Key Generation and Asymmetric Key Generation/IKE
FFC key pair generation (key
size 2048 bits)
FIPS PUB 186-4 Appliances
(#A2906):
DSA
ECDSA
RSA
VMs (#A2907):
DSA
ECDSA
RSA
N/A
ECC key pair generation
(NIST curves P-256, P-384, P-
521)
Note that TLS and SSH each
use any of P-256, P-384, or P-
521, and certificate generation
uses only P-256 or P-384.
FIPS PUB 186-4
RSA key generation (key sizes
2048, 3072, 4096 bits)
Note that TLS uses 2048-bit
RSA keys while certificate and
SSH RSA key pair generation
use 2048, 3072, or 4096-bit
keys.
FIPS PUB 186-4
Page 58 of 84
FFC Schemes using Diffie-
Hellman group 14 that meet
the following: RFC 3526 and
SP 800-56Ar3
RFC 3526
NIST SP 800-56Ar3
Cryptographic Key Establishment
RSA based key establishment RSAES-PKCS1-v1_5 RSA = N/A
Appliances
(#A2906):
KAS-ECC-SSC
KAS-FFC-SSC
VMs (#A2907):
KAS-ECC-SSC
KAS-FFC-SSC
ECDSA based key
establishment
NIST SP 800-56A
FFC based key establishment NIST SP 800-56A
Key establishment scheme
using Diffie-Hellman group 14
that meets the following: RFC
3526 and SP 800-56Ar3
RFC 3526
NIST SP 800-56Ar3
AES Data Encryption/Decryption
AES CBC, CTR, GCM (128,
192, 256 bits)
AES as specified in ISO
18033-3
CBC as specified in ISO
10116
CTR as specified in ISO
10116
GCM as specified in ISO
19772
Appliances
(#A2906):
AES
VMs (#A2907):
AES
Signature Generation and Verification
RSA Digital Signature
Algorithm (rDSA) (modulus
2048, 3072, 4096)
FIPS PUB 186-4, “Digital
Signature Standard (DSS)”,
Section 5.5, using PKCS #1
v2.1 Signature Schemes
RSASSA-PSS
and/or
RSASSAPKCS1v1_5;
ISO/IEC 9796-2, Digital
signature scheme 2
or
Digital Signature scheme 3
Appliances
(#A2906):
RSA
VMs (#A2907):
RSA
ECDSA (NIST curves P-256,
P-384, and P-521)
FIPS PUB 186-4, “Digital
Signature Standard (DSS)”,
Section 6 and Appendix D,
Implementing “NIST curves”
P-256, P-384, ISO/IEC
14888-3, Section 6.4
Appliances
(#A2906):
ECDSA
VMs (#A2907):
ECDSA
Page 59 of 84
Cryptographic Hashing
SHA-1, SHA-256, SHA-384
and SHA-512 (digest sizes
160, 256, 384 and 512 bits)
ISO/IEC 10118-3:2004 Appliances
(#A2906):
SHS
VMs (#A2907):
SHS
Keyed-hash Message Authentication
• HMAC-SHA-1 (block
size 512 bits, key size
160 bits and digest
size 160 bits)
• HMAC-SHA-256
(block size 512 bits,
key size 256 bits and
digest size 256 bits)
• HMAC-SHA-384
(block size 1024 bits,
key size 384 bits and
digest size 384 bits)
• HMAC-SHA-512
(block size 1024 bits,
key size 512 bits and
digest size 512 bits)
ISO/IEC 9797-2:2011 Appliances
(#A2906):
HMAC
VMs (#A2907):
HMAC
Random Bit Generation
CTR_DRBG (AES-256) ISO/IEC 18031:2011 Appliances
(#A2906):
DRBG
VMs (#A2907):
DRBG
The TOE implements the ISO/IEC 18031:2011 Deterministic Random Bit Generator
(DRBG) based on the AES 256 block cipher in counter mode (CTR_DRBG(AES)). The
TOE instantiates the DRBG with maximum security strength, obtaining the 256 bits
of entropy to seed the DRBG. The hardware-based entropy source is described in the
proprietary Entropy Design document. The TOE generates asymmetric cryptographic
keys used for key establishment in accordance with 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 ECC schemes, and FIPS PUB 186-4,
“Digital Signature Standard (DSS)”, Appendix B.1 for FFC schemes. In FIPS-CC mode,
all non-Approved key generation and key establishment functions are disabled.
Where required, only the CAVP-validated Approved key generation and key
establishment functions are used for all protocols including TLS, HTTPS, IKE/IPsec,
and SSH.
While the TOE generally fulfills all of the FIPS PUB 186-4 requirements without
extensions, the following table specifically identifies the “should”, “should not”, and
“shall not” conditions from the publication along with an indication of whether the
Page 60 of 84
TOE conforms to those conditions with deviations rationalized. Key generation is
among the identified sections.
Table 8 FIPS 186-4 Conformance
FIPS PUB 186-4
“should”, “should not”, or
“shall not”
Implemented
accordingly?
Rationale for
deviation
FIPS PUB 186-4
Appendix B.1
B.1.1 should Yes N/A
B.1.2 should Yes N/A
FIPS PUB 186-4
Appendix B.3
B.3.1 shall not Yes N/A
FIPS PUB 186-4
Appendix B.4
B.4.1 should Yes N/A
B.4.2 should Yes N/A
The TOE performs cryptographic RSA-based key establishment6
in accordance with
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”,
NIST Special Publication 800-56A for elliptic curve-based key establishment 7
schemes, and NIST Special Publication 800-56A for finite field-based key
establishment8
schemes. The TOE acts as both a sender and as a recipient for all
supported key establishment schemes (ECC, FFC, DH Group14), and just a sender for
RSA key establishment scheme. The TOE does not reveal specific details about an
error (e.g., decryption error) for RSA-based key establishment schemes. For TLS, the
domain parameters used for the finite field-based key establishment scheme are
compliance with FIPS 186-4. For SSH and IKE, the TOE uses safe primes as defined
by RFC 35269
section 3 key establishment scheme (when Diffie-Hellman Group 14 is
used). Per SP 800-56Ar3, only the safe primes (e.g., MODP-2048) defined in Sections
3 of RFC 3526 can be used. NOTE: RFC 7919 (FFDHE) is not supported.
The claimed key generation and key establishment algorithms used for each function
is summarized below.
FCS_CKM.1:
- X.509 key pair generation: ECDSA (256, 384), RSA (2048, 3072, 4096)
- SSH RSA key pair generation: RSA (2048, 3072, 4096)
- SSH: FFC DH Group 14, ECDSA (256, 384, 521)
- TLS: ECDSA (256, 384, 521), FFC (2048)
- IPsec: FFC DH Group 14, ECDSA (256, 384)
FCS_CKM.2:
6
RSA-based key generation and establishment are used for TLS only (connection to the syslog server only)
7
Elliptic curve-based key generation and establishment are used for HTTPS, TLS, SSH, and IKE connections.
8
Finite field-based key generation and establishment are used for HTTPS and TLS connections.
9
Diffie-Hellman Group 14 with safe primes based on RFC 3526 and SP 800-56Ar3 are used for SSH and IKE
connections.
Page 61 of 84
- SSH: FFC DH Group 14, ECC (256, 384, 521)
- TLS: ECC (256, 384, 521), FFC (2048)
- IPsec: FFC DH Group 14, ECC (256, 384)
The SHA-1/SHA-2 hash function is associated with the digital signature
generation/verification and corresponding HMAC functions.
FCS_CKM.4
Table 9 Private Keys and CSPs
CSP
#
CSP/Key Name Type Description
1
RSA Private Keys RSA RSA Private keys for verification
of signatures, authentication or
key establishment.
(RSA 2048, 3072, or 4096-bit)
2
ECDSA Private
Keys
ECDSA ECDSA Private key for
verification of signatures and
authentication
(P-256, P-384, P-521)
3
TLS Pre-Master
Secret
TLS
Secret
Secret value used to derive the
TLS session keys
4
TLS DHE/ECDHE
Private
Components
DH Diffie-Hellman private FFC or EC
component used in TLS
(DHE 2048, ECDHE P-256, P-
384, P-521)
5
TLS HMAC Keys HMAC TLS integrity and authentication
session keys (HMAC-SHA-1,
HMAC-SHA2-256, HMAC-SHA2-
512)
6
TLS Encryption
Keys
AES TLS encryption session keys
(128 and 256 CBC or GCM)
7
SSH Session
Integrity Keys
HMAC Used in all SSH connections to
the security module’s command
line interface.
(HMAC-SHA-1, HMAC-SHA2-
256, HMAC-SHA2-512)
8
SSH Session
Encryption Keys
AES Used in all SSH connections to
the security module’s command
line interface.
(128 and 256 bits in CBC and
CTR, or 128 and 256 bits in GCM)
9
SSH DH Private
Components
DH Diffie Hellman private component
used in key establishment (DH
2048)
Page 62 of 84
10 S-S VPN IPsec/IKE
authentication
Keys
HMAC (SHA-1, SHA-256, SHA-384 or
SHA- 512) Used to authenticate
the peer in an IKE/IPsec tunnel
connection.
11 S-S VPN IPsec/IKE
session Keys
AES Used to encrypt IKE/IPsec data.
These are AES (128, 192, and 256
CBC) IKE keys and (128, 192, and
256 CBC, 128 CCM, 128 and 256
GCM) IPsec keys
12 S-S VPN IPsec/IKE
Diffie Hellman
Private
Components
DH Diffie-Hellman (Group 14, 19 and
20) private component used in
key establishment
13 RA VPN IPsec
session Keys
AES (128 CBC, 128 and 256 GCM)
Used to encrypt remote access
sessions utilizing IPsec.
14 RA VPN IPsec
authentication
HMAC
HMAC (SHA-1) Used in authentication of
remote access IPsec data.
15
Firmware code
integrity check
HMAC
ECDSA
Used to check the integrity of
crypto-related code. (HMAC-
SHA-256 and ECDSA P-256)
16
Firmware Content
Encryption Key
AES-256 Used to encrypt/decrypt
firmware, software, and sensitive
content.
17
Password Password Authentication string with a
minimum length of 6 characters.
18
DRBG Seed /State DRBG AES 256 CTR DRBG used in the
generation of a random values.
The TOE performs a key error detection check on each internal, intermediate
transfer of a key. The TOE stores persistent secret and private keys in encrypted
form (AES encrypted) when not in use. The KEK is the Firmware Content Encryption
Key (also known as the Master Key). The KEK is not stored encrypted but is
protected using Cryptod (Palo Alto Networks proprietary keys storage module) and
destroyed by the TOE’s overwriting method. The TOE zeroizes (i.e., overwrite) non-
persistent cryptographic keys as soon as their associated session has terminated. In
addition, the TOE recognizes when a private key expires and promptly zeroizes the
key on expiration. The TOE does not permit expired private signature keys to be
archived.
Page 63 of 84
Private cryptographic keys, plaintext cryptographic keys, and all other critical security
parameters stored in intermediate locations for the purposes of transferring the
key/critical security parameters (CSPs) to another location are zeroized immediately
following the transfer. Zeroization is done by overwriting the storage location with a
random pattern, followed by a read-verify. Note that plaintext cryptographic keys and
CSPs are only ever stored in volatile memory. For non-volatile memories other than
EEPROM and Flash, the zeroization is executed by overwriting three times using a
different alternating data pattern each time. This includes the SSD storage. This
includes all CSPs that are not stored in volatile memory such as private keys, hashed
passwords, and entropy seeds. The old KEK is overwritten when a new KEK is
generated.
For volatile memory and non-volatile EEPROM and Flash memories, the zeroization
is executed by a single direct overwrite consisting of a pseudo random pattern
generated by Approved DRBG. Sensitive data in volatile memory includes session
keys such as encryption keys, integrity keys, pre-Master secret, etc.
FCS_HTTPS_EXT.1(1
)
FCS_HTTPS_EXT.1(2
)
FCS_TLSC_EXT.1
FCS_TLSC_EXT.2
FCS_TLSS_EXT.1
FCS_TLSS_EXT.2
The TOE can be configured as a TLS server for mutual certificate-based
authentication for secure connections. To enable certificate-based authentication,
the TOE must be configured to use a client certificate profile using the Device >
Certificate Management > Certificate Profile tab. The TOE uses TLS service profiles
to specify a certificate and the allowed protocol versions for TLS services. The TOE
(as a TLS client) uses TLSv1.2 to initiate a TLS connection to external syslog server.
The TOE (as TLS server) receives inbound remote administration TLS traffic on the
management (MGT) interface from TLS client (e.g., web browser). The key
agreement parameters of the server key exchange message consist of the key
establishment parameters generated by the TOE: Diffie-Hellman Ephemeral
parameters with key size of 2048 bits, ECDHE implementing NIST curves
secp256r1 and secp384r1. The TOE supports session resumption using session
tickets for a single context (no configuration needed). The TOE checks if session
tickets expire which would trigger a full handshake. The session tickets are
encrypted with AES encryption and 128-bits encryption key plus 256-bits HMAC-
SHA-256 key; and adhered to the structural format provided in section 4 of RFC
5077. Fallback password-based authentication is not supported for this interface.
The TOE denies connections from clients requesting connections using SSL 2.0, SSL
3.0, or TLS 1.0 and shall not establish a trusted channel if the fully qualified
distinguished name (FQDN) in the subject or Subject Alternative Name (SAN) field
contained in a certificate does not match the expected identifier for the peer. The
TOE will match the FQDN identifier according to RFC 6125.
The TOE can be configured as a TLS server to permit inbound remote administration
traffic (HTTPS) in which the client (e.g., web browser) initiates handshake and
performs server authentication via server certificate. If mutual authentication is
configured, the client must present a valid client certificate and the TOE must validate
the client certificate, or the HTTPS connection will fail. The TOE’s HTTPS protocol
complies with RFC 2818 and is implemented using TLS 1.2 (RFC 5246) and TLS 1.1
(RFC 4346). The key agreement parameters of the server key exchange message
consist of the key establishment parameters generated by the TOE: Diffie-Hellman
Ephemeral parameters with key size 2048 bits, ECDHE implementing NIST curves
secp256r1 and secp521r1. The TOE denies connections from clients requesting
connections using SSL 2.0, SSL 3.0, or TLS 1.0 by default.
The TOE can be configured as a TLS client for secure communication to an external
audit server. The TOE presents the Supported Elliptic Curves/Supported Groups
Extension in the Client Hello with the secp256r1, secp384r1, and secp521r1 NIST
curves and is configured when FIPS-CC mode is enabled. The TOE verifies that the
Page 64 of 84
presented identifier matches the reference identifier according to RFC 6125 and only
establishes a trusted channel if the peer certificate is valid (no override mechanism).
The TOE compares the external server’s presented identifier to the reference
identifier by matching the certificate FQDN (hostname) or IPv4 address in the SAN
field or CN (of subject Field) of the server certificate. The SAN is checked first and if
there is any match, the connection is allowed. The TOE supports IPv4 address
reference identifiers and wildcards (for FQDN only) for peer authentication. The only
supported IP address format for IPv4 is specified in RFC 3986. The CN field is
composed of IPv4 addresses that follow the rules described in RFC 3986. All
networking addresses are in big-endian order, when converting between types, all
strings will convert to the machine byte order (little endian or big-endian) and in the
case of little endian, it is flipped to big-endian and then compared. Certificate pinning
is not supported but mutual authentication is supported.
The TOE implements TLS 1.2 (RFC 5246) and TLS 1.1 (RFC 4346).
TOE (as TLS client) to syslog server (same ciphersuites for mutual authentication, if
configured). Support TLSv1.2 only and RSA, DHE (finite-field based), and ECDHE
(elliptic curve-based) schemes.
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
• TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246
• TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC
5289
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC
5289
TOE (as TLS server) for the Web UI management and GlobalProtect (GP) connections
(same ciphersuites for mutual authentication if configured). Supports TLSv1.1 or
TLSv1.2, and DHE (finite-field based), and ECDHE (elliptic curve-based) schemes.
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC
4492
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC
4492
Page 65 of 84
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC
5289
FCS_SSHS_EXT.1 The TOE supports SSHv2 (compliant to RFCs 4251, 4252, 4253, 4254, 4344, 5647,
6668) with AES encryption/decryption algorithm (in CBC, CTR, or GCM mode) with
key sizes of 128 and 256 bits. No optional characteristics are supported. The TOE
also supports HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512, implicit MAC
(aes128-gcm@openssh.com and aes256-gcm@openssh.com) for integrity and
authenticity. Both encryption and integrity algorithms are administrator-configurable
and while 3DES, HMAC-MD5, diffie-hellman-group-1 are also supported, they are all
disabled when FIPS-CC mode is enabled. Only the Approved encryption and integrity
algorithms along with key exchange algorithms diffie-hellman-group14-sha1 (based
on RFC 3526 Section 3), ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-
nistp521 (based on elliptic curve from FCS_CKM.2) and authentication public-key
algorithm ssh-rsa are permitted in the evaluated configuration. If the SSH client (in
the operational environment) only support non-Approved algorithms, the SSH
connection will be rejected by the TOE.
The TOE uses Palo Alto Networks Crypto Module implementation to support the
SSHv2 connections. The password authentication timeout period is 60 seconds
allowing clients to retry only 4 times. In addition, both public-key (RSA) and password-
based authentication can be configured with password-based being the default
method. For password, the TOE verifies the user identity when the username is
entered. For public-key, the administrator must associate the public key to the user.
SSH packets are limited to 256 Kbytes and any packet over that size will be dropped
(i.e., not processed farther and buffer containing the packet will be freed). The TOE
manages a tracking mechanism for each SSH session so that it can initiate a new key
exchange (rekey) when either a configurable amount of data (10 – 4000 MBs) or time
(10 – 3600 seconds) has passed, whichever threshold occurs first. In the evaluated
configuration, the administrator should not configure the SSH data rekey threshold
to be more than 1024 MBs.
FCS_IPSEC_EXT.1
FCS_CKM.1/IKE
The TOE provides mechanisms to implement an IPsec Security Policy Database (SPD)
in tunnel mode and to process packets to satisfy the behavior of DISCARD, BYPASS
and PROTECT packet processing as described in RFC 4301. This is achieved through
the administrator configuring appropriately specified access control lists (ACLs). The
ACLs consist of policy rules and profiles. The TOE compares packets in turn against
each rule in the Security ACL to determine if the packet matches the rule. Packets
can be matched based on protocol (e.g., TCP, UDP), source IP address and destination
IP address. The first rule that matches the traffic is applied. If a policy rule matching
the traffic attributes is not found, or if it is found and it specifies a deny action, then
the packet is dropped (or DISCARDed) and the session is deleted. If the application
flow is allowed and no further security profiles are applied then it is forwarded (it is
allowed to BYPASS the tunnel). If the application is allowed and there are additional
Page 66 of 84
security profiles set, it will be sent to the stream signature processor. The traffic
matching the IPsec crypto Security profile would then flow through the IPsec tunnel
and be classified as “PROTECTED”. If there is no SA that the IPsec can use to protect
this traffic to the peer, IPsec uses IKE to negotiate with the remote peer to set up the
necessary IPsec SAs on behalf of the data flow. The negotiation uses information
specified in the IKE Network Profiles. If the TOE receives a packet that does not
match any rules in the SPD the TOE discards the packet. By default, the TOE is
configured to allow all intrazone (within the zone) traffic and deny all interzone
(between zones) traffic. Typically, intrazone traffic is considered to be trusted;
however, both intrazone and interzone traffic can be configured to deny all traffic if
there is no rule match by clicking on the security policy and clicking on the Override
button on the bottom on the Policy > Security screen. In the evaluated configuration,
the default deny all rule for interzone traffic should not be modified.
The TOE uses route-based VPNs where the firewall makes a routing decision based
on the destination IP address. It is not necessary to define special rules or to make
explicit reference to a VPN tunnel; routing and encryption decisions are determined
only by the destination IP address. Packets matching the destination IP address are
permitted otherwise they are denied. The TOE also supports Network Address
Translation (NAT) policies (as defined in RFC 5996) where policies can be defined to
specify whether source or destination IP addresses and ports are converted between
public and private addresses and ports. For example, private source addresses can be
translated to public addresses on traffic sent from an internal (trusted) zone to a public
(untrusted) zone. NAT policy rules are based on the source and destination zones, the
source and destination addresses, and the application service. The NAT policy rules
are compared against the incoming traffic in sequence; the first rule that matches the
incoming traffic is applied. If no rules match, then the flow is denied.
IKEv2 SA lifetime limits can be configured by an authorized administrator and can be
limited to 24 hours for phase 1 (range: 1 to 8760 hours) and 8 hours (range: 1 to 8760
hours) for phase 2 SAs. IKEv1 SA lifetime is configurable as well and the range of time
value is same as for IKEv2. Both IKEv1 and IKEv2 SA phase 2 lifetime limits can be
established based on number of bytes.
The IKEv1 (as defined in RFCs 2407, 2408, 2409, 4109, 4304) and IKEv2 (as defined
in RFCs 5996 and 4868) protocols implemented by the TOE include DH Group 14
(2048-bit MODP), DH Groups 19 (256-bit Random ECP), and 20 (384-bit Random
ECP), using RSA and ECDSA peer X.509v3 certificate authentication conforming to
RFC4945. The DH Group 14 is based on RFC 3526 section 3 and ECP is based on
elliptic curve in FCS_CKM.2. IKE keys used as part of the establishment are generated
according to FIPS 186-4. In the IKEv1 phase 1 (main mode only) and phase 2
exchanges, the TOE and peer will agree on the strongest DH group both can support.
For IKEv1, aggressive mode is disabled by default. When the TOE initiates IKE
negotiation, the DH group is sent in order according to the peer’s configuration.
When the TOE receives an IKE proposal, it will select the first match and the
negotiation will fail if there is no match. During IKEv1 phase 1 authentication is based
on a verifiable signature as described in RFC2409. In addition, the TSF will only
establish an IKE channel if the presented identifier in the peer X.509v3 certificate CN
(Common Name) field matches the configured identifier: Distinguished Name (DN),
IP address, or Fully Qualified Domain Name (FQDN).
The keys are generated using the AES-CTR Deterministic Random Bit Generator
(DRBG), as specified in ISO/IEC 18031:2011, and the following corresponding key
sizes (in bits) are used: 224 (for DH Group 14), 256 (for DH Group 19), 384 (for DH
Group 20) bits.
Page 67 of 84
The nonces used in the IKE exchanges are generated at least 128 bits in size and at
least half the output size of the PRF hash. The TSF generates the nonces of length at
least 128 (for DH Group 14), 128 (for DH Group 19), and 192 (for DH Group 20) bits
and are generated with the Approved DRBG. The TSF generates the secret value x
used in the IKE Diffie-Hellman key exchange (“x” in gx
mod p) using the random bit
generator specified in FCS_RBG_EXT.1 and having a length of at least 224 (for DH
Group 14), 256 (for DH Group 19), and 384 (for DH Group 20) bits.
The TOE provides AES-CBC-128, AES-CBC-192, and AES-CBC-256 for encrypting
IKEv1 and IKEv2 payloads. The TOE provides AES-CBC-128, AES-CBC-192, AES-
CBC-256, AES-GCM-128 and AES-GCM-256 for encrypting IPsec payloads. The
administrator is instructed to ensure that the size of key used for ESP must be less
than or equal to the key size used to protect the IKE payload. Once configured, the
TSF will check that the symmetric key size used in the IKE is greater than or equal to
the symmetric key size used in the ESP. The TOE implementation of IPsec protocol
ESP complies with RFC 4303 using the algorithms specified in FCS_IPSEC_EXT.1.4
together with the HMAC specified in FCS_IPSEC_EXT.1.4. SHA-based HMAC
function truncated output is not used.
6.3 User Data Protection
FDP_RIP.2 The TOE allocates and releases (i.e., deallocates) the memory resources used for
network packet objects. When it receives new data from the network and allocates
new buffer resources to store and transmit data to the network, it ensures that the
new buffers are not padded out with previously transmitted or otherwise residual
information by overwriting unused parts of the buffer with 0s.
6.4 Identification and Authentication
FIA_UIA_EXT.1
FIA_UAU_EXT.2
FIA_UAU.7
The TOE is designed to require users to be identified and authenticated before they
can access any of the TOE functions. The only capabilities allowed prior to users
authenticating are the display of the informative (login) banner and responding to
ICMP request (e.g., ping or ICMP echo reply).
The TOE maintains user accounts which it uses to control access to the TOE. When
creating a new user account, the administrator specifies a username (i.e., user identity
or ID), a password or X.509v3 certificate10
/public-key/common access card, and a
role. To enable client certificate-based authentication (i.e., mutual authentication),
the TOE must be configured to use a client certificate profile using the Device >
Certificate Management > Certificate Profile tab. When a client certificate profile is
enabled, each administrator must use a client certificate for access to the TOE via
TLS. The client certificate must identify the domain name (in this case, the username)
in the SAN (first) or CN (second if SAN is not present). The TOE will match the
10
X.509 certificate is only supported for the UI. It is not supported for SSH or API.
Page 68 of 84
presented username to the username in the local database and associated role. Only
one role is specified in the user account per user.
The TOE uses the username and password (i.e., API key for API) attributes to identify
and authenticate the user when the user logs in via the GUI, API, or CLI. With public
key-based authentication, a digital signature is exchanged and verified, in lieu of a
password. The TOE does not echo passwords as they are entered, and the private
keys are never transmitted. For CLI or UI, the default authentication method is
password. API authentication supports API key which is the password encrypted. The
administrators must configure public-key authentication which is supported for both
SSH and HTTPS sessions. It uses the role attribute to specify user permissions and
control what the user can do with the GUI, API, or CLI.
The administrator can logon to the GUI/API by using a secure connection (HTTPS,
HTTPS over IPsec) from a web browser or to CLI by using a secure connection
(SSHv2) from a SSH client. The TOE provides access to the GUI/API/CLI locally via
direct RJ-45 Ethernet cable connection using HTTPS and SSH, and remotely using
HTTPS/TLS/IPsec or SSHv2. The administrator enters the IP address or hostname of
the TOE and their username and password. Optionally for GUI only, the TOE also can
be configured to require a client certificate (mutual authentication) and additionally
require the username, possession of the CAC, and knowledge of the private key (i.e.,
2-factor authentication). The credentials may be supplied by a CAC or retrieved from
the client computer.
Regardless of whether a user logs in using an HTTPS or SSH connection, a logon is
successful when the username and password provided by the user matches a defined
account on the TOE or when the username and digital signature is verified by the
TOE (e.g., verify the possession of a private key that corresponds to the public key
defined for that user account).
FIA_PMG_EXT.1 Passwords can be composed of upper and lower case letters, numbers and special
characters (“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(”, “)”, “'”, “+”, “,”, “-”, “.”, “/”, “:”, “;”, “<”,
“=”, “>”, “[”, “\”, “]”, “_”, “`”, “{”, “}”, and “~”). For the default Admin only, the password
must be composed of at least one lower case, one upper case, and one number or
special character. The minimum password length is configurable by the administrator
from 8 up to 15 characters. Note in FIPS-CC mode, the minimum password length
cannot be configured below 8. The maximum password length is 31 characters. For
example, if the administrator configures the minimum password length as 15, you can
only create passwords from length of 15 to 31.
FIA_AFL.1 The TOE logs all unsuccessful authentication attempts in the System Log and tracks
the number of failed attempts via internal counters. The TOE can be configured to
lock a user or authorized IT entity out after a configurable number (1 – 10) of
unsuccessful authentication attempts. The lock can be configured to last a specified
amount of time (1 – 60 minutes) during which providing the correct credentials will
still not allow access (i.e., locked out), or until an administrator logs in to unlock the
locked user. A setting of “0” will lock out the user indefinitely. In this case, the
Administrator must unlock the locked user. These settings can be configured for both
HTTPS/TLS and SSH remote administration connections but applies to password
authentication only. Public-key authentication is not vulnerable to weak passwords
that can be brute-forced. It’s required that at least one administrator, preferably the
Superuser role (predefined ‘admin’ account), is configured with public-key
authentication for SSH. In the rare situation where all administrators (customer
created) are locked out at the same time, the Superuser role (predefined ‘admin’
Page 69 of 84
account) with public-key authentication can be used to login. In addition, the user can
also wait until the lockout time expires.
FIA_X509_EXT.1/Rev The TOE uses X.509v3 certificates as defined by RFC 5280 to support authentication
for TLS (server authentication and mutual authentication), IKE/IPsec, and HTTPS
connections. Public key infrastructure (PKI) credentials, such as RSA keys and
certificates are stored in the TOE’s underlying file system on the appliance.
Certificates and their associated private key are stored in a single container: the
Certificate File. The PKCS#12 file consists of an Encrypted Private Key and X.509
Certificate. By default, all the private keys are protected since they are always stored
in encrypted format using AES-256. The physical security of the appliance
(A.PHYSICAL_PROTECTION) protects the appliance and the certificates from being
tampered with or deleted. In addition, the TOE identification and authentication
security functions protect an unauthorized user from gaining access to the TOE.
Revocation checking is performed on the TLS and IPsec peer certificates presented
to the TOE. For IPsec, the TOE supports both Online Certificate Status Protocol
(OCSP) and Certificate Revocation List (CRL) status verification for certificate profiles.
If both are configured, the TOE first tries the OCSP method; if the OCSP server is
unavailable, the TOE uses the CRL method. For TLS, the TOE only supports CRL.
The TOE uses the following rules for validating the extendedKeyUsage11
field:
• 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.
• 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.
• 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.
The TOE validates a certificate path by ensuring the presence of the basicConstraints
extension is present and the cA flag is set to TRUE for all CA certificates. The TOE
forms a Certificate trust path by ensuring that the basic constraints are met, proper
key usage parameters exist, the CA flag exists, performing a revocation check of each
certificate in the path and performing the validity of the CA certificate. The TOE will
not treat a certificate as a CA certificate if the basicConstraints extension is not
present or the cA flag is not set to TRUE. The TOE supports certificate path validation
for a minimum path length of three certificates and terminates with a trusted CA
certificate (i.e., Root certificate).
The TOE downloads and caches OCSP status information for every CA listed in the
trusted CA list of the TOE. The OCSP status is cached for the ‘next update time’ that
is configured on the OCSP responder. The TOE uses this received value as the cache
time. OCSP responders can also be configured for other external devices if someone
decides to use it. The TOE uses a hard coded 1 hour as next update time (cached
time) in this case. Caching only applies to validated certificates; if a TOE never
validated a certificate, the TOE cache does not store the OCSP information for the
issuing CA. To use OCSP for verifying the revocation status of certificates, you must
configure the TOE to access an OCSP responder (server). The entity that manages
the OCSP responder can be a third-party certificate authority (CA) or, if your
enterprise has its own PKI, the TOE itself.
The TOE downloads and caches the last-issued CRL for every CA listed in the trusted
CA list of the TOE. The signature on the CRL is verified as defined in RFCs 5280 and
FIA_X509_EXT.2
11
Certificates are not used for trusted updates or executable code integrity.
Page 70 of 84
5759 (supporting strong Suite B ECDSA algorithms and curve sizes for signing CRL).
Caching only applies to validated certificates; if a TOE never validated a certificate,
the TOE cache does not store the CRL for the issuing CA. Also, the cache only stores
a CRL until it expires. The TOE supports CRLs only in Distinguished Encoding Rules
(DER) or PEM format.
When the certificate status is unknown or cannot be determined, the TLS session is
blocked. This is the default behavior for syslog connection and cannot be changed.
For the HTTPS management session (if mutual authentication is configured) and
IKE/IPsec connection to another firewall (VPN gateway), this behavior is configurable
but in the evaluated configuration, the required action is to block the TLS session.
This is not done by default. To configure this option, create a Certificate Profile and
check the “Block session if certificate status cannot be retrieved within timeout”
checkbox.
FIA_X509_EXT.3 The authorized administrator may generate a certificate request as specified in RFC
2986 and provide the following information in the request: public key, Common
Name, Organization, Organizational Unit, and Country. The administrator may also
import a certificate and private key into the TOE from an enterprise certificate
authority or obtain a certificate from an external CA. The TOE provides the ability for
administrators to generate a Certificate Signing Request (CSR) with a multi-level
organizational unit. When the administrators import a certificate based on the CSR,
the TOE will validate the certificate chain is based on a trusted CA which must be
present on the TOE. Otherwise, the TOE will reject the certificate and will not
associate it with the CSR.
6.5 Security Management
FMT_MOF.1/ManualUpdate
FMT_MOF.1/Services
FMT_MTD.1/CoreData
FMT_MTD.1/CryptoKeys
The TOE provides a GUI or API management interface, and CLI to support
security management of the TOE. The GUI or API is accessible via direct
connection to the management port on the device (local access), or remotely
over HTTPS or HTTPS tunneled over IPsec. The CLI is accessible via direct
connection to the management port on the device (local access), or remotely
over SSHv2. The restricted role-based privileges enable only authorized
administrators to configure the TOE functions such as updating the TOE and
manipulating TSF data. For examples, the ability to manage the TOE’s trust
store, enable or disable of start/stop services (e.g., DNS via Device > Setup >
Services > DNS Servers, SNMP via Device > Setup > Operations > SNMP Setup),
configure audit behavior, and VPN keys/certificates are restricted to Security
Administrators only. The Security Administrators can generate RSA and ECDSA
keypair (public key embedded in certificate), import private key and certificate,
and delete keys. The key management operations can be performed via the
Web UI or by CLI/API command. The users must be identified and
authenticated by the TOE prior to any access to the management functions
(including those that manipulate the TSF data).
FMT_SMF.1
FMT_SMF.1/FFW
FMT_SMF.1/VPN
The security management functions provided by the TOE include, but are not
limited to:
• Ability to administer the TOE locally and remotely;
• Ability to configure the access banner;
Page 71 of 84
• Ability to configure the session inactivity time before session
termination or locking;
• Ability to update the TOE, and to verify the updates using digital
signature capability prior to installing those updates;
• Ability to configure the authentication failure parameters for
FIA_AFL.1;
• Ability to configure the list of TOE-provided services available before
an entity is identified and authenticated, as specified in FIA_UIA_EXT.1;
• Ability to configure the cryptographic functionality;
• Ability to configure thresholds for SSH rekeying;
• Ability to re-enable an Administrator account;
• Ability to set the time which is used for time-stamps;
• Ability to import X.509v3 certificates to the TOE’s trust store;
• Ability to manage the TOE’s trust store and designate X509v3
certificates as trust anchor;
• Ability to configure firewall rules;
• Ability to configure the lifetime for IPsec SAs;
• Ability to configure the reference identifier for the peer;
• Ability to enable, disable, determine and modify the behavior of all the
security functions of the TOE identified in the VPNGW Module to the
Administrator;
• Ability to configure all security management functions identified in
other sections of the VPNGW Module;
• Ability to configure the IPsec functionality;
• Ability to import X.509v3 certificates;
• Ability to configure audit behavior (e.g. changes to storage locations for
audit; changes to behaviour when local audit storage space is full);
• Ability to start and stop services;
• Ability to manage the trusted public keys database;
• Definition of packet filtering rules;
• Association of packet filtering rules to network interfaces;
• Ordering of packet filtering rules by priority.
The GUI, CLI, and API (XML and REST) provide the same supported
management functionality. All management functions above are available from
any of these interfaces. The local interface supports the use of a dedicated
Ethernet port that only supports HTTPS, HTTPS over IPsec, and SSH
communications with a whitelisted local IP address.
FMT_SMR.2 The TOE controls user access to commands and resources based on user role.
Users are given permission to access a set of commands and resources based
on their user role. By default, the TOE has the following pre-defined
administrator roles: Superuser, Superuser (Read-Only), and Device
Page 72 of 84
Administrator. These administrator roles (except Read-Only) are all considered
Security Administrator as defined in the Error! Reference source not found. for t
he purposes of this ST. For example, a user with Superuser role can create,
modify, or delete user accounts but user with Read-Only role cannot. All roles
(including Security Administrator as defined in the NDcPP) can administer the
TOE both locally and remotely via CLI or Web UI, and a user account can only
be assigned one role at a time.
• Superuser—Full read-write access to TOE and all device groups,
templates, and managed firewalls including user and role management
(create, modify, delete).
• Superuser (Read-Only)—Read-only access to TOE and all device
groups, templates, and managed firewalls.
• Device Administrator—Full access to TOE except for the create,
modify, or delete administrators or roles.
The Security Administrator role shall be able to administer the TOE locally; and
the Security Administrator role shall be able to administer the TOE remotely.
6.6 Protection of the TSF
FPT_SKP_EXT.1 Certificates and their associated private key are stored in a single container: the
Certificate File. The PKCS#12 file consists of an Encrypted Private Key and X.509
Certificate. By default, all the private keys are protected since they are always stored
in encrypted format using AES-256. The TOE prevents the reading of all keys by
encrypting them with a Master Key using AES-256. The TOE does not provide an
interface to read the Master Key. The TOE is designed specifically to prevent access to
locally-stored cryptographically protected passwords and does not disclose any keys
stored in the TOE. The TOE protects the confidentiality of user passwords by hashing
the passwords using SHA-256. The TOE does not offer any functions that will disclose
to any users a stored cryptographic key or password.
FPT_APW_EXT.1
FPT_FLS.1/SelfTest
FPT_TST_EXT.1
FPT_TST_EXT.3
The TOE meets FPT_TST_EXT requirements and therefore provides self-tests at start-
up to demonstrate the correct operation of: key error detection, cryptographic
algorithms, and DRBG. The self-tests also verify the integrity of stored TSF executable
code and TSF data. The TOE performs the following Power-on self-tests:
• AES Encrypt Known Answer Test
• AES Decrypt Known Answer Test
• AES GCM Encrypt Known Answer Test
• AES GCM Decrypt Known Answer Test
• AES CCM Encrypt Known Answer Test
• AES CCM Decrypt Known Answer Test
• RSA Sign Known Answer Test
• RSA Verify Known Answer Test
• RSA Encrypt/Decrypt Known Answer Test
• ECDSA Sign Known Answer Test
• ECDSA Verify Known Answer Test
• HMAC-SHA-1 Known Answer Test
• HMAC-SHA-256 Known Answer Test
• HMAC-SHA-384 Known Answer Test
• HMAC-SHA-512 Known Answer Test
Page 73 of 84
• SHA-1 Known Answer Test
• SHA-256 Known Answer Test
• SHA-384 Known Answer Test
• SHA-512 Known Answer Test
• DRBG SP800-90A Known Answer Tests
• SP 800-90A Section 11.3 Health Tests
• DH Known Answer Test
• ECDH Known Answer Test
• SP 800-135 KDF Known Answer Tests
• Firmware Integrity Test – verified with HMAC-SHA-256 and ECDSA P-256. If
the calculated result does not equal the previously generated result, the
software/firmware test shall fail.
A known-answer test involves operating the cryptographic algorithm on data for which
the correct output is already known and comparing the calculated output with the
previously generated output (the known answer). If the calculated output does not
equal the known answer, the known-answer test shall fail.
If a self-test (e.g., Known Answer Test, Entropy Health Tests, Firmware Integrity Test
using ECDSA as defined in FCS_COP.1/SigGen) fails, the TOE enters an error state and
outputs an error indicator. The TOE doesn’t perform any cryptographic operations or
functions while in the error state. All data output from the TOE is inhibited when an
error state exists. Should one or more power-up self-tests fail the module will reboot
and enter maintenance mode (i.e., error state) in which the reason for the failure can
be determined. In the maintenance mode, all operational and network functions will be
unavailable with one exception which is the Reboot operation.
These self-tests are sufficient to ensure correct functionality of the TSF because the
self-tests encompass the cryptographic functionality and the integrity of the entire
TOE software/firmware executable code.
FPT_TUD_EXT.1 Authorized administrators may query the current software/firmware version of the
TOE.
• CLI: command ‘show system info | match sw-version’,
• UI: Dashboard > General Information,
• API:
When updates are installed, the TOE need to be rebooted for the change to take place
(no delayed activation). When updates are available from Palo Alto, an administrator
can obtain and install those updates from updates.paloaltonetworks.com if there is an
internet connection. For an additional layer of protection, Palo Alto Networks has
chosen to sign (using RSA-2048) all content that is downloaded to the TOE. If the TOE
is not connected to the internet, the administrators can download the updates and
upload it to the TOE.
When the TOE update package and its corresponding digital signature is downloaded
or uploaded; the digital signature is checked automatically by TOE by verifying the
signature using the public key (corresponding to the RSA key used to create the
signature). Palo Alto Networks manages the updates.paloaltonetworks.com and
guarantees that images are digitally signed. Public keys are stored and protected on the
TOE’s file system. If the signature is verified, the update is performed; otherwise, the
update is not performed.
FPT_STM_EXT.1 The TOE is a hardware appliance, or a virtual appliance image installed on a
virtualization platform that includes a hardware-based real-time clock. The clock is
Page 74 of 84
based on a quartz crystal running at high frequency and accuracy. The hardware
hosting the VM-Series provides the time clock, as well as CPU, ports, etc., which are
provided by VM hypervisor. The TOE’s embedded OS manages the clock and exposes
administrator clock-related functions such as set time. The clock is used for audit
record time stamps, measuring session activity for termination, administrator lockout,
SSH/IPsec session rekeying, and X.509 certificate validation.
6.7 TOE Access
FTA_SSL_EXT.1 The TOE subsequently will enforce an administrator-defined inactivity timeout value
after which the inactive, local or remote, session will be terminated regardless of
authentication methods (e.g., password, public-key, X.509v3 certificate). The TOE can
be configured by an administrator to set an interactive session timeout value (any
integer value from 1 to 1,440 minutes with default set to 60 minutes). The function is
enabled by default and the administrator must follow the CC AGD to configure the
session idle timeout value. A remote session that is inactive (i.e., no commands issuing
from the remote client) for the defined timeout value will be terminated. A local session
that is similarly inactive for the defined timeout period will be terminated. The users will
be required to re-enter their user ID and their password or perform public-key or
certificate-based authentication, so they can establish a new session once a session is
terminated. Users can also initiate termination of their own sessions. They can click on
the “Logout” link or enter the “exit” command.
FTA_SSL.3
FTA_SSL.4 The TOE provides both local and remote administrators the ability to logout (or
terminate) their sessions as directed by the user.
FTA_TAB.1 The TOE can be configured to display an informative banner that will appear prior to
authentication when accessing the TOE via either a direct or remote connection to the
management port in order to access the Web Interface (HTTPS) or CLI (SSH).
6.8 Trusted Path/Channels
FTP_ITC.1
FTP_ITC.1/VPN
The TOE can be configured to send audit records to external syslog server(s) using TLS
or IPsec in real-time. The TOE permits the TSF to initiate communication with the syslog
server using TLS trusted channel. Mutual authentication is supported but must be
configured for all TLS channels. The TOE permits the following communications below:
• Connecting with remote VPN gateways/peers using IPsec [TOE is peer],
• Connecting with GlobalProtect (VPN peer) using TLS [TOE is server],
• Transmitting audit records to an audit server using IPsec or TLS [TOE is client],
The TOE communicates with its authorized trusted entities over TLS or IPsec, and all
communication are sent over the trusted channel and are protected by the security
protocols. The underlying cryptographic algorithms and implementation are CAVP-
validated and are part of the TOE.
Page 75 of 84
FTP_TRP.1/Admin The TOE provides SSH, HTTPS (TLSv1.1 and TLSv1.2), and IPsec12
to support secure
remote administration. Administrators can initiate a remote session that is secured (from
disclosure and modification) using CAVP-validated cryptographic operations, and all
remote security management functions require the use of a secure channel. In FIPS-CC
mode, telnet and HTTP are permanently disabled.
6.9 Stateful Traffic Filtering
FFW_RUL_EXT.1
FFW_RUL_EXT.2
An authorized administrator may configure the TOE to apply stateful traffic filtering rules
with actions permit with logging or drop with logging on the following protocols:
• Internet Control Message Protocol version 4 (ICMPv4)
• Internet Control Message Protocol version 6 (ICMPv6)
• Internet Protocol version 4 (IPv4)
• Internet Protocol version 6 (IPv6)
o IPv6 Extension header type (Next Header, Hdr Ext Len, Header Specific
Data, Option Type, Opt Data Len, Option Data, Routing Type)
• Transmission Control Protocol (TCP)
• User Datagram Protocol (UDP)
Conformance with the RFC 792 (ICMPv4), RFC 4443 (ICMPv6), RFC 791(IPv4), RFC
2460 (IPv6), RFC 793 (TCP), RFC 768 (UDP) protocols is verified by Palo Alto through
regular quality assurance, regression, and interoperability testing.
A Security Administrator can configure the TOE to control the type of information that
is allowed to pass through the TOE. The Security Administrator defines the security zone
and applies security policies and security profiles to network traffic attempting to
traverse the TOE to determine what actions to take.
Security Zones
The TOE groups interfaces into security zones. Each zone identifies one or more
interfaces on the TOE. Separate zones must be created for each type of interface (Layer
2, Layer 3, or virtual wire), and each interface must be assigned to a zone before it can
process traffic.
Security Policies
Security policies provide the firewall rule sets that specify whether to block or allow
network connections, based on the source and destination zones, addresses, and the
application service (such as UDP port 67 or TCP port 80). Security policy rules are
processed in sequence order (top to bottom), applying the first rule that matches the
incoming traffic. To make a rule get checked first, the Security Administrator can place
the rule at the top of the order. Conflicting rules can be configured but the first matching
rule will be enforced on the traffic.
Security policies can be defined only between zones of the same type and be assigned
to a distinct network interface. However, the administrator can create a VLAN interface
for one or more VLANs and then apply a security policy between the VLAN interface
12
The HTTPS management session can be tunneled over IPsec to provide additional security.
Page 76 of 84
zone and a Layer 3 interface zone. This has the same effect as applying policies between
the Layer 2 and Layer 3 interface zones.
Each rule can be configured to generate a log record when the traffic matches the
defined rule using the ‘policy->Security->options’ selection. The logging option can be
configured to log at the start of a session, or at the end of a session or both.
The TOE enforces the stateful traffic filtering rules based on the following subject and
information security attributes:
• Source security zone to which the physical network interface is assigned
• Destination security zone to which the network interface is assigned
• Information specifiable in security policies, which provide the information flow
rule sets:
o presumed identity of source subject—source address information within
the packet
o identity of destination subject—destination address information within
the packet
o transport layer protocol (e.g., TCP, UDP)
o Internet layer protocol (e.g., ICMP type, code)
o source subject service identifier (e.g., source port number)
o destination subject service identifier (e.g., destination port number)
• Information security attributes for stateful packet inspection—for connection-
oriented protocols (e.g., TCP), the sequence number, acknowledgement number,
and flags (SYN, ACK, RST, FIN); and for connectionless protocols (e.g., UDP), the
source and destination network identifiers; and source and destination service
identifiers. Note that the TOE uses an IP-based network stack.
The TOE supports the Transmission Control Protocol (TCP) (RFC 793) which performs a
handshake during session setup to initiate and acknowledge a session. After the data is
transferred, the session is closed in an orderly manner, where each side transmits a FIN
packet and acknowledges it with an ACK packet. The handshake that initiates the TCP
session is often a three-way handshake (an exchange of three messages) between the
initiator and the listener, or it could be a variation, such as a four-way or five-way split
handshake or a simultaneous open. The TOE supports the TCP Split Handshake Drop
feature, which can prevent TCP Split Handshake Session Establishment.
The TOE keeps state about connections or pseudo-connections and uses the information
to permit or drop information flow. The TOE permits information flow between two
subjects (i.e., from the physical interface on which network traffic entered to the physical
interface determined by the destination address in the network packet) only where a
security policy is defined between the source and destination zones that includes a rule
that grants permission, based on the information security attributes listed above and the
corresponding settings in the policy rule.
A security policy rule includes the following attributes against which network packets
can be compared:
• Source Zone, Destination Zone—zones must be of the same type (Layer 2, Layer
3, or Virtual Wire). Multiple zones can be specified in a single rule to simplify
management
Page 77 of 84
• Source Address, Destination Address—the IPv4 or IPv6 addresses for which the
rule applies. Addresses must first be defined by the administrator, who specifies
a name for the address and the actual IPv4 or IPv6 addresses to be associated
with that name. Addresses can be specified as a single address, an address with
a mask, or an address range. Addresses can also be combined into address
groups to simplify management
• Service—specifies services to limit applications to specific protocols and port
numbers.
A security policy rule also includes the following attributes that determine what the TOE
does with the network packet:
• Action—can be ‘allow’ or ‘drop’
• Profiles—specifies any checking to be performed by the security profiles such as
IPsec crypto Security and IKE Network Security. These profile allow/require the
network traffic to be PROTECTed.)
• Options—specifies the following additional processing options for network
packets matching the rule:
o Log Setting—generate log entries in the local traffic log
o Schedule—limits the days and times when the rule is in effect (e.g., an
‘allow’ rule might be active only during normal business hours)
o QoS Marking—change the Quality of Service (QoS) marking on packets
matching the rule
o Disable Server Response Inspection—disables packet inspection from
the server to the client, which may be useful under heavy server load
conditions.
Prior to matching packets with the policy rules, fragmented packets are reassembled.
Upon receiving a packet that is not associated with an established session (a packet with
the SYN flag set without a corresponding ACK flag being set), the packet will be matched
to the security rules to make a determination of whether to allow or drop the information
flow. If the packet is associated with an established session (packet sequence number,
acknowledgment number, and flags match an existing session record), the information
flow is permitted.
The Security Administrator may limit the number of half-open TCP connections and
defines the thresholds that constitute flooding. The DoS Protection profile sets the
thresholds at which the firewall generates a DoS alarm, takes action such as Random
Early Drop, and drops additional incoming connections. The dropped connections are
logged, if configured so, but are always counted.
A DoS Protection profile policy rule that is set to protect (rather than to allow or drop
packets) determines the criteria for packets to match (such as source address) in order
to be counted toward the thresholds. The DoS Protection policy counts all connection
attempts toward the thresholds. This flexibility permits the blacklisting certain traffic, or
whitelist certain traffic and treat other traffic as DoS traffic. When the incoming rate
exceeds the maximum threshold, the firewall blocks incoming traffic from the source
address.
The TOE uses a patented technology called App-ID to identify and control applications
based on knowing exactly what the application is by evaluating the content of the traffic.
This unique approach to traffic classification allows the TOE to provide visibility and
control of the actual application, besides the ports or protocols that are allowed. App-ID
Page 78 of 84
is session "state" aware which allows the TOE to allow or block subsequent packets in a
session. The TOE maintains a session “state” table for all sessions as part of the traffic
processing layer of the device. If a packet doesn’t match an existing session, then it is
forced through the policy lookup process to determine if it should be allowed or not. If
allowed, a session will be created. The logging can be enabled as well.
The application decoder builds the state table based on the relevant RFCs.
The TOE creates dynamic rules, maintaining the session states to support processing the
FTP network protocol traffic for TCP data sessions in accordance with the FTP protocol
as specified in RFC 959 using the FTP App-ID. The FTP App-ID identifies the application
based on its unique properties and transaction characteristics using the App-ID
technology to dynamically open pinholes to establish the connection, determine the
parameters for the session and negotiate the ports that will be used for the transfer of
data; these applications use the application-layer payload to communicate the dynamic
TCP ports on which the application opens data connections. For such applications, the
firewall serves as an Application Level Gateway (ALG), and it opens a pinhole for a limited
time and for exclusively transferring data or control traffic. The dynamic sessions are
removed when the FTP sessions are terminated (i.e., closed) by the FTP server or client,
or when the TCP timeout expires (i.e., maximum time session can be open without any
activities). Logging can be enabled in the security policy rule configured to monitor the
FTP traffic, and can log FTP session starts, FTP session ends, or both. It does not log
individual FTP command or data packet.
The device provides a setting such that the Security Administrator can enable or disable
ICMP and SNMP for all users.
The TOE rejects requests for access or services when received on an interface that is
not associated with the source address from which the information flow is sourced (by
administrator configured “Strict IP address check” in the Zone Protection Profile”). Traffic
is dropped if the source address of the incoming traffic correspond to the IP address of
an external broadcast network or loopback network; if the incoming traffic is received
from the external network but has a source address that correspond to the internal
network; or if traffic is received from the internal network but has a source address that
correspond to the external network. The TOE rejects packets where the source address
is equal to the address of the network interface where the network packet was received.
Access or service requests are also rejected when the presumed source identity specifies
a broadcast identity or a loopback identifier. Security rules to block, permit or log are
applied to multicast traffic. The TOE rejects and logs packets where the source address
of the network packet is defined as being on a multicast network. The TOE discards and
logs strict source routing, loose source routing, and record route packets. The TOE
blocks RFC 6598 “Carrier Grade NAT” IP address block of 100.64.0.0/10. In addition,
requests in which the information received contains the set of host network identifiers
by which information is to travel from the source subject to the destination subject are
rejected.
The TOE has the capability to block the following IPv6 traffic:
• block both inbound and outbound IPv6 Site Local Unicast addresses (FEC0::/10)
• block IPv6 Jumbo Payload datagrams (Option Type 194).
• drop all inbound and outbound IPv6 packets containing a Hop-by-Hop header
with option type values intended for Destination Options
• drop all inbound IPv6 packets for which the layer 4 protocol and ports
(undetermined transport) cannot be located.
Page 79 of 84
• drop all inbound IPv6 packets with a Type 0 Routing header.
• drop all inbound IPv6 packets with a Type 1 or Types 3 through 255 Routing
Header.
• drop all inbound IPv6 packets containing undefined header extensions/protocol
values.
• drop fragmented IPv6 packets when any fragment overlaps another.
• drop all inbound IPv6 packets containing more than one Fragmentation Header
within an IP header chain.
• drop all inbound and outbound IPv6 packets containing a Hop-by-Hop header
with option type values intended for Destination Options.
• block IPv6 multicast addresses (FF00::/8) as a source address.
Following is a more detailed description of the TOE’s firewall capability.
When the TOE receives a packet, it first determines if it represents a new connection or
if it is part of an existing session. If it is part of an existing session, the traffic is processed
based on the parameters of the existing session. If it is a new connection, the TOE
retrieves the source and destination zones and performs an initial policy lookup. If a
policy is defined for the zone pair (i.e., source and destination zones) a session is created
and packet processing proceeds. By default, traffic between each pair of security zones
is blocked until at least one rule is added to allow traffic between the two zones. Sessions
are not created for a new connection if there is no policy defined for the zone pair; or if
there is an initial deny rule for the application service (i.e. service-HTTP, service-https)
matching the traffic with no applications defined.
The TOE performs the following steps when processing traffic:
• The traffic is passed through the Application Identification and Application Decoders
to determine what type of application is creating the session.
• Once the application is known, the TOE performs a policy lookup with the following
information:
▪ The source/destination IP address
▪ The source/destination security zone
▪ The application and service (port and protocol, Next Header)
▪ The source user13
(when available)
o If a security policy is found, the policy rules are compared against the
incoming traffic in sequence and the first rule that matches the traffic is
applied. If a policy rule matching all of the traffic attributes listed above is
not found, or if it is found and it specifies a drop action, then the packet is
dropped (or DISCARDed) and the session is deleted.
o If the application flow is allowed and no further security profiles are applied
then it is forwarded (it is allowed to BYPASS the tunnel).
o If the application is allowed and there are additional security profiles set, it
will be sent to the stream signature processor. The traffic matching the IPsec
crypto Security profile would then flow through the IPsec tunnel and be
classified as “PROTECTED”.
13
Source user in policies is not within the scope of the evaluation.
Page 80 of 84
▪ If there is no SA that the IPsec can use to protect this traffic to the
peer, IPsec uses IKE to negotiate with the remote peer to set up the
necessary IPsec SAs on behalf of the data flow. The negotiation
uses information specified in the IKE Network Profiles.
Security policies can also specify security profiles that may be used to protect against
viruses, spyware, and other threats after the connection is established.
Security Profiles
Each security policy can include specification of one or more security profiles, which
provide additional protection and control. Security profiles are configured and applied to
firewall policy. Each security policy can specify one or more of the following security
profiles:
• IPsec Crypto Security profile
• IKE Crypto Security profile
The TOE can remove existing traffic flows from the set of established traffic flows based
on the session inactivity timeout and completion of the expected information flow for
each protocol (TCP/UDP/ICMPv4/ICMPv6). The timeout period due to inactivity is
administrator configurable from 1 – 6044800 seconds per protocol. Session removal
becomes effective before the next packet that might match the session is processed.
The TOE implements an implicit “deny-all” rule to interfaces where a traffic filtering rule
has been applied. If a policy rule matching all of the traffic attributes described is not
found, or if it is found and it specifies a deny action, then the packet is dropped, and the
session is deleted. Session removal becomes effective before the next packet that might
match the session is processed.
The PAN-OS performs Strict IP Address check, reject, and is capable of logging network
packets where the source or destination address of the network packet is defined as
being an address “reserved for future use” as specified in RFC 5735 for IPv4. The
administrator may also configure the TOE to reject and log network packets where the
source or destination address of the network packet is defined as a link-local address, an
“unspecified address” or an address “reserved for future definition and use” as specified
in RFC 3513 for IPv6. The TOE rejects and is capable of logging invalid and fragmented
IP packets which cannot be re-assembled completely. The TOE detects all invalid
fragmented packets, such as a fragmented packet that partially overlaps a previously
received fragment, or a fragmented packet with invalid length, and drops and/or logs
them as configured in the Zone Protection Profiles. Optionally, the TOE can be
configured to consider any fragmented packet as invalid and to drop and log them.
IP fragments will be parsed, be reassembled by defragmentation process and fed back
to parser starting with IP header. A fragment may be discarded due to tear-drop attack
(overlapping fragments).
The network traffic can go through the TOE only if the Policy Enforcement Module is
fully functional and it is enforcing all policies. During start-up and initialization, the TOE
runs a series of system checks and the FIPS power up self- tests to ensure the system is
functioning correctly. If these tests run successfully, the TOE will bring up the control
plane and data-plane system modules. The Policy Enforcement Module (running on Data
Plane) uses the policy configuration information created from the Management Server
Module (running on the control plane). The configuration information includes all of the
policies required by the Policy Enforcement Module. Policies are used to control
information flow on the network. Only once the Policy Enforcement Module running on
Page 81 of 84
the data-plane is up and running and the TOE’s system configuration is applied to
enforce all security policies, can the TOE pass the traffic.
The TOE implements the following safeguards that prevent packets from flowing
through the TOE without applying the ruleset in the event of a component failure. The
traffic can go through the TOE only if the Policy Enforcement Module is fully functional
and enforcing all policies as described above. The Policy Enforcement Module can be
configured to stop traffic when the traffic or system logs are full. Whenever a failure
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.
The Policy Enforcement Module uses the policy configuration information created from
the Management Server Module. The configuration information includes all of the
policies required by the Policy Enforcement Module. Policies are used to control
information flow on the network.
6.10 Packet Filtering
FPF_RUL_EXT.1 The Packet Filtering function is a subset of the Stateful Traffic Filtering function. This
section provides a brief overview and summary of the packet filtering function. The
Stateful Traffic Filtering function Section 6.9 contains additional detail relevant to this
function.
On the TOE, security policies determine whether to block or allow a session based on
traffic attributes such as the source and destination security zone, the source and
destination IP address, protocol (as specified in RFCs), Next Header, the application, user,
and the service.
All traffic passing through the firewall is matched against a session and each session is
matched against a security policy. When a session match occurs, the security policy is
applied to bi-directional traffic (client to server and server to client) in that session. For
traffic that doesn’t match any defined rules, a final configurable deny or allow rule is
applied. The default rules allow all intrazone (within the zone) traffic and deny all
interzone (between zones) traffic. Typically, intrazone traffic is considered to be trusted
however both intrazone and interzone traffic can be configured to deny all traffic if there
is no rule match by clicking on the security policy and clicking on the Override button on
the bottom on the Policy ->Security screen. In the evaluated configuration, the default
deny all rule for interzone traffic should not be modified. Each rule can be configured to
generate a log record when the traffic matches the defined rule using the ‘policy-
>Security->options’ selection. The logging option can be configured to log at the start of
a session, or at the end of a session or both.
Security policies are evaluated left to right and from top to bottom in a packet filtering
table format. A packet is matched against the first rule that meets the defined criteria;
after a match is triggered the subsequent rules are not evaluated. Therefore, the more
specific rules must precede more generic ones in order to enforce the best match criteria.
Traffic that matches a rule generates a log entry of the session in the traffic log, if logging
is enabled for that rule.
The TOE will drop the packets if one of its interfaces is overwhelmed by network traffic.
The 7000 series provides higher performance, in order to compensate the FPGA is
Page 82 of 84
designed to drop IPv6 with “zero” destination in the initial ingress packet processing. This
event is logged in the FPGA counter log “flow_fpga_rcv_igr_IPV6DSTZERO”.
The security policy rules that determine whether a packet is transferred from one
interface to another is based on:
1. IP address of source as defined as the original IP address in the packet.
2. IP address of destination as defined as the original IP address in the packet.
3. Service used allows Layer 4 selection (TCP or UDP) port for the application.
4. Source Zone from which the traffic originates.
5. Destination Zone at which the traffic terminates.
Page 83 of 84
7. Protection Profile Claims
This ST is conformant to the [CFG_NDcPP-FW-VPNGW_V1.2], [NDcPP], [FW-Module], and [VPNGW-
Module].
Page 84 of 84
8. Rationale
This Security Target includes by reference the Error! Reference source not found., [FW-Module], and [
VPNGW-Module] applicable Security Problem Definition, Security Objectives, and Security Assurance
Requirements. The Security Target makes no additions to the Error! Reference source not found., [FW-M
odule], and [VPNGW-Module] assumptions. Security Functional Requirements have been reproduced
verbatim with the Protection Profile and PP-Module operations completed except where refinements were
made by the ST author and formatted per the defined convention. Operations on the security requirements
follow Error! Reference source not found., [FW-Module], and [VPNGW-Module] application notes and e
valuation activities. The Security Target did not add or remove any security requirements. Consequently,
Error! Reference source not found., [FW-Module], and [VPNGW-Module] rationales apply and are c
omplete.