ciena carrier ethernet solutions 3900/5100 series · pdf fileassurance activities report for a...

Assurance Activities Report

for a Target of Evaluation

Ciena Carrier Ethernet Solutions

3900/5100 Series

Security Target (Version 1.0)

Assurance Activities Report (AAR)

Version 1.0

2/12/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

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

Kevin Le

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

Table of Contents

1 Purpose ............................................................................................................................................... - 1 - 2 TOE Summary Specification Assurance Activities ............................................................................ - 1 - 3 Operational Guidance Assurance Activities ....................................................................................... - 5 - 4 Test Assurance Activities (Test Report) ........................................................................................... - 10 -

4.1 Platforms Tested and Composition ......................................................................................... - 11 - 4.2 Omission Justification ............................................................................................................. - 11 - 4.3 Assessment of the Ciena Test Environment ............................................................................ - 12 -

4.3.1 Physical Assessment ........................................................................................................... - 12 - 4.3.2 Logical Assessment ............................................................................................................ - 12 -

4.4 Test Cases ............................................................................................................................... - 13 - 4.4.1 Security Audit ..................................................................................................................... - 13 - 4.4.2 Cryptographic Security ....................................................................................................... - 14 - 4.4.3 User Data Protection ........................................................................................................... - 17 - 4.4.4 Identification and Authentication ....................................................................................... - 17 - 4.4.5 Security Management ......................................................................................................... - 20 - 4.4.6 Protection of the TSF .......................................................................................................... - 20 - 4.4.7 TOE Access ........................................................................................................................ - 21 - 4.4.8 Trusted Path/Channels ........................................................................................................ - 23 -

4.5 Vulnerability Testing .............................................................................................................. - 26 - 5 Conclusions ...................................................................................................................................... - 26 - 6 Glossary of Terms ............................................................................................................................ - 26 -

1/15/2015 CC TEST LAB #200423-0

Page - 1 -

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 Ciena Carrier Ethernet Solutions 3900/5100 Series

Security Target v1.0 (ST) 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 TSS section 8.1.3 of the ST.

(1) Locally, the TOE stores audit data in up to four files each for the command and security logs. Each file

stores a maximum size of 32 MB.

(2) The oldest log file will be overwritten when storage space is exhausted.

(3) Users must have with Admin or Super privilege to be able to delete the logs.

(4) The TOE is configured to transmit its collected audit data to an SFTP server in the Operational

Environment. Command logs are transferred manually while security logs are able to be sent automatically

on a periodic basis.

(5) The trusted channel used to send audit data to the Operational Environment is protected using SSH.

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.

Section 8.2.1 of the TSS states the sections of which the TOE conforms to SP 800-56A. Specifically the

TOE complies with Section 5.6 for asymmetric key pair generation and key establishment in the NIST SP

800-56A.

1/15/2015 CC TEST LAB #200423-0

Page - 2 -

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.

The TSS section 8.2.2 of the ST discusses how the TOE performs key and cryptographic material

destruction. This description includes SSH host and session keys as well as any plaintext password data that

is entered by a user once the password is hashed. The TSS states the OpenSSL cryptographic module

automatically zeroizes sensitive data via API function calls for any data that resides in temporary memory.

Any SSH keys that are stored persistently on the TOE can be deleted by an administrator with Admin or

Super privilege level.

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_RBG_EXT.1 – This SFR does not contain any NDPP TSS Assurance Activities.

FCS_SSH_EXT.1.1 – This SFR does not contain any NDPP TSS Assurance Activities.

FCS_SSH_EXT.1.2 – The Assurance Activity requires the TSS 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.

TSS section 8.2.8 states the TOE implementation of SSHv2 supports RSA signature verification for

authentication in addition to password-based authentication. This is consistent with the

FCS_SSH_EXT.1.5.

FCS_SSH_EXT.1.3 – The Assurance Activity requires the TSS to describe how “large packets” are

detected and handled.

TSS section 8.2.8 states “large packets, defined here as being greater than 32,768 bytes, are detected by the

SSH implementation and dropped by the SSH 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.

Section 8.2.8 of the TSS correctly states that the TOE implementation of SSHv2 supports AES-CBC-128

and AES-CBC-256 for its transport algorithms

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.

Section 8.2.8 correctly lists hmac-sha1 and hmac-sha2-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 TSS in section 8.2.8 indicates that key exchange method used by the TOE is a configurable option, and

thus not hard-coded. The allowed key exchange methods are diffie-hellman-group14-sha1, ecdh-sha2-

nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521.

1/15/2015 CC TEST LAB #200423-0

Page - 3 -

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.

Section 8.3 of the TSS 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”.

Refer to FIA_UAU_EXT.2

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.

Section 8.4.2 of the TSS states that the administrative users can be authenticated either by username and

password, or by username and SSH public key if authenticating remotely using SSH. Users are not allowed

to perform any functions on the TOE without first being successfully identified and authenticated by the

TOE’s authentication mechanism. At initial login, locally or through SSH, the administrative user is

prompted to provide a username. After the user provides the username, the user is prompted to provide

either the administrative password or the users SSH key that is associated with the username, depending on

the method of authentication the TOE is configured to use.

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_UIA_EXT.1

since other than accepting the banner no other actions are allowed prior to administrator log-in via the local

or SSH interfaces. No actions can be accomplished until the user is successfully authenticated and can only

act within the scope of their assigned privileges. Section 8.5.1 in the TSS defines each administrative role

that can be assigned to users. These roles limit the user ability to perform management functions on the

TOE.

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.

Section 8.6.2 of the TSS 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 (Admin or

Super). Key data that is resident in volatile memory cannot be accessed by an administrative command.

Any persistent key data is stored in the underlying filesystem of the OS on internal flash memory. This

section also states that the management interface of the TOE does not provide any access to the file systems

that store persistent keys.

1/15/2015 CC TEST LAB #200423-0

Page - 4 -

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.

Section 8.6.1 of the TSS states that passwords are not stored in plaintext. Passwords are hashed using SHA-

512 and this hash is what 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 TSS in section 8.6.3 indicates that the TOE can use the system hardware clock or optionally can

synchronize with one or more NTP servers. The administrator has the ability to set the time manually. It

also states that the TOE uses the time for audit timestamps as well as to determine whether an

administrative session has gone in-active.

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 TSS states in section 8.6.5 that an authorized administrator has the ability to perform TOE updates

using an SFTP client that retrieves software updates from an SFTP server. This section also discusses how

updates are obtained and that they are verified using a digital signature verification process. If the

verification fails, the process is halted and the downloaded update is removed from its 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.

Section 8.6.4 of the TSS lists all of the self-tests performed by the TOE. These self-tests are sufficient to

ensure proper operation of the TSF because it tests all cryptographic functions, software integrity, and

hardware integrity. The TSS states that in the event that a self-test fails, the TOE will automatically reboot.

If the TSF has been corrupted or the hardware has failed such that rebooting will not resolve the issue, an

administrator (Admin or Super) will need to factory reset the TOE and/or replace the failed hardware

component.

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 evaluator shall check the TSS to ensure that it details each method of access (local and

remote) available to the administrator (e.g., serial port, SSH, HTTPS).

Section 8.7.4 of the TSS states that an administrator with the Super level privilege has the ability to

configure a login banner. This banner will be displayed prior to the authentication of a user during a local

and remote session.

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.

1/15/2015 CC TEST LAB #200423-0

Page - 5 -

Section 8.8.1 of the TSS states that the trusted channel to the audit server and the update server uses SFTP

secured by SSH using OpenSSH 6.6P1, which is consistent with the protocol claims made by the ST. This

section also states that protocols that are not claimed in this evaluation are limited by enabling the “FIPS-

compliant mode of operation” during the initial configuration of the TOE.

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.

Section 8.8.2 of the TSS states that all remote administration is performed via the SSH 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 Carrier

Ethernet Solutions 3900/5100 Series which runs the Ciena Service Aware Operating System (SAOS) 6.14

which is an extension of the Linux kernel version 3.10.

3 Operational Guidance Assurance Activities The evaluation team completed the testing of the Operational Guidance, which includes the review of the

Ciena Carrier Ethernet Solutions 3900/5100 Series Supplemental Administrative Guidance v1.0 (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 CES 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] 39XX/51XX SAOS 6.14 Product Fundamentals - 009-3257-006

[2] 39XX/51XX SAOS 6.14 Administration and Security - 009-3257-007

[3] 39XX/51XX SAOS 6.14 Configuration - 009-3257-008

[4] 39XX/51XX SAOS 6.14 Command Reference - 009-3257-010

[5] 5142 Hardware Installation and Start-up Manuals – 009-3206-001*

*names vary based on individual hardware models, reference [1] for the full list. 5100 series

model’s documentation provided as example.

[6] 39XX/51XX SAOS 6.14 System Event Reference - 009-3257-024

[7] 39XX/51XX SAOS 6.14 Advanced Ethernet Configuration - 009-3257-040

[8] 39XX/51XX SAOS 6.14 Fault and Performance Management - 009-3257-009

1/15/2015 CC TEST LAB #200423-0

Page - 6 -

[9] 39XX/51XX SAOS 6.14 Advanced OAM Configuration - 009-3257-044

[10] 39XX/51XX SAOS 6.14 Software Management and Licensing - 009-3257-018

[11] 39XX/51XX SAOS 6.x Planning, Engineering, and Ordering Guide - 009-3299-029

[12] Ciena Carrier Ethernet Solutions 3900/5100 Series Security Target v1.0

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 1.”

Section 8 of the AGD lists the security-relevant auditable events for the TOE 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. Additionally, a comprehensive list of the ‘system events’ that are

considered to be auditable events for the CES product is provided in [6]. Document [8] provides a general

overview of the log format under ‘Event logging configuration’.

“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 CES 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 Carrier Ethernet Solutions 3900/5100 Series 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).”

In the evaluated configuration, local audit data can be stored in the flash or ram. Configuration for local

storage is described in section 6.1 of the Supplemental Administrative Guidance (AGD). The steps in the

Supplemental Administrative Guidance (AGD) section 6.3 indicate how to enable a remote audit server and

securely transfer audit data to it using SSH. Command log data is stored in the /flash1/log/CmdLog.[0-4]. It

can be transmitted to the remote audit server using SSH via the ‘system xftp putfile’ command.

“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 procedures for establishing a trusted channel to the audit server are described in section 6 of the

Supplemental Administrative Guidance (AGD) document.

1/15/2015 CC TEST LAB #200423-0

Page - 7 -

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).”

Section 6.6 of the Supplemental Administrative Guidance (AGD) provides instructions for how to

configure the TOE to implement SSH in a manner that is consistent with the Security Target.

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

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.”

Password management is described in section 7.4 of the Supplemental Administrative Guidance (AGD).

This section provides the guidance necessary to set the minimum password length by using the command

‘user password-policy set min-length <value>’. Additionally, section 7.4 provides the following

recommendations regarding creating a strong password, passwords should include 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”.

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. For each supported the login method, the evaluator shall ensure the operational guidance

provides clear instructions for successfully logging on.”

Creating usernames and passwords is described in section 7.3 of the AGD. The passwords are collected and

hashed after the command is entered to create the user. This prevents the password from being shown in the

command log. SSH server configuration is described in section 6.2 of the AGD. This section shows the

commands necessary to generate the SSH server key for remote administration. Authenticating to the TOE

for both password-based and public key-based authentication is described in section 7.1 of the AGD. This

section discusses how administrators can authenticate to the TOE using username and password as well as

username and SSH key. It also details the steps necessary to generate the key pair and where to store the

new key within the TOE.

“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.”

Section 7.5 of the AGD provides instructions on how to configure the pre-authentication login banner.

There is no other method by which a user or administrator can view or interact with TSF data prior to

authentication.

1/15/2015 CC TEST LAB #200423-0

Page - 8 -

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 AGD was developed for the purpose of describing the TOE’s functions related to the requirements of

the PP. This has been stated in Section 2 of the AGD: “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.” Section 9 of the AGD provides a pointer to

the AGD section that satisfies the PP’s SFRs. The TOE has a fixed set of administrative roles with a fixed

set of privileges. Each AGD section describes the role(s) needed to perform a function. For further

information on these roles, Document [4] provides a listing of administrative commands and the minimum

level of privilege required to execute each of them.

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.”

Configuration of the TOE can occur locally via the serial console or remotely over the dedicated

management Ethernet port (if available) or data plane interface via in-band management. Section 6.7 of the

AGD provides instructions on how to set up in-band management. Section 6.2 of the AGD provides

instructions on how to set up the SSH server for remote administration. Section 7.1 of the AGD provides

instructions for 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.”

Section 7.7 of the AGD provides instructions on how to set the time manually and configure the TOE to

connect to an NTP server. Procedure 4-2 of [2] provides more detailed instructions on how to manually set

the system date and time. It also gives a brief description of each field within the command. Procedures 3-

17 through 3-22 of [2] provide instructions on how to set up and administer NTP.

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.5 of the AGD references procedures for enabling FIPS mode, which also enables the use of self-

tests by the TOE. In the event that a self-test fails, the TOE will automatically reboot. If the TSF has been

corrupted or the hardware has failed such that rebooting will not resolve the issue, an administrator will

need to factory reset the TOE and/or replace the failed hardware component. Section 10 notes the

operational modes of the TOE and gives further details for how the TOE handles self-test failures. Section

11 of the AGD provides contact information of the vendor for additional technical support.

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.”

1/15/2015 CC TEST LAB #200423-0

Page - 9 -

Sections 6.4 and 6.6 of the AGD describe the pre-conditions that must be met in order for the TOE to

receive trusted updates over a secure connection. Section 7.8 of AGD summarizes the method by which

software upgrades are applied and verified. The ‘software upgrade’ command in [4] describes the syntax

for performing a system upgrade. The general instructions for acquiring, verifying, and performing trusted

updates are described in detail in [10]. Section 7.8 of the AGD also describes the TOE’s validation of the

digital signature and that the update is aborted when the validation fails.

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.6 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 7.5 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.”

Sections 6.2, 6.3, 6.4 and 6.6 of the AGD provide instructions for configuring the SSH server, SFTP client,

SFTP server, and SSH algorithms for trusted communications to connect to transfer audit data remotely and

retrieve software updates. Sections 6.3 and 6.4 also indicate that if a connection is broken during a log

transfer or while downloading a software update that the TOE will automatically continue the operation

once the connection is re-established.

FTP_TRP.1 – “The evaluator shall confirm that the operational guidance contains instructions for establishing the

remote administrative sessions for each supported method.”

Sections 6.2 and 6.6 of the AGD provide instructions for configuring the SSH server and SSH algorithms

for trusted communications for remote administrative sessions.

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.”

The AGD lists all of the protocols that can be configured to run on the TOE in the evaluated configuration

(SSH Server (Section 6.2), SFTP Client (Section 6.3), SFTP Server (Section 6.4), enabling FIPS mode

(Section 6.5), and the algorithms for both the SSH Server and Client in Section 6.6). In addition [4] lists all

of the commands that can be run. 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.

“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.”

1/15/2015 CC TEST LAB #200423-0

Page - 10 -

Section 6.5 of the AGD specifies that the TOE shall be placed into FIPS mode to ensure the correct set of

validated algorithms are used. Section 6.6 describes that the CES product supports other cryptographic

algorithms but the only algorithms that were tested are listed. Other algorithms were not tested or

evaluated. Section 6.6 also gives instructions on how to disable the non-compliant algorithms for both the

SSH Server and Client.

“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.”

The AGD in section 6.4 specifies the method of setting up the SFTP server to perform a software update.

Section 7.8 of the AGD discusses the process in which the administrator with the Admin or Super privilege

can update the device in a secure manner. Document [10] provides detailed steps on installing and

activating software.

“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 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 CES 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 Carrier Ethernet Solutions 3900/5100 Series Security Target was not evaluated and should be

exercised at the user’s risk.”

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.”

The installation and configuration of the TOE is discussed in sections 5 and 6 of the AGD. Within the

AGD, Table 5-1 specifies the models described in the ST.

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). The evaluation team conducted all testing activities of Ciena Carrier Ethernet

Solutions at Ciena’s facility in Hanover, MD between November and December 2015.

1/15/2015 CC TEST LAB #200423-0

Page - 11 -

4.1 Platforms Tested and Composition

The evaluation team set up a test environment for the independent functional testing that allowed them to

perform the full suite of test assurance activities on the following three models 3904, 3931-910 and 5142.

This ensured that the firmware images were tested on each processor type (ARM and Cavium) to ensure the

same results were produced. In addition the full suite of test assurance activities was divided up, in a non-

overlapping manner, across four models to perform sample testing on the 3905, 5142, 5150 and 5160. In

addition the different interface types and interface speeds were sampled to ensure the same results were

produced.

Because the models and interfaces on which the full set of testing was executed fully covers both binary

images of the TOE and all security-relevant external interfaces, this testing is sufficient to demonstrate

identical results were produced. However, in order to more thoroughly support this argument, sampled

testing on the remaining models was used to confirm the accuracy of this assertion.

4.2 Omission Justification

Through the review of the models, the evaluation team determined that each of the product models are

identical in every aspect except for the power supplies provided on each model, data plane interfaces,

presence/absence of an out-of-band management interface, and underlying processor family. The supported

power supplies are not relevant to the ability of the product to correctly implement its claimed security

functionality. Therefore, these variations are not considered to be ‘different’ for the purpose of determining

the models to be tested. Because not all models provide an out-of-band management interface, both in-band

and out-of-band management was tested in full. Additionally, since the physical capabilities of the in-band

management interface vary between models, testing is designed to encompass each type of interface that

supports in-band management.

The evaluation team’s test environment includes each of the claimed product models. However, due to the

fact that the only differences between the models that have potential security relevance are the specific

interfaces used to manage the TSF and the binary image that is tailored to the underlying hardware

architecture, it is not considered to be necessary to execute the full set of tests on each model. The

evaluation team therefore has devised the following testing permutations:

Perform the entire functional test suite on the 3904 device (Dernhelm image)

o Local interface: serial port

o Remote interface: in-band management, 100M/1G SFP

Perform the entire functional test suite on the 3931-910 device (Caliondo image)


o Remote interface: in-band management, 10/100/1000M RJ-45

Perform the entire functional test suite on the 5142 device (Caliondo image)


o Remote interface: out-of-band management

On the following devices, perform a sampling of the functional test suite such that each functional

class is tested on at least one other device and each device has testing from at least one functional

class performed on it:

o 3095

100M/1G SFP

o 3932

1G/10G SFP+

o CN 5150

XFP

o 5160

1G/10G SFP+

1/15/2015 CC TEST LAB #200423-0

Page - 12 -

This sample ensures that both software images and each physical and logical method of remote

administration are tested.

For those devices where the entire test suite will be executed, both local and remote administration will be

used in order to demonstrate equivalent functionality between the two. In all cases, the external entities

used to support the management functions (audit server, update server, NTP server) will be connected to

the TOE using the same interface that is selected for remote management.

For in-band management, the data plane port used to handle management traffic will be configured such

that traffic bound for the management plane is tagged by either the computer running the SSH client or by a

local area network (LAN) switch that is connected to the TOE.

Because the models and interfaces on which the full set of testing was executed fully covers both binary

images of the TOE and all security-relevant external interfaces, this testing is sufficient to demonstrate

equivalent functionality. However, in order to more thoroughly support this argument, sampled testing on

the remaining models was used to confirm the accuracy of this assertion.

The testing performed has a sufficient level of overlap between the tested models and interfaces to validate

that the TOE performs the same regardless of the specific model.

4.3 Assessment of the Ciena Test Environment

The purpose of this section is to ensure that Ciena’s test environment and Booz Allen’s use of this

environment during testing conforms with the expectations of NVLAP Handbooks 150 and 150-20, and

Labgram #078/Valgram #098.

4.3.1 Physical Assessment

Ciena Headquarters located in Hanover, MD is the physical location for the Ciena Ethernet Solutions

(CES) test environment. Booz Allen reviewed the physical security controls of the test environment and

interviewed Ciena employees to ensure that the Ciena Ethernet Solutions 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 laboratory where the CES devices are

installed is a secured internal room located at the Ciena Headquarters location. Thus, physical access to the

CES 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 CES 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.

1/15/2015 CC TEST LAB #200423-0

Page - 13 -

4.4 Test Cases

The evaluation team completed the functional testing activities onsite at the vendor’s facility. 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 evaluator shall test the TOE’s ability to correctly generate audit records by

having the TOE generate audit records for the events listed in table 1 and

administrative actions. This should include all instances of an event--for instance, if

there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1

events must be generated for each mechanism. The evaluator shall test that audit

records are generated for the establishment and termination of a channel for each of

the cryptographic protocols contained in the ST. If HTTPS is implemented, the test

demonstrating the establishment and termination of a TLS session can be combined

with the test for an HTTPS session. For administrative actions, the evaluator shall

test that each action determined by the evaluator above to be security relevant in the

context of this PP is auditable. When verifying the test results, the evaluator shall

ensure the audit records generated during testing match the format specified in the

administrative guide, and that the fields in each audit record have the proper entries.

Note that the testing here can be accomplished in conjunction with the testing of the

security mechanisms directly. For example, testing performed to ensure that the

administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied

and should address the invocation of the administrative actions that are needed to

verify the audit records are generated as expected.

Test Instructions Execute this test per the test steps.

Test Steps 1. Turn on the audit functionality on the TOE. Audit records are located in

the security log and event logs. The audit records are located in the

security log by default.

2. Perform actions related to the SFRs listed in Table 6-2 – Auditable Events

from the Security Target such that an audit record is generated for that

particular action. Repeat events until finished

1/15/2015 CC TEST LAB #200423-0

Page - 14 -

3. To view the security log run the following command:

System security log show

4. Perform actions related to the SFRs listed in Table 6-2 – Auditable Events

from the Security Target such that an audit record is generated for that

particular action. Repeat events until finished.

5. Verify each event is audited after each test

6. Log flash view [tail, keyword]

7. Save a copy of each audit record generated for each event.

8. Log flash disable will perform a global disabling of logging to flash

Test Results Pass

Execution Method Manual


SFR FAU_STG_EXT.1

Test Objective The evaluator shall establish a session between the TOE and the audit server

according to the configuration guidance provided. The evaluator shall then examine

the traffic that passes between the audit server and the TOE during several activities

of the evaluator’s choice designed to generate audit data to be transferred to the

audit server. The evaluator shall observe that these data are not able to be viewed in

the clear during this transfer, and that they are successfully received by the audit

server. The evaluator shall record the particular software (name, version) used on

the audit server during testing.


Test Steps 1. Start Wireshark packet capture between the TOE and an sftp server

2. system security log transfer set sftp-server <ip address> login-id ocadmin

echoless-password

3. system security log transfer set dest-path <path>

4. system security log transfer show

5. Perform some auditable events

6. Transfer the audit data now:

System sec log transfer now

7. Stop and save the packet capture

8. Take a screenshot of the encrypted packets

9. Verify the audit data has been received on the sftp server. Take a

screenshot showing the data has been received.

10. Save a copy of the audit records

Test Results Pass


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.


SFR FCS_SSH_EXT.1.1

Test Objective The evaluator shall, for each public key algorithm supported, show that the TOE

1/15/2015 CC TEST LAB #200423-0

Page - 15 -

supports the use of that public key algorithm to authenticate a user connection. Any

configuration activities required to support this test shall be performed according to

instructions in the operational guidance.


Test Steps 1. On the client running Bitvise generate a new client key pair.

2. Export the public key into a file called <user>.pk2

3. Place this file in the sftp server under the root directory

4. On the TOE run the command to transfer and install the key for <user>

ssh server key install user <user> sftp-server <ip address> login-id <sftp

user> echoless-password <cr>

5. Enter the password for the sftp user

6. Start a packet capture of the connection between the client and the TOE

using Wireshark

7. On the client machine run Bitvise and connect to the TOE using the RSA

algorithm for authentication.


9. Take a screenshot of the Bitvise authentication parameters

10. Take a screenshot of the CLI connection showing the successful

connection to the TOE.

11. Take a screenshot of the packet capture showing the algorithm negotiation

includes RSA

Test Results Pass



SFR FCS_SSH_EXT.1.2

Test Objective Using the operational guidance, the evaluator shall configure the TOE to accept

password-based authentication, and demonstrate that a user can be successfully

authenticated to the TOE over SSH using a password as an authenticator.


Test Steps 1. On the client machine run Bitvise and connect to the TOE using password

based authentication.

2. Take a screenshot of the Bitvise authentication parameters

3. Take a screenshot of the CLI showing the successful connection to the

TOE

4. Save a copy of the audit record for the successful login using SSH

Test Results Pass



SFR FCS_SSH_EXT.1.3

Test Objective The evaluator shall demonstrate that if the TOE receives a packet larger than that

specified in this component, that packet is dropped.


Test Steps 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.

1/15/2015 CC TEST LAB #200423-0

Page - 16 -

Test Results Pass



SFR FCS_SSH_EXT.1.4

Test Objective The evaluator shall establish a SSH connection using each of the encryption

algorithms specified by the requirement. It is sufficient to observe (on the wire) the

successful negotiation of the algorithm to satisfy the intent of the test.


Test Steps 1. Start a packet capture of the connection between the client and the TOE

using Wireshark

2. Run Bitvise and connect to the TOE using AES-CBC-128 as the

encryption algorithm

3. Run Show command to send packets between the TOE and the client


5. Find the algorithm exchange packet and take a screenshot showing the

successful negotiation using AES-CBC-128.

6. Save the audit record of the successful connection.

7. Repeat steps 1-6 using AES-CBC-256 the connection will be successful

8. Repeat steps 1, 2, 4 using 3DES-CBC. This time the connection will be

unsuccessful. Take a screen shot showing the unsuccessful negotiation and

save the packet capture.

9. Save the audit record showing the unsuccessful login attempt

Test Results Pass



SFR FCS_SSH_EXT.1.6

Test Objective The evaluator shall establish a SSH connection using each of the integrity

algorithms specified by the requirement. It is sufficient to observe (on the wire) the

successful negotiation of the algorithm to satisfy the intent of the test.


Test Steps 1. Start a packet capture of the connection between the client and the TOE

using Wireshark

2. Run Bitvise and connect to the TOE using hmac-sha1 as the integrity

algorithm

3. Run Show command to send packets between the TOE and the Client.


5. Find the algorithm exchange packet and take a screen shot showing the

successful negotiation using hmac-sha-1

6. Save the audit record corresponding to the successful log

7. Repeat steps 1-6 using hmac-sha2-256 will be successful

Test Results Pass



SFR FCS_SSH_EXT.1.7

Test Objective The evaluator shall attempt to perform a diffie-hellman-group1-sha1 key exchange,

and observe that the attempt fails. For each allowed key exchange method, the

evaluator shall then attempt to perform a key exchange using that method, and

observe that the attempt succeeds.

1/15/2015 CC TEST LAB #200423-0

Page - 17 -


Test Steps 1. Start the Wireshark packet capture between the client and the TOE.

2. Run Bitvise and connect to the TOE using diffie-hellman-group1-sha1


4. This test will be unsuccessful.

5. Take a screenshot of the Bitvise configuration screen.

6. Take a screenshot of the failed negotiation packet

7. Save the audit record corresponding to the unsuccessful attempt

8. Start the Wireshark packet capture between the client and the TOE.

9. Run Bitvise and connect to the TOE using diffie-hellman-group14-sha1

10. Run the Show command to send packets between the TOE and the client

11. Stop and save the packet capture.

12. Take a screenshot of the Bitvise configuration

13. Take a screenshot of the successful algorithm exchange packet

14. Save the audit record corresponding to the successful login

15. Repeat steps 8-14 using ecdh-sha2-nistp256 will be successful

16. Repeat steps 8-14 using ecdh-sha2-nistp384 will be successful

17. Repeat steps 8-14 using ecdh-sha2-nistp521 will be successful Test Results Pass


4.4.3 User Data Protection

There are no ATE Assurance Activities for any SFRs in this class.

4.4.4 Identification and Authentication


SFR FIA_PMG_EXT.1

Test Objective The evaluator shall compose passwords that either meet the requirements, or fail to

meet the requirements, in some way. For each password, the evaluator shall verify

that the TOE supports the password. While the evaluator is not required (nor is it

feasible) to test all possible compositions of passwords, the evaluator shall ensure

that all characters, rule characteristics, and a minimum length listed in the

requirement are supported, and justify the subset of those characters chosen for

testing.


Test Steps 1. Set the password policy

2. User password-policy set min-length 15

3. Create a user with the required password

4. User create user user1 access-level admin echoless-password

5. Enter Password: abcdefghijklmnopqrstuvwxyzA12!

6. Verify Password: abcdefghijklmnopqrstuvwxyzA12!

7. Login with the user and password abcdefghijklmnopqrstuvwxyzA12!

8. Confirm the user password is accepted

9. Repeat steps 3-8 with user2 and password

BCDEFGHIJKLMNOPQRSTUVWXYZa345@

10. Repeat steps 3-8 with user 3 and password aA67890#$%^&*()

11. Repeat steps 3-8 with user4 and password abcdefghijklA1!

12. Repeat steps 3-8 with user5 and password bcdefghijklA1!

13. This time the password is rejected

1/15/2015 CC TEST LAB #200423-0

Page - 18 -

14. Take screen shots of the configuration and login attempts

Test Results Pass



SFR FIA_UAU.7

Test Objective The evaluator shall locally authenticate to the TOE. While making this attempt, the

evaluator shall verify that at most obscured feedback is provided while entering the

authentication information.


Test Steps 1. Login to the TOE over the local console connection via the serial port

2. Ensure the password is obscured (Not shown on the terminal)

Test Results Pass



SFR FIA_UIA_EXT.1

Test Objective The evaluator shall use the operational guidance to configure the appropriate

credential supported for the login method. For that credential/login method, the

evaluator shall show that providing correct I&A information results in the ability to

access the system, while providing incorrect information results in denial of access.


Test Steps 1. LOCAL CONSOLE via SERIAL

2. If needed create a user using the following command

3. User create user test1 access-level admin echoless-password

4. Enter Password:

5. Verify Password:

6. Login in via the local console screen over the serial connection using a

valid username and password

7. Take a screenshot showing the successful login attempt

8. Exit from the local console

9. Save the audit record

10. Login in via the local console using a valid username and invalid password

11. Take a screenshot showing the unsuccessful login attempt.


13. Login in via the local console using an invalid username and invalid

password



16. Login in via the local console using an invalid username and valid

password



19. REMOTE via SSH

20. Login via the remote SSH connection using a valid username and

password



23. Exit from the CLI.

24. Login via the remote SSH connection using a valid username and invalid

1/15/2015 CC TEST LAB #200423-0

Page - 19 -

password



27. Login via the remote SSH connection using an invalid username and

invalid password



30. Login via the remote SSH connection using an invalid username and valid

password



33. Login via the remote SSH connection using an invalid username and valid

password



Test Results Pass



SFR FIA_UIA_EXT.1

Test Objective The evaluator shall configure the services allowed (if any) according to the

operational guidance, and then determine the services available to an external

remote entity. The evaluator shall determine that the list of services available is

limited to those specified in the requirement.


Test Steps 1. REMOTE via SSH

2. Login to the TOE and run the command:

system shell banner create

banner <login|welcome> line <string>

3. Exit from the TOE

4. Use bitvise to login remotely using SSH and take a screenshot to show that

the login banner is the only service that was run prior to login.

5. Save the audit record showing the banner configuration and login attempt

6. Use bitvise to login remotely using SSH with username=”show version”

and password=”show version”


Test Results Pass



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 Steps 1. If the banner is not created, create it using the command:

system shell banner create banner <login|welcome> line <string>

2. Login to the TOE via the local console and verify that only the banner

service is available.


1/15/2015 CC TEST LAB #200423-0

Page - 20 -

4. Login to the TOE via the local console using username=”show version”

and password “show version”

Test Results Pass


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


SFR FPT_STM.1

Test Objective The evaluator uses the operational guide to set the time. The evaluator shall then

use an available interface to observe that the time was set correctly.


Test Steps 1. Disable NTP or verify that it is not configured or running.

2. Run the command system show date time

3. Run the command system set date <yy-mm-dd> time <hh:mm:ss>

4. Run the command system show date time

5. Take screen shots and save the audit records

Test Results Pass



SFR FPT_STM.1

Test Objective If the TOE supports the use of an NTP server; the evaluator shall use the

operational guidance to configure the NTP client on the TOE, and set up a

communication path with the NTP server. The evaluator will observe that the NTP

server has set the time to what is expected. If the TOE supports multiple protocols

for establishing a connection with the NTP server, the evaluator shall perform this

test using each supported protocol claimed in the operational guidance.


Test Steps 1. Set the clock on the TOE to 1 hour before the current time using the

command:

system set date <yy-mm-dd> time <hh:mm:ss>

2. Run the command:

ntp client add server <server ip address>

ntp client enable server <server ip address>

3. Allow time for the sync with the server

4. Check the current time on the TOE to ensure it has changed to the correct

time. Run the command system show date time

Test Results Pass



SFR FPT_TUD_EXT.1

Test Objective The evaluator performs the version verification activity to determine the current

version of the product. The evaluator obtains a legitimate update using procedures

described in the operational guidance and verifies that it is successfully installed on

the TOE. Then, the evaluator performs a subset of other assurance activity tests to

demonstrate that the update functions as expected. After the update, the evaluator

1/15/2015 CC TEST LAB #200423-0

Page - 21 -

performs the version verification activity again to verify the version correctly

corresponds to that of the update.


Test Steps Test using the update server

1. Perform a version check prior to the update by running the following

command:

Software show

2. To install and activate the package after the next reboot/restart run the

following command:

software install package-path <Path to the package> sftp-server <server

ip address> login-id <username> echoless-password

3. chassis reboot

4. Note software validation always occurs on both banks 5 minutes after boot

but it can be run manually by running the software validate command

5. Note the software activate command will activate the software

Test Results Pass



SFR FPT_TUD_EXT.1

Test Objective The evaluator performs the version verification activity to determine the current

version of the product. The evaluator obtains or produces an illegitimate update,

and attempts to install it on the TOE. The evaluator verifies that the TOE either

rejects the update without intervention or detects that the update is illegitimate and

allows the administrator to reject the update (as specified in the operational

guidance).


Test Steps 1. Test using the update server

2. Perform a version check prior to attempting to install an illegitimate

update and notate the version.

3. Obtain an image and modify it using a Hex Editor

4. Put the modified image on the SFTP server

5. To install and activate the package after the next reboot/restart issue the

following command:

software install package-path <path to bad package> sftp-server <server ip

address> login-id <username> echoless-password

6. The software installation should fail to install

7. This check will verify the RSA digital signature of the image

8. Perform a version check after attempting to install an illegitimate update

and verify that the version number did not change.

Test Results Pass


4.4.7 TOE Access


SFR FTA_SSL_EXT.1

Test Objective The evaluator follows the operational guidance to configure several different values

for the inactivity time period referenced in the component. For each period

configured, the evaluator establishes a local interactive session with the TOE. The

1/15/2015 CC TEST LAB #200423-0

Page - 22 -

evaluator then observes that the session is either locked or terminated after the

configured time period. If locking was selected from the component, the evaluator

then ensures that re-authentication is needed when trying to unlock the session.


Test Steps 1. Test using the local console connection over the serial port

2. Login to the TOE using the local console port

3. Run the command:

System shell set global-inactivity-timer on

system shell set global-inactivity-timeout 3

4. Exit the TOE

5. Login to the TOE again and run the show time command

6. Wait for 3 minutes

7. Take a snapshot of the screen showing the inactivity terminated the

session to show that 3 minutes elapsed

8. Repeat steps 2-7 using 5 minutes and 7 minutes

Test Results Pass



SFR FTA_SSL.3

Test Objective The evaluator follows the operational guidance to configure several different values

for the inactivity time period referenced in the component. For each period

configured, the evaluator establishes a remote interactive session with the TOE.

The evaluator then observes that the session is terminated after the configured time

period.


Test Steps 1. REMOTE via SSH

2. Login to the TOE from the client using Bitvise and using SSH

3. Run the command:

System shell set global-inactivity-timer on

system shell set global-inactivity-timeout 3

4. Exit the TOE

5. Login to the TOE again and run the show time command

6. Wait for 3 minutes

7. Take a snapshot of the screen showing the inactivity terminated the

session to show that 3 minutes elapsed

8. Repeat steps 2-7 using 5 minutes and 7 minutes

Test Results Pass



SFR FTA_SSL.4

Test Objective The evaluator initiates an interactive local session with the TOE. The evaluator then

follows the operational guidance to exit or log off the session and observes that the

session has been terminated.


Test Steps 1. Login using the local serial port connection

2. Run the exit command

3. Take a screenshot showing the user logged off

Test Results Pass

1/15/2015 CC TEST LAB #200423-0

Page - 23 -



SFR FTA_SSL.4

Test Objective The evaluator initiates an interactive remote session with the TOE. The evaluator

then follows the operational guidance to exit or log off the session and observes that

the session has been terminated.


Test Steps 1. Login using Bitvise and SSH


3. Take a snapshot showing the user logged off

Test Results Pass



SFR FTA_TAB.1

Test Objective The evaluator follows the operational guidance to configure a notice and consent

warning message. The evaluator shall then, for each method of access specified in

the TSS, establish a session with the TOE. The evaluator shall verify that the notice

and consent warning message is displayed in each instance.


Test Steps 1. Login via the local console connection via the serial port

2. Run the command:

system shell banner create login line <”String”>


4. Login over the local console connection and verify the banner is displayed.

5. Login over the Remote SSH connection and verify the banner is displayed.

6. Take a snapshot of the screen

7. Login using Bitvise and SSH

8. Remove the banner that was created in the previous step.

System shell banner delete banner login

9. Run the command:

system shell banner create login line <”String”>


11. Run Bitvise to login using SSH and verify the banner is displayed.

12. Login to the Local Console and verify the banner is displayed.

13. Take a snapshot of the screen

Test Results Pass


4.4.8 Trusted Path/Channels


SFR FTP_ITC.1

Test Objective The evaluators shall 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 Steps Test SFTP between the TOE and the SFTP Update Server

1/15/2015 CC TEST LAB #200423-0

Page - 24 -

1. Start Wireshark packet capture between the TOE and the SFTP Update

Server

2. To install the package but not activate it, run the following command:

software install package-path <path to package> sftp-server <server ip

address> defer-activation login-id <username> echoless-password

3. Run the following command to show that the update has been pulled from

the server and stored in the update bank:

Software show

4. Stop the Wireshark packet capture

NOTE: The SFTP server is used for the storage of audit records as well as the

update server. Testing the secure communications while transferring audit records

was completed while testing FAU_STG_EXT.1 (TEST002).

Test Results Pass



SFR FTP_ITC.1

Test Objective 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 Steps This requirement is satisfied by the testing of FAU_STG_EXT.1 and

FPT_TUD_EXT.1.

Test Results Pass



SFR FTP_ITC.1

Test Objective The evaluator shall ensure, for each communication channel with an authorized IT

entity, the channel data are not sent in plaintext.


Test Steps This requirement is satisfied by the testing of FAU_STG_EXT.1 (Test002) and

FTP_ITC.1 (Test 025)

Test Results Pass



SFR FTP_ITC.1

Test Objective 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 Steps 1. Test SFTP between the TOE and the audit server

2. Start Wireshark packet capture between the TOE and an sftp server

3. If the TOE is not configured to send logs to the SFTP server run the

command:

System security log transfer set sftp-server <server> login-id <user>

password <password>

4. Perform some auditable events

5. Transfer the logs to the SFTP server using:

1/15/2015 CC TEST LAB #200423-0

Page - 25 -

System sec log transfer now

6. While the transfer is taking place, physically disconnect the connection

and reconnect it.


8. Take a screenshot of the encrypted packets. Verify there are no packets in

plaintext and the communications is protected.

9. Verify the audit data has been received on the sftp server. Take a

screenshot showing the data has been received.

10. Save a copy of the audit records

Test SFTP between the TOE and the SFTP Update Server

11. Start Wireshark packet capture between the TOE and the SFTP Update

Server

12. To install the package but not activate it, run the following command:

software install package-path <path to package> sftp-server <server ip

address> defer-activation login-id <username> echoless-password

13. While the transfer is taking place, physically disconnect the connection

and reconnect it.

Test Results Pass



SFR FTP_TRP.1

Test Objective 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 Steps 1. TOE --- SSH client connection using Bitvise.

2. (This is tested during FCS_SSH SFRs)

Test Results Pass



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 Steps 1. TOE --- SSH client only via the applicable interface and no other.

2. Try SSH connections using other ports and interfaces.

Test Results Pass



SFR FTP_TRP.1

Test Objective The evaluator shall ensure, for each method of remote administration, the channel

data are not sent in plaintext.


1/15/2015 CC TEST LAB #200423-0

Page - 26 -

Test Steps 1. TOE --- SSH client

2. Start Wireshark packet capture between the TOE and the SSH client

3. Connect to the TOE using SSH in Bitvise using the CC acceptable

algorithms

4. Run the Show command

5. Stop the packet capture

6. Search for the encrypted SSH packets between the client and the TOE in the

Wireshark capture.

7. Take a screenshot to show they are encrypted

8. Save the packet capture

Test Results Pass


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.

CLI Privilege Escalation

This attack involves enumerating a valid username with access to a non SAOS-CLI shell, then

cracking the user’s password and logging in.

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

API Application Programming Interface

1/15/2015 CC TEST LAB #200423-0

Page - 27 -

ASCII American Standard Code for Information Interchange

CAVP Cryptographic Algorithm Validation Program

CBC Cipher Block Chaining

CES Carrier Ethernet Solutions

CLI Command Line Interface

CSP Critical Security Parameter

DHE Diffie-Hellman

DRBG Deterministic Random Bit Generator

HMAC Hashed Message Authentication Code

KAS Key Agreement Scheme

MAC Media Access Control

NDPP Network Device Protection Profile

POST Power On Self-Test

NTP Network Time Protocol

QoS Quality of Service

RSA Rivest Shamir Adelman (encryption algorithm)

SAOS Service Aware Operating System

SFTP Secure File Transfer Protocol

SHA Secure Hash Algorithm

SHS Secure Hash Standard

SSH Secure Shell

Table 6-1: Acronyms

Terminology Definition

Super User The Super User can read and make configuration changes including

changes to users. This user corresponds to the Authorized Administrator

role of the NDPP.

Admin User Can read and make configuration changes

Limited User Read only user

Table 6-2: Terminology

ciena carrier ethernet solutions 3900/5100 series · pdf fileassurance activities report for a...

Documents