assurance activities report for palo alto networks pa-200 ... · december 2011 (stff) network ......

Assurance Activities Report

for

Palo Alto Networks PA-200, PA-500, PA-

2000 Series, PA-3000 Series, PA-4000 Series,

PA-5000 Series, PA-7000 Series, VM Series,

Next-Generation Firewall with PAN-OS

7.0.1-h4

Version 0.4

November 23, 2015

Evaluated By:

Leidos Inc. (formerly Science Applications International Corporation)

Common Criteria Testing Laboratory

6841 Benjamin Franklin Drive

Columbia, MD 21046

Prepared for:

National Information Assurance Partnership

Common Criteria Evaluation and Validation Scheme

of 90

The Developer of the TOE:

Palo Alto Networks, Inc.

4401 Great America Parkway

Santa Clara, CA 95054

The TOE Evaluation was sponsored by:

Palo Alto Networks, Inc.

4401 Great America Parkway

Santa Clara, CA 95054

Evaluation Personnel: Katie Sykes

Cody Cummins

Kevin Steiner

Justin Sagurton

Protection Profile

Protection Profile for Network Devices, Version 1.1, 8 June 2012, as amended by Errata #3 dated 03 November

2014 (NDPP) and CSfC Selections for VPN Gateways

Network Device Protection Profile (NDPP) Extended Package Stateful Traffic Filter Firewall, Version 1.0, 19

December 2011 (STFF)

Network Device Protection Profile (NDPP) Extended Package VPN Gateway, Version 1.1, 12 April 2013 (VPNGW)

as amended by CSfC Selections for VPN Gateways (CSfC)

of 90

1. INTRODUCTION ............................................................................................................................................... 5

1.1 EVIDENCE ....................................................................................................................................................... 5

2. SECURITY FUNCTIONAL REQUIREMENT ASSURANCE ACTIVITIES .............................................. 6

2.1 SECURITY AUDIT (FAU)................................................................................................................................. 6 2.1.1 Audit Data Generation (FAU_GEN.1) .................................................................................................. 6 2.1.2 User Audit Association (FAU_GEN.2) .................................................................................................. 9 2.1.3 External Audit Trail Storage (FAU_STG_EXT.1) ................................................................................. 9

2.2 CRYPTOGRAPHIC SUPPORT (FCS) ................................................................................................................ 10 2.2.1 Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1(1)) ........................................... 10 2.2.2 Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1(2)) ........................................... 12 2.2.3 Cryptographic Key Zeroization (FCS_CKM_EXT.4) .......................................................................... 14 2.2.4 Cryptographic Operation (for data encryption/decryption) (FCS_COP.1(1)) .................................... 14 2.2.5 Cryptographic Operation (for cryptographic signature) (FCS_COP.1(2))......................................... 15 2.2.6 Cryptographic Operation (for cryptographic hashing) (FCS_COP.1(3)) ........................................... 16 2.2.7 Cryptographic Operation (for keyed-hash message authentication) (FCS_COP.1(4)) ....................... 16 2.2.8 Explicit: IPSEC (FCS_IPSEC_EXT.1) ................................................................................................ 17 2.2.9 Extended: Cryptographic Operation (Random Bit Generation) (FCS_RBG_EXT.1) ......................... 28 2.2.10 Explicit: HTTPS (FCS_HTTPS_EXT.1) .............................................................................................. 29 2.2.11 Explicit: TLS (FCS_TLS_EXT.1) ......................................................................................................... 30

2.3 USER DATA PROTECTION (FDP)................................................................................................................... 32 2.3.1 Full Residual Information Protection (FDP_RIP.2) ........................................................................... 32

2.4 IDENTIFICATION AND AUTHENTICATION (FIA)............................................................................................. 32 2.4.1 Authentication Failure Handling (FIA_AFL.1) ................................................................................... 32 2.4.2 Password Management (FIA_PMG_EXT.1) ....................................................................................... 33 2.4.3 Protected Authentication Feedback (FIA_UAU.7) .............................................................................. 34 2.4.4 User Identification and Authentication (FIA_UIA_EXT.1) ................................................................. 35 2.4.5 Extended: Password-based Authentication Mechanism (FIA_UAU_EXT.2) ...................................... 36 2.4.6 Extended: X509 Certificates (FIA_X509_EXT.1) ............................................................................... 36

2.5 SECURITY MANAGEMENT (FMT) ................................................................................................................. 40 2.5.1 Management of Security Functions Behavior (FMT_MOF.1) ............................................................. 40 2.5.2 Management of TSF Data (for general TSF data) (FMT_MTD.1) ...................................................... 40 2.5.3 Specification of Management Functions (FMT_SMF.1) ..................................................................... 41 2.5.4 Restrictions on Security Roles (FMT_SMR.2) ..................................................................................... 42 2.6.1 Extended Packet Filtering (FPF_RUL_EXT.1) ................................................................................... 42

2.7 PROTECTION OF THE TSF (FPT) ................................................................................................................... 52 2.7.1 Extended: Protection of Administrator Passwords (FPT_APW_EXT.1) ............................................. 52 2.7.2 Extended: Protection of TSF Data (for reading of all symmetric keys) (FPT_SKP_EXT.1) ............... 53 2.7.3 Fail Secure (FPT_FLS) ....................................................................................................................... 53 2.7.4 Reliable Time Stamp (FPT_STM.1) ..................................................................................................... 54 2.7.5 TSF Testing (FPT_TST_EXT.1) ........................................................................................................... 54 2.7.6 Extended: Trusted Update (FPT_TUD_EXT.1) ................................................................................... 56

2.8 TOE ACCESS (FTA) ..................................................................................................................................... 57 2.8.1 TSF-Initiated Termination (FTA_SSL.3) ............................................................................................. 57 2.8.2 User-Initiated Termination (FTA_SSL.4) ............................................................................................ 57 2.8.3 TSF-Initiated Session Locking (FTA_SSL_EXT.1) .............................................................................. 58 2.8.4 Default TOE Access Banners (FTA_TAB.1) ........................................................................................ 58

2.9 TRUSTED PATH/CHANNELS (FTP) ................................................................................................................ 59 2.9.1 Inter-TSF Trusted Channel (FTP_ITC.1) ............................................................................................ 59 2.9.2 Trusted Path (FTP_TRP.1) .................................................................................................................. 60

2.10 STATEFUL TRAFFIC FILTERING (FFW) ......................................................................................................... 61 2.10.1 Stateful Traffic Filtering (FFW_RUL_EXT.1) ..................................................................................... 61

3. SECURITY ASSURANCE REQUIREMENT ASSURANCE ACTIVITIES .............................................. 82

3.1 DEVELOPMENT (ADV) ................................................................................................................................. 82

of 90

3.1.1 Basic Functional Specification (ADV_FSP.1) ..................................................................................... 82 3.2 GUIDANCE DOCUMENTS (AGD) ................................................................................................................... 82

3.2.1 Operational User Guidance (AGD_OPE.1) ........................................................................................ 82 3.2.2 Preparative Procedures (AGD_PRE.1) ............................................................................................... 85

3.3 TESTS (ATE) ................................................................................................................................................ 85 3.3.1 Independent Testing – Conformance (ATE_IND.1) ............................................................................. 85

3.4 VULNERABILITY ASSESSMENT (AVA) ......................................................................................................... 88 3.4.1 Vulnerability Survey (AVA_VAN.1) ..................................................................................................... 88

3.5 LIFE-CYCLE SUPPORT (ALC) ....................................................................................................................... 89 3.5.1 Labeling of the TOE (ALC_CMC.1) .................................................................................................... 89 3.5.2 TOE Coverage (ALC_CMS.1) ............................................................................................................. 90

LIST OF TABLES

NO TABLE OF FIGURES ENTRIES FOUND.

of 90

1. Introduction

This document presents results from performing assurance activities associated with the Palo Alto Networks PA-

200, PA-500, PA-2000 Series, PA-3000 Series, PA-4000 Series, PA-5000 Series, PA-7000 Series, VM Series, Next-

Generation Firewall with PAN-OS 7.0.1-h4 evaluation. This report contains sections documenting the performance

of assurance activities associated with each of the Security Functional Requirements (SFRs) and Security Assurance

Requirements (SARs) as specified in the Protection Profile for Network Devices, Version 1.1, 8 June 2012, as

amended by Errata #3 dated 03 November 2014 and CSfC Selections for VPN Gateways, the Network Device

Protection Profile (NDPP) Extended Package Stateful Traffic Filter Firewall, Version 1.0, 19 December 2011

(TFFW) and the Network Device Protection Profile (NDPP) Extended Package VPN Gateway, Version 1.1, 12 April

2013 (VPNGW) as amended by CSfC Selections for VPN Gateways (CSfC).

1.1 Evidence

[ST] Palo Alto Networks PA-200, PA-500, PA-2000 Series, PA-3000 Series, PA-4000 Series, PA-5000

Series, PA-7000 Series, VM Series, Next-Generation Firewall with PAN-OS 7.0.1-h4 Security

Target v1.0, November 23, 2015

[NDPP] Protection Profile for Network Devices, Version 1.1, 8 June 2012, as amended by Errata #3 dated

03 November 2014 and CSfC Selections for VPN Gateways

[TFFW] Network Device Protection Profile (NDPP) Extended Package Stateful Traffic Filter Firewall,

Version 1.0, 19 December 2011

[VPNGW] Network Device Protection Profile (NDPP) Extended Package VPN Gateway, Version 1.1, 12

April 2013 as amended by CSfC Selections for VPN Gateways (CSfC)

[ADMIN] Palo Alto Networks PAN-OS Administrator’s Guide Version 7.0.1-h4

[CCECG] Common Criteria Evaluated Configuration Guide, Palo Alto Networks Next Generation Firewall,

Document Version 1.0, November 23, 2015

[WEB] Palo Alto Networks Web Interface Reference Guide

of 90

2. Security Functional Requirement Assurance Activities

This section describes the assurance activities associated with the SFRs defined in the ST and the results of those

activities as performed by the evaluation team. The assurance activities are derived from the Protection Profile for

Network Devices, Version 1.1, 8 June 2012, as amended by Errata #3 dated 03 November 2014 and CSfC Selections

for VPN Gateways, the Network Device Protection Profile (NDPP) Extended Package Stateful Traffic Filter

Firewall, Version 1.0, 19 December 2011 (TFFW) and the Network Device Protection Profile (NDPP) Extended

Package VPN Gateway, Version 1.1, 12 April 2013 (VPNGW) as amended by CSfC Selections for VPN Gateways

(CSfC).

2.1 Security Audit (FAU)

2.1.1 Audit Data Generation (FAU_GEN.1)

2.1.1.1 FAU_GEN.1.1

2.1.1.1.1 TSS Assurance Activities

The evaluator shall check to ensure that the TSS contains a list (possibly empty except for authentication failures for

user-level connections) of the protocol failures that are auditable. The evaluator shall test all identified audit events

during protocol testing/audit testing.

The evaluator shall verify that the TSS describes how the Packet filter firewall rules can be configured to log

network traffic associated with applicable rules. Note that this activity should have been addressed with a

combination of the TSS assurance activities for FPF_RUL_EXT.1.

The evaluator shall verify that the TSS describes how the TOE behaves when one of its interfaces is overwhelmed

by network traffic. It is acceptable for the TOE to drop packets that it cannot process, but under no circumstances is

the TOE allowed to pass packets that do not satisfy a rule that allows the permit operation or belong to an allowed

established session. It may not always be possible for the TOE to audit dropped packets due to implementation

limitations. These limitations and circumstances in which the event of dropped packets is not audited shall be

described in the TSS.

The evaluator shall verify that the TSS describes how the stateful traffic filter firewall rules can be configured to log

network traffic associated with applicable rules. Note that this activity should have been addressed with a

combination of the TSS assurance activities for FFW_RUL_EXT.1.

Section 6.1 indicates that the only protocol (i.e., HTTPS, TLS) failures auditable by the TOE are authentication

failures for user-level connections. Section 6.9 and 6.10 indicate that each packet filter or firewall rule, and each

stateful traffic filter firewall rule can be configured to generate a log record when the traffic matches the defined rule

using the ‘policy->Security->options’ selection. The logging option can be configured to log at the start of a session,

or at the end of a session or both.

Section 6.9 states that the TOE will drop the packets if one of its interfaces is overwhelmed by network traffic. The

7000 series provides higher performance, in order to compensate the FPGA is designed to drop IPv6 with “zero”

destination in the initial ingress packet processing. This event is logged in the FPGA counter log

“flow_fpga_rcv_igr_IPV6DSTZERO”.

2.1.1.1.2 Guidance Assurance Activities

The evaluator shall check the administrative guide and ensure that it lists all of the auditable events and provides a

format for audit records. Each audit record format type must be covered, along with a brief description of each field.

The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the

description of the fields contains the information required in FAU_GEN.1.2, and the additional information

specified in Table 1.

Section 2.7.1 of the CCECG references the ADMIN guide which describes the logs maintained by the TOE in the

“Monitoring” section. These logs include: Traffic; Threat; Configuration; System; and HIP Match. Taken together,

of 90

these log files provide the security audit trail that satisfies the auditing requirements specified in the PPs listed in

Section 1.1 of this document.

The “Monitoring” section of [ADMIN] (sub-section “Use Syslog for Monitoring”, topic “Syslog Field

Descriptions”) also describes the format of the records written to each of the log files, including a brief description

of each field.

Section 2.7.2 of the CCECG lists the auditable events mandated by the requirements in the PP’s and identifies to

which of the log files each auditable event is written. During testing, the evaluator confirmed that the audit messages

generated for all TOE audit events include the required information.

The evaluator shall also make a determination of the administrative actions that are relevant in the context of this

PP. The evaluator shall examine the administrative guide and make a determination of which administrative

commands, including subcommands, scripts, and configuration files, are related to the configuration (including

enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements

specified in the PP. The evaluator shall document the methodology or approach taken while determining which

actions in the administrative guide are security relevant with respect to this PP. The evaluator may perform this

activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements.

The evaluator examined the supplied guidance documentation, identifying all mechanisms available to the

administrator for configuring and managing the capabilities of the TOE. Those mechanisms related to the SFRs

specified in the ST were identified and mapped to the applicable SFRs. In addition, the evaluator sought to confirm

that all SFRs that would be expected to have a management capability related to them had appropriate management

capabilities identified in the guidance documentation. Section 2.7.2 of the CCECG indicates that all administrative

actions are recorded in the Config log.

The administrative actions identified as auditable are:

Start and reboot TOE

Enable FIPS mode

Set time

Configure syslog

Configure password control

Configure user lockout after authentication failure

Enable and configure TLS/HTTPS

Create a local user

Configure local authentication

Query current TOE software version

Initiate and verify software updates

Configure time interval of session inactivity

Configure the login banner

Terminate own session

Configure IPsec/IKE trusted channel to remote VPN gateways/peers, audit server, UIA, update server

Configure packet filtering

Configure firewall rules

Configure reference identifier for the peer

Configure x.509 certificates

The evaluator shall verify that the operational guidance describes how to configure the stateful traffic filter firewall

rules to result in applicable network traffic logging. Note that this activity should have been addressed with a

combination of the guidance assurance activities for FFW_RUL_EXT.1.

The evaluator shall verify that the operational guidance describes how to configure the Packet filter firewall rules to

result in applicable network traffic logging. Note that this activity should have been addressed with a combination of

the guidance assurance activities for FPF_RUL_EXT.1.

of 90


rules to result in applicable network traffic logging. Note that this activity should have been addressed with a

combination of the guidance assurance activities for FFW_RUL_EXT.1.

Section 2.7.3 of the CCECG references the “Policy” section of the ADMIN guide and indicates that the TOE uses

policies to enforce rules and specify actions to be taken by the TOE. It also provides the steps to navigate and

configure a security policy to log network traffic via the GUI. Security policy rules are used to determine whether to

block or allow a session based on traffic attributes such as the source and destination security zone, the source and

destination IP address, the application, user, and the service. When an administrator creates a security policy rule,

the administrator can specify if the TOE will log traffic matching the rule. The administrator does this as follows.

2.1.1.1.3 Test Activities

The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit

records for the events listed in table 1 and administrative actions. This should include all instances of an event--for

instance, if there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be generated

for each mechanism. The evaluator shall test that audit records are generated for the establishment and termination

of a channel for each of the cryptographic protocols contained in the ST. If HTTPS is implemented, the test

demonstrating the establishment and termination of a TLS session can be combined with the test for an HTTPS

session. For administrative actions, the evaluator shall test that each action determined by the evaluator above to be

security relevant in the context of this PP is auditable. When verifying the test results, the evaluator shall ensure the

audit records generated during testing match the format specified in the administrative guide, and that the fields in

each audit record have the proper entries.

Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly.

For example, testing performed to ensure that the administrative guidance provided is correct verifies that

AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the

audit records are generated as expected.

The following test is expected to execute outside the context of the other requirements. While testing the TOE’s

compliance against the SFRs, either specific tests are developed and run in the context of this SFR, or as is typically

done, the audit capability is turned on while testing the TOE’s behavior in complying to the other SFRs in this EP.

Test 1: The evaluator shall attempt to flood the TOE with network packets such that the TOE will be unable to

process all the packets. This may require the evaluator to configure the TOE to limit the bandwidth the TOE is

capable to handling (e.g., use of a 10 MB interface).

Test 2: The evaluator shall test that the interfaces used to configure the stateful traffic filter firewall rules for logging

yield expected network traffic logs in association with the applicable rules. A number of rule combination and

ordering scenarios need to be configured and tested by attempting to pass both valid and invalid network traffic

matching rules design to permit, deny and log matching network traffic. Note that this activity should have been

addressed with a combination of the Test assurance activities for FFW_RUL_EXT.1.

The evaluation team performed the testing specified in the assurance activity and confirmed the TOE’s ability to

generate the specified audit events.

Refer to the Evaluation Team Test Report for Palo Alto Networks PA-200, PA-500, PA-2000 Series, PA-3000

Series, PA-4000 Series, PA-5000 Series, PA-7000 Series, VM Series, Next-Generation Firewall with PAN-OS

7.0.1-h4 for details of testing of the auditing capabilities of the TOE.

2.1.1.2 FAU_GEN.1.2

2.1.1.2.1 Assurance Activity

This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1.

of 90

2.1.2 User Audit Association (FAU_GEN.2)

2.1.2.1 Assurance Activity

This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1.

2.1.3 External Audit Trail Storage (FAU_STG_EXT.1)

2.1.3.1 TSS Assurance Activities

For both types of TOEs (those that act as an audit server and those that send data to an external audit server), there is

some amount of local storage. The evaluator shall examine the TSS to ensure it describes the amount of audit data

that are stored locally; what happens when the local audit data store is full; and how these records are protected

against unauthorized access.

Section 6.1 of the ST indicates that the audit trail generated by the TOE comprises several logs, which are locally

stored in the PAN-OS file system on the hard disk:

Configuration logs—include events such as when an administrator configures the security policies, and

when an administrator configures which events gets audited

System logs—record user login and logout

Traffic logs—record the traffic flow events

Threat logs—record the detection and blocking of threats

The size of each log file is administrator configurable from the Web Interface by specifying the percentage of space

allocated to each log type on the hard disk. If the log size is reduced, the firewall removes the oldest logs when the

changes are committed. When a log reaches the maximum size, the firewall starts overwriting the oldest log entries

with the new log entries. Maximum disk space is platform dependent and it depends on the hard disk drive installed

on the system. For example, for a 120GB drive approximately 83GB is allocated for logging. Platform capabilities

range from a limit of 3-4GB for the PA-200 which has a 16GB flash drive and up for the larger platforms.

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 NDPP. The TOE does not provide an

interface where a user can modify the audit records, thus it prevents modification to the audit records.

The TOE can be configured to send generated audit records to an external Syslog server using TLS. When

configured to send audit records to a syslog server, audit records are also written to the external syslog as they are

written locally to the internal logs.

TOE is not an audit server

The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the

external audit server, and how the trusted channel is provided.

Section 6.1 indicates that the TOE can be configured to send generated audit records to an external Syslog server

using TLS. When configured to send audit records to a syslog server, audit records are also written to the external

syslog as they are written locally to the internal logs.

2.1.3.2 Guidance Assurance Activities

The evaluator shall also examine the operational guidance to determine that it describes the relationship between the

local audit data and the audit data that are sent to the audit log server. For example, when an audit event is

generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and

“cleared” periodically by sending the data to the audit server.

The evaluator shall also examine the operational guidance to ensure it describes how to establish the trusted channel

to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version

of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server.

of 90

Section 2.7.4 of the CCECG indicates that the TOE can be configured to forward generated audit records to an

external syslog server. When so configured, the TOE automatically converts the audit records to syslog format

before forwarding them to the external syslog server. Audit records are converted and forwarded to the external

syslog as they are written locally to the log files.

The “Monitoring” section of [ADMIN] (sub-section “Use Syslog for Monitoring”, topic “Configure Syslog

Monitoring”) provides information on how to configure the TOE to export audit records to a syslog server. Section

2.7.4 of the CCECG provides the steps to navigate and configure the TOE to export logs over a TLS-protected

channel.


The evaluator shall also examine the operational guidance to ensure it describes how to establish the trusted channel

to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version

of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server.

The “Monitoring” section of [ADMIN] (sub-section “Use Syslog for Monitoring”, topic “Configure Syslog

Monitoring”) provides information on how to configure the TOE to export audit records to a syslog server. Section

2.7.4 of the CCECG provides the steps to navigate and configure the TOE to export logs over a TLS-protected

channel.

2.1.3.3 Test Activities

Testing of the trusted channel mechanism will be performed as specified in the associated assurance activities for the

particular trusted channel mechanism.


The evaluator shall perform the following test for this requirement:

Test 1: The evaluator shall establish a session between the TOE and the audit server according to the configuration

guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE

during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server.

The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they

are successfully received by the audit server. The evaluator shall record the particular software (name, version) used

on the audit server during testing.


establish a trusted channel using TLS with the external audit server and transfer audit data to the server via the

trusted channel.



7.0.1-h4 for details of testing of transfer of audit data from the TOE.

2.2 Cryptographic Support (FCS)

2.2.1 Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1(1))


Note: This TSS Assurance Activity has been modified by a VPN Client TRRT decision.

NIAP’s decision on 7/14/2014 stated the following: “It is acceptable to replace the assurance activity in the VPN

Client PP for FCS_CKM.1 with that in the NDPP Errata #2. The ST/AAR should note that this was done.”

The evaluator shall ensure that the TSS contains a description of how the TSF complies with 800-56A and/or 800-

56B, depending on the selections made. This description shall indicate the sections in 800-56A and/or 800-56B that

are implemented by the TSF, and the evaluator shall ensure that key establishment is among those sections that the

TSF claims to implement.

of 90

The ST indicates that the TOE generates asymmetric cryptographic keys for elliptic curve-based key establishment

schemes in accordance with Sections 5 and 6 of SP 800-56A and for RSA-based key establishment schemes in

accordance with Sections 5 through 8 of SP 800-56B.


The evaluator shall check that the operational guidance describes how the key generation functionality is invoked,

and describes the inputs and outputs associated with the process for each signature scheme supported. The evaluator

shall also check that guidance is provided regarding the format and location of the output of the key generation

process.

The steps in Section 2.7.4 of the CCECG describe how to generate a CA key pair on the TOE and to generate a

client key for mutual authentication. Section 2.8.2 indicates that when configuring and selecting IKE and IPsec

cryptographic profiles, that the key strength of the encryption algorithm specified in the IPsec profile is not to be

greater than the key strength of the encryption algorithm specified in the IKE profile. For example, if the configured

IKE profile specifies aes-128-cbc, then the configured IPsec profile must not specify aes-256-cbc or aes-256-gcm.

The “VPNs” section of [ADMIN] (sub-section “Set Up Site-to-Site VPN”, topic “Define Cryptographic Profiles”)

provides information on configuring IKE and IPsec cryptographic profiles for completing IKE Phase 1 and Phase 2

negotiations, respectively. In order to conform to the requirements of the PPs, the following configuration

restrictions must be followed:

When configuring an IKE cryptographic profile:

o Only the following Diffie-Hellman (DH) groups are to be used: group14; group19; group20. Do

not specify group1, group2, or group5.

o Only the following authentication algorithms are to be used: sha1; sha256; sha384; sha512. Do

not specify md5.

o Only the following encryption algorithms are to be used: aes-128-cbc; aes-256-cbc. Do not

specify aes-192-cbc or 3des.

When configuring an IPsec cryptographic profile:

o Select ESP (Encapsulating Security Payload) as the IPsec Protocol. Do not use AH

(Authentication Header).

o Only the following encryption algorithms are to be used: aes-128-cbc; aes-256-cbc; aes-128-gcm;

aes-256-gcm. Do not specify aes-192-cbc, aes-128-ccm or 3des.


not specify md5.



Note also, when configuring and selecting IKE and IPsec cryptographic profiles, that the key strength of the

encryption algorithm specified in the IPsec profile is not to be greater than the key strength of the encryption

algorithm specified in the IKE profile. For example, if the configured IKE profile specifies aes-128-cbc, then the

configured IPsec profile must not specify aes-256-cbc or aes-256-gcm.


The evaluator shall use the key pair generation portions of "The FIPS 186-3 Digital Signature Algorithm Validation

System (DSA2VS)", "The FIPS 186-3 Elliptic Curve Digital Signature Algorithm Validation System

(ECDSA2VS)", and "The RSA Validation System (RSA2VS)" as a guide in testing the requirement above,

depending on the selection performed by the ST author. This will require that the evaluator have a trusted reference

implementation of the algorithms that can produce test vectors that are verifiable during the test.

In Section 6.2 (Cryptographic Support) of [ST], Table 4 (Cryptographic Functions) identifies the CAVP cert

numbers verifying validation for FFC key pair generation, ECC key pair generation and RSA key generation:

of 90

Asymmetric key generation

FFC key pair generation(key size

2048 bits)

NIST Special Publication 800-56A Appliances:

Component #564

VMs:

Component #568

ECC key pair generation(NIST

curves P-256, P-384)


Component #564, #567

VMs:


RSA key generation (key size 2048

bits)’, with reference to ‘FIPS 186-

4’

NIST Special Publication 800-56B Appliances:

RSA #1782

VMs:

RSA #1797

2.2.2 Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1(2))

2.2.2.1 TSS Assurance Activity

The evaluator shall check to ensure that the TSS describes how the key-pairs are generated. In order to show that the

TSF implementation complies with FIPS PUB 186-3, the evaluator shall ensure that the TSS contains the following

information:

• The TSS shall list all sections of Appendix B to which the TOE complies.

• For each applicable section listed in the TSS, for all statements that are not "shall" (that is, "shall not",

"should", and "should not"), if the TOE implements such options it shall be described in the TSS. If the

included functionality is indicated as "shall not" or "should not" in the standard, the TSS shall provide a

rationale for why this will not adversely affect the security policy implemented by the TOE;

• For each applicable section of Appendix B, any omission of functionality related to "shall" or “should”

statements shall be described;

Any TOE-specific extensions, processing that is not included in the Appendices, or alternative implementations

allowed by the Appendices that may impact the security requirements the TOE is to enforce shall be described.

FIPS 186-3 has, at least for the purposes of this requirement, been superseded by FIPS 186-4. Therefore, this TSS

assurance activity is N/A, because the implementation’s compliance to FIPS 186-4 is demonstrated by its CAVP

certification, which covers key generation.

2.2.2.2 Guidance Assurance Activity

The evaluator shall check that the operational guidance describes how the key generation functionality is invoked,

and describes the inputs and outputs associated with the process for each signature scheme supported. The evaluator

shall also check that guidance is provided regarding the format and location of the output of the key generation

process.entation of the algorithms that can produce test vectors that are verifiable during the test.








of 90

negotiations, respectively. In order to conform to the requirements of the PPs listed in Section 1.1 of the CCECG,

the following configuration restrictions must be followed:














not specify md5.









not specify md5.



Note also, when configuring and selecting IKE and IPsec cryptographic profiles, that the key strength of the

encryption algorithm specified in the IPsec profile is not to be greater than the key strength of the encryption

algorithm specified in the IKE profile. For example, if the configured IKE profile specifies aes-128-cbc, then the

configured IPsec profile must not specify aes-256-cbc or aes-256-gcm.

2.2.2.3 Test Activity

The evaluator shall use the key pair generation portions of "The FIPS 186-3 Elliptic Curve Digital Signature

Algorithm Validation System (ECDSA2VS)" and "The RSA Validation System (RSA2VS)" as a guide in testing the

requirement above, depending on the selection performed by the ST author. This will require that the evaluator have

a trusted reference implementation of the algorithms that can produce test vectors that are verifiable during the test.


numbers verifying validation for FFC key pair generation, ECC key pair generation and RSA key generation as

specified in the SFR:

Asymmetric key generation

FFC key pair generation(key size

2048 bits)


Component #564

VMs:

Component #568

of 90

ECC key pair generation(NIST

curves P-256, P-384)



VMs:


RSA key generation (key size 2048

bits)’, with reference to ‘FIPS 186-

4’

NIST Special Publication 800-56B Appliances:

RSA #1782

VMs:

RSA #1797

2.2.3 Cryptographic Key Zeroization (FCS_CKM_EXT.4)


The evaluator shall check to ensure the TSS describes each of the secret keys (keys used for symmetric encryption),

private keys, and CSPs used to generate key; when they are zeroized (for example, immediately after use, on system

shutdown, etc.); and the type of zeroization procedure that is performed (overwrite with zeros, overwrite three times

with random pattern, etc.). If different types of memory are used to store the materials to be protected, the evaluator

shall check to ensure that the TSS describes the zeroization procedure in terms of the memory in which the data are

stored (for example, “secret keys stored on flash are zeroized by overwriting once with zeros, while secret keys

stored on the internal hard drive are zeroized by overwriting three times with a random pattern that is changed

before each write”).

Section 6.2 of the ST states that the TOE 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 for the

purposes of transferring the key/critical security parameters (CSPs) to another location are zeroized immediately

following the transfer. Zeroization is done by overwriting the storage location with a random pattern, followed by a

read-verify. Note that plaintext cryptographic keys and CSPs are only ever stored in volatile memory. For non-

volatile memories other than EEPROM and Flash, the zeroization is executed by overwriting three or more times

using a different alternating data pattern each time. 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 a read-verify.


None defined.


None defined.

2.2.4 Cryptographic Operation (for data encryption/decryption) (FCS_COP.1(1))


None defined.


None defined.

of 90


The evaluator shall use tests appropriate to the modes selected in the above requirement from "The Advanced

Encryption Standard Algorithm Validation Suite (AESAVS)", "The XTS-AES Validation System (XTSVS)", The

CMAC Validation System (CMACVS)", "The Counter with Cipher Block Chaining-Message Authentication Code

(CCM) Validation System (CCMVS)", and "The Galois/Counter Mode (GCM) and GMAC Validation System

(GCMVS)" (these documents are available from http://csrc.nist.gov/groups/STM/cavp/index.html) as a guide in

testing the requirement above. This will require that the evaluator have a reference implementation of the algorithms

known to be good that can produce test vectors that are verifiable during the test.


numbers verifying validation of the Encryption/Decryption using AES CBC and GCM as specified in the SFR.

Encryption/Decryption

AES CBC, GCM (128, 256 bits) FIPS PUB 197

NIST SP 800-38A

NIST SP 800-38D

Appliances:

AES #3475

VMs:

AES #3501

2.2.5 Cryptographic Operation (for cryptographic signature) (FCS_COP.1(2))


None defined.


None defined.


The evaluator shall use the signature generation and signature verification portions of "The Digital Signature

Algorithm Validation System” (DSA2VS), "The Elliptic Curve Digital Signature Algorithm Validation System”

(ECDSA2VS), and "The RSA Validation System” (RSAVS 186-2 or RSA2VS (for 186-3)) as a guide in testing the

requirement above. The Validation System used shall comply with the conformance standard identified in the ST

(i.e., FIPS PUB 186-2 or FIPS PUB 186-3). This will require that the evaluator have a reference implementation of

the algorithms known to be good that can produce test vectors that are verifiable during the test.


numbers verifying validation of the signature generation and verification using RSA and ECDSA as specified in the

SFR.

Cryptographic signature services

RSA Digital Signature Algorithm

(rDSA) (modulus 2048)

FIPS PUB 186-3

Appliances:

RSA #1782

VMs:

RSA #1797

ECDSA (NIST curves P-256 and P-

384)

FIPS PUB 186-3

Appliances:

ECDSA #713

Component #566

VMs:

of 90

ECDSA #714

Component #571

2.2.6 Cryptographic Operation (for cryptographic hashing) (FCS_COP.1(3))


None defined.


None defined.


The evaluator shall use "The Secure Hash Algorithm Validation System (SHAVS)" as a guide in testing the

requirement above. This will require that the evaluator have a reference implementation of the algorithms known to

be good that can produce test vectors that are verifiable during the test


numbers verifying validation of the secure hash algorithms as specified in the SFRs.

Cryptographic hashing

SHA-1, SHA-224, SHA-256, SHA-

384 and SHA-512 (digest sizes 160,

224, 256, 384 and 512 bits)

FIPS Pub 180-3 Appliances:

SHS #2870

VMs:

SHS #2888

2.2.7 Cryptographic Operation (for keyed-hash message authentication) (FCS_COP.1(4))


None defined.


None defined.


The evaluator shall use "The Keyed-Hash Message Authentication Code (HMAC) Validation System (HMACVS)"

as a guide in testing the requirement above. This will require that the evaluator have a reference implementation of

the algorithms known to be good that can produce test vectors that are verifiable during the test.


numbers verifying validation of the keyed hash message algorithms as specified in the SFRs.

Keyed-hash message authentication

of 90

Keyed-hash message authentication

HMAC-SHA-1 (block size 512 bits,

key size 160 bits and digest size 160

bits)

HMAC-SHA-224 (block size 512

bits, key size 224 bits and digest

size 224 bits)


bits, key Size 256 bits and digest

size 256 bits)



size 384 bits)



size 512 bits)

FIPS Pub 198-1

FIPS Pub 180-3

Appliances:

HMAC #2220

VMs:

HMAC #2235

2.2.8 Explicit: IPSEC (FCS_IPSEC_EXT.1)

2.2.8.1 FCS_IPSEC_EXT.1.1


Nothing is done in addition to determining that the TOE’s implementation is conformant to RFC 4301 as described

above.


The evaluator shall examine the operational guidance to verify it instructs the Administrator how to construct entries

into the SPD that specify a rule for DISCARD, BYPASS and PROTECT.

Section 2.8.3 of the CCECG references the “Policy” section of [ADMIN] (sub-section “Policy-Based Forwarding”)

which provides information on configuring rules consistent with the definition of an IPsec Security Policy Database

(SPD) as specified in RFC 4301 (i.e., rules that contain operations that DISCARD, BYPASS, and PROTECT

network packets). Section 2.8.3 of the CCECG provides the steps to navigate and configure the TOE to set up

connections between peer VPN devices and configure Policy-Based Forwarding (PBF) and security policy rules for

DISCARD, BYPASS and PROTECT processing.


The evaluator uses the operational guidance to configure the TOE and platform to carry out the following tests:

Test 1: The evaluator shall configure the SPD such that there is a rule for DISCARD, BYPASS, PROTECT. The

selectors used in the construction of the rule shall be different such that the evaluator can send in three network

packets with the appropriate fields in the packet header that each packet will match one of the three rules. The

evaluator observes via the audit trail, and packet captures that the TOE exhibited the expected behavior: appropriate

packet was dropped, allowed through without modification, was encrypted by the IPsec implementation.

Test 2: The evaluator shall devise two equal SPD entries with alternate operations – BYPASS and PROTECT. The

entries should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first entry

is enforced in both cases by generating applicable packets and using packet capture and logs for confirmation.

Test 3: The evaluator shall repeat the procedure above, except that the two entries should be devised where one is a

subset of the other (e.g., a specific address vs. a network segment). Again, the evaluator should test both orders to

ensure that the first is enforced regardless of the specificity of the rule.

of 90


configure the SPD and verified the order of the entries is properly executed.



7.0.1-h4 for details of testing the TOE’s SPD.



The evaluator checks the TSS to ensure it states that the TOE can operate in tunnel mode and/or transport mode (as

selected).

Section 6.2 of the ST state that the TOE supports tunnel mode and uses the SHA-based HMAC algorithms as

specified in FCS_COP.1(4) Cryptographic Operations (for keyed-hash message authentication).


The evaluator shall confirm that the operational guidance instructs the Administrator how the TOE is configured in

each mode selected.





connections between peer VPN devices and configure Policy-Based Forwarding (PBF) including configuring tunnel

mode.


The evaluator shall perform the following test(s) based on the selections chosen:

Test 1 (conditional): If tunnel mode is selected, the evaluator uses the operational guidance to configure the TOE in

tunnel mode, and a TOE peer in tunnel mode. The evaluator configures the two peer TOEs to use any of the

allowable cryptographic algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated. The

evaluator shall then initiate a session between the peers. The evaluator observes in the audit trail and the captured

packets that a successful connection was established using the tunnel mode.

Test 2 (conditional): If transport mode is selected, the evaluator uses the operational guidance to configure the TOE

to operate in transport mode when it receives packets from the VPN client. The evaluator configures the TOE and

VPN client to use any of the allowed cryptographic algorithms, authentication methods, etc. to ensure an allowable

SA can be negotiated. The evaluator then initiates a connection with the TOE using the VPN client. The evaluator

observes in the audit trail and the captured packets that a successful connection was established using the transport

mode.

The evaluation team performed the testing specified in the assurance activity and confirmed the TOE’s ability to be

configured and use tunnel mode.



7.0.1-h4 for details of testing the TOE’s SPD in tunnel mode.

of 90



The evaluator shall examine the TSS to verify that the TSS provides a description of how a packet is processed

against the SPD and that if no “rules” are found to match, that a final rule exists, either implicitly or explicitly, that

causes the network packet to be discarded.

Section 6.2 indicates that the TOE provides mechanisms to implement an IPsec Security Policy Database (SPD) and

to process packets to satisfy the behavior of DISCARD, BYPASS and PROTECT packet processing as described in

RFC 4301. This is achieved through the administrator configuring appropriately specified access control lists

(ACLs). The ACLs consist of policy rules and profiles. The TOE compares packets in turn against each rule in the

Security ACL to determine if the packet matches the rule. Packets can be matched based on protocol (e.g., TCP,

UDP), source IP address and destination IP address. The first rule that matches the traffic is applied. If a policy rule

matching the traffic attributes is not found, or if it is found and it specifies a deny action, then the packet is dropped

(or DISCARDed) and the session is deleted. If the application flow is allowed and no further security profiles are

applied then it is forwarded (it is allowed to BYPASS the tunnel). If the application is allowed and there are

additional security profiles set, it will be sent to the stream signature processor. The traffic matching the IPSec

crypto Security profile would then flow through the IPSec tunnel and be classified as “PROTECTED”. If there is

no SA that the IPsec can use to protect this traffic to the peer, IPsec uses IKE to negotiate with the remote peer to set

up the necessary IPsec SAs on behalf of the data flow. The negotiation uses information specified in the IKE

Network Profiles. If the TOE receives a packet that does not match any rules in the SPD the TOE discards the

packet. By default, the TOE is configured to allow all intrazone (within the zone) traffic and deny all interzone

(between zones) traffic. Typically interzone traffic is considered to be trusted however, both intrazone and interzone

traffic can be configured to deny all traffic if there is no rule match by clicking on the security policy and clicking

on the Override button on the bottom on the Policy ->Security screen. In the evaluated configuration, the default

deny all rule for interzone traffic should not be modified.


The evaluator checks that the operational guidance provides instructions on how to construct the SPD and uses the

guidance to configure the TOE for the following tests.





connections between peer VPN devices and configure Policy-Based Forwarding (PBF) and security policy rules for

DISCARD, BYPASS and PROTECT processing.


The evaluator uses the guidance to configure the TOE for the following tests.

Test 1: The evaluator shall configure the TOE’s SPD, such that it has entries that contain operations that DISCARD,

BYPASS, and PROTECT network packets. The evaluator also configures the TOE so that all auditable events with

respect to FCS_IPSEC_EXT.1 are enabled. The evaluator may use the SPD that was created for verification of

FCS_IPSEC_EXT.1.1. The evaluator shall construct a network packet that matches a BYPASS entry, and send that

packet to the TOE. The evaluator should observe that the network packet is passed by the TOE to the proper

destined interface with no modification. The evaluator shall then modify a field in the packet header; such that it no

longer matches the evaluator created entries (there may be a “TOE created” final entry that discards packets that do

not match any previous entries). The evaluator sends the packet to the TOE, and observes that the packet was not

permitted to flow to any of the TOE’s interfaces. The evaluator shall verify that an audit record is generated that

specifies that the packet was discarded as expected.


process the SPD entries that contain operations that DISCARD, BYPASS, and PROTECT network packets. The

evaluator modified a packet header such that it did not match any previous entries and verified that the packet was

not permitted to flow to any of the TOE’s interfaces.

of 90



7.0.1-h4 for details of testing the TOE’s SPD.



The evaluator shall examine the TSS to verify that the algorithms AES-GCM-128 and AES-GCM-256 are

implemented. If the ST author has selected either AES-CBC-128 or AES-CBC-256 in the requirement, then the

evaluator verifies the TSS describes these as well. In addition, the evaluator ensures that the SHA-based HMAC

algorithm conforms to the algorithms specified in FCS_COP.1(4) Cryptographic Operations (for keyed-hash

message authentication).

Section 6.2 of the ST indicates that the TOE includes an implementation of IPsec in accordance with RFC 4301. The

primary cryptographic algorithms used by the TOE include AES-CBC-128, AES-CBC-256 (both specified by RFC

3602); and AES-GCM-128, AES-GCM-256 as specified in RFC 4106 along with IKEv1 as defined in RFCs 2407,

2408, 2409, RFC 4109; and IKEv2 as defined in RFCs 5996 (with mandatory support for NAT traversal as specified

in section 2.23), and 4868 for hash functions. Note that the TOE supports both main and aggressive modes, though

aggressive mode should be disabled in the evaluated configuration. The modes can be configured using the GUI to

auto, main, or aggressive; the default mode is “auto”. The CC guidance document instructs the administrator to set it

“main”. The TOE supports tunnel mode and uses the SHA-based HMAC algorithms as specified in FCS_COP.1(4)

Cryptographic Operations (for keyed-hash message authentication).


The evaluator checks the operational guidance to ensure it provides instructions on how to configure the TOE to use

the AES-GCM-128, and AES-GCM-256 algorithms, and if either AES-CBC-128 or AES-CBC-256 have been

selected the guidance instructs how to use these as well.

As referenced in section 2.8.2, the “VPNs” section of [ADMIN] (sub-section “Set Up Site-to-Site VPN”, topic

“Define Cryptographic Profiles”) provides information on configuring IKE and IPsec cryptographic profiles for

completing IKE Phase 1 and Phase 2 negotiations, respectively. In order to conform to the requirements of the PPs,

it also specifies the restrictions on the configuration.





not specify md5.









not specify md5.



of 90


The evaluator shall also perform the following tests:

Test 1: The evaluator shall configure the TOE as indicated in the operational guidance configuring the TOE to using

each of the AES-GCM-128, and AES-GCM-256 algorithms, and attempt to establish a connection using ESP in

confidentiality and integrity mode. If the ST Author has selected either AES-CBC-128 or AES-CBC-256, the TOE

is configured to use those algorithms and the evaluator attempts to establish a connection using ESP in

confidentiality and integrity mode for those algorithms selected.

The evaluator configured the TOE to use the AES-GCM-128, AES-GCM-256 as specified in RFC 4106 and the

AES-CBC-128, AES-CBC-256 algorithms.



7.0.1-h4 for details of testing the TOE’s implementation of IPSec using ESP.



The evaluator shall examine the TSS to verify that IKEv1 and/or IKEv2 are implemented.

Section 6.2 of the ST indicates that the TOE includes an implementation of IPsec in accordance with RFC 4301. The

primary cryptographic algorithms used by the TOE include AES-CBC-128, AES-CBC-256 (both specified by RFC

3602); and AES-GCM-128, AES-GCM-256 as specified in RFC 4106 along with IKEv1 as defined in RFCs 2407,

2408, 2409, RFC 4109; and IKEv2 as defined in RFCs 5996 (with mandatory support for NAT traversal as specified

in section 2.23), and 4868 for hash functions.


The evaluator checks the operational guidance to ensure it instructs the administrator how to configure the TOE to

use IKEv1 and/or IKEv2 (as selected), and uses the guidance to configure the TOE to perform NAT traversal for the

following test.

Section 2.8.2 of the CCECG refers to the “VPNs” section of [ADMIN] (sub-section “Set Up Site-to-Site VPN”,

topic “Set Up an IKE Gateway”) which provides guidance on configuring the TOE as a VPN gateway. This includes

the version of IKE the VPN gateway will use. You can specify IKEv1 only mode, IKEv2 only mode, or IKEv2

preferred mode. The gateway begins its negotiation with its peer in the mode specified here. If you select IKEv2

preferred mode, the two peers will use IKEv2 if the remote peer supports it; otherwise they will use IKEv1. Note,

if you specify IKEv1 mode only or IKEv2 preferred mode, you must specify main for the Exchange Mode (done

on the Advanced Options > IKEv1 tab).


Test 1 (conditional): The evaluator shall configure the TOE/platform so that it will perform NAT traversal

processing as described in the TSS and RFC 5996, section 2.23. The evaluator shall initiate an IPsec connection and

determine that the NAT is successfully traversed.

The evaluator configured the TOE to so that it will perform NAT traversal processing as described in the TSS and

RFC 5996 and confirmed that the NAT is successfully traversed when an IPsec connection is initiated.



7.0.1-h4 for details of testing the TOE’s implementation of IPSec with NAT traversal.

of 90



The evaluator shall ensure the TSS identifies the algorithms used for encrypting the IKEv1 and/or IKEv2 payload,

and that the algorithms AES-CBC-128, AES-CBC-256 are specified, and if others are chosen in the selection of the

requirement, those are included in the TSS discussion.

Section 6.2 of the ST states that the TOE provides AES-CBC-128, AES-CBC-256, AES-GCM-128 and AES-GCM-

256 for encrypting IKEv1 and IKEv2 payloads. The administrator is instructed to ensure that the size of key used for

ESP must be less than or equal to the key size used to protect the IKE payload.


The evaluator ensures that the operational guidance describes how the TOE can be configured to use the mandated

algorithms, as well as any additional algorithms selected in the requirement. The guidance is then used to configure

the TOE to perform the following test.


topic “Set Up an IKE Gateway”) which provides guidance on configuring the TOE as a VPN gateway. This includes

the version of IKE the VPN gateway will use. You can specify IKEv1 only mode, IKEv2 only mode, or IKEv2

preferred mode. The gateway begins its negotiation with its peer in the mode specified here. If you select IKEv2

preferred mode, the two peers will use IKEv2 if the remote peer supports it; otherwise they will use IKEv1. Note,

if you specify IKEv1 mode only or IKEv2 preferred mode, you must specify main for the Exchange Mode (done

on the Advanced Options > IKEv1 tab).









not specify md5.









not specify md5.




Test 1: The evaluator shall configure the TOE to use AES-CBC-128 to encrypt the IKEv1 and/or IKEv2 payload

and establish a connection with a peer device, which is configured to only accept the payload encrypted using AES-

CBC-128. The evaluator will consult the audit trail to confirm the algorithm was that used in the negotiation.

of 90

The evaluator configured the TOE to use AES CBC 128 to encrypt the IKEv1 and IKEv2 payload and establish a

connection with a peer device.



7.0.1-h4 for details of testing the TOE’s implementation of IPSec.



The evaluator shall examine the TSS to ensure that, in the description of the IPsec protocol supported by the TOE, it

states that aggressive mode is not used for IKEv1 Phase 1 exchanges, and that only main mode is used. It may be

that this is a configurable option.

Section 6.2 of the ST states that the TOE supports both main and aggressive modes, though aggressive mode should

be disabled in the evaluated configuration. The modes can be configured using the GUI to auto, main, or aggressive;

the default mode is “auto”. The CC guidance document instructs the administrator to set it “main”.


If the mode requires configuration of the TOE prior to its operation, the evaluator shall check the operational

guidance to ensure that instructions for this configuration are contained within that guidance.

Section 2.8.2 of the CCECG states that if you specify IKEv1 mode only or IKEv2 preferred mode, you must specify

main for the Exchange Mode (done on the Advanced Options > IKEv1 tab).


Test 1 (conditional): The evaluator shall configure the TOE as indicated in the operational guidance, and attempt to

establish a connection using an IKEv1 Phase 1 connection in aggressive mode. This attempt should fail. The

evaluator should then show that main mode exchanges are supported. This test is not applicable if IKEv1 is not

selected above in the FCS_IPSEC_EXT.1.5 protocol selection.

The evaluator attempted to configure the TOE to use IKEv1 Phase 1 connection in aggressive mode. The attempt

failed as expected.



7.0.1-h4 for details of testing the TOE’s implementation of IPSec using main mode exchanges.

2.2.8.8 Explicit: IPSEC (FCS_IPSEC_EXT.1.8)


How the lifetimes are established and enforced is described in the RFCs and the evaluator examines the TSS as

stated at the beginning of this section.

Section 6.2 state that the IKEv2 SA lifetime and volume limits can be configured by an authorized administrator and

can be limited to 24 hours for phase 1 and 8 hours for phase 2 SAs. IKEv1 SA lifetime is configurable as well and

the range of time value is same as for IKEv2. Both IKEv1 and IKEv2 SA lifetimes can be established based on

number of packets or bytes.

of 90


The evaluator verifies that the values for SA lifetimes can be configured and that the instructions for doing so are

located in the operational guidance. The evaluator ensures that the Administrator is able to configurable Phase 1 SAs

values for 24 hours and 8 hours for Phase 2 SAs. Currently there are no values mandated for the number of packets,

the evaluator just ensures that this can be configured. The TOE may limit the lifetime on the number of bytes that

have been transmitted and this would be acceptable.


topic “Define Cryptographic Profiles”) which provides information on configuring Phase 1 and Phase 2 SA

lifetimes. The Phase 1 lifetime is configured in the IKE profile and can be specified in seconds, minutes, hours, or

days. The supported range is 3 minutes to 365 days, with a default of 8 hours. The Phase 2 lifetime is configured in

the IPsec profile and can be specified in terms both of time (in seconds, minutes, hours, or days—the supported

range is 3 minutes to 365 days) and volume of data (denoted as Lifesize).


When testing this, the evaluator needs to ensure that both sides are configured appropriately. From the RFC “A

difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA

is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. If the two ends

have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the

rekeying. If the two ends have the same lifetime policies, it is possible that both will initiate a rekeying at the same

time (which will result in redundant SAs). To reduce the probability of this happening, the timing of rekeying

requests SHOULD be jittered.”

Each of the following tests shall be performed for each version of IKE selected in the FCS_IPSEC_EXT.1.5

protocol selection:

Test 1: The evaluator shall configure a maximum lifetime in terms of the # of packets (or bytes) allowed following

the operational guidance. The evaluator shall establish an SA and determine that once the allowed # of packets (or

bytes) through this SA is exceeded, the connection is closed.

Test 2: The evaluator shall construct a test where a Phase 1 SA is established and attempted to be maintained for

more than 24 hours before it is renegotiated. The evaluator shall observe that this SA is closed or renegotiated in 24

hours or less. If such an action requires that the TOE be configured in a specific way, the evaluator shall implement

tests demonstrating that the configuration capability of the TOE works as documented in the operational guidance.

Test 3: The evaluator shall perform a test similar to Test 1 for Phase 2 SAs, except that the lifetime will be 8 hours

instead of 24.

The evaluator configured the TOE Phase 1 SA lifetime to 24 hours. The evaluator also conducted a similar test to

verify the Phase 2 SAs to be 8 hours. This was performed for both IKEv1 and IKEv2.



7.0.1-h4 for details of testing the TOE’s implementation of SA lifetimes.

2.2.8.9 FCS_IPSEC_EXT.1.9, FCS_IPSEC_EXT.1.10


The evaluator shall check to ensure that, for each DH group supported by the TSF, the TSS describes the process for

generating "x" (as defined in FCS_IPSEC_EXT.1.9) and each nonce. The evaluator shall verify that the TSS

indicates that the random number generated that meets the requirements in this PP is used, and that the length of "x"

and the nonces meet the stipulations in the requirement.

Section 6.2 of the ST indicates that the IKEv1 and IKEv2 protocols implemented by the TOE include DH Group 14

(2048-bit MODP), DH Groups 19 (256-bit Random ECP), and 20 (384-bit Random ECP), using RSA (aka rDSA)

and ECDSA peer authentication. The keys are generated using the AES-CTR Deterministic Random Bit Generator

of 90

(DRBG), as specified in SP 800-90, and the following corresponding key sizes (in bits) are used: 224 (for DH Group

14), 256 (for DH Group 19), 384 (for DH Group 20) bits. The nonces used in IKE exchanges are generated such

that the probability that a specific nonce value will be repeated during the life of a specific IPsec SA is less than 1 in

2^112 bits (for DH Group 14), 2^128 bits (for DH Group 19), and 2^192 bits (for DH Group 20)].


None identified.


None identified.



The evaluator shall check to ensure that the DH groups specified in the requirement are listed as being supported in

the TSS. If there is more than one DH group supported, the evaluator checks to ensure the TSS describes how a

particular DH group is specified/negotiated with a peer.



and ECDSA peer authentication. In the IKEv1 phase 1 and phase 2 exchanges, the TOE and peer will agree on the

best DH group both can support. When the TOE initiates IKE negotiation, the DH group is sent in order according

to the peer’s configuration. When the TOE receives an IKE proposal, it will select the first match and the negotiation

will fail if there is no match. During IKEv1 phase 1 authentication is based on a verifiable signature as described in

RFC2409. The keys are generated using the AES-CTR Deterministic Random Bit Generator (DRBG), as specified

in SP 800-90, and the following corresponding key sizes (in bits) are used: 224 (for DH Group 14), 256 (for DH

Group 19), 384 (for DH Group 20) bits. The nonces used in IKE exchanges are generated such that the probability

that a specific nonce value will be repeated during the life of a specific IPsec SA is less than 1 in 2^112 bits (for DH

Group 14), 2^128 bits (for DH Group 19), and 2^192 bits (for DH Group 20)].


None identified.


The evaluator shall also perform the following test:

Test 1: For each supported DH group, the evaluator shall test to ensure that all IKE protocols can be successfully

completed using that particular DH group.

The evaluator tested that for each supported DH group, all IKE protocols were successfully completed.



7.0.1-h4 for details of testing the TOE’s implementation of DH groups.

2.2.8.11 FCS_IPsec_EXT.1.12

2.2.8.11.1 TSS Assurance Activity

The evaluator ensures that the TSS identifies RSA and/or ECDSA as being used to perform peer authentication. The

description must be consistent with the algorithms as specified in FCS_COP.1(2) Cryptographic Operations (for

cryptographic signature).

of 90



and ECDSA peer authentication.

2.2.8.11.2 Guidance Assurance Activity

The evaluator ensures the operational guidance describes how to set up the TOE to use the cryptographic algorithms

RSA and/or ECDSA.

In order to construct the environment and configure the TOE for the following tests, the evaluator will ensure that

the operational guidance also describes how to configure the TOE to connect to a trusted CA, and ensure a valid

certificate for that CA is loaded into the TOE and marked “trusted”.

Section 2.7.4 of the CCECG provides the steps via the GUI interface for configuring the TOE to use the RSA and

ECDSA algorithms for peer authentication. It also provides the steps to configure the TOE to connect to a trusted

CA.

2.2.8.11.3 Test Activity

For efficiency sake, the testing that is performed here has been combined with aspects of the testing for

FIA_X509_EXT.1 Extended: X.509 Certificates, specifically FIA_X509_EXT.1.4, and FIA_X509_EXT.1.5.

The following five tests shall be repeated for each peer authentication protocol selected in the

FCS_IPSEC_EXT.1.12 selection above:

Test 1: The evaluator shall have the TOE generate a public-private key pair, and submit a CSR (Certificate Signing

Request) to a CA (trusted by both the TOE and the peer VPN used to establish a connection) for its signature. The

values for the DN (Common Name, Organization, Organizational Unit, and Country) will also be passed in the

request.

Test 2: The evaluator shall use a certificate signed using the RSA or ECDSA algorithm to authenticate the remote

peer during the IKE exchange. This test ensures the remote peer has the certificate for the trusted CA that signed the

TOE’s certificate and it will do a bit-wise comparison on the DN. This bit-wise comparison of the DN ensures that

not only does the peer have a certificate signed by the trusted CA, but the certificate is from the DN that is expected.

The evaluator will configure the TOE to associate a certificate (e.g., a certificate map in some implementations) with

a VPN connection. This is what the DN is checked against.

Test 3: The evaluator shall test that the TOE can properly handle revoked certificates – conditional on whether CRL

or OCSP is selected; if both are selected, and then a test is performed for each method. For this draft of the EP, the

evaluator has to only test one up in the trust chain (future drafts may require to ensure the validation is done up the

entire chain). The evaluator shall ensure that a valid certificate is used, and that the SA is established. The evaluator

then attempts the test with a certificate that will be revoked (for each method chosen in the selection) to ensure when

the certificate is no longer valid that the TOE will not establish an SA.

Test 4: The evaluator shall construct a certificate path, such that the certificate of the CA issuing the TOE’s

certificate does not contain the basicConstraints extension. The validation of the certificate path fails.


certificate has the cA flag in the basicConstraints extension not set. The validation of the certificate path fails.


certificate has the cA flag in the basicConstraints extension set to TRUE. The validation of the certificate path

succeeds.

Test 7: The evaluator shall test that given a signed certificate from a trusted CA, that when the DN does not match –

any of the four fields can be modified such that they do not match the expected value, that an SA does not get

established.

of 90

Test 8: The evaluator shall ensure that the TOE is configurable to either establish an SA, or not establish an SA if a

connection to the certificate validation entity cannot be reached. For each method selected for certificate validation,

the evaluator attempts to validate the certificate – for the purposes of this test, it does not matter if the certificate is

revoked or not. For the “mode” where an SA is allowed to be established, the connection is made. Where the SA is

not to be established, the connection is refused.

The evaluator tested that peer authentication using each algorithm can be successfully achieved; that the TOE can

properly handle revoked certificates and that validation of the certificate path will fail if the CA issuing the TOE’s

certificate does not contain the basicConstraints extension or if the certificate has the cA flag in the basicConstraints

extension not set.



7.0.1-h4 for details of testing of the RSA and ECDSA signature algorithms used for peer authentication in the

TOE’s IPsec implementation.

2.2.8.12 FCS_IPsec_EXT.1.13

2.2.8.12.1 TSS Assurance Activity

The evaluator shall check that the TSS describes the potential strengths (in terms of the number of bits in the

symmetric key) of the algorithms that are allowed for the IKE and ESP exchanges. The TSS shall also describe the

checks that are done when negotiating IKEv1 Phase 2 and/or IKEv2 CHILD_SA suites to ensure that the strength

(in terms of the number of bits of key in the symmetric algorithm) of the negotiated algorithm is less than or equal to

that of the IKE SA this is protecting the negotiation.

Section 6.2 states that the TOE includes an implementation of IPsec in accordance with RFC 4301. The primary

cryptographic algorithms used by the TOE include AES-CBC-128, AES-CBC-256 (both specified by RFC 3602);

and AES-GCM-128, AES-GCM-256 as specified in RFC 4106 along with IKEv1 as defined in RFCs 2407, 2408,

2409, RFC 4109; and IKEv2 as defined in RFCs 5996 (with mandatory support for NAT traversal as specified in

section 2.23), and 4868 for hash functions. The TOE provides AES-CBC-128, AES-CBC-256, AES-GCM-128 and

AES-GCM-256 for encrypting IKEv1 and IKEv2 payloads. The administrator is instructed to ensure that the size of

key used for ESP must be less than or equal to the key size used to protect the IKE payload. (Note that per TD0014,

it is acceptable for this functionality to be configurable in the evaluated configuration. Clear guidance must be

provided to the administrator to instruct them to ensure that the size of the key configured to use with ESP is less

than or equal to the size of the key configured to protect the IKE payload).

2.2.8.12.2 Guidance Assurance Activity

The evaluator simply follows the guidance to configure the TOE to perform the following tests.

The evaluator followed the guidance in the CCECG in order to perform the following tests.

2.2.8.12.3 Test Activity

Test 1: This test shall be performed for each version of IKE supported by the TOE. The evaluator shall successfully

negotiate an IPsec connection using each of the supported algorithms and hash functions identified in the

requirements.

Test 2: This test shall be performed for each version of IKE supported by the TOE. The evaluator shall attempt to

establish an SA for ESP that selects an encryption algorithm with more strength than that being used for the IKE SA

(i.e., symmetric algorithm with a key size larger than that being used for the IKE SA). Such attempts should fail.


establish an IKE SA using an algorithm that is not one of the supported algorithms and hash functions identified in

the requirements. Such an attempt should fail.

of 90


establish an SA for ESP (assumes the proper parameters where used to establish the IKE SA) that selects an

encryption algorithm that is not identified in FCS_IPSEC_EXT.1.4. Such an attempt should fail.

For IKEv1 and IKEv2, the evaluator tested that the TOE could successfully negotiate an IPsec connection using

each of the supported algorithms and hash functions identified in the requirements. The evaluator tested that an

attempt to establish an SA for ESP that selects an encryption algorithm with more strength than that being used for

the IKE SA (i.e., symmetric algorithm with a key size larger than that being used for the IKE SA) and that an

attempt using an algorithm that is not supported would fail.



7.0.1-h4 for details of testing of the algorithms and hash functions supported by the TOE’s implementation of IPsec.

2.2.9 Extended: Cryptographic Operation (Random Bit Generation) (FCS_RBG_EXT.1)

2.2.9.1 Assurance Activities

Documentation shall be produced—and the evaluator shall perform the activities—in accordance with Annex D,

Entropy Documentation and Assessment.

The vendor produced an Entropy Assessment Report, which was reviewed and approved by the Information

Assurance Directorate (IAD) within the National Security Agency (NSA).

The evaluator shall also perform the following tests, depending on the standard to which the RBG conforms.

Implementations Conforming to FIPS 140-2, Annex C

The reference for the tests contained in this section is The Random Number Generator Validation System (RNGVS)

[RNGVS]. The evaluators shall conduct the following two tests. Note that the "expected values" are produced by a

reference implementation of the algorithm that is known to be correct. Proof of correctness is left to each Scheme.

The evaluators shall perform a Variable Seed Test. The evaluators shall provide a set of 128 (Seed, DT) pairs to the

TSF RBG function, each 128 bits. The evaluators shall also provide a key (of the length appropriate to the AES

algorithm) that is constant for all 128 (Seed, DT) pairs. The DT value is incremented by 1 for each set. The seed

values shall have no repeats within the set. The evaluators ensure that the values returned by the TSF match the

expected values.

The evaluators shall perform a Monte Carlo Test. For this test, they supply an initial Seed and DT value to the TSF

RBG function; each of these is 128 bits. The evaluators shall also provide a key (of the length appropriate to the

AES algorithm) that is constant throughout the test. The evaluators then invoke the TSF RBG 10,000 times, with the

DT value being incremented by 1 on each iteration, and the new seed for the subsequent iteration produced as

specified in NIST-Recommended Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using the 3-

Key Triple DES and AES Algorithms, Section 3. The evaluators ensure that the 10,000th value produced matches

the expected value.

Implementations Conforming to NIST Special Publication 800-90

The evaluator shall perform 15 trials for the RNG implementation. If the RNG is configurable, the evaluator shall

perform 15 trials for each configuration. The evaluator shall also confirm that the operational guidance contains

appropriate instructions for configuring the RNG functionality.

If the RNG has prediction resistance enabled, each trial consists of (1) instantiate drbg, (2) generate the first block of

random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second

block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is

a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The

next two are additional input and entropy input for the first call to generate. The final two are additional input and

entropy input for the second call to generate. These values are randomly generated. “Generate one block of random

bits” means to generate random bits with number of returned bits equal to the Output Block Length (as defined in

NIST SP 800-90).

of 90

If the RNG does not have prediction resistance, each trial consists of (1) instantiate drbg, (2) generate the first block

of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that

the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial.

The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate

operation. The fifth value is additional input to the first call to generate. The sixth and seventh are additional input

and entropy input to the call to reseed. The final value is additional input to the second generate call.

The following paragraphs contain more information on some of the input values to be generated/selected by the

evaluator.

Entropy input: the length of the entropy input value must equal the seed length.

Nonce: If a nonce is supported (CTR_DRBG with no df does not use a nonce), the nonce bit length is one-half the

seed length.

Personalization string: The length of the personalization string must be <= seed length. If the implementation only

supports one personalization string length, then the same length can be used for both values. If more than one string

length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does

not use a personalization string, no value needs to be supplied.

Additional input: the additional input bit lengths have the same defaults and restrictions as the personalization string

lengths.


numbers verifying that the TOE’s DRBG implementation is validated as specified in the SFRs.

Random bit generation

CTR_DRBG (AES) from a

hardware based noise source with

one independent software-based

noise source of 256 bits of non-

determinism

NIST Special Publication 800-90 Appliances:

DRBG #870

VMs:

DRBG #871

Section 2.4 of the CCECG describes how the TOE should be configured into CC Mode which restricts the

cryptographic mechanisms to FIPS-approved algorithms. Beyond this, the RNG functionality is not configurable.

2.2.10 Explicit: HTTPS (FCS_HTTPS_EXT.1)

2.2.10.1 TSS Activity

The evaluator shall check the TSS to ensure that it is clear on how HTTPS uses TLS to establish an administrative

session, focusing on any client authentication required by the TLS protocol vs. security administrator authentication

which may be done at a different level of the processing stack.

Section 6.2 states that the TOE’s HTTPS protocol complies with RFC 2818 and is implemented using TLS 1.0 (RFC

2246), TLS 1.1 (RFC 4346) and TLS 1.2 (RFC 5246) supporting the following ciphersuites:

TLS_RSA_WITH_AES_128_CBC_SHA


TLS_DHE_RSA_WITH_AES_128_CBC_SHA


TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256


of 90

Section 6.4 states that the TOE uses X.509v3 certificates as defined by RFC 5280 to support authentication for

IPsec, and TLS connections.

2.2.10.2 Guidance Activity

None defined.


Testing for this activity is done as part of the TLS testing; this may result in additional testing if the TLS tests are

done at the TLS protocol level.



7.0.1-h4 for details of TLS testing.

2.2.11 Explicit: TLS (FCS_TLS_EXT.1)

2.2.11.1 TSS Activity

The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional

characteristics (e.g., extensions supported, client authentication supported) are specified, and the ciphersuites

supported are specified as well. The evaluator shall check the TSS to ensure that the ciphersuites specified are

identical to those listed for this component.

Section 6.2 states that the TOE’s HTTPS protocol complies with RFC 2818 and is implemented using TLS 1.0 (RFC

2246), TLS 1.1 (RFC 4346) and TLS 1.2 (RFC 5246) supporting the following ciphersuites:







2.2.11.2 Guidance Activity

The evaluator shall also check the operational guidance to ensure that it contains instructions on configuring the

TOE so that TLS conforms to the description in the TSS (for instance, the set of ciphersuites advertised by the TOE

may have to be restricted to meet the requirements)

Section 2.4 of the CCECG describes how to configure the TOE into CC/FIPS mode in order to restrict the allowed

algorithms to FIPS-approved cryptography

Section 2.8.3 of the CCECG states that in its evaluated configuration, the TOE supports the following TLS

ciphersuites:



TLS_RSA_WITH_AES_128_CBC_SHA256





TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.

of 90

The specific ciphersuites are configured based on the asymmetric algorithm specified when generating a certificate

(see “Generate a Certificate on the Device” in [ADMIN]) and by the version of TLS specified in an SSL/TLS

Service Profile (see “Configure an SSL/TLS Service Profile” in [ADMIN]). The possible combinations and the

resultant configured ciphersuites are summarized in the following table.

SSL/TLS Service Profile Setting

Certificate Algorithm/ Negotiated Protocol

TLS 1.0/1.1 only TLS 1.0/1.1/1.2 TLS 1.2 only

RSA/TLS 1.0,

1.1

RSA-AES128-SHA

RSA-AES256-SHA

DHE-RSA-AES128-SHA

DHE-RSA-AES256-SHA

RSA-AES128-SHA

RSA-AES256-SHA

DHE-RSA-AES128-SHA

DHE-RSA-AES256-SHA

N/A

RSA/TLS 1.2

N/A

RSA-AES128-SHA

RSA-AES128-SHA256

RSA-AES128-GCM-SHA256


RSA-AES256-SHA

RSA-AES256-SHA256

DHE-RSA-AES128-SHA

DHE-RSA-AES256-SHA

RSA-AES128-SHA

RSA-AES128-SHA256

RSA-AES256-SHA256



ECDSA/TLS 1.0,

1.1 Not allowed in evaluated configuration

ECDSA/TLS 1.2

N/A

Not allowed in

evaluated

configuration

ECDHE-ECDSA-AES256-GCM-

SHA384

ECDHE-ECDSA-AES128-GCM-

SHA256



Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement.

This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of a HTTPS

session. It is sufficient to observe (on the wire) the successful negotiation of a ciphersuite to satisfy the intent of the

test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the ciphersuite

being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES).

The evaluator established a TLS connection using each of the ciphersuites specified in the SFR as part of the HTTPS

session. The TOE’s HTTPS protocol complies with RFC 2818 and is implemented using TLS 1.0 (RFC 2246), TLS

1.1 (RFC 4346), TLS 1.2 (RFC 5246) supporting the following ciphersuites:

Mandatory:


Optional:


TLS_RSA_WITH_AES_256_CBC_ SHA256



of 90






7.0.1-h4 for details of testing the supported ciphersuites in the TOE’s implementation of TLS.

2.3 User Data Protection (FDP)

2.3.1 Full Residual Information Protection (FDP_RIP.2)


The evaluator shall check to ensure that the TSS describes packet processing to the extent that they can determine

that no data will be reused when processing network packets. The evaluator shall ensure that this description at a

minimum describes how the previous data are zeroized/overwritten, and at what point in the buffer processing this

occurs.

Section 6.3 of the ST states that the TSF allocates and releases the memory resources used for network packet

objects. Both when it receives data from the network and when it transmits data to the network, it ensures that the

buffers are not padded out with previously transmitted or otherwise residual information by overwriting unused parts

of the buffer with 0s.


None defined.


None defined.

2.4 Identification and Authentication (FIA)

2.4.1 Authentication Failure Handling (FIA_AFL.1)


The evaluator shall examine the TSS to determine that it contains a description, for each supported method for

remote administrative actions, of how successive unsuccessful authentication attempts are detected and tracked. The

TSS shall also describe the method by which the remote administrator is prevented from successfully logging on to

the TOE, and the actions necessary to restore this ability.

Section 6.4 of the ST states that the TOE logs all unsuccessful authentication attempts in the System Log. The

device 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 such that a Security Administrator must manually

re-enable the account or it can be configured to last a specified amount of time (0 – 60 minutes). These settings can

be configured for both HTTPS/TLS and IPSec remote administration connections and applies to password and

certificate based authentication.

of 90


The evaluator shall examine the operational guidance to ensure that instructions for configuring the number of

successive unsuccessful authentication attempts (1.1) and time period (1.2, if implemented) are provided, and that

the process of allowing the remote administrator to once again successfully log on is described for each “action”

specified (if that option is chosen). If different actions or mechanisms are implemented depending on the secure

protocol employed (e.g., TLS vs. SSH), all must be described.

In the “Defining Management Settings” section of the WEB guide, the steps for configuring the number of

successive unsuccessful authentication attempts are provided under Authentication settings. The number of failed

login attempts ranges from 0-10. A value of 0 specifies unlimited attempts.


The evaluator shall perform the following tests for IPsec, and for each other method by which remote administrators

access the TOE (e.g., TLS, SSH):

Test 1: The evaluator shall use the operational guidance to configure the number of successive unsuccessful

authentication attempts allowed by the TOE. The evaluator shall test that once the limit is reached, attempts with

valid credentials are not successful. For each action specified by the requirement, the evaluator shall show that

following the operational guidance and performing each action to allow the remote administrator access are

successful.

Test 2: The evaluator shall use the operational guidance to configure the number of successive unsuccessful

authentication attempts allowed by the TOE and a time period after which valid logins will be allowed for a remote

administrator. After exceeding the specified number of invalid login attempts and showing that valid login is not

possible, the evaluator shall show that waiting for the interval defined by the time period before another access

attempt will result in the ability for the remote administrator to successfully log on using valid credentials.

The evaluator tested the TOE’s authentication failure handling via both HTTPS and IPsec.



7.0.1-h4 for details of the TOE’s implementation of authentication failure handling.

2.4.2 Password Management (FIA_PMG_EXT.1)


None defined.


The evaluator shall examine the operational guidance to determine that it provides guidance to security

administrators on the composition of strong passwords, and that it provides instructions on setting the minimum

password length.

Section 2.10.2 of the CCECG provides guidance to security administrators on the composition of strong passwords

and how to configure the minimum password length. When password-based authentication is used, administrators

need to ensure the passwords they use are suitably secure. Many organizations, as a matter of policy, specify

minimum requirements for choosing and constructing user passwords and such policies should be adhered to.

Additionally, or where site-specific policies are not defined, administrators should consider the following when

choosing passwords:

Ensure the password is not too short—a minimum of 8 characters is suggested

Use a mix of upper and lower case alphabetic, numeric, and punctuation characters

Avoid using dictionary words or words readily associated with you (e.g., name of spouse, pet or favorite

sports team)

of 90

Consider using a passphrase—a combination of words that is easy to remember but difficult for an attacker

to guess.

The Palo Alto Networks devices support the ability to configure minimum password length and complexity settings.

To do this, navigate to Devices > Setup and edit the Minimum Password Complexity section. This allows the

following values to be set:

Minimum length

Minimum uppercase letters

Minimum lowercase letters

Minimum numeric characters

Minimum special characters.


The evaluator shall also perform the following tests. Note that one or more of these tests can be performed with a

single test case.

Test 1: The evaluator shall compose passwords that either meet the requirements, or fail to meet the requirements, in

some way. For each password, the evaluator shall verify that the TOE supports the password. While the evaluator is

not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all

characters, rule characteristics, and a minimum length listed in the requirement are supported, and justify the subset

of those characters chosen for testing.

The evaluation team performed the tests specified in the assurance activity and confirmed the TOE supports the

specified password composition requirements, including the specified minimum length.



7.0.1-h4 for details of testing of the specified password composition requirements, including the specified minimum

length.

2.4.3 Protected Authentication Feedback (FIA_UAU.7)


None defined.


None defined.


The evaluator shall perform the following test for each method of local login allowed:

Test 1: The evaluator shall locally authenticate to the TOE. While making this attempt, the evaluator shall verify

that at most obscured feedback is provided while entering the authentication information.

The evaluation team performed the test specified in the assurance activity and confirmed the TOE provides only

obscured feedback when authentication information is entered at the local console.



7.0.1-h4 for details of testing of the of obscured authentication feedback provided at the local console.

of 90

2.4.4 User Identification and Authentication (FIA_UIA_EXT.1)


The evaluator shall examine the TSS to determine that it describes the logon process for each logon method (local,

remote (HTTPS, SSH, etc.)) supported for the product. This description shall contain information pertaining to the

credentials allowed/used, any protocol transactions that take place, and what constitutes a “successful logon”.

Section 6.4 states that the TOE maintains user accounts which it uses to control access to the firewall. When creating

a new user account, the administrator specifies a user name (i.e., user identity), a password or X509

certificate/common access card, and a role. To enable certificate-based authentication, the TOE must be configured

to use a client certificate profile using the Device > Certificate Management > Certificate Profile tab. When a client

certificate profile is enabled, each administrator must use a client certificate for access to the TOE via IPSec and

TLS. Only one role is specified in the user account per user. The TOE uses the user name and password attributes

to identify and authenticate the user when the user logs in via the GUI. With certificate-based authentication, a

digital signature is exchanged and verified, in lieu of a password. The TOE does not echo passwords as they are

entered. It uses the role attribute to specify user permissions and control what the user can do with the GUI.

The administrator can logon to the GUI by using a secure connection (https) from a web browser. The administrator

enters the IP address of the TOE and their username and password or alternatively the TOE may be configured to

require a certificate. The credentials may be supplied by a CAC or retrieved from the client computer.

In order for an administrator to log to the GUI using IPSec, an IPSec tunnel has to be established between the client

laptop/management station and the TOE. The administrator uses a third party IPSec client for setting up an IPSec

tunnel to the TOE. Authentication is performed using the pre-shared keys or the certificates. The administrator runs

a web browser and establishes TLS over IPSec. The authentication method for the user can be performed using a

password or a certificate. If the user is using a CAC, the card must be inserted into the card reader. Regardless of

whether the certificate is on a CAC or not, there is no difference in how the TOE uses the client certificate to

authenticate the user; besides the use of the CAC reader and accessing the credential on the card.

Regardless of whether a user logs in using an HTTPS or IPsec connection, a logon is successful when the username

and password provided by the user matches a defined account on the TOE; or when the username and digital

signature on the certificate is validated by the TOE.


The evaluator shall examine the operational guidance to determine that any necessary preparatory steps (e.g.,

establishing credential material such as pre-shared keys, tunnels, certificates, etc.) to logging in are described. For

each supported login method, the evaluator shall ensure the operational guidance provides clear instructions for

successfully logging on. If configuration is necessary to ensure the services provided before login are limited, the

evaluator shall determine that the operational guidance provides sufficient instruction on limiting the allowed

services.

Section 2.10.1 of the CCECG states that in the evaluated configuration, the device supports the following methods

of administrator authentication:

Local administrator accounts with local password-based authentication

Local administrator accounts with certificate-based authentication.

Note that these methods are mutually exclusive—either all administrators are authenticated using a local password,

or they are all authenticated using a certificate.

The “Device Management” section of [ADMIN] (sub-section “Management Interfaces”, topic “Use the Web

Interface”) describes how the administrator logs on to the TOE via the Web Interface using password-based

authentication.

The “Device Management” section of [ADMIN] (sub-section “Manage Firewall Administrators”, topic

“Administrative Authentication”) provides the following link to an on-line description of how to configure the TOE

for certificate-based authentication: https://live.paloaltonetworks.com/docs/DOC-2672. This article also shows how

the administrator then logs on to the TOE using certificate-based authentication.

https://live.paloaltonetworks.com/docs/DOC-2672

of 90

There is no configuration necessary to limit services provided before login.


The evaluator shall perform the following tests for each method by which administrators access the TOE (local and

remote), as well as for each type of credential supported by the login method:

Test 1: The evaluator shall use the operational guidance to configure the appropriate credential supported for the

login method. For that credential/login method, the evaluator shall show that providing correct I&A information

results in the ability to access the system, while providing incorrect information results in denial of access.

Test 2: The evaluator shall configure the services allowed (if any) according to the operational guidance, and then

determine the services available to an external remote entity. The evaluator shall determine that the list of services

available is limited to those specified in the requirement.

Test 3: For local access, the evaluator shall determine what services are available to a local administrator prior to

logging in, and make sure this list is consistent with the requirement.

The evaluation team performed the tests specified in the assurance activity and confirmed, for all supported methods

of administrator access, the TOE allows access to the GUI when the correct authentication credentials are provided,

and denies access when incorrect credentials are provided. The TOE only displays the warning banner and allows

for network switching services prior to a user being identified and authenticated.



7.0.1-h4 for details of testing of the TOE’s identification and authentication functions including display of warning

banners prior to the user being identified and authenticated.

2.4.5 Extended: Password-based Authentication Mechanism (FIA_UAU_EXT.2)


Assurance activities for this requirement are covered under those for FIA_UIA_EXT.1. If other authentication

mechanisms are specified, the evaluator shall include those methods in the activities for FIA_UIA_EXT.1.

2.4.6 Extended: X509 Certificates (FIA_X509_EXT.1)


The TSS shall describe all certificate stores implemented that contain certificates used to meet the requirements of

this EP. This description shall contain information pertaining to how certificates are loaded into the store, and how

the store is protected from unauthorized access. The TSS description will also include a discussion as to how the

TOE forms a certification path as specified in the standard and how certificates are validated (CRL and/or OCSP are

included in the discussion, as well as the certificate path validation algorithm).

Section 6.4 states that the TOE uses X.509v3 certificates as defined by RFC 5280 to support authentication for

IPsec, and TLS connections. Public key infrastructure (PKI) credentials, such as Rivest, Shamir, and Adelman

(RSA) keys and certificates are stored in the TOE’s underlying file system on the appliance. 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) 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 Open Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) status

verification for certificate profiles. If both are configured, the devices first try the OCSP method; if the OCSP

server is unavailable, the devices use the CRL method.

The TOE downloads and caches OCSP status information for every CA listed in the trusted CA list of the firewall.

The OCSP status is cached for the ‘next update time’ that is configured on the OCSP responder. The TOE uses this

received value as the cache time. OCSP responders can also be configured for other external devices if someone

of 90

decides to use it. The TOE uses a hard coded 1 hour as next update time (cached time) in this case. Caching only

applies to validated certificates; if a firewall never validated a certificate, the firewall cache does not store the OCSP

information for the issuing CA. To use Open Certificate Status Protocol (OCSP) for verifying the revocation

status of certificates, you must configure the firewall to access an OCSP responder (server). The entity that manages

the OCSP responder can be a third-party certificate authority (CA) or, if your enterprise has its own public key

infrastructure (PKI), the firewall itself.

The TOE downloads and caches the last-issued CRL for every CA listed in the trusted CA list of the firewall.

Caching only applies to validated certificates; if a firewall never validated a certificate, the firewall cache does not

store the CRL for the issuing CA. Also, the cache only stores a CRL until it expires. The firewall supports CRLs

only in Distinguished Encoding Rules (DER) format.

The authorized administrator may generate a self-signed root CA certificate as specified in RFC 2986 and provide

the following information in the request: public key, Common Name, Organization, Organizational Unit, Country,

State, Locality, Department, Email, and Host Name. The administrator may also import a certificate and private

key into the firewall from an enterprise certificate authority or obtain a certificate from an external CA. The TOE

provides the ability for administrators to generate a Certificate Signing Request (CSR) with a multi-level

organizational unit.

The TOE validates a certificate path by ensuring the presence of the basicConstraints extension is present and the cA

flag is set to TRUE for all CA certificates. The TOE forms a Certificate trust path by ensuring that the basic

constraints are met, proper key usage parameters exist, the CA flag exists, performing a revocation check of each

certificate in the path and performing the validity of the CA certificate. The TOE will not treat a certificate as a CA

certificate if the basicConstraints extension is not present or the cA flag is not set to TRUE. The TOE supports

CAC (Common Access Card) or client certs to authenticate users prior to accessing systems. An x.509 certificate is

provided by the user/client upon connecting to a secured resource. Using that certificate, the identity of the user is

established and that information is used to determine what level of access should be allowed. If the Subject

Alternate name (SAN) is present in the certificate then it is used as a username to perform verification. The TOE

performs DNS lookup for usernames that are FQDNs. If the SAN is not present then we use the subject DN in the

certificate as the username. This username can then be used to lookup group membership info in Active Directory or

some other directory. In order to validate the cert, the TOE checks whether the issuing CA is a trusted issuer by

PAN-OS. If the client-certificate section is specified and use-crl and/or use-ocsp are specified, the validity of the

client certificate will be verified based on the methods specified. The order is always OCSP followed by CRL if

both are set. Device authentications occur as follows. For trusted channel connections with remote VPN

gateways/peers, the TOE checks the IKE ID payload with the local IKE gateway configuration and the fields in peer

certificate. Device authentication for the transmission of audit records to an audit server using IPsec or TLS occurs

as follows. If the server certificate provided by the audit server has Subject Alternate Name or multiple names

(SANs) then each one of those names are verified against the server name/ip configured. If the SAN or SANs is not

present in the certificate then the certificate subject DN is checked for a match against the configured server.

Connections with the UIA to retrieve the IP address mapping information use TLS 1.2 with

RSA_With_AES_256_GCM_SHA384 with hardcoded/predefined, self-signed certificate. The use of pre-defined

self-signed internal certs renders the certificate subject name not applicable as it would always be the same. For

connections with the update server, if the server certificate provided by the update server has Subject Alternate

Name or multiple names (SANs) then each one of those defined names are verified against the update server

name/ip configured. If the SAN or SANs is not present in the certificate then the TOE compares the certificate

subject DN and matches that against the configured update server. The TOE will not establish an SA if a certificate

or certificate path is deemed invalid; or if the presented identifier does not match the configured reference identifier

of the peer as described above. If the TOE cannot establish a connection to determine the validity of a certificate,

the administrator may establish the SA or disallow the establishment of the SA.

Certificates and their associated private key are stored in a single container: the Certificate File. The PKCS#12 file

consists of an Encrypted Private Key and X509 Certificate.

of 90


The evaluator shall verify that the operational guidance describes how the administrator loads certificates into the

certificate store. If the level of protection can be managed by the administrator, the guidance provides a description

of how to manage the protection mechanism. The guidance instructs the administrator how to establish a protected

connection to the CA for the transmission of the Certificate Request Message, as well as containing instructions to

generate a key pair and the Certificate Request Message to the CA.

The guidance documentation provides instructions how to select the method used for checking certificate validity

(CRLs, OCSP), as well as how to setup a communication path with the entity providing the information pertaining

to certificate validity. How the administrator can configure the TOE to either allow or disallow the establishment of

an SA is also described in the operational guidance.

Section 2.7.4 of the CCECG references the “Monitoring” section of [ADMIN] (sub-section “Use Syslog for

Monitoring”, topic “Configure Syslog Monitoring”) which provides information on how to configure the TOE to

export audit records to a syslog server. This includes steps to configure the TLS protected channel between the TOE

and the syslog server. These steps include how to establish a protected connection to the CA for transmission of the

Certificate Request Message, generating a key pair and using CRL and OCSP to check certificate validity.


The tests associated with this component are bundled with the FCS_IPSEC_EXT.1.12 requirements and specified by

TD0037 as identified below for the FIA_X509_EXT.1.9 and FIA_X509_EXT.1.10 elements.

2.4.6.4 FIA_X509_EXT.1.9, FIA_X509_EXT.1.10


The evaluator shall ensure that the TSS describes how the TOE compares the peer’s presented identifier to the

reference identifier. This description shall include whether the certificate presented identifier is compared to the ID

payload presented identifier, which field(s) of the certificate are used as the presented identifier (DN, Common

Name, or SAN), and, if multiple fields are supported, the logical order comparison. If the ST author assigned an

additional identifier type, the TSS description shall also include a description of that type and the method by which

that type is compared to the peer’s presented certificate.

Section 6.4 of the ST states that the TOE validates a certificate path by ensuring the presence of the basicConstraints

extension is present and the cA flag is set to TRUE for all CA certificates. The TOE forms a Certificate trust path

by ensuring that the basic constraints are met, proper key usage parameters exist, the CA flag exists, performing a

revocation check of each certificate in the path and performing the validity of the CA certificate. The TOE will not

treat a certificate as a CA certificate if the basicConstraints extension is not present or the cA flag is not set to

TRUE.

The TOE compares a peer’s presented identifier to the reference identifier as follows.

CAC (Common Access Card) or client certs for authentication of users prior to accessing systems - An

x.509 certificate is provided by the user/client upon connecting to a secured resource. Using that certificate,

the identity of the user is established and that information is used to determine what level of access should

be allowed. If the Subject Alternate name (SAN) is present in the certificate then it is used as a username

to perform verification. The TOE performs DNS lookup for usernames that are FQDNs. If the SAN is not

present then we use the subject DN in the certificate as the username. This username can then be used to

lookup group membership info in a directory located in TOE files. In order to validate the cert, the TOE

checks whether the issuing CA is a trusted issuer by PAN-OS. If the client-certificate section is specified

and use-crl and/or use-ocsp are specified, the validity of the client certificate will be verified based on the

methods specified. The order is always OCSP followed by CRL if both are set. Device authentications

occur as follows.

For trusted channel connections with remote VPN gateways/peers, the TOE requires the IKE peer id to be

configured for certificate authentication: if the type is DN, the TOE checks the peer id against subject DN;

otherwise it is checked against the SAN field.

of 90

Device authentication for the transmission of audit records to an audit server using IPsec or TLS occurs as

follows. If the server certificate provided by the audit server has Subject Alternate Name or multiple names

(SANs) then each one of those names are verified against the server name/ip configured. If the SAN or

SANs is not present in the certificate then the certificate subject DN is checked for a match against the

configured server.

Connections with the UIA to retrieve the IP address mapping information use TLS 1.2 with

RSA_With_AES_256_GCM_SHA384 with hardcoded/predefined, self-signed certificate. The use of pre-

defined self-signed internal certs renders the certificate subject name not applicable as it would always be

the same.

For connections with the update server, if the server certificate provided by the update server has Subject

Alternate Name or multiple names (SANs) then each one of those defined names are verified against the

update server name/ip configured. If the SAN or SANs is not present in the certificate then the TOE

compares the certificate subject DN and matches that against the configured update server.

The TOE will not establish an SA if a certificate or certificate path is deemed invalid; or if the presented identifier

does not match the configured reference identifier of the peer as described above. If the TOE cannot establish a

connection to determine the validity of a certificate, the administrator may establish the SA or disallow the

establishment of the SA.


The evaluator shall ensure that the operational guidance includes the configuration of the reference identifier(s) for

the peer.

The “Setup and IKE Gateway” section of the WEB guide provides instructions for configuration of the peer

identification.


The evaluator follows the guidance in the performance of the assurance activities for the FIA_X509 requirement.

For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests:

Test 1: For each field of the certificate supported for comparison, the evaluator shall configure the peer’s reference

identifier on the TOE (per the administrative guidance) to match the field in the peer’s presented certificate and shall

verify that the IKE authentication succeeds.

Test 2: For each field of the certificate support for comparison, the evaluator shall configure the peer’s reference

identifier on the TOE (per the administrative guidance) to not match the field in the peer’s presented certificate and

shall verify that the IKE authentication fails.

The following tests are conditional:

Test 3: (conditional) If, according to the TSS, the TOE supports both Common Name and SAN certificate fields and

uses the preferred logic outlined in the Application Note, the tests above with the Common Name field shall be

performed using peer certificates with no SAN extension. Additionally, the evaluator shall configure the peer’s

reference identifier on the TOE to not match the SAN in the peer’s presented certificate but to match the Common

Name in the peer’s presented certificate, and verify that the IKE authentication fails.

Test 4: (conditional) If the TOE supports DN identifier types, the evaluator shall configure the peer’s reference

identifier on the TOE (per the administrative guidance) to match the subject DN in the peer’s presented certificate

and shall verify that the IKE authentication succeeds. To demonstrate a bit-wise comparison of the DN, the

evaluator shall change a single bit in the DN (preferably, in an Object Identifier (OID) in the DN) and verify that the

IKE authentication fails.

Test 5: (conditional) If the TOE supports both IPv4 and IPv6 and supports IP address identifier types, the evaluator

must repeat test 1 and 2 with both IPv4 address identifiers and IPv6 identifiers. Additionally, the evaluator shall

verify that the TOE verifies that the IP header matches the identifiers by setting the presented identifiers and the

reference identifier with the same IP address that differs from the actual IP address of the peer in the IP headers and

verifying that the IKE authentication fails.

of 90

Test 6: (conditional) If, according to the TSS, the TOE performs comparisons between the peer’s ID payload and the

peer’s certificate, the evaluator shall repeat the following test for each combination of supported identifier types and

supported certificate fields (as above). The evaluator shall configure the peer to present a different ID payload than

the field in the peer’s presented certificate and verify that the TOE fails to authenticate the IKE peer.

The evaluation team performed the tests specified in the assurance activity and confirmed that IKE authentication

only succeeds when the peer’s reference identifier on the TOE matches the field in the peer’s presented certificate.



7.0.1-h4 for details of testing of the TOE’s supported certificates.

2.5 Security Management (FMT)

2.5.1 Management of Security Functions Behavior (FMT_MOF.1)

2.5.1.1 Assurance Activities

None Identified.

2.5.2 Management of TSF Data (for general TSF data) (FMT_MTD.1)


The evaluator shall examine the TSS to determine that, for each administrative function identified in the operational

guidance; those that are accessible through an interface prior to administrator log-in are identified. For each of these

functions, the evaluator shall also confirm that the TSS details how the ability to manipulate the TSF data through

these interfaces is disallowed for non-administrative users.

Section 6.4 indicates that the TOE is designed to require users to be identified and authenticated before they can

access any of the TOE functions. The only capabilities allowed prior to users authenticating are the display of the

warning banner before authentication.

Section 6.5 (Security Management) describes how the TSF limits access to administrative functions. The TOE

provides a GUI management interface to support security management of the TOE. The GUI is accessible via direct

connection to the management port on the device, or remotely over HTTPS or IPSec. The management interfaces

enable the authorized administrators to configure the TOE functions and to manipulate TOE data.

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 custom

administrator roles: auditadmin, cryptoadmin, and securityadmin. These administrator roles are all considered

Security Administrator as defined in the NDPP for the purposes of this ST. All roles can administer the TOE both

locally and remotely.


The evaluator shall review the operational guidance to determine that each of the TSF-data-manipulating functions

implemented in response to the requirements of this PP is identified, and that configuration information is provided

to ensure that only administrators have access to the functions.

Section 2.1.1.1.2 of this AAR identifies the administrative actions that are relevant in the context of the three PPs.

The individual SFR related assurance activities throughout this document reference the areas in the guidance that

describe each of the TSF data manipulating functions that are implemented in response to the requirements of the

PP’s.

Section 2.4 of the CCECG states that placing the TOE in CC Mode provides CC specific features including the

Security Administrator, Audit Administrator and Cryptographic Administrator roles. Section 2.11 of the CCECG

of 90

indicates that the TOE is preconfigured with a default administrative account (admin) that provides full read-write

access (also known as superuser access) to the device. The Superuser role is intended only for initial configuration,

to create the administrator accounts for the Security Administrator, Audit Administrator, and Cryptographic

Administrator. The “Device Management” section of [ADMIN] (sub-section “Manage Firewall Administrators”,

topic “Create an Administrative Account”) provides guidance on creating administrative accounts.

Section 2.11.1 of the CCECG clarifies that only the three roles provided in CC mode may be used in the evaluated

configuration. The Security Administrator can perform all TOE security functions except modification of

cryptographic security data and managing the audit logs. The Audit Administrator can only review and delete audit

records and the Cryptographic Administrator can review audit records, modify cryptographic security data and

execute cryptographic self tests.


None defined.

2.5.3 Specification of Management Functions (FMT_SMF.1)


The evaluator shall verify that the TSS describes how the Packet filter firewall rules can be configured. Note that

this activity should have been addressed with the TSS assurance activities for FPF_RUL_EXT.1.

The evaluator shall verify that the TSS describes how the stateful traffic filter firewall rules can be configured. Note

that this activity should have been addressed with the TSS assurance activities for FFW_RUL_EXT.1.

See the TSS Assurance Activities for FPF_RUL_EXT.1 and FFW_RUL_EXT.1


The evaluator shall verify that the operational guidance describes how to configure the Packet filter firewall rules,

including how to set any configurable defaults and how to configure each of the applicable rule attributes, actions,

and associated interfaces. The evaluator must ensure that the operational guidance also provides instruction that

would allow an administrator to ensure that configured rules are properly ordered. Note that this activity should have

been addressed with the Guidance assurance activities for FPF_RUL_EXT.1.


rules, including how to set any configurable defaults and how to configure each of the applicable rule attributes,

actions, and associated interfaces. The evaluator must ensure that the operational guidance also provides instruction

that would allow an administrator to ensure that configured rules are properly ordered. Note that this activity should

have been addressed with the Guidance assurance activities for FFW_RUL_EXT.1.

See the Guidance Assurance Activities for FPF_RUL_EXT.1 and FFW_RUL_EXT.1


Test 1: The evaluator shall devise tests that demonstrate that the functions used to configure the Packet filter firewall

rules yield expected changes in the rules that they are correctly enforced. A number of rule combination and


through the TOE. Note that this activity should have been addressed with a combination of the Test assurance

activities for FPF_RUL_EXT.1.

Test 1: The evaluator shall devise tests that demonstrate that the functions used to configure the stateful traffic filter

firewall rules yield expected changes in the rules that they are correctly enforced. A number of rule combination and


through the TOE. Note that this activity should have been addressed with a combination of the Test assurance

activities for FFW_RUL_EXT.1.

See the Test Activities for FPF_RUL_EXT.1 and FFW_RUL_EXT.1

of 90

2.5.4 Restrictions on Security Roles (FMT_SMR.2)


None defined.


The evaluator shall review the operational guidance to ensure that it contains instructions for administering the TOE

both locally and remotely, including any configuration that needs to be performed on the client for remote

administration.

Section 2.4 of the CCECG states that in order to manage a Palo Alto Networks device in a way consistent with the

evaluated configuration, device management should only be performed via the web interface over HTTPS from a

trusted network connection using an Internet Explorer (IE, version 7 or later), Firefox (version 3.6 or later), Safari

(version 5 or later), or Chrome (version 11 or later) browser. Panorama, Telnet, and HTTP, and connections over

untrusted networks are not supported and must not be enabled. Refer to the “Device Management” section of

[ADMIN] for more details on using the web interface.


In the course of performing the testing activities for the evaluation, the evaluator shall use all supported interfaces,

although it is not necessary to repeat each test involving an administrative action with each interface. The evaluator

shall ensure, however, that each supported method of administering the TOE that conforms to the requirements of

this PP be tested; for instance, if the TOE can be administered through a local hardware interface; SSH; and

TLS/HTTPS; then all three methods of administration must be exercised during the evaluation team’s test activities.

The evaluation team performed tests at the GUI over both HTTPS/TLS and IPsec, thereby exercising all supported

methods of administration.

2.6 Packet Filtering (FPF)

2.6.1 Extended Packet Filtering (FPF_RUL_EXT.1)

2.6.1.1 FPF_RUL_EXT.1.1


The evaluator shall verify that the TSS provide a description of the TOE’s initialization/startup process, which

clearly indicates where processing of network packets begins to take place, and provides a discussion that supports

the assertion that packets cannot flow during this process.

The evaluator shall verify that the TSS also includes a narrative that identifies the components (e.g., active entity

such as a process or task) involved in processing the network packets and describes the safeguards that would

prevent packets flowing through the TOE without applying the ruleset in the event of a component failure. This

could include the failure of a component, such as a process being terminated, or a failure within a component, such

as memory buffers full and cannot process packets.

Section 6.9 indicates that the Packet Filtering function is a subset of the Stateful Traffic Filtering function. On the

Palo Alto Networks firewall, security policies determine whether to block or allow a session based on traffic

attributes such as the source and destination security zone, the source and destination IP address, the application,

user, and the service.

All traffic passing through the firewall is matched against a session and each session is matched against a security

policy. When a session match occurs, the security policy is applied to bi-directional traffic (client to server and

server to client) in that session. For traffic that doesn’t match any defined rules, a final configurable deny or allow

rule is applied. The default rules allow all intrazone (within the zone) traffic and deny all interzone (between zones)

of 90

traffic. Typically interzone traffic is considered to be trusted however both intrazone and interzone traffic can be

configured to deny all traffic if there is no rule match by clicking on the security policy and clicking on the Override

button on the bottom on the Policy ->Security screen. In the evaluated configuration, the default deny all rule for

interzone traffic should not be modified. Each rule can be configured to generate a log record when the traffic

matches the defined rule using the ‘policy->Security->options’ selection. The logging option can be configured to

log at the start of a session, or at the end of a session or both.

Security policies are evaluated left to right and from top to bottom in a packet filtering table format. A packet is

matched against the first rule that meets the defined criteria; after a match is triggered the subsequent rules are not

evaluated. Therefore, the more specific rules must precede more generic ones in order to enforce the best match

criteria. Traffic that matches a rule generates a log entry at the end of the session in the traffic log, if logging is

enabled for that rule.

The TOE will drop the packets if one of its interfaces is overwhelmed by network traffic. The 7000 series provides

higher performance, in order to compensate the FPGA is designed to drop IPv6 with “zero” destination in the initial

ingress packet processing. This event is logged in the FPGA counter log “flow_fpga_rcv_igr_IPV6DSTZERO”.

The security policy rules that determine whether a packet is transferred from one interface to another is based on:

1. IP address of source as defined as the original IP address in the packet.

2. IP address of destination as defined as the original IP address in the packet.

3. Service used allows Layer 4 selection (TCP or UDP) port for the application.

4. Source Zone from which the traffic originates.

5. Destination Zone at which the traffic terminates.

Section 6.10 states that network traffic can go through the TOE only if the Policy Enforcement Module is fully

functional and it is enforcing all policies. During start-up and initialization, the TOE runs a series of system checks

and the FIPS 140-2 power up self- tests to ensure the system is functioning correctly. If these tests run successfully,

the TOE will bring up the control plane and data-plane system modules. The Policy Enforcement Module (running

on dataplane) uses the policy configuration information created from the Management Server Module (running on

the control plane). The configuration information includes all of the policies required by the Policy Enforcement

Module. Policies are used to control information flow on the network. Only once the Policy Enforcement Module

running on the data-plane is up and running and the TOE’s system configuration is applied to enforce all security

policies, can the TOE pass the traffic.

The TOE implements the following safeguards that prevent packets from flowing through the TOE without applying

the ruleset in the event of a component failure. The traffic can go through the TOE only if the Policy Enforcement

Module is fully functional and enforcing all policies as described above. The Policy Enforcement Module can be

configured to stop traffic when the traffic or system logs are full. Whenever a failure occurs within the TOE that

results in the TOE ceasing operation, the TOE securely disables its interfaces to prevent the unintentional flow of

any information to or from the TOE and reloads.


The operational guidance associated with this requirement is assessed in the subsequent test assurance activities.


Test 1: The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized.

A steady flow of network packets that would otherwise be denied by the ruleset should be directed at the TOE’s

interfaces, with packet sniffers listening to see if any network traffic is allowed through.

Note: The remaining testing associated with application of the ruleset is addressed in the subsequent test assurance

activities.

The evaluation team performed the tests specified in the assurance activity and confirmed that no packets made it

through the firewall during initialization and the packets were appropriately logged as dropped.

of 90



7.0.1-h4 for details of testing of the TOE’s network traffic handling.

2.6.1.2 FPF_RUL_EXT.1.2


The evaluators shall verify that the TSS indicates that the following protocols are supported:

•RFC 791(IPv4)

•RFC 2460 (IPv6)

•RFC 793 (TCP)

•RFC 768 (UDP).

The evaluator shall verify that the TSS describes how conformance with the identified RFCs has been determined by

the TOE developer (e.g., third party interoperability testing, protocol compliance testing).

Section 6.10 states that an authorized administrator may configure the TOE to apply stateful traffic filtering rules of

permit, deny, and log on the following protocols:

Internet Control Message Protocol version 4 (ICMPv4)


Internet Protocol (IPv4)

Internet Protocol version 6 (IPv6)

Transmission Control Protocol (TCP)

User Datagram Protocol (UDP)

Conformance with the RFC 792 (ICMPv4), RFC 4443 (ICMPv6), RFC 791(IPv4), RFC 2460 (IPv6), RFC 793

(TCP), RFC 768 (UDP) protocols is verified by Palo Alto through regular quality assurance, regression, and

interoperability testing.


The evaluator shall verify that the operational guidance indicates that the following protocols are supported:

•RFC 791 (IPv4)

•RFC 2460 (IPv6)

•RFC 793 (TCP)

•RFC 768 (UDP)

The guidance will describe the other protocols contained within the ST (e.g., IPsec, IKE, potentially HTTPS, SSH,

and TLS) that are processed by the TOE. The evaluator ensures it is made clear what protocols were not considered

as part of the TOE evaluation.

Section 2.2 of the CCECG states that the evaluated functionality is scoped exclusively to the security functional

requirements specified in [ST]. In particular, only the following protocols implemented by the Palo Alto Networks

devices have been tested, and only to the extent specified by the security functional requirements: IPsec; IKE; TLS;

HTTPS. The packet filtering/stateful traffic filtering capabilities of the Palo Alto Networks devices have been tested

only for the following protocols: IPv4; IPv6; ICMPv4; ICMPv6; TCP; UDP; FTP. The following protocols

identified in [ST] have not been considered in the evaluation: SMTP; SNMP; SSH.

of 90

Section 2.9 of the CCECG states that the Palo Alto Networks firewalls can be configured to perform stateful traffic

filtering on the following protocols and associated attributes:

Internet Control Message Protocol version 4 (ICMPv4), as defined in RFC 792

o Type

o Code


o Type

o Code

Internet Protocol (IPv4), as defined in RFC 791

o Source address

o Destination address

o Transport layer protocol

Internet Protocol version 6 (IPv6), as defined in RFC 2460

o Source address



Transmission Control Protocol (TCP), as defined in RFC 793

o Source port

o Destination port

User Datagram Protocol (UDP), as defined in RFC 768

o Source port

o Destination port.


The testing associated with this requirement is addressed in the subsequent test assurance activities.

2.6.1.3 FPF_RUL_EXT.1.3/ FPF_RUL_EXT.1.4/ FPF_RUL_EXT.1.5


The evaluator shall verify that the TSS describes a Packet Filtering policy and the following attributes are:

IPv4

Source Address

Destination Address

Protocol

IPv6

Source Address

Destination Address

Next Header (Protocol)

TCP

Source Port

of 90

Destination Port

UDP

Source Port

Destination Port

The evaluator shall verify that each rule can identify the following actions: permit, deny, and log.

The evaluator shall verify that the TSS identifies all interface types subject to the Packet Filtering policy and

explains how rules are associated with distinct network interfaces. Where interfaces can be grouped into a common

interface type (e.g., where the same internal logical path is used, perhaps where a common device driver is used)

they can be treated collectively as a distinct network interface.

Section 6.10 of the ST states that the TOE enforces the stateful traffic filtering rules based on the following subject

and information security attributes:

Source security zone to which the physical network interface is assigned

Destination security zone to which the network interface is assigned

Information specifiable in security policies, which provide the information flow rule sets:

o presumed identity of source subject—source address information within the packet

o identity of destination subject—destination address information within the packet

o transport layer protocol (e.g., TCP, UDP)

o Internet layer protocol (e.g., ICMP type, code)

o source subject service identifier (e.g., source port number)

o destination subject service identifier (e.g., destination port number)

Information security attributes for stateful packet inspection—for connection-oriented protocols (e.g.,

TCP), the sequence number, acknowledgement number, and flags (SYN, ACK, RST, FIN); and for

connectionless protocols (e.g., UDP), the source and destination network identifiers; and source and

destination service identifiers. Note that the TOE uses an IP-based network stack.

The TOE keeps state about connections or pseudo-connections and uses the information to permit or deny

information flow. The TOE permits information flow between two subjects (i.e., from the physical interface on

which network traffic entered to the physical interface determined by the destination address in the network packet)

only where a security policy is defined between the source and destination zones that includes a rule that grants

permission, based on the information security attributes listed above and the corresponding settings in the policy

rule.

A security policy rule includes the following attributes against which network packets can be compared:

Source Zone, Destination Zone—zones must be of the same type (Layer 2, Layer 3, or Virtual Wire).

Multiple zones can be specified in a single rule to simplify management

Source Address, Destination Address—the IPv4 or IPv6 addresses for which the rule applies. Addresses

must first be defined by the administrator, who specifies a name for the address and the actual IPv4 or IPv6

addresses to be associated with that name. Addresses can be specified as a single address, an address with a

mask, or an address range. Addresses can also be combined into address groups to simplify management

Service—specifies services to limit applications to specific protocols and port numbers.

A security policy rule also includes the following attributes that determine what the TOE does with the network

packet:

Action—can be ‘allow’ or ‘deny’

Profiles—specifies any checking to be performed by the security profiles described above (i.e., antivirus,

anti-spyware, vulnerability protection, data filtering, file blocking)

of 90

Options—specifies the following additional processing options for network packets matching the rule:

o Log Setting—generate log entries in the local traffic log

o Schedule—limits the days and times when the rule is in effect (e.g., an ‘allow’ rule might be active

only during normal business hours)

o QoS Marking—change the Quality of Service (QoS) marking on packets matching the rule

The TOE groups interfaces into security zones. Each zone identifies one or more interfaces on the TOE. Separate

zones must be created for each type of interface (Layer 2, Layer 3, or virtual wire), and each interface must be

assigned to a zone before it can process traffic.

Security policies provide the firewall rule sets that specify whether to block or allow network connections, based on

the source and destination zones, addresses, and the application service (such as UDP port 67 or TCP port 80).

Security policy rules are processed in sequence, applying the first rule that matches the incoming traffic.

Security policies can be defined only between zones of the same type. However, the administrator can create a

VLAN interface for one or more VLANs and then apply a security policy between the VLAN interface zone and a

Layer 3 interface zone. This has the same effect as applying policies between the Layer 2 and Layer 3 interface

zones.

Each rule can be configured to generate a log record when the traffic matches the defined rule using the ‘policy-

>Security->options’ selection. The logging option can be configured to log at the start of a session, or at the end of a

session or both.


The evaluators shall verify that the operational guidance identifies the following attributes as being configurable

within Packet filtering rules for the associated protocols:

IPv4

Source address

Destination Address

Protocol

IPv6

Source address

Destination Address


TCP

Source Port

Destination Port

UDP

Source Port

Destination Port

The evaluator shall verify that the operational guidance indicates that each rule can identify the following actions:

permit, deny, and log.

The evaluator shall verify that the operational guidance explains how rules are associated with distinct network

interfaces.

The evaluator shall verify that the operational guidance explains how to determine the interface type of a distinct

network interface (e.g., how to determine the device driver for a distinct network interface).




o Type

o Code

of 90


o Type

o Code


o Source address




o Source address




o Source port

o Destination port


o Source port

o Destination port.

The Palo Alto Networks firewalls group interfaces into security zones. Each zone identifies one or more interfaces

on the firewall, and each interface must be assigned to a zone before it can process traffic. On the Palo Alto

Networks firewall, security policies are used to determine whether to block or allow a session, based on traffic

attributes such as the source and destination security zone, the source and destination IP address, and the source and

destination port (service).



server to client) in that session. For traffic that doesn’t match any defined rules, the default rules apply. The default

rules allow all intrazone (within the zone) traffic and deny all interzone (between zones) traffic.

Security policies are evaluated left to right and from top to bottom. A packet is matched against the first rule that

meets the defined criteria; after a match is triggered the subsequent rules are not evaluated. Therefore, the more

specific rules must precede more generic ones in order to enforce the best match criteria. Traffic that matches a rule

generates a log entry at the end of the session in the traffic log, if logging is enabled for that rule. The logging

options are configurable for each rule, and can for example be configured to log at the start of a session instead of,

or in addition to, logging at the end of a session.


Test 1: The evaluator shall use the instructions in the operational guidance to test that packet filter rules can be

created that permit, deny, and log packets for each of the following attributes:

IPv4

Source address

Destination Address

Protocol

IPv6

Source address

Destination Address


TCP

of 90

Source Port

Destination Port

UDP

Source Port

Destination Port

Test 2: Repeat the test assurance activity above to ensure that Packet filtering rules can be defined for each distinct

network interface type supported by the TOE.

Note that these test activities should be performed in conjunction with those of FPF_RUL_EXT.1.7 where the

effectiveness of the rules is tested; here the evaluator is just ensuring the guidance is sufficient and the TOE supports

the administrator creating a ruleset based on the above attributes. The test activities for FPF_RUL_EXT.1.7 define

the protocol/attribute combinations required to be tested. If those combinations are configured manually, that will

fulfill the objective of these test activities, but if those combinations are configured otherwise (e.g., using

automation), these test activities may be necessary in order to ensure the guidance is correct and the full range of

configurations can be achieved by a TOE administrator.

The evaluation team performed the tests specified in the assurance activity and confirmed that packet filter rules can

be created that permit, deny, and log packets for the attributes listed above.



7.0.1-h4 for details of testing of the TOE’s packet filter rules.

2.6.1.4 FPF_RUL_EXT.1.6


The evaluator shall verify that the TSS describes the algorithm applied to incoming packets, including the

processing of default rules, determination of whether a packet is part of an established session, and application of

administrator defined and ordered ruleset.

Section 6.9 states that on the Palo Alto Networks firewall, security policies determine whether to block or allow a

session based on traffic attributes such as the source and destination security zone, the source and destination IP

address, the application, user, and the service.



server to client) in that session. For traffic that doesn’t match any defined rules, a final configurable deny or allow

rule is applied. The default rules allow all intrazone (within the zone) traffic and deny all interzone (between zones)




interzone traffic should not be modified. Each rule can be configured to generate a log record when the traffic

matches the defined rule using the ‘policy->Security->options’ selection. The logging option can be configured to

log at the start of a session, or at the end of a session or both.






The logging options are configurable for each rule, and can for example be configured to log at the start of a session

instead of, or in addition to, logging at the end of a session.

of 90


The evaluator shall verify that the operational guidance describes how the order of Packet filtering rules is

determined and provides the necessary instructions so that an administrator can configure the order of rule

processing.

Section 2.9 states that security policies are evaluated left to right and from top to bottom. A packet is matched

against the first rule that meets the defined criteria; after a match is triggered the subsequent rules are not evaluated.

Therefore, the more specific rules must precede more generic ones in order to enforce the best match criteria. Traffic

that matches a rule generates a log entry at the end of the session in the traffic log, if logging is enabled for that rule.

The logging options are configurable for each rule, and can for example be configured to log at the start of a session

instead of, or in addition to, logging at the end of a session.


Test 1: The evaluator shall devise two equal Packet filtering rules with alternate operations – permit and deny. The

rules should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first rule is

enforced in both cases by generating applicable packets and using packet capture and logs for confirmation.

Test 2: The evaluator shall repeat the procedure above, except that the two rules should be devised where one is a



The evaluation team performed the tests specified in the assurance activity and confirmed that the packet filter rules

permit and deny can be deployed in two distinct orders.




2.6.1.5 FPF_RUL_EXT.1.7


The evaluator shall verify that the TSS describes the process for applying Packet filtering rules and also that the

behavior (either by default, or as configured by the administrator) is to deny packets when there is no rule match

unless another required conditions allows the network traffic (i.e., FPF_RUL_EXT.1.6 or FPF_RUL_EXT.1.7).

Section 6.9 states that for traffic that doesn’t match any defined rules, a final configurable deny or allow rule is

applied. The default rules are to allow all intrazone (within the zone) traffic and deny all interzone (between zones)




interzone traffic should not be modified.


The evaluator shall verify that the operational guidance describes the behavior if no rules or special conditions apply

to the network traffic. If the behavior is configurable, the evaluator shall verify that the operational guidance

provides the appropriate instructions to configure the behavior to deny packets with no matching rules.

Section 2.9 states that for traffic that doesn’t match any defined rules, the default rules apply. The default rules allow

all intrazone (within the zone) traffic and deny all interzone (between zones) traffic.

of 90


Test 1: The evaluator shall configure the TOE to permit and log each defined IPv4 Transport Layer Protocol (see

table 9-1 Defined Protocol-specific Values) in conjunction with a specific source address and specific destination

address, specific source address and wildcard destination address, wildcard source address and specific destination

address, and wildcard source address and wildcard destination address. The evaluator shall generate packets

matching each defined IPv4 Transport Layer Protocol and within the configured source and destination addresses in

order to ensure that they are permitted (i.e., by capturing the packets after passing through the TOE) and logged.

Test 2: The evaluator shall configure the TOE to permit all traffic except to deny and log each defined IPv4

Transport Layer Protocol (see table 9-1 Defined Protocol-specific Values) in conjunction with a specific source

address and specific destination address, specific source address and wildcard destination address, wildcard source

address and specific destination address, and wildcard source address and wildcard destination address. The

evaluator shall generate packets matching each defined IPv4 Transport Layer Protocol and within the configured

source and destination addresses in order to ensure that they are denied (i.e., by capturing no applicable packets

passing through the TOE) and logged.




address, and wildcard source address and wildcard destination address. Additionally, the evaluator shall configure

the TOE to deny and log each defined IPv4 Transport Layer Protocol (see table 9-1 Defined Protocol-specific

Values) in conjunction with different (than those permitted above) combinations of a specific source address and

specific destination address, specific source address and wildcard destination address, wildcard source address and

specific destination address, and wildcard source address and wildcard destination address. The evaluator shall

generate packets matching each defined IPv4 Transport Layer Protocol and outside the scope of all source and

destination addresses configured above in order to ensure that they are denied (i.e., by capturing no applicable

packets passing through the TOE).



address, specific source address and wildcard destination address, wildcard 36 source address and specific

destination address, and wildcard source address and wildcard destination address. The evaluator shall generate

packets matching each defined IPv6 Transport Layer Protocol and within the configured source and destination

addresses in order to ensure that they are permitted (i.e., by capturing the packets after passing through the TOE)

and logged.


Transport Layer Protocol (see table 9-1 Defined Protocol-specific Values) in conjunction with a specific source











Values) in conjunction with different (than those permitted above) combinations of a specific source address and






of 90

Test 7: The evaluator shall configure the TOE to permit and log protocol 6 (TCP) using a selected source port, a

selected destination port, and a selected source and destination port combination. The evaluator shall generate

packets matching the configured source and destination TCP ports in order to ensure that they are permitted (i.e., by

capturing the packets after passing through the TOE) and logged.

Test 8: The evaluator shall configure the TOE to deny and log protocol 6 (TCP) using a selected source port, a


packets matching the configured source and destination TCP ports in order to ensure that they are denied (i.e., by

capturing no applicable packets passing through the TOE) and logged.

Test 9: The evaluator shall configure the TOE to permit and log protocol 17 (UDP) using a selected source port, a


packets matching the configured source and destination UDP ports in order to ensure that they are permitted (i.e., by

capturing the packets after passing through the TOE) and logged. Here the evaluator ensures that the UDP port 500

(IKE) is included in the set of tests.

Test 10: The evaluator shall configure the TOE to deny and log protocol 17 (UDP) using a selected source port, a


packets matching the configured source and destination UDP ports in order to ensure that they are denied (i.e., by

capturing no applicable packets passing through the TOE) and logged. Again, the evaluator ensures that UDP port

500 is included in the set of tests


operate as expected in each test scenario.




2.7 Protection of the TSF (FPT)

2.7.1 Extended: Protection of Administrator Passwords (FPT_APW_EXT.1)


The evaluator shall examine the TSS to determine that it details all authentication data that are subject to this

requirement, and the method used to obscure the plaintext password data when stored. The TSS shall also detail how

passwords are stored in such a way that they are unable to be viewed through an interface designed specifically for

that purpose, as outlined in the application note.

Section 6.6 states that the TOE is designed specifically to prevent access to locally-stored cryptographically

protected passwords.. The TOE protects the confidentiality of user passwords by encrypting the password using

AES-256. The TOE does not offer any functions that will disclose the password to any users.


None Defined.


None defined.

of 90

2.7.2 Extended: Protection of TSF Data (for reading of all symmetric keys) (FPT_SKP_EXT.1)


The evaluator shall examine the TSS to determine that it details how any pre-shared keys, symmetric keys, and

private keys are stored and that they are unable to be viewed through an interface designed specifically for that

purpose, as outlined in the application note. If these values are not stored in plaintext, the TSS shall describe how

they are protected/obscured.

Section 6.6 states that certificates and their associated private key are stored in a single container: the Certificate

File. The PKCS#12 file consists of an Encrypted Private Key and X509 Certificate. By default all the private keys

are protected since they are always stored in encrypted format using AES-256. The TOE prevents the reading of all

keys by encrypting them with a Master Key using AES-256. The TOE does not provide an interface to read the

Master Key. The TOE does not offer any functions that will disclose a stored cryptographic key to any users.


None defined.


None defined.

2.7.3 Fail Secure (FPT_FLS)


The evaluator shall ensure the TSS describes how the TOE ensures a shutdown upon a self-test failure, a failed

integrity check of the TSF executable image, or a failed health test of the noise source. If there are instances when a

shut-down does not occur, e.g., a failure is deemed non-security relevant, those cases are identified and a rationale

supporting the classification and justification why the TOE’s ability to enforce its security policies is not affected.

Section 6.6 of the ST states that failed self-tests comply with FIPS 140-2 requirements, i.e., a generated key shall not

be used, the cryptographic module shall react as required by FIPS PUB 140-2 for failing a self-test, and this event

will be audited. If a self-test fails, the TOE enters an error state and outputs an error indicator. The TOE doesn’t

perform any cryptographic operations while in the error state. All data output from the TOE is inhibited when an

error state exists. Should one or more power-up self-tests fail the module will reboot and enter a state in which the

reason for the reboot can be determined.

Whenever a failure occurs within the TOE that results in the TOE ceasing operation, the TOE securely disables its

interfaces to prevent the unintentional flow of any information to or from the TOE and reboots. It will stop booting

up the TOE and enter a state in which the reason for the reboot can be determined. The System administrator can

check the failure and boot up the TOE. So long as the failures persist, the TOE will continue to reboot. This

functionally prevents any failure from causing an unauthorized information flow. There are no failures that

circumvent this protection.


None defined.


None defined.

of 90

2.7.4 Reliable Time Stamp (FPT_STM.1)


The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time. The TSS

provides a description of how the time is maintained and considered reliable in the context of each of the time

related functions.

Section 6.6 of the ST indicates that the TOE is a hardware appliance or a virtual appliance image installed on 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. The clock is used for audit record time stamps, measuring session

activity for termination, and for cryptographic operations based on time/date.


The evaluator examines the operational guidance to ensure it instructs the administrator how to set the time. If the

TOE supports the use of an NTP server, the operational guidance instructs how a communication path is established

between the TOE and the NTP server, and any configuration of the NTP client on the TOE to support this

communication.

Section 2.4.1 of the CCECG provides guidance on setting the system time by navigating to Device > Setup>

Management and editing the General Settings section.


Test 1: The evaluator uses the operational guide to set the time. The evaluator shall then use an available interface to

observe that the time was set correctly.

Test2: [conditional] If the TOE supports the use of an NTP server; the evaluator shall use the operational guidance

to configure the NTP client on the TOE, and set up a communication path with the NTP server. The evaluator will

observe that the NTP server has set the time to what is expected. If the TOE supports multiple protocols for

establishing a connection with the NTP server, the evaluator shall perform this test using each supported protocol

claimed in the operational guidance.

The evaluation team performed the tests specified in the assurance activity and verified that the instructions in the

guidance for setting the time were correct and the time was observed to be set correctly via the admin interface.

There are no claims made in the ST regarding use of an NTP server, therefore no testing of the TOE’s ability to

communicate with and synchronize it’s time to an NTP server was performed.



7.0.1-h4 for details of testing of the TOE’s time setting function.

2.7.5 TSF Testing (FPT_TST_EXT.1)


The evaluator shall examine the TSS to ensure that it details the self tests that are run by the TSF on start-up. This

description should include an outline of what the tests are actually doing (e.g., rather than saying “memory is

tested”, a description similar to “memory is tested by writing a value to each memory location and reading it back to

ensure it is identical to what was written” shall be used).The evaluator shall ensure that the TSS makes an argument

that the tests are sufficient to demonstrate that the TSF is operating correctly.

Section 6.6 of the ST states The TOE meets FIPS 140-2 requirements and therefore provides self-tests at start-up

(which are also on-demand tests available to administrators) to demonstrate the correct operation of: key error

detection, cryptographic algorithms, and RNG. Conditional self-tests are also run during the course of normal

operation. The self-tests verify the integrity of stored TSF executable code and TSF data. The TOE performs the

following Power-on self-tests:

AES Encrypt Known Answer Test

of 90

AES Decrypt Known Answer Test

CCM Known Answer Test

RSA Sign Known Answer Test

RSA Verify Known Answer Test

HMAC-SHA-1 Known Answer Test

HMAC-SHA-256 Known Answer Test

SHA-1 Known Answer Test




RNG Known Answer Test

Firmware Integrity Test – A 128 bit EDC (using MD5) is calculated on non-security related code. Security

related code is verified with HMAC-SHA-256. If the calculated result does not equal the previously

generated result, the software/firmware test shall fail.

A known-answer test involves operating the cryptographic algorithm on data for which the correct output is already

known and comparing the calculated output with the previously generated output (the known answer). If the

calculated output does not equal the known answer, the known-answer test shall fail.

The TOE performs the following Conditional Self-Tests within the cryptographic module when the conditions

specified for the tests occur:

1. Continuous Random Number Generator (RNG) test – performed on NDRNG and RNG, 128 bits

2. RSA Pairwise Consistency Test

3. Firmware Load Test – Verify RSA 2048 signature on firmware at time of load. . If the digital signature

cannot be verified, the test shall fail.

The RNG continuous random number generator test is performed on each RNG and tests for failure to a constant

value as follows:

1. If each call to a RNG produces blocks of n bits (where n > 15), the first n-bit block generated after

power-up, initialization, or reset shall not be used, but shall be saved for comparison with the next n-bit

block to be generated. Each subsequent generation of an n-bit block shall be compared with the previously

generated block. The test shall fail if any two compared n-bit blocks are equal.

2. If each call to a RNG produces fewer than 16 bits, the first n bits generated after power-up, initialization,

or reset (for some n > 15) shall not be used, but shall be saved for comparison with the next n generated

bits. Each subsequent generation of n bits shall be compared with the previously generated n bits. The test

fails if any two compared n-bit sequences are equal.

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.

of 90


The evaluator shall ensure that the operational guidance describes the possible errors that may result from such tests,

and actions the administrator should take in response; these possible errors shall correspond to those described in the

TSS.

Section 2.8.1 of the CCECG states that in the evaluated configuration, Cryptographic Administrators have the ability

to execute cryptographic self-tests by navigating to Device > Master Key and Diagnostics. The Cryptographic

Administrator clicks on “Run Cryptographic Algorithm Self Test” to run the FIPS 140-2 set of self-tests or “Run

Software Integrity Self Test” to run the TOE’s software integrity self-test. If a self-test fails, the TOE enters an error

state and outputs an error indicator. The TOE doesn’t perform any cryptographic operations while in the error state.

All data output from the TOE is inhibited when an error state exists.


None defined.

2.7.6 Extended: Trusted Update (FPT_TUD_EXT.1)


Updates to the TOE either have a hash associated with them, or are signed by an authorized source. If digital

signatures are used, the definition of an authorized source is contained in the TSS, along with a description of how

the certificates used by the update verification mechanism are contained on the device. The evaluator ensures this

information is contained in the TSS. The evaluator also ensures that the TSS (or the operational guidance) describes

how the candidate updates are obtained, the processing associated with verifying the digital signature or calculating

the hash of the updates, and the actions that take place for successful (hash or signature was verified) and

unsuccessful (hash or signature could not be verified) cases.

Section 6.6 states Authorized administrators may query the current software/firmware version of the TOE. Note

that the TOE is firmware and software. When updates are available from Palo Alto, an administrator can obtain and

install those updates from updates.paloaltonetworks.com. The secured connection to the Palo Alto server supports

TLS v1.0, TLS v1.1, TLS v1.2 and uses FIPS-approved algorithms. For an additional layer of protection, Palo Alto

Networks has chosen to sign (using RSA-2048) and encrypt (using AES-256) all content that is downloaded to the

firewall.

When the TOE update package and its corresponding digital signature is downloaded; the digital signature is

checked automatically by PAN-OS by verifying the signature using the public key (corresponding to the RSA key

used to create the signature). Certificates and keys are stored on the TOE’s file system. If the signature is verified,

the update is performed; otherwise the update is not performed. The administrator may also verify the download

manually by checking the hash value against the publically published hash on the support site. If the hashes match,

the update can be performed; however if they do not match, the update should not be performed.


The evaluator ensures that the operational guidance (or the TSS) describes how the candidate updates are obtained,

the processing associated with verifying the digital signature or calculating the hash of the updates, and the actions

that take place for successful (hash or signature was verified) and unsuccessful (hash or signature could not be

verified) cases.

Section 2.12 states that TOE administrators can obtain TOE updates from the Palo Alto Networks Support Site

https://suport.paloaltonetworks.com). If the TOE has Internet access from the management port, the list of available

updates can be displayed via the TOE’s Web Interface, from which the version to be installed can be selected and

downloaded. Otherwise, the desired update can be downloaded to another host and then uploaded to the TOE and

installed.

Software updates are digitally signed by Palo Alto. During the process of loading the update onto the TOE, and prior

to commencing installation, the TOE uses a built-in certificate to verify the digital signature on the software package

to confirm the integrity of the update package. If the digital signature is found to be valid, the TOE will advise the

https://suport.paloaltonetworks.com/

of 90

administrator the update is ready to be installed. If the digital signature is found to be invalid, the TOE displays an

error message stating the update is invalid and does not make it available for installation.


The evaluator shall perform the following tests:

Test 1: The evaluator performs the version verification activity to determine the current version of the product. The

evaluator obtains a legitimate update using procedures described in the operational guidance and verifies that it is

successfully installed on the TOE. Then, the evaluator performs a subset of other assurance activity tests to

demonstrate that the update functions as expected. After the update, the evaluator performs the version verification

activity again to verify the version correctly corresponds to that of the update.

Test 2: The evaluator performs the version verification activity to determine the current version of the product. The

evaluator obtains or produces an illegitimate update, and attempts to install it on the TOE. The evaluator verifies that

the TOE rejects the update.

The evaluation team performed the tests specified in the assurance activity and confirmed a legitimate update could

be installed successfully on the TOE and that an illegitimate update was rejected.



7.0.1-h4 for details of testing of successful installation of a legitimate update to the TOE as well as the rejection of

an illegitimate update.

2.8 TOE Access (FTA)

2.8.1 TSF-Initiated Termination (FTA_SSL.3)


None defined.


None defined.


The evaluator shall perform the following test:

Test 1: The evaluator follows the operational guidance to configure several different values for the inactivity time

period referenced in the component. For each period configured, the evaluator establishes a remote interactive

session with the TOE. The evaluator then observes that the session is terminated after the configured time period.

The evaluation team performed the test specified in the assurance activity and confirmed the TOE terminated a

remote interactive session after the configured periods of inactivity had elapsed.



7.0.1-h4 for details of testing of the TOE’s remote session timeout and termination function.

2.8.2 User-Initiated Termination (FTA_SSL.4)


None defined.

of 90


None defined.



Test 1: The evaluator initiates an interactive local session with the TOE. The evaluator then follows the operational

guidance to exit or log off the session and observes that the session has been terminated.

Test 2: The evaluator initiates an interactive remote session with the TOE. The evaluator then follows the

operational guidance to exit or log off the session and observes that the session has been terminated.

The evaluation team performed the tests specified in the assurance activity and confirmed the user was able to

terminate both an interactive local session at the TOE console and a remote interactive session over the SSH-

provided trusted path.



7.0.1-h4 for details of testing of the TOE’s logout function.

2.8.3 TSF-Initiated Session Locking (FTA_SSL_EXT.1)


None defined.


None defined.



Test 1: The evaluator follows the operational guidance to configure several different values for the inactivity time

period referenced in the component. For each period configured, the evaluator establishes a local interactive session

with the TOE. The evaluator then observes that the session is either locked or terminated after the configured time

period. If locking was selected from the component, the evaluator then ensures that re-authentication is needed when

trying to unlock the session.

The evaluation team performed the test specified in the assurance activity and confirmed the TOE terminated a local

interactive session after the configured period of inactivity had elapsed.



7.0.1-h4 for details of testing of the TOE’s local interactive session timeout and termination.

2.8.4 Default TOE Access Banners (FTA_TAB.1)


The evaluator shall check the TSS to ensure that it details each method of access (local and remote) available to the

administrator (e.g., serial port, SSH, HTTPS).

Section 6.5 states that the TOE provides a GUI management interface to support security management of the TOE.

The GUI is accessible via direct connection to the management port on the device, or remotely over HTTPS or

IPsec. Section 6.7 indicates that the TOE can be configured to display an informative banner that will appear prior

to authentication when accessing the TOE via either a direct or remote connection to the management port in order

of 90

to access the Web Interface (GUI). The TOE subsequently will enforce an administrator-defined inactivity timeout

value after which the inactive session will be terminated.


None defined.



Test 1: The evaluator follows the operational guidance to configure a notice and consent warning message. The

evaluator shall then, for each method of access specified in the TSS, establish a session with the TOE. The evaluator

shall verify that the notice and consent warning message is displayed in each instance.

The evaluation team performed the test specified in the assurance activity and confirmed the TOE displayed the

configured notice and consent warning message for both HTTPS/TLS and IPsec remote access.



7.0.1-h4 for details of testing of the TOE’s login banners.

2.9 Trusted Path/Channels (FTP)

2.9.1 Inter-TSF Trusted Channel (FTP_ITC.1)


The evaluator shall examine the TSS to determine that, for all communications with authorized IT entities identified

in the requirement, each communications mechanism is identified in terms of the allowed protocols for that IT

entity. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the

requirements in the ST.

Section 6.8 states that the following:

The TOE can be configured to export audit records to an external Syslog server using IPsec or TLS.

The TOE uses TLS to protect communications between itself and the UIA, and with the update server for

TOE updates, App-ID and threat prevention signature updates.

The TOE uses IPsec to protect communications between VPN Gateways/peers.

To support secure remote administration, the TOE includes an implementation of HTTPS and supports

IPsec. An authorized administrator can establish secure remote connections with the TOE using HTTP

over TLS or by establishing an IPsec connection.


The evaluator shall confirm that the operational guidance contains instructions for establishing the allowed protocols

with each authorized IT entity, and that it contains recovery instructions should a connection be unintentionally

broken.

As noted previously, Section 2.7.4 of the CCECG provides instructions for how to establish a TLS protected channel

and an IPsec protected channel between the TOE and a syslog server. Section 2.4 states that in order to manage a

Palo Alto Networks device in a way consistent with the evaluated configuration, device management should only be

performed via the web interface over HTTPS from a trusted network connection using an Internet Explorer (IE,

version 7 or later), Firefox (version 3.6 or later), Safari (version 5 or later), or Chrome (version 11 or later) browser.

Panorama, Telnet, and HTTP, and connections over untrusted networks are not supported and must not be enabled.

Refer to the “Device Management” section of [ADMIN] for more details on using the web interface.

Section 2.8.2 and 2.8.3 provide instructions on establishing an IPsec connection between two IPsec peers. It also

references pertinent sections in the Admin Guide that provide further details: The “VPNs” section of [ADMIN]

of 90

(sub-section “Set Up Site-to-Site VPN”, topic “Set Up an IKE Gateway”) provides guidance on configuring the

TOE as a VPN gateway. The “VPNs” section of [ADMIN] (sub-section “Set Up Site-to-Site VPN”, topic “Define

Cryptographic Profiles”) provides information on configuring IKE and IPsec cryptographic profiles for completing

IKE Phase 1 and Phase 2 negotiations, respectively.



Test 1: The evaluators shall ensure that communications using each protocol with each authorized IT entity is tested

during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring

that communication is successful.

Test 2: For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall follow the

operational guidance to ensure that in fact the communication channel can be initiated from the TOE.

Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data

are not sent in plaintext.

Test 4: The evaluators shall, for each protocol associated with each authorized IT entity tested during test 1, the

connection is physically interrupted. The evaluator shall ensure that when physical connectivity is restored,

communications are appropriately protected.

Further assurance activities are associated with the specific protocols.

The evaluation team performed the tests specified in the assurance activity and confirmed the TOE was able to

establish a trusted channel with an external syslog server using IPSec and TLS. Testing additionally demonstrated

the trusted channel was established with the appropriate cryptographic protocol and algorithms to ensure channel

data was not sent in plaintext. A test was also performed to physically interrupt the connection between the TOE and

the external syslog server and to verify that communications remained protected when connectivity was restored.



7.0.1-h4 for details of testing of testing of the TOE’s trusted channel.

2.9.2 Trusted Path (FTP_TRP.1)


The evaluator shall examine the TSS to determine that the methods of remote TOE administration are indicated,

along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the

TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the

requirements in the ST.

Section 6.8 states that to support secure remote administration, the TOE includes an implementation of HTTPS and

supports IPsec. An authorized administrator can establish secure remote connections with the TOE using HTTP over

TLS or by establishing an IPsec connection. To successfully establish an interactive administrative session, the

administrator must be able to provide acceptable user credentials (e.g., certificate; or user id, password, and role),

after which they will be able to access the GUI features. The TOE requires the use of the trusted path for initial

administrator authentication and all subsequent remote administrative actions.


The evaluator shall confirm that the operational guidance contains instructions for establishing the remote

administrative sessions for each supported method.

As noted previously, Section 2.7.4 of the CCECG provides instructions for how to establish a TLS protected channel

and an IPsec protected channel between the TOE and a syslog server. Section 2.4 states that in order to manage a

Palo Alto Networks device in a way consistent with the evaluated configuration, device management should only be

performed via the web interface over HTTPS from a trusted network connection using an Internet Explorer (IE,

version 7 or later), Firefox (version 3.6 or later), Safari (version 5 or later), or Chrome (version 11 or later) browser.

of 90

Panorama, Telnet, and HTTP, and connections over untrusted networks are not supported and must not be enabled.

Refer to the “Device Management” section of [ADMIN] for more details on using the web interface.

Section 2.8.2 and 2.8.3 provide instructions on establishing an IPsec connection between two IPsec peers. It also

references pertinent sections in the Admin Guide that provide further details: The “VPNs” section of [ADMIN]

(sub-section “Set Up Site-to-Site VPN”, topic “Set Up an IKE Gateway”) provides guidance on configuring the

TOE as a VPN gateway. The “VPNs” section of [ADMIN] (sub-section “Set Up Site-to-Site VPN”, topic “Define

Cryptographic Profiles”) provides information on configuring IKE and IPsec cryptographic profiles for completing

IKE Phase 1 and Phase 2 negotiations, respectively.



Test 1: The evaluators shall ensure that communications using each specified (in the operational guidance) remote

administration method is tested during the course of the evaluation, setting up the connections as described in the

operational guidance and ensuring that communication is successful.

Test 2: For each method of remote administration supported, the evaluator shall follow the operational guidance to

ensure that there is no available interface that can be used by a remote user to establish a remote administrative

sessions without invoking the trusted path.

Test 3: The evaluator shall ensure, for each method of remote administration, the channel data is not sent in

plaintext.

Further assurance activities are associated with the specific protocols.

The evaluation team performed the tests specified in the assurance activity and confirmed that the TOE can be

remotely administrated over IPsec or TLS/HTTPS. The evaluation team did not identify any interface that could be

used to establish a remote administrative session without invoking the trusted path. Testing additionally

demonstrated the trusted path was established with the appropriate cryptographic protocol and algorithms to ensure

channel data was not sent in plaintext.



7.0.1-h4 for details of testing of the TOE’s remote administration via HTTPS/TLS and IPsec function.

2.10 Stateful Traffic Filtering (FFW)

2.10.1 Stateful Traffic Filtering (FFW_RUL_EXT.1)

2.10.1.1 FFW_RUL_EXT.1.1


The evaluator shall verify that the TSS provide a description of the TOE’s initialization/startup process, which

clearly indicates where processing of network packets begins to take place, and provides a discussion that supports

the assertion that packets cannot flow during this process.

The evaluator shall verify that the TSS also include a narrative that identifies the components (e.g., active entity

such as a process or task) involved in processing the network packets and describe the safeguards that would prevent

packets flowing through the TOE without applying the ruleset in the event of a component failure. This could

include the failure of a component, such as a process being terminated, or a failure within a component, such as

memory buffers full and cannot process packets.

Section 6.10 states that the TOE groups interfaces into security zones. Each zone identifies one or more interfaces

on the TOE. Separate zones must be created for each type of interface (Layer 2, Layer 3, or virtual wire), and each

interface must be assigned to a zone before it can process traffic.

of 90

Security policies provide the firewall rule sets that specify whether to block or allow network connections, based on

the source and destination zones, addresses, and the application service (such as UDP port 67 or TCP port 80).

Security policy rules are processed in sequence, applying the first rule that matches the incoming traffic.

Security policies can be defined only between zones of the same type. However, the administrator can create a

VLAN interface for one or more VLANs and then apply a security policy between the VLAN interface zone and a

Layer 3 interface zone. This has the same effect as applying policies between the Layer 2 and Layer 3 interface

zones.

Each rule can be configured to generate a log record when the traffic matches the defined rule using the ‘policy-

>Security->options’ selection. The logging option can be configured to log at the start of a session, or at the end of a

session or both.

The TOE enforces the stateful traffic filtering rules based on the following subject and information security

attributes:














The TOE rejects requests for access or services when received on an interface that is not associated with the source

address from which the information flow is sourced (by administrator configured “Strict IP address check” in the

Zone Protection Profile”). Traffic is dropped if the source address of the incoming traffic correspond to the IP

address of an external broadcast network or loopback network; if the incoming traffic is received from the external

network but has a source address that correspond to the internal network; or if traffic is received from the internal

network but has a source address that correspond to the external network. The TOE rejects packets where the source

address is equal to the address of the network interface where the network packet was received. Access or service

requests are also rejected when the presumed source identity specifies a broadcast identity or a loopback identifier.

Security rules to block, permit or log are applied to multicast traffic. The TOE discards and logs strict source

routing, loose source routing, and record route packets. In addition, requests in which the information received

contains the set of host network identifiers by which information is to travel from the source subject to the

destination subject are rejected.

When the TOE receives a packet, it first determines if it represents a new connection or if it is part of an existing

session. If it is part of an existing session, the traffic is processed based on the parameters of the existing session. If

it is a new connection, the TOE retrieves the source and destination zones and performs an initial policy lookup. If a

policy is defined for the zone pair (i.e., source and destination zones) a session is created and packet processing

proceeds. By default, traffic between each pair of security zones is blocked until at least one rule is added to allow

traffic between the two zones. Sessions are not created for a new connection if there is no policy defined for the

zone pair; or if there is an initial deny rule for the application service (i.e. service-HTTP, service-https) matching the

traffic with no applications defined.

The TOE performs the following steps when processing traffic:

of 90

The traffic is passed through the Application Identification and Application Decoders to determine what type of

application is creating the session.

Once the application is known, the TOE performs a policy lookup with the following information:

The source/destination IP address

The source/destination security zone

The application and service (port and protocol)

The source user1 (when available)

o If a security policy is found, the policy rules are compared against the incoming traffic in sequence and

the first rule that matches the traffic is applied. If a policy rule matching all of the traffic attributes

listed above is not found, or if it is found and it specifies a deny action, then the packet is dropped (or

DISCARDed) and the session is deleted.

o If the application flow is allowed and no further security profiles are applied then it is forwarded (it is

allowed to BYPASS the tunnel).

o If the application is allowed and there are additional security profiles set, it will be sent to the stream

signature processor. The traffic matching the IPSec crypto Security profile would then flow through

the IPSec tunnel and be classified as “PROTECTED”.

If there is no SA that the IPsec can use to protect this traffic to the peer, IPsec uses IKE to

negotiate with the remote peer to set up the necessary IPsec SAs on behalf of the data flow.

The negotiation uses information specified in the IKE Network Profiles.

Security policies can also specify security profiles that may be used to protect against viruses, spyware, and other

threats after the connection is established.

Security Profiles

Each security policy can include specification of one or more security profiles, which provide additional protection

and control. Security profiles are configured and applied to firewall policy. Each security policy can specify one or

more of the following security profiles:

IPSec crypto Security profile

IKE Network profile

The TOE can remove existing traffic flows from the set of established traffic flows based on the session inactivity

timeout and completion of the expected information flow. The timeout period due to inactivity is administrator

configurable from 1 – 6044800 seconds.

The TOE implements an implicit “deny-all” rule to interfaces where a traffic filtering rule has been applied. If a

policy rule matching all of the traffic attributes described is not found, or if it is found and it specifies a deny action,

then the packet is dropped and the session is deleted.

The PAN-OS performs Strict IP Address check, reject, and is capable of logging network packets where the source

or destination address of the network packet is defined as being an address “reserved for future use” as specified in

RFC 5735 for IPv4. The administrator may also configure the TOE to reject and log network packets where the

source or destination address of the network packet is defined as a link-local address, an “unspecified address” or an

address “reserved for future definition and use” as specified in RFC 3513 for IPv6. The TOE rejects and is capable

of logging invalid and fragmented IP packets which cannot be re-assembled completely. The TOE detects all

malformed fragmented packets, and drops and/or logs them as configured in the Zone Protection Profiles.

IP fragments will be parsed, be reassembled by defragmentation process and fed back to parser starting with IP

header. A fragment may be discarded due to tear-drop attack (overlapping fragments).

The network traffic can go through the TOE only if the Policy Enforcement Module is fully functional and it is

enforcing all policies. During start-up and initialization, the TOE runs a series of system checks and the FIPS 140-2

1 Source user in policies is not within the scope of the evaluation.

of 90

power up self- tests to ensure the system is functioning correctly. If these tests run successfully, the TOE will bring

up the control plane and data-plane system modules. The Policy Enforcement Module (running on dataplane) uses

the policy configuration information created from the Management Server Module (running on the control plane).

The configuration information includes all of the policies required by the Policy Enforcement Module. Policies are

used to control information flow on the network. Only once the Policy Enforcement Module running on the data-

plane is up and running and the TOE’s system configuration is applied to enforce all security policies, can the TOE

pass the traffic.

The TOE implements the following safeguards that prevent packets from flowing through the TOE without applying

the ruleset in the event of a component failure. The traffic can go through the TOE only if the Policy Enforcement

Module is fully functional and enforcing all policies as described above. The Policy Enforcement Module can be

configured to stop traffic when the traffic or system logs are full. Whenever a failure occurs within the TOE that

results in the TOE ceasing operation, the TOE securely disables its interfaces to prevent the unintentional flow of

any information to or from the TOE and reloads.

The Policy Enforcement Module uses the policy configuration information created from the Management Server

Module. The configuration information includes all of the policies required by the Policy Enforcement Module.

Policies are used to control information flow on the network.


The operational guidance associated with this requirement is assessed in the subsequent test assurance activities.


Test 1: The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized.

A steady flow of network packets that would otherwise be denied by the ruleset should be directed at the TOE’s

interfaces, with packet sniffers listening to see if any network traffic is allowed through.

Note: The remaining testing associated with application of the ruleset is addressed in the subsequent test assurance

activities.

The evaluation team performed the tests specified in the assurance activity and confirmed that no packets made it

through the firewall during initialization and the packets were appropriately logged as dropped.



7.0.1-h4 for details of testing of the TOE’s network traffic handling.

2.10.1.5 FFW_RUL_EXT.1.2


The evaluator shall verify that the TSS indicates that the following protocols are supported:

RFC 792 (ICMPv4)

RFC 4443 (ICMPv6)

RFC 791 (IPv4)

RFC 2460 (IPv6)

RFC 793 (TCP)

RFC 768 (UDP)

The evaluator shall verify that the TSS describes how conformance with the identified RFCs has been determined by

the TOE developer (e.g., third party interoperability testing, protocol compliance testing).

Section 6.10 states that an authorized administrator may configure the TOE to apply stateful traffic filtering rules of

permit, deny, and log on the following protocols:

of 90







Conformance with the RFC 792 (ICMPv4), RFC 4443 (ICMPv6), RFC 791(IPv4), RFC 2460 (IPv6), RFC 793

(TCP), RFC 768 (UDP) protocols is verified by Palo Alto through regular quality assurance, regression, and

interoperability testing.


The evaluator shall verify that the operational guidance indicates that the following protocols are supported:

RFC 792 (ICMPv4)

RFC 4443 (ICMPv6)

RFC 791 (IPv4)

RFC 2460 (IPv6)

RFC 793 (TCP)

RFC 768 (UDP)

If the guidance describes other protocols that are processed by the TOE, it should be made clear that those protocols

were not considered as part of the TOE evaluation.




o Type

o Code


o Type

o Code


o Source address




o Source address




o Source port

of 90

o Destination port


o Source port

o Destination port.



2.10.1.9 FFW_RUL_EXT.1.3, FFW_RUL_EXT.1.4, FFW_RUL_EXT.1.5


The evaluator shall verify that the TSS describes a stateful packet filtering policy and the following attributes are

identified as being configurable within stateful traffic filtering rules for the associated protocols:

ICMPv4

Type

Code

ICMPv6

Type

Code

IPv4

Source address

Destination Address

Transport Layer Protocol

IPv6

Source address

Destination Address


TCP

Source Port

Destination Port

UDP

Source Port

Destination Port

The evaluator shall verify that each rule can identify the following actions: permit, deny, and log.

The evaluator shall verify that the TSS identifies all interface types subject to the stateful packet filtering policy and

explains how rules are associated with distinct network interfaces. Where interfaces can be grouped into a common

interface type (e.g., where the same internal logical path is used, perhaps where a common device driver is used)

they can be treated collectively as a distinct network interface.









of 90








The TOE keeps state about connections or pseudo-connections and uses the information to permit or deny

information flow. The TOE permits information flow between two subjects (i.e., from the physical interface on

which network traffic entered to the physical interface determined by the destination address in the network packet)

only where a security policy is defined between the source and destination zones that includes a rule that grants

permission, based on the information security attributes listed above and the corresponding settings in the policy

rule.

A security policy rule includes the following attributes against which network packets can be compared:

Source Zone, Destination Zone—zones must be of the same type (Layer 2, Layer 3, or Virtual Wire).

Multiple zones can be specified in a single rule to simplify management

Source Address, Destination Address—the IPv4 or IPv6 addresses for which the rule applies. Addresses

must first be defined by the administrator, who specifies a name for the address and the actual IPv4 or IPv6

addresses to be associated with that name. Addresses can be specified as a single address, an address with a

mask, or an address range. Addresses can also be combined into address groups to simplify management

Service—specifies services to limit applications to specific protocols and port numbers.

A security policy rule also includes the following attributes that determine what the TOE does with the network

packet:

Action—can be ‘allow’ or ‘deny’

Profiles—specifies any checking to be performed by the security profiles described above (i.e., antivirus,

anti-spyware, vulnerability protection, data filtering, file blocking)

Options—specifies the following additional processing options for network packets matching the rule:

o Log Setting—generate log entries in the local traffic log

o Schedule—limits the days and times when the rule is in effect (e.g., an ‘allow’ rule might be active

only during normal business hours)

o QoS Marking—change the Quality of Service (QoS) marking on packets matching the rule

The TOE groups interfaces into security zones. Each zone identifies one or more interfaces on the TOE. Separate

zones must be created for each type of interface (Layer 2, Layer 3, or virtual wire), and each interface must be

assigned to a zone before it can process traffic.

Each rule in a security policy can be configured to generate a log record when the traffic matches the defined rule

using the ‘policy->Security->options’ selection.


The evaluators shall verify that the operational guidance identifies the following attributes as being configurable

within stateful traffic filtering rules for the associated protocols:

ICMPv4

Type

Code

ICMPv6

Type

of 90

Code

IPv4

Source address

Destination Address


IPv6

Source address

Destination Address


TCP

Source Port

Destination Port

UDP

Source Port

Destination Port

The evaluator shall verify that the operational guidance indicates that each rule can identify the following actions:

permit, deny, and log.

The evaluator shall verify that the operational guidance explains how rules are associated with distinct network

interfaces.

The evaluator shall verify that the operational guidance explains how to determine the interface type of a distinct

network interface (e.g., how to determine the device driver for a distinct network interface).

Section 2.9 of the CCECG states that Palo Alto Networks firewalls can be configured to perform stateful traffic



o Type

o Code


o Type

o Code


o Source address




o Source address




o Source port

o Destination port


o Source port

of 90

o Destination port.

The Palo Alto Networks firewalls group interfaces into security zones. Each zone identifies one or more interfaces

on the firewall, and each interface must be assigned to a zone before it can process traffic. On the Palo Alto

Networks firewall, security policies are used to determine whether to block or allow a session, based on traffic

attributes such as the source and destination security zone, the source and destination IP address, and the source and

destination port (service).











Refer to the “Policy” section, “Security Policy” sub-section of [ADMIN] for detailed guidance on configuring

security policies that define how stateful traffic filtering is applied to network packets received by the firewall.



Test 1: The evaluator shall use the instructions in the operational guidance to test that stateful packet filter firewall

rules can be created that permit, deny, and log packets for each of the following attributes:

ICMPv4

Type

Code

ICMPv6

Type

Code

IPv4

Source address

Destination Address


IPv6

Source address

Destination Address


TCP

Source Port

Destination Port

UDP

Source Port

Destination Port

Test 2: Repeat the test assurance activity above to ensure that stateful traffic filtering rules can be defined for each

distinct network interface type supported by the TOE.

Note that these test activities should be performed in conjunction with those of FFW_RUL_EXT.1.10 where the

effectiveness of the rules is tested. The test activities for FFW_RUL_EXT.1.10 define the protocol/attribute

combinations required to be tested. If those combinations are configured manually, that will fulfill the objective of

these test activities, but if those combinations are configured otherwise (e.g., using automation), these test activities

may be necessary in order to ensure the guidance is correct and the full range of configurations can be achieved by a

TOE administrator.

of 90

The evaluation team performed the tests specified in the assurance activity and confirmed that packet filter rules can

be created that permit, deny, and log packets for the attributes listed above.




2.10.1.13 FFW_RUL_EXT.1.6


The evaluator shall verify that the TSS identifies the protocols that support stateful session handling. The TSS shall

identify TCP, UDP, and ICMP if selected by the ST author.

The evaluator shall verify that the TSS describes how stateful sessions are established (including handshake

processing) and maintained.

The evaluator shall verify that for TCP, the TSS identifies and describes the use of the following attributes in session

determination: source and destination addresses, source and destination ports, sequence number, and individual

flags.

The evaluator shall verify that for UDP, the TSS identifies and describes the following attributes in session

determination: source and destination addresses, source and destination ports.

The evaluator shall verify that for ICMP (if selected), the TSS identifies and describes the following attributes in

session determination: source and destination addresses, other attributes chosen in FFW_RUL_EXT.1.6.

The evaluator shall verify that the TSS describes how established stateful sessions are removed. The TSS shall

describe how connections are removed for each protocol based on normal completion and/or timeout conditions.

The TSS shall also indicate when session removal becomes effective (e.g., before the next packet that might match

the session is processed).

Section 6.10 of the ST states that an authorized administrator may configure the TOE to apply stateful traffic

filtering rules of permit, deny, and log on the following protocols:


















of 90





Section 6.10 states that when the TOE receives a packet, it first determines if it represents a new connection or if it

is part of an existing session. If it is part of an existing session, the traffic is processed based on the parameters of

the existing session. If it is a new connection, the TOE retrieves the source and destination zones and performs an

initial policy lookup. If a policy is defined for the zone pair (i.e., source and destination zones) a session is created

and packet processing proceeds. By default, traffic between each pair of security zones is blocked until at least one

rule is added to allow traffic between the two zones. Sessions are not created for a new connection if there is no

policy defined for the zone pair; or if there is an initial deny rule for the application service (i.e. service-HTTP,

service-https) matching the traffic with no applications defined.








The source user (when available)



listed above is not found, or if it is found and it specifies a deny action, then the packet is dropped and

the session is deleted.

o If the application flow is allowed and no further security profiles are applied then it is forwarded.


signature processor.

Prior to matching packets with the policy rules, fragmented packets are reassembled. Upon receiving a packet that

is not associated with an established session (a packet with the SYN flag set without a corresponding ACK flag

being set), the packet will be matched to the security rules to make a determination of whether to allow or deny the

information flow. If the packet is associated with an established session (packet sequence number, acknowledgment

number, and flags match an existing session record), the information flow is permitted.

The device provides a setting such that the Security Administrator can enable or disable ICMP and SNMP for all

users. The TOE rejects requests for access or services when received on an interface that is not associated with the

source address from which the information flow is sourced. Access or service requests are also rejected when the

presumed source identity specifies a broadcast identity or a loopback identifier. Security rules to block, permit or

log are applied to multicast traffic. The TOE discards and logs strict source routing, loose source routing, and

record route packets. In addition, requests in which the information received contains the set of host network

identifiers by which information is to travel from the source subject to the destination subject are rejected.

The TOE can remove existing traffic flows from the set of established traffic flows based on the session inactivity

timeout and completion of the expected information flow. The timeout period due to inactivity is administrator

configurable from 1 – 6044800 seconds. Session removal becomes effective before the next packet that might match

the session is processed.

The TOE implements an implicit “deny-all” rule to interfaces where a traffic filtering rule has been applied. If a

policy rule matching all of the traffic attributes described is not found, or if it is found and it specifies a deny action,

then the packet is dropped and the session is deleted. Session removal becomes effective before the next packet that

might match the session is processed.

of 90

The TOE supports the Transmission Control Protocol (TCP) (RFC 793) which performs a handshake during session

setup to initiate and acknowledge a session. After the data is transferred, the session is closed in an orderly manner,

where each side transmits a FIN packet and acknowledges it with an ACK packet. The handshake that initiates the

TCP session is often a three-way handshake (an exchange of three messages) between the initiator and the listener,

or it could be a variation, such as a four-way or five-way split handshake or a simultaneous open. The TOE supports

the TCP Split Handshake Drop feature, which can prevent TCP Split Handshake Session Establishment.

The TOE uses a patented technology called App-ID to identify and control applications based on knowing exactly

what the application is by evaluating the content of the traffic. This unique approach to traffic classification allows

the TOE to provide visibility and control of the actual application, besides the ports or protocols that are allowed.

App-ID is session "state" aware which allows the TOE to allow or block subsequent packets in a session. The TOE

maintains a session “state” table for all sessions as part of the traffic processing layer of the device. If a packet

doesn’t match an existing session, then it is forced through the policy lookup process to determine if it should be

allowed or not. If allowed, a session will be created. The application decoder builds the state table based on the

relevant RFCs. The TOE creates dynamic rules, maintaining the session states to support processing the FTP

network protocol traffic for TCP data sessions in accordance with the FTP protocol as specified in RFC 959 using

the FTP App-ID. Logging can be enabled in the security policy rule configured to control the FTP traffic.


The evaluator shall verify that the operational guidance describes stateful session behaviors. For example, a TOE

might not log packets that are permitted as part of an existing session.

Section 2.7.3 of the CCECG references the “Policy” section of [ADMIN], the TOE uses policies to enforce rules and

specify actions to be taken by the TOE. Security policy rules are used to determine whether to block or allow a


address, the application, user, and the service. When an administrator creates a security policy rule, the administrator

can specify if the TOE will log traffic matching the rule.

Section 2.9 of the CCECG states that the Palo Alto Networks firewalls group interfaces into security zones. Each

zone identifies one or more interfaces on the firewall, and each interface must be assigned to a zone before it can

process traffic. On the Palo Alto Networks firewall, security policies are used to determine whether to block or

allow a session, based on traffic attributes such as the source and destination security zone, the source and

destination IP address, and the source and destination port (service).














Test 1: The evaluator shall configure the TOE to permit and log TCP traffic. The evaluator shall initiate a TCP

session. While the TCP session is being established, the evaluator shall introduce session establishment packets with

incorrect flags to determine that the altered traffic is not accepted as part of the session (i.e., a log event is generated

to show the ruleset was applied). After a TCP session is successfully established, the evaluator shall alter each of the

session determining attributes (source and destination addresses, source and destination ports, sequence number,

flags) one at a time in order to verify that the altered packets are not accepted as part of the established session.

of 90

Test 2: The evaluator shall terminate the TCP session established per Test 1 as described in the TSS. The evaluator

shall then immediately send a packet matching the former session definition in order to ensure it is not forwarded

through the TOE without being subject to the ruleset.

Test 3: The evaluator shall expire (i.e., reach timeout) the TCP session established per Test 1 as described in the

TSS. The evaluator shall then send a packet matching the former session in order to ensure it is not forwarded


Test 4: The evaluator shall configure the TOE to permit and log UDP traffic. The evaluator shall establish a UDP

session. Once a UDP session is established, the evaluator shall alter each of the session determining attributes

(source and destination addresses, source and destination ports) one at a time in order to verify that the altered

packets are not accepted as part of the established session.

Test 5: The evaluator shall expire (i.e., reach timeout) the UDP session established per Test 4 as described in the



Test 6: If ICMP is selected, the evaluator shall configure the TOE to permit and log ICMP traffic. The evaluator

shall establish a session for ICMP as defined in the TSS. Once an ICMP session is established, the evaluator shall

alter each of the session determining attributes (source and destination addresses, other attributes chosen in

FFW_RUL_EXT.1.6) one at a time in order to verify that the altered packets are not accepted as part of the

established session.

Test 7: If applicable, the evaluator shall terminate the ICMP session established per Test 6 as described in the TSS.

The evaluator shall then immediately send a packet matching the former session definition in order to ensure it is not

forwarded through the TOE without being subject to the ruleset.

Test 8: The evaluator shall expire (i.e., reach timeout) the ICMP session established per Test 6 as described in the



The evaluation team performed the tests specified in the assurance activity and confirmed that the traffic filter

firewall rules operate as expected in each test scenario.



7.0.1-h4 for details of testing of the TOE’s traffic filter firewall.

2.10.1.17 FFW_RUL_EXT.1.7


The evaluator shall verify that the TSS identifies the protocols that can cause the automatic creation of dynamic

packet filtering rules. In some cases rather than creating dynamic rules, the TOE might establish stateful sessions to

support some identified protocol behaviors. The TSS shall identify FTP and optionally other protocols.

The evaluator shall verify that the TSS explains the dynamic nature of session establishment and removal. The TSS

also shall explain any logging ramifications.

The evaluator shall verify that for FTP, the TSS explains how FTP data sessions will be allowed through the TOE in

response to FTP control sessions.

The evaluator shall verify that for each of the other protocols selected, the TSS explains the dynamic nature of

session establishment and removal specific to the protocol.







of 90



The TOE uses a patented technology called App-ID to identify and control applications based on knowing exactly

what the application is by evaluating the content of the traffic. This unique approach to traffic classification allows

the TOE to provide visibility and control of the actual application, besides the ports or protocols that are allowed.

App-ID is session "state" aware which allows the TOE to allow or block subsequent packets in a session. The TOE

maintains a session “state” table for all sessions as part of the traffic processing layer of the device. If a packet

doesn’t match an existing session, then it is forced through the policy lookup process to determine if it should be

allowed or not. If allowed, a session will be created. The logging can be enabled as well.

The application decoder builds the state table based on the relevant RFCs.

The TOE creates dynamic rules, maintaining the session states to support processing the FTP network protocol

traffic for TCP data sessions in accordance with the FTP protocol as specified in RFC 959 using the FTP App-ID.

Logging can be enabled in the security policy rule configured to control the FTP traffic.


The evaluator shall verify that the operational guidance describes dynamic session establishment capabilities.

The evaluator shall verify that the operational guidance describes the logging of dynamic sessions consistent with

the TSS.

Section 6.10 of the ST states that the TOE uses a patented technology called App-ID to identify and control

applications based on knowing exactly what the application is by evaluating the content of the traffic. This unique

approach to traffic classification allows the TOE to provide visibility and control of the actual application, besides

the ports or protocols that are allowed. App-ID is session "state" aware which allows the TOE to allow or block

subsequent packets in a session. The TOE maintains a session “state” table for all sessions as part of the traffic

processing layer of the device. If a packet doesn’t match an existing session, then it is forced through the policy

lookup process to determine if it should be allowed or not. If allowed, a session will be created. The logging can be

enabled as well. The application decoder builds the state table based on the relevant RFCs.

The TOE creates dynamic rules, maintaining the session states to support processing the FTP network protocol

traffic for TCP data sessions in accordance with the FTP protocol as specified in RFC 959 using the FTP App-ID.

Logging can be enabled in the security policy rule configured to control the FTP traffic.


Test 1: The evaluator shall define stateful traffic filtering rules to permit and log an FTP session and deny and log

TCP ports above 1024. Subsequently, the evaluator shall establish an FTP session in order to ensure that it succeeds.

The evaluator shall examine the generated logs to verify they are consistent with the operational guidance.

Test 2: Continuing from Test 1, the evaluator shall determine (e.g., using a packet sniffer) which port above 1024 is

being used by the FTP data session, terminate the FTP session, and then verify that TCP packets cannot be sent

through the TOE using the same source and destination addresses and ports.

Test 3: For each additionally supported protocol, the evaluator shall repeat the procedure above for the protocol. In

each case the evaluator must use the applicable RFC or standard in order to determine what range of ports to block

in order to ensure the dynamic rules are created and effective.





7.0.1-h4 for details of testing of the TOE’s traffic filter firewall rules.

of 90

2.10.1.21 FFW_RUL_EXT.1.8


The evaluator shall verify that the TSS identifies the following as packets that will be automatically rejected and are

capable of being logged:

1. Packets which are invalid fragments, including a description of what constitutes an invalid fragment

2. Fragments that cannot be completely re-assembled

3. Packets where the source address is equal to the address of the network interface where the network packet was

received

4. Packets where the source address does not belong to the networks associated with the network interface where the

network packet was received, including a description of how the TOE determines whether a source address belongs

to a network associated with a given network interface

5. Packets where the source address is defined as being on a broadcast network

6. Packets where the source address is defined as being on a multicast network

7. Packets where the source address is defined as being a loopback address

8. Packets where the source address is defined as being a reserved address as specified in RFC 1918 for IPv4, and

RFC 3513 for IPv6

9. Packets where the source or destination address of the network packet is a link-local address

10. Packets where the source or destination address of the network packet is defined as being an address “reserved

for future use” as specified in RFC 5735 for IPv4

11. Packets where the source or destination address of the network packet is defined as an “unspecified address” or

an address “reserved for future definition and use” as specified in RFC 3513 for IPv6

12. Packets with the IP options: Loose Source Routing, Strict Source Routing, or Record Route specified

13. Other packets defined in FFW_RUL_EXT.1.8.

Section 6.10 states that the device provides a setting such that the Security Administrator can enable or disable

ICMP and SNMP for all users. The TOE rejects requests for access or services when received on an interface that

is not associated with the source address from which the information flow is sourced. Access or service requests are

also rejected when the presumed source identity specifies a broadcast identity or a loopback identifier. Security

rules to block, permit or log are applied to multicast traffic. The TOE discards and logs strict source routing, loose

source routing, and record route packets. In addition, requests in which the information received contains the set of

host network identifiers by which information is to travel from the source subject to the destination subject are

rejected.

Section 6.10 states that the PAN-OS performs Strict IP Address check, reject, and is capable of logging network

packets where the source or destination address of the network packet is defined as being an address “reserved for

future use” as specified in RFC 5735 for IPv4. The administrator may also configure the TOE to reject and log

network packets where the source or destination address of the network packet is defined as a link-local address, an

“unspecified address” or an address “reserved for future definition and use” as specified in RFC 3513 for IPv6. The

TOE rejects and is capable of logging invalid and fragmented IP packets which cannot be re-assembled completely.

The TOE detects all invalid fragmented packets, such as a fragmented packet that partially overlaps a previously

received fragment, or a fragmented packet with invalid length, and drops and/or logs them as configured in the Zone

Protection Profiles. Optionally, the TOE can be configured to consider any fragmented packet as invalid and to drop

and log them. IP fragments will be parsed, be reassembled by defragmentation process and fed back to parser

starting with IP header. A fragment may be discarded due to tear-drop attack (overlapping fragments).

The TOE rejects requests for access or services when received on an interface that is not associated with the source

address from which the information flow is sourced (by administrator configured “Strict IP address check” in the

Zone Protection Profile”). Traffic is dropped if the source address of the incoming traffic correspond to the IP

address of an external broadcast network or loopback network; if the incoming traffic is received from the external

of 90

network but has a source address that correspond to the internal network; or if traffic is received from the internal

network but has a source address that correspond to the external network. The TOE rejects packets where the source

address is equal to the address of the network interface where the network packet was received. Access or service

requests are also rejected when the presumed source identity specifies a broadcast identity or a loopback identifier.

Security rules to block, permit or log are applied to multicast traffic. The TOE rejects and logs packets where the

source address of the network packet is defined as being on a multicast network. The TOE discards and logs strict

source routing, loose source routing, and record route packets. In addition, requests in which the information

received contains the set of host network identifiers by which information is to travel from the source subject to the

destination subject are rejected.


The evaluator shall verify that the operational guidance describes packets that are discarded and potentially logged

by default. If applicable protocols are identified, their descriptions need to be consistent with the TSS. If logging is

configurable, the evaluator shall verify that applicable instructions are provided to configure auditing of

automatically rejected packets.

Section 2.7.3 of the CCECG references the “Policy” section of [ADMIN], the TOE uses policies to enforce rules and

specify actions to be taken by the TOE. Security policy rules are used to determine whether to block or allow a


address, the application, user, and the service. When an administrator creates a security policy rule, the administrator

can specify if the TOE will log traffic matching the rule. Section 2.7.3 provides instructions for configuring the

security policies to log applicable network traffic.


Test 1: The evaluator shall test each of the conditions for automatic packet rejection in turn. In each case, the TOE

should be configured to allow all network traffic and the evaluator shall generate a packet or packet fragment that is

to be rejected. The evaluator shall use packet captures to ensure that the unallowable packet or packet fragment is

not passed through the TOE.

Test 2: For each of the cases above, the evaluator shall use any applicable guidance to enable rejected packet

logging. In each case above, the evaluator shall ensure that the rejected packet or packet fragment was appropriately

logged.

The evaluation team performed the tests specified in the assurance activity and confirmed that automatic packet

rejection operates as expected.



7.0.1-h4 for details of testing of the TOE’s packet rejection rules.

2.10.1.25 FFW_RUL_EXT.1.9


The evaluator shall verify that the TSS describes the algorithm applied to incoming packets, including the

processing of default rules, determination of whether a packet is part of an established session, and application of

administrator defined and ordered ruleset.

Section 6.9 of the ST provides some information regarding the TOE’s packet processing algorithm. This section

states all traffic passing through the firewall is matched against a session and each session is matched against a

security policy. When a session match occurs, the security policy is applied to bi-directional traffic (client to server

and server to client) in that session. For traffic that doesn’t match any defined rules, the default rules apply. The

default rules—displayed at the bottom of the security rulebase—are predefined to allow all intrazone (within the

zone) traffic and deny all interzone (between zones) traffic. Although these rules are part of the pre-defined

configuration and are read-only by default, you can override them and change a limited number of settings,

including the tags, action (allow or deny), log settings, and security profiles.

of 90






Section 6.10 confirms that security policy rules are processed in sequence, applying the first rule that matches the

incoming traffic.

Section 6.10 states that prior to matching packets with the policy rules, fragmented packets are reassembled. Upon

receiving a packet that is not associated with an established session (a packet with the SYN flag set without a

corresponding ACK flag being set), the packet will be matched to the security rules to make a determination of

whether to allow or deny the information flow. If the packet is associated with an established session (packet

sequence number, acknowledgment number, and flags match an existing session record), the information flow is

permitted.
















The source user2 (when available)



listed above is not found, or if it is found and it specifies a deny action, then the packet is dropped and

the session is deleted.

o If the application flow is allowed and no further security profiles are applied then it is forwarded.


signature processor.


The evaluator shall verify that the operational guidance describes how the order of stateful traffic filtering rules is

determined and provides the necessary instructions so that an administrator can configure the order of rule

processing.

Section 2.9 of the CCECG states that security policies are evaluated left to right and from top to bottom. A packet is




of 90

enabled for that rule. The logging options are configurable for each rule, and can for example be configured to log at

the start of a session instead of, or in addition to, logging at the end of a session.




Test 1: The evaluator shall devise two equal stateful traffic filtering rules with alternate operations – permit and

deny. The rules should then be deployed in two distinct orders and in each case the evaluator shall ensure that the

first rule is enforced in both cases by generating applicable packets and using packet capture and logs for

confirmation.

Test 2: The evaluator shall repeat the procedure above, except that the two rules should be devised where one is a







7.0.1-h4 for details of testing of the TOE’s traffic filter firewall rules.

2.10.1.29 FFW_RUL_EXT.1.10


The evaluator shall verify that the TSS describes the process for applying stateful traffic filtering rules and also that

the behavior (either by default, or as configured by the administrator) is to deny packets when there is no rule match

unless another required conditions allows the network traffic (i.e., FFW_RUL_EXT.1.6 or FFW_RUL_EXT.1.7).

Section 6.9 provides some information regarding the TOE’s packet processing algorithm. This section states all

traffic passing through the firewall is matched against a session and each session is matched against a security



rules—displayed at the bottom of the security rulebase—are predefined to allow all intrazone (within the zone)

traffic and deny all interzone (between zones) traffic. Although these rules are part of the pre-defined configuration

and are read-only by default, you can override them and change a limited number of settings, including the tags,

action (allow or deny), log settings, and security profiles.

Section 6.10 indicates that, by default, traffic between each pair of security zones is blocked until at least one rule is

added to allow traffic between the two zones. Sessions are not created for a new connection if there is no policy

defined for the zone pair; or if there is an initial deny rule for the application service (i.e. service-HTTP, service-

https) matching the traffic with no applications defined. If a security policy is found, the policy rules are compared

against the incoming traffic in sequence and the first rule that matches the traffic is applied. If a policy rule

matching all of the traffic attributes listed above is not found, or if it is found and it specifies a deny action, then the

packet is dropped and the session is deleted.


The evaluator shall verify that the operational guidance describes the behavior if no rules or special conditions apply

to the network traffic. If the behavior is configurable, the evaluator shall verify that the operational guidance

provides the appropriate instructions to configure the behavior to deny packets with no matching rules.

Section 2.9 of the CCECG states that all traffic passing through the firewall is matched against a session and each

session is matched against a security policy. When a session match occurs, the security policy is applied to bi-

directional traffic (client to server and server to client) in that session. For traffic that doesn’t match any defined

rules, the default rules apply. The default rules allow all intrazone (within the zone) traffic and deny all interzone

(between zones) traffic.

of 90


Test 1: The evaluator shall test each of the conditions for automatic packet rejection in turn. In each case, the TOE

should be configured to allow all network traffic and the evaluator shall generate a packet or packet fragment that is

to be rejected. The evaluator shall use packet captures to ensure that the unallowable packet or packet fragment is

not passed through the TOE. Test 2: For each of the cases above, the evaluator shall use any applicable guidance to

enable rejected packet logging. In each case above, the evaluator shall ensure that the rejected packet or packet

fragment was appropriately logged.

Test 1: The evaluator shall configure the TOE to permit and log each defined ICMPv4 Type and Code (see table 4-2

Defined Protocol-specific Attributes). The evaluator will generate packets matching each defined ICMPv4 Type and

Code in order to ensure that they are permitted (i.e., by capturing the packets after passing through the TOE) and

logged.

Test 2: The evaluator shall configure the TOE to deny and log each defined ICMPv4 Type and Code (see table 4-2


Code in order to ensure that they are denied (i.e., by capturing no applicable packets passing through the TOE) and

logged.

Test 3: The evaluator shall configure the TOE with no ICMPv4 rules. The evaluator will generate packets matching

each defined ICMPv4 Type and Code in order to ensure that they are denied (i.e., by capturing no applicable packets

passing through the TOE).

Test 4: The evaluator shall configure the TOE to permit and log each defined ICMPv6 Type and Code (see table 4-2


Code in order to ensure that they are permitted (i.e., by capturing the packets after passing through the TOE) and

logged.

Test 5: The evaluator shall configure the TOE to deny and log each defined ICMPv6 Type and Code (see table 4-2


Code in order to ensure that they are denied (i.e., by capturing no applicable packets passing through the TOE) and

logged.

Test 6: The evaluator shall configure the TOE with no ICMPv6 rules. The evaluator will generate packets matching

each defined ICMPv6 Type and Code in order to ensure that they are denied (i.e., by capturing no applicable packets

passing through the TOE).


table 4-2 Defined Protocol-specific Attributes) in conjunction with a specific source address and specific destination






Transport Layer Protocol (see table 4-2 Defined Protocol-specific Attributes) in conjunction with a specific source






of 90






Attributes) in conjunction with different (than those permitted above) combinations of a specific source address and













Transport Layer Protocol (see table 4-2 Defined Protocol-specific Attributes) in conjunction with a specific source











Attributes) in conjunction with different (than those permitted above) combinations of a specific source address and






Test 13: The evaluator shall configure the TOE to permit and log TCP using a selected source port, a selected

destination port, and a selected source and destination port combination. The evaluator shall generate packets

matching the configured source and destination TCP ports in order to ensure that they are permitted (i.e., by


Test 14: The evaluator shall configure the TOE to deny and log TCP using a selected source port, a selected


matching the configured source and destination TCP ports in order to ensure that they are denied (i.e., by capturing

no applicable packets passing through the TOE) and logged.

Test 15: The evaluator shall configure the TOE to permit and log UDP using a selected source port, a selected


matching the configured source and destination UDP ports in order to ensure that they are permitted (i.e., by


Test 16: The evaluator shall configure the TOE to deny and log UDP using a selected source port, a selected


matching the configured source and destination UDP ports in order to ensure that they are denied (i.e., by capturing

no applicable packets passing through the TOE) and logged.

of 90





7.0.1-h4 for details of testing of the TOE’s traffic filter firewall.

of 90

3. Security Assurance Requirement Assurance Activities

3.1 Development (ADV)

3.1.1 Basic Functional Specification (ADV_FSP.1)


There are no specific assurance activities associated with these SARs. The functional specification documentation is

provided to support the evaluation activities described in Section 4.2, and other activities described for AGD, ATE,

and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed

by virtue of the other assurance activities being performed; if the evaluator is unable to perform an activity because

there is insufficient interface information, then an adequate functional specification has not been provided.

3.2 Guidance Documents (AGD)

3.2.1 Operational User Guidance (AGD_OPE.1)


Some of the contents of the operational guidance will be verified by the assurance activities in Section 4.2 and

evaluation of the TOE according to the CEM. The following additional information is also required.

The operational guidance shall at a minimum list the processes running (or that could run) on the TOE in its

evaluated configuration during its operation that are capable of processing data received on the network interfaces

(there are likely more than one of these, and this is not limited to the process that "listens" on the network interface).

It is acceptable to list all processes running (or that could run) on the TOE in its evaluated configuration instead of

attempting to determine just those that process the network data. For each process listed, the administrative guidance

will contain a short (e.g., one- or two-line) description of the process' function, and the privilege with which the

service runs. "Privilege" includes the hardware privilege level (e.g., ring 0, ring 1), any software privileges

specifically associated with the process, and the privileges associated with the user role the process runs as or under.

Section 3 of the CCECG provides the list of processes running on the TOE in its evaluated configuration. The TOE

is a Linux-based network operating system. Most IP packets are processed in the kernel. Some protocol packets are

processed in user mode by protocol daemons. Most processes are owned by non-privileged users and run in non-

privileged mode.

The following tables list the daemons/processes in user mode that are capable of processing data received on

network interfaces. The first table lists the processes running on the Management Plane, while the second table lists

the processes running on the Data Plane.

Management Plane Processes

Process Name Description

appweb Web services

authd Authentication daemon

chasd Chassis monitoring and sysd services for chassis

crypto Cryptography and secure key services

dagger Some core debug and startup services for linux to PanOS interfaces

devsrvr Device Server

dhcp DHCP services

of 90


dnsproxy DNS services

dp-console Logging into data-plane

ehmon LED, fan, etc. monitor

ha-sshd SSH server for High Availability

ha_agent High Availability agent communicator

ikemgr IKEv2, IKEv1

keymgr IPsec HA sync

l2ctrl L2 Control Services

l3svc L3 Services

logrcvr Logger service

masterd Master Controller

mgmtsrvr Management System

monitor System monitoring

netconfig_agent Netconfig protocol

pppoe Power over Ethernet

rasmgr Remote Access

routed Routing daemon

satd Satellite daemon

snmpd SNMP server

sslmgr SSL, X509, cert, etc.

sslvpn SSL VPN

sslvpn_ngx SSL VPN through nginx

sysd Super IPC

sysdagent system agent and daemon

useridd User ID

varrcvr Var logger

websrvr Web server

Data Plan Processes


brdagent Data Plane Board Agent

comm Data Plane Communication

dha Data Plane HA

masterd Data Plane Master Controller

monitor Data Plane Monitor

of 90


mprelay Management Plane relay

ntp Data Plane NTP

sysdagent Data Plane Sys agent

The operational guidance shall contain instructions for configuring the cryptographic engine associated with the

evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic

engines was not evaluated nor tested during the CC evaluation of the TOE.

The following guidance is provided for configuring the cryptographic functions of the TOE:

Section 2.4 of the CCECG describes putting the TOE into CC mode.

Section 2.4 of the CCECG provides information regarding how the TOE can be setup to perform remote

administration via the web interface over HTTPS

Section 2.7.4 of the CCECG describes configuring TLS for communications between the TOE and a syslog

server.

Section 2.8 of the CCECG describes how the administrator can run cryptographic self tests and how to

configure IKE and IPsec.

Section 2.8.3 of the CCECG describes how to specify the TLS ciphersuites that are supported in the

evaluated configuration.

The documentation must describe the process for verifying updates to the TOE, either by checking the hash or by

verifying a digital signature. The evaluator shall verify that this process includes the following steps:

For hashes, a description of where the hash for a given update can be obtained. For digital signatures, instructions

for obtaining the certificate that will be used by the FCS_COP.1(2) mechanism to ensure that a signed update has

been received from the certificate owner. This may be supplied with the product initially, or may be obtained by

some other means.

Instructions for obtaining the update itself. This should include instructions for making the update accessible to the

TOE (e.g., placement in a specific directory).

Instructions for initiating the update process, as well as discerning whether the process was successful or

unsuccessful. This includes generation of the hash/digital signature.

The evaluator ensures that the operational guidance (or the TSS) describes how the candidate updates are obtained,

the processing associated with verifying the digital signature or calculating the hash of the updates, and the actions

that take place for successful (hash or signature was verified) and unsuccessful (hash or signature could not be

verified) cases.

Section 2.12 states that TOE administrators can obtain TOE updates from the Palo Alto Networks Support Site

(https://support.paloaltonetworks.com). If the TOE has Internet access from the management port, the list of

available updates can be displayed via the TOE’s Web Interface, from which the version to be installed can be

selected and downloaded. Otherwise, the desired update can be downloaded to another host and then uploaded to the

TOE and installed.

Software updates are digitally signed by Palo Alto. During the process of loading the update onto the TOE, and prior

to commencing installation, the TOE uses a built-in certificate to verify the digital signature on the software package

to confirm the integrity of the update package. If the digital signature is found to be valid, the TOE will advise the

administrator the update is ready to be installed. If the digital signature is found to be invalid, the TOE displays an

error message stating the update is invalid and does not make it available for installation.

The TOE will likely contain security functionality that does not fall in the scope of evaluation under this PP. The

operational guidance shall make it clear to an administrator which security functionality is covered by the evaluation

activities.

https://support.paloaltonetworks.com/

of 90

The CCECG, ADMIN and WEB guides, collectively identify the functionality that is covered by the evaluation and

provide specific configuration information and instructions. These guides clearly indicate how the TOE should be

configured into CC/FIPS mode and what changes are enabled in the TOE including what is not included in the

evaluated configuration.

3.2.2 Preparative Procedures (AGD_PRE.1)


As indicated in the introduction above, there are significant expectations with respect to the documentation—

especially when configuring the operational environment to support TOE functional requirements. The evaluator

shall check to ensure that the guidance provided for the TOE adequately addresses all platforms claimed for the

TOE in the ST.

The instructions and guidance contained in the he CCECG, ADMIN and WEB guides are applicable to all of the

TOE platforms.

3.3 Tests (ATE)

3.3.1 Independent Testing – Conformance (ATE_IND.1)


The evaluator shall prepare a test plan and report documenting the testing aspects of the system. The test plan covers

all of the testing actions contained in the CEM and the body of this PP’s Assurance Activities. While it is not

necessary to have one test case per test listed in an Assurance Activity, the evaluator must document in the test plan

that each applicable testing requirement in the ST is covered.

The test plan identifies the platforms to be tested, and for those platforms not included in the test plan but included

in the ST, the test plan provides a justification for not testing the platforms. This justification must address the

differences between the tested platforms and the untested platforms, and make an argument that the differences do

not affect the testing to be performed. It is not sufficient to merely assert that the differences have no affect;

rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary.

The test plan describes the composition of each platform to be tested, and any setup that is necessary beyond what is

contained in the AGD documentation. It should be noted that the evaluator is expected to follow the AGD

documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition.

This may include special test drivers or tools. For each driver or tool, an argument (not just an assertion) should be

provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its

platform. This also includes the configuration of the cryptographic engine to be used. The cryptographic algorithms

implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated

(IPsec, TLS/HTTPS, SSH).

The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those

objectives. These procedures include expected results. The test report (which could just be an annotated version of

the test plan) details the activities that took place when the test procedures were executed, and includes the actual

results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix

installed; and then a successful re-run of the test, the report would show a “fail” and “pass” result (and the

supporting details), and not just the “pass” result.

The TOE includes the following appliance models from the Palo Alto Networks PA-200, PA-500, PA-2000 Series,

PA-3000 Series, PA-4000 Series, PA-5000 Series, PA-7000 Series, VM Series, Next-Generation Firewall with

PAN-OS 7.0.1-h4. The specific Firewall appliance models include:

1. PA-200

2. PA-500

3. PA-2000

a. PA-2020

of 90

b. PA-2050

4. PA-3000

a. PA-3020

b. PA-3050

c. PA-3060

5. PA-4000

a. PA-4020

b. PA-4050

c. PA-4060

6. PA-5000

a. PA-5020

b. PA-5050

c. PA-5060

7. PA-7000

a. PA-7050

b. PA-7080

8. VM-Series

a. VM-1000-HV

b. VM-300

c. VM-200

d. VM-100

The subset of TOE hardware models tested includes one model from each Equivalency grouping shown in the table

below. The models in each grouping share the same processor architecture. The code base is common across all

product series. The differences among the appliance models relate to speed, performance and capacity and do not

affect any of the claimed security functions. The software for each appliance model within a group is from the same

source code base with the only differences in the binaries being related to performance aspects of the hardware and

not related to TOE security functions.

A similar argument applies to the VM Series in Group 5. All VM series models are built from the same PAN-OS

source code. There are no differences in the binaries that affect PP specified functionality and they can all run on

identical hardware. All VM-series have the same software image, designed to interoperate with all supported

hypervisors. This base image is packaged into a single RAW disk image. This common disk image is converted

into a compatible format for each hypervisor (i.e. ova, qcow2, and xva). The support site for Palo Alto Networks

then distributes the formatted disk images for deployment.

Equivalency

Grouping

Platform

Family Platform Models

Cavium

Management Plane(MP)

/Data Plane(DP)

Intel

Management Plane(MP)

Group 1 PA-200 PA-200 Octeon MIPS64 (DP/MP) None

PA-500 PA-500 Octeon MIPS64 (DP/MP)

PA-2000 PA-2050, PA-2020 Octeon MIPS64 (DP/MP)

Group 2 PA-3000 PA-3050, PA-3020 Octeon MIPS64 (DP) Intel Celeron

PA-3060 Octeon MIPS64 (DP)

Group 3 PA-4000 PA-4060, PA-4050,

PA-4020

Octeon MIPS64 (DP) Intel Xeon

PA-5000 PA-5060, PA-5050,

PA-5020

Octeon MIPS64 (DP) Intel Xeon

Group 4 PA-7000

PA-7050, PA-7080

Octeon MIPS64 (DP)

Octeon MIPS64 (Logging Card)

Intel Core i7

of 90

Palo Alto CAVP listing references following CPUs: Cavium Octeon MIPS64; Intel Multi Core Xeon; Intel Celeron

P4505; Intel Core I7

Reference: Search for "Palo Alto Networks” at http://csrc.nist.gov/groups/STM/cavp/documents/rng/rngval.html

As identified in Section 2.2.2 of the Palo Alto Networks Common Criteria Entropy Assessment Report v1.0, PAN-

OS actually implements two kernels, one for the Management Plane (MP) and one for each instance of the Data

Plane (DP). The MP typically performs management related functions at a very nominal rate while the DP

implements line-rate functionality. The DP software always runs on a Cavium Octeon CPU. The MP software runs

on an Intel CPU on all platforms except the PA-200, PA-500 and PA-2000. PA-200, PA-500 and PA-2000 devices

are slightly different, since they have only one, multicore Cavium CPU. On these devices, the MP software runs on

the Cavium along with the DP software, but on different cores.

VM devices are similar to the PA-200/500/2000 devices. Depending on the number of cores allocated for PAN-OS,

one core will be allocated for the MP and one or more cores for DP software. VMs are deployed in the system using

Intel CPU's based on either the Ivy Bridge or Haswell microarchitecture.

The VM-Series virtual appliances are considered to be in their evaluated configuration only when installed on the

following specified hardware platforms:

Dell PowerEdge R430, R530, R630, R730, R730xd and R930 Servers

Equivalent platforms i.e., Intel Ivy Bridge or Haswell-based processor with Broadcom or Intel Network

Interface Controllers supported by the server

In addition, the VM-Series virtual appliance must be the only guest running in the virtualized environment.

Evaluation testing included the VM-300 installed on a Dell PowerEdge R730 Server running VMware ESXi 5.5 on

an Intel Xeon E5-2630 v3 (Haswell microarchitecture) processor with Broadcom 5720 NIC. Testing on one of the

specified hardware platforms including one processor and one network interface controller was deemed sufficient

based on the following equivalence rationale:

Standard device drivers from Broadcom and Intel were tested on the PA firewall devices and on the VM

series platform, therefore network interface controllers using those families of Ethernet drivers that are

supported by the specified Dell Servers are considered equivalent.

Within the Ivy Bridge microarchitecture, all processor models (Celeron, Pentium, Core, Xeon) implement

the same instruction set. Differences are all associated with performance attributes, based on number of

cores, L3 cache size, CPU clock rate, graphics clock rate, and Thermal Design Power (a measure of the

heat generated by the CPU).

Within the Haswell microarchitecture, all processor models (Celeron, Pentium, Core, Xeon) implement the

same instruction set. Differences are all associated with performance attributes, based on number of cores,

L3 cache size, CPU clock rate, graphics clock rate, and Thermal Design Power (a measure of the heat

generated by the CPU).

The Haswell microarchitecture implements a superset of the Ivy Bridge instruction set. The new

instructions are associated with extensions to support vector processing, which in turn improves

performance in applications such as floating-point calculations and graphics processing. Haswell is

backward compatible with Ivy Bridge, so software that executes on Ivy Bridge will also work on Haswell.”

The subset of TOE models tested are as follows:

o PA-200 Next Generation Firewall

Group 5 VM Series

VM-1000-HV, VM-

300, VM-200, VM-

100

Supported

hypervisor:

VMware ESXi 5.5

Intel Core i7

Intel Xeon

Intel Core i7

Intel Xeon

http://csrc.nist.gov/groups/STM/cavp/documents/rng/rngval.html

of 90

o PA-5050 Next Generation Firewall

o PA 3060 Next Generation Firewall

o PA 7050 Next Generation Firewall

o VM-300 running on Dell R730 with Intel Xeon Processor E5-2630 v3

All tests were performed on all four models and the VM series in the subset. Testing was performed via the

management interface which is the same for all platforms. There is no testing at the physical network interfaces

since the TOE provides a management port that is separate from the network ports used for routing and switching.

The test plans and test results are documented in Evaluation Team Test Report for Palo Alto Networks PA-200, PA-

500, PA-2000 Series, PA-3000 Series, PA-4000 Series, PA-5000 Series, PA-7000 Series, VM Series, Next-

Generation Firewall with PAN-OS 7.0.1-h4. A non-proprietary overview of the testing performed by the evaluation

team in response to the Assurance Activities specified in the PP’s has been included in the relevant sections of this

Assurance Activities Report.

3.4 Vulnerability Assessment (AVA)

3.4.1 Vulnerability Survey (AVA_VAN.1)


As with ATE_IND, the evaluator shall generate a report to document their findings with respect to this requirement.

This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The

evaluator performs a search of public information to determine the vulnerabilities that have been found in network

infrastructure devices and the implemented communication protocols in general, as well as those that pertain to the

particular TOE. The evaluator documents the sources consulted and the vulnerabilities found in the report. For each

vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator

formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is

determined by assessing the attack vector needed to take advantage of the vulnerability. For example, if the

vulnerability can be detected by pressing a key combination on boot-up, a test would be suitable at the assurance

level of this PP. If exploiting the vulnerability requires expert skills and an electron microscope, for instance, then a

test would not be suitable and an appropriate justification would be formulated.

VPNGW

The evaluator shall generate network packets that cycle through all of the values for the Transport Layer Protocol

attribute that are undefined by the RFCs for IPv4 and IPv6. For example, IPv4 has an eight-bit field for Transport

Layer Protocol. Only 100 Transport Layer Protocol values are defined in the RFC for IPv4 (see Table 9-1 in

Appendix E), but there are 256 possible values. The evaluator is required to construct packets that exercise each

possible value not defined in the RFC (the defined values are already tested in FPF_RUL_EXT.1.7) of Transport

Layer Protocol (including all possible combinations) and target each distinct interface type to determine that the

TOE handles these packets appropriately. Since none of these packets will match a rule, or belong to an allowed

session the packets should be dropped. Since there are no requirements that the VPN Gateway audit a packet being

dropped under these circumstances, the evaluator shall ensure the VPN Gateway does not allow these packets to

flow through the TOE. Note that for IPv6, protocol numbers 0 (Hop-by-Hop options), 60 (Destination options), 44

(Fragment), 51 (AH), and 50 (ESP) are extension header numbers rather than transport layer protocol numbers and

should be excluded from testing.

of 90

TFFW

The evaluator shall generate network packets that cycle through all of the values for attributes, Type, Code, and

Transport Layer Protocol, that are undefined by the RFC for each of the protocols, ICMPv4, ICMPv6, IPv4, and

IPv6. For example, ICMPv4 has an eight-byte field for Type and an eight-byte field for the Code. Only 21 Types are

defined in the RFC (see table 4-2), but there are 256 possible value. Each Type has a Code associated with it, the

number of RFC defined Codes varies based on the Type. The evaluator is required to construct packets that exercise

each possible value not defined in the RFC (the defined values are already tested in FFW_RUL_EXT.1.10) of Type

and Code (including all possible combinations) and target each distinct interface type to determine that the TOE

handles these packets appropriately. Since none of these packets will match a rule, or belong to an allowed session

the packets should be dropped. Since there are no requirements that the firewall audit a packet being dropped under

these circumstances, the evaluator shall ensure the firewall does not allow these packets to flow through the TOE.

In addition to the undefined attribute testing required above, the evaluator shall perform intelligent fuzz testing of

the remaining fields in the required protocol headers (excluding FTP). The intent of intelligent fuzzing is that a

packet that is otherwise correctly constructed, such that it will be denied when the ruleset is applied, has random

values inserted into each of the protocol header fields. The evaluator ensures a statistically significant sample size,

which will vary depending on the protocol field length, is used and is justified in their report.

The evaluator should consult whatever diagnostics (e.g., logging, process status, interface errors) the TOE offers to

determine if the TOE was adversely impacted by the processing of such packets.


operate as expected in each test scenario.




3.5 Life-Cycle Support (ALC)

3.5.1 Labeling of the TOE (ALC_CMC.1)


The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that

specifically identifies the version that meets the requirements of the ST. The evaluator shall ensure that this

identifier is sufficient for an acquisition entity to use in procuring the TOE (including the appropriate administrative

guidance) as specified in the ST. Further, the evaluator shall check the AGD guidance and TOE samples received

for testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a web site

advertising the TOE, the evaluator shall examine the information on the web site to ensure that the information in

the ST is sufficient to distinguish the product.

Section 2.3 of the ST identifies the guidance documentation for the TOE

Section 1.1 of the ST includes the TOE identification. The TOE is identified in terms of the hardware device and

software included in the evaluated configuration. Palo Alto Networks PA-200, PA-500, PA-2000 Series, PA-3000


7.0.1-h4.

During testing, the evaluator determined the TOE is labeled with identifying information consistent with the

information in the ST and that the software version can be verified via the GUI interface.

The guidance documentation submitted for evaluation identifies the applicable software version consistent with the

evaluated version specified in the ST.

The evaluator examined information on the vendor website regarding the TOE and confirmed the information in the

ST is sufficient to distinguish the evaluated version of the product from unevaluated versions.

of 90

3.5.2 TOE Coverage (ALC_CMS.1)


The “evaluation evidence required by the SARs” in this PP is limited to the information in the ST coupled with the

guidance provided to administrators and users under the AGD requirements. By ensuring that the TOE is

specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the

assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component.