National Information Assurance Partnership
Common Criteria Evaluation and Validation Scheme
Validation Report
for the
Pulse Policy Secure v9.1, Version 1.0
Report Number: CCEVS-VR-11020-2020
Dated: 03/30/20
Version: 1.0
National Institute of Standards and Technology National Security Agency
Information Technology Laboratory Information Assurance Directorate
100 Bureau Drive 9800 Savage Road STE 6940
Gaithersburg, MD 20899 Fort George G. Meade, MD 20755-6940
®
TM
2
ACKNOWLEDGEMENTS
Validation Team
Paul Bicknell
Jenn Dotson
Randy Heimann
Linda Morrison (Lead Validator)
Clare Olin
Jean Petty (Senior Validator)
Common Criteria Testing Laboratory
Anthony Busciglio
Brad Mitchell
Kevin Zhang
Olexandr Kholyavko
Acumen Security, LLC
3
Table of Contents
1 Executive Summary ...........................................................................................................4
2 Identification ......................................................................................................................5
3 Architectural Information .................................................................................................6
4 Security Policy....................................................................................................................7
4.1 Security Audit..........................................................................................................................................7
4.2 Cryptographic Support............................................................................................................................7
4.3 Identification and Authentication............................................................................................................7
4.4 Security Management..............................................................................................................................7
4.5 Protection of the TSF...............................................................................................................................7
4.6 TOE Access..............................................................................................................................................8
4.7 Trusted Path/Channels............................................................................................................................8
5 Assumptions, Threats & Clarification of Scope................................................................9
5.1 Assumptions.............................................................................................................................................9
5.2 Threats................................................................................................................................................... 10
5.3 Clarification of Scope............................................................................................................................. 11
6 Documentation .................................................................................................................13
7 TOE Evaluated Configuration ........................................................................................14
7.1 Evaluated Configuration ....................................................................................................................... 14
7.2 Excluded Functionality.......................................................................................................................... 14
8 IT Product Testing...........................................................................................................15
8.1 Developer Testing .................................................................................................................................. 15
8.2 Evaluation Team Independent Testing.................................................................................................. 15
9 Results of the Evaluation .................................................................................................16
9.1 Evaluation of Security Target................................................................................................................ 16
9.2 Evaluation of Development Documentation .......................................................................................... 16
9.3 Evaluation of Guidance Documents ...................................................................................................... 16
9.4 Evaluation of Life Cycle Support Activities .......................................................................................... 16
9.5 Evaluation of Test Documentation and the Test Activity...................................................................... 17
9.6 Vulnerability Assessment Activity......................................................................................................... 17
9.7 Summary of Evaluation Results ............................................................................................................ 17
10 Validator Comments & Recommendations ....................................................................18
11 Annexes ............................................................................................................................19
12 Security Target.................................................................................................................20
13 Glossary............................................................................................................................21
14 Bibliography.....................................................................................................................22
4
1 Executive Summary
This Validation Report (VR) is intended to assist the end user of this product and any security
certification Agent for that end user in determining the suitability of this Information Technology
(IT) product for their environment. End users should review the Security Target (ST), which is
where specific security claims are made, in conjunction with this VR, which describes how those
security claims were tested and evaluated and any restrictions on the evaluated configuration.
Prospective users should carefully read the Assumptions and Clarification of Scope in Section 5
and the Validator Comments in Section 10, where any restrictions on the evaluated configuration
are highlighted.
This report documents the National Information Assurance Partnership (NIAP) assessment of the
evaluation of the Pulse Policy Secure v9.1 Target of Evaluation (TOE). It presents the
evaluation results, their justifications, and the conformance results. This VR is not an
endorsement of the TOE by any agency of the U.S. Government and no warranty of the TOE is
either expressed or implied. This VR applies only to the specific version and configuration of
the product as evaluated and documented in the ST.
The evaluation was completed by Acumen Security in March 2020. The information in this
report is largely derived from the Evaluation Technical Report (ETR) and associated test report,
all written by Acumen Security. The evaluation determined that the product is both Common
Criteria Part 2 Extended and Part 3 Conformant and meets the assurance requirements defined in
the collaborative Protection Profile for Network Devices, Version 2.1.
The Target of Evaluation (TOE) identified in this Validation Report has been evaluated at a
NIAP approved Common Criteria Testing Laboratory using the Common Methodology for IT
Security Evaluation (Version 3.1, Rev. 5) for conformance to the Common Criteria for IT
Security Evaluation (Version 3.1, Rev. 5), as interpreted by the Assurance Activities contained in
the collaborative Protection Profile for Network Devices, Version 2.1. This Validation Report
applies only to the specific version of the TOE as evaluated. The evaluation has been conducted
in accordance with the provisions of the NIAP Common Criteria Evaluation and Validation
Scheme and the conclusions of the testing laboratory in the evaluation technical report are
consistent with the evidence provided.
5
2 Identification
The CCEVS is a joint National Security Agency (NSA) and National Institute of
Standards effort to establish commercial facilities to perform trusted product evaluations.
Under this program, security evaluations are conducted by commercial testing
laboratories called Common Criteria Testing Laboratories (CCTLs). CCTLs evaluate
products against Protection Profile containing Assurance Activities, which are
interpretation of CEM work units specific to the technology described by the PP.
The NIAP Validation Body assigns Validators to monitor the CCTLs to ensure quality
and consistency across evaluations. Developers of information technology products
desiring a security evaluation contract with a CCTL and pay a fee for their product's
evaluation. Upon successful completion of the evaluation, the product is added to NIAP's
Product Compliance List.
Table 1 provides information needed to completely identify the product, including:
 The Target of Evaluation (TOE): the fully qualified identifier of the product as
evaluated.
 The Security Target (ST), describing the security features, claims, and assurances
of the product.
 The conformance result of the evaluation.
 The Protection Profile(s) to which the product is conformant.
 The organizations and individuals participating in the evaluation.
Table 1: Evaluation Identifiers
Item Identifier
Evaluation Scheme United States NIAP Common Criteria Evaluation and Validation Scheme
TOE Pulse Policy Secure v9.1
Protection Profile collaborative Protection Profile for Network Devices, Version 2.1
Security Target Pulse Policy Secure v9.1 Security Target, V1.1, March 16, 2020
Evaluation Technical
Report
Pulse Policy Secure ETR, V1.1, March 16, 2020
CC Version Version 3.1, Revision 5
Conformance Result CC Part 2 Extended and CC Part 3 Conformant
Sponsor PulseSecure, LLC.
Developer PulseSecure, LLC.
Common Criteria
Testing Lab (CCTL)
Acumen Security
Rockville, MD
CCEVS Validators Paul Bicknell, Jenn Dotson, Randy Heimann, Clare Olin, Linda Morrison, Jean Petty
6
3 Architectural Information
Pulse Policy Secure (PPS) is a next-generation NAC that enables visibility to understand an
organization’s security posture and enforce role-based access and endpoint security policies for
network users. PPS allows administrators to define, implement, and enforce policy by enabling
endpoint discovery, monitoring, and alerting.
The TOE is classified as a network device (a generic infrastructure device that can be connected
to a network) or a virtual network device (a Virtual Appliance that can be connected to a
network) depending on the underlying platform. The TOE software consists of Pulse Policy
Secure (PPS) 9.1. The appliance’s software is built on IVE OS 2.0. The TOE consists of the PPS
application, IVE OS, and either the TOE hardware or the VM hypervisor, all of which are
delivered with the TOE. The TOE hardware consists of either the PSA Models 300, 3000, 5000,
7000C, or 7000F.
7
4 Security Policy
The TOE provides the security functionality required by NDcPP v2.1, September 24, 2018.
4.1 Security Audit
The TOE generates audit records for security relevant events. The TOE maintains a local audit
log as well as sending the audit records to a remote Syslog server. Audit records sent to the
remote server are protected by a TLS connection. Each audit record includes identity (username,
IP address, or process), date and time of the event, type of event, and the outcome of the event.
The TOE prevents modification to the local audit log.
4.2 Cryptographic Support
The TOE includes the Pulse Secure Cryptographic Module that implements CAVP validated
cryptographic algorithms for random bit generation, encryption/decryption, authentication, and
integrity protection/verification. These algorithms are used to provide security for the TLS and
HTTPs connections for secure management and secure connections to a syslog server. TLS and
HTTPs are also used to verify firmware updates.
4.3 Identification and Authentication
The TOE authenticates administrative users using a username/password or username/X.509
certificate combination. The TOE does not allow access to any administrative functions prior to
successful authentication. The TOE validates and authenticates X.509 certificates for all
certificate uses. The TOE supports passwords consisting of alphanumeric and special characters
and enforces minimum password lengths. The TSF supports certificates using RSA or ECDSA
signature algorithms. The TOE only allows users to view the login warning banner and
send/receive ICMP packets prior to authentication. Remote administrators are locked out after a
configurable number of unsuccessful authentication attempts.
4.4 Security Management
The TOE allows users with the Security Administrator role to administer the TOE over a remote
web UI or a local CLI. These interfaces do not allow the Security Administrator to execute
arbitrary commands or executables on the TOE. Security Administrators can manage
connections to an external Syslog server, as well as determine the size of local audit storage.
4.5 Protection of the TSF
The TOE implements several self-protection mechanisms. It does not provide an interface for the
reading of secret or private keys. The TOE ensures timestamps, timeouts, and certificate checks
are accurate by maintaining a real-time clock. Upon startup, the TOE runs a suite of self-tests to
verify that it is operating correctly. The TOE also verifies the integrity and authenticity of
firmware updates by verifying a digital signature of the update prior to installing it.
8
4.6 TOE Access
The TOE can be configured to display a warning and consent banner when an administrator
attempts to establish an interactive session over the local CLI or remote web UI. The TOE also
enforces a configurable inactivity timeout for remote and local administrative sessions.
4.7 Trusted Path/Channels
The TOE uses TLS to provide a trusted communication channel between itself and remote
Syslog servers. The trusted channels utilize X.509 certificates to perform mutual authentication.
The TOE initiates the TLS trusted channel with the remote server. The TOE uses HTTPS/TLS to
provide a trusted path between itself and remote administrative users. The TOE does not
implement any additional methods of remote administration. The remote administrative users are
responsible for initiating the trusted path when they wish to communicate with the TOE.
9
5 Assumptions, Threats & Clarification of Scope
5.1 Assumptions
The specific conditions listed in the following subsections are assumed to exist in the TOE’s
environment. These assumptions include both practical realities in the development of the TOE
security requirements and the essential environmental conditions on the use of the TOE.
ID Assumption
A.PHYSICAL_PROTECTION The network device is assumed to be physically protected in its
operational environment and not subject to physical attacks that
compromise the security and/or interfere with the device’s physical
interconnections and correct operation. This protection is assumed to
be sufficient to protect the device and the data it contains. As a
result, the cPP will not include any requirements on physical tamper
protection or other physical attack mitigations. The cPP will not
expect the product to defend against physical access to the device
that allows unauthorized entities to extract data, bypass other
controls, or otherwise manipulate the device.
A.LIMITED_FUNCTIONALITY The device is assumed to provide networking functionality as its
core function and not provide functionality/services that could be
deemed as general purpose computing. For example, the device
should not provide computing platform for general purpose
applications (unrelated to networking functionality).
A.NO_THRU_TRAFFIC_PROTECTION A standard/generic network device does not provide any assurance
regarding the protection of traffic that traverses it. The intent is for
the network device to protect data that originates on or is destined to
the device itself, to include administrative data and audit data.
Traffic that is traversing the network device, destined for another
network entity, is not covered by the ND cPP. It is assumed that this
protection will be covered by cPPs and PP-Modules for particular
types of network devices (e.g, firewall).
A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the network device are assumed to
be trusted and to act in the best interest of security for the
organization. This includes being appropriately trained, following
policy, and adhering to guidance documentation. Administrators are
trusted to ensure passwords/credentials have sufficient strength and
entropy and to lack malicious intent when administering the device.
The network device is not expected to be capable of defending
against a malicious administrator that actively works to bypass or
compromise the security of the device.
For TOEs supporting X.509v3 certificate-based authentication, the
Security Administrator(s) are expected to fully validate (e.g. offline
verification) any CA certificate (root CA certificate or intermediate
CA certificate) loaded into the TOE’s trusted source (aka ‘root
store’, ‘trusted CA Key Store’, or similar) as a trust anchor prior to
use (e.g. offline verification).
A.REGULAR_UPDATES The network device firmware and software is assumed to be updated
by an administrator on a regular basis in response to the release of
product updates due to known vulnerabilities.
A.ADMIN_CREDENTIALS_SECURE The administrator’s credentials (private key) used to access the
network device are protected by the platform on which they reside.
10
A.COMPONENTS_RUNNING
(applies to distributed TOEs only)
For distributed TOEs it is assumed that the availability of all TOE
components is checked as appropriate to reduce the risk of an
undetected attack on (or failure of) one or more TOE components. It
is also assumed that in addition to the availability of all components
it is also checked as appropriate that the audit functionality is
running properly on all TOE components.
A.RESIDUAL_INFORMATION The Administrator must ensure that there is no unauthorized access
possible for sensitive residual information (e.g. cryptographic keys,
keying material, PINs, passwords etc.) on networking equipment
when the equipment is discarded or removed from its operational
environment.
5.2 Threats
The following table lists the threats addressed by the TOE and the IT Environment. The
assumed level of expertise of the attacker for all the threats identified below is Enhanced-Basic.
ID Threat
T.UNAUTHORIZED_ADMINISTRATOR_ACCESS Threat agents may attempt to gain administrator access
to the network device by nefarious means such as
masquerading as an administrator to the device,
masquerading as the device to an administrator,
replaying an administrative session (in its entirety, or
selected portions), or performing man-in-the-middle
attacks, which would provide access to the
administrative session, or sessions between network
devices. Successfully gaining administrator access
allows malicious actions that compromise the security
functionality of the device and the network on which it
resides.
T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic
algorithms or perform a cryptographic exhaust against
the key space. Poorly chosen encryption algorithms,
modes, and key sizes will allow attackers to
compromise the algorithms, or brute force exhaust the
key space and give them unauthorized access allowing
them to read, manipulate and/or control the traffic with
minimal effort.
T.UNTRUSTED_COMMUNICATION_CHANNELS Threat agents may attempt to target network devices that
do not use standardized secure tunneling protocols to
protect the critical network traffic. Attackers may take
advantage of poorly designed protocols or poor key
management to successfully perform man-in-the-middle
attacks, replay attacks, etc. Successful attacks will result
in loss of confidentiality and integrity of the critical
network traffic, and potentially could lead to a
compromise of the network device itself.
T.WEAK_AUTHENTICATION_ENDPOINTS Threat agents may take advantage of secure protocols
that use weak methods to authenticate the endpoints –
e.g. a shared password that is guessable or transported
as plaintext. The consequences are the same as a poorly
designed protocol, the attacker could masquerade as the
Administrator or another device, and the attacker could
insert themselves into the network stream and perform a
man-in-the-middle attack. The result is the critical
11
network traffic is exposed and there could be a loss of
confidentiality and integrity, and potentially the network
device itself could be compromised.
T.UPDATE_COMPROMISE Threat agents may attempt to provide a compromised
update of the software or firmware which undermines
the security functionality of the device. Non-validated
updates or updates validated using non-secure or weak
cryptography leave the update firmware vulnerable to
surreptitious alteration.
T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change, and/or
modify the security functionality of the network device
without administrator awareness. This could result in the
attacker finding an avenue (e.g., misconfiguration, flaw
in the product) to compromise the device and the
administrator would have no knowledge that the device
has been compromised.
T.SECURITY_FUNCTIONALITY_COMPROMISE Threat agents may compromise credentials and device
data enabling continued access to the network device
and its critical data. The compromise of credentials
includes replacing existing credentials with an attacker’s
credentials, modifying existing credentials, or obtaining
the administrator or device credentials for use by the
attacker.
T.PASSWORD_CRACKING Threat agents may be able to take advantage of weak
administrative passwords to gain privileged access to
the device. Having privileged access to the device
provides the attacker unfettered access to the network
traffic, and may allow them to take advantage of any
trust relationships with other network devices.
T.SECURITY_FUNCTIONALITY_FAILURE An external, unauthorized entity could make use of
failed or compromised security functionality and might
therefore subsequently use or abuse security functions
without prior authentication to access, change or modify
device data, critical network traffic or security
functionality of the device.
5.3 Clarification of Scope
All evaluations (and all products) have limitations, as well as potential misconceptions that need
clarifying. This text covers some of the more important limitations and clarifications of this
evaluation. Note that:
 As with any evaluation, this evaluation only shows that the evaluated configuration meets
the security claims made, with a certain level of assurance. The level of assurance for this
evaluation is defined within the collaborative Protection Profile for Network Devices,
Version 2.1.
 Consistent with the expectations of the Protection Profile, this evaluation did not
specifically search for, nor seriously attempt to counter, vulnerabilities that were not
“obvious” or vulnerabilities to objectives not claimed in the ST. The CEM defines an
“obvious” vulnerability as one that is easily exploited with a minimum of understanding
of the TOE, technical sophistication and resources.
12
 The evaluation of security functionality of the product was limited to the functionality
specified in the claimed PPs. Any additional security related functional capabilities
included in the product were not covered by this evaluation.
13
6 Documentation
The following documents were provided by the vendor with the TOE for evaluation:
 Pulse Policy Secure v9.1 Security Target, V1.1, March 16, 2020
 Pulse Secure Operational User Guidance and Preparative Procedures, V1.2, March 2020
14
7 TOE Evaluated Configuration
7.1 Evaluated Configuration
The TOE consists of the following hardware:
 PSA 300
 PSA 3000
 PSA 5000
 PSA 7000C
 PSA 7000F
Running:
 Pulse Policy Secure (PPS) v9.1
The PPS software runs on any of the TOE hardware appliance platforms or on a virtual
appliance. The TOE is delivered with the PCS v9.1 software installed on one of the PSA
appliances. The TOE can also be a virtual appliance on VMware ESXi 6.0, with a Dell
PowerEdge R430R530 as the hardware platform. ESXi is a bare-metal hypervisor so there is no
underlying operation system. In the evaluated configuration, there are no guest VMs on the
physical platform providing non-network device functionality.
7.2 Excluded Functionality
The TOE includes the following functionality that is not covered in this Security Target and may
not be enabled or used in in the CC evaluated configuration:
 DMI Agent
 SNMP Traps
 External Authentication Servers for administrator authentication
15
8 IT Product Testing
This section describes the testing efforts of the developer and the evaluation team. It is derived
from information contained in Evaluation Test Report for Pulse Policy Secure v9.1, V1.0,
January 10, 2020, which is not publicly available. The Assurance Activities Report provides an
overview of testing and the prescribed assurance activities.
8.1 Developer Testing
No evidence of developer testing is required in the Assurance Activities for this product.
8.2 Evaluation Team Independent Testing
The evaluation team verified the product according the vendor-provided guidance documentation
and ran the tests specified in the collaborative Protection Profile for Network Devices, Version
2.1. The Independent Testing activity is documented in the Assurance Activities Report, V1.2,
March 24, 2020, which is publicly available, and is not duplicated here.
16
9 Results of the Evaluation
The results of the assurance requirements are generally described in this section and are
presented in detail in the proprietary documents: the Detailed Test Report (DTR) and the
Evaluation Technical Report (ETR). The reader of this document can assume that activities and
work units received a passing verdict.
A verdict for an assurance component is determined by the resulting verdicts assigned to the
corresponding evaluator action elements. The evaluation was conducted based upon CC version
3.1 rev 5 and CEM version 3.1 rev 5. The evaluation determined the Pulse Policy Secure v9.1 to
be Part 2 extended, and meets the SARs contained in the PP. Additionally the evaluator
performed the Assurance Activities specified in the NDcPP V2.1.
9.1 Evaluation of Security Target
The evaluation team applied each ASE CEM work unit. The ST evaluation ensured the ST
contains a description of the environment in terms of policies and assumptions, a statement of
security requirements claimed to be met by the Pulse Connect Secure v9.1 that are consistent
with the Common Criteria, and product security function descriptions that support the
requirements. Additionally, the evaluator performed an assessment of the Assurance Activities
specified in the collaborative Protection Profile for Network Devices, Version 2.1.
9.2 Evaluation of Development Documentation
The evaluation team applied each ADV CEM work unit. The evaluation team assessed the
design documentation and found it adequate to aid in understanding how the TSF provides the
security functions. The design documentation consists of a functional specification contained in
the Security Target's TOE Summary Specification. Additionally, the evaluator performed the
Assurance Activities specified in the collaborative Protection Profile for Network Devices,
Version 2.1 related to the examination of the information contained in the TOE Summary
Specification.
9.3 Evaluation of Guidance Documents
The evaluation team applied each AGD CEM work unit. The evaluation team ensured the
adequacy of the user guidance in describing how to use the operational TOE. Additionally, the
evaluation team ensured the adequacy of the administrator guidance in describing how to
securely administer the TOE. The guides were assessed during the design and testing phases of
the evaluation to ensure they were complete. Additionally, the evaluator performed the
Assurance Activities specified in the collaborative Protection Profile for Network Devices,
Version 2.1 related to the examination of the information contained in the operational guidance
documents.
9.4 Evaluation of Life Cycle Support Activities
The evaluation team applied each ALC CEM work unit. The evaluation team found that the TOE
was identified.
17
The validator reviewed the work of the evaluation team, and found that sufficient evidence and
justification was provided by the evaluation team to confirm that the evaluation was conducted in
accordance with the requirements of the CEM, and that the conclusion reached by the evaluation
team was justified.
9.5 Evaluation of Test Documentation and the Test Activity
The evaluation team applied each ATE CEM work unit. The evaluation team ran the set of tests
specified by the Assurance Activities in the collaborative Protection Profile for Network
Devices, Version 2.1 and recorded the results in a Test Report, summarized in the Evaluation
Technical Report and Assurance Activities Report.
9.6 Vulnerability Assessment Activity
The evaluation team applied each AVA CEM work unit. The evaluation team performed a public
search for vulnerabilities, performed vulnerability testing and did not discover any issues with
the TOE.
9.7 Summary of Evaluation Results
The evaluation team's assessment of the evaluation evidence demonstrates that the claims in
the ST are met. Additionally, the evaluation team's test activities also demonstrated the
accuracy of the claims in the ST.
The validation team's assessment of the evidence provided by the evaluation team is that it
demonstrates that the evaluation team performed the Assurance Activities in the collaborative
Protection Profile for Network Devices, Version 2.1, and correctly verified that the product
meets the claims in the ST.
18
10 Validator Comments & Recommendations
The validation team notes that the evaluated configuration is dependent upon the TOE being
configured per the evaluated configuration instructions in the Pulse Policy Secure Operational
User Guidance and Preparative Procedures, Version 1.2, March 2020 document.
Please note that the functionality evaluated is scoped exclusively to the security functional
requirements specified in the Security Target. Other functionality included in the product was not
assessed as part of this evaluation. All other functionality provided by the product needs to be
assessed separately and no further conclusions can be drawn about their effectiveness.
19
11 Annexes
Not applicable.
20
12 Security Target
Pulse Policy Secure v9.1 Security Target,V1.1, March 16, 2020
21
13 Glossary
The following definitions are used throughout this document:
 Common Criteria Testing Laboratory (CCTL). An IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and
approved by the CCEVS Validation Body to conduct Common Criteria-based
evaluations.
 Conformance. The ability to demonstrate in an unambiguous way that a given
implementation is correct with respect to the formal model.
 Evaluation. The assessment of an IT product against the Common Criteria using the
Common Criteria Evaluation Methodology to determine whether or not the claims made
are justified; or the assessment of a protection profile against the Common Criteria using
the Common Evaluation Methodology to determine if the Profile is complete, consistent,
technically sound and hence suitable for use as a statement of requirements for one or
more TOEs that may be evaluated.
 Evaluation Evidence. Any tangible resource (information) required from the sponsor or
developer by the evaluator to perform one or more evaluation activities.
 Feature. Part of a product that is either included with the product or can be ordered
separately.
 Target of Evaluation (TOE). A group of IT products configured as an IT system, or an
IT product, and associated documentation that is the subject of a security evaluation
under the CC.
 Validation. The process carried out by the CCEVS Validation Body leading to the issue
of a Common Criteria certificate.
 Validation Body. A governmental organization responsible for carrying out validation
and for overseeing the day-to-day operation of the NIAP Common Criteria Evaluation
and Validation Scheme.
22
14 Bibliography
The Validation Team used the following documents to produce this Validation Report:
1. Common Criteria for Information Technology Security Evaluation - Part 1: Introduction
and general model, Version 3.1 Revision 5.
2. Common Criteria for Information Technology Security Evaluation - Part 2: Security
functional requirements, Version 3.1 Revision 5.
3. Common Criteria for Information Technology Security Evaluation - Part 3: Security
assurance requirements, Version 3.1 Revision 5.
4. Common Evaluation Methodology for Information Technology Security Evaluation,
Version 3.1 Revision 5.
5. Collaborative Protection Profile for Network Devices, Version 2.1, 24 September 2018
(NDcPP21).
6. Pulse Policy Secure v9.1 Security Target, Version 1.1, March 16, 2020.
7. Assurance Activity Report for Pulse Policy Secure v9.1, Version 1.2, March 24, 2020.
8. Test Plan for PPS (PSA7000), Version 1.1, March 16, 2020.
9. Test Plan for Virtual PPS, Version 1.2, Date, March 24, 2020.
10. Evaluation Technical Report for Pulse Policy Secure v9.1, Version 2.1, March 16, 2020.
11. Pulse Policy Secure Operational User Guidance and Preparative Procedures, Version 1.2,
March 2020.