ST Vid10925-Agd

NETSCOUT Arbor Edge Defense and
APS Systems
Supplemental Administrative Guidance
for Common Criteria
Version 1.1
December 12, 2019
NETSCOUT Systems, Inc.

310 Littleton Road
Westford, MA 01886-4105
Prepared By:
Cyber Assurance Testing Laboratory

1100 West Street
Laurel, MD 20707
Contents
1 Introduction ........................................................................................................................................... 3
2 Intended Audience ................................................................................................................................ 3
3 Terminology .......................................................................................................................................... 3
4 References ............................................................................................................................................. 4
5 Evaluated Configuration of the TOE .................................................................................................... 4
5.1 TOE Components.......................................................................................................................... 4
5.2 Supporting Environmental Components ....................................................................................... 4
5.3 Assumptions.................................................................................................................................. 5
6 Secure Acceptance, Installation, and Configuration ............................................................................. 6
6.1 Initial Out-Of-The-Box Setup ....................................................................................................... 6
6.1.1 Changing the Default Admin Password ................................................................................ 7
6.1.2 Logging in Directly to the Serial Port Through Terminal Emulation ................................... 7
6.1.3 Logging in through Remote CLI ........................................................................................... 8
6.1.4 Logging in to the Web GUI .................................................................................................. 8
6.1.5 Enabling FIPS mode ............................................................................................................. 8
6.1.6 Creating User Accounts ........................................................................................................ 8
6.1.7 Enabling Audit Level ............................................................................................................ 8
6.2 Power-On Self Tests ..................................................................................................................... 9
6.3 Configuring OCSP ........................................................................................................................ 9
6.4 Cryptographic Configuration Notice ............................................................................................ 9
6.5 SSH Implementation ................................................................................................................... 10
6.6 Configuring TLS ......................................................................................................................... 11
6.7 Configuring Elliptic Curves ........................................................................................................ 12
6.8 Configuring Certificates.............................................................................................................. 13
7 Secure Management of the TOE ......................................................................................................... 14
7.1 Authenticating to the TOE .......................................................................................................... 14
7.2 Failed Authentication Lockout.................................................................................................... 14
7.2.1 Changing the Number of Login Attempts ........................................................................... 15
1|Page
7.2.2 Unlocking a User Account .................................................................................................. 15
7.3 User Accounts and User Management ........................................................................................ 15
7.3.1 Assigning User Roles .......................................................................................................... 16
7.4 Password Management ............................................................................................................... 16
7.4.1 Configuring Password Policies ........................................................................................... 16
7.4.2 Resetting Passwords............................................................................................................ 16
7.5 Login Banner .............................................................................................................................. 17
7.6 Session Termination.................................................................................................................... 17
7.6.1 Admin Logout ..................................................................................................................... 17
7.6.2 Termination from Inactivity ................................................................................................ 17
7.7 System Time Configuration ........................................................................................................ 18
7.8 Secure Updates............................................................................................................................ 19
7.8.1 Display Current Version ..................................................................................................... 19
7.8.2 Uploading the Upgrade Files .............................................................................................. 20
7.8.3 Upgrading the Software ...................................................................................................... 20
8 Auditing .............................................................................................................................................. 21
8.1 Audit Storage .............................................................................................................................. 34
8.2 Stopping and Starting Audit Server ............................................................................................ 34
9 Operational Modes .............................................................................................................................. 35
10 Additional Support .......................................................................................................................... 35
Table of Tables
Table 1: AED/APS Hardware Specifications ............................................................................................... 4
Table 2: Evaluated Components of the Operational Environment ............................................................... 5
Table 4: Management Functions by Interface............................................................................................. 15
Table 5: AED/APS Sample Audit Records................................................................................................. 21
2|Page
1 Introduction
The NETSCOUT Arbor Edge Defense and Availability Protection System (APS) Systems (referred as
AED/APS (or APS for short) from this point forward) is a network device that includes hardware and
software whose primary functionality is to secure the internet data center’s edge from threats against
availability, specifically from application-layer distributed denial of service (DDoS) attacks. The
collaborative Protection Profile for Network Devices, version 2.0 + Errata 20180314 (NDcPP) defines a
network device as “a device composed of both hardware and software that is connected to the network
and has an infrastructure role within the network”. Additionally, the NDcPP says that example devices
that fit this definition include routers, firewalls, intrusion detection systems, and switches.
As a Common Criteria evaluated product, this guidance serves to define the ‘evaluated configuration’ in
which the evaluation was performed and to summarize how to perform the security functions that were
tested as part of the evaluation.
2 Intended Audience
This document is intended for administrators responsible for installing, configuring, and/or operating
AED/APS. Guidance provided in this document allows the reader to deploy the product in an
environment that is consistent with the configuration that was evaluated as part of the product’s Common
Criteria (CC) testing process. It also provides the reader with instructions on how to exercise the security
functions that were claimed as part of the CC evaluation. The reader is also expected to be familiar with
the general operation of the AED/APS product. This supplemental guidance includes references to
NETSCOUT’s standard documentation set for the product and does not explicitly reproduce materials
located there.
The reader is also expected to be familiar with the NETSCOUT Arbor Edge Defense and APS Systems
Security Target and the general CC terminology that is referenced in it. This document references the
Security Functional Requirements (SFRs) that are defined in the Security Target document and provides
instructions for how to perform the security functions that are defined by these SFRs. The AED/APS
product as a whole provides a great deal of security functionality but only those functions that were in the
scope of the claimed PP are discussed here. Any functionality that is not described here or in the
NETSCOUT Arbor Edge Defense and APS Systems Security Target was not evaluated and should be
exercised at the user’s risk.
3 Terminology
In reviewing this document, the reader should be aware of the terms listed below. These terms are also
described in the NETSCOUT Arbor Edge Defense and APS Systems Security Target.
CC: stands for Common Criteria. Common Criteria provides assurance that the process of specification,
implementation and evaluation of a computer security product has been conducted in a rigorous and
standard and repeatable manner at a level that is commensurate with the target environment for use.
3|Page
SFR: stands for Security Functional Requirement. An SFR is a security capability that was tested as part
of the CC process.
TOE: stands for Target of Evaluation. This refers to the aspects of the AED/APS product that contain the
security functions that were tested as part of the CC evaluation process.
4 References
The following security-relevant documents are included with the TOE. This is part of the standard
documentation set that is provided with the product. Documentation that is not related to the functionality
tested as part of the CC evaluation is not listed here.
[1] Arbor Networks APS Appliance Quick Start Card
[2] Arbor Networks AED Appliance Quick Start Card
[3] Arbor Networks APS Compliance Guide for Common Criteria and FIPS, Version 6.0.1
[4] Arbor Edge Defense Compliance Guide for Common Criteria and FIPS, Version 6.2.2
[5] Arbor Networks APS User Guide, Version 6.2
[6] Arbor Edge Defense User Guide, Version 6.2
The following document was created in support of the AED/APS CC evaluation:
[7] NETSCOUT Arbor Edge Defense and APS Systems Security Target, version 1.1
5 Evaluated Configuration of the TOE

This section lists the components that have been included in the TOE’s evaluated configuration, whether
they are part of the TOE itself, environmental components that support the security behavior of the TOE,
or non-interfering environmental components that were present during testing but are not associated with
any security claims:
5.1 TOE Components

The TOE is NETSCOUT Arbor Edge Defense and APS Systems, running AED/APS software version
6.6, which is built on top of Arbux internal OS v7.0 (ArbOS). The AED/APS is a rack-mounted hardware
device. The evaluated model’s specific hardware and configuration is as follows:
Table 1: AED/APS Hardware Specifications
Model APS2600/AED2600 APS2800/AED2800
Processor Intel E5-2608L v3 - 2.00GHz Intel E5-2648L v3 - 1.80GHz
Sockets 2 2
Memory 32 GB 64 GB
OS SSD Capacity 240 GB 240 GB
Cores Per CPU 6 12
5.2 Supporting Environmental Components

The following table lists components and applications in the environment that the TOE relies upon in
order to function properly:
4|Page
Table 2: Evaluated Components of the Operational Environment
Component Definition
A server that acts as a trusted issuer of digital certificates and hosts the OCSP
Certification Authority
Responders that identifies revoked certificates.
Any general-purpose computer that is used by an administrator to manage the TOE.
The TOE can be managed remotely, in which case the management workstation
requires an SSH client to access the CLI or a web browser (Microsoft Internet
Management
Explorer 10 or 11, Google Chrome 44, Firefox ESR 31 or 40) to access the web GUI,
Workstation
or locally, in which case the management workstation must be physically connected
to the TOE using the serial port and must use a terminal emulator that is compatible
with serial communications.
The syslog server connects to the TOE and allows the TOE to send syslog messages
Syslog Server to it for remote storage. This is used to send copies of audit data to be stored in a
remote location for data redundancy purposes.
A general-purpose computer that is used to store software update packages that can
be retrieved by the Security Administrator and downloaded via the management
workstation. Software updates, including new versions, are made available to
licensed clients through an Electronic Software Distribution system. Access to the
Update Server
ESD server is controlled by the NETSCOUT Arbor client services organization and
limited to actively licensed clients. Updates are transferred from the management
workstation to the TOE via the web GUI upload tool from the management
workstation. The TOE does not directly access the update server.
5.3 Assumptions
In order to ensure the product is capable of meeting its security requirements when deployed in its
evaluated configuration, the following conditions must be satisfied by the organization, as defined in the
claimed Protection Profile:
 Physical security: The AED/APS product does not claim any sort of physical tamper-evident or
tamper-resistant security mechanisms. Therefore, it is necessary to deploy the product in a locked
or otherwise physically secured environment so that it is not subject to untrusted physical
modification.
 Limited functionality: The AED/APS product must only be used for its intended networking
purpose. General purpose computing applications, especially those with network-visible
interfaces, may compromise the security of the product if introduced.
 No through traffic protection: The security boundary of the Common Criteria evaluation is
limited to traffic flowing to or from the TOE. The intent is for AED/APS 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 NDcPP. It is assumed that this protection will be covered by cPPs for particular types of
network devices (e.g., firewall).
 Trusted administration: The AED/APS product does not provide a mechanism to protect
against the threat of a rogue or otherwise malicious administrator. Therefore, it is the
5|Page
responsibility of the organization to perform appropriate vetting and training for Security
Administrators prior to granting them the ability to manage the product.
 Regular updates: NETSCOUT provides regular product updates for the AED/APS product that
include bug fixes as well as functionality and security enhancements. It is expected that
administrators are reasonably diligent in ensuring that software patches are applied regularly as
they are made available.
 Secure admin credentials: AED/APS protects the administrator’s credentials stored on
AED/APS that are used to access it. Additionally, it is assumed that any administrative
credentials maintained by an environmental server are secured in order to mitigate the risk of
impersonation.
 Residual information: It is the responsibility of the administrator to 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.
6 Secure Acceptance, Installation, and Configuration

Documentation for how to order and acquire the TOE is described under the Contact Us link on the
NETSCOUT website www.NETSCOUT.com. Section 5.1 of this document lists the properties that are
associated with the TOE. When receiving delivery of the TOE, this documentation should be checked as
part of the acceptance procedures so that the correctness of the hardware can be verified.
Physical installation and first-time setup of the TOE can be accomplished by completing the initial
installation and configuration procedures that are outlined in the APS Quick Start Guide [1]. Once the
TOE is physically installed, it is recommended that an administrator acquire the software image for the
current version from NETSCOUT and perform a software upgrade to the current version. Depending on
when the device was manufactured, AED/APS may have a different software version initially installed on
it. The TOE will need to be booted and the procedures in [1] must be followed to complete the installation
of AED/APS software.
NOTE: The Admin Guide provides an optional setting to use the Network Time Protocol but in the
evaluated configuration the TOE’s clock will be set by the administrator.
The Security Administrator must also perform the actions defined in [1] to prepare to access the TOE
remotely and change the passwords for the default user and root accounts on the CLI.
6.1 Initial Out-Of-The-Box Setup

Follow the steps outlined in the APS Quick Start Guide [1] for initial out-of-the-box installation and setup
of the TOE. The Security Administrator can follow a quick installation script that prompts the
administrator to enter the information that is required. If the installation script does not appear, the APS
can be installed by typing a series of commands in the command line interface (CLI). The Security
Administrator can also use the CLI to configure options that are not in the script or to redo any of the
original configurations.
6|Page
NOTE: During installation, in order to use APS in FIPS mode, enter yes to the Enable FIPS mode?
prompt in the installation script. When FIPS mode is enabled, APS supports FIPS compliant algorithms
only.
NOTE: Default username is admin and default password is arbor. Change this password for security
purposes after logging in for the first time.
6.1.1 Changing the Default Admin Password

If the installation script does not appear, enter these steps manually in the CLI.
Before starting the APS services, the default administrator password must be changed:
1. Enter:
services aaa local password admin interactive
2. Enter the new password.
3. Re-enter the new password.
4. To save the configuration from anywhere within the CLI, enter: config write
NOTE: It is important to save the configuration whenever you make changes. Saving the configuration
ensures that the current changes take effect immediately and preserves the configuration if APS is
rebooted. Typically, it’s not necessary to save the configuration after every command that is entered. It is
usually sufficient to save the configuration at the end of every session.
6.1.2 Logging in Directly to the Serial Port Through Terminal Emulation

A workstation can be connected directly into the serial port on the TOE. Alternately, a serial console can
be connected to the serial port on the TOE and then use a terminal emulator to access the CLI. Boot
commands are available when connected through the serial port. To use the serial port, a null modem (RJ-
45) cable must be used to connect the TOE to the console. Instructions for connecting the serial cable are
in [1]. Use the following setting to configure the terminal emulation program to connect to the CLI:
Baud rate: 9600
Data bits: 8
Stop bits: 1
Parity: None
Flow control: None
To log in to the serial port through terminal emulation via the CLI:
1. Start the terminal emulator and establish a connection to the TOE’s serial port.
2. Press any key, if prompted to do so.
3. If the boot menu appears, select disk.
4. At the CLI login prompt, enter valid Security Administrator credentials (username and password).
7|Page
6.1.3 Logging in through Remote CLI
To log in through SSH via the remote CLI:
1. Start the SSH client and establish a connection by entering the IP address or DNS hostname for
the TOE as needed.
2. At the remote CLI login prompt, enter valid Security Administrator credentials (username and
password).
6.1.4 Logging in to the Web GUI

To log in through HTTPS through the web GUI:
1. Open a web browser.
2. Type https:// followed by the IP address of the APS appliance.
3. If applicable, select the appropriate option for accepting the site’s certificate, and then click OK.
4. In the Welcome window, enter valid Security Administrator credentials (username and password).
5. Click Login.
6.1.5 Enabling FIPS mode

By default, AED/APS comes delivered with many security settings already enabled but additional
security settings will need to be configured to meet the requirements of the Common Criteria certification.
During the installation of the TOE, ensure that FIPS mode is enabled via the CLI. When prompted, enter
“yes” to the “Enable FIPS mode?” in the installation script. When FIPS mode is enabled, the TOE
supports the claimed cryptographic algorithms only. To see what cryptographic algorithms are claimed,
see the Security Target [7], “Cryptographic Support.”
6.1.6 Creating User Accounts

To create user accounts:
1. Authenticate to the TOE via the web GUI.
2. Navigate to Administration > User Accounts.
3. Click Add Account.
4. Specify the values in the fields, ensuring the system_admin group for the account.
NOTE: If making non-Security Administrator accounts, use system_user group for the account.
5. Save to create the new user account.
6.1.7 Enabling Audit Level

1. Authenticate to the TOE via the CLI.
2. Enter:
services aaa local accounting set level commands
8|Page
6.2 Power-On Self Tests
During the start-up of the TOE, the TSF runs a cryptographic module integrity test as well as a
cryptographic known-answer test. These tests verify that the cryptographic module is operating correctly
and has not been tampered with. If a cryptographic self-test fails, the device will become inoperable. The
only remediation for this test failure is to have a Security Administrator contact NETSCOUT support per
the guidance in Section 10..
The TOE also performs a file system self-test during start-up to ensure the underlying hardware does not
have any anomalies that would cause the software to be executed in an unpredictable or inconsistent
manner. This test calls the standard test method in the ext3 file system to check the file system data
structures and confirm that they are in a consistent state.
In the event that a POST fails, the boot process will terminate. The TOE will need to be rebooted to
attempt to clear the error. If the TOE has been corrupted or the hardware has failed such that rebooting
will not resolve the issue, a Security Administrator will need to contact NETSCOUT support per the
guidance in Section 10.
6.3 Configuring OCSP

In FIPS mode, the TOE uses the Online Certificate Status Protocol (OCSP) validation to determine the
revocation status of a certificate. The Security Administrator can configure whether the TOE accepts or
rejects certificates when the OCSP responder is unreachable.
NOTE: By default, if the OCSP responder is unavailable to determine the validity of the certificate, the
TOE rejects the certificate.
To configure the OCSP unreachable option:
5. Enter:
services http certificate ocsp unreachable {reject | accept}
NOTE: Where “reject|accept” indicates whether to reject or accept certificates when the OCSP
responder is unreachable.
6.4 Cryptographic Configuration Notice

The administrator installing the TOE is expected to perform all of the operations in Section 6 of this
document. This will result in the TOE’s cryptographic operations being limited to the claims made within
the Common Criteria evaluation. There is no further configuration required on the TOE’s cryptographic
engine as the TOE already comes pre-configured to meet many of the Common Criteria requirements
such as key destruction and SHA-512 password hashing. There are no known instances where key
destruction does not happen as defined by the Security Target. Section 6.1 automates many of the
remaining configurations through the FIPS mode, and the remaining Sections of 6.5 through 6.8 have the
9|Page
administrator manually configuring the remaining items (i.e., algorithms, certificates, elliptic curves). For
this reason, other configurations require no further administrative action.
NOTE: The use of other cryptographic engines and cryptographic settings were not evaluated nor tested
during the Common Criteria evaluation of the TOE.
6.5 SSH Implementation

The TOE implements the SSHv2 protocol that is used to secure the remote CLI management connection
(SSH Server). The TOE supports password-based and public key-based authentication methods; both
username/password and public key authentication methods are supported on the remote CLI.
Session keys are created when the TOE establishes an SSHv2 connection. The TOE will monitor the time
period during which the SSHv2 session keys are active and how much data has been transmitted using
them. The TOE performs an SSH rekey no longer than 1 hour elapsing or after no more than 1 GB of data
is transferred whichever comes first. All SSHv2 connections will be dropped upon detection of any packet
greater than 262,144 bytes being transported.
NOTE: The SSH session key thresholds for time and amount of transmitted data are not configurable in
the evaluated configuration.
Connecting to the TOE with SSHv2 requires the SSH service to support:
 Encryption algorithms: aes-128-ctr, aes-256-ctr, aes128-gcm@openssh.com, aes256-
gcm@openssh.com
 Public key algorithms: ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521
 Data Integrity MAC algorithms: hmac-sha1, hmac-sha2-256, hmac-sha2-512
 Key exchange method: diffie-hellman-group14-sha1, ecdh-sha2-nistp256, ecdh-sha2-nistp384,
ecdh-sha2-nistp521
NOTE: The TOE has a FIPS mode to limit the SSH connection parameters to those defined in the
evaluated configuration.
NOTE: The SSH service is enabled by default.
NOTE: The MAC algorithms defined above are the only ones included in the evaluated configuration. If
deviating from this configuration, the “none” MAC algorithm is never allowed for SSH.
Only one SSH host key is activated at a time. Once another SSH host key is activated/configured, it
disables the previous host key. To generate and import the applicable SSH host key type onto the TOE
SSH Server:
Execute the following commands on the test machine to generate an ssh-rsa host key and transfer it to the
TOE:
ssh-keygen -t rsa -f ssh_host_key_rsa
echo -e "\001\002" > keys_to_upload
tar cf - ssh_host_key_rsa* >> keys_to_upload 2>/dev/null
scp -c aes128-ctr keys_to_upload admin@<TOE-IP-Address>:
10 | P a g e
Execute the following command on the TOE to import and then delete the generated SSH host key:
services ssh key host set disk:keys_to_upload
system files delete disk:keys_to_upload
For ecdsa-sha2-nistp256, the TOE can generate this SSH host key type by performing the following
steps:
2. Execute the following command:
services ssh key generate
3. If asked to overwrite, enter “y”.
Execute the following commands on the test machine to generate an ecdsa-sha2-nistp384 host key and
transfer it to the TOE:
ssh-keygen -t ecdsa -b 384 -f ssh_host_key_ecdsa
tar cf - ssh_host_key_ecdsa* >> keys_to_upload 2>/dev/null
Execute the following commands on the test machine to generate an ecdsa-sha2-nistp521 host key and
transfer it to the TOE:
ssh-keygen -t ecdsa -b 521 -f ssh_host_key_ecdsa
tar cf - ssh_host_key_ecdsa* >> keys_to_upload 2>/dev/null
6.6 Configuring TLS

The TOE, when configured in FIPS mode, uses only TLS v1.2 protocol to secure the following
connections and channels: web GUI management interface connection using HTTPS (TLS Server) and
for the secure connection to the external syslog server. Therefore, the syslog server and web browser must
support TLS v1.2 and be configured to support at least one of the cipher suites listed below. No action is
needed by the Security Administrators when the connection is unintentionally broken.
11 | P a g e
When the TOE is operating in “FIPS mode”, TLS uses only the following ciphersuites:
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
NOTE: The TOE supports this full list. However, when an RSA certificate is loaded, only the RSA
ciphers will be available. When ECDSA certificate is loaded only the ECDSA ciphers will be available.
When the TOE uses TLS client functionality, the presented identifier for the server certificate has to
match the reference identifier in order to establish the connection. The TOE supports either the hostname
or IP address as reference identifiers. Wildcards cannot be used when defining the reference identifier on
the TOE.
NOTE: When the TOE uses TLS server functionality, it will reject all connection attempts from TLS
versions other than v1.2.
To set the reference identifier to be used for certificate validation:
8. Perform the following steps to install the required CA certificates into the TOE CA trust store:
a) Authenticate to the TOE via the CLI.
b) Execute the following command:
services http certificate import ca_only disk:<concatenated-
CA-file>
Note: For “concatenated-CA-file”, specify the concatenated CA file for the web GUI TLS
server certificate and the set of CA files (e.g. rootCA) that form the trust chain for the remote
audit server.
9. Execute the following command:
services logging remote set <SYSLOG-SERVER-HOSTNAME> tcp
<PORT> secure
Note: The reference identifier is specified by “<SYSLOG-SERVER-HOSTNAME>”.
6.7 Configuring Elliptic Curves

In the evaluated configuration, the TOE’s TLS implementation is configured to present the Supported
Elliptic Curves Extension in the Client Hello using NIST curves secp256r1, secp384r1, and secp521r1.
Certificate pinning is not supported. When certificate validation fails, the connection is not established.
The TOE also generates EC Diffie-Hellman parameters over NIST curves secp256r1, secp384r1,
secp521r1 and generates Diffie-Hellman parameters of 2048 bits for key establishment.
To configure the TLS server to use a specified Elliptic Curve, the following steps must be performed.
12 | P a g e
Substitute the curve type (secp256r1 (prime256v1), secp384r1, secp521r1) with the desired selection and
perform the following steps:
Generate an ECDSA certificate using curve secp256r1 (prime256v1) for the elliptic curve private key.
1. Transfer the generated certificate to the TOE:
a. Authenticate to the TOE via the web GUI.
b. Navigate to Administration > Files.
c. Choose Upload File.
d. Specify the signed certificate and choose Upload.
3. Execute the following commands to load the generated certificate onto the TOE web server:
services http certificate import disk:<signed-certificate>
disk:<combined-CA-file>
Note: For “combined-CA-file”, specify the concatenated CA file for the web GUI TLS server
certificate and the set of CA files (e.g. rootCA) that form the trust chain for the remote audit server.
6.8 Configuring Certificates

The TOE performs certificate validity checking for outbound TLS connections to the syslog server whose
certificate must be signed by the same certificate authority as the TOE.
In addition to the validity checking, the TOE will validate certificate revocation status using Online
Certificate Status Protocol (OCSP). The Security Administrator can configure the TOE to accept or reject
a certificate in the event the OCSP responder is unavailable via the CLI. By default, if the OCSP
responder is unavailable to determine the validity of the certificate, the TOE rejects the certificate.
The TOE determines the validity of certificates by ensuring that the certificate and the certificate path are
valid. The TOE supports the minimum length of three certificates in the path. In addition, the certificate
path is terminated in a trusted CA certificate, the basicConstraints extension is present, and the CA flag is
set to TRUE for all CA certificates. The TOE also ensures that the extendedKeyUsage field includes the
correct purpose for its intended use. The only supported use of X.509 certificates is for Server
Authentication for TLS server certificates.
In order to support TLS/HTTPS connectivity over the web GUI, the TOE provides the ability, via the
CLI, to generate a Certificate Request Message so that its server certificate can be signed by a
Certification Authority. The message includes Common Name, Organization, Organizational Unit, and
Country values. The certificate chain of the Certificate Response is validated by the TOE prior to being
installed as the TOE’s server certificate.
2. Execute the following commands to generate a certificate request message:
services http certificate generate custom disk:mycsr.csr
13 | P a g e
3. Specify the responses to the interactive prompts to establish Common Name, Organization,
Organizational Unit, and Country values.
4. Submit the “mycsr.csr” file to the CA for signing.
7 Secure Management of the TOE

The following sections provide information on managing TOE functionality that is relevant to the claimed
Protection Profile. Note that this information is largely derived from [2] through [6] but summarized here
to discuss only actions that are required as part of the ‘evaluated configuration’. The Security
Administrator is encouraged to reference these documents in full in order to have in-depth awareness of
the security functionality of the AED/APS, including functions that may be beyond the scope of this
evaluation.
7.1 Authenticating to the TOE

Users must authenticate to the TOE in order to perform any management functions. Users can
authenticate to the TOE locally or remotely. Local users log in to the local console (workstation with
terminal emulator) using a username and password via the serial port. Remote users can log in to the TOE
using SSH to access the remote CLI using either username and password or SSH public key via the
Ethernet Management Port, or through the web GUI using a username and password via TLS/HTTPS.
In order for users to successfully log in, there are necessary preparatory steps that need to be configured
by the Security Administrator. For Remote SSH (public/private key based) authentication, perform the
following steps to load an SSH key onto the TOE:
2. Navigate to Administration > Files.
3. Choose Upload File.
4. Specify the SSH public key and upload it to the TOE.
6. Execute the following command to associate the SSH public key with the TOE user:
services ssh key import disk:SSH_public_key.pub
7.2 Failed Authentication Lockout

The TOE provides configurable counters for consecutive failed authentication attempts that will result in
a user account being locked due to the failure counter being reached. The CLI and the web GUI have a
single shared counter that adds to the total count. This setting is configurable only in the CLI and can be
set between 1 and 999,999,999 attempts. The default setting is 5 attempts. While the user account is
locked, no authentication is possible. The account will remain locked until a Security Administrator
manually unlocks it.
All remote accounts are subject to the account lockout mechanism. To prevent total lockout, a local
administrator can manually unlock any locked-out accounts.
14 | P a g e
NOTE: If an account is locked automatically, then the user cannot log in with a password. However, if
SSH key authentication was enabled previously on the TOE, then the user can log in with an SSH key.
7.2.1 Changing the Number of Login Attempts

The administrator can change the number of times that users can attempt to log in before they are locked
out of their account. To change the number of login attempts that are allowed:
2. Enter the following commands to configure the number of successive unsuccessful authentication
attempts before the account is locked:
services aaa max_login_failures set 5
Note: This setting is configurable only in the CLI and can be set between 1 and 999,999,999
attempts.
7.2.2 Unlocking a User Account

After a user is locked out of the TOE, the administrator must unlock the user account manually in the
CLI. To unlock a user account:
1. Authenticate to the TOE via the local console and execute the following command to unlock the
account:
services aaa enable_account username
Note: Where “username” is the user’s account.
7.3 User Accounts and User Management

The security management functions available to authorized users of the TOE are mediated by a role-based
access control system. The role-based access control system is enforced via the local console, the remote
CLI, or the web GUI. The TOE has three claimed roles: System Administrator, DDoS Admin, and
System User. Users in the System User role only have read access to view events and blocked host
queries via web GUI. Only the System Administrator and the DDoS Admin role are capable of
performing management functions on the TOE both locally and remotely. Administrators can perform
management functions via the local console or remotely via the remote CLI or web GUI. All relevant
management activity is performed by the System Administrator, role which corresponds to the NDcPP’s
definition of Security Administrator. The following table lists the TOE management functions and
identifies the interface(s) that can be used to perform them:
Table 3: Management Functions by Interface
Management Function Local CLI Remote CLI Remote GUI
Configure TLS Connection Parameters X X
Configure SSH Connection Parameters X X
Configure Failed Lockout Threshold X X
Create Users X X X
Unlock User Account X
15 | P a g e
Modify User Passwords X X X
Modify Password Policy X X
Generate X.509 Certificate Request Message X X
Initiate Manual Update X X
Configure System Time X X
Configure Idle Session Timeout X X
Configure Banner Text X
Custom user roles (functionality out of scope of the evaluation) are created based on privileges by the
Security Administrator via the CLI. The Security Administrator can assign users to the custom role on
either the web GUI or the CLI. Only one role can be assigned to a user, however, a role can be assigned
to multiple users.
7.3.1 Assigning User Roles

To add assign user roles to user accounts:
2. Navigate to Administration > User Accounts.
3. Click on the user name to display the Edit Account window.
4. Select the user group to assign to the user.
5. Click Save to finish editing.
7.4 Password Management

In the evaluated configuration, the TOE enforces passwords to have minimum length between 7 and 72
characters. The accepted characters include upper and lower case letters, numbers, and the special
characters “!”,”@”,”#”,”$”,”%”,”^”,”&”,”*”,”(“,”)”. In order to minimize the risk of account
compromise, it is recommended to use a password that includes a mixture of uppercase, lowercase,
numeric, and special characters and is not a common word or phrase, but is not so complex that it must be
written down in order to be remembered.
7.4.1 Configuring Password Policies

The password policy is configurable by the Security Administrator via the CLI:
2. Execute the following commands to specify the minimum and maximum password length values:
services aaa password_length min 7
services aaa password_length max 72
7.4.2 Resetting Passwords

2. Execute the following commands to reset the password for the “admin” user:
16 | P a g e
services aaa local password admin interactive
3. Create a password.
7.5 Login Banner

In the evaluated configuration, the warning login banner is displayed prior to the user authenticating to
the TOE via the local console, the remote CLI, and the web GUI. The display of the warning banner is the
only service that can be run prior to authentication and thus, the TOE does not allow a user to perform
any other actions prior to authentication, regardless of the interface used.
The pre-login banner is configured through the web GUI and is applied to all authentication options.
To configure the login banner:
2. Navigate to Administration > General.
3. Specify the pre-authentication banner text in the Pre-Login Banner text field and then click
Save.
Note: The banner message may contain up to 1300 characters.
7.6 Session Termination

7.6.1 Admin Logout
The Security Administrator or user is able to terminate their own session by entering the exit command
when logged into the local console or remote CLI via SSH. The Security Administrator or user can
terminate their own session by clicking on Log Out in the top-right corner when logged into the web
GUI.
7.6.2 Termination from Inactivity

The TOE can be configured to terminate a local and remote session after a specific period of time. The
inactivity timeout can be configured between 0-999 minutes. For local and remote CLI sessions, the
default setting is disabled and there is no timeout configured (value of 0). For web GUI sessions, there is
no default timeout configured. However, in the evaluated configuration, the inactivity timeout will be
enabled by the Security Administrator.
In the event that the inactivity setting is met while users are logged into the CLI, the TOE closes the SSH
connection. In the event that the inactivity setting is reached while a user is logged into the web GUI, the
user’s session will end. Once a session has been terminated, the user must re-authenticate to start a new
session.
Viewing the current idle timeout in the CLI
To view the idle timeout:
2. Enter:
17 | P a g e
services http idle
Configuring the idle timeout in the CLI

To configure the idle timeout in the CLI:
2. Configure the CLI to terminate the session after the specified number of minutes:
system idle set <minutes>
3. Configure the web GUI to terminate the session after the specified number of minutes:
services http idle set <minutes>
Note: Security Administrators authenticated to the local console or remote CLI may configure
this setting for all of the local console, remote CLI, and web GUI.
Configuring the idle timeout in the GUI
To configure the idle timeout in the web GUI:
1. Authenticate to the TOE web GUI.
2. Select Administration > General.
3. On the Configure General Settings page, in the UI Idle Timeout box, enter an amount of time in
minutes. This is the amount of time that must elapse before users are logged out of the web GUI
due to inactivity.
4. Click Save.
Note: Security Administrators authenticated to the web GUI can only configure the timeout
setting for the web GUI.
7.7 System Time Configuration

The TOE has an underlying hardware clock that is used for time keeping. In the evaluated configuration
of the TOE, the system time is expected to be manually set. The TOE does not claim support for the use
of NTP. The TOE uses time data for the following purposes:
 Audit record timestamps
 Inactivity timeout for administrative sessions
 Expiration checking for certificates
To configure the date and time of the TOE:
2. Execute the following commands to set the clock:
 For APS:
services aps stop
clock set MMDDhhmmCCYY
18 | P a g e
services aps start
 For AED:
services aed stop
clock set MMDDhhmmCCYY
services aed start
Note: MM = Month, DD = Day, hh = Hour (24 hour format), mm = Minute, CCYY =
Year
3. Execute the following command to verify the clock was set to the specified value:
clock
7.8 Secure Updates

To maintain security throughout the lifecycle of the AED/APS product, the TOE provides a mechanism to
apply software updates. Software updates, including new versions, are made available to licensed clients
through an Electronic Software Distribution (ESD) system. Access to the ESD server is controlled by the
NETSCOUT Arbor client services organization and limited to actively licensed clients. In order to update
the TOE, the Security Administrator manually downloads the update from the customer portal on the
Arbor website to their local management workstation and then applied to the TOE. Once downloaded, the
update is loaded onto the TOE using the web GUI. At this point, the update is not installed on the TOE –
only loaded into the filesystem. The Security Administrator then authenticates to the TOE via the CLI and
manually performs installation of the update. Updates are signed using OpenSSL and verified against a
public key which is shipped with ArbOS. The signature is checked automatically during the installation
process. Packages with invalid or missing signatures cannot be installed.
7.8.1 Display Current Version

Before downloading a new image, the current version of the software image should be identified. The
Security Administrator can query the current version of the TOE's firmware/software on the local/remote
CLI interface and the web GUI interface.
To query the current version of the TOE's firmware/software on the local/remote CLI interface:
2. Execute the following command to obtain the current TOE software version:
system version
3. Execute the following command to obtain the a list of TOE software packages uploaded on
system:
system files show
Within the web GUI interface, the user can select “About” link to display the currently installed version.
19 | P a g e
7.8.2 Uploading the Upgrade Files
2. Navigate to Administration > Files
3. Click Upload File.
4. Specify the ArbOS update file and click Upload.
5. Click Upload another.
6. Specify the APS/AED updated file and click Upload File.
NOTE: At this point Common Criteria refers to this as a delayed activation because until the following
steps are completed the update has not been activated and the previous version is still executing. There is
no method of determining the version other than a directory listing showing the filename that has the
version in the name.
8. Execute the following command to stop the APS/AED services:
 If APS:
services aps stop
 If AED:
services aed stop
9. Execute the following command to save the current configuration:
config write
7.8.3 Upgrading the Software

1. Execute the following command to uninstall the old APS/AED package:
system files uninstall <package-name>
<package-name> = the name of the old APS/AED package
2. Execute the following command to install the new ArbOS update:
system files install disk:<ArbOS-package-name>
<ArbOS-package-name>= the file name of the new ArbOS file that was uploaded
3. After the installation is finished, execute the following commands to reboot the TOE:
reload
y
4. After the TOE has been rebooted, authenticate to the TOE via the CLI.
5. Execute the following command to install the APS/AED update:
system files install disk:<APS/AED-package-name>
20 | P a g e
<APS/AED-package-name>= the file name of the new APS/AED file that was
uploaded
6. After the installation is finished, execute the following commands to reboot the TOE:
reload
y
NOTE: All services and security mechanisms will now cease to operate until installation is complete.
7. After the TOE has rebooted, authenticate to the TOE via the CLI.
8. Execute the following command to start the APS/AED services:
 If APS:
services aps start
 If AES:
services aed start
9. Execute the following command to save the configuration:
config write
10. Repeat Step 2 of Section 7.8.1 “Display Current Version” to verify the TOE is the same version
of the newly installed software updates.
8 Auditing
In order to be compliant with Common Criteria, the TOE audits the events in the table below. The TOE
generates audit records for all administrative functions performed on the TOE. The audit records are
generated and stored in the form of syslog records which are sent to a remote syslog server. The
transmission of this data to the syslog server is protected from unauthorized modification and deletion
using TLSv1.2.
The following is an example of an audit record that AED/APS produces:
Jan 8 22:43:39 omicron sshd[14215]: #LOGIN-CLI-SUCCEED admin
10.1.0.112
Each audit record contains identifying information required by Common Criteria including the date and
time the event occurred [Jan 8 22:43:39], the type of event [LOGIN-CLI], the subject identity of the event
[admin 10.1.0.112], and the outcome of the event [LOGIN-CLI-SUCCEED].
The TOE allows any user to view audit records via the CLI. In the evaluated configuration, the TOE does
not provide any interface for users to modify or delete audit data. Sample audit records for each security-
relevant auditable event are included in the following table.
Table 4: AED/APS Sample Audit Records
Auditable Event Sample Audit Record
21 | P a g e
Startup of audit functions
Starting device
May 22 13:20:56 (none) kernel: [ 0.000000] Initializing cgroup subsys
cpuset
May 22 13:20:56 (none) kernel: [ 0.000000] Linux version 4.1.15-arbux
(root@a8b593f653a8) (gcc version 6.4.1 20170727 (Red Hat 6.4.1-1)
Start-up and shutdown of the (GCC) ) #1 SMP PREEMPT Thu Nov 8 18:53:22 UTC 2018
audit functions.
Shutdown of audit functions
Shutdown of audit function requires a Shutdown of the device.
Shutdown device
May 22 09:17:28 arbor-aps2600.catl.local shutdown[45522]: shutting
down for system reboot
Local Console login using password

Oct 15 14:19:26 arbor-aps2600.catl.local login: pam_arbor: #AUTH-
LOCAL-SUCCEED admin:system_admin
Oct 15 14:19:26 arbor-aps2600.catl.local login: #LOGIN-CLI-SUCCEED
admin (null)
CLI login using SSH Key

May 22 08:49:17 arbor-aps2600.catl.local sshd[126501]: Accepted
publickey for admin from 192.168.1.3 port 41554 ssh2: ECDSA
SHA256:lAF7rNMXzasNbkj8VXYP3GTz4UBGFo5lnXFDgGTn4p0
May 22 08:49:17 arbor-aps2600.catl.local sshd[126501]: #LOGIN-CLI-
SUCCEED admin 192.168.1.3
CLI login using password

Oct 15 14:17:16 arbor-aps2600.catl.local sshd[32668]: pam_arbor:
#AUTH-LOCAL-SUCCEED admin:system_admin
Oct 15 14:17:16 arbor-aps2600.catl.local sshd[32668]: #LOGIN-CLI-
Administrative login and logout.
Oct 15 14:17:16 arbor-aps2600.catl.local sshd[32668]: Accepted
password for admin from 192.168.1.3 port 33689 ssh2
GUI login using password

Oct 15 14:21:31 arbor-aps2600.catl.local arbos_login: pam_arbor:
Oct 15 14:21:31 arbor-aps2600.catl.local arbos_login: #LOGIN-UI-
Local Console logout

Jan 28 11:25:05 arbor-aps2600.catl.local auth: COMMAND exit BY
admin FROM cli
Jan 28 11:25:05 arbor-aps2600.catl.local auth: LOGOUT admin FROM
cli
CLI logout
22 | P a g e
Oct 15 10:57:03 arbor-aps2600.catl.local sshd[44432]: Received
disconnect from 192.168.1.3 port 33644:11: disconnected by user
Oct 15 10:57:03 arbor-aps2600.catl.local sshd[44432]: Disconnected from
192.168.1.3 port 33644
GUI logout
Oct 15 10:59:03 arbor-aps2600.catl.local login[25768]: [S] #LOGOUT-
UI-SUCCEED admin 192.168.1.98
Administrator configured password policy

Setting minimum
Oct 15 13:24:52 arbor-aps2600.catl.local auditcomsh: User: admin
Command: / services aaa password_length min 7
Setting maximum
Command: / services aaa password_length max 72
Administrator configured login banner

Feb 21 12:42:17 arbor-aps2600.catl.local ui[18350]: [S] #PRE-LOGIN-
BANNER-CHANGED admin 192.168.1.98
Administrator configured session inactivity timeout

Changes to TSF data related to
configuration changes. For CLI:
Apr 2 12:35:06 arbor-aps2600.catl.local auth: COMMAND system idle
set 3 BY admin FROM cli VIA 192.168.1.3
Apr 2 12:35:06 arbor-aps2600.catl.local auditcomsh: User: admin
Command: / system idle set 3
For GUI:
Command: / services http idle set 3
Administrator configured login failure parameters

Command: / services aaa max_login_failures set 3
Generating/import of, changing,

See ‘Management of cryptographic keys.’
or deleting of cryptographic keys.
Successful password change
Resetting passwords. Command: / services aaa local password admin interactive
Successful login
23 | P a g e
Oct 15 13:26:33 arbor-aps2600.catl.local sshd[73607]: pam_arbor: set
group system_admin
Oct 15 13:26:33 arbor-aps2600.catl.local sshd[73607]: pam_arbor: set
auth_method LOCAL
Oct 15 13:26:33 arbor-aps2600.catl.local sshd[73607]: Accepted
Oct 23 10:49:40 arbor-aps2600.catl.local stunnel: LOG4[0]: s_connect:

connected 192.168.1.152:6514
Failure to establish a HTTPS Oct 23 10:49:40 arbor-aps2600.catl.local stunnel: LOG3[0]:
Session. SSL_connect: 14077410: error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Failure to establish SSH session

FAIL admin 192.168.1.98
#AUTH-LOCAL-FAILED admin
Failure to establish an SSH Oct 15 12:15:16 arbor-aps2600.catl.local sshd[69861]: Failed password
session. for admin from 192.168.1.98 port 2722 ssh2
(SSH Server)
Failure to establish SSH session with host key
Apr 24 16:15:11 arbor-aps2600.catl.local sshd[113474]: Unable to
negotiate with 192.168.1.3 port 40609: no matching host key type found.
Their offer: ssh-dss [preauth]
Failure to establish TLS client session with invalid cipher

Apr 3 13:32:59 arbor-aps2600.catl.local stunnel: LOG3[3]: SSL_connect:
Failure to establish a TLS session.
140920F8: error:140920F8:SSL routines:ssl3_get_server_hello:unknown
(TLS Client)
cipher returned
Failure to establish TLS server session with invalid cipher

Apr 3 14:08:49 arbor-aps2600.catl.local httpd[129780]: [ssl:info] [pid
129780] [client 192.168.1.98:49867] AH02008: SSL library error 1 in
handshake (server 127.0.0.1:443)
Failure to establish a TLS session.
(TLS Server)
129780] SSL Library Error: error:1408A0C1:SSL
routines:ssl3_get_client_hello:no shared cipher -- Too restrictive
SSLCipherSuite or using DSA server certificate?
CLI unsuccessful login attempts:

Unsuccessful login attempts limit
is met or exceeded.
Oct 15 12:51:15 arbor-aps2600.catl.local sshd[3501]: #LOGIN-CLI-FAIL
admin 192.168.1.3
24 | P a g e
Oct 15 12:51:17 arbor-aps2600.catl.local sshd[3501]: Failed password for
admin from 192.168.1.3 port 33675 ssh2
admin 192.168.1.3
admin 192.168.1.3
Oct 15 12:51:31 arbor-aps2600.catl.local sshd[3501]: Connection closed
by 192.168.1.3 port 33675 [preauth]
Oct 15 12:51:39 arbor-aps2600.catl.local sshd[3909]: #AUTH-FAIL-
MAX-LOGINS-EXCEEDED admin
admin 192.168.1.3
GUI unsuccessful login attempts:

Oct 15 13:00:02 arbor-aps2600.catl.local arbos_login: #LOGIN-UI-FAIL
admin 192.168.1.98
admin 192.168.1.98
admin 192.168.1.98
Oct 15 13:00:21 arbor-aps2600.catl.local arbos_login: #AUTH-FAIL-
MAX-LOGINS-EXCEEDED admin
admin 192.168.1.98
25 | P a g e
All use of identification and
See ‘Administrative login and logout.’
authentication mechanism.
Issuer Certificate failed

Apr 29 16:41:34 arbor-aps2600.catl.local stunnel: LOG4[7]: s_connect:
connected 192.168.1.152:6514
Apr 29 16:41:34 arbor-aps2600.catl.local stunnel: LOG4[7]: CERT: Pre-
verification error: unable to get local issuer certificate
Apr 29 16:41:34 arbor-aps2600.catl.local stunnel: LOG4[7]: Rejected by
CERT at depth=1: C=US, ST=Maryland, L=Laurel, O=BAH, OU=CCTL,
CN=CCTL Intermediate 02 CA
Apr 29 16:41:34 arbor-aps2600.catl.local stunnel: LOG3[7]:
SSL_connect: 14090086: error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed
Certificate expired
Oct 22 17:53:18 arbor-aps2600.catl.local stunnel: LOG4[1]: CERT: Pre-
verification error: certificate has expired
Oct 22 17:53:18 arbor-aps2600.catl.local stunnel: LOG4[1]: Rejected by
CN=syslog01.catl.local
Oct 22 17:53:18 arbor-aps2600.catl.local stunnel: LOG3[1]:
Unsuccessful attempt to validate a
certificate.
Node Certificate revoked

connected 192.168.1.3:8888
Oct 23 09:50:20 arbor-aps2600.catl.local stunnel: LOG3[0]: OCSP:
Certificate revoked
OCSP at depth=0: C=US, ST=Maryland, L=Laurel, O=BAH, OU=CCTL,
Intermediate01 CA Certificate revoked

connected 192.168.1.3:8886
Certificate revoked
26 | P a g e
OCSP at depth=2: C=US, ST=Maryland, O=BAH, OU=CCTL,
Missing OCSP signing

connected 192.168.1.3:8886
Oct 23 10:08:25 arbor-aps2600.catl.local stunnel: LOG3[1]: error queue:
27069070: error:27069070:OCSP routines:OCSP_basic_verify:root ca not
trusted
OCSP_basic_verify: 2706A067: error:2706A067:OCSP
routines:OCSP_CHECK_DELEGATED:missing ocspsigning usage
OCSP at depth=2: C=US, ST=Maryland, O=BAH, OU=CCTL,
Certificate signature failure

connected 192.168.1.3:8887
Certificate accepted
Oct 24 08:45:02 arbor-aps2600.catl.local stunnel: LOG4[2]: CERT: Pre-
verification error: certificate signature failure
Oct 24 08:45:02 arbor-aps2600.catl.local stunnel: LOG3[2]: error queue:
14090086: error:14090086:SSL
SSL_connect: D0C5006: error:0D0C5006:asn1 encoding
routines:ASN1_item_verify:EVP lib
Invalid CA
Apr 29 17:04:53 arbor-aps2600.catl.local stunnel: LOG4[1]: s_connect:
connected 192.168.1.3:6514
Apr 29 17:04:53 arbor-aps2600.catl.local stunnel: LOG4[1]: CERT: Pre-
verification error: invalid CA certificate
Apr 29 17:04:53 arbor-aps2600.catl.local stunnel: LOG4[1]: Rejected by
CN=CCTL Intermediate 02 CA FALSE
27 | P a g e
Apr 29 17:04:53 arbor-aps2600.catl.local stunnel: LOG3[1]:
Any attempt to initiate a manual

See ‘Initiation of update; result of the update attempt (success or failure).’
update.
Starting services
Jan 28 12:17:07 arbor-aps2600.catl.local auth: COMMAND services
logging remote set syslog01.catl.local tcp 6514 secure BY admin FROM
cli VIA 192.168.1.3
Jan 28 12:17:07 arbor-aps2600.catl.local auditcomsh: User: admin
Command: / services logging remote set syslog01.catl.local tcp 6514
secure
Jan 28 12:17:09 arbor-aps2600.catl.local rsyslogd: [origin
software="rsyslogd" swVersion="8.26.0" x-pid="122400" x-
info="http://www.rsyslog.com"] start
Starting and stopping of services.
Jan 28 12:17:09 arbor-aps2600.catl.local stunnel: LOG4[0]: s_connect:
connected 192.168.1.152:6514
Jan 28 12:17:09 arbor-aps2600.catl.local stunnel: LOG4[0]: TLS
connected: new session negotiated
Stopping services
Jan 28 12:15:44 arbor-aps2600.catl.local auth: COMMAND services
logging remote clear BY admin FROM cli VIA 192.168.1.3
Jan 28 12:15:44 arbor-aps2600.catl.local auditcomsh: User: admin
Command: / services logging remote clear
Generation of SSH host keys
Apr 11 12:38:27 arbor-aps2600.catl.local auth: COMMAND services ssh
key generate BY admin FROM cli VIA 192.168.1.3
Command: / services ssh key generate
Apr 11 12:38:28 arbor-aps2600.catl.local ssh: User admin successfully
Management of cryptographic generated host key
keys.
CLI Output
admin@arbor-aps2600.catl.local:/# services ssh key generate
Destination file exists.
Overwrite? [n] y
Generating new SSH host key file.....done.
admin@arbor-aps2600.catl.local:/#
All management activities of TSF

See ‘Changes to TSF data related to configuration changes.’
data.
28 | P a g e
Discontinuous changes (CLI only) Administrator change of date & time
to time - either Oct 15 11:32:57 arbor-aps2600.catl.local auditcomsh: User: admin
Administrator actuated Command: / global clock set 1015113418
or changed via an automated admin@arbor-aps2600.catl.local:/# clock
process. Mon Oct 15 11:34:38 EST 2018
Initiation of update
May 3 06:14:48 arbor-aps2600.catl.local auth: COMMAND system files
install disk:arbos-7.0-JD3H-x86_64 BY admin FROM cli VIA
192.168.1.3
May 3 06:19:19 arbor-aps2600.catl.local auth: COMMAND system files
install disk:Arbor-APS-6.2.2-JD3H-x86_64 BY admin FROM cli VIA
192.168.1.3
Initiation of update; result of the
update attempt (success or
Update failure
failure).
Apr 3 09:30:40 arbor-aps2600.catl.local arbpkg: (admin) Failed package
install of /base/store/files/arbos-7.0-JC1J-x86_64_invalid_payload: No
valid signature on package
Apr 3 09:31:18 arbor-aps2600.catl.local arbpkg: (admin) Failed package
install of /base/store/files/Arbor-APS-6.2.1-JC1J-
x86_64_invalid_payload: No valid signature on package
(Local CLI) Session termination due to inactivity:

The termination of a local session
by the session locking mechanism.
Apr 2 12:35:50 arbor-aps2600.catl.local auth: LOGIN admin FROM cli
Apr 2 12:38:50 arbor-aps2600.catl.local auth: LOGOUT admin FROM
cli TIMEOUT
(CLI) Session termination due to inactivity

VIA 192.168.1.3
The termination of a remote cli VIA 192.168.1.3 TIMEOUT
session by the session locking Apr 2 10:23:55 arbor-aps2600.catl.local sshd[33717]: Received
mechanism. disconnect from 192.168.1.3 port 37034:11: disconnected by user
Apr 2 10:23:55 arbor-aps2600.catl.local sshd[33717]: Disconnected from
192.168.1.3 port 37034
SSH Client Output

Connection to 192.168.1.120 closed.
craka@catlsvcs:~$
(GUI) Session termination due to inactivity
29 | P a g e
Command: / services http idle set 3
Oct 15 10:36:55 arbor-aps2600.catl.local arbos_login: #LOGIN-UI-
Oct 15 10:39:59 arbor-aps2600.catl.local mod_auth_tkt: #UI-SESSION-
TIMEOUT admin 192.168.1.98
(Local Console) Manual session termination

Jan 28 11:25:05 arbor-aps2600.catl.local auth: COMMAND exit BY
admin FROM cli
Jan 28 11:25:05 arbor-aps2600.catl.local auth: LOGOUT admin FROM
cli
(CLI) Manual session termination

The termination of an interactive Oct 15 10:57:03 arbor-aps2600.catl.local sshd[44432]: Received
session. disconnect from 192.168.1.3 port 33644:11: disconnected by user
Oct 15 10:57:03 arbor-aps2600.catl.local sshd[44432]: Disconnected from
192.168.1.3 port 33644
(GUI) Manual session termination

Oct 15 10:59:03 arbor-aps2600.catl.local login[25768]: [S] #LOGOUT-
Initiation of the trusted channel (Remote syslog via TLS)

May 30 07:44:43 arbor-aps2600.catl.local auth: COMMAND services
cli VIA 192.168.1.3
May 30 07:44:43 arbor-aps2600.catl.local auditcomsh: User: admin
secure
May 30 07:44:46 arbor-aps2600.catl.local rsyslogd: [origin
May 30 07:44:46 arbor-aps2600.catl.local stunnel: LOG4[0]: s_connect:
connected 192.168.1.152:6514
Initiation of the trusted channel.
May 30 07:44:46 arbor-aps2600.catl.local stunnel: LOG4[0]: OCSP:
Connecting to the AIA responder "http://192.168.1.3:8886"
connect 192.168.1.3:8886: Connection refused (111)
30 | P a g e
May 30 07:44:46 arbor-aps2600.catl.local stunnel: LOG4[0]: TLS
Termination of the trusted channel (Remote syslog via TLS)
cli VIA 192.168.1.3
secure
May 30 07:44:46 arbor-aps2600.catl.local rsyslogd: [origin
connected 192.168.1.152:6514
Termination of the trusted May 30 07:44:46 arbor-aps2600.catl.local stunnel: LOG3[0]: s_connect:
channel. connect 192.168.1.3:8888: Connection refused (111)
May 30 07:44:46 arbor-aps2600.catl.local stunnel: LOG4[0]: TLS
logging view syslog tail 30 BY admin FROM cli VIA 192.168.1.3
Command: / services logging view syslog tail 30
May 30 07:44:54 arbor-aps2600.catl.local auth: COMMAND / commands
services dns show raw BY (system) FROM web
services ntp show raw BY (system) FROM web
ip access show BY (system) FROM web
May 30 07:45:01 arbor-aps2600.catl.local CROND[122528]: (admin)
CMD (/bin/cronexec /etc/c.min)
May 30 07:45:01 arbor-aps2600.catl.local CROND[122527]: (admin)
CMD (/bin/cronexec /etc/c.emin)
logging remote clear BY admin FROM cli VIA 192.168.1.3
Command: / services logging remote clear
May 30 07:45:02 arbor-aps2600.catl.local stunnel: LOG3[main]:
Terminated
31 | P a g e
Failure of the trusted channel (Remote syslog via TLS)
Failure of the trusted channel connected 192.168.1.152:6514
functions. Oct 23 10:49:40 arbor-aps2600.catl.local stunnel: LOG3[0]:
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Initialization of the trusted path (SSH/CLI)
Apr 11 13:11:44 arbor-aps2600.catl.local sshd[39939]: pam_arbor: set
group system_admin
Apr 11 13:11:44 arbor-aps2600.catl.local sshd[39939]: pam_arbor: set
auth_method LOCAL
Apr 11 13:11:44 arbor-aps2600.catl.local sshd[39939]: pam_arbor:
Apr 11 13:11:44 arbor-aps2600.catl.local sshd[39939]: #LOGIN-CLI-
Apr 11 13:11:44 arbor-aps2600.catl.local sshd[39939]: Accepted
VIA 192.168.1.3
Initialization of the trusted path (TLS/GUI)

Apr 11 13:19:20 arbor-aps2600.catl.local httpd[52812]: [ssl:notice] [pid
52812] [client 192.168.1.98:5443] AH01964: Connection to child 12
established (server 127.0.0.1:443)
Initiation of the trusted path. established (server 127.0.0.1:443)
Apr 11 13:19:28 arbor-aps2600.catl.local arbos_login: pam_arbor: set
group system_admin
Apr 11 13:19:28 arbor-aps2600.catl.local arbos_login: pam_arbor: set
auth_method LOCAL
Apr 11 13:19:28 arbor-aps2600.catl.local arbos_login: pam_arbor:
Apr 11 13:19:28 arbor-aps2600.catl.local arbos_login: #LOGIN-UI-
32 | P a g e
Apr 11 13:19:28 arbor-aps2600.catl.local auth: LOGIN admin FROM web
VIA 192.168.1.98
Termination of the trusted path (SSH/CLI)

Apr 11 13:11:47 arbor-aps2600.catl.local auth: COMMAND exit BY
admin FROM cli VIA 192.168.1.3
cli VIA 192.168.1.3
Apr 11 13:11:47 arbor-aps2600.catl.local sshd[39939]: Received
disconnect from 192.168.1.3 port 37741:11: disconnected by user
Apr 11 13:11:47 arbor-aps2600.catl.local sshd[39939]: Disconnected from
192.168.1.3 port 37741
Termination of the trusted path (TLS/GUI)

Apr 11 13:19:36 arbor-aps2600.catl.local login[113441]: [S] #LOGOUT-
52810] [client 192.168.1.98:5444] AH02001: Connection closed to child
10 with standard shutdown (server 127.0.0.1:443)
Termination of the trusted path.
Failure of the trusted path (SSH/CLI)

Apr 11 13:15:21 arbor-aps2600.catl.local sshd[47401]: Unable to
negotiate with 192.168.1.3 port 37742: no matching cipher found. Their
offer: aes128-cbc,aes256-cbc [preauth]
Failure of the trusted path Failure of the trusted path (TLS/GUI)

functions. Apr 11 13:30:11 arbor-aps2600.catl.local httpd[52806]: [ssl:notice] [pid
52806] [client 192.168.1.98:5453] AH02008: SSL library error 1 in
handshake (server 127.0.0.1:443)
33 | P a g e
52806] SSL Library Error: error:1408A0C1:SSL
routines:ssl3_get_client_hello:no shared cipher -- Too restrictive
SSLCipherSuite or using DSA server certificate?
8 with abortive shutdown (server 127.0.0.1:443)
8.1 Audit Storage

In the evaluated configuration, the TOE will send audit records to a remote syslog server via an encrypted
TLS channel. When the TOE is configured to send data to the syslog server, the audit records are
immediately pushed to the syslog server. If syslog server connectivity is unavailable, audit records will
only be stored locally. Upon re-establishment of communications with the syslog server, new audit
records will resume being transmitted to it but the audit records that were generated during the time the
syslog server connection was down remain stored locally and are not sent to the syslog server.
The TOE has a fixed audit log rotation method for storing and automatically deleting old records. The
TOE allocates 64 MB for up to 11 separate log files to store audit data. When the first audit log is full, a
second is automatically created. This process is repeated until 11 files have been created. Once the 11th
file is full, the first file is deleted, and another is created to be populated with the newest audit data. In the
evaluated configuration, the TOE does not allow any user to manipulate, modify, or delete the audit
records stored locally.
Local syslog entries can be viewed by authenticating to the TOE via the CLI and then executing this
command:
services logging view syslog
8.2 Stopping and Starting Audit Server

The TOE provides the provides the ability to start and stop audit transmission to an external syslog server.
2. Execute the following command to disable configured syslog server communication:
services logging clear
3. Execute the following command to enable syslog server communications:
services logging remote set <SYSLOG-SERVER-HOSTNAME> tcp
<PORT> secure
For example: syslog01.catl.local tcp 6514 secure
34 | P a g e
9 Operational Modes
When the TOE is first installed and FIPS mode is enabled, the TOE supports FIPS compliant algorithms
only. After initial installation, the TOE must still be placed into its evaluated configuration by performing
the steps described in Section 6 of this document. Once placed in the evaluated configuration, the TOE’s
operational mode will perform the functions as described in [7].
NOTE: FIPS mode does not place the TOE in another mode of operation but is instead a term for
executing a script that updates system settings for the evaluated configuration.
In the event that a POST fails, the TOE will need to be rebooted. If the TOE has been corrupted or the
hardware has failed such that rebooting will not resolve the issue, a Security Administrator will need to
contact NETSCOUT support per the guidance in Section 10.
10 Additional Support
NETSCOUT provides technical support for its products if needed. Customers can register for a support
account at www.netscout.com/support-services under Customer Portals. Additionally, customers can open
a ticket with NETSCOUT support by calling +1 (888) 357-7667, or by emailing support@netscout.com.
International support phone numbers are also available on their website, www.netscout.com/support-
services.
35 | P a g e

ST Vid10925-Agd

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ST Vid10925-Agd

Uploaded by

Copyright:

Available Formats

NETSCOUT Arbor Edge Defense and

NETSCOUT Systems, Inc.

Cyber Assurance Testing Laboratory

5 Evaluated Configuration of the TOE

5.1 TOE Components

5.2 Supporting Environmental Components

6 Secure Acceptance, Installation, and Configuration

6.1 Initial Out-Of-The-Box Setup

6.1.1 Changing the Default Admin Password

6.1.2 Logging in Directly to the Serial Port Through Terminal Emulation

6.1.4 Logging in to the Web GUI

6.1.5 Enabling FIPS mode

6.1.6 Creating User Accounts

6.1.7 Enabling Audit Level

6.3 Configuring OCSP

6.4 Cryptographic Configuration Notice

6.5 SSH Implementation

6.6 Configuring TLS

6.7 Configuring Elliptic Curves

6.8 Configuring Certificates

7 Secure Management of the TOE

7.1 Authenticating to the TOE

7.2 Failed Authentication Lockout

7.2.1 Changing the Number of Login Attempts

7.2.2 Unlocking a User Account

7.3 User Accounts and User Management

7.3.1 Assigning User Roles

7.4 Password Management

7.4.1 Configuring Password Policies

7.4.2 Resetting Passwords

7.5 Login Banner

7.6 Session Termination

7.6.2 Termination from Inactivity

Configuring the idle timeout in the CLI

7.7 System Time Configuration

7.8 Secure Updates

7.8.1 Display Current Version

7.8.3 Upgrading the Software

Local Console login using password

CLI login using SSH Key

CLI login using password

GUI login using password

Local Console logout

Administrator configured password policy

Administrator configured login banner

Administrator configured session inactivity timeout

Administrator configured login failure parameters

Generating/import of, changing,

Oct 23 10:49:40 arbor-aps2600.catl.local stunnel: LOG4[0]: s_connect:

Failure to establish SSH session

Failure to establish TLS client session with invalid cipher

Failure to establish TLS server session with invalid cipher

CLI unsuccessful login attempts:

GUI unsuccessful login attempts:

Issuer Certificate failed

Node Certificate revoked

Intermediate01 CA Certificate revoked

Missing OCSP signing

Certificate signature failure

Any attempt to initiate a manual

All management activities of TSF

(Local CLI) Session termination due to inactivity: