Palo Alto Networks, Inc.
www.paloaltonetworks.com
© 2025 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.
FCS_TLSC_EXT
Palo Alto Networks
M-200, M-300, M-600, and
M-700 Hardware, and Virtual
Appliances all running
Panorama 11.1
Security Target
Version: 1.0
Date: March 20, 2025
Panorama 11.1 Security Target Palo Alto Networks
Page 2 of 58
Table of Contents
1. Security Target Introduction 4
1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION 4
1.2 CONFORMANCE CLAIMS 5
1.3 CONVENTIONS 6
1.3.1 Terminology 6
1.3.2 Acronyms 7
2. PRODUCT DESCRIPTION 8
2.1 TOE OVERVIEW 9
2.2 TOE ARCHITECTURE 10
2.2.1 Physical Boundaries 11
2.2.2 Logical Boundaries 14
2.3 TOE DOCUMENTATION 16
2.4 EXCLUDED FUNCTIONALITY 16
3. SECURITY PROBLEM DEFINITION 18
4. SECURITY OBJECTIVES 19
4.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT 19
5. IT SECURITY REQUIREMENTS 21
5.1 EXTENDED REQUIREMENTS 21
5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS 21
5.2.1 Security Audit (FAU) 22
5.2.2 Cryptographic Support (FCS) 25
5.2.3 Identification and Authentication (FIA) 34
5.2.4 Security Management (FMT) 35
5.2.5 Protection of the TSF (FPT) 36
5.2.6 TOE Access (FTA) 38
5.2.7 Trusted Path/Channels (FTP) 38
5.3 TOE SECURITY ASSURANCE REQUIREMENTS 39
6. TOE SUMMARY SPECIFICATION 40
6.1 SECURITY AUDIT 40
6.2 CRYPTOGRAPHIC SUPPORT 41
6.3 IDENTIFICATION AND AUTHENTICATION 50
6.4 SECURITY MANAGEMENT 52
6.5 PROTECTION OF THE TSF 54
6.6 TOE ACCESS 56
6.7 TRUSTED PATH/CHANNELS 56
7. PROTECTION PROFILE CLAIMS 57
8. RATIONALE 58
Panorama 11.1 Security Target Palo Alto Networks
Page 3 of 58
LIST OF FIGURES
Figure 1: TOE Deployment 9
Figure 2: TOE Architecture 10
LIST OF TABLES
Table 1 TOE Platforms 12
Table 2 Excluded Features 16
Table 3 TOE Security Functional Components 21
Table 4 Auditable Events 23
Table 5 Assurance Components 39
Table 6 Cryptographic Functions 41
Table 7 Private Keys and CSPs 44
Panorama 11.1 Security Target Palo Alto Networks
Page 4 of 58
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 a centralized management appliance running
version Panorama 11.1, provided by Palo Alto Networks Inc. Panorama is available as a virtual or physical
appliance, each of which supports licenses for managing up to 25, 100, or 1,000 next-generation firewalls.
The physical appliances include the M-200, M-300, M-600, and M-700 models and the virtual appliances
include Panorama virtual appliances which are used to simplify central management and collect information
on activity across all managed firewall and Wildfire appliances. Information can include network traffic, user
activity, threats which allows for the TOE to centrally analyze, investigate, and report on the aggregated
data.
The focus of this evaluation is on the TOE functionality supporting the claims in the collaborative Protection
Profile for Network Devices and Functional Package for Secure Shell. (See section 1.2 for specific version
information).
The only capabilities covered by the evaluation are those specified in the aforementioned Protection Profile,
all other capabilities are not covered in the evaluation. The security functionality specified in [NDcPP] and
[SSHPKG] include protection of communications between the TOE and trusted external IT entities (trusted
channel), protection of communications between the TOE and administrators (trusted path), identification
and authentication of administrators, auditing of security-relevant events, ability to verify the source and
integrity of updates to the TOE, implementation of session idle timeout, and the restricted use of FIPS
Approved algorithms and protocols.
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 M-200, M-300, M-600, and M-700 Hardware, and Virtual Appliances all
running Panorama 11.1 Security Target
ST Version – Version 1.0
ST Date – March 20, 2025
TOE Identification – Palo Alto Networks M-200, M-300, M-600, and M-700 Hardware, and Virtual
Appliances all running Panorama 11.1.
The Panorama virtual appliance is supported on the following hypervisors:
● VMware
o VMware ESXi with vSphere 7.0
● Microsoft Hyper-V Server 2019
● Kernel-based Virtual Machine (KVM) on Ubuntu 20.04
Evaluation testing included the following:
Panorama 11.1 Security Target Palo Alto Networks
Page 5 of 58
● VMware ESXi 7.0:
o Dell PowerEdge R740 Processor: Intel Xeon Gold 6248 (Cascade Lake microarchitecture)
with Broadcom 57416 NIC
o Memory: 128 GB RDIMM
● Hyper-V 2019 on Microsoft Hyper-V Server 2019 and KVM 4 on Ubuntu 20.04:
o Dell PowerEdge R740 Processor: Intel Xeon Gold 6248 (Cascade Lake microarchitecture)
with Broadcom 57416 NIC
o Memory: 128 GB RDIMM
● M-700 Hardware Appliance
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: This ST is conformant
to:
● collaborative Protection Profile for Network Devices, Version 3.0e, 6 December 2023 [NDcPP]
● Functional Package for Secure Shell (SSH) Version 1.0, 13 May 2021 [SSHPKG]
The following NIAP Technical Decisions apply to this PP/ST and have been accounted for in the ST
development and the conduct of the evaluation:
● TD0682: Addressing Ambiguity in FCS_SSHS_EXT.1 Tests
o TD updates test evaluation activities that apply to the TOE. [SSHPKG]
● TD0695: Choice of 128 or 256 bit size in AES-CTR in SSH Functional Package
o This TD has been applied to the TOE. [SSHPKG]
● TD0732: FCS_SSHS_EXT.1.3 Test 2 Update
o TD updates test evaluation activities that apply to the TOE. [SSHPKG]
● TD0777: Clarification to Selections for Auditable Events for FCS_SSH_EXT.1
o This TD has been applied. [SSHPKG]
● TD0836: NIT Technical Decision: Redundant Requirements in FPT_TST_EXT.1
o TD updates SFRs that apply to the TOE [NDcPP]
● TD0868: NIT Technical Decision: Clarification of time frames in FCS_IPSEC_EXT.1.7 and
FCS_IPSEC_EXT.1.8
o This TD is not applicable because the TOE does not use IPSec [NDcPP]
● TD0879: NIT Decision: Correction of Chapter Headings in CPP_ND_V3.0E
o This TD is not applicable because there are no claims for a local interface [NDcPP]
● TD0880: NIT Decision: Removal of Duplicate Selection in FMT_SMF.1.1
o This TD removes a duplicate selection [NDcPP]
Panorama 11.1 Security Target Palo Alto Networks
Page 6 of 58
● TD0886: Clarification to FAU_STG_EXT.1 Test 6
o This TD adds an application note to clarify a test activity that applies to the TOE [NDcPP]
● TD0899: NIT Technical Decision: Correction of Renegotiation Test for TLS 1.2
o This TD has been applied to incorporate the TD updates [NDcPP]
● TD0900: NIT Technical Decision: Clarification to Local Administrator Access in
FIA_UIA_EXT.1.3
o This TD has been incorporated; TD0900 modifies FIA_UIA_EXT.1.3 [NDcPP]
● Common Criteria for Information Technology Security Evaluation Part 2: Security functional
components, Version 3.1, Revision 5, April 2017.
● Part 2 Extended
● Common Criteria for Information Technology Security Evaluation Part 3: Security assurance
components, Version 3.1 Revision 5, April 2017.
● Part 3 Conformant.
1.3 Conventions
The following conventions have been applied in this document:
● Security Functional Requirements – Part 2 of the CC defines the approved set of operations that
may be applied to functional requirements: iteration, assignment, selection, and refinement.
● 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].
● Each Selection/Assignment operation completed by the ST author is bolded and italicized 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)).
1.2.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 Panorama.
Device Group Group the managed firewalls into logical units. A device group enables grouping based
on network segmentation, geographic location, organizational function, or any other
common aspect of firewalls that require similar policy configurations.
Log Collector Aggregate logs from managed firewalls. When generating reports, Panorama queries
the Log Collectors for log information, providing visibility into all the network activity
that the firewalls monitor.
PAN-DB A mode where the TOE functions as a URL filtering database as an on-premise
appliance.
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.
Panorama 11.1 Security Target Palo Alto Networks
Page 7 of 58
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.
1.2.2 Acronyms
AES Advanced Encryption Standard
CBC Cipher-Block Chaining
CC Common Criteria for Information Technology Security Evaluation
CEM Common Evaluation Methodology for Information Technology
Security
CM Configuration Management
CLI Command Line Interface
DH Diffie-Hellman
DRBG Deterministic Random Bit Generator
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
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IPsec Internet Protocol Security
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
URL Uniform Resource Locator
VM Virtual Machine
VPN Virtual Private Network
Panorama 11.1 Security Target Palo Alto Networks
Page 8 of 58
2. Product Description
Palo Alto Networks Panorama management appliances provide centralized monitoring and management of
Palo Alto Networks next-generation firewalls and Wildfire appliances. It provides a single location from
which administrators can oversee all applications, users, and content traversing the whole network, and then
use this knowledge to create application enablement policies that control and protect the network. Using
Panorama for centralized policy and firewall management increases operational efficiency in managing and
maintaining a network of firewalls.
This evaluation only includes the Panorama physical and virtual appliance models as identified in section 1.1.
Palo Alto Networks next-generation firewalls were evaluated previously, and information about them and
Wildfire are provided for completeness only.
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 WildFire appliance provides an on-premises WildFire private cloud, enabling the analysis of suspicious
files in a sandbox environment without requiring the firewall to send 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.
Panorama enables the administrator to effectively configure, manage, and monitor the firewalls and Wildfire
appliances with central oversight. Even though firewall and Wildfire appliances can be managed locally, by
using Panorama to manage the appliances, the following three major benefits can be achieved:
1. Centralized Configuration and Deployment - To simplify central management and rapid
deployment of the firewalls and WildFire appliances on the network, use Panorama to pre-stage
the firewalls and WildFire appliances for deployment. Administrators can then assemble the
firewalls into groups and create templates to apply a base network and device configuration and
use device groups to administer globally shared and local policy rules.
2. Aggregated Logging with Central Oversight for Analysis and Reporting - Collect information on
activity across all the managed firewalls on the network and centrally analyze, investigate, and
report on the data. This comprehensive view of network traffic, user activity, and the associated
risks empowers the administrators to respond to potential threats using the rich set of policies to
securely enable applications on the network.
3. Delegated Administration - Enables administrator to delegate or restrict access to global and local
firewall configurations and policies.
Panorama 11.1 Security Target Palo Alto Networks
Page 9 of 58
Figure 1: TOE Deployment
2.1 TOE Overview
The Target of Evaluation (TOE) is one or more Palo Alto Networks management appliance(s) that include
Panorama M-200, M-300, M-600, and M-700 appliances and virtual appliances all running Panorama
version 11.1. Panorama is available as a virtual or physical appliance, each of which supports licenses for
managing up to 25, 100, or 1,000 firewalls. The TOE type is a network device as specified in the NDcPP.
In a deployment architecture, the Panorama security management appliance provides the capability to
remotely manage multiple firewall appliances that control network traffic flow and WildFire appliances that
analyze suspicious files traversing the network. However, since the firewall and Wildfire appliances are in
the operational environment, these capabilities (i.e., stateful inspection filtering, IPsec VPN gateway, IPS/IDS
threat prevention) are not evaluated (out of scope). Only the secure communication channels from
Panorama to firewalls and Wildfires are claimed. In addition, the TOE is not a distributed TOE as defined in
the [NDcPP].
The administrators can deploy Panorama in the following system modes:
● Panorama - The appliance functions as a management server to manage firewalls and Dedicated
Log Collectors. The appliance also supports a local Log Collector to aggregate firewall logs. This
mode is the default mode.
● Management-Only - The appliance is a dedicated management appliance for Palo Alto Networks
firewalls and Dedicated Log Collectors. The appliance has no firewall log collection capabilities.
● Log Collector - The appliance functions as a Dedicated Log Collector. In this deployment, the
appliance has no web interface for administrative access, only a command line interface or CLI.
When in Log Collector mode, Panorama is intended to be managed by another manager in Panorama
or Management-Only mode (NOTE: this function is not evaluated). However, it provides a CLI with
all of the administrative functions necessary to configure and manage the device.
Regardless of which system mode is deployed, the TOE must also be configured to run in the Common
Criteria mode of operation described below. In addition, the TOE satisfies all mandatory SFRs regardless of
Panorama 11.1 Security Target Palo Alto Networks
Page 10 of 58
system modes though some selection-based requirements such as HTTPS may not be relevant (for example,
Log Collector mode does not support web interface).
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 requirements for startup and conditional self-tests as well as algorithm selection are enforced. In this
mode, only CC Approved cryptographic algorithms and key sizes are available. All tested models were placed
into the evaluated configuration by the lab, including the enabling of FIPS-CC mode.
2.2 TOE Architecture
The TOE high-level architecture is divided into four main subsystems: system software (SS); database (DB);
hardware (HW) and the hardened Linux-Derived operating system (OS). The system software provides
system management functionality including proprietary software, management interfaces (CLI and GUI),
cryptographic support (Palo Alto Networks Crypto Module), logging service (syslog-ng and auditd), web
service (nginx), and authentication service. The database provides a data repository for audit logs, user
account data, system data, configuration data, system log (i.e., syslog), and configuration logs. The operating
system provides a customized Linux kernel to enforce domain separation, memory management, disk access,
file I/O, network stacks (IPv4/IPv6), and communications with the underlying hardware components
including the network interface cards (NICs), memory, CPUs, and hard disks. Only services and libraries
required by the system software and DB are enabled in the OS. The virtual appliances will include the
hypervisor as well (not shown in figure 2).
The following diagram depicts both the hardware and software architecture of the TOE.
Figure 2: TOE Architecture
Panorama 11.1 Security Target Palo Alto Networks
Page 11 of 58
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.
● Virtual appliances installed on specified hardware - the VM-Series supports the exact security
functionalities available in the physical form factor appliances, allowing an administrator to safely
enable physical or virtual appliances that enable applications flowing into, and across their virtual
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
VMs. VMs are deployed in the system using Intel CPUs.
● Panorama OS software v11.1 – the software/firmware component that runs the appliance. For
VMs, Panorama OS is software and for hardware appliances, Panorama OS is firmware. Panorama
OS is built on top of a Linux kernel and runs along with NGINX (the web server that Palo Alto
Networks uses), syslog-ng, sshd, Palo Alto Networks Crypto Module, and various vendor-developed
applications that implement its capabilities.
The physical boundary of the TOE comprises the whole appliance (M-200, M-300, M-600, and M-700); and
the virtual appliances on specified hypervisor and hardware. The models only differ in their performance
capability (e.g., processor speed, memory, and disk space), but they all provide the same security
functionality.
The appliance attaches to a physical network and includes the following ports:
● M-200: 3 RJ-45 10Mbps/100Mbps/1000Mbps ports for network/management traffic (Ethernet
ports); 1 RJ-45 10Mbps/100Mbps/1000Mbps port to access the device GUI through an Ethernet
interface (management port); and 1 console port for connecting a serial console (management
console port).
● M-300: 1 RJ-45 100Mbps/1000Mbps/10000Mbps ports for network/management traffic
(Ethernet ports); 1 RJ-45 100Mbps/1000Mbps/10000Mbps port to access the device GUI through
an Ethernet interface (management port); and 1 console port for connecting a serial console
(management console port).
● M-600: 3 RJ-45 10Mbps/100Mbps/1000Mbps ports for network/management traffic (Ethernet
ports); 2 10 GigE ports for network/management traffic (Gigabit Ethernet ports); 1 RJ-45
10Mbps/100Mbps/1000Mbps port to access the device GUI through an Ethernet interface
(management port); and 1 console port for connecting a serial console (management console port).
● M-700: 1 RJ-45 100Mbps/1000Mbps/10000Mbps ports for network/management traffic
(Ethernet ports); 2 10 GigE ports for network/management traffic (Gigabit Ethernet ports); 1 RJ-45
100Mbps/1000Mbps/10000Mbps port to access the device GUI through an Ethernet interface
(management port); and 1 console port for connecting a serial console (management console port).
In the evaluated configuration, the TOE can be managed by:
● A computer 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).
System logs, which record information about the system such as authentication attempts, session idle
timeout, and sessions establishment, termination, failures, are logged and stored locally by default.
Configuration logs, which record all management actions are also logged and stored locally by default.
Panorama 11.1 Security Target Palo Alto Networks
Page 12 of 58
Table 1 TOE Platforms
Product
Identification
Illustration Description
M-200 Processor: Intel Xeon E5-
2620 v4 (Broadwell)
Memory: 128 GB DDR4
Maximum Logging Rate as
Manager: Undisclosed
Maximum Log Storage on
Appliance: 16 TB (4 8TB
RAID disks)
SSD Storage Space: 240
GB
M-300 Processor: Intel Xeon
Silver 4310 (Ice Lake)
Memory: 256 GB DDR4
Maximum Logging Rate as
Manager: Undisclosed
Maximum Log Storage on
Appliance: 32 TB (4 x 8TB
RAID disks)
SSD Storage Space: 480
GB
M-600 Processor: Intel Xeon E5-
2680 v4 (Broadwell)
Memory: 256 GB DDR4
Maximum Logging Rate as
Manager: Undisclosed
Maximum Log Storage on
Appliance: 48 TB (12 8TB
RAID disks)
SSD Storage Space: 240
GB
M-700 Processor: Intel Xeon
Silver 4316 (Ice Lake)
Memory: 512 GB DDR4
Panorama 11.1 Security Target Palo Alto Networks
Page 13 of 58
Product
Identification
Illustration Description
Maximum Logging Rate as
Manager: Undisclosed
Maximum Log Storage on
Appliance: 48 TB (12 8TB
RAID disks)
SSD Storage Space: 480
GB
Virtual Appliances
On VMware
ESXi
Processor: See section 1.1.
Memory: Up to 64 GB
(min 16 GB)
Maximum Logging Rate as
Manager: 10,000 logs per
second
Maximum Log Storage on
Appliance: 24 TB (12
virtual logging disks)
SSD Storage Space: N/A
On Hyper-V Processor: See section 1.1.
Memory: Up to 32 GB
(min 8 GB)
Maximum Logging Rate as
Manager: 10,000 logs per
second
Maximum Log Storage on
Appliance: 24 TB (12
virtual logging disks)
SSD Storage Space: N/A
On KVM Processor: See section 1.1.
Memory: Up to 32 GB
(min 8 GB)
Maximum Logging Rate as
Manager: 10,000 logs per
second
Panorama 11.1 Security Target Palo Alto Networks
Page 14 of 58
Product
Identification
Illustration Description
Maximum Log Storage on
Appliance: 24 TB (12
virtual logging disks)
SSD Storage Space: N/A
The operational environment includes the following:
● Syslog server
● Palo Alto Networks Firewall or Wildfire appliances
● Workstation
o Web browsers - Chrome (version 119 or later) browser
o SSHv2 client
2.2.2 Logical Boundaries
This section summarizes the security functions provided by the TOE:
● Security Audit
● Cryptographic Support
● Identification and Authentication
● Security Management
● Protection of the TSF
● TOE Access
● Trusted Path/Channels
2.2.2.1 Security Audit
The TOE is designed to be able to generate logs for security relevant events including the events specified
in [NDcPP] and [SSHPKG]. By default, the TOE stores the logs locally so they can be accessed by an
administrator. The TOE can also 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 (RBG), encryption/decryption, digital signature generation and verification, cryptographic
hashing, and keyed-hash message authentication features in support of higher-level cryptographic
protocols, including SSH and TLS. Note that to be in the evaluated configuration, the TOE must be
configured in FIPS-CC mode, which ensures the TOE’s configuration is consistent with the FIPS standard
and [NDcPP] and [SSHPKG]. All physical and virtual appliance included in the TOE (Palo Alto Networks
Crypto Module) are CAVP-validated and details are provided in the TOE Security Summary (TSS):
● The M-Series appliances are covered by CAVP certificates (#A3453).
o AES - [FCS_COP.1/DataEncryption]
o RSA, ECDSA - [FCS_COP.1/SigGen and FCS_CKM.1]
o SHS - [FCS_COP.1/Hash]
o HMAC - [FCS_COP/1/KeyedHash]
o DRBG - [FCS_RBG_EXT.1]
o KAS - [FCS_CKM.2]
Panorama 11.1 Security Target Palo Alto Networks
Page 15 of 58
● The Panorama virtual appliances are covered by CAVP certificates (#A3454).
o AES - [FCS_COP.1/DataEncryption]
o RSA, ECDSA - [FCS_COP.1/SigGen and FCS_CKM.1]
o SHS - [FCS_COP.1/Hash]
o HMAC - [FCS_COP/1/KeyedHash]
o DRBG - [FCS_RBG_EXT.1]
o KAS - [FCS_CKM.2]
2.2.2.3 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 interfaces via HTTPS (GUI) and SSH (CLI) for interactive administrator sessions and programmatic
interfaces via HTTPS for XML and REST APIs.
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 human user and to
associate that user with an authorized role. In addition, the TOE can authenticate users using X509
certificates and can be configured to lock a user out after a configurable number of unsuccessful
authentication attempts.
2.2.2.4 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/CLI
using an HTTPS/TLS 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 audit function, configure the
idle timeout, and review the audit trail. The TOE provides pre-defined Security Administrator, Audit
Administrator, and Cryptographic Administrator roles. These administrator roles are all considered Security
Administrator as defined in the [NDcPP] for the purposes of this ST.
2.2.2.5 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. It also includes a
mechanism to verify TOE updates to prevent malicious or other unexpected changes in the TOE.
2.2.2.6 TOE Access
The TOE can be configured to display an administrator-defined advisory banner before establishing an
administrative user session and to terminate remote interactive sessions after a configurable period of
inactivity. It also provides users the capability to terminate their own interactive sessions.
Panorama 11.1 Security Target Palo Alto Networks
Page 16 of 58
2.2.2.7 Trusted Path/Channels
The TOE protects interactive communication with administrators using SSH or HTTP over TLS (HTTPS). SSH
and TLS ensure both integrity and disclosure protection.
The TOE protects communication with the syslog server, Palo Alto Networks firewalls and Wildfire
Appliances using TLS connections.
2.3 TOE Documentation
Palo Alto Networks Inc. offers a series of documents that describe the installation of Palo Alto Networks
Panorama as well as guidance for subsequent use and administration of the applicable security features.
Additionally, the evaluated guidance documents are downloadable from the Product Compliant List on the
NIAP website.
For Panorama v11.1, these documents include:
● Palo Alto Networks Common Criteria Evaluated Configuration Guide (CCECG) for Panorama
11.1 Publication Date: March 20, 2025
● Panorama Administrator’s Guide Version 11.1, Last Revised: August 19, 2024
● PAN-OS® and PanoramaTM
API Usage Guide Version 11.1 & later Last Revised: August 21,
2024
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. 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 and HTTPS only as the management
protocols to manage the TOE.
External Authentication Servers The NDcPP does not require external authentication servers.
Shell and Console Access The shell and console access are only allowed for pre-
operational installation, configuration, and post-operational
maintenance and troubleshooting.
API request over HTTP By default, the TOE support API requests over HTTPS only.
API request over HTTP is disabled and cannot be enabled in
the evaluated configuration.
Stateful inspection filtering, VPN
gateway, IPS/IDS threat
prevention, URL filtering (PAN-
DB), Log forwarding, and
Malware sandboxing.
These features are provided by Palo Alto Networks firewalls
and Wildfire appliances and are not included in this evaluation.
Only the secure TLS connections between the firewalls and
Wildfire to the TOE were evaluated.
Panorama 11.1 Security Target Palo Alto Networks
Page 17 of 58
Feature Description
Centralized Device
Management.
These features (e.g., Policy Template and Push, Device Group)
were not evaluated. Only the secure TLS connections between
the firewalls and Wildfire to the TOE were evaluated.
Any features not associated with
SFRs in claimed NDcPP
NDcPP forbids adding additional requirements to the Security
Target (ST). If additional functionalities are mentioned in the ST,
it is for completeness only.
Panorama 11.1 Security Target Palo Alto Networks
Page 18 of 58
3. Security Problem Definition
This security target includes by reference the Security Problem Definition (composed of organizational
policies, threat statements, and assumption) from [NDcPP].
In general, the [NDcPP] has presented a Security Problem Definition appropriate for network infrastructure
devices, such as firewalls, routers, managers and as such is applicable to the Palo Alto TOE. NOTE:
A.COMPONENTS_RUNNING is not applicable because this is not a distributed TOE. [NDcPP] also has
virtualization assumptions that are applicable to the virtual TOE only.
Panorama 11.1 Security Target Palo Alto Networks
Page 19 of 58
4. Security Objectives
Like the Security Problem Definition, this security target includes by reference the Security Objectives from
the [NDcPP]. 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] has presented Security Objectives appropriate for network infrastructure devices,
such as is applicable to the Palo Alto TOE. NOTE: OE.COMPONENTS_RUNNING is not applicable because
this is not a distributed TOE.
4.1 Security Objectives for the Operational Environment
OE.PHYSICAL Physical security, commensurate with the
value of the TOE and the data it contains, is provided by
the environment.
OE.NO_GENERAL_PURPOSE There are no general-
purpose computing capabilities (e.g., compilers or user
applications) available on the TOE, other than those
services necessary for the operation, administration and
support of the TOE. Note: For vNDs the TOE includes
only the contents of the its own VM, and does not include
other VMs or the VS.
OE.NO_THRU_TRAFFIC_PROTECTION The TOE does
not provide any protection of traffic that traverses it. It is
assumed that protection of this traffic will be covered by
other security and assurance measures in the operational
environment.
OE.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 vNDs, this includes the VS
Administrator responsible for configuring the VMs that
implement ND functionality.
For TOEs supporting X.509v3 certificate-based
authentication, the Security Administrator(s) are assumed
to monitor the revocation status of all certificates in the
TOE's trust store and to remove any certificate from the
Panorama 11.1 Security Target Palo Alto Networks
Page 20 of 58
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.
For vNDs, this applies when the physical platform on
which the VM runs is removed from its operational
environment.
OE.VM_CONFIGURATION For vNDs, the Security
Administrator ensures that the VS and VMs are configured
to
● reduce the attack surface of VMs as much as
possible while supporting ND functionality (e.g.,
remove unnecessary virtual hardware, turn off
unused inter-VM communications mechanisms),
and
● correctly implement ND functionality (e.g., ensure
virtual networking is properly configured to
support network traffic, management channels,
and audit reporting).
The VS should be operated in a manner that reduces the
likelihood that vND operations are adversely affected by
virtualisation features such as cloning, save/restore,
suspend/resume, and live migration.
If possible, the VS should be configured to make use of
features that leverage the VS’s privileged position to
provide additional security functionality. Such features
could include malware detection through VM
introspection, measured VM boot, or VM snapshot for
forensic analysis.
Panorama 11.1 Security Target Palo Alto Networks
Page 21 of 58
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] and [SSHPKG].
The SARs are the set of mandatory SARs and optional ALC_FLR.3 specified in [NDcPP].
5.1 Extended Requirements
All the extended requirements in this ST have been drawn from the [NDcPP] and [SSHPKG]. The [NDcPP]
and [SSHPKG] define all the extended SFRs (*_EXT) and since they are not redefined in this ST, the [NDcPP]
and [SSHPKG] should be consulted for more information regarding those CC extensions.
5.2 TOE Security Functional Requirements
The following table identifies the SFRs that are satisfied by the Palo Alto TOE.
Table 3 TOE Security Functional Components
Requirement Class Requirement Component
FAU: Security Audit FAU_GEN.1: Audit Data Generation
FAU_GEN.2: User Identity Association
FAU_STG_EXT.1: Protected Audit Event Storage
FAU_STG.1: Protected Audit Trail Storage
FCS: Cryptographic
Support
FCS_CKM.1: Cryptographic Key Generation
FCS_CKM.2: Cryptographic Key Establishment
FCS_CKM.4: Cryptographic Key Destruction
FCS_COP.1/DataEncryption: Cryptographic Operation (AES Data
Encryption/Decryption)
FCS_COP.1/SigGen: Cryptographic Operation (Signature Generation and
Verification)
FCS_COP.1/Hash: Cryptographic Operation (Hash Algorithm)
FCS_COP.1/KeyedHash: Cryptographic Operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1: Random Bit Generation
FCS_HTTPS_EXT.1: HTTPS Protocol
FCS_SSH_EXT.1: SSH Protocol
FCS_SSHS_EXT.1: SSH Protocol - Server
FCS_TLSC_EXT.1: TLS Client Protocol
FCS_TLSS_EXT.1(1): TLS Server Protocol (Web UI Connection)
FCS_TLSS_EXT.1(2): TLS Server Protocol (Firewall and WF Connections)
FCS_TLSS_EXT.2: TLS Server Support for Mutual Authentication
Panorama 11.1 Security Target Palo Alto Networks
Page 22 of 58
Requirement Class Requirement Component
FIA: Identification and
Authentication
FIA_AFL.1: Authentication Failure Handling
FIA_PMG_EXT.1: Password Management
FIA_UIA_EXT.1: User Identification and Authentication
FIA_X509_EXT.1/Rev: X.509 Certificate Validation
FIA_X509_EXT.2: X.509 Certificate Authentication
FIA_X509_EXT.3: X.509 Certificate Requests
FMT: Security
Management
FMT_MOF.1/ManualUpdate: Management of Security Functions
Behaviour
FMT_MTD.1/CoreData: Management of TSF Data
FMT_SMF.1: Specification of Management Functions
FMT_SMR.2: Restrictions on Security Roles
FPT: Protection of the TSF FPT_SKP_EXT.1: Protection of TSF Data (for reading of all symmetric
keys)
FPT_APW_EXT.1: Protection of Administrator Passwords
FPT_STM_EXT.1: Reliable Time Stamps
FPT_TST_EXT.1: TSF Testing
FPT_TUD_EXT.1: Trusted Update
FTA: TOE Access FTA_SSL.3: TSF-initiated Termination
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_TRP.1/Admin: Trusted Path
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 Administrator account shall be logged if
individual 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 Administrator account shall be logged)];
d) Specifically defined auditable events listed in Table 4
Panorama 11.1 Security Target Palo Alto Networks
Page 23 of 58
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 (if applicable), and the
outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the cPP/ST, 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 Configuration of local audit settings. Identity of account making
changes to the audit
configuration.
FAU_STG.1 None. None.
FCS_CKM.1 None. None.
FCS_CKM.2 None. None.
FCS_CKM.4 None. None.
FCS_COP.1/DataEncryption None. None.
FCS_COP.1/SigGen None. None.
FCS_COP.1/Hash None. None.
FCS_COP.1/KeyedHash None. None.
FCS_RBG_EXT.1 None. None
FCS_HTTPS_EXT.1 Failure to establish an HTTPS
session.
Reason for failure
FCS_SSH_EXT.1 ● [Failure to establish a SSH
session]
● [Establishment of SSH
connection]
● [Termination of SSH
connection session]
● [Reason for failure and
Non-TOE endpoint of
connection (IP Address)]
● [Non-TOE endpoint of
connection (IP Address)]
● [Non-TOE endpoint of
connection (IP Address)]
● [None] ● [None]
FCS_SSHS_EXT.1 No events specified. N/A
FCS_TLSC_EXT.1 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 authenticate the client Reason for failure
FIA_AFL.1 Unsuccessful login attempts limit is
met or exceeded.
Origin of the attempt (e.g., IP
address)
Panorama 11.1 Security Target Palo Alto Networks
Page 24 of 58
Requirement Auditable Events Additional Audit Record
Contents
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_X509_EXT.1/Rev ● Unsuccessful attempt to
validate a certificate
● Any addition, replacement
or removal of trust anchors1
in the TOE's trust store
● Reason for failure of
certificate validation
● Identification of
certificates added,
replaced or removed as
trust anchor in the
TOE's trust store
FIA_X509_EXT.2 None. None.
FIA_X509_EXT.3 None. None.
FMT_MOF.1/ManualUpdate Any attempt to initiate a manual
update
None.
FMT_MTD.1/CoreData None. None.
FMT_SMF.1 All management activities of TSF
data.
None.
FMT_SMR.2 None. None.
FPT_SKP_EXT.1 None. None.
FPT_APW_EXT.1 None. None.
FPT_TST_EXT.1 None. None.
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.3 The termination of a remote session
by the session locking mechanism.
None.
FTA_SSL.4 The termination of an interactive
session.
None.
FTA_TAB.1 None. None.
FTP_ITC.1 ● Initiation of the trusted
channel.
● Termination of the trusted
channel.
● None
● None
● Reason for failure
1
Importing CA certificate(s) or generating CA certificate(s) internally will implicitly set them as trust anchor.
Panorama 11.1 Security Target Palo Alto Networks
Page 25 of 58
Requirement Auditable Events Additional Audit Record
Contents
● Failure of the trusted
channel functions.
FTP_TRP.1/Admin ● Initiation of the trusted
path.
● Termination of the trusted
path.
● Failures of the trusted path
functions.
● None
● None
● Reason for failure
FAU_GEN.2 – User Identity Association
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be
able to associate each auditable event with the identity of the user that caused the event.
FAU_STG_EXT.1 – Protected Audit Event Storage
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data
to an external IT entity using a trusted channel according to FTP_ITC.1.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the
TOE itself. In addition [
● The TOE shall consist of a single standalone component that stores audit data
locally].
FAU_STG_EXT.1.3 The TSF shall maintain a [log file] of audit records in the
event that an interruption of communication with the remote audit server occurs.
FAU_STG_EXT.1.4 The TSF shall be able to store [persistent] audit records
locally with a minimum storage size of [45 MB].
FAU_STG_EXT.1.5 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.
FAU_STG_EXT.1.6 The TSF shall provide the following mechanisms for
administrative access to locally stored audit records [ability to view locally].
FAU_STG.1 – Protected Audit Trail Storage
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from
unauthorised deletion.
FAU_STG.1.2 The TSF shall be able to prevent unauthorised modifications to the stored
audit records in the audit trail.
5.2.2 Cryptographic Support (FCS)
FCS_CKM.1 – Cryptographic Key Generation
Panorama 11.1 Security Target Palo Alto Networks
Page 26 of 58
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-bits, 3072-bits, or 4096-
bits] that meet the following: FIPS PUB 186-4, “Digital Signature Standard
(DSS)”, Appendix B.3;
● ECC schemes using “NIST curves” [P-256, P-384, P-521] that meet the
following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4;
● FFC Schemes using ‘safe-prime’ groups that meet the following: “NIST Special
Publication 800-56A Revision 3, Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography” and [RFC
3526].
] and specified cryptographic key sizes [assignment: cryptographic key sizes]
that meet the following: [assignment: list of standards].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: [
● Elliptic curve-based key establishment schemes that meet the following: NIST
Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”;
● FFC Schemes using “safe-prime” groups that meet the following: ‘NIST Special
Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography” and [groups
listed in RFC 3526].
] that meets the following: [assignment: list of standards].
FCS_CKM.4 – Cryptographic Key Destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method
● For plaintext keys in volatile storage, the destruction shall be executed by a
[single overwrite consisting of [a pseudo-random pattern using the TSF’s
RBG]];
● For plaintext keys in non-volatile storage, the destruction shall be executed by
the invocation of an interface provided by a part of the TSF that [
o logically addresses the storage location of the key and performs a
[[three]-pass] overwrite consisting of [[a different alternating pattern
that does not contain any CSP]];
that meets the following: No Standard.
FCS_COP.1/DataEncryption – Cryptographic Operation (AES Data
Encryption/Decryption)
FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in
accordance with a specified cryptographic algorithm AES used in [CBC, CTR, GCM]
mode and cryptographic key sizes [128 bits, 256 bits] that meet the following: AES
Panorama 11.1 Security Target Palo Alto Networks
Page 27 of 58
as specified in ISO 18033-3, [CBC as specified in ISO 10116, CTR as specified in ISO
10116, GCM as specified in ISO 19772].
FCS_COP.1/SigGen – Cryptographic Operation (Signature Generation and Verification)
FCS_COP.1.1/SigGen The TSF shall perform cryptographic signature services
(generation and verification) in accordance with a specified cryptographic algorithm
[
● RSA Digital Signature Algorithm,
● Elliptic Curve Digital Signature Algorithm
] and cryptographic key sizes [
● For RSA: modulus 2048 bits or greater,
● For ECDSA: 256 bits or greater
] that meet the following: [
● For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Section 5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or
RSASSA-PKCS1v1_5; ISO/IEC 9796-2, Digital signature scheme 2 or Digital
Signature scheme 3,
● For ECDSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”,
Section 6 and Appendix D, Implementing “NIST curves” [P-256, P-384, P-
521]; ISO/IEC 14888-3, Section 6.4
].
FCS_COP.1/Hash – Cryptographic Operation (Hash Algorithm)
FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in
accordance with a specified cryptographic algorithm [SHA-1, SHA-256, SHA-384,
SHA-512] and cryptographic key sizes [assignment: cryptographic key sizes] and
message digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC
10118-3:2004.
FCS_COP.1/KeyedHash – Cryptographic Operation (Keyed Hash Algorithm)
FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message
authentication in accordance with a specified cryptographic algorithm [HMAC-SHA-
1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, implicit] and cryptographic
key sizes [160, 256, 384, 512] and message digest sizes [160, 256, 384, 512] bits
that meet the following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”.
FCS_HTTPS_EXT.1 – HTTPS Protocol
FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with
RFC 2818.
FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS protocol using TLS.
FCS_RBG_EXT.1 – Random Bit Generation
Panorama 11.1 Security Target Palo Alto Networks
Page 28 of 58
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit
generation services in accordance with ISO/IEC 18031:2011 using [CTR_DRBG
(AES)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one
entropy source that accumulates entropy from [[one] platform-based noise source]
with 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_SSH_EXT.1 – SSH Protocol
FCS_SSH_EXT.1.1 The TSF shall implement SSH acting as a [server] in
accordance with that complies with RFCs 4251, 4252, 4253, 4254, [4344, 5647,
5656, 6668, 8332] and [no other standard].
FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol
implementation supports the following authentication methods: [
● “password” (RFC 4252),
● “keyboard-interactive” (RFC 4252),
● “publickey” (RFC 4252): [
o ssh-rsa (RFC 4253),
o rsa-sha2-256 (RFC 8332),
o rsa-sha2-512 (RFC 8332)
]
] and no other methods.
FCS_SSH_EXT.1.3 The TSF shall ensure that, as described in RFC 4253,
packets greater than [262,105 bytes] in an SSH transport connection are dropped.
FCS_SSH_EXT.1.4 The TSF shall protect data in transit from unauthorised
disclosure using the following mechanisms: [
● aes128-cbc (RFC 4253),
● aes256-cbc (RFC 4253),
● aes128-ctr (RFC 4344),
● aes256-ctr (RFC 4344),
● aes128-gcm@openssh.com (RFC 5647),
● aes256-gcm@openssh.com (RFC 5647)
] and no other mechanisms.
FCS_SSH_EXT.1.5 The TSF shall protect data in transit from modification,
deletion, and insertion using: [
● hmac-sha2-256 (RFC 6668),
● hmac-sha2-512 (RFC 6668),
● implicit
] and no other mechanisms.
FCS_SSH_EXT.1.6 The TSF shall establish a shared secret with its peer using:
[
● ecdh-sha2-nistp256 (RFC 5656),
● ecdh-sha2-nistp384 (RFC 5656),
● ecdh-sha2-nistp521 (RFC 5656)
] and no other mechanisms.
FCS_SSH_EXT.1.7 The TSF shall use SSH KDF as defined in [
Panorama 11.1 Security Target Palo Alto Networks
Page 29 of 58
● RFC 5656 (Section 4)
] to derive the following cryptographic keys from a shared secret: session keys.
FCS_SSH_EXT.1.8 The TSF shall ensure that [
● a rekey of the session keys
] occurs when any of the following thresholds are met:
● one hour connection time
● no more than one gigabyte of transmitted data, or
● no more than one gigabyte of received data.
FCS_SSHS_EXT.1 – SSH Protocol - Server
FCS_SSHS_EXT.1.1 The TSF shall authenticate itself to its peer (SSH Client)
using: [
● ssh-rsa (RFC 4253),
● rsa-sha2-256 (RFC 8332),
● rsa-sha2-512 (RFC 8332),
● ecdsa-sha2-nistp256 (RFC 5656),
● ecdsa-sha2-nistp384 (RFC 5656),
● ecdsa-sha2-nistp521 (RFC 5656)
].
FCS_TLSC_EXT.1 – TLS Client Protocol
FCS_TLSC_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246)] supporting
the following ciphersuites:
[
● TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
● TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
● TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
● TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
● TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
● TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
● TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246
● TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
● TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
● TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC
5289
● TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
● TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
● TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
● TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
] and no other ciphersuites.
Panorama 11.1 Security Target Palo Alto Networks
Page 30 of 58
FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifiers matches
[the reference identifier per RFC 6125 Section 6] and no other attribute types].
FCS_TLSC_EXT.1.3 The TSF shall not establish a trusted channel if the server
certificate is invalid [
● without any administrator override mechanism].
FCS_TLSC_EXT.1.4 The TSF shall [present the Supported Groups Extension with
the following curves/groups: [secp256r1, secp384r1, secp521r1] and no other
curves/groups] in the Client Hello.
FCS_TLSC_EXT.1.5 The TSF shall [
● present the signature_algorithms extension with support for the following
algorithms: [
o rsa_pkcs1 with sha256(0x0401),
o rsa_pkcs1with sha384(0x0501),
o rsa_pkcs1 with sha512(0x0601),
o ecdsa_secp256r1 with sha256(0x0403),
o ecdsa_secp384r1 with sha384(0x0503),
o ecdsa_secp521r1 with sha512(0x0603),
o rsa_pss_rsae with sha256(0x0804),
o rsa_pss_rsae with sha384(0x0805),
o rsa_pss_rsae with sha512(0x0806),
] and no other algorithms;
].
FCS_TLSC_EXT.1.6 The TSF [does not provide] the ability to configure the list
of supported ciphersuites as defined in FCS_TLSC_EXT.1.1.
FCS_TLSC_EXT.1.7 The TSF shall prohibit the use of the following extensions:
● Early data extension
● Post-handshake client authentication according to RFC 8446, Section
4.2.6.
FCS_TLSC_EXT.1.8 The TSF shall [not use PSKs].
FCS_TLSC_EXT.1.9 The TSF shall [reject [TLS 1.2] renegotiation attempts].
FCS_TLSS_EXT.1(1) - TLS Server Protocol (Web UI Connection)
FCS_TLSS_EXT.1.1(1) The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.3 (RFC
8446)] and reject all other TLS and SSL versions. The TLS implementation will
support the following ciphersuites:
[
● 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_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
● TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
Panorama 11.1 Security Target Palo Alto Networks
Page 31 of 58
● 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
● TLS_AES_128_GCM_SHA256
● TLS_AES_256_GCM_SHA384
] and no other ciphersuites.
FCS_TLSS_EXT.1.2(1) The TSF shall authenticate itself using X.509 certificate(s)
using [RSA with key size [2048, 3072, 4096] bits; ECDSA over NIST curves
[secp256r1, secp384r1, secp521r1] and no other curves].
FCS_TLSS_EXT.1.3(1) The TSF shall perform key exchange using: [
● EC Diffie-Hellman key agreement over NIST curves [secp256r1, secp384r1,
secp521r1] and no other curves;
● Diffie-Hellman parameters [of size 2048 bits]
].
Application Note: For ECDHE, this is supported for both TLSv1.2 and TLSv1.3. For DHE, this is only supported for
TLSv1.2.
FCS_TLSS_EXT.1.4(1) The TSF shall support [session resumption based on session
tickets according to RFC 5077 (TLS 1.2), session resumption according to RFC 8446
(TLS 1.3)].
FCS_TLSS_EXT.1.5(1) The TSF [provides] the ability to configure the list of
supported ciphersuites as defined in FCS_TLSS_EXT.1.1(1).
FCS_TLSS_EXT.1.6(1) The TSF shall prohibit the use of the following extensions:
● Early data extension
FCS_TLSS_EXT.1.7(1) The TSF shall [not use PSKs].
FCS_TLSS_EXT.1.8(1) The TSF shall [reject [TLS 1.2, TLS 1.3] renegotiation
attempts].
Application Note: For the management connection, the TOE is the TLS server.
Panorama 11.1 Security Target Palo Alto Networks
Page 32 of 58
FCS_TLSS_EXT.1(2) - TLS Server Protocol (Firewall and WF Connections)
FCS_TLSS_EXT.1.1(2) The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.3 (RFC
8446)] and reject all other TLS and SSL versions. The TLS implementation will
support the following ciphersuites:
[
● TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
● TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 8422
● TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
● TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
● TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 8422
● TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC
5289
● TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 8422
● TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC
5289
● TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC
5289
● TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 8422
● TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
● TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
● TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
● TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
● TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
● TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
● TLS_AES_256_GCM_SHA384
● TLS_AES_128_GCM_SHA256
] and no other ciphersuites.
FCS_TLSS_EXT.1.2(2) The TSF shall authenticate itself using X.509 certificate(s)
using [RSA with key size [2048, 3072, 4096] bits; ECDSA over NIST curves
[secp256r1, secp384r1, secp521r1] and no other curves].
FCS_TLSS_EXT.1.3(2) The TSF shall perform key exchange using: [
● EC Diffie-Hellman key agreement over NIST curves [secp256r1, secp384r1,
secp521r1] and no other curves;
● Diffie-Hellman parameters [of size 2048 bits]
].
Application Note: For ECDHE, this is supported for both TLSv1.2 and TLSv1.3. For DHE, this is only supported for
TLSv1.2.
FCS_TLSS_EXT.1.4(2) The TSF shall support [session resumption based on session
tickets according to RFC 5077 (TLS 1.2), session resumption according to RFC 8446
(TLS 1.3)].
Panorama 11.1 Security Target Palo Alto Networks
Page 33 of 58
FCS_TLSS_EXT.1.5(2) The TSF [does not provide] the ability to configure the list
of supported ciphersuites as defined in FCS_TLSS_EXT.1.1(2).
FCS_TLSS_EXT.1.6(2) The TSF shall prohibit the use of the following extensions:
● Early data extension
FCS_TLSS_EXT.1.7(2) The TSF shall [not use PSKs].
FCS_TLSS_EXT.1.8(2) The TSF shall [reject [TLS 1.2, TLS 1.3] renegotiation
attempts].
Application Note: For the Firewall and WildFire connections, the TOE is the TLS server.
FCS_TLSS_EXT.2 - TLS Server Support for Mutual Authentication
FCS_TLSS_EXT.2.1 The TSF shall support TLS communication with mutual
authentication of TLS clients using X.509v3 certificates and shall [
● reject the connection if the client either does not provide a client certificate at
all or the client certificate cannot be successfully validated by the TOE (except
for override mechanisms that might be defined in FCS_TLSS_EXT.2.2) ('hard
fail')
].
FCS_TLSS_EXT.2.2 When establishing a trusted channel, by default the TSF
shall not establish a trusted channel if the client certificate is invalid. The TSF shall
also [
• not implement any administrator override mechanism
].
FCS_TLSS_EXT.2.3 The TSF shall not establish a trusted channel if the
identifier contained in a certificate does not match an expected identifier for the
client. If the identifier is a Fully Qualified Domain Name (FQDN), then the TSF shall
match the identifiers according to RFC 6125, otherwise the TSF shall parse the
identifier from the certificate and match the identifier against the expected
identifier of the client as described in the TSS.
FCS_TLSS_EXT.2.4 The TSF shall present a [TLS 1.2, TLS 1.3] Certificate
Request message containing the following algorithms: [
● rsa_pkcs1 with sha256(0x0401),
● rsa_pkcs1with sha384(0x0501),
● rsa_pkcs1 with sha512(0x0601),
● ecdsa_secp256r1 with sha256(0x0403),
● ecdsa_secp384r1 with sha384(0x0503),
] and no other algorithms.
Panorama 11.1 Security Target Palo Alto Networks
Page 34 of 58
Application Note: For the management and device connections, the TOE is the TLS server. Mutual authentication
is supported for management connection but is optional and can be configured. For the connections to the WF or
firewall (i.e., device connections), mutual authentication is required and must be configured.
5.2.3 Identification and Authentication (FIA)
FIA_AFL.1 – Authentication Failure Handling
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 a remote session using any authentication method that involves a password until
an Administrator defined time period has elapsed].
FIA_PMG_EXT.1 – Password Management
FIA_PMG_EXT.1.1 The TSF shall provide the following password
management capabilities for administrative passwords:
1. Passwords shall be able to be composed of any combination of upper and
lower case letters, numbers, and the following special characters: [“!”, “@”,
“#”, “$”, “%”, “^”, “&”, “*”, “(”, “)”, [“’”, “+”, “,”, “-”, “.”, “/”, “:”, “;”, “<”, “=”, “>”, “[”,
“\”, “]”, “_”, “`”, “{”, “}”, “~”, and “all Unicode characters”]];
2. Minimum password length shall be configurable to between [8] and [16]
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]].
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_UIA_EXT.1.3 The TSF shall provide the following remote authentication
mechanisms [Web GUI password, SSH password, SSH public key, X.509 certificate]
and [no other mechanism]. The TSF shall provide the following local authentication
mechanisms [none].
FIA_UIA_EXT.1.4 The TSF shall authenticate any administrator user’s
claimed identity according to each mechanism specified in FIA_UIA_EXT.1.3.
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.
Panorama 11.1 Security Target Palo Alto Networks
Page 35 of 58
● 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].
● 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 DTLS/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 DTLS/TLS shall have the Client
Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the
extendedKeyUsage field.
o OCSP certificates presented for OCSP responses shall have the OCSP
Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the
extendedKeyUsage field.
FIA_X509_EXT.1.2/Rev The TSF shall only treat a certificate as a CA certificate if
the basicConstraints extension is present and the CA flag is set to TRUE.
FIA_X509_EXT.2 – X.509 Certificate Authentication
FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC
5280 to support authentication for [TLS, HTTPS], and [no additional uses].
FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine
the validity of a certificate, the TSF shall [not accept the certificate].
FIA_X509_EXT.3 – X.509 Certificate Requests
FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request as specified
by RFC 2986 and be able to provide the following information in the request: public
key and [Common Name, Organization, Organizational Unit, Country].
FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the
Root CA upon receiving the CA Certificate Response.
5.2.4 Security Management (FMT)2
FMT_MOF.1/ManualUpdate - Management of Security Functions Behaviour
FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the
functions to perform manual updates to Security Administrators.
FMT_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.
2
Note: FMT_SMF.1.1 has been updated to address TD0880
Panorama 11.1 Security Target Palo Alto Networks
Page 36 of 58
FMT_MTD.1/CryptoKeys – Management of TSF Data
FMT_MTD.1.1/CryptoKeys The TSF shall restrict the ability to manage the
cryptographic keys to Security Administrators.
FMT_SMF.1 – Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions:
● Ability to administer the TOE remotely;
● Ability to configure the access banner;
● Ability to configure the remote session inactivity time before session termination;
● Ability to update the TOE, and to verify the updates using digital signature
capability prior to installing those updates;
[
o Ability to configure local audit behaviour (e.g. changes to storage locations
for audit; changes to behaviour when local audit storage space is full;
changes to local audit storage size);
o Ability to modify the behaviour of the transmission of audit data to an
external IT entity;
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 manage the cryptographic keys;
o Ability to configure the cryptographic functionality;
o Ability to configure thresholds for SSH rekeying;
o Ability to configure the list of supported (D)TLS ciphers;
o Ability to set the time which is used for time-stamps;
o Ability to manage the TOE's trust store and designate X.509v3 certificates
as trust anchors;
o Ability to generate Certificate Signing Request (CSR) and process CA
certificate response;
o Ability to configure the authentication failure parameters for FIA_AFL.1;
o Ability to manage the trusted public keys database;
].
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 remotely
are satisfied.
5.2.5 Protection of the TSF (FPT)
FPT_SKP_EXT.1 – Protection of TSF Data (for reading of all symmetric keys)
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys,
symmetric keys, and private keys.
Panorama 11.1 Security Target Palo Alto Networks
Page 37 of 58
FPT_APW_EXT.1 – Protection of Administrator Passwords
FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-
plaintext form.
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext
administrative passwords.
FPT_STM_EXT.1 – Reliable Time Stamps
FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for
its own use.
FPT_STM_EXT.1.2 The TSF shall [allow the Security Administrator to set the
time].
FPT_TST_EXT.1 – TSF Testing
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests:
● During initial start-up (on power on) to verify the integrity of the TOE
firmware and software;
● Prior to providing any cryptographic service and [on-demand] to verify correct
operation of cryptographic implementation necessary to fulfil the TSF;
● [start-up] self-tests [
● AES Encrypt Known Answer Test
● AES Decrypt Known Answer Test
● AES GCM Encrypt Known Answer Test
● AES GCM Decrypt Known Answer Test
● AES CCM Encrypt Known Answer Test
● AES CCM Decrypt Known Answer Test
● RSA Sign Known Answer Test
● RSA Verify Known Answer Test
● RSA Encrypt/Decrypt Known Answer Test
● ECDSA Sign Known Answer Test
● ECDSA Verify Known Answer Test
● HMAC (HMAC-SHA-1/256/384/512) Known Answer Test
● SHA-1 Known Answer Test
● SHA-256 Known Answer Test
● SHA-384 Known Answer Test
● SHA-512 Known Answer Test
● DRBG SP800-90A Known Answer Tests
● SP 800-90A Section 11.3 Health Tests
● DH Known Answer Test
● ECDH Known Answer Test
● SP 800-135 KDF Known Answer Tests
● Firmware Integrity Test
].
to demonstrate the correct operation of the TSF.
Application Note: Modified per TD0836.
Panorama 11.1 Security Target Palo Alto Networks
Page 38 of 58
FPT_TST_EXT.1.2 The TSF shall respond to [all failures] by [[entering an error
state called maintenance mode]].
FPT_TUD_EXT.1 – Trusted Update
FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to
query the currently executing version of the TOE firmware/software and [no other
TOE firmware/software version].
FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to
manually initiate updates to TOE firmware/software and [no other update
mechanism].
FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate
firmware/software updates to the TOE using a [digital signature] prior to installing
those updates.
5.2.6 TOE Access (FTA)
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 user Administrator-initiated termination of the user’s
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
unauthorised use of the TOE.
5.2.7 Trusted Path/Channels (FTP)
FTP_ITC.1 – Inter-TSF Trusted Channel
FTP_ITC.1.1 The TSF shall be capable of using [TLS] to provide a trusted communication
channel between itself and another trusted IT product authorized IT entities supporting
the following capabilities: audit server, [[Firewall and Wildfire]] that is logically distinct from
other communication channels and provides assured identification of its end points and
protection of the channel data from modification or disclosure and detection of
modification of the channel data.
FTP_ITC.1.2 The TSF shall permit [the TSF, 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 [
Panorama 11.1 Security Target Palo Alto Networks
Page 39 of 58
● transmitting audit records to an audit server using TLS
].
FTP_TRP.1/Admin – Trusted Path
FTP_TRP.1.1/Admin The TSF shall be capable of using [SSH, HTTPS] to provide
a communication path between itself and authorized remote Administrators users
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 users 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.
5.3 TOE Security Assurance Requirements
The security assurance requirements for the TOE are included by reference to [NDcPP] along with optional
ALC_FLR.3.
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
ALC_FLR.3: Systematic flaw remediation
ASE: Security Target Evaluation ASE_INT.1: ST introduction
ASE_CCL.1: Conformance claims
ASE_SPD.1: Security problem definition
ASE_OBJ.1: Security objectives for the operational
environment
ASE_ECD.1: Extended components definition
ASE_REQ.1: Stated security requirements
ASE_TSS.1: TOE summary specification
ATE: Tests ATE_IND.1: Independent testing - conformance
AVA: Vulnerability Assessment AVA_VAN.1: Vulnerability survey
Consequently, the evaluation activities specified in the following Supporting Document and in the SSH
Package apply to the TOE evaluation:
● Supporting Document Mandatory Technical Document: Evaluation Activities for Network Device
cPP Version: 3.0e, December 6, 2023
● Functional Package for Secure Shell (SSH), Version 1.0, May 13, 2021
Panorama 11.1 Security Target Palo Alto Networks
Page 40 of 58
6. TOE Summary Specification
This chapter describes the security functions:
● Security Audit
● Cryptographic Support
● Identification and Authentication
● Security Management
● Protection of the TSF
● TOE Access
● Trusted Path/Channels
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 or CLI, as well as all of the events
identified in Table 4 (which corresponds to the audit events specified in the [NDcPP] and
[SSHPKG].
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
FAU_STG.1
The audit trail generated by the 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.
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 25% to system log and 30% to
configuration log. For example, on an M-200, that is 12.48 GB and 14.98 GB,
respectively. On VM, it’s 4% each with about 633 MB allocated for each log type but this
will depend on the size of the virtual disk allocated. The minimum storage size that can
be configured is 45 MB on all platforms.
Panorama 11.1 Security Target Palo Alto Networks
Page 41 of 58
The 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 [NDcPP]. The TOE is a single standalone
component that stores audit data locally. The administrators can view the stored audit
logs locally as well. The TOE does not provide an interface where a user can modify the
audit records, thus it prevents modification to the audit records.
The TOE can be configured to send generated audit records to an external Syslog server
in real-time using TLS. 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.2
FCS_COP.1/*
FCS_RBG_EXT.1
The TOE includes NIST-validated cryptographic algorithms provided by Palo Alto
Networks Crypto Module supporting the cryptographic functions below. The following
functions have been certified in accordance with the identified standards.
Table 6 Cryptographic Functions
Functions Standards Certificates
Asymmetric Key Generation (FCS_CKM.1)
ECC key pair generation (NIST
curves P-256, P-384, P-521)
Note that TLS and SSH each use
any of P-256, P-384, or P-521
for authentication, but
certificate generation by the
TOE for P-256 and P-384 key
sizes only.
FIPS PUB 186-4 Appliances:
#A3453
ECC
RSA
FFC
VMs:
#A3454
ECC
RSA
FFC
RSA key generation (key sizes
2048, 3072, 4096 bits)
FIPS PUB 186-4
FFC Schemes using Diffie-
Hellman groups that meet the
following: RFC 3526 and SP
800-56Ar3 (2048-bit MODP)
RFC 3526
NIST SP 800-56Ar3
Cryptographic Key Establishment (FCS_CKM.2)
ECDSA based key
establishment (NIST P-256, P-
384, P-521)
NIST SP 800-56Ar3 Appliances:
#A3453
Panorama 11.1 Security Target Palo Alto Networks
Page 42 of 58
FFC-based Key establishment
scheme using Diffie-Hellman
groups that meet the
following: RFC 3526 and SP
800-56Ar3 (2048-bit MODP)
RFC 3526
NIST SP 800-56Ar3
ECC
FFC
VMs:
#A3454
ECC
FFC
AES Data Encryption/Decryption (FCS_COP.1/DataEncryption)
AES CBC, CTR, GCM (128,
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:
#A3453
AES
VMs:
#A3454
AES
Signature Generation and Verification (FCS_COP.1/SigGen)
RSA Digital Signature
Algorithm (rDSA) (modulus
2048, 3072, 4096)
FIPS PUB 186-4, “Digital
Signature Standard (DSS)”,
Section 5.5, using PKCS #1
v2.1 Signature Schemes
RSASSA-PSS
and/or
RSASSAPKCS1v1_5;
ISO/IEC 9796-2, Digital
signature scheme 2
or
Digital Signature scheme 3
Appliances:
#A3453
RSA
VMs:
#A3454
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:
#A3453
ECDSA
VMs:
#A3454
ECDSA
Cryptographic Hashing (FCS_COP.1/Hash)
SHA-1, SHA-256, SHA-384
and SHA-512 (digest sizes
160, 256, 384 and 512 bits)
ISO/IEC 10118-3:2004 Appliances:
#A3453
SHS
VMs:
#A3454
SHS
Keyed-hash Message Authentication (FCS_COP.1/KeyedHash)
Panorama 11.1 Security Target Palo Alto Networks
Page 43 of 58
● 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:
#A3453
HMAC
VMs:
#A3454
HMAC
Random Bit Generation (FCS_RBG_EXT.1)
CTR_DRBG (AES-256) from a
hardware-based noise source
of 256 bits of non-
determinism
ISO/IEC 18031:2011 Appliances:
#A3453
DRBG
VMs:
#A3454
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.4 for ECC schemes, and FIPS PUB 186-4, “Digital
Signature Standard (DSS)”, Appendix B.1 for FFC schemes. RSA key generation is for
authentication only and not for key establishment.
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.
The TOE performs cryptographic key establishment in accordance with NIST Special
Publication 800-56A for elliptic curve-based key establishment schemes, and NIST
Special Publication 800-56A for finite field-based key establishment schemes. The
TOE acts as both a sender and as a recipient for all supported key establishment
schemes (ECC, FFC). For TLS, the domain parameters used for the finite field-based
key establishment scheme are compliance with FIPS 186-4. Per SP 800-56Ar3, only
the safe primes (e.g., MODP-2048) defined in Sections 3 of RFC 3526 can be used.
NOTE: RFC 7919 (FFDHE) is not supported.
The claimed key generation and key establishment algorithms used for each function is
summarized below.
Panorama 11.1 Security Target Palo Alto Networks
Page 44 of 58
FCS_CKM.1:
- X.509 key pair generation: ECDSA (256, 384), RSA (2048, 3072, 4096)
- SSH RSA key pair generation: RSA (2048, 3072, 4096)
- SSH: ECDSA (256, 384, 521)
- TLS: ECC (256, 384, 521), FFC (2048)
FCS_CKM.2:
- SSH: ECC (256, 384, 521)
- TLS: ECC (256, 384, 521), FFC (2048)
The SHA-2 hash function is associated with the digital signature
generation/verification and corresponding HMAC functions. SHA-256 is also used for
hashing the administrator password for storage. SHA-1 is used as part of ssh-rsa
authentication and TLS client ciphersuites integrity.
FCS_CKM.4
Table 7 Private Keys and CSPs
C
S
P
#
CSP/Key
Name
Type Descriptio
n
Storage Destruct
ion
1
RSA Private
Keys
RSA RSA Private
keys for
verification of
signatures
and
authenticatio
n.
(RSA 2048,
3072, or
4096-bit)
HDD Via
Zeroization
service
2
ECDSA
Private Keys
ECDSA ECDSA
Private key
for
verification of
signatures
and
authenticatio
n
(P-256, P-
384, P-521)
HDD Via
Zeroization
service
3
TLS Pre-
Master Secret
TLS
Secret
Secret value
used to
derive the
TLS session
keys
RAM Zeroize at
session
termination
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)
RAM Zeroize at
session
termination
Panorama 11.1 Security Target Palo Alto Networks
Page 45 of 58
5
TLS HMAC
Keys
HMAC TLS integrity
and
authenticatio
n session
keys (HMAC-
SHA2-256,
HMAC-
SHA2-384,
HMAC-
SHA2-512)
RAM Zeroize at
session
termination
6
TLS
Encryption
Keys
AES TLS
encryption
session keys
(128 and 256
CBC or GCM)
RAM Zeroize at
session
termination
7
SSH Session
Integrity Keys
HMAC Used in all
SSH
connections
to the
security
module’s
command line
interface.
(HMAC-
SHA2-256,
HMAC-
SHA2-512)
RAM Zeroize at
session
termination
8
SSH Session
Encryption
Keys
AES Used in all
SSH
connections
to the
security
module’s
command line
interface.
(128 and 256
bits in CBC
and CTR, or
128 and 256
bits in GCM)
RAM Zeroize at
session
termination
9
SSH ECDH
Private
Components
ECDH ECDH private
component
(ECDH P-
256, P-384,
P-521)
RAM Zeroize at
session
termination
16
Firmware
code integrity
check
HMAC
ECDSA
Used to
check the
integrity of
crypto-
related code.
(HMAC-SHA-
256 and
ECDSA P-
256)
*Keys used to
perform
power-up
self-tests are
not CSPs and
do not need
HDD N/A
Panorama 11.1 Security Target Palo Alto Networks
Page 46 of 58
to be
zeroized
17
Firmware
Content
Encryption
Key
AES-256 Used to
encrypt/decr
ypt firmware,
software, and
sensitive
content.
HDD Zeroization
service
18
Password Password Authenticatio
n string with
a minimum
length of 8
characters.
Stored
hashed with
SHA-256 and
nonce.
HDD Zeroization
service
19
DRBG Seed
/State
DRBG AES 256 CTR
DRBG used
in the
generation of
a random
values.
RAM Zeroize at
session
termination
/ power-
cycle
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 (Key Encryption Key) is the Firmware Content
Encryption Key (also known as the Master Key). The KEK is not stored encrypted but
is protected either using 1.) Cryptod (Palo Alto Networks proprietary key storage
module) 2.) External HSM. By default, HSM (hardware security module) is not used as
it needs to be configured. If stored by Cryptod (evaluated configuration), then it is
destroyed by the TOE’s overwriting method. If it is stored via External HSM
(operational environment), it is protected by the HSM and is out of scope. The TOE
also zeroizes (i.e., overwrites) 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 session
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, KEK,
hashed passwords, and entropy seeds. Note: Only the KEK is stored in plaintext and is
zeroized as noted below. It is used to encrypt all the private keys and other sensitive
data.
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 from the
TOE’s approved DRBG, followed by a read-verify. Sensitive data in volatile memory
includes session keys such as encryption keys, integrity keys, pre-Master secret, etc.
For non-volatile memory, the only plaintext key that is stored is the KEK. When a new
KEK is generated, the old KEK is destroyed via key store APIs that overwrites the old
Panorama 11.1 Security Target Palo Alto Networks
Page 47 of 58
KEK. The KEK is erased when the administrator initiates the zeroization function, which
overwrites the KEK three or more times using an alternating pattern of ones and zeroes.
Destruction of all encrypted stored keys is accomplished indirectly through destruction
of the KEK that encrypted them.
FCS_HTTPS_EXT.1
FCS_TLSC_EXT.1
FCS_TLSS_EXT.1(1)
FCS_TLSS_EXT.1(2)
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 Panorama > Certificate
Management > Certificate Profile tab. The TOE uses TLS service profiles to specify a
certificate and the allowed protocol versions for TLS services. TLS PSK authentication
is not supported by the TOE. The TOE (as a TLS client) uses TLS 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, firewall, Wildfire). The key agreement parameters of the server key
exchange message consist of the key establishment parameters generated by the TOE:
Diffie-Hellman parameters with key size of MODP group 2048-bit, ECDSA
implementing NIST curves secp256r1, secp384r1, and secp521r1. The TOE supports
session resumption using session tickets for a single context (no configuration needed).
The TOE checks if session tickets expire which would trigger a full handshake. The
session tickets are encrypted with AES encryption and 128-bits encryption key plus
256-bits HMAC-SHA-256 key; and adhered to the structural format provided in
section 4 of RFC 5077. This interface does not support fallback authentication for TLS.
The certificate used for TLS authentication must be RSA or ECDSA with minimum key
sizes of 2048 or 256 bits, respectively, and up to 4096 bits for RSA and 521 bits for
ECDSA. The TOE denies connections from clients requesting connections using SSL
2.0, SSL 3.0, TLS 1.0, or TLS 1.1 by default and shall not establish a trusted channel if
the fully qualified distinguished name (FQDN) in the subject or Subject Alternative
Name (SAN) field contained in a certificate does not match the expected identifier for
the peer. The TOE will match the FQDN identifier according to RFC 6125. The TOE
also supports username as identifier for Web UI HTTPS connection.
The TOE can be configured as a TLS server to permit inbound remote administration
traffic (HTTPS) in which the peer initiates handshake and peer authentication is
performed via username and password credentials. The TOE’s HTTPS protocol
complies with RFC 2818 and is implemented using TLS 1.2 (RFC 5246) and TLS 1.3
(RFC 8446). HTTPS is used for Web UI management connection so only the server
requirements in RFC 2818 are applicable. RFC 2818 (section 2.1: complies as specified,
section 2.2: complies as specified, section 2.2.1: not applicable, section 2.2.2: complies
as specified, section 2.3: default port is 443, section 2.4: Use ‘https’ as specified, section
3.1: not applicable, and section 3.2: client identity checking is performed).
The key agreement parameters of the server key exchange message consist of the key
establishment parameters generated by the TOE: Diffie-Hellman parameters with key
size 2048 MODP, ECDSA implementing NIST curves secp256r1,secp384r1, and
secp521r1. The TOE supports session resumption using session tickets. The session
tickets are encrypted with AES encryption and 128-bits encryption key plus 256-bits
HMAC-SHA-256 key; and adhered to the structural format provided in section 4 of
RFC 5077. Fallback to password-based authentication is not supported. The TOE
denies connections from clients requesting connections using SSL 2.0, SSL 3.0, TLS 1.0,
or TLS 1.1 when in FIPS-CC mode.
The TOE can be configured as a TLS client for secure communication to an external
audit server. The TOE presents the Supported Elliptic Curves/Supported Groups
Extension in the Client Hello with the secp256r1, secp384r1, and secp521r1 NIST
curves and is configured when FIPS-CC mode is enabled. The TOE verifies that the
Panorama 11.1 Security Target Palo Alto Networks
Page 48 of 58
presented identifier matches the reference identifier according to RFC 6125 and only
establishes a trusted channel if the peer certificate is valid. The TOE compares the
external server’s presented identifier to the reference identifier by matching the
certificate FQDN (hostname) 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 wildcards for server authentication using FQDN (hostname) only. IP
address should not be used.
The following is a list of supported ciphersuites for the TOE's TLS client to syslog
server. TOE (as TLS client) to syslog server connection. Support TLSv1.2 only and DHE
(finite-field based), and ECDHE (elliptic curve-based) schemes. When FIPS-CC mode is
enabled, only the following TLS ciphersuites are configured:
● 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
The following is a list of supported ciphersuites for the Web UI management
connection (TOE is TLS server). Supports TLSv1.2 or TLSv1.3 only, and DHE (finite-
field based) for TLSv1.2 only and ECDHE (elliptic curve-based) schemes for both.
Mutual authentication is optional (same ciphersuites if configured). The following TLS
ciphersuites are available. An Administrator can further restrict the supported
ciphersuites in the SSL/TLS Service Profile.
● 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_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
● TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
● TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
● TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
● TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
● TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
● TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
● TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
● TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
● TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
● TLS_AES_128_GCM_SHA256
● TLS_AES_256_GCM_SHA384
The following is a list of supported ciphersuites for connection to firewall or Wildfire
connection (TOE is the TLS server and mutual authentication required). Supports
TLSv1.2 or TLSv1.3 only, and DHE (finite-field based) for TLSv1.2 only, and ECDHE
Panorama 11.1 Security Target Palo Alto Networks
Page 49 of 58
(elliptic curve-based) schemes for both. An Administrator can further restrict the
supported ciphersuites in the SSL/TLS Service Profile.
● TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
● TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 8422
● TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
● TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
● TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 8422
● TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
● TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 8422
● TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
● TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
● TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 8422
● TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
● TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
● TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
● TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
● TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
● TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
● TLS_AES_256_GCM_SHA384
● TLS_AES_128_GCM_SHA256
When FIPS-CC mode is enabled, all TLS connections will only support the following
signature algorithms extensions:
● rsa_pkcs1 with sha256(0x0401),
● rsa_pkcs1with sha384(0x0501),
● rsa_pkcs1 with sha512(0x0601),
● ecdsa_secp256r1 with sha256(0x0403),
● ecdsa_secp384r1 with sha384(0x0503),
● ecdsa_secp521r1 with sha512(0x0603),
● rsa_pss_rsae with sha256(0x0804),
● rsa_pss_rsae with sha384(0x0805),
● rsa_pss_rsae with sha512(0x0806)
FCS_SSH_EXT.1
FCS_SSHS_EXT.1
The TOE supports SSHv2 server (compliant to RFCs 4251, 4252, 4253, 4254, 4344,
5647, 5656, 6668, 8332) with AES encryption/decryption algorithms (aes128-cbc,
aes256-cbc, aes128-ctr, aes256-ctr, aes128-gcm@openssh.com, aes256-
gcm@openssh.com) with key sizes of 128 and 256 bits. No optional characteristics are
supported. The TOE also supports HMAC-SHA-256, HMAC-SHA-512, implicit MAC
(aes128-gcm@openssh.com and aes256-gcm@openssh.com) for integrity and
authenticity. Both encryption and integrity algorithms are administrator-configurable
but non-Approved 3DES, HMAC-MD5, diffie-hellman-group-1 are all disabled when
FIPS-CC mode is enabled. Only the Approved encryption and integrity algorithms along
with key exchange algorithms ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-
sha2-nistp521 and authentication public-key algorithms ssh-rsa, rsa-sha2-256, and rsa-
sha2-512 are permitted in the evaluated configuration. In addition, the TOE supports
SSH KDF as specified in RFC 5656 section 4. If the SSH client (in the operational
environment) only supports non-Approved algorithms, the SSH connection will be
rejected by the TOE. SSH server supports both RSA and ECDSA SSH host keys as
specified in FCS_SSHS_EXT.1.
The TOE uses OpenSSH implementation to support the SSHv2 connections. The
password authentication timeout period is 60 seconds allowing clients to retry only 4
times by default (number of failed attempts is configurable). In addition, public-key
(RSA), keyboard-interactive, and password-based authentication can be configured
Panorama 11.1 Security Target Palo Alto Networks
Page 50 of 58
with password-based being the default method. For password, the TOE verifies the
user identity when the username is entered. For public-key, the administrator must
associate the public key to the user. Keyboard-interactive is a generic authentication
method that can be used to implement different types of authentication mechanisms
such as password and public-key. SSH packets are limited to 262,105 bytes 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 and the threshold limits apply to
both transmitted and received data.
6.3 Identification and Authentication
FIA_UIA_EXT.1 The TOE is designed to require users to be identified and authenticated before they
can access any of the TOE functions. The only capabilities allowed prior to users
authenticating are the display of the informative (login) banner and responding to
ICMP request (e.g., ping or ICMP echo reply).
The TOE maintains user accounts which it uses to control access to the TOE. When
creating a new user account, the administrator specifies a username (i.e., user identity
or ID), a password, SSH public key, or X.509v3 certificate, and a role. Certificate-
based authentication is only supported on the GUI. To enable client certificate-based
authentication (i.e., mutual authentication), the TOE must be configured to use a
client certificate profile using the Panorama > 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 username and password attributes to identify and authenticate the
user when the user logs in via the GUI, CLI, or API. 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, GUI, or API, the default authentication method is password. 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 or CLI.
The administrator can logon to the GUI or API by using a secure connection (HTTPS)
from a web browser or to CLI by using a secure connection (SSHv2) from a SSH client.
The TOE provides access using an HTTPS/TLS or SSHv2 client. The administrator
enters the IP address of the TOE and their username and password. The TOE also
can be configured to require a client certificate (mutual authentication) and
additionally require the username and password or not (i.e., 2-factor authentication).
Regardless of whether a user logs in using an HTTPS or SSH connection, a logon is
successful when the username and password or public-key authentication provided
Panorama 11.1 Security Target Palo Alto Networks
Page 51 of 58
by the user matches a defined account on the TOE or when the username and digital
signature is verified by the TOE.
FIA_PMG_EXT.1 Passwords can be composed of upper and lower case letters, numbers and special
characters (“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(”, “)”, “'”, “+”, “,”, “-”, “.”, “/”, “:”, “;”, “<”,
“=”, “>”, “[”, “\”, “]”, “_”, “`”, “{”, “}”, “~”, and “all Unicode characters”). The minimum
password length is configurable by the administrator from 8 up to 16 characters. Note
in FIPS-CC mode, the minimum password length cannot be configured below 8. The
maximum password length is 63 characters. For example, if the administrator
configures the minimum password length as 15, they can only create passwords from
length of 15 to 63.
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 secure 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
(authenticating administrators). Public key infrastructure (PKI) credentials, such as
RSA keys and certificates are stored in the TOE’s underlying file system on the
appliance. Certificates and their associated private key are stored in a single
container: the Certificate File. The PKCS#12 file consists of an Encrypted Private Key
and X.509 Certificate. By default, all the private keys are protected since they are
always stored in encrypted format using AES-256. The physical security of the
appliance (A.PHYSICAL_PROTECTION) protects the appliance and the certificates
from being tampered with or deleted. In addition, the TOE identification and
authentication security functions protect an unauthorized user from gaining access
to the TOE.
The TOE supports Online Certificate Status Protocol (OCSP) status verification for
presented peer TLS certificates as specified in RFC 6960 during negotiation.
The TOE uses the following rules for validating the extendedKeyUsage3
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.
The TOE validates a certificate path by ensuring the presence of the basicConstraints
extension is present and the cA flag is set to TRUE for all CA certificates. The TOE
forms a Certificate trust path by ensuring that the basic constraints are met, proper
key usage parameters exist, the CA flag exists, performing a revocation check of each
certificate in the path and performing the validity of the CA certificate. The TOE will
FIA_X509_EXT.2
3
Certificates are not used for trusted updates or executable code integrity.
Panorama 11.1 Security Target Palo Alto Networks
Page 52 of 58
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 Administrator must import or generate a root
CA certificate and store it in the TOE trust store. To use only a specific trusted
certificate, the Administrator must specify only that certificate in the Certificate
Profile and tie that Profile to a TLS connection.
When the certificate status is unknown or cannot be determined, the TLS session is
not established.
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 check to make sure the certificate chain are present in the TOE.
Otherwise, the TOE will reject the certificate and will not associate it with the CSR.
6.4 Security Management
FMT_MOF.1/ManualUpdate
FMT_MTD.1/CoreData
FMT_MTD.1.1/CryptoKeys
The TOE provides a GUI management interface and CLI to support security
management of the TOE. The GUI is accessible over HTTPS. Note the TOE in
Log Collector mode does not support GUI. The CLI is accessible 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 example, the ability to manage the TOE’s trust store is restricted to
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). Authenticated users can manage cryptographic keys
accordingly.
An Administrator is able to manage RSA/ECDSA Private/Public keys, and
passwords once successfully authenticated into the TOE. Functions available
for managing them include generating, importing, and deleting these keys /
private parameters.
FMT_SMF.1 The security management functions provided by the TOE include, but are not
limited to:
● Ability to administer the TOE remotely;
● Ability to configure the access banner;
● Ability to configure the session inactivity time before session
termination;
● Ability to update the TOE, and to verify the updates using digital
signature capability prior to installing those updates;
● Ability to configure the list of TOE-provided services available before
an entity is identified and authenticated, as specified in FIA_UIA_EXT.1;
Panorama 11.1 Security Target Palo Alto Networks
Page 53 of 58
● Ability to configure local audit behaviour (e.g. changes to storage
locations for audit; changes to behaviour when local audit storage
space is full, changes to local audit storage size);
● Ability to modify the behaviour of the transmission of audit data to an
external IT entity;
● Ability to manage the cryptographic keys;
● Ability to configure the cryptographic functionality;
● Ability to configure thresholds for SSH rekeying;
● Ability to configure the list of supported (D)TLS ciphers;
● Ability to set the time which is used for time-stamps;
● Ability to manage the TOE's trust store and designate X.509v3
certificates as trust anchors;
● Ability to generate Certificate Signing Request (CSR) and process CA
certificate response;
● Ability to configure the authentication failure parameters for
FIA_AFL.1;
● Ability to manage the trusted public keys database
The GUI, CLI, and API (XML and REST) provide the same supported
management functionality. With regards to the TSF management functions
above, they are available on all interfaces.
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 and in Panorama and Management-Only modes,
the TOE has the following pre-defined administrator roles: Superuser,
Superuser (Read-Only), and Panorama Administrator. These administrator roles
(except Read-Only) are all considered Security Administrator as defined in the
[NDcPP] 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 can administer the TOE via CLI or web UI, and a user account
can only be assigned one role at a time. In Log Collector mode, only the
Superuser role is supported and there is only one user account.
● Superuser—Full read-write access to Panorama and all device groups,
templates, and managed firewalls including user and role management
(create, modify, delete).
● Superuser (Read-Only)—Read-only access to Panorama and all device
groups, templates, and managed firewalls.
● Panorama Administrator—Full access to Panorama except for the
create, modify, or delete administrators or roles.
6.5 Protection of the TSF
Panorama 11.1 Security Target Palo Alto Networks
Page 54 of 58
FPT_SKP_EXT.1 Certificates and their associated private key are stored in a single container: the
Certificate File. The PKCS#12 file consists of an Encrypted Private Key and X.509
Certificate. By default, all the private keys are protected since they are always stored
in encrypted format using AES-256. The TOE prevents the reading of all keys by
encrypting them with a Master Key using AES-256. The TOE does not provide an
interface to read the Master Key. The TOE is designed specifically to prevent access
to locally-stored cryptographically protected passwords and does not disclose any
keys stored in the TOE. The TOE protects the confidentiality of user passwords by
hashing the passwords using SHA-256. The TOE does not offer any functions that
will disclose to any users a stored cryptographic key or password.
FPT_APW_EXT.1
FPT_TST_EXT.1 The TOE meets self-test requirements and therefore provides self-tests at start-up
to demonstrate the correct operation of: key error detection, cryptographic
algorithms, and RNG. Conditional self-tests are also run during the course of normal
operation. The self-tests verify the integrity of stored TSF executable code and TSF
data. The TOE performs the following Power-on self-tests:
● AES Encrypt Known Answer Test
● AES Decrypt Known Answer Test
● AES GCM Encrypt Known Answer Test
● AES GCM Decrypt Known Answer Test
● AES CCM Encrypt Known Answer Test
● AES CCM Decrypt Known Answer Test
● RSA Sign Known Answer Test
● RSA Verify Known Answer Test
● RSA Encrypt/Decrypt Known Answer Test
● ECDSA Sign Known Answer Test
● ECDSA Verify Known Answer Test
● HMAC (HMAC-SHA-1/256/384/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
o Includes Instantiate / Generate / Reseed / Uninstantiate Functions
● DH Known Answer Test
● ECDH Known Answer Test
● SP 800-135 KDF Known Answer Tests
● Firmware Integrity Test – verified with HMAC-SHA-256 and ECDSA P-256.
If the calculated result does not equal the previously generated result, the
software/firmware test shall fail.
A known-answer test involves operating the cryptographic algorithm on data for
which the correct output is already known and comparing the calculated output with
the previously generated output (the known answer). If the calculated output does
not equal the known answer, the known-answer test shall fail.
The TOE performs the following Conditional Self-Tests within the cryptographic
module when the conditions specified for the tests occur:
1. SP 800-90B health tests are performed in the entropy source as required by
SP 800-90B requirements
2. RSA Pairwise Consistency Test
3. ECDSA Pairwise Consistency Test
Panorama 11.1 Security Target Palo Alto Networks
Page 55 of 58
4. Firmware Load Test – Verify using RSA 2048 with SHA-256 signature on
firmware at time of load. If the digital signature cannot be verified, the test
shall fail.
The TOE performs the following pair-wise consistency tests for public and private
keys:
1. If the keys are used to perform an approved key transport method or
encryption, then the public key shall encrypt a plaintext value. The resulting
ciphertext value shall be compared to the original plaintext value. If the two
values are equal, then the test shall fail. If the two values differ, then the
private key shall be used to decrypt the ciphertext and the resulting value
shall be compared to the original plaintext value. If the two values are not
equal, the test shall fail.
2. If the keys are used to perform the calculation and verification of digital
signatures, then the consistency of the keys shall be tested by the calculation
and verification of a digital signature. If the digital signature cannot be
verified, the test shall fail.
If a self-test fails, the TOE enters an error state and outputs an error indicator. The
TOE doesn’t perform any cryptographic operations 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 a maintenance state in
which the reason for the reboot can be determined.
The methods above are sufficient to ensure the correct functionality of the TSF as
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 (command ‘show system info | match sw-version’). When updates are installed,
the TOE needs to be rebooted for the change to take place (no delayed activation).
When updates are available from Palo Alto, an administrator can obtain and install
those updates from updates.paloaltonetworks.com if there is an internet connection.
For an additional layer of protection, Palo Alto Networks has chosen to sign (using
RSA-2048) all content that is downloaded to the TOE. If the TOE is not connected
to the internet, the administrators can download the updates and upload it to the
TOE.
When the TOE update package and its corresponding digital signature is downloaded
or uploaded; the digital signature is checked automatically by TOE by verifying the
signature using the public key (corresponding to the RSA key used to create the
signature). Palo Alto Networks manages the update server and guarantees that
images are digitally signed. Public keys are stored and protected on the TOE’s file
system. If the signature is verified, the update is performed; otherwise, the update is
not performed.
FPT_STM_EXT.1 The TOE is a hardware appliance or a virtual appliance image installed on a
virtualization platform that includes a hardware-based real-time clock. The 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, time-based lockout following authentication failure, and for
cryptographic operations based on time/date.
Panorama 11.1 Security Target Palo Alto Networks
Page 56 of 58
6.6 TOE Access
FTA_SSL.3 The TOE will enforce an administrator-defined inactivity timeout value after which the
inactive 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 disabled by default and
the administrator must follow the CC AGD to configure the session idle timeout value.
A session that is inactive (i.e., no commands issuing from the remote client) for the
defined timeout value 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. An API session
automatically terminates after the API call completes.
FTA_SSL.4 The TOE provides remote users the ability to logout (or terminate) their sessions as
directed by the user. The user can click on the “Logout” link to terminate a web GUI
session and can enter the “exit” command to terminate a CLI session.
FTA_TAB.1 The TOE can be configured to display an informative banner that will appear prior to
authentication when accessing the TOE via secure connection to the management port
in order to access the Web Interface (HTTPS) or CLI (SSH).
6.7 Trusted Path/Channels
FTP_ITC.1 The TOE can be configured to send audit records to external Syslog server(s) using TLS
in real-time. The TOE permits the TSF to initiate communication with the Syslog server,
using TLS trusted channel. The TOE communicates with its authorized entities over TLS
only and all communication are sent over the trusted channel, including the TOE initial
communication. The TOE communicates with firewall and Wildfire over TLS
connections. Mutual authentication is supported but must be configured for all TLS
server channels. The underlying TLS algorithms are supported by CAVP-validated
cryptographic mechanisms included in the TOE implementation.
FTP_TRP.1/Admin The TOE provides SSH and HTTPS (TLSv1.3 and TLSv1.2) to support secure
administration. HTTPS is supported in Panorama and Management-Only modes.
Administrators can initiate a session that is secured (from disclosure and modification)
using CAVP-validated cryptographic operations, and all security management functions
require the use of this secure channel. In FIPS-CC mode, telnet and HTTP are disabled
permanently.
Panorama 11.1 Security Target Palo Alto Networks
Page 57 of 58
7. Protection Profile Claims
This ST is exact conformant to the [NDcPP] and [SSHPKG].
Panorama 11.1 Security Target Palo Alto Networks
Page 58 of 58
8. Rationale
This Security Target includes by reference the [NDcPP] applicable Security Problem Definition, Security
Objectives, and Security Assurance Requirements. The Security Target makes no additions to the [NDcPP]
assumptions. Security Functional Requirements have been reproduced verbatim with the Protection Profile
operations completed except where refinements were made by the ST author and formatted per the defined
convention. Operations on the security requirements follow [NDcPP] and [SSHPKG] application notes and
evaluation activities. The Security Target did not add or remove any security requirements but added
optional ALC_FLR.3. Consequently, [NDcPP] rationale applies and is complete.