Ciena 5400 Series Packet Optical Platform - niap-ccevs.org · PDF file1 of 35 Assurance...

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_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


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 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):


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


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

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


3. Initiate a connection to the TOE via SSH and authenticate via the CLI

interface.


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



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



SFR FCS_SSH_EXT.1

Test Objective Verify that the TOE rejects excessively large SSH packets.


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



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.




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.


5. Examine the packets to verify that AES-CBC-128 was used as the


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):


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 -




5. Examine the packets to verify that AES-CBC-128 was used as the



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



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



5. Examine the packets to verify that the hmac-sha1 integrity algorithm was

used.


7. Repeat Steps 1-6 except replace “hmac-sha1” with “hmac-sha2-256.”

Test Results Pass



SFR FCS_SSH_EXT.1

Test Objective Verify that the TOE only allows diffie-hellman-group14-sha1 for the SSH key

exchange protocol.


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.



5. Examine the packets to verify that the diffie-hellman-group14-sha1 key

exchange method was used.


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



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 Steps 1. Configure the remote syslog server to only use the

“TLS_RSA_WITH_AES_128_CBC_SHA” ciphersuite.


3. Perform operations on the TOE that cause syslog data to be transmitted to

the remote syslog server.


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


“TLS_RSA_WITH_AES_256_CBC_SHA” with

“TLS_RSA_WITH_AES_128_CBC_SHA256”.


“TLS_RSA_WITH_AES_128_CBC_SHA256” with

“TLS_RSA_WITH_AES_256_CBC_SHA256”.


“TLS_RSA_WITH_AES_256_CBC_SHA256” with

“DHE_TLS_RSA_WITH_AES_128_SHA256”.

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



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.


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


canc-user::administrator:abc;




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:




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







ent-user-secu::bahuser:abc:: 56789!%^()+-!!a,TL1,AA;





23. Validate that the TOE successfully authenticated.


ent-user-secu::bahuser:abc::bcdef123[]`~{}|_:TL1,AA;







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



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



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



7. Authenticate to the TOE via the local console using an invalid username

and an invalid password.



Remote SSH (MCLI) (password based):

1. Authenticate to the TOE via SSH using a valid username and password.



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.



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 -



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!;




via TL1 using the following command an invalid username and valid

password:

act-user::baduser:abc::admin1!;




via TL1 using a valid username and an invalid password.

act-user::administrator:abc::badpwd!;




via TL1 using an invalid username and an invalid password.

act-user::baduser2:abc::badpwd2!;



Remote SSH (MCLI) (public/private key based):

1. Authenticate to the TOE via SSH using a valid username and valid private

key.



3. Authenticate to the TOE via SSH using an invalid username and a valid

private key.



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 -



7. Authenticate to the TOE via SSH using an invalid username and an invalid

private key.



Test Results Pass



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.



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



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


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 purpose of this test is to ensure that the time is able to be correctly set on 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



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.



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



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.



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.


9. Option 7 – Transfer software release from the file server.

10. After the transfer is finished, choose Option 8 – Return to previous menu.


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



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.



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


4.4.7 TOE Access


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


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



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.



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:



created in Step 2.


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:



created in Step 2.


Test Results Pass



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



SFR FTA_SSL.4

Test Objective The purpose of this test is to ensure that an administrator can terminate its own

remote interactive session.

.



1. Authenticate to the TOE via SSH (via port 10220).

2. Enter the “canc-user::<username>:abc;” command to terminate the session.


SSH (MCLI):

1. Authenticate to the TOE via SSH (via port 22).

2. Enter the “10” command to terminate the session.


Test Results Pass



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


4.4.8 Trusted Path/Channels


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


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



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.




FPT_TUD_EXT.1 – Test 018.

07/22/2015 CC TEST LAB #200423-0

Page - 29 -






repository server is encrypted and initiated by the TOE.



FCS_TLS_EXT.1 – Test 009


2. Perform some action that causes the TOE to transmit audit data to the

remote syslog server.


4. Observe that communication between the TOE and the remote syslog

server is encrypted and initiated by the TOE.

Test Results Pass



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



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.



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.




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.


repository server is encrypted.



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.


5. Observe that communication between the TOE and the remote syslog

server is encrypted.

Test Results Pass



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



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



SFR FTP_TRP.1

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

data are not sent in plaintext.


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


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

Ciena 5400 Series Packet Optical Platform - niap-ccevs.org · PDF file1 of 35 Assurance...

Documents

Transcript of Ciena 5400 Series Packet Optical Platform - niap-ccevs.org · PDF file1 of 35 Assurance...