The NETSCOUT Arbor Edge Defense and APS Systems (AED/APS) are used to secure the internet data center’s edge from threats against availability, specifically from application-layer distributed denial of service (DDoS) attacks. AED/APS deploys at ingress points to an enterprise to detect, block, and report on key categories of Distributed Denial of Service (DDoS) attacks.
","evaluation_configuration":"","security_evaluation_summary":"The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. NETSCOUT Arbor Edge Defense and APS Systems were 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 security functional requirements stated in the NETSCOUT Arbor Edge Defense and APS Systems Security Target Version 1.1, December 12, 2019. The evaluation was completed in December 2019. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report, CCEVS-VR-VID10925-2019 prepared by CCEVS.
","environmental_strengths":"\r\nAudit 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 TLS. Audit data is also stored locally to ensure availability of the data if communications with the syslog server becomes unavailable. Local audit records are stored in files which are rotated to ensure a maximum limit of disk usage is enforced.
\r\nThe TOE uses sufficient security measures to protect its data in transmission by implementing cryptographic methods and trusted channels. The TOE uses SSHv2 and TLS/HTTPS to secure the trusted path to the Remote CLI and the web GUI respectively. The TOE also uses TLS to secure the trusted channel to the remote syslog server.
\r\n\r\n
The cryptographic algorithms are provided by a NETSCOUT FIPS Object Module (CERT 3457). Cryptographic 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 by overwriting them with random data. In the evaluated configuration, the TOE operates in “FIPS 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 1.2/HTTPS. Users authenticate to the TOE using one of the following methods:
\r\n\r\n
The 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 until a Security Administrator unlocks it. This behavior is configurable and shared by the CLI and by the web GUI. Passwords that are maintained by the TSF can be composed of upper case, lower case, numbers, and special 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\n\r\n
As 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 Online Certificate Status Protocol (OCSP). 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 three roles: System Administrator, DDoS Admin, and System User. Each of these roles has varying levels of fixed privilege to interact with the TSF. The System Administrator 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). Therefore, a user that is assigned this role 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 must be manually set in evaluated configuration. 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.
\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. All updates are downloaded to a local machine from the vendor website and then loaded on to the TOE. The updated image is verified via a digital signature before installation completes.
\r\nThe TOE can terminate inactive local console, remote CLI or web GUI sessions after a specified time period. 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 remote syslog server using TLS to encrypt the audit data that traverses the channel. When accessing the TOE remotely, administrators interact with the TSF using a trusted path. The remote CLI is protected via SSHv2 and the web GUI is protected by TLS/HTTPS.
","features":[]}