CC Certificate 

Security Target 

Validation Report 

Assurance Activity 

Administrative Guide 

Viasat’s Secure VPN virtual Network Device (TOE) is a Virtualized Network Device executing on Windows Hyper-V virtual machine manager running on the Windows 10 Pro 22H2 Operating System and is intended to provide bump-in-the-wire IPsec encryption to virtual or physical systems deployed behind the device on the Plaintext network.

The TOE has only one evaluated configuration. The evaluated configuration consists of the Hardware Platform and Software Platform listed in Section 1.3.4 of the Security Target and the TOE software as described in Section 1.4.1 of the Security Target, in conjunction with the administrative configuration as described in the Guidance Documentation. The evaluated configuration is a ‘Case 1’ evaluated configuration as described in [cPP] Section 1.2, where the TOE is represented by the vND alone. The evaluated configuration includes the vND and the Virtualization System (VS) where the VS encompasses the virtual hardware abstraction, the hypervisor or virtual machine manager (VMM) and the physical chassis. No other evaluated configurations are expressed or implied.

The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme. The criteria against which the TOE was evaluated are described in the Common Criteria for Information Technology Security Evaluation, Version 3.1 Release 5.  The Common Methodology for Information Technology Security Evaluation, Version 3.1 Revision 5, was used by the CCTL to conduct the evaluation.  The product, when configured as identified in the Administrative Guidance documentation, satisfies the security functional requirements stated in the Viasat Secure VPN v1.1.7 Security Target. The project underwent CCEVS Validator review.  The evaluation was completed in October 2023.  Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report prepared by CCEVS.

Audit

·     The TOE:

      o   Generates audit records for all required security relevant events.

o   Includes in each audit record the identity of the user that caused the event (if applicable), date and time of the event, type of event, and the outcome of the event.

o   Protects storage of audit information from unauthorized deletion.

o   Prevents unauthorized modifications to the stored audit records.

o   Can transmit audit data to/receive data from an external IT entity using the TLS protocol.

o   Performs audit log rotation when the local storage of audit records is full.

o   Counts the number of audit records that are overwritten when the local storage space for audit records is full.

Cryptography

    ·   The TSF performs the following cryptographic operations:

o   For TLS as a client and server, supporting the following cryptographic algorithms:

  ·        Supports the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuite consisting of the following cryptographic services:

·        ECDSA digital signature generation/verification

·        AES-256 in GCM mode for bulk data ciphering

·        ECDHE key exchange utilizing the secp384r1 elliptic curve

·        SHA-384 hashing primitive

·        HMAC-SHA2-384 for keyed hashing

·        The TLS client TSF supports mutual authentication utilizing x.509v3 PKI.

o   For IPsec, the TSF supports the following:

·        ECDSA digital signature generation/verification for IKEv2 supporting NIST P-256 and P-384 curves.

·        AES-GCM-256 algorithm for encryption and message authentication for the IPsec ESP protocol

·        AES-GCM-256 or AES-CBC-256 to protect the IKEv2 payload

·        HMAC-SHA-384 to authenticate the IKEv2 payload

·        Diffie-Hellman groups 19 and 20 for use in IKEv2

·        IPv4 only; IPv6 is not supported for IPsec

o   The TSF utilizes a CTR_DRBG using AES-256, as its source for secure random bit generation.

o   The Trusted Update TSF utilizes ECDSA digital signatures associated with x.509v3 certificates using P-384 curve.

o   The TSF zeroizes all plaintext secret and private cryptographic keys and CSPs once they are no longer required.

Identification and Authentication

      ·     The TSF:

                  o   Supports passwords consisting of alphanumeric and special characters.

o   Allows the Security Administrator (SA) to set a minimum password length.

o   Will lock out offending accounts that fail to successfully authenticate after an administratively defined number failed authentication attempts that the remote management interface. The offending account will be unlocked after an administratively configurable amount of time elapses.

o   Provides a local console management interface that is accessible via username and password authentication

o   Does not echo back characters input for the password at the local console

o   Utilizes x.509v3 certificates to identify itself to remote management users via the trusted path (HTTPS Server).

o   Utilizes x.509v3 certificate-based authentication to support a mutually authenticated trusted channel to a remote audit logging server (TLS client with mutual authentication).

o   Utilizes x.509v3 certificates for authentication of system software updates.

o   Supports the generation of Certificate Signing Requests.

o   Requires all administrative-users to authenticate before allowing the user to perform any actions other than:

                  ·  Viewing the warning banner

·  Automated generation of cryptographic keys

·  ICMP echo reply (when configured in packet filtering table by the SA)

·  Responding to ARP requests with ARP replies

·  Packet forwarding through the IPsec tunnel (when configured by the SA)

·  Packet forwarding through BYPASS packet filtering table (when configured by the SA)

Security Management

    ·   The TSF stores and protects the following data:

  o   Local audit records, user account data, and local authentication data (such as administrator passwords)

o   Cryptographic keys including symmetric keys, and private keys.

o   There is one class of user on the TOE:

o   Security Admin user

o   Management of the TSF:

o   The administrator can perform manual updates, determine the behavior of or modify the behavior of the handling of audit data, modify the behavior of the TSF, enable or disable services offered by the TOE, manage TSF data, modify, delete, generate or import cryptographic keys, configure the access banner, manage packet filtering and configure the session inactivity timeout period.

o   The administrator may perform these functions locally or remotely via the Command Line Interface (CLI) or Remote Management Interface (RMI)

Protection of the TSF

·   The TSF:

  o   Prevents the reading of secret and private keys.

o   Provides reliable time stamps for itself.

o   Runs a suite of self-tests during the initial start-up (upon power on) to demonstrate the correction operation of the TSF.

o   Provides a means to verify firmware/software updates to the TOE using a digital signature mechanism prior to installing those updates.

Packet Filtering

·   The TSF:

o   Can be configured to filter network packets based on IPv4, IPv6, TCP and UDP protocols.

o   Can only DROP and LOG IPv6 packets.

o   Can be configured to log network packets that match a packet filter rule.

o   Processes packet filter rules in an administratively defined order.

o   Can apply Packet filtering rules to any network interface of the TOE.

o   Has a final ‘drop’ rule if no rule matches the packet being processed.

TOE Access

·   The TOE:

o   For local interactive sessions, terminates active session after an Authorized Administrator-specified period of session inactivity.

o   Terminates a remote interactive session after an Authorized Administrator-configurable period of session inactivity.

o   Allows Administrator-initiated termination of the Administrator’s own interactive session.

o   Is capable of displaying an Authorized Administrator-specified advisory notice and consent warning message regarding unauthorized use of the TOE before establishing an administrative user session.

Trusted Path/Channels

·   The TOE:

o   Uses IPsec, and TLS to provide a trusted communication channel between itself and all authorized IT entities that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.

o   Permits the TSF, or the authorized IT entities to initiate communication via the trusted channel.

o   Permits remote administrators to initiate communication via the trusted path.

o   Requires the use of the trusted path for initial administrator authentication and all remote administration actions.

Vendor Information