National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme Validation Report Bivio Networks, Inc. Bivio 6310-NC Report Number: CCEVS-VR-11106-2020 Dated: 07 December 2020 Version: 1.1 National Institute of Standards and Technology Information Technology Laboratory 100 Bureau Drive Gaithersburg, MD 20899 National Security Agency Information Assurance Directorate 9800 Savage Road STE 6940 Fort George G. Meade, MD 20755-6940 2 Acknowledgements Validation Panel Jean Petty Chris Thorpe Clare Olin Lisa Mitchell Linda Morrison [MITRE Corporation] Common Criteria Testing Laboratory Oleg Andrianov, Michael Baron, Gerrit Kruitbosch UL Verification Services Inc. San Luis Obispo, CA 3 Table of Contents 1 Executive Summary......................................................................................5 2 Identification of the TOE ..............................................................................6 3 Security Policy..............................................................................................7 3.1 Audit................................................................................................................................. 7 3.2 Cryptographic Operations................................................................................................ 7 3.3 Identification and Authentication.................................................................................... 8 3.4 Security Management...................................................................................................... 8 3.5 Protection of the TSF........................................................................................................ 9 3.6 TOE Access........................................................................................................................ 9 3.7 Trusted Path/Channels..................................................................................................... 9 4 Assumptions and Clarification of Scope........................................................9 4.1 Secure Usage Assumptions .............................................................................................. 9 4.2 Threats Countered by the TOE....................................................................................... 11 4.3 Organizational Security Policies ..................................................................................... 12 4.4 Clarification of Scope ..................................................................................................... 12 5 Architectural Information...........................................................................12 5.1 Architecture Overview ................................................................................................... 13 5.1.1 TOE Hardware.....................................................................................................................13 5.1.2 TOE Software ......................................................................................................................14 6 Documentation ..........................................................................................14 7 IT Product Testing.......................................................................................15 7.1 Developer Testing .......................................................................................................... 15 7.2 Evaluation Team Independent Testing .......................................................................... 15 7.3 Vulnerability Analysis ..................................................................................................... 15 8 Evaluated configuration .............................................................................16 9 Results of the Evaluation............................................................................16 10 Validator Comments/Recommendations....................................................16 11 Security Target ...........................................................................................17 4 12 Terms.........................................................................................................17 12.1 Acronyms.................................................................................................................... 17 13 Bibliography...............................................................................................17 5 1 Executive Summary This report documents the NIAP validators’ assessment of the CCEVS evaluation of the Bivio 6310-NC. This report is intended to assist the end-user of this product with determining the suitability of this IT product in their environment. End-users should review both the Security Target (ST), which is where specific security claims are made, in conjunction with this Validation Report (VR), which describes how those security claims were evaluated. The evaluation was performed by UL Verification Services Inc., a Common Criteria Testing Laboratory (CCTL) in San Luis Obispo, CA, USA. The Bivio 6310-NC (Target of Evaluation, or TOE) is a network device providing highly variable network functionality. It achieves this by leveraging RHEL8.2 to provide full hardware access to the networking applications, allowing them to address the high-performance hardware devices directly. The Bivio 6310-NC device can be used to run a variety of applications for processing network data, both commercial and open source. It is out of scope for this certification process to include all these applications for evaluation, so a standard application factory-installed to all Bivio 6310-NC devices as part of the base BiviOS is included with the TOE. This application provides the following non-evaluated functionality:  Inspects packets and will either drop them or forward them based on configuration.  Uses the default mechanisms for packet handling and represents other packet processing applications that a customer may choose to install. This table identifies components that must be present in the Operational Environment to support the operation of the TOE. Component Description Local Console  A local console with an RS-232 port for use with the Bivio provided console cable. Syslog Server (Remote Audit Server)  Syslog server conformant to RFC 5424 (Syslog over TCP capable of receiving an SSH tunnel from the TOE. SSHv2 Client (Remote Administrative Access)  Administrators will need an SSHv2 Client conformant to RFCs 4251, 4252, 4253, 4254, and 6668. o SSH Client conformant to RFCs 4251, 4252, 4253, 4254, and 6668. The SSH client must support AES128-CBC and AES256-CBC encryption algorithms, using HMAC- SHA2-256 or HMAC-SHA2-512 integrity algorithms, and performing key exchange using Diffie-Hellman Group14-SHA1 o To perform public-key authentication to the TOE, the 6 SSHv2 client will need to be capable of supporting SSH- RSA. TLS Client (Remote Administrative Access)  The TOE also provides a CSfC TLS protected server capability, which requires a Telnet Client that supports TLS 1.2 and one or more of the following ciphersuites: o TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 Table 1: Operational Environment Components 2 Identification of the TOE Table 2 provides information needed to completely identify the product, including:  The Target of Evaluation (TOE), the fully qualified identifier of the product as evaluated;  The Security Target (ST), describing the security features, claims, and assurances of the product;  The conformance result of the evaluation;  The organizations and individuals participating in the evaluation. Evaluation Scheme United States Common Criteria Evaluation Validation Scheme Evaluated Target of Evaluation Bivio 6310-NC Protection Profile collaborative Protection Profile for Network Devices, Version 2.2e, dated March 23, 2020 [NDcPP] Security Target Bivio 6310-NC Security Target, Version: 0.8, November 25, 2020 Dates of Evaluation June-December 2020 Conformance Result Pass Common Criteria Version 3.1r5 Common Evaluation Methodology (CEM) Version 3.1r5 Evaluation Technical Report (ETR) 20-5018-R-0019 V1.1 Sponsor/Developer Bivio Networks, Inc. 7 Common Criteria Testing Lab (CCTL) UL Verification Services Inc. CCTL Evaluators Oleg Andrianov, Gerrit Kruitbosch, Michael C. Baron CCEVS Validators Jean Petty, Chris Thorpe, Clare Olin, Lisa Mitchell, Linda Morrison Table 2: Product Identification 3 Security Policy This section contains the product features and denotes which are within the logical boundaries of the TOE. The following Security Functions are supported by the TOE:  Audit  Cryptography  Identification and Authentication  Security Management  Protection of the TSF  TOE Access  Trusted Path/Channels 3.1 Audit  The TOE will audit all events and information defined in Table 4: Auditable Events of the Security Target  The TOE will also include the identity of the user that caused the event (if applicable), date and time of the event, type of event, and the outcome of the event.  The TOE protects storage of audit information from unauthorized deletion.  The TOE prevents unauthorized modifications to the stored audit records.  The TOE can transmit audit data to an external IT entity using SSH protocol. 3.2 Cryptographic Operations The TSF performs the following cryptographic operations: For TLS:  AES-128 in CBC mode for data ciphering, using SHA-1 hashing and RSA key exchange.  AES-256 in GCM mode for data ciphering, using SHA-384 hashing and ECDHE key exchange.  HMAC-SHA2-384 for keyed hash. For SSH:  AES-128 or AES-256 in CBC mode, HMAC-SHA2-256 or HMAC-SHA2-512 hashing and DH key exchange.  Public key authentication via SSH-RSA, RSA-SHA2-256 and RSA-SHA2-512 using HMAC- SHA1, HMAC-SHA2-256 and HMAC-SHA2-512 hashing algorithms. 8  The TOE supports NTP v4 (RFC 5905). For NTP, the TOE uses the Symmetric key Method to ensure authenticity and integrity; supporting SHA1, SHA512 and SHA256 MACs.  TOE Random bit generation utilizes CTR_DRBG as defined by NIST SP 800-90A. This is not configurable, and there are no other cryptographic engines provided in the TOE.  To support SSH for trusted path and trusted channel, the TOE cryptographic module implements RSA key generation with key sizes of 2048-bits and finite-field cryptography with modulus sizes of 2048 bits (Diffie-Hellman Group14).  To support TLS, the TOE cryptographic module implements Elliptic-Curve key generation over NIST curve secp256r1 and RSA key generation using 2048-bit keys.  The TOE supports Trusted Update by allowing the administrator to download update files from Bivio. Any software installed on the TOE will become active immediately and is authenticated using a published hash. Trusted update uses SHA-256 hash function in its algorithm.  The TSF zeroizes all plaintext secret and private cryptographic keys and CSPs once they are no longer required. 3.3 Identification and Authentication  The TSF supports passwords consisting of alphanumeric and special characters. The TSF also allows administrators to set a minimum password length and support passwords with 9 characters or more.  The TSF requires all administrative users to authenticate before allowing the user to perform any actions other than: o Display the warning banner in accordance with FTA_TAB.1 o Responding to ICMP echo requests o Responding to ARP requests with ARP replies o Establishing TLS connection on TCP port 27777 o Automated generation of cryptographic keys 3.4 Security Management  The TSF stores and protects the following data: o Syslog data, user account data, and local authentication data (such as administrator passwords). o Cryptographic keys including pre-shared keys, symmetric keys, and private keys.  There is one class of user on the TOE: The Admin user o The Admin user has full control over the TOE.  Management of the TSF: o The administrator can perform manual updates, determine the behavior of or modify the behavior of the handling of audit data, modify the behavior of the TSF, enable or disable services offered by the TOE, determine the behavior of or modify the behavior of audit functionality when local audit storage is full, manage TSF data, modify, delete, generate or import cryptographic keys, configure the access banner, and configure the session inactivity timeout period. 9 o The administrator may perform these functions locally or remotely using the trusted path provided by SSH and defined in FTP_TRP.1. 3.5 Protection of the TSF  The TSF protects TSF data from disclosure when the data is transmitted between different parts of the TOE.  The TSF prevents the reading of secret and private keys.  The TOE provides reliable time stamps for itself.  The TOE runs a suite of self-tests during the initial start-up (upon power on) to demonstrate the correct operation of the TSF.  The TOE provides a means to verify firmware/software updates to the TOE using a published hash prior to installing those updates. 3.6 TOE Access  The TOE, for local interactive sessions, will terminate the session after an Authorized Administrator-specified period of session inactivity.  The TOE terminates a remote interactive session after an Authorized Administrator- configurable period of session inactivity.  The TOE allows Administrator-initiated termination of the Administrator’s own interactive session.  Before establishing an administrative user session, the TOE is capable of displaying an Authorized Administrator-specified advisory notice and consent warning message regarding unauthorized use of the TOE. 3.7 Trusted Path/Channels  The TOE uses SSH to provide a trusted communication channel between itself and all authorized IT entities that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.  The TOE permits the TSF, or the authorized IT entities to initiate communication via the trusted channel.  The TOE permits remote administrators to initiate communication via the trusted path.  The TOE requires the use of the trusted path for initial administrator authentication and all remote administration actions. 4 Assumptions and Clarification of Scope 4.1 Secure Usage Assumptions The following assumptions are made about the usage of the TOE: 10 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 assumed to be sufficient to protect the device and the data it contains. As a result, the cPP does 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). In the case of vNDs, the VS is considered part of the TOE with only one vND instance for each physical hardware platform. The exception being where components of the distributed TOE run inside more than one virtual machine (VM) on a single VS. There are no other guest VMs on the physical platform providing non-Network Device functionality. A.NO_THRU_TRAFFIC_PROTECTION 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). 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_SECURE The Administrator’s credentials (private key) used to access the Network Device are protected by the platform on which they reside. 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 11 discarded or removed from its operational environment. 4.2 Threats Countered by the TOE The TOE is designed to counter the following threats: T.UNAUTHORIZED_ADMINISTRATOR_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_COMMUNICATION_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. 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 12 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_FUNCTIONALITY_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. T.PASSWORD_CRACKING Threat agents may be able to take advantage of weak administrative passwords to gain privileged access to the device. Having privileged access to the device provides the attacker unfettered access to the network traffic, and may allow them to take advantage of any trust relationships with other Network Devices. T.SECURITY_FUNCTIONALITY_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. 4.3 Organizational Security Policies The TOE enforces the following OSPs: P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by accessing the TOE. 4.4 Clarification of Scope As mentioned in Section 4.1 above, the TOE does not provide any assurance regarding the protection of traffic that traverses it. The intent is for this 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 evaluation. 5 Architectural Information The TOE is classified as a Network Device for Common Criteria purposes. 13 5.1 Architecture Overview The TOE is made up of hardware and software components. 5.1.1 TOE Hardware TOEs are identified with a part number in the format: 1. B6310-NC-C(x,y)M(1,2,3,4,5)D(1,2,3,4,5,6)N(1,2,3,4) a. This chassis is the “standard” product chassis. 2. B6310R-NC-C(x,y)M(1,2,3)D(1,2,3,4,5,6)N(1,2,4) a. This chassis is a shorter, ruggedized chassis. 3. PacStar 451 a. This chassis does not have configuration options and will always use the “C04” processor specification (defined below) and no others. The first digit ‘x’ following ‘C’ is indicative of the processor family (0 – Broadwell, 1 – Skylake, 2 – Cascade Lake), and the second digit ‘y’ (following the digit ‘x’) is selected to match Bivio’s hardware model numbering. The naming conventions specified above reference the following hardware: Bivio 6310-NC Naming Convention Part Number Processor Options with C11 Dual Intel Xeon Gold 6148, 2.4 GHz w/ 27Mb Cache Options with C13 Dual Intel Xeon Silver 4110, 2.1 GHz w/ 11Mb Cache Options with C15 Dual Intel Xeon Gold 6138, 2.0 GHz w/27Mb Cache Options with C21 Dual Intel Xeon Silver 4215, 2.5Ghz with 11Mb cache Options with C22 Dual Intel Xeon Silver 4214, 2.5Ghz with 11Mb cache Options with C23 Dual Intel Xeon Silver 4208, 2.1Ghz with 11Mb cache Options with C24 Dual Intel Xeon Gold 5222, 3.8Ghz with 16.5 Mb cache Options with C25 Dual Intel Xeon Gold 6242, 2.8Ghz with 22Mb cache Options with C26 Dual Intel Xeon Gold 6252, 2.5Ghz with 35.75Mb cache Options with C04 Intel Xeon D 1541, 2.1Ghz with 12MB cache Part Number Installed RAM Options with M1 256GB DDR4-2666 memory Options with M2 512GB DDR4-2666 memory Options with M3 384GB DDR4-2666 memory 14 Options with M4 768GB DDR4-2666 memory Options with M5 1536GB DDR4-2666 memory Part Number Installed Storage Options with D1 2x 1TB SSD storage Options with D2 2x 2TB SSD storage Options with D3 4x 2TB SSD storage Options with D4 8x 2TB SSD storage Options with D5 4x 3.8TB SSD storage Options with D6 8x 3.8TB SSD storage Part Number Installed NIC Interfaces Options with N1 2x 10GbE Fiber interfaces and 4x 1GbE Copper interfaces Options with N2 4x 10GbE Fiber interfaces and 4x 1GbE Copper interfaces Options with N3 6x 10GbE Fiber interfaces and 2x 1GbE Copper interfaces Options with N4 4x 10GbE Fiber interfaces and 2x 1GbE Copper interfaces All “M”, “D”, and “N” options are configuration options which do not affect the evaluated functionality, but are part of the model number. AES-NI technology is enabled for all the listed CPUs. 5.1.2 TOE Software The TOE runs the following software: BiviOS 8.5.1 V: Version 8.5.1 (Build 202006181129) V: Version 8.5.1-104-bv (Patch 202009191230) V: Version 8.5.1-103-rh (Patch 202008311617) 6 Documentation The TOE is delivered to the consumer via carrier services. The guidance documents are included with the shipment and also provided to the product consumer via download from a web-based customer portal provided by the vendor. Only the document(s) in bold were utilized for meeting the CC guidance requirements and only they should be trusted for the purpose of installing, administering, or using the product in its evaluated configuration. Any other documents should not be trusted for those purposes. Document Revision Date Bivio 6310-NC Common Criteria Administrative Guidance 1.10 November 23, 2020 15 7 IT Product Testing This section describes the testing efforts of the Developer and the Evaluation Team. 7.1 Developer Testing No testing was performed by the developer. 7.2 Evaluation Team Independent Testing The evaluation team performed the independent testing activities to confirm the TOE operates to the TOE security functional requirements as specified in the ST for a product claiming conformance to the collaborative Protection Profile for Network Devices, Version 2.2e, dated March 23, 2020. The evaluation team devised a Test Plan based on the Testing Assurance Activities specified in the Protection Profile. The Test Plan described how each test activity was to be performed. The evaluation team executed the tests specified in the Test Plan and documented the results in the Test Report. Independent testing was performed at the UL facility in San Luis Obispo, CA. The hardware/software was provided in the same form that customers would receive it. The evaluator installed and configured the TOE in accordance with the vendor provided guidance documentation and performed the testing procedures as described in the Test Documentation. 7.3 Vulnerability Analysis The evaluation team performed a vulnerability assessment and penetration testing based on TOE hardware/software component identifiers provided by the vendor, and network port scans of the TOE. The comprehensive port scan identified all open ports and acquired all possible identifying information from the TOE. This information was compared to the services listed in the ST and the information provided by the vendor and was used as input into the public domain search. The following search terms were used:  rhel  Redhat  Openssh  Stunnel  openssl 1.1.1  openssl  chrony  AIDE  TCP  TLS  SSH  BIVIO 16  Intel  Xeon  Broadcom  Matrox  ntp. Based on the results, no vulnerabilities exist in the TOE that are exploitable in the evaluated configuration. All CVEs identified in the public domain search either do not affect the specific version of the TOE’s hardware/software components or functionality, were mitigated by security patches installed by the vendor, or were mitigated by assumptions in the Protection Profile. Each platform of the TOE utilizes an Intel CPU which is subject to the Specter/Meltdown hardware vulnerabilities (identified as CVE-2017-5753, CVE-2017-5715 and CVE-2017-5754). The version of Red Hat Enterprise Linux used by the TOE (RHEL 8.2) already contains mitigation for those vulnerabilities. 8 Evaluated configuration The TOE was configured for evaluation per the provided Administrative Guidance, using all claimed TOE functionality, specifically management through SSH, Local console and TLS- enabled telnet and time synchronization using NTP, and remote syslog server as a remote audit storage. 9 Results of the Evaluation The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. The TOE was evaluated against the criteria contained in the Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 5. The evaluation methodology used by the Evaluation Team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 Revision 5. UL has determined that the TOE meets the security criteria in the Security Target. A team of Validators, on behalf of the CCEVS Validation Body, monitored the evaluation. The evaluation was completed in November 2020. 10 Validator Comments/Recommendations The validation team notes that the evaluated configuration is dependent upon the TOE being configured per the evaluated configuration instructions in the Bivio 6310-NC Common Criteria Administrative Guidance document. No versions of the TOE and software, either earlier or later were evaluated. Please note that the functionality evaluated is scoped exclusively to the security functional requirements specified in the Security Target. Other functionality included in the product was not assessed as part of this evaluation. 17 11 Security Target Bivio 6310-NC Security Target, Version: 0.8, November 25, 2020. 12 Terms 12.1 Acronyms CC Common Criteria CSP Critical Security Parameters DAC Discretionary Access Control EAL Evaluation Assurance Level FIPS Federal Information Processing Standards Publication 140-2 IDS Intrusion Detection System IPS Intrusion Prevention System I/O Input/Output MIB Management Information Base NDcPP collaborative Protection Profile for Network Devices, Version 2.2e NIST National Institute of Standards and Technology OCSP Online Certificate Status Protocol PP Protection Profile SF Security Functions SFR Security Functional Requirements ST Security Target TOE Target of Evaluation TSF TOE Security Functions 13 Bibliography [1] 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. [2] Common Criteria (CC) for Information Technology Security Evaluation – Part 2: Security functional components, April 2017, Version 3.1, Revision 5, CCMB-2017-04-002. [3] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance components, April 2017, Version 3.1, Revision 5, CCMB-2017-04-003. [4] Common Methodology for Information Technology Security Evaluation – Evaluation methodology, April 2017, Version 3.1, Revision 5, CCMB-2017-04-004. 18 [5] CC and CEM addenda, Exact Conformance, Selection-Based SFRs, Optional SFRs, May 2017, Version 0.5, CCDB-2017-05-xxx. [6] collaborative Protection Profile for Network Devices, Version 2.2e, March 23, 2020.