Gigamon GigaVUE's Visibility Appliances primary functionality is to use the Gigamon Forwarding Policy to receive out-of-band copied network data from external sources (TAP or SPAN port) and forward that copied network data to one or many tool ports for packet capture or analyzing tools based on user selected criteria.
","evaluation_configuration":"\r\n\r\nThe TOE is the Gigamon GigaVUE Visibility Appliance Series containing 16 models:
\r\nHD4: GVS-HD4A1 (AC power), GVS-HD4A2 (DC power)
\r\nHD8, GVS-HD8A1 (AC power), GVS-HD8A2 (DC power)
\r\nHC1: GVS-HC101 (AC power), GVS-HC102 (DC power)
\r\nHC2: GVS-HC2A1 (AC power), GVS-HC2A2 (DC power)
\r\nHC3: GVS-HC301 (AC power), GVS-HC302 (DC power)
\r\nTA10: GVS-TAX01 (AC power), GVS-TAX02 (DC power)
\r\nTA40: GVS-TAQ01 (AC power), GVS-TAQ02 (DC power)
\r\nTA100: GVS-TAC01 (AC power), GVS-TAC02 (DC power)
\r\n\r\n
Each of these devices runs the Gigamon GigaVUE software release 5.1.01 and provides identical security functionality to one another.
\r\n\r\n
The following lists components and applications in the environment that the TOE relies upon in order to function properly:
\r\nThe evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. Gigamon GigaVUE Release 5.1.01 was evaluated against the criteria contained in the Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 4. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 Revision 4. The product, when installed and configured per the instructions provided in the preparative guidance, satisfies all of the security functional requirements stated in the Gigamon GigaVUE Security Target Version 1.0. The evaluation underwent CCEVS Validator review. The evaluation was completed in September 2018. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report, CCEVS-VR-VID10902-2018 prepared by CCEVS.
\r\n\r\n\r\n","environmental_strengths":"\r\n\r\n
Audit records are generated for various types of management activities and events. The audit records include the date and time stamp of the event, the event type and subject identity. In the evaluated configuration, the TSF is configured to transmit audit data to a remote Syslog Server using SSHv2, but audit data is also stored locally to ensure availability of the data if communications with the Syslog Server are unavailable. Local audit records are stored in “message” files which are rotated to ensure a maximum limit of disk usage is enforced. Only users with the Admin privilege can access or delete the log files. Users with the Admin privilege are considered trusted users and are therefore not expected to delete or modify the audit records.
\r\nThe TOE uses sufficient security measures to protect its data in transmission by implementing cryptographic methods and trusted channels. The TOE uses SSH to secure the remote CLI and Syslog Server trusted channels. The TOE also uses TLS/HTTPS to secure the trusted channels for the secure web GUI, Update Server and LDAP server. SSH communications are established using Diffie-Hellman group 14 while TLS communications are established using the ECC scheme using NIST curve P-256.
\r\nCryptographic keys are generated using the CTR_DRBG provided by this module. The TOE erases all plaintext secret and private keys that reside in both RAM and non-volatile storage with zeroes. In the evaluated configuration, the TOE operates in “Secure Cryptography Mode” which is used to restrict algorithms to meet the PP requirements.
\r\nAll users must be identified and authenticated to the TOE before being allowed to perform any actions on the TOE. This is true of users accessing the TOE via the local console, or protected paths using the remote CLI via SSH or web GUI via TLS/HTTPS. Users authenticate to the TOE using one of the following methods:
\r\n· Username/password (defined on the TOE)
\r\n· LDAP authentication
\r\n· Username/public key (SSH only)
\r\nThe TSF provides a configurable number of maximum consecutive authentication failures that are permitted by a user. Once this number has been met, the account is locked for a configurable time interval. Passwords that are maintained by the TSF can be composed of upper case, lower case, numbers and special characters. The Security Administrator can define the password length between 8 and 30 characters. Password information is never revealed during the authentication process including during login failures. Before a user authenticates to the device, a configurable warning banner is displayed.
\r\nAs part of establishing trusted remote communications, the TOE provides X.509 certificate functionality. In addition to verifying the validity of certificates, the TSF can check their revocation status using a certificate revocation list (CRL). The TSF can also generate a Certificate Signing Request in order to obtain a signed certificate to install for its own use as a TLS server.
\r\nThe TOE defines two roles: Admin and Monitor. Each of these roles has varying levels of fixed privilege to interact with the TSF. The Admin role is able to perform all security-relevant management functionality (such as user management, password policy configuration, application of software updates, and configuration of cryptographic settings). The Monitor role provides view-only access to ports and configurations. Therefore, the term “Admin”, used throughout this document, is considered to be a Security Administrator of the TSF. Management functions can be performed using the local CLI, remote CLI, or web GUI. All software updates to the TOE are performed manually.
\r\nThe TOE stores usernames and passwords in a password file that cannot be viewed by any user on the TOE regardless of the user's role. The passwords are hashed using SHA-512. Public keys are stored in the configuration database which is integrity checked at boot time. Key data is stored in plaintext on the hard drive but cannot be accessed by any user. The TOE has an underlying hardware clock that is used for keeping time. The time can be manually set by the administrator. Power-on self-tests are executed automatically when the FIPS validated cryptographic module is loaded into memory. The FIPS cryptographic module verifies its own integrity using an HMAC-SHA1 digest computed at build time. All binaries (e.g. executables, libraries), are located on a read-only partition and cannot be modified. In addition, the TOE has a configuration database that is integrity checked at boot time.
\r\n\r\n
The version of the TOE (both the currently executing version and the installed/updated version, if different) can be verified from any of the administrative interfaces provided by the TSF. The TOE is updated via the Gigamon Update Server or the local Update Server via an HTTPS protected connection. The updated image is verified via a digital signature.
\r\nThe TOE can terminate inactive local console, remote CLI or web GUI sessions after a specified time period. The default setting is 15 minutes. Users can also terminate their own interactive sessions. Once a session has been terminated, the TOE requires the user to re-authenticate to establish a new session. The TOE displays an administratively configured banner on the local console or remote CLI and the web GUI prior to allowing any administrative access to the TOE.
\r\nThe TOE connects and sends data to IT entities that reside in the Operational Environment via trusted channels. In the evaluated configuration, the TOE connects with a Syslog Server using SSH to encrypt the audit data that traverses the channel. The TOE also connects with an LDAP server using TLS and to an Update Server using TLS/HTTPS. The Update Server may either be one maintained by Gigamon, or a local server that is deployed in the TOE’s Operational Environment. When accessing the TOE remotely, administrators interface with the TSF using a trusted path. The remote CLI is protected via SSH and the web GUI is protected by TLS/HTTPS.
","features":[]}