Assurance Activity Report for Arista Networks Switches Running EOS

Assurance Activity Report For Arista Networks Switches Running EOS

Version 1.4 12/03/2019

Certification Reference: 383-4-483

Produced by:

1000 Innovation Drive  Ottawa ON K2K 3E7

Prepared for:

Canadian Common Criteria Scheme (CCCS)

Arista Networks Switches Running EOS Assurance Activity Report

The Developer of the TOE: Arista Networks, Inc.

The Security Target Developed By: Arista Networks, Inc. 5453 Great America Parkway Santa Clara, CA 95054

The TOE Evaluation Sponsored By: Arista Networks, Inc.

2 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Table of Contents

1 INTRODUCTION ...... 8 1.1 REFERENCES ...... 8 1.2 TARGET OF EVALUATION ...... 8 1.2.1 Platform Equivalence ...... 11 1.2.2 Tested Platforms Subset ...... 13 2 SECURITY FUNCTIONAL REQUIREMENTS ...... 14 2.1 SECURITY AUDIT (FAU) ...... 14 2.1.1 FAU_GEN.1 Audit Data Generation ...... 14 2.1.1.1 TSS Assurance Activities ...... 14 2.1.1.2 Guidance Assurance Activities ...... 14 2.1.1.3 Testing Assurance Activities ...... 26 2.1.2 FAU_GEN.2 User Identity Association ...... 26 2.1.2.1 TSS Assurance Activities ...... 26 2.1.2.2 Guidance Assurance Activities ...... 26 2.1.2.3 Testing Assurance Activities ...... 26 2.1.3 FAU_STG_EXT.1 Protected Audit Event Storage ...... 27 2.1.3.1 TSS Assurance Activities ...... 27 2.1.3.2 Guidance Assurance Activities ...... 27 2.1.3.3 Testing Assurance Activities ...... 28 2.2 CRYPTOGRAPHIC SUPPORT (FCS) ...... 29 2.2.1 FCS_CKM.1 Cryptographic Key Generation ...... 29 2.2.1.1 TSS Assurance Activities ...... 29 2.2.1.2 Guidance Assurance Activities ...... 29 2.2.1.3 Testing Assurance Activities ...... 30 2.2.2 FCS_CKM.2 Cryptographic Key Establishment ...... 30 2.2.2.1 TSS Assurance Activities ...... 30 2.2.2.2 Guidance Assurance Activities ...... 30 2.2.2.3 Testing Assurance Activities ...... 31 2.2.3 FCS_CKM.4 Cryptographic Key Destruction ...... 31 2.2.3.1 TSS Assurance Activities ...... 31 2.2.3.2 Guidance Assurance Activities ...... 33 2.2.3.3 Testing Assurance Activities ...... 33 2.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption) 33 2.2.4.1 TSS Assurance Activities ...... 33 2.2.4.2 Guidance Assurance Activities ...... 33 2.2.4.3 Testing Assurance Activities ...... 33 2.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification ...33 2.2.5.1 TSS Assurance Activities ...... 33 2.2.5.2 Guidance Assurance Activities ...... 34 2.2.5.3 Testing Assurance Activities ...... 34 2.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm) ...... 34 2.2.6.1 TSS Assurance Activities ...... 34 2.2.6.2 Guidance Assurance Activities ...... 34 2.2.6.3 Testing Assurance Activities ...... 34 2.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm) ...... 35 2.2.7.1 TSS Assurance Activities ...... 35 2.2.7.2 Guidance Assurance Activities ...... 35 2.2.7.3 Testing Assurance Activities ...... 35 2.2.8 FCS_RBG_EXT.1 Extended: Cryptographic Operation (Random Bit Generation) ...... 36 2.2.8.1 TSS Assurance Activities ...... 36 2.2.8.2 Guidance Assurance Activities ...... 36 2.2.8.3 Testing Assurance Activities ...... 36 2.2.9 FCS_SSHC_EXT.1 SSH Client ...... 36 2.2.9.1 FCS_SSHC_EXT.1.2 ...... 36

3 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.2.9.1.1 TSS Assurance Activities ...... 36 2.2.9.1.2 Guidance Assurance Activities ...... 37 2.2.9.1.3 Testing Assurance Activities ...... 37 2.2.9.2 FCS_SSHC_EXT.1.3 ...... 37 2.2.9.2.1 TSS Assurance Activities ...... 37 2.2.9.2.2 Guidance Assurance Activities ...... 37 2.2.9.2.3 Testing Assurance Activities ...... 37 2.2.9.3 FCS_SSHC_EXT.1.4 ...... 38 2.2.9.3.1 TSS Assurance Activities ...... 38 2.2.9.3.2 Guidance Assurance Activities ...... 38 2.2.9.3.3 Testing Assurance Activities ...... 38 2.2.9.4 FCS_SSHC_EXT.1.5 ...... 39 2.2.9.4.1 TSS Assurance Activities ...... 39 2.2.9.4.2 Guidance Assurance Activities ...... 39 2.2.9.4.3 Testing Assurance Activities ...... 39 2.2.9.5 FCS_SSHC_EXT.1.6 ...... 39 2.2.9.5.1 TSS Assurance Activities ...... 39 2.2.9.5.2 Guidance Assurance Activities ...... 40 2.2.9.5.3 Testing Assurance Activities ...... 40 2.2.9.6 FCS_SSHC_EXT.1.7 ...... 40 2.2.9.6.1 TSS Assurance Activities ...... 40 2.2.9.6.2 Guidance Assurance Activities ...... 40 2.2.9.6.3 Testing Assurance Activities ...... 41 2.2.9.7 FCS_SSHC_EXT.1.8 ...... 41 2.2.9.7.1 TSS Assurance Activities ...... 41 2.2.9.7.2 Guidance Assurance Activities ...... 41 2.2.9.7.3 Testing Assurance Activities ...... 41 2.2.9.8 FCS_SSHC_EXT.1.9 ...... 42 2.2.9.8.1 TSS Assurance Activities ...... 42 2.2.9.8.2 Guidance Assurance Activities ...... 42 2.2.9.8.3 Testing Assurance Activities ...... 42 2.2.10 FCS_SSHS_EXT.1 SSH Server ...... 43 2.2.10.1 FCS_SSHS_EXT.1.2 ...... 43 2.2.10.1.1 TSS Assurance Activities ...... 43 2.2.10.1.2 Guidance Assurance Activities ...... 43 2.2.10.1.3 Testing Assurance Activities ...... 43 2.2.10.2 FCS_SSHS_EXT.1.3 ...... 43 2.2.10.2.1 TSS Assurance Activities ...... 43 2.2.10.2.2 Guidance Assurance Activities ...... 43 2.2.10.2.3 Testing Assurance Activities ...... 44 2.2.10.3 FCS_SSHS_EXT.1.4 ...... 44 2.2.10.3.1 TSS Assurance Activities ...... 44 2.2.10.3.2 Guidance Assurance Activities ...... 44 2.2.10.3.3 Testing Assurance Activities ...... 44 2.2.10.4 FCS_SSHS_EXT.1.5 ...... 45 2.2.10.4.1 TSS Assurance Activities ...... 45 2.2.10.4.2 Guidance Assurance Activities ...... 45 2.2.10.4.3 Testing Assurance Activities ...... 45 2.2.10.5 FCS_SSHS_EXT.1.6 ...... 46 2.2.10.5.1 TSS Assurance Activities ...... 46 2.2.10.5.2 Guidance Assurance Activities ...... 46 2.2.10.5.3 Testing Assurance Activities ...... 46 2.2.10.6 FCS_SSHS_EXT.1.7 ...... 46 2.2.10.6.1 TSS Assurance Activities ...... 46 2.2.10.6.2 Guidance Assurance Activities ...... 47 2.2.10.6.3 Testing Assurance Activities ...... 47 2.2.10.7 FCS_SSHS_EXT.1.8 ...... 47 2.2.10.7.1 TSS Assurance Activities ...... 47 2.2.10.7.2 Guidance Assurance Activities ...... 47 2.2.10.7.3 Testing Assurance Activities ...... 47 2.2.11 FCS_TLSS_EXT.2 Extended: TLS Server Protocol with mutual authentication ...... 48 2.2.11.1 FCS_TLSS_EXT.2.1 ...... 48

4 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.2.11.1.1 TSS Assurance Activities ...... 48 2.2.11.1.2 Guidance Assurance Activities ...... 49 2.2.11.1.3 Testing Assurance Activities ...... 49 2.2.11.2 FCS_TLSS_EXT.2.2 ...... 50 2.2.11.2.1 TSS Assurance Activities ...... 50 2.2.11.2.2 Guidance Assurance Activities ...... 50 2.2.11.2.3 Testing Assurance Activities ...... 51 2.2.11.3 FCS_TLSS_EXT.2.3 ...... 51 2.2.11.3.1 TSS Assurance Activities ...... 51 2.2.11.3.2 Guidance Assurance Activities ...... 51 2.2.11.3.3 Testing Assurance Activities ...... 51 2.2.11.4 FCS_TLSS_EXT.2.4 and FCS_TLSS_EXT.2.5 ...... 52 2.2.11.4.1 TSS Assurance Activities ...... 52 2.2.11.4.2 Guidance Assurance Activities ...... 52 2.2.11.4.3 Testing Assurance Activities ...... 52 2.2.11.5 FCS_TLSS_EXT.2.6 ...... 53 2.2.11.5.1 TSS Assurance Activities ...... 53 2.2.11.5.2 Guidance Assurance Activities ...... 53 2.2.11.5.3 Testing Assurance Activities ...... 53 2.3 IDENTIFICATION AND AUTHENTICATION (FIA) ...... 54 2.3.1 FIA_AFL.1 Authentication Failure Management ...... 54 2.3.1.1 TSS Assurance Activities ...... 54 2.3.1.2 Guidance Assurance Activities ...... 54 2.3.1.3 Testing Assurance Activities ...... 55 2.3.2 FIA_PMG_EXT.1 Password Management ...... 55 2.3.2.1 TSS Assurance Activities ...... 55 2.3.2.2 Guidance Assurance Activities ...... 55 2.3.2.3 Testing Assurance Activities ...... 56 2.3.3 FIA_UIA_EXT.1 User Identification and Authentication ...... 56 2.3.3.1 TSS Assurance Activities ...... 56 2.3.3.2 Guidance Assurance Activities ...... 57 2.3.3.3 Testing Assurance Activities ...... 57 2.3.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism ...... 58 2.3.5 FIA_UAU.7 Protected Authentication Feedback ...... 58 2.3.5.1 TSS Assurance Activities ...... 58 2.3.5.2 Guidance Assurance Activities ...... 58 2.3.5.3 Testing Assurance Activities ...... 58 2.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation ...... 58 2.3.6.1 TSS Assurance Activities ...... 58 2.3.6.2 Guidance Assurance Activities ...... 59 2.3.6.3 Testing Assurance Activities ...... 59 2.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication...... 61 2.3.7.1 TSS Assurance Activities ...... 61 2.3.7.2 Guidance Assurance Activities ...... 62 2.3.7.3 Testing Assurance Activities ...... 62 2.3.8 FIA_X509_EXT.3 Extended: X509 Certificate Requests ...... 62 2.3.8.1 TSS Assurance Activities ...... 62 2.3.8.2 Guidance Assurance Activities ...... 63 2.3.8.3 Testing Assurance Activities ...... 63 2.4 SECURITY MANAGEMENT (FMT) ...... 64 2.4.1 FMT_MOF.1/ManualUpdate ...... 64 2.4.1.1 TSS Assurance Activities ...... 64 2.4.1.2 Guidance Assurance Activities ...... 64 2.4.1.3 Testing Assurance Activities ...... 64 2.4.2 FMT_MTD.1/CoreData Management of TSF Data ...... 64 2.4.2.1 TSS Assurance Activities ...... 64 2.4.2.2 Guidance Assurance Activities ...... 65 2.4.2.3 Testing Assurance Activities ...... 65 2.4.3 FMT_MTD.1/CryptoKeys Management of TSF Data ...... 65 2.4.3.1 TSS Assurance Activities ...... 65 2.4.3.2 Guidance Assurance Activities ...... 65

5 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.4.3.3 Testing Assurance Activities ...... 65 2.4.4 FMT_SMF.1 Specification of Management Functions ...... 66 2.4.4.1 TSS Assurance Activities ...... 66 2.4.4.2 Guidance Assurance Activities ...... 66 2.4.4.3 Testing Assurance Activities ...... 67 2.4.5 FMT_SMR.2 Restrictions on security roles ...... 67 2.4.5.1 TSS Assurance Activities ...... 67 2.4.5.2 Guidance Assurance Activities ...... 67 2.4.5.3 Testing Assurance Activities ...... 68 2.5 PROTECTION OF THE TSF (FPT) ...... 69 2.5.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys) ...... 69 2.5.1.1 TSS Assurance Activities ...... 69 2.5.1.2 Guidance Assurance Activities ...... 69 2.5.1.3 Testing Assurance Activities ...... 69 2.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords ...... 69 2.5.2.1 TSS Assurance Activities ...... 69 2.5.2.2 Guidance Assurance Activities ...... 69 2.5.2.3 Testing Assurance Activities ...... 69 2.5.3 FPT_TST_EXT.1 TSF Testing ...... 70 2.5.3.1 TSS Assurance Activities ...... 70 2.5.3.2 Guidance Assurance Activities ...... 70 2.5.3.3 Testing Assurance Activities ...... 70 2.5.4 FPT_TUD_EXT.1 Trusted Update ...... 72 2.5.4.1 TSS Assurance Activities ...... 72 2.5.4.2 Guidance Assurance Activities ...... 73 2.5.4.3 Testing Assurance Activities ...... 73 2.5.5 FPT_STM_EXT.1 Reliable Time Stamps ...... 74 2.5.5.1 TSS Assurance Activities ...... 74 2.5.5.2 Guidance Assurance Activities ...... 75 2.5.5.3 Testing Assurance Activities ...... 75 2.6 TOE ACCESS (FTA) ...... 75 2.6.1 FTA_SSL_EXT.1 TSF-initiated Session Locking ...... 75 2.6.1.1 TSS Assurance Activities ...... 75 2.6.1.2 Guidance Assurance Activities ...... 75 2.6.1.3 Testing Assurance Activities ...... 76 2.6.2 FTA_SSL.3 TSF-initiated Termination ...... 76 2.6.2.1 TSS Assurance Activities ...... 76 2.6.2.2 Guidance Assurance Activities ...... 76 2.6.2.3 Testing Assurance Activities ...... 77 2.6.3 FTA_SSL.4 User-initiated Termination ...... 77 2.6.3.1 TSS Assurance Activities ...... 77 2.6.3.2 Guidance Assurance Activities ...... 77 2.6.3.3 Testing Assurance Activities ...... 77 2.6.4 FTA_TAB.1 Default TOE Access Banners ...... 78 2.6.4.1 TSS Assurance Activities ...... 78 2.6.4.2 Guidance Assurance Activities ...... 78 2.6.4.3 Testing Assurance Activities ...... 78 2.7 TRUSTED PATH/CHANNELS (FTP) ...... 79 2.7.1 FTP_ITC.1 Inter-TSF Trusted Channel ...... 79 2.7.1.1 TSS Assurance Activities ...... 79 2.7.1.2 Guidance Assurance Activities ...... 79 2.7.1.3 Testing Assurance Activities ...... 79 2.7.2 FTP_TRP.1/Admin Trusted Path ...... 80 2.7.2.1 TSS Assurance Activities ...... 80 2.7.2.2 Guidance Assurance Activities ...... 80 2.7.2.3 Testing Assurance Activities ...... 81 3 SECURITY ASSURANCE REQUIREMENTS ...... 82 3.1 ASE: SECURITY TARGET EVALUATION ...... 82 3.1.1 General ASE ...... 82

6 of 86 Arista Networks Switches Running EOS Assurance Activity Report

3.2 ADV_FSP.1 BASIC FUNCTIONAL SPECIFICATION ...... 82 3.2.1 Assurance Activities ...... 82 3.3 AGD: GUIDANCE DOCUMENTS ...... 83 3.3.1 AGD_OPE.1 Operational User Guidance ...... 83 3.3.1.1 Assurance Activities ...... 83 3.3.2 AGD_PRE.1 Preparative Procedures ...... 84 3.3.3 Assurance Activities ...... 84 3.4 ALC: LIFE-CYCLE SUPPORT ...... 84 3.4.1 ALC_CMC.1 Labelling of the TOE ...... 84 3.4.1.1 Assurance Activities ...... 84 3.4.2 ALC_CMS.1 TOE CM coverage ...... 85 3.4.2.1 Assurance Activities ...... 85 3.5 ATE: TESTS ...... 85 3.5.1 ATE_IND.1 Independent Testing – Conformance ...... 85 3.5.1.1 Assurance Activities ...... 85 3.6 AVA: VULNERABILITY ASSESSMENT ...... 85 3.6.1 AVA_VAN.1 Vulnerability Survey ...... 85

List of Tables

TABLE 1: GUIDANCE AND REFERENCE DOCUMENTS ...... 8 TABLE 2: ARISTA NETWORKS SWITCHES HARDWARE MODELS ...... 9 TABLE 3: HARDWARE REQUIREMENTS ...... 13 TABLE 4: AUDITABLE EVENTS DEFINED IN THE CPP ...... 15 TABLE 5: AUDITS OF ADMINISTRATIVE COMMANDS ...... 22

7 of 86 Arista Networks Switches Running EOS Assurance Activity Report

1 Introduction

This document summarizes the evaluation results of a specific Target of Evaluation (TOE), Arista Networks Switches Running EOS, conforming to the collaborative Protection Profile for Network Devices Version 2.1, by listing the assurance activities and associated results as performed by the evaluators.

1.1 References

The following table provides information needed to identify and to control the Security Target (ST), the Target of Evaluation (TOE), and other evidence used in this evaluation. Table 1: Guidance and Reference Documents

Item Identifier Short Form Security Target Arista Networks Switches Running EOS, Version 2.9, December 03, 2019 [ST] Protection Profile collaborative Protection Profile for Network Devices Version 2.1, 24 [PP] September 2018 (NDcPP) Supporting Document Evaluation Activities for Network Device cPP Version 2.1, September 2018 [SD]

Common Criteria Common Criteria Guidance Supplement – Arista Switches, Version 1.14 [CC GUIDE] Configuration Guide October 17, 2019 User Guidance Arista User Manual, Arista EOS Version 4.21.0F, August 6, 2018 [ADMIN]

Test Report NDcPP Arista Test Report v0.2- November-08-2019 [TSTRPT] Functional Specification Arista Networks Switches Running EOS 4.21.0F FSP v0.5, May 14, 2019 [FSP] Document

1.2 Target of Evaluation

The TOE is the Arista Networks Switches running EOS version 4.22.1FX-CC. The TOE is classified as a Network Device, or a device composed of both hardware and software that is connected to the network and has an infrastructure role within the network. The Arista Networks Data Center and Cloud Computing Switches are enterprise class switches (Network Devices for CC purposes) that provide OSI model Layer 2, 3, and 4 Ethernet interconnectivity and network management services (Data Link, Network, and Transport Layers, respectively). They also contain software applications that deliver workflow automation, high availability, network visibility and analytics, and integration with third-party applications for virtualization, management, automation and orchestration services. The TOE Hardware models are the 7500R, 7320X, 7300X, 7300X3, 7280R, 7260X, 7260X3, 7250QX, 7170, 7160, 7060X, 7060X4, 7050X3, 7050X, 7020R, 7010T and 720XP series switches. The following table lists the TOE models and descriptions for each one.

8 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Table 2: Arista Networks Switches Hardware Models

Arista Networks Switches Hardware Models

Series Models Supervisor/Host CPU Chassis Options: ● DCS-7504, DCS-7504N with 4 line card slots ● DCS-7508, DCS-7508N with 8 line card slots ● DCS-7512, DCS-7512N with 12 line card slots ● DCS-7516, DCS-7516N with 16 line card slots Supervisor Module Options: ● DCS-7500-SUP2 ● DCS-7516-SUP2

7500R Line Card Options: Intel Broadwell-DE ● DCS-7500R-36CQ (36x QSFP100 100G ports) ● DCS-7500R-36Q (36x QSFP+ 40G ports) ● DCS-7500R-48S2CQ (48x SFP+ 10G & 2x QSFP100 100G ports) ● DCS-7500R2A-36CQ, 7500R2-36CQ (36x QSFP100 100G ports) ● DCS-7500R2AK-36CQ (36x QSFP100 100G ports) ● DCS-7500R2AK-48YCQ (48x SFP+ 10G & 2x QSFP100 100G ports)

Chassis Options: ● DCS-7304 with 4 line card slots ● DCS-7308 with 8 line card slots ● DCS-7316 with 16 line card slots Supervisor Module: ● DCS-7300-SUP 7320X, 7300X, 7300X3 Line Card Options: Intel Sandy Bridge EN ● DCS-7320X-32C-LC (32x QSFP100 100G ports) ● DCS-7300X-32Q-LC (32x QSFP+ 40G ports) ● DCS-7300X-64S-LC (48x SFP+ 10G & 4x QSFP+ 40G ports) ● DCS-7300X-64T-LC (48x 10GBASE-T 10G & 4x QSFP+ 40G ports)

9 of 86 Arista Networks Switches Running EOS Assurance Activity Report

● 7280CR2A-30, 7280CR2K-30 (30x QSFP100 100G ports)

7280R ● 7280CR-48 (48x QSFP100 100G & 8x Intel Sandy Bridge EN (Subseries: 7280CR) QSFP+ 40G ports) ● 7280CR2-60, 7280CR2A-60, 7280CR2K-60 (60x QSFP100 100G ports) ● 7280QR-C36, 7280QRA-C36S (24x QSFP+ 40G & 12x QSFP100 100G ports) 7280R AMD G Series: Steppe Eagle (Subseries: 7280QR) ● 7280QR-C72 (56x QSFP+ 40G & 16x QSFP100 100G ports) ● 7280SRA-48C6, 7280SR-48C6 (48x SFP+ 10G & 6x QSFP100 100G ports) 7280R ● 7280SR2A-48YC6, 7280SR2-48YC6 (48x AMD G Series: Steppe Eagle (Subseries: 7280SR) SFP25 25G & 6x QSFP100 100G ports) ● 7280SR2K-48C6 (24x SFP+ 10G & 24x SFP25 25G & 6x QSFP100 100G ports) 7280R ● 7280TRA-48C6, 7280TR-48C6 (48x AMD G Series: Steppe Eagle (Subseries: 7280TR) 10GBASE-T 10G & 6x QSFP100 100G ports) ● 7260CX-64, 7260QX-64 (64x QSFP+ 40G Intel Sandy Bridge EN or 7260X ports) AMD G Series: eKabini 7260X3 ● 7260CX3-64 (64x QSFP100 100G ports) Intel Broadwell-DE 7250QX ● 7250QX-64 (64x QSFP+ 40G ports) Intel Sandy Bridge EN ● 7170-32C (32x QSFP100 100G ports) 7170 Intel Broadwell-DE ● 7170-64C (64x QSFP100 100G ports) ● 7160-32CQ (32x QSFP100 100G ports) ● 7160-48TC6 (48x SFP25 25G & 6x QSFP100 AMD G Series: eKabini or 7160 100G ports) AMD G Series: Steppe Eagle ● 7160-48YC6 (48x 10GBASE-T 10G & 6x QSFP100 100G ports) ● 7060CX2-32S, 7060CX-32S (32x QSFP100 100G & 2x SFP+ 10G ports) 7060X AMD G Series: Steppe Eagle ● 7060SX2-48YC6 (48x SFP25 25G & 6x QSFP100 100G ports) ● 7060PX4-32 (32x OSFP 400G ports & 2x SFP+ 10G ports) 7060X4 Intel Broadwell-DE ● 7060DX4-32 (32x QSFP-DD 400G ports & 2x SFP+ 10G ports) ● 7050CX3-32S (32x QSFP100 100G ports) 7050X3 ● 7050SX3-48YC12 (48x SFP25 25G & 12x AMD G Series: Steppe Eagle QSFP100 100G ports) ● 7050TX-48 (32x 10GBASE-T 10G & 4x QSFP+ 40G ports) ● 7050TX-64 (48x 10GBASE-T 10G & 4x QSFP+ 40G ports)

7050X ● 7050TX-72 (48x 10GBASE-T 10G & 2x MXP AMD G Series: eKabini (Subseries: TX, SX, QX) ports) ● 7050TX-96 (48x 10GBASE-T 10G & 4x MXP ports) ● 7050TX-128 (96x 10GBASE-T 10G & 8x QSFP+ 40G ports)

10 of 86 Arista Networks Switches Running EOS Assurance Activity Report

● 7050TX2-128 (96x 10GBASE-T 10G & 8x QSFP+ 40G ports) ● 7050SX-64 (48x SFP+ 10G & 4x QSFP+ 40G ports) ● 7050SX-72 (48x SFP+ 10G & 2x MXP ports) ● 7050SX-96 (48x SFP+ 10G & 4x MXP ports) ● 7050SX2-128 (96x 10GBASE-T 10G & 8x QSFP+ 40G ports) ● 7050QX-32S, 7050QX2-32S (32x QSFP+ 40G & 4x SFP+ 10G ports) ● 7050TX-72Q (48x 10GBASE-T 10G & 6x 7050X QSFP+ 40G ports) AMD G Series: Steppe Eagle (Subseries: TX, SX) ● 7050SX-72Q, 7050SX2-72Q (48x SFP+ 10G & 6x QSFP+ 40G ports) 7050X ● 7050SX-128 (96x SFP+ 10G & 8x QSFP+ Intel Sandy Bridge EN (Subseries: SX) 40G ports) ● 7020SR-24C2, 7020SRG-24C2 (24x 10GBASE-T 10G & 2x QSFP100 100G ports) 7020R AMD G Series: Steppe Eagle ● 7020TR-48, 7020TRA-48 (48x 1000BASE-T 1G & 6x SFP+ 10G ports) ● 7010T-48 (48x 1000BASE-T 1G & 4x SFP+ 7010T AMD G Series: eKabini 10G ports) ● 720XP-48ZC2-F (40x 2.5G & 8x 5G ports) ● 720XP-24ZY4-F (16x 2.5G & 8x 5G ports) 720XP AMD G Series: Steppe Eagle ● 720XP-48Y6-F (48x 1G ports) ● 720XP-24Y6-F (24x 1G ports)

1.2.1 Platform Equivalence

The TOE is a Network Device that includes both hardware and software components. The underlying architecture of each TOE appliance consists of hardware that supports physical network connections, memory, processor, and non- volatile storage and software that implements routing and switching functionality, device drivers, maintains the configuration for the appliance, the audit settings and other user information. While the hardware varies between the different appliance models, the software (Arista Linux-based operating system called Extensible Operating System (EOS) version 4.21.0F) is shared across all platforms. The same binary image of the EOS is installed on all TOE hardware models. The software implements two distinct types of functionality – switching (or the data plane) and management (or the control plane). Only the control plane contains functionality that is relevant to this evaluation. The software responsible for implementing control plane is composed of subsystems designed to implement all of the claimed Security Functionality (SF). Validating the correct operation of the SF-relevant functionality on all available hardware would provide complete assurance. However, most of the differences between the individual appliances are not security relevant for this evaluation. The source code implementing the software is hardware-agnostic, with the image (compiled code) targeting CPU architecture. The vendor affirms that single image applicable to all appliances is produced, and that image is compiled targeting x86-64 architecture. Four switches were selected for testing – each belonging to a different CPU architecture. Hardware dependencies While different appliance models use different enclosures and have a different number and types of ports, power supplies, and so on, the functional differences are: • Modular vs Fixed Form Factor • CPU architecture

11 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Switching functionality and the operation of switching fabric microprocessors (or line cards in modular switches) is exclusively a data plane functionality and is not security relevant for this evaluation. The TOE appliances utilizes one of the following CPUs types: Intel Broadwell-DE, Intel Sandy Bridge EN, AMD G Series (Steppe Eagle), or AMD G Series (eKabini). All of these CPUs implement the same x86-64 instruction set. While specific sub-versions of these CPUs may vary in clock rate, cache size, FSB speed, the number and type of host adapters, and so on, these are not security-relevant distinctions. In simple terms, these differences determine how fast the binary code is shuffled, how much of it is accessed at the same time, and how the CPU’s scheduler prioritizes individual instructions in the pipeline. However, this does not change the results of executing compiled code and the logical code path stays the same. This is relevant distinction, as it means that the TOE’s image, by virtue of being deterministic code, will execute in the same way on all claimed platforms. Difference in TOE binaries The TOE image (source code complied for the target architecture) implement all data plane and control plane functionality. The software is based on a common code base of a modular nature. All of the TOE platforms implement a uniform control plane architecture. For the data plane, configuration code controls platform specific features. While all modules and drivers are part of the binary code, only those modules applicable to the specific platform’s hardware are enabled on the specific appliance. Each instance of Arista EOS v 4.22.1F is produced from the same source code and compiled into a binary targeting a specific CPU architecture. Difference in libraries There is no difference in the libraries between appliances. The TOE uses a consistent set of libraries and third-party software that is universally implemented across all platforms. Difference in compiler The same EOS binary image runs on all TOE hardware models. All EOS code is compiled to the same x86-64 architecture producing single image, making it such that no processor runs anything different from any other processor. All processors implement the i686 assembly language. All SFRs claimed in the Security Target are implemented by EOS. Hence, all SF behave identically on every switch model. Management interface The management interface is implemented as a Command Line Interface (CLI) available remotely over SSH and locally over console ports. The TOE offers a consistent set of predetermined CLI commands for all appliances. The only appliance-specific commands are related to data plane functionality, such as configuring PoE or data link layer protocols. That is, all CLI functionality that is relevant to this evaluation is identical across all appliances. SF differences There are no SF-related functional differences between appliances. The TOE implements the following Security Functionality: • Security Audit • Cryptographic Support • Identification and Authentication • Security Management • Protection of the TOE Security Function (TSF) • TOE Access • Trusted Path/Channels The TOE’s Security Functionality is associated with the following modules:  EOS (Protection of the TSF)  Crypto Module (Cryptographic Support)  eAPI Server (Cryptographic Support, Trusted Path)  SSH Client (Cryptographic Support, Security Audit)  SSH Server (Cryptographic Support, Trusted Channel)

Each SF is implemented by Arista EOS v4.22.1F based on consistent source code combined with a known set of libraries and compiled for target architecture. Cryptographic Module

12 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The Arista Networks Switches EOS 4.22.1F relies exclusively on the Arista EOS Crypto Module v1.0 which is based on OpenSSL. The Arista EOS Crypto Module v1.0 is CMVP #2909 certified software cryptographic module and is covered by the following CAVP certificates: • AES: CAVP# 4280 • RSA: CAVP# 2301 • SHS: CAVP# 3516 • DRBG: CAVP# 1340 • HMAC: CAVP# 2816 • CVL: Certificate # 1012

1.2.2 Tested Platforms Subset

Following switches were used for the testing based on the platform equivalency details provided in the above section. Table 3: Hardware Requirements

TOE Series Model Name Form Factor CPU Architecture CPU Identification TOE A 7020R 7020R-48XRJ45 Fixed Form X86-64 AMD G Series: Factor Steppe Eagle TOE B 7260X DCS-7260CX3- Modular X86-64 Intel Broadwell- 64-F DE TOE C 7050X 7050TX-48 Fixed Form x86-64 AMD G Series: Factor eKabini TOE D 7300X DCS-7304 Modular x86-64 Intel Sandy chassis with Bridge EN DCS-7300-SUP and a single line card

13 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2 Security Functional Requirements

2.1 Security Audit (FAU)

2.1.1 FAU_GEN.1 Audit Data Generation

2.1.1.1 TSS Assurance Activities

TSS Assurance Activities: For the administrative task of generating/import of, changing, or deleting of cryptographic keys as defined in FAU_GEN.1.1c, the TSS should identify what information is logged to identify the relevant key. TSS Implementation Details/Results: The evaluator confirmed that the ST Section 7.1 contains the categorical description of administrative actions related to cryptographic keys. For the administrative task of generating/import of, changing, or deleting of cryptographic keys, following information are provided in the Section 7.1 of ST. Changes to cryptographic keys performed by security administrators: ▪ Generating SSH key pair. The same key pair is used by both SSH server and client. ▪ Generating key pair for Certificate Signing Request (CSR). ▪ Importing of new TLS server certificate.

The evaluator confirmed that the TSS includes the following description as to what information is logged to identify keys: “SHA-256 hash of the public key or the certificate file is included in the audit log to uniquely identify them.” Based on this description the evaluator concluded that the TSS adequately identifies relevant keys and describes the key identification scheme enabling authorized administrators to trace individual keys when reviewing the audit trail.

2.1.1.2 Guidance Assurance Activities

Guidance Assurance Activities: (1) The evaluator shall check the guidance documentation and ensure that it lists all of the auditable events and provides a format for audit records. (2) Each audit record format type must be covered, along with a brief description of each field. (3) The evaluator shall check to make sure that every audit event type mandated by the cPP is described and that the description of the fields contains the information required in FAU_GEN1.2, and the additional information specified in the table of audit events. (4) The evaluator shall also make a determination of the administrative actions related to TSF data related to configuration changes. (5) The evaluator shall examine the guidance documentation and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the cPP. The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to the cPP. (6) The evaluator may perform this activity as part of the activities associated with ensuring that the corresponding guidance documentation satisfies the requirements related to it.

14 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Guidance Implementation Details/Results:

(1) The evaluator checked the CC Guide, Section 4 – Auditable Events and noted it provides an example of each auditable event required by FAU_GEN.1. Each audit records documented in two parts: one entry providing a format of the audit record, and another providing an actual example. The evaluator considers this description adequate to both interpret the logs, which are mostly human-readable, and to assist with searching for the specific record on an auditable event in the audit trail.

(2) The evaluator checked the CC Guide, and noted that it lists all of the TOE’s audit event types. The evaluator crosschecked this list with the ST, Table 8 to ensure that every audit event mandated by the NDcPP is described. Each audit record contains the following information: date and time of the event, type of event, subject identity, and the outcome (success or failure). All audit records contain this mandatory information. In cases where audit record contains an alert or an error, subject identity can be inferred from the audit record (e.g. ConfigAgent) and context (e.g. copying file).

Audit records, when stored and displayed by the TOE, follow the following format:

Format: service=shell priv-lvl=15 cmd=username secret 0 *.

For example, here is how a successful password reset of an user is recorded:

May 23 22:48:19 switch Aaa: %ACCOUNTING-6-CMD: admin vty3 10.95.66.234 stop task_id=283 start_time=1558669699.17 timezone=EST service=shell priv-lvl=15 cmd=username CCUser secret 0 *

(3) The evaluator verified that every audit event required by FAU_GEN.1 is described and that the description of the fields contains all the necessary information. The CC Guide, Section 4 list all relevant audit records. See mapping table below for details.

Table 4: Auditable Events defined in the cPP Additional CC Guide Mapping SFR Auditable Event Audit Record Contents FAU_GEN.1 Startup and None. CC Guide, Section 4.1, Audit Data Shutdown of the Audit Generation, p.23 Function FAU_GEN.2 None. None. N/A FAU_STG_EXT.1 None. None. N/A FCS_CKM.1 None. None. N/A FCS_CKM.2 None. None. N/A FCS_CKM.4 None. None. N/A FCS_COP.1/DataEncryption None. None. N/A FCS_COP.1/SigGen None. None. N/A FCS_COP.1/Hash None. None. N/A FCS_COP.1/KeyedHash None. None. N/A FCS_RBG_EXT.1 None. None. N/A FCS_SSHC_EXT.1 Failure to establish an Reason for CC Guide, Section 4.2.1, Audit SSH session failure. Data Generation, FCS_SSHC_EXT.1 – SSH Client Protocol, p.26

Example:

15 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The following audit logs indicate failure to establish the SSH tunnel.

May 23 21:51:11 switch SuperServer: %SECURITY-3- SSH_TUNNEL_INITIAL_TIMEOUT: SSH tunnel LogTunnel was unable to reach the remote host and the connection timed out May 24 02:00:12 switch ConfigAgent: %SECURITY-6- SSH_TUNNEL_CONFIGURED: SSH tunnel LogTunnel from local TCP port 514 to localhost:514 via [email protected] is fully configured May 24 02:00:09 switch ConfigAgent: %SECURITY-6- SSH_TUNNEL_UNCONFIGURED: SSH tunnel LogTunnel from local TCP port 514 to localhost:514 via [email protected] has been unconfigured Non-TOE Example: endpoint of connection (IP May 23 21:51:11 switch Address) SuperServer: %SECURITY-3- SSH_TUNNEL_INITIAL_TIMEOUT: SSH tunnel LogTunnel was unable to reach the remote host and the connection timed out FCS_SSHS_EXT.1 Failure to establish an Reason for CC Guide, Section 4.2.2 SSH session failure. FCS_SSHS_EXT.1 – SSH Server Protocol, p.27

Example:

Format: sshd[]: Error: user failed to login

Log Sample:

Oct 15 10:32:10 switch-DCS7050 Aaa:557:%AAA-4-LOGIN_FAILED: user ccadmin1 failed to login [from 192.168.0.205] [service:sshd] [reason: Authentication failed – Bad user]

FCS_TLSS_EXT.2 Failure to establish a Reason for failure CC Guide, Section 4.2.3 TLS Session FCS_TLSS_EXT.2 – TLS Server Protocol with Mutual Authentication, p.28

Example:

Format : nginx[] SSL_do_handshake() failed () while SSL handshaking, client:.

16 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Log Sample: Jun 1 00:16:18 switch nginx: 2019/06/01 00:16:18 [info] 8888#0: *6 SSL_do_handshake() failed (SSL: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired:SSL alert number 45) while SSL handshaking, client: ::ffff:10.95.66.234, server: [::]:443

FIA_AFL.1 Unsuccessful login Origin of the CC Guide, Section 4.2.4 FIA_AFL.1 attempts limit is met attempt (e.g., IP – Authentication Failure or exceeded. address). Management, p.29

Example:

Format: user failed to login [from: ] [service: sshd] [reason: Account temporarily locked from remote access due to too many consecutive failed login attempts.]

Log Sample: May 23 21:49:06 switch Aaa: %AAA-4-LOGIN_FAILED: user CCUser failed to login [fr om: 10.95.66.234] [service: sshd] [reason: Account temporarily locked from remote access due to too many consecutive failed login attempts.]

FCS_PMG_EXT.1 None. None. N/A FIA_UIA_EXT.1 All use of the Origin of the CC Guide, Section 4.2.5 identification and attempt (e.g., IP FIA_UIA_EXT.1 – User authentication address). Identification and Authentication, mechanism. p.30

Example:

Format: user logged in [from: ] [service: < sshd, command-api >]

Log Sample: May 23 21:17:53 switch Aaa: %AAA-5-LOGIN: user CCUser logged in [from: 10.95.66. 234] [service: sshd]

AAA FAILED

17 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Format: user logged in [from: ] [service: ] [reason: ]

Log Sample: May 23 21:26:06 switch Aaa: %AAA-4-LOGIN_FAILED: user CCUser failed to login [fr om: 10.95.66.234] [service: sshd] [reason: Authentication failed - Bad secret]

FIA_UAU_EXT.2 All use of the Origin of the CC Guide, Section 4.2.6 identification and attempt (e.g., IP FIA_UIA_EXT.2 – Password-based authentication address). Authentication Mechanism, p.30 mechanism. Example:

Format: user logged in [from: ] [service: login]

Log Sample: Oct 15 10:50:29 switch-DCS7304 Aaa: %AAA-5-LOGIN: user ccadmin logged in [from: ] [service: login]

FIA_UAU.7 None. None. N/A FIA_X509_EXT.1/Rev Unsuccessful attempt Reason for failure CC Guide, Section 4.2.3 to validate a of certificate FCS_TLSS_EXT.2 – TLS Server certificate validation Protocol with Mutual Any additional, Identification of Authentication, p.28 replacement or certificates added, removal of trust replaced or If the TLS connection fails, the anchors in the TOE’s removed as trust following audit log will be trust store. anchor in the generated. The field TOE’s trust store. will contain the information about the failure. The failure codes are as defined in TLS Alert Protocol (see RFC 8446 Appendix B.2).

Format : nginx[] SSL_do_handshake() failed () while SSL handshaking, client:.

18 of 86 Arista Networks Switches Running EOS Assurance Activity Report

FIA_X509_EXT.2 None. None. N/A FIA_X509_EXT.3 None. None. N/A FMT_MOF.1/ManualUpdate Any attempt to initiate None. CC Guide, Section 4.2.8 a manual update FMT_MOF.1/ManualUpdate – Management of Security Functions Behaviour, p.31

Example:

Format: < username > service=shell priv-lvl=15 cmd=copy .

Log Sample: May 24 23:26:38 switch Aaa: %ACCOUNTING-6-CMD: admin vty3 10.95.66.234 stop task_id=2658 start_time=1558765598.5 timezone=EST service=shell priv- lvl=15 cmd=copy flash:EOS.swi.orig flash:EOS.swi

FMT_MTD.1/CoreData None. None. N/A FMT_MTD.1/CryptoKeys None. None. N/A FMT_SMF.1 All management None. CC Guide, Section 4.2.9 activities of TSF data. FMT_SMF.1- Specification of Management Functions, p.32

Example:

Format : service= shell priv-lvl=15 cmd=.

Log Samples: May 24 02:32:54 switch Aaa: %ACCOUNTING-6-CMD: CCUser vty3 10.95.66.234 stop task_id=415 start_time=1558683174.38 timezone=EST service=shell priv- lvl=15 cmd=banner login

FMT_SMR.2 None. None. N/A FPT_SKP_EXT.1 None. None. N/A FPT_APW_EXT.1 None. None. N/A

FPT_TST_EXT.1 None. None. N/A FPT_TUD_EXT.1 Initiation of update; None. N/A result of the update

19 of 86 Arista Networks Switches Running EOS Assurance Activity Report

attempt (success or failure) FPT_STM_EXT.1 Discontinuous The old and new CC Guide, Section 4.2.11 changes values for the FMT_SMF.1- Reliable Time to time - either time. Origin of the Stamps, p.33 Administrator attempt to change actuated or changed time for success Example: via an automated and failure (e.g., process. IP address). Format: (Note that no continuous service=shell changes to time need priv-lvl=15 cmd=clock set also application note on Log Sample: FPT_STM_EXT.1) May 23 21:56:17 switch Aaa: %ACCOUNTING-6-CMD: CCUser vty3 10.95.66.234 stop task_id=264 start_time=1558666577.21 timezone=EST service=shell priv- lvl=15 cmd=clock set 21:56:01 05/23/2019

FTA_SSL_EXT.1 The termination of a None. CC Guide, Section 4.2.12 local session by the FPT_SSL_EXT.1 – TSF Initiated session locking Session Locking, p.33 mechanism. SESSION_IDLE_TIMEOUT Format: Session for user on service terminated due to idle timeout.

Log Sample: May 23 21:40:29 switch SuperServer: %SECURITY-6- SESSION_IDLE_TIMEOUT: Session for user CCUser on service ssh terminated due to idle timeout.

FTA_SSL.3 The termination of a None. CC Guide, Section 4.2.13 remote session by the FPT_SSL.3 – TSF Initiated Session session locking Termination, p.34 mechanism. SESSION_IDLE_TIMEOUT Format: Session for user on service terminated due to idle timeout.

Log Sample: May 23 21:40:29 switch SuperServer: %SECURITY-6- SESSION_IDLE_TIMEOUT: Session for user CCUser on service ssh terminated due to idle timeout.

20 of 86 Arista Networks Switches Running EOS Assurance Activity Report

FTA_SSL.4 The termination of an None. CC Guide, Section 4.2.14 interactive session. FPT_SSL.4 – User Initiated Termination, p.34

Format: user logged out [from: ] [service: ].

Log Sample: May 23 21:17:41 switch Aaa: %AAA-5-LOGOUT: user CCUser logged out [from: 10.95.6 6.234] [service: sshd]

FTA_TAB.1 None. None. N/A FTP_ITC.1 Initiation of the Identification of For trusted channel over SSH trusted channel. the initiator and Tunnel to audit server, see Termination of the target of failed description of audit logs for trusted channel. trusted channels FCS_SSHC_EXT.1. Failure of the trusted establishment channel functions. attempt. For trusted channel over TLS from eAPI client, see description of audit logs for FCS_TLSS_EXT.2 and FIA_X509_EXT.1/Rev . FTP_TRP.1/Admin Initiation of the None. For trusted path over SSH from trusted path. human interactive user to TOE, see Termination of the description of audit logs for trusted path. FCS_SSHS_EXT.1. Failure of the trusted path functions.

(4) During testing, the evaluator closely followed CC Guide. Based on administrative actions defined in the ST, FMT_SMF.1 Specification of Management Functions and initial configuration instructions in CC Guide the evaluator determined that Administrative Actions listed in the Table 5: Audits of Administrative Commands are the entirety of relevant commands for the evaluated configuration.

(5) The evaluator examined the CC Guide, Section 3 and made the determination that administrative commands meet the requirements outlines in the cPP. The evaluator determined that configuration of the TOE into the evaluated configuration generates appropriate level of audit records. The evaluator considered commands issued to the TOE as part of establishing evaluated configuration as well as management commands explicitly defined in the cPP to be security relevant.

21 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Table 5: Audits of Administrative Commands Access Administrative Command Executed Mapping to Privilege Actions Guidance Administrator Configuring audit The local console always displays current audit events when the Section 3.10 – TOE is powered on. Audit Logs However, to configure necessary audit level, the logging trap Configuration commands must be issued. These commands generate appropriate p.12 audit records. See example below:

switch(config)#logging trap informational switch(config)#logging level all 6 switch(config)#logging trap system tag sshd switch(config)#logging trap system tag ssh switch(config)#logging trap system tag nginx switch(config)#logging trap system tag rsyslogd switch(config)#aaa accounting exec default start- stop logging switch(config)#aaa accounting system default start-stop logging switch(config)#aaa accounting commands all default start-stop logging switch(config)#wait-for-warmup switch(config)#show logging switch(config)#write Administrator Shut-down of The audit functions operate at all times. However, it is possible to Section 3.10 – audit functions manually shut it down (and take the TOE out of evaluated Audit Logs configuration). The event generates the following audit record: Configuration p.12 switch(config)#no logging on

Administrator Configure RBAC To enable RBAC mode both AAA Authentication and Authorization Section 3.11 – mode must be configured: Names User Accounts p.13 switch(conf)#aaa authentication login default local switch(conf)#aaa authorization exec default local switch(conf)#aaa authorization commands all default local switch(conf)#aaa authorization serial-console Administrator Configure switch(config-mgmt-security)#password minimum Section 3.2 – password length 8 Hostname, DNS complexity Server, Time Setting, Login Banner and Password Restrictions, p.6 Administrator TLS configuration When operating in FIPS mode, the system is restricted to only the Section 3.12 TLS 1.1 and TLS 1.2 protocol version and support the following TLS Server p.16 cipher suites in line with the NIST SP800-131A Rev 1 policy document

switch(config-mgmt-sec-ssl-profile-TLSserv)#tls versions 1.1 1.2 switch(config-mgmt-sec-ssl- profile-TLSserv)#cipher-list AES128- SHA256:AES256:SHA256:DHE-RSA-AES128-SHA256:DHE- RSA-AES-256-SHA256 switch(config-mgmt-sec-ssl-profile-TLSserv)#write

22 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Administrator FIPS mode To enable FIPS mode, issue the following command: Section 3.12 switch(config-mgmt-sec-ssl-profile-TLSserv)#fips TLS Server - restrictions Section Define Ciphersuites, p.17 Administrator Audit server To configure audit server (syslog), configure cryptographic options Section 3.8 & configuration used by SSH, in particular, symmetric encryption cipher, key 3.9 –SSH exchange, message authentication, server host key algorithms and Configuration & the SSH tunnel. SSH Tunnel, p.9 The command to enable logging to a remote syslog server is as -12. follows: switch(config-mgmt-ssh)#tunnel LogTunnel switch(config-mgmt-ssh-LogTunnel)# local port 514 switch(config-mgmt-ssh-LogTunnel)# ssh-server user authuser port 22 switch (config-mgmt-ssh-LogTunnel)# remote host port 514 Administrator Audit levels The TOE supports multiple audit levels. In the evaluated Section 3.10 – configurations configuration, the logging level must be set at 6. Audit Logs The command is as follows: Configuration, switch(conf)#logging level all 6 p.12 Administrator X.509 Certificate The TOE acts as TLS server (eAPI Server) for an eAPI client Section 3.12 management connection. The TOE requires mutual authentication using X.509 TLS Server, digital certificate for eAPI Client access to the TOE. p.16 An X.509v3 digital certificate is an electronic document used to prove ownership of a public key. It contains information about the key's identity, information about the key's owner, and the digital signature of an entity that has verified the certificate's content as correct. Certificate Authority (CA) The entity that verifies the contents of the digital certificate and signs it indicating that the certificate is valid and correct is called the Certificate Authority (CA). Certificate Signing Request (CSR) An entity that wants a signed certificate or a digital certificate requests one through a CSR. switch#security pki key generate rsa 2048 TLSserv_key

To install a CA certificate, enter the following command: switch(config)# copy usb1:/IntCA_cert.pem certificate: IntCA_cert.pem switch(config)# copy usb1:/RootCA_cert.pem certificate: RootCA_cert.pem Administrator Verifying and To upgrade or downgrade the Arista EOS: Section 3.1 – applying updates 1. Verify the Arista EOS version running on the switch; use the Software Image, show version command in EXEC Privilege mode. This p.4 command displays the current Arista EOS version information on the system. 2. Validate the software image on the USB flash drive (after the image has been transferred to the system, but before the image has been installed), use the verify command in EXEC Privilege mode. This command calculates a hash value of the image file on the USB flash drive.

23 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Administrator Configuring To set the time and date for the switch hardware clock, use the Section 3.2 system time. following command: Hostname, DNS switch(config)# clock timezone Server, Time switch(config)# clock set Setting, Login switch(config)# show clock Banner and password Restrictions, p.6 Administrator Configuring and To configure the banner use the following command: Section 3.2 - modifying access switch(conf)#banner login Hostname, DNS banner. Enter TEXT message. Type ‘EOF’ on its own line to end. Server, Time Setting, Login Example: Banner and password This is a secure switch for networking. Do not attempt to connect to Restrictions, p.6 this switch unless permitted to do so. EOF

switch(config)#write Administrator Termination of To configure the login lockout period, use Section 3.11 interactive remote switch(config) # aaa authentication policy lockout Named User session. failure 3 window 300 duration 900 Accounts, p.13 Administrator Generating/import Command for generating SSH-RSA key: Section 3.12 of cryptographic switch(config)# reset ssh hostkey rsa TLS Server, keys Command for generating TLS Server X.509 private key: p.16 switch(config)# security pki key generate rsa 2048 TLSserv key Command for generating TLS Server X.509 certificate signing request: switch(config)# security pki certificate generate signing-request Copying all of the CA certificates from USB onto the TOE switch# copy usb1:/IntCA_cert.pem certificate: switch# copy usb1:/RootCA_cert.pem certificate: switch# copy usb1:/TLSserv_cert.pem certificate: Installing all the certificates into the TOE switch(config-mgmt-sec-ssl-profile-TLSserv)# certificate TLSserv_cert.pem key TLSserv_key switch(config-mgmt-sec-ssl-profile-TLSserv)# chain certificate IntCA_cert.pem switch(config-mgmt-sec-ssl-profile-TLSserv)# trust certificate IntCA_cert.pem switch(config-mgmt-sec-ssl-profile-TLSserv)# chain certificate RootCA_cert.pem switch(config-mgmt-sec-ssl-profile-TLSserv)# trust certificate RootCA_cert.pem Administrator Changing of Configure cryptographic options used by SSH, in particular, Section 3.6 IP cryptographic symmetric encryption cipher, key exchange, message Address, p.8 keys authentication and server host key algorithms.

switch(config-mgmt-ssh)#cipher aes256-cbc aes128- cbc switch(config-mgmt-ssh)#key-exchange diffie- hellman-group14-sha1 switch(config-mgmt-ssh)#mac hmac-sha2-256 switch(config-mgmt-ssh)#hostkey server rsa

24 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Administrator Deletion of Deleting the system certificate: cryptographic #delete certificate: keys Deleting the CA certificate: #no trust #delete certificate: Administrator Administrative When a system is configured using the factory default configuration, Section 3.11 – login there is only one userid created on the TOE: the “admin” userid. It Named User has no user role associated with it by default. Any additional userids Accounts, p.13 needed for associated user roles must be created.

To create a userid on the TOE, use the following command: switch(conf)# username ccadmin secret 0 “PLAIN_TEXT_PASSWORD” role Administrator User Password User passwords cannot be “reset”, only set / created as new N/A Reset passwords. Administrator On-demand self- The TOE includes a suite of FIPS self-tests that validate the tests integrity of the Arista Crypto Module and verify the implementation of the FIPS DRBG and the cryptographic algorithms. Self-test passed: 00:00:11: %STKUNIT0-M:CP %CRYPTO-5- FIPS_SELF_TEST_PASSED: [sysd] FIPS crypto module self-test passed Self-test failure: 00:00:11: %STKUNIT0-M:CP %CRYPTO-5- FIPS_SELF_TEST_FAILED: [sysd] FIPS crypto module self-test failed

25 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.1.1.3 Testing Assurance Activities

Testing Assurance Activities: (1) The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed in the table of audit events and administrative actions listed above. This should include all instances of an event: for instance, if there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be generated for each mechanism. (2) The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. If HTTPS is implemented, the test demonstrating the establishment and termination of a TLS session can be combined with the test for an HTTPS session. (3) When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the guidance documentation, and that the fields in each audit record have the proper entries. Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly.

Testing Implementation Details/Results: (1) The Evaluator prepared the Audit Report that captured all the TOE generated audit records for the events listed in the Table 5. (2) The TOE utilizes SSH Client to implement a trusted channel with a syslog server, SSH Server to secure CLI interfaces with the remote administrators and TLS Server to offer eAPI scripting functionality. Test cases PP-12A to PP-12G (FCS_SSHS_EXT.1), PP-13A to PP-13H (FCS_SSHC_EXT.1) and PP-15A to PP-15G (FCS_TLSS_EXT.2) confirmed that for the establishment and termination of a secure channel generates appropriate audit records. (3) As part of overall testing effort, the evaluator verified that each secure channel generates appropriate audit records and that each audit record match the format specified in the guidance.

2.1.2 FAU_GEN.2 User Identity Association

2.1.2.1 TSS Assurance Activities

TSS Assurance Activities: The TSS requirements for FAU_GEN.2 are already covered by the TSS requirements for FAU_GEN.1. TSS Implementation Details/Results: N/A

2.1.2.2 Guidance Assurance Activities

Guidance Assurance Activities: The Guidance Documentation requirements for FAU_GEN.2 are already covered by the Guidance Documentation requirements for FAU_GEN.1. Guidance Implementation Details/Results: N/A

2.1.2.3 Testing Assurance Activities

Testing Assurance Activities: This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1. Testing Implementation Details/Results: N/A

26 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.1.3 FAU_STG_EXT.1 Protected Audit Event Storage

2.1.3.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided. (2) The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally; what happens when the local audit data store is full; and how these records are protected against unauthorized access. (3) The evaluator shall examine the TSS to ensure it describes whether the TOE is a standalone TOE that stores audit data locally or a distributed TOE that stores audit data locally on each TOE component or a distributed TOE that contains TOE components that cannot store audit data locally on themselves but need to transfer audit data to other TOE components that can store audit data locally. (4) The evaluator shall examine the TSS to ensure that it details the behaviour of the TOE when the storage space for audit data is full. When the option ‘overwrite previous audit record’ is selected, this description should include an outline of the rule for overwriting audit data. If ‘other actions’ are chosen such as sending the new audit data to an external IT entity, then the related behaviour of the TOE shall also be detailed in the TSS. (5) The evaluator shall examine the TSS to ensure that it details whether the transmission of audit information to an external IT entity can be done in real-time or periodically. In case the TOE does not perform transmission in real- time the evaluator needs to verify that the TSS provides details about what event stimulates the transmission to be made as well as the possible as well as acceptable frequency for the transfer of audit data.

TSS Implementation Details/Results: (1) The evaluator noted that the trusted channel with an audit server is secured with SSH. The evaluator examined the ST Section 7.1 and found the following description: “To protect the audit records in transit from the TOE to the remote audit server in the Operational Environment, the TOE establishes a Trusted Channel between itself and the external audit server using the SSHv2 protocol.” (2) The ST Section 7.1 explains that the audit logs generated by the TSF are stored locally in the persistent Flash memory. The maximum size for the file storing the local audit logs is configurable. When the file exceeds its size limit, it is trimmed to remove the oldest audit logs until the size drops below the configured threshold. (3) The evaluator noted that the TOE is a hardware network switch and is consistently described as such throughout the ST. The evaluator examined the ST Section 7.1 and noted that it includes description of local audit storage. (4) The ST Section 7.1 describes that the when the file exceeds its configured persistent memory size limit, it is trimmed to remove the oldest audit logs until the size drops below the configured threshold. (5) The ST Section 7.1 describes that the TOE can be configured to transfer the audit records to the remote syslog server ST states: “Thus, the rsyslog daemon makes one copy of audit log on the local Flash memory and sends another copy to the configured remote audit server as soon as they are generated.”

2.1.3.2 Guidance Assurance Activities

Guidance Assurance Activities: (1) The evaluator shall also examine the guidance documentation to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server. (2) The evaluator shall also examine the guidance documentation to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server. For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and “cleared” periodically by sending the data to the audit server.

27 of 86 Arista Networks Switches Running EOS Assurance Activity Report

(3) The evaluator shall also ensure that the guidance documentation describes all possible configuration options for FAU_STG_EXT.1.3 and the resulting behaviour of the TOE for each possible configuration. The description of possible configuration options and resulting behaviour shall correspond to those described in the TSS.

Guidance Implementation Details/Results: (1) The evaluator examined the CC Guide, Section 3.8, SSH Configuration and Section 3.9 SSH Tunnel, pages 10- 12, and ensured that it describes how to establish a trusted channel to the audit server using SSH protocol. The SSH is clearly identified as SSHv2 conforming to RFC 4251 in the ST and that SSHv2 is the industry standard for more than a decade, as such SSH can be understood to implicitly state v2.The guidance provides all the necessary steps to integrate TOE and Syslog Server to establish a secure communication between them . (2) The evaluator examined the CC Guide, Section 3.9.2 Tunnel Endpoint on the Switch, page 11, and ensured that it describes how audit data is synchronized with the external audit server. The guidance states that when an audit event is generated, it is simultaneously sent to the external server and the local store. (3) The evaluator examined the CC Guide, Section 3.10 Audit Logs Configuration, page 12, and ensured that it describes configuration option for FAU_STG_EXT.1.3 periodic audit log rotation (delete the oldest log file) and ensured that the TOE overwrites the oldest log in the file when it reaches the persistent log size.

2.1.3.3 Testing Assurance Activities

Testing Assurance Activities: Testing of the trusted channel mechanism for audit will be performed as specified in the associated assurance activities for the particular trusted channel mechanism. The evaluator shall perform the following additional test for this requirement: Test 1: (1) The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. (2) The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. (3) The evaluator shall record the particular software (name, version) used on the audit server during testing. (4) The evaluator shall verify that the TOE is capable of transferring audit data to an external audit server automatically without administrator intervention. Test 2: (1) The evaluator shall perform operations that generate audit data and verify that this data is stored locally. (2) The evaluator shall perform operations that generate audit data until the local storage space is exceeded and verifies that the TOE complies with the behaviour defined in FAU_STG_EXT.1.3. Depending on the configuration this means that the evaluator has to check the content of the audit data when the audit data is just filled to the maximum and then verifies that 1) The existing audit data is overwritten with every new auditable event that should be tracked according to the specified rule (for the option ‘overwrite previous audit records’ in FAU_STG_EXT.1.3) The TOE behaves as specified (for the option ‘other action’ in FAU_STG_EXT.1.3). Testing Implementation Details/Results: The evaluator followed the procedures outlines in the guidance to configure TOE audit functionality. Test 1: (1) The evaluator followed the CC Guide, Section 8 SSH Configuration, Section 3.9 SSH Tunnel and Section 3.10 Audit Logs Configuration to establish a secure connection between the TOE and the audit server. (2) The evaluator examined network traffic, observed a successful SSH handshake and encrypted data sent between the TOE and the audit server, and concluded that a secure channel was successfully established between the TOE and the remote audit server. During this period, the evaluator observed audit records

28 of 86 Arista Networks Switches Running EOS Assurance Activity Report

updated on the remote audit server and concluded that these audit records were sent as part of encrypted traffic. See test case PP-8A for audit details. (3) The evaluator used Wireshark software and a mirroring port on a core switch to view and capture relevant network traffic exchange between the TOE and the remote audit server. (4) Upon finishing setting up the SSH tunnel between the TOE and the Audit Server, the evaluator noted audit events messages showing up on the audit server event’s log file for every CLI Commands issued, without needing any administrator intervention.

Test 2: (1) The evaluator executed the commands from the CC guide and confirmed using the CLI commands (show logging system and show logging all) given in the guidance document to confirm that the logs are generated and stored locally. The evaluator used the Section 4 of the CC guide to compare the format and details of the audit logs generated by the TOE. (2) The evaluator configured the persistent logging bytes on TOE so that if the bytes of the logs go over the persistent value configuration, oldest audit record will be first. The evaluator used a custom script to populate the audit records in the local audit log file. Prior to running the script, the evaluator issued a command to clear the local audit log. The evaluator observed the deletion of old audit records when the local log exceeded the allocated space using the “logging persistent 4096” bytes as given in the guidance document. This observation confirmed that the oldest audit record was deleted first, which is consistent to how it is described in the ST. See test case PP-8C for details.

2.2 Cryptographic Support (FCS)

2.2.1 FCS_CKM.1 Cryptographic Key Generation

2.2.1.1 TSS Assurance Activities

TSS Assurance Activities: The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme. TSS Implementation Details/Results: The ST Section 7.2 entry for FCS_CKM.1 states: “The TSF supports generation of 2048-bit RSA asymmetric keys for eAPI TLS server authentication and for SSH client and SSH server authentication. The supported RSA scheme meets the FIPS PUB 186-4, Digital Signature Standard (DSS), Appendix B.3 standard. The TSF generates Diffie-Hellman Group 14 asymmetric keys for session keys establishment in SSH and TLS session according to RFC 3526, Section 3.”

2.2.1.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all cryptographic protocols defined in the Security Target. Guidance Implementation Details/Results: The TOE implements SSH client and server that use RSA key authentication and TLS server that uses X509 –based (using RSA-based certificate) mutual authentication.

29 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The evaluator examined the CC Guide, Section 3.12, TLS Server, Page 16 and verified that it contains instructions for the administrator to configure the cipher suites for TOE (AES128-SHA256:AES256-SHA256:DHE-RSA-AES128- SHA256:DHE-RSAAES256-SHA256)for the TLS communication.

2.2.1.3 Testing Assurance Activities

Testing Assurance Activities: None Testing Implementation Details/Results: The Arista EOS Crypto Module v1.0 is CMVP #2909 certified software cryptographic module and is covered by the following CAVP certificates: • AES: CAVP# 4280 • RSA: CAVP# 2301 • SHS: CAVP# 3516 • DRBG: CAVP# 1340 • HMAC: CAVP# 2816 There is no testing activity for this section in the SD.

2.2.2 FCS_CKM.2 Cryptographic Key Establishment

2.2.2.1 TSS Assurance Activities

TSS Assurance Activities: The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme (including whether the TOE acts as a sender, a recipient, or both). If Diffie- Hellman group 14 is selected from FCS_CKM.2.1, the TSS shall describe how the implementation meets RFC 3526 Section 3. TSS Implementation Details/Results: The evaluator examined the ST Section 7.2 and determined that the key establishment schemes specified in FCS_CKM.2 correspond to the key generation schemes claimed in FCS_CKM.1. The TSF implements TLS Server supporting RSA (as part of TLS_RSA ciphers) and Ephemeral Diffie-Hellman (as part of TLS_DHE ciphers) key establishment schemes, and SSH Client and Server support Ephemeral Diffie-Hellman key establishment scheme. When a key establishment (or key exchange) uses Ephemeral Diffie-Hellman method, temporary keys are generated for every connection. The ST Section 7.2 reflects this by stating: “The TSF generates Diffie-Hellman Group 14 asymmetric keys for session keys establishment in SSH and TLS session according to RFC 3526, Section 3”. When RSA key exchange is used, existing RSA public keys are used to establish a session key. The TOE’s cryptographic module includes algorithm capabilities for FIPS PUB 186-4 key generation. The ST Section 7.2 reflects this by stating: “The TSF supports generation of 2048-bit RSA asymmetric keys for eAPI TLS server authentication and for SSH client and SSH server authentication. The supported RSA scheme meets the FIPS PUB 186-4, Digital Signature Standard (DSS), and Appendix B.3 standard”. With TLS 1.2 using RSA Key Exchange (TLS_RSA ciphers), the client always generates the pre-master secret and sends it to the server. For Diffie-Hellman (TLS_DHE ciphers), the pre-master secret is a result of the mutual key agreement using values from both client and server and is not ever transmitted. However, the client will always initiate the TLS handshake with a Client Hello and server always selects cipher and for DHE ciphers provides the parameters (prime modulus p and generator g). RFC 3526, Section 3 contains predefined 2048-bit MODP group id 14, commonly known as Diffie-Hellman Group 14. The ST Section 7.2 explains how the TSF meets RFC 3526, Section 3 by stating: “The TSF generates Diffie- Hellman Group 14 asymmetric keys for session keys establishment in SSH and TLS session according to RFC 3526, Section 3”.

2.2.2.2 Guidance Assurance Activities

Guidance Assurance Activities:

30 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s). Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.8, SSH Configuration, Page 9 and verified that it instructs the administrator how to configure the TOE to use the selected key establishment scheme(s).

2.2.2.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall verify the correctness of the TSF’s implementation of RSAES-PKCS1-v1_5 by using a known good implementation for each protocol selected in FTP_TRP.1/Admin, FTP_TRP.1/Join, FTP_ITC.1 and FPT_ITT.1 that uses RSAES-PKCS1-v1_5.

Note: TD0402 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=412 was applied. Testing Assurance Activities Details/Results:

Evaluator checked the ST, and found that it is listing the relevant SFRs: FTP_TRP.1/Admin with SSH as the only selection and FTP_ITC.1 with SSH and TLS as the selections. These selections correspond to FCS_SSHC_EXT.1, FCS_SSHS_EXT.1 and FCS_TLSS_EXT.2 SFRs. To verify correctness of implementation of each protocol the evaluator used known good implementation (Syslog Server syslog-ng 3.19 CentOS flavor, Bitvise SSH Client v8.27, Bitvise Server v8.35, Custom TLS tool) to confirm the interoperability. To test the FCS_SSHC_EXT.1, a SSH connection from the TOE to the Syslog server was established to transfer the audit logs. In case of testing SSH server, a CLI over SSH session using Bitvise client was established. In case of testing TOE’s TLS server feature, a TLS connection was made from an eAPI client host (CentOS 7) using the open-source wget command (an utility used to retrieve files using HTTP, HTTPS and FTP). The wget utility was used to test the remote administration of the TOE over https. The evaluator considers Bitvise Client v8.27, Bitvise Server v8.35, Syslog server 3.19 and CentOS 7 to be known good implementations and considers successful session establishment to be an evidence of correct RSAES-PKCS1-v1_5 and Diffie-Hellman Group 14 implementations. In addition to the above described cryptographic operations, the TOE performs cryptographic RSA-Based signature generation and verification via the Arista EOS Crypto Module v(1.0), which was tested according to the Cryptographic Algorithm Validation Program (CAVP) and was awarded the certificate number 2301 covering RSA-based signature generation.

2.2.3 FCS_CKM.4 Cryptographic Key Destruction

2.2.3.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator examines the TSS to ensure it lists all relevant keys (describing the origin and storage location of each), all relevant key destruction situations (e.g. factory reset or device wipe function, disconnection of trusted channels, key change as part of a secure channel protocol), and the destruction method used in each case. For the purpose of this Evaluation Activity, the relevant keys are those keys that are relied upon to support any of the SFRs in the Security Target.

(2) The evaluator confirmed that the description of keys and storage locations is consistent with the functions carried out by the TOE (e.g. that all keys for the TOE-specific secure channels and protocols, or that support FPT_APW.EXT.1 and FPT_SKP_EXT.1, are accounted for). In particular, if a TOE claims not to store plaintext keys in non-volatile memory then the evaluator checks that this is consistent with the operation of the TOE.

(3) The evaluator shall check to ensure the TSS identifies how the TOE destroys keys stored as plaintext in non- volatile memory, and that the description includes identification and description of the interfaces that the TOE uses to destroy keys (e.g., file system APIs, key store APIs).

31 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Note that where selections involve ‘destruction of reference’ (for volatile memory) or ‘invocation of an interface’ (for non-volatile memory) then the relevant interface definition is examined by the evaluator to ensure that the interface supports the selection(s) and description in the TSS. In the case of non-volatile memory the evaluator includes in their examination the relevant interface description for each media type on which plaintext keys are stored. The presence of OS-level and storage device-level swap and cache files is not examined in the current version of the Evaluation Activity.

(4) Where the TSS identifies keys that are stored in a non-plaintext form, the evaluator shall check that the TSS identifies the encryption method and the key-encrypting-key used, and that the key-encrypting-key is either itself stored in an encrypted form or that it is destroyed by a method included under FCS_CKM.4.

(5) The evaluator shall check that the TSS identifies any configurations or circumstances that may not conform to the key destruction requirement (see further discussion in the Guidance Documentation section below). Note that reference may be made to the Guidance Documentation for description of the detail of such cases where destruction may be prevented or delayed.

(6) Where the ST specifies the use of “a value that does not contain any CSP” to overwrite keys, the evaluator examines the TSS to ensure that it describes how that pattern is obtained and used, and that this justifies the claim that the pattern does not contain any CSPs. TSS Implementation Details/Results: The evaluator examined the ST Section 7.2 TSS and noted that it lists all relevant keys (describing the origin and storage location of each), all relevant key destruction situations (e.g. factory reset or device wipe function, disconnection of trusted channels, key change as part of a secure channel protocol), and the destruction method used in each case. (1) The evaluator confirmed that Table 18 in the Section 7.2 contains the list of plaintext CSPs, the purpose of the keys, and storage location of each key, key generation process, method of zeroization and situation of zeroization.

(2) The evaluator confirmed that Table 18 in the Section 7.2 contains the list of all keys generated and used for the TOE-specific secure channels and protocols, or that support FPT_APW.EXT.1 and FPT_SKP_EXT.1, are accounted for and their storage locations. The description of keys and storage locations provides a general understanding of the implemented functionality. However, the evaluators have no direct access to the underlying implementation and have no way to verify these claims other than to confirm that the TSS section includes such claims and that they are plausible.

(3) The evaluator checked the ST Section 7.2 and confirmed that the TSS section contains information on the key destruction requirements as the following: “The programmatic destruction of keys is carried out by using a specialized algorithm that iteratively overwrites the file location with patterns to ensure the key is destroyed. This is structured in such a way that any updates to the cryptographic key files ( creation, modification, deletion ) result in all previous key files being destroyed prior to the new files being written. As such, there is no delay in the destruction of keys. At the physical layer, non-volatile memory is implemented on the TOE by either eUSB, eMMC, or SSD devices. These have a minimal write endurance of 17 TeraBytes, which under normal usage are expected to last the lifetime of the device. In the unlikely event that there is a write-failure, the issue will be reported in the logging system. In such circumstances it is recommended to replace the media and physically destroy the faulty non-volatile memory device.”

(4) TSS section does not identify any keys that are stored in a non-plaintext form. The TOE, a discrete appliance that enforces access control, does not protect keys stored in the non-volatile memory.

(5) The TOE is not subjected to any situations that could prevent or delay key destruction.

(6) Where the ST specifies the use of “a value that does not contain any CSP” to overwrite keys, the evaluator examined the TSS to ensure that it describes how that pattern is obtained and used, and that this justifies the claim that the pattern does not contain any CSPs. The evaluator confirmed that this selection is not made within the ST.

32 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.2.3.2 Guidance Assurance Activities

Guidance Assurance Activities: A TOE may be subject to situations that could prevent or delay key destruction in some cases. The evaluator shall check that the guidance documentation identifies configurations or circumstances that may not strictly conform to the key destruction requirement, and that this description is consistent with the relevant parts of the TSS (and any other supporting information used). The evaluator shall check that the guidance documentation provides guidance on situations where key destruction may be delayed at the physical layer.

For example, when the TOE does not have full access to the physical memory, it is possible that the storage may be implementing wear-levelling and garbage collection. This may result in additional copies of the key that are logically inaccessible but persist physically. Where available, the TOE might then describe use of the TRIM command and garbage collection to destroy these persistent copies upon their deletion (this would be explained in TSS and Operational Guidance). Guidance Assurance Activities Details/Results: As per the ST, The TOE is not subjected to any situations that could prevent or delay key destruction. The evaluator checked the CC guide Sections 3.8 (SSH Configuration) and Section 3.12 (TLS Server), and confirmed that the guidance document contains instructions to permanently delete the unused or unwanted keys and certificates from the TOE.

2.2.3.3 Testing Assurance Activities

Testing Assurance Activities: None Testing Assurance Activities Details/Results: N/A

2.2.4 FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption)

2.2.4.1 TSS Assurance Activities

TSS Assurance Activities: None TSS Implementation Details/Results: N/A

2.2.4.2 Guidance Assurance Activities

Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A

2.2.4.3 Testing Assurance Activities

Testing Assurance Activities: Specific algorithm tests are detailed in the Supporting Document Section 2.2.4.1 Testing Assurance Activities Details/Results: The evaluator verified that the TOE’s encryption/decryption implementation as validated by CAVP AES certificates: #4280 using the exact version of the cryptographic module following appropriate installation and usage guidance. This validates AES as defined in NIST SP 800-38A.

2.2.5 FCS_COP.1/SigGen Cryptographic Operation (Signature Generation and Verification

2.2.5.1 TSS Assurance Activities

TSS Assurance Activities: None TSS Implementation Details/Results: N/A

33 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.2.5.2 Guidance Assurance Activities

Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A

2.2.5.3 Testing Assurance Activities

Testing Assurance Activities: Specific algorithm tests are detailed in the Supporting Document Section 2.2.5.1 Testing Assurance Activities Details/Results: The evaluator verified that the TOE’s Signature Generation and Verification implementation as validated by CAVP RSA certificates: #2301 using the exact version of the cryptographic module following appropriate installation and usage guidance. This validates RSA schemes using cryptographic key sizes [of 2048-bit or greater] as defined in FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4.

2.2.6 FCS_COP.1/Hash Cryptographic Operation (Hash Algorithm)

2.2.6.1 TSS Assurance Activities

TSS Assurance Activities: The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS. TSS Implementation Details/Results: The evaluator checked the ST Section 7.2 and confirmed that the TSS identifies hashing functionality used by other cryptographic functionality, specifically:  Table 17 entry for FCS_COP.1/Hash details hashing functionality using SHA-1, SHA-256, SHA-384 and SHA- 512.  Table 17 entry for FCS_COP.1/KeyedHash lists keyed hash algorithm parameters that utilize HMAC-SHA2- 256. The evaluator examined these descriptions and concluded that they are consistent and match functionality claimed in SHS cert #3516 certificate and HMAC cert #2816.

2.2.6.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator checks the AGD documents to determine that any configuration that is required to configure the required hash sizes is present. Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.8, SSH Configuration Page 9 along with 3.12, TLS Server Page 16 and confirmed that the guide contains instructions for configuring the required hash size for the message authentication.

2.2.6.3 Testing Assurance Activities

Testing Assurance Activities: Specific algorithm tests are detailed in the Supporting Document Section 2.2.6.3. Testing Assurance Activities Details/Results: The evaluator verified that the TOE’s hashing implementation as validated by CAVP SHS certificates: #3516 using the exact version of the cryptographic module following appropriate installation and usage guidance. This validates the claims of conformance for the TOE’s hashing functionality to FIPS PUB 180-4 or ISO/IEC 10118-3:2004 “Secure Hash Standard” within its operational environment.

34 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.2.7 FCS_COP.1/KeyedHash Cryptographic Operation (Keyed Hash Algorithm)

2.2.7.1 TSS Assurance Activities

TSS Assurance Activities: The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used. TSS Implementation Details/Results: The evaluator examined the ST Section 7.2 Table 17 and noted that it references CAVP #2816 that specifies the algorithm as HMAC-SHA2-256, supported cryptographic key length as 256 bits, message digest size as 256 bits and the hash functions used. It matches with the ST Section 6.1.2.7.

2.2.7.2 Guidance Assurance Activities

Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A

2.2.7.3 Testing Assurance Activities

Testing Assurance Activities: For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set shall consist of a key and message data. The evaluator shall have the TSF generate HMAC tags for these sets of test data. The resulting MAC tags shall be compared to the result of generating HMAC tags with the same key and message data using a known good implementation. Testing Assurance Activities Details/Results: The evaluation team verified that the TOE’s keyed hashing implementation as validated by CAVP HMAC certificate #2816 using the exact version of the cryptographic module following appropriate installation and usage guidance. This validates the claim of conformance for the TOE’s keyed hashing functionality to FIPS PUB 198-1.

35 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.2.8 FCS_RBG_EXT.1 Extended: Cryptographic Operation (Random Bit Generation)

2.2.8.1 TSS Assurance Activities

TSS Assurance Activities: The evaluator shall examine the TSS to determine that it specifies the DRBG type, identifies the entropy source(s) seeding the DRBG, and state the assumed or calculated min-entropy supplied either separately by each source or the min-entropy contained in the combined seed value. TSS Assurance Activities Details/Results: The evaluator examined the ST Section 7.2 and determined the DRBG type and the entropy sources from the following statement in the ST that “The TOE uses a software-based CTR_DRBG (AES-256) random bit generator (DRBG) that complies with NIST SP 800-90 for all cryptographic operations. Each DRBG instance is seeded with full 384 bits of entropy (256 bits for AES key and 128 bits for nonce) sourced from Linux Random Number Generator (LRNG) operating in a blocking mode (/dev/random). LRNG accumulates entropy from two software based noise sources: i) interrupt times via add_interrupt_randomness function, and ii) variability in timing of instructions executions in CPU using “Haveged” daemon.” The detailed entropy justification is provided in a separate [ENT] document.

2.2.8.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation contains appropriate instructions for configuring the RNG functionality. Guidance Assurance Activities Details/Results: This cryptographic functionality is not administrator-configurable.

2.2.8.3 Testing Assurance Activities

Testing Assurance Activities: Specific algorithm tests are detailed in the Supporting Document Section 2.2.8.3. Testing Assurance Activities Details/Results: The evaluator verified that the TOE uses a software based CTR_DRBG (AES-256) random bit generator (DRBG) that complies with NIST SP 800-90 for all cryptographic operations. The evaluator examined the CC Guide and confirmed that the Section 3.7 Entropy covers instructions to enable Havege source of entropy for RNG. Network Interrupts source is always running when the switch is running. The Havege algorithm extracts entropy from CPU flutter and for that, Haveged deamon needs to be enabled using the following commands: switch(config)#management security switch(config-mgmt-sec)#entropy source haveged

2.2.9 FCS_SSHC_EXT.1 SSH Client

2.2.9.1 FCS_SSHC_EXT.1.2

2.2.9.1.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication and that this list conforms to FCS_SSHC_EXT.1.5. and ensure that if password- based authentication methods have been selected in the ST then these are also described. TSS Assurance Activities Details/Results: The evaluator examined the ST Section 7.2 and confirmed that TOE supports only public key authentication to the external audit server. The ST Section 7.2 describes the public key algorithms that are acceptable for use for

36 of 86 Arista Networks Switches Running EOS Assurance Activity Report

authentication through the following statement: “Following public key scheme is supported: rsa-sha2- 256 that uses 2048-bit RSA key and SHA-256 digital signature”. This description matches with FCS_SSHC_EXT.1.5, as provided in the ST Section 6.1.2.9.

2.2.9.1.2 Guidance Assurance Activities Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A

2.2.9.1.3 Testing Assurance Activities Testing Assurance Activities: Test 1: If password-based authentication methods have been selected in the ST then using the guidance documentation, the evaluator shall configure the TOE to perform password-based authentication to an SSH server, and demonstrate that a user can be successfully authenticated by the TOE to an SSH server using a password as an authenticator. Note: Public key authentication is tested as part of testing for FCS_SSHC_EXT.1.5 Testing Assurance Activities Details/Results: Test1: TOE as a SSH client authenticates to the audit server only using the public key. Public key authentication was tested as part of testing for FCS_SSHC_EXT.1.5. Public Key Authentication is enabled for the user in the syslog configuration file such that the TOE and Syslog server should mutually authenticate using the public key before establishing the SSH connections. As part of SSH Client testing, the evaluator loaded syslog’s public key and associated it with the server’s identity on the TOE. Then observed successful SSH connection to the syslog server with the correct public key (Test Case PP- 13D) and failed SSH connection when connecting the server with a different non-matching public key (Test Case PP- 13D) the evaluator concluded that public key authentication works correctly. Password-based authentication is not claimed, is not supported, and consequently was not tested. Please refer to test case PP-13D for more details.

2.2.9.2 FCS_SSHC_EXT.1.3

2.2.9.2.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check that the TSS describes how “large packets” in terms of RFC 4253 are detected and handled. TSS Assurance Activities Details/Results: The evaluator checked the ST Section 7.2 and confirmed that the following TSS content describes how the large packets are detected and handled.

“In order to comply with RFC 4253, “large packets” received by the SSH client (packets greater than 262,144-bytes) in the SSH connection are dropped”.

2.2.9.2.2 Guidance Assurance Activities Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A

2.2.9.2.3 Testing Assurance Activities Testing Assurance Activities: The evaluator shall demonstrate that if the TOE receives a packet larger than that specified in this component, that packet is dropped. Testing Assurance Activities Details/Results: The evaluator used a custom tool to send “an artificially padded large SSH handshake packet“. The modified packet, server key exchange init, included the supported cipher list padded with a repeated ‘the-quick-brow’

37 of 86 Arista Networks Switches Running EOS Assurance Activity Report

garbage string until the packet was of the desired length. Using packet capture, an application layer rejection was observed. See PP-13B test case for details.

2.2.9.3 FCS_SSHC_EXT.1.4

2.2.9.3.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the encryption algorithms supported are specified as well. The evaluator shall check the TSS to ensure that the encryption algorithms specified are identical to those listed for this component. TSS Assurance Activities Details/Results: The evaluator noted that the ST Section 7.2 describes that the TOE implements the SSHv2 protocol and supports the following encryption algorithms: aes128-cbc and aes256-cbc. The evaluator checked TSS section and ensured that the encryption algorithms specified are identical to those listed for this SFR in Section 6.1.2.9.

2.2.9.3.2 Guidance Assurance Activities Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements). Guidance Assurance Activities Details/Results: The evaluator checked the CC guide Section 3.8 SSH Configuration and confirmed that the section contains instructions to configure the TOE to accept only aes128-cbc and aes256-cbc encryption algorithms so that SSH conforms to the description in the TSS.

2.2.9.3.3 Testing Assurance Activities Testing Assurance Activities: (1) The evaluator must ensure that only claimed ciphers and cryptographic primitives are used to establish a SSH connection. To verify this, the evaluator shall start session establishment for a SSH connection with a remote server (referred to as ‘remote endpoint’ below). (2) The evaluator shall capture the traffic exchanged between the TOE and the remote endpoint during protocol negotiation (e.g. using a packet capture tool or information provided by the endpoint, respectively). (3) The evaluator shall verify from the captured traffic that the TOE offers all the ciphers defined in the TSS for the TOE for SSH sessions, but no additional ones compared to the definition in the TSS. (4) The evaluator shall perform one successful negotiation of an SSH session to verify that the TOE behaves as expected. It is sufficient to observe the successful negotiation of the session to satisfy the intent of the test. (5) If the evaluator detects that not all ciphers defined in the TSS for SSH are supported by the TOE and/or the TOE supports one or more additional ciphers not defined in the TSS for SSH, the test shall be regarded as failed.

Testing Assurance Activities Details/Results: (1) The evaluator verified through test case PP-13D that only claimed ciphers (aes128-cbc and aes256-cbc) and cryptographic primitives are used to establish a SSH transport connection. The evaluator configured the TOE to use only aes128-cbc and aes256-cbc as the acceptable ciphers and verified in the audit logs that the session establishment attempt negotiated aes128-cbc as the cipher the first time and aes256-cbc as the cipher the second time and that each session was established successfully. (2) The evaluator used Wireshark for the traffic capture between the TOE and the remote endpoint during protocol negotiation. (3) The evaluator verified the output of the packet capture, and concluded that the TOE proposed a cipher suite list of aes128-cbc and aes256-cbc and no other ciphers. (4) The evaluator verified through test case PP-13A that the TOE successfully negotiated the claimed ciphers for to establish SSH transport connection and confirmed that the TOE behaves as expected.

38 of 86 Arista Networks Switches Running EOS Assurance Activity Report

(5) The evaluator verified through test case PP-13C that the TOE supports only the ciphers listed in the TSS section of the SSH and rejected all the connection attempts that proposed ciphers that are not claimed in the ST.

2.2.9.4 FCS_SSHC_EXT.1.5

2.2.9.4.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the public key algorithms supported are specified as well. The evaluator shall check the TSS to ensure that the public key algorithms specified are identical to those listed for this component. TSS Assurance Activities Details/Results: The evaluator checked the ST Section 7.2, which details that the TOE implements rsa-sha2-256 for public key authentication that uses 2048-bit RSA key and SHA-256 digital signature. The evaluator verified the TSS to ensure that the public key specified is identical to that listed for this SFR in Section 6.1.2.9 of the ST. Listing all relevant RFCs clearly defines SSH protocol use and that no other optional characteristics are present in the product.

2.2.9.4.2 Guidance Assurance Activities Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements). Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.8, SSH Configuration, Page 9 and confirmed that the CC guide contains instructions on configuring the TOE so that SSH conforms to the description in the TSS.

2.2.9.4.3 Testing Assurance Activities Testing Assurance Activities: Test 1: The evaluator shall establish a SSH connection using each of the public key algorithms specified by the requirement to authenticate an SSH server to the TOE. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. Test 2: The evaluator shall configure an SSH server to only allow a public key algorithm that is not included in the ST selection. The evaluator shall attempt to establish an SSH connection from the TOE to the SSH server and observe that the connection is rejected. Testing Assurance Activities Details/Results: Test 1: The evaluator verified through test case PP-13D that the TOE supports only the ciphers listed in the TSS section of the ST. Test 2: The evaluator verified through test case PP-13D that selecting a non-supported public key algorithm (ecdsa) for SSH connection failed to establish a connection between the TOE and the SSH Server.

2.2.9.5 FCS_SSHC_EXT.1.6

2.2.9.5.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check the TSS to ensure that it lists the supported data integrity algorithms, and that that list corresponds to the list in this component. TSS Assurance Activities Details/Results: The evaluator checked the ST Section 7.2 and noted that it contains information about the supported integrity algorithm. The TOE implements SSHv2 protocol and supports the following data integrity algorithm: hmac-sha2-256.

39 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The list of supported data integrity algorithms corresponds to the list in this component in Section 6.1.2.9.

2.2.9.5.2 Guidance Assurance Activities Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed data integrity algorithms are used in SSH connections with the TOE (specifically, that the “none” MAC algorithm is not allowed). Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.8, SSH Configuration, Page 9 and confirmed that it contains instructions to the administrator to configure and verify the allowed data integrity algorithm (hmac-sha2-256)that are used in the SSH connections with the TOE.

2.2.9.5.3 Testing Assurance Activities Testing Assurance Activities: Test 1: (conditional, if an HMAC or AEAD_AES_*_GCM algorithm is selected in the ST) The evaluator shall establish an SSH connection using each of the algorithms, except “implicit”, specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. Note: To ensure the observed algorithm is used, the evaluator shall ensure a non-aes*[email protected] encryption algorithm is negotiated while performing this test. Test 2: (conditional, if an HMAC or AEAD_AES_*_GCM algorithm is selected in the ST) The evaluator shall configure an SSH, server to only allow a MAC algorithm that is not included in the ST selection. The evaluator shall attempt to connect from the TOE to the SSH server and observe that the attempt fails. Note: To ensure the proposed MAC algorithm is used, the evaluator shall ensure a non-aes*- [email protected] encryption algorithm is negotiated while performing this test. Testing Assurance Activities Details/Results: Test 1: The evaluator verified through test case PP-13E that the TOE establishes SSH connection using only the hmac-sha2-256 integrity algorithm as listed in the TSS section of the ST. Test 2: The evaluator verified through test case PP-13E that selecting a non-supported hashing algorithm (hmac- sha1) for SSH connection failed to establish a connection between the TOE and the SSH Server.

2.2.9.6 FCS_SSHC_EXT.1.7

2.2.9.6.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check the TSS to ensure that it lists the supported key exchange algorithms, and that that list corresponds to the list in this component. TSS Assurance Activities Details/Results: The evaluator checked the ST Section 7.2, which explains that the TOE supports Diffie-hellman-group14-sha1 as its key exchange algorithm.

This list corresponds to the list in this component in Section 6.1.2.9.

2.2.9.6.2 Guidance Assurance Activities Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed key exchange algorithms are used in SSH connections with the TOE. Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.8, SSH Configuration, Page 9 and confirmed that it contains instructions to the administrator to configure and verify the allowed key exchange algorithm (Diffie-hellman- group14-sha1) that are used in the SSH connections with the TOE.

40 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.2.9.6.3 Testing Assurance Activities Testing Assurance Activities: Test 1: The evaluator shall configure an SSH server to permit all allowed key exchange methods. The evaluator shall attempt to connect from the TOE to the SSH server using each allowed key exchange method, and observe that each attempt succeeds. Testing Assurance Activities Details/Results: Test 1: The evaluator verified through test case PP-14F that the TOE establishes SSH connection using only the Diffie-hellman-group14-sha1 key-exchange algorithms as listed in the TSS section of the ST.

2.2.9.7 FCS_SSHC_EXT.1.8

2.2.9.7.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check that the TSS specifies the following: a) Both thresholds are checked by the TOE. b) Rekeying is performed upon reaching the threshold that is hit first. TSS Assurance Activities Details/Results: The evaluator confirmed that the ST Section 7.2 details that an SSH connection is automatically rekeyed by default after 60 minutes or 1 GB of data, both of these thresholds are included as part of the design and not administrator configurable.

2.2.9.7.2 Guidance Assurance Activities Guidance Assurance Activities: If one or more thresholds that are checked by the TOE to fulfil the SFR are configurable, then the evaluator shall check that the guidance documentation describes how to configure those thresholds. Either the allowed values are specified in the guidance documentation and must not exceed the limits specified in the SFR (one hour of session time, one gigabyte of transmitted traffic) or the TOE must not accept values beyond the limits specified in the SFR. The evaluator shall check that the guidance documentation describes that the TOE reacts to the first threshold reached. Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.8, SSH Configuration, Page 9-10 and confirmed that it contains instructions to the administrator to configure the rekeying frequency (every 1 Gb) and rekeying interval (1 hour).

2.2.9.7.3 Testing Assurance Activities Testing Assurance Activities: The evaluator needs to perform testing that rekeying is performed according to the description in the TSS. The evaluator shall test both, the time-based threshold and the traffic-based threshold. For testing of the time-based threshold the evaluator shall use the TOE to connect to an SSH server and keep the session open until the threshold is reached. The evaluator shall verify that the SSH session has been active longer than the threshold value and shall verify that the TOE initiated a rekey (the method of verification shall be reported by the evaluator). Testing does not necessarily have to be performed with the threshold configured at the maximum allowed value of one hour of session time but the value used for testing shall not exceed one hour. The evaluator needs to ensure that the rekeying has been initiated by the TOE and not by the SSH server the TOE is connected to. For testing of the traffic-based threshold the evaluator shall use the TOE to connect to an SSH server, and shall transmit data from and to the TOE within the active SSH session until the threshold for transmitted traffic is reached. The transmitted traffic is the total traffic comprising incoming and outgoing traffic. The evaluator shall verify that more data has been transmitted within the SSH session than the threshold allows and shall verify that the TOE initiated a rekey (the method of verification shall be reported by the evaluator). Testing does not necessarily have to be performed with the threshold configured at the maximum allowed value of one gigabyte of transferred traffic but the value used for testing shall not exceed one gigabyte. The evaluator needs to ensure that the rekeying has been initiated by the TOE and not by the SSH server the TOE is connected to. If one or more thresholds that are checked by the TOE to fulfil the SFR are configurable, the evaluator needs to verify that the threshold(s) can be configured as described in the guidance documentation and the evaluator needs to test that modification of the thresholds is restricted to Security Administrators (as required by FMT_MOF.1/Functions).

41 of 86 Arista Networks Switches Running EOS Assurance Activity Report

In cases where data transfer threshold could not be reached due to hardware limitations it is acceptable to omit testing of this (SSH rekeying based on data transfer threshold) threshold if both the following conditions are met: a) An argument is present in the TSS section describing this hardware-based limitation and b) All hardware components that are the basis of such argument are definitively identified in the ST. For example, if specific Ethernet Controller or WiFi radio chip is the root cause of such limitation, these chips must be identified. Testing Assurance Activities Details/Results: The evaluator configured the TOE’s SSH rekey settings based on time-based (rekey interval 5 minutes) and traffic-based thresholds (rekey frequency 1 MB) as provided in the CC Guide. For the time-based threshold, the evaluator prevented the session from timing out while waiting for the rekey to happen. For traffic-based threshold, the evaluator repeatedly used the #show tech-support command. The evaluator observed the rekeying happening after every 5 minutes and when the data threshold exceeded 1MB through the local audit logs and remote audit logs. Please refer to PP-13G for more details.

2.2.9.8 FCS_SSHC_EXT.1.9

2.2.9.8.1 TSS Assurance Activities TSS Assurance Activities: None TSS Assurance Activities Details/Results: N/A

2.2.9.8.2 Guidance Assurance Activities Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A

2.2.9.8.3 Testing Assurance Activities Testing Assurance Activities: Test 1: The evaluator shall delete all entries in the TOE’s list of recognized SSH server host keys and, if selected, all entries in the TOE’s list of trusted certification authorities. The evaluator shall initiate a connection from the TOE to an SSH server. The evaluator shall ensure that the TOE either rejects the connection or displays the SSH server’s public key (either the key bytes themselves or a hash of the key using any allowed hash algorithm) and prompts the user to accept or deny the key before continuing the connection. Test 2: The evaluator shall add an entry associating a host name with a public key into the TOE’s local database. The evaluator shall replace, on the corresponding SSH server, the server’s host key with a different host key. If 'password-based' is selected for the TOE in FCS_SSHC_EXT.1.2, the evaluator shall initiate a connection from the TOE to the SSH server using password-based authentication, shall ensure that the TOE rejects the connection, and shall ensure that the password was not transmitted to the SSH server (for example, by instrumenting the SSH server with a debugging capability to output received passwords). If 'password-based' is not selected for the TOE in FCS_SSHC_EXT.1.2, the evaluator shall initiate a connection from the TOE to the SSH server using public key-based authentication, and shall ensure that the TOE rejects the connection. Testing Assurance Activities Details/Results: Test 1: The TOE supports “strict hostkey checking”, which means the TOE rejects the connection to the remote SSH Server if the SSH server’s host key is removed from the known hosts list of the TOE. The evaluator verified through test case PP-13H that the TOE rejects the SSH connection with the server if all the entries in the known host are deleted. Test 2: The evaluator verified through test case PP-13H that replacing the host key on the server will fail the SSH handshake between the TOE and the remote server, if the replaced new key is not updated on the TOE known hosts list.

42 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.2.10 FCS_SSHS_EXT.1 SSH Server

2.2.10.1 FCS_SSHS_EXT.1.2

2.2.10.1.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication and that this list conforms to FCS_SSHS_EXT.1.5. and ensure that if password- based authentication methods have been selected in the ST then these are also described. TSS Assurance Activities Details/Results: The TOE provides SSH server capability for remote administration. The evaluator confirmed from the ST Section 7.2, the TOE supports both password based authentication and public key authentication for remote client access.

The evaluator checked the ST Section 7.2, and confirmed that the TSS states that rsa-sha2-256 is used as the public key algorithm for creating SSH hostkey and client key acceptance. This value conforms to FCS_SSHS_EXT.1.5, as provided in the ST Section 6.1.2.10.

2.2.10.1.2 Guidance Assurance Activities Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A

2.2.10.1.3 Testing Assurance Activities Testing Assurance Activities: Test 1: If password-based authentication methods have been selected in the ST then using the guidance documentation, the evaluator shall configure the TOE to accept password-based authentication, and demonstrate that user authentication succeeds when the correct password is provided by the user. Test 2: If password-based authentication methods have been selected in the ST then the evaluator shall use an SSH client, enter an incorrect password to attempt to authenticate to the TOE, and demonstrate that the authentication fails. Note: Public key authentication is tested as part of testing for FCS_SSHS_EXT.1.5. Testing Assurance Activities Details/Results: Test 1: The evaluator followed the CC guide, Section 3.11 Named User Accounts to configure the TOE to accept password-based authentication, and demonstrated that a user can be successfully authenticated to the TOE over SSH using a password as an authenticator. See test case PP-12A for details. Test 2: The evaluator configured the TOE to accept password-based authentication and demonstrated that entering invalid password failed the authentication. See test case PP-12A for details. Note: Public key authentication is tested as part of testing for FCS_SSHS_EXT.1.5.

2.2.10.2 FCS_SSHS_EXT.1.3

2.2.10.2.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check that the TSS describes how “large packets” in terms of RFC 4253 are detected and handled. TSS Assurance Activities Details/Results: The evaluator checked the ST Section 7.2 and confirmed that the TOE will reject the connection when large packets are detected during the SSH communication. The evaluator confirmed this behaviour through testing.

2.2.10.2.2 Guidance Assurance Activities

43 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Guidance Assurance Activities: None Guidance Assurance Activities Details/Results: N/A

2.2.10.2.3 Testing Assurance Activities Testing Assurance Activities: The evaluator shall demonstrate that if the TOE receives a packet larger than that specified in this component, that packet is dropped. Testing Assurance Activities Details/Results: The evaluator used a custom tool to send an artificially padded large SSH handshake packet, which is larger than the specified size of 256kb. The modified packet, client key exchange init, included a valid list of ciphers padded with a repeated ‘the-quick-brow’ garbage string until the packet was of the desired length. Using packet capture, an application layer rejection was observed. See test case PP-12B for details.

2.2.10.3 FCS_SSHS_EXT.1.4

2.2.10.3.1 TSS Assurance Activities TSS Assurance Activities: (1) The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the encryption algorithms supported are specified as well. (2) The evaluator shall check the TSS to ensure that the encryption algorithms specified are identical to those listed for this component. TSS Assurance Activities Details/Results: The evaluator checked the ST Section 7.2 and verified that (1) The TOE implements the SSHv2 protocol and supports the following encryption algorithms: aes128-cbc and aes256-cbc. (2) The encryption algorithms specified are identical to those listed for this SFR in Section 6.1.2.10.

2.2.10.3.2 Guidance Assurance Activities Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements). Guidance Assurance Activities Details/Results: The evaluator checked the CC Guide, Section 3.8, SSH Configuration, Page 9-10 and confirmed that it contains SSH configurations (like FPS, symmetric encryption cipher, key exchange, and message authentication and server host key algorithms) that conforms to the description in the TSS.

2.2.10.3.3 Testing Assurance Activities Testing Assurance Activities: (1) The evaluator must ensure that only claimed ciphers and cryptographic primitives are used to establish a SSH connection. To verify this, the evaluator shall start session establishment for a SSH connection from a remote client (referred to as ‘remote endpoint’ below). (2) The evaluator shall capture the traffic exchanged between the TOE and the remote endpoint during protocol negotiation (e.g. using a packet capture tool or information provided by the endpoint, respectively). (3) The evaluator shall verify from the captured traffic that the TOE offers all the ciphers defined in the TSS for the TOE for SSH sessions, but no additional ones compared to the definition in the TSS. (4) The evaluator shall perform one successful negotiation of an SSH session to verify that the TOE behaves as expected. It is sufficient to observe the successful negotiation of the session to satisfy the intent of the test.

If the evaluator detects that not all ciphers defined in the TSS for SSH are supported by the TOE and/or the TOE supports one or more additional ciphers not defined in the TSS for SSH, the test shall be regarded as failed. Testing Assurance Activities Details/Results:

44 of 86 Arista Networks Switches Running EOS Assurance Activity Report

(1) The TOE in the evaluated configuration supports aes128-cbc and aes256-cbc encryption algorithms as part of the SSH transport layer protocol. As part of test case PP-12C, the evaluator observed a successful SSHv2 handshake using each supported encryption algorithms. (2) The evaluator captured the SSH traffic between the TOE and Syslog server using Wireshark tool (3) The evaluator confirmed that only the TOE supported encryption algorithms were used for the handshake and no other additional algorithms were listed in the supported list during the handshake. (4) The evaluator confirmed through the test case PP-13C, the TOE successfully performed the SSH negotiation using the supported algorithms (aes128-cbc and aes256-cbc) and accepted the connection from the SSH client. Wireshark packet capture tool was used to analyze the protocol negotiation and session establishment, and to confirm that each of the expected encryption algorithm was used. The evaluator configured the SSH client to only offer 3des-cbc encryption during the handshake. The evaluator attempted to establish an SSH connection and observed that the connection was rejected by the TOE.

2.2.10.4 FCS_SSHS_EXT.1.5

2.2.10.4.1 TSS Assurance Activities TSS Assurance Activities: (1) The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the public key algorithms supported are specified as well. (2) The evaluator shall check the TSS to ensure that the public key algorithms specified are identical to those listed for this component. TSS Assurance Activities Details/Results: (1) The evaluator checked Section 7.2 of the ST, which states that the TOE implements rsa-sha2-256 for public key authentication that uses 2048-bit RSA key and SHA-256 digital signature. (2) The evaluator verified the TSS to ensure that the public key specified is identical to that listed for this SFR in Section 6.1.2.10 of the ST.

2.2.10.4.2 Guidance Assurance Activities Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements). Guidance Assurance Activities Details/Results: The evaluator checked the CC Guide, Section 3.8, SSH Configuration, Page 9 and confirmed that it contains SSH configurations (FIPS, symmetric encryption cipher, key exchange, and message authentication and server host key algorithms) that conform to the description in the TSS.

2.2.10.4.3 Testing Assurance Activities Testing Assurance Activities: Test 1: The evaluator shall establish a SSH connection using each of the public key algorithms specified by the requirement to authenticate the TOE to an SSH client. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. Test 2: The evaluator shall choose one public key algorithm supported by the TOE. The evaluator shall generate a new key pair for that algorithm without configuring the TOE to recognize the public key for authentication. The evaluator shall use an SSH client to attempt to connect to the TOE with the new key pair and demonstrate that authentication fails. Note: TD0412 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=412 was applied. Test 3: The evaluator shall configure an SSH client to only allow a public key algorithm that is not included in the ST selection. The evaluator shall attempt to establish an SSH connection from the SSH client to the TOE and observe that the connection is rejected. Testing Assurance Activities Details/Results: Test 1: The evaluator confirmed through the test case PP-12D, the TOE successfully performed the SSH negotiation using the key created using the supported algorithm (rsa-sha2-256) to accept the connection from the SSH client. Test 2: The evaluator verified through test case PP-12D that selecting a host key on the SSH client which was not

45 of 86 Arista Networks Switches Running EOS Assurance Activity Report

imported to the TOE known hosts list failed the SSH connection between the TOE and SSH client. when the evaluator initiated the SSH connection from the client, TOE rejected the connection due to unknown host key. Test 3: The evaluator verified through test case PP-12D that selecting a non-supported public key algorithm (ssh-rsa) for SSH connection failed to establish a connection between the TOE and the SSH Server.

2.2.10.5 FCS_SSHS_EXT.1.6

2.2.10.5.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check the TSS to ensure that it lists the supported data integrity algorithms, and that that list corresponds to the list in this component. TSS Assurance Activities Details/Results: The evaluator checked the ST Section 7.2 and ensures that the TOE implements SSHv2 protocol and supports the following data integrity algorithm: hmac-sha2-256. The list of supported data integrity algorithms corresponds to the list in this component in Section 6.1.2.10.

2.2.10.5.2 Guidance Assurance Activities Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed data integrity algorithms are used in SSH connections with the TOE (specifically, that the “none” MAC algorithm is not allowed). Guidance Assurance Activities Details/Results: The evaluator checked the CC Guide, Section 3.8, SSH Configuration, Page 9-10 and ensured that it contains instructions to the administrator on configuring only the allowed data integrity algorithm (hmac-sha2-256) to be used in the SSH connections with the TOE.

2.2.10.5.3 Testing Assurance Activities Testing Assurance Activities: Test 1: (conditional, if an HMAC or AEAD_AES_*_GCM algorithm is selected in the ST) The evaluator shall establish an SSH connection using each of the algorithms, except “implicit”, specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test. Note: To ensure the observed algorithm is used, the evaluator shall ensure a non-aes*[email protected] encryption algorithm is negotiated while performing this test. Test 2: (conditional, if an HMAC or AEAD_AES_*_GCM algorithm is selected in the ST) The evaluator shall configure an SSH client to only allow a MAC algorithm that is not included in the ST selection. The evaluator shall attempt to connect from the SSH client to the TOE and observe that the attempt fails. Note: To ensure the proposed MAC algorithm is used, the evaluator shall ensure a non-aes*[email protected] encryption algorithm is negotiated while performing this test. Testing Assurance Activities Details/Results: Test 1: The evaluator verified through test case PP-13E that the TOE establishes SSH connection using only the hmac-sha2-256 integrity algorithm as listed in the TSS section of the ST. Test 2: The evaluator verified through test case PP-13E that selecting a non-supported hashing algorithm (hmac-sha1) for SSH connection failed to establish a connection between the TOE and the SSH Client.

2.2.10.6 FCS_SSHS_EXT.1.7

2.2.10.6.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check the TSS to ensure that it lists the supported key exchange algorithms, and that that list corresponds to the list in this component. TSS Assurance Activities Details/Results:

46 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The evaluator checked ST Section 7.2 and ensures that the TSS contains the following information “TOE supports Diffie-hellman-group14-sha1 as its key exchange algorithm”. This corresponds to the algorithm provided in Section 6.1.2.10.

2.2.10.6.2 Guidance Assurance Activities Guidance Assurance Activities: The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed key exchange algorithms are used in SSH connections with the TOE. Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.8, SSH Configuration, Page 9-10 and confirmed that it contains instructions to the administrator to configure and verify the allowed key exchange algorithms (Diffie-hellman-group14- sha1) that are used in the SSH connections with the TOE.

2.2.10.6.3 Testing Assurance Activities Testing Assurance Activities: Test 1: The evaluator shall configure an SSH client to only allow the diffie-hellman-group1-sha1 key exchange. The evaluator shall attempt to connect from the SSH client to the TOE and observe that the attempt fails. Test 2: For each allowed key exchange method, the evaluator shall configure an SSH client to only allow that method for key exchange, attempt to connect from the client to the TOE, and observe that the attempt succeeds. Testing Assurance Activities Details/Results: Test 1: The evaluator configured the SSH client to only allow the diffie-hellman-group1-sha1 key exchange algorithm and verified through test case PP-12F that the TOE rejects SSH connection when the SSH client connects to the TOE due to invalid algorithm. Test 2: The evaluator verified through test case PP-12F that the TOE establishes SSH connection using only the Diffie-hellman-group14-sha1 key-exchange algorithms as listed in the TSS section of the ST.

2.2.10.7 FCS_SSHS_EXT.1.8

2.2.10.7.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check that the TSS specifies the following: a) Both thresholds are checked by the TOE. b) Rekeying is performed upon reaching the threshold that is hit first. TSS Assurance Activities Details/Results: The evaluator checked the ST Section 7.2 and confirmed that the TSS contains details that SSH connection is automatically rekeyed by default after 60 minutes or 1 GB of data, both of these thresholds are administrator- configurable.

2.2.10.7.2 Guidance Assurance Activities Guidance Assurance Activities: If one or more thresholds that are checked by the TOE to fulfil the SFR are configurable, then the evaluator shall check that the guidance documentation describes how to configure those thresholds. Either the allowed values are specified in the guidance documentation and must not exceed the limits specified in the SFR (one hour of session time, one gigabyte of transmitted traffic) or the TOE must not accept values beyond the limits specified in the SFR. The evaluator shall check that the guidance documentation describes that the TOE reacts to the first threshold reached. Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.8, SSH Configuration, Page 10 and confirmed that it contains instructions to the administrator to configure the rekeying frequency (1 GB) and rekeying interval (1 hour).

2.2.10.7.3 Testing Assurance Activities Testing Assurance Activities:

47 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The evaluator needs to perform testing that rekeying is performed according to the description in the TSS. The evaluator shall test both, the time-based threshold and the traffic-based threshold. For testing of the time-based threshold the evaluator shall use an SSH client to connect to the TOE and keep the session open until the threshold is reached. The evaluator shall verify that the SSH session has been active longer than the threshold value and shall verify that the TOE initiated a rekey (the method of verification shall be reported by the evaluator). Testing does not necessarily have to be performed with the threshold configured at the maximum allowed value of one hour of session time but the value used for testing shall not exceed one hour. The evaluator needs to ensure that the rekeying has been initiated by the TOE and not by the SSH client that is connected to the TOE. For testing of the traffic-based threshold the evaluator shall use an SSH client to connect to the TOE, and shall transmit data from and to the TOE within the active SSH session until the threshold for transmitted traffic is reached. The transmitted traffic is the total traffic comprising incoming and outgoing traffic. The evaluator shall verify that more data has been transmitted within the SSH session than the threshold allows and shall verify that the TOE initiated a rekey (the method of verification shall be reported by the evaluator). Testing does not necessarily have to be performed with the threshold configured at the maximum allowed value of one gigabyte of transferred traffic but the value used for testing shall not exceed one gigabyte. The evaluator needs to ensure that the rekeying has been initiated by the TOE and not by the SSH client that is connected to the TOE. If one or more thresholds that are checked by the TOE to fulfil the SFR are configurable, the evaluator needs to verify that the threshold(s) can be configured as described in the guidance documentation and the evaluator needs to test that modification of the thresholds is restricted to Security Administrators (as required by FMT_MOF.1/Functions). In cases where data transfer threshold could not be reached due to hardware limitations it is acceptable to omit testing of this (SSH rekeying based on data transfer threshold) threshold if both the following conditions are met: c) An argument is present in the TSS section describing this hardware-based limitation and d) All hardware components that are the basis of such argument are definitively identified in the ST. For example, if specific Ethernet Controller or WiFi radio chip is the root cause of such limitation, these chips must be identified. Testing Assurance Activities Details/Results: The TOE implements administrator-configurable SSH rekey based on time-base or traffic-based thresholds and this event is audited. As part of test case PP-12G, the evaluator configured the threshold to 5 minutes and 1MB of data. For the time-based threshold, the evaluator prevented the session from timing out while waiting for the rekey to happen. For traffic-based threshold, the evaluator repeatedly used the #show tech-support command. This CLI command displays a collection of data from other show commands and was used to exceed traffic-based threshold. In both the cases, the evaluator through the rekeying audit logs generated by the TOE for specific client (IP Address) confirmed that re-keying happens every 5 minutes and when the traffic threshold crossed 1MB of data.

2.2.11 FCS_TLSS_EXT.2 Extended: TLS Server Protocol with mutual authentication

2.2.11.1 FCS_TLSS_EXT.2.1

2.2.11.1.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified are identical to those listed for this component. TSS Assurance Activities Details/Results: The evaluator checked the ST Section 7.2 description and noted that the TSS describes the implementation of the TLS protocol and lists the following ciphersuites: ● TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 ● TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 ● TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246 ● TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 as the supported ciphersuites, which matches those listed for this component in Section 6.1.2.11.

48 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.2.11.1.2 Guidance Assurance Activities Guidance Assurance Activities: The evaluator shall check the guidance documentation to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS (for instance, the set of ciphersuites advertised by the TOE may have to be restricted to meet the requirements). Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.12, TLS Server, Page 16-20 and confirmed that it contains instructions to the administrator to configure the TLS Server that conforms to the description in the TSS (like CSR creation, accepted ciphersuites, accepted TLS versions etc.).

2.2.11.1.3 Testing Assurance Activities Testing Assurance Activities: Test 1: The evaluator shall establish a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of an HTTPS session. It is sufficient to observe the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES). Test 2: The evaluator shall send a Client Hello to the server with a list of ciphersuites that does not contain any of the ciphersuites in the server’s ST and verify that the server denies the connection. Additionally, the evaluator shall send a Client Hello to the server containing only the TLS_NULL_WITH_NULL_NULL ciphersuite and verify that the server denies the connection. Test 3: The evaluator shall use a client to send a key exchange message in the TLS connection that does not match the server-selected ciphersuite (for example, send an ECDHE key exchange while using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite or send a RSA key exchange while using one of the ECDSA ciphersuites.) The evaluator shall verify that the TOE disconnects after receiving the Key Exchange message. Test 4: The evaluator shall perform the following modifications to the traffic: a) withdrawn b) withdrawn c) Modify a byte in the Client Finished handshake message, and verify that the server rejects the connection and does not send any application data. d) After generating a fatal alert by sending a Finished message from the client before the client sends a ChangeCipherSpec message, send a Client Hello with the session identifier from the previous test, and verify that the server denies the connection. e) (Test Intent: The intent of this test is to ensure that the server's TLS implementation immediately makes use of the key exchange and authentication algorithms to: a) Correctly encrypt (D)TLS Finished message and b) Encrypt every (D)TLS message after session keys are negotiated.) The evaluator shall use one of the claimed ciphersuites to complete a successful handshake and observe transmission of properly encrypted application data. The evaluator shall verify that no Alert with alert level Fatal (2) messages were sent. The evaluator shall verify that the Finished message (Content type hexadecimal 16 and handshake message type hexadecimal 14) is sent immediately after the server's ChangeCipherSpec (Content type hexadecimal 14) message. The evaluator shall examine the Finished message (encrypted example in hexadecimal of a TLS record containing a Finished message, 16 03 03 00 40 11 22 33 44 55...) and confirm that it does not contain unencrypted data (unencrypted example in hexadecimal of a TLS record containing a Finished message, 16 03 03 00 40 14 00 00 0c...), by verifying that the first byte of the encrypted Finished message does not equal hexadecimal 14 for at least one of three test messages. There is a chance that an encrypted Finished message contains a hexadecimal value of '14' at the position where a plaintext Finished message would contain the message type code '14'. If the observed Finished message contains a hexadecimal value of '14' at the position where the plaintext Finished message would contain the message type code, the test shall be repeated three times in total. In case the value of '14' can be observed in all three tests it can be assumed that the Finished message has indeed been sent in plaintext and the test has to be regarded as 'failed'. Otherwise it has to be assumed that the observation of the value '14' has been due to chance and that the Finished message has indeed been sent encrypted. In that latter case the test shall be regarded as 'passed'.

49 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Testing Assurance Activities Details/Results: Test 1: The TOE implements trusted channel with an eAPI Client host using v1.2. In this configuration, the TOE acts as a TLS server. The following TLS ciphers are supported in the evaluated configuration:  TLS_RSA_WITH_AES_128_CBC_SHA256  TLS_RSA_WITH_AES_256_CBC_ SHA256  TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256  TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 In test case PP-15A, the evaluator established a TLS connection using each of the ciphersuites specified by the above requirement as given in the ST. A custom test tool was used to force negotiation of each supported ciphersuite. Packet capture was then used to observe the handshake and to confirm that the selected ciphersuite was successfully negotiated between the TOE and the custom tool. Test 2: As part of test case PP-15A, the evaluator configured the custom tool to send Client Hello to the TOE TLS server with a list of ciphersuites that does not contain any of the cipher suites in the server’s ST and verified that the server denied the connection. Additionally, the evaluator sent a Client Hello to the server using the custom tool containing only the TLS_NULL_WITH_NULL_NULL cipher suite and verified that the server denies the connection. Test 3: As part of the test case PP-15A, the evaluator configured the custom tool to send Client Hello to the TOE TLS server with a list of unsupported ciphersuites of the server (given below)  TLS_RSA_WITH_RC4_128_MD5  TLS_RSA_WITH_NULL_SHA256  TLS_DHE_DSS_WITH_AES_128_GCM_SHA256  TLS_NULL_WITH_NULL_NULL and verified that the server disconnected the connection after receiving the key exchange message. Test 4: The evaluator used a custom test tool to send modified traffic as specified in the assurance activities. For the following tests, the test tool is acting as a TLS client and the TOE is acting as a server. c) In test case PP-15B, the evaluator configured the custom tool to modify a byte in the Client Finished handshake message, and verified that the server rejected the connection and did not send any application data. d) In test case PP-15C, the evaluator configured the custom tool to send FINISH message instead of CHANGE_CIPHER_SPEC and then tried to resume the previous session and verified that the TOE rejected the connection from the client. e) In test case PP-15D, the evaluator sent the client Hello handshake message that contained ciphersuite specified in the ST. The evaluator observed that the TLS handshake was successful between the TOE and the Client tool. In test case PP-15D, the evaluator examine the Finished message captured using the packet capture and confirmed that it did not contain unencrypted data by verifying that the first byte of the encrypted Finished message did not equal hexadecimal 14.

2.2.11.2 FCS_TLSS_EXT.2.2

2.2.11.2.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall verify that the TSS contains a description of the denial of old SSL and TLS versions. TSS Assurance Activities Details/Results: The ST Section 7.2 mentions TLS v1.2 protects the communication channel with mutual authentication. Any attempts to establish a session using any other TLS or SSL versions (SSL 1.0, SSL, 2.0, SSL 3.0, TLS 1.0 and TLS 1.1) is denied by the TOE.

2.2.11.2.2 Guidance Assurance Activities

50 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Guidance Assurance Activities: The evaluator shall verify that any configuration necessary to meet the requirement must be contained in the AGD guidance. Guidance Assurance Activities Details/Results: The evaluator verified that the CC Guide, Section 3.12, TLS Server, Page 17 contains instructions to the administrator to configure necessary parameters like FIPS compliant ciphersuites (allowed TLS versions 1.2) to meet the configuration necessary to meet the requirements between the TOE and the authorized IT entities.

2.2.11.2.3 Testing Assurance Activities Testing Assurance Activities: The evaluator shall send a Client Hello requesting a connection for all mandatory and selected protocol versions in the SFR (e.g. by enumeration of protocol versions in a test client) and verify that the server denies the connection for each attempt. Testing Assurance Activities Details/Results: As part of test case PP-15E, the evaluator chose the options for deprecated SSL version (SSL 1.0, SSL, 2.0, SSL 3.0, TLS 1.0 and TLS 1.1) in the custom tool and verified that the TOE rejected the connection when the evaluator tried to establish connection between the tool and TOE TLS server, handshake failed due to the deprecated SSL/TLS version.

2.2.11.3 FCS_TLSS_EXT.2.3

2.2.11.3.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall verify that the TSS describes the key agreement parameters of the server Key Exchange message. TSS Assurance Activities Details/Results: The evaluator verified that the ST Section 7.2 states that the TOE uses RSA key establishment with key size 2048 bits and DHE key establishment with key size 2048 bits. The evaluator also verified that the ciphersuites specified match those listed for this component in Section 6.1.2.11.

2.2.11.3.2 Guidance Assurance Activities Guidance Assurance Activities: The evaluator shall verify that any configuration necessary to meet the requirement must be contained in the AGD guidance. Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.12, TLS Server, Page 16 - 20 and confirmed that it contains instructions to the administrator to configure necessary parameters like FIPS compliant ciphersuites (allowed cipher-list AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES-256-SHA256) to meet the requirement of the TOE for the TLS mutual authentication between the TOE and the authorized IT entities.

2.2.11.3.3 Testing Assurance Activities Testing Assurance Activities: The evaluator shall attempt a connection using an ECDHE ciphersuite and a configured curve. Using a packet analyser, verify that the key agreement parameters in the Key Exchange message are the ones configured. (Determining that the size matches the expected size for the configured curve is sufficient.) The evaluator shall repeat this test for each supported NIST Elliptic Curve and each supported Diffie-Hellman key size. The evaluator shall attempt establishing connection using each claimed key establishment protocol (RSA, DH, ECDHE) with each claimed parameter (RSA key size, Diffie-Hellman parameters, supported curves) as selected in FCS_TLSS_EXT.2.3. For example, determining that the RSA key size matches the claimed size is sufficient to satisfy this test. The evaluator shall ensure that each supported parameter combination is tested. Note that this testing can be accomplished in conjunction with the other testing activities

Testing Assurance Activities Details/Results:

51 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The evaluator configured the custom tool and attempted the connection using each claimed key establishment protocols (RSA, Diffie-Hellman) with each claimed parameter (key size 2048, Diffie-Hellman-Group14-Sha1) as selected in FCS_TLSS_EXT.2.3 and confirmed the successful connection between the TOE and the custom tool. Please refer to test case PP-15A for more details.

2.2.11.4 FCS_TLSS_EXT.2.4 and FCS_TLSS_EXT.2.5

2.2.11.4.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall ensure that the TSS description required per FIA_X509_EXT.2.1 includes the use of client-side certificates for TLS mutual authentication. TSS Assurance Activities Details/Results: The ST Section 7.2 mentions that the TOE supports client-side certificate validation for TLS mutual authentication during the eAPI TLS client connection.

2.2.11.4.2 Guidance Assurance Activities Guidance Assurance Activities: If the TSS indicates that mutual authentication using X.509v3 certificates is used, the evaluator shall verify that the AGD guidance includes instructions for configuring the client-side certificates for TLS mutual authentication. Guidance Assurance Activities Details/Results: The evaluator verified that the CC Guide, Section 3.14, eAPI Client Operation, Pages 21-22 contains instructions for configuring the client-side certificates for TLS mutual authentication between the TOE and the remote TLS administrator client.

2.2.11.4.3 Testing Assurance Activities Testing Assurance Activities: Test 1: The evaluator shall configure the server to send a certificate request to the client and shall attempt a connection without sending a certificate from the client. The evaluator shall verify that the connection is denied. Test 2[conditional]: If TLS1.2 is claimed for the TOE, the evaluator shall configure the server to send a certificate request to the client without the supported_signature_algorithm used by the client's certificate. The evaluator shall attempt a connection using the client certificate and verify that the connection is denied." Note: TD0395 https://www.niap-ccevs.org/Documents_and_Guidance/view_td.cfm?td_id=405 was applied. Test 3 [conditional]: If the TOE supports sending a non-empty Certificate Authorities list in its Certificate Request message, the evaluator shall configure the client to send a certificate that does not chain to one of the Certificate Authorities (either a Root or Intermediate CA) in the server’s Certificate Request message. The evaluator shall verify that the attempted connection is denied. If the TOE doesn't support sending a non-empty Certificate Authorities list in its Certificate Request message, this test shall be omitted. Test 4: The aim of this test is to check the response of the server when it receives a client identity certificate that is signed by an impostor CA (either Root CA or intermediate CA). To carry out this test the evaluator shall configure the client to send a client identity certificate with an issuer field that identifies a CA recognised by the TOE as a trusted CA, but where the key used for the signature on the client certificate does not in fact correspond to the CA certificate trusted by the TOE (meaning that the client certificate is invalid because its certification path does not in fact terminate in the claimed CA certificate). The evaluator shall verify that the attempted connection is denied.

Testing Assurance Activities Details/Results: Test 1: As part of test case PP-15G, the evaluator chose the option “Never send certificate in response to Certificate request” on the custom TLS tool and attempted a connection to the TOE server. The Evaluator verified that the TOE TLS server without the client authentication certificate denies the connection. Test 2[conditional]: The TOE claims TLS v1.2 as per the ST, so as part of the test case PP-15G, the evaluator configured the TLS custom tool with the option “client sends certificate with unsupported signature algorithm” and attempted a connection to the TOE server. The evaluator verified that the TOE TLS server denied the connection sent with the client certificate with unsupported signature algorithm.

52 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Test 3[conditional]: The TOE claims mutual authentication for TLS connection as per the ST, so as part of the test case 9A, the evaluator configured the TOE with trusted CA certificates to send the CA certificate list in the certificate request message. The evaluator observed the failure of handshake and connection rejected by the TOE when the client sends the client certificate not signed by any of the CA in the TOE’s trusted list. Test 4: As part of the test case PP-15G, the evaluator created a new intermediate CA certificate signed by the root CA, whose subject DN is same as the intermediate CA certificate that is imported and trusted on the TOE. The evaluator then created a new eAPI Client certificate signed by the new intermediate CA. The evaluator initiated a TLS connection from the custom TLS tool to the TOE server, by selecting the option “client sends certificate with untrusted CA”. The evaluator observed that the TOE rejected the client certificate with an “unknown CA” error and denied the TLS connection request.

2.2.11.5 FCS_TLSS_EXT.2.6

2.2.11.5.1 TSS Assurance Activities TSS Assurance Activities: The evaluator shall verify that the TSS describes how the DN or SAN in the certificate is compared to the expected identifier. TSS Assurance Activities Details/Results: The ST Section 7.2 states that the TOE checks to see if the Common Name of the client certificate matches with the username of the account configured for the eAPI client. If no match is found, the TOE will terminate the attempted session establishment. If a match is found, TOE allows the authentication process to complete and the session to successfully establish. The TOE does not process the SAN value in the client certificate.

The evaluator verified that the information specified matches what is stated in the SFR in Section 6.1.2.11.

2.2.11.5.2 Guidance Assurance Activities Guidance Assurance Activities: If the DN is not compared automatically to the Domain Name or IP address, username, or email address, then the evaluator shall ensure that the AGD guidance includes configuration of the expected DN or the directory server for the connection. Guidance Assurance Activities Details/Results: The evaluator verified that the CC Guide, Section 3.13, eAPI Server Configuration, Page 21 contains instructions for configuring the client-side certificates. For the TLS authentication to be successful, the TOE requires the common name of the client certificate to match with one of the user accounts already created on the TOE with the proper role (Network Operator role).

2.2.11.5.3 Testing Assurance Activities Testing Assurance Activities: The evaluator shall send a client certificate with an identifier that does not match an expected identifier and verify that the server denies the connection. Testing Assurance Activities Details/Results: As part of the test case PP-15H, the evaluator created a client certificate with a common name not matching the username created for the TLS connection on the TOE. The evaluator verified that the certificate with no matching common name as one of the usernames of the TOE is denied connection to the TOE server.

53 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.3 Identification and Authentication (FIA)

2.3.1 FIA_AFL.1 Authentication Failure Management

2.3.1.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall examine the TSS to determine that it contains a description, for each supported method for remote administrative actions, of how successive unsuccessful authentication attempts are detected and tracked. (2) The TSS shall also describe the method by which the remote administrator is prevented from successfully logging on to the TOE, and the actions necessary to restore this ability. (3) The evaluator shall examine the TSS to confirm that the TOE ensures that authentication failures by remote administrators cannot lead to a situation where no administrator access is available, either permanently or temporarily (e.g. by providing local logon which is not subject to blocking). TSS Implementation Details/Results: (1) The evaluator verified that the ST Section 7.3 states “The RS-232/VT-100 local administrative interface is never locked out”. Consecutive authentication failures result into temporary account lockout for remote administrative user. (2) The ST Section 7.3 states that the Security Administrator when initializing the TOE configures the threshold number of failures between 1 and 255 and subsequent lockout period. (3) The evaluator verified in the ST Section 7.3 that the TOE ensures that authentication failures by remote administration cannot lead to a situation where no administrator access is available. The local administrative account is never locked out.

2.3.1.2 Guidance Assurance Activities

Guidance Assurance Activities: (1) The evaluator shall examine the guidance documentation to confirm that it describes, and identifies the importance of, any actions that are required in order to ensure that administrator access will always be maintained, even if remote administration is made permanently or temporarily unavailable due to blocking of accounts as a result of FIA_AFL.1. (2) The evaluator shall examine the guidance documentation to ensure that instructions for configuring the number of successive unsuccessful authentication attempts and time period (if implemented) are provided, and that the process of allowing the remote administrator to once again successfully log on is described for each “action” specified (if that option is chosen). If different actions or mechanisms are implemented depending on the secure protocol employed (e.g., TLS vs. SSH), all must be described.

Guidance Implementation Details/Results: (1) The evaluator examined the CC Guide, Section 3.11, Named User Accounts Page 13 and confirmed that the guide contains instructions to disable lockout policy for remote administrator. The guide also confirms that the local administrative access is never locked out. (2) The evaluator examined the CC Guide, Section 3.11, Named User Accounts Page 13 and confirmed that the guide contains instructions for configuring the authentication policy to lockout remote administrator accounts (SSH) after certain number of successive unsuccessful authentication attempts and for a certain time period. The instruction provides direction that after the lockout time period, the administrator can login to the device successfully.

54 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.3.1.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall perform the following tests for each method by which remote administrators access the TOE (e.g. any passwords entered as part of establishing the connection protocol or the remote administrator application): Test 1: The evaluator shall use the operational guidance to configure the number of successive unsuccessful authentication attempts allowed by the TOE (and, if the time period selection in FIA_AFL.1.2 is included in the ST, then the evaluator shall also use the operational guidance to configure the time period after which access is re-enabled). The evaluator shall test that once the authentication attempts limit is reached, authentication attempts with valid credentials are no longer successful. Test 2: After reaching the limit for unsuccessful authentication attempts as in Test 1 above, the evaluator shall proceed as follows. If the administrator action selection in FIA_AFL.1.2 is included in the ST then the evaluator shall confirm by testing that following the operational guidance and performing each action specified in the ST to re-enable the remote administrator’s access results in successful access (when using valid credentials for that administrator). If the time period selection in FIA_AFL.1.2 is included in the ST then the evaluator shall wait for just less than the time period configured in Test 1 and show that an authorisation attempt using valid credentials does not result in successful access. The evaluator shall then wait until just after the time period configured in Test 1 and show that an authorisation attempt using valid credentials results in successful access.

Testing Implementation Details/Results: Test 1: As part of the test case PP-14, the evaluator, using the CC guide Section 3.11 Named User Accounts Page 13, configured the authentication policy lockout invalid login attempts to 3 times, lockout period of 15 minutes after three consecutive invalid login attempts in 5 minute window and verified that the remote administrator (via SSH) was not able to login using the valid credentials in the 15 minutes lockout time. Test 2: As part of the test case PP-14, the evaluator confirmed that the after the defined number of unsuccessful authentication attempts, the administrator was not able to login using the valid credentials in the 15 minutes lockout time through SSH client. Once the time elapsed, the administrator was able to login to the TOE successfully without any administrator intervention as defined in the ST. As part of the test case PP-14, the evaluator confirmed that the evaluator could not able to authenticate to the TOE when tried to login just less than the time period configured in Test 1 and confirmed that the authorization attempt using a valid credential does not result in successful access.

2.3.2 FIA_PMG_EXT.1 Password Management

2.3.2.1 TSS Assurance Activities

TSS Assurance Activities: None TSS Implementation Details/Results: N/A

2.3.2.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall examine the guidance documentation to determine that it: a) identifies the characters that may be used in passwords and provides guidance to security administrators on the composition of strong passwords, and b) provides instructions on setting the minimum password length and describes the valid minimum password lengths supported. Guidance Implementation Details/Results:

55 of 86 Arista Networks Switches Running EOS Assurance Activity Report

a) The evaluator examined the CC Guide, Section 3.2 Hostname, DNS Server, Time Setting, Login Banner and Password Restrictions Page 6 and verified that it contains instructions on the acceptable characters and symbols for the passwords. b) The evaluator examined the CC Guide, Section 3.2, Hostname, Time Setting, Login Banner and Password Restrictions, Page 6 and verified that instructions are given in the guide for setting minimum password length.

2.3.2.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall perform the following tests. Test 1: The evaluator shall compose passwords that either meet the requirements, or fail to meet the requirements, in some way. For each password, the evaluator shall verify that the TOE supports the password. While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all characters, and a minimum length listed in the requirement are supported, and justify the subset of those characters chosen for testing. Testing Implementation Details/Results: Test 1: The TOE supports both password-based authentication and public-key based authentication. As part of the test case PP-3, the evaluator tested all of the password attributes required by the PP, including negative tests. The evaluator tested the following rules for the password based authentication:  Passwords composed of any combination of upper and lower case letters, numbers, and the following special characters: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”;  Minimum password length of 8 characters

The evaluator set the minimum password length to 8 characters and observed that the set value took effect. As part of the negative testing, the evaluator tested the minimum length password policy by providing a shorter password during user creation and noted that an error message stating that a minimum of 8 characters were required for passwords was produced. Password length greater than 8 characters and password length equal to 8 characters were also tested in the positive tests.

2.3.3 FIA_UIA_EXT.1 User Identification and Authentication

2.3.3.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall examine the TSS to determine that it describes the logon process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the product. This description shall contain information pertaining to the credentials allowed/used, any protocol transactions that take place, and what constitutes a “successful logon”. (2) The evaluator shall examine the TSS to determine that it describes which actions are allowed before user identification and authentication. The description shall cover authentication and identification for local and remote TOE administration. TSS Implementation Details/Results: The evaluator checked and confirmed that: (1) The ST, Section 7.3, describes that the CLI is accessed over the serial console port for local logon. Local management supports password-based authentication. The ST, Section 7.3 describes that for remote administration, implemented as a CLI over SSH, the TOE supports both password based and public key based authentication. For local administration, only password-based authentication is supported. For remote administrative access, both password and RSA public key authentication is used. The TOE performs the initial authentication verification locally by comparing the public key supplied by the client with the local keys file. Once the public key matches, the TOE performs the authorization against the Role Based Access Control (RBAC) module. Depending on the outcome of the RBAC module check, the remote administrator is granted or denied access to the CLI interface. (2) The ST, Section 7.3 details that a username and password are required to logon to the TOE locally, and password or public key authentication for remote access. Once the username and passwords have been validated by the system then authorization to the CLI interface is decided based on the outcome of the RBAC module. If an incorrect username and passwords are entered then access is denied. Logging into the TOE with the correct

56 of 86 Arista Networks Switches Running EOS Assurance Activity Report

credentials constitutes a successful logon. For RSA authentication, the TOE validates the presented public key against authorized keys file and verifies possession of a private key by negotiating secure channel using this public key.

2.3.3.2 Guidance Assurance Activities

Guidance Assurance Activities: (1) The evaluator shall examine the guidance documentation to determine that any necessary preparatory steps (e.g., establishing credential material such as pre- shared keys, tunnels, certificates, etc.) to logging in are described. (2) For each supported the login method, the evaluator shall ensure the guidance documentation provides clear instructions for successfully logging on. (3) If configuration is necessary to ensure the services provided before login are limited, the evaluator shall determine that the guidance documentation provides sufficient instruction on limiting the allowed services. Guidance Implementation Details/Results: (1) The evaluator examined the CC Guide, Section 3.4 Default Account Protection page 7, and confirmed that it contains adequate instructions for local administrator login to the switch. Section 3.12 TLS Server, Page 16 covers necessary preparatory steps (generating certificate signing request (CSR) on the TOE, installing trusted CA certificates, installing TLS server certificate, CRL file to the TOE) for the successful logging of the remote administrator(s) to the TOE using the public key authentication. (2) The TOE supports two types of login method, password authentication and public key authentication. The evaluator examined the CC Guide, Section 3.4 Default Account Protection Page 7 and Section 3.12 TLS Server Page 16, and confirmed that those sections provide clear instructions for successful logging on to the TOE. (3) The evaluator examined the CC Guide, Section 3.5 Disallowed Access Methods (SNMP, Telnet, API) and confirmed that it contains instructions to ensure that the guide contains instructions on limiting the allowed services.

2.3.3.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall perform the following tests for each method by which administrators access the TOE (local and remote), as well as for each type of credential supported by the login method: Test 1: The evaluator shall use the guidance documentation to configure the appropriate credential supported for the login method. For that credential/login method, the evaluator shall show that providing correct I&A information results in the ability to access the system, while providing incorrect information results in denial of access. Test 2: The evaluator shall configure the services allowed (if any) according to the guidance documentation, and then determine the services available to an external remote entity. The evaluator shall determine that the list of services available is limited to those specified in the requirement. Test 3: For local access, the evaluator shall determine what services are available to a local administrator prior to logging in, and make sure this list is consistent with the requirement. Testing Implementation Details/Results: Test 1: The evaluator followed the user guidance and used a valid username and password to successfully login to the TOE. The evaluator used an invalid username and password and observed that access to the TOE was denied. This was carried out for both local (Console CLI) and remote access (CLI via SSH). See PP-7 for valid local access, PEN-3 for invalid local access, and PP-12A for valid and invalid remote access. Test 2: The evaluator observed that for both local (Console CLI) and remote access (CLI via SSH) that the list of services available is limited to those specified in the requirement. Test 3: The evaluator observed that for local access the login prompt is displayed after establishing a connection, with no other services permitted. Successful login was indicated by a command line prompt, while a failed login returned the operator to the user name login prompt. Thus there are no actions permitted to the user without prior successful identification and authentication to the TOE. See PEN-3 for invalid local access.

57 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.3.4 FIA_UAU_EXT.2 Password-based Authentication Mechanism

Evaluation Activities for this requirement are covered under those for FIA_UIA_EXT.1. If other authentication mechanisms are specified, the evaluator shall include those methods in the activities for FIA_UIA_EXT.1.

2.3.5 FIA_UAU.7 Protected Authentication Feedback

2.3.5.1 TSS Assurance Activities

TSS Assurance Activities: None TSS Implementation Details/Results: N/A

2.3.5.2 Guidance Assurance Activities

Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A

2.3.5.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall perform the following test for each method of local login allowed: Test 1: The evaluator shall locally authenticate to the TOE. While making this attempt, the evaluator shall verify that at most obscured feedback is provided while entering the authentication information. Testing Implementation Details/Results: Test 1: The evaluator authenticated locally to the TOE and observed that the password was obscured during entering of authentication information. This behaviour was observed for console login to the TOE using the test case PP-12A.

2.3.6 FIA_X509_EXT.1/Rev X.509 Certificate Validation

2.3.6.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place, and that the TSS identifies any of the rules for extendedKeyUsage fields (in FIA_X509_EXT.1.1) that are not supported by the TOE (i.e. where the ST is therefore claiming that they are trivially satisfied). It is expected that revocation checking is performed when a certificate is used in an authentication step and when performing trusted updates (if selected). It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the option for using X.509 certificates for self-testing is selected). (2) The TSS shall describe when revocation checking is performed and on what certificates. If the revocation checking during authentication is handled differently depending on whether a full certificate chain or only a leaf certificate is being presented, any differences must be summarized in the TSS section and explained in the Guidance. It is expected that revocation checking is performed when a certificate is used in an authentication step. It is expected that revocation checking is performed on both leaf and intermediate CA certificates when a leaf certificate is presented to the TOE as part of the certificate chain during authentication. Revocation checking of any CA certificate designated a trust anchor is not required. It is not sufficient to perform a revocation check of a CA certificate only when it is loaded onto the device.

TSS Implementation Details/Results: The evaluator checked and confirmed that:

(1) The ST Section 7.3 describes that the TOE supports the use of X.509v3 digital certificates as defined by RFC 5280 to authenticate connections with authorize IT entities. The TSS describes in general terms the process of

58 of 86 Arista Networks Switches Running EOS Assurance Activity Report

certificate validation and extension checking, explicitly mentioning validating extendedKeyUsage field and checking BasicConstraints extension. This description also includes acceptable values for extendedKeyUsage: serverAuthentication for IT Servers, clientAuthentication for Clients.

(2) The ST Section 7.3, describes the supported certificate path validation algorithms as: cRL Distribution Points (CDP). The TSS explains that revocation checking performed on identity certificates presented to the TOE and all CA certificates in the chain up to the trust anchor (excluding). The TSS also mentions that when loading signed CSR to the TOE, the revocation checking is performed.

(3) The ST Section 7.3 mentions that the TOE constructs the trust chain based on CA certificates in its trust store and as a result performs complete revocation chain regardless whether full chain or just leaf certificate is presented up to the trust anchor (either a root CA certificate or an intermediate CA certificate).

2.3.6.2 Guidance Assurance Activities

Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A

2.3.6.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall demonstrate that checking the validity of a certificate is performed when a certificate is used in an authentication step or when performing trusted updates (if FPT_TUD_EXT.2 is selected). It is not sufficient to verify the status of a X.509 certificate only when it is loaded onto the TOE. It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the option for using X.509 certificates for self-testing is selected). The evaluator shall perform the following tests for FIA_X509_EXT.1.1/Rev. These tests must be repeated for each distinct security function that utilizes X.509v3 certificates. For example, if the TOE implements certificate-based authentication with IPSEC and TLS, then it shall be tested with each of these protocols: Test 1a: The evaluator shall present the TOE with a valid chain of certificates (terminating in a trusted CA certificate) as needed to validate the leaf certificate to be used in the function, and shall use this chain to demonstrate that the function succeeds. Test 1a shall be designed in a way that the chain can be 'broken' in Test 1b by either being able to remove the trust anchor from the TOEs trust store, or by setting up the trust store in a way that at least one intermediate CA certificate needs to be provided, together with the leaf certificate from outside the TOE, to complete the chain (e.g. by storing only the root CA certificate in the trust store). Test 1b: The evaluator shall then 'break' the chain used in Test 1a by either removing the trust anchor in the TOE's trust store used to terminate the chain, or by removing one of the intermediate CA certificates (provided together with the leaf certificate in Test 1a) to complete the chain. The evaluator shall show that an attempt to validate this broken chain fails. Test 2: The evaluator shall demonstrate that validating an expired certificate results in the function failing. Test 3: The evaluator shall test that the TOE can properly handle revoked certificates-–conditional on whether CRL or OCSP is selected; if both are selected, then a test shall be performed for each method. The evaluator shall test revocation of the peer certificate and revocation of the peer intermediate CA certificate i.e. the intermediate CA certificate should be revoked by the root CA. The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails. Revocation checking is only applied to certificates that are not designated as trust anchors. Therefore the revoked certificate(s) used for testing shall not be a trust anchor. Test 4: If OCSP is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If CRL is selected, the evaluator shall configure the CA to sign a CRL with a certificate that does not have the cRLsign key usage bit set, and verify that validation of the CRL fails. Test 5: The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate. (The certificate will fail to parse correctly.) Test 6: The evaluator shall modify any byte in the last byte of the certificate and demonstrate that the certificate fails to validate. (The signature on the certificate will not validate.)

59 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Test 7: The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate. (The hash of the certificate will not validate.)

The evaluator shall perform the following tests for FIA_X509_EXT.1.2/Rev. The tests described must be performed in conjunction with the other certificate services assurance activities, including the functions in FIA_X509_EXT.2.1/Rev. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. Where the TSS identifies any of the rules for extendedKeyUsage fields (in FIA_X509_EXT.1.1) that are not supported by the TOE (i.e. where the ST is therefore claiming that they are trivially satisfied) then the associated extendedKeyUsage rule testing may be omitted. The goal of the following tests is to verify that the TOE accepts a certificate as a CA certificate only if it has been marked as a CA certificate by using basicConstraints with the CA flag set to True (and implicitly tests that the TOE correctly parses the basicConstraints extension as part of X509v3 certificate chain validation). For each of the following tests the evaluator shall create a chain of at least three certificates: a self-signed root CA certificate, an intermediate CA certificate and a leaf (node) certificate. The properties of the certificates in the chain are adjusted as described in each individual test below (and this modification shall be the only invalid aspect of the relevant certificate chain). Test 1: The evaluator shall ensure that at least one of the CAs in the chain does not contain the basicConstraints extension. The evaluator confirms that the TOE rejects such a certificate at one (or both) of the following points: (i) as part of the validation of the leaf certificate belonging to this chain; (ii) when attempting to add a CA certificate without the basicConstraints extension to the TOE’s trust store (i.e. when attempting to install the CA certificate as one which will be retrieved from the TOE itself when validating future certificate chains). Test 2: The evaluator shall ensure that at least one of the CA certificates in the chain has a basicConstraints extension in which the CA flag is set to FALSE. The evaluator confirms that the TOE rejects such a certificate at one (or both) of the following points: (i) as part of the validation of the leaf certificate belonging to this chain; (ii) when attempting to add a CA certificate with the CA flag set to FALSE to the TOE’s trust store (i.e. when attempting to install the CA certificate as one which will be retrieved from the TOE itself when validating future certificate chains). The evaluator shall repeat these tests for each distinct use of certificates. Thus, for example, use of certificates for TLS connection is distinct from use of certificates for trusted updates so both of these uses would be tested. But there is no need to repeat the tests for each separate TLS channel in FTP_ITC.1 and FTP_TRP.1/Admin (unless the channels use separate implementations of TLS).

Testing Implementation Details/Results: For the following test cases, two-tier hierarchical CA structure and a single-tier CA were used:  Root CA  Intermediate CA1  end entity certificate for positive testing  Untrusted CA  end entity certificate for negative testing The TOE supports only cRL Distribution Point (CDP) for certificate revocation checking. IIS (Internet Information Service – Web Server) server was installed to provide http URI service for the TOE to download the CRLs of all the CAs in a regular interval. A custom script was installed on the TOE for the scheduled CRL download from the IIS server. For positive testing 2 CA certificates (RootCA  IntCA1) were added to the TOE’s trusted certificate store. The evaluator created an SSL profile on the TOE (as per the CC guide Section 3.12 TLS Server) and assigned the CA certificates to the profile to form the successful chain from the TOE certificate to the Root Certificate.

FIA_X509_EXT.1.1/Rev: Test 1a: As part of PP-9A, the evaluator confirmed that the RootCAIntCA1 certificate chain was loaded into the TOE’s certificate store. The evaluator then used TLS handshake to present a valid 2048-bit RSA X509v3 leaf certificate signed by IntCA1 and observed that the handshake succeeded. Test 1b: The evaluator then removed the IntCA1 from the trust store and observed that the validation of the TOE certificate failed due to the absence of the IntCA1 certificate. Test 2: As part of PP-9B, the evaluator used a valid but short-lived (1 day) 2048-bit RSA X509v3 client certificate signed by IntCA1 during the eAPI client connection to the TOE server. The evaluator then used the expired certificate and attempted to re-establish connection, which resulted in the TLS handshake failing and the TOE producing “TLS connection failed – unable to establish connection: certificate expired” message.

60 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Test 3: The TOE implements CRL to perform revocation checking. As part of PP-9C, the evaluator used TLS handshake to present a structurally valid 2048-bit RSA X509v3 leaf certificate signed by IntCA1 that was revoked and observed that the handshake failed. The evaluator repeated this test by revoking IntCA1 and observer that the handshake failed. Test 4: The TOE implements CRL to perform revocation checking. As part of PP-9D, the evaluator created a new IntCA1 certificate signed by the rootCA that did not have cRL sign bit in the Key Usage of the IntCA1 certifacate and verified that the TOE ssl profile became invalid due to the wrong CA certificate added to the trusted store. Test 5: As part of PP-9E, the evaluator configured the test tool to present an otherwise valid RSA X509v3 certificate that contained a modified byte in the first eight bytes of the certificate. The evaluator observed TLS handshake and confirmed that the certificate validation failed and the TOE produced: ”TLS connection failed – unable to establish connection: wrong tag”. Test 6: As part of PP-9F, the evaluator configured the test tool to present an otherwise valid RSA X509v3 certificate that contained a modified byte in the last eight bytes of the certificate and observed that the certificate validation failed. The evaluator observed TLS handshake and the TOE produced: ”RSA_EAY_PUBLIC_DECRYPT:padding check failed error”. Test 7: As part of PP-9G, the evaluator configured test tool to present an otherwise valid RSA X509v3 certificate that contained a modified byte in the public key of the certificate. The evaluator observed TLS handshake and confirmed that the certificate validation failed and the TOE produced: ”TLS connection failed – unable to establish connection: bad signature”. FIA_X509_EXT.1.2/Rev: Test 1: As part of PP-9H, the evaluator attempted to install an intermediate CA certificate that was missing the basicConstraints extension. The evaluator observed that this certificate failed the format check by the TOE and an error was generated. The certificate was not installed on the TOE. Test 2: As part of PP-9I, the evaluator attempted to install an intermediate CA certificate that had the CA flag in the basicConstraints extension set the FALSE. The evaluator observed that this certificate failed the format check by the TOE and an error was generated.

2.3.7 FIA_X509_EXT.2 X.509 Certificate Authentication

2.3.7.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE can use the certificates. (2) The evaluator shall examine the TSS to confirm that it describes the behaviour of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. The evaluator shall verify that any distinctions between trusted channels are described. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the guidance documentation contains instructions on how this configuration action is performed. TSS Implementation Details/Results: (1) The evaluator checked the ST Section 7.3 and verified that the TSS describes how the TOE chooses which certificate to use and how the certificate is installed in the TOE. The TSS states “Security administrator installs X.509 v3 certificates in the TLS server. To facilitate this, Security Administrator first generates certificate-signing request (CSR). CSR causes generation of 2048-bit RSA private and public key pair in the TOE. Security Administrator obtains the signed certificate from the CA and imports in the TOE. This facilitates the eAPI client to validate identity of the server”. (2) The evaluator checked the ST Section 7.3 and confirmed that the TSS describes the behaviour of the TOE when a connection cannot be established during the validity check of a certificate that is being used in establishing a trusted channel. The TSS states “When an X509 certificate is presented during TLS handshake, the TOE validates the presented certificate and the entire trust chain by performing various checks on the certificate including revocation checks. Each certificate revocation check is performed using the local CRL files downloaded in a regular

61 of 86 Arista Networks Switches Running EOS Assurance Activity Report

interval from the CRL servers. The Security Administrator configures the device with one or more Certificate Distribution Points (CDP) to download the latest CRL files. At the time of revocation checking, the TOE ensures that the current time lies within the validity period of the CRL, that is between the effective date and the next update date mentioned in the CRL. The certification revocation checking can fail either because the certificate is revoked as per the CRL, or because the recent CRL for the CA that issued the certificate is not present in the local copy to perform the revocation checking. If any of the checks mentioned in the TSS fails, then the TLS connection is rejected.”

2.3.7.2 Guidance Assurance Activities

Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A

2.3.7.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall perform the following test for each trusted channel: (1) The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking to be performed in at least some part by communicating with a non-TOE IT entity. (2) The evaluator shall then manipulate the environment so that the TOE is unable to verify the validity of the certificate, and observe that the action selected in FIA_X509_EXT.2.2 is performed. If the selected action is administrator-configurable, then the evaluator shall follow the guidance documentation to determine that all supported administrator-configurable options behave in their documented manner. Testing Implementation Details/Results: As per the ST Section 7.3, The TOE performs following checks on the certificate presented by the eAPI client:  That the certificate chain presented by the eAPI client can be traced to the CA certificate that is lowest in the hierarchy of certificates imported into the TOE as described above. That is, this lowest CA certificate acts as the trust anchor. Note that the trust anchor can be an intermediate CA certificate or the root CA certificate.  That the current date and time lies between the “Valid from” and “Valid to” for each certificate from the leaf certificate in the chain presented by eAPI client upto and including the trust anchor.  That the basicConstraints extension is included with CA flag is set to TRUE for all CA certificates in the chain.  That the extendedKeyUsage field in the leaf certificate in the chain presented by eAPI client has the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2).  That the digital signatures are correct in all certificates.  That none of the certificates from the leaf up to the trust anchor is revoked. It is not necessary to check revocation status of the trust anchor and other CA certificates upstream of the trust anchor. If any of the checks mentioned above fails, then the TLS connection is rejected. (1) As part of test case PP-10A, the evaluator created a valid eAPI client certificate to mutually authenticate the eAPI client host with the TOE eAPI TLS server. The evaluator observed that eAPI Client successfully authenticates to the TOE using a valid X.509v3 certificate upon valid checking as listed above by the TOE. (2) The evaluator then revoked the eAPI client certificate, issued a new CRL and try the connection again. The authentication failed with “certificate revoked” error.

2.3.8 FIA_X509_EXT.3 Extended: X509 Certificate Requests

2.3.8.1 TSS Assurance Activities

TSS Assurance Activities: If the ST author selects "device-specific information", the evaluator shall verify that the TSS contains a description of the device-specific fields used in certificate requests.

62 of 86 Arista Networks Switches Running EOS Assurance Activity Report

TSS Implementation Details/Results: The ST author has not selected “device-specific information”; therefore, this activity is not applicable.

2.3.8.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall check to ensure that the guidance documentation contains instructions on requesting certificates from a CA, including generation of a Certificate Request. If the ST author selects "Common Name", "Organization", "Organizational Unit", or "Country", the evaluator shall ensure that this guidance includes instructions for establishing these fields before creating the Certification Request. Guidance Implementation Details/Results: The evaluator examined the CC Guide, Section 3.12 TLS Server, Page 16 covers necessary preparatory steps (generating certificate signing request (CSR) on the TOE, installing trusted CA certificates, installing TLS server certificate, CRL file to the TOE) for the successful logging of the remote administrator(s) to the TOE using the public key authentication. The instructions covers the generation of CSR by prompting a number of questions like Common Name, Two-Letter Country Code, Organization Name, Organization Unit etc.

2.3.8.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall perform the following tests: a) Test 1: The evaluator shall use the guidance documentation to cause the TOE to generate a Certification Request. The evaluator shall capture the generated message and ensure that it conforms to the format specified. The evaluator shall confirm that the Certification Request provides the public key and other required information, including any necessary user-input information. b) Test 2: The evaluator shall demonstrate that validating a response message to a Certification Request without a valid certification path results in the function failing. The evaluator shall then load a certificate or certificates as trusted CAs needed to validate the certificate response message, and demonstrate that the function succeeds. Testing Implementation Details/Results: a) Test 1: As part of the test case PP-12, the evaluator used the guidance documentation Section 3.12 TLS server Page 16 generate a Certification Request on the TOE. The evaluator then verified the certificate signing request file and ensured that it conforms to the format specified. The evaluator confirmed that the Certification Request contains the public key and other required information for creating the certificate by a CA. b) Test 2: As part of the PP-9A, the evaluator removed the intermediate CA certificate and observed that validating the TOE certificate without a valid certificate path changed the SSL profile state to invalid. The evaluator then reloaded the intermediate CA certificate, re-ran the profile validation query, and confirmed the valid status of the SSL profile when the trusted store contains all valid CA certificate required to form the chain.

63 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.4 Security Management (FMT)

2.4.1 FMT_MOF.1/ManualUpdate

2.4.1.1 TSS Assurance Activities

TSS Assurance Activities: None TSS Implementation Details/Results: N/A

2.4.1.2 Guidance Assurance Activities

Guidance Assurance Activities: (1) The evaluator shall examine the guidance documentation to determine that any necessary steps to perform manual update are described. (2) The guidance documentation shall also provide warnings regarding functions that may cease to operate during the update (if applicable). Guidance Implementation Details/Results: (1) The evaluator examined the CC Guide, Section 3.1 Software Image Page 4, and confirmed that it contains adequate instructions to perform manual update. (2) The evaluator examined the CC Guide, Section 3.1 Software Image Page 4, and confirmed that it contains instructions to cease the upgrade operation and contact the Arista support to report the issue.

2.4.1.3 Testing Assurance Activities

Testing Assurance Activities: (1) The evaluator shall try to perform the update using a legitimate update image without prior authentication as security administrator (either by authentication as a user with no administrator privileges or without user authentication at all – depending on the configuration of the TOE). The attempt to update the TOE shall fail. (2) The evaluator shall try to perform the update with prior authentication as security administrator using a legitimate update image. This attempt should be successful. This test case should be covered by the tests for FPT_TUD_EXT.1 already. Testing Implementation Details/Results: (1) As part of the test case PP-1B, the evaluator attempted to perform an update using a legitimate update image by authenticating as a user with no administrator privileges. The evaluator could not able to run any management commands due to authorization denied error. This confirms that the TOE does not allow a user without administrator privileges to perform image updates or any configuration changes to the TOE. (2) As part of the test case PP-1B, the evaluator performed the update, with prior authentication as security administrator, using a legitimate update image. The TOE was updated successfully and the update process generated appropriate audit record(s).

2.4.2 FMT_MTD.1/CoreData Management of TSF Data

2.4.2.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall examine the TSS to determine that, for each administrative function identified in the guidance documentation; those that are accessible through an interface prior to administrator log-in are identified. (2) For each of these functions, the evaluator shall also confirm that the TSS details how the ability to manipulate the TSF data through these interfaces is disallowed for non-administrative users. (3) If the TOE supports handling of X.509v3 certificates and implements a trust store, the evaluator shall examine the TSS to determine that it contains sufficient information to describe how the ability to manage the TOE’s trust store is restricted. TSS Implementation Details/Results:

64 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The evaluator verified that: (1) The ST Section 7.4, details that the TOE requires all users (local or remote) to be successfully identified, authenticated and authorized before permitting any TSF-mediated actions. (2) The ST Section 7.4, details that local or remote user is not allowed to perform the TSF management functions without successful authentication and authorization. (3) The ST Section 7.4, details that only authenticated and authorized users (local or remote) can import CA certificates to the TOE’s trust store.

2.4.2.2 Guidance Assurance Activities

Guidance Assurance Activities: (1) The evaluator shall review the guidance documentation to determine that each of the TSF-data-manipulating functions implemented in response to the requirements of the cPP is identified, and that configuration information is provided to ensure that only administrators have access to the functions. (2) If the TOE supports handling of X.509v3 certificates and provides a trust store, the evaluator shall review the guidance documentation to determine that it provides sufficient information for the administrator to configure and maintain the trust store in a secure way. If the TOE supports loading of CA certificates, the evaluator shall review the guidance documentation to determine that it provides sufficient information for the administrator to securely load CA certificates into the trust store. The evaluator shall also review the guidance documentation to determine that it explains how to designate a CA certificate a trust anchor. Guidance Implementation Details/Results: (1) The evaluator examined the CC Guide, Section 3, and determined that the instructions provided satisfy each of the TSF-data-manipulating functions implemented in response to the requirements of the cPP and confirmed that the Section 3.11 Named User Accounts Page 13 provides instructions to ensure that only administrators have access to the functions. (2) The evaluator examined the CC Guide, Section 3.12 Page 16 and confirmed that the section contains instructions for the administrator to configure and maintain the trust store in a secure way. As the TOE supports loading of CA certificates, the evaluator reviewed the Section 3.12 and confirmed that it provides sufficient information for the administrator to securely load CA certificate into the trust store.

2.4.2.3 Testing Assurance Activities

Testing Assurance Activities: None Testing Implementation Details/Results: N/A

2.4.3 FMT_MTD.1/CryptoKeys Management of TSF Data

2.4.3.1 TSS Assurance Activities

TSS Assurance Activities: None TSS Implementation Details/Results: N/A

2.4.3.2 Guidance Assurance Activities

Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A

2.4.3.3 Testing Assurance Activities

Testing Assurance Activities: (1) The evaluator shall try to perform at least one of the related actions (modify, delete, generate/import) without prior authentication as security administrator (either by authentication as a non-administrative user, if supported, or without authentication at all). Attempts to perform related actions without prior authentication should fail. According to the implementation no other users than the Security Administrator might be defined and without any user

65 of 86 Arista Networks Switches Running EOS Assurance Activity Report

authentication the user might not be able to get to the point where the attempt to manage cryptographic keys can be executed. In that case it shall be demonstrated that access control mechanisms prevent execution up to the step that can be reached without authentication as Security Administrator. (2) The evaluator shall try to perform at least one of the related actions with prior authentication as security administrator. This attempt should be successful.

Testing Implementation Details/Results: (1) As part of the test case PP-1B, the evaluator attempted to login using the defaultuser (role: do-nothing) credentials and ran the management commands. The evaluator could not able to run any management commands due to authorization denied error. This confirms that the TOE does not allow a user without administrator privileges to perform any management related activities including crypto key operations (modify, delete, generate/import). (2) As part of the test case PP-9A PP-12D and PP-13D, the evaluator was able to perform crypto key operations (modify, delete, generate/import) when logged as a Security Administrator.

2.4.4 FMT_SMF.1 Specification of Management Functions

2.4.4.1 TSS Assurance Activities

TSS Assurance Activities: The evaluator shall examine the TSS, Guidance Documentation and the TOE as observed during all other testing and shall confirm that the management functions specified in FMT_SMF.1 are provided by the TOE. The evaluator shall confirm that the TSS details which security management functions are available through which interface(s) (local administration interface, remote administration interface).

TSS Implementation Details/Results: The evaluator noted that the ST Section 7.4 details which security management functions are available through which interface(s) (local administration interface, remote administration interface) through the following list: The local console and remote management interfaces allow the Security Administrator to perform the following TSF management functions:  Administer the TOE locally and remotely  Create the TOE access banner  Set the session inactivity timeout values  Verify and manually install firmware updates (verification using published hash)  Configure failed login threshold and lockout period  Generate, import, delete and configure cryptographic keys required by SSH and TLS  Specify ciphersuites for SSH and TLS  Set system time  Import x.509v3 certificates in trust store

The evaluator using the CC Guide Section 3, and testing activities through PP-1X to PP-8X confirmed that the TOE satisfies all the management functions specified in FMT_SMF.1 both via local administrator interface and remote administrator interface.

2.4.4.2 Guidance Assurance Activities

Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A

66 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.4.4.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator tests management functions as part of testing the SFRs identified in section 2.4.4. No separate testing for FMT_SMF.1 is required unless one of the management functions in FMT_SMF.1.1 has not already been exercised under any other SFR. Testing Implementation Details/Results: Please refer to the corresponding AA sections according to the list given below.

Function Testing Reference Administer the TOE locally and remotely PP-7 Create the TOE access banner PP-5 Set the session inactivity timeout values PP-4 Verify and manually install firmware updates (verification PP-1B using published hash) Configure failed login threshold and lockout period PP-14 Generate, import, delete and configure cryptographic PP-9A to 9J and PP-12A to PP-12G keys required by SSH and TLS Specify ciphersuites for SSH and TLS PP-12A to PP-12G, PP-13A to PP-13H and PP-15A to PP-15H Set system time PP-2

Import x.509v3 certificates in trust store PP-9A

2.4.5 FMT_SMR.2 Restrictions on security roles

2.4.5.1 TSS Assurance Activities

TSS Assurance Activities: None TSS Implementation Details/Results: N/A

2.4.5.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall review the guidance documentation to ensure that it contains instructions for administering the TOE both locally and remotely, including any configuration that needs to be performed on the client for remote administration. Guidance Implementation Details/Results: The evaluator examined the CC Guide, Section 3.11 Named User Accounts Page 13, and confirmed that it contains instructions for administering the TOE both locally and remotely, including the entire necessary configuration to be performed on the remote SSH Client.

67 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.4.5.3 Testing Assurance Activities

Testing Assurance Activities: (1) In the course of performing the testing activities for the evaluation, the evaluator shall use all supported interfaces, although it is not necessary to repeat each test involving an administrative action with each interface. (2) The evaluator shall ensure, however, that each supported method of administering the TOE that conforms to the requirements of this cPP be tested; for instance, if the TOE can be administered through a local hardware interface; SSH; and TLS/HTTPS; then all three methods of administration must be exercised during the evaluation team’s test activities. Testing Implementation Details/Results: (1) The evaluator followed the user guidance to configure the CLI interface for local administration of the TOE. The TOE administered exclusively via CLI that implements both remote and local administration. There is no differences in how CLI operates regardless of how it is accessed. (2) Throughout the testing, the evaluator followed the user guidance to configure CLI over SSH for remote administration of the TOE and CLI over crossover cable for local administration of the TOE.

68 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.5 Protection of the TSF (FPT)

2.5.1 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys)

2.5.1.1 TSS Assurance Activities

TSS Assurance Activities: The evaluator shall examine the TSS to determine that it details how any pre-shared keys, symmetric keys, and private keys are stored and that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. If these values are not stored in plaintext, the TSS shall describe how they are protected/obscured. TSS Implementation Details/Results: The evaluator confirmed that the ST Section 7.2 Table 18 lists all of the TOE’s Critical Security Parameters (CSPs) and details how they are protected and stored. The evaluator checked the Section 7.5 and confirmed that the TSS states administrative interface does not provide a documented command for any user to view any of the private or session keys. There are no pre-shared keys.

2.5.1.2 Guidance Assurance Activities

Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A

2.5.1.3 Testing Assurance Activities

Testing Assurance Activities: None Testing Implementation Details/Results: N/A

2.5.2 FPT_APW_EXT.1 Protection of Administrator Passwords

2.5.2.1 TSS Assurance Activities

TSS Assurance Activities: The evaluator shall examine the TSS to determine that it details all authentication data that are subject to this requirement, and the method used to obscure the plaintext password data when stored. The TSS shall also detail passwords are stored in such a way that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. TSS Implementation Details/Results: The evaluator confirmed that the ST Section 7.5 describes how credentials are stored and protected. Based on this section of the ST, it is clear that raw password authentication data are not stored in non-volatile memory in the plain text.

2.5.2.2 Guidance Assurance Activities

Guidance Assurance Activities: None Guidance Implementation Details/Results: N/A

2.5.2.3 Testing Assurance Activities

Testing Assurance Activities: None Testing Implementation Details/Results: N/A

69 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.5.3 FPT_TST_EXT.1 TSF Testing

2.5.3.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall examine the TSS to ensure that it details the self-tests that are run by the TSF; this description should include an outline of what the tests are actually doing (e.g., rather than saying "memory is tested", a description similar to "memory is tested by writing a value to each memory location and reading it back to ensure it is identical to what was written" shall be used). (2) The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is operating correctly. TSS Implementation Details/Results: (1) The evaluator confirmed that the ST Section 7.5 contains details that the TSF performs known-answer testing, integrity testing, pairwise consistency testing and conditional self-testing.

(2) The ST Section 7.5 describes a standard set of cryptographic self-tests that are consistent with industry’s best practices. Therefore, the evaluator considers them to be sufficient.

2.5.3.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall also ensure that the guidance documentation describes the possible errors that may result from such tests, and actions the administrator should take in response; these possible errors shall correspond to those described in the TSS. Guidance Implementation Details/Results: The CC Guide, Section 3 Secure Configuration details that FIPS mode enabled before any crypto configuration. When the configuration is done, it forces FIPS power-on self-test every time new SSH or TLS instance is created. Note that this happens during run time and not in configuration time. if power-on self-test fails for any of the configuration, the SSH or TLS service is not started. The failure is indicated by log pair such as the following: The following is a sample error message when a self-test fails during SSH startup: Jun 4 16:46:21 switch kernel: [ 721.533308] potentially unexpected fatal signal 6. Jun 4 16:46:21 switch kernel: [ 721.533315] CPU: 0 PID: 4200 Comm: ssh Tainted: P O 4.9.122.Ar-11549262.eostrunk.1 #1

The following is a sample error message when a self-test fails during TLS server startup connection: Jun 4 16:48:40 switch kernel: [ 860.681208] potentially unexpected fatal signal 6. Jun 4 16:48:40 switch kernel: [ 860.681216] CPU: 0 PID: 4970 Comm: nginx Tainted: P O 4.9.122.Ar-11549262.eostrunk.1 #1

2.5.3.3 Testing Assurance Activities

Testing Assurance Activities: It is expected that at least the following tests are performed: a) Verification of the integrity of the firmware and executable software of the TOE. b) Verification of the correct operation of the cryptographic functions necessary to fulfill any of the SFRs. Although formal compliance is not mandated, the self tests performed should aim for a level of confidence comparable to: a) [FIPS 140-2], chap. 4.9.1, Software/firmware integrity test for the verification of the integrity of the firmware and executable software. Note that the testing is not restricted to the cryptographic functions of the TOE.

70 of 86 Arista Networks Switches Running EOS Assurance Activity Report b) [FIPS 140-2], chap. 4.9.1, Cryptographic algorithm test for the verification of the correct operation of cryptographic functions. Alternatively, national requirements of any CCRA member state for the security evaluation of cryptographic functions should be considered as appropriate. The evaluator shall either verify that the self-tests described above are carried out during initial start-up or that the developer has justified any deviation from this. Testing Implementation Details/Results: a) The TOE must be configured to be in FIPS mode of operation as part of the evaluated configuration. The evaluator observed visually via output to the console that the integrity tests were executed on startup of the TOE. b) The evaluator observed the self-test being executed during the formal testing. When the device starts up, the self- tests are executed as expected.

71 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.5.4 FPT_TUD_EXT.1 Trusted Update

2.5.4.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall verify that the TSS describe how to query the currently active version. If a trusted update can be installed on the TOE with a delayed activation, the TSS needs to describe how and when the inactive version becomes active. The evaluator shall verify this description. (2) The evaluator shall verify that the TSS describes all TSF software update mechanisms for updating the system firmware and software (for simplicity the term 'software' will be used in the following although the requirements apply to firmware and software). (3) The evaluator shall verify that the description includes a digital signature verification of the software before installation and that installation fails if the verification fails. Alternatively an approach using a published hash can be used. In this case the TSS shall detail this mechanism instead of the digital signature verification mechanism. The evaluator shall verify that the TSS describes the method by which the digital signature or published hash is verified to include how the candidate updates are obtained, the processing associated with verifying the digital signature or published hash of the update, and the actions that take place for both successful and unsuccessful signature verification or published hash verification. (4) If the options ‘support automatic checking for updates’ or ‘support automatic updates’ are chosen from the selection in FPT_TUD_EXT.1.2, the evaluator shall verify that the TSS explains what actions are involved in automatic checking or automatic updating by the TOE, respectively. (5) If the ST author indicates that a certificate-based mechanism is used for software update digital signature verification, the evaluator shall verify that the TSS contains a description of how the certificates are contained on the device. The evaluator also ensures that the TSS (or guidance documentation) describes how the certificates are installed/updated/selected, if necessary. (6) If a published hash is used to protect the trusted update mechanism, then the evaluator shall verify that the trusted update mechanism does involve an active authorization step of the Security Administrator, and that download of the published hash value, hash comparison and update is not a fully automated process involving no active authorization by the Security Administrator. In particular, authentication as Security Administration according to FMT_MOF.1/ManualUpdate needs to be part of the update process when using published hashes. TSS Implementation Details/Results: The evaluator verified the ST Section 7.5 and confirmed that: (1) It details TSF software updates. When software updates are available, an administrator may obtain and apply the updates, query the currently active version and when to stop the installation. (2) The TOE uses published SHA-512 to verify the update package integrity. The update is performed by Security Administrator and only on the remote management console. When the update package is copied to the TOE, SHA-512 checksum is generated on the update package using the CLI command sha512sum and visually compare the generated hash value with the published hash value to make sure that the integrity of the package is not compromised during the download and transfer to the TOE. If the verification process fails then the installation will not continue. (3) The TOE uses published hash using SHA-512 hash value. Once the update package has been downloaded to the device, then executing the“sha512sum” CLI command will produce a SHA-512 hash value. The Security Administrator must then visually compare the results to the published hash value on the Arista website with the produced value. Upon successful comparison, the Security Administrator can then initiate the upgrade. If the verification process fails then the Security Administrator is instructed not to proceed further. (4) As per the ST Section 6.1.5.4, “TSF shall provide Security Administrators the ability to manually initiate updates to TOE firmware/software and no other update mechanisms”. An authorized user must authenticate to the secure Arista Customer Support portal where the software downloads are available and manually initiate updates to the TOE firmware/software. (5) The ST does not make any claims of supporting certificate-based update verification. (6) The ST states that there is a manual hash verification and confirmation step involved in the update mechanism.

72 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.5.4.2 Guidance Assurance Activities

Guidance Assurance Activities: (1) The evaluator shall verify that the guidance documentation describes how to query the currently active version. If a trusted update can be installed on the TOE with a delayed activation, the guidance documentation needs to describe how to query the loaded but inactive version. (2) The evaluator shall verify that the guidance documentation describes how the verification of the authenticity of the update is performed (digital signature verification or verification of published hash). The description shall include the procedures for successful and unsuccessful verification. The description shall correspond to the description in the TSS. (3) If a published hash is used to protect the trusted update mechanism, the evaluator shall verify that the guidance documentation describes how the Security Administrator can obtain authentic published hash values for the updates. (4) If this was information was not provided in the TSS: If the ST author indicates that a certificate-based mechanism is used for software update digital signature verification, the evaluator shall verify that the Guidance Documentation contains a description of how the certificates are contained on the device. The evaluator also ensures that the Guidance Documentation describes how the certificates are installed/updated/selected, if necessary. Guidance Implementation Details/Results: (1) The evaluator examined the CC Guide, Section 3.1 Software Image, Page 4, and confirmed that it contains instructions for querying the currently active version. Arista switches do not support delayed activation. (2) The evaluator examined the CC Guide, Section 3.1 Software Image, Page 4, and confirmed that it contains instructions for verifying the authenticity of the update package before the update is installed on the switches. The guide contains instructions for successful verification (proceed with the install) and unsuccessful verification (contact Arista support) and do not install the package. (3) The evaluator examined the CC Guide, Section 3.1 Software Image, Page 4, and confirmed that it contains instructions for the Security Administrator to obtain authentic published hash value from the Arista’s website. (4) Verifying digitally signed updates are not claimed in the ST, therefore this assurance activity is not applicable.

2.5.4.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall perform the following tests: a) Test 1: The evaluator performs the version verification activity to determine the current version of the product. If a trusted update can be installed on the TOE with a delayed activation, the evaluator shall also query the most recently installed version (for this test the TOE shall be in a state where these two versions match). The evaluator obtains a legitimate update using procedures described in the guidance documentation and verifies that it is successfully installed on the TOE. For some TOEs loading the update onto the TOE and activation of the update are separate steps (‘activation’ could be performed e.g. by a distinct activation step or by rebooting the device). In that case the evaluator verifies after loading the update onto the TOE but before activation of the update that the current version of the product did not change but the most recently installed version has changed to the new product version. After the update, the evaluator performs the version verification activity again to verify the version correctly corresponds to that of the update and that current version of the product and most recently installed version match again. b) Test 2 (if digital signatures are used): The evaluator first confirmed that no updates are pending and then performs the version verification activity to determine the current version of the product, verifying that it is different from the version claimed in the update(s) to be used in this test. The evaluator obtains or produces illegitimate updates as defined below, and attempts to install them on the TOE. The evaluator verifies that the TOE rejects all of the illegitimate updates. The evaluator performs this test using all of the following forms of illegitimate updates: 1) A modified version (e.g. using a hex editor) of a legitimately signed update 2) An image that has not been signed 3) An image signed with an invalid signature (e.g. by using a different key as expected for creating the signature or by manual modification of a legitimate signature) 4) If the TOE allows a delayed activation of updates the TOE must be able to display both the currently executing version and most recently installed version. The handling of version information of the most recently installed version might differ between different TOEs depending on the point in time when an attempted update is rejected. The evaluator shall verify that the TOE handles the most recently installed version information for that case as described in the guidance documentation. After the TOE has rejected the update

73 of 86 Arista Networks Switches Running EOS Assurance Activity Report

the evaluator shall verify, that both, current version and most recently installed version, reflect the same version information as prior to the update attempt c) Test 3 (if published hash is verified on the TOE): If the published hash is provided to the TOE by the Security Administrator and the verification of the hash value over the update file(s) against the published hash is performed by the TOE, then the evaluator shall perform the following tests. The evaluator first confirmed that no update is pending and then performs the version verification activity to determine the current version of the product, verifying that it is different from the version claimed in the update(s) to be used in this test. 1) The evaluator obtains or produces an illegitimate update such that the hash of the update does not match the published hash. The evaluator provides the published hash value to the TOE and calculates the hash of the update either on the TOE itself (if that functionality is provided by the TOE), or else outside the TOE. The evaluator confirms that the hash values are different, and attempts to install the update on the TOE, verifying that this fails because of the difference in hash values (and that the failure is logged). Depending on the implementation of the TOE, the TOE might not allow the user to even attempt updating the TOE after the verification of the hash value fails. In that case the verification that the hash comparison fails is regarded as sufficient verification of the correct behaviour of the TOE.

2) The evaluator uses a legitimate update and tries to perform verification of the hash value without storing the published hash value on the TOE. The evaluator confirmed that this attempt fails. Depending on the implementation of the TOE it might not be possible to attempt the verification of the hash value without providing a hash value to the TOE, e.g. if the hash value needs to be handed over to the TOE as a parameter in a command line message and the syntax check of the command prevents the execution of the command without providing a hash value. In that case the mechanism that prevents the execution of this check shall be tested accordingly, e.g. that the syntax check rejects the command without providing a hash value, and the rejection of the attempt is regarded as sufficient verification of the correct behaviour of the TOE in failing to verify the hash. The evaluator then attempts to install the update on the TOE (in spite of the unsuccessful hash verification) and confirmed that this fails. Depending on the implementation of the TOE, the TOE might not allow to even attempt updating the TOE after the verification of the hash value fails. In that case the verification that the hash comparison fails is regarded as sufficient verification of the correct behaviour of the TOE.

3) If the TOE allows delayed activation of updates, the TOE must be able to display both the currently executing version and most recently installed version. The handling of version information of the most recently installed version might differ between different TOEs. Depending on the point in time when the attempted update is rejected, the most recently installed version might or might not be updated. The evaluator shall verify that the TOE handles the most recently installed version information for that case as described in the guidance documentation. After the TOE has rejected the update the evaluator shall verify, that both, current version and most recently installed version, reflect the same version information as prior to the update attempt. If the verification of the hash value over the update file(s) against the published hash is not performed by the TOE, Test 3 shall be skipped. The evaluator shall perform Test 1, Test 2 and Test 3 (if applicable) for all methods supported (manual updates, automatic checking for updates, automatic updates). Testing Implementation Details/Results: a) Test 1: The evaluator displayed the version of the product, then installed an update. The published hash value was verified visually against the generated hash, and the update was loaded successfully after verification. After the update, the evaluator performed the version verification activity again to verify the version correctly corresponds to that of the update and that current version of the product and most recently installed version match again. Delayed activation is not supported by the TOE. b) Test 2: The evaluator modified an update using a binary editor and then attempted to install it. The hash verification failed and the Security Administrator is advised not to proceed further and report the problem to Arista immediately. So the update was not installed. Verifying digitally signed updates are not claimed in the ST, therefore this assurance activity is not applicable and so not tested.

2.5.5 FPT_STM_EXT.1 Reliable Time Stamps

2.5.5.1 TSS Assurance Activities

TSS Assurance Activities:

74 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time, and that it provides a description of how the time is maintained and considered reliable in the context of each of the time related functions. TSS Implementation Details/Results: The evaluator examined the ST Section 7.5 and noted that the TOE uses system time for time stamps of the operations. As per the ST, the Security Administrator initially sets the system time manually using the CLI command interface. After that two components are responsible to keep the system time namely, hardware-based real-time clock managed by embedded OS, and the software-based “system clock” which is a software counter based on the timer interrupt. Once every 30 days, the Security Administrator is expected to set the clock on the TOE using a CLI command. The new time must come from the authenticated time source meeting Common Criteria requirements.

2.5.5.2 Guidance Assurance Activities

Guidance Assurance Activities: (1) The evaluator examines the guidance documentation to ensure it instructs the administrator how to set the time. (2) If the TOE supports the use of an NTP server, the guidance documentation instructs how a communication path is established between the TOE and the NTP server, and any configuration of the NTP client on the TOE to support this communication. Guidance Implementation Details/Results: (1) The evaluator examined the CC Guide, Section 3.2 Hostname Time Setting, Page 6, and confirmed that it contains instructions to show clock and set new time and timezone. (2) The TOE does not claim to support the use of an NTP server.

2.5.5.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall perform the following tests: Test 1: The evaluator uses the guidance documentation to set the time. The evaluator shall then use an available interface to observe that the time was set correctly. Test 2: If the TOE supports the use of an NTP server; the evaluator shall use the guidance documentation to configure the NTP client on the TOE, and set up a communication path with the NTP server. The evaluator will observe that the NTP server has set the time to what is expected. If the TOE supports multiple protocols for establishing a connection with the NTP server, the evaluator shall perform this test using each supported protocol claimed in the guidance documentation. If the audit component of the TOE consists of several parts with independent time information, then the evaluator shall verify that the time information between the different parts are either synchronized or that it is possible for all audit information to relate the time information of the different part to one base information unambiguously. Testing Implementation Details/Results: Test 1: As part of test case PP-2 the evaluator manually set the time on the TOE based on the instructions provided in the CC guide Section 3.2 Page 6. Test 2: The TOE does not support the use of an NTP server.

2.6 TOE Access (FTA)

2.6.1 FTA_SSL_EXT.1 TSF-initiated Session Locking

2.6.1.1 TSS Assurance Activities

TSS Assurance Activities: None TSS Implementation Details/Results: N/A

2.6.1.2 Guidance Assurance Activities

75 of 86 Arista Networks Switches Running EOS Assurance Activity Report

Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation states whether local administrative session locking or termination is supported and instructions for configuring the inactivity time period. Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.3 Console Idle Timeout, Page 7, and confirmed that it contains instructions to set idle timeout for local and remote administrative session locking and termination.

2.6.1.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall perform the following test: Test 1: The evaluator follows the guidance documentation to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a local interactive session with the TOE. The evaluator then observes that the session is either locked or terminated after the configured time period. If locking was selected from the component, the evaluator then ensures that re- authentication is needed when trying to unlock the session. Testing Assurance Activities Details/Results: Test 1: As part of the test case PP-4, the evaluator followed the CC guide Section 3.3 Page 7 and configured the following values 1, 3, 5 minutes for the inactivity time period. The evaluator configured the login session timeout value to 1, 3, 5 minutes, and observed that the session was terminated after each of the indicated time out values. The evaluator then observed that re-authentication was required when trying to unlock the session.

2.6.2 FTA_SSL.3 TSF-initiated Termination

2.6.2.1 TSS Assurance Activities

TSS Assurance Activities: None TSS Implementation Details/Results: N/A

2.6.2.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation states whether local administrative session locking or termination is supported and instructions for configuring the inactivity time period. Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.8 SSH Idle Timeout, Page 10, and confirmed that it contains instructions to set idle timeout for local and remote administrative session locking and termination.

76 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.6.2.3 Testing Assurance Activities

Testing Assurance Activities: For each method of remote administration, the evaluator shall perform the following test: Test 1: The evaluator follows the guidance documentation to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a remote interactive session with the TOE. The evaluator then observes that the session is terminated after the configured time period. Testing Assurance Activities Details/Results: Test 1: As part of the test case PP-4, the evaluator followed the CC guide Section 3.8 SSH Idle Timeout, Page 10 and configured the following values 1, 3, 5 minutes for the inactivity time period. The evaluator configured the login session timeout value to 1, 3, 5 minutes, and observed that the SSH session was terminated after each of the indicated time out values. The evaluator then observed that re-authentication was required when trying to unlock the session.

2.6.3 FTA_SSL.4 User-initiated Termination

2.6.3.1 TSS Assurance Activities

TSS Assurance Activities: None TSS Implementation Details/Results: N/A

2.6.3.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation states how to terminate a local or remote interactive session. Guidance Assurance Activities Details/Results: The evaluator verified the CC guide Section 3.3 Console Idle Timeout Page 7 and Section 3.8 SSH Configuration Page 9 and confirmed the presence of instructions to terminate a local or remote interactive session.

2.6.3.3 Testing Assurance Activities

Testing Assurance Activities: For each method of remote administration, the evaluator shall perform the following tests: Test 1: The evaluator initiates an interactive local session with the TOE. The evaluator then follows the guidance documentation to exit or log off the session and observes that the session has been terminated. Test 2: The evaluator initiates an interactive remote session with the TOE. The evaluator then follows the guidance documentation to exit or log off the session and observes that the session has been terminated. Testing Assurance Activities Details/Results: Test 1: The evaluator established an interactive local session with the TOE. The evaluator followed the user guidance to log off from the session and observed that the session was terminated. Test 2: The evaluator established a SSH session with the TOE. The evaluator followed the user guidance to log off from the SSH session and observed that the session was terminated and closed immediately.

77 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.6.4 FTA_TAB.1 Default TOE Access Banners

2.6.4.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall check the TSS to ensure that it details each administrative method of access (local and remote) available to the Security Administrator (e.g., serial port, SSH, HTTPS). (2) The evaluator shall check the TSS to ensure that all administrative methods of access available to the Security Administrator are listed and that the TSS states that the TOE is displaying an advisory notice and a consent warning message for each administrative method of access. The advisory notice and the consent warning message might be different for different administrative methods of access, and might be configured during initial configuration (e.g. via configuration file). TSS Implementation Details/Results: (1) The evaluator examined the ST Section 7.6 and confirmed that it contains details about each administrative method of access (local and remote) available to the Security Administrator. Local administrator access the TOE using the local serial port, while remote administrators access the TOE via SSH. (2) The ST Section 7.6 explains that the TOE displays a Security Administrator-specified advisory notice and consent warning message (banner) when a user initiates an interactive session either locally or remotely.

2.6.4.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall check the guidance documentation to ensure that it describes how to configure the banner message. Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.2 Hostname, Time Setting, Login Banner and Password Restrictions, Page 6, and confirmed that it contains instructions to configure the banner message.

2.6.4.3 Testing Assurance Activities

Testing Assurance Activities from NDCPP: The evaluator shall also perform the following test: Test 1: The evaluator follows the guidance documentation to configure a notice and consent warning message. The evaluator shall then, for each method of access specified in the TSS, establish a session with the TOE. The evaluator shall verify that the notice and consent warning message is displayed in each instance. Test 1: As part of the test case PP-5, the evaluator followed the guidance to configure a notice and consent warning message, then established a session with the TOE and observed that the TOE displayed the notice and consent warning message. The evaluator observed the that the TOE displayed the notice and consent warning message for both local and remote methods of access.

78 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.7 Trusted Path/channels (FTP)

2.7.1 FTP_ITC.1 Inter-TSF Trusted Channel

2.7.1.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall examine the TSS to determine that, for all communications with authorized IT entities identified in the requirement, each secure communication mechanism is identified in terms of the allowed protocols for that IT entity, whether the TOE acts as a server or a client, and the method of assured identification of the non-TSF endpoint. (2) The evaluator shall also confirm that all secure communication mechanisms are described in sufficient detail to allow the evaluator to match them to the cryptographic protocol Security Functional Requirements listed in the ST. TSS Implementation Details/Results: (1) The evaluator examined the ST Section 7.7 entry for FTP_ITC.1, and noted the following: For Syslog Server as an authorized entity: “Trusted Channel connection is created between TSF and audit server. It is protected by SSH. TOE acts as SSH Client in the Trusted Channel connection to audit server. Operation of SSH is described above in FCS_SSHC_EXT.1.” For eAPI JSON-RPC Client as an authorized entity: “Trusted Channel connection is created between TSF and eAPI JSON-RPC Client. It is protected by TLS.TOE acts as TLS Server in the Trusted Channel connection to eAPI JSON-RPC Client. Operation of TLS is described above in FCS_TLSS_EXT.2.” (2) The evaluator also confirmed this section contains details on the trusted channel communication between the TOE and the authorized entities (external audit server, eAPI JSON-RPC Client). The evaluator confirmed that all protocols listed in the TSS are specified and included in the requirements of the ST.

2.7.1.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation contains instructions for establishing the allowed protocols with each authorized IT entity, and that it contains recovery instructions should a connection be unintentionally broken. Guidance Implementation Details/Results: The evaluator examined the CC Guide, Section 3.8 SSH Configuration Page 9 and Section 3.12 TLS Server page 16 and confirmed that they contain adequate instructions for establishing the allowed protocols with each authorized IT entity and also contains recovery instructions if a SSH connection is unintentionally broken. A TLS connection is not an interactive one, so there is no instructions required to recover a TLS connection if it is broken unintentionally.

2.7.1.3 Testing Assurance Activities

Testing Assurance Activities: The vendor shall provide to the evaluator application layer configuration settings for all secure communication mechanisms specified by the FTP_ITC.1 requirement. This information should be sufficiently detailed to allow the evaluator to determine the application layer timeout settings for each cryptographic protocol. There is no expectation that this information must be recorded in any public-facing document or report. The evaluator shall perform the following tests: Test 1: The evaluators shall ensure that communications using each protocol with each authorized IT entity is tested during the course of the evaluation, setting up the connections as described in the guidance documentation and ensuring that communication is successful. Test 2: For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall follow the guidance documentation to ensure that in fact the communication channel can be initiated from the TOE. Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext. Test 4: Objective: The objective of this test is to ensure that the TOE reacts appropriately to any connection outage or interruption of the route to the external IT entities.

79 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The evaluator shall, for each instance where the TOE acts as a client utilizing a secure communication mechanism with a distinct IT entity, physically interrupt the connection of that IT entity for the following durations: i) a duration that exceeds the TOE’s application layer timeout setting, ii) a duration shorter than the application layer timeout but of sufficient length to interrupt the MAC layer. The evaluator shall ensure that, when the physical connectivity is restored, communications are appropriately protected and no TSF data is sent in plaintext. In the case where the TOE is able to detect when the cable is removed from the device, another physical network device (e.g. a core switch) shall be used to interrupt the connection between the TOE and the distinct IT entity. The interruption shall not be performed at the virtual node (e.g. virtual switch) and must be physical in nature. Testing Implementation Details/Results: Test 1: The evaluator followed the user guidance documentation and set up communication using the SSH protocol with the syslog server and the TLS with mutual authentication with the eAPI Client. Test 2: The evaluator verified that once the SSH tunnel was established the communication channel was initiated from the TOE to the audit server. This is not applicable for the eAPI Client as the TLS communication is initiated from the eAPI Client to the TOE TLS Server. Test 3: For communication channel with the syslog server and eAPI Client, it was observed that data was not sent in plaintext. Wireshark packet capture was used to verify the data was not in plain text. Test 4: The evaluator physically interrupted the connection to the audit server using SSH using multiple threshold values (5 minutes, 4 hours and overnight). The evaluator observed that the SSH tunnel should be reestablished manually between the TOE and the remote audit server for 4 hours and overnight downtime and observed that the communications were appropriately protected for all the threshold values. Whereas the TLS connection from the eAPI Client to the TOE Server is not persistent. The connection will be disconnected as soon as the request file on the eAPI Client is executed one time.

2.7.2 FTP_TRP.1/Admin Trusted Path

2.7.2.1 TSS Assurance Activities

TSS Assurance Activities: (1) The evaluator shall examine the TSS to determine that the methods of remote TOE administration are indicated, along with how those communications are protected. (2) The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST. TSS Implementation Details/Results: (1) The evaluator examined the ST Section 7.7, which states that the TOE uses SSH for remote TOE administration. (2) The evaluator confirmed that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the NDcPP requirement, and are included in the relevant SFRs in the ST.

2.7.2.2 Guidance Assurance Activities

Guidance Assurance Activities: The evaluator shall confirm that the guidance documentation contains instructions for establishing the remote administrative sessions for each supported method. Guidance Assurance Activities Details/Results: The evaluator examined the CC Guide, Section 3.8 SSH Configuration Page 9 and confirmed that they contain adequate instructions for establishing the remote administrative sessions for each supported method (SSH for remote administrators).

80 of 86 Arista Networks Switches Running EOS Assurance Activity Report

2.7.2.3 Testing Assurance Activities

Testing Assurance Activities: The evaluator shall perform the following tests: Test 1: The evaluators shall ensure that communications using each specified (in the guidance documentation) remote administration method is tested during the course of the evaluation, setting up the connections as described in the guidance documentation and ensuring that communication is successful. Test 2: The evaluator shall ensure, for each communication channel, the channel data is not sent in plaintext. Further assurance activities are associated with the specific protocols. Testing Assurance Activities Details/Results: Test 1: The evaluator followed the user guidance and set up communication using SSH v2 for remote administration. Test 2: The evaluator verified that once the SSH session was established, the communication channel was initiated from the TOE.

81 of 86 Arista Networks Switches Running EOS Assurance Activity Report

3 Security Assurance Requirements

The sections below specify Evaluation Activities for the Security Assurance Requirements included in the related cPPs. The Evaluation Activities are an interpretation of the more general CEM assurance requirements as they apply to the specific technology area of the TOE.

3.1 ASE: Security Target Evaluation

3.1.1 General ASE

Evaluation Activities: (1) When evaluating a Security Target, the evaluator performs the work units as presented in the CEM. In addition, the evaluator ensures the content of the TSS in the ST satisfies the EAs specified in Section 2 (Evaluation Activities for SFRs). Evaluation Activities Details/Results: (1) The evaluator performed the work units as presented in the CEM. The evaluator ensured the content of the TSS in the ST satisfied the EAs specified in Section 2.

3.2 ADV_FSP.1 Basic Functional Specification

3.2.1 Assurance Activities

Evaluation Activities: (1) The evaluator shall examine the interface documentation to ensure it describes the purpose and method of use for each TSFI that is identified as being security relevant. In this context, TSFI are deemed security relevant if they are used by the administrator to configure the TOE, or to perform other administrative functions (e.g. audit review or performing updates). Additionally, those interfaces that are identified in the ST, or guidance documentation, as adhering to the security policies (as presented in the SFRs), are also considered security relevant. The intent is that these interfaces will be adequately tested, and having an understanding of how these interfaces are used in the TOE is necessary to ensure proper test coverage is applied. The set of TSFI that are provided as evaluation evidence are contained in the Administrative Guidance and User Guidance. (2) The evaluator shall check the interface documentation to ensure it identifies and describes the parameters for each TSFI that is identified as being security relevant. (3) The evaluator shall examine the interface documentation to develop a mapping of the interfaces to SFRs. The evaluator uses the provided documentation and first identifies, and then examines a representative set of interfaces to perform the EAs presented in Section 2, including the EAs associated with testing of the interfaces. It should be noted that there may be some SFRs that do not have an interface that is explicitly “mapped” to invoke the desired functionality. For example, generating a random bit string, destroying a cryptographic key that is no longer needed, or the TSF failing to a secure state, are capabilities that may be specified in SFRs, but are not invoked by an interface. However, if the evaluator is unable to perform some other required EA because there is insufficient design and interface information, then the evaluator is entitled to conclude that an adequate functional specification has not been provided, and hence that the verdict for the ADV_FSP.1 assurance component is a ‘fail’. Evaluation Activities Details/Results: FSP document was reviewed by the evaluator and provided to the scheme as part of the checkout package. This document outlines TOE TSFIs and states their purpose, method of use, and identifies parameters by referencing applicable RFC standard.

82 of 86 Arista Networks Switches Running EOS Assurance Activity Report

3.3 AGD: Guidance Documents

3.3.1 AGD_OPE.1 Operational User Guidance

3.3.1.1 Assurance Activities

Evaluation Activities: (1) The evaluator shall ensure the Operational guidance documentation is distributed to administrators and users (as appropriate) as part of the TOE, so that there is a reasonable guarantee that administrators and users are aware of the existence and role of the documentation in establishing and maintaining the evaluated configuration. (2) The evaluator shall ensure that the Operational guidance is provided for every Operational Environment that the product supports as claimed in the Security Target and shall adequately address all platforms claimed for the TOE in the Security Target. (3) The evaluator shall ensure that the Operational guidance contains instructions for configuring any cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. (4) The evaluator shall ensure the Operational guidance makes it clear to an administrator which security functionality and interfaces have been assessed and tested by the EAs. (5) In addition the evaluator shall ensure that the following requirements are also met. a) The guidance documentation shall contain instructions for configuring any cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. b) The documentation must describe the process for verifying updates to the TOE by verifying a digital signature. The evaluator shall verify that this process includes the following steps: 1) Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory). 2) Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes instructions that describe at least one method of validating the hash/digital signature. c) The TOE will likely contain security functionality that does not fall in the scope of evaluation under this cPP. The guidance documentation shall make it clear to an administrator which security functionality is covered by the Evaluation Activities. Evaluation Activities Details/Results: (1) The vendor submitted Common Criteria Guide v1.14 for the evaluation. The evaluator used the guide to configure the TOE in the Common Criteria (CC) mode. Sometimes, the evaluator used the User Guidance for in-depth details of the commands. (2) The evaluator followed the Section 3.1 to 3.7 of the CC guide to configure the TOE to be setup in an evaluated configuration. (3) The evaluator examined the procedures in Section 3 to ensure that the guide includes instructions to successfully install the TOE in each Operational Environment. (4) The guide provides administrator login information in Section 3.1 for the first time setup. (5) In addition the evaluator also confirmed the following criteria’s: a) The CC Guide, Section 3, Secure Configuration, Page 4-23 details how to configure the cryptographic engine in FIPS mode. b) The CC Guide, Section 3.1, Software Image, Page 4 details how to obtain and apply updates to the system and determining if an upgrade was successful/unsuccessful. c) The product presents a hash to be manually compared by the administrator to a published hash before loading the update as stated in the ST and found during testing.

83 of 86 Arista Networks Switches Running EOS Assurance Activity Report

3.3.2 AGD_PRE.1 Preparative Procedures

3.3.3 Assurance Activities

Evaluation Activities: (1) The evaluator shall examine the Preparative procedures to ensure they include a description of how the administrator verifies that the operational environment can fulfil its role to support the security functionality (including the requirements of the Security Objectives for the Operational Environment specified in the Security Target). The documentation should be in an informal style and should be written with sufficient detail and explanation that they can be understood and used by the target audience (which will typically include IT staff who have general IT experience but not necessarily experience with the TOE product itself). (2) The evaluator shall examine the Preparative procedures to ensure they are provided for every Operational Environment that the product supports as claimed in the Security Target and shall adequately address all platforms claimed for the TOE in the Security Target. (3) The evaluator shall examine the preparative procedures to ensure they include instructions to successfully install the TSF in each Operational Environment. (4) The evaluator shall examine the preparative procedures to ensure they include instructions to manage the security of the TSF as a product and as a component of the larger operational environment. (5) In addition the evaluator shall ensure that the following requirements are also met. The preparative procedures must a) include instructions to provide a protected administrative capability; and b) identify TOE passwords that have default values associated with them and instructions shall be provided for how these can be changed. Evaluation Activities Details/Results: (6) The vendor submitted Common Criteria Guide v1.14 for the evaluation. The evaluator used the guide to configure the TOE in the Common Criteria (CC) mode. Sometimes, the evaluator used the User Guidance for in-depth details of the commands. (7) The evaluator followed the Section 3.1 to 3.7 of the CC guide to configure the TOE to be setup in an evaluated configuration. (8) The evaluator examined the procedures in Section 3 to ensure that the guide includes instructions to successfully install the TOE in each Operational Environment. (9) The guide provides administrator login information in Section 3.1 for the first time setup. (10) In addition the evaluator also confirmed the following criteria’s: a) The CC Guide, Section 3.4, Default Account Protection, Page 7 details how to configure a protected administrative capability. b) The CC Guide, Section 3.1, Software Image, Page 4 contains the details on the default TOE password and Section 3.4 provides instructions on the password change for the administrator.

3.4 ALC: Life-cycle Support

3.4.1 ALC_CMC.1 Labelling of the TOE

3.4.1.1 Assurance Activities

Evaluation Activities: When evaluating that the TOE has been provided and is labelled with a unique reference, the evaluator performs the work units as presented in the CEM. Evaluation Activities Details/Results: The evaluator performed the CEM work units as reported in the ETR.

84 of 86 Arista Networks Switches Running EOS Assurance Activity Report

3.4.2 ALC_CMS.1 TOE CM coverage

3.4.2.1 Assurance Activities

Evaluation Activities: When evaluating the developer’s coverage of the TOE in their CM system, the evaluator performs the work units as presented in the CEM. Evaluation Activities Details/Results: The evaluator performed the CEM work units as reported in the ETR.

3.5 ATE: Tests

3.5.1 ATE_IND.1 Independent Testing – Conformance

3.5.1.1 Assurance Activities

Evaluation Activities: The focus of the testing is to confirm that the requirements specified in the SFRs are being met. Additionally, testing is performed to confirm the functionality described in the TSS, as well as the dependencies on the Operational guidance documentation is accurate. The evaluator performs the CEM work units associated with the ATE_IND.1 SAR. Specific testing requirements and EAs are captured for each SFR in Sections 2, 3 and 4. The evaluator should consult Appendix B when determining the appropriate strategy for testing multiple variations or models of the TOE that may be under evaluation. Evaluation Activities Details/Results: Please refer to the NDcPP Arista Test Plan v1.9 - October-28-2019 for all details.

3.6 AVA: Vulnerability Assessment

3.6.1 AVA_VAN.1 Vulnerability Survey

Evaluation Assurance Activities: (1) The evaluator shall examine the documentation outlined below provided by the developer to confirm that it contains all required information. This documentation is in addition to the documentation already required to be supplied in response to the EAs listed previously. The developer shall provide documentation identifying the list of software and hardware components1 that compose the TOE. Hardware components should identify at a minimum the processors used by the TOE. Software components include applications, the operating system and other major components that are independently identifiable and reusable (outside the TOE) such as a web server and protocol or cryptographic libraries. This additional documentation is merely a list of the name and version number of the components, and will be used by the evaluators in formulating hypotheses during their analysis. (2) The evaluator formulates hypotheses in accordance with process defined in Appendix A. The evaluator documents the flaw hypotheses generated for the TOE in the report in accordance with the guidelines in Appendix A.3. The evaluator shall perform vulnerability analysis in accordance with Appendix A.2. The results of the analysis shall be documented in the report according to Appendix A.3. Evaluation Activities Details/Results: The Vendor had provided comprehensive list of third party software components that are used in the EOS of the TOE. This list included 384 entries for Application Packages and 33 entries of Python Packages, which included webservers, protocol libraries, system utilities etc.

85 of 86 Arista Networks Switches Running EOS Assurance Activity Report

The evaluator conducted vulnerability assessment of all these entries using the methods described below and created a detailed report (Arista Networks Switches Packages VA.xls) based on the assessment outcome. The evaluator used the following methods to do the vulnerability analysis which includes a public search for vulnerabilities on the following websites and vulnerability testing listed in the Arista Test Report:  The National Vulnerability Database at https://nvd.nist.gov/vuln  The CVE Details website at https://www.cvedetails.com/vulnerability-search.php Both sites were checked using the package name and version provided in the list, as in many instances, one website would yield one or more results while the other provided no results, and vice versa. In many instances, several hundred potential vulnerabilities had to be checked. In every instance where each website generated hits, the results were cross checked for duplicate entries.

The evaluator created a vulnerability report on all the packages and identified 10 application packages that are to be addressed for vulnerabilities by the vendor. The evaluator recommended the vendor to patch each package that was identified, leaving no possibility to whether the TOE could be exploited. Failing that, each vulnerability has to be explained, with a rationale provided as to why such vulnerability is not applicable to the TOE or how it is not feasible to exploit such vulnerability in the evaluated configuration.

The vendor confirmed that all the issues were addressed in the evaluated version of the TOE.

86 of 86