National Information Assurance Partnership
Common Criteria Evaluation and Validation Scheme
Validation Report
for the
Junos OS 20.3R3 for NFX350
Report Number: CCEVS-VR-11236-2022
Dated: 06/20/2022
Version: 1.0
National Institute of Standards and Technology Department of Defense
Information Technology Laboratory ATTN: NIAP, Suite 6982
100 Bureau Drive 9800 Savage Road
Gaithersburg, MD 20899 Fort Meade, MD 20755-6982
®
TM
2
ACKNOWLEDGEMENTS
Validation Team
Jim Donndelinger
Meredith Hennan
DeRon Graves
The Aerospace Corporation
Common Criteria Testing Laboratory
Acumen Security, LLC
3
Table of Contents
1 Executive Summary............................................................................................................... 4
2 Identification.......................................................................................................................... 6
3 Architectural Information .................................................................................................... 7
3.1.1 Linux OS......................................................................................................................................................8
3.1.2 Junos Control Plane......................................................................................................................................8
3.1.3 Juniper Device Manager (JDM)...................................................................................................................9
3.1.4 Open vSwitch (OVS) Bridge........................................................................................................................9
4 Security Policy...................................................................................................................... 10
4.1 Non-TOE hardware/software/firmware.....................................................................................................11
5 Assumptions, Threats & Clarification of Scope ............................................................... 13
5.1 Assumptions..................................................................................................................................................13
5.2 Threats...........................................................................................................................................................16
5.3 Clarification of Scope...................................................................................................................................24
5.3.1 Product Functionality not Included in the Scope of the Evaluation ...........................................................25
6 Documentation..................................................................................................................... 26
7 TOE Evaluated Configuration ........................................................................................... 27
7.1 Evaluated Configuration..............................................................................................................................27
8 IT Product Testing............................................................................................................... 28
8.1 Developer Testing .........................................................................................................................................28
8.2 Evaluation Team Independent Testing.......................................................................................................28
9 Results of the Evaluation .................................................................................................... 29
9.1 Evaluation of Security Target .....................................................................................................................29
9.2 Evaluation of Development Documentation...............................................................................................29
9.3 Evaluation of Guidance Documents............................................................................................................29
9.4 Evaluation of Life Cycle Support Activities...............................................................................................30
9.5 Evaluation of Test Documentation and the Test Activity .........................................................................30
9.6 Vulnerability Assessment Activity ..............................................................................................................30
9.7 Summary of Evaluation Results..................................................................................................................31
10 Validator Comments & Recommendations ...................................................................... 32
11 Annexes................................................................................................................................. 33
12 Security Target .................................................................................................................... 34
13 Glossary................................................................................................................................ 35
14 Bibliography......................................................................................................................... 36
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 to determine 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 the
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 Junos OS 20.3R3 for NFX350 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 June 2022. The information in this report
is largely derived from the Evaluation Technical Report (ETR) and associated test report, each
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 U.S. Government Protection Profile for Security Requirements for collaborative
Protection Profile for Network Devices, version 2.2e, dated 27 March 2020 (CPP_ND_V2.2E),
collaborative Protection Profile Module for Stateful Traffic Filter Firewalls, Version 1.4e, dated
01 July 2020 (MOD_CPP_FW_V1.4E), PP-Module for Virtual Private Network (VPN) Gateways,
version 1.1, dated 01 July 2020 (MOD_VPNGW_V1.1) and PP-Module for Intrusion Prevention
Systems (IPS), Version 1.0, dated 11 May 2021 (MOD_IPS_V1.0).
The TOE identified in this VR 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 CPP_ND_V2.2E, MOD_CPP_FW_V1.4E,
MOD_VPNGW_V1.1 and MOD_IPS_V1.0. This VR 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 ETR are consistent with the evidence provided.
The validation team provided guidance on technical issues and evaluation processes and
reviewed the individual work units documented in the ETR and the Assurance Activities Report
(AAR). The validation team found that the evaluation showed that the product satisfies all of
the functional requirements and assurance requirements stated in the ST. Based on these
findings, the validation team concludes that the testing laboratory's findings are accurate, the
5
conclusions justified, and the conformance results are correct. The conclusions of the testing
laboratory in the ETR are consistent with the evidence produced.
6
2 Identification
The CCEVS is a joint National Security Agency (NSA) and National Institute of Standards and
Technology (NIST) 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 PP
containing assurance activities, which are an 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 IT products desiring a security evaluation
contract with a CCTL will 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 Junos OS 20.3R3 for NFX350
Protection Profile CPP_ND_V2.2E, MOD_CPP_FW_V1.4E, MOD_VPNGW_V1.1 and MOD_IPS_V1.0
Security Target Security Target Junos 20.3R3 for NFX350 Version 1.2
Evaluation Technical
Report
Evaluation Technical Report for Junos OS 20.3R3 NFX350
CC Version Version 3.1, Revision 5
Conformance Result CC Part 2 Extended and CC Part 3 Conformant
Sponsor Juniper Networks, Inc.
Developer Juniper Networks, Inc.
Common Criteria
Testing Lab (CCTL)
Acumen Security
2400 Research Blvd
Suite 395, Rockville, MD 20850,
USA
CCEVS Validators Jim Donndelinger
Meredith Hennan
DeRon Graves
The Aerospace Corporation
7
3 Architectural Information
The TOE is Juniper Networks, Inc. Junos OS 20.3R3 for NFX350 Network Services Platform. The NFX350 is
a network device that integrates routing, switching, and security functions on a single platform.
The NFX350 supports the definition of, and enforces, information flow policies among network nodes,
also providing for stateful inspection of every packet that traverses the network and central management
to manage the network security policy. All information flow from one network node to another passes
through an instance of the TOE. Information flow is controlled on the basis of network node addresses,
protocol, type of access requested, and services requested. In support of the information flow security
functions, the TOE ensures that security-relevant activity is audited, that functions are protected from
potential attacks, and that the security tools to manage all of the security functions are provided. The TOE
provides multi-site VPN gateway functionality, and also implements Intrusion Prevention System
functionality, capable of monitoring information flows to detect potential attacks based on pre-defined
attack signature and anomaly characteristics in the traffic.
The deployment of the Junos OS 20.3R3 for NFX350 TOE includes a hypervisor, which runs a Virtual
Machine (VM) on an NFX350 series hardware model:
• NFX350-S1
• NFX350-S2
• NFX350-S3
The TOE includes a Linux Operating System (OS), Junos Control Plane (JCP), a Juniper Device Manager
(JDM) and an Open vSwitch (OVS) bridge. NFX350 supports the installation of 3rd party VMs and
containers, but installation of 3rd party VMs and containers is not allowed in the evaluated
configuration. Error! Reference source not found. below shows the general architecture for the NFX350.
8
Figure 1 NFX350 Architecture
3.1.1 Linux OS
NFX350 is running on Wind River Linux 8 as its host OS. The host OS functions as a hypervisor and runs
natively on an Intel Xeon D processor.
3.1.2 Junos Control Plane
Junos Control Plane (JCP) is the Junos VM running on the host OS. JCP is used to configure the network
ports of the NFX350 device, and JCP runs by default as vjunos0 on NFX350. The JCP functions as the single
point of management for all the components. The JCP supports:
• Layer 2 to Layer 3 routing services
• Layer 3 to Layer 4 security services
• Layer 4 to Layer 7 advanced security services
In addition, the JCP enables virtualized network functions (VNF) lifecycle management. VNF is a virtualized
implementation of a network device and its functions. In the NFX350 NextGen architecture, Linux
functions as the hypervisor, and it creates and runs the VNFs. The VNFs include functions such as firewalls,
routers, and WAN accelerators.
The JCP VM is the single administration point for the NFX350 platform. It is the front-end for all
functionality provided by the NFX350 software. Logging in via console of SSH take the user to a CLI
prompt on the JCP VM. This CLI is the single point of configuration for all NFX350 services.
9
3.1.2.1 L2 Data Plane
L2 data plane manages the Layer 2 traffic. The L2 data plane forwards the LAN traffic to the OVS bridge.
The L2 data plane is mapped to the virtual FPC0 on the JCP.
3.1.2.2 L3 Data Plane
L3 data plane provides data path functions for the Layer 3 to Layer 7 services. The L3 data plane is
mapped to the virtual FPC1 on the JCP.
3.1.3 Juniper Device Manager (JDM)
JDM is an application container that manages VNFs and provides infrastructure services. The JDM
functions in the background. JDM is a low-footprint Linux container that provides these functions:
• Virtual Machine (VM) lifecycle management
• Device management and isolation of host OS from user installations
• NIC, single-root I/O virtualization (SR-IOV), and virtual input/output (VirtIO) interface
provisioning
• Inventory and resource management
• Internal network and image management
• Service chaining—provides building blocks such as virtual interfaces and bridges for users to
implement service chaining polices
• Virtual console access to VNFs including vSRX and vjunos
3.1.4 Open vSwitch (OVS) Bridge
The OVS bridge is a VLAN-aware system bridge that acts as the network functions virtualization
backplane to which the VNFs, FPC1, and FPC0 connect.
10
4 Security Policy
The logical boundary of the TOE includes the following security functionality:
Table 2 – TOE Logical Boundary Security Functionality
Security Functions The TOE provides the security functions required by the Collaborative
Protection Profile for Network Devices, hereafter referred to as NDcPP
v2.2e or NDcPP, the collaborative Protection Profile Module for Stateful
Traffic Filter Firewalls (MOD_CPP_FW_V1.4E), the PP-Module for Virtual
Private Network Gateways (MOD_VPNGW_V1.1) and the PP-Module for
Intrusion Prevention Systems (MOD_IPS_V1.0). Identified security
functions include Security Audit, Cryptographic Support, Identification
and Authentication, Security Management, Protection of the TSF, Toe
Access, Trusted Path/Channels, Firewall, VPN and IPS.
Protected Communications The TOE provides an SSH server to support protected communications for
administrators to establish secure sessions and to connect to external
syslog servers.
The TOE also supports IPsec connections to provide multi-site virtual
private network (VPN) gateway functionality and also as a tunnel for
remote administrate SSH connections. The TOE requires that applications
exchanging information with it are successfully authenticated prior to any
exchange (i.e. applications connecting over SSH and IPsec).
Telnet, File Transfer Protocol (FTP), and Secure Socket Layer (SSL) are out
of scope.
The TOE includes cryptographic modules that provide the underlying
cryptographic services, including key management and protection of
stored keys, algorithms, random bit generation and crypto-
administration. The cryptographic modules provide confidentiality and
integrity services for authentication and for protecting communications
with adjacent systems.
Administrator Authentication Administrative users must provide unique identification and
authentication data before any administrative access to the system is
granted. Authentication data entered and stored on the TOE is protected.
The TOE can be configured to terminate interactive user sessions and to
present an access banner with warning messages prior to authentication.
Correct Operation The TOE provides for both cryptographic and non-cryptographic self-tests
and is capable of automated recovery from failure states.
Trusted Update The administrator can initiate update of the TOE software. The integrity
of any software updates is verified prior to installation of the updated
software.
Audit TOE auditable events are stored in the syslog files in the VM filesystem
and can be sent to an external log server (via Netconf over SSH).
Auditable events include start-up and shutdown of the audit functions,
authentication events, service requests, IPS events, as well as the events
listed in Table 12 and Table 13 of the ST. Audit records include the date
and time, event category, event type, username, and the outcome of the
11
event (success or failure). Local (VM) syslog storage limits are
configurable and are monitored. In the event of storage limits being
reached the oldest logs will be overwritten.
Management The TOE provides a Security Administrator role that is responsible for:
• the configuration and maintenance of cryptographic elements
related to the establishment of secure connections to and from
the evaluated product
• the regular review of all audit data;
• initiation of trusted update function;
• administration of VPN, IPS and Firewall functionality;
• all administrative tasks (e.g., creating the security policy).
The devices are managed through a Command Line Interface (CLI). The CLI
is accessible through local (serial) console connection or remote
administrative (SSH) session.
The Security Administrator role includes the capability to manage all
NFX350 services. Access to manage the device’s FreeBSD host can only
be gained through the JCP.
Packet Filtering/Stateful Traffic
Filtering
The TOE provides stateful network traffic filtering based on examination of
network packets and the application of information flow rules.
Intrusion Prevention The TOE can be configured to analyze IP-based network traffic forwarded
to the TOE’s interfaces and detect violations of administratively-defined
IPS policies. The TOE is capable of initiating a proactive response to
terminate/interrupt an active potential threat, and to initiate a response
in real time that would cause interruption of the suspicious traffic flow.
User Data Protection/Information
Flow Control
The TOE is designed to forward network packets (i.e., information flows)
from source network entities to destination network entities based on
available routing information using Virtual Routers. This information is
either provided directly by TOE users or indirectly from other network
entities (outside the TOE) configured by the TOE users. The TOE has the
capability to regulate the information flow across its interfaces; traffic
filters can be set in accordance with the presumed identity of the source,
the identity of the destination, the transport layer protocol, the source
service identifier, and the destination service identifier (TCP or UDP port
number).
4.1 Non-TOE hardware/software/firmware
The TOE relies on the provision of the following items in the network environment:
12
• Syslog server supporting SSHv2 connections to send audit logs;
• SSHv2 client for remote administration;
• Serial connection client for local administration.
• IPsec peer
13
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.
The assumptions included in 3 are drawn directly from PP and any relevant
EPs/Modules/Packages.
Table 3 – Assumptions
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 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 does not include any
requirements on physical tamper protection or
other physical attack mitigations. The cPP does
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. For vNDs, this assumption applies to the
physical platform on which the VM runs.
14
ID Assumption
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 a computing platform
for general purpose applications (unrelated to
networking functionality).
(NOTE: following paragraph is for virtual
network devices. Please delete if the TOE is not
a virtual device)
In the case of vNDs, the VS is considered part of
the TOE with only one vND instance for each
physical hardware platform. The exception
being where components of the distributed
TOE run inside more than one virtual machine
(VM) on a single VS. There are no other guest
VMs on the physical platform providing non-
Network Device functionality.
A.NO_THRU_TRAFFIC_PROTECTION1 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).
1
A.NO_THRU_TRAFFIC_PROTECTION is still operative, but only for the interfaces in the TOE that are defined by the Base-
PP and not the PP-Module.
15
ID Assumption
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 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.
(The paragraph that follows is for x509v3 cert-
based authentication. If not relevant, remove)
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 trust store (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.
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.
A.CONNECTIONS (IPS) It is assumed that the TOE is connected to
distinct networks in a manner that ensures that
16
ID Assumption
the TOE security policies will be enforced on all
applicable network traffic flowing among the
attached networks.
A.CONNECTIONS (VPN) It is assumed that the TOE is connected to
distinct networks in a manner that ensures that
the TOE security policies will be enforced on all
applicable network traffic flowing among the
attached networks.
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.
The threats included in Table 4 are drawn directly from the PP and any EPs/Modules/Packages
specified in Section 2.2 of the ST.
Table 4 – Threats
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
17
ID Threat
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 tunnelling 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
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
18
ID Threat
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.
T.NETWORK_DISCLOSURE (FFW) An attacker may attempt to “map” a
subnet to determine the machines that
reside on the network, and obtaining the IP
addresses of machines, as well as the
services (ports) those machines are
offering. This information could be used to
mount attacks to those machines via the
services that are exported.
T.NETWORK_ACCESS (FFW) With knowledge of the services that are
exported by machines on a subnet, an
19
ID Threat
attacker may attempt to exploit those
services by mounting attacks against those
services.
T.NETWORK_MISUSE (FFW) An attacker may attempt to use services
that are exported by machines in a way
that is unintended by a site’s security
policies. For example, an attacker might be
able to use a service to “anonymize” the
attacker’s machine as they mount attacks
against others.
T.MALICIOUS TRAFFIC (FFW) An attacker may attempt to send
malformed packets to a machine in hopes
of causing the network stack or services
listening on UDP/TCP ports of the target
machine to crash.
T.NETWORK_DISCLOSURE (IPS) Sensitive information on a protected
network might be disclosed resulting from
ingress- or egress-based actions.
T.NETWORK_ACCESS (IPS) Unauthorized access may be achieved to
services on a protected network from
outside that network, or alternately
services outside a protected network from
inside the protected network. If malicious
external devices are able to communicate
with devices on the protected network via
a backdoor then those devices may be
susceptible to the unauthorized disclosure
of information.
T.NETWORK_MISUSE (IPS) Access to services made available by a
protected network might be used counter
to Operational Environment policies.
Devices located outside the protected
network may attempt to conduct
inappropriate activities while
communicating with allowed public
services. E.g. manipulation of resident
tools, SQL injection, phishing, forced resets,
malicious zip files, disguised executables,
privilege escalation tools and botnets.
20
ID Threat
T.NETWORK_DOS (IPS) Attacks against services inside a protected
network, or indirectly by virtue of access to
malicious agents from within a protected
network, might lead to denial of services
otherwise available within a protected
network. Resource exhaustion may occur
in the event of co-ordinate service request
flooding from a small number of sources .
T.DATA INTEGRITY (VPN) Devices on a protected network may be
exposed to threats presented by devices
located outside the protected network,
which may attempt to modify the data
without authorization. If known malicious
external devices are able to communicate
with devices on the protected network or if
devices on the protected network can
communicate with those external devices
then the data contained within the
communications may be susceptible to a
loss of integrity.
T.NETWORK_ACCESS (VPN) Devices located outside the protected
network may seek to exercise services
located on the protected network that are
intended to only be accessed from inside
the protected network or only accessed by
entities using an authenticated path into
the protected network. Devices located
outside the protected network may,
likewise, offer services that are
inappropriate for access from within the
protected network.
From an ingress perspective, VPN gateways
can be configured so that only those
network servers intended for external
consumption by entities operating on a
trusted network (e.g., machines operating
on a network where the peer VPN
gateways are supporting the connection)
are accessible and only via the intended
ports. This serves to mitigate the potential
for network entities outside a protected
21
ID Threat
network to access network servers or
services intended only for consumption or
access inside a protected network.
From an egress perspective, VPN gateways
can be configured so that only specific
external services (e.g., based on destination
port) can be accessed from within a
protected network, or moreover are
accessed via an encrypted channel. For
example, access to external mail services
can be blocked to enforce corporate
policies against accessing uncontrolled e-
mail servers, or, that access to the mail
server must be done over an encrypted
link.
T.NETWORK_ACCESS (VPN) Devices located outside the protected
network may seek to exercise services
located on the protected network that are
intended to only be accessed from inside
the protected network or only accessed by
entities using an authenticated path into
the protected network. Devices located
outside the protected network may,
likewise, offer services that are
inappropriate for access from within the
protected network.
From an ingress perspective, VPN gateways
can be configured so that only those
network servers intended for external
consumption by entities operating on a
trusted network (e.g., machines operating
on a network where the peer VPN
gateways are supporting the connection)
are accessible and only via the intended
ports. This serves to mitigate the potential
for network entities outside a protected
network to access network servers or
services intended only for consumption or
access inside a protected network.
From an egress perspective, VPN gateways
can be configured so that only specific
22
ID Threat
external services (e.g., based on destination
port) can be accessed from within a
protected network, or moreover are
accessed via an encrypted channel. For
example, access to external mail services
can be blocked to enforce corporate
policies against accessing uncontrolled e-
mail servers, or, that access to the mail
server must be done over an encrypted
link.
T.NETWORK_DISCLOSURE (VPN) Devices on a protected network may be
exposed to threats presented by devices
located outside the protected network,
which may attempt to conduct
unauthorized activities. If known malicious
external devices are able to communicate
with devices on the protected network, or
if devices on the protected network can
establish communications with those
external devices (e.g., as a result of a
phishing episode or by inadvertent
responses to email messages), then those
internal devices may be susceptible to the
unauthorized disclosure of information.
From an infiltration perspective, VPN
gateways serve not only to limit access to
only specific destination network addresses
and ports within a protected network, but
whether network traffic will be encrypted
or transmitted in plaintext. With these
limits, general network port scanning can
be 8 prevented from reaching protected
networks or machines, and access to
information on a protected network can be
limited to that obtainable from specifically
configured ports on identified network
nodes (e.g., web pages from a designated
corporate web server). Additionally, access
can be limited to only specific source
addresses and ports so that specific
networks or network nodes can be blocked
from accessing a protected network
23
ID Threat
thereby further limiting the potential
disclosure of information.
From an exfiltration perspective, VPN
gateways serve to limit how network nodes
operating on a protected network can
connect to and communicate with other
networks limiting how and where they can
disseminate information. Specific external
networks can be blocked altogether or
egress could be limited to specific
addresses and/or ports. Alternately, egress
options available to network nodes on a
protected network can be carefully
managed in order to, for example, ensure
that outgoing connections are encrypted to
further mitigate inappropriate disclosure of
data through packet sniffing.
T.NETWORK_MISUSE (VPN) Devices located outside the protected
network, while permitted to access
particular public services offered inside the
protected network, may attempt to
conduct inappropriate activities while
communicating with those allowed public
services. Certain services offered from
within a protected network may also
represent a risk when accessed from
outside the protected network.
From an ingress perspective, it is generally
assumed that entities operating on external
networks are not bound by the use policies
for a given protected network.
Nonetheless, VPN gateways can log policy
violations that might indicate violation of
publicized usage statements for publicly
available services.
From an egress perspective, VPN gateways
can be configured to help enforce and
monitor protected network use policies. As
explained in the other threats, a VPN
gateway can serve to limit dissemination of
data, access to external servers, and even
24
ID Threat
disruption of services – all of these could be
related to the use policies of a protected
network and as such are subject in some
regards to enforcement. Additionally, VPN
gateways can be configured to log network
usages that cross between protected and
external networks and as a result can serve
to identify potential usage policy violations.
T.REPLAY_ATTACK (VPN) If an unauthorized individual successfully
gains access to the system, the adversary
may have the opportunity to conduct a
“replay” attack. This method of attack
allows the individual to capture packets
traversing throughout the network and
send the packets at a later time, possibly
unknown by the intended receiver. Traffic
is subject to replay if it meets the following
conditions:
Cleartext: an attacker with the ability to
view unencrypted traffic can identify an
appropriate segment of the
communications to replay as well in order
to cause the desired outcome.
No integrity: alongside cleartext traffic, an
attacker can make arbitrary modifications
to captured traffic and replay it to cause
the desired outcome if the recipient has no
means to detect these.
5.3 Clarification of Scope
All evaluations (and all products) have limitations, as well as potential misconceptions needing
clarification. This text covers some of the more important limitations and clarifications of this
evaluation. Note that:
• As with any evaluation, this evaluation covers only the specific device models and
software as identified in this document, and not any earlier or later versions released or
in process. The level of assurance for this evaluation is defined within the
CPP_ND_V2.2E, MOD_CPP_FW_V1.4E, MOD_VPNGW_V1.1 and MOD_IPS_V1.0.
• Apart from the Admin Guide, additional customer documentation for the specific TOE
models was not included in the scope of the evaluation and therefore should not be
relied upon when configuring or operating the device as evaluated.
25
• 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.
• The evaluation of security functionality of the product was limited to the Security
functionality requirements and applicable TDs specified in the claimed PPs. Any
additional non-security related functional capabilities of the product were not covered
by this evaluation.
5.3.1 Product Functionality not Included in the Scope of the Evaluation
The following product functionality is not included in the CC evaluation:
• Use of telnet, since it violates the Trusted Path requirement set
• Use of FTP, since it violates the Trusted Path requirement set
• Use of SNMP, since it violates the Trusted Path requirement set
• Use of SSL, including management via J-Web, JUNOScript and JUNOScope, since it
violates the Trusted Path requirement set
• Use of CLI account super-user and linux root account.
• Hosting additional VMs on the TOE physical platform.
26
6 Documentation
The following guidance documents were provided by the vendor with the TOE for evaluation:
• Common Criteria Configuration Guide for NFX350 Network Services Platform Release
20.3R3, June 13th,2022
Any additional customer documentation provided with the product, or that is available online
was not included in the scope of the evaluation and therefore should not be relied upon when
configuring or operating the device as evaluated.
To use the product in the evaluated configuration, the product must be configured as specified
in the Guidance Documentation listed above. Consumers are encouraged to download the
configuration guides from the NIAP website to ensure the device is configured as evaluated
27
7 TOE Evaluated Configuration
7.1 Evaluated Configuration
This evaluation is for the Junos OS 20.3R3 for NFX350 series network devices, Models: NFX350-S1,
NFX350-S2, and NFX350-S3 running Junos version 20.3R3 configured in accordance with the
documentation identified in Section 6 of this report.
28
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 Junos OS 20.3R3 for NFX350, which is
not publicly available. The AAR Section 6 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 to the vendor-provided guidance
documentation and ran the tests specified in the CPP_ND_V2.2E, MOD_CPP_FW_V1.4E,
MOD_VPNGW_V1.1 and MOD_IPS_V1.0. The Test configuration diagram and list of test tools
used during the evaluation can be found in AAR Section 6 page 145, which is publicly available,
and is not duplicated here.
29
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 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 Junos OS 20.3R3
NFX350 to be Part 2 extended, and meets the SARs contained in the PP. Additionally, the
evaluator performed the assurance activities specified in the NDPP.
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 Junos OS 20.3R3 for NFX350 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 CPP_ND_V2.2E, MOD_CPP_FW_V1.4E, MOD_VPNGW_V1.1 and
MOD_IPS_V1.0.
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.2 Evaluation of Development Documentation
The evaluation team applied each EAL 1 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 ST's TSS. Additionally, the evaluator performed the assurance activities specified in the
CPP_ND_V2.2E, MOD_CPP_FW_V1.4E, MOD_VPNGW_V1.1 and MOD_IPS_V1.0 related to the
examination of the information contained in the TOE Summary Specification.
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 assurance activities, and that the conclusion reached by the evaluation
team was justified.
9.3 Evaluation of Guidance Documents
The evaluation team applied each EAL 1 AGD CEM work unit. The evaluation team ensured the
30
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 CPP_ND_V2.2E, MOD_CPP_FW_V1.4E, MOD_VPNGW_V1.1
and MOD_IPS_V1.0 related to the examination of the information contained in the operational
guidance documents.
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 assurance activities, and that the conclusion reached by
the evaluation team was justified.
9.4 Evaluation of Life Cycle Support Activities
The evaluation team applied each EAL 1 ALC CEM work unit. The evaluation team found
that the TOE was identified.
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 EAL 1 ATE CEM work unit. The evaluation team ran the set of
tests specified by the assurance activities in the CPP_ND_V2.2E, MOD_CPP_FW_V1.4E,
MOD_VPNGW_V1.1 and MOD_IPS_V1.0 and recorded the results in a Test Report, summarized
in the ETR and AAR.
The validator reviewed the work of the evaluation team and found that sufficient evidence was
provided by the evaluation team to show that the evaluation activities addressed the test
activities in the CPP_ND_V2.2E, MOD_CPP_FW_V1.4E, MOD_VPNGW_V1.1 and MOD_IPS_V1.0,
and that the conclusion reached by the evaluation team was justified.
9.6 Vulnerability Assessment Activity
The evaluation team applied each EAL 1 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. The summary of vulnerability assessment and testing can be found in the AAR
Section 7.6, latest search was run on June 9th, 2022.
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 addressed the
vulnerability analysis assurance activities in the CPP_ND_V2.2E, MOD_CPP_FW_V1.4E,
31
MOD_VPNGW_V1.1 and MOD_IPS_V1.0, and that the conclusion reached by the evaluation
team was justified.
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
CPP_ND_V2.2E, MOD_CPP_FW_V1.4E, MOD_VPNGW_V1.1 and MOD_IPS_V1.0, and correctly
verified that the product meets the claims in the ST.
32
10 Validator Comments & Recommendations
Validation team notes that the syslog server must have an SSH client with NETCONF support configured
to receive the streamed syslog messages.
33
11 Annexes
Not applicable.
34
12 Security Target
Security Target Junos 20.3R3 for NFX350 Version 1.2, June 20th, 2022
35
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.
36
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. Security Target Junos 20.3R3 for NFX350 Version 1.2, June 20th, 2022
6. Common Criteria Configuration Guide for NFX350 Network Services Platform Release
20.3R3, June 13th, 2022
7. Evaluation Technical Report for Junos OS 20.3R3 for NFX350 Version 1.2, June 20th, 2022
8. Assurance Activity Report for Junos OS 20.3R3 for NFX350 Version 1.2, June 20th, 2022