Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA © 2026 Cisco Systems, Inc. This document can be reproduced in full without any modifications. - Cisco Secure Network Analytics (SNA) 7.5 Security Target Version 1.2 July 13, 2026 Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 2 of 67 - Table of Contents 1 SECURITY TARGET INTRODUCTION .............................................................................7 1.1 ST and TOE Reference .................................................................................................... 7 1.2 TOE Overview ................................................................................................................. 7 1.2.1 TOE Product Type.................................................................................................... 8 1.2.2 Supported non-TOE Hardware/ Software/ Firmware............................................... 8 1.3 TOE Description .............................................................................................................. 8 1.4 TOE Evaluated Configuration........................................................................................ 10 1.5 Physical Scope of the TOE............................................................................................. 11 1.6 Logical Scope of the TOE.............................................................................................. 12 1.6.1 Security Audit......................................................................................................... 12 1.6.2 Communication....................................................................................................... 12 1.6.3 Cryptographic Support............................................................................................ 12 1.6.4 Identification and authentication............................................................................. 13 1.6.5 Security Management ............................................................................................. 13 1.6.6 Protection of the TSF.............................................................................................. 14 1.6.7 TOE Access ............................................................................................................ 14 1.6.8 Trusted Path/Channels ............................................................................................ 14 1.7 Excluded Functionality .................................................................................................. 14 2 Conformance Claims.............................................................................................................15 2.1 Common Criteria Conformance Claim .......................................................................... 15 2.2 Protection Profile Conformance..................................................................................... 15 2.3 Protection Profile Conformance Claim Rationale.......................................................... 15 2.3.1 TOE Appropriateness.............................................................................................. 15 2.3.2 TOE Security Problem Definition Consistency...................................................... 16 2.3.3 Statement of Security Requirements Consistency.................................................. 16 3 SECURITY PROBLEM DEFINITION................................................................................17 3.1 Threats............................................................................................................................ 17 3.2 Assumptions................................................................................................................... 18 3.3 Organizational Security Policies.................................................................................... 20 4 SECURITY OBJECTIVES...................................................................................................22 4.1 Security Objectives for the TOE .................................................................................... 22 4.2 Security Objectives for the Environment....................................................................... 22 5 SECURITY REQUIREMENTS ...........................................................................................24 5.1 Conventions.................................................................................................................... 24 5.2 TOE Security Functional Requirements ........................................................................ 24 5.3 SFRs Drawn from NDcPP.............................................................................................. 25 5.3.1 Security audit (FAU)............................................................................................... 25 Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 3 of 67 - 5.3.2 Communication Partner Control (FCO).................................................................. 29 5.3.3 Cryptographic Support (FCS)................................................................................. 29 5.3.4 Identification and authentication (FIA) .................................................................. 35 5.3.5 Security management (FMT).................................................................................. 37 5.3.6 Protection of the TSF (FPT) ................................................................................... 39 5.3.7 TOE Access (FTA) ................................................................................................. 40 5.3.8 Trusted Path/Channels (FTP).................................................................................. 40 5.4 TOE SFR Dependency Rationale................................................................................... 42 5.5 Security Assurance Requirements.................................................................................. 42 5.5.1 SAR Requirements.................................................................................................. 42 5.5.2 Security Assurance Requirements Rationale.......................................................... 42 5.6 Assurance Measures....................................................................................................... 42 6 TOE Summary Specification ................................................................................................44 6.1 TOE Security Functional Requirement Measures.......................................................... 44 7 Supplemental TOE Summary Specification Information......................................................61 7.1 Key Destruction.............................................................................................................. 61 7.2 CAVP Certificate Equivalence....................................................................................... 62 8 Annex A: References ............................................................................................................65 9 Annex B: SFR TOE Components Mapping..........................................................................66 Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 4 of 67 - List of Tables TABLE 1: ACRONYMS....................................................................................................................................5 TABLE 2: ST AND TOE IDENTIFICATION.......................................................................................................7 TABLE 3: IT ENVIRONMENT COMPONENTS ..................................................................................................8 TABLE 4: TOE HARDWARE COMPONENT MODELS AND SPECIFICATIONS ...................................................9 TABLE 5: TOE SOFTWARE COMPONENTS.....................................................................................................9 TABLE 6: TOE PROVIDED CRYPTOGRAPHY................................................................................................12 TABLE 7: EXCLUDED FUNCTIONALITY .......................................................................................................14 TABLE 8: PROTECTION PROFILE AND FUNCTIONAL PACKAGE ...................................................................15 TABLE 9: NIAP TECHNICAL DECISIONS .....................................................................................................15 TABLE 10: THREATS....................................................................................................................................17 TABLE 11: TOE ASSUMPTIONS ...................................................................................................................18 TABLE 12 ORGANIZATIONAL SECURITY POLICIES.....................................................................................20 TABLE 13: SECURITY OBJECTIVES FOR THE ENVIRONMENT ......................................................................22 TABLE 14: SECURITY FUNCTIONAL REQUIREMENTS .................................................................................24 TABLE 15: AUDITABLE EVENTS..................................................................................................................26 TABLE 16: ASSURANCE MEASURES ............................................................................................................42 TABLE 17: ASSURANCE MEASURES ............................................................................................................43 TABLE 18: TOE SFR MEASURES ................................................................................................................44 TABLE 19: TOE KEY DESTRUCTION...........................................................................................................61 TABLE 20: PROCESSORS WITHIN THE TOE.................................................................................................62 TABLE 21: CAVP VALIDATION NUMBERS FOR THE CISCO FIPS PROVIDER (FP)......................................63 TABLE 22: CAVP VALIDATION NUMBERS FOR BOUNCY CASTLE (BC).....................................................64 TABLE 23: REFERENCES..............................................................................................................................65 TABLE 24: DISTRIBUTED TOE SFR MAPPING ............................................................................................66 List of Figures FIGURE 1: TOE AND ENVIRONMENT...........................................................................................................11 Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 5 of 67 - List of 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 CAVP Cryptographic Algorithm Validation Program (under NIST) CC Common Criteria for Information Technology Security Evaluation CEM Common Evaluation Methodology for Information Technology Security CM Configuration Management DHCP Dynamic Host Configuration Protocol DNS Domain Name System FC / SFC SNA Flow Collector FIPS Federal Information Processing Standards FOM FIPS Object Module, a cryptographic module FP FIPS Provider (cryptographic implementation), formerly FOM FQDN Fully Qualified Domain Name FS / SFS SNA Flow Sensor GE Gigabit Ethernet port HTTP Hyper-Text Transport Protocol HTTPS Hyper-Text Transport Protocol Secure ICMP Internet Control Message Protocol IT Information Technology MC See SMC NDcPP collaborative Protection Profile for Network Devices NIST National Institute of Standards and Technology OS Operating System PP Protection Profile UDP User Datagram Protocol SA Security Association SFP Small–form-factor pluggable port SHS Secure Hash Standard SMC SNA Management Console Note: Starting with v7.4.0, the SMC was renamed to “Manager” though appliance part numbers, and installation/update filenames for version 7.5 still contain the acronym “SMC”. ST Security Target TCP Transport Control Protocol TOE Target of Evaluation TSC TSF Scope of Control TSF TOE Security Function TSP TOE Security Policy Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 6 of 67 - 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), Cisco Secure Network Analytics (SNA). 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 Secure Network Analytics (SNA) 7.5 Security Target Page 7 of 67 - 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 2: ST and TOE Identification Name Description ST Title Cisco Secure Network Analytics ST Version 1.2 Publication Date July 13, 2026 Vendor and ST Author Cisco Systems, Inc. TOE Reference Secure Network Analytics (SNA) TOE Hardware Models • SNA Management Console (ST-SMC2300-K9, and L-ST-SMC-VE-K9) • SNA Flow Collector (ST-FC4300-K9, and L-ST-FC-VE-K9) • SNA Flow Sensor (ST-FS1300-K9, ST-FS3300-K9, ST-FS4300-K9, and L-ST- FS-VE-K9) TOE Software Version 7.5 Keywords Threat Detection, Incident Response, Forensics 1.2 TOE Overview The Cisco Secure Network Analytics (SNA) TOE is a centrally managed system of distributed components for collection, storage, and analysis of network telemetry data. The TOE includes the models as defined in Table 2 in section 1.1. The evaluated configurations of the TOE consist of one SNA Manager, one or more Flow Collectors (FC), and one or more Flow Sensors (FS). Each of the TOE components are available as a stand-alone physical appliance, or as a virtual appliance. The physical and virtual appliances provide equivalent functionality, and a mixture of physical and virtual appliances can be deployed together. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 8 of 67 - 1.2.1 TOE Product Type Cisco Secure Network Analytics (SNA) is a set of distributed network appliances including a central management appliance that manages all the distributed appliances, which may be physical and/or virtual appliances. SNA provides visibility and security analytics (threat detection, and threat response) using network traffic telemetry data. SNA can generate telemetry data directly (by directly monitoring traffic flows) or can collect telemetry data generated by devices in an existing network infrastructure. 1.2.2 Supported non-TOE Hardware/ Software/ Firmware 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 3: IT Environment Components Component Required Usage/Purpose Description for TOE performance Management Workstation with TLS Client (browser) Yes SNA supports the latest versions of Chrome, Firefox, and Microsoft Edge. The browser is required to remotely manage the TOE via the WebUI on the SNA Manager. Management Workstation with Console Connection Yes Required for initial installation of each device, optional thereafter. This includes any workstation that is directly connected to the console port (or keyboard-video-mouse ports) of any TOE component. Certification Authority Yes The external CA Server is used be used to provide new device identity certificates for each TOE component to replace their initial self-signed certificates. The CA-signed certificates are used for all TLS connections to/from all TOE components. The CA Server also supports certificate revocation checking by CRLs (via CRL distribution points) and/or OCSP responders. LDAP Server Yes Any AAA server that supports LDAP over TLS. The TOE maintains local administrative accounts on the Manager, and those accounts can be used for remote administration, though most deployments will opt to also use LDAP for authentication of administrative accounts. Syslog Server Yes This includes any syslog server to which the TOE would transmit syslog messages. NTP Server Yes The TOE supports communications with an NTP Server in order to synchronize the date and time for a reliable timestamp on the TOE. Note: The management “workstation” is not part of the TOE and should not be confused with the SNA Management “Console,” which is part of the TOE. The management workstation is the computer the TOE administrator uses to access the TOE. 1.3 TOE Description This section provides an overview of the Cisco Secure Network Analytics Target of Evaluation (TOE). The TOE is a system comprised of three appliance types (Manager, FC, and FS) described below, each of Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 9 of 67 - which is comprised of both software and hardware. The software on each appliance type is a proprietary build of Linux with Cisco SNA applications, where each appliance type (Manager, FC, and FS) contains its own set of applications specific to its unique functionality. The hardware of each appliance (physical and virtual) is a Cisco UCS server platform as listed in Table 4. The software running on each type of SNA appliance is software image Release 7.5. The Cisco Secure Network Analytics components that comprise the TOE have common hardware characteristics. Any hardware differences, e.g. the amount of RAM or drive space, or the number of network interfaces, affect only non-TSF relevant functionality such as throughput and amount of storage, and therefore support security equivalency of the TOE component models. This TOE is considered a ‘distributed’ TOE as defined in NDcPP in that this TOE requires multiple distinct TOE components to operate as a logical whole in order to fulfil the requirements of NDcPP, and those TOE components are separated (distributed) across a network. This TOE includes one management component (Manager), and two types of managed network devices (FC, and FS). In a distributed TOE, not all requirements need to be enforced by each TOE component; a summary table showing which SFRs apply to which TOE component can be found in Annex B: SFR TOE Components Mapping. The SNA Manager provides the administrative interface to manage all TOE components. The Manager aggregates, organizes, and presents analysis from up to 25 Flow Collectors, and other sources. It provides a graphical representations of network traffic, identity information, customized summary reports, and integrated security and network intelligence for comprehensive analysis. The SNA Flow Collector (FC) receives telemetry data from SNA Flow Sensors and other sources such as routers, switches, firewalls, and endpoint agents. The FC stores collected data in its internal database, analyses the data, sends event notifications to the Manager, and supports further forensics and long-term data analysis via customized reporting provided by the Manager. Multiple Flow Collectors may be managed by a single Manager and are available as hardware appliances or as virtual machines. The Flow Sensor (FS) produces telemetry for segments of the switching and routing infrastructure that can’t generate NetFlow natively. The Flow Sensors connect directly to a mirroring port or network tap to monitor network traffic and generate telemetry data. Multiple Flow Sensors can be managed by a single Manager and are available as hardware appliances or as virtual appliances to monitor virtual machine environments. Note, all the data collection, correlation, and analysis features described above are outside the scope of this CC evaluation. All the CC-evaluated security functionality is described later in this document, particularly in sections 1.6, 5.3, and section 6. Table 4 below describes the models that have been claimed within this evaluation: Table 4: TOE Hardware Component Models and Specifications SNA Appliance Type Part Number Server platform Entropy Source SNA Manager ST-SMC2300-K9 L-ST-SMC-VE-K9 UCSC-C225-M6SX JENT SNA Flow Sensor ST-FS1300-K9 ST-FS3300-K9 ST-FS4300-K9 L-ST-FS-VE-K9 SNA Flow Collector ST-FC4300-K9 L-ST-FC-VE-K9 Table 5: TOE Software Components Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 10 of 67 - SNA Appliance Type Part Number Software SNA Manager ST-SMC2300-K9 Note: All physical appliances (Manager, FS, FC) are delivered with software preinstalled, using the same installation image used to install/deploy the virtual edition (VE), and are updated and patched with the same files used for the VE. L-ST-SMC-VE-K9 Install: SMC-7.5.2-20250121.1527-833bbd1d6ff3- 0.iso Update: update-smc-ROLLUP20260214- 7.5.2-v2-01.swu SNA Flow Sensor ST-FS1300-K9 ST-FS3300-K9 ST-FS4300-K9 See note above regarding physical appliances. L-ST-FS-VE-K9 Install: FlowSensor-7.5.2-20250121.1527- 833bbd1d6ff3-0.iso Update: update-fsuf-ROLLUP20260214-7.5.2- v2-01.swu SNA Flow Collector ST-FC4300-K9 See note above regarding physical appliances. L-ST-FC-VE-K9 Install: FlowCollector-NetFlow-7.5.2- 20250121.1527-833bbd1d6ff3-0.iso Update: update-fcnf-ROLLUP20260214- 7.5.2-v2-01.swu 1.4 TOE Evaluated Configuration The TOE consists of one or more physical or virtual devices as specified in section 1.5 below and includes the Cisco SNA software. The figure below shows each of the three TOE components in the operational environment. The diagram shows one of each TOE component (Manager, FC, and FS), where each appliance (each TOE component) can be either physical or virtual. The diagram shows only a single icon for the FS though the FS physical appliance is available in three models . Regardless of the form-factor, each TOE component type provides the same TOE security functionality. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 11 of 67 - Figure 1: TOE and Environment Figure 1 shows the protocols and connections (TLS, HTTPS, HTTP, and the serial connections) that are relevant to requirements within NDcPP (where HTTP is used for CRL and OCSP connections to the CA Server). The TOE components also use other protocols (e.g. DNS, NetFlow and sFlow) that are not relevant to NDcPP requirements as that traffic does not contain TSF data. Each appliance contains a DNS client for FQDN resolution (e.g. for LDAP servers, CAs, URL distribution points, and OCSP responders). The FC receives NetFlow or sFlow traffic (depending on whether the FC was installed in sFlow or NetFlow mode) from FS. The FS monitors network traffic (via its promiscuous (passive) interface) and generates sFlow or NetFlow data to transmit to an FC. 1.5 Physical Scope of the TOE The TOE is a hardware and software solution composed of three major components: Manager, FC, and FS. 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 and includes the Cisco SNA Compliance Guide and additional guidance documents referenced therein, all of which are downloadable from the http://cisco.com web site. The TOE is comprised of the physical specifications as described in Table 4 in section 1.3 above. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 12 of 67 - 1.6 Logical Scope of the TOE The TOE is comprised of several security features. Each of the features identified above consists of several security functionalities, as identified below. 1. Security Audit 2. Communication 3. Cryptographic Support 4. Identification and Authentication 5. Security Management 6. Protection of the TSF 7. TOE Access 8. Trusted Path/Channels These features are described in more detail in the subsections below. 1.6.1 Security Audit The Cisco Secure Network Analytics provides extensive auditing capabilities. The TOE can audit events related to cryptographic functionality, identification and authentication, and administrative actions. The Cisco Secure Network Analytics generates an audit record for each auditable event. Each security relevant audit event has the date, timestamp, event description, and subject identity. The administrator configures auditable events, configures secure transmission of audit records to a remote audit server, and manages audit data storage. The TOE provides the administrator with a local circular audit trail. Audit messages are stored locally and transmitted over an encrypted channel to an external audit server. 1.6.2 Communication The TOE allows authorized administrators to control which SNA appliance (FC, and FS) is managed by the Manager. This is performed through a registration process over TLS. The administrator can also de- register an appliance if he or she wishes to no longer manage it through the Manager. For this TOE the process of registration/joining a new managed appliance (FC, FS) to the Manager is manually initiated by the administrator installing each appliance. The initial TLS connection is authenticated to the Manager using the Manager administrator’s username/password, at which point the appliances exchange their X.509 certificates, and from that point forward all TLS communications among appliances are authenticated using X.509 certificates. 1.6.3 Cryptographic Support The TOE provides cryptography in support of other Cisco SNA security functionality. This cryptography has been validated by the NIST CAVP (see section 7.2 for certificate references). The TOE provides cryptography in support for TLS, which is used for remote administrative management, and secure communication among TOE components, and connects from the TOE to LDAP and syslog servers. The cryptographic services provided by the TOE are described in Table 6 below. Table 6: TOE Provided Cryptography Cryptographic Method Use within the TOE AES Used to encrypt TLS session traffic. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 13 of 67 - Cryptographic Method Use within the TOE ECDH Used to provide key exchange in TLS. RSA Signature Services X.509 certificate signing and verification. Data signing and verification in TLS. HMAC Used for keyed hash, integrity services in TLS session establishment. DRBG Used for random number generation Used in TLS session establishment. SHA Used to provide TLS traffic integrity verification Transport Layer Security (TLS) Used in TLS session establishment. During initial installation each TOE component generates its own unique self-signed X.509v3 certificate, and during initial configuration all those certificates are replaced with new CA-signed identity certificates which are then used for all TLS connections including mutual authentication of TLS connections among TOE components. Configuration of trust stores for all components is performed via the Central Management WebUI of the Manager, but each TOE component generates its own unique keypair and its own certificate signing requests (CSR), and imports (via the Central Management WebUI of the Manager) TLS certificates that have been signed by an external CA server. 1.6.4 Identification and authentication TOE components perform two types of authentication: password-based authentication of administrators for remote administration of the TOE; and certificate-based authentication of devices. Device-level authentication allows TOE components to establish secure channels with other TOE components, and with external servers (LDAP and syslog). The TOE provides administrator authentication against a local user database. Password-based authentication can be performed on the serial console, and the GUI (accessible via HTTPS/TLS). For authentication to the GUI, the TOE optionally supports use of a AAA server (using LDAP over TLS), which would be outside the TOE boundary. 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 of 8 to 256 characters. After a configurable number of incorrect login attempts at administrative interfaces where authentication is processed locally (i.e. where LDAP is not used), the TOE will lock the offending account until an Administrator defined time period has elapsed. 1.6.5 Security Management 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 HTTPS/TLS 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; the timestamps maintained by the TOE; and updates to the TOE. When an administrative session is initially established, the TOE displays an administrator-configurable warning banner. This is used to provide any information deemed necessary by the administrator. After a set amount of time of inactivity, the administrator will be locked out of the administrator interface. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 14 of 67 - 1.6.6 Protection of the TSF The TOE protects against interference and tampering by untrusted subjects by implementing identification, authentication, and access controls to limit configuration to Authorized Administrators. The TOE prevents reading of plaintext cryptographic keys and passwords. 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. The TOE is able to verify any software updates prior to the software updates being installed on the TOE to avoid the installation of unauthorized software. The TOE performs self-testing to verify correct operation of its cryptographic module. The TOE components are not general-purpose operating systems; root access is not permitted, external software applications cannot be installed, and access to memory space is restricted to TOE functions. The TOE is distributed, including multiple appliances that communicate with each other over a network. These internal TOE communications between TOE components are protected within TLS and authenticated using X.509 certificates. 1.6.7 TOE Access The TOE can terminate inactive sessions after an Authorized Administrator configurable time-period. Once a session has been terminated the TOE requires the user to re-authenticate to establish a new session. The TOE can also display an Authorized Administrator specified banner on the CLI management interface and the WebUI prior to allowing any administrative access to the TOE. 1.6.8 Trusted Path/Channels The TOE establishes a trusted path with syslog servers using TLS, and with LDAP servers using TLS. Remote administration of the TOE uses TLS/HTTPS. All communications between TOE components are protected within TLS; the initial joining of TOE components is authenticated using a username and password that’s manually entered during the joining process, and subsequent communications between TOE components are automatically authenticated using X.509 certificates. 1.7 Excluded Functionality The following functionality is excluded from the evaluation. The exclusion of this functionality does not affect compliance to the collaborative Protection Profile for Network Devices (NDcPP). Table 7: Excluded Functionality Excluded Functionality Exclusion Rationale Non-FIPS 140-3 mode of operation This mode of operation includes non-FIPS allowed operations. RADIUS and TACACS+ LDAP over TLS can be used instead of RADIUS and TACACS+, which cannot be secured in TLS. SSH SSH access to each TOE component is disabled during initial configuration. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 15 of 67 - 2 CONFORMANCE CLAIMS 2.1 Common Criteria Conformance Claim The TOE and ST are compliant with the Common Criteria (CC) Version 3.1, Revision 5, dated April 2017. For a listing of Assurance Requirements claimed see section 5.5. The TOE and ST are CC Part 2 extended and CC Part 3 conformant. 2.2 Protection Profile Conformance The TOE and ST are conformant with the Protection Profile as listed in Table 8 below. Table 8: Protection Profile and Functional Package Protection Profile / Functional Package Version Date collaborative Protection Profile for Network Devices (CPP_ND_V3.0E) 3.0e 06-December-2023 NIAP Technical Decisions (TDs) have been applied as indicated in Table 9 below: Table 9: NIAP Technical Decisions TD # TD Name Protection Profile or Package Applied to this TOE TD1033 Sunset Dates for NDcPP Configurations NDcPPv3.0e Yes TD0990 NIT Technical Decision: CTR_DRBG in FCS_RBG_EXT.1.2 NDcPPv3.0e Yes TD0973 NIT Technical Decision: FCS_(D)TLSS_EXT.1.3 Test 2 DHE Ciphersuite Conditionality NDcPPv3.0e Yes TD0923 NIT Technical Decision: Auditable event for FAU_STG_EXT.1 in FAU_GEN.1.2 NDcPPv3.0e Yes TD0921 NIT Technical Decision: Addition of FIPS PUB 186-5 and Correction of Assignment NDcPPv3.0e Yes TD0900 NIT Technical Decision: Clarification to Local Administrator Access in FIA_UIA_EXT.1.3 NDcPPv3.0e Yes TD0899 NIT Technical Decision: Correction of Renegotiation Test for TLS 1.2 NDcPPv3.0e Yes TD0886 Clarification to FAU_STG_EXT.1 Test 6 NDcPPv3.0e Yes TD0880 NIT Decision: Removal of Duplicate Selection in FMT_SMF.1 NDcPPv3.0e Yes TD0879 NIT Decision: Correction of Chapter Headings in CPP_ND_v3.0E NDcPPv3.0e Yes TD0868 NIT Technical Decision: Clarification of time frames in FCS_IPSEC_EXT.1.7 and FCS_IPSEC_EXT.1.8 NDcPPv3.0e No IPsec is not in the TOE TD0836 NIT Technical Decision: Redundant Requirements in FPT_TST_EXT.1 NDcPPv3.0e Yes 2.3 Protection Profile Conformance Claim Rationale 2.3.1 TOE Appropriateness The TOE provides all of the functionality at a level of security commensurate with that identified in the U.S. Government Protection Profile and Functional Package: Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 16 of 67 - • collaborative Protection Profile for Network Devices, Version 3.0e, 06-December-2023 2.3.2 TOE Security Problem Definition Consistency The Assumptions, Threats, and Organization Security Policies included in the Security Target represent the Assumptions, Threats, and Organization Security Policies specified in the NDcPP, for which conformance is claimed verbatim. All concepts covered in the Protection Profile Security Problem Definition are included in the Security Target Statement of Security Objectives Consistency. The Security Objectives included in the Security Target represent the Security Objectives specified in the NDcPP, for which conformance is claimed verbatim. All concepts covered in the Protection Profile’s Statement of Security Objectives are included in the Security Target. 2.3.3 Statement of Security Requirements Consistency The Security Functional Requirements included in the Security Target represent the Security Functional Requirements specified in the NDcPP, for which conformance is claimed verbatim. All concepts covered in each of the Protection Profile’s Statement of Security Requirements are included in the Security Target. Additionally, the Security Assurance Requirements included in the Security Target are identical to the Security Assurance Requirements included in the claimed Protection Profiles. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 17 of 67 - 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 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.UNAUTHORIZED_ADMINIST RATOR_ACCESS Threat agents may attempt to gain Administrator access to the Network Device by nefarious means such as masquerading as an Administrator to the device, masquerading as the device to an Administrator, replaying an administrative session (in its entirety, or selected portions), or performing man-in-the-middle attacks, which would provide access to the administrative session, or sessions between Network Devices. Successfully gaining Administrator access allows malicious actions that compromise the security functionality of the device and the network on which it resides. T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic algorithms or perform a cryptographic exhaust against the key space. Poorly chosen encryption algorithms, modes, and key sizes will allow attackers to compromise the algorithms, or brute force exhaust the key space and give them unauthorized access allowing them to read, manipulate and/or control the traffic with minimal effort. T.UNTRUSTED_COMMUNICAT ION_CHANNELS Threat agents may attempt to target Network Devices that do not use standardized secure tunnelling protocols to protect the critical network traffic. Attackers may take advantage of poorly designed protocols or poor key management to successfully perform man- in-the-middle attacks, replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of the critical network traffic, and potentially could lead to a compromise of the Network Device itself. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 18 of 67 - Threat Threat Definition T.WEAK_AUTHENTICATION_ ENDPOINTS Threat agents may take advantage of secure protocols that use weak methods to authenticate the endpoints, e.g. a shared password that is guessable or transported as plaintext. The consequences are the same as a poorly designed protocol, the attacker could masquerade as the Administrator or another device, and the attacker could insert themselves into the network stream and perform a man-in-the-middle attack. The result is the critical network traffic is exposed and there could be a loss of confidentiality and integrity, and potentially the Network Device itself could be compromised. T.UPDATE_COMPROMISE Threat agents may attempt to provide a compromised update of the software or firmware which undermines the security functionality of the device. Non-validated updates or updates validated using non-secure or weak cryptography leave the update firmware vulnerable to surreptitious alteration. T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change, and/or modify the security functionality of the Network Device without Administrator awareness. This could result in the attacker finding an avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the Administrator would have no knowledge that the device has been compromised. T.SECURITY_FUNCTIONALIT Y_COMPROMISE Threat agents may compromise credentials and device data enabling continued access to the Network Device and its critical data. The compromise of credentials includes replacing existing credentials with an attacker’s credentials, modifying existing credentials, or obtaining the Administrator or device credentials for use by the attacker. Threat agents may also be able to take advantage of weak administrative passwords to gain privileged access to the device. T.SECURITY_FUNCTIONALIT Y_FAILURE An external, unauthorized entity could make use of failed or compromised security functionality and might therefore subsequently use or abuse security functions without prior authentication to access, change or modify device data, critical network traffic or security functionality of the device. 3.2 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 11: TOE Assumptions Assumption Assumption Definition A.PHYSICAL_PROTECTION The network device is assumed to be physically protected in its operational environment and not subject to physical attacks that compromise the security or interfere with the device’s physical interconnections and correct operation. This protection is Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 19 of 67 - Assumption Assumption Definition assumed to be sufficient to protect the device and the data it contains. As a result, the cPP will not include any requirements on physical tamper protection or other physical attack mitigations. The cPP does not expect the product to defend against physical access to the device that allows unauthorized entities to extract data, bypass other controls, or otherwise manipulate the device. For vNDs, this assumption applies to the physical platform on which the VM runs. A.LIMITED_FUNCTIONALITY The device is assumed to provide networking functionality as its core function and not provide functionality/services that could be deemed as general purpose computing. For example, the device should not provide a computing platform for general purpose applications (unrelated to networking functionality). If a virtual TOE evaluated as a pND, following Case 2 vNDs as specified in Section 1.2, the VS is considered part of the TOE with only one vND instance for each physical hardware platform. The exception being where components of a distributed TOE run inside more than one virtual machine (VM) on a single VS. In Case 2 vND, no non-TOE guest VMs are allowed on the platform. A.NO_THRU_TRAFFIC_PROTE CTION A standard/generic network device does not provide any assurance regarding the protection of traffic that traverses it. The intent is for the network device to protect data that originates on or is destined to the device itself, to include administrative data and audit data. Traffic that is traversing the network device, destined for another network entity, is not covered by the ND cPP. It is assumed that this protection will be covered by cPPs and PP-Modules for particular types of network devices (e.g., firewall). A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the network device are assumed to be trusted and to act in the best interest of security for the organization. This includes appropriately trained, following policy, and adhering to guidance documentation. Administrators are trusted to ensure passwords/credentials have sufficient strength and entropy and to lack malicious intent when administering the device. The network device is not expected to be capable of defending against a malicious Administrator that actively works to bypass or compromise the security of the device. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are expected to fully validate (e.g. offline verification) any CA certificate (root CA certificate or intermediate CA certificate) loaded into the TOE’s trust store (aka 'root store', ' trusted CA Key Store', or similar) as a trust anchor prior to use (e.g. offline verification). Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 20 of 67 - Assumption Assumption Definition A.REGULAR_UPDATES The network device firmware and software is assumed to be updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. A.ADMIN_CREDENTIALS_SEC URE The Administrator’s credentials (private key) used to access the network device are protected by the platform on which they reside. A.COMPONENTS_RUNNING For distributed TOEs it is assumed that the availability of all TOE components is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. It is also assumed that in addition to the availability of all components it is also checked as appropriate that the audit functionality is running properly on all TOE components. A.RESIDUAL_INFORMATION The Administrator must ensure that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. A.VS_TRUSTED_ADMINISTRA TOR The Security Administrators for the VS are assumed to be trusted and to act in the best interest of security for the organization. This includes not interfering with the correct operation of the device. The Network Device is not expected to be capable of defending against a malicious VS Administrator that actively works to bypass or compromise the security of the device. A.VS_REGULAR_UPDATES The VS software is assumed to be updated by the VS Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. A.VS_ISOLATION For vNDs, it is assumed that the VS provides, and is configured to provide sufficient isolation between software running in VMs on the same physical platform. Furthermore, it is assumed that the VS adequately protects itself from software running inside VMs on the same physical platform. A.VS_CORRECT_CONFIGURAT ION For vNDs, it is assumed that the VS and VMs are correctly configured to support ND functionality implemented in VMs. 3.3 Organizational Security Policies The following table lists the Organizational Security Policies imposed by an organization to address its security needs. Table 12 Organizational Security Policies Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 21 of 67 - 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 Administrators consent by accessing the TOE. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 22 of 67 - 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 collaborative Protection Profile for Network Devices v3.0e does not define any security objectives for the TOE. 4.2 Security Objectives for the Environment All of the assumptions stated in section 3.2 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.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. 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. Note: For vNDs the TOE includes only the contents of its own VM, and does not include other VMs or the VS. OE.NO_THRU_TRAFFIC_PROTE CTION The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this traffic will be covered by other security and assurance measures in the operational environment. OE.TRUSTED_ADMIN Security Administrators are trusted to follow and apply all guidance documentation in a trusted manner. For vNDs, this includes the VS Administrator responsible for configuring the VMs that implement ND functionality. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are assumed to monitor the revocation status of all certificates in the TOE's trust store and to remove any certificate from the TOE’s trust store in case such certificate can no longer be trusted. OE.UPDATES The TOE firmware and software is updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 23 of 67 - Environment Security Objective IT Environment Security Objective Definition OE.ADMIN_CREDENTIALS_SEC URE The Administrator’s credentials (private key) used to access the TOE must be protected on any other platform on which they reside. OE.COMPONENTS_RUNNING For distributed TOEs the Security Administrator ensures that the availability of every TOE component is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. The Security Administrator also ensures that it is checked as appropriate for every TOE component that the audit functionality is running properly. OE.RESIDUAL_INFORMATION The Security Administrator ensures that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. For vNDs, this applies when the physical platform on which the VM runs is removed from its operational environment. OE.VM_CONFIGURATION For vNDs, the Security Administrator ensures that the VS and VMs are configured to o reduce the attack surface of VMs as much as possible while supporting ND functionality (e.g., remove unnecessary virtual hardware, turn off unused inter- VM communications mechanisms), and o correctly implement ND functionality (e.g., ensure virtual networking is properly configured to support network traffic, management channels, and audit reporting). The VS should be operated in a manner that reduces the likelihood that vND operations are adversely affected by virtualization features such as cloning, save/restore, suspend/resume, and live migration. If possible, the VS should be configured to make use of features that leverage the VS’s privileged position to provide additional security functionality. Such features could include malware detection through VM introspection, measured VM boot, or VM snapshot for forensic analysis. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 24 of 67 - 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 5, dated April 2017 and all international interpretations. 5.1 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; • Assignment completed within a selection in the PP: the completed assignment text is indicated with italicized and underlined text; • Refinement made by PP author: Indicated with bold text; • Refinement made by ST author: Indicated with bold and underlined text; • Selection: Indicated with underlined text; • Iteration: Indicated by appending the iteration number in parenthesis, e.g., (1), (2), (3). • Where operations were completed in the NDcPP itself, the formatting used in the NDcPP has been retained. Explicitly stated SFRs are identified by having a label ‘EXT’ after the requirement name for TOE SFRs. Formatting conventions outside of operations and iterations matches the formatting specified within the NDcPP. 5.2 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. Note: Each SFR is applicable to all TOE components except where noted at the end of each SFR. Table 14: 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_GEN_EXT.1 Security Audit Generation FAU_STG_EXT.1 Protected Audit Event Storage FAU_STG_EXT.4 Protected Local Audit Event Storage for Distributed TOEs FCO: Communication FCO_CPC_EXT.1 Component Registration Channel Definition FCS: Cryptographic support FCS_CKM.1 Cryptographic Key Generation (Refined) FCS_CKM.2 Cryptographic Key Establishment (Refined) FCS_CKM.4 Cryptographic Key Destruction FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) FCS_COP.1.1/Hash Cryptographic Operation (Hash Algorithm) FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) FCS_HTTPS_EXT.1 HTTPS Protocol FCS_NTP_EXT.1 NTP Protocol Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 25 of 67 - Class Name Component Identification Component Name FCS_RBG_EXT.1 Random Bit Generation FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.2 TLS Client Protocol with Authentication FCS_TLSS_EXT.1 TLS Server Protocol FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication FIA: Identification and authentication FIA_AFL.1 Authentication Failure Management FIA_PMG_EXT.1 Password Management FIA_UIA_EXT.1 User Identification and Authentication FIA_UAU.7 Protected Authentication Feedback FIA_X509_EXT.1/ITT X.509 Certificate Validation FIA_X509_EXT.1/Rev X.509 Certificate Validation FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.3 X.509 Certificate Requests FMT: Security management FMT_MOF.1/ManualUpdate Management of security functions behaviour FMT_MTD.1/CoreData Management of TSF Data FMT_MTD.1/CryptoKeys Management of TSF Data FMT_SMF.1 Specification of Management Functions FMT_SMR.2 Restrictions on Security Roles FPT: Protection of the TSF FPT_APW_EXT.1 Protection of Administrator Passwords FPT_ITT.1 Basic Internal TSF Data Transfer Protection FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) FPT_STM_EXT.1 Reliable Time Stamps FPT_TST_EXT.1 TSF Testing FPT_TUD_EXT.1 Trusted update FTA: TOE Access FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_SSL.3 TSF-initiated Termination FTA_SSL.4 User-initiated Termination FTA_TAB.1 Default TOE Access Banners FTP: Trusted path/channels FTP_ITC.1 Inter-TSF trusted channel FTP_TRP.1/Admin Trusted Path FTP_TRP.1/Join Trusted Path 5.3 SFRs Drawn from NDcPP 5.3.1 Security audit (FAU) 5.3.1.1 FAU_GEN.1 Audit data generation FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shutdown of the audit functions; b) All auditable events for the not specified level of audit; and c) All administrator actions comprising: • Administrative login and logout (name of user account shall be logged if individual user accounts are required for Administrators). • Changes to TSF data related to configuration changes (in addition to the information that a change occurred it shall be logged what has been changed). Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 26 of 67 - • Generating/import of, changing, or deleting of cryptographic keys (in addition to the action itself a unique key name or key reference shall be logged). • [Resetting passwords (name of related user account shall be logged)]; d) Specifically defined auditable events listed in Table 15. 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 (if applicable), 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 cPP/ST, information specified in column three of Table 15. Table 15: Auditable Events SFR Auditable Event Additional Audit Record Contents FAU_GEN.1 None. None. FAU_GEN.2 None. None. FAU_GEN_EXT.1 None. None. FAU_STG_EXT.1 Configuration of local audit settings. Identity of account making changes to audit configuration. FAU_STG_EXT.4 None. None. FCO_CPC_EXT.1 • Enabling communications between a pair of components. • Disabling communications between a pair of components. Identities of the endpoints pairs enabled or disabled. FCS_CKM.1 None. None. FCS_CKM.2 None. None. FCS_CKM.4 None. None. FCS_COP.1/DataEncryption None. None. FCS_COP.1/SigGen None. None. FCS_COP.1/Hash None. None. FCS_COP.1/KeyedHash None. None. FCS_HTTPS_EXT.1 Failure to establish an HTTPS session. Reason for failure. FCS_NTP_EXT.1 • Configuration of a new time server • Removal of configured time server Identity if new/removed time server FCS_RBG_EXT.1 None. None. FCS_TLSC_EXT.1 Failure to establish an TLS session Reason for failure. FCS_TLSC_EXT.2 None. None. FCS_TLSS_EXT.1 Failure to establish an TLS session Reason for failure. FCS_TLSS_EXT.2 Failure to authentication the client Reason for failure. FIA_AFL.1 Unsuccessful login attempts limit is met or exceeded. Origin of the attempt (e.g., IP address). FIA_PMG_EXT.1 None. None. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 27 of 67 - SFR Auditable Event Additional Audit Record Contents FIA_UIA_EXT.1 All use of the identification and authentication mechanism. Origin of the attempt (e.g., IP address). FIA_UAU.7 None. None. FIA_X509_EXT.1/ITT • Unsuccessful attempt to validate a certificate. • Any addition, replacement or removal of trust anchors in the TOE’s trust store. • Reason for failure of certificate validation. • Identification of certificates added, replaced or removed as trust anchor in the TOE’s trust store. FIA_X509_EXT.1/Rev • Unsuccessful attempt to validate a certificate. • Any addition, replacement or removal of trust anchors in the TOE’s trust store. • Reason for failure of certificate validation. • Identification of certificates added, replaced or removed as trust anchor in the TOE’s trust store. FIA_X509_EXT.2 None. None. FIA_X509_EXT.3 None. None. FMT_MOF.1/ManualUpdate Any attempt to initiate a manual update None. FMT_MTD.1/CoreData None. None. FMT_MTD.1/CryptoKeys None. None. FMT_SMF.1 All management activities of TSF data. None. FMT_SMR.2 None. None. FPT_APW_EXT.1 None. None. FPT_ITT.1 • Initiation of the trusted channel. • Termination of the trusted channel. • Failure of the trusted channel functions. Identification of the initiator and target of failed trusted channels establishment attempt. FPT_SKP_EXT.1 None. None. FPT_STM_EXT.1 Discontinuous changes to time - either Administrator actuated or changed via an automated process. (Note that no continuous changes to time need to be logged. See also application note on FPT_STM_EXT.1) For discontinuous changes to time: The old and new values for the time. Origin of the attempt to change time for success and failure (e.g., IP address). FPT_TST_EXT.1 None. None. FPT_TUD_EXT.1 Initiation of update. result of the update attempt (success or failure) None. FTA_SSL_EXT.1 The termination of a local session by the session locking mechanism. None. FTA_SSL.3 The termination of a remote session by the session locking mechanism. None. FTA_SSL.4 The termination of an interactive session. None. FTA_TAB.1 None. None. FTP_ITC.1 • Initiation of the trusted channel. • Termination of the trusted channel. Identification of the initiator and target of failed trusted Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 28 of 67 - SFR Auditable Event Additional Audit Record Contents • Failure of the trusted channel functions. channels establishment attempt FTP_TRP.1/Admin • Initiation of the trusted path. • Termination of the trusted path. • Failure of the trusted path functions. None. FTP_TRP.1/Join • Initiation of the trusted path. • Termination of the trusted path. • Failure of the trusted path functions. None. 5.3.1.2 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. 5.3.1.3 FAU_GEN_EXT.1 Security Audit Generation FAU_GEN_EXT.1.1 The TSF shall be able to generate audit records for each TOE component. The audit records generated by the TSF of each TOE component shall include the subset of security relevant audit events which can occur on the TOE component. 5.3.1.4 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 according to FTP_ITC.1. FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. In addition [ • The TOE shall be a distributed TOE that stores audit data on the following TOE components: [Manager, FC, and FS]. FAU_STG_EXT.1.3 The TSF shall maintain a [log file] of audit records in the event that an interruption of communication with the remote audit server occurs. FAU_STG_EXT.1.4 The TSF shall be able to store [persistent] audit records locally with a minimum storage size of [5MB]. FAU_STG_EXT.1.5 The TSF shall [overwrite previous audit records according to the following rule: [oldest records will be overwritten], [no other action]] when the local storage space for audit data is full. FAU_STG_EXT.1.6 The TSF shall provide the following mechanisms for administrative access to locally stored audit records [manual export, ability to view locally]. 5.3.1.5 FAU_STG_EXT.4 Protected Local Audit Event Storage for Distributed TOEs FAU_STG_EXT.4.1 The TSF of each TOE component which stores security audit data locally shall perform the following actions when the local storage space for audit data is full: [ Component: Action:[ Manager Overwrite previous audit records according to the following rule: [oldest records will be overwritten when the local storage space for audit data is full] Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 29 of 67 - FC Overwrite previous audit records according to the following rule: [oldest records will be overwritten when the local storage space for audit data is full] FS Overwrite previous audit records according to the following rule: [oldest records will be overwritten when the local storage space for audit data is full] ]]. 5.3.2 Communication Partner Control (FCO) 5.3.2.1 FCO_CPC_EXT.1 Component Registration Channel Definition FCO_CPC_EXT.1.1 The TSF shall require a Security Administrator to enable communications between any pair of TOE components before such communication can take place. FCO_CPC_EXT.1.2 The TSF shall implement a registration process in which components establish and use a communications channel that uses [ • A channel that meets the secure registration channel requirements in FTP_TRP.1/Join] for at least TSF data. FCO_CPC_EXT.1.3 The TSF shall enable a Security Administrator to disable communications between any pair of TOE components. 5.3.3 Cryptographic Support (FCS) 5.3.3.1 FCS_CKM.1 Cryptographic Key Generation FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm: [ • RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 or FIPS PUB 186-5, “Digital Signature Standard (DSS)”, A.1; • ECC schemes using “NIST curves” [P-256, P-384, P-521] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.4 or FIPS PUB 186-5, “Digital Signature Standard (DSS)”, Appendix A.2, or ISO/IEC 14888-3, “IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms”, Section 6.6.; • FFC Schemes using ‘safe-prime’ groups that meet the following: “NIST Special Publication 800- 56A Revision 3, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” and [RFC 7919]. ] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. 5.3.3.2 FCS_CKM.2 Cryptographic Key Establishment FCS_CKM.2.1 The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: [ Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 30 of 67 - • Elliptic curve-based key establishment schemes that meet the following: NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”; • FFC Schemes using “safe-prime” groups that meet the following: NIST Special Publication 800- 56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” and [groups listed in RFC 7919]. ] that meets the following: [assignment: list of standards]. 5.3.3.3 FCS_CKM.4 Cryptographic Key Destruction FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method • For plaintext keys in volatile storage, the destruction shall be executed by a [destruction of reference to the key directly followed by a request for garbage collection]; • For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation of an interface provided by a part of the TSF that [ o instructs a part of the TSF to destroy the abstraction that represents the key] that meets the following: No Standard. 5.3.3.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1.1/DataEncryption The TSF shall perform encryption/decryption in accordance with a specified cryptographic algorithm AES used in [GCM] mode and cryptographic key sizes [128 bits, 256 bits] that met the following: AES as specified in ISO 18033-3, [GCM as specified in ISO 19772]. 5.3.3.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification) FCS_COP.1.1/SigGen The TSF shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm [ • RSA Digital Signature Algorithm, • Elliptic Curve Digital Signature Algorithm ] and cryptographic key sizes [ • For RSA: modulus 2048, and 4096 bits, • For ECDSA: 256, 384, and 521 bits ] that meet the following: [ • For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1 v2.1 or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 5.4 using PKCS #1 v2.2 Signature Schemes RSASSA-PSS and/or RSASSAPKCS2v1_5; ISO/IEC 9796-2, Digital Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 31 of 67 - signature scheme 2 or Digital Signature scheme 3, • For ECDSA schemes implementing [P-256, P-384, P-521] curves that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 6 and Appendix D, Implementing “NIST Recommended” curves; or FIPS PUB 186-5, "Digital Signature Standard (DSS)", Section 6 and NIST SP 800-186 Section 3.2.1, Implementing Weierstrass curves; or ISO/IEC 14888-3, "IT Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms", Section 6.6. ] 5.3.3.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) FCS_COP.1.1/Hash The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] and cryptographic key sizes [assignment: cryptographic key sizes] and message digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC 10118-3:2004. 5.3.3.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) FCS_COP.1.1/KeyedHash The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC- SHA-512] and cryptographic key sizes [160-bit, 256-bit, 384-bit, 256-bit, 512-bit] and message digest sizes [160, 256, 384, 512] bits that meet the following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”. 5.3.3.8 FCS_HTTPS_EXT.1 HTTPS Protocol Note: This SFR applies only to the Manager component of the TOE. FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818. FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS protocol using TLS. 5.3.3.9 FCS_NTP_EXT.1 NTP Protocol FCS_NTP_EXT.1.1 The TSF shall use only the following NTP version(s) [NTP v4 (RFC 5905)]. FCS_NTP_EXT.1.2 The TSF shall update its system time using [selection: • Authentication using [SHA1] as the message digest algorithm(s); ]. FCS_NTP_EXT.1.3 The TSF shall not update NTP timestamp from broadcast and/or multicast addresses. FCS_NTP_EXT.1.4 The TSF shall support configuration of at least three (3) NTP time sources in the Operational Environment. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 32 of 67 - 5.3.3.10 FCS_RBG_EXT.1 Random Bit Generation FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in accordance with ISO/IEC 18031:2011 using [HMAC_DRBG (SHA-256)]. FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy from [[1] software-based noise source] with minimum of [256 bits] of entropy at least equal to [the greatest security strength, according to ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash Functions”]. 5.3.3.11 FCS_TLSC_EXT.1 TLS Client Protocol FCS_TLSC_EXT.1.1 The TSF shall implement [TLS 1.3 (RFC 8446), TLS 1.2 (RFC 5246)] and reject all other TLS and SSL versions. The TLS implementation will support the following ciphersuites: [ • Supported ciphersuites for TLS 1.2: o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 o TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 • Supported ciphersuites for TLS 1.3: o TLS_AES_128_GCM_SHA256 o TLS_AES_256_GCM_SHA384 o TLS_AES_128_CCM_SHA256 ]. FCS_TLSC_EXT.1.2 The TSF shall verify that the presented identifier matches [the reference identifier per RFC 6125 section 6, IPv4 addresses in CN or SAN]. FCS_TLSC_EXT.1.3 The TSF shall not establish a trusted channel if the server certificate is invalid. The TSF shall also [ • without any administrator override mechanism. ]. FCS_TLSC_EXT.1.4 The TSF shall [present the Supported Groups Extension with the following curves/groups: [ • Supported groups for FTP_ITC (syslog-over-TLS and LDAP-over-TLS): o secp256r1 o secp384r1 o secp521r1 o ffdhe3072 o ffdhe4096 • Supported groups for FPT_ITT: o secp256r1 o secp384r1 o secp521r1 o ffdhe2048 o ffdhe3072 o ffdhe4096 Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 33 of 67 - ] and no other curves/groups] in the Client Hello. FCS_TLSC_EXT.1.5 The TSF shall [ • present the signature_algorithms extension with support for the following algorithms: [ o rsa_pkcs1 with sha256(0x0401), o rsa_pkcs1 with sha384(0x0501), o rsa_pkcs1 with sha512(0x0601), o ecdsa_secp256r1 with sha256(0x0403), o ecdsa_secp384r1 with sha384(0x0503), o ecdsa_secp521r1 with sha512(0x0603), o rsa_pss_rsae with sha256(0x0804), o rsa_pss_rsae with sha384(0x0805), o rsa_pss_rsae with sha512(0x0806), o rsa_pss_pss with sha256(0x0809), o rsa_pss_pss with sha384(0x080a), o rsa_pss_pss with sha512(0x080b) o ] and no other algorithms; ]. FCS_TLSC_EXT.1.6 The TSF [does not provide] the ability to configure the list of supported ciphersuites as defined in FCS_TLSC_EXT.1.1. FCS_TLSC_EXT.1.7 The TSF shall prohibit the use of the following extensions: • Early data extension • post-handshake client authentication according to RFC 8446, section 4.2.6. FCS_TLSC_EXT.1.8 The TSF shall [not use PSKs]. FCS_TLSC_EXT.1.9 The TSF shall [for FPT_ITT support TLS 1.2 secure renegotiation through use of the “renegotiation_info” TLS extension in accordance with RFC 5746, for all other uses of TLS 1.2 and all uses of TLS 1.3 reject [TLS 1.2, TLS 1.3] renegotiation attempts]. 5.3.3.12 FCS_TLSC_EXT.2 TLS Client Protocol with Authentication Note: This SFR does not apply to LDAP over TLS, which is only applicable to the Manager component of the TOE. FCS_TLSC_EXT.2.1 The TSF shall support TLS communication with mutual authentication using X.509v3 certificates. 5.3.3.13 FCS_TLSS_EXT.1 TLS Server Protocol FCS_TLSS_EXT.1.1 The TSF shall implement [TLS 1.3 (RFC 8446), TLS 1.2 (RFC 5246)] and reject all other TLS and SSL versions. The TLS implementation will support the following ciphersuites: [ • Supported ciphersuites for TLS 1.2: o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 • Supported ciphersuites for TLS 1.3: o TLS_AES_128_GCM_SHA256 o TLS_AES_256_GCM_SHA384 o TLS_AES_128_CCM_SHA256 ]. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 34 of 67 - FCS_TLSS_EXT.1.2 The TSF shall authenticate itself using X.509 certificate(s) using [RSA with key size [2048, 4096] bits; ECDSA over NIST curves [secp256r1, secp384r1, secp521r1] and no other curves]. FCS_TLSS_EXT.1.3 The TSF shall perform key exchange using [ • EC Diffie-Hellman key agreement over NIST curves [secp256r1, secp384r1, secp521r1] and no other curves; • Diffie-Hellman parameters [ffdhe2048, ffdhe3072 and ffdhe4096]; ]. FCS_TLSS_EXT.1.4 The TSF shall support [session resumption based on session IDs according to RFC 5246 (TLS 1.2), session resumption based on session tickets according to RFC 5077 (TLS 1.2), session resumption according to RFC 8446 (TLS 1.3)]. FCS_TLSS_EXT.1.5 The TSF [does not provide] the ability to configure the list of supported ciphersuites as defined in FCS_TLSS_EXT.1.1. FCS_TLSS_EXT.1.6 The TSF shall prohibit the use of the following extensions: • Early data extension FCS_TLSS_EXT.1.7 The TSF shall [only use PSKs in TLS 1.3 session resumption with forward secrecy]. FCS_TLSS_EXT.1.8 The TSF shall [reject [TLS 1.2, TLS 1.3] renegotiation attempts]. 5.3.3.14 FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication Note: This SFR does not apply to the Manager WebUI (for remote administration). FCS_TLSS_EXT.2.1 The TSF shall support TLS communication with mutual authentication of TLS clients using X.509v3 certificates and shall [ • reject the connection if the client either does not provide a client certificate at all or the client certificate cannot be successfully validated by the TOE (except for override mechanisms that might be defined in FCS_TLSS_EXT.2.2) ('hard fail') ]. FCS_TLSS_EXT.2.2 When establishing a trusted channel, by default the TSF shall not establish a trusted channel if the client certificate is invalid. The TSF shall also [ • not implement any administrator override mechanism ]. FCS_TLSS_EXT.2.3 The TSF shall not establish a trusted channel if the identifier contained in a certificate does not match the expected identifier for the client. If the identifier is a Fully Qualified Domain Name (FQDN), then the TSF shall match the identifiers according to RFC 6125, otherwise the TSF shall parse the identifier from the certificate and match the identifier against the expected identifier of the client as described in the TSS. FCS_TLSS_EXT.2.4 The TSF shall present a [TLS 1.2, TLS 1.3] Certificate Request message containing the following algorithms: [ • rsa_pkcs1 with sha256(0x0401), Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 35 of 67 - • rsa_pkcs1 with sha384(0x0501), • rsa_pkcs1 with sha512(0x0601), • ecdsa_secp256r1 with sha256(0x0403), • ecdsa_secp384r1 with sha384(0x0503), • ecdsa_secp521r1 with sha512(0x0603), • rsa_pss_rsae with sha256(0x0804), • rsa_pss_rsae with sha384(0x0805), • rsa_pss_rsae with sha512(0x0806), • rsa_pss_pss with sha256(0x0809), • rsa_pss_pss with sha384(0x080a), • rsa_pss_pss with sha512(0x080b) ] and no other algorithms. 5.3.4 Identification and authentication (FIA) 5.3.4.1 FIA_AFL.1 Authentication Failure Management Note: This SFR applies only to the Manager component of the TOE. FIA_AFL.1.1 The TSF shall detect when an Administrator configurable positive integer within [1-10] unsuccessful authentication attempts occur related to Administrators attempting to authenticate remotely using a password. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the TSF shall [prevent the offending Administrator from successfully establishing a remote session using any authentication method that involves a password until an Administrator defined time period has elapsed]. 5.3.4.2 FIA_PMG_EXT.1 Password Management FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for administrative passwords: a) Passwords shall be able to be composed of any combination of upper and lower case letters, numbers, and the following special characters: [“!”, “@”, “#”, “$”, “%”,“(“, “)”, [“<”, “>”, “.”, “?”, “/”, “’”, “””, “\”, “|”, “:”, “;”, “`”, “~”, “-“, “_”, “+”, “=”, “{”, “}”, “[“, and “]”]]; b) Minimum password length shall be configurable to between [8] and [256] characters. 5.3.4.3 FIA_UIA_EXT.1 User Identification and Authentication 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; Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 36 of 67 - • [no other actions] 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_UIA_EXT.1.3 The TSF shall provide the following remote authentication mechanisms [Web GUI password] and [external authentication server]. The TSF shall provide the following local authentication mechanisms [password-based]. FIA_UIA_EXT.1.4 The TSF shall authenticate any administrative user’s claimed identity according to each authentication mechanism specified in FIA_UIA_EXT.1.3. 5.3.4.4 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. 5.3.4.5 FIA_X509_EXT.1/ITT X.509 Certificate Validation FIA_X509_EXT.1.1/ITT The TSF shall validate certificates in accordance with the following rules: • RFC 5280 certificate validation and certification path validation supporting a minimum path length of two certificates. • The certification path must terminate with a trusted CA certificate designated as a trust anchor. • The TSF shall validate a certification path by ensuring that all CA certificates in the certification path contain the basicConstraints extension with the CA flag set to TRUE. • The TSF shall validate the revocation status of the certificate using [no revocation method] • The TSF shall validate the extendedKeyUsage field according to the following rules: o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. FIA_X509_EXT.1.2/ITT The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. 5.3.4.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation FIA_X509_EXT.1.1/Rev The TSF shall validate certificates in accordance with the following rules: • RFC 5280 certificate validation and certification path validation supporting a minimum path length of three certificates. • The certification path must terminate with a trusted CA certificate designated as a trust anchor. • The TSF shall validate a certification path by ensuring that all CA certificates in the certification path contain the basicConstraints extension with the CA flag is set to TRUE. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 37 of 67 - • The TSF shall validate the revocation status of the certificate using [the Online Certificate Status Protocol (OCSP) as specified in RFC 6960, a Certificate Revocation List (CRL) as specified in RFC 5280 Section 6.3] • The TSF shall validate the extendedKeyUsage field according to the following rules: o Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. o Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. o Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. o OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. FIA_X509_EXT.1.2/Rev The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE. 5.3.4.7 FIA_X509_EXT.2 X.509 Certificate Authentication FIA_X509_EXT.2.1 The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [TLS], and [code signing for system software updates]. FIA_X509_EXT.2.2 When the TSF cannot establish a connection to determine the validity of a certificate, the TSF shall [not accept the certificate]. 5.3.4.8 FIA_X509_EXT.3 X.509 Certificate Requests FIA_X509_EXT.3.1 The TSF shall generate a Certificate Request Message as specified by RFC 2986 and be able to provide the following information in the request: public key and [Common Name, Organization, Organizational Unit, Country]. FIA_X509_EXT.3.2 The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response. 5.3.5 Security management (FMT) 5.3.5.1 FMT_MOF.1/ManualUpdate Management of security functions behaviour Note: This SFR applies only to the Manager component of the TOE. FMT_MOF.1.1/ManualUpdate The TSF shall restrict the ability to enable the functions to perform manual update to Security Administrators. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 38 of 67 - 5.3.5.2 FMT_MTD.1/CoreData Management of TSF Data FMT_MTD.1.1/CoreData The TSF shall restrict the ability to manage the TSF data to the Security Administrators. 5.3.5.3 FMT_MTD.1/CryptoKeys Management of TSF data Note: This SFR applies only to the Manager component of the TOE. FMT_MTD.1.1/CryptoKeys The TSF shall restrict the ability to manage the cryptographic keys to Security Administrators. 5.3.5.4 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 remotely; • Ability to configure the access banner; • Ability to configure the session inactivity time before session termination; • Ability to update the TOE, and to verify the updates using digital signature capability prior to installing those updates; • [ o Ability to modify the behaviour of the transmission of audit data to an external IT entity; o Ability to manage the cryptographic keys; o Ability to configure the cryptographic functionality; o Ability to configure the interaction between TOE components; o Ability to configure NTP; o Ability to configure the reference identifier for the peer; o Ability to manage the TOE's trust store and designate X509.v3 certificates as trust anchors; o Ability to generate Certificate Signing Request (CSR) and process CA certificate response; o Ability to administer the TOE locally; o Ability to configure the local session inactivity time before session termination or locking; o Ability to configure the authentication failure parameters for FIA_AFL.1; ]. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 39 of 67 - 5.3.5.5 FMT_SMR.2 Restrictions on Security Roles FMT_SMR.2.1 The TSF shall maintain the roles: • Security Administrator. FMT_SMR.2.2 The TSF shall be able to associate users with roles. FMT_SMR.2.3 The TSF shall ensure that the conditions • The Security Administrator role shall be able to administer the TOE remotely are satisfied. 5.3.6 Protection of the TSF (FPT) 5.3.6.1 FPT_APW_EXT.1 Protection of Administrator Passwords FPT_APW_EXT.1.1 The TSF shall store administrative passwords in non-plaintext form. FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext administrative passwords. 5.3.6.1 FPT_ITT.1 Basic internal TSF data transfer protection FPT_ITT.1.1 The TSF shall protect TSF data from disclosure and detect its modification when it is transmitted between separate parts of the TOE through the use of [TLS]. 5.3.6.1 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. 5.3.6.2 FPT_STM_EXT.1 Reliable time stamps FPT_STM_EXT.1.1 The TSF shall be able to provide reliable time stamps for its own use. FPT_STM_EXT.1.2 The TSF shall [synchronise time with an NTP server]. 5.3.6.3 FPT_TST_EXT.1: TSF Testing FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests: • During initial start-up (on power on) to verify the integrity of the TOE firmware and software; • Prior to providing any cryptographic service and [periodically during normal operation] to verify correct operation of cryptographic implementation necessary to fulfil the TSF; • [no other] self-tests. to demonstrate the correct operation of the TSF. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 40 of 67 - 5.3.6.4 FPT_TUD_EXT.1 Trusted Update FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the currently executing version of the TOE firmware/software and [no other TOE firmware/software version]. FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually initiate updates to TOE firmware/software and [no other update mechanism]. FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates to the TOE using a [digital signature] prior to installing those updates. 5.3.7 TOE Access (FTA) 5.3.7.1 FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [ • terminate the session] after a Security Administrator-specified time period of inactivity. 5.3.7.2 FTA_SSL.3 TSF-initiated Termination Note: This SFR applies only to the Manager component of the TOE. FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a Security Administrator- configurable time interval of session inactivity. 5.3.7.3 FTA_SSL.4 User-initiated Termination FTA_SSL.4.1 The TSF shall allow user Administrator-initiated termination of the user’s Administrator’s own interactive session. 5.3.7.4 FTA_TAB.1 Default TOE Access Banners FTA_TAB.1.1 Before establishing a an administrative user session the TSF shall display a Security Administrator-specified advisory notice and consent warning message regarding unauthorized use of the TOE. 5.3.8 Trusted Path/Channels (FTP) 5.3.8.1 FTP_ITC.1 Inter-TSF trusted channel FTP_ITC.1.1 The TSF shall be capable of using [TLS] to provide a trusted communication channel between itself and another trusted IT product authorized IT entities supporting the following capabilities: audit server, [authentication server] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure and detection of modification of the channel data. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 41 of 67 - FTP_ITC.1.2 The TSF shall permit [the TSF, the authorized IT entities] to initiate communication via the trusted channel. FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [syslog over TLS, LDAP over TLS]. 5.3.8.1 FTP_TRP.1/Admin Trusted Path Note: This SFR applies only to the Manager component of the TOE. FTP_TRP.1.1/Admin The TSF shall be capable of using [TLS, HTTPS] to provide a communication path between itself and authorized 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 and provides detection of modification of the channel data. FTP_TRP.1.2/Admin The TSF shall permit remote Administrators users to initiate communication via the trusted path. FTP_TRP.1.3/Admin The TSF shall require the use of the trusted path for initial Administrator authentication and all remote administration actions. 5.3.8.1 FTP_TRP.1/Join Trusted Path FTP_TRP.1.1/Join The TSF shall provide a communication path between itself and a joining component [selection: remote, local] users that is logically distinct from other communication paths and provides assured identification of [both joining component and TSF endpoint] its end points and protection of the communicated data from modification and [disclosure]. FTP_TRP.1.2/Join The TSF shall permit [the joining component] to initiate communication via the trusted path. FTP_TRP.1.3/Join The TSF shall require the use of the trusted path for joining components to the TSF under environmental constraints identified in [none (no environmental constraints)]. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 42 of 67 - 5.4 TOE SFR Dependency Rationale The NDcPP contains all the requirements claimed in this Security Target. As such the dependencies are not applicable since the PP itself has been approved. 5.5 Security Assurance Requirements 5.5.1 SAR Requirements The TOE assurance requirements for this ST are taken directly from the NDcPP and derived from Common Criteria Version 3.1, Revision 5. The assurance requirements are summarized in the table below. Table 16: Assurance Measures Assurance Class Components Components Description Security Target (ASE) ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.1 Security objectives for the operational environment ASE_REQ.1 Stated security requirements ASE_SPD.1 Security Problem Definition ASE_TSS.1 TOE summary specification Development (ADV) ADV_FSP.1 Basic Functional Specification Guidance documents (AGD) AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative User guidance Life cycle support (ALC) ALC_CMC.1 Labelling of the TOE ALC_CMS.1 TOE CM coverage ALC_FLR.2 Flaw Reporting Procedures Tests (ATE) ATE_IND.1 Independent testing - sample Vulnerability assessment (AVA) AVA_VAN.1 Vulnerability survey 5.5.2 Security Assurance Requirements Rationale The Security Assurance Requirements (SARs) in this Security Target represent the SARs identified in the NDcPP. As such, the NDcPP SAR rationale is deemed acceptable since the PP itself has been validated. 5.6 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. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 43 of 67 - Table 17: Assurance Measures Component How requirement will be met ADV_FSP.1 There are no specific assurance activities associated with ADV_FSP.1. The requirements on the content of the functional specification information are implicitly assessed by virtue of the other assurance activities being performed. The functional specification is comprised of the information contained in the AGD_OPE and AGD_PRE documentation, coupled with the information provided in the TSS of the ST. The assurance activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary. 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.1 The AGD and ST implicitly meet this assurance requirement. The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. ALC_CMS.1 ALC_FLR.2 Cisco has established procedures for accepting and acting upon all reports of security flaws and requests for corrections to those flaws and provides flaw remediation guidance addressed to TOE users. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_IND.1 Cisco provides the TOE for testing. AVA_VAN.1 Cisco provides the TOE for testing. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 44 of 67 - 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 18: TOE SFR Measures TOE SFRs How the SFR is Met FAU_GEN.1 FAU_GEN_EXT.1 The TOE generates an audit record that is stored internally within the TOE whenever an audited event occurs. Each TOE component generates its own audit messages, and stores its own audit messages locally (local audit is not configurable). None of the TOE components transmit their audit messages to other TOE components (they each transmit to syslog servers as noted for FAU_STG_EXT.1). The types of events that cause audit records to be generated include, cryptography related events, identification and authentication related events, and administrative events (the specific events and the contents of each audit record are listed in Table 15). Audit messages contain enough detail to identify the origin of the event, when the event occurred, where the event occurred, the outcome of the event, and the type of event that occurred. Additionally, the startup and shutdown of the audit functionality is audited. For audit messages related to management of cryptographic keys, the audit message details include the name of the certificate associated with the key (keys cannot be managed independently from the certificates with which they’re associated). Example audit message (clock update): AuditLogger[pid]: AuditLogger: osaxsd/pid,1100,,root (0),localhost,1,System time updated from [] to [current-date/time] FAU_GEN.2 The TOE ensures 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. Example audit messages: Account ‘sysadmin’ logged out from console: I&A User Logout The user has logged out of Console sysadmin(75) 127.0.0.1 osaxsd() Yes Account ‘admin’ logged out from remote GUI: I&A User Logout The user has logged out admin svc-token-authority(1) Yes Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 45 of 67 - TOE SFRs How the SFR is Met FAU_STG_EXT.1 FAU_STG_EXT.4 Each TOE component is configured to export syslog records to a specified, external syslog server. The TOE uses TLS to protect communications with external syslog server. The TOE transmits its audit events in real time to all configured syslog servers at the same time logs are written to the local log buffer. When the local audit data storage on each TOE component is full, the TOE component will overwrite the oldest stored audit records when writing new audit records. Each TOE component stores its own audit records and each TOE component has the same audit retention rules: each TOE component maintains a log file (the local audit data storage) that stores up to 5MB of log messages (the average message size on the TOE is ~180 bytes, so each 5MB file contains an average of ~27,000 messages.), and when the 5MB limit is reached the entire log is overwritten with a new log. A log rotation job runs nightly; and if the active log has grown to 5 MB, it is rotated. This results in the oldest records being purged to allow space for new records to be written. No administrative interface allows Administrators to clear the local audit logs or to modify the contents of local audit logs. FCO_CPC_EXT.1 In order for a new TOE component to become part of the distributed TOE it must successfully complete a registration process. The Manager is the management server within this distributed TOE and each other appliance type (FC, and FS) must individually register with the Manager in order to become part of the TOE. Registration of a new appliance cannot be initiated by the Manager, registration is initiated by the administrator performing the initial configuration of the FC, or FS. During the initial configuration process the administrator is asked whether the new appliance will be managed by a Manager, and after answering affirmatively that administrator is prompted to provide the IP address or hostname of the Manager and a valid Manager administrator username and password to authenticate to the Manager. During that initial TLS session the Manager and the new appliance exchange their unique X.509 certificates. Once the certificates have been exchanged, the new appliance has been joined with the Manager and all subsequent (automated) communications between the Manager and managed appliances use X.509 certificates for authentication in accordance with FPT_ITT.1 and FIA_X509_EXT.1/ITT. The Manager administrator can de-register an appliance by selecting "Remove This Appliance" from the Central Management page of the WebUI on the Manager. A local administrator of the managed appliance can remove the registration by selecting “RemoveAppliance” from the System Configuration menu. Either of these actions, whether initiated from the Manager or from the managed appliance, will result in each TOE component deleting the device association from its local configuration, and no further TSF Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 46 of 67 - TOE SFRs How the SFR is Met data will be exchanged between the appliances without completing a new registration process. FCS_CKM.1 FCS_CKM.2 The TOE generates asymmetric keys in accordance with the RSA schemes using key sizes of 4096-bit that are conformant to the FIPS Pub 186-4, Appendix B.3. In addition, ECC schemes are used with P- 256, P-384, and P-521. The TOE can create a RSA public-private key pair that can be used to generate a Certificate Signing Request (CSR). Via offline CSR transfer the TOE can provide its CSR for a Certificate Authority (CA) generate a certificate, and the TOE’s signed certificate can be imported. The key pair generation portions of "The RSA Validation System" for FIPS 186-4 were used as a guide in testing the FCS_CKM.1 during the FIPS validation. The TOE implements FFC key establishment schemes in TLS. The FFC key generation and key establishment (both using ‘safe-primes’ groups) meets NIST Special Publication 800-56A Revision 3. ECC is used for ECDH key exchange for TLS. Scheme SFR Services RSA FCS_TLSC_EXT.1 LDAP over TLS RSA FCS_TLSC_EXT.2 Syslog over TLS Distributed TOE communication RSA FCS_TLSS_EXT.1 HTTPS Remote Administration RSA FCS_TLSS_EXT.2 Distributed TOE communication When using TLSv1.2: ECC (P-256, P-384, P-521) When using TLSv1.3: ECC (P-256, P-384, P-521) FFC (ffdhe2048, ffdhe3072, ffdhe4096) FCS_TLSC_EXT.1 LDAP over TLS FCS_TLSC_EXT.2 Syslog over TLS Distributed TOE communication FCS_TLSS_EXT.1 HTTPS Remote Administration FCS_TLSS_EXT.2 Distributed TOE communication FFC FCS_TLSC_EXT.1 LDAP over TLS FFC FCS_TLSC_EXT.2 Syslog over TLS Distributed TOE communication FFC FCS_TLSS_EXT.1 HTTPS Remote Administration FFC FCS_TLSS_EXT.2 Distributed TOE communication FCS_CKM.4 The TOE meets all requirements specified in FIPS 140-3 for destruction of keys and Critical Security Parameters (CSPs). See Table 19 for more information on the key destruction. FCS_COP.1/DataEncryption The TOE provides symmetric encryption and decryption capabilities using AES in GCM mode (128 bits, 256 bits) as described in ISO 19772. AES is implemented in TLS. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 47 of 67 - TOE SFRs How the SFR is Met Through the implementation of the FIPS validated cryptographic module, the TOE provides AES encryption and decryption in support of TLS for secure communications. FCS_COP.1/SigGen The TOE provides cryptographic signature services using RSA Digital Signature Algorithm with key sizes of 2048 and 4096 bits as specified in FIPS PUB 186-4, “Digital Signature Standard”. TOE components: authenticate their own software updates (relevant to FPT_TUD_EXT.1.3) using RSA 2048-bit digital signatures; authenticate each other (relevant to FPT_ITT.1) using RSA 4096-bit certificates; and use all support all RSA key sizes and ECDSA curves listed in FCS_COP.1/SigGen for other TLS communications (relevant to FTP_ITC.1 and FTP_TRP.1). Through the implementation of the FIPS validated cryptographic module, the TOE provides cryptographic signatures in support of TLS for secure communications. Management of the cryptographic algorithms is provided through the GUI with auditing of those commands. The TOE provides the RSA option in support of TLS key establishment. FCS_COP.1/Hash The TOE provides cryptographic hashing services using SHA-1, SHA- 256, SHA-384, and SHA-512 as specified in : ISO/IEC 9797-2:2011, Section 7. Through the implementation of the FIPS validated cryptographic module, the TOE provides Secure Hash Standard (SHS) hashing in support of TLS, for secure communications. Management of the cryptographic algorithms is provided through the GUI with auditing of those commands. FCS_COP.1/KeyedHash The TOE provides keyed-hashing message authentication services using HMAC-SHA-1 HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512, with key sizes 160, 256, 384 and 512-bits, and message digest sizes 160, 256, 384 and 512-bits as specified in ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”. Through the implementation of the FIPS validated cryptographic module, the TOE provides SHS hashing and HMAC message authentication in support TLS for secure communications. Management of the cryptographic algorithms is provided through the GUI with auditing of those commands. SHS hashing and HMAC message authentication is used in the establishment of TLS/HTTPS sessions. FCS_HTTPS_EXT.1 Note: This SFR applies only to the Manager component of the TOE. The TOE implements HTTPS over TLS as specified in RFC 2818 and FCS_TLSS_EXT.1. The TSF HTTPS implementation authenticates the TOE to the remote client with an X.509 certificate. System Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 48 of 67 - TOE SFRs How the SFR is Met Administrators manage the TOE identity certificates using the TOE GUI. The TSF HTTPS implementation performs server based authentication using a server X.509v3 certificate to establish the TLS session. The TSF HTTPS implementation does not require client authentication at the TLS level but presents the Web interface logon page for administrative users to authenticate using their name and password. FCS_NTP_EXT.1 NTP functionality can be enabled using the Central Management (WebUI) on the Manager to configure each appliance (via Appliance Manager > Appliance Configuration > Network Services > NTP Server). Each appliance can be configured to use up to three NTP servers (NTPv4) and authenticating each server with a unique Key ID and Key Value (SHA1). The TOE will not use any NTP updates from broadcast or multicast addresses. FCS_RBG_EXT.1 The TOE implements a NIST-approved HMAC Deterministic Random Bit Generator (DRBG) seeded by a software-based entropy source within the TOE. The DRBG is seeded with a minimum of 256 bits of full entropy, which is at least equal to the greatest security strength of the keys and hashes that the DRBG will generate. FCS_TLSC_EXT.1 FCS_TLSC_EXT.2 The TOE uses TLS clients for: • Transmitting syslog over TLS. • Interconnections among distributed TOE components. • Connecting to LDAP servers over TLS. The TLS clients of each TOE component support mutual authentication (FCS_TLSC_EXT.2) for connections to the syslog server (FTP_ITC.1), and for interconnections between distributed TOE components (FPT_ITT.1). Mutual authentication is not supported for TLS connections to LDAP servers (FTP_ITC.1). The TOE only supports TLSv1.3 and TLSv1.2 with AES 128 or 256 bit symmetric ciphers in GCM mode, in conjunction with SHA (SHA256, and SHA384), RSA, ECDHE (NIST curves supported are secp256r1, secp384r1, and secp521r1), finite-field DHE using ffdhe named groups as specified in RFC 7919, and ECDSA. The supported groups presented in the Client Hello are connection-type specific: for FTP_ITC connections (syslog-over-TLS and LDAP-over-TLS) the TOE presents ffdhe3072 and ffdhe4096; for FPT_ITT inter-appliance connections the TOE presents ffdhe2048, ffdhe3072, andffdhe4096. These supported groups are presented by default and this behavior is not configurable. The following TLS cipher suites are implemented by the TOE in CC mode and are not configurable (other than by enabling CC mode): Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 49 of 67 - TOE SFRs How the SFR is Met • Ciphersuites relevant to FTP_ITC and FCS_TLSC_EXT.1, for syslog over TLS (client only, from each TOE component) are listed in section 5.3.3.11 of this document. • Ciphersuites relevant to FPT_ITT, FCS_TLSC_EXT.1, and FCS_TLSS_EXT.1 (client and server, where each TOE component can operate as the client and/or server) are as listed in sections 5.3.3.11 and 5.3.3.13 of this document. • Ciphersuites relevant to FTP_ITC and FCS_TLSC_EXT.1 for LDAP over TLS (client only, from the Manager TOE component only) are listed in section 5.3.3.11 of this document. While the FP (see section 7.2) supports additional cipher suites (for example, RSA_3DES_EDE_CBC_SHA, RSA_DES_CBC_SHA, RSA_RC4_128_MD5, RSA_RC4_128_SHA, etc.), they are all disabled while operating in CC mode. If the remote TLS server does not support TLSv1.2 or TLSv1.3, the TLS connection will fail. The TOE TLS clients support the signature_algorithms extension with the algorithms listed in FCS_TLSC_EXT.1.5, and that behavior is not configurable. The TOE TLS clients do not support the signature_algorithms_cert extension, and that behavior is not configurable. When in CC mode and the TOE acts as a TLS client connecting to a syslog server (syslog-over-TLS) the TOE will verify the server Common Name (CN) and/or Subject Alternative Name (SAN) against the reference identity. For all LDAP-over-TLS connections and all TLS connections between TOE components the TOE will verify the reference identifier in accordance with RFC 6125 section 6. When an IP address is used as the reference identifier (supported for LDAP-over-TLS and syslog-over-TLS) the TOE converts the text representations (dotted-decimal notation) of the locally-stored IP address and the IP addresses found in the CN to binary (hex-based) representations in network byte order, enforcing the canonical format per RFC 3986. For TLS connections from the TOE to syslog servers: use of wildcards is not supported; certificate pinning is not supported. For TLS connections between TOE components: use of wildcards is not supported; certificate pinning is not supported; and the TOE will reject the TLS connection if the SAN is not present in the remote endpoint’s certificate. For TLS connections to LDAP servers: use of wildcards is supported; certificate pinning is not supported. In any case (connection to a syslog or LDAP servers, or connections among TOE components), if verification fails the TLS connection will not be established. The key agreement parameters of the key exchange message for TLSv1.3 are specified in the RFC 8446 (section 4.1) and the TOE is conformant to the RFC. The key agreement parameters of the server Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 50 of 67 - TOE SFRs How the SFR is Met key exchange message for TLSv1.2 are specified in the RFC 5246 (section 7.4.3) and the TOE is conformant to the RFC. TLS session renegotiation is supported in all TLS clients within the TOE. For the TOE TLS clients used for inter-appliance communication (relevant to FPT_ITT) the TOE supports TLS 1.2 secure renegotiation through use of the “renegotiation_info” TLS extension in accordance with RFC 5746. For all other uses (relevant to FTP_ITC) of TLS (TLS 1.2 and TLS 1.3) the TOE TLS clients will reject renegotiation attempts. FCS_TLSS_EXT.1 FCS_TLSS_EXT.2 An authorized administrator can initiate inbound TLSv1.3 or TLSv1.2 connections using the web based GUI for remote administration of the TOE. Any session where the client offers the following in the client hello: SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 will be rejected by the TOE’s TLS server. When using the TLS_RSA ciphers (listed in section 5.3.3.13) the RSA public key is used for authentication and key exchange. The TOE implements TLS session resumption differently across multiple contexts, though session resumption is not coordinated across contexts, so a session established in one context cannot be resumed in another. The Manager WebUI supports session resumption based on session tickets according to RFC 5077. Session tickets are encrypted using the symmetric algorithms and key lengths associated with the negotiated ciphersuite and which are consistent with the selections from FCS_COP.1/DataEncryption. Session tickets adhere to the structural format provided in section 4 of RFC 5077. For TOE TLS servers that support inter-appliance communication (relevant to FPT_ITT) the TOE supports session resumption based on session IDs according to RFC 5246 (when using TLS 1.2), and session resumption according to RFC 8446 (when using TLS 1.3). The TOE only uses PSKs (pre-shared keys) in TLS 1.3 in session resumption with forward secrecy. The TOE does not permit out-of-band provisioning of PSKs. The TOE will perform a full TLS handshake under any of the following conditions: • The Session ID is not recognized in the TOE session cache • The session associated with a Session ID or ticket has expired • Session ticket decryption or integrity verification fails • TLS version or cipher suite mismatch occurs between the stored session and the new ClientHello • The client omits resumption identifiers • Server-side policy requires renegotiation (e.g., configuration change or administrative reset) • PSK identity or binder validation fails (TLS 1.3) Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 51 of 67 - TOE SFRs How the SFR is Met • The TOE has been restarted and session state is not recoverable (if persistence is not configured) The TLS servers of each TOE component support mutual authentication (FCS_TLSS_EXT.2) for interconnections between distributed TOE components (FPT_ITT.1). Mutual authentication is not supported for TLS connections used for remote administration (FTP_TRP.1). When a TLS session is initiated between two TOE components, the server side of the TLS session will check the client certificate and if the SAN within the client certificate does not match the expected identifier on the server, the connection will be rejected by the server. The TOE supports TLSv1.3 and TLSv1.2 with AES 128 or 256 bit symmetric ciphers in GCM mode, in conjunction with SHA (SHA256, and SHA384), RSA, finite-field DHE using ffdhe named groups as specified in RFC 7919, and ECDHE (NIST curves supported are secp256r1, secp384r1, and secp521r1). The TOE will use secp521r1 if supported by the client, otherwise secp384r1, and lastly secp256r1. The following TLS cipher suites are implemented by the TOE in CC mode: • Ciphersuites relevant to FPT_ITT, FCS_TLSC_EXT.1, and FCS_TLSS_EXT.1 (client and server) are as listed in sections 5.3.3.11 and 5.3.3.13 of this document. • Ciphersuites relevant to FTP_TRP.1 and FCS_TLSS_EXT.1 (server only) are as listed in section 5.3.3.13 of this document. While the FP (see section 7.2) supports additional cipher suites (for example, RSA_3DES_EDE_CBC_SHA, RSA_DES_CBC_SHA, RSA_RC4_128_MD5, RSA_RC4_128_SHA, etc.), they are all disabled while operating in CC mode. If the remote TLS client does not support TLSv1.2 or TLSv1.3 the TLS connections will fail and the administrators will not establish a HTTPS web-based session with the TOE. The key agreement parameters of the key exchange message for TLSv1.3 are specified in the RFC 8446 (section 4.1) and the TOE is conformant to the RFC. The key agreement parameters of the server key exchange message for TLSv1.2 are specified in the RFC 5246 (section 7.4.3) and the TOE is conformant to the RFC. The TOE TLS servers support the signature_algorithms extension, do not support the signature_algorithms_cert extension, and the behavior is not configurable. FIA_AFL.1 Note: This SFR applies only to the Manager component of the TOE. The administrator can configure the maximum number of failed login attempts (configurable from 1-10 consecutive failed attempts) before the account is locked. Accounts that become locked by this feature Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 52 of 67 - TOE SFRs How the SFR is Met will remain locked for an administratively defined number of minutes (configurable from 1-720 minutes). By default this feature is disabled. The predefined ‘admin’ account on each appliance is exempt from being locked out, but in the CC-evaluated configuration that account is disabled. All remote administration is performed via the Manager using non-default administrative accounts on the Manager (local accounts or LDAP accounts), and no remote authentication is permitted to any other TOE component. If all non-default remote administration accounts become locked due to consecutive failed login attempts, the default ‘sysadmin’ account (which can only login via console and is exempt from lockout) can unlock the default ‘admin’ account and the default ‘admin’ account can be used to unlock any locally stored (not LDAP) remote administrative account. 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 “]”. Minimum password length is configurable by the Authorized Administrator; the minimum number of characters can be set from 8 to 256 inclusive. Password composition rules specifying the types and number of required characters that comprise the password are settable by the Authorized Administrator. FIA_UIA_EXT.1 The TOE requires all users to be successfully identified and authenticated before allowing any TSF mediated actions to be performed except for acknowledging the pre-login warning banner. The TOE mediates all administrative actions through its GUI and CLI. Once a potential administrative user attempts to access the TOE through either a directly connected console or remotely through TLS, 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. In this distributed TOE all remote administration is performed via the WebUI (GUI) of the Manager. Each SNA appliance has a default ‘admin’ account (only valid for WebUI access, not CLI), which must be disabled, but cannot be deleted. During installation configuration of the TOE (following guidance in AGD_PRE) the default ‘admin’ account will be used on the Manager to create one or more custom administrative accounts on the Manager, and to configure LDAP authentication on the Manager. Once at least one custom administrative WebUI account (with full privileges) has been created on the Manager, the ‘sysadmin’ account (which is only valid for CLI access, not WebUI) will use ‘SystemConfig’ (a menu-based interface Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 53 of 67 - TOE SFRs How the SFR is Met via the CLI) to disable the default ‘admin’ account on each SNA appliance (Manager, FC, and FS). Once the default ‘admin’ account on each appliance has been disabled all subsequent remote WebUI administration of every SNA appliance will be performed via the Manager only. Each non-Manager (FC, and FS) TOE component continues to have a remotely accessible login page (via HTTPS), but all remote login attempts will fail because the only existing WebUI account (the default ‘admin’ account) is disabled during initial configuration of each appliance. Every TOE component (Manager, FC, and FS) continues to allow local console login using the default ‘sysadmin’ account for maintenance and recovery purposes. FIA_UAU.7 When a user enters their password at the local console none of the typed characters are echoed in the password field, and at the HTTPS/TLS GUI, the password field displays only ‘*’ characters so that the password is obscured. For remote session authentication, the TOE does not echo any characters as they are entered. FIA_X509_EXT.1/ITT When the distributed components initiate TLS connections to each other the client validates the server’s certificates during session establishment and validate those certificates against the locally stored root certificate. Revocation checking (neither CRL nor OCSP checking) is not performed for the TLS connection between TOE components. The extendedKeyUsage field is validated according to the following rules: Server certificates have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field; and the Client certificates have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. Checking is done for the ‘basicConstraints’ extension and the ‘cA’ flag to determine whether they are present and set to TRUE. If they are not, the CA certificate is not accepted as a trust anchor. FIA_X509_EXT.1/Rev FIA_X509_EXT.2 FIA_X509_EXT.3 The TOE uses X.509v3 certificates as defined by RFC 5280 to support authentication for TLS connections. The certificate validation checking takes place during the TLS session setup. The TOE can generate a RSA key pair that can be embedded in a Certificate Signing Request (CSR) created by the TOE. The CSR can be generated at the UI. The administrator can then download the CSR from the GUI and provide the CSR to the CA for the CA to sign and issue a certificate. Once the certificate has been issued, the administrator can import the X.509v3 certificate into the TOE. All certificate management for all TOE components is managed via the GUI of the Manager. More than one certificate from one or more CAs on the TOE can be stored and used by TOE. For example, one certificate from one CA could be used for TLS connections to syslog or LDAP server, while Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 54 of 67 - TOE SFRs How the SFR is Met another certificate from another CA could be used for TLS connections to another syslog or LDAP server. The physical security of the TOE (A.PHYSICAL_PROTECTION) protects the switch and the certificates from being tampered with or deleted. In addition, the TOE identification and authentication security functions protect an unauthorized user from gaining access to the TOE. Certificate revocation checking is supported by the TOE through use of OCSP and CRL when the TOE is validating server certificates when initiating outbound TLS connections to syslog and LDAP servers (for FTP_ITC only). The extendedKeyUsage field is validated according to the following rules: Server certificates have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field; the Client certificates have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field; and the OCSP responder certificates have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. Certificate validation includes verification of the basicConstraints extension and the CA flag to determine whether they are present and set to TRUE. The local CA certificate that was imported must contain the basic constraints extension with the CA flag set to true, the check also ensure that the key usage extension is present. In all use cases (syslog-over-TLS and LDAP-over-TLS, whether using CRL or OCSP) if the connection to determine the certificate validity cannot be established, the TOE will not accept the certificate. The TOE uses digital signature verification to verify the integrity of system software updates prior to installation of updates on each appliance. FMT_MOF.1/ManualUpdate Note: This SFR applies only to the Manager component of the TOE. Manual software updates can only be initiated by the authorized administrator through the Manager GUI. Updates for all TOE components are managed through the GUI of the Manager. All update files are first uploaded by an administrator to the Manager, then a Manager administrator manually initiates installing of updates to each appliance (Manager, FC, and FS). When updating appliances other than the Manager itself, the update files are transmitted from the Manager to each other TOE component over the same TLS connection used for all other distributed TOE (FPT_ITT.1) communications. FMT_MTD.1/CoreData The TOE restricts the access to manage TSF data that can affect the security functions of the TOE to Security Administrators (i.e., administrator roles). The TSF data here includes user accounts and roles, login banner, inactivity timeout values, password length settings, TOE updates, X.509 certificates, audit records, and audit server information. Access to TSF data is disallowed for all non- administrative users because all accounts are administrative accounts. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 55 of 67 - TOE SFRs How the SFR is Met Each TOE component contains a trust store of X.509v3 certificates. The trust store contains certificates for the local TOE component, and certificates for all other TOE components with which the local component communicates, and certificates for remote syslog servers. The trust store on the Manager additionally contains X.509v3 certificates of remote LDAP servers. Access to trust store data on each component is restricted to authorized administrators only. Remote administrators using the Manager WebUI can manage trust stores on each TOE component via the Manager WebUI. Local ‘sysadmin’ accounts on each appliance could regenerate a new self- signed X.509v3 device certificate, but doing so would break communication with other TOE components and would result in removing that component from the TOE. FMT_MTD.1/CryptoKeys Note: This SFR applies only to the Manager component of the TOE. The TOE restricts the access to manage cryptographic keys to Security Administrators (i.e., administrator roles). Ability to manage cryptographic keys is disallowed for all non-administrative users because all accounts are administrative accounts. Each TOE component contains its own set of cryptographic keys. Key regeneration/replacement/removal can be performed for any appliance via the Manager WebUI. FMT_SMF.1 The TOE includes the functions necessary to administer the TOE locally and remotely. Most TOE administrative actions are performed via the WebUI/GUI of the Manager, but each TOE component also has a local serial console interface through which some administrative actions can be performed. Each TOE component has an active WebUI accessible via TLS, but the Manager is the only TOE component that allows login via its WebUI. The following administrative actions are performed via the Manager WebUI: • Configuring the pre-login access banner. The banner for each TOE component is configured separately, and each TOE component uses a single banner for its local console and for its remote WebUI. • Configuring session inactivity time limits. The same idle timeout values apply to the WebUI and console interfaces. • Management and verification of software updates for each TOE component. (Note: The local console of each appliance can be used to verify the running version, but the local console cannot be used to install updates.) • Configuring audit behavior such as adding/removing syslog servers, and configuring use of TLS for those connections. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 56 of 67 - TOE SFRs How the SFR is Met • Configuring cryptographic functionality, such as enabling CC mode and FIPS mode, and enabling file integrity checking. • Configuring interactions between TOE components such as removing/deleting a managed TOE component, or rebooting a TOE component. • Configuring use of one or more NTP servers, including NTP authentication. • Configuring the reference identifier for peers such as adding IP addresses for syslog servers, and adding FQDN or IP addresses for LDAP servers. • Managing the trust store of each TOE component, importing trust anchors, and importing certificates of multiple TOE components, syslog servers, and LDAP servers. • Configuration of authentication failure parameters for FIA_AFL.1 including number of successive failed login attempts prior to lockout, and the duration of lockout. The following administrative actions can be performed via the local console on each appliance: • Changing administrator passwords for the sysadmin account (the sysadmin account cannot login via the WebUI). • Configuring syslog compliance and certificate path debug logging. • Verifying the TOE version. FMT_SMR.2 The TOE platform maintains both privileged and semi-privileged administrator roles. The terms “Authorized Administrator” and "Security Administrator" are used interchangeable in this ST to refer to any user that has been assigned to a privilege level that is permitted to perform the relevant action; therefore, has the appropriate privileges to perform the requested functions. The assigned role determines the functions the user can perform; hence the authorized administrator with the appropriate privileges. FPT_APW_EXT.1 TOE ensures that plaintext user passwords will not be disclosed, even to administrators. There are no administrative interfaces that allow viewing of stored passwords; there is no viewable configuration file and no viewable password file; when changing passwords the old password is not displayed in any form (plaintext or otherwise) and the new password is obscured with asterisks as it’s being typed; passwords are obscured by asterisks during login via WebUI and are not echoed at all (the cursor at the password prompt does not move) when logging via the console; passwords are not written to audit records. FPT_ITT.1 The distributed components of the TOE communicate with each other using TLSv1.2 and TLSv1.3. The Manager communicates with each other appliance (FC, and FS), and the TLS sessions can be initiated in Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 57 of 67 - TOE SFRs How the SFR is Met either direction. During most TOE activity the managed components (FC, and FS) initiate the mutually-authenticated TLS (FCS_TLSC_EXT.2) connections to the Manager (FCS_TLSS_EXT.2) to query the Manager for any updates (configuration updates and software updates). The Manager will initiate mutually-authenticated TLS connections (FCS_TLSC_EXT.2) with other components (FCS_TLSS_EXT.2) when a Manager administrator initiates a query for data stored on another component (e.g. to query for network flow data) for the purpose of displaying query results/reports to the Manager administrator. FPT_SKP_EXT.1 The TOE stores all private keys (associated with local X.509v3 certificates), and pre-shared/symmetric keys (associated with LDAP servers) such that they are not readable by administrators. The keys are stored in plaintext but there are no administrative interfaces that allow viewing of any stored keys. FPT_STM_EXT.1 The TOE provides a source of date and time information in the form of a software clock, which it uses for writing timestamps to audit messages (FAU_GEN.1), for tracking session idle time (FTA_SSL_EXT.1 and FTA_SSL.3), for unlocking accounts after consecutive failed login attempts (FIA_AFL.1), and for verifying validity times of X.509v3 certificates (FIA_X509_EXT.1). When each TOE component boots, it will set its software clock to match the hardware clock of the underlying server. All SNA appliances operate in the UTC time zone and the time zone is not configurable, so the hardware clock of the underlying system must also be set to UTC. The software clock on each TOE component can be configured via the WebUI to use one or more NTP servers (must be configured to use at least one). FPT_TST_EXT.1 The TOE components include a number of built in diagnostic tests that are run during start-up to determine whether the TOE is operating properly. The crypto module within the TOE runs power-on self-tests including known answer tests (KATs). The following self-tests are executed: AES encryption/decryption KAT, RSA pairwise consistency and sign/verify KAT, SHA hash KATs, HMAC-SHA hash KATs, and DRBG KATs. When any crypto-dependent service (such as the TLS web server) initiates startup of the crypto module and any self-test fails during the startup of the crypto module the crypto module returns an error to the service and the service will fail to start. The crypto module will not enter an operational state if any of its self-tests fail, thus the requesting service will also fail to start, and the TOE will not enter a fully operational state. The TOE will remain in a state where all crypto-dependent services remain disabled (all TLS services: remote administration, inter-TSF communication, syslog-over-TLS, and LDAP-over-TLS), so the only interactive interface available will Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 58 of 67 - TOE SFRs How the SFR is Met be via the local serial console for troubleshooting purposes. When a crypto-dependent service initiates startup of the crypto module and all cryptographic self-tests pass during the startup of the crypto module the crypto module returns a successful response to the service and the services continue to load. The TOE runs SHA-256 integrity tests daily to verify the integrity of the kernel, and all binaries and libraries. If the hash verification fails, the TOE will generate an audit message indicating which file changed. The virtual appliance forms of TOE components perform the same self-tests as the physical appliances. These tests (periodically reverifying the integrity of the software files, periodically reverifying the permissions of those files, and verifying the correct operation of cryptographic operations prior to the TOE becoming operational) are sufficient to demonstrate that the TSF is operating correctly. FPT_TUD_EXT.1 An Authorized Administrator can query the software version running on the TOE (on each TOE component) and can initiate software updates to each TOE component. The software version can be queried in multiple ways: the version running on every TOE component can be queried via the Manager WebUI, and the console interface of each individual TOE component can be used to view the running version on that component. When software updates are made available by Cisco, an administrator can download the update from Cisco to a local administrative workstation, then upload the software updates to the Manager. Uploading a software update to the Manager will not automatically initiate installation of the update. Updates for all TOE components are first uploaded to the Manager by a Manager administrator via the Manager WebUI/GUI then using the same interface the Manager administrator initiates installation of the software updates to each TOE component until all TOE components have been updated to the same version. Updates for all TOE components other than the Manager itself (FC, FS) are transferred from the Manager to other TOE components over the same TLS channel that’s used for all other FPT_ITT.1 communications. When an administrator initiates the update process from the Manager, each appliance will use digital signature verification to ensure the integrity of the software update prior to installation of the update. FTA_SSL_EXT.1 FTA_SSL.3 Note: FTA_SSL.3 applies only to the Manager component of the TOE. TOE administrators can configure maximum inactivity times individually for both local and remote administrative sessions. These settings are not immediately activated for the current session, changes to inactivity limits are enforced for new sessions. If a local user session is inactive for a configured period of time, the session will be terminated, and re-authentication is required to start a new session. If a remote user session is inactive for the configured idle Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 59 of 67 - TOE SFRs How the SFR is Met time limit, the session will be terminated and will require authentication to establish a new session. The configurable idle timeout value is the same for local and remote sessions, and configured individually for each appliance via the Manager GUI: Central Management > Appliance Manager > General > Protected Sessions Time-Out. The configurable inactivity timeout range for local console sessions and remote sessions is from 2 to 1440 minutes. FTA_SSL.4 Administrators are able to logout of all local and remote administrative sessions. From the local console, the administrator selects “Exit”. From the GUI, the administrator clicks “Logout”. FTA_TAB.1 The TOE displays a privileged Administrator specified banner on the CLI management interface and on the WebUI prior to allowing any administrative access to the TOE. The banner configured for each appliance (all configured via the Manager WebUI) is displayed prior to login at that appliance’s local console and prior to login at that appliance’s WebUI. Note that once the managed appliances (FC, or FS) are in their CC evaluated configuration, authentication to each of their WebUI is effectively disabled since the local ‘admin’ account on those appliances is disabled and no remote (LDAP) authentication will be enabled, but the login banner continues to be displayed prior displaying the login prompt, and failed authentication attempts are logged. FTP_ITC.1 The TOE protects communications between itself and remote audit servers using TLS. This provides a secure channel to transmit the syslog messages. The TOE protects communications between itself and AAA (LDAP) servers are secured using TLS. FTP_TRP.1/Admin Note: This SFR applies only to the Manager component of the TOE. All remote administrative communications take place over a secure encrypted TLS (HTTPS) session, allowing remote administrators to initiate TLS (HTTPS) communications with the TOE. TLSv1.2 and TLSv1.3 are supported, using the ciphersuites and RFCs listed under FCS_TLSS_EXT.1, and the RFC listed in FCS_HTTPS_EXT.1. FTP_TRP.1/Join During installation of the TOE the Manager is configured first, then other appliances are joined to the Manager and after successful registration those appliances are managed via the Manager. When TOE components are joined to the Manager, the administrator installing the non-Manager appliance (FC, or FS) inputs the IP address or DNS-resolvable hostname of the Manager, then the new appliance initiates a TLS session to the Manager. This initial TLS session used Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 60 of 67 - TOE SFRs How the SFR is Met for joining is authenticated using a valid Manager administrator username and password that is manually entered by the administrator performing the initial configuration of the new appliance. If authentication succeeds, the Manager server certificate fingerprint is displayed for the administrator to confirm, and if the administrator approves the certificate the Manager and the joining appliance exchange X.509 certificates, and the initial TLS session is closed. All subsequent connections between the TOE components also use TLS, but use X.509 certificate-based authentication in accordance with FPT_ITT.1 and FIA_X509_EXT.1/ITT. No supplemental support is required from the operational environment to secure the TLS connections between the Manager and other TOE components that are being joined to the Manager. If attempts to join SNA appliances to a Manager fail: • No FPT_ITT.1 TLS session (using certificate-based authentication per FIA_X509_EXT.1/ITT) can be established between the devices, and thus no TSF data can be exchanged between the devices until registration successfully completes. • If the connection failed due to network connectivity error, resolve the connectivity, and reattempt joining. • If the connection fails due to incorrect information provided by the administrator of the joining component (e.g. incorrect hostname/IP address of the Manager, or incorrect account name or password for the Manager), correct the information, and reattempt joining. Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 61 of 67 - 7 SUPPLEMENTAL TOE SUMMARY SPECIFICATION INFORMATION 7.1 Key Destruction The following table describes the key destruction referenced by FCS_CKM_EXT.4 provided by the TOE. Table 19: TOE Key Destruction Name Generation/ Algorithm Purpose Storage Location Destruction Summary RSA public/private keys DRBG Identity certificates for TOE components for TLS. Private Key – hard disk (plaintext) and RAM (plain text) Public Key – hard disk (plaintext) and RAM (plain text) Private Key - destroyed when certificates are deleted by administrators. Public Key - are deleted from hard disk when the certificates are deleted by administrators. Diffie-Hellman Key Pairs DRBG Key agreement for TLS sessions. RAM (plain text) Keys in RAM are destroyed upon resetting (i.e., terminating all sessions) or rebooting. RSA public/private keys RSA Used for TLS sessions. Hard disk (plain text)/RAM (plain text) Private Key - The private key is destroyed when the Manager and other appliances regenerate new CSRs, which results in generating new key pairs. TLS Session Keys DH / DRBG Algorithm: AES Used for HTTPS sessions. RAM (plain text) Keys in RAM are destroyed upon rebooting the TOE. Passwords User generated Critical security parameters used to authenticate administrators. Hard disk (Hashed with SHA-512 and salt value) Passwords are not stored in plaintext. Only the hashed of the passwords and a 32-bit nonces are stored. Pre-shared keys / secrets User generated Critical security parameters used to authenticate to LDAP servers. Hard disk Stored in plaintext. Pre-shared keys and secrets are destroyed when deleted or replaced by administrators. Certificates of Certificate Authorities (CAs) DRBG Necessary to verify certificates issued by the CA. Install the CA's certificate prior to installing subordinate certificates. Hard disk (plain text) and RAM (plain text) CA certificates are destroyed from hard disk when the CA certificates are deleted by the administrators. CA certificates in RAM will be destroyed upon rebooting the TOE. PRNG Seed Key Entropy Seed key for DRBG RAM (plain text) Seed keys are destroyed and overwritten with the generation of new seed Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 62 of 67 - 7.2 CAVP Certificate Equivalence Each TOE component contains two cryptographic modules, the CiscoSSL FIPS Provider Cryptographic Implementation version 8.0 (using abbreviation “FP” for FIPS Provider), and the Cisco BC Cryptographic Implementation version 2.0.0 (using abbreviation “BC” for Bouncy Castle). The table below (Table 20) lists the CAVP certs for each TOE appliance, and the CPU in each appliance. Because there are both physical and virtual appliances available for each TOE component, there are separate CAVP certs for each cryptographic module, a “firmware” CAVP certificate for physical appliances, and a “software” CAVP certificate for the virtual appliances. Where the FP or BC certificate was validated as software, the processor is identified along with the operating system and hypervisor in the operational environment of the validated FP. Table 20: Processors Within the TOE CAVP # Processor Microarchitecture Lithography TOE Appliance / Platform FP: A3032 BC: A8371 AMD EPYC 7453 (Zen 3) Zen 3 7nm ST-SMC2300-K9 FP: A3032 BC: A8371 AMD EPYC 7313P (Zen 3) Zen 3 7nm ST-FS1300-K9 FP: A3032 BC: A8371 AMD EPYC 7313 (Zen 3) Zen 3 7nm ST-FS3300-K9 FP: A3032 BC: A8371 AMD EPYC 7443 (Zen 3) Zen 3 7nm ST-FS4300-K9 FP: A3032 BC: A8371 AMD EPYC 7453 (Zen 3) Zen 3 7nm ST-FC4300-K9 FP: A5466 BC: A8338 AMD EPYC 7302 (Zen 2) w/ Linux 6 on ESXi 8.0 Zen 2 7nm Cisco UCS C225-M6S (with any of: L-ST-SMC-VE-K9, L- ST-FC-VE-K9, and/or L-ST- FS-VE-K9) The tables on the following pages (Table 21 and Table 22) contain the CAVP certificate numbers for each cryptographic module as applicable to each SFR. Page 63 of 67 Table 21: CAVP Validation Numbers for the Cisco FIPS Provider (FP) Algorithm SFR Standard CAVP # (physical appliances) CAVP # (virtual appliances) AES GCM 128/256 FCS_COP.1/DataEncryptionAES as specified in ISO 18033-3 GCM as specified in ISO 19772 A3032 A5466 RSA 2048-bit and 4096-bit Sig Gen & Verify Key Gen FCS_COP.1/SigGen FCS_CKM.1 FIPS PUB 186-4, PKCS#1 v2.1, RSASSA-PSS and RSASSAPKCS2v1_5 FIPS PUB 186-4, Appendix B.3 A3032 A5466 ECDSA curves P-256, P-384, and P-521 Sig Gen & Verify Key Gen and Verify FCS_COP.1/SigGen FCS_CKM.1 FIPS PUB 186-4, Section 6 and Appendix D FIPS PUB 186-4, Appendix B.4 A3032 A5466 Hashing SHA-1, SHA-256, SHA-384, SHA-512 FCS_COP.1/Hash ISO/IEC 10118-3:2004 A3032 A5466 Keyed Hash HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 FCS_COP.1/KeyedHash ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2” A3032 A5466 DRBG HMAC_DRBG (SHA-256) FCS_RBG_EXT.1 ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash Functions” A3032 A5466 CVL KAS ECC ECC (P-256, P-384, P-521) FCS_CKM.1 FCS_CKM.2 FIPS PUB 186-4, Appendix B.4 NIST SP800-56A, Revision 3 A3032 A5466 Safe Primes RFC 7919 ffdhe2048, ffdhe3072, ffdhe4096 FCS_CKM.1 FCS_CKM.2 NIST SP800-56A, Revision 3 RFC 7919 Tested by Known Good Implementation Tested by Known Good Implementation Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 64 of 67 Table 22: CAVP Validation Numbers for Bouncy Castle (BC) Algorithm SFR Standard CAVP # (physical appliances) CAVP # (virtual appliances) AES GCM 128/256 FCS_COP.1/DataEncryptionAES as specified in ISO 18033-3 GCM as specified in ISO 19772 A8371 A8338 RSA 2048-bit and 4096-bit Sig Gen & Verify Key Gen FCS_COP.1/SigGen FCS_CKM.1 FIPS PUB 186-4, PKCS#1 v2.1, RSASSA-PSS and RSASSAPKCS2v1_5 FIPS PUB 186-4, Appendix B.3 A8371 A8338 ECDSA curves P-256, P-384, and P-521 Sig Gen & Verify Key Gen and Verify FCS_COP.1/SigGen FCS_CKM.1 FIPS PUB 186-4, Section 6 and Appendix D FIPS PUB 186-4, Appendix B.4 A8371 A8338 Hashing SHA-1, SHA-256, SHA-384, SHA-512 FCS_COP.1/Hash ISO/IEC 10118-3:2004 A8371 A8338 Keyed Hash HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 FCS_COP.1/KeyedHash ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2” A8371 A8338 DRBG HMAC_DRBG (SHA-256) FCS_RBG_EXT.1 ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash Functions” A8371 A8338 CVL KAS ECC ECC (P-256, P-384, P-521) FCS_CKM.1 FCS_CKM.2 FIPS PUB 186-4, Appendix B.4 NIST SP800-56A, Revision 3 A8371 A8338 Safe Primes RFC 7919 ffdhe2048, ffdhe3072, ffdhe4096 FCS_CKM.1 FCS_CKM.2 NIST SP800-56A, Revision 3 RFC 7919 Tested by Known Good Implementation Tested by Known Good Implementation Page 65 of 67 8 ANNEX A: REFERENCES The following documentation was used to prepare this ST: Table 23: References Identifier Description [CC_PART1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model, dated April 2017, version 3.1, Revision 5, CCMB- 2017-04-001 [CC_PART2] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional components, dated April 2017, version 3.1, Revision 5, CCMB- 2017-04-002 [CC_PART3] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance components, dated April 2017, version 3.1, Revision 5, CCMB- 2017-04-003 [CEM] Common Methodology for Information Technology Security Evaluation – Evaluation Methodology, dated April 2017, version 3.1, Revision 5, CCMB-2017- 04-004 [NDcPP] collaborative Protection Profile for Network Devices, version 3.0e, 06-December- 2023 [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 Rev 2, May 2013 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography [800-56B] NIST Special Publication 800-56B Recommendation for Pair-Wise, August 2009 Key Establishment Schemes Using Integer Factorization Cryptography [FIPS 140-3] FIPS PUB 140-3 Federal Information Processing Standards Publication Security Requirements for Cryptographic Modules, May 22, 2019 [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 186-4] FIPS PUB 186-4 Federal Information Processing Standards Publication Digital Signature Standard (DSS), July 2013 [FIPS PUB 198-1] Federal Information Processing Standards Publication The Keyed-Hash Message Authentication Code (HMAC), July 2008 [NIST SP 800-90A Rev 1] NIST Special Publication 800-90A Recommendation for Random Number Generation Using Deterministic Random Bit Generators, January 2015 [FIPS PUB 180-3] FIPS PUB 180-3 Federal Information Processing Standards Publication Secure Hash Standard (SHS), October 2008 Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 66 of 67 9 ANNEX B: SFR TOE COMPONENTS MAPPING This TOE is a distributed TOE consistent with Use Case 3 as defined in the NDcPP. The following mapping shows which SFRs are supported by which TOE components: Table 24: Distributed TOE SFR Mapping Requirement Description SFR Enforcement Component Audit Generation Component FAU_GEN.1 Audit Data Generation All All FAU_GEN.2 User Identity Association All N/A FAU_GEN_EXT.1 Security Audit Generation All N/A FAU_STG_EXT.1 Protected Audit Event Storage All N/A FAU_STG_EXT.4 Protected Local Audit Event Storage for Distributed TOEs All N/A FCO_CPC_EXT.1 Communication Partner Control All All FCS_CKM.1 Cryptographic Key Generation All N/A FCS_CKM.2 Cryptographic Key Establishment All N/A FCS_CKM.4 Cryptographic Key Destruction All N/A FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) All N/A FCS_COP.1/SigGen Cryptographic Operation (Signature Verification) All N/A FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) All N/A FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) All N/A FCS_HTTPS_EXT.1 HTTPS Protocol Manager only Manager only FCS_NTP_EXT.1 NTP Protocol All All FCS_RBG_EXT.1 Random Bit Generation All N/A FCS_TLSC_EXT.1 TLS Client Protocol All All FCS_TLSC_EXT.2 TLS Client Protocol with authentication All All FCS_TLSS_EXT.1 TLS Server Protocol All All FCS_TLSS_EXT.2 TLS Server Protocol with Mutual Authentication All All FIA_AFL.1 Authentication Failure Management Manager only Manager only FIA_PMG_EXT.1 Password Management All N/A FIA_UIA_EXT.1 User Identification and Authentication All All FIA_UAU_EXT.2 Password-based Authentication Mechanism All All FIA_UAU.7 Protected Authentication Feedback All N/A FIA_X509_EXT.1/ITT FIA_X509_EXT.1/Rev X.509 Certification Validation All All Cisco Secure Network Analytics (SNA) 7.5 Security Target Page 67 of 67 FIA_X509_EXT.2 X.509 Certificate Authentication All N/A FIA_X509_EXT.3 Certificate Requests All N/A FMT_MOF.1/ManualUpdate Trusted Update - Management of Security Functions behaviour Manager only Manager only FMT_MTD.1/CoreData Management of TSF Data All All FMT_MTD.1/CryptoKeys Management of TSF Data Manager only N/A FMT_SMF.1 Specification of Management Functions All All FMT_SMR.2 Restrictions on Security Roles All N/A FPT_APW_EXT.1 Protection of Administrator Passwords All N/A FPT_ITT.1 Basic internal TSF data transfer protection All All FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) All N/A FPT_STM_EXT.1 Reliable Time Stamps All All FPT_TST_EXT.1 Testing All N/A FPT_TUD_EXT.1 Trusted Update All All FTA_SSL_EXT.1 TSF-Initiated Session Locking All All FTA_SSL.3 TSF-initiated Termination Manager only Manager only FTA_SSL.4 User-Initiated Termination All All FTA_TAB.1 Default TOE Access Banner All N/A FTP_ITC.1 Inter-TSF Trusted Channel All All FTP_TRP.1/Admin Trusted Path Manager only Manager only FTP_TRP.1/Join Trusted Path All All