Ciena 5400 Series Packet Optical Platform

Transcription

1 Ciena 5400 Series Packet Optical Platform Security Target ST Version: 1.0 January 11, 2016 Ciena Corporation 7035 Ridge Road Hanover, MD Prepared By: Cyber Assurance Testing Laboratory 900 Elkridge Landing Road, Suite 100 Linthicum, MD 21090

2 Table of Contents 1 Security Target Introduction ST Reference ST Identification Document Organization Terminology Acronyms TOE Reference TOE Overview TOE Type TOE Description Evaluated Components of the TOE Components and Applications in the Operational Environment Excluded from the TOE Not Installed Installed but Requires a Separate License Installed But Not Part of the TSF Physical Boundary Software Logical Boundary Security Audit Cryptographic Support User Data Protection Identification and Authentication Security Management Protection of the TSF TOE Access Trusted Path/Channels Conformance Claims CC Version CC Part 2 Conformance Claims P a g e

3 3.3 CC Part 3 Conformance Claims PP Claims Package Claims Package Name Conformant or Package Name Augmented Conformance Claim Rationale Security Problem Definition Threats Organizational Security Policies Assumptions Security Objectives TOE Security Objectives Security Objectives for the Operational Environment Security Problem Definition Rationale Extended Components Definition Extended Security Functional Requirements Extended Security Assurance Requirements Security Functional Requirements Conventions Security Functional Requirements Summary Security Functional Requirements Class FAU: Security Audit Class FCS: Cryptographic Support Class FDP: User Data Protection Class FIA: Identification and Authentication Class FMT: Security Management Class FPT: Protection of the TSF Class FTA: TOE Access Class FTP: Trusted Path/Channels Statement of Security Functional Requirements Consistency Security Assurance Requirements Class ADV: Development P a g e

4 7.1.1 Basic Functional Specification (ADV_FSP.1) Class AGD: Guidance Documents Operational User Guidance (AGD_OPE.1) Preparative Procedures (AGD_PRE.1) Class ALC: Life-cycle Support Labeling of the TOE (ALC_CMC.1) TOE CM coverage (ALC_CMS.1) Class ATE: Tests Independent testing - conformance (ATE_IND.1) Class AVA: Vulnerability Assessment Vulnerability Survey (AVA_VAN.1) TOE Summary Specification Security Audit FAU_GEN.1: FAU_GEN.2: FAU_STG_EXT.1: Cryptographic Support FCS_CKM.1: FCS_CKM_EXT.4: FCS_COP.1(1): FCS_COP.1(2): FCS_COP.1(3): FCS_COP.1(4): FCS_RBG_EXT.1: FCS_SSH_EXT.1: FCS_TLS_EXT.1: User Data Protection FDP_RIP.2: Identification and Authentication FIA_PMG_EXT.1: FIA_UAU_EXT.2: P a g e

5 8.4.3 FIA_UAU.7: FIA_UIA_EXT.1: Security Management FMT_MTD.1: FMT_SMF.1: FMT_SMR.2: Protection of the TSF FPT_APW_EXT.1: FPT_SKP_EXT.1: FPT_STM.1: FPT_TST_EXT.1: FPT_TUD_EXT.1: TOE Access FTA_SSL_EXT.1: FTA_SSL.3: FTA_SSL.4: FTA_TAB.1: Trusted Path/Channels FTP_ITC.1: FTP_TRP.1: Table of Figures Figure 1-1: TOE Boundary... 9 Table of Tables Table 1-1: Customer Specific Terminology... 7 Table 1-2: CC Specific Terminology... 7 Table 1-3: Acronym Definition... 8 Table 2-2: Evaluated Components of the Operational Environment P a g e

6 Table 4-1: TOE Threats Table 4-2: TOE Organization Security Policies Table 4-3: TOE Assumptions Table 4-4: TOE Objectives Table 4-5: TOE Operational Environment Objectives Table 6-1: Security Functional Requirements for the TOE Table 6-2: Auditable Events Table 8-1: Audit Events Table 8-2: TSF Management Functions P a g e

7 1 Security Target Introduction This chapter presents the Security Target (ST) identification information and an overview. An ST contains the Information Technology (IT) security requirements of an identified Target of Evaluation (TOE) and specifies the functional and assurance security measures offered by the TOE. 1.1 ST Reference This section provides information needed to identify and control this ST and its Target of Evaluation ST Identification ST Title: Security Target ST Version: 1.0 ST Publication Date: January 11, 2016 ST Author: Booz Allen Hamilton Document Organization Chapter 1 of this document provides identifying information for the ST and TOE as well as a brief description of the TOE and its associated TOE type. Chapter 2 describes the TOE in terms of its physical boundary, logical boundary, exclusions, and dependent Operational Environment components. Chapter 3 describes the conformance claims made by this ST. Chapter 4 describes the threats, assumptions, objectives, and organizational security policies that apply to the TOE. Chapter 5 defines extended Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs). Chapter 6 describes the SFRs that are to be implemented by the TSF. Chapter 7 describes the SARs that will be used to evaluate the TOE. Chapter 8 provides the TOE Summary Specification, which describes how the SFRs that are defined for the TOE are implemented by the TSF. 6 P a g e

8 1.1.3 Terminology This section defines the terminology used throughout this ST. The terminology used throughout this ST is defined in Table 1-1 and 1-2. These tables are to be used by the reader as a quick reference guide for terminology definitions. Term Account Administrator MCLI Superuser TL1 [Management Interface] Definition Account Administrator, or AA, is the highest administrative privilege available on the TOE s TL1 interface. All TSF-relevant functionality that can be managed from the TL1 interface can be performed by the AA. This role is an Authorized Administrator for the TL1 interface. Management Command Line Interface (MCLI) is a command shell interface that can be used to administer the TOE locally or remotely using SSH. This interface is primarily used for functions that are performed during initial setup/deployment of the TOE. Superuser is the only administrative privilege available on the TOE s MCLI. All TSFrelevant functionality that can be managed from the MCLI can be performed by the superuser. This role is an Authorized Administrator for the MCLI. The Transaction Language 1 (TL1) management interface is a TL1-compatible command shell interface that can be used to administer the TOE locally or remotely using SSH. This interface is distinct from the MCLI and is used to perform functions that may be modified during ongoing administration of the TOE. Table 1-1: Customer Specific Terminology Term Authorized Administrator Entropy Security Administrator Trusted Channel Trusted Path Definition The claimed Protection Profile defines an Authorized Administrator role that is authorized to manage the TOE and its data. A string of quasi-random data that is generated by unpredictable physical and/or logical phenomena in a computer and is used in the generation of random numbers. Synonymous with Authorized Administrator. An encrypted connection between the TOE and a trusted remote server. An encrypted connection between a remote administrative interface and the TOE. Table 1-2: CC Specific Terminology Acronyms The acronyms used throughout this ST are defined in Table 1-3. This table is to be used by the reader as a quick reference guide for acronym definitions. Acronym AES CAVP CBC CLI CSP DHE DRBG HMAC Definition Advanced Encryption Standard Cryptographic Algorithm Validation Program Cipher Block Chaining Command Line Interface Critical Security Parameter Diffie-Hellman Deterministic Random Bit Generator Hashed Message Authentication Code 7 P a g e

9 MCLI MPLS NDPP NTP OSI OTN RSA SDH SFTP SHA SHS SONET SSH TL1 Management Command Line Interface Multiprotocol Label Switching Network Device Protection Profile Network Time Protocol Open Systems Interconnection Optical Transport Network Rivest Shamir Adelman (encryption algorithm) Synchronous Digital Hierarchy Secure File Transfer Protocol Secure Hash Algorithm Secure Hash Standard Synchronous Optical Networking Secure Shell Transaction Language One Table 1-3: Acronym Definition 1.2 TOE Reference The TOE is the, which is a packet-optical switching platform. It is also known as the Ciena 5400 Series. The 5400 Series contains two models: the Ciena 5430 and Ciena Each of these devices runs Linux kernel version and provides identical security functionality to one another. 1.3 TOE Overview The is a family of hardware devices that provides OSI Layer 2 network traffic management services. It is a packet-optical switching platform that enables users to direct traffic to designated ports, giving them control of network availability for specific services. The system features an agnostic switch fabric that is capable of switching SONET/SDH, OTN, and Ethernet/MPLS networks. The Ciena 5400 Series supports OC-48/STM-16 and OC-192/STM-64, OTU1/2/3/4, and 1/10/40/100G Ethernet interfaces to provide up to 15 Tbps switching capacity using a combination of: Up to 30 line modules on the 5430 chassis Up to 10 line modules on the 5410 chassis The Ciena 5400 Series is a family of standalone single hardware appliances that run Linux. The Target of Evaluation (TOE) is the general network device security functions that are provided by the Ciena 5400 Series, such as security auditing, trusted communications, security management, and identification and authentication. The appliances provide command line and TL1 interfaces to the TOE s security functionality as well as the switching behavior that is beyond the scope of the claimed Protection Profile. 8 P a g e

10 Syslog Server TLS NTP Server (optional) TOE Operational Environment (TSFI) Operational Environment (non-tsfi) TOE Network 1 Network Local Serial or Ethernet SSH Management Workstation SFTP Server Figure 1-1: TOE Boundary In practice, the TOE will be deployed to perform OSI Layer 2 switching functions and will be connected to a number of other network traffic infrastructure equipment. This has not been depicted in detail because this capability is out of scope of the TOE from a security functional perspective. 1.4 TOE Type The TOE type for the Ciena 5400 Series is Network Device. The TOE is a hardware appliance whose primary functionality is related to the handling of network traffic. The NDPP defines a network device as a device composed of hardware and software that is connected to the network and has an infrastructure role in the overall enterprise. Additionally, the NDPP says that example devices that fit this definition include routers, firewalls, intrusion detection systems, audit servers, and switches that have Layer 3 functionality. The TOE is a switch that has Layer 2 and Layer 3 functionality. The TOE type is justified because the TOE provides an infrastructure role in internetworking of different network environments across an enterprise. 9 P a g e

11 2 TOE Description This section provides a description of the TOE in its evaluated configuration. This includes the physical and logical boundaries of the TOE. 2.1 Evaluated Components of the TOE The TOE is the. This is a family of products that contains the following hardware models: 10 P a g e Ciena 5410 Packet Optical Platform Ciena 5430 Packet Optical Platform Each of these hardware models is a standalone network appliance. 2.2 Components and Applications in the Operational Environment The following table lists components and applications in the environment that the TOE relies upon in order to function properly: Component Management Workstation NTP Server Syslog Server Update Server Definition Any general-purpose computer that is used by an administrator to manage the TOE. The TOE can be managed remotely, in which case the management workstation requires an SSH client, or locally, in which case the management workstation must be physically connected to the TOE using the serial port and must use a terminal emulator that is compatible with serial communications. A system that provides an authoritative and reliable source of time using network time protocol (NTP). A general-purpose computer that is running a syslog server, which is used to store audit data generated by the TOE. A server running the secure file transfer protocol (SFTP) that is used as a location for storing product updates that can be transferred to the TOE. Table 2-1: Evaluated Components of the Operational Environment In the evaluated configuration, an NTP server is optional, as the TOE also provides the ability to maintain system time using its internal hardware clock. 2.3 Excluded from the TOE The following optional products, components, and/or applications can be integrated with the TOE but are not included in the evaluated configuration. They provide no added security related functionality for the evaluated product. They are separated into three categories: not installed, installed but requires a separate license, and installed but not part of the TSF Not Installed There are no optional components that are omitted from the installation process Installed but Requires a Separate License No components are installed that require a separate license.

12 2.3.3 Installed But Not Part of the TSF This section contains functionality or components that are part of the purchased product but are not part of the TSF relevant functionality that is being evaluated as the TOE. 11 P a g e CORBA administrative interface by default, the CORBA administrative interface that can be used to interact with the TSF does not provide security. In the evaluated configuration, it will be disabled following initial setup so that all remote administrative communications use SSH. FTP, HTTP, TELNET, TELNET_TLS, SNMP these protocols must be locked (disabled) in the evaluated configuration. Additionally, the TOE includes a number of functions that are outside the scope of the claimed Protection Profile. These functions are not part of the TSF because there are no SFRs that apply to them. 2.4 Physical Boundary The physical boundary of the TOE includes the Ciena 5410 and 5430 Packet Optical Platform hardware appliances and the software that runs on them. The TOE includes a Freescale MPC8572 processor which is used to provide entropy to the software deterministic random bit generation function. The TOE guidance documentation that is considered to be part of the TOE can be found in the Common Criteria-specific guidance for the, which is delivered on physical media to customers purchasing the equipment and is also made available on the Ciena website Software The operating system used by the TOE is Linux, kernel version The TOE is managed using a combination of a management command-line interface (MCLI) and Transaction Language 1 (TL1) interface. Both of these interfaces can be used for either local administration or secure remote administration using SSH. 2.5 Logical Boundary 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. User Data Protection 4. Identification and Authentication 5. Security Management 6. Protection of the TSF 7. TOE Access 8. Trusted Path/Channels Security Audit The TOE provides extensive auditing capabilities. The security log includes detailed records of all user activity including events related to authentication, management, and session termination. Establishment, termination, and failure to establish trusted communications is also audited. The TOE generates audit logs

13 using syslog, and the collected audit data can be transmitted securely to a remote server in the Operational Environment. The TOE records, for each audited event, the date and time of the event, the type of event, the subject s claimed identity, and the outcome (success or failure) of that event. Depending on the specific type of event, additional data may be included in the audit record Cryptographic Support The TOE provides cryptography in support of SSH and TLS trusted communications for remote administration, remote storage of audit data, and secure download of TOE updates. Asymmetric keys used by the TSF are generated in accordance with NIST SP The TOE uses CAVP-validated cryptographic algorithms (certificates AES #3753, RSA #1930, SHS #3124, HMAC #2456, DRBG #1029) to ensure that appropriately strong cryptographic algorithms are used for these trusted communications. The TOE collects entropy from a third-party hardware source contained within the device to ensure sufficient randomness for secure key generation User Data Protection The TOE ensures that packets transmitted from the TOE do not contain residual information from previous packets. Any data that terminates before the minimum packet size is reached is padded with zeroes Identification and Authentication All users must be identified and authenticated to the TOE via locally-defined username and password or username and SSH public key before being allowed to perform any actions on the TOE, except viewing a banner. The TOE provides complexity rules that ensure that user-defined passwords will meet a minimum security strength through the set of supported characters and configurable minimum password length. As part of connecting to the TOE locally, using the management workstation, password data will be obfuscated as it is being input Security Management The product maintains several pre-defined roles for the TL1 administrative interface. Of these, the Account Administrator (AA) is the only administrative role that has the ability to manage the TSF, so it is the only TL1 role that is within the scope of the TOE. The TOE also provides a separate superuser role that is used exclusively for managing the TSF using the MCLI. The superuser and AA roles are analogous to the role of Security Administrator as defined by the NDPP. The remaining roles perform network management related functionality that is not considered to be part of the TSF Protection of the TSF The TOE is expected to ensure the security and integrity of all data that is stored locally and accessed remotely. The TOE stores passwords in an obfuscated format. The cryptographic module prevents the unauthorized disclosure of secret cryptographic data, and administrative passwords are hashed using SHA-256. The TOE maintains system time with either its local hardware clock or optionally with an NTP 12 P a g e

14 server synchronization. TOE software updates are acquired using SFTP and initiated using the MCLI. Software updates are digitally signed to ensure their integrity. The TSF also validates its correctness through the use of self-tests for both cryptographic functionality and integrity of the system software TOE Access The TOE can terminate inactive sessions after an administrator-configurable time period. The TOE also allows users to terminate their own interactive session. Once a session has been terminated the TOE requires the user to re-authenticate to establish a new session. The TOE can also display a configurable banner on both the MCLI and TL1 interfaces that is displayed prior to use of any other TSF Trusted Path/Channels The TOE establishes a trusted path to the TOE using SSH for MCLI and TL1 administration. The TOE also establishes trusted channels for sending audit data to a remote syslog server using TLS and for downloading software updates and manually transferring audit records using SFTP (FTP over SSH). 13 P a g e

15 3 Conformance Claims 3.1 CC Version This ST is compliant with Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 4 September CC Part 2 Conformance Claims This ST and Target of Evaluation (TOE) is Part 2 extended to include all applicable NIAP and International interpretations through 11 January CC Part 3 Conformance Claims This ST and Target of Evaluation (TOE) is Part 3 conformant to include all applicable NIAP and International interpretations through 11 January PP Claims This ST claims exact conformance to the following Protection Profile: Protection Profile for Network Devices, version 1.1 [NDPP] This PP claim also includes the NDPP Errata #3 that provides updates and clarifications to the NDPP. 3.5 Package Claims The TOE claims exact conformance to the NDPP, version 1.1. The TOE claims following optional SFRs that are defined in the appendices of the claimed PP: FCS_SSH_EXT.1 FCS_TLS_EXT.1 This does not violate the notion of exact conformance because the PP specifically indicates these as allowable options and provides both the ST author and evaluation laboratory with instructions on how these claims are to be documented and evaluated. 3.6 Package Name Conformant or Package Name Augmented This ST and TOE are conformant with the claimed PP. 3.7 Conformance Claim Rationale The NDPP states the following: This is a Protection Profile (PP) for a network device. A network device in the context of this PP is a device composed of hardware and software that is connected to the network and has an infrastructure role in the overall enterprise. Examples of a network device that should claim compliance to this PP include routers, firewalls, IDSs, audit servers, and switches that have Layer 3 functionality. 14 P a g e

16 The TOE is a family of hardware appliances that is designed to perform low-level network traffic switching between SONET/SDH, OTN, and Ethernet/MPLS switches. As such, it can be understood as a network switch. Therefore, the conformance claim is appropriate. 15 P a g e

17 4 Security Problem Definition 4.1 Threats This section identifies the threats against the TOE. These threats have been taken from the NDPP. Threat T.ADMIN_ERROR T.TSF_FAILURE T.UNDETECTED_ACTIONS T.UNAUTHORIZED_ACCESS T.UNAUTHORIZED_UPDATE T.USER_DATA_REUSE Threat Definition An administrator may unintentionally install or configure the TOE incorrectly, resulting in ineffective security mechanisms. Security mechanisms of the TOE may fail, leading to a compromise of the TSF. 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. A user may gain unauthorized access to the TOE data and TOE executable code. A malicious user, process, or external IT entity may masquerade as an authorized entity in order to gain unauthorized access to data or TOE resources. A malicious user, process, or external IT entity may misrepresent itself as the TOE to obtain identification and authentication data. A malicious party attempts to supply the end user with an update to the product that may compromise the security features of the TOE. User data may be inadvertently sent to a destination not intended by the original sender. Table 4-1: TOE Threats 4.2 Organizational Security Policies This section identifies the organizational security policies which are expected to be implemented by an organization that deploys the TOE. These policies have been taken from the NDPP. Policy P.ACCESS_BANNER Policy Definition 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. Table 4-2: TOE Organization Security Policies 4.3 Assumptions The specific conditions listed in this section are assumed to exist in the TOE s Operational Environment. These assumptions have been taken from the NDPP. Assumption A.NO_GENERAL_PURPOSE A.PHYSICAL A.TRUSTED_ADMIN Assumption Definition 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. Physical security, commensurate with the value of the TOE and the data it contains, is assumed to be provided by the environment. TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. Table 4-3: TOE Assumptions 16 P a g e

18 4.4 Security Objectives This section identifies the security objectives of the TOE and its supporting environment. The security objectives identify the responsibilities of the TOE and its environment in meeting the security needs TOE Security Objectives This section identifies the security objectives of the TOE. These objectives have been taken directly from the NDPP. Objective O.PROTECTED_COMMUN ICATIONS O.VERIFIABLE_UPDATES O.SYSTEM_MONITORING O.DISPLAY_BANNER O.TOE_ADMINISTRATION O.RESIDUAL_INFORMATI ON_CLEARING O.SESSION_LOCK O.TSF_SELF_TEST Objective Definition The TOE will provide protected communication channels for administrators, other parts of a distributed TOE, and authorized IT entities. The TOE will provide the capability to help ensure that any updates to the TOE can be verified by the administrator to be unaltered and (optionally) from a trusted source. The TOE will provide the capability to generate audit data and send those data to an external IT entity. The TOE will display an advisory warning regarding use of the TOE. The TOE will provide mechanisms to ensure that only administrators are able to log in and configure the TOE, and provide protections for logged-in administrators. The TOE will ensure that any data contained in a protected resource is not available when the resource is reallocated. The TOE shall provide mechanisms that mitigate the risk of unattended sessions being hijacked. The TOE will provide the capability to test some subset of its security functionality to ensure it is operating properly. Table 4-4: TOE Objectives Security Objectives for the Operational Environment The TOE s operating environment must satisfy the following objectives: Objective OE.NO_GENERAL_PURPO SE OE.PHYSICAL OE.TRUSTED_ADMIN Objective Definition 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. Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. TOE Administrators are trusted to follow and apply all administrator guidance in a trusted manner. Table 4-5: TOE Operational Environment Objectives 4.5 Security Problem Definition Rationale The assumptions, threats, OSPs, and objectives that are defined in this ST represent the assumptions, threats, OSPs, and objectives that are specified in the Protection Profile to which the TOE claims conformance. The associated mappings of assumptions to environmental objectives, SFRs to TOE 17 P a g e

19 objectives, and OSPs and objectives to threats are therefore identical to the mappings that are specified in the claimed Protection Profile. 18 P a g e

20 5 Extended Components Definition 5.1 Extended Security Functional Requirements The extended Security Functional Requirements that are claimed in this ST are taken directly from the PP to which the ST and TOE claim conformance. These extended components are formally defined in the PP in which their usage is required. Therefore the Extended used in SFR component name will be dropped. 5.2 Extended Security Assurance Requirements There are no extended Security Assurance Requirements in this ST. 19 P a g e

21 6 Security Functional Requirements 6.1 Conventions The CC permits four functional component operations assignment, refinement, selection, and iteration to be performed on functional requirements. This ST will highlight the operations in the following manner: Assignment: allows the specification of an identified parameter. Indicated with italicized text. Refinement: allows the addition of details. Indicated with bold text and italicized text. Selection: allows the specification of one or more elements from a list. Indicated with underlined text. Iteration: allows a component to be used more than once with varying operations. Indicated with a sequential number in parentheses following the element number of the iterated SFR. When multiple operations are combined, such as an assignment that is provided as an option within a selection or refinement, a combination of the text formatting is used. If SFR text is reproduced verbatim from text that was formatted in a claimed PP (such as if the PP s instantiation of the SFR has a refinement or a completed assignment), the formatting is not preserved. This is so that the reader can identify the operations that are performed by the ST author as opposed to the PP author. 6.2 Security Functional Requirements Summary The following table lists the SFRs claimed by the TOE: Class Name Component Identification Component Name FAU_GEN.1 Audit Data Generation Security Audit FAU_GEN.2 User Identity Association FAU_STG_EXT.1 External Audit Trail Storage FCS_CKM.1 Cryptographic Key Generation (for asymmetric keys) FCS_CKM_EXT.4 Cryptographic Key Zeroization FCS_COP.1(1) Cryptographic Operation (for data encryption/decryption) FCS_COP.1(2) Cryptographic Operation (for cryptographic signature) Cryptographic Support Cryptographic Operation (for cryptographic FCS_COP.1(3) hashing) FCS_COP.1(4) Cryptographic Operation (for keyed-hash message authentication) FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation) FCS_SSH_EXT.1 SSH FCS_TLS_EXT.1 TLS User Data Protection FDP_RIP.2 Full Residual Information Protection Identification and FIA_PMG_EXT.1 Password Management 20 P a g e

22 Class Name Component Identification Component Name Authentication FIA_UAU_EXT.2 Password-based Authentication Mechanism FIA_UAU.7 Protected Authentication Feedback FIA_UIA_EXT.1 User Identification and Authentication Management of TSF Data (for general TSF FMT_MTD.1 data) Security Management FMT_SMF.1 Specification of Management Functions FMT_SMR.2 Restrictions on Security Roles FPT_APW_EXT.1 Protection of Administrator Passwords Protection of TSF Data (for reading of all FPT_SKP_EXT.1 symmetric keys) Protection of the TSF FPT_STM.1 Reliable Time Stamps FPT_TST_EXT.1 TSF Testing FPT_TUD_EXT.1 Trusted Update FTA_SSL_EXT.1 TSF-initiated Session Locking TOE Access FTA_SSL.3 TSF-initiated Termination FTA_SSL.4 User-initiated Termination FTA_TAB.1 Default TOE Access Banners Trusted Path /Channels FTP_ITC.1 Inter-TSF Trusted Channel FTP_TRP.1 Trusted Path Table 6-1: Security Functional Requirements for the TOE 21 P a g e

23 6.3 Security Functional Requirements Class FAU: Security Audit FAU_GEN.1 Audit Data Generation FAU_GEN.1.1 FAU_GEN.1.2 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) All administrative actions; d) [Specifically defined auditable events listed in Table 6-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 three of Table 6-2]. Requirements Auditable Events Additional Audit Record Contents FCS_SSH_EXT.1 Failure to establish an SSH session Establishment/Termination of an SSH session. Reason for failure. Non-TOE endpoint of connection (IP address) for both successes and failures. FCS_TLS_EXT.1 Failure to establish an TLS session Establishment/Termination of an TLS session. Reason for failure. Non-TOE endpoint of connection (IP address) for both successes and failures. FIA_UIA_EXT.1 All use of the identification and authentication mechanism. FIA_UAU_EXT.2 All use of the authentication mechanism. FPT_STM.1 Changes to the time. The old and new values for the time. Origin of the attempt (e.g., IP address). FPT_TUD_EXT.1 Initiation of update. No additional information. FTA_SSL_EXT.1 FTA_SSL.3 FTA_SSL.4 FTP_ITC.1 FTP_TRP.1 Any attempts at unlocking of an interactive session. The termination of a remote session by the session locking mechanism. The termination of an interactive session. Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Initiation of the trusted channel. Termination of the trusted channel. Failures of the trusted path functions. Table 6-2: Auditable Events Provided user identity, origin of the attempt (e.g., IP address). Origin of the attempt (e.g., IP address). No additional information. No additional information. No additional information. Identification of the initiator and target of failed trusted channels establishment attempt. Identification of the claimed user identity. Application Note: The TSF only terminates interactive sessions and does not lock them (see FTA_SSL_EXT.1). Therefore, the auditable event of any attempts at unlocking of an interactive session is synonymous with authentication attempts to the TOE. 22 P a g e

24 FAU_GEN.2 User Identity Association 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_EXT.1 External Audit Trail Storage FAU_STG_EXT.1.1 The TSF shall be able to [transmit the generated audit data to an external IT entity] using a trusted channel implementing the [SSH, TLS] protocol Class FCS: Cryptographic Support FCS_CKM.1 Cryptographic Key Generation (for asymmetric keys) FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys used for key establishment in accordance with [NIST Special Publication A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography for finite fieldbased key establishment schemes; NIST Special Publication B, Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography for RSAbased key establishment schemes] and specified cryptographic key sizes equivalent to, or greater than, a symmetric key strength of 112 bits FCS_CKM_EXT.4 Cryptographic Key Zeroization FCS_CKM_EXT.4.1 The TSF shall zeroize all plaintext secret and private cryptographic keys and CSPs when no longer required FCS_COP.1(1) Cryptographic Operation (for data encryption/decryption) FCS_COP.1.1(1) The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm AES operating in [CBC, [no other modes]] and cryptographic key sizes 128-bits and 256-bits that meets the following: FCS_COP.1(2) FIPS PUB 197, Advanced Encryption Standard (AES) [NIST SP A]. Cryptographic Operation (for cryptographic signature) FCS_COP.1.1(2) The TSF shall perform cryptographic signature services in accordance with a [(2) RSA Digital Signature Algorithm (rdsa) with a key size (modulus) of 2048 bits or greater] that meets the following: 23 P a g e

25 Case: RSA Digital Signature Algorithm FIPS PUB or FIPS PUB 186-3, Digital Signature Standard FCS_COP.1(3) Cryptographic Operation (for cryptographic hashing) FCS_COP.1.1(3) The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [SHA-1, SHA-256] and message digest sizes [160, 256] bits that meet the following: FIPS PUB 180-3, Secure Hash Standard FCS_COP.1(4) Cryptographic Operation (for keyed-hash message authentication) FCS_COP.1.1(4) The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm HMAC-[SHA-1, SHA-256], key size [greater than block size, less than block size, equal to block size], and message digest sizes [160, 256] bits that meet the following: FIPS PUB 198-1, The Keyed-Hash Message Authentication Code, and FIPS PUB 180-3, Secure Hash Standard FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation) FCS_RBG_EXT.1.1 FCS_RBG_EXT.1.2 The TSF shall perform all random bit generation (RBG) services in accordance with [NIST Special Publication using [Hash_DRBG (any)]]; seeded by an entropy source that accumulated entropy from [a TSF-hardware-based noise source]. The deterministic RBG shall be seeded with a minimum of [256 bits] of entropy at least equal to the greatest security strength of the keys and hashes that it will generate FCS_SSH_EXT.1 SSH FCS_SSH_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252, 4253, 4254, and [no other RFCs]. FCS_SSH_EXT.1.2 FCS_SSH_EXT.1.3 FCS_SSH_EXT.1.4 FCS_SSH_EXT.1.5 FCS_SSH_EXT.1.6 The TSF shall ensure that the SSH protocol implementation supports the following authentication methods as described in RFC 4252: public key-based, password-based. The TSF shall ensure that, as described in RFC 4253, packets greater than [32000] bytes in an SSH transport connection are dropped. The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms: AES-CBC-128, AES-CBC-256, [no other algorithms]. The TSF shall ensure that the SSH transport implementation uses [SSH_RSA] and [no other public key algorithms] as its public key algorithm(s). The TSF shall ensure that data integrity algorithms used in SSH transport connection is [hmac-sha1, hmac-sha2-256]. 24 P a g e

26 FCS_SSH_EXT.1.7 The TSF shall ensure that diffie-hellman-group14-sha1 and [no other methods] are the only allowed key exchange methods used for the SSH protocol FCS_TLS_EXT.1 TLS FCS_TLS_EXT.1.1 The TSF shall implement one or more of the following protocols [TLS 1.2 (RFC 5246)] supporting the following ciphersuites: Mandatory Ciphersuites: TLS_RSA_WITH_AES_128_CBC_SHA Optional Ciphersuites: [TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 ] Class FDP: User Data Protection FDP_RIP.2 Full Residual Information Protection FDP_RIP.2.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the [allocation of the resource to, deallocation of the resource from] all objects Class FIA: Identification and Authentication FIA_PMG_EXT.1 Password Management FIA_PMG_EXT.1.1 Application Note: 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: [!, %, ^, (, ), [ +, -, [, ], `, ~, {, }, ]]; The TSF also supports the underscore (_) character for administrative passwords but this was not included in the text of the assignment because the formatting conventions would cause it to be ambiguously represented. 2. Minimum password length shall settable by the Security Administrator, and support passwords of 15 characters or greater; 25 P a g e

27 FIA_UAU_EXT.2 Password-based Authentication Mechanism FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism, [SSH public-key based authentication mechanism] to perform administrative user authentication FIA_UAU.7 Protected Authentication Feedback FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the authentication is in progress at the local console FIA_UIA_EXT.1 User Identification and Authentication FIA_UIA_EXT.1.1 FIA_UIA_EXT.1.2 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; [[display of diagnostic non-tsf environmental data e.g., temperature, fan speed]] The TSF shall require each administrative user to be successfully identified and authenticated before allowing any other TSF-mediated actions on behalf of that administrative user Class FMT: Security Management FMT_MTD.1 Management of TSF Data (for general TSF data) FMT_MTD.1.1 The TSF shall restrict the ability to manage the TSF data to the Security Administrators FMT_SMF.1 Specification of Management Functions 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 update the TOE, and to verify the updates using [digital signature] capability prior to installing those updates; [Ability to configure the cryptographic functionality] FMT_SMR.2 Restrictions on Security Roles FMT_SMR.2.1 The TSF shall maintain the roles: Authorized Administrator. Application Note: The Authorized Administrator role as defined by the NDPP is met through the combination of the superuser role used to manage the MCLI and the Account Administrator (AA) role that is defined for the TL1 interface. 26 P a g e

28 FMT_SMR.2.2 FMT_SMR.2.3 The TSF shall be able to associate users with roles. The TSF shall ensure that the conditions: Authorized Administrator role shall be able to administer the TOE locally; Authorized Administrator role shall be able to administer the TOE remotely; are satisfied Class FPT: Protection of the TSF FPT_APW_EXT.1 Protection of Administrator Passwords FPT_APW_EXT.1.1 FPT_APW_EXT.1.2 The TSF shall store passwords in non-plaintext form. The TSF shall prevent the reading of plaintext passwords FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys FPT_STM.1 Reliable Time Stamps FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use FPT_TST_EXT.1 TSF Testing 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 FPT_TUD_EXT.1 Trusted Update FPT_TUD_EXT.1.1 FPT_TUD_EXT.1.2 FPT_TUD_EXT.1.3 The TSF shall provide security administrators the ability to query the current version of the TOE firmware/software. The TSF shall provide security administrators the ability to initiate updates to TOE firmware/software. The TSF shall provide a means to verify firmware/software updates to the TOE using a [digital signature mechanism] prior to installing those updates Class FTA: TOE Access FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_SSL_EXT.1.1 Application Note: The TSF shall, for local interactive sessions, [terminate the session] after a Security Administrator-specified time period of inactivity. Security Administrator in this case is considered to be synonymous with Authorized Administrator as defined in FMT_SMR P a g e

29 FTA_SSL.3 TSF-initiated Termination FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security Administratorconfigurable time interval of session inactivity. Application Note: Security Administrator in this case is considered to be synonymous with Authorized Administrator as defined in FMT_SMR FTA_SSL.4 User-initiated Termination FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator s own interactive session FTA_TAB.1 Default TOE Access Banners FTA_TAB.1.1 Before establishing an administrative user session the TSF shall display a Security Administrator-specified advisory notice and consent warning message regarding use of the TOE Class FTP: Trusted Path/Channels FTP_ITC.1 Inter-TSF Trusted Channel FTP_ITC.1.1 FTP_ITC.1.2 FTP_ITC.1.3 The TSF shall use [TLS, SSH] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: audit server, [[update server]] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data. The TSF shall permit the TSF, or the authorized IT entities to initiate communication via the trusted channel. The TSF shall initiate communication via the trusted channel for [transfer of audit data, acquisition of TOE updates] FTP_TRP.1 Trusted Path FTP_TRP.1.1 FTP_TRP.1.2 FTP_TRP.1.3 The TSF shall use [SSH] provide a trusted communication path between itself and remote administrators that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from disclosure and detection of modification of the communicated data. The TSF shall permit remote administrators to initiate communication via the trusted path. The TSF shall require the use of the trusted path for initial administrator authentication and all remote administration actions. 28 P a g e

30 6.4 Statement of Security Functional Requirements Consistency The Security Functional Requirements included in the ST represent all required SFRs specified in the claimed PP as well as a subset of the optional SFRs. All hierarchical relationships, dependencies, and unfulfilled dependency rationales in the ST are considered to be identical to those that are defined in the claimed PP. 7 Security Assurance Requirements This section identifies the Security Assurance Requirements (SARs) that are claimed for the TOE. The SARs which are claimed are consistent with the claimed PP. 7.1 Class ADV: Development Basic Functional Specification (ADV_FSP.1) Developer action elements: ADV_FSP.1.1D The developer shall provide a functional specification. ADV_FSP.1.2D The developer shall provide a tracing from the functional specification to the SFRs Content and presentation elements: ADV_FSP.1.1C The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.2C The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.3C The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering. ADV_FSP.1.4C The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification Evaluator action elements: ADV_ FSP.1.1E 29 P a g e

31 The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_ FSP.1.2E The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. 7.2 Class AGD: Guidance Documents Operational User Guidance (AGD_OPE.1) Developer action elements: AGD_OPE.1.1D The developer shall provide operational user guidance Content and presentation elements: AGD_OPE.1.1C The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. AGD_OPE.1.2C The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner. AGD_OPE.1.3C The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. AGD_OPE.1.4C The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. AGD_OPE.1.5C The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences, and implications for maintaining secure operation. AGD_OPE.1.6C The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST. 30 P a g e

32 AGD_OPE.1.7C The operational user guidance shall be clear and reasonable Evaluator action elements: AGD_OPE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence Preparative Procedures (AGD_PRE.1) Developer action elements: AGD_PRE.1.1D The developer shall provide the TOE, including its preparative procedures Content and presentation elements: AGD_ PRE.1.1C The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. AGD_ PRE.1.2C The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST Evaluator action elements: AGD_ PRE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AGD_ PRE.1.2E The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation. 7.3 Class ALC: Life-cycle Support Labeling of the TOE (ALC_CMC.1) Developer action elements: ALC_CMC.1.1D The developer shall provide the TOE and a reference for the TOE. 31 P a g e