Upload
truongkhanh
View
219
Download
2
Embed Size (px)
Citation preview
1 of 35
Assurance Activities Report
for a Target of Evaluation
Ciena 5400 Series Packet
Optical Platform
Security Target (Version 1.0)
Assurance Activities Report (AAR)
Version 1.0
2/1/2016
Evaluated by:
Booz Allen Hamilton Common Criteria Test Laboratory
NIAP Lab # 200423
900 Elkridge Landing Road, Suite 100
Linthicum, MD 21090
Prepared for:
National Information Assurance Partnership
Common Criteria Evaluation and Validation Scheme
2 of 35
The Developer of the TOE: Ciena Corporation,
7035 Ridge Road,
Hanover, MD 21076 USA
The Author of the Security Target: Booz Allen Hamilton,
900 Elkridge Landin Road,
Linthicum, MD 21090 USA
The TOE Evaluation was sponsored by: Ciena Corporation,
7035 Ridge Road,
Hanover, MD 21076 USA
Evaluation Personnel: Christopher Gugel, CC Technical Director
Jeff Barbi
David Cornwell
Herbert Markle
Christopher Rakaczky
Applicable Common Criteria Version
Common Criteria for Information Technology Security Evaluation, September 2012 Version 3.1 Revision 4
Common Evaluation Methodology Version
Common Criteria for Information Technology Security Evaluation, Evaluation Methodology, September
2012 Version 3.1 Revision 4
3 of 35
Table of Contents
1 Purpose ............................................................................................................................................... - 2 - 2 TOE Summary Specification Assurance Activities ............................................................................ - 2 - 3 Operational Guidance Assurance Activities ....................................................................................... - 6 - 4 Test Assurance Activities (Test Report) ........................................................................................... - 12 -
4.1 Platforms Tested and Composition ......................................................................................... - 12 - 4.2 Omission Justification ............................................................................................................. - 12 - 4.3 Assessment of the Ciena Test Environment ............................................................................ - 12 -
4.3.1 Physical Assessment ........................................................................................................... - 12 - 4.3.2 Logical Assessment ............................................................................................................ - 13 -
4.4 Test Cases ............................................................................................................................... - 13 - 4.4.1 Security Audit ..................................................................................................................... - 13 - 4.4.2 Cryptographic Security ....................................................................................................... - 15 - 4.4.3 User Data Protection ........................................................................................................... - 18 - 4.4.4 Identification and Authentication ....................................................................................... - 18 - 4.4.5 Security Management ......................................................................................................... - 23 - 4.4.6 Protection of the TSF .......................................................................................................... - 23 - 4.4.7 TOE Access ........................................................................................................................ - 25 - 4.4.8 Trusted Path/Channels ........................................................................................................ - 28 -
4.5 Vulnerability Testing .............................................................................................................. - 31 - 5 Conclusions ...................................................................................................................................... - 31 - 6 Glossary of Terms ............................................................................................................................ - 31 -
07/22/2015 CC TEST LAB #200423-0
Page - 1 -
07/22/2015 CC TEST LAB #200423-0
Page - 2 -
1 Purpose The purpose of this document is to serve as a non-proprietary attestation that this evaluation has satisfied all
of the TSS, AGD, and ATE Assurance Activities required by the Protection Profiles/Extended Packages to
which the TOE claims exact conformance.
2 TOE Summary Specification Assurance Activities The evaluation team completed the testing of the Security Target (ST) ‘Ciena 5400 Series Packet Optical
Platform Security Target’ and confirmed that the TOE Summary Specification (TSS) contains all
Assurance Activities as specified by the ‘Protection Profile for Network Devices Version 1.1’ and ‘Security
Requirements for Network Devices Errata #3’. The evaluators were able to individually examine each
SFR’s TSS statements and determine that they comprised sufficient information to address each SFR
claimed by the TOE as well as meet the expectations of the NDPP Assurance Activities.
Through the evaluation of ASE_TSS.1-1, described in the ETR, the evaluators were able to determine that
each individual SFR was discussed in sufficient detail in the TSS to describe the SFR being met by the TSF
in general. However, in some cases the Assurance Activities that are specified in the claimed source
material instruct the evaluator to examine the TSS for a description of specific behavior to ensure that each
SFR is described to an appropriate level of detail. The following is a list of each SFR, the TSS Assurance
Activities specified for the SFR, and how the TSS meets the Assurance Activities. Additionally, each SFR
is accompanied by the source material (NDPP, NDPP Errata) that defines where the most up-to-date TSS
Assurance Activity was defined.
FAU_GEN.1 –This SFR does not contain any NDPP TSS Assurance Activities.
FAU_GEN.2.1 – This SFR does not contain any NDPP TSS Assurance Activities.
FAU_STG_EXT.1 – The NDPP TSS Assurance Activities require the TSS to describe:
(1) amount of audit data that are stored locally,
(2) what happens when the local audit data store is full,
(3) how these records are protected against unauthorized access,
(4) means by which the audit data are transferred to the external audit server, and
(5) how the trusted channel is provided.
This has all been described within the information mapped to FAU_STG_EXT.1 in Section 8.1.3 of the ST.
(1) Locally, the TOE stores audit data in up to four files for both audit log and security syslog file type.
Audit log files can contain up to 1,000 records and security syslog files have a maximum size of 10 MB.
(2) The oldest log file will be overwritten when storage space is exhausted.
(3) The TOE does not provide a mechanism to delete the locally-stored audit data.
(4) The TOE uses syslog-ng to transmit audit data remotely using TCP.
(5) This channel is protected using TLS. If the audit data is transmitted manually SFTP (SSH) is used.
FCS_CKM.1 – The Assurance Activity requires the TSS to contain a description of how the TSF complies
with 800-56A, including the sections in the standards that are implemented by the TSF, such that key
establishment is among the claimed sections.
The Section 8.2.1 of the ST states the sections of which the TOE conforms to these SPs, and claims that the
TOE complies with Section 5.6 and all subsections for asymmetric key pair generation and key
establishment in the NIST SP 800-56A. In addition, the TOE also complies with section 6 of NIST SP 800-
56B for RSA-based key establishment schemes that are used for TLS communications initiated by the
TOE.
FCS_CKM_EXT.4 – The Assurance Activity requires the TSS to describe all of the secret key, private
keys, and CSPs; when they are zeroed; and the type of procedure that is performed to do this.
07/22/2015 CC TEST LAB #200423-0
Page - 3 -
The Section 8.2.2 of the ST states that the TOE zeroizes keys by using the OpenSSL cryptographic module
which automatically zeroizes sensitive data via API function calls for any data that resides in temporary
memory. This includes SSH host and session keys as well as TLS data. In each case, the cryptographic data
is overwritten in memory with all zeroes when no longer in use. Permanently stored SSH keys can be
securely erased by setting the TOE into maintenance mode. The erasure is done by using the linux ‘shred’
function.
FCS_COP.1(1) –This SFR does not contain any NDPP TSS Assurance Activities.
FCS_COP.1(2) – This SFR does not contain any NDPP TSS Assurance Activities.
FCS_COP.1(3) – This SFR does not contain any NDPP TSS Assurance Activities.
FCS_COP.1(4) – This SFR does not contain any NDPP TSS Assurance Activities.
FCS_RBG_EXT.1 – This SFR does not contain any NDPP TSS Assurance Activities.
FCS_SSH_EXT.1.1 – This SFR does not contain any TSS Assurance Activities.
FCS_SSH_EXT.1.2 – The Assurance Activity requires the Section 8.2.8 of the ST to describe the public
key algorithms that are acceptable for SSH authentication that this list conforms to FCS_SSH_EXT.1.5,
and that password-based methods are allowed.
The TSS lists password-based and public key-based methods (RSA Signature Verification) for SSHv2
authentication.
FCS_SSH_EXT.1.3 – The Assurance Activity requires the TSS to describe how “large packets” are
detected and handled.
The Section 8.2.8 of the ST states that packets greater than 32,000 bytes are dropped internally by the SSH
transport connection process.
FCS_SSH_EXT.1.4 – The Assurance Activity requires the TSS to specify any optional characteristics of
the SSH transport implementation and the algorithms that are used for the transport implementation such
that they are consistent with the SFR definition.
The Section 8.2.8 of the ST correctly lists AES-CBC-128 and AES-CBC-256 as the transport
implementations.
FCS_SSH_EXT.1.5 – This SFR does not contain any TSS Assurance Activities.
FCS_SSH_EXT.1.6 – The Assurance Activity requires the TSS to list the supported data integrity
algorithms consistent with the SFR definition.
The Section 8.2.8 of the ST correctly lists HMAC-SHA1, and HMAC-SHA-256 as the supported data
integrity algorithms.
FCS_SSH_EXT.1.7 – The Assurance Activity requires the TSS to state that the use of DH group 14 is
“hard-coded” into the SSH implementation if this is the case.
The Section 8.2.8 of the ST indicates that key exchange methods used by the TOE is a configurable option,
and thus not hard-coded, but DH group 14 is the only allowed method within the evaluated configuration.
07/22/2015 CC TEST LAB #200423-0
Page - 4 -
FCS_TLS_EXT.1 – The Assurance Activity requires the TSS to describe the implementation of this
protocol to ensure that the ciphersuites supported are specified, such that they are consistent with the
ciphersuites defined for the SFR.
The Section 8.2.9 of the ST correctly lists the following as the supported ciphersuites used in TLS 1.2:
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
FDP_RIP.2 – The Assurance Activity requires the TSS to describe packet processing and how residual
data is removed and at what point in the buffer processing this occurs.
The Section 8.3.1 of the ST states that zeroization is performed upon the allocation of memory for a packet.
This section also states that the TOE may also zeroize data immediately after the deallocation of memory
which would occur in addition to the upon allocation zeroization function.
FIA_PMG_EXT.1 – This SFR does not contain any NDPP TSS Assurance Activities.
FIA_UIA_EXT.1 – The Assurance Activity requires the TSS to describe the logon process for each
supported logon method including information pertaining to the credentials allowed/used, any protocol
transactions that take place, and what constitutes a “successful logon”.
The Section 8.4.2 of the ST states that the administrative users are authenticated on the MCLI and TL1
both locally and remotely using a username and password or for remote SSH sessions using a username and
public-key.
FIA_UAU_EXT.2 – This SFR does not contain any TSS Assurance Activities unless other authentication
mechanisms have been specified, in which case they are to be discussed in conjunction with
FIA_UIA_EXT.1.
FIA_UAU.7 – This SFR does not contain any NDPP TSS Assurance Activities.
FMT_MTD.1 – The Assurance Activity requires the TSS to identify all administrator functions that are
accessible through an interface prior to administrator log-in are identified, and how the ability to
manipulate TSF data is disallowed for non-administrative users via these interfaces.
The NDPP TSS Assurance Activities are satisfied by the TSS information mapped to FIA_UAU_EXT.1 in
Section 8.4.2 since other than accepting the banner and possibly seeing diagnostic non-TSF environmental
data, such as temperature and fan speed, if the connection is via the local serial console. Otherwise, no
other actions are allowed prior to administrator log-in via the MCLI or TL1 interfaces. This section also
states that a user is an Authorized Administrator if they are able to manage any TSF capabilities (an MCLI
superuser or Account Administrator for TL1).
FMT_SMF.1 – This SFR does not contain any NDPP TSS Assurance Activities.
FMT_SMR.2 – This SFR does not contain any NDPP TSS Assurance Activities.
FPT_SKP_EXT.1 – The Assurance Activity requires the TSS to detail how pre-shared keys, symmetric
keys, and private keys are stored such that they’re unable to be viewed. The TSS is also required to assert
that passwords are stored in such a way that there is no interface designed for the purpose of viewing this
data.
The Section 8.6.2 of the ST states that the TOE does not provide a mechanism to view secret keys and key
material. Public key data that is stored on the TOE can be viewed by an authorized administrator. Key data
that is resident in volatile memory cannot be accessed by an administrative command. Any persistent key
07/22/2015 CC TEST LAB #200423-0
Page - 5 -
data is stored in the underlying filesystem of the OS on internal flash memory. The TOE’s management
interfaces do not provide any direct access to the file system so there is no administrative method of
accessing this data.
FPT_APW_EXT.1 – The Assurance Activity requires the TSS to detail all of the authentication data that
is subject to this requirement and the method used to obscure the password plaintext data. The TSS is also
required to assert that passwords are stored in such a way that there is no interface designed for the purpose
of viewing this data.
The Section 8.6.1 of the ST states that passwords are stored after being hashed using SHA-256 and this
hash is stored on the TOE. There is no function to display the password in plaintext.
FPT_STM.1 – The Assurance Activity requires the TSS to list each security function that makes use of
time and a description of how time is maintained and considered to be reliable.
The Section 8.6.3 of the ST indicates that the TOE can use the system hardware clock or optionally can
synchronize with one or more NTP servers. It also states that time data is used for timestamps on audit
record and in determining whether an administrative session has gone inactive.
FPT_TUD_EXT.1 – The Assurance Activity requires the TSS (or the operational guidance) to describe
how the candidate updates are obtained; the processing associated with verifying the digital signature or
calculating the hash of the updates; and the actions that take place for successful (hash or signature was
verified) and unsuccessful (hash or signature could not be verified) cases.
The Section 8.6.5 of the ST states that an authorized administrator has the ability to perform TOE updates
using an SFTP server. Updates are verified by a digital signature as well as an internal hash verification
which is not made public. The digital signature uses a 2048 bit key. If the digital signature verification fails,
the upgrade process will stop and the downloaded software release will be flushed from the device’s
temporary memory.
FPT_TST_EXT.1 – The Assurance Activity requires the TSS to detail the self tests that are run by the TSF
on start-up; this description should include an outline of what the tests are actually doing and makes an
argument that the tests are sufficient to demonstrate that the TSF is operating correctly.
The Section 8.6.4 of the ST states that the TOE runs a series of self-tests during initial start-up to verify its
correct operation. As part of the startup of the TOE, the OpenSSL cryptographic module will perform a
series of known answer tests to verify the correct functionality of the cryptographic functions as well as
fingerprint and SHA file checksums to validate its own integrity. Independent of the cryptographic module,
the integrity of the software image itself is also validated against a known hash to ensure its integrity. In the
event that a cryptographic self-tests fail, the TOE will attempt to reboot itself.
FTA_SSL_EXT.1 – This SFR does not contain any NDPP TSS Assurance Activities.
FTA_SSL.3 – This SFR does not contain any NDPP TSS Assurance Activities.
FTA_SSL.4 – This SFR does not contain any NDPP TSS Assurance Activities.
FTA_TAB.1 – The Assurance Activity requires the TSS to detail each method of access (local and remote)
available to the administrator.
Section 8.7.4 of the ST details local and remote access via the MCLI and TL1 interfaces and that a banner
is displayed.
FTP_ITC.1 – The Assurance Activity requires the TSS to describe that, for all communications with
authorized IT entities, each mechanism is identified in terms of the allowed protocols, and that these
protocols are consistent with the SFR.
07/22/2015 CC TEST LAB #200423-0
Page - 6 -
The Section 8.8.1 of the ST states that the trusted channel to the syslog server is secured using TLS, the
trusted channel to a remote file server is secured using SFTP, which is used as the upgrade server and to
manually transfer audit records.
FTP_TRP.1 – The Assurance Activity requires the TSS to describe the methods of remote TOE
administration and how these communications are protected, such that they are consistent with the
protocols defined elsewhere in the ST.
The Section 8.8.2 of the ST states that remote administration is performed via the MCLI or TL1 interfaces
that are protected by SSHv2, which is consistent with the protocol claims made by the ST.
Additionally, the assurance activity for ALC_CMC.1 requires the ST to identify the product version that
meets the requirements of the ST such that the identifier is sufficiently detailed to be usable for
acquisitions. The ST TOE reference in section 1.2 clearly identifies the product as the Ciena 5400 Series
Packet Optical Platform which includes the two models Ciena 5430 and Ciena 5410 and using operating
system Linux kernel version 3.4.36.
3 Operational Guidance Assurance Activities The evaluation team completed the testing of the Operational Guidance, which includes the review of the
“Ciena 5400 Series Packet Optical Platform Supplemental Administrative Guidance” (AGD) document,
and confirmed that the Operational Guidance contains all Assurance Activities as specified by the
‘Protection Profile for Network Devices Version 1.1’ (NDPP) and ‘Security Requirements for Network
Devices Errata #3’ (Errata). The evaluators reviewed the NDPP and Errata to identify the security
functionality that must be discussed for the operational guidance. This is prescribed by the Assurance
Activities for each SFR and the AGD SARs. The evaluators have listed below each of the SFRs defined in
the NDPP that have been claimed by the TOE (some SFRs are conditional or optional) as well as the AGD
SAR, along with a discussion of where in the operational guidance the associated Assurance Activities
material can be found. The AGD includes references to other guidance documents that must be used to
properly install, configure, and operate the TOE in its evaluated configuration. The AGD and its references
to other Ciena 5400 Series Packet Optical Platform guidance documents were reviewed to assess the
Operational Guidance Assurance Activities. The AGD contains references to these documents in Chapter 4
and these references can also be found below:
If an SFR is not listed, one of the following conditions applies:
There is no Assurance Activity for the SFR.
The Assurance Activity for the SFR specifically indicates that it is simultaneously satisfied by
completing a different Assurance Activity (a testing Assurance Activity for the same SFR, a
testing Assurance Activity for a different SFR, or a guidance Assurance Activity for another SFR).
The Assurance Activity for the SFR does not specify any actions to review the operational
guidance.
The following references are used in this section of the document:
[1] Turn-up and Test – 009-3251-002
[2] Alarm and Trouble Clearing Procedures Manual - 009-3251-003
[3] Service Manual - 009-3251-004
[4] Node Manager User Guide - 009-3251-005
[5] System Description - 009-3251-006
[6] 5430 Switch Hardware Installation – 009-3251-001
[7] 5410 Switch Hardware Installation – 009-3251-019
[8] TL1 Interface Manual – 009-2009-086
07/22/2015 CC TEST LAB #200423-0
Page - 7 -
FAU_GEN.1 –
“The evaluator shall check the administrative guide and ensure that it lists all of the auditable events and
provides a format for audit records. Each audit record format type must be covered, along with a brief
description of each field. The evaluator shall check to make sure that every audit event type mandated by
the PP is described and that the description of the fields contains the information required in
FAU_GEN1.2, and the additional information specified in Table 6-2.”
Section 8 of the AGD lists the security-relevant auditable events for the TOE in the table called “NDPP
Auditable Events” and provides sample audit data for each event. From this example, the relationship
between the audit logs shown in the table and the required fields can be determined clearly. Each audit
event type mandated by the PP is described. Additionally, the “TL1 Interface Manual” provides an
overview of the log format under RTRV-AUDIT-SECULOG ‘Retrieve Audit Security Log Information.
“The evaluator shall also make a determination of the administrative actions that are relevant in the
context of this PP. The evaluator shall examine the administrative guide and make a determination of
which administrative commands, including subcommands, scripts, and configuration files, are related to
the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are
necessary to enforce the requirements specified in the PP. The evaluator shall document the methodology
or approach taken while determining which actions in the administrative guide are security relevant with
respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring
the AGD_OPE guidance satisfies the requirements.”
Section 2 of the AGD states: “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 Ciena 5400 Series Packet Optical Platform 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.” Since the AGD references external documents, it is understood that only
the sections of those external documents specifically referenced by the AGD are an extension to the
statement above. All other portions of the externally referenced documents are considered outside the scope
of the evaluation which is in line with the following statement, also in Section 2 of the AGD: “Any
functionality that is not described here or in the Ciena 5400 Series Packet Optical Platform Security Target
was not evaluated and should be exercised at the user’s risk.”
FAU_STG_EXT.1 –
“The evaluator shall also examine the operational guidance to determine that it describes the relationship
between the local audit data and the audit data that are sent to the audit log server (for TOEs that are not
acting as an audit log server).”
Section 8.1 of the AGD describes that the evaluated configuration the TOE sends audit data as it is
collected to a syslog server in the Operational Environment over a secure TLS channel. The configuration
of the Syslog Server using the MCLI is specified in section 6.4 of the AGD. The transportation of logs to
the syslog server is mentioned in the reference “System Description Rel3.0” on Page 3-81 under the section
“Security Logs” and the transfer protocol is TLS 1.2. The operational guidance states that locally the TOE
stores the audit data in two types of logs, each with up to four files. The oldest log file will be overwritten
when storage space is exhausted.
“The evaluator shall also examine the operational guidance to ensure it describes how to establish the
trusted channel to the audit server, as well as describe any requirements on the audit server (particular
audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to
communicate with the audit server.”
The transportation of logs to the syslog server is mentioned in the reference “System Description Rel3.0”
on Page 3-81 under the section Security Logs. This uses TLS1.2 using
TLS_RSA_WITH_AES_128_CBC_SHA. The configuration of the Syslog Server using the MCLI is
specified in section 6.5 of the AGD. The only configuration of the trusted channel can be found in Section
6.1 of the AGD.
07/22/2015 CC TEST LAB #200423-0
Page - 8 -
FCS_SSH_EXT.1.4 –
“The evaluator shall also check the operational guidance to ensure that it contains instructions on
configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms
advertised by the TOE may have to be restricted to meet the requirements).”
Configuration of the SSH server and SSH client cryptographic algorithms is not under administrator
control. However, the administrator must place the TOE in the CC Mode of operation, as described in
Section 6.1 of the AGD. The algorithms are restricted to those identified in Section 8.2.8 of the ST that are
used in the evaluated configuration and meet the PP requirements. The evaluator verified this claim by
examining the AGD and other operational guidance. There were no functions discovered in which to
restrict/unrestrict the advertised algorithms, data integrity algorithms, or key exchange.
FCS_SSH_EXT.1.6 –
“The evaluator shall also check the operational guidance to ensure that it contains instructions to the
administrator on how to ensure that only the allowed data integrity algorithms are used in SSH
connections with the TOE (specifically, that the “none” MAC algorithm is not allowed).”
See FCS_SSH_EXT.1.4
FCS_SSH_EXT.1.7 –
“The evaluator shall ensure that operational guidance contains configuration information that will allow
the security administrator to configure the TOE so that all key exchanges for SSH are performed using DH
group 14 and any groups specified from the selection in the ST.”
See FCS_SSH_EXT.1.4
FCS_TLS_EXT.1 –
“The evaluator shall also check the operational guidance to ensure that it contains instructions on
configuring the TOE so that TLS conforms to the description in the TSS (for instance, the set of ciphersuites
advertised by the TOE may have to be restricted to meet the requirements).”
Configuration of the TLS client cryptographic algorithms is not under administrator control. However, the
administrator must place the TOE in the CC Mode of operation, as described in Section 6.1 of the AGD.
The algorithms are restricted to those identified in Section 8.2.9 of the ST that are used in the evaluated
configuration and meet the PP requirements. The evaluator verified this claim by examining the AGD and
operation guidance. No means in which to restrict/unrestrict the advertised algorithms, data integrity
algorithms, or key exchange was found.
FIA_PMG_EXT.1 –
“The evaluator shall examine the operational guidance to determine that it provides guidance to security
administrators on the composition of strong passwords, and that it provides instructions on setting the
minimum password length.”
Section 6.3 of the AGD specifies how to configure the minimum password length to be 15 characters.
Section 7.5 of the AGD describes password management. Passwords must contain two alphabetical
characters, one numerical character and one special character. Passwords can be changed in TL1 using the
ed-pi command.
FIA_UIA_EXT.1 –
“The evaluator shall examine the operational guidance to determine that any necessary preparatory steps
(e.g., establishing credential material such as pre-shared keys, tunnels, certificates, etc.) to logging in are
described.”
07/22/2015 CC TEST LAB #200423-0
Page - 9 -
The AGD does describe how to configure those items that are related to that authentication enforcement:
Creating usernames and password is described in Sections 7.4 and 7.5 of the AGD. Authenticating to the
TOE is described in Section 7.2 of the AGD. Configuring the TOE for SSH Public/Private key
authentication is described in Section 6.7 of the AGD. Section 6.1 of the AGD describes enabling CC mode
to properly secure the trusted path. Setting the minimum password length is discussed in Section 6.3 of the
AGD. The login banner configuration is described in Section 6.8. The TOE automatically enforces
username and password based authentication out of the box.
“For each supported the login method, the evaluator shall ensure the operational guidance provides clear
instructions for successfully logging on.”
Section 7.2 of the AGD specifies the means to authenticate to access the MCLI and TL1 user interfaces.
Local users login to the MCLI using a username and password while remote users login to the MCLI using
a username and password or public-key. The remote process is protected by SSHv2. Remote users
accessing TL1 provide a username and password in syntax of a command over an SSHv2 protected
channel.
“If configuration is necessary to ensure the services provided before login are limited, the evaluator shall
determine that the operational guidance provides sufficient instruction on limiting the allowed services.”
The only security related service provided by the TOE prior to authentication is the displaying of the login
banner at the login request prompt. Section 6.8 of the AGD specifies how to create this login banner for all
means of accessing the TOE.
FMT_MTD.1 –
“The evaluator shall review the operational guidance to determine that each of the TSF-data-manipulating
functions implemented in response to the requirements of this PP is identified, and that configuration
information is provided to ensure that only administrators have access to the functions.”
The TOE has a fixed set of administrative roles with a fixed set of privileges. The “System Description”
document’s Table 3-9 provides a listing of administrative access levels and privileges allowed. This
corresponds with the description in Section 8.5.2 of the ST which describes the management functions
allowed and which user interface is needed to execute the particular functionality. Section 7.1 of the AGD
is clear that only the Account Administrator role for the TL1 interface and superuser for the MCLI are
applicable to the NDPP requirements. Section 6 and 7 of the AGD give detailed steps with the appropriate
interface (MCLI or TL1) on how to configure the TOE into the evaluated configuration. These sections also
provide instructions on updating the software on the TOE, manage the users of the TOE, and configuring
the TOE for transmitting audit and acquiring time from an NTP server.
FMT_SMR.2 – “The evaluator shall review the operational guidance to ensure that it contains instructions for
administering the TOE both locally and remotely, including any configuration that needs to be performed
on the client for remote administration.”
Section 7.1 of the AGD describes the roles available to assign a user to and what privileges they would
have. Configuration of the TOE can occur locally via the serial console or remotely over the dedicated
management Ethernet port via SSH. Section 7.2 of the AGD provides instructions on how to log in to the
TOE once an appropriate connection has been set up.
FPT_STM.1 –
“The evaluator examines the operational guidance to ensure it instructs the administrator how to set the
time. If the TOE supports the use of an NTP server, the operational guidance instructs how a
communication path is established between the TOE and the NTP server, and any configuration of the NTP
client on the TOE to support this communication.”
07/22/2015 CC TEST LAB #200423-0
Page - 10 -
The “System Maintenance” section of the “TL1 Interface Manual” provides instructions on how to
manually set the system time. Section 6.5 of the AGD provides instructions on how to set up and
administer an NTP server using the MCLI.
FPT_TST_EXT.1 –
“The evaluator shall also ensure that the operational guidance describes the possible errors that may
result from such tests, and actions the administrator should take in response; these possible errors shall
correspond to those described in the TSS.”
Section 6.1 of the AGD references procedures for enabling CC mode. The TOE uses a cryptographic
module (but which cannot be claimed as being FIPS validated) however the algorithms the TOE uses have
been put through CAVP testing. Section 7.8 describes what the self-tests include and what happens when
an error occurs. The cryptographic module performs known answer tests (KAT) at boot for each of the
cryptographic algorithms used by the TOE. The software image is also checked against a known hash to
validate its integrity at boot. Document [2] is a dedicated manual for trouble clearing conditions in order to
return the switch to a fully operational condition. Section 11 of the AGD also reminds the user that Ciena
provides additional support to their customers.
FPT_TUD_EXT.1 –
“The evaluator also ensures that the TSS (or the operational guidance) describes how the candidate
updates are obtained; the processing associated with verifying the digital signature or calculating the hash
of the updates; and the actions that take place for successful (hash or signature was verified) and
unsuccessful (hash or signature could not be verified) cases.”
Section 6.6 of the AGD describes the process for performing a secure system upgrade. The general
instructions for acquiring, verifying, and performing trusted updates are also described in detail in the
“Turn-up and Test” document.
FTA_SSL_EXT.1, FTA_SSL.3, FTA_SSL.4 – There is no specific assurance activity. However, the
assurance activity for testing requires the tester to follow the operational guidance to configure the system
inactivity period. Section 7.3 of the AGD provides information on manual and automatic session
termination activities.
FTA_TAB.1 – There is no specific assurance activity. However, the assurance activity for testing requires
the tester to follow the operational guidance to configure the banner. Section 6.8 of the AGD provides
instructions on how to configure the login banner.
FTP_ITC.1 –
“The evaluator shall confirm that the operational guidance contains instructions for establishing the
allowed protocols with each authorized IT entity, and that it contains recovery instructions should a
connection be unintentionally broken.”
Section 6.4 of the AGD discusses that in the case of disconnected channel between the TOE and the syslog
server, the connection will automatically re-establish with no further input from the administrator. Section
6.6 discusses that if the channel becomes disconnected between the TOE and SFTP server during a
software download, the administrator is required to perform the listed steps in order to download the full
update. As discussed in section 6.6, Section 8.1 also states that the administrator must perform all steps
listed in the case of the communication disconnect during the manual push of audit data to the SFTP server.
FTP_TRP.1 – “The evaluator shall confirm that the operational guidance contains instructions for establishing the
remote administrative sessions for each supported method.”
Section 7.2 of the AGD states that in the event the administrator/superuser gets disconnected while
remotely administering the TOE, they must re-authenticate in order to resume management activities.
07/22/2015 CC TEST LAB #200423-0
Page - 11 -
AGD_OPE.1 –
“The operational guidance shall at a minimum list the processes running (or that could run) on the TOE in
its evaluated configuration during its operation that are capable of processing data received on the
network interfaces (there are likely more than one of these, and this is not limited to the process that
"listens" on the network interface). It is acceptable to list all processes running (or that could run) on the
TOE in its evaluated configuration instead of attempting to determine just those that process the network
data. For each process listed, the administrative guidance will contain a short (e.g., one- or two-line)
description of the process' function, and the privilege with which the service runs. "Privilege" includes the
hardware privilege level (e.g., ring 0, ring 1), any software privileges specifically associated with the
process, and the privileges associated with the user role the process runs as or under.”
Section 5.4 of the AGD discusses the protocols that are used by the TOE also it lists all of the protocols that
are supported by the TOE but are considered outside of the scope of the evaluation. In addition the AGD
details the configuration of the SSH Public/Private Key authentication (Section 6.7), Syslog Server over
TLS (Section 6.4), updating the TOE over SFTP (Section 6.6), and enabling the TOE into CC mode
(Section 6.1) which pre-configures the TOE with only the authorized algorithms used for SSH and TLS.
“The operational guidance shall contain instructions for configuring the cryptographic engine associated
with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of
other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE.”
The cryptographic algorithms used in SSH and TLS are restricted by placing the TOE into “CC mode” as
described in Section 6.1 of the AGD. The algorithms are set to only those identified in Section 8.2.8 of the
ST which meet the PP requirements. All other algorithms are disabled.
“The documentation must describe the process for verifying updates to the TOE, either by checking the
hash or by verifying a digital signature. The evaluator shall verify that this process includes the following
steps:
1. For hashes, a description of where the hash for a given update can be obtained.
2. Instructions for obtaining the update itself. This should include instructions for making the update
accessible to the TOE (e.g., placement in a specific directory).
3. Instructions for initiating the update process, as well as discerning whether the process was successful
or unsuccessful. This includes generation of the hash/digital signature.”
Section 6.6 of the AGD provides instructions on performing a secure software upgrade and verifying the
Release Signing Certificate information using the MCLI.
“The TOE will likely contain security functionality that does not fall in the scope of evaluation under this
PP. The operational guidance shall make it clear to an administrator which security functionality is
covered by the evaluation activities.”
Section 5 of the AGD specifies the evaluated configuration of the TOE. Section 6 specifies the secure
installation and configuration and section 7 specifies the secure management of the TOE. The security
functionalities defined by these sections are consistent with those found in the ST and so it is clear which
security functionalities are covered by the evaluation activities. Additionally, Section 2 of the AGD states:
“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 Ciena 5400 Series Packet Optical Platform 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.”
Since the AGD references external documents, it is understood that only the sections of those external
documents specifically referenced by the AGD are an extension to the statement above. All other portions
of the externally referenced documents are considered outside the scope of the evaluation which is in line
with the following statement, also in Section 2 of the AGD: “Any functionality that is not described here or
in the Ciena 5400 Series Packet Optical Platform Security Target was not evaluated and should be
exercised at the user’s risk.”
07/22/2015 CC TEST LAB #200423-0
Page - 12 -
AGD_PRE.1 –
“As indicated in the introduction above, there are significant expectations with respect to the
documentation—especially when configuring the operational environment to support TOE functional
requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately
addresses all platforms claimed for the TOE in the ST.”
Section 5 of the AGD describes the evaluated configuration of the TOE. In Section 5.1 the TOE
components are specified (Ciena 5410 and Ciena 5430 using linux kernel version 3.4.36), in Section 5.2 the
supporting environmental components are specified and in Section 5.3 the assumptions are specified.
4 Test Assurance Activities (Test Report) The following sections demonstrate that all ATE Assurance Activities for the TOE have been met. This
evidence has been presented in a manner that is consistent with the “Reporting for Evaluations Against
NIAP-Approved Protection Profiles” guidance that has been provided by NIAP. Specific test steps and
associated detailed results are not included in this report in order for it to remain non-proprietary. The test
report is a summarized version of the test activities that were performed as part of creating the Evaluation
Technical Report (ETR).
4.1 Platforms Tested and Composition
The evaluation team set up a test environment for the independent functional testing that allowed them to
perform all test assurance activities across two pre-configured models and over the relevant interfaces. The
testing performed has a complete overlap between the tested models and interfaces to validate that the TOE
performs the same regardless of the specific model.
Both the Ciena 5430 and 5410 models that are part of this evaluation were deployed at the vendor’s test
facility. These models were used for the execution of the independent functional testing and vulnerability
testing.
The evaluation team performed testing of the TSF functionality across both of the models as well as each of
the available management interfaces (MCLI and TLS). The full set of tests were replicated for each model
and the tests were developed to stimulate each applicable TSF relevant interface; which would fully test all
combinations of the selected models and their TSF relevant interfaces. The testing performed on each
physical interface of each model, with the same logical interface SFR functionality, validated that the
internal processing of the TOE would produce the same results regardless of the specific model or physical
interface used to initiate or perform the processing. The testing is consistent with the use of the interfaces
defined within the ST. Thus, the testing of the interfaces was based upon testing SFR functionality related
to user actions over each interface.
4.2 Omission Justification
Both the Ciena 5430 and Ciena 5410 models were tested. No models were omitted.
4.3 Assessment of the Ciena Test Environment
4.3.1 Physical Assessment
Ciena Headquarters located in Hanover, MD is the physical location for the Ciena 5400 Series Packet
Optical Platform test environment. Booz Allen reviewed the physical security controls of the test
environment and interviewed Ciena employees to ensure that the Ciena 5400 Series Packet Optical
Platform testing environment was secure. Booz Allen has found that Ciena Headquarters has similar access
controls to Booz Allen’s CCTL. The Ciena location requires a person to be a Ciena employee to enter the
building or be escorted as a visitor by a Ciena employee. The building is primarily controlled by a badge
access system for employees whereas visitors must sign in and wear a temporary visitor nameplate. The
07/22/2015 CC TEST LAB #200423-0
Page - 13 -
laboratory where the Ciena 5400 Series Packet Optical Platform devices are installed is a secured internal
room located at the Ciena Headquarters location. Thus, physical access to the Ciena 5400 Series Packet
Optical Platform devices would require a person to pass through the badge access control by being a Ciena
employee or a visitor being escorted by a Ciena employee as well as have access to the internal room where
the servers are located. The evaluator conducted a daily inspection of the space and equipment for any
signs of tampering of the space or equipment and found no such evidence of malicious tampering. Booz
Allen finds that these physical access controls are satisfactory to protect the environment from unwanted
physical access.
4.3.2 Logical Assessment
The functional testing can be executed remotely from the physical test environment. The only way to
access the Ciena 5400 Series Packet Optical Platform devices was to connect to the local test network that
the TOE resides on and that was built for common criteria functional testing specifically. At the end of each
work day, the evaluators saved any configuration that was performed according to the AGD and shutdown
the devices. At times during the testing, Ciena personnel performed changes to the configuration of the test
environment. This was mainly to swap out the TOE for another model to be able to conduct testing. Any
configuration performed by Ciena personnel during the functional testing timeframe was conducted using
the AGD as guidance and under the supervision of the evaluators. Booz Allen finds these logical access
controls are satisfactory to protect the environment from unwanted logical access.
4.4 Test Cases
The evaluation team completed the functional testing activities within the vendor’s test environment. The
evaluation team conducted a set of testing that includes all ATE Assurance Activities as specified by the
‘Protection Profile for Network Devices Version 1.1’ (NDPP) and ‘Security Requirements for Network
Devices Errata #3’ (Errata). The evaluators reviewed the NDPP and Errata to identify the security
functionality that must be verified through functional testing. This is prescribed by the Assurance Activities
for each SFR.
If an SFR is not listed, one of the following conditions applies:
The Assurance Activity for the SFR specifically indicates that it is simultaneously satisfied by
completing a test Assurance Activity for a different SFR.
The Assurance Activity for the SFR does not specify any actions related to ATE activities (e.g.
FPT_APW_EXT.1).
Note that some SFRs do not have Assurance Activities associated with them at the element level (e.g.
FCS_SSH_EXT.1.1). In such cases, testing for the SFR is considered to be satisfied by completion of all
Assurance Activities at the component level.
The following lists for each ATE Assurance Activity, the test objective, test instructions, test steps, and test
results. Note that unless otherwise specified, the test configuration is to be in the evaluated configuration as
defined by the OPE. For example, some tests require the TOE to be brought out of the evaluated
configuration to temporarily disable cryptography to prove that the context of transmitted data is accurate.
As part of the cleanup for each test, the TOE is returned to the evaluated configuration.
4.4.1 Security Audit
Test Case Number 001
SFR FAU_GEN.1 and FAU_GEN.2
Test Objective The purpose of this test is to verify the TOE generates audit records for start-up and
shutdown of the TOE.
Test Instructions Execute this test per the test steps.
07/22/2015 CC TEST LAB #200423-0
Page - 14 -
Test Steps 1. Authenticate to the TOE via the MCLI.
2. Option 6 - Perform system operations
3. Option 8 – Full reset the primary CTM. This step will reboot the TOE and
will produce audit records of the shutdown and startup.
4. Perform actions related to the SFRs listed in Table 18 – Auditable Events
from the Security Target such that an audit record is generated for that
particular action.
Test Results Pass
Execution Method Manual
Test Case Number 002
SFR FAU_STG_EXT.1
Test Objective [TOE is not an audit server]
The purpose of this test is to verify that the audit records are able to be sent to an
audit server and that the audit records are successfully sent via SSH and are not
able to be viewed in the clear during transfer
Test Instructions Execute this test per the test steps.
Test Steps Remote SFTP log server SSH (MCLI):
1. Authenticate to the TOE.
2. Option 6 – Perform system operations
3. Option 23 – Support menu
4. Option 5 – Upload logs, no crash dump files
5. Option 1 – Create log archive
6. For the module, type: “all”.
7. Option 3 – Enter URL for logs archive file transfer – guided entry
8. For the transfer protocol, type “sftp”.
9. Specify SFTP server IP address and port, destination path, username (Option
4), and password (Option 5).
10. Option 7 to initiate the transfer.
11. Audit log data can be found within the transferred archived .tar file by
extracting it and navigating on the destination server to:
logs-<NODE_NAME>-<SLOT_NAME_FROM_STEP_6>-
<TIMESTAMP>-<CLI_PID>.tgz\var\log\messages AND
logs-<NODE_NAME>-<SLOT_NAME_FROM_STEP_6>-
<TIMESTAMP>-<CLI_PID>.tgz\var\log\archive\messages.*.gz
Remote syslog server SSH (MCLI):
1. Authenticate to the TOE.
2. Option 7 – Modify system configuration
3. Option 18 – Security Log Settings Menu
4. Option 2 – Enable/Disable External Security Log Support (enable)
5. Option 3 – Set Security Log Remote Destination IP (Input syslog IP address
and port at prompt)
6. Option 4 – Set Security Log Connection Mode (tls)
7. Option 6 – Commit pending Security Log configuration
07/22/2015 CC TEST LAB #200423-0
Page - 15 -
Test Results Pass
Execution Method Manual
4.4.2 Cryptographic Security
Test cases for FCS_CKM.1, FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), and
FCS_RBG_EXT.1 are not included within this section. This is because the ATE Assurance Activities have
been satisfied by the vendor having the TOE's algorithms assessed under Cryptographic Algorithm
Validation Program (CAVP). As part of CAVP validation the TOE’s cryptographic algorithms went
through CAVS testing which directly maps to these SFRs’ ATE Assurance Activities. Refer to the results
of the CAVP validation for the certificates listed within the Security Target.
Test Case Number 003
SFR FCS_SSH_EXT.1
Test Objective The purpose of this test is to verify that the TOE supports the use of each claimed
SSH public key algorithm to authenticate a user connection.
Test Instructions Execute this test per the test steps.
Test Steps SSH (TL1):
1. On the test machine configure the SSH client to only use the RSA public key
algorithm.
2. Begin capturing packets on the test machine.
3. Initiate a connection to the TOE via SSH and authenticate via the TL1
interface.
4. Stop capturing packets on the test machine.
5. Confirm that the SSH connection was successful and that it used the RSA
public key algorithm by reviewing packet capture data.
SSH (MCLI):
1. On the test machine configure the SSH client to only use the RSA public key
algorithm.
2. Begin capturing packets on the test machine.
3. Initiate a connection to the TOE via SSH and authenticate via the CLI
interface.
4. Stop capturing packets on the test machine.
5. Confirm that the SSH connection was successful and that it used the RSA
public key algorithm by reviewing packet capture data.
Test Results Pass
Execution Method Manual
Test Case Number 004
SFR FCS_SSH_EXT.1
Test Objective The purpose of this test is to verify that the TOE supports the use of password-
based SSH authentication.
Test Instructions Execute this test per the test steps.
Test Steps 1. Testing for this activity has been satisfied as a result of the SFR
Assurance Activity testing performed in FIA_UIA_EXT.1 Test 013.
07/22/2015 CC TEST LAB #200423-0
Page - 16 -
Test Results Pass
Execution Method Manual
Test Case Number 005
SFR FCS_SSH_EXT.1
Test Objective Verify that the TOE rejects excessively large SSH packets.
Test Instructions Execute this test per the test steps.
Test Steps SSH (MCLI):
1. Open Wireshark on the test system and begin packet capture.
2. Initiate a connection to the TOE by running a tool and executing the
commands to inject a packet larger than the maximum allowed
3. Stop Wireshark packet capture.
4. Analyze Wireshark packet capture for TCP [RST] responses to the test
system from the TOE.
SSH (TL1):
1. Open Wireshark on the test system and begin packet capture.
2. Initiate a connection to the TOE by running a tool and executing the
commands to inject a packet larger than the maximum allowed
3. Stop Wireshark packet capture.
4. Analyze Wireshark packet capture for TCP [RST] responses to the test
system from the TOE.
Test Results Pass
Execution Method Manual
Test Case Number 006
SFR FCS_SSH_EXT.1
Test Objective The purpose of this test is to verify that the TOE supports only AES-CBC-128 and
AES-CBC-256 encryption algorithms as specified in the Security Target.
Test Instructions Execute this test per the test steps.
Test Steps SSH (TL1):
1. Begin capturing packets on the test machine.
2. On the test machine, configure the SSH client use only AES-CBC-128 as the
encryption algorithm.
3. Connect to the TOE using the SSH client.
4. Stop capturing packets on the test machine.
5. Examine the packets to verify that AES-CBC-128 was used as the
encryption algorithm.
6. Terminate the SSH connection.
7. Repeat Steps 1-6 except replace “AES-CBC-128” with “AES-CBC-256.”
8. Repeat Steps 1-4 except replace “AES-CBC-128” with “3DES-CBC.”
9. Verify that an SSH session failed to establish.
SSH (MCLI):
1. Begin capturing packets on the test machine.
2. On the test machine, configure the SSH client use only AES-CBC-128 as the
07/22/2015 CC TEST LAB #200423-0
Page - 17 -
encryption algorithm.
3. Connect to the TOE using the SSH client.
4. Stop capturing packets on the test machine.
5. Examine the packets to verify that AES-CBC-128 was used as the
encryption algorithm.
6. Terminate the SSH connection.
7. Repeat Steps 1-6 except replace “AES-CBC-128” with “AES-CBC-256.”
8. Repeat Steps 1-4 except replace “AES-CBC-128” with “3DES-CBC.”
9. Verify that an SSH session failed to establish.
Test Results Pass
Execution Method Manual
Test Case Number 007
SFR FCS_SSH_EXT.1
Test Objective The purpose of this test is to ensure the TOE uses hmac-sha1 and hmac-sha2-256 as
its data integrity algorithms.
Test Instructions Execute this test per the test steps.
Test Steps 1. Begin capturing packets on the test machine.
2. On the test machine, configure the SSH client use only the hmac-sha1
integrity algorithm.
3. Connect to the TOE using the SSH client.
4. Stop capturing packets on the test machine.
5. Examine the packets to verify that the hmac-sha1 integrity algorithm was
used.
6. Terminate the SSH connection.
7. Repeat Steps 1-6 except replace “hmac-sha1” with “hmac-sha2-256.”
Test Results Pass
Execution Method Manual
Test Case Number 008
SFR FCS_SSH_EXT.1
Test Objective Verify that the TOE only allows diffie-hellman-group14-sha1 for the SSH key
exchange protocol.
Test Instructions Execute this test per the test steps.
Test Steps 1. Begin capturing packets on the test machine.
2. On the test machine, configure the SSH client use only the diffie-hellman-
group14-sha1 key exchange method.
3. Connect to the TOE using the SSH client.
4. Stop capturing packets on the test machine.
5. Examine the packets to verify that the diffie-hellman-group14-sha1 key
exchange method was used.
6. Terminate the SSH connection.
7. Repeat Steps 1-6 except replace “diffie-hellman-group14-sha1” with
“diffie-hellman-group1-sha1.”
8. Verify that an SSH session failed to establish Test Results Pass
Execution Method Manual
Test Case Number 009
SFR FCS_TLS_EXT.1
Test Objective Verify that the TOE supports the establishment of TLS connections using
07/22/2015 CC TEST LAB #200423-0
Page - 18 -
appropriate ciphersuites.
Test Instructions Execute this test per the test steps.
Test Steps 1. Configure the remote syslog server to only use the
“TLS_RSA_WITH_AES_128_CBC_SHA” ciphersuite.
2. Begin capturing packets on the test machine.
3. Perform operations on the TOE that cause syslog data to be transmitted to
the remote syslog server.
4. Stop capturing packets on the test machine.
5. Validate that the TLS connection between the TOE and the remote syslog
server was successful and used only the ciphersuite specified in Step 1.
6. Repeat Steps 1-5, except replace
“TLS_RSA_WITH_AES_128_CBC_SHA” with
“TLS_RSA_WITH_AES_256_CBC_SHA”.
7. Repeat Steps 1-5, except replace
“TLS_RSA_WITH_AES_256_CBC_SHA” with
“TLS_RSA_WITH_AES_128_CBC_SHA256”.
8. Repeat Steps 1-5, except replace
“TLS_RSA_WITH_AES_128_CBC_SHA256” with
“TLS_RSA_WITH_AES_256_CBC_SHA256”.
9. Repeat Steps 1-5, except replace
“TLS_RSA_WITH_AES_256_CBC_SHA256” with
“DHE_TLS_RSA_WITH_AES_128_SHA256”.
Test Results Pass
Execution Method Manual
4.4.3 User Data Protection
There are no ATE Assurance Activities for any SFRs in this class.
4.4.4 Identification and Authentication
Test Case Number 011
SFR FIA_PMG_EXT.1
Test Objective The purpose of this test is to show that the TOE supports the password length of a
minimum of 15 characters and a combination of special characters as outlined in
the Security Target.
Test Instructions Execute this test per the test steps.
Test Steps SSH (TL1):
1. Authenticate to the TOE as a newly created user (bahuser) via the TL1
interface.
2. Enter the following command to change the password for the currently
logged in user:
ed-pid::bahuser:abc::mypassword!2345:abcdefghijklmn1!;
3. Enter the following command to logout:
canc-user::bahuser:abc;
4. Authenticate to the TOE as the bahuser via the TL1 interface using the
password created in Step 2.
5. Validate that the user is successfully authenticated.
6. Enter the following command to logout:
canc-user::bahuser:abc;
07/22/2015 CC TEST LAB #200423-0
Page - 19 -
7. Authenticate to the TOE as the Administrator:
act-user::administrator:abc::admin1!;
8. Enter the following command to delete the “bahuser” account and create a
new “bahuser” account with the new password:
dlt-user-secu::bahuser:abc;
ent-user-secu::bahuser:abc:: opqrstuvwxyzAB2%,TL1,AA
9. Enter the following command to logout:
canc-user::administrator:abc;
10. Authenticate to the TOE as the bahuser via the TL1 interface using the
password created in Step 8.
11. Validate that the user is successfully authenticated.
12. Repeat steps 6-8 and create the bahuser using a new password:
ent-user-secu::bahuser:abc:: CDEFGHIJKLMNOP3^,TL1,AA 13. Enter the following command to logout:
canc-user::administrator:abc;
14. Authenticate to the TOE as the bahuser via the TL1 interface using the
password created in Step 12.
15. Validate that the TOE successfully authenticated. 16. Repeat steps 6-8 and create the bahuser using a new password:
ent-user-secu::bahuser:abc:: QRSTUVWXYZ01234!,TL1,AA
17. Enter the following command to logout:
canc-user::administrator:abc;
18. Authenticate to the TOE as the bahuser via the TL1 interface using the
password created in Step 16.
19. Validate that the user is successfully authenticated.
20. Repeat steps 6-8 and create the bahuser using a new password:
ent-user-secu::bahuser:abc:: 56789!%^()+-!!a,TL1,AA;
21. Enter the following command to logout:
canc-user::administrator:abc;
22. Authenticate to the TOE as the bahuser via the TL1 interface using the
password created in Step 20.
23. Validate that the TOE successfully authenticated.
24. Repeat steps 6-8 and create the bahuser using a new password:
ent-user-secu::bahuser:abc::bcdef123[]`~{}|_:TL1,AA;
25. Enter the following command to logout:
canc-user::administrator:abc;
26. Authenticate to the TOE as the bahuser via the TL1 interface using the
password created in Step 24.
27. Validate that the user is successfully authenticated.
28. Repeat steps 6-8 and create the bahuser using a new password:
ent-user-secu::bahuser:abc:: bcdefghijklA1!;TL1,AA;
29. The TOE rejects the creation of the account using this password because it
is less than the minimum character requirement of 15.
Test Results Pass
Execution Method Manual
Test Case Number 012
SFR FIA_UAU.7
07/22/2015 CC TEST LAB #200423-0
Page - 20 -
Test Objective The purpose of this test is to verify that the TOE does not provide any feedback
while a local user is entering their password credential.
Test Instructions Execute this test per the test steps.
Test Steps 1. Authenticate to the TOE via the local console.
2. While entering password information, verify that the most obscured
feedback is provided.
Test Results Pass
Execution Method Manual
Test Case Number 012
SFR FIA_UIA_EXT.1
Test Objective The purpose of this test is to verify the ability of the TOE to either allow or deny
access of users to the system using correct/incorrect login authentication credentials
that are supported by the TOE. This test applies to all user interfaces.
Test Instructions Execute this test per the test steps.
Test Steps Local console (password based):
1. Authenticate to the TOE via the local console using a valid username and
password.
2. Verify that the TOE successfully authenticated and that audit logs were
generated reflecting the login.
3. Authenticate to the TOE via the local console using an invalid username
and valid password.
4. Verify that the TOE failed to authenticate and that audit logs were
generated reflecting the failure.
5. Authenticate to the TOE via the local console using a valid username and
an invalid password.
6. Verify that the TOE failed to authenticate and that audit logs were
generated reflecting the failure.
7. Authenticate to the TOE via the local console using an invalid username
and an invalid password.
8. Verify that the TOE failed to authenticate and that audit logs were
generated reflecting the failure.
Remote SSH (MCLI) (password based):
1. Authenticate to the TOE via SSH using a valid username and password.
2. Verify that the TOE successfully authenticated and that audit logs were
generated reflecting the login.
3. Authenticate to the TOE via SSH using an invalid username and valid
password.
4. Verify that the TOE failed to authenticate and that audit logs were generated
reflecting the failure.
5. Authenticate to the TOE via SSH using a valid username and an invalid
password.
6. Verify that the TOE failed to authenticate and that audit logs were generated
reflecting the failure.
7. Authenticate to the TOE via SSH using an invalid username and an invalid
password.
07/22/2015 CC TEST LAB #200423-0
Page - 21 -
8. Verify that the TOE failed to authenticate and that audit logs were generated
reflecting the failure.
Remote SSH (TL1) (password based):
1. Initiate a connection to the TOE via SSH and then authenticate to the TOE
via TL1 using the following command for valid username and valid
password:
act-user::administrator:abc::admin1!;
2. Verify that the TOE successfully authenticated and that audit logs were
generated reflecting the login.
3. Initiate a connection to the TOE via SSH and then authenticate to the TOE
via TL1 using the following command an invalid username and valid
password:
act-user::baduser:abc::admin1!;
4. Verify that the TOE failed to authenticate and that audit logs were generated
reflecting the failure.
5. Initiate a connection to the TOE via SSH and then authenticate to the TOE
via TL1 using a valid username and an invalid password.
act-user::administrator:abc::badpwd!;
6. Verify that the TOE failed to authenticate and that audit logs were generated
reflecting the failure.
7. Initiate a connection to the TOE via SSH and then authenticate to the TOE
via TL1 using an invalid username and an invalid password.
act-user::baduser2:abc::badpwd2!;
8. Verify that the TOE failed to authenticate and that audit logs were generated
reflecting the failure.
Remote SSH (MCLI) (public/private key based):
1. Authenticate to the TOE via SSH using a valid username and valid private
key.
2. Verify that the TOE successfully authenticated and that audit logs were
generated reflecting the login.
3. Authenticate to the TOE via SSH using an invalid username and a valid
private key.
4. Verify that the TOE failed to authenticate and that audit logs were generated
reflecting the failure.
5. Authenticate to the TOE via SSH using a valid username and an invalid
private key.
07/22/2015 CC TEST LAB #200423-0
Page - 22 -
6. Verify that the TOE failed to authenticate and that audit logs were generated
reflecting the failure.
7. Authenticate to the TOE via SSH using an invalid username and an invalid
private key.
8. Verify that the TOE failed to authenticate and that audit logs were generated
reflecting the failure.
Test Results Pass
Execution Method Manual
Test Case Number 014
SFR FIA_UIA_EXT.1
Test Objective For remote access, the evaluator shall determine what services are available to a
local administrator prior to logging in, and make sure this list is consistent with the
requirement.
Test Instructions Execute this test per the test steps.
Test Steps SSH (MCLI):
1. Authenticate to the TOE via SSH.
2. Verify that the warning banner is displayed prior to authentication to the
TOE.
3. Verify that no other services are available prior to authentication by entering
a privileged command such as “1” to
“Display system configuration” at the username and password prompts.
TL1 (SSH)
1. Authenticate to the TOE as the administrator.
2. Enter command:
ED-ECFG::CUSTOMERSETTINGS:MYSTAG::PREBANNER=Welcome
TEST;
3. Attempt to authenticate to the TOE via the TL1 interface.
4. Validate that the warning banner configured in step 2 is presented prior to
authentication.
5. Verify that no other services are available prior to authentication by entering
a privileged command such as “rtrv-TOD:::abc;” at the prompt.
Test Results Pass
Execution Method Manual
Test Case Number 015
SFR FIA_UIA_EXT.1
Test Objective For local access, the evaluator shall determine what services are available to a local
administrator prior to logging in, and make sure this list is consistent with the
requirement.
Test Instructions Execute this test per the test steps.
Test Steps Local Console (MCLI):
1. Authenticate to the TOE via the local console.
2. Verify that the warning banner is displayed prior to authentication to the
TOE.
3. Verify that no other services are available prior to authentication by
07/22/2015 CC TEST LAB #200423-0
Page - 23 -
entering a privileged command such as “1” to
“Display system configuration” at the username and password prompts.
Test Results Pass
Execution Method Manual
4.4.5 Security Management
The ATE assurance activities for this class are described in the NDPP as being implicitly satisfied through
the execution of other testing. Therefore, there are no independent assurance activities for this class.
4.4.6 Protection of the TSF
Test Case Number 016
SFR FPT_STM.1
Test Objective The purpose of this test is to ensure that the time is able to be correctly set on the
TOE.
Test Instructions Execute this test per the test steps.
Test Steps SSH (TL1):
1. Authenticate to the TOE.
2. Use the following TL1 command to edit the date and time:
ED-DAT:::abc::DATE=15-11-11,TIME=09-40-22;
3. Verify that the date and time was set by entering the following TL1
command:
rtrv-TOD:::abc;
4. Log out of the TOE.
5. Log into the TOE and run the command to show the system time and
verify that it saved.
Test Results Pass
Execution Method Manual
Test Case Number 017
SFR FPT_STM.1
Test Objective The purpose of this test is to ensure that the time is correctly set on the TOE by an
NTP server.
Test Instructions Execute this test per the test steps.
Test Steps SSH (MCLI):
1. Authenticate to the TOE through the MCLI.
2. Using the following commands configure the TOE to sync with the NTP
server.
a) Option 7 – Modify System Configuration
b) Option 16 – NTP Settings Menu
a. Option 2 – Enable
b. Option 3 – Client mode
c. Option 4 – Enable/Disable Authentication Support
07/22/2015 CC TEST LAB #200423-0
Page - 24 -
d. Option 7 – NTP Server Settings Menu
i. Option 4 – Set IP address for NTP = 10.41.77.2
ii. Option 5 – Set Server Authentication Key ID = 0
iii. Option 6 – Enable/Disable iburst mode = enable (default)
iv. Option 7 – Set Minimum Polling Interval = 64 (default)
v. Option 8 – Set Maximum Polling Interval = 1024 (default)
vi. Option 10 – Commit NTP Server
Test Results Pass
Execution Method Manual
Test Case Number 018
SFR FPT_TUD_EXT.1
Test Objective The purpose of this test is to ensure that the TOE successfully installs a legitimate
update by demonstrating the update functions as expected and by comparing the
previous version with the updated version.
Test Instructions Execute this test per the test steps.
Test Steps SSH (MCLI):
1. Authenticate to the TOE via the MCLI.
2. Option 3 – Upgrade or revert software release.
3. Option 3 – Download a new release.
4. Option 1 – List available software releases and scroll up to view RELEASE
that is “good in-use” for the current version.
5. Choose Option 3 – Enter URL for software release file transfer – guided
entry.
a) Enter the protocol (SFTP)
b) Enter the IP address
c) (Optional) Enter port number
d) (Optional) Enter path of the file
6. Option 4 – Enter user name for file server access.
7. Option 5 – Enter password for file server access.
8. Begin capturing packets on the test machine.
9. Option 7 – Transfer software release from the file server.
10. After the transfer is finished, choose Option 8 – Return to previous menu.
11. Stop capturing packets on the test machine.
12. Option 5 – Upgrade to new software release.
13. Specify the name of the release to upgrade to from the list of available
updates.
14. After the update has finished installing and a login prompt is returned,
authenticate to the TOE.
15. Query the TOE for its current version and verify that the version number has
increased.
Test Results Pass
Execution Method Manual
Test Case Number 019
07/22/2015 CC TEST LAB #200423-0
Page - 25 -
SFR FPT_TUD_EXT.1
Test Objective The purpose of this test is to ensure that the TOE rejects an illegitimate update.
Test Instructions Execute this test per the test steps.
Test Steps SSH (MCLI):
1. Authenticate to the TOE via the MCLI.
2. Option 3 – Upgrade or revert software release.
3. Option 1 – List available software releases and scroll up to view RELEASE
that is “good in-use” and notate the current version.
4. Option 3 – Download a new release.
5. Option 3 – Enter URL for software release file transfer – guided entry.
a) Enter the protocol (SFTP)
b) Enter the IP address (192.168.100.9)
c) (Optional) Enter port number
d) (Optional) Enter path of the file
6. Option 4 – Enter user name for file server access.
7. Option 5 – Enter password for file server access.
8. Option 7 – Transfer software release from the file server.
9. Validate that the TOE failed to download the update because of a signature
failure.
10. Choose Option 1 – List available software releases and scroll up to view
RELEASE that is “good in-use” and notate the current version
Test Results Pass
Execution Method Manual
4.4.7 TOE Access
Test Case Number 020
SFR FTA_SSL_EXT.1
Test Objective The purpose of this test is to ensure that local interactive sessions to the TOE are
terminated after various inactivity specifications.
Test Instructions Execute this test per the test steps.
Test Steps 1. Authenticate to the TL1 interface as the administrator.
2. Enter the command to configure the timeout for the superuser.
ed-user-secu::superuser:abc:::TMOUT=3;
3. Authenticate to the local console as the superuser and do not perform any
action. Wait for the session to timeout.
4. Repeat step 2
ed-user-secu::bahuser:abc:::TMOUT=5;
5. Repeat step 3.
6. Repeat step 2.
ed-user-secu::bahuser:abc:::TMOUT=7;
7. Repeat step 4.
8. Collect the log files that show the login and session termination due to
07/22/2015 CC TEST LAB #200423-0
Page - 26 -
inactivity.
Test Results Pass
Execution Method Manual
Test Case Number 021
SFR FTA_SSL.3
Test Objective The purpose of this test is to ensure that remote interactive sessions to the TOE are
terminated after various inactivity specifications.
Test Instructions Execute this test per the test steps.
Test Steps SSH (TL1):
1. Authenticate to the TOE as the Administrator via the TL1 interface.
2. Create a user and configure the timeout using the following command:
ent-user-secu::bahuser:abc::<password>,TL1,AA:TMOUT=3;
3. Log out of the administrator account and log in using the account that was
created in Step 2.
4. Keep the session idle and wait 3 minutes for the session to log out.
5. Authenticate to the TOE as the Administrator.
6. Change the timeout for the user that was created to 5 minutes using the
following command:
ed-user-secu::bahuser:abc:::TMOUT=5;
7. Log out of the administrator account and log in using the account that was
created in Step 2.
8. Keep the session idle and wait 5 minutes for the session to log out.
9. Authenticate to the TOE as the Administrator via the TL1 interface.
10. Change the timeout for the user that was created to 7 minutes using the
following command:
ed-user-secu::bahuser:abc:::TMOUT=7;
11. Log out of the administrator account and log in using the account that was
created in Step 2.
12. Keep the session idle and wait 7 minutes for the session to log out.
Test Results Pass
Execution Method Manual
Test Case Number 022
SFR FTA_SSL.4
Test Objective The purpose of this test is to ensure that an administrator can terminate its own
local interactive session
Test Instructions Execute this test per the test steps.
Test Steps 1. Authenticate to the TOE via the local console.
2. Enter the “10” command to terminate the session.
3. Observe that the session has been terminated.
Test Results Pass
07/22/2015 CC TEST LAB #200423-0
Page - 27 -
Execution Method Manual
Test Case Number 023
SFR FTA_SSL.4
Test Objective The purpose of this test is to ensure that an administrator can terminate its own
remote interactive session.
.
Test Instructions Execute this test per the test steps.
Test Steps SSH (TL1):
1. Authenticate to the TOE via SSH (via port 10220).
2. Enter the “canc-user::<username>:abc;” command to terminate the session.
3. Observe that the session has been terminated.
SSH (MCLI):
1. Authenticate to the TOE via SSH (via port 22).
2. Enter the “10” command to terminate the session.
3. Observe that the session has been terminated.
Test Results Pass
Execution Method Manual
Test Case Number 024
SFR FTA_TAB.1
Test Objective The purpose of this test is to verify that the TOE can be configured to display a
warning message (banner) before establishing any administrative user session.
Test Instructions Execute this test per the test steps.
Test Steps Local console (MCLI) & Remote via SSH (MCLI):
1. Enable the CORBA interface.
2. Launch Ciena Node Manager and populate the following fields:
Node Url: <NODE_NAME>:<TOE_IP_ADDRESS>
User Name: administrator
Password: admin1!
3. Click “NE Defaults” tab > “Account Defaults” tab.
4. In the “Pre Authentication Login Banner” field enter the following text:
“THIS IS A WARNING BANNER! USG SYSTEM! WARNING!”
5. Click on “Accept” and then exit the Ciena Node Manager.
6. Disable the CORBA interface.
7. Attempt to authenticate to the TOE via the local console.
8. Validate that the warning banner configured in Step 4 is presented prior to
authentication.
9. Attempt to authenticate to the TOE via SSH (MCLI).
10. Validate that the warning banner configured in Step 4 is presented prior to
authentication.
07/22/2015 CC TEST LAB #200423-0
Page - 28 -
TL1 (SSH)
1. Authenticate to the TOE as the administrator.
2. Enter command:
ED-ECFG::CUSTOMERSETTINGS:MYSTAG::PREBANNER=Welcome
TEST;
3. Attempt to authenticate to the TOE via the TL1 interface.
4. Validate that the warning banner configured in step 2 is presented prior to
authentication.
Test Results Pass
Execution Method Manual
4.4.8 Trusted Path/Channels
Test Case Number 025
SFR FTP_ITC.1
Test Objective 1. Ensure that communications using each protocol with each authorized IT entity
is tested during the course of the evaluation, setting up the connections as described
in the operational guidance and ensuring that communication is successful.
Test Instructions Execute this test per the test steps.
Test Steps TOE and SFTP update server
This test is conducted in conjunction with the test assurance activities in
FPT_TUD_EXT.1 – Test 018.
TOE and Remote log repository server
1. Begin capturing packets on the test machine.
2. Perform Steps 1-10 in FAU_STG_EXT.1 – Test 002 – SSH (MCLI).
3. Stop capturing packets on the test man-in-the-middle test machine.
4. Observe that communication between the TOE and the remote log
repository server is encrypted.
TOE and Remote syslog server
1. This test is conducted in conjunction with the test assurance activities
in FCS_TLS_EXT.1 – Test 009
Test Results Pass
Execution Method Manual
Test Case Number 026
SFR FTP_ITC.1
Test Objective 1. For each protocol that the TOE can initiate as defined in the requirement, the
evaluator shall follow the operational guidance to ensure that in fact the
communication channel can be initiated from the TOE.
Test Instructions Execute this test per the test steps.
Test Steps TOE and SFTP update server
This test is conducted in conjunction with the test assurance activities in
FPT_TUD_EXT.1 – Test 018.
07/22/2015 CC TEST LAB #200423-0
Page - 29 -
TOE and Remote log repository server
1. Begin capturing packets on the test machine.
2. Perform Steps 1-10 in FAU_STG_EXT.1 – Test 002 – SSH (MCLI).
3. Stop capturing packets on the test man-in-the-middle test machine.
4. Observe that communication between the TOE and the remote log
repository server is encrypted and initiated by the TOE.
TOE and Remote syslog server
This test is conducted in conjunction with the test assurance activities in
FCS_TLS_EXT.1 – Test 009
1. Begin capturing packets on the test machine.
2. Perform some action that causes the TOE to transmit audit data to the
remote syslog server.
3. Stop capturing packets on the test man-in-the-middle test machine.
4. Observe that communication between the TOE and the remote syslog
server is encrypted and initiated by the TOE.
Test Results Pass
Execution Method Manual
Test Case Number 027
SFR FTP_ITC.1
Test Objective 1. The evaluator shall ensure, for each communication channel with an authorized
IT entity, the channel data are not sent in plaintext.
Test Instructions Execute this test per the test steps.
Test Steps Testing for this SFR Assurance Activity is satisfied by testing performed in the
SFR Assurance Activities for FTP_ITC.1 Tests 025 and 026.
Test Results Pass
Execution Method Manual
Test Case Number 028
SFR FTP_ITC.1
Test Objective 1. The evaluators shall, for each protocol associated with each authorized IT entity
tested during test 1, the connection is physically interrupted. The evaluator shall
ensure that when physical connectivity is restored, communications are
appropriately protected.
Test Instructions Execute this test per the test steps.
Test Steps TOE and SFTP update server
1. Perform Steps 1-9 in FPT_TUD_EXT.1 – Test 018.
2. Physically disconnect the connection between the TOE and the SFTP
update server and then reconnect it before the image transfer is complete.
3. Perform Steps 10-11 in FPT_TUD_EXT.1 – Test 018.
TOE and Remote log repository server
1. Begin capturing packets on the test machine.
2. Perform Steps 1-10 in FAU_STG_EXT.1 – Test 002 – SSH (MCLI).
3. Physically disconnect the connection between the TOE and the remote log
repository server and then reconnect it before the transfer completes.
07/22/2015 CC TEST LAB #200423-0
Page - 30 -
4. Stop capturing packets on the test man-in-the-middle test machine once
the transfer completes.
5. Observe that communication between the TOE and the remote log
repository server is encrypted.
TOE and Remote syslog server
1. Begin capturing packets on the test machine.
2. Perform some action that causes the TOE to transmit audit data to the
remote syslog server.
3. Physically disconnect the connection between the TOE and the syslog
server and then reconnect it after 10 seconds have elapsed.
4. Stop capturing packets on the test man-in-the-middle test machine.
5. Observe that communication between the TOE and the remote syslog
server is encrypted.
Test Results Pass
Execution Method Manual
Test Case Number 029
SFR FTP_TRP.1
Test Objective 1. The evaluators shall ensure that communications using each specified (in the
operational guidance) remote administration method is tested during the course of
the evaluation, setting up the connections as described in the operational guidance
and ensuring that communication is successful.
Test Instructions Execute this test per the test steps.
Test Steps 1. Testing for this SFR Assurance Activity is satisfied by testing
performed in the SFR Assurance Activities for FTP_TRP.1 Test031.
Test Results Pass
Execution Method Manual
Test Case Number 030
SFR FTP_TRP.1
Test Objective For each method of remote administration supported, the evaluator shall follow the
operational guidance to ensure that there is no available interface that can be used
by a remote user to establish a remote administrative sessions without invoking the
trusted path.
Test Instructions Execute this test per the test steps.
Test Steps 1. On the test machine, enter the following commands to perform a
comprehensive port scan against the TOE:
nmap -sT -sV -vv -n -T4 -p 0-65535 -oA <TOE_IP_ADDRESS>
Test Results Pass
Execution Method Manual
Test Case Number 031
SFR FTP_TRP.1
Test Objective The evaluator shall ensure, for each method of remote administration, the channel
data are not sent in plaintext.
Test Instructions Execute this test per the test steps.
07/22/2015 CC TEST LAB #200423-0
Page - 31 -
Test Steps MCLI (SSH)
1. Start Wireshark between the TOE and the remote machine used to
administer the TOE.
2. Connect to the TOE as an administrator using the MCLI.
3. Stop the packet capture and ensure the packets are encrypted.
TL1 (SSH)
1. Start Wireshark between the TOE and the remote machine used to
administer the TOE.
2. Connect to the TOE as an administrator using the TL1 interface.
3. Stop the packet capture and ensure the packets are encrypted.
Test Results Pass
Execution Method Manual
4.5 Vulnerability Testing
The evaluation team created a set of vulnerability tests to attempt to subvert the security of the TOE. These
tests were created based upon the evaluation team's review of the vulnerability analysis evidence and
independent research. The evaluation team conducted searches for public vulnerabilities related to the TOE.
A few notable resources consulted include securityfocus.com, the cve.mitre.org, and the nvd.nist.gov.
Upon the completion of the vulnerability analysis research, the team had identified several generic
vulnerabilities upon which to build a test suite. These tests were created specifically with the intent of
exploiting these vulnerabilities within the TOE or its configuration.
The team tested the following areas:
Port Scanning
Remote access to the TOE should be limited to the standard TOE interfaces and procedures. This
test enumerates network port and service information to determine if any ports were open and
running services outside of the TOE standard configuration.
Force SSHv1
This attack determines if the client will accept both SSHv1 and SSHv2 connections when the TOE
claims to only support SSHv2
SSH Timing Attack (User Enumeration)
This attack attempts to enumerate validate usernames for the SSH interface, by observing the
difference in server response times to valid username login attempts.
The TOE successfully prevented any attempts of subverting its security.
Verdict: The evaluation team has completed testing of this component, resulting in a verdict of PASS.
5 Conclusions The TOE was evaluated against the ST and has been found by this evaluation team to be conformant with
the ST. The overall verdict for this evaluation is: Pass.
6 Glossary of Terms
Acronym Definition
AES Advanced Encryption Standard
CAVP Cryptographic Algorithm Validation Program
CBC Cipher Block Chaining
07/22/2015 CC TEST LAB #200423-0
Page - 32 -
CLI Command Line Interface
CSP Critical Security Parameter
DHE Diffie-Hellman
DRBG Deterministic Random Bit Generator
HMAC Hashed Message Authentication Code
MCLI Management Command Line Interface
MPLS Multiprotocol Label Switching
NDPP Network Device Protection Profile
NTP Network Time Protocol
OSI Open Systems Interconnection
OTN Optical Transport Network
RSA Rivest Shamir Adelman (encryption algorithm)
SDH Synchronous Digital Hierarchy
SFTP Secure File Transfer Protocol
SHA Secure Hash Algorithm
SHS Secure Hash Standard
SONET Synchronous Optical Networking
SSH Secure Shell
TL1 Transaction Language One
Table 6-1: Acronyms
Terminology Definition
Authorized Administrator Any user which has been assigned to a privilege level that is permitted to
perform all TSF-related functions.
Role An assigned role gives a user varying access to the management of the
TOE.
Security Administrator Synonymous with Authorized Administrator for the purposes of this
evaluation.
User Any entity (human user or external IT entity) outside the TOE that interacts
with the TOE.
Table 6-2: Terminology