Palo Alto Networks
PA-220 Series, PA-800
Series, PA-3000 Series, PA-
3200 Series, PA-5200
Series, PA-7000 Series, and
VM Series Next-Generation
Firewall with PAN-OS 9.1.8
Security Target
Version: 1.0
Date: March 15, 2021
Palo Alto Networks, Inc.
www.paloaltonetworks.com
© 2021 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 9.1.8 Security Target Palo Alto Networks
Page ii of iv
Table of Contents
1. SECURITY TARGET INTRODUCTION ............................................................................................................1
1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION......................................................................................1
1.2 CONFORMANCE CLAIMS ................................................................................................................................3
1.3 CONVENTIONS ...............................................................................................................................................5
1.3.1 Terminology .........................................................................................................................................5
1.3.2 Acronyms..............................................................................................................................................5
2. PRODUCT DESCRIPTION ...............................................................................................................................7
2.1 TOE OVERVIEW ............................................................................................................................................8
2.2 TOE ARCHITECTURE...................................................................................................................................10
2.2.1 Physical Boundaries .........................................................................................................................11
2.2.2 Logical Boundaries ...........................................................................................................................20
2.3 TOE DOCUMENTATION ...............................................................................................................................21
2.4 EXCLUDED FUNCTIONALITY.........................................................................................................................22
3. SECURITY PROBLEM DEFINITION ............................................................................................................24
4. SECURITY OBJECTIVES...............................................................................................................................25
4.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT................................................................25
5. IT SECURITY REQUIREMENTS ...................................................................................................................27
5.1 EXTENDED REQUIREMENTS ........................................................................................................................27
5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS...........................................................................................27
5.2.1 Security Audit (FAU).........................................................................................................................29
5.2.2 Cryptographic Support (FCS)..........................................................................................................32
5.2.3 User Data Protection (FDP).............................................................................................................43
5.2.4 Identification and Authentication (FIA)...........................................................................................43
5.2.5 Security Management (FMT)...........................................................................................................45
5.2.6 Protection of the TSF (FPT) ............................................................................................................47
5.2.7 TOE Access (FTA)............................................................................................................................48
5.2.8 Trusted Path/Channels (FTP) .........................................................................................................48
5.2.9 Stateful Traffic Filtering (FFW)........................................................................................................50
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............................................................................................................................66
6.4 IDENTIFICATION AND AUTHENTICATION.......................................................................................................67
6.5 SECURITY MANAGEMENT ............................................................................................................................70
6.6 PROTECTION OF THE TSF...........................................................................................................................71
6.7 TOE ACCESS ..............................................................................................................................................74
6.8 TRUSTED PATH/CHANNELS.........................................................................................................................75
6.9 STATEFUL TRAFFIC FILTERING....................................................................................................................76
6.10 PACKET FILTERING..................................................................................................................................82
7. PROTECTION PROFILE CLAIMS ................................................................................................................83
PAN OS 9.1.8 Security Target Palo Alto Networks
Page iii of iv
8. RATIONALE......................................................................................................................................................84
PAN OS 9.1.8 Security Target Palo Alto Networks
Page iv of iv
LIST OF FIGURES
Figure 1: TOE Architecture ..................................................................................................................................10
LIST OF TABLES
Table 1 TOE Platforms...........................................................................................................................................14
Table 2 Excluded Features...................................................................................................................................22
Table 3 TOE Security Functional Components...............................................................................................27
Table 4 Auditable Events......................................................................................................................................29
Table 5 Assurance Components.........................................................................................................................55
Table 6 Cryptographic Functions.......................................................................................................................57
Table 7 FIPS 186-4 Conformance .......................................................................................................................59
Table 8 Private Keys and CSPs...........................................................................................................................60
PAN OS 9.1.8 Security Target Palo Alto Networks
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 v9.1.8 provided by Palo Alto Networks Inc.
The next-generation firewall includes the PA-220, PA-220R, PA-820, PA-850, PA-3020, PA-3050, PA-
3060, PA-3220, PA-3250, PA-3260, PA-5220, PA-5250, PA-5260, PA-5280, 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 User Identification
Agent (UIA) installed on a PC in the operational environment communicates with the domain controller to
retrieve user-specific information. It allows the next-generation firewall to automatically collect user
information and include it in policies and enforcement.
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-800 Series, PA-3000 Series, PA-3200 Series, PA-5200
Series, PA-7000 Series, and VM Series Next-Generation Firewall with PAN-OS 9.1.8 Security Target
ST Version – Version 1.0
ST Date – March 15, 2021
TOE Identification – Palo Alto Networks PA-220 Series, PA-800 Series, PA-3000 Series, PA-3200 Series,
PA-5200 Series, PA-7000 Series, and VM Series, Next-Generation Firewall with PAN-OS 9.1.8. The
specific Firewall appliance models include:
1. PA-220 Series
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 2 of 84
a. PA-220
b. PA-220R
2. PA-800 Series
a. PA-820
b. PA-850
3. PA-3000 Series
a. PA-3020
b. PA-3050
c. PA-3060
4. PA-3200 Series
a. PA-3220
b. PA-3250
c. PA-3260
5. PA-5200 Series
a. PA-5220
b. PA-5250
c. PA-5260
d. PA-5280
6. PA-7000 Series1
a. PA-7050
b. PA-7080
7. 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 5.5, 6.0, 6.5, or 6.7
 Linux KVM
o Ubuntu: 14.04 LTS QEMU-KVM 2.0.0 and libvirt 1.2.2)
o Ubuntu: 16.04 LTS (QEMU-KVM 2.5 0; libvirt 1.3.1; Open vSwitch: 2.5.0)
o CentOS/RedHat Enterprise Linux: 7 (QEMU-KVM 1.5.3 and libvirt 2.0.0)
1
Palo Alto Networks PA-7000 Series firewalls support five different Network Processing Cards (NPC): PAN-PA-
7000-20G-NPC, PAN-PA-7000-20GQ-NPC, PAN-PA-7000-20GXM-NPC, PAN-PA-7000-20GQXM-NPC, and
PAN-PA-7000-100G-NPC.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 3 of 84
o CentOS: 7 (QEMU-KVM 1.5.3 and libvirt 3.9.0)
 Microsoft Hyper-V Server 2012 R2 ---- 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 2012 R2, or as an add-on/role for Windows Server 2012 R2.
The VM-Series must be the only guest running in the virtualized environment. Evaluation testing included
the following:
VMware ESXi 6.5:
 Dell PowerEdge R730 Processor: Intel XEON CPU E5-2640 v4 (Broadwell microarchitecture)
with Broadcom 5720 NIC
 Memory: 64 GB ECC DDR4 2133
Microsoft Hyper-V Server 2012 R2:
 Dell PowerEdge R730 Processor: Intel XEON CPU E5-2640 v4 (Broadwell microarchitecture)
with Broadcom 5720 NIC
 Memory: 64 GB ECC DDR4 2133
Linux KVM CentOS 7.5:
 Dell PowerEdge R730 Processor: Intel XEON CPU E5-2640 v4 (Broadwell microarchitecture)
with Broadcom 5720 NIC
 Memory: 64 GB ECC DDR4 2133
Evaluation testing included the following hardware and processors:
 PA-3260: Cavium Octeon CN7360 MIPS64 (DP) / Intel Pentium D1517 (MP)
 PA-7080: Cavium Octeon CN6880 MIPS64 (DP) / Intel Core i7-2715 (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
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.0, March 6, 2020 [CFG_NDcPP-FW-VPNGW_V1.0] consisting of the following
components:
· collaborative Protection Profile for Network Devices, Version 2.1, 24 September 2018 [NDcPP]
· PP-Module for Stateful Traffic Filter Firewalls, Version 1.3, 27 September 2019 [FW-Module]
· PP-Module for Virtual Private Network (VPN) Gateways, Version 1.0, 17 September 2019
[VPNGW-Module]
The following NIAP Technical Decisions2 apply to this [NDcPP] and have been accounted for in the ST
development and the conduct of the evaluation:
 0484 – NIT Technical Decision for Interactive sessions in FTA_SSL_EXT.1 & FTA_SSL.3
 0483 – NIT Technical Decision for Applicability of FPT_APW_EXT.1
2
The following TDs are not applicable: 453, 451, 447, and 411.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 4 of 84
 0482 – NIT Technical Decision for Identification of usage of cryptographic schemes
 0481 – NIT Technical Decision for FCS_(D)TLSC_EXT.X.2 IP addresses in reference
identifiers
 0480 – NIT Technical Decision for Granularity of audit events
 0478 – NIT Technical Decision for Application Notes for FIA_X509_EXT.1
 0477 – NIT Technical Decision for Clarifying FPT_TUD_EXT.1 Trusted Update
 0475 – NIT Technical Decision for Separate traffic consideration for SSH rekey
 0450 – NIT Technical Decision for RSA-based ciphers and the Server Key Exchange message
 0425 – NIT Technical Decision for Cut-and-paste Error for Guidance AA
 0424 – NIT Technical Decision for NDcPP v2.1 Clarification - FCS_SSHC/S_EXT1.5
 0423 – NIT Technical Decision for Clarification about application of RfI#201726rev2
 0412 – NIT Technical Decision for FCS_SSHS_EXT.1.5 SFR and AA discrepancy
 0410 – NIT technical decision for Redundant assurance activities associated with FAU_GEN.1
 0409 – NIT decision for Applicability of FIA_AFL.1 to key-based SSH authentication
 0408 – NIT Technical Decision for local vs. remote administrator accounts
 0407 – NIT Technical Decision for handling Certification of Cloud Deployments
 0402 – NIT Technical Decision for RSA-based FCS_CKM.2 Selection
 0401 – NIT Technical Decision for Reliance on external servers to meet SFRs
 0400 – NIT Technical Decision for FCS_CKM.2 and elliptic curve-based key establishment
 0399 – NIT Technical Decision for Manual installation of CRL (FIA_X509_EXT.2)
 0398 – NIT Technical Decision for FCS_SSH*EXT.1.1 RFCs for AES-CTR
 0397 – NIT Technical Decision for Fixing AES-CTR Mode Tests
 0396 – NIT Technical Decision for FCS_TLSC_EXT.1.1, Test 2
 0395 – NIT Technical Decision for Different Handling of TLS1.1 and TLS1.2
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:
 0520 – VPN Gateway SFR Rationale
 0511 – VPN GW Conformance Claim to allow for a PP-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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 5 of 84
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 was 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:
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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 6 of 84
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)
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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 7 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 (FPT_ITC.1) between the firewalls and the products are claimed and validated in this
evaluation. The product descriptions below are provided for completeness only.
 Panorama network security management appliance enables control of a centralized management
of network of Palo Alto firewalls from one central location. An administrator may view all of the
firewall traffic, manage all aspects of device configuration, push global policies, and generate
reports on traffic patterns or security incidents — all from a single console.
 The WildFire appliance provides an on-premises WildFire private cloud, enabling the analysis of
suspicious files in a sandbox environment without requiring the firewall to sends files out of
network. The WildFire appliance can be configured to host a WildFire private cloud where the
firewall is configured to submit samples to the local WildFire appliance for analysis. The WildFire
appliance sandboxes all files locally and analyzes them for malicious behaviors using the same
engine the WildFire public cloud uses. Within minutes, the private cloud returns analysis results to
the firewall WildFire Submissions logs. The WildFire appliance can be configured to locally
generate antivirus and DNS signatures for discovered malware, and to assign a URL category to
malicious links. Connected firewalls can be enabled to retrieve the latest signatures and URL
categories every five minutes. Malware can be submitted to the WildFire public cloud. The WildFire
public cloud re-analyzes the sample and generates a signature to detect the malware—this
signature can be made available within minutes to protect global users. Locally-generated
malware reports (without sending the raw sample content) can be submitted to the WildFire public
cloud, to contribute to malware statistics and threat intelligence. Up to 100 Palo Alto Networks
firewalls, each with a valid WildFire subscription, can be configured to forward samples to a single
WildFire appliance. Beyond the WildFire firewall subscriptions, no additional WildFire subscription
is required to enable a WildFire private cloud deployment.
 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.
 The User Identification Agent (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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 8 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-820, PA-850, PA-3020, PA-3050, PA-
3060, PA-3220, PA-3250, PA-3260, PA-5220, PA-5250, PA-5260, PA-5280, 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 v9.1.8. 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
allowed to run on. High risk applications can be blocked, as well as high-risk behavior such as file-
sharing or FTP.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 9 of 84
 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).
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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 10 of 84
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 X509 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.
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:
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 11 of 84
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 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
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 v9.1.8 – 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,
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 12 of 84
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-820, PA-850,
PA-3020, PA-3050, PA-3060, PA-3220, PA-3250, PA-3260, PA-5220, PA-5250, PA-5260, PA-5280, 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-3020, PA-3050, PA-
3060, PA-3220, PA-3250, PA-3260, PA-5220, PA-5250, PA-5260, PA-5280, 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, and 1 Micro USB Console. 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). Processor: Cavium Octeon CN7130 MIPS64 (DP/MP)
 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
(management console port); 1 USB, and 1 Micro USB Console. 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, and 1 Micro USB Console. Processor: Cavium Octeon CN7240 MIPS64 (DP/MP)
 PA-3020/PA-3050: 12 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); 1 RJ-45 port for connecting a serial console
(management console port); and 2 RJ-45 ports for high-availability (HA) control and
synchronization. Processor: Cavium Octeon CN6335 MIPS64 (DP) / Intel Celeron P4505 (MP)
 PA-3060: 8 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); 1 RJ-45 port for connecting a serial console (management
console port); and 2 RJ-45 ports for high-availability (HA) control and synchronization. Processor:
Cavium Octeon CN6335 MIPS64 (DP) / Intel Celeron P4505 (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. Processor: Cavium Octeon CN7350 MIPS64 (DP) /
Intel Pentium D1517 (MP)
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 13 of 84
 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. Processor: Cavium Octeon CN7360 MIPS64 (DP) / Intel Pentium
D1517 (MP)
 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. 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. 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. Processor: Cavium Octeon CN7890 MIPS64 (DP) / Intel Xeon D1567 (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. Processor: Cavium Octeon CN6880 MIPS64 (DP) / Intel Core i7-2715
(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. Processor: Cavium Octeon CN6880 MIPS64 (DP) / Intel Core i7-2715
(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 Panorama or Wildfire appliances
 Palo Alto Networks Global Protect or UIA application
 Workstation
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 14 of 84
o Web browsers - Internet Edge (Release 42 or later), Firefox (version 66.0.5 or later), Safari
(version 12.0.3 or later on Mac, and version 5.1.7 or later on Windows and iOS), and
Chrome (version 74 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 2008 32-bit and 64-
bit, Windows Server 2012, and Windows Server 2012 R2.
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-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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 15 of 84
Product
Identification
Illustration Description
 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-3020  2 Gbps firewall throughput (App-
ID enabled)
 1 Gbps threat prevention
throughput
 500 Mbps IPsec VPN throughput
 250,000 max sessions
 50,000 new sessions per second
 1,000 IPsec VPN tunnels/tunnel
interfaces
 1,000 TLS VPN Users
 10 virtual routers
 1/6 virtual systems (base/max)
 40 security zones
 2,500 max number of policies
PA-3050  4 Gbps firewall throughput
(App-ID enabled)
 2 Gbps threat prevention
throughput
 500 Mbps IPsec VPN throughput
 500,000 max sessions
 50,000 new sessions per second
 2,000 IPsec VPN tunnels/tunnel
interfaces
 2,000 TLS VPN Users
 10 virtual routers
 1/6 virtual systems (base/max)
 40 security zones
 5,000 max number of policies
PA-3060  4 Gbps firewall throughput (App-
ID enabled1)
 2 Gbps threat prevention
throughput
 500 Mbps IPsec VPN throughput
 500,000 max sessions
 50,000 new sessions per second
 2,000 IPsec VPN tunnels/tunnel
interfaces
 2,000 TLS VPN Users
 10 virtual routers
 1/6 virtual systems (base/max)
 40 security zones
 5,000 max number of policies
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 16 of 84
Product
Identification
Illustration Description
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)
 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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 17 of 84
Product
Identification
Illustration Description
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)
 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)
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 18 of 84
Product
Identification
Illustration Description
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
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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 19 of 84
Product
Identification
Illustration Description
 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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 20 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 140-2 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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 21 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 the UIA, Panorama, Global Protect, and Wildfire using TLS
connections; the 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.
For PAN-OS v9.1.8, these documents include:
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 22 of 84
 Palo Alto Networks Common Criteria Evaluated Configuration Guide (CCECG) for PAN-OS 9.1.8,
March 15, 2021
 PAN-OS® Administrator’s Guide Version 9.1, Last Revised February 16, 2021
 VM-Series Deployment Guide Version 9.1, Last Revised January 5, 2021
 PAN-OS CLI Quick Start Version 9.1, Last Revised January 22, 2021
 PAN-OS Web Interface Help Version 9.1, Last Revised December 22, 2020
 PAN-OS and Panorama API Usage Guide Version 9.1, Last Revised January 11, 2021
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 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 is 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.
SD-WAN The PAN-OS software can include a native SD-WAN
subscription to provide intelligent and dynamic path selection
on top of what the PAN-OS security software already delivers.
Secure SD-WAN provides the optimal end user experience by
leveraging multiple ISP links to ensure application
performance and scale capacity. The SD-WAN capability is
considered out of scope.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 23 of 84
Feature Description
Include Username in HTTP
Header Insertion Entries
Allows the firewall to relay a user’s identity when they are
accessing your network through secondary security
appliances that are connected to your Palo Alto Networks
firewall. You can configure your firewall to include the
username in the HTTP header so that other security
appliances in your network can identify the user without
additional infrastructure (such as proxies used to insert the
username). This simplifies deployment, reduces page-load
latency, and eliminates multiple authentications for users.
This feature is outside the scope of the evaluation.
East-West Traffic Inspection
with VM-Series Firewall on
VMware NSX-T
The integration the VM-Series firewall with VMware NSX-T
provides comprehensive visibility and safe application
enablement of all east-west traffic in a NSX-T deployment.
When the VM-Series firewall is deployed as part of a service
chain in a Host Based (per ESXi host) or Clustered (as part of
an ESXi service cluster) NSX-T managed cloud environment,
you can inspect and secure lateral traffic between virtual
machines in the data center and implement micro-
segmentation. This feature is outside the scope of the
evaluation.
SAML Authentication SAML Authentication is an XML-based open-standard for
transferring identity data between two parties: an identity
provider (IdP) and a service provider (SP). External
authentication is outside the scope of the evaluation.
Proxy Support for Cortex Data
Lake
The firewall can be configured to forward logs to Cortex Data
Lake through a proxy server. This enables you to send log
data to Cortex Data Lake from a network without a default
gateway. The forwarding of logs to Cortex Data Lake is
outside the scope of the evaluation.
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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 24 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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 25 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.
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.
OE.CONNECTIONS The TOE is connected to distinct networks in a manner
that ensures that the TOE security policies will be
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 26 of 84
enforced on all applicable network traffic flowing among
the attached networks.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 27 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 [NDcPP], [FW-Module] and [VPNGW-Module].
5.1 Extended Requirements
All of 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.1) and
since they are not redefined in this ST, those PPs and Modules should be consulted for more information
in regard to 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
FAU: Security Audit FAU_GEN.1: Audit Data Generation
FAU_GEN.2: User Identity Association
FAU_STG_EXT.1: Protected Audit Event Storage
FCS: Cryptographic
Support
FCS_CKM.1: Cryptographic Key Generation
FCS_CKM.1/IKE: Cryptographic Key Generation (for IKE Peer
Authentication)
FCS_CKM.2: Cryptographic Key Establishment
FCS_CKM.4: Cryptographic Key Destruction
FCS_COP.1/DataEncryption: Cryptographic Operation (AES Data
Encryption/Decryption)
FCS_COP.1/SigGen: Cryptographic Operation (Signature Generation
and Verification)
FCS_COP.1/Hash: Cryptographic Operation (Hash Algorithm)
FCS_COP.1/KeyedHash: Cryptographic Operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1: Random Bit Generation
FCS_HTTPS_EXT.1(1): HTTPS Protocol (Default)
FCS_HTTPS_EXT.1(2): HTTPS Protocol (Configure Mutual
Authentication)
FCS_SSHS_EXT.1: SSH Server Protocol
FCS_TLSC_EXT.1: TLS Client Protocol
FCS_TLSC_EXT.2(1): TLS Client Protocol with Authentication (Syslog
Connection)
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 28 of 84
Requirement Class Requirement Component
FCS_TLSC_EXT.2(2): TLS Client Protocol with Authentication
(Panorama, Wildfire, or UIA Connections)
FCS_TLSS_EXT.1: TLS Server Protocol
FCS_TLSS_EXT.2: TLS Server Protocol with Mutual Authentication
FCS_IPSEC_EXT.1: IPsec Protocol
FDP: User Data
Protection
FDP_RIP.2: Full Residual Information Protection
FIA: Identification and
Authentication
FIA_AFL.1: Authentication Failure Management
FIA_PMG_EXT.1: Password Management
FIA_UIA_EXT.1: User Identification and Authentication
FIA_UAU_EXT.2: Password-based Authentication Mechanism
FIA_UAU.7: Protected Authentication Feedback
FIA_X509_EXT.1/Rev: X.509 Certificate Validation
FIA_X509_EXT.2(1): X.509 Certificate Authentication (Syslog
Connection)
FIA_X509_EXT.2(2): X.509 Certificate Authentication (FW, HTTPS,
Panorama, UIA, GP, and Wildfire Connections)
FIA_X509_EXT.3: X.509 Certificate Requests
FMT: Security
Management
FMT_MOF.1/ManualUpdate: Management of Security Functions
Behaviour
FMT_MOF.1/Services: Management of Security Functions Behaviour
FMT_MOF.1/Functions: Management of Security Functions Behaviour
FMT_MTD.1/CryptoKeys: Key Management of TSF Data
FMT_MTD.1/CoreData: Management of TSF Data
FMT_SMF.1: Specification of Management Functions
FMT_SMF.1/FFW: Specification of Management Functions
FMT_SMR.2: Restrictions on Security Roles
FPT: Protection of the
TSF
FPT_SKP_EXT.1: Protection of TSF Data (for reading of all pre-shared,
symmetric and private keys)
FPT_APW_EXT.1: Protection of Administrator Passwords
FPT_FLS.1/SelfTest Fail Secure (Self-test Failures)
FPT_TST_EXT.1: TSF Testing
FPT_TST_EXT.3: Extended TSF Testing
FPT_TUD_EXT.1: Trusted Update
FPT_STM_EXT.1: Reliable Time Stamps
FTA: TOE Access FTA_SSL_EXT.1: TSF-initiated Session Locking
FTA_SSL.3: TSF-initiated Termination
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 29 of 84
Requirement Class Requirement Component
FTA_SSL.4: User-initiated Termination
FTA_TAB.1: Default TOE Access Banners
FTP: Trusted
Path/Channels
FTP_ITC.1: Inter-TSF Trusted channel
FTP_ITC.1/VPN: Inter-TSF Trusted channel
FTP_TRP.1/Admin: Trusted Path
FFW: Stateful Traffic
Filter Firewall
FFW_RUL_EXT.1: Stateful Traffic Filtering
FFW_RUL_EXT.2: Stateful Filtering of Dynamic Protocols
FPF: Packet Filtering FPF_RUL_EXT.1: Rules for Packet Filtering
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
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
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.1/IKE None. None.
FCS_CKM.2 None. None.
FCS_CKM.4 None. None.
FCS_COP.1/DataEncryption None. None.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 30 of 84
Requirement Auditable Events Additional Audit Record
Contents
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(1)
FCS_TLSC_EXT.2(2)
Failure to establish a TLS session. Reason for failure
FCS_TLSS_EXT.1 Failure to establish a TLS session. Reason for failure
FCS_TLSS_EXT.2 Failure to establish a TLS session. Reason for failure
FCS_IPSEC_EXT.1 Session Establishment with peer Entire packet contents of
packets transmitted/received
during session establishment
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
Any addition, replacement or
removal of trust anchors3 in the
TOE's trust store
Reason for failure of certificate
validation
Identification of certificates
added, replaced or removed
as trust anchor in the TOE's
trust store
FIA_X509_EXT.2(1)
FIA_X509_EXT.2(2)
None. None.
FIA_X509_EXT.3 None. None.
FMT_MOF.1/ManualUpdate Any attempt to initiate a manual
update
None.
3
Importing CA certificate(s) or generating CA certificate(s) internally will implicitly set them as trust anchor.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 31 of 84
Requirement Auditable Events Additional Audit Record
Contents
FMT_MOF.1/Services None. None.
FMT_MOF.1/Functions 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_FLS.1/SelfTest None. None.
FPT_TST_EXT.1 None. None.
FPT_TST_EXT.3 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
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
channels establishment
attempt.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 32 of 84
Requirement Auditable Events Additional Audit Record
Contents
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
FPF_RUL_EXT.1 Application of rules configured
with the ‘log’ operation
Source and destination
addresses
Source and destination ports
Transport Layer Protocol
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;
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 33 of 84
 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 Diffie-Hellman group 14 that meet the following:
RFC 3526, Section 3
] 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 meets the
following: NIST Special Publication 800-56A Revision 2,
“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”
 Key establishment scheme using Diffie-Hellman group 14 that meets
the following RFC 3526, Section 3
] that meets the following: [assignment: list of standards].
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]];
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 34 of 84
 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
[selection:
o logically addresses the storage location of the key and performs a
[selection: single, [assignment: number of passes]-pass] overwrite
consisting of [selection: a pseudo-random pattern using the TSF’s
RBG, zeroes, ones, a new value of the key, [assignment: a static
or dynamic value that does not contain any CSP]];
o instructs a part of the TSF to destroy the abstraction that
represents the key]]
that meets the following: No Standard.
Application Note: The TOE does not store plain text keys in non-volatile storage.
NIAP TRRT 241 response stated: “The TRRT does not see the need to modify the
requirement. If the TOE does not store plaintext keys in one type of memory, that
portion of the requirement is met. A statement in the TSS that plaintext keys are
not stored in a specific type of memory is sufficient.”
FCS_COP.1/DataEncryption – Cryptographic Operation (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: FCS_COP.1/DataEncryption in the [VPNGW-Module] has
been used.
FCS_COP.1/SigGen – Cryptographic Operation (Signature Generation and Verification)
FCS_COP.1.1/SigGen The TSF shall perform cryptographic signature services (generation and
verification) in accordance with a specified cryptographic algorithm [
 RSA Digital Signature Algorithm and cryptographic key sizes
(modulus) [2048 bits, 3072 bits],
 Elliptic Curve Digital Signature Algorithm and cryptographic key
sizes [256 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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 35 of 84
cryptographic key sizes [assignment: cryptographic key sizes] and message
digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC 10118-
3:2004.
FCS_COP.1/KeyedHash – Cryptographic Operation (Keyed Hash Algorithm)
FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in accordance
with a specified cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256, HMAC-
SHA-384, HMAC-SHA-512] and cryptographic key sizes [160, 256, 384, 512] and
message digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC
9797-2:2011, Section 7 “MAC Algorithm 2”.
FCS_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] hardware-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 that complies with RFC(s) [4251, 4252,
4253, 4254, 4344, 6668].
Application Note: FCS_SSHS_EXT.1.1 is updated based on TD0398.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 36 of 84
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following
authentication methods as described in RFC 4252: public key-based, [password-
based].
FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than [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.
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.
Application Note: FCS_SSHS_EXT.1.8 is updated based on TD0475.
FCS_TLSC_EXT.1 - TLS Client Protocol
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_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
 TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
 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_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
 TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC
5246
 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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 37 of 84
 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:
[identifiers defined in RFC 6125, IPv4 address in CN or SAN] are matched to
reference identifiers.
Application Note: SFR updated based on T0481.
FCS_TLSC_EXT.1.3 When establishing a trusted channel, by default the TSF shall not establish a
trusted channel if the server certificate is invalid. The TSF shall also [
 Not implement any administrator override mechanism].
FCS_TLSC_EXT.1.4 The TSF shall [present the Supported Elliptic Curves Extension with the
following NIST curves: [secp256r1, secp384r1, secp521r1] and no other
curves] in the Client Hello.
Application Note: The TOE connecting to the syslog server acts as a TLS client
only supports TLS1.2.
FCS_TLSC_EXT.2(1) - TLS Client Protocol with Authentication (Syslog Connection)
FCS_TLSC_EXT.2.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_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
 TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
 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_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 38 of 84
 TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC
5246
 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.2.2(1) The TSF shall verify that the presented identifiers of the following types:
[identifiers defined in RFC 6125, IPv4 address in CN or SAN] are matched to
reference identifiers.
Application Note: SFR updated based on TD0481.
FCS_TLSC_EXT.2.3(1) When establishing a trusted channel, and if mutual authentication is
configured, by default the TSF shall not establish a trusted channel if the server
certificate is invalid. The TSF shall also [
 Not implement any administrator override mechanism].
FCS_TLSC_EXT.2.4(1) The TSF shall [present the Supported Elliptic Curves Extension with
the following NIST curves: [secp256r1, secp384r1, secp521r1] and no other
curves] in the Client Hello.
FCS_TLSC_EXT.2.5(1) The TSF shall support mutual authentication using X.509v3 certificates.
Application Note: Mutual authentication is supported for the TOE to syslog server
TLSv1.2 connection, if configured.
FCS_TLSC_EXT.2(2) - TLS Client Protocol with Authentication (Panorama, Wildfire, or UIA
Connections)
FCS_TLSC_EXT.2.1(2) 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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 39 of 84
 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
].
FCS_TLSC_EXT.2.2(2) The TSF shall verify that the presented identifiers of the following types:
[identifiers defined in RFC 6125, IPv4 address in CN or SAN] are matched to
reference identifiers.
Application Note: SFR updated based on TD0481.
FCS_TLSC_EXT.2.3(2) When establishing a trusted channel, by default the TSF shall not establish
a trusted channel if the server certificate is invalid. The TSF shall also [
 Not implement any administrator override mechanism].
FCS_TLSC_EXT.2.4(2) The TSF shall [present the Supported Elliptic Curves Extension with
the following NIST curves: [secp256r1, secp384r1, secp521r1] and no other
curves] in the Client Hello.
FCS_TLSC_EXT.2.5(2) The TSF shall support mutual authentication using X.509v3 certificates.
Application Note: Mutual authentication is required for the TOE (TLS client)
connection to the Panorama, Wildfire, or UIA (RSA key exchange is not supported
for these connections —See TSS for more details TLS versions and ciphersuites).
FCS_TLSS_EXT.1 - TLS Server Protocol
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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 40 of 84
 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
].
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 [generate EC Diffie-Hellman parameters over NIST curves
[secp256r1, secp384r1] and no other curves; generate Diffie-Hellman
parameters of size [2048 bits]].
Application Note: For the management and Global Protection (GP) connections,
the TOE is the TLS server.
FCS_TLSS_EXT.2 - TLS Server Protocol with Mutual Authentication
FCS_TLSS_EXT.2.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
].
FCS_TLSS_EXT.2.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS
1.0, and [none].
FCS_TLSS_EXT.2.3 The TSF shall [generate EC Diffie-Hellman parameters over NIST curves
[secp256r1, secp384r1] and no other curves; generate Diffie-Hellman
parameters of size [2048 bits]].
FCS_TLSS_EXT.2.4 The TSF shall support mutual authentication of TLS clients using X.509v3
certificates.
FCS_TLSS_EXT.2.5 When establishing a trusted channel, and if mutual authentication is configured,
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].
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 41 of 84
FCS_TLSS_EXT.2.6 The TSF shall not establish a trusted channel if the distinguished name (DN) or
Subject Alternative Name (SAN) contained in a certificate does not match the
expected identifier for the peer.
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
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;
];
 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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 42 of 84
[
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 all IKE protocols implement DH Groups 19 (256-bit
Random ECP), 20 (384-bit Random ECP, and [14 (2048-bit MODP)].
Application Note: This SFR element has been modified from its definition in the
NDcPP by mandating DH groups 19 and 20.
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.
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), [SAN: IP address, SAN: Fully Qualified Domain
Name (FQDN), CN: IP address, CN: Fully Qualified Domain Name (FQDN)].
Application Note: FCS_IPSEC_EXTT.1.14 in the [VPNGW-Module] is used.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 43 of 84
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].
Application Note: SFR updated based on TD0408.
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 [6] 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.
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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 44 of 84
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/RevThe 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(1) – X.509 Certificate Authentication (Syslog Connection)
FIA_X509_EXT.2.1(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: FIA_X509_EXT.2.1 in the [VPNGW-Module] is used.
FIA_X509_EXT.2.2(1) 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.2(2) – X.509 Certificate Authentication (FW, HTTPS, Panorama, UIA, GP, and Wildfire
Connections)
FIA_X509_EXT.2.1(2) The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for IPsec and [TLS, HTTPS], and [no additional uses].
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 45 of 84
Application Note: FIA_X509_EXT.2.1 in the [VPNGW-Module] is used.
FIA_X509_EXT.2.2(2) When the TSF cannot establish a connection to determine the validity of a
certificate, the TSF shall [allow the Administrator to choose whether to accept
the certificate in these cases].
Application Note: For the connection to the firewall (VPN gateway), web browser
(HTTPS), Panorama, UIA, GP, or Wildfire, the default behavior is to accept the
client/server certificate and allow the connection. However, the behavior is
configurable for these connections.
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 in the [VPNGW-Module] is used.
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/Services The TSF shall restrict the ability to enable and disable start and stop the
functions services to Security Administrators.
FMT_MOF.1/Functions - Management of Security Functions Behaviour
FMT_MOF.1.1/Functions The TSF shall restrict the ability to [modify the behaviour of] the functions
[transmission of audit data to an external IT entity] to Security Administrators.
FMT_MTD.1/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: FMT_MTD.1.1/CryptoKeys in the [VPNGW-Module] is used.
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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 46 of 84
FMT_SMF.1 – Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
 Ability to administer the TOE locally and remotely;
 Ability to configure the access banner;
 Ability to configure the session inactivity time before session termination or
locking;
 Ability to update the TOE, and to verify the updates using digital signature
and [no other] capability prior to installing those updates;
 Ability to configure the authentication failure parameters for FIA_AFL.1;
 Ability to manage the cryptographic keys;
 Ability to configure the cryptographic functionality;
 Ability to configure the lifetime for IPsec SAs;
 Ability to import X.509v3 certificates to the TOE’s trust store;
 Ability to configure the IPsec functionality;
 Ability to import X.509v3 certificates;
 Ability to enable, disable, determine and modify the behavior of all the
security functions of the TOE identified in this PP-Module to the
Administrator;
 Ability to configure all security management functions identified in other
sections of this PP-Module;
[
o Ability to start and stop services
o Ability to configure audit behavior;
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 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
].
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_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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 47 of 84
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.
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.
Application Note: SFR updated based on TD0483.
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_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
 Firmware Integrity Test
]
Application Note: FPT_TST_EXT.1 in the [VPNGW-Module] is used.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 48 of 84
FPT_TST_EXT.3 – Extended TSF Testing
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: FPT_TUD_EXT.1.3 in the [VPNGW-Module] is used.
FPT_STM_EXT.1 – Reliable Time Stamps
FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use.
FPT_STM_EXT.1.2 The TSF shall [allow the Security Administrator to set the time].
5.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.
5.2.8 Trusted Path/Channels (FTP)
FTP_ITC.1 – Inter-TSF Trusted Channel
FTP_ITC.1.1 The TSF shall use [TLS, IPsec] to provide a trusted communication channel between itself
and authorized IT entities supporting the following capabilities: audit server, VPN
communications, [[connections with UIA, VPN Gateway/peer connections,
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 49 of 84
connections to Wildfire, connections to Panorama, connections to 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 [
 Connecting with remote VPN gateways/peers using IPsec,
 Connecting with Global Protect (VPN peer) using TLS
 Transmitting audit records to an audit server using IPsec or TLS,
 To retrieve the IP address mapping information with UIA using TLS,
 Communicating to WildFire and Panorama Management System using
TLS].
FTP_ITC.1/VPN – Inter-TSF Trusted Channel
FTP_ITC.1.1 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 The TSF shall permit [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 [remote VPN
gateways/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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 50 of 84
5.2.9 Stateful Traffic Filtering (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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 51 of 84
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;
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;
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 52 of 84
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.
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;
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 53 of 84
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].
PAN OS 9.1.8 Security Target Palo Alto Networks
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 process the following network traffic protocols:
 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 Traffic 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.
PAN OS 9.1.8 Security Target Palo Alto Networks
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 5 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 assurance activities specified in the following Supporting Documents apply to the TOE
evaluation:
 Supporting Document Mandatory Technical Document: Evaluation Activities for Network Device
cPP, September-2018, Version 2.1
 Supporting Document Mandatory Technical Document: Evaluation Activities for Stateful Traffic
Filter Firewalls PP-Module, September-2019, Version 1.3
 Supporting Document Mandatory Technical Document: PP-Module for Virtual Private Network
(VPN) Gateways Version 1.0, 2019-09-17
PAN OS 9.1.8 Security Target Palo Alto Networks
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 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! Reference source not found., [FW-Module], and [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. Please 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
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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 57 of 84
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 found.. 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 providing supporting
cryptographic functions. The following functions have been certified in accordance
with the identified standards.
Table 6 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
(#C1005):
DSA
ECDSA
RSA
VMs (#C999):
DSA
ECDSA
RSA
ECC key pair generation
(NIST curves P-256, P-384,
P-521)
FIPS PUB 186-4
RSA key generation (key
sizes 2048, 3072 bits)
FIPS PUB 186-4
FFC Schemes using Diffie-
Hellman group 14 that meet
the following: RFC 3526,
Section 3
RFC 3526, Section 3 N/A
Cryptographic Key Establishment
RSA based key
establishment
RSAES-PKCS1-v1_5 RSA = N/A
Appliances
(#C1005):
ECDSA based key
establishment
NIST SP 800-56A
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 58 of 84
FFC based key
establishment
NIST SP 800-56A Component
VMs (#C999):
Component
Key establishment scheme
using Diffie-Hellman group
14 that meets the following
RFC 3526, Section 3
RFC 3526, Section 3 N/A
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
(#C1005):
AES
VMs (#C999):
AES
Signature Generation and Verification
RSA Digital Signature
Algorithm (rDSA) (modulus
2048, 3072)
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
(#C1005):
RSA
VMs (#C999):
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
(#C1005):
ECDSA
VMs (#C999):
ECDSA
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
(#C1005):
SHS
VMs (#C999):
SHS
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 59 of 84
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
(#C1005):
HMAC
VMs (#C999):
HMAC
Random Bit Generation
CTR_DRBG (AES-256) ISO/IEC 18031:2011 Appliances
(#C1005):
DRBG
VMs (#C999):
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
TOE conforms to those conditions with deviations rationalized. Key generation is
among the identified sections.
Table 7 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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 60 of 84
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 establishment4 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 establishment5
schemes, and NIST Special Publication 800-56A for finite field-based key
establishment6 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 RFC
35267 section 3 key establishment scheme as specified in RFC 4253 section 6.5
(when Diffie-Hellman Group 14 is used).
FCS_CKM.4
Table 8 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 or 3072-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)
4
RSA-based key generation and establishment are used for TLS only (connection to the syslog server only)
5
Elliptic curve-based key generation and establishment are used for HTTPS, TLS, SSH, and IKE connections.
6
Finite field-based key generation and establishment are used for HTTPS and TLS connections.
7
Diffie-Hellman Group 14 based on RFC 3526, Section 3 are used for SSH and IKE connections.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 61 of 84
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, 192, 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)
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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 62 of 84
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.
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(1)
FCS_TLSC_EXT.2(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: RSA8 with key size of 2048
bits and 3072 bits, Diffie-Hellman Ephemeral parameters with key size of 2048 bits,
ECDHE implementing NIST curves secp256r1 and secp384r1. 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 distinguished name (DN) or
Subject Alternative Name (SAN) contained in a certificate does not match the
expected identifier for the peer.
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
8
RSA key establishment is used for the TLS client connection to the external syslog server only.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 63 of 84
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 secp384r1. The TOE denies
connections from clients requesting connections using SSL 2.0, SSL 3.0, or TLS
1.0.
The TOE can be configured as a TLS client for secure communication to an external
audit server. The TOE presents the Supported Elliptic Curves 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 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. 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_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
 TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
 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_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
 TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
 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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 64 of 84
 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 client) connection to Panorama, User Identification Agent (UIA) or
Wildfire (WF). Supports TLSv1.2 only, and DHE (finite-field based) and ECDHE
(elliptic curve-based) schemes. Mutual authentication is required.
 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
TOE (as TLS server) for the Web UI management and Global Protect (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
 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
FCS_SSHS_EXT.1 The TOE supports SSHv2 (compliant to RFCs 4251, 4252, 4253, 4254, 4344, 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, aes128-
gcm@openssh.com, and aes256-gcm@openssh.com for integrity and authenticity.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 65 of 84
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 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.
The 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) 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 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,
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 66 of 84
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 (aka rDSA) 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-based in FCS_CKM.2. In the IKEv1
phase 1 (main mode only) and phase 2 exchanges, the TOE and peer will agree on
the best DH group both can support. 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 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.
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. 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.
6.3 User Data Protection
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 67 of 84
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 user name (i.e., user
identity or ID), a password or X.509v3 certificate/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 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 user name 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-factors 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).
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 68 of 84
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 6 up to 15 characters. Note in FIPS-CC mode, the minimum
password length cannot be configured below 6 and for the default Admin only, the
minimum password length has a lower bound of 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). 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 recommended 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’
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) and HTTPS
connections. Public key infrastructure (PKI) credentials, such as Rivest, Shamir,
and Adelman (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 X509 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.
The TOE supports Online Certificate Status Protocol (OCSP) and Certificate
Revocation List (CRL) status verification for certificate profiles. If both are
configured, the devices first try the OCSP method; if the OCSP server is unavailable,
the devices use the CRL method.
The TOE uses the following rules for validating the extendedKeyUsage9 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
FIA_X509_EXT.2(1)
FIA_X509_EXT.2(2)
9
Certificates are not used for trusted updates or executable code integrity.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 69 of 84
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.
When establishing a TLS session, clients can use OCSP to check the revocation
status of the authentication certificate. The authenticating client sends a request
containing the serial number of the certificate to the OCSP responder (server). The
responder searches the database of the certificate authority (CA) that issued the
certificate and returns a response containing the status (good, revoked or unknown)
to the client. The advantage of the OCSP method is that it can verify status in real-
time, instead of depending on the issue frequency (hourly, daily, or weekly) of CRLs.
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 RFC
5759. 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),
IKE/IPsec connection to another firewall (VPN gateway), and for the TLS sessions
to the Panorama, UIA, GP and Wildfire, this behavior is configurable but in the
evaluated configuration, the recommended 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.
Apply the Certificate Profile to a specific TLS connection (e.g., from firewall to
Panorama or firewall to Wildfire).
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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 70 of 84
6.5 Security Management
FMT_MOF.1/ManualUpdate
FMT_MOF.1/Services
FMT_MOF.1/Functions
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, configure audit behavior, and
VPN keys/certificates are restricted to Security Administrators only. 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
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;
 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 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;
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 71 of 84
 Ability to configure audit behavior;
 Ability to start and stop services;
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
Administrator. These administrator roles (except Read-Only) are all considered
Security Administrator as defined in the Error! Reference source not found.
for the 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.
 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 X509
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/Self
Test
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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 72 of 84
 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
 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:
https://<TOE>/api/?type=op&cmd=<show><system><info></info></system></show>&
key=<APIkey>). 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) and encrypt
(using AES-256) 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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 73 of 84
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 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, and for cryptographic
operations based on time/date.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 74 of 84
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, x509v3 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.
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).
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 75 of 84
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, Panorama, UIA, and Wildfire using TLS trusted channel. The TOE
permits the following communications below:
 Connecting with remote VPN gateways/peers using IPsec,
 Connecting with Global Protect (VPN peer) using TLS,
 Transmitting audit records to an audit server using IPsec or TLS,
 To retrieve the IP address mapping information with UIA using TLS,
 Communicating to WildFire and Panorama Management System using TLS
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.
FTP_TRP.1/Admin The TOE provides SSH, HTTPS (TLSv1.1 and TLSv1.2), and IPsec10 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.
10
The HTTPS management session can be tunneled over IPsec to provide additional security.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 76 of 84
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.
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
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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 77 of 84
 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
 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:
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 78 of 84
 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
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
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 79 of 84
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.
 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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 80 of 84
 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 user11 (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”.
 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
11
Source user in policies is not within the scope of the evaluation.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 81 of 84
 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. The
timeout period due to inactivity is administrator configurable from 1 – 6044800 seconds.
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 140-2 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 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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 82 of 84
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, 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
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.
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 83 of 84
7. Protection Profile Claims
This ST is conformant to the [CFG_NDcPP-FW-VPNGW_V1.0], [NDcPP], [FW-Module], and [VPNGW-
Module].
PAN OS 9.1.8 Security Target Palo Alto Networks
Page 84 of 84
8. Rationale
This security target includes by reference the Error! Reference source not found., [FW-Module], and
[VPNGW-Module] Security Problem Definition, Security Objectives, and Security Assurance Requirements.
The security target makes no additions to the Error! Reference source not found., [FW-Module], and
[VPNGW-Module] assumptions. Security functional requirements have been reproduced verbatim with the
protection profile operations completed. Operations on the security requirements follow Error! Reference
source not found., [FW-Module], and [VPNGW-Module] application notes and assurance 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 complete.