Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2017 Cisco Systems, Inc. All rights reserved.
Cisco Nexus 9000 Switches in standalone mode with
Nexus 2000 Fabric Extenders v7.0(3)
Security Target
Version 1.0
May 31, 2017
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
2
Table of Contents
1 SECURITY TARGET INTRODUCTION................................................................................8
1.1 ST and TOE Reference ...................................................................................................... 8
1.2 TOE Overview................................................................................................................... 8
TOE Product Type....................................................................................................... 9
1.2.1
Supported non-TOE Hardware/ Software/ Firmware................................................ 11
1.2.2
1.3 TOE DESCRIPTION....................................................................................................... 11
1.4 TOE Evaluated Configuration ......................................................................................... 14
1.5 Physical Scope of the TOE .............................................................................................. 15
1.6 Logical Scope of the TOE................................................................................................ 16
Security Audit............................................................................................................ 16
1.6.1
Cryptographic Support .............................................................................................. 16
1.6.2
Full Residual Information Protection ........................................................................ 17
1.6.3
Identification and authentication ............................................................................... 17
1.6.4
Information Flow Control.......................................................................................... 17
1.6.5
Security Management................................................................................................ 18
1.6.6
Protection of the TSF................................................................................................. 19
1.6.7
TOE Access ............................................................................................................... 19
1.6.8
Trusted path/Channels ............................................................................................... 19
1.6.9
1.7 Excluded Functionality.................................................................................................... 20
2 Conformance Claims...............................................................................................................21
2.1 Common Criteria Conformance Claim............................................................................ 21
2.2 Protection Profile Conformance ...................................................................................... 21
3 SECURITY PROBLEM DEFINITION ..................................................................................22
3.1 Assumptions..................................................................................................................... 22
3.2 Threats.............................................................................................................................. 22
3.3 Organizational Security Policies...................................................................................... 23
4 SECURITY OBJECTIVES .....................................................................................................24
4.1 Security Objectives for the TOE...................................................................................... 24
4.2 Security Objectives for the Environment......................................................................... 25
5 SECURITY REQUIREMENTS..............................................................................................26
5.1 Extended TOE Security Functional Components............................................................. 26
Cryptographic Support (FCS).................................................................................... 26
5.1.1
Identification and authentication (FIA) ..................................................................... 27
5.1.2
Protection of Administrator Passwords (FPT_APW_EXT)...................................... 30
5.1.3
5.2 Conventions ..................................................................................................................... 31
5.3 TOE Security Functional Requirements .......................................................................... 32
5.4 SFRs................................................................................................................................. 33
Security audit (FAU) ................................................................................................. 33
5.4.1
Cryptographic Support (FCS).................................................................................... 34
5.4.2
User data protection (FDP)........................................................................................ 35
5.4.3
Identification and authentication (FIA) ..................................................................... 37
5.4.4
Security Management (FMT) .................................................................................... 37
5.4.5
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
3
Protection of the TSF (FPT) ...................................................................................... 39
5.4.6
TOE Access (FTA).................................................................................................... 40
5.4.7
Trusted Path/Channels (FTP) .................................................................................... 40
5.4.8
5.5 TOE SFR Hierarchies and Dependencies........................................................................ 40
5.6 Extended TOE Security Functional Components Definition........................................... 42
Security Assurance Requirements Rationale............................................................. 43
5.6.1
5.7 Assurance Measures......................................................................................................... 44
6 TOE Summary Specification...................................................................................................46
6.1 TOE Security Functional Requirement Measures ........................................................... 46
6.2 TOE Bypass and interference/logical tampering Protection Measures ........................... 56
6.3 Rationale for requirements/TOE Objectives.................................................................... 57
6.4 Rationale for TOE Security Objectives ........................................................................... 57
6.5 Security objectives rationale............................................................................................ 60
Tracing of security objectives to SPD ....................................................................... 60
6.5.1
Justification of tracing ............................................................................................... 61
6.5.2
7 Annex A: Key Zeroization ......................................................................................................63
7.1 Key Zeroization ............................................................................................................... 63
8 Annex B: References...............................................................................................................64
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
4
List of Tables
TABLE 1 ACRONYMS............................................................................................................................................................................................ 5
TABLE 2 TERMINOLOGY ..................................................................................................................................................................................... 6
TABLE 3 ST AND TOE IDENTIFICATION.......................................................................................................................................................... 8
TABLE 5: HARDWARE MODELS AND SPECIFICATIONS.................................................................................................................................12
TABLE 6 FIPS REFERENCES.............................................................................................................................................................................16
TABLE 7 TOE PROVIDED CRYPTOGRAPHY ...................................................................................................................................................17
TABLE 8 EXCLUDED FUNCTIONALITY ............................................................................................................................................................20
TABLE 9 TOE ASSUMPTIONS ...........................................................................................................................................................................22
TABLE 10 THREATS..........................................................................................................................................................................................22
TABLE 11 ORGANIZATIONAL SECURITY POLICIES.......................................................................................................................................23
TABLE 12 SECURITY OBJECTIVES FOR THE TOE..........................................................................................................................................24
TABLE 13 SECURITY OBJECTIVES FOR THE ENVIRONMENT........................................................................................................................25
TABLE 14 EXTENDED TOE SECURITY FUNCTIONAL REQUIREMENTS.....................................................................................................26
TABLE 15 SECURITY FUNCTIONAL REQUIREMENTS....................................................................................................................................32
TABLE 16 AUDITABLE EVENTS.......................................................................................................................................................................33
TABLE 17 CRYPTOGRAPHIC KEY GENERATION.............................................................................................................................................34
TABLE 18 CRYPTOGRAPHIC OPERATIONS......................................................................................................................................................34
TABLE 19: TSF MANAGEMENT SFP..............................................................................................................................................................38
TABLE 20: ROLES AND OPERATIONS ON TSF DATA....................................................................................................................................38
TABLE 21: TOE SECURITY FUNCTIONAL REQUIREMENTS DEPENDENCY RATIONALE..........................................................................40
TABLE 22 EXTENDED COMPONENTS RATIONALE ........................................................................................................................................42
TABLE 23: ASSURANCE MEASURES FOR EAL2 ............................................................................................................................................44
TABLE 24 HOW TOE SFRS ARE MET ............................................................................................................................................................46
TABLE 25: SFR/OBJECTIVES MAPPINGS.......................................................................................................................................................57
TABLE 26 SFR TRACING JUSTIFICATION .......................................................................................................................................................59
TABLE 27 TRACING OF SECURITY OBJECTIVES TO SPD ...............................................................................................................................60
TABLE 28 THREAT AND OSP RATIONALE ....................................................................................................................................................62
TABLE 29: THREAT/POLICIES/TOE OBJECTIVES RATIONALE .................................................................................................................62
TABLE 30: TOE KEY ZEROIZATION................................................................................................................................................................63
TABLE 31: REFERENCES ...................................................................................................................................................................................64
List of Figures
FIGURE 1 9300 AND 9500 TYPICAL DEPLOYMENT ....................................................................................................................................10
FIGURE 3 TOE AND ENVIRONMENT...............................................................................................................................................................15
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
5
Acronyms
The following acronyms and abbreviations are common and may be used in this Security Target:
Table 1 Acronyms
Acronyms /
Abbreviations
Definition
AAA Administration, Authorization, and Accounting
ACL Access Control Lists
AES Advanced Encryption Standard
BRI Basic Rate Interface
CC Common Criteria for Information Technology Security Evaluation
CEM Common Evaluation Methodology for Information Technology Security
CM Configuration Management
CSU Channel Service Unit
DHCP Dynamic Host Configuration Protocol
EAL Evaluation Assurance Level
GE Gigabit Ethernet port
ICMP Internet Control Message Protocol
ISDN Integrated Services Digital Network
IT Information Technology
NDPP Network Device Protection Profile
OS Operating System
PP Protection Profile
SA Security Association
SFP Security Function Policy
SHS Secure Hash Standard
SSHv2 Secure Shell (version 2)
ST Security Target
TCP Transport Control Protocol
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Function
TSP TOE Security Policy
UDP User datagram protocol
VRF Virtual Routing and Forwarding
WAN Wide Area Network
WIC WAN Interface Card
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
6
Terminology
Table 2 Terminology
Term Definition
Authorized
Administrator
Any user which has been assigned to a privilege level that is permitted to perform all TSF-
related functions.
Peer switch Another switch on the network that the TOE interfaces with.
Privilege level Assigns a user specific management access to the TOE to run specific commands. For
NX-OS privilege levels in IOS can be mapped to the NX-OS user roles. The privilege
levels are from 1-15 with 15 having full administrator access to the TOE similar to root
access in UNIX or Administrator access on Windows. Privilege level 1 has the most
limited access to the CLI. By default when a user logs in to the Cisco NX-OS, they will
be in user EXEC mode (level 1). From this mode, the administrator has access to some
information about the TOE, such as the status of interfaces, and the administrator can view
routes in the routing table. However, the administrator can't make any changes or view the
running configuration file. The privilege levels are customizable so that an Authorized
Administrator can also assign certain commands to certain privilege levels.
Role An assigned role gives a user varying access to the management of the TOE. For the
purposes of this evaluation the privilege level of a user is synonymous with the assigned
privilege level.
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.
Vty vty is a term used by Cisco to describe a single terminal (whereas Terminal is more of a
verb or general action term).
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
7
DOCUMENT INTRODUCTION
Prepared By:
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
This document provides the basis for an evaluation of a specific Target of Evaluation (TOE), the
Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders (9k). The Nexus
2000 Fabric Extenders are optional. This Security Target (ST) defines a set of assumptions
about the aspects of the environment, a list of threats that the product intends to counter, a set of
security objectives, a set of security requirements, and the IT security functions provided by the
TOE which meet the set of requirements. Administrators of the TOE will be referred to as
administrators, Authorized Administrators, TOE administrators, semi-privileged, privileged
administrators, and security administrators in this document.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
8
1 SECURITY TARGET INTRODUCTION
The Security Target contains the following sections:
 Security Target Introduction [Section 1]
 Conformance Claims [Section 2]
 Security Problem Definition [Section 3]
 Security Objectives [Section 4]
 IT Security Requirements [Section 5]
 TOE Summary Specification [Section 6]
The structure and content of this ST comply with the requirements specified in the Common
Criteria (CC), Part 1, Annex A, and Part 2.
1.1 ST and TOE Reference
This section provides information needed to identify and control this ST and its TOE.
Table 3 ST and TOE Identification
Name Description
ST Title Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders
ST Version 1.0
Publication Date May 31, 2017
Vendor and ST Author Cisco Systems, Inc.
TOE Reference Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders
TOE Hardware Models 9300, 9500, 2000
TOE Software Version NX-OS version 7.0(3)I5(1)
Keywords Switch, Data Protection, Authentication
TOE Guidance Cisco Nexus 9000 Series Switch Common Criteria Configuration Guide v1.0
1.2 TOE Overview
The Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders offer
both modular (9500 switches) and fixed (9300 switches) 1,10, 40, and 100 Gigabit Ethernet (GE)
configurations designed to operate in one of two modes providing Data Center Ethernet (DCE):
 Cisco NX-OS mode for traditional architectures and consistency across the Cisco Nexus
portfolio
 ACI mode to take full advantage of the policy-focused services and infrastructure
automation features of the Cisco Application Centric Infrastructure (ACI)
In addition to the Nexus 9000 Series Switches, the solution provided by the TOE includes the
Cisco Nexus 2000 Series Fabric Extenderes, and the NX-OS software. The TOE can be
deployed with the Nexus 9k or together with the Nexus 2000 Fabric Extender.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
9
The Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders with
optional Nexus 2000 Fabric Extenders TOE are data center switches that support up to 60
terabits per second (Tbps) of nonblocking performance switching, making them highly capable
and effective in the role of data center aggregation layer switches. The TOE is comprised of the
Nexus 9000 Series Switches and Nexus 2000 Fabric Extenders (FEX) that include the 9300,
9500, 2000 models running NX-OS. The 9k switches, Nexus 2k FEX and NX-OS are
collectively referred to as TOE or individually as TOE Components. The 9300 switches are
fixed form factor and the 9500 switches are modular and are available in 8-, 32-, 36- and 48 slot
chassis. These 9500 modular chassis can be outfitted with the following types of modules:
 Supervisor modules: Supervisor modules provide scalable control plane and
management functions for the switch. The Supervisor modules control Layer 2 and 3
services, redundancy capabilities, configuration management, status monitoring, power
and environmental management, and transparent upgrades to I/O and fabric modules.
 Fabric modules: Fabric modules provide the central switching element for fully
distributed forwarding on the I/O modules. The addition of each Fabric Module increases
the bandwidth to all module slots. The Cisco Nexus 9500 platform supports up to six
fabric modules, each with up to 10 24-Tbps line-rate packet forwarding capacity. All
fabric cards are directly connected to all line cards. With load balancing across fabric
cards, the architecture achieves optimal bandwidth distribution within the chassis.
 Line Card I/O modules: The Line Card Modules are full-featured, high-performance
modules with support for high-density 10-, 40-, and 100-Gigabit Ethernet interfaces.
The Nexus 2000 Fabric Extender functions essentially as a remote line card and is optional to the
deployment of the Nexus 9000 in standalone mode in order to add additional ports.
TOE Product Type
1.2.1
The 9k TOE component is a data center-class switch for use as an aggregation switch in the data
center. They can be deployed in standalone mode using NX-OS or with the implementation of
Application Centric Infrastructure (ACI). In this Common Criteria Evaluation the TOE will be
in standalone mode using NX-OS with Nexus 2000 Fabric Connector (FEX). The Nexus 2000
FEX is an optional component.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
10
Figure 1 9300 and 9500 typical deployment
The Cisco Nexus 9500 is a modular chassis that supports up to 16 line cards, 2 supervisor
modules, 2 chassis controllers, 3 fan trays, 6 fabric modules, and 10 power supplies. The switch
supports comprehensive Layer 2 and 3 functions on nonblocking 1, 10, 40 and 100 Gigabit
Ethernet ports. The Cisco Nexus 9300 platform consists of fixed-port switches designed for top-
of-rack (ToR) and middle-of-row (MoR) deployment in data centers that support enterprise
applications, service provider hosting, and cloud computing environments. They are Layer 2 and
3 nonblocking 10 and 40 Gigabit Ethernet switches with up to 2.56 terabits per second (Tbps) of
internal bandwidth.
Cisco NX-OS is a Cisco-developed highly configurable proprietary operating system that
provides for efficient and effective routing and switching as well as network virtualization. NX-
OS is a next-generation data center class operating system designed for maximum scalability and
application availability. The NX-OS data center class operating system was built with
modularity, resiliency, and serviceability at its foundation. NX-OS is based on the industry-
proven Cisco Storage Area Network Operating System (SAN-OS) Software and helps ensure
continuous availability to set the standard for mission-critical data center environments.
Although it is a separate OS from NX-OS, it includes many of the same commands and features
of Cisco NX-OS.
NX-OS provides virtual routing and forwarding capabilities that logically segment the network
by virtualizing both the routing control plane and data plane functions into autonomous
instances. Routing protocols and interfaces, both physical and logical, become members of a
specific VRF instance via configuration. For each VRF, IPv4 and IPv6 tables are created
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
11
automatically and independent routing and forwarding decisions are made. NX-OS supports up
to 1000 unique VRF instances.
For management purposes the TOE provides command line access to administer the TOE.
Although NX-OS performs many networking functions, this TOE only addresses the functions
that provide for the security of the TOE itself as described in 1.6 Logical Scope of the TOE
below.
Supported non-TOE Hardware/ Software/ Firmware
1.2.2
The TOE supports (in some cases optionally) the following hardware, software, and firmware in
its environment when the TOE is configured in its evaluated configuration:
Table 4 IT Environment Components
Component Required Usage/Purpose Description for TOE performance
Local Console Yes This includes any IT Environment Console that is directly connected to the TOE
via the Serial Console Port and is used by the TOE administrator to support TOE
administration.
Management
Workstation with
SSH Client
Yes This includes any IT Environment Management workstation with a SSH client
installed that is used by the TOE administrator to support TOE administration
through SSH protected channels. Any SSH client that supports SSHv2 may be
used.
Syslog Server No This includes any syslog server to which the TOE would transmit syslog
messages and the encryption of the session.
RADIUS or
TACACS+ AAA
Server
No This includes any IT environment RADIUS or TACACS+ AAA server that
provides single-use authentication mechanisms. The TOE correctly leverages
the services provided by this RADIUS or TACACS+ AAA server to provide
single-use authentication to administrators.
1.3 TOE DESCRIPTION
This section provides an overview of the Cisco Nexus 9000 Switches in standalone mode with
Nexus 2000 Fabric Extenders Target of Evaluation (TOE). The TOE is comprised of both
software and hardware. The hardware is comprised of the following model series: 9300, 9500,
2000. The software is comprised of the NX-OS software image Release 7.0(3)I5(1)
The Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders that
comprise the TOE have common hardware characteristics. These characteristics affect only non-
TSF relevant functions of the switches (such as throughput and amount of storage) and therefore
support security equivalency of the switches in terms of hardware. All security functionality is
enforced on the Nexus 9000 Series switches. Table 5 below describes the models have been
claimed within this evaluation:
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
12
Table 5: Hardware Models and Specifications
Model Description Interfaces
Cisco 9300 models
9332PQ QSFP+ 40-Gigabit downlink interface ports.
Ports 1 to 12 and 15 to 26 also support 40-
Gigabit-to-4x10-Gigabit breakout cables with the
Dynamic Breakout feature.
QSFP+ 40-Gigabit uplink interface ports (6)
1.3.1.1.1 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
USB ports (2)
9372PX
1.3.1.1.2 1- and 10-Gigabit SFP+ interface ports (48)
1.3.1.1.3 QSFP+ 40-Gigabit interface ports (6)
1.3.1.1.4 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.5 USB ports (2)
9372PX-E
1.3.1.1.6 1- and 10-Gigabit BASE-T interface ports (48)
1.3.1.1.7 QSFP+ 40-Gigabit interface ports (6)
1.3.1.1.8 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.9 USB ports (2)
9372TX
1.3.1.1.10 48 1- and 10-Gigabit Ethernet Small Form-Factor
10 Plugable (SFP+) optical ports (supporting 1-
Gigabit and 10-Gigabit speeds) QSFP+ 40-
Gigabit interface ports (6)
1.3.1.1.11
1.3.1.1.12 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.13 USB ports (2)
9372TX-E
1.3.1.1.14 48 1- and 10-Gigabit BASE-T QSFP+ 40-Gigabit
interface ports (6)
1.3.1.1.15 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.16 USB ports (2)
9396PX
1.3.1.1.17 4-port 100-Gigabit Ethernet CFP2 optical ports,
or 6- or 12-port 40-Gigabit Ethernet Quad Small
Form-Factor Plugable (QSFP+) optical ports for
connections to other devices
1.3.1.1.18
1.3.1.1.19 48 1- and 10-Gigabit Ethernet Small Form-Factor
10 Plugable (SFP+) optical ports (supporting 1-
Gigabit and 10-Gigabit speeds) to switches or
Fabric Extenders (FEXs)
1.3.1.1.20 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.21 USB ports (2)
9396TX
1.3.1.1.22 4-port 100-Gigabit Ethernet CFP2 optical ports,
or 6- or 12-port 40-Gigabit Ethernet Quad Small
Form-Factor Plugable (QSFP+) optical ports for
connections to other devices
1.3.1.1.23
1.3.1.1.24 48 10GBASE-T copper ports (supporting 10
1.3.1.1.25 100-Megabit, 1-Gigabit, and 10-Gigabit speeds)
for connections to other devices
1.3.1.1.26 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.27 USB ports (2)
93120TX
1.3.1.1.28 96 10GBASE-T copper ports (supporting speeds 6
of 100 Megabits, 1 Gigabit, and 10 Gigabits) to
other devices
6 40-Gigabit Ethernet Quad Small Form-Factor 7
Plugable (QSFP+) optical ports for uplink
1.3.1.1.29 connections to aggregation switches
1.3.1.1.30 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.31 USB ports (2)
93128TX Four, six, or 12 40-Gigabit Ethernet Quad Small
Form-Factor Plugable (QSFP+) optical ports for
uplink connections to aggregation switches
1.3.1.1.32
96 10GBASE-T copper ports (supporting speeds
1.3.1.1.34 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.35 USB ports (2)
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
13
Model Description Interfaces
10
of 100 Megabits, 1 Gigabit, and 10 Gigabits) to
1.3.1.1.33 other devices
93180YC-EX Intel Core i3 processor Four 48 x 10/25-Gbps
fiber ports and 6 x 40/100-Gbps Quad Small
Form-Factor Pluggable 28 (QSFP28) ports
1.3.1.1.36 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.37 USB ports (1)
93108TC-EX Intel Core i3 processor Four 48 x 10GBASE-T
ports and 6 x 40/100-Gbps QSFP28 ports
1.3.1.1.38 I/O ports as described
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.39 USB ports (1)
1.3.1.1.40 Cisco 9500 models
9504 Chassis: up to 2 supervisor modules of the same
type, 4 I/O modules, and up to 6 fabric modules, 2
system controllers
Based on Supervisor and I/O modules
installed
1
9508 Chassis: up to 2 supervisor modules of the same
type, 8-I/O modules, up to two system controller
modules, up to six fabric modules
1.3.1.1.41 Based on Supervisor and I/O modules
installed
9516 Chassis: up to 2 supervisor modules and 16 I/O
modules, up to two system controller modules, up
to six fabric modules
1.3.1.1.42 Based on Supervisor and I/O modules
installed
Supervisor A four cores, 1.8 GHz, 16 GB of memory, and 64
GB of SSD (N9K-SUP-A)
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.43 USB ports (2)
Supervisor B six cores, 2.1 GHz, 24 GB of memory, and 256
GB of SSD (N9K-SUP-B)
Management ports: 1 RJ45 connector
Console serial port: 1 RJ45 connector
1.3.1.1.44 USB ports (2)
System
Controller
A pair of redundant system controllers offloads
chassis management functions from the supervisor
modules. The controllers are responsible for
managing power supplies and fan trays and are a
central point for the Gigabit Ethernet out-of-band
channel (EOBC) between the supervisors, fabric
modules, and line cards.
1.3.1.1.45 Not Applicable
1.3.1.1.46
1.3.1.1.47 2000 Series Fabric Extenders
Cisco Nexus
2348TQ
Cisco Nexus 2348TQ 1.3.1.1.48 Cisco Nexus 2348TQ
Cisco Nexus
2348UPQ
Cisco Nexus 2348UPQ 1.3.1.1.49 Cisco Nexus 2348UPQ
Cisco Nexus
2224TP
Cisco Nexus 2224TP 1.3.1.1.50 Cisco Nexus 2224TP
Cisco Nexus
2248TP
Cisco Nexus 2248TP 1.3.1.1.51 Cisco Nexus 2248TP
Cisco Nexus
2248TP-E
Cisco Nexus 2248TP-E 1.3.1.1.52 Cisco Nexus 2248TP-E
Cisco Nexus
2232PP
Cisco Nexus 2232PP 1.3.1.1.53 Cisco Nexus 2232PP
Cisco Nexus Cisco Nexus 2248PQ 1.3.1.1.54 Cisco Nexus 2248PQ
1
The I/O modules that are compatible with the Nexus 9500 Series are listed on the Cisco web site in the I/O data
sheets for the respective module: http://www.cisco.com/c/en/us/products/switches/nexus-9000-series-
switches/models-comparison.html. For conciseness the I/O modules are not listed explicitly in the above table.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
14
Model Description Interfaces
2248PQ
Cisco Nexus
2232TM
Cisco Nexus 2232TM 1.3.1.1.55 Cisco Nexus 2232TM
Cisco Nexus
2232TM-E
Cisco Nexus 2232TM-E 1.3.1.1.56 Cisco Nexus 2232TM-E
1.4 TOE Evaluated Configuration
The TOE consists of one or more switches as specified in section 1.5 below and includes the
Cisco NX-OS software. The TOE has two or more network interfaces and is connected to at
least one internal and one external network. The Cisco NX-OS configuration determines how
packets are handled to and from the TOE’s network interfaces. The switch configuration will
determine how traffic flows received on an interface will be handled. Typically, packet flows are
passed through the internetworking device and forwarded to their configured destination. The
following routing protocols are used on all of the TOE models:
 Open Shortest Path First (OSPF) Protocol Versions 2 (IPv4) and 3 (IPv6)
 Intermediate System-to-Intermediate System (IS-IS) Protocol for IPv4
 Border Gateway Protocol (BGP) for IPv4 and IPv6
 Enhanced Interior Gateway Routing Protocol (EIGRP) for IPv4 and IPv6
 Routing Information Protocol Version 2 (RIPv2)
 Protocol Independent Multicast (PIM)
All supported modules for the 9300, 9500, 2000 series are considered part of the TOE evaluated
configuration.
Also, if the TOE is to be remotely administered, then the management workstation must be
connected to an internal network and SSHv2 must be used to securely connect to the TOE.
Audit records are stored locally, but may be remotely backed up to a remote syslog server. If
these servers are used, they must be attached to the internal (trusted) network. The internal
(trusted) network is meant to be separated effectively from unauthorized individuals and user
traffic; one that is in a controlled environment where implementation of security policies can be
enforced.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
15
Figure 2 TOE and Environment
1.5 Physical Scope of the TOE
The TOE is a hardware and software solution that makes up the switch models as follows: Nexus
9300, 9500, 2000. The network on which they reside is considered part of the environment. The
TOE guidance documentation that is considered to be part of the TOE can be found listed in the
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders
documentation is downloadable from the web sites:
 http://www.cisco.com/c/en/us/support/switches/nexus-9000-series-switches/products-
installation-and-configuration-guides-list.html
 http://www.cisco.com/c/en/us/support/switches/nexus-2000-series-fabric-extenders/tsd-
products-support-series-home.html
The TOE is comprised of the following physical specifications as described in Table 5 in section
1.3 above.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
16
1.6 Logical Scope of the TOE
The TOE is comprised of several security features. Each of the security features identified above
consists of several security functionalities, as identified below.
1. Security Audit
2. Cryptographic Support
3. Full Residual Information Protection
4. Information Flow Control
5. Identification and Authentication
6. Security Management
7. Protection of the TSF
8. TOE Access
9. Trusted Path/Channels
These features are described in more detail in the subsections below. In addition, the TOE
implements all RFCs described within the security functional requirements as necessary to
satisfy testing/assurance measures prescribed therein.
Security Audit
1.6.1
The Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders provide
extensive auditing capabilities. The TOE can audit events related to cryptographic functionality,
identification and authentication, enforcement of information flow control policies and
administrative actions. The Cisco Nexus 9000 Switches in standalone mode with Nexus 2000
Fabric Extenders generate an audit record for each auditable event. Each security relevant audit
event has the date, timestamp, event description, and subject identity. The authorized
administrator configures auditable events, performs back-up operations, and manages audit data
storage. The TOE provides the administrator with a circular audit trail. Logs are written to
DRAM, NVRAM, and flash.
Cryptographic Support
1.6.2
The TOE provides cryptography in support of other Cisco 9k security functionality. This
cryptography has been validated for conformance to the requirements of FIPS 140-2 Level 2 (see
Table 6 for certificate references).
Table 6 FIPS References
Algorithm Supported Mode Cert. #
Nexus 9000 Series TOE Component
AES CTR, ECB, GMAC (128, 192, 256) 2710
SHA-1 Byte Oriented 2275
HMAC SHA-1 Byte Oriented 1689
RSA 1024, 2048 bits 1406
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
17
The TOE provides cryptography in support of remote administrative management via SSHv2.
The cryptographic services provided by the TOE are described in Table 7 below.
Table 7 TOE Provided Cryptography
Cryptographic Method Use within the TOE
Secure Shell Establishment Used to establish initial SSH session.
RSA/DSA Signature Services Used in SSH session establishment.
SHA-1 Used to provide SSH traffic integrity verification
AES CTR, ECB, GMAC (128, 192, 256) Used to encrypt SSH session traffic.
HMAC Used for keyed hash, integrity services in SSH session establishment.
Cryptographic algorithm used to authenticate the RADIUS message.
Cryptographic algorithm used to authenticate the PAC authentication
Full Residual Information Protection
1.6.3
The TOE ensures that all information flows from the TOE do not contain residual information
from previous traffic. Packets are padded with zeros. Residual data is never transmitted from
the TOE.
Identification and authentication
1.6.4
The TOE performs user authentication for the Authorized Administrator of the TOE. The TOE
provides authentication services for administrative users to connect to the TOE's secure
administrator interfaces. The TOE requires Authorized Administrators to authenticate prior to
being granted access to any of the management functionality. The TOE can be configured to
require a minimum password length as well as mandatory password complexity rules. The TOE
provides administrator authentication against a local user database. Password-based
authentication can be performed on the local serial port referred to as the management port on
the Nexus switches. In addition, password-based authentication can be performed when
connecting to the TOE CLIs remotely using SSHv2. The SSHv2 interface also supports
authentication using SSH keys. The TOE supports use of a RADIUS or TACACS+ AAA server
(part of the IT Environment) to facilitate authentication (including single-use authentication, or
password-based authentication) and authorization (roles) for administrative users attempting to
connect to the TOE’s CLI. When the role is defined via the CLI on the TOE it is sent to the
RADIUS server using Vendor Specific Attributes (VSA).
Information Flow Control
1.6.5
The TOE provides the ability to control traffic flow into or out of the Nexus 9000 switch. The
following types of traffic flow are controlled for both IPv4 and IPv6 traffic:
 Layer 3 Traffic – RACLs
 Layer 2 Traffic – PACLs
 VLAN Traffic – VACLs
 Virtual Routing and Forwarding - VRFs
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
18
A RACL is an administratively configured access control list that is applied to Layer 3 traffic
that is routed into or out Nexus 9000 Series switch. A PACL is an administratively configured
access control list that is applied to Layer 2 traffic that is routed into Nexus 9000 Series switch.
A VACL is an administratively configured access control list that is applied to packets that are
routed into or out of a VLAN or are bridged within a VLAN. VACLs are strictly for security
packet filtering and for redirecting traffic to specific physical interfaces.
RACLs can filter traffic based on the following: Source IP address, Destination IP address,
Source port number, Destination port number, Protocol, ICMP message type, ICMP message
code, IGMP message type, Precedence, Packet Length, or DSCP value.
PACLs can filter ingress traffic based on the following: Source IP address, Destination IP
address, Source port number, Destination port number, Protocol, ICMP message type, ICMP
message code, IGMP message type, Source MAC address, Destination MAC address, Protocol,
Class of Service (COS), VLAN ID, Precedence, Packet Length, or DSCP value.
Traffic into or out of a VLAN can be filtered by VACLs based on the following: Source IP
address, Destination IP address, Source port number, Destination port number, Protocol, ICMP
message type, ICMP message code, IGMP message type, Source MAC address, Destination
MAC address, Protocol, Class of Service (COS), VLAN ID, Precedence, Packet Length, or
DSCP value.
The TOE supports Virtual Routing and Forwarding (VRF). VRFs allow multiple instances of
routing tables to exist within the Nexus 9000 Series switch TOE component simultaneously. This
increases functionality by allowing network paths to be segmented without using multiple
devices. Each VRF instance uses a single routing table. These tables prevent traffic from being
forwarded outside a specific VRF path and also keep out traffic that should remain outside the
VRF path.
Security Management
1.6.6
The TOE provides secure administrative services for management of general TOE configuration
and the security functionality provided by the TOE. All TOE administration occurs either
through a secure SSHv2 session or via a local console connection. The TOE provides the ability
to securely manage:
 All TOE administrative users;
 All identification and authentication;
 All audit functionality of the TOE;
 All TOE cryptographic functionality;
 Information Flow Control Policies and Rules;
 The timestamps maintained by the TOE;
 Update to the TOE; and
 TOE configuration file storage and retrieval.
Unlike Cisco IOS devices, which use privilege levels to determine authorization, Cisco NX-OS
devices use role-based access control (RBAC). To enable both types of devices to be
administered by the same TACACS+ servers, an authorized administrator can map the privilege
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
19
levels configured on TACACS+ servers to user roles configured on Cisco
NX-OS devices. The Nexus 9000 Series switch supports the following predefined roles:
 network-admin – This role is a super administrative role. This role has read and write
privileges for any configuration item on the Nexus 9000 Series.
 network-operator - This role has read access to the entire Cisco NX-OS device.
All administrators are considered to be security administrators in this ST. Administrators can
create configurable login banners to be displayed at time of login. The 9k has a CLI that can be
administered either remotely using SSHv2 or locally via a console that is directly connected via a
serial cable.
Protection of the TSF
1.6.7
The TOE protects against interference and tampering by untrusted subjects by implementing
identification, authentication, and access controls to limit configuration and access to Authorized
Administrators. The TOE prevents reading of cryptographic passwords.
Additionally Cisco NX-OS is not a general-purpose operating system and access to Cisco NX-
OS memory space is restricted to only Cisco NX-OS functions.
Use of separate VLANs is used to ensure routing protocol communications between the TOE and
neighbor switches including routing table updates and neighbor switch authentication will be
logically isolated from traffic on other VLANs.
The TOE internally maintains the date and time. This date and time is used as the timestamp that
is applied to audit records generated by the TOE. Administrators can update the TOE’s clock
manually. Finally, the TOE performs power-up self-tests and conditional self-tests to verify
correct operation of the switch itself and that of the cryptographic module.
TOE Access
1.6.8
The administrator can terminate their own session by exiting out of the CLI. The TOE can also
be configured to display an Authorized Administrator specified banner on the CLI management
interface prior to allowing any administrative access to the TOE.
Trusted path/Channels
1.6.9
The TOE allows trusted paths to be established to itself from remote administrators over SSHv2
for remote CLI access.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
20
1.7 Excluded Functionality
The following functionality is excluded from the evaluation.
Table 8 Excluded Functionality
Excluded Functionality Exclusion Rationale
Telnet Telnet will be disabled in the evaluated configuration.
SNMP SNMP will be disabled in the evaluated configuration.
NTP NTP will be disabled in the evaluated configuration.
DCNM GUI The DCNM GUI was not included in the evaluated configuration.
Bash shell Bash shell interface was not included in the evaluation.
PTP PTP is not included in the evaluation.
These functions will be disabled by configuration. The DCNM Management GUI is a separate
application, not shipped or downloaded with the Nexus 9k standalone image.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
21
2 CONFORMANCE CLAIMS
2.1 Common Criteria Conformance Claim
The TOE and ST are compliant with the Common Criteria (CC) Version 3.1, Revision 4, dated:
September 2012. For a listing of Assurance Requirements claimed see section 5.6.1. The TOE
and ST are EAL2 conformant as wells as CC Part 2 extended and CC Part 3 conformant.
2.2 Protection Profile Conformance
This ST and TOE it describes is not claiming conformance to any Protection Profile.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
22
3 SECURITY PROBLEM DEFINITION
This chapter identifies the following:
 Significant assumptions about the TOE’s operational environment.
 IT related threats to the organization countered by the TOE.
 Environmental threats requiring controls to provide sufficient protection.
 Organizational security policies for the TOE as appropriate.
This document identifies assumptions as A.assumption with “assumption” specifying a unique
name. Threats are identified as T.threat with “threat” specifying a unique name. Organizational
Security Policies (OSPs) are identified as P.osp with “osp” specifying a unique name.
3.1 Assumptions
The specific conditions listed in the following subsections are assumed to exist in the TOE’s
environment. These assumptions include both practical realities in the development of the TOE
security requirements and the essential environmental conditions on the use of the TOE.
Table 9 TOE Assumptions
Assumption Assumption Definition
A.NO_GENERAL_PURPOSE It is assumed that there are no general-purpose computing capabilities (e.g.,
compilers or user applications) available on the TOE, other than those services
necessary for the operation, administration and support of the TOE.
A.PHYSICAL Physical security, commensurate with the value of the TOE and the data it
contains, is assumed to be provided by the environment.
A.SYSLOG It is assumed the TOE administrator will ensure the session between the TOE
and the remote syslog server is secured.
A.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator guidance
in a trusted manner.
3.2 Threats
The following table lists the threats addressed by the TOE and the IT Environment. The
assumed level of expertise of the attacker for all the threats identified below is Enhanced-Basic.
Table 10 Threats
Threat Threat Definition
T.NET_TRAFFIC An unauthorized user may send network traffic to unauthorized
destinations through the Nexus 9000 Series switch without detection.
T.TSF_FAILURE An attacker succeeds in triggering an undetected change in the TOE
start-up procedure or configuration to cause starting up of the TOE into
an insecure state resulting in the loss of integrity of the TSF.
T.UNAUTHORIZED_ACCESS An unauthorized user succeeds in gaining access to the TOE or to
legitimate administrator authentication data communicated between the
TOE and a Management Station by successfully masquerading as an
authorized administrator or legitimate TOE in order to gain
unauthorized access to data or TOE resources.
T.UNDETECTED_ACTIONS Malicious remote users or external IT entities may take actions that
adversely affect the security of the TOE. These actions may remain
undetected and thus their effects cannot be effectively mitigated.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
23
Threat Threat Definition
T.USER_DATA_REUSE An attacker may disrupt the TOE causing user data to be inadvertently
sent to a destination not intended by the original sender.
3.3 Organizational Security Policies
The following table lists the Organizational Security Policies imposed by an organization to
address its security needs.
Table 11 Organizational Security Policies
Policy Name Policy Definition
P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or
any other appropriate information to which users consent by accessing the TOE.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
24
4 SECURITY OBJECTIVES
This Chapter identifies the security objectives of the TOE and the IT Environment. The security
objectives identify the responsibilities of the TOE and the TOE’s IT environment in meeting the
security needs.
 This document identifies objectives of the TOE as O.objective with objective specifying
a unique name. Objectives that apply to the IT environment are designated as
OE.objective with objective specifying a unique name.
4.1 Security Objectives for the TOE
The following table, Security Objectives for the TOE, identifies the security objectives of the
TOE. These security objectives reflect the stated intent to counter identified threats and/or
comply with any security policies identified. An explanation of the relationship between the
objectives and the threats/policies is provided in the rationale section of this document.
Table 12 Security Objectives for the TOE
TOE Objective TOE Security Objective Definition
O.DATA_FLOW_CONTROL The TOE shall ensure that only authorized traffic is
permitted to flow through the TOE to its destination.
O.DISPLAY_BANNER The TOE will display an advisory warning regarding use of
the TOE.
O.PROTECTED_COMMUNICATIONS The TOE will provide protected communication channels
for administrators and authorized IT entities.
O.RESIDUAL_INFORMATION_CLEARING The TOE will ensure that any data contained in a protected
resource is not available when the resource is reallocated.
O.SYSTEM_MONITORING The TOE will provide the capability to generate audit data
and send those data to an external IT entity.
O.TOE_ADMINISTRATION The TOE will provide mechanisms to ensure that only
administrators are able to log in and configure the TOE.
O.TSF_SELF_TEST The TOE will provide the capability to test some subset of
its security functionality to ensure it is operating properly.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
25
4.2 Security Objectives for the Environment
All of the assumptions stated in section 3.1 are considered to be security objectives for the
environment. The following are the Protection Profile non-IT security objectives, which, in
addition to those assumptions, are to be satisfied without imposing technical requirements on the
TOE. That is, they will not require the implementation of functions in the TOE hardware and/or
software. Thus, they will be satisfied largely through application of procedural or administrative
measures.
Table 13 Security Objectives for the Environment
Environment Security
Objective
IT Environment Security Objective Definition
OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g., compilers or user
applications) available on the TOE, other than those services necessary for the
operation, administration and support of the TOE.
OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it
contains, is provided by the environment.
OE.SYSLOG The TOE administrator will ensure the session between the TOE and the
remote syslog server is secured.
OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator guidance
in a trusted manner.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
26
5 SECURITY REQUIREMENTS
This section identifies the Security Functional Requirements for the TOE. The Security
Functional Requirements included in this section are derived from Part 2 of the Common Criteria
for Information Technology Security Evaluation, Version 3.1, Revision 4, dated: September 2012
and all international interpretations.
5.1 Extended TOE Security Functional Components
This section specifies the extended SFRs for the TOE. The extended SFRs have been organized
by class. Table 14 identifies all extended SFRs implemented by the TOE.
Table 14 Extended TOE Security Functional Requirements
Name Description
FCS_SSH_EXT.1 Explicit: SSH
FIA_PMG_EXT.1 Password Management
FIA_UIA_EXT.1 User Identification and Authentication
FIA_UAU_EXT.2 Extended: Password-based Authentication Mechanism
FPT_APW_EXT.1 Extended: Protection of Administrator Passwords
FPT_TST_EXT.1 TSF Testing
Cryptographic Support (FCS)
5.1.1
FCS_SSH_EXT.1 SSH
5.1.1.1
Family Behavior
The component in this family addresses the ability for a server to offer SSH to protect data
between a client and the server using the SSH protocol.
Component leveling
FCS_SSH_EXT.1 SSH Server requires that the server side of SSH be implemented as specified.
Management: FCS_SSH_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_SSH_EXT.1
FCS_SSH_EXT SSH Server Protocol 1
F
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
27
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) Failure of SSH session establishment.
b) SSH session establishment
c) SSH session termination
FCS_SSH_EXT.1 SSH Server Protocol
Hierarchical to: No other components
Dependencies: FCS_COP.1 Cryptographic operation
FCS_SSH_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs 4251,
4252, 4253, and 4254.
FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following authentication methods as described in RFC 4252: public key-based, password-based.
FCS_SSH_EXT.1.3 The TSF shall ensure that the SSH transport implementation supports the
following encryption algorithms: AES-CTR-128, AES-CTR-192, AES-CTR-256.
FCS_SSH_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses
SSH_RSA and [selection: PGP-SIGN-RSA, PGP-SIGN-DSS, no other public key algorithms,] as
its public key algorithm(s).
FCS_SSH_EXT.1.5 The TSF shall ensure that data integrity algorithms used in SSH transport
connection is [selection: hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96].
Identification and authentication (FIA)
5.1.2
FIA_PMG_EXT.1 Password Management
5.1.2.1
Family Behavior
The TOE defines the attributes of passwords used by administrative users to ensure that strong
passwords and passphrases can be chosen and maintained.
Component leveling
FIA_PMG_EXT.1 Password management requires the TSF to support passwords with varying
composition requirements, minimum lengths, maximum lifetime, and similarity constraints.
FIA_PMG_EXT Password Management 1
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
28
Management: FIA_PMG_EXT.1
No management functions.
Audit: FIA_PMG_EXT.1
No specific audit requirements.
FIA_PMG_EXT.1 Password Management
Hierarchical to: No other components.
Dependencies: No other components.
FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities
for administrative passwords:
1. Passwords shall be able to be composed of any combination of upper and lower case
letters, numbers, and the following special characters: [selection: “!”, “@”, “#”, “$”,
“%”, “^”, “&”, “*”, “(“, “)”].
FIA_UIA_EXT.1 User Identification and Authentication
5.1.2.2
Family Behavior
The TSF allows certain specified actions before the non-TOE entity goes through the
identification and authentication process.
Component leveling
FIA_UIA_EXT.1 User Identification and Authentication requires administrators (including
remote administrators) to be identified and authenticated by the TOE, providing assurance for
that end of the communication path. It also ensures that every user is identified and authenticated
before the TOE performs any mediated functions
Management: FIA_UIA_EXT.1
The following actions could be considered for the management functions in FMT:
a) Ability to configure the list of TOE services available before an entity is identified and
authenticated
Audit: FIA_UIA_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
FIA_UIA_EXT User Identification and Authentication 1
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
29
a) All use of the identification and authentication mechanism
b) Provided user identity, origin of the attempt (e.g. IP address)
FIA_UIA_EXT.1 User Identification and Authentication
Hierarchical to: No other components.
Dependencies: FTA_TAB.1 Default TOE Access Banners
FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE
entity to initiate the identification and authentication process:
 Display the warning banner in accordance with FTA_TAB.1;
 [selection: no other services. [assignment: list of services, actions performed by the TSF
in response to unauthenticated non-TOE requests.]
FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully
identified and authenticated before allowing any other TSF-mediated action on behalf of that
administrative user.
FIA_UAU_EXT.2 Extended: Password-based Authentication Mechanism
5.1.2.3
Family Behavior
Provides for a locally based administrative user authentication mechanism
Component leveling
FIA_UAU_EXT.2 The password-based authentication mechanism provides administrative users
a locally based authentication mechanism.
Management: FIA_UAU_EXT.2
The following actions could be considered for the management functions in FMT:
a) None
Audit: FIA_UAU_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) Minimal: All use of the authentication mechanism
FIA_UAU_EXT Password-based Authentication Mechanism 2
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
30
FIA_UAU_EXT.2 Password-based Authentication Mechanism
Hierarchical to: No other components.
Dependencies: None
FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism,
[selection: [assignment: other authentication mechanism(s)], none] to perform administrative
user authentication.
Protection of Administrator Passwords (FPT_APW_EXT)
5.1.3
FPT_APW_EXT.1 Protection of Administrator Passwords
5.1.3.1
Family Behavior
Components in this family ensure that the TSF will protect plaintext credential data such as
passwords from unauthorized disclosure.
Component leveling
FPT_APW_EXT.1 Protection of administrator passwords requires that the TSF prevent plaintext
credential data from being read by any user or subject.
Management: FPT_APW_EXT.1
The following actions could be considered for the management functions in FMT:
a) No management functions.
Audit: FPT_APW_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) No audit necessary.
FPT_APW_EXT.1 Protection of Administrator Passwords
Hierarchical to: No other components
Dependencies: No other components.
FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form.
FPT_APW_EXT Protection of Administrator Passwords 1
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
31
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords.
FPT_TST_EXT.1: TSF Testing
5.1.3.2
Family Behavior
Components in this family address the requirements for self-testing the TSF for selected correct
operation.
Component leveling
FPT_TST_EXT.1 TSF Self-test requires a suite of self-tests to be run during initial start-up in
order to demonstrate correct operation of the TSF.
FPT_TST_EXT.2 Self-tests based on certificates applies when using certificates as part of self-
test, and requires that the self-test fails if a certificate is invalid.
Management: FPT_TST_EXT.1, FPT_TST_EXT.2
The following actions could be considered for the management functions in FMT:
a) No management functions.
Audit: FPT_TST_EXT.1, FPT_TST_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) Indication that TSF self-test was completed
FPT_TST_EXT.1 TSF testing
Hierarchical to: No other components.
Dependencies: None
FPT_TST_EXT.1.1 The TSF shall run a suite of self-tests during initial start-up (on power on)
to demonstrate the correct operation of the TSF.
5.2 Conventions
The CC defines operations on Security Functional Requirements: assignments, selections,
assignments within selections and refinements. This document uses the following font
conventions to identify the operations defined by the CC:
 Assignment: Indicated with [italicized] text within brackets;
 Assignment within a selection: Indicated with [italicized underlined] text within brackets;
 Refinement: Indicated with bold text and/or strikethroughs;
FPT_TST_EXT TSF Self-test
1
2
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
32
 Selection: Indicated with [underlined] text within brackets;
 Iteration: Indicated by appending the iteration number in parenthesis, e.g., (1), (2), (3).
Explicitly stated SFRs are identified by having a label ‘EXT’ after the requirement name for
TOE SFRs.
5.3 TOE Security Functional Requirements
This section identifies the Security Functional Requirements for the TOE. The TOE Security
Functional Requirements that appear in the following table are described in more detail in the
following subsections.
Table 15 Security Functional Requirements
Class Name Component
Identification
Component Name
FAU: Security audit FAU_GEN.1 Audit data generation
FAU_GEN.2 User Identity Association
FAU_STG.1 Protected Audit Trail Storage
FCS: Cryptographic support FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.4 Cryptographic Key Zeroization
FCS_COP.1 Cryptographic Operation
FCS_SSH_EXT.1 Explicit: SSH
FDP: User data protection FDP_IFC.1 Complete information flow control
FDP_IFF.1 Simple security attributes
FDP_RIP.2 Full Residual Information Protection
FIA: Identification and
authentication
FIA_PMG_EXT.1 Explicit: Password Management
FIA_UIA_EXT.1 Explicit: User Identification and Authentication
FIA_UID.2 User identification before any action
FIA_UAU_EXT.2 Explicit: Password-based Authentication Mechanism
FIA_UAU.7 Protected authentication feedback
FMT: Security management FMT_MSA.1 Management of security attributes
FMT_MSA.3 Static attribute initialisation
FMT_MTD.1 Management of TSF Data
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security Roles
FPT: Protection of the TSF FPT_APW_EXT.1 Extended: Protection of Administrator Passwords
FPT_STM.1 Reliable Time Stamps
FPT_TST_EXT.1 TSF Testing
FTA: TOE Access FTA_SSL.4 User-initiated Termination
FTA_TAB.1 Default TOE Access Banners
FTP: Trusted path/channels FTP_TRP.1 Trusted Path
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
33
5.4 SFRs
Security audit (FAU)
5.4.1
FAU_GEN.1 Audit data generation
5.4.1.1
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shut-down of the audit functions;
b) All auditable events for the [not specified] level of audit; and
c) [
 When a packet matches a configured deny ACL rule;
 Configuration Changes on the Nexus 9k standalone series switch;
 Administrative Authentication on the the Nexus 9k standalone series switch;
 Administrative Log-off on the the Nexus 9k standalone series switch].
FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or
failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the functional
components included in the PP/ST, [information specified in column two of Table 16].
Table 16 Auditable Events
Audited Action Recorded Information
When a packet matches a configured deny IP
ACL rule
Protocol
Type
Source address
Destination address
Source Port (if applicable)
Destination Port (if applicable)
Configuration Changes on the Nexus 9k
standalone Series switch
Day of Week, Date, Action, User, status of the configuration
change, terminal information (when applicable)
Administrative Authentication on the Nexus 9k
standalone Series switch
Date, Action, User, terminal information (when applicable)
Administrative Log-off on the Nexus 9k
standalone Series switch
Date, Action, User, terminal information (when applicable)
FAU_GEN.2 User Identity Association
5.4.1.2
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able
to associate each auditable event with the identity of the user that caused the event.
FAU_STG.1 Protected Audit Trail Storage
5.4.1.3
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised
deletion.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
34
FAU_STG.1.2 The TSF shall be able to [prevent] unauthorised modifications to the stored audit
records in the audit trail.
Cryptographic Support (FCS)
5.4.2
FCS_CKM.1 Cryptographic key generation
5.4.2.1
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [see first column in Table 17 below] and specified
cryptographic key sizes [see "key sizes" column in Table 17 below] that meet the following: [see
last column in Table 17 below].
Table 17 Cryptographic Key Generation
Cryptographic key generation algorithm Key sizes List of standards
RSA 1024, 2048 bits FIPS 140-2
Diffie-Hellman (Group 1, Group 14) 128 and 256 bits FIPS 140-2
Hmac-sha-1 160 bits FIPS 140-2
FCS_CKM.4 Cryptographic key destruction
5.4.2.2
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [zeroization] that meets the following: [FIPS 140-2
requirements stated in Annex A Table 30].
FCS_COP.1 Cryptographic operation
5.4.2.3
FCS_COP.1.1 The TSF shall perform [See "cryptographic operations" in Table 18] in
accordance with a specified cryptographic algorithm [See "algorithm" in Table 18] and
cryptographic key sizes [See "key size" in Table 18] that meet the following: [See "list of
standards" in Table 18].
Table 18 Cryptographic Operations
Cryptographic
Operation
Algorithm Key Size List of Standards
Encryption/Decryption AES (CTR, ECB, GMAC) 128 bits
192 bits
256 bits
FIPS 140-2, FIPS PUB 197, NIST SP 800-
38A, NIST SP 800-38D
Cryptographic
signature
DSA 1024-bits
2048-bits
FIPS 140-2,
FIPS PUB 186-3, “Digital Signature
Standard”
Cryptographic
signature
RSA (rDSA) 1024-bits
2048-bits
FIPS 140-2, FIPS PUB 186-2 or FIPS PUB
186-3, “Digital Signature Standard”
Cryptographic Hashing
Services
SHA-1, SHA-256. SHA-512 160 bits
256 bits
512 bits
FIPS 140-2, FIPS PUB 186-3, “Digital
Signature Standard”
Keyed-hash message
authentication
HMAC-SHA-1, HMAC-
SHA-256, HMAC-SHA-384,
128 bits
256 bits
FIPS 140-2, FIPS Pub 198-1, "The Keyed-
Hash Message Authentication Code, and
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
35
Cryptographic
Operation
Algorithm Key Size List of Standards
HMAC-SHA-512 384 bits
512 bits
FIPS Pub 180-3, “Secure Hash Standard”
FCS_SSH_EXT.1 Explicit: SSH
5.4.2.4
FCS_SSH_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs 4251,
4252, 4253, 4254.
FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the
following authentication methods as described in RFC 4252: public key-based, password-based.
FCS_SSH_EXT.1.3 The TSF shall ensure that the SSH transport implementation supports the
following encryption algorithms: AES-CTR-128, AES-CTR-192, AES-CTR-256.
FCS_SSH_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses
[SSH_RSA] and [no other public key algorithms] as its public key algorithm(s).
FCS_SSH_EXT.1.5 The TSF shall ensure that data integrity algorithms used in SSH transport
connection is [hmac-sha1].
User data protection (FDP)
5.4.3
FDP_IFC.1 Subset information flow control
5.4.3.1
FDP_IFC.1.1 The TSF shall enforce the [Virtual and Distributed Switch Information Flow
Control SFP] on [
Subject:
a) physical and virtual network interfaces
Information:
b) network packets
c) operations: permit/deny/redirect/deny-and-log layer two and layer three
communications. ]
FDP_IFF.1 Simple security attributes
5.4.3.2
FDP_IFF.1.1 The TSF shall enforce the [Virtual and Distributed Switch Information Flow
Control SFP] based on the following types of subject and information security attributes: [
 Subjects: physical network interfaces and virtual network interfaces
 Subject security attributes: interface identifier, VLAN identifier (if applicable), VRF
identifier (if applicable)
 Information: network packets
 Information security attributes: IP address and MAC address source identifier, IP
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
36
address and MAC address destination identifier, protocol, packet length, Precedence,
DSCP Value, DHCP Server and interfaces configured as trusted].
FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject
and controlled information via a controlled operation if the following rules hold: [If the
configured access control lists permit the information flow based on a combination of subject
security attributes and information security attributes, then the network packets are allowed to
flow.].
FDP_IFF.1.3 The TSF shall enforce the [none].
FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the following
rules: [
 DHCP traffic received on interfaces configured as trusted is always allowed to pass, or
 ARP traffic received on interfaces configured as trusted is always allowed to pass].
FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following
rules: [
For IP Network Traffic Flows:
 The TOE denies IP traffic flow when the IP address and MAC address of the traffic are
not identified as a valid combination either through IP Source Guard/Traffic
Storm//DHCP Snooping/Dynamic ARP Inspection policies or administrative
configuration;
 For IP traffic, if the security attributes do not match an administratively configured
RACL or VACL, the traffic flow is denied; or
 If the IP traffic security attributes do not map to a configured VRF, the traffic flow is
denied;
For Non-IP Network Traffic Flows:
 For Non-IP traffic, if security attributes do not match an administratively configured
RACL, PACL, or VACL, the traffic flow is denied].
FDP_RIP.2 Full Residual Information Protection
5.4.3.3
FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made
unavailable upon the [deallocation of the resource from] all objects.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
37
Identification and authentication (FIA)
5.4.4
FIA_PMG_EXT.1 Password Management
5.4.4.1
FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities
for administrative passwords:
1. Passwords shall be able to be composed of any combination of upper and lower
case letters, numbers, and the following special characters:[“!”, “@”, “#”, “$”,
“%”, “^”, “&”, “*”, “(“,”)”].
FIA_UIA_EXT.1 User Identification and Authentication
5.4.4.2
FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE
entity to initiate the identification and authentication process:
 Display the warning banner in accordance with FTA_TAB.1;
 [no other services.]
FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully
identified and authenticated before allowing any other TSF-mediated action on behalf of that
administrative user.
FIA_UID.2 User identification before any action
5.4.4.3
FIA_UID.2.1 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
FIA_UAU_EXT.2 Extended: Password-based Authentication Mechanism
5.4.4.4
FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism,
[remote password-based authentication via RADIUS or TACACS+] to perform administrative
user authentication.
FIA_UAU.7: Protected authentication feedback
5.4.4.5
FIA_UAU.7.1The TSF shall provide only [obscured feedback] to the user while the
authentication is in progress.
Security Management (FMT)
5.4.5
FMT_MSA.1 Management of security attributes
5.4.5.1
FMT_MSA.1.1 The TSF shall enforce the [TSF Management SFP] to restrict the ability to
[[read, write]] the security attributes [defined within administratively configured ACLs policy
rules and IP Source Guard/Traffic Storm/DHCP Snooping/Dynamic ARP Inspection policies as
described in Table 19] to [the roles/operations defined in Table 19 below].
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
38
Table 19: TSF Management SFP
Role Operations
network-admin
(Resident on the Nexus 9000
Switch)
read, write operations for all security attributes defined within
administratively configured ACLs policy rules and IP Source
Guard/Traffic Storm/DHCP Snooping/Dynamic ARP Inspection..
read, write operations for all security attributes defined within
administratively configured ACLs policy rules IP Source Guard/Traffic
Storm/DHCP Snooping/Dynamic ARP Inspection policies. .
network-operator (Resident
on the Nexus 9000 Series
Switch)
Read operations for all security attributes defined within
administratively configured ACLs policy rules and IP Source
Guard/Traffic Storm/DHCP Snooping/Dynamic ARP Inspection
policies.
read operations for all security attributes defined within
administratively configured ACLs policy rules and IP Source
Guard/Traffic Storm/ DHCP Snooping/Dynamic ARP Inspection
policies.
Administrator defined role(s)
(Resident on the Nexus 9000
Series Switch)
read, write operations consistent with the role definitions.
FMT_MSA.3 Static attribute initialisation
5.4.5.2
FMT_MSA.3.1 The TSF shall enforce the [TSF Management SFP] to provide [restrictive]
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the [no role] to specify alternative initial values to override
the default values when an object or information is created.
FMT_MTD.1 Management of TSF data
5.4.5.3
FMT_MTD.1.1 The TSF shall restrict the ability to [[read, write]] the [TSF Data described in
the table below] to [the roles identified in the table below].
Table 20: Roles and operations on TSF Data
Role Operation TSF Data
Nexus 9000 Series Data
network-admin Read, write All Nexus 9000 Series configuration data.
This includes cryptographic related Nexus
9000 Series configuration data.
network-operator Read All Nexus 9000 Series configuration data.
This includes cryptographic related Nexus
9000 Series configuration data.
Administratively configured Nexus
9000 Series roles with “read”
privileges
Read Nexus 9000 Series configuration data which
can be read by the commands, features, and
feature groups for which the role is
authorized to access. This includes
cryptographic related Nexus 9000 Series
configuration data.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
39
Role Operation TSF Data
Administratively configured Nexus
9000 Series roles with “write”
privileges
Write Nexus 9000 Series configuration data which
can be written by the commands, features, and
feature groups for which the role is
authorized to access. This includes
cryptographic related Nexus 9000 Series
configuration data.
FMT_SMF.1 Specification of Management Functions
5.4.5.4
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [
 Ability to administer the TOE locally and remotely;
 Ability to configure the list of TOE-provided services available before an entity is
identified and authenticated, as specified in FIA_UIA_EXT.1;
 Ability to configure the cryptographic functionality.]
FMT_SMR.1 Security roles
5.4.5.5
FMT_SMR.1.1 The TSF shall maintain the roles [network-admin (CLI role), network-
operator(CLI role), and Administrator defined role(s) (CLI role).]
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Protection of the TSF (FPT)
5.4.6
FPT_APW_EXT.1 Extended: Protection of Administrator Passwords
5.4.6.1
FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form.
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords.
FPT_STM.1 Reliable time stamps
5.4.6.2
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
FPT_TST_EXT.1: TSF Testing
5.4.6.3
FPT_TST_EXT.1.1 The TSF shall run a suite of self-tests during initial start-up (on power on)
to demonstrate the correct operation of the TSF.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
40
TOE Access (FTA)
5.4.7
FTA_SSL.4 User-initiated Termination
5.4.7.1
FTA_SSL.4.1 The TSF shall allow user Administrator-initiated termination of the user's
Administrator’s own interactive session.
FTA_TAB.1 Default TOE Access Banners
5.4.7.2
FTA_TAB.1.1 Before establishing a user session, the TSF shall display an advisory warning
message regarding unauthorised use of the TOE.
Trusted Path/Channels (FTP)
5.4.8
FTP_TRP.1 Trusted Path
5.4.8.1
FTP_TRP.1.1 The TSF shall provide a communication path between itself and [remote]
administrators users that is logically distinct from other communication paths and provides
assured identification of its end points and protection of the communicated data from
[disclosure].
FTP_TRP.1.2 The TSF shall permit [remote users administrators] to initiate communication
via the trusted path.
FTP_TRP.1.3 The TSF shall require the use of the trusted path for [[all remote administrative
actions]].
5.5 TOE SFR Hierarchies and Dependencies
This section of the Security Target demonstrates that the identified TOE and IT Security
Functional Requirements include the appropriate hierarchical SFRs and dependent SFRs. The
following table lists the TOE Security Functional Components and the Security Functional
Components each are hierarchical to and dependent upon and any necessary rationale.
Not applicable in the Rationale column means the Security Functional Requirement has no
dependencies and therefore, no dependency rationale is required. Satisfied in the Rationale
column means the Security Functional Requirements dependency was included in the ST.
Table 21: TOE Security Functional Requirements Dependency Rationale
SFR Dependencies Rationale
FAU_GEN.1 FPT_STM.1 Met by FPT_STM.1
FAU_GEN.2 FAU_GEN.1
FIA_UID.1
Met by FAU_GEN.1
FIA_UID.2
FAU_STG.1 FAU_GEN.1 Met by FAU_GEN.1
FCS_CKM.1 [FCS_CKM.2 or
FCS_COP.1]
Met by FCS_COP.1
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
41
SFR Dependencies Rationale
FCS_CKM.4 Met by FCS_CKM.4
FCS_CKM.4 [FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
Met by FCS_CKM.1
FCS_COP.1 [FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
Met by FCS_CKM.1
FCS_CKM.4 Met by FCS_CKM.4
FCS_SSH_EXT.1 FCS_COP.1 Met by FCS_COP.1
FDP_IFC.1 FDP_IFF.1 Met by FDP_IFF.1
FDP_IFF.1 [FDP_IFC.1 or
FDP_IFC.1]
FMT_MSA.3
Met by FDP_IFC.1 and
FMT_MSA.3
FDP_RIP.2 No Dependencies Not applicable.
FIA_PMG_EXT.1 No Dependencies Not applicable.
FIA_UIA_EXT.1 FTA_TAB.1 Not applicable.
FIA_UID.2 No Dependencies Not applicable.
FIA_UAU_EXT.2 No Dependencies Not applicable.
FIA_UAU.7 FIA_UAU.1 Met by
FIA_UAU_EXT.2
FIA_UAU_EXT.2 is
modeled after
FIA_UAU.2 which is
hierarchical to
FIA_UAU.1 and
therefore meets the
dependency.
FMT_MSA.1 [FDP_ACC.1, or
FDP_IFC.1]
FMT_SMR.1
FMT_SMF.1
Not applicable as the
TSF Management SFP
is defined in Table 19
instead of in a separate
SFR.
Met by FMT_SMR.1
Met by FMT_SMF.1
FMT_MSA.3 FMT_MSA.1 Met by FMT_MSA.1
FMT_SMR.1 Met by FMT_SMR.1
FMT_MTD.1 FMT_SMF.1 Met by FMT_SMF.1
FMT_SMR.1 Met by FMT_SMR.1
FMT_SMF.1 No Dependencies Not applicable.
FMT_SMR.1 FIA_UID.1 Met by FIA_UID.2
FPT_APW_EXT.1 No Dependencies Not applicable.
FPT_STM.1 No Dependencies Not applicable.
FPT_TST_EXT.1 No Dependencies Not applicable.
FTA_SSL.4 No Dependencies Not applicable.
FTA_TAB.1 No Dependencies Not applicable.
FTP_TRP.1 No Dependencies Not applicable.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
42
5.6 Extended TOE Security Functional Components Definition
This Security Target includes Security Functional Requirements (SFR) that are not drawn from
existing CC Part 2. The Extended SFRs are identified by having a label ‘_EXT’ after the
requirement name for TOE SFRs. The structure of the extended SFRs is modeled after the SFRs
included in CC Part 2. The structure is as follows:
A. Class – The extended SFRs included in this ST are part of the identified classes of
requirements.
B. Family – The extended SFRs included in this ST are part of several SFR families
C. Component – The extended SFRs are not hierarchical to any other components,
though they may have identifiers terminating on other than “1”. The dependencies
for each extended component are identified in the TOE SFR Dependencies section of
this ST below.
D. The management requirements, if any, associated with the extended SFRs are
incorporated into the Security management SFRs defined in this ST.
E. The audit requirements, if any, associated with the extended SFRs are incorporated
into the Security audit SFRs defined in this ST.
F. The dependency requirements, if any, associated with the extended SFRs are
identified in the dependency rationale and mapping section of the ST (Table 21).
Table 22 Extended Components Rationale
Component Rationale
FCS_SSH_EXT.1 This SFR was modeled from the NDPP – where it is defined as a requirement specific to SSH
protocol supported by the TOE. The SSH protocol is used to secure communications between
the TOE and the endpoints; mainly remote administration. Securing the communication
channel provides interoperability and resistance to cryptographic attack by means of two-way
authentication of each endpoint. Compliance to the NDPP is not being claimed and the SFR
has been adapted in this ST to support the TOE’s implementation of the protocol as well as the
specifics detailed in the NDPP. Given that this is a validated US Government Protection
Profile the rationale for use of this extended requirement is deemed acceptable.
FIA_PMG_EXT.1 This SFR was modeled from the NDPP – where it is defined as a requirement for TSF
password complexity rules for TOE administrators. FIA_PMG_EXT.1 was used to distinguish
that the password quality parameters are required for administrator passwords and not user
passwords. The FIA_SOS.1 SFR in the CC Part 2 does not distinguish between administrator
and user password quality parameters. In addition, this extended SFR provides for password
management capabilities of administrative passwords that the CC Part 2 SFR does not
provide. Compliance to the NDPP is not being claimed and the SFR has been adapted in this
ST to support the TOE’s authentication security functionality. Given this is a validated US
Government Protection Profile the rationale for use of this extended requirement is deemed
acceptable.
FIA_UIA_EXT.1 This SFR was modeled from the NDPP – where it is defined as a requirement for TSF actions
allowed prior to identification and authentication of an authorized administrator. Compliance
to the NDPP is not being claimed and the SFR has been adapted in this ST to support the
TOE’s identification and authentication security functionality. Given this is from a validated
US Government Protection Profile the rationale for use of this extended requirement is deemed
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
43
Component Rationale
acceptable.
FIA_UAU_EXT.2 This SFR was modeled from the NDPP – where it is defined as a requirement for TSF user
authentication. Compliance to the NDPP is not being claimed and the SFR has been adapted
in this ST to support the TOE’s authentication security functionality. Given this is from a
validated US Government Protection Profile the rationale for use of this extended requirement
is deemed acceptable.
FPT_APW_EXT.1 This SFR was modeled from NDPP – where it is defined as a requirement for the TSF to not
store passwords in plaintext. Compliance to the NDPP is not being claimed and the SFR has
been adapted in this ST to support the TOE’s authentication security functionality. Given this
is a validated US Government Protection Profile the rationale for use of this extended
requirement is deemed acceptable.
FPT_TST_EXT.1 This SFR was modeled from NDPP – where it is defined as a requirement for TSF self-tests of
the TOE during initialization (on bootup) that allows for the detection of failures of the
underlying security mechanisms prior to the TOE becoming operational. Compliance to the
NDPP is not being claimed and the SFR has been adapted in this ST to support the TOE’s
comprehensive set of self-tests. Given this is from a validated US Government Protection
Profile the rationale for use of this extended requirement is deemed acceptable.
Security Assurance Requirements Rationale
5.6.1
This Security Target claims conformance to EAL2. This target was chosen to ensure that the
TOE has a moderate level of assurance in enforcing its security functions when instantiated in its
intended environment which imposes no restrictions on assumed activity on applicable networks.
The TOE satisfies the identified assurance requirements. This section identifies the Assurance
Measures applied by Cisco to satisfy the assurance requirements. The table below lists the
details.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
44
5.7 Assurance Measures
The TOE satisfies the identified assurance requirements. This section identifies the Assurance
Measures applied by Cisco to satisfy the assurance requirements. The table below lists the
details.
Table 23: Assurance Measures for EAL2
Component How requirement will be met
ADV_ARC.1 The architecture description provides the justification how the security functional
requirements are enforced, how the security features (functions) cannot be bypassed, and how
the TOE protects itself from tampering by untrusted active entities. The architecture
description also identifies the system initialization components and the processing that occurs
when the TOE is brought into a secure state (e.g. transition from a down state to the initial
secure state (operational).it’
ADV_FSP.2 The functional specification describes the external interfaces of the TOE; such as the means
for a user to invoke a service and the corresponding response of those services. The
description includes the interface(s) that enforces a security functional requirement, the
interface(s) that supports the enforcement of a security functional requirement, and the
interface(s) that does not enforce any security functional requirements. The interfaces are
described in terms of their purpose (general goal of the interface), method of use (how the
interface is to be used), parameters (explicit inputs to and outputs from an interface that
control the behavior of that interface), parameter descriptions (tells what the parameter is in
some meaningful way), and error messages (identifies the condition that generated it, what
the message is, and the meaning of any error codes). The development evidence also contains
a tracing of the interfaces to the SFRs described in this ST.
ADV_TDS.1 The TOE design describes the TOE security functional (TSF) boundary and how the TSF
implements the security functional requirements. The design description includes the
decomposition of the TOE into subsystems, thus providing the purpose of the subsystem, the
behavior of the subsystem and the actions the subsystem performs. The description also
identifies the subsystem as SFR (security function requirement) enforcing, SFR supporting,
or SFR non-interfering; thus identifying the interfaces as described in the functional
specification. In addition, the TOE design describes the interactions among or between the
subsystems; thus providing a description of what the TOE is doing and how.
AGD_OPE.1 The Administrative Guide provides the descriptions of the processes and procedures of how
the administrative users of the TOE can securely administer the TOE using the interfaces that
provide the features and functions detailed in the guidance.
AGD_PRE.1 The Installation Guide describes the installation, generation, and startup procedures so that
the users of the TOE can put the components of the TOE in the evaluated configuration.
ALC_CMC.2 The Configuration Management (CM) document(s) describes how the consumer (end-user) of
the TOE can identify the evaluated TOE (Target of Evaluation). The CM document(s),
identifies the configuration items, how those configuration items are uniquely identified, and
the adequacy of the procedures that are used to control and track changes that are made to the
TOE. This includes details on what changes are tracked, how potential changes are
incorporated, and the degree to which automation is used to reduce the scope for error.
Cisco uniquely identifies configuration items and each release of the TOE has a unique
reference. The Configuration Management documentation contains a configuration item list.
ALC_CMS.2
ALC_DEL.1 Cisco documents the delivery procedure for the TOE to include the procedure on how to
download certain components of the TOE from the Cisco website and how certain
components of the TOE are physically delivered to the user. The delivery procedure detail
how the end-user may determine if they have the TOE and if the integrity of the TOE has
been maintained. Further, the delivery documentation describes how to acquire the proper
license keys to use the TOE components.
ATE_COV.1 The Test document(s) consist of a test plan describes the test configuration, the approach to
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
45
Component How requirement will be met
ATE_FUN.1 testing, and how the TOE security functionality interfaces (TSFI) has been tested against its
functional specification as described in the TOE design and the security architecture
description. The test document(s) also include the test cases/procedures that show the test
steps and expected results, specify the actions and parameters that were applied to the
interfaces, as well as how the expected results should be verified and what they are. Actual
results are also included in the set of Test documents.
ATE_IND.2 Cisco will provide the TOE for testing.
AVA_VAN.2 Cisco will provide the TOE for testing.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
46
6 TOE SUMMARY SPECIFICATION
6.1 TOE Security Functional Requirement Measures
This chapter identifies and describes how the Security Functional Requirements identified above
are met by the TOE.
Table 24 How TOE SFRs are Met
TOE SFRs How the SFR is Met
FAU_GEN.1 The TOE generates an audit record that is stored internally within the TOE whenever an
audited event occurs. The types of events that cause audit records to be generated include,
cryptography related events, events related to the enforcement of information flow policies,
identification and authentication related events, and administrative events (the specific events
and the contents of each audit record are listed in Table 16. Each of the events is specified in
the syslog which is stored internal to the TOE in enough detail to identify the user for which
the event is associated, when the event occurred, where the event occurred, the outcome of the
event, and the type of event that occurred.
The administrative configuration of RACLs, PACLs, and VACLS contain an option to enable
auditing. If auditing is enabled, each time traffic that matches a configured RACL, PACL, or
VACL enters or leaves the Nexus 9000 Series switch an audit record is generated. The type of
information recorded depends on what type of ACL is met and the action applied to the traffic.
A full list of the contents of the generated audit information can be found in the table
associated with FAU_GEN.1.
Each time an administrative user logs into or off of the Nexus 9000 Series switch, an audit
record is generated. The audit record contains the Day of Week, the Date, the Action, the User
ID, and terminal information (where applicable) of the user logging into the Nexus 9000
Series switch. Whenever an administrative user make a configuration change to the Nexus
9000 Series switch, an audit record is generated on a per-command basis. Likewise, the audit
record contains the Day of Week, the Date, the Action, the User ID, the outcome of the event,
and terminal information (where applicable) of the user making the configuration change.
Auditing cannot be globally disabled and is automatically available upon the startup of the
TOE. As a result, there is no auditable event that captures the startup and shutdown of the
audit function. Therefore, the first audit event on startup and the last audit event on shutdown
of the TOE are the designated startup and shutdown audit events.
Example audit events are included below:
Fri May 30 13:21:22 2014:type=update:id=64.103.212.160@pts/0:user=admin
:cmd=configure terminal ; username test123 password ******** role network-operator
(SUCCESS)
In the above log event a date and timestamp is displayed as well as an event description
“cmd=configure terminal”. The subject identity where a command is directly run by a user is
displayed “user=admin.” The outcome of the command is displayed: “SUCCESS”.
FAU_GEN.2 The TOE shall ensure that each auditable event is associated with the user that triggered the
event and as a result they are traceable to a specific user. For example a human user, user
identity, or related session ID would be included in the audit record. For an IT entity or
device, the IP address, MAC address, host name, or other configured identification is
presented. A sample audit record is below:
Fri May 30 13:21:22 2014:type=update:id=64.103.212.160@pts/0:user=admin:cmd=deleted
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
47
TOE SFRs How the SFR is Met
user test123
FAU_STG.1 Access to the audit records stored on the TOE is only through a TSF Mediated interface. Only
users explicitly authorized to access the audit records are given access to the audit records.
There is no interface which may be used to perform audit record modification. In addition,
logs can only be cleared by an authorized administrator.
For the Nexus 9000 Series, logs are written to DRAM, NVRAM, and flash. By default,
system messages of severity 0, 1, or 2 (emergency, alert, or critical) are logged to NVRAM
(#show log nvram). Additionally by default, system messages are written to DRAM
log:messages (#show log) and to the flash (#show logging logfile) at logging level 5 (which
includes levels 0-5) with up to 4 MB size.
The logging logfile global configuration command enables copying of system messages to an
internal log file in flash, allows for setting the level of logging (0-7) which by default is level
5, and optionally sets the size of the file as well as the name of the log file.
The AAA logs that audit administrator actions on the TOE are stored separately in the AAA
accounting log. All log locations are protected from modification and unauthorized deletion
through the roles assigned to authorized administrators. The logging to NVRAM and flash
provide persistent logging data after a system reload. By default, the logs are circular and
once the log files reach capacity of the flash storage, they are overwritten. With NX-OS, there
is logging of event-histories that run in the background by default. The event-history log size
is configurable.
FCS_CKM.1 The TOE generates cryptographic keys for Diffie-Hellman key establishment (conformant to
NIST SP 800-56A) and for RSA key establishment schemes (conformant to NIST SP 800-
56B). Diffie-hellman is used to generate the key that will secure the SSH sessions. The TOE
complies with section 5.6 and all subsections regarding asymmetric key pair generation and
key establishment in the NIST SP 800-56A. The TOE complies with section 6 and all
subsections regarding RSA key pair generation and key establishment in the NIST SP 800-
56B.
The HMAC-SHA1 is used for the key generation in authenticating the RADIUS and PAC
communications. HMAC-1 is also used to ensure data integrity during SSH sessions.
FCS_CKM.4 The TOE meets all requirements specified in FIPS 140-2 for destruction of keys and Critical
Security Parameters (CSPs) in that none of the symmetric keys, pre-shared keys, or private
keys are stored in plaintext form.
Through the implementation of cryptographic module, the TOE zeroizes all of the
cryptographic keys used within the TOE after the key is no longer of use to the TOE. The key
and CSP zeroization capabilities of the TOE have been verified as part of the TOE’s FIPS
140-2 validation. See Table 6 and Table 30 for more information.
The cryptographic key destruction is used as follows:
 After TOE administration via SSH/SFTP is completed, the tunnel is torn down and
the session key is overwritten.
FCS_COP.1 The TOE provides symmetric encryption and decryption capabilities using AES in CTR, ECB,
and GMAC modes (128, 192, and 256 bits) as described in FIPS PUB 197, NIST SP 800-38A
and NIST SP 800-38D. AES is implemented in the following protocols: SSHv2. Through the
implementation of the FIPS validated algorithms, the TOE provides AES encryption and
decryption in support of SSHv2 for secure communications and for encrypting stored
passwords. Management of the cryptographic algorithms is provided through the CLI with
auditing of those commands. AES data encryption is the encryption/ decryption option that is
used within SSHv2 communications. Specifically, AES is used to encrypt SSHv2 session
traffic.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
48
TOE SFRs How the SFR is Met
AES - Provides data protection using symmetric encryption and decryption for SSH/SFTP
communications. AES is used to encrypt the password.
SHA- hashing - Provides the hashing protection required by the SSH protocol.
RSA: This provides the asymmetric encryption used as part of the session setup process for
SSH communications.
DSA: Provides data protection using symmetric encryption and decryption for SSH/SFTP
communications.
HMAC-SHA: Is used to ensure the integrity of the SSHv2 session.
FCS_SSH_EXT.1 The TOE implements SSHv2 (telnet is disabled in the evaluated configuration).
SSHv2 sessions are limited to an administrator configurable session timeout period, and will
be rekeyed upon request from the SSH client. The key exchange methods used by the TOE is a
configurable option..
The TOE implementation of SSHv2 supports the following:
 local password-based authentication for administrative users accessing the TOE
through SSHv2, and optionally supports deferring authentication to a remote AAA
server.
 encryption algorithms, AES-CTR-128, AES-CTR-192, AES-CTR-256 to ensure
confidentiality of the session.
 hashing algorithms HMAC-SHA-1 or HMAC-SHA-96 to ensure the integrity of the
session.
FDP_IFC.1 The TOE enforces the Virtual and Distributed Switch Information Flow Control policies on
network traffic (IPv4, IPv6 and non-IP) received by the Nexus 9000 Series interfaces
including any Nexus Layer 3 interface, VLAN interfaces, Physical Layer 3 interfaces, Layer 3
Ethernet subinterfaces, Layer 3 Ethernet port-channel interfaces, Layer 3 Ethernet port-
channel subinterfaces, Tunnels, Management interfaces, Layer 2 interfaces, or Layer 2
Ethernet port-channel interfaces. Each information flow is controlled by the supervisor
(permit, drop, ignore) via the ACLs while the network traffic is mediated via the I/O network
module ports. The TOE makes an information flow decision to Permit traffic flow, Deny
traffic flow, Redirect the traffic to an interface, Deny traffic flow and log a copy of the traffic,
Disable the ingress interface, or Create DHCP binding table.
Whenever an endpoint device attempts to send network traffic to the TOE protected network,
the TOE verifies that the posture, or state, of the endpoint devices complies with the
administratively configured security policies before the endpoint device can send network
traffic to TOE protected resources. For endpoint devices that comply with the administratively
configured policies, the TOE permits the network traffic to flow to the TOE protected resource
in the network. For endpoint devices that do not comply with administratively configured
security policies, the TOE either denies the traffic flow or quarantines the Traffic flow to
access to the TOE protected network that is sufficient only for remediation. After remediation
the TOE checks the posture of the device again.
FDP_IFF.1 Whenever network traffic (both IP and non-IP traffic) is received by one of the Nexus 9000
Series interfaces, the TOE applies administratively configured information flow policies to the
traffic in the following order,
1. Port Security/IP Source Guard/Traffic Storm/DHCP Snooping/Dynamic
ARP Inspection (all applied at the same time)
2. PACL MAC ACLs
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
49
TOE SFRs How the SFR is Met
3. VRFs
4. VACL IP/MAC ACLs
5. RACL IP/MAC ACLs
The specific rules associated with each policy are, as follows:
Port Security
An administrator can configure the Nexus 9000 Series switch to allow inbound traffic from
only a restricted set of MAC addresses. This policy can be applied to Layer 2 Access Ports,
Layer 2 Trunk Ports, or Layer 2 SPAN Source Ports. The Nexus 9000 Series switch makes an
information flow decision to permit, deny, or disable the port whenever traffic is received on
the port. The TOE makes the information decision based on the following,
 The source MAC address is administratively configured as secure for the Nexus 9000
Series interface, or,
 The source MAC address is dynamically identified as secure by the TOE. A source
MAC address is considered secure if the following criteria is met,
o The Nexus 9000 Series has not reached any connection maximums;
o The source MAC address has not already been secured for another port within
the same VLAN
 And, the network traffic flow is not denied by any IP Source Guard/Traffic
Storm/DHCP Snooping/Dynamic ARP Inspection policies
 If a Nexus 9000 Series interface receives network traffic from a source MAC address
that is not identified as secure, one of the following actions takes place, the ingress
port is shutdown or the network traffic is denied.
IP Source Guard
IP Source Guard is a per-interface traffic filter that permits IP traffic only when the IP address
and MAC address of each packet matches. The IP Source Guard information flow policy is
applied to the layer 2 interfaces of the Nexus 9000 Series switch. If the TOE determines that
the IP address and MAC address of the traffic does not come from the same source the TOE
will deny the network traffic flow. The following rules are enforced by the TOE for this
information flow policy,
 Network traffic flow is permitted if the Source IP address and MAC address
combination are administratively configured as a valid combination, or,
 The Source IP address and MAC address combination were previously identified as a
valid combination by the TOE through DHCP Snooping
 And, the network traffic flow is not denied by any Port Security/Traffic Storm/
DHCP Snooping
Traffic Storm
Traffic storm control allows an administrator to monitor the levels of the incoming traffic to a
Nexus 9000 Series switch layer 2 interface over a 1-second interval. During this interval, the
traffic level, which is a percentage of the total available bandwidth of the port, is compared
with the administratively configured traffic storm control level. When the ingress traffic
reaches the traffic storm control level that is configured on the port, traffic storm control
denies the traffic flow until the interval ends. The TOE enforces the following traffic storm
rules,
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
50
TOE SFRs How the SFR is Met
 Network traffic flow is permitted if the bandwidth used by the combination of
Broadcast, Unicast, and Multicast Traffic on a given port does not exceed the
administratively configured threshold of available bandwidth for that interface port
over a one second time frame
 And, the network traffic flow is not denied by any IP Source Guard/Port
Security/DHCP Snooping/Dynamic ARP Inspection policies
 Network traffic flow is denied when the bandwidth used by the combination of
Broadcast, Unicast, and Multicast Traffic on a given port exceeds the
administratively configured threshold of available bandwidth for that interface port
over a one second time frame
DHCP Snooping
The Nexus 9000 Series switch provides the ability to validate DHCP messages received from
untrusted sources and prevent invalid DHCP messages from passing. The Nexus 9000 Series
switch builds a database from information collected by valid DHCP requests. The Nexus 9000
Series switch then uses the information obtained from the valid DHCP requests to verify the
validity of ARP requests received by untrusted sources by checking the collected IP-to-MAC
address mapping. Traffic that is identified as valid ARP requests are allowed to pass. Packets
identified as invalid ARP traffic are dropped. These services can be administratively turned on
and off. The following rules are enforced by the TOE.
 The Nexus 9000 Series switch permits DHCP traffic to flow unless any of the
following conditions occur (in which case the traffic flow is denied): The Nexus 9000
Series switch receives a DHCP response packet (such as DHCPACK, DHCPNAK, or
DHCPOFFER packet) on an untrusted interface. The Nexus 9000 Series receives a
packet on an untrusted interface, and the source MAC address and the DHCP client
hardware address do not match. This check is performed only if the DHCP snooping
MAC address verification option is turned on. The Nexus 9000 Series receives a
DHCPRELEASE or DHCPDECLINE message from an untrusted host with an entry
in the DHCP snooping binding table, and the interface information in the binding
table does not match the interface on which the message was received.
 And, the network traffic flow is not denied by any IP Source Guard/Traffic
Storm/Port Security/Dynamic ARP Inspection policies.
Dynamic ARP Inspection
Dynamic ARP Inspection ensures that only valid ARP requests and responses are relayed.
When DAI is enabled the Nexus 9000 Series switch performs these information flows:
 The TOE permits ARP traffic flows received on an untrusted Nexus 9000 Series
switch interface to the appropriate destination if a valid IP-to-MAC address binding
exists within the DHCP binding table
 And, the network traffic flow is not denied by any IP Source Guard/Traffic
Storm/DHCP Snooping/Port Security policies
 The TOE denies ARP traffic flows received on an untrusted Nexus 9000 Series
switch interface if a valid IP-to-MAC address binding does not exist within the
DHCP binding table
PACLs
When non-IP network traffic that meets an administratively configured PACL MAC ACL is
received on Layer 2 interfaces or Layer 2 Ethernet port-channel interfaces, the Nexus 9000
Series switch makes an information flow decision to either permit or deny the traffic. Traffic is
permitted or denied, as follows,
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
51
TOE SFRs How the SFR is Met
 Ingress Non-IP traffic with security attributes that match an administratively
configured PACL permit policy for non-IP traffic rule is allowed to flow, or,
 Ingress Non-IP traffic with security attributes that match an administratively
configured deny policy rule is not permitted. The PACL permit/deny polices for non-
IP traffic are comprised of a combination of information attributes and a permit/deny
operation. The information attributes that are available for the creation of PACL
permit/deny policies for non-IP traffic include: Source MAC address, Destination
MAC address, Protocol, Class of Service (COS), VLAN ID
VRFs
The Nexus 9000 Series switch provides the ability for an administrative user to configure
VRFs for incoming IP traffic. For IP traffic that is received by the Nexus 9000 Series
interfaces, the Nexus 9000 Series switch verifies which VRF the traffic is associated with and
forwards the traffic in a manner consistent with the routing table associated with the VRF.
There is no way for the user to circumvent the configured VRFs. The following VRF related
rules are applied to Network traffic.
 IP traffic with security attributes that map to a configured VRF will be forwarded
through the Nexus 9000 Series switch TOE component per the VRF routing table
VACL IP/MAC ACLs
When network traffic that meets an administratively configured VACL IP ACL is received on
VLAN interfaces, the Nexus 9000 Series switch makes an information flow decision to
forward the traffic, redirect the traffic, drop the traffic, or drop the packet and create a log of
the traffic. Traffic is forwarded, redirected, dropped, or dropped and logged, as follows,
 IP traffic with security attributes that match an administratively configured permit
policy rule is allowed to flow, or,
 IP traffic with security attributes that match an administratively configured deny
policy rule is not permitted to flow. IP traffic with security attributes that match an
administratively configured redirect policy rule is redirected to the specified
interface, or,
 IP traffic with security attributes that match an administratively configured deny-and-
log policy rule is not permitted to flow and a copy of the traffic is logged by the TOE.
The permit/deny/redirect/deny-and-log polices (defined in VACL IP/MAC ACLs) for
IP traffic described above are comprised of a combination of subject security
attributes and information attributes and a permit/deny/redirect/deny-and-log
operation. The subject attributes that are available for the creation of
permit/deny/redirect/deny-and-log policies include: vlan-ID. The information
attributes that are available for the creation of permit/deny/redirect/deny-and-log
policies include: Source IP address, Destination IP address, Source port number,
Destination port number, Protocol, ICMP message type, ICMP message code, IGMP
message type, Packet length, Precedence, DSCP Value
 Non-IP traffic with security attributes that match an administratively configured
permit policy rule is allowed to flow, or,
 Non-IP traffic with security attributes that match an administratively configured deny
policy rule is not permitted to flow. Non-IP traffic with security attributes that match
an administratively configured redirect policy rule is redirected to the specified
interface, or,
 Non-IP traffic with security attributes that match an administratively configured
deny-and-log policy rule is not permitted to flow.
The permit/deny/redirect/deny-and-log polices (defined in VACL IP/MAC ACLs) for
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
52
TOE SFRs How the SFR is Met
non-IP traffic described above are comprised of a combination of subject security
attributes and information attributes and a permit operation. The subject attributes
that are available for the creation of these permit/deny/redirect/deny-and-log policies
include: vlan-ID. The information attributes that are available for the creation of these
permit/deny/redirect/deny-and-log policies include: Source MAC address,
Destination MAC address, Protocol, Class of Service (COS), or VLAN ID
RACL IP/MAC ACLs
When network traffic that meets an administratively configured RACL or PACL IP ACL is
received on VLAN interfaces, Physical Layer 3 interfaces, Layer 3 Ethernet subinterfaces,
Layer 3 Ethernet, port-channel interfaces, Layer 3 Ethernet port-channel subinterfaces,
Tunnels, Management interfaces, Layer 2 interfaces, or Layer 2 Ethernet port-channel
interfaces, the Nexus 9000 Series switch makes an information flow decision to either permit
or deny the traffic. Traffic is permitted or denied, as follows,
 Ingress or egress IP traffic with security attributes that match an administratively
configured RACL permit policy rule is allowed to flow, or,
 Ingress or egress IP traffic with security attributes that match an administratively
configured RACL deny policy for IP traffic rule is not permitted. The RACL
permit/deny polices for IP traffic are comprised of a combination of information
attributes and a permit/deny operation. The information attributes that are available
for the creation of RACL permit/deny policies include: Source IP address,
Destination IP address, Source port number, Destination port number, Protocol,
ICMP message type, ICMP message code, IGMP message type, Packet length,
Precedence, DSCP Value
Note: RACLs are applied to both ingress and egress traffic. PACLs are applied to only ingress
traffic.
Additionally, the following explicit authorize rules are enforced on information flows.
 DHCP traffic received on interfaces configured as trusted is always allowed to pass,
or,
 ARP traffic received on interfaces configured as trusted is always allowed to pass.
The following explicit deny rules are enforced on information flows.
For IP Network Traffic Flows:
 The TOE denies IP traffic flow when the IP address and MAC address of the traffic
are not identified as a valid combination through DHCP Snooping or administrative
configuration, or,
 For IP traffic, if the security attributes do not match an administratively configured
RACL or VACL, the traffic flow is denied, or,
 If the IP traffic security attributes do not map to a configured VRF, the traffic flow is
denied
For Non-IP Network Traffic Flows:
For Non-IP traffic, if security attributes do not match an administratively configured RACL,
PACL, or VACL, the traffic flow is denied
FDP_RIP.2 The TOE ensures that packets transmitted from the TOE do not contain residual
information from data deallocated from previous packets. Packets that are not the required
length use zeros for padding. Residual data is never transmitted from the TOE. Packet
handling within memory buffers ensures new packets cannot contain portions of previous
packets. Packet buffers are used to form a packet in software. The contents of the buffers are
sent to the ethernet driver with the appropriate addresses and 64 byte length packet that needs
to be transmitted. Once the packet is sent and the buffers are deallocated, new packet data
overwrites the old. If the outgoing packet has a size less than 64 bytes then the packet is
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
53
TOE SFRs How the SFR is Met
padded so that it is 64 bytes in length. The buffers are deallocated and reused once the
operation is over. This applies to both data plane traffic and administrative session traffic.
FIA_PMG_EXT.1 The TOE supports the local definition of users with corresponding passwords. The passwords
can be composed of any combination of upper and lower case letters, numbers, and special
characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”.
FIA_UIA_EXT.1
FIA_UAU_EXT.2
FIA_UID.2
The TOE requires all users to be successfully identified and authenticated before allowing any
TSF mediated actions to be performed on behalf of that administrator user. Administrative
access to the TOE is facilitated through the TOE’s Nexus 9000 Series CLI. The TOE
mediates all administrative actions through the CLI. Once a potential administrative user
attempts to access the CLI of the TOE through either a directly connected console or remotely
through an SSHv2 connection, the TOE prompts the user for a user name and password. Only
after the administrative user presents the correct authentication credentials will access to the
TOE administrative functionality be granted. No access is allowed to the administrative
functionality of the TOE until an administrator is successfully identified and authenticated.
Authentication may be provided via either:
 Remote authentication (facilitated by RADIUS or TACACS+ (provided by the
IT environment));
 Authentication against a local database.
FIA_UAU.7 When a user enters their password at the local console or via SSH, the TOE does not echo any
of the characters of the password or any representation of the characters.
FMT_MSA.1 The TOE allows authenticated and authorized administrative users of the Nexus 9000 Series
switch TOE component to Read, write ACLs policy and the Inspection policies as well as the
attributes contained within the policy rules. The TOE allows access to the policy rules based
on the permissions defined for the user’s administratively assigned roles. Only users assigned
a role with access privileges to the policy rules have any access. All other administrative users
have no visibility into the existence of the policy rules. The TOE provides two ways to
manage the ACL and Inspection policy rules and the security attributes within the policy rules,
traditional rule configuration in which or new rules are applied and all connections are lost
during configuration and atomic configuration which allows new configurations to be applied
without losing current connections.
FMT_MSA.3 There are no default ACLs for the information flow control on the Nexus 9000 Series switch
TOE component. Without default ACLs and/or RACLS, packet flows are not allowed. This
is a restrictive default policy. The TOE does allow other policies to be created. However,
when the policies are removed, the default TOE information flow control policy is still
restrictive.
FMT_MTD.1 The TOE provides the ability for administrators of the Nexus 9000 Series to access TOE
configuration and audit data. Each of the predefined and administratively configured roles has
either read or write access to the configuration and audit data. See the SFR definition in
section 5 for details regarding the specific access available to each user role.
FMT_SMF.1 Through the administrative interface of the Nexus 9000 Series switch (CLI), the TOE
facilitates the following administrative functions:
 Configuration of RACL, PACL IP ACLs within the ACLs SFP – This functionality
allows the configuration of RACL and PACL IP ACLs by an administrative user.
 Configuration of VACL IP ACLs within the ACLs SFP – This functionality allows
the configuration of VACL IP ACLs by an administrative user.
 Configuration of PACL MAC ACLs within the ACLs SFP – This functionality
allows the configuration of PACL MAC ACLs by an administrative user.
 Configuration of VACL MAC ACLs within the ACLs SFP - This functionality
allows the configuration of VACL MAC ACLs by an administrative user.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
54
TOE SFRs How the SFR is Met
 Configuration of RBACs - This functionality allows the configuration of RBACs by
an administrative user.
 Configuration of Port Security within the ACLs SFP - This functionality allows the
configuration of Port Security by an administrative user.
 Configuration of IP Source Guard within the ACLs SFP - This functionality allows
the configuration of IP Source Guard by an administrative user.
 Configuration of Traffic Storm within the ACLs SFP - This functionality allows the
configuration of Traffic Storm by an administrative user.
 Configuration of Control Plane Policing within the Control Plane Policing/Rate
Limiting SFP - This functionality allows the configuration of Control Plan Policing
by an administrative user.
 Configuration of Rate Limiting within the Control Plane Policing/Rate Limiting SFP
- This functionality allows the configuration of Rate limiting by an administrative
user.
 Reviewing audit records – This functionality allows Nexus 9000 Series audit records
to be viewed by an administrative user.
 Configuration of Nexus 9000 Series cryptographic services - This functionality
allows the configuration of Nexus 9000 Series cryptographic by an administrative
user.
 Management of Users – This functionality allows the creation and configuration of
users and the ability to assign roles to a specific user.
 Review Nexus 9000 Series configuration - This functionality allows the
administrative user to review the Nexus 9000 Series configuration.
FMT_SMR.1 Cisco NX-OS devices uses role-based access control (RBAC) for authorization. To enable
NX-OS to be administered by the same TACACS+ servers that administer other Cisco
IOS/IOS-XE devices, an authorized administrator can map the privilege levels configured on
TACACS+ servers to user roles configured on Cisco NX-OS devices by using the 'feature
privilege' command.
The Nexus 9000 Series switch supports the following predefined roles:
 network-admin – This role is a super administrative role. This role has read and write
privileges for any configuration item on the Nexus 9000 Series switch.
 network-operator - This role has read access to the entire Cisco NX-OS device.
The permissions associated with the predefined administrative roles cannot be modified. The
TOE does allow, however, for the configuration of custom administrative roles on the Nexus
9000 Series switch. Access for the custom roles can be defined per command, feature (a
group of command, or feature group (a collection of features).
The permissions associated with the predefined administrative roles cannot be modified.
FPT_APW_EXT.1 The TOE prevents reading of cryptographic passwords. AES password encryption can be
configured by an authorized administrator to encrypt stored passwords using the "feature
password encryption aes" command.
In this manner, the TOE ensures that plaintext user passwords will not be disclosed even to
administrators.
FPT_STM.1 The Nexus 9000 Series switch can provide hardware based timestamp that are used to provide
that timestamp in audit records. The TOE provides the option to either use the internally
generated time stamps or at the discretion of the administrator use an external time server to
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
55
TOE SFRs How the SFR is Met
provide the time stamp.
The TOE provides a source of date and time information for the router, used in audit
timestamps. This function can only be accessed from within the configuration exec mode via
the privileged mode of operation of the TOE. The clock function is reliant on the system clock
provided by the underlying hardware.
FPT_TST_EXT.1 The TOE runs a suite of self-tests during initial start-up to verify its correct operation. Refer
to the FIPS Security Policy for available options and management of the cryptographic self-
test.
For testing of the TSF, the TOE automatically runs checks and tests at startup and during
resets to ensure the TOE is operating correctly. Refer to the Guidance documentation for
installation configuration settings and information and troubling shooting if issues are
identified.
When the system is booted up in FIPS mode, the FIPS power-up self-tests run on the
supervisor and line card modules. If any of these FIPS self-tests fail, the whole system is
moved to the FIPS error state. In this state, as per the FIPS requirement, all cryptographic
keys are deleted, and all line cards are shut down. This mode is exclusively meant for
debugging purposes.
Once the switch is in the FIPS error state, any reload of a line card moves it to the failure state.
To move the switch back to FIPS mode, it has to be rebooted. However, once the switch is in
FIPS mode, any power-up self-test failure on a subsequent line card reload or insertion affects
only that line card, and only the corresponding line card is moved to the failure state.
If any of the self-tests fail, the TOE transitions into an error state. In the error state, all secure
data transmission is halted and the TOE outputs status information indicating the failure.
The following cryptographically self-tests tests are run:
 AES Known Answer Test (Separate encrypt and decrypt)
 AES-CCM Known Answer Test (Separate encrypt and decrypt)
 AES-GCM Known Answer Test (Separate encrypt and decrypt)
 AES-CMAC Known Answer Test
 AES-XTS Known Answer Test (Separate encrypt and decrypt)
 DSA Sign/Verify Test o FIPS 186-3 ECDSA Sign/Verify Test
 HMAC Known Answer Tests
o HMAC-SHA1 Known Answer Test
o HMAC-SHA224 Known Answer Test
o HMAC-SHA256 Known Answer Test
o HMAC-SHA384 Known Answer Test
o HMAC-SHA512 Known Answer Test
 KAS ECC Primitive “Z” KAT
 RSA Known Answer Test (Separate sign and verify)
 SHA-1 Known Answer Test
 Software Integrity Test (HMAC-SHA1)
 Conditional tests
o Pairwise consistency tests for RSA, DSA, and ECDSA
FTA_SSL.4 An administrator is able to exit out of both local and remote administrative sessions.
FTA_TAB.1 The TOE displays a customizable login banner on the local and remote CLI management
interface prior to allowing any administrative access to the TOE.
FTP_TRP.1 All remote administrative communications take place over a secure encrypted SSH session.
The SSH session is encrypted using AES encryption. A remote authorized administrator is
able to initiate SSH communications with the TOE.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
56
6.2 TOE Bypass and interference/logical tampering Protection Measures
The Nexus 9000 Series switch is a hardware appliance untrusted subjects. All administration and
configuration operations are performed within the physical boundary of the TOE. Also, all TSP
enforcement functions must be invoked and succeed prior to functions within the TSC
proceeding.
The TOE has been designed so that all locally maintained TSF data can only be manipulated via
the secured management interfaces, including CLI interface. There are no undocumented
interfaces for managing the product. The CLI interface achieves a trusted path via SSH public
key authentication and is recommended for remote authorized administrator.
All sub-components included in the TOE hardware rely on the main Nexus 9000 Series switch
for power, memory management, and access control. In order to access any portion of the Nexus
9000 switch, the Identification & Authentication mechanisms of the Nexus 9000 Series switch
must be invoked and succeed.
No processes outside of the TOE are allowed direct access to any TOE memory. The TOE only
accepts traffic through legitimate TOE interfaces. None of these interfaces provide any access to
internal TOE resources.
The Nexus 9000 Series switch provides a secure domain for its operation. Each component has
its own resources that other components within the same Nexus 9000 Series switch platform are
not able to affect.
There are no unmediated traffic flows into or out of either component of the TOE (Nexus 9000
Series switch). The information flow policies identified in the SFRs are applied to all traffic
received and sent by the Nexus 9000 Series TOE component. Both communication types
including data plane communication, and control plane communications are mediated by the
TOE. Control plane communications refer to administrative traffic used to control the operation
of the TOE. There is no opportunity for unaccounted traffic flows to flow into or out of the
TOE.
The Nexus 9000 Series switch provides a secure domain for each VLAN to operate within. Each
VLAN has its own forwarding plane resources that other VLANs within the same Nexus 9000
Series switch TOE component are not able to affect.
The Nexus 9000 Series switch provides a secure domain for each VRF to operate within. Each
VRF has its own resources that other VRFs within the same Nexus 9000 Series switch TOE
component are not able to affect.
The TOE includes the NX-OS software which is installed on the Nexus 9000 series switch
hardware. The NX-OS software is resident within the TOE hardware and is protected by the
mechanisms described above.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
57
This design, combined with the fact that only an administrative user with the appropriate role
may access the TOE security functions, provides a distinct protected domain for the TOE that is
logically protected from interference and is not bypassable.
6.3 Rationale for requirements/TOE Objectives
The security requirements are derived according to the general model presented in Part 1 of the
Common Criteria. Specifically, the tables below illustrate the mapping between the security
requirements and the security objectives and the relationship between the threats, policies and IT
security objectives. This section identifies each Security Functional Requirement identified in
Section 5, the TOE security objective(s) identified in Section 4 that addresses it, Table 25 and
Table 26 provide the mapping and rationale for inclusion of each SFR in this ST.
6.4 Rationale for TOE Security Objectives
Table 25: SFR/Objectives Mappings
O.DATA_FLOW_CONTROL
O.DISPLAY_BANNER
O.PROTECTED_COMMUNICATIONS
O.RESIDUAL_INFORMATION_CLEARING
O.SYSTEM_MONITORING
O.TOE_ADMINISTRATION
O.TSF_SELF_TEST
FAU_GEN.1 X
FAU_GEN.2 X
FAU_STG.1 X
FCS_CKM.1 X
FCS_CKM.4 X
FCS_COP.1 X
FCS_SSH_EXT.1 X
FDP_IFC.1 X
FDP_IFF.1 X
FDP_RIP.2 X
FIA_PMG_EXT.1 X
FIA_UIA_EXT.1 X
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
58
O.DATA_FLOW_CONTROL
O.DISPLAY_BANNER
O.PROTECTED_COMMUNICATIONS
O.RESIDUAL_INFORMATION_CLEARING
O.SYSTEM_MONITORING
O.TOE_ADMINISTRATION
O.TSF_SELF_TEST
FIA_UID.2 X
FIA_UAU_EXT.2 X
FIA_UAU.7 X
FMT_MSA.1 X
FMT_MSA.3 X X
FMT_MTD.1 X
FMT_SMF.1 X
FMT_SMR.1 X
FPT_APW_EXT.1 X
FPT_STM.1 X
FPT_TST_EXT.1 X
FTA_SSL.4 X
FTA_TAB.1 X
FTP_TRP.1 X
The inspection of Table 25 shows that:
 Each SFR traces back to at least one security objective;
 Each security objective for the TOE has at least one SFR tracing to it.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
59
Justification of SFR tracing
6.4.1.1
The justification demonstrates that the SFRs address all security objectives of the TOE.
Table 26 SFR Tracing Justification
Objective Rationale
O.DATA_FLOW_CONTROL The SFRs, FDP_IFC.1, and FDP_IFF.1 meet this objective by ensuring the
TOE mediates the flow of all information between clients and servers
located on internal and external networks governed by the TOE. The TOE
is required to identify the subject attributes and information attributes
necessary to enforce the Virtual and Distributed Switch Information Flow
Control SFP. The policy is defined by rules defining the conditions for
which information is permitted or denied to flow. The SFR, FMT_MSA.3,
ensures the TOE provides the capability for administrators to define default
deny rules, though the default policy for the information flow control
security rules is restrictive where no explicit rules exist until created and
applied by an Authorized Administrator.
The TOE enforces information flow policies on network traffic (both IPv4
and v6 and non-IP) received by the Nexus 9000 Series interfaces including
any Nexus Layer 3 interface, VLAN interfaces, Physical Layer 3 interfaces,
Layer 3 Ethernet subinterfaces, Layer 3 Ethernet port-channel interfaces,
Layer 3 Ethernet port-channel subinterfaces, Tunnels, Management
interfaces, Layer 2 interfaces, or Layer 2 Ethernet port-channel interfaces.
The TOE makes an information flow decision to Permit traffic flow, Deny
traffic flow, Redirect the traffic to an interface, Deny traffic flow and log a
copy of the traffic, Disable the ingress interface, or Create DHCP binding
table.
Whenever an endpoint device attempts to send network traffic to the TOE
protected network, the TOE verifies that the posture, or state, of the
endpoint devices complies with the administratively configured security
policies before the endpoint device can send network traffic to TOE
protected resources. For endpoint devices that comply with the
administratively configured policies, the TOE permits the network traffic to
flow to the TOE protected resource in the network. For endpoint devices
that do not comply with administratively configured security policies, the
TOE either denies the traffic flow or quarantines the Traffic flow to access
to the TOE protected network that is sufficient only for remediation. After
remediation the TOE checks the posture of the device again.
O.DISPLAY_BANNER The SFR, FTA_TAB.1 meets this objective by displaying an advisory
notice and consent warning message regarding unauthorized use of the
TOE.
O.PROTECTED_COMMUNICAT
IONS
The SFRs, FCS_CKM.1, FCS_CKM.4, FCS_COP.1, FCS_SSH_EXT.1,
FTP_TRP.1 meet this objective by ensuring the communications between
the TOE and endpoints are secure by implementing the encryption
protocols as defined in the SFRs and as specified by the RFCs.
O.RESIDUAL_INFORMATION_
CLEARING
The SFR, FDP_RIP.2 meets this objective by ensuring no left over user
data from the previous transmission is included in the network traffic.
O.SYSTEM_MONITORING The SFRs, FAU_GEN.1, FAU_GEN.2, FAU_STG.1, FPT_STM.1 meet
this objective by auditing actions on the TOE. The audit records identify
the user associated with the action/event, whether the action/event was
successful or failed, the type of action/event, and the date/time the
action/event occurred. The TOE writes audit events to NVRAM, DRAM
and flash. All log locations are protected from modification and deletion.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
60
Objective Rationale
Logs can only be cleared by an authorized administrator through the CLI.
O.TOE_ADMINISTRATION The SFRs, FIA_UIA_EXT.1, FIA_PMG_EXT.1, FIA_UAU_EXT.2,
FIA_UID.2, FIA_UAU.7, FMT_MSA.1, FMT_MSA.3, FMT_MTD.1,
FMT_SMF.1, FMT_SMR.1, FPT_APW_EXT.1, FTA_SSL.4 meet this
objective by ensuring the TOE supports a password-based authentication
mechanism with password complexity enforcement such as, strong
passwords, password life-time constraints, providing current password
when changing the password, obscured password feedback when logging
in, and passwords are not stored in plaintext. The objective is further met
by ensuring restrictive default values are enforced on the SFPs
(authorization and flow control), that only Authorized Administrators can
override the default values. The TOE provides the management and
configuration features to securely manage the TOE and that those functions
are restricted to the Authorized Administrator. In addition, the TOE
provides the ability for an Authorized Administrator to exit or logoff an
administrator session.
O.TSF_SELF_TEST The SFR, FPT_TST_EXT.1 meets this objective by performing self-test to
ensure the TOE is operating correctly and all functions are available and
enforced.
6.5 Security objectives rationale
The security objectives rationale shows how the security objectives correspond to assumptions,
threats, and organizational security policies and provide a justification of that tracing.
Tracing of security objectives to SPD
6.5.1
The tracing shows how the security objectives OT.* and OE.* trace back to assumptions A.*,
threats T.*, and organizational security policies OSP.* defined by the SPD.
Table 27 Tracing of security objectives to SPD
A.NO_GENERAL_PURPOSE
A.PHYSICAL
A.SYSLOG
A.TRUSTED_ADMIN
T.
NET_TRAFFIC
T.TSF_FAILURE
T.UNAUTHORIZED_ACCESS
T.UNDETECTED_ACTIONS
T.USER_DATA_REUSE
P.ACCESS
BANNER
O.DATA_FLOW_CONTROL X
O.DISPLAY_BANNER X
O.PROTECTED_COMMUNICATIONS X
O.RESIDUAL_INFORMATION_CLEARING X
O.SYSTEM_MONITORING X
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
61
A.NO_GENERAL_PURPOSE
A.PHYSICAL
A.SYSLOG
A.TRUSTED_ADMIN
T.
NET_TRAFFIC
T.TSF_FAILURE
T.UNAUTHORIZED_ACCESS
T.UNDETECTED_ACTIONS
T.USER_DATA_REUSE
P.ACCESS
BANNER
O.TOE_ADMINISTRATION X
O.TSF_SELF_TEST X
OE.NO_GENERAL_PURPOSE X
OE.PHYSICAL X
OE.SYSLOG X
OE.TRUSTED_ADMIN X
Justification of tracing
6.5.2
The justification demonstrates that the tracing of the security objectives to assumptions, threats,
and OSPs is effective and all the given assumptions are upheld, all the given threats are
countered, and all the given OSPs are enforced.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
62
Tracing of threats and OSPs
6.5.2.1
Table 28 Threat and OSP Rationale
Objective Rationale
O.DATA_FLOW_CONTROL This security objective is necessary to counter the threat T.NET_TRAFFIC to
ensure that information flow control policies are enforced to limit access to
an attacker (unauthorized user) sending malicious traffic through/to the TOE.
O.DISPLAY_BANNER This security objective is necessary to address the Organizational Security
Policy P.ACCESS_BANNER to ensure an advisory notice and consent
warning message regarding unauthorized use of the TOE is displayed before
the session is established.
O.PROTECTED_COMMUNICA
TIONS
This security objective is necessary to counter the threat:
T.UNAUTHORIZED_ACCESS to ensure remote communications with the
TOE are not compromised. O.PROTECTED_COMMUNICATIONS ensures
that the administrator remote communications path is encrypted; therefore,
providing a secured remote communications session to the TOE CLI
preventing unauthorized users from viewing credentials or other TSF data
passed in the session communications.
O.RESIDUAL_INFORMATION_
CLEARING
This security objective is necessary to counter the threat
T.USER_DATA_REUSE so that data traversing the TOE could inadvertently
be sent to a user other than that intended by the sender of the original
network traffic.
O.SYSTEM_MONITORING This security objective is necessary to counter the
T.UNDETECTED_ACTIONS to ensure activity is monitored so the security
of the TOE is not compromised.
O.TOE_ADMINISTR
ATION
This security objective is necessary to counter the threat:
T.UNAUTHORIZED_ACCESS to ensure administrators must identify and
authenticate themselves before gaining access to the TOE's management
interface.
O.TSF_SELF_TEST This security objective is necessary to counter the threat T.TSF_FAILURE to
ensure failure of mechanisms do not lead to a compromise in the TSF.
Tracing of assumptions
6.5.2.2
Table 29: Threat/Policies/TOE Objectives Rationale
Environment Objective Rationale
OE.NO_GENERAL_PURPOSE This security objective is necessary to address the assumption
A.NO_GENERAL_PURPOSE by ensuring there are no general-purpose
computing capabilities (e.g., the ability to execute arbitrary code or
applications) capabilities on the TOE.
OE.PHYSICAL This security objective is necessary to address the assumption
A.PHYSICAL by ensuring the TOE and the data it contains is physically
protected from unauthorized access.
OE.TRUSTED_ADMIN This security objective is necessary to address the assumption A.TRU
STED_ADMIN by ensuring the administrators are non-hostile and follow
all administrator guidance.
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
63
7 ANNEX A: KEY ZEROIZATION
7.1 Key Zeroization
The following table describes the FIPS 140-2 key zeroization referenced by FCS_CKM.4
provided by the TOE.
Table 30: TOE Key Zeroization
Name Description Zeroization
Diffie-Hellman
Shared Secret
The value is zeroized after it has been given back to the
consuming operation. The value is overwritten by 0’s.
Automatically after
completion of DH
exchange.
Overwritten with: 0x00
Diffie Hellman
private exponent
The function returns the value to the RP and then calls the
function to perform the zeroization of the generated key pair
(p_dh_kepair) and then calls the standard Linux free (without the
poisoning). These values are automatically zeroized after
generation and once the value has been provided back to the
actual consumer.
Zeroized upon completion
of DH exchange.
Overwritten with: 0x00
RADIUS secret The function calls aaa_free_secret, which uses the poisoned free
operation to zeroize the memory from the secret structure by
overwriting the space with 0x0d and releasing the memory.
Zeroized using the
following command:
# no radius-server key
Overwritten with: 0x0d
TACACS+ secret The function calls aaa_free_secret, which uses the poisoned free
operation to zeroize the memory from the secret structure by
overwriting the space with 0x0d and releasing the memory.
Zeroized using the
following command:
# no tacacs-server key
Overwritten with: 0x0d
SSH Private Key Once the function has completed the operations requiring the
RSA key object, the module over writes the entire object (no
matter its contents) using memset. This overwrites the key with
all 0’s.
Zeroized using the
following command:
# crypto key zeroize rsa
Overwritten with: 0x00
SSH Session Key The results zeroized using the free operation with the poisoning
mechanism to overwrite the values with 0x00. This is called by
the ssh_close function when a session is ended.
Automatically when the
SSH session is terminated.
Overwritten with: 0x00
Cisco Nexus 9000 Switches in standalone mode with Nexus 2000 Fabric Extenders Security Target
64
8 ANNEX B: REFERENCES
The following documentation was used to prepare this ST:
Table 31: References
Identifier Description
[CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction
and general model, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-001
[CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2: Security
functional components, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-
002
[CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3: Security
assurance components, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-
003
[CEM] Common Methodology for Information Technology Security Evaluation – Evaluation
Methodology, dated September 2012, version 3.1, Revision 4, CCMB-2012-009-004
[NDPP] Protection Profile for Network Devices, version 1.1, June 8, 2012
[800-38A] NIST Special Publication 800-38A Recommendation for Block 2001 Edition
Recommendation for Block Cipher Modes of Operation Methods and Techniques December
2001
[800-56A] NIST Special Publication 800-56A, March, 2007
Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography (Revised)
[800-56B] NIST Special Publication 800-56B Recommendation for Pair-Wise, August 2009
Key Establishment Schemes Using Integer Factorization Cryptography
[FIPS 140-2] FIPS PUB 140-2 Federal Information Processing Standards Publication
Security Requirements for Cryptographic Modules May 25, 2001
[FIPS PUB 186-2] FIPS PUB 186-2 Federal Information Processing Standards Publication 2000 January 27
[FIPS PUB 186-3] FIPS PUB 186-3 Federal Information Processing Standards Publication Digital Signature
Standard (DSS) June, 2009
[FIPS PUB 198-1] Federal Information Processing Standards Publication The Keyed-Hash Message
Authentication Code (HMAC) July 2008
[FIPS PUB 180-3] FIPS PUB 180-3 Federal Information Processing Standards Publication Secure Hash
Standard (SHS) October 2008