Palo Alto Networks
WF-500-B
Appliance running
WildFire 11.1
Security Target
Version: 1.0
Date: October 22, 2025
​ 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.​
​
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
Table of Contents
1. SECURITY TARGET INTRODUCTION​ 4
1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION​ 5
1.2 CONFORMANCE CLAIMS​ 5
1.3 CONVENTIONS​ 6
1.3.1 Terminology​ 7
1.3.2 Acronyms​ 7
2. PRODUCT DESCRIPTION​ 9
2.1 TOE OVERVIEW​ 9
2.2 TOE ARCHITECTURE​ 10
2.2.1 Physical Boundaries​ 11
2.2.2 Logical Boundaries​ 12
2.3 TOE DOCUMENTATION​ 13
2.4 EXCLUDED FUNCTIONALITY​ 13
3. SECURITY PROBLEM DEFINITION​ 15
4. SECURITY OBJECTIVES​ 16
4.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT​ 16
5. IT SECURITY REQUIREMENTS​ 17
5.1 EXTENDED REQUIREMENTS​ 17
5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS​ 17
5.2.1 Security Audit (FAU)​ 19
5.2.2 Cryptographic Support (FCS)​ 22
5.2.3 Identification and Authentication (FIA)​ 28
5.2.4 Security Management (FMT)​ 30
5.2.5 Protection of the TSF (FPT)​ 30
5.2.6 TOE Access (FTA)​ 32
5.2.7 Trusted Path/Channels (FTP)​ 32
5.3 TOE SECURITY ASSURANCE REQUIREMENTS​ 34
6. TOE SUMMARY SPECIFICATION​ 35
6.1 SECURITY AUDIT​ 36
6.2 CRYPTOGRAPHIC SUPPORT​ 36
6.3 IDENTIFICATION AND AUTHENTICATION​ 43
6.4 SECURITY MANAGEMENT​ 45
6.5 PROTECTION OF THE TSF​ 46
6.6 TOE ACCESS​ 49
6.7 TRUSTED PATH/CHANNELS​ 49
7. PROTECTION PROFILE CLAIMS​ 50
8. RATIONALE​ 51
​ ​
Page 2 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
LIST OF FIGURES
Figure 1 - WildFire File Analysis​ 1
Figure 2 - WildFire Interaction with Systems​ 7
Figure 3 - TOE Architecture​ 7
LIST OF TABLES
Table 1 TOE Platforms​ 8
Table 2 Excluded Features​ 10
Table 3 TOE Security Functional Components​ 14
Table 4 Auditable Events​ 16
Table 5 Assurance Components​ 29
Table 6 Cryptographic Functions​ 31
Table 7 FIPS 186-4 Conformance​ 33
Table 8 Private Keys and CSPs​ 34
​ ​
Page 3 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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 are physical appliances running WildFire software
version 11.1, provided by Palo Alto Networks, Inc.
The physical is the WF-500-B, which is an on-premise network device that identify unknown malware,
zero-day exploits, and Advanced Persistent Threats (APTs) through dynamic analysis, and automatically
disseminates protection in near real-time to help security teams meet the challenge of advanced
cyber-attacks. Unknown files are analyzed by WildFire in a scalable sandbox environment where new
threats are identified, and protections are automatically developed and delivered in the form of an update.
The result is a unique, closed loop approach to controlling cyber threats that begins with positive security
controls to reduce the attack surface, inspection of all traffic, ports, and protocols to block all known threats,
and rapid detection of unknown threats by observing their actual behavior. The appliance’s architecture
allows organizations to meet privacy and regulatory requirements for local analysis while still benefiting
from shared threat intelligence and protections from other WildFire subscribers.
Figure 1 - WildFire File Analysis
The focus of this evaluation is on the TOE functionality supporting the claims in the collaborative Protection
Profile for Network Devices and SSH Package. (See Section 1.2 for specific version information).
​ ​
Page 4 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
The only capabilities covered by the evaluation are those specified in the aforementioned Protection Profile
and Functional Package, all other capabilities are not covered in the evaluation. The security functionality
specified in [NDcPP] and [SSHPKG] includes 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
●​ Security Problem Definition
●​ Security Objectives
●​ IT Security Requirements
●​ TOE Summary Specification
●​ Protection Profile Claims
●​ Rationale
1.1​ Security Target, TOE and CC Identification
ST Title – Palo Alto Networks WF-500-B Appliance running WildFire 11.1 Security Target
ST Version – Version 1.0
ST Date – October 22, 2025
TOE Identification – Palo Alto Networks WF-500-B Appliance running WildFire 11.1.
TOE Developer – Palo Alto Networks, Inc.
Evaluation Sponsor – Palo Alto Networks, Inc.
CC Identification – Common Criteria for Information Technology Security Evaluation, Version 3.1, Release 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:
●​ PP Reference: collaborative Protection Profile for Network Devices, Version 3.0e,
6-December-2023 [NDcPP]
●​ Package Reference: Functional Package for Secure Shell (SSH) Version 1.0 13-May-2021 [SSHPKG]
The following NIAP Technical Decisions apply to the [SSHPKG], and have been accounted for in the ST
development:
●​ 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 is applicable to the TOE because it supports both 128 and 256 bits for AES-CTR.
[SSHPKG]
●​ TD0732: FCS_SSHS_EXT.1.3 Test 2 Update
o TD updates test evaluation activities that apply to the TOE. [SSHPKG]
​ ​
Page 5 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
●​ TD0777: Clarification to Selections for Auditable Events for FCS_SSH_EXT.1
o This TD is applicable to the TOE because it logs failure to establish SSH connection. [SSHPKG]
●​ TD0909: Updates to FCS_SSH_EXT.1.1 App Note in SSH FP 1.0
o This TD is applicable to the TOE as it supports public keys. [SSHPKG]
The following NIAP Technical Decisions apply to the [NDcPP], and have been accounted for in the ST
development:
●​ TD0836: NIT Technical Decision: Redundant Requirements in FPT_TST_EXT.1
o The TD modifies the FPT_TST_EXT.1.1 SFR and the AAR evaluation activities have been
modified. [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 Technical Decision: Correction of Chapter Headings in CPP_ND_V3.0E
o This TD modifies the chapter numbering and has been applied [NDcPP]
●​ TD0880: NIT Technical Decision: Removal of Duplicate Selection in FMT_SMF.1.1
o This TD removes a duplicate selection [NDcPP]
●​ 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: Correlation of Recognition Test for TLS 1.2
o This TD modifies test activities for TLS Clients and Server, which is supported by the TOE
[NDcPP]
●​ TD0900: NIT Technical Decision: Clarification to Local Administrator Access in
FIA_UIA_EXT.1.3
o This TD modifies a supported function, which has been applied to this ST [NDcPP]
●​ TD0921: NIT Technical Decision: Addition of FIPS PUB 186-5 and Correction of Assignment
o This TD modifies a supported function, which has been applied to this ST [NDcPP]
●​ TD0923: NIT Technical Decision: Auditable event for FAU_STG_EXT.1 in FAU_GEN.1.2
o This TD modifies a function that is supported / claimed by the TOE [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.
●​ All operations performed in this ST are identified according to conventions described in [NDcPP].
​ ​
Page 6 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
●​ 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].
●​ Selection/Assignment operations completed by the ST author was bolded to show that it was
completed by the ST author and not taken as-is from the PP.
●​ Iteration operations completed by the ST author are identified with (1), (2), and (next number) with
descriptive text following the name (e.g. FCS_HTTPS_EXT.1(1) HTTPS Protocol (TLS Server)).
1.3.1​ Terminology
The following terms and abbreviations are used in this ST:
●​ WF – WildFire appliance
●​ UID – Unique Identification feature is a combination LED/button that is used to assist a technician
in locating a device
●​ CO – Cryptographic Officer (Administrator or superuser)
●​ CCECG – Common Criteria Evaluated Configuration Guide used to assist an administrator with
steps for configuring the TOE properly
1.3.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
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
​ ​
Page 7 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
ST Security Target
TLS Transport Layer Security
TOE Target of Evaluation
TSF TOE Security Functions
UID User Identifier
URL Uniform Resource Locator
​ ​
Page 8 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
2.​ Product Description
The TOE is the Palo Alto Networks WF-500-B appliance, which utilizes the WildFire 11.1 software. The TOE
provides detection and prevention of zero-day malware using a combination of dynamic and static analysis
to detect threats and create protections to block malware. The WF-500-B appliance extends the
capabilities of Palo Alto Networks’ Next Generation Firewalls by receiving network traffic samples to
identify and block targeted and unknown malware.
The evaluation only includes the WF-500-B physical device as identified in sections above. Other
deployments of WildFire are cloud-based and are not within scope of this evaluation. Palo Alto Networks
Next-Generation Firewalls are components of the TOE’s Operational Environment and were evaluated
previously, and information about them are provided for completeness only.
2.1 TOE Overview
It is required that the TOE be placed in FIPS-CC mode, which ensures that only FIPS/CC approved/allowed
algorithms are utilized when interacting with other devices in the operational network. For communications
with Palo Alto Networks Firewalls appliances, only the secure communication channels are claimed.
The TOE utilizes various protocols in its communication with other devices. TLS is used to secure
connections between the TOE and other devices on the network such as the Firewall and syslog server. For
any updates that are required on the TOE such as configuration changes that are processed via CLI, SSHv2 is
used to secure these connections.
The various protocols implemented by the module include TLS and SSH. The TOE has the ability to handle
certificates for their desired purpose as well as being able to generate certificates that can be used for these
functions. Administrators are able to setup the TOE to support mutual authentication to improve the
security of their appliance as it communicates with other devices.
As a network device, the TOE is required to generate logging events, which can be used by administrators to
audit functions of the TOE as well as its interactions with other components. The TOE provides the ability to
store logs locally, and also has the ability to send these logs to an external syslog server via a TLS connection.
To protect the TOE from unauthorized access and disruption, the TOE has security features in place that will
log out idle administrators, lock the device in the event of too many failed authentication attempts, and has
the ability to increase the password length to harden the credentials of administrators.
Operators that provide the correct credentials to the TOE are able to perform all management functions via
the CLI, which is protected using SSHv2. Configurations can be updated for the ability of the appliance to
communicate with other devices on the network, generate certificates, and perform security actions such as
zeroization.
Figure 2 provides an overview of the communication protocols used between the TOE and other devices on
the network. The PAN-OS Firewall devices are in the operational environment, and only the secure
communication channels from the WildFire to those devices are claimed.
​ ​
Page 9 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
Figure 2 - WildFire Interaction with Systems
2.2​ TOE Architecture
The TOE is a hardware and software solution that is comprised of items listed in Section 2.2.1 and 2.2.2. The
software comes pre-installed on the device and can be updated by downloading a new version from the Palo
Alto Networks support site. The system consists of the following items: system software, database,
linux-derived operating system, and the hardware. The database is a repository for audit logs, user logs, and
system/configuration data. The system software contains necessary items to support the functionality of the
device such as using OpenSSL/OpenSSH, and items necessary for management interfaces (CLI). The
WildFire 11.1 software runs on top of the PAN-OS 11.1 operating system. PAN-OS 11.1 is an operating
system derived from Linux kernel version 4.18.0 to enforce domain separation, memory management, disk
access, file I/O, and communications with the underlying hardware components including memory, network
I/O, CPUs, and hard disks. Only services and libraries required by the system software and DB are enabled in
the OS.
The following diagram demonstrates the software and hardware architecture of the TOE.
​ ​
Page 10 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
Figure 3 - TOE Architecture
2.2.1​ Physical Boundaries
The TOE consists of the following components:
●​ Palo Alto Networks WF-500-B hardware appliance
●​ WildFire 11.1 (running on top of PAN-OS 11.1): The software component that runs on the appliance
The WF-500-B appliance includes the following ports:
●​ (Qty. 1) RJ-45 10/100/1000 management port used for managing the device and for data traffic
●​ (Qty. 3) RJ-45 10/100/1000 ports used for data traffic
●​ (Qty. 1) Graphics Port (reserved for future use)
●​ (Qty. 1) UID
●​ (Qty. 1) DB-9 serial port for console access (disabled in FIPS-CC mode)
●​ (Qty. 2) Power supplies
●​ (Qty. 4) USB ports (reserved for future use; disabled in FIPS-CC mode)
Table 1 TOE Platforms
Product
Identification
Illustration Description
WF-500-B
The appliance detects unknown
threats through a combination of
multiple complementary analysis
techniques.
Processor: Intel Xeon Silver 4316
(Ice Lake)
Memory: 512GB DDR4-3200
RAM
System Storage: 512 GB SSD
system storage
​ ​
Page 11 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
The operational environment includes the following:
●​ Syslog server
●​ Palo Alto Networks Firewall appliances
●​ Workstation
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 a variety of security relevant events including the events
specified in [NDcPP] and [SSHPKG]. The TOE can be configured to store the logs locally or can be configured
to send the logs to a designated external log server.
2.2.2.2​ Cryptographic Support
The TOE implements NIST validated cryptographic algorithms that provide key management, random bit
generation, encryption/decryption, digital signature and cryptographic hashing and keyed-hash message
authentication features in support of cryptographic protocols such as TLS and SSH. In order to utilize these
features, the TOE must be configured in FIPS-CC mode.
The TOE’s (Palo Alto Networks Crypto Module) cryptographic functionality is validated by the following
CAVP certificate: #A3453.
2.2.2.3​ Identification and Authentication
The TOE requires that all users that access the TOE be successfully identified and authenticated before they
can have access to any security functions that are available in the TOE. The TOE offers functions through
connections using SSH for administrators.
The TOE supports the local definition and authentication of administrators with username, password, SSH
keys, and role that it uses to authenticate the operator. These items are associated with an operator and an
authorized role for access to the TOE. The TOE uses X.509 certificates to support TLS authentication. In the
evaluated configuration, the syslog connection implements OCSP for status verification for the certificate.
The connection to the firewalls can use either CRLs or OCSP.
2.2.2.4​ Security Management
The TOE provides access to the security management features using the CLI. CLI commands are transmitted
over SSH for secure connections. Security management commands are limited to administrators and only
available after the operator has successfully authenticated themselves to the TOE. The TOE provides access
to these services using an SSHv2 client. The product also includes a console port, but once FIPS-CC mode is
enabled, the console port is disabled.
​ ​
Page 12 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
2.2.2.5​ Protection of the TSF
The TOE implements features designed to protect itself, and to ensure the reliability and integrity of its
security functions.
Stored passwords and cryptographic keys are protected so that unauthorized access does not result in
sensitive data being lost, and the TOE also contains various self-tests so that it can detect if there are any
errors with the system or if malicious activity has occurred. The TOE provides its own timing mechanism to
ensure that reliable time information is present. The TOE uses digital signature mechanisms when
performing trusted updates to ensure installation of software is valid and authenticated properly.
2.2.2.6​ TOE Access
The TOE provides the ability for both TOE and user-initiated locking of the interactive sessions for the TOE
termination of an interactive session after a period of inactivity is observed. Additionally, the TOE is able to
display an advisory message regarding unauthorized use of the TOE before establishing a user session.
2.2.2.7​ Trusted Path/Channels
The TOE protects interactive communication with administrators using SSH. Communication with other
devices and services (such as a Syslog server) are protected using TLS and X.509 certificates to support TLS
authentication.
2.3​ TOE Documentation
Palo Alto Networks, Inc. has several documents that provide operators with information regarding the
installation, and the included security features.
For WildFire 11.1 these documents include the following:
●​ Palo Alto Networks Common Criteria Evaluated Configuration Guide (CCECG) for WildFire 11.1
●​ Palo Alto Networks WildFire Appliance Administrator Guide Version 11.1, Last Revised: August 23,
2023
●​ WF-500-B WildFire Appliance Hardware Reference Guide, March 21, 2023
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 and SSH. The features below are out of scope.
Table 2 Excluded Features
Feature Description
Telnet Protocol Telnet is disabled by default and cannot be enabled in the
evaluated configuration. Telnet is insecure protocols which
allow for plaintext passwords to be transmitted. Use SSH only
as the management protocols to manage the TOE.
​ ​
Page 13 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
Feature Description
HTTP HTTP is disabled by default and cannot be enabled in the
evaluated configuration.
External Authentication Servers The WildFire appliance supports the optional use of RADIUS
as an authentication server, but this is not claimed in the TOE’s
evaluated configuration.
WildFire Cloud Other deployments of WildFire are cloud-based and not within
the scope of this evaluation.
Shell and Console Access The shell and console access is only allowed for
pre-operational installation, configuration, and
post-operational maintenance and troubleshooting.
Any features not associated
with SFRs in claimed [NDcPP]
and [SSHPKG]
[NDcPP] and [SSHPKG] forbids adding additional
requirements to the Security Target (ST). If additional
functionalities are mentioned in the ST, it is for completeness
only.
​ ​
Page 14 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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, 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 not applicable here.
​ ​
Page 15 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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. NOTE: OE.COMPONENTS_RUNNING is not applicable because this is not a
distributed TOE. [NDcPP] also has a virtualization related objective (OE.VM_CONFIGURATION) that is not
applicable here.
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 TOEs supporting X.509v3 certificate-based
authentication, the Security Administrator(s) are assumed
to monitor the revocation status of all certificates in the
TOE's trust store and to remove any certificate from the
TOE’s trust store in case such certificate can no longer be
trusted.
OE.RESIDUAL_INFORMATION​ The Security Administrator ensures that there is no
unauthorized access possible for sensitive residual
information (e.g. cryptographic keys, keying material,
PINs, passwords etc.) on networking equipment when the
equipment is discarded or removed from its operational
environment. For vNDs, this applies when the physical
​ ​
Page 16 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
platform on which the VM runs is removed from its
operational environment.
​
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].
As a result, refinements and operations already performed in that PP and FP are not identified (e.g.,
highlighted) here, rather the requirements have been copied from that PP and any residual operations have
been completed herein. Of particular note, the [NDcPP] and [SSHPKG] made a number of refinements and
completed some of the SFR operations defined in the CC and that PP and FP should be consulted to identify
those changes if necessary.
The SARs are the set of mandatory SARs and the 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] with optional
ALC_FLR.3. 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)
​ ​
Page 17 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
Requirement Class Requirement Component
FCS_COP.1/KeyedHash: Cryptographic Operation (Keyed Hash
Algorithm)
FCS_RBG_EXT.1: Random Bit Generation
FCS_SSH_EXT.1: SSH Protocol
FCS_SSHS_EXT.1: SSH Protocol - Server
FCS_TLSC_EXT.1: TLS Client Protocol
FCS_TLSS_EXT.1: TLS Server Protocol
FCS_TLSS_EXT.2: TLS Server Support for Mutual Authentication
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(1): X.509 Certificate Authentication (Syslog
Connections)
FIA_X509_EXT.2(2): X.509 Certificate Authentication (Firewall
Connections)
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
​ ​
Page 18 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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
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_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)
​ ​
Page 19 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
Requirement Auditable Events Additional Audit Record
Contents
●​ None ●​ None
FCS_SSHS_EXT.1 None None
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)
FIA_PMG_EXT.1 None. None.
FIA_UIA_EXT.1 All use of identification and
authentication mechanisms.
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(1)
FIA_X509_EXT.2(2)
None. None.
FIA_X509_EXT.3 None. None.
FMT_MOF.1/ManualUpdate Any attempt to initiate a manual
update
None.
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).
1
Importing CA certificate(s) or generating CA certificate(s) internally will implicitly set them as trust anchor.
​ ​
Page 20 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
Requirement Auditable Events Additional Audit Record
Contents
FTA_SSL.3 The termination of a remote session
by the session locking mechanism.
None.
FTA_SSL.4 The termination of an interactive
session.
None.
FTA_TAB.1 None. None.
FTP_ITC.1 ●​ Initiation of the trusted
channel.
●​ Termination of the trusted
channel.
●​ Failure of the trusted
channel functions.
●​ None
●​ None
●​ Reason for failure
FTP_TRP.1/Admin ●​ Initiation of the trusted
path.
●​ Termination of the trusted
path.
●​ Failure 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 [
●​ 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 [drop new audit data] 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 unauthorized deletion.
​ ​
Page 21 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
FAU_STG.1.2​ The TSF shall be able to prevent unauthorized modifications to the stored audit records in
the audit trail.
5.2.2​ Cryptographic Support (FCS)
FCS_CKM.1 – Cryptographic Key Generation
FCS_CKM.1.1​ The TSF shall generate asymmetric cryptographic keys in accordance with a
specified cryptographic key generation algorithm: [
●​ RSA schemes using cryptographic key sizes of [2048-bits, 3072-bits, and
4096-bits] that meet the following: FIPS PUB 186-4, “Digital Signature
Standard (DSS)”, Appendix B.3 or FIPS PUB 186-5, “Digital Signature
Standard (DSS)”, A.1;
●​ 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
or FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Appendix A.2, or
ISO/IEC 14888-3, “IT Security techniques - Digital signatures with appendix -
Part 3: Discrete logarithm based mechanisms”, Section 6.6.;
●​ FFC Schemes using ‘safe-prime’ groups that meet the following: “NIST Special
Publication 800-56A Revision 3, Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography” and [RFC
3526].
] and specified cryptographic key sizes [assignment: cryptographic key sizes]
that meet the following: [assignment: list of standards].
FCS_CKM.2 – Cryptographic Key Establishment
FCS_CKM.2.1​ The TSF shall perform cryptographic key establishment in accordance with a
specified cryptographic key establishment method: [
●​ Elliptic curve-based key establishment schemes that meet the following: NIST
Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”;
●​ FFC Schemes using “safe-prime” groups that meet the following: ‘NIST Special
Publication 800-56A Revision 3, “Recommendation for 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 [logically
addresses the storage location of the key and performs a [single, [three or
more]-pass] overwrite consisting of [[alternating ones and zeroes]]]
that meets the following: No Standard.
​ ​
Page 22 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
FCS_COP.1/DataEncryption – Cryptographic Operation (AES Data Encryption/Decryption)
FCS_COP.1.1/DataEncryption​ The TSF shall perform encryption/decryption in accordance with a specified
cryptographic algorithm AES used in [CBC, CTR, GCM] mode and cryptographic key
sizes [128 bits, 256 bits] that meet the following: AES as specified in ISO 18033-3,
[CBC as specified in ISO 10116, CTR as specified in ISO 10116, GCM as specified in ISO
19772].
FCS_COP.1/SigGen – Cryptographic Operation (Signature Generation and Verification)
FCS_COP.1.1/SigGen​ The TSF shall perform cryptographic signature services (generation and verification) in
accordance with a specified cryptographic algorithm [
●​ RSA Digital Signature Algorithm,
●​ 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 or FIPS PUB 186-5, “Digital Signature Standard
(DSS)”, Section 5.4 using PKCS #1 v2.2 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 implementing [P-256, P-384, P-521] curves that meet the
following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and
Appendix D, Implementing “NIST Recommended curves” or FIPS PUB 186-5,
“Digital Signature Standard (DSS)”, Section 6 and NIST SP 800-186 Section
3.2.1, Implementing Weierstrass curves; or ISO/IEC 14888-3, “IT Security
techniques - Digital signatures with appendix - Part 3: Discrete logarithm
based mechanisms”, Section 6.6.
].
FCS_COP.1/Hash – Cryptographic Operation (Hash Algorithm)
FCS_COP.1.1/Hash​ The TSF shall perform cryptographic hashing services in accordance with a specified
cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] and cryptographic
key sizes [assignment: cryptographic key sizes] and message digest sizes [160, 256,
384, 512] bits that meet the following: ISO/IEC 10118-3:2004.
FCS_COP.1/KeyedHash – Cryptographic Operation (Keyed Hash Algorithm)
FCS_COP.1.1/KeyedHash​ The TSF shall perform keyed-hash message authentication in accordance
with a specified cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256,
HMAC-SHA-384, HMAC-SHA-512, implicit] and cryptographic key sizes [160, 256,
384, 512] and message digest sizes [160, 256, 384, 512] bits that meet the
following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”.
​ ​
Page 23 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
FCS_RBG_EXT.1 – Random Bit Generation
FCS_RBG_EXT.1.1​ The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using [CTR_DRBG (AES)].
FCS_RBG_EXT.1.2 ​ The deterministic RBG shall be seeded by at least one entropy source that
accumulates entropy from [[one] platform-based noise source] with 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, [4256, 4344, 5647, 5656, 6668, 8308, 8332]
and [no other standard].
FCS_SSH_EXT.1.2​ The TSF shall ensure that the SSH protocol implementation supports the following
user authentication methods: [
●​ “password” (RFC 4252),
●​ “keyboard-interactive” (RFC 4256),
●​ “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 [
​ ​
Page 24 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
●​ 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 8422
●​ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 8422
●​ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 8422
●​ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 8422
●​ 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.
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].
​ ​
Page 25 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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 - TLS Server Protocol
FCS_TLSS_EXT.1.1 ​ The TSF shall implement [TLS 1.2 (RFC 5246)] and reject all other TLS and SSL
versions. The TLS implementation will support the following ciphersuites:
[
●​ TLS_DHE_RSA_WITH_AES_128_SHA as defined in RFC 5246
●​ TLS_DHE_RSA_WITH_AES_256_SHA as defined in RFC 5246
●​ TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
●​ TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
●​ TLS_ECDHE_ECDSA_WITH_AES_128_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_SHA as defined in RFC 8422
●​ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 8422
​ ​
Page 26 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
] and no other ciphersuites.
FCS_TLSS_EXT.1.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 ​ 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]
].
FCS_TLSS_EXT.1.4 ​ The TSF shall support [session resumption based on session tickets according to RFC
5077 (TLS 1.2)].
FCS_TLSS_EXT.1.5 ​ The TSF [does not provide] the ability to configure the list of supported ciphersuites
as defined in FCS_TLSS_EXT.1.1.
FCS_TLSS_EXT.1.6 ​ The TSF shall prohibit the use of the following extensions:
●​ Early data extension
FCS_TLSS_EXT.1.7 ​ The TSF shall [not use PSKs].
FCS_TLSS_EXT.1.8 ​ The TSF shall [reject [TLS 1.2] renegotiation attempts].
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] Certificate Request message containing the
following algorithms: [
●​ rsa_pkcs1 with sha256(0x0401),
●​ rsa_pkcs1with sha384(0x0501),
●​ rsa_pkcs1 with sha512(0x0601),
​ ​
Page 27 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
●​ ecdsa_secp256r1 with sha256(0x0403),
●​ ecdsa_secp384r1 with sha384(0x0503),
] and no other algorithms.
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 Administrator from successfully establishing remote session using
any authentication method that involves a password until an Administrator defined time period
has elapsed].
FIA_PMG_EXT.1 – Password Management
FIA_PMG_EXT.1.1​ The TSF shall provide the following password management capabilities for
administrative passwords:
1.​ Passwords shall be able to be composed of any combination of upper and
lower case letters, numbers, and the following special characters: [“!”, “@”,
“#”, “$”, “%”, “^”, “&”, “*”, “(”, “)”, [“'”, “+”, “,”, “-”, “.”, “/”, “:”, “;”, “<”, “=”, “>”, “[”, “\”,
“]”, “_”, “`”, “{”, “}”, “~”, and “all Unicode characters”]];
2.​ Minimum password length shall be configurable to between [8] and [15]
characters.
FIA_UIA_EXT.1 – User Identification and Authentication
FIA_UIA_EXT.1.1​ The TSF shall allow the following actions prior to requiring the non-TOE entity to
initiate the identification and authentication process:
●​ Display the warning banner in accordance with FTA_TAB.1;
●​ [[ICMP]].
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 [SSH
password, SSH public key] 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.
​ ​
Page 28 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
●​ The certificate path must terminate with a trusted CA certificate as a trust
anchor.
●​ The TSF shall validate a certification path by ensuring that all CA certificates in
the certification path contain the basicConstraints extension with the CA flag
set to TRUE.
●​ The TSF shall validate the revocation status of the certificate using [the
Online Certificate Status Protocol (OCSP) as specified in RFC 6960, a Certificate
Revocation List (CRL) as specified in RFC 5280 Section 6.3, Certificate
Revocation List (CRL) as specified in RFC 5759 Section 5].
●​ The TSF shall validate the extendedKeyUsage field according to the following
rules:
o​ Certificates used for trusted updates and executable code integrity
verification shall have the Code Signing purpose (id-kp 3 with OID
1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.
o​ Server certificates presented for 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(1) – X.509 Certificate Authentication (Syslog Connection)
FIA_X509_EXT.2.1(1) ​ The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for [TLS], and [no additional uses].
FIA_X509_EXT.2.2(1) ​ When the TSF cannot establish a connection to determine the validity of a
certificate, the TSF shall [not accept the certificate].
FIA_X509_EXT.2(2) – X.509 Certificate Authentication (Firewall Connections)
FIA_X509_EXT.2.1(2) ​ The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for [TLS], and [no additional uses].
FIA_X509_EXT.2.2(2) ​ When the TSF cannot establish a connection to determine the validity of a
certificate, the TSF shall [allow the Administrator to choose whether to accept the
certificate in these cases].
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, Country].
FIA_X509_EXT.3.2 ​ The TSF shall validate the chain of certificates from the Root CA upon receiving the
CA Certificate Response.
​ ​
Page 29 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
5.2.4​ Security Management (FMT)
FMT_MOF.1/ManualUpdate - Management of Security Functions Behaviour
FMT_MOF.1.1/ManualUpdate​ The TSF shall restrict the ability to enable the functions to perform manual
updates to Security Administrators.
FMT_MTD.1/CoreData – Management of TSF Data
FMT_MTD.1.1/CoreData​ The TSF shall restrict the ability to manage the TSF data to Security
Administrators.
FMT_SMF.1 – Specification of Management Functions
FMT_SMF.1.1​ The TSF shall be capable of performing the following management functions:
●​ Ability to administer the TOE 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 the list of TOE-provided services available before an entity
is identified and authenticated, as specified in FIA_UIA_EXT.1;
o​ Ability to configure the cryptographic functionality;
o​ Ability to configure thresholds for SSH rekeying;
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.
​ ​
Page 30 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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-SHA-1 Known Answer Test
●​ HMAC-SHA-256 Known Answer Test
●​ HMAC-SHA-384 Known Answer Test
●​ HMAC-SHA-512 Known Answer Test
●​ SHA-1 Known Answer Test
●​ SHA-256 Known Answer Test
●​ SHA-384 Known Answer Test
●​ SHA-512 Known Answer Test
●​ DRBG SP800-90A Known Answer Tests
●​ SP 800-90A Section 11.3 Health Tests
●​ DH Known Answer Test
●​ ECDH Known Answer Test
●​ SP 800-135 KDF Known Answer Tests
●​ Firmware Integrity Test
●​ Pairwise Consistency Tests
●​ SP 800-90B Entropy Health Tests
].
to demonstrate the correct operation of the TSF.
Application Note: Modified per TD0836.
​ ​
Page 31 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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 a 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] 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 [
●​ transmitting audit records to an audit server using TLS].
​ ​
Page 32 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
FTP_TRP.1/Admin – Trusted Path
FTP_TRP.1.1/Admin​ The TSF shall be capable of using [SSH] 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.
​ ​
Page 33 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
5.3 TOE Security Assurance Requirements
The security assurance requirements for the TOE are included by reference to [NDcPP] and 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 Documents apply to the TOE
evaluation:
●​ Supporting Document Mandatory Technical Document: Evaluation Activities for Network Device
cPP, 6 December-2023, Version 3.0e
●​ Functional Package for Secure Shell (SSH), Version 1.0, May 13, 2021
​ ​
Page 34 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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 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 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 device, 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 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 TOE does not provide an interface where a
user can modify the audit records, thus it prevents modification to the audit records.
When a log reaches the maximum size (at least 45 MB), the TOE drops new audit data.
Maximum disk space is dependent on the customer’s installation as it depends on the
number of hard drives installed on the system.
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
​ ​
Page 35 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
records are also written to the external syslog as they are written locally to the internal
logs. The locally stored audit records can be viewed via the CLI.
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, and certificate
generation uses only P-256 or
P-384.
FIPS PUB 186-4 Safe Primes
Key
Generation
#A3453
ECDSA
#A3453
RSA #A3453
RSA key generation (key
sizes 2048, 3072, 4096 bits)
Note that TLS uses 2048-bit
RSA keys while certificate and
SSH RSA key pair generation
use 2048, 3072, or 4096-bit
keys.
FIPS PUB 186-4
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 ECC #A3453
FFC #A3453
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
​ ​
Page 36 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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
AES #A3453
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
RSA #A3453
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
ECDSA
#A3453
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 SHS #A3453
Keyed-hash Message Authentication (FCS_COP.1/KeyedHash)
• HMAC-SHA-1 (key size
160 bits and digest size 160
bits)
• HMAC-SHA-256 ( key size
256 bits and digest size 256
bits)
• HMAC-SHA-384 (key size
384 bits and digest size 384
bits)
• HMAC-SHA-512 (key size
512 bits and digest size 512
bits)
ISO/IEC 9797-2:2011 HMAC
#A3453
Random Bit Generation (FCS_RBG_EXT.1)
​ ​
Page 37 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
CTR_DRBG (AES) from a
platform based noise source
of 256 bits of
non-determinism
ISO/IEC 18031:2011 DRBG
#A3453
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 from a proprietary hardware entropy source to seed the DRBG. The entropy
source is described in the proprietary Entropy Design document.
The TOE generates asymmetric cryptographic keys used for key establishment in
accordance with FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 for
RSA schemes, FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 for ECC
schemes, and Diffie-Hellman Groups according to RFC 3526.
While the TOE generally fulfills all of the FIPS PUB 186-4 requirements without
extensions, the following table specifically identifies the “should”, “should not”, and “shall
not” conditions from the publication along with an indication of whether the TOE
conforms to those conditions with deviations rationalized. Key generation is among the
identified sections.
Table 7 FIPS 186-4 Conformance
FIPS PUB 186-4
“should”, “should
not”, or “shall not”
Implemented
accordingly?
Rationale for
deviation
FIPS PUB 186-4
Appendix B.3
B.3.1 shall not Yes N/A
FIPS PUB 186-4
Appendix B.4
B.4.1 Should Yes N/A
B.4.2 Should Yes N/A
The TOE performs cryptographic 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 elliptic curve-based, and finite field-based key
establishment schemes. For TLS, the domain parameters used for the finite field-based
key establishment scheme are compliance with FIPS 186-4. For SSH, the ECC key
establishment only. NOTE: RFC 7919 (FFDHE) is not supported.
The claimed key generation and key establishment algorithms used for each function is
summarized below.
FCS_CKM.1:
-​ X.509 key pair generation: ECDSA (256, 384), RSA (2048, 3072, 4096)
-​ SSH RSA key pair generation: RSA (2048, 3072, 4096)
-​ SSH: ECDSA (256, 384, 521)
-​ TLS: ECC (256, 384, 521), FFC (2048)
​ ​
Page 38 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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 8 Private Keys and CSPs
CSP
#
CSP/Key Name Type Description
1
RSA Private Keys RSA RSA Private keys for verification of
signatures or authentication.
(RSA 2048, 3072, or 4096-bit)
2
ECDSA Private
Keys
ECDSA ECDSA Private key for verification of
signatures and authentication
(P-256, P-384, P-521)
3
TLS Pre-Master
Secret
TLS
Secret
Secret value used to derive the TLS
session keys
4
TLS DHE/ECDHE
Private
Components
DH Diffie-Hellman private FFC or EC
component used in TLS
(DHE 2048, ECDHE P-256, P-384,
P-521)
5
TLS HMAC Keys HMAC TLS integrity and authentication
session keys (HMAC-SHA-1,
HMAC-SHA2-256,
HMAC-SHA2-384)
6
TLS Encryption
Keys
AES TLS encryption session keys
(128 and 256 CBC or GCM)
7
SSH Session
Integrity Keys
HMAC Used in all SSH connections to the
security module’s command line
interface.
(HMAC-SHA2-256,
HMAC-SHA2-512)
8
SSH Session
Encryption Keys
AES Used in all SSH connections to the
security module’s command line
interface.
(128 and 256 bits in CBC and CTR, or
128 and 256 bits in GCM)
9
SSH ECDH Private
Components
ECDH ECDH and private component
(ECDH P-256, P-384, P-521)
​ ​
Page 39 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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 to be zeroized
17
Firmware Content
Encryption Key
AES-256 Used to encrypt/decrypt firmware,
software, and sensitive content.
18
Password Password Authentication string with a
minimum length of 8 characters.
Stored hashed with SHA-256 and
nonce.
19
DRBG Seed /State DRBG AES 256 CTR DRBG used in the
generation of a random values.
The TOE performs a key error detection check on each internal, intermediate transfer of
a key. The TOE stores persistent secret and private keys in encrypted form (AES-CBC
encrypted) when not in use. The KEK (256-bit AES key) is the Firmware Content
Encryption Key (also known as the Master Key). The KEK is not stored encrypted but is
protected by Cryptod. The KEK is destroyed by the TOE’s overwriting method. The TOE
also zeroizes 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 in volatile memory 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 (e.g., TLS encryption keys, SSH session keys) and CSPs (e.g.,
TLS Pre-Master secret, ECDHE/DHE private components) 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 of ones and zeros 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. Only the KEK
is stored in plaintext. It is used to encrypt all the private keys and other sensitive data.
When a new KEK is generated, the old KEK is destroyed via key store APIs that
overwrites the old 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.
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, followed by
​ ​
Page 40 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
a read-verify. Sensitive data in volatile memory includes session keys such as encryption
keys, integrity keys, and the Pre-Master secret.
FCS_TLSC_EXT.1
FCS_TLSS_EXT.1
FCS_TLSS_EXT.2
The TOE can be configured as a TLS server for mutual certificate-based authentication
for secure connections. 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, ECDHE
implementing NIST curves secp256r1, secp384r1, and secp521r1. The TOE supports
session resumption using 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. TOE does not support fallback authentication for TLS. The TOE denies
connections from clients requesting connections using SSL 2.0, SSL 3.0, TLS 1.0 or TLS
1.1 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 section 6. If the client certificate is not valid, the TOE
will not establish a connection.
The TOE can be configured as a TLS client for secure communication to an external audit
server. The TOE verifies that the presented identifier matches the reference identifier
(identifiers in RFC 6125 section 6) 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 Common Name (Subject), FQDN
(hostname), and prioritizing the SAN field (if it exists) over the CN field. The TOE
supports FQDN reference identifier and wildcards for peer authentication; IP addresses
are not used in the evaluated configuration for the syslog connection. The TOE presents
the Supported Elliptic Curves Extension in the Client Hello with the secp256r1,
secp384r1, and secp521r1 NIST curves and is enabled by default. Additionally, the TOE
supports RSA key sizes of 2048/3072/4096 bits, and ECDSA curves of P-256/384/521
for the digital signature algorithms that may be present in the TLS server certificate.
The TOE implements only TLS 1.2 (RFC 5246), and does not support cipher suite
configuration.
TOE (as TLS client) to syslog server supports the following cipher suites:
●​ 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 8422
●​ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 8422
●​ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 8422
●​ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 8422
●​ 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
​ ​
Page 41 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
TOE (as TLS server) connection to firewall (same for mutual authentication) supports
TLS:
●​ TLS_DHE_RSA_WITH_AES_128_SHA as defined in RFC 5246
●​ TLS_DHE_RSA_WITH_AES_256_SHA as defined in RFC 5246
●​ TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
●​ TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
●​ TLS_ECDHE_ECDSA_WITH_AES_128_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_SHA as defined in RFC 8422
●​ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 8422
When FIPS-CC mode is enabled, all TLS connections will only support the following
signature algorithm extensions for TLS mutual authentication (by default):​
●​ rsa_pkcs1 with sha256(0x0401),
●​ rsa_pkcs1with sha384(0x0501),
●​ rsa_pkcs1 with sha512(0x0601),
●​ ecdsa_secp256r1 with sha256(0x0403),
●​ ecdsa_secp384r1 with sha384(0x0503)
For TLS client functionality in FIPS-CC mode, the TOE supports the following signature
algorithm extensions (by default):
●​ 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, 8308, 8332) with AES encryption/decryption algorithm (in CBC, CTR,
or GCM mode) with key sizes of 128 or 256 bits. The TOE does not support any other
optional characteristics for encryption or public key algorithms. The TOE also supports
HMAC-SHA-256, HMAC-SHA-512, implicit MAC (aes128-gcm@openssh.com and
aes256-gcm@openssh.com) for integrity. Both encryption and integrity algorithms are
administrator-configurable and while 3DES, HMAC-MD5, diffie-hellman-group-1 are
also supported, they are all disabled when FIPS-CC mode is enabled. Only the Approved
encryption and integrity algorithms along with key exchange algorithms
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. 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
implements SSH KDF as defined in RFC 5656 section 4 for use in ECC key establishment
​ ​
Page 42 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
schemes. Additionally, the SSH KDF that is utilized by the TOE has been algorithm
tested and received a CAVP certificate to ensure that the KDF is functioning properly.
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 but configurable. In addition, public-key (RSA), keyboard-interactive,
and password-based authentication can be configured with password-based being the
default method. For password, the TOE verifies the user identity when the username is
entered. For public-key, the administrator must associate the public key to the user. SSH
packets are limited to 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 that 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 an 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, password, and a
role. Only one role is specified in the user account per user. The administrator can
also specify an SSH key to be used instead of a password.
The TOE uses the username and password or an SSH key to identify and authenticate
the user when the user logs in via the CLI. The TOE does not echo passwords as they
are entered, and the private keys are never transmitted. When accessing the CLI, the
default authentication method is password. The administrators must configure
public-key authentication which is supported for SSH sessions. It uses the role
attribute to specify user permissions and control what the user can do with the CLI.
The administrator can logon to CLI by using a secure connection (SSHv2) from an
SSH client. The TOE provides secure access using an SSHv2 client. The administrator
enters the IP address/hostname of the TOE and their username and password or
their corresponding SSH key.
A logon successful note is provided when the correct credentials are used (username
and password or SSH key) that matches a defined account on 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 15 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.
​ ​
Page 43 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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 (0 – 60 minutes) during which providing the correct credentials will
still not allow access (i.e. locked out). A setting of “0” will lock out the user
indefinitely. In this case, the Administrator must unlock the locked user.
These settings can be configured for SSH administration connections but applies to
password authentication only. Public-key authentication is not vulnerable to weak
passwords that can be brute-forced. In the evaluated configuration, it is required that
at least one administrator, preferably the Superuser role (predefined ‘admin’
account), is configured with public-key authentication for SSH to prevent a denial of
service due to locked accounts.
FIA_X509_EXT.1/Rev The TOE uses X.509v3 certificates as defined by RFC 5280 to support authentication
for TLS connections (client and server authentication). 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 Certificate Revocation List (CRL) and Online Certificate Status
Protocol (OCSP) status verification for certificate profiles. CRL supports RFC 5280
and 5759 supporting strong Suite B ECDSA algorithms and curve sizes for signing
CRLs, and OCSP as specified in RFC 6960. In the evaluated configuration, the syslog
connection implements OCSP for status verification for the certificate. The
connection to the firewalls can use either CRLs or OCSP.
The TOE uses the following rules for validating the extendedKeyUsage 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 that the CA flag is set to TRUE for all CA certificates. The
TOE forms a Certificate trust path by ensuring that the basic constraints are met,
proper key usage parameters exist, the CA flag exists, performing a revocation check
of each certificate in the path and performing the validity of the CA certificate. The
TOE will not treat a certificate as a CA certificate if the basicConstraints extension is
not present or the CA flag is not set to TRUE.
The TOE supports certificate path validation for a minimum path length of three
certificates and terminates with a trusted CA certificate (i.e., Root certificate). The
Administrator must import or generate a root CA certificate and store it in the TOE
FIA_X509_EXT.2(1)
FIA_X509_EXT.2(2)
​ ​
Page 44 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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.
A certificate is checked for revocation status the first time it is used, and once
validated, the status is cached for one hour. The TOE downloads and caches the
last-issued CRL for every CA listed in the trusted CA list of the TOE. Caching only
applies to validated certificates; if a TOE never validated a certificate, the TOE cache
does not store the CRL for the issuing CA. Also, the cache only stores a CRL until it
expires (one hour period). The TOE supports CRLs only in Distinguished Encoding
Rules (DER) or PEM format.
The TLS session for Syslog is blocked when the certificate status is unknown or
cannot be determined. This is the default behavior for syslog connections and cannot
be changed. When configuring the TLS sessions for Firewalls, the administrator may
configure the profile whether or not to block connections when certificate status is
unknown or cannot be determined.
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: Common Name,
Organization, 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. 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
The TOE provides a CLI to support security management of the TOE. The CLI is
accessible securely over SSHv2. The restricted role-based privileges enable
only authorized administrators to configure the TOE functions such as updating
the TOE, managing X.509v3 certificates in the trust store, and manipulating
TSF data.
FMT_SMF.1 The security management functions provided by the TOE include:
●​ 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;
●​ Ability to configure the list of TOE-provided services available before
an entity is identified and authenticated, as specified in FIA_UIA_EXT.1;
●​ Ability to configure the cryptographic functionality;
●​ Ability to configure thresholds for SSH rekeying;
●​ Ability to set the time which is used for time-stamps;
●​ Ability to 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
​ ​
Page 45 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
The CLI provides the administrator the ability to administer the TOE securely
with all management functions. The management functions above can be
configured when the administrator successfully authenticates into the TOE via
the CLI.
FMT_SMR.2 The TOE controls user access to commands and resources based on user role.
Users are given permission to access a set of commands and resources based
on their user role. By default, the TOE has the following pre-defined
administrator roles: Superuser. The administrator role (Superuser) is
considered the Security Administrator as defined in the [NDcPP] for the
purposes of this ST. All roles can administer the TOE securely, and a user
account can only be assigned one role at a time.
●​ Superuser—Full read-write access to WildFire services
6.5​ Protection of the TSF
FPT_SKP_EXT.1 Certificates and their associated private key are stored in a single container: the
Certificate File. The PKCS#12 file consists of an Encrypted Private Key and X.509
Certificate. By default, all the private keys (including SSH 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 runs self-tests to ensure that the cryptographic capabilities of the TOE are
intact, which include the list below. These tests are performed each time the module
is powered on or when the administrator initiates it via CLI.
●​ AES Encrypt Known Answer Test
●​ AES Decrypt Known Answer Test
●​ AES GCM Encrypt Known Answer Test
●​ AES GCM Decrypt Known Answer Test
●​ AES CCM Encrypt Known Answer Test
●​ AES CCM Decrypt Known Answer Test
●​ RSA Sign Known Answer Test
●​ RSA Verify Known Answer Test
●​ RSA Encrypt/Decrypt Known Answer Test
●​ ECDSA Sign Known Answer Test
●​ ECDSA Verify Known Answer Test
●​ HMAC-SHA-1 Known Answer Test
●​ HMAC-SHA-256 Known Answer Test
​ ​
Page 46 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
●​ HMAC-SHA-384 Known Answer Test
●​ HMAC-SHA-512 Known Answer Test
●​ SHA-1 Known Answer Test
●​ SHA-256 Known Answer Test
●​ SHA-384 Known Answer Test
●​ SHA-512 Known Answer Test
●​ DRBG SP800-90A Known Answer Tests
●​ SP 800-90A Section 11.3 Health Tests
●​ DH Known Answer Test
●​ ECDH Known Answer Test
●​ SP 800-135 KDF Known Answer Tests
●​ Firmware Integrity Test
●​ Pairwise Consistency Tests
●​ SP 800-90B Entropy Health Tests
The software integrity is verified with HMAC-SHA-256 and ECDSA P-256. If the
calculated result does not equal the previously generated result, the integrity 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:
Conditional Self-Tests
●​ SP 800-90B health tests are performed at power-up and continuously
●​ RSA Pairwise Consistency Test
●​ ECDSA Pairwise Consistency Test
●​ Firmware Load Test – Verify firmware signatures using RSA 2048 with
SHA-256 at time of load
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.
​ ​
Page 47 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
If a self-test fails, the TOE enters an error state and outputs an error indicator. The
TOE does not 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 can query the current version of the TOE’s software
using the CLI with the command “show system info”, and are able to receive updates
from updates.paloaltonetworks.com using the command “request system software
check” followed by “request system software download <version>”. There is no
automatic installation of new software; an administrator must manually perform
this update. The Palo Alto Networks Update Server supports TLS and uses approved
cipher suites to ensure that downloads from the server are protected, and are not
tampered with in transit.
As an additional precaution, 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
(manual update).
When the TOE update package and its corresponding digital signature is
downloaded or uploaded; the digital signature is checked automatically by the 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 in
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 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, certificate validity checking,
timing administrator lockout due to excessive failed authentication attempts, and
for cryptographic operations based on time/date.
​ ​
Page 48 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
6.6​ TOE Access
FTA_SSL.3 The TOE will enforce an administrator-defined inactivity timeout value after which the
inactive, session will be terminated regardless of authentication methods (e.g.
password, public-key). 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 issued 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 authentication (i.e. restart an SSH
connection) in order to establish a new session once the session is terminated. The
users can also enter the ‘exit’ command to terminate user sessions.
FTA_SSL.4 The TOE provides the function to logout (or terminate) user sessions as directed by the
user.
FTA_TAB.1 The TOE can be configured to display an administrator-defined advisory banner prior to
authentication when accessing the TOE via a secure connection to the management
port in order to access the CLI (SSH).
6.7​ Trusted Path/Channels
FTP_ITC.1 The TOE can be configured to send audit records to an external syslog server using TLS
in real-time. The TOE permits the TSF to initiate communication with the syslog server
using the TLS trusted channel. The TOE (TLS server) can also communicate with the
Palo Alto Networks firewalls via TLS. Mutual authentication is supported but must be
configured for all TLS channels.
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 underlying TLS algorithms are supported by CAVP-validated
cryptographic mechanisms included in the TOE implementation.
FTP_TRP.1/Admin The TOE provides SSH to provide a communication path between itself and authorized
administrators. Administrators can initiate a secure session that is secure using CAVP
validated cryptographic operations, and all security management functions require the
use of this security channel. In FIPS-CC mode, Telnet and HTTP are disabled
permanently.
​ ​
Page 49 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
7.​ Protection Profile Claims
This ST is exact conformant to the [NDcPP] and [SSHPKG].
​ ​
Page 50 of 51
WF-500-B WildFire 11.1 Security Target​ ​ ​
Palo Alto Networks
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
and functional package 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 ALC_FLR.3. Consequently, [NDcPP] and [SSHPKG] rationale applies and is
complete.
​ ​
Page 51 of 51