CC Certificate 

Security Target 

Validation Report 

Assurance Activity 

Administrative Guide: Common Criteria Guide for vSRX3.0 

Administrative Guide: Junos® OS Software Installation and Upgrade Guide 

Administrative Guide: vSRX Virtual Firewall Deployment Guide for Private and Public Cloud 

Administrative Guide: IPsec VPN User Guide 

Administrative Guide: Attack Detection and Prevention User Guide for Security Devices 

Administrative Guide: Junos ® OS Flow-Based and Packet-Based Processing User Guide for Security Devices 

Administrative Guide: Intrusion Detection and Prevention User Guide 

Administrative Guidance: PublicKey Infrastructure Feature Guide for Security Devices 

The TOE is the Juniper Networks, Inc. Juniper vSRX3.0 with Junos OS 22.2R2 Virtual Firewall. It is intended for deployment with service providers and large enterprises. The TOE may be operated in single mode or in cluster mode. Cluster mode is a High Availability (HA) mode in which two instances of a TOE are connected and configured to operate like a single device. This ensures high availability in the case of equipment malfunction in one of the devices.

The TOE allows definition of packet filtering policies which are enforced on all traffic traversing to, from or through it. Each packet is also subjected to stateful inspection. Further security is added by an intrusion prevention function. All traffic is monitored against signatures of known attacks and for abnormalities in traffic patterns. If potentially malicious traffic is detected, protective action is taken. Security policies are managed, and the TOE configuration controlled by Security Administrators. Management occurs via a Command Line Interface (CLI) from a local or remote management station.

The TOE is deployed as a gatekeeper between two networks so that all traffic between the two networks passes through an instance of the TOE. This ensures that all traffic between the two networks is subject to the security policies the TOE enforces. Traffic and information flows are controlled based on the rules set by TOE Administrators concerning network node addresses, protocol, type of access requested, and the service requested. The TOE implements a default deny rule, i.e. it drops any network traffic not explicitly allowed by the rules. All security relevant activities and events are audited.

Additionally, the TOE implements a multi-site Virtual Private Network (VPN) gateway functionality for tunneling traffic between itself and a VPN peer. In Cluster Mode, the link between the two instances of TOE may also be secured with IPsec. If the audit records are forwarded to an external syslog server, the connection between the TOE and the syslog server may be protected with SSH. The connection between the TOE and a remote management station is also protected by SSH.

TOE software is deployed with a hypervisor and a x86 server. The user configures the hypervisor on the selected server and installs the TOE software on the hypervisor. The software is downloaded from the Juniper web site. TOE Software is protected with a digital signature and hash values. The TOE verifies the signatures and hash values at the boot up and executes a full suite of self-tests to ensure that the TOE functions correctly and only authentic TOE software is executed.

The evaluated configuration consists of the following:

TOE Software:

·        Junos OS 22.2R2 for vSRX3.0 software, including the vSRX3.0 Virtual Machine

TOE Hardware must have at least the number of NICs as there are vNICs configured in the TOE. It must be one of the following:

·        HP ProLiant DL380p Gen9 with Intel Xeon E5-2600 v4 series

·        PacStar 451 with Intel Xeon E-2200M series

The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme. The criteria against which the Juniper vSRX3.0 with Junos OS 22.2R2 was evaluated are described in the Common Criteria for Information Technology Security Evaluation, Version 3.1 rev 5.  The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 rev 5.

The product, when delivered configured as identified in the Common Criteria Guide for vSRX3.0, Release 22.2R2, December 13, 2023, satisfies all of the security functional requirements stated in the Juniper vSRX3.0 with Junos OS 22.2R2 Security Target, Version 0.9, December 14,2023. The project underwent CCEVS Validator review.  The evaluation was completed in September 2023.  Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report prepared by CCEVS.

The security functions the TOE implements are summarized in the following sections.

Security Audit

The TOE implements an audit function which generates an audit record for each auditable event. Audit logs containing audit records are stored in protected syslog files in the VM filesystem. Syslog files may be forwarded to an external log server via Netconf over SSH.

Auditable events include start-up and shutdown of the audit functions, authentication events, configuration changes, management operations on cryptographic keys, resetting of passwords, IPS events, service requests, and other event listed in Table 9 and Table 10 of the Security Target. Audit records include, where applicable, the date and time of the event, event category, event type, username of the user causing the event, and the success or failure of the event.

The amount of storage available for local syslog files is configurable by the Administrator. The TOE monitors the size of the syslog file against the configured limits. If the storage limit is reached, the TOE shall overwrite the existing audit records. The oldest audit records shall be overwritten first.

Cryptographic Support

The TOE implements IPSec with Internet Key Exchange IKEv1 and IKEv2 as well as SSH to protect communication with peer entities. All required cryptographic algorithms, key management functions and random bit generation methods are implemented by the TOE.

IPSec is implemented in tunnel mode with the payload encrypted with AES in GCM, CBC and CTR modes with 128-bit, 192-bit and 256-bit key lengths using HMAC-SHA-256. The symmetric keys used for IPSec are generated using IKEv1 and IKEv2. The TOE implements a random bit generator which generates the secret exponent for use in IKE DH-key exchange. Random bits are generated using HMAC-DRBG seeded by hardware and software noise sources.

Both RSA and ECDSA are implemented. DH Groups 14, 19 and 20 are implemented and the secret exponent is generated to be of appropriate length for each, i.e. 112 bits for DH Group 14, 128 bits for DH Group 19 and 192 bits for DH Group 20. The random number generator is also used for generating the nonces. Both RSA and ECDSA may be used for peer authentication with RFC 4945-conformant X.509 certificates in the IKE exchange. Pre-shared keys may also be used.

SSH is implemented in accordance with the relevant RFC suite. Both public key based and password based authentication are implemented. Public key authentication uses ECDSA with SHA on NIST curve P-256, P-384 or P-521. Key exchange may additionally use DH Group 14 with SHA-1. AES is used for protecting the payload in CBC or CTR mode with a 128-bit or 256-bit key and with HMAC-SHA1, HMAC-SHA2-256 or HMAC-SHA2-256 as data integrity algorithm. Maximum key life-time is one hour or at most one GB of data. After any of the thresholds are met, a rekeying shall be performed. Cryptographic keys are destroyed both from the volatile and the non-volatile memory when no longer required.

Identification and Authentication

Identification and authentication concerns with human users and with the peer entities of the TOE. Human users are identified with a user name and authenticated with a password. IPsec peer entities are identified by a Security Association (SA) established by IKE and authenticated using X.509 certificates or pre-shared key. SSH peer entities are identified by IP address and authenticated by a public key protocol or a password.

Human users accessing the TOE from the console are authenticated by password. When human users access the TOE from a remote management station the TOE first establishes an SSH connection between the management workstation and itself, then authenticates the human user over the SSH connection with a password.

When authenticating peer entities for VPN connection establishment, the TOE first authenticates the IPSec peer entity using X.509 certificates or pre-shared keys, and then the SSH peer entity using public-key or password based authentication. Upon successful IPSec and SSH peer entity authentication the TOE establishes a VPN session with SSH tunneled over IPSec.

The TOE may have several human users but only implements a single role, Security Administrator. Each user has a unique user name and a password which shall be entered to the TOE for identification and authentication. The password should be known only to the user and is not displayed in clear by the TOE. Only upon successful identification and authentication shall the user be assigned to the role of a Security Administrator. The TOE displays a warning banner at the authentication window to inform the users of the restrictions on access and of the consequences of unauthorized use.

If a user authentication attempt fails, the user is required to re-attempt authentication. The TOE keeps track of the number of failed attempts and compares it to an Administrator-configured number of maximum allowed authentication attempts. If the maximum number is met, the TOE shall prevent the user from establishing any remote sessions with the TOE until an Administrator-defined time-out period has elapsed.

Users may select their own password, but the TOE only accepts them if they meet a defined quality criterion. A password must contain characters of at least two of the character groups (upper case letters, lower case letters, numbers, and special characters). The length of a password must be at least the minimum length configured by Administrators but not less than ten characters.

The TOE implements X.509 authentication for IPSec peers. Alternatively, pre-shared key based authentication may be used. X.509 certificates are validated against pre-defined rules and require a minimum path length of three certificates. The certificates are validated from the Root CA upon the TOE receiving a CA Certificate Response. In case the TOE cannot establish the validity of a certificate, the Administrator is prompted to reject or accept the certificate.

Security Management

The TOE implements a rich Command Line Interface (CLI) the Administrators (i.e. users successfully authenticated and assigned to the role Security Administrator) may use to configure and manage the TOE. No other method of management but the CLI exists. All security management functions are available to the Administrators via the CLI locally from the console or remotely over SSH.

Protection of the TSF

The TOE ensures that the cryptographic keys and passwords are stored in a secure manner.

The TOE provides a reliable timestamp for its own use. The reliable timestamp can be set by a security administrator or authenticated NTP.

Cryptographic keys may only be accessed by authorized processes. Keys are erased when no longer required. Passwords are hashed before storage and may not be recovered to. When a password is read from a user, it is obscured on the screen and hashed prior to comparison to the stored password.

TOE Software is associated to a digital signature and a hash value. The signature and the hash value may be used by Administrators to verify the integrity of the software. In case of an upgraded software being made available by the developers, the Administrator may download the upgraded software from the developer's web site for installation on the TOE. The upgrade is associated with a digital signature which must be successfully verified prior to the installation of the upgrade.

The TOE also implements a set of critical self-tests at the start-up. These tests include power-on tests, file integrity test, cryptographic function and key integrity test, authentication test, known answer tests for cryptographic algorithms, and health tests for the noise sources used in the random bit generation. If any of the power-on self-tests, verification of the TOE software digital signature, or the testing of the noise source health fails, the TOE shall shut itself down as a defensive measure.

TOE Access

The TOE implements measures to ensure that inactive sessions may not be used by unauthorized users. The TOE keeps track of session inactivity and terminates any session where the maximum inactivity time has been reached. The CLI used for administering the TOE includes a logout call which the users may use to terminate their own sessions.

The TOE also displays an access banner at each authentication exchange. The access banner may be configured by the Administrators and contains an advisory notice and consent warning informing users of the legitimate use of the TOE and the sanctions for attempts of unauthorized use.

Trusted Path/Channels

The TOE implements a VPN gateway functionality which allows a trusted channel between itself and VPN peers for tunneling network traffic. The VPN peer may request a VPN connection between itself and the TOE. The VPN connection is an SSH connection tunneled over IPSec.

In Cluster Mode, the Administrators may configure the communication between the two nodes to be protected with IPsec.

The TOE also implements an SSH server for a trusted path between itself and a remote management station. The management station may request establishment of an SSH connection. Upon successful connection establishment, all communication between the remote management station and the TOE, including the authentication exchange between the user and the TOE as well as all subsequent CLI commands, shall be exchanged over SSH.

Packet Filtering

Administrators may define rules for the TOE to use to filter each TCP/IP packet. The rules may be assigned to any network interface. Each packet is inspected individually, and the TOE ensures that each packet is erased from the buffer it is stored for inspection prior to the storage of the next packet in the same buffer. This ensures that each inspection is only on the fields of the packet and no residual information from previously inspected packets influences the inspection.

Packet filtering rules may be defined on IPv4, IPv6, TCP and UDP header information. IP packet rules may use source and destination addresses as well as the protocol (or next header in IPv6). TCP and UDP datagrams are filtered by rules using source and destination ports. Each packet is handled according to the first matching rule in the rule base. Any traffic for which there is no matching rule shall be dropped. For a matching rule, the TOE shall permit the packet depending on the rule and may also log the event.

Firewall

Administrators of the TOE may also define rules for stateful traffic filtering of network traffic based on ICMPv4, ICMPv6, IPv4, IPv6, TCP and UDP protocol fields. Rules may be defined for each network port of the TOE individually. The TOE inspects all incoming and outgoing traffic against those rules and permits or denies the traffic based on the rules. Additional rules are enforced to ensure that traffic which is illegitimate on high likelihood shall be dropped and a log entry generated. The rules are examined in order and the traffic is examined and filtered according to the first matching rule. If no rule matches the traffic, the traffic shall be dropped.

Intrusion Prevention

The TOE implements intrusion prevention capabilities to prevent potentially malicious network traffic from reaching the protected network. The capabilities are implemented by three distinct means:

·        The TOE allows Administrators to define lists of known-good and known-bad IP source and destination addresses. Any IP datagram matching an entry in the known-bad list shall be dropped and any IP datagram matching an entry in the known-good list shall be allowed.

·        The TOE maintains a list of attack signature on network traffic headers and payload and inspects all network traffic against those attack signatures. Administrator action is not required to define the rules, but the Administrator may configure the TOE action taken when traffic matches an attack signature. The Administrator may decide to allow the traffic flow, send a TCP reset to the source or destination of the malicious traffic, or block the traffic flow.

Administrators may also define patterns for regular network traffic and express threshold values indicating a deviation from the expected, regular traffic. Deviations may occur because of an unusual traffic volume, an unusual time of the day, or an unusual frequency of traffic. Upon detecting a deviation from regular traffic, the TOE shall take Administrator-configured action to prevent the potentially malicious traffic from reaching the protected network.  

Vendor Information