Preview only show first 10 pages with watermark. For full document please download

Assurance Activity Report Hsl Secure Km Switch Peripheral Switch Protection Profile

   EMBED


Share

Transcript

Assurance Activity Report HSL Secure KM Switch Peripheral Switch Protection Profile Document version: 1.0 February 2016 Document prepared by HSL Secure KM Switch Switch Document History Version 1.0 Date February 17, 2016 Author B Pleffner Assurance Activity Report v1.0 Description Evaluation and Assurance activities complete Page ii HSL Secure KM Switch Switch Intentionally left blank Assurance Activity Report v1.0 Page iii HSL Secure KM Switch Switch Table of Contents 1 INTRODUCTION..................................................................................................... 6 1.1 2 3 OVERVIEW ........................................................................................................... 6 TOE EVALUATION SPECIFICS .......................................................................... 7 2.1 DOCUMENT REFERENCES ..................................................................................... 7 2.2 EVALUATED PLATFORMS (FROM SECURITY TARGET) .......................................... 7 2.3 EQUIVALENCY ..................................................................................................... 7 EVALUATION ......................................................................................................... 9 3.1 TECHNIQUES, TOOLS AND STANDARDS ................................................................ 9 3.2 TEST CONFIGURATION ....................................................................................... 10 3.2.1 Test Setup E (4P KM) ..................................................................................... 10 3.3 4 TEST CONFIGURATION DIAGRAM....................................................................... 12 ASSURANCE ACTIVITIES FOR PSS PP .......................................................... 13 4.1 FDP_IFC.1 (1) SUBSET INFORMATION FLOW CONTROL ..................................... 13 4.2 FDP_IFF.1 (1) SIMPLE SECURITY ATTRIBUTES .................................................. 14 4.3 FDP_IFC.1 (2) SUBSET INFORMATION FLOW CONTROL ..................................... 17 4.4 FDP_IFF.1 (2) SIMPLE SECURITY ATTRIBUTES .................................................. 17 4.5 FDP_ACC.1 SUBSET ACCESS CONTROL ............................................................ 36 4.6 FDP_ACF.1 SECURITY ATTRIBUTE BASED ACCESS CONTROL ............................ 37 4.7 FDP_RIP.1 SUBSET RESIDUAL INFORMATION PROTECTION .............................. 40 4.8 FPT_PHP.1 SUBSET RESIDUAL INFORMATION PROTECTION .............................. 43 4.9 FPT_PHP.3 SUBSET RESIDUAL INFORMATION PROTECTION .............................. 45 4.10 FPT_FLS.1 FAILURE WITH PRESERVATION OF SECURE STATE ........................... 48 4.11 FPT_TST.1 TSF TESTING .................................................................................. 50 4.12 FTA_CIN_EXT.1 EXTENDED: CONTINUOUS INDICATIONS ............................... 54 4.13 FAU_GEN.1: AUDIT DATA GENERATION ......................................................... 56 4.14 FIA_UAU.2 USER AUTHENTICATION BEFORE ANY ACTION ............................... 58 4.15 FIA_UID.2 USER IDENTIFICATION BEFORE ANY ACTION ................................... 59 4.16 FMT_MOF.1 MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOR ................... 59 4.17 FMT_SMF.1 MANAGEMENT OF SECURITY FUNCTIONS BEHAVIOR .................... 61 4.18 FMT_SMR.1 SECURITY ROLES ......................................................................... 63 4.19 FTA_ATH_EXT.1 USER AUTHENTICATION DEVICE RESET ............................... 64 Assurance Activity Report v1.0 Page 4 HSL Secure KM Switch Switch 4.20 ADV_FSP.1 BASIC FUNCTIONAL SPECIFICATION ............................................. 66 4.21 AGD_OPE.1 OPERATIONAL USER GUIDANCE .................................................. 67 4.22 AGD_PRE.1 PREPARATIVE PROCEDURES ......................................................... 67 4.23 ATE_IND.1 INDEPENDENT TESTING - CONFORMANCE ..................................... 68 4.24 ALC_CMC.1 LABELING OF THE TOE ............................................................... 70 4.25 ALC_CMS.1 TOE CM COVERAGE ................................................................... 73 5 CONCLUSIONS AND RECOMMENDATIONS ................................................ 74 6 LIST OF EVALUATION EVIDENCE ................................................................. 75 7 PRODUCT COMPLIANCE LISTING ENTRY ................................................. 76 8 LIST OF ACRONYMS/GLOSSARY OF TERMS ............................................. 77 9 RATIONAL FOR PRODUCTS SELECTED ...................................................... 79 9.1 OVERVIEW ......................................................................................................... 79 9.2 RATIONALE FOR TEST COVERAGE OF MULTIPLE TOE MODELS ........................... 79 9.3 JUSTIFICATION FOR SELECTION MADE BY HSL .................................................. 80 9.3.1 Secure KM Switch (Group E) .......................................................................... 80 9.4 SUMMERY .......................................................................................................... 81 9.4.1 Number of ports / enclosures........................................................................ 81 9.4.1 Operation Mode ............................................................................................ 81 9.4.2 fUSB function Supported ............................................................................... 81 Assurance Activity Report v1.0 Page 5 HSL Secure KM Switch Switch 1 1.1 Introduction Overview This Assurance Activity Report (AAR) documents the evaluation of HSL Secure KM Switch developed by HSL. HSL is the sponsor of this evaluation which is being conducted by CSC Security Testing and Certification Laboratory (STCL) under the United States National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS). The following table contains the configuration control identifiers for the Target of Evaluation (TOE); the Security Target (ST) for the evaluation; this document, the ETR, and the Protection Profile the TOE is conformed to. Table 1: Items under configuration management Item Configuration Control Identifier Target of Evaluation: HSL Secure KM Switch Security Target: High Security Labs Secure KM Security Target, version 3.14 Assurance Activity Report HSL Secure KM Switch Assurance Activity Report version 1.0 (this document) Evaluation Technical Report HSL Secure KM Switch EAL1 Evaluation Technical Report version 1.0 Protection Profile: Standard Protection Profile for Peripheral Sharing Switches, version 3.0 (PSS PP) Assurance Activity Report v1.0 Page 6 HSL Secure KM Switch Switch 2 TOE Evaluation Specifics 2.1 Document References Table 2: Referenced documents Ref. Document [A] HSL Secure KM Switch Assurance Activity Report (This document) [B] High Security Labs Secure KM Security Target, version 3.14 [C] SECURE KM SWITCH 2/4/8 PORT USER MANUAL 2.2 Evaluated Platforms (from Security Target) Table 3: Evaluated TOE N o Model P/N Description Eval. Version CGA1 0106 HSL Secure SH KM 2-Port, No video, PP 3.0 30303-00C4 2-Port 1 SM20 N-3 4-Port 2 SM40 N-3 CGA1 0141 HSL Secure SH KM Switch 4-Port No video, PP 3.0 30303-00C4 3 SM40 NU-3 CGA1 0142 HSL Secure SH KM Switch 4-Port No video, w/fUSB, PP 3.0 30333-00C4 8-Port 4 SM80 N-3 CGA1 0152 HSL Secure SH KM Switch 8-port, PP 3.0 30303-00C4 5 SM80 NU-3 CGA1 0153 HSL Secure SH KM Switch 8-port w/fUSB, PP 3.0 30333-00C4 2.3 Equivalency The Design Documentation describes a low-level breakdown of the TOE including firmware logic and circuitry. Review of this document shows how the circuitry is extended to include more ports for the 2, 4, and 8 port models. Because the number of ports on the KM switch has no effect on the security threats associated with it, it is adequate to test a specific function on one product with arbitrary number of channels. It should be noted that the peripheral functions are identical in hardware and firmware across the different models. This document describes the testing procedure for the 5 TOE models that are listed in table 3 above. The scope of the test plans includes only the claimed SFR’s, which are identical for each model of the KM switch. Each test case verifies one or more SFR’s in the Security Target. The only model specific test cases are those that iterate through each computer in order to verify that each port is working as intended. The test cases can be applied to any model of the KM by changing the number of computers tested. Assurance Activity Report v1.0 Page 7 HSL Secure KM Switch Switch Based on the design presented in the ST, and the test cases defined in this document, there are no aspects of the different models that are not covered in testing a single model. The primary differences between the various evaluated products are: 1) Hardware differences: a) The number of ports that the KM support – 2, 4, or, 8; b) Models with and without fUSB (DPP) function; and c) All TOE are sharing the same firmware and significant similarities in the hardware designs. The development and production processes of the different models are identical. 2) The rationale provided in Section 9. 3) The following table provides a list of the TOE used for testing and the models they represent from the embedded document: Table 4: Tested TOE Test Case Product model TOE Type Represented models Test E SM40NU-3 Secure KM Switch SM20N-3, SM40N-3, SM40NU-3, SM80N-3, SM80NU-3 Assurance Activity Report v1.0 Page 8 HSL Secure KM Switch Switch 3 Evaluation HSL Secure KM Switch is the Target of Evaluation (TOE) under the Standard Protection Profile for Peripheral Sharing Switches, version 3.0. 3.1 Techniques, Tools and Standards The standards used in the conduct of this evaluation:     Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model September 2012 Version 3.1 Revision 4 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components September 2012 Version 3.1 Revision 4 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components September 2012 Version 3.1 Revision 4 Common Methodology for Information Technology Security Evaluation methodology September 2012 Version 3.1 Revision 4 Test tools used in the independent testing are: The evaluators used general purpose Intel/Windows computers and the following software tools: 1) List off all software tools and hardware tools and their versions as follows: • Computer #1 – Asus M52BC-US003S Running Windows 7 Ultimate 64 Bit, Service pack 1 S/N E8PDCG00123C • Computer #2 – Asus M52BC-US003S Running Windows 7 Ultimate 64 Bit, Service pack 1 S/N E8PDCG00122D • Computer #3 – Asus M52BC-US003S Running Windows 7 Ultimate 64 Bit, Service pack 1 S/N E8PDCG00124S • Computer #4 – Asus M52BC-US003S Running Windows 7 Ultimate 64 Bit, Service pack 1 S/N E8PDCG00125C • Oscilloscope – Agilent Technologies DSO3102A Digital Storage Oscilloscope, S/N CN47423598 • Lab power supply – Siglent SPD3303D Programmable power supply, S/N SPD30CE1150090. • Display #1 – Asus PA248Q, S/N EBLMQS082778 • Display #2 – Asus PA248Q, S/N EBLMQS082775 • Display #3 – Asus PA248Q, S/N EBLMQS082767 • Display #4 – Asus PA248Q, S/N EBLMQS082736 • Signal Generator – Rigol DG1022A 2 Channel 25MHz Function / Arbitrary Waveform Generator, S/N DG1F134700206 Assurance Activity Report v1.0 Page 9 HSL Secure KM Switch Switch • DVM – Fluke 117 True RMS Multi-meter, S/N 30390050WS • USB Sniffer – Teledyne Lecroy USB-TMS2-M01-X Mercury T2, S/N 13788 • USB Load – HSL custom built accessory, S/N 972002 • USB Traffic generator – HSL custom built, S/N 972001 • Mass storage devices – Sandisk Cruzer Blade 8GB SDCZS0-008G • USB Printer – HP Deskjet 1513 C5X25A • USB Keyboards – Asus G01 KB • USB Mouse – Asus 0K1000 • PS/2 Keyboard – Rosenwill RK-200 • Amplified speakers – CA Audio CA-3602 • USB Headset – Koss SB/45 • USB Camera – Logitech Webcam C110 • USB Smart-card reader – Belkin F1DN005U • Microphone – Connectland Microphone Sur Pied M1810 • Analog Headset – Koss CS100 – 32 Ohm Stereo headset • MCCS Console – SoftMCCS Ver. 2.5.0.1034 • USB Analyzer software – USBLyzer Ver. 21. • Keyboard emulator software - PassMark KeyboardTest™ version 3.0 • Tone Generator software – Tone Generator 100Hz – 15 KHz Ver. 1.04 • Athena smart-card • Athena IDProtect Manager Tool Version 6.20.08 • Atmel Evaluation Board EVK1100 + AVR Studio 6 suite 3.2 Test Configuration 3.2.1 Test Setup E (4P KM)           1 x HSL SM40NU-3 Secure 4-Port KM (P/N: CGA10142); 1 x AC Power cable; 1 x Wall mounted power supply (P/N: CPS05296); 8 x HSL DPP USB Cable (P/N: CPN05487); 1 x USB Mouse; 1 x USB Keyboard; 1 x Qualified USB smart-card reader; 4 x PC’s installed with Microsoft Windows 7, Windows 8 or Linux; 2 x Displays; 1 x Headsets; and Assurance Activity Report v1.0 Page 10 HSL Secure KM Switch Switch ● ● 4.11 ● ● ● ● ● 4.8 ● 4.10 Page 11 Assurance Activity Report v1.0 ● ● ● ● ● ● ● ● 4.6 ● ● ● ● ● ● 4.4 ● ● ● ● ● ● ● ● ● ● 4.5 Armed TOE sample with open enclosure Oscilloscope USB Composite device evaluation board USB Camera USB Printer Audio signal generator EDID reading and parsing software DisplayPort source device MCCS control console software application Display having DP 1.2 interface DisplayPort AUX channel analyzer Dynamic headphones Digital Voltmeter Open 3.5 mm stereo plug Computer microphone (analog) USB Generator Keyboard emulator software application Tone generator software application Amplified speakers USB Type B plug Power supply with current limit USB Overload plug USB Hub USB Audio device USB storage device USB protocol analyzer software USB protocol analyzer device (sniffer) Test Case From PP Additional test equipment per table 5 below.  Note that the TOE used in all tests except for physical attack tests should be in the following initial state:  Anti-tampering system is activated and armed.  Device is new. Table 5: Additional equipment needed for some Test Cases 4.1 4.2 ● ● ● ● ● ● ● ● ● ● 4.3 ● ● ● ● ● ● ● ● ● ● 4.7 4.9 4.12 4.13 ● 4.14 HSL Secure KM Switch Switch 3.3 Test Configuration Diagram The following figures are test configurations examples Sample 4 port KM switch with 4 monitors connected directly to computers Note: This is a basic configuration for testing the 4 – port KM. Not all peripherals are connected to the TOE at all times. Displays are connected directly to their PC in KM systems. Assurance Activity Report v1.0 Page 12 HSL Secure KM Switch Switch 4 4.1 Assurance Activities for PSS PP FDP_IFC.1 (1) Subset information flow control FDP_IFC.1.1 (1) The TSF shall enforce the [User Data Protection SFP] on [Subjects: TOE computer interfaces, TOE peripheral device interfaces Information: User data transiting the TOE Operations: Data flow between subjects]. Assurance Activity Assurance Activities for this SFR were integrated with the Data Isolation Requirements SFR below. TSS Verification Verify that the ST identifies subjects, information, and operations identified in the SFR. CSC: It is stated in Section 7.1, in the first bulleted list, Bullet A identifies the keyboard and mouse USB device emulators as the peripheral interfaces. The computer interfaces are identified in Bullet C as host (computer) emulators. The bulleted list also discusses the rules for data transiting the TOE between the mouse and keyboard emulators and the computer interfaces (host emulators). Operational Guidance Verification CSC: Operational Guidance analysis was conducted in the Data Isolation Requirements SFR below as required by the Assurance Activity. Testing Summary CSC: Testing was conducted in the Data Isolation Requirements SFR below as required by the Assurance Activity. Assurance Activity Report v1.0 Page 13 HSL Secure KM Switch Switch 4.2 FDP_IFF.1 (1) Simple security attributes Security Target FDP_IFF.1.1 (1) The TSF shall enforce the [User Data Protection SFP] based on the following types of subject and information security attributes: [Subject: TOE computer interfaces Subject security attributes: user selected computer interface Subject: TOE peripheral device interfaces Subject security attributes: none Information: User data transiting the TOE Information security attributes: none]. FDP_IFF.1.2(1) The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [The user makes a selection to establish a data flow connection between the peripheral device interfaces and one computer interface based on the following rules: 1) The attribute User Selected Computer determines the operation Allowed Data Flow such that the only permitted data flows are as listed in the table below: Value of User Selected Computer Allowed Data Flow n This ST will claim the following data-flow claims based on applicable TOE groups: [Selection] a) User keyboard peripheral device interface data flowing from peripheral device interface to computer interface #n; b) User mouse peripheral device interface data flowing from peripheral device interface to computer interface #n; c) User authentication peripheral device data flowing bidirectional between computer interface #n and user authentication device peripheral interface; and d) Analog audio output data flowing from computer interface #n to the audio peripheral device interface; 2) When the user changes the attribute by selecting a different computer, this causes the TOE to change the data flow accordingly. Assurance Activity Report v1.0 Page 14 HSL Secure KM Switch Switch FDP_IFF.1.3 (1) 3) The specific TOE implementation may allow splitting of the user control to different shared peripheral groups. For example, the user authentication device selected computer may be #2, while the keyboard and mouse selected computer device may be #1. In this case, each selection shall be clearly indicated. 4) The TOE may support multiple instances of the peripheral devices shown in the table above, or a subset of these peripheral devices.] The TSF shall enforce the [the following additional information flow control SFP rules if the TOE supports user authentication devices [Selection]: 1) following an event of the user changing the attribute by selecting a different computer, the TOE must reset the power to the connected user authentication device. FDP_IFF.1.4 (1) The TSF shall explicitly authorize an information flow based on the following rules: [no additional rules]. FDP_IFF.1.5 (1) The TSF shall explicitly deny an information flow based on the following rules: 1) [The TSF shall deny any information flow between TOE peripheral device interfaces and TOE non-selected computer interfaces. 2) The TSF shall deny any data flow between an external entity and the TOE computer interfaces. 3) The TSF shall deny any user data flow between the TOE and an external entity]. Assurance Activity Assurance Activities for this SFR were integrated with the Data Isolation Requirements SFR below. TSS Verification Verify that the ST discusses the information flow control rules discussed in the SFR. CSC: The following table identifies for each switch in the evaluation per Section 1.3.2.1 of the Security Target meets at least one selection from FDP_IFF.1.2 (1). Where a column contains a checkmark indicates the switch meets the selection. Table 6: FDP_IFF.1.2 (1) flows per TOE N o Model Description Selection # from FDP_IFF.1.2 (1) a 1) SM20N-3 HSL Secure SH KM 2-Port, No video, PP 3.0 Assurance Activity Report v1.0 b X c X d e X Page 15 HSL Secure KM Switch Switch 2) SM40N-3 HSL Secure SH KM Switch 4-Port No video, PP 3.0 X X 3) SM40NU -3 HSL Secure SH KM Switch 4-Port No video, w/fUSB, PP 3.0 X X 4) SM80N-3 HSL Secure SH KM Switch 8-port, PP 3.0 X X 5) SM80NU -3 HSL Secure SH KM Switch 8-port w/fUSB, PP 3.0 X X X X X X X X Operational Guidance Verification CSC: Operational Guidance analysis was conducted in the Data Isolation Requirements SFR below as required by the Assurance Activity. Testing Summary CSC: Testing was conducted in the Data Isolation Requirements SFR below as required by the Assurance Activity. Assurance Activity Report v1.0 Page 16 HSL Secure KM Switch Switch 4.3 FDP_IFC.1 (2) Subset information flow control Security Target FDP_IFC.1.1 (2) The TSF shall enforce the [Data Isolation SFP] on [Subjects: TOE computer interfaces, TOE peripheral interfaces Information: data transiting the TOE Operations: data flows between computer interfaces]. Assurance Activity This Assurance Activity is combined with FDP_IFF.1 (2). 4.4 FDP_IFF.1 (2) Simple security attributes Security Target FDP_IFF.1.1 (2) The TSF shall enforce the [Data Isolation SFP] based on the following types of subject and information security attributes: [Subject: TOE interfaces Subject security attributes: Interface types (Allowed TOE interface types are listed in Annex C of this PP. Power source and connected computer interfaces are also applicable interface types.) Subject: TOE peripheral device interfaces Subject security attributes: none Information: data transiting the TOE Information security attributes: data types. (The TSF will enforce the data isolation SFP on the following data types: a. User keyboard key codes; b. User pointing device commands; c. Video information (User display video data and display management data); d. Audio output data; and e. User authentication device data.)]. FDP_IFF.1.2 (2) The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: 1) [During normal TOE operation, the TSF shall permit only user entered keyboard key codes, and user input mouse commands to flow between the TOE keyboard and mouse peripheral device interfaces and the TOE selected computer interface. No flow is permitted between the selected computer interface and the TOE keyboard and Assurance Activity Report v1.0 Page 17 HSL Secure KM Switch Switch mouse peripheral device interfaces. 2) The TSF shall permit information flow and TSF resources sharing between two TOE user peripheral interfaces of the same Shared Peripheral group. Both functions may share the same interface]. FDP_IFF.1.3 (2) The TSF shall enforce the [No additional rules]. FDP_IFF.1.4 (2) The TSF shall explicitly authorize an information flow based on the following rules: [No additional rules]. FDP_IFF.1.5 (2) The TSF shall explicitly deny an information flow based on the following rules: [1. The TSF will deny any information flow between TOE Computer Interfaces, except those allowed by the User Data Flow rules; 2. The TSF will deny data flow other than keyboard entries and mouse reports between the TOE keyboard and mouse peripheral device interfaces and the TOE selected computer interface; 3. The TSF will deny power flow between the selected computer interface and TOE keyboard and mouse peripheral device interfaces; 4. The TSF will deny information flow from the TOE selected computer interface to the TOE keyboard and mouse peripheral device interface; 5. The TSF will deny data flow of user authentication device data transiting the TOE to non-selected TOE computer interfaces; 6. The TSF will assure that the user authentication device computer interfaces are not shared with any other TOE peripheral function interface (keyboard, mouse etc.); 7. The TSF will deny information flow between two TOE user peripheral interfaces in different Shared Peripheral groups; 8. The TSF will deny analog audio information flow between the TOE selected computer audio interface and the user audio device peripheral interface when a microphone peripheral device is intentionally or unintentionally connected to the TOE audio peripheral device interface; 9. The TSF will enforce unidirectional information flow between the TOE selected computer audio interface and the user audio device peripheral interface. Bidirectional information flow shall be denied; 13. The TSF will recognize and enable only those peripherals with an authorized interface type as defined in Annex C of this PP. Information flow to all other peripherals will be denied; and Assurance Activity Report v1.0 Page 18 HSL Secure KM Switch Switch 14. All denied information flows will also be denied when the TOE’s power source is removed] Assurance Activity TSS The evaluator shall verify that the TOE Summary Specification (TSS) describes all of the interfaces supported in each port group. Any options to switch peripherals independently from the keyboard and mouse must be described. The evaluator shall also verify that the TSS lists and describes all TOE control options. To improve USB data analysis, prior to the following tests, the evaluator shall receive a full list of all USB endpoints used by the TOE, and their specific functions. The evaluator shall verify that the TSS describes all of the external interfaces supported by the TOE and that there are no external interfaces other than computer interfaces, power interfaces and peripheral device interfaces. Any wireless or wired interface must be fully described with its intended function. The evaluator shall verify that the TSS describes all of the interfaces supported in each port group. Any options to switch peripherals independently from the keyboard and mouse must be described. The evaluator shall examine the TSS and verify that for any human interface device that may be switched independently from the keyboard and mouse, there is a description that explains how this interface is isolated from all other device interfaces. The evaluator shall be able to determine from this description that there are no shared components, shared lines or shared power supplies. The evaluator shall verify that the TSS provides details about supported user authentication devices. TSS shall also indicate whether the user authentication device is emulated by the TOE or switched. The evaluator shall examine the TSS to verify that it describes how the user authentication data path is isolated from all other data paths. This section must indicate that the data path used by the user authentication device is not shared with other transiting data. This section must also describe how the USB port for the user authentication device is powered separately from other peripheral device functions. If the TOE includes an integrated user authentication device, the evaluator shall examine the TSS to verify that is describes: 1) How the user authentication data path is isolated from all other data paths; 2) If the user authentication device is emulated by the PSS or not; 3) If the user authentication device is emulated, then the TSS shall include detailed information describing authentication session termination by the user, and describe how this occurs simultaneously in all connected computers. [Conditional – not applicable] If the TOE supports DisplayPort video – Assurance Activity Report v1.0 Page 19 HSL Secure KM Switch Switch The evaluator shall verify that the TSS describes how the TOE video auxiliary channel (AUX) path blocks information flows other than the minimal set required to establish the video link. The description should discuss the method implemented to prevent unauthorized DisplayPort transactions:  The TOE prevents the DisplayPort AUX channel link from reaching speeds higher than 1 megabits per second (DisplayPort ver 1.2 or higher) while blocking MCCS transactions; or  The TOE disassembles the DisplayPort AUX channel transactions to block all unauthorized transactions. Guidance The evaluator shall verify that the operational guidance provides clear direction for the connection of computers and peripheral devices to the TOE. Any options to switch peripheral devices independently from the keyboard and mouse must be described, including a description of how this switching is indicated on the PSS. The evaluator shall verify that the operational guidance provides clear direction for the usage and connection of TOE interfaces. General information may be provided for computer, power and peripheral devices. Any wireless or wired interface that receives or transmits data to or from the TOE must be described in sufficient detail to allow the evaluator to determine if there is a risk that these interfaces could be misused to import or export user data. The evaluator shall examine the user guidance and verify that the guidance provides users with information on how to recognize a device where the anti-tampering functionality has been activated. The evaluator shall review the following subjects in the user and administrative guidance to verify that there are no processes or settings that may allow any forbidden data flow between objects: a) Installation options; b) TOE configurations: c) TOE firmware options; or d) Accessories supplied with TOE The evaluator shall verify that any cables or accessories supplied with the TOE (as described in the guidance) do not support computer interface types in the following prohibited protocols list: a) Microphone audio input; b) Line in audio input; c) DockPort; d) USB docking; e) Thunderbolt; or f) Other docking protocols. Assurance Activity Report v1.0 Page 20 HSL Secure KM Switch Switch The evaluator shall verify that the supported peripheral devices and protocols match the information in Annex C of this PP. The evaluator shall examine the TOE user guidance to determine if there are any operating modes that allow peripheral devices to be switched independently from the keyboard and mouse. All such operating modes must be covered in the TSS. The evaluator shall examine the TOE guidance and verify that the TOE does not support microphone or audio line input device interfaces. The evaluator shall also examine the TOE guidance and verify that it includes an explicit warning not to use microphone, line input or headset devices with the TOE. Tests 1) Since a PSS typically has a large set of switched peripheral devices and connected computers, in order to prevent duplication of test setup and testing effort, several tests were grouped into larger test sets. The selection of the appropriate test set is based on the specific TOE implementation, which is based on the type of peripheral devices being supported. 2) Each port group switch selection must be tested for each device; however, not all port groups must be connected simultaneously. For example, if testing a 16-port device, the evaluator may use four connected computers, but must change the connected ports several times to ensure all computer port group connections and switch selections are tested. Likewise, a single USB protocol analyzer may be used, but must be moved to test each applicable port. Several of the tests are written assuming a 4 port device. Each test must be adapted to accommodate all of the ports on each tested TOE. 3) The tests assume the use of Windows on each connected computer. It is permissible to perform the tests using Linux based connected machines with similar applications installed. 4) The evaluator is expected to prepare an image or bitmap with an easily visible number to be used as a background for each connected computer in order to identify each channel (e.g., a white background with the number 1 may serve as a desktop background for computer #1.) 5) Note that some of the following tests require knowledge of the USB protocol to properly configure and operate a USB protocol analyzer and USB sniffer. Evaluation Note: The actual tests in the Protection Profile Sections 4.2.10 – 4.2.20 were not reproduced for brevity. In the actual tests for this SFR, the test steps are reproduced from the PP. TSS Verification The evaluator shall verify that the TOE Summary Specification (TSS) describes all of the interfaces supported in each port group. Any options to switch peripherals independently from the keyboard and mouse must be described. Assurance Activity Report v1.0 Page 21 HSL Secure KM Switch Switch CSC: Tables 4 and 5 of the ST describes the protocols supported for each of the switches for each of the computer ports. For example, the first switch, SM20N-3, supports USB 1.1/2.0 console keyboard and mouse, and analog audio. The evaluator shall also verify that the TSS lists and describes all TOE control options. CSC: Table 4 identifies specifically, per switch, what is supported by the console port group. The keyboard, mouse, and audio peripherals are identified for each switch. To improve USB data analysis, prior to the following tests, the evaluator shall receive a full list of all USB endpoints used by the TOE, and their specific functions. The evaluator shall verify that the TSS describes all of the external interfaces supported by the TOE and that there are no external interfaces other than computer interfaces, power interfaces and peripheral device interfaces. Any wireless or wired interface must be fully described with its intended function. CSC: Tables 4 and 5 details what interfaces and protocols are supported for each switch for the computer ports and the console ports. Table 3 of the ST list the peripheral devices supported by the TOE. The evaluator received a full list of all USB endpoints used by the TOE – an empty list. No internal hub or endpoints listed in that list. The application note for FDP_IFF.1.1(2) also states the interfaces not supported including Microphone audio input, DockPort, USB Docking, Thunderbolt, and other docking protocols. The evaluator shall verify that the TSS describes all of the interfaces supported in each port group. CSC: Tables 4 and 5 details what interfaces and protocols are supported for each switch for the computer ports and the console ports. Any options to switch peripherals independently from the keyboard and mouse must be described. CSC: There are no options to switch peripherals independently from the keyboard and mouse. Each peripheral group is powered by the connected group computer and sits behind a one way data diode. When a computer is selected, all peripherals in that group are selected. See Section 7.1 of the ST. The evaluator shall examine the TSS and verify that for any human interface device that may be switched independently from the keyboard and mouse, there is a description that explains how this interface is isolated from all other device interfaces. CSC: There is no option to switch other devices independently from the keyboard and mouse. The evaluator shall be able to determine from this description that there are no shared components, shared lines or shared power supplies. CSC: Section 7.1 describe the isolation requirements behind emulators (which are microcontrollers for each port group) to prevent peripherals from having direct Assurance Activity Report v1.0 Page 22 HSL Secure KM Switch Switch access to computer ports. Each device emulator is powered by its own connected computer. Power domains of different computer interfaces are completely independent and isolated behind unidirectional data diodes. The evaluator shall verify that the TSS provides details about supported user authentication devices. TSS shall also indicate whether the user authentication device is emulated by the TOE or switched. CSC: Section 7.4, states the details about supported user authentication devices, “Standard smart-card reader USB token or biometric authentication device having USB smart-card class interface complying with USB Organization standard CCID Revision 1.1 or ICCID Revision 1.0.” Table 7 of this document identifies the TOE having this function. Section 7.4, the DPP function, bullet e states, “The TOE does not emulate or process user authentication device data. No data retention is possible.” The evaluator shall examine the TSS to verify that it describes how the user authentication data path is isolated from all other data paths. This section must indicate that the data path used by the user authentication device is not shared with other transiting data. This section must also describe how the USB port for the user authentication device is powered separately from other peripheral device functions. CSC: Section 7.4, bullets a and b describe each (dedicated peripheral port) DPP computer interface as using independent circuitry and power planes. There is no shared circuitry or logical functions with other ports or other TOE functions. The user authentication device data paths in the TOE are fully isolated from all other user data paths and functions. If the TOE includes an integrated user authentication device, the evaluator shall examine the TSS to verify that is describes: 1) How the user authentication data path is isolated from all other data paths; 2) If the user authentication device is emulated by the PSS or not; 3) If the user authentication device is emulated, then the TSS shall include detailed information describing authentication session termination by the user, and describe how this occurs simultaneously in all connected computers. CSC: None of the evaluated switches have integrated user authentication device functionality. [Conditional – not applicable for KM TOE] If the TOE supports DisplayPort video The evaluator shall verify that the TSS describes how the TOE video auxiliary channel (AUX) path blocks information flows other than the minimal set required to establish the video link. The description should discuss the method implemented to prevent unauthorized DisplayPort transactions:  The TOE prevents the DisplayPort AUX channel link from reaching speeds higher than 1 megabits per second (DisplayPort ver 1.2 or higher) while blocking MCCS transactions; or Assurance Activity Report v1.0 Page 23 HSL Secure KM Switch Switch  The TOE disassembles the DisplayPort AUX channel transactions to block all unauthorized transactions. CSC: None of the KM switches support video. Operational Guidance Verification The evaluator shall verify that the operational guidance provides clear direction for the connection of computers and peripheral devices to the TOE. Any options to switch peripheral devices independently from the keyboard and mouse must be described, including a description of how this switching is indicated on the PSS. CSC: The User Guidance provides clear direction for the connection of computer and peripheral devices to the TOE through installation guides, precautions, and pictures. It is also stated, “Product design achieves maximal security by keeping the video path separate with keyboard and mouse switched together, purging keyboard buffer when switching channels.” The evaluator shall verify that the operational guidance provides clear direction for the usage and connection of TOE interfaces. General information may be provided for computer, power and peripheral devices. CSC: Throughout each User Guidance there are Installation guides, Operational guides and pictures to describe a clear direction for the usage and connection of all TOE interfaces. Any wireless or wired interface that receives or transmits data to or from the TOE must be described in sufficient detail to allow the evaluator to determine if there is a risk that these interfaces could be misused to import or export user data. CSC: Each User Guidance Manual has warnings and precautions stating, “For security reasons products do not support wireless keyboards and mice. In any case do not connect wireless keyboard/mouse to product.” Table 7: Referenced documents Document Reference (see document references in Section 2.1) [C] Risk factor for wireless or wired interface Page 6 The evaluator shall examine the user guidance and verify that the guidance provides users with information on how to recognize a device where the anti-tampering functionality has been activated. CSC: It is stated in the “User Guidance & Precautions,” the product is equipped with an always-on active anti-tampering system. In addition, “Any attempt to open product enclosure will activate the anti-tamper system indicated by all channel-select LEDs flashing continuously.” Assurance Activity Report v1.0 Page 24 HSL Secure KM Switch Switch Table 8: Referenced documents Document Reference Anti-tampering activation (see document references in Section 2.1) [C] Page 6, bullet 6 The evaluator shall review the following subjects in the user and administrative guidance to verify that there are no processes or settings that may allow any forbidden data flow between objects: a) Installation options; b) TOE configurations: c) TOE firmware options; or d) Accessories supplied with TOE CSC: The User Manuals only show how to install and operate the product, there are no processes or settings allowing any forbidden data flow. All User manuals were examined in their entirety. The evaluator shall verify that any cables or accessories supplied with the TOE (as described in the guidance) do not support computer interface types in the following prohibited protocols list: a) Microphone audio input; b) Line in audio input; c) DockPort; d) USB docking; e) Thunderbolt; or f) Other docking protocols. CSC: The User Guidance Manuals have a section showing the products package contents. The Contents included do not support computer interface types in the prohibited protocols list above. The Guidance Manuals also specifically state “For security reasons products do not support microphone/line-in audio input.” Table 9: Referenced documents Document Reference Package Contents (see document references in Section 2.1) [C] Page 3 Microphone/line-in audio input Page 6, bullet 5 The evaluator shall verify that the supported peripheral devices and protocols match the information in Annex C of this PP. The TOE supports keyboard / mouse Assurance Activity Report v1.0 Page 25 HSL Secure KM Switch Switch The evaluator shall examine the TOE user guidance to determine if there are any operating modes that allow peripheral devices to be switched independently from the keyboard and mouse. CSC: There are no options to switches peripherals independently from the keyboard and mouse. All such operating modes must be covered in the TSS. CSC: Per the ST, there are no options to switches peripherals independently from the keyboard and mouse. The evaluator shall examine the TOE guidance and verify that the TOE does not support microphone or audio line input device interfaces. CSC: Per the ST, for security reasons products do not support microphone/line-in audio input. Table 10: Referenced documents Document Reference (see document Section 2.1) references [C] Microphone/Line-in Audio Support in Page 6, bullet 5 The evaluator shall also examine the TOE guidance and verify that it includes an explicit warning not to use microphone, line input or headset devices with the TOE. CSC: Explicit warning found in all TOE guidance at the same locations indicated in table 10 above. Text appearing in that bullet is, “For security reasons product do not support microphone/line-in audio input. In any case do not connect a microphone to product audio output port, including headsets. Assurance Activity Report v1.0 Page 26 HSL Secure KM Switch Switch Testing Summary Table 11: Applicable test setups Test Setup HSL Model Number TOE Type E SM40NU-3 Secure KM Switch Assurance Activity Testing Summary Test 4.1 – User Control This test is mandatory for all TOEs claiming compliance to this PP. General test setup from the PP, section 4.2.9, was followed to ensure the tests themselves would be run according to the established procedures. Section 4.2.10 of the PP were followed as prescribed, results are captured below in the section marked “Actual Tests”. The following chart indicates which models were tested by the evaluator: Test Setup Part E Test 4.1 – User Control - ● Notes / Justification: Section 3.2 above identifies those additional items required to have the TOE in an operational condition; those items were used for these tests. The switch tested did not fail any portion of the required steps set forth in the PP. “Test E” several channel switching methods tested: front panel push buttons were used; Cursor tracking method also used. The front panel and the TOE does not allow for nonauthorized methods to be enabled through any configuration. The TOE does not support a computer port scanning mode which was verified through the UG. When depressing more than one front panel button at a time the TOE reverts back to the last correctly depressed selection. Additionally, Microsoft’s “Notepad” was opened on each of the connected PCs. As characters were typed in one pc the front panel was used to select a different pc where it was noted that the letters typed on the previous PC did not carry over to the newly selected PC. The pictures presented above were consistent with the findings. Test 4.2 – Keyboard Switching, Data Isolation and Device Qualification Rules General test setup from the PP, section 4.2.9, was followed to ensure the tests themselves would be run according to the established procedures. Section 4.2.10 of the PP were followed as prescribed, results are captured below in the section marked “Actual Tests”. The following chart indicates which models were tested by the evaluator: Test Setup Test 4.2 – Keyboard Switching, Data Isolation and Device Qualification Rules Assurance Activity Report v1.0 Part E 1 2 3 4 5 ● ● ● ● ● Page 27 HSL Secure KM Switch Switch The USBLyzer software was setup and testing began. All PCs were loaded and correctly configured with the USB protocol analyzer software. For Part 1 the evaluator setup the required number of computers for each TOE. All PCs used Microsoft Operating System Windows 7 and the application Notepad was used to enter text at each PC. All tests on all TOEs resulted in positive results. No TOE tested failed any of the required tests set forth in the PP. Part 2, Steps 16 thru 24 of the PP, was conducted without incident. USB devices that were not a keyboard were rejected and not enumerated. This was verified through the use of the USB protocol analyzer and through Device Manager of Windows 7. This process was repeated through a USB hub to verify the TOE recognized the keyboard through a USB hub yet rejected non-keyboard USB devices. Part3, steps 25 thru 35d of the PP, ensured the keyboard flow isolation and unidirectional rule was compliant in the TOEs tested. Tools such as Passmark keyboard emulation was used as instructed in the PP. No test of any TOE resulted in a failure. Part 4, steps 36 – 40, ensured the TOEs tested properly disabled unauthorized USB devices connected directly to the TOE or through a USB hub. All USB devices required by the PP were connected resulting in the TOE disabling those devices. Assurance Activity Report v1.0 Page 28 HSL Secure KM Switch Switch Pert 5, steps 41 – 43 of the PP, the tests conducted were an attempt to change ports of the TOE through a combination of key sequences. All TOEs tested did not allow switching of ports/channels through key sequences. Test 4.3 – Mouse Switching, Data Isolation and Device Qualification Rules Test setup procedures described in section 4.2.12 of the PP were followed prior to test initiation. Those section in the below table that are grayed out were not tested for those parts. Test Setup Test 4.3 - Mouse Switching, Data Isolation and Device Qualification Rules Part E 1 2 3 4 5 ● ● ● ● ● All results of the required tests were successful. A capture example of part 1: Test 4.3 step 8 – No new traffic captured in the non-selected computer, cursor remains static. Part 2, steps 16 thru 24 of the PP, demonstrated mouse movement on the selected PC not being replicated on a second non-selected PC. A USB analyzer was used to confirm data between the chosen system and the device was the only allowed data to pass. All steps were performed and results were as expected. Part 3, steps 25 thru 35 of the PP, required the use of a gaming mouse with programmable LEDs. Assurance Activity Report v1.0 Page 29 HSL Secure KM Switch Switch Results were as expected MS Windows Device Manager was used to confirm devices were not enumerated that were HIDs. Part 4, steps 36 thru 40 of the PP, correctly disabled USB devices that were not authorized and were verified through the use of a protocol analyzer. The switch tested resulted in a negative result. Part 5, steps 41 thru 43 of the PP, mouse data flow was isolated to only the chosen PC. This was verified through the use of a USB protocol analyzer. Overall no negative results were experienced and the switches functioned as expected. Test 4.4 – Display Switching, Data Isolation and Unidirectional Flow Rules Test setup procedures described in section 4.2.13 of the PP were followed prior to test initiation. Test Setup Test 4.4 - Display Switching, Data Isolation and Unidirectional Flow Rules Part E 1 2 3 Parts, 2 and 3 of test 4.4 are not applicable for KM as it does not support display. Test 4.5 –User Authentication Device Switching and Isolation Rules Test setup procedures described in section 4.2.14 of the PP were followed prior to test initiation. Test Setup Part E 1 ● 2 Test 4.5 – User Authentication Device Switching and Isolation Rules 3 ● 4 ● 5 ● Part 1, steps 6 thru 15 of the PP, tests the TOE to ensure only the selected computer recognizes the user authentication device and properly populates its use to that chosen PC. The images resulting from testing show the TOE is recognized by device manager and the results are as expected. Assurance Activity Report v1.0 Page 30 HSL Secure KM Switch Switch Card Reader populated to device manager (Step 8) Step 9 – not visible on PC -2 Step 10 – USB analyzer does not detect traffic on PC – 2 Part 2, steps 16 – 31 of the PP, verify that user authentication using the TOE on the chosen PC does not replicate authentication on the remaining PCs. Very easy test to run and check. Picture shows Step 18 shows use of software supplied with was also used to verify the selected PC recognized the TOE and validated there was a CAC correctly inserted. All steps were successfully accomplished verifying the TOEs tested complied with the PP. Part 3, steps 32 – 39 of the PP, ensures that the process of user authentication for one selected computer does not generate USB traffic on the other USB interfaces of the same computer. This is verified through physical inspection of the TOE as well as the User Guide for each supported model of the TOEs tested. Part, 4 steps 40 thru 41 of the PP, ensured that the TOE properly handled qualified and nonqualified devices connected to the user authentication device port. Assurance Activity Report v1.0 Page 31 HSL Secure KM Switch Switch Picture indicates USB analyzer with audio device connected. A total of seven USB devices, as identified in the PP, were tested with expected results. Part 5, steps 42 thru 52 of the PP, the evaluator verified that the TOEs tested properly handled qualified and non-qualified devices connected to the user authentication device port after proper configuration. Six USB devices were used as indicated in the PP resulting in the correct expected response. The image below is an example of the conversation captured, the USB sniffer captured the enumeration and then reset and long idle. All testes for this section resulted in the correct expectation. No TOE failed at any point in the tests required by the PP. Test 4.6 – Analog Audio Output Switching, Isolation and data-flow Rule The following steps evaluate TOE compliance with the allowed data flow as it is applied to the analog audio output. Note that all KM TOE supports audio devices. Test setup procedures described in section 4.2.15 of the PP were followed prior to test initiation. The evaluator confirmed that an analog audio signal traversing the TOE from one userselected connected computer does not leak to the non-selected computers’ analog audio interfaces. Similarly, the evaluator verified that there is no significant leakage across the non-selected computers. Test Setup Test 4.6 – Analog Audio Output Switching, Isolation and data-flow Rule Part E - ● For this test a programmable tone generator (Step 19) was used to test at the required frequencies (image below) All steps in the test were straight forward, generate tone on selected TOE channel then change to PC without tone to check if you can hear the tone generated on from the previous selected PC. Assurance Activity Report v1.0 Page 32 HSL Secure KM Switch Switch A sample of the oscilloscope analysis at 1 Hz: The image depicts 1 Hz injected signal not visible in the noise background. Noise and signal totals 32 mVpp. Part 2 of the test, steps 30-49 of the PP, required the evaluator to verify that the TOE analog audio functions: - Are unidirectional (computer interface to peripheral device data flow only); - Will reject a microphone if connected to the audio peripheral interface port; and - Will attenuate the audio signal from a connected headset to a level that would not enable audio eavesdropping. All steps were followed implicitly resulting in the expected findings. The switch did tested did not fail any portion of the required test procedures. Test 4.7 – No Other External Interfaces In the following test, the evaluator shall examine the TOE external interfaces to assure that only the interfaces (connectors) allowed by this PP are available. There are no external wired interfaces other than: a) Computer interfaces; b) Peripheral device interfaces; and c) Power interfaces Test 4.8 – No Flow between Computer Interfaces (USB-to-USB, Power-to-USB) In this test, the evaluator shall confirm that the following types of events in one TOE computer interface do not have any effect on any other TOE computer interface: Test setup procedures described in section 4.2.17 of the PP were followed prior to test initiation.  Test Setup Test 4.7 – No Other External Interface Part E - ● None of the TOEs submitted for CC consideration support wireless interfaces. Radiated emission tests were conducted by the Israel Testing Laboratories was provided establishing that no emissions emitted from any of the tested products. This satisfies the second step of the test. Test Setup Test 4.8 – No Flow between Computer Interfaces (USB-to-USB, Power-to-USB) Part E - ● The evaluator connected a USB protocol analyzer between PC-2 and the TOE, and reboot PC-1. Was any USB traffic captured on PC-2 pertaining to PC-1? The only movement on the non-rebooted machines was the conversation of the protocol analyzer communicating with the new (changed to PC) USB connection. A USB overload device was created using the process described in the PP Annex. The following screen capture is indicative of the results for each of the sequences followed in the PP: Computer reboot or Assurance Activity Report v1.0 Page 33 HSL Secure KM Switch Switch power off; Normal USB traffic flowing to the selected computer; Enumeratio n of various USB devices on non-selected computer interfaces; Peripheral device overcurrent event effect on nonselected computers; and USB power signaling effect between computer interfaces.     Test 4.9 – No Flow between Computer Interfaces with TOE Powered Off (USB-toUSB, Power-toUSB) In this test, the evaluator shall confirm that the following types of events in one computer interface do not have any effect on any other computer interface while the TOE is powered off:  Computer reboot or power off; and  USB power All TOEs tested resulted in the expected findings. No TOE failed any part of the tests. Test setup procedures described in section 4.2.18 of the PP were followed prior to test initiation. Test Setup Test 4.9 – No Flow between Computer Interfaces with TOE Powered Off (USB-toUSB, Power-to-USB) Part E - ● An external power supply was required for this test. The switch tested performed as expected. The TOE power off / power on process did not allow ANY USB traffic through itself. Image below is of step 4: Turn off the TOE and observe TOE enumeration data flow on all connected computers. Assurance Activity Report v1.0 Page 34 HSL Secure KM Switch Switch signaling effect between computer interfaces. It should be noted that although the TOE is powered off, some components of the TOE may still be powered from the connected computers. Test 4.10 – No Flow between Computer Interfaces (Power-/ USB to-Audio) Test 4.11 – Peripheral to Peripheral Interface Rule In this test, the evaluator shall verify that the TOE implementation properly isolates the peripheral device interfaces that are not switched together. Note that the following test assumes that the USB keyboard and mouse combination and the USB user authentication device are independently switched. The test may be modified to support different Test Setup Test 4.10 – No Flow between Computer Interfaces (Power-/ USB-to-Audio) Part E - ● The evaluator verified that power events at one TOE USB computer interface did not affect the analog audio output computer interface of another computer. The four TOEs identified in the table above did not result in any negative findings. The steps provided in the PP were easily followed. No special equipment was required. No special test setup was required for 4.2.20 of the PP. Test Setup Test 4.11 – Peripheral to Peripheral Interface Rule Part E - ● The evaluator verified that the TOE implementation properly isolates the peripheral device interfaces that are not switched together. Note that the following test assumes that the USB keyboard and mouse combination and the USB user authentication device are independently switched. The test may be modified to support different combinations of peripheral devices with minor changes. An example of positive results is presented the image below. The characters type in Notepad on PC 2 do not appear on PC 1: All results from all TOEs tested resulted in positive findings. The switch did not fail this test. Assurance Activity Report v1.0 Page 35 HSL Secure KM Switch Switch combinations of peripheral devices with minor changes. 4.5 FDP_ACC.1 Subset access control FDP_ACC.1.1 The TSF shall enforce the [peripheral device SFP] on [Subjects: Peripheral devices Objects: Console ports Operations: allow connection, disallow connection]. Assurance Activity Assurance Activities for this SFR are covered by the next SFR FDP_ACF.1. Assurance Activity Report v1.0 Page 36 HSL Secure KM Switch Switch 4.6 FDP_ACF.1 Security attribute based access control FDP_ACF.1.1 The TSF shall enforce the [peripheral device SFP] to objects based on the following: [Subjects: Peripheral devices Subject security attributes: peripheral device type Objects: Console ports Object security attributes: none]. FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [The TOE shall query the connected peripheral device upon initial connection or upon TOE power up and allow connection for authorized peripheral devices in accordance with the table in Annex C of this PP]. FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [none.]. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [The TOE peripheral device interface (console) port shall reject any peripheral device with unauthorized values]. Assurance Activity The evaluator shall verify that the TSS describes the allowed devices for each peripheral port type. The description does not need to include brand or model information, but must provide the following information: a. Whether or not the USB keyboard and USB mouse console ports are interchangeable or may be combined into one port (composite USB device); b. Whether or not PS/2 keyboard and mouse console ports are supported. c. What types of authentication devices (e.g., smart card, CAC, token, biometric reader) are supported, how they are identified, and whether or not the TOE enables configurable user authentication device profiling (filtering); d. What audio out devices types are supported; and e. What user display interface protocols are supported by the TOE If hub and composite devices are permitted, the TSS must describe how the TOE filters endpoints. The evaluator shall also verify that the TSS includes a statement indicating that the peripheral device qualification profiles cannot be changed after production. Assurance Activity Report v1.0 Page 37 HSL Secure KM Switch Switch Verify that the TSS provides information on how the whitelist and blacklist are loaded into the TOE and which users are authorized to load / change these parameters. (Only privileged administrators shall be authorized to perform this activity.) The evaluator shall verify that the user guidance provides instructions for the implementation and use of all implemented connection types, and their limitations. The guidance must describe the visual indications provided to a user when a connected device is rejected. Tests covering this SFR are tests 4.2 and 4.3 above. Evaluator Note: Test 4.2 is Test #2 and 4.3 is Test #3 above. TSS Verification The evaluator shall verify that the TSS describes the allowed devices for each peripheral port type. The description does not need to include brand or model information, but must provide the following information: a. Whether or not the USB keyboard and USB mouse console ports are interchangeable or may be combined into one port (composite USB device); CSC: Per the Table of authorized devices for FDP_ACF.1, the USB keyboard and USB mouse console ports are composite ports and the TOE can filter USB endpoints. b. Whether or not PS/2 keyboard and mouse console ports are supported. CSC: PS/2 Keyboard and mouse console ports are not supported for the TOE. Only USB ports are used. From Table 20, PS/2 to USB adapter must be used for PS/2 keyboards and mice and the table in section 1.3.2.3 specifies the same. c. What types of authentication devices (e.g., smart card, CAC, token, biometric reader) are supported, how they are identified, and whether or not the TOE enables configurable user authentication device profiling (filtering); CSC: Section 7.4 of the ST explains how the authentication security function works and the bullet c of the section explains defining device enumeration. TOE support user authentication devices, that “Standard smart-card reader USB token or biometric authentication device having USB smart-card class interface.”, as stated in the first bullet in Section 7.4 Table 7 of this document identifies the TOE having this function. d. What audio out devices types are supported; and CSC: Section 7.3 of the ST identifies the security features of the audio subsystem. The TOE supports audio, that “standard analog headphones and standard amplified speakers or multimedia set.” Table of 5 of the ST further clarifies the audio as analog stereo. e. What user display interface protocols are supported by the TOE CSC: Table 3 of the ST defines that all KM switches do not support video. Assurance Activity Report v1.0 Page 38 HSL Secure KM Switch Switch The evaluator shall also verify that the TSS includes a statement indicating that the peripheral device qualification profiles cannot be changed after production. CSC: Section 7.4 of the ST identifies the switches that support user authentication device function as configured by default as FDF (Fixed Device Filtration) switches with the filter set to qualify only standard smart-card reader USB token or biometric authentication device having USB smart-card class interface. Table 7 of this document identifies the TOE as having this function. Verify that the TSS provides information on how the whitelist and blacklist are loaded into the TOE and which users are authorized to load / change these parameters. (Only privileged administrators shall be authorized to perform this activity.) CSC: It is stated in Section 7.4 TOE User authentication device subsystem that CDF is supported for switches that are having fUSB function and states, “Qualified administrator after successfully logging-in to the TOE administrative function may switch the TOE to CDF (Configurable Device Filtration) mode through loading any white-list/black-list or traffic rules.” Operational Guidance Verification The evaluator shall verify that the user guidance provides instructions for the implementation and use of all implemented connection types, and their limitations. CSC: The User Guidance Manual has instructions for the use of all implemented connection types and their limitations on the Equipment Requirement page; their connection types and limitations are located on the Product Specifications page. See mapping below. Table 12: Referenced documents Document Reference Instructions (see document references in Section limitations. 2.1) [C] for Implementation and Page 8-9 The guidance must describe the visual indications provided to a user when a connected device is rejected. CSC: If the device is detected but is not authorized, the device will be rejected for security reasons. This will be indicated by fUSB status LED flashing green. Table 13: Referenced documents Document Reference Visual indication of device rejected (see document references in Section 2.1) [C] Page 6, bullet 7 Testing Summary Tests covering this SFR are tests 4.2 and 4.3 summarized above. Assurance Activity Report v1.0 Page 39 HSL Secure KM Switch Switch 4.7 FDP_RIP.1 Subset Residual information protection FDP_RIP.1.1 [Refinement] The TSF shall ensure that any previous information content of a resource is made unavailable upon the [deallocation of the resource from] the following objects: [a TOE computer interface]: • immediately after TOE switch to another selected computer; • and on start-up of the TOE] Assurance Activity TSS The TSS shall include a detailed Letter of Volatility. The evaluator shall verify that the TSS Letter of Volatility provides at least the following information: a. b. c. d. It indicates which TOE components have a non-volatile memory, the nonvolatile memory technology, manufacturer and part number and memory size. The type of data that the TOE may store on each one of these components. Whether or not each one of these parts is used to store user data and how this data may remain in the TOE after power down. If the specific component may be independently powered by something other than the TOE (for example – by a connected computer). The TSS must indicate whether or not the TOE has user data buffers and how these buffers are deleted when the user switches to another computer. Note that user configuration and TOE settings are not user data and therefore may be stored in the TOE on non-volatile memory components. Guidance Check the user or administrative guidance for any limitations regarding transfer of the TOE between different security levels / roles in the organization. Ensure this guidance is consistent with the claims in the Security Target. Check that the user guidance provides a method to purge TOE memory or to Restore Factory Default settings. Test Test 4.12 Residual Information Protection Evaluator Note: See actual test below TSS Verification The TSS shall include a detailed Letter of Volatility. The evaluator shall verify that the TSS Letter of Volatility provides at least the following information: Assurance Activity Report v1.0 Page 40 HSL Secure KM Switch Switch a. b. c. d. It indicates which TOE components have a non-volatile memory, the nonvolatile memory technology, manufacturer and part number and memory size. The type of data that the TOE may store on each one of these components. Whether or not each one of these parts is used to store user data and how this data may remain in the TOE after power down. If the specific component may be independently powered by something other than the TOE (for example – by a connected computer). CSC: It is stated in the Letter of Volatility through a table which components have non-volatile memory, the memory technology, manufacturer/part number/memory size and the types of data the TOE may store on each component. The text below this table further explains how data is stored and if the component may be independently powered. The Letter of Volatility is provided in Annex C of the Security Target. The TSS must indicate whether or not the TOE has user data buffers and how these buffers are deleted when the user switches to another computer. Note that user configuration and TOE settings are not user data and therefore may be stored in the TOE on non-volatile memory components. CSC: Section 7.1, bullet l, indicates that during TOE switching from one computer to another, the system controller function assures that the keyboard and mouse stacks are deleted and that the first 100 milliseconds of commands received from the keyboard after switching are ignored (deleted). Operational Guidance Verification Check the user or administrative guidance for any limitations regarding transfer of the TOE between different security levels / roles in the organization. Ensure this guidance is consistent with the claims in the Security Target. CSC: Guidance does not provide specific limitations regarding transfer of the TOE between different security levels/roles in the organization. Check that the user guidance provides a method to purge TOE memory or to Restore Factory Default settings. CSC: All guidance describes a ‘Restore-to-Default’ function, and states “product boots after Restore-to-Default, the active channel will be #1 and settings will be reset to default erasing all user-set definitions.” There is also picture evidence indicating where the ‘Restore-to-Default’ function is on each device. Assurance Activity Report v1.0 Page 41 HSL Secure KM Switch Switch Table 14: Referenced documents Document Reference (see document references in Section 2.1) [C] Page 6 bullet 2; page 16 Testing Summary Test 4.12 – Residual Information Protection The switch tested has a letter of volatility assuring that no user data remains in the TOE after power down. After confirming the character repeat was set to the highest possible Notepad was used to continuously press the Letter “a” to capture nothing but “aaaaaaaaaaaaaaaaaaaa…” across the Notepad session. Changing to PC-2 and verifying there was no “a” on its session of its own Notepad, then repeating the process but holding down the letter “b”. No letter of previous displayed PC was seen on current displayed PC. All steps resulted in the expected findings. The following image illustrates the Notepad session on PC -1 : Assurance Activity Report v1.0 Page 42 HSL Secure KM Switch Switch 4.8 FPT_PHP.1 Subset Residual information protection FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF. FPT_PHP.1.2 The TSF shall provide the capability to determine whether physical tampering with the TSF's devices or TSF's elements has occurred. Assurance Activity TSS The evaluator shall verify that the TSS indicates that the TOE provides unambiguous detection of physical tampering. The evaluator shall verify that the TSS provides information that describes how the TOE indicates that it has been tampered with and how these indications cannot be turned on by the TOE user. Guidance The evaluator shall verify that the user guidance describes the mechanism by which the TOE provides unambiguous detection of physical tampering and provides the user with instructions for verifying that the TOE has not been tampered with. Test The test for this SFR combined with the ant-tampering function testing. See test 4.13 (Test #13) below. TSS Verification The evaluator shall verify that the TSS indicates that the TOE provides unambiguous detection of physical tampering. CSC: Section 7.6 of the ST indicates two non-ambiguous physical detection mechanisms the switches use to detect evidence of tampering. a) The switches use ‘Tampering Evident Labels’ (TEL) located in on the TOE enclosure. Any attempt to access the TOE internal circuitry would cause permanent visible damage to one or more TEL. Each label is numbered with unique number that recoded by the manufacturer during TOE production. b) There is an always-on anti-tampering system mechanically coupled to the TOE enclosure to detect and attempt to access the TOE internal circuitry. Once triggered by physically attempting to open the enclosure or depleting/failing the battery causes the anti-tampering function to trigger and the TOE will become permanently disabled. The TOE cannot be recovered. The evaluator shall verify that the TSS provides information that describes how the TOE indicates that it has been tampered with and how these indications cannot be turned on by the TOE user. Assurance Activity Report v1.0 Page 43 HSL Secure KM Switch Switch CSC: Section 7.6, bullet d, indicates, “All TOE interfaces and user functions are disabled and proper user indications are shown through sequentially blinking front panel LEDs.” when the TOE has been tampered with. Operational Guidance Verification The evaluator shall verify that the user guidance describes the mechanism by which the TOE provides unambiguous detection of physical tampering and provides the user with instructions for verifying that the TOE has not been tampered with. CSC: All the user manuals provided for the evaluation describe the use of tamper evident labels and the always-on anti-tampering system. All manuals describe how user can determine from these mechanisms the switch has been tampered with. The manuals provide a pictorial description of what an untampered tamper label will look like. See the table below for where each is described in the manuals. The manuals state the indication for a tampered state as all LEDs blinking. Table 15: Referenced documents Document Reference Tamper evident labels (see document references in Section 2.1) [C] Page 10 Determining tamper evident labels tampered with Page 10 Testing Summary CSC: Test Combined with FPT_PHP.3 as per the Assurance Activity. Assurance Activity Report v1.0 Page 44 HSL Secure KM Switch Switch 4.9 FPT_PHP.3 Subset Residual information protection FPT_PHP.3.1 [Refinement] The TSF shall resist [a physical attack on the TOE for the purpose of gaining access to the internal components, or to damage the anti-tampering battery] to the [TOE Enclosure] by responding automatically such that the SFRs are always enforced becoming permanently disabled. Assurance Activity TSS The evaluator shall verify that the TSS describes the TOE’s reaction to opening the device enclosure, or damaging/exhausting the anti-tampering battery associated with the enclosure. Guidance The evaluator shall verify that the user guidance warns the user of the actions that will cause the anti-tampering functionality to disable the device. Guidance shall also include a clear description of the anti-tampering triggering user indications. Test Test 4.13 Tampered TOE is permanently disabled and properly isolated Evaluator Note: See actual test below TSS Verification The evaluator shall verify that the TSS describes the TOE’s reaction to opening the device enclosure, or damaging/exhausting the anti-tampering battery associated with the enclosure. CSC: Section 7.6 indicates in the fourth and fifth bullets there is an always-on anti-tampering system mechanically coupled to the TOE enclosure to detect and attempt to access the TOE internal circuitry. Once triggered by physically attempting to open the enclosure or depleting/failing the battery causes the antitampering function to trigger and the TOE will become permanently disabled. The TOE cannot be recovered. Operational Guidance Verification The evaluator shall verify that the user guidance warns the user of the actions that will cause the anti-tampering functionality to disable the device. CSC: All user manuals provide a clear warning that states, “Important: This product is equipped with always-on active anti-tampering system. Any attempt to open the product enclosure will activate the anti-tamper triggers and render the unit inoperable and warranty void.” See the table below for page reference for the warning. Assurance Activity Report v1.0 Page 45 HSL Secure KM Switch Switch Table 16: Referenced documents Document Reference Tamper evident (see document references in warning Section 2.1) [C] label Determining tampering active Page 10 system Page 10 Guidance shall also include a clear description of the anti-tampering triggering user indications. CSC: As stated in FPT_PHP.1, the indication for a tampered state as all LEDs blinking. Table 17: Referenced documents Document Reference Determining tampering system active (see document references in Section 2.1) [C] Page 10 Testing Summary Test 4.13 Tampered TOE is permanently disabled and properly Isolated In the following test the evaluator shall attempt to gain physical access to the TOE internal circuitry (enough access to allow the insertion of tools to tamper with the internal circuitry). The TOE antitampering function is expected to trigger, causing an irreversible change to the TOE functionality. The evaluator then shall verify that the anti- As set forth in the PP, the evaluator ensured each TOE had at least one tamper label attached at points of seams. Test Setup Part C 1 2 3 ● ● ● Test 4.13 - Tampered TOE is permanently disabled and properly isolated Part – 1, Steps 1 thru 3 of the PP, resulted in the following: The following image is a sample of those TOEs tested: The tamper label is clearly visible and in the non-tampered condition. The second image displays the tampered state of the label removal: Assurance Activity Report v1.0 Page 46 HSL Secure KM Switch Switch tampering triggering provides the expected user indications and also disables the TOE. TOE disabling means that the user would not be able to use the TOE for any purpose – all peripheral devices and computers are isolated. Note that it is obvious that if the TOE was physically tampered with, then the attacker may easily circumvent the tamper indication means (for example cut the relevant TOE front panel wires). Nevertheless, the following test verifies that the user would be unable to ignore the TOE tampering indications and resume normal work. Part 2 – steps 4 and 5 of the PP, required the evaluator to ensure that the antitampering is permanent. The removal of the anti-tamper label, as evident in the image above, is permanent. When the evaluator attempted to gain access to the tested TOE there was an audible click or cracking sound. The switch did not have accessible settings that could reset the TOE itself to a different functional state. Part -3, steps 6 thru 9 of the PP, the evaluator verified the TOE behavior conformed to the data isolation requirements once the device was tampered. All TOEs resulted in non-functional devices. The TOEs displayed either flashing lights, or clicking sounds with no switch function working nor keyboard or mouse functionality. If the TOE supported audio a load clicking in sequence with the flashing PC selection indicator could be heard. Assurance Activity Report v1.0 Page 47 HSL Secure KM Switch Switch 4.10 FPT_FLS.1 Failure with preservation of secure state FPT_FLS.1.1 The TSF shall preserve a secure state by disabling the TOE when the following types of failures occur: [failure of the power on selftest, failure of the anti-tampering function]. Assurance Activity Assurance Activities for this SFR were integrated with the TSF Testing Assurance Activities below. TSS Verification The evaluator shall verify that the TSS describes the secure state when the failure of the power on self-test and failure of the anti-tampering function occur. CSC: It is stated in Section 7.7, TOE Self-testing, that if the self-testing function has failed, the TOE will provide proper user indications and will disable normal operation. In Section 7.6, when the anti-tampering mechanism is triggered, “all TOE interfaces and user functions are disabled and proper user indications are shown through sequentially blinking front panel LEDs.” when the TOE has been tampered with.” Operational Guidance Verification The evaluator shall verify that the guidance describes the secure state when the failure of the power on self-test and failure of the anti-tampering function occur. CSC: All user guidance state a precaution in case of self-test failure, “As product powers-up it performs a self-test procedure. In case of self- test failure for any reason, including jammed buttons, the product will be Inoperable. Self-test failure will be indicated by the following abnormal LED behavior: a. All channel-select LEDs will be turned ON and then OFF; b. A specific, predefined LED combination will be turned ON; c. The predefined LED combination will indicate the problem type (jammed buttons, firmware integrity). Try to power cycle product. If problem persists please contact your system administrator or technical support.” Table 18: Referenced documents Document Reference (see document references in Section 2.1) [C] Self-Test Failure and Anti-Tampering Page 6, bullet 1 & 6 Testing Summary CSC: FPT_PHP.3, Test 4.13, showed the tampered TOE is permanently disabled and properly isolated. Assurance Activity Report v1.0 Page 48 HSL Secure KM Switch Switch . Assurance Activity Report v1.0 Page 49 HSL Secure KM Switch Switch 4.11 FPT_TST.1 TSF testing FPT_TST.1.1 [Refinement] The TSF shall run a suite of self-tests that includes as minimum: a. Test of the basic TOE hardware and firmware integrity; and b. Test of the basic computer-to-computer isolation; and c. Test of critical security functions (i.e., user control and antitampering). [during initial startup, [upon reset button activation]] to demonstrate the correct operation of [the TSF]. FPT_TST.1.2 The TSF shall provide users with the capability to verify the integrity of [the TSF functionality]. FPT_TST.1.3 The TSF shall provide users with the capability to verify the integrity of [the TSF]. Assurance Activity TSS The evaluator shall verify that the TSS describes the self- tests that are performed on start up or on reset (if a reset function is available). The evaluator shall verify that the self-test covers at least the following: a) b) c) d) a basic integrity test of the TOE hardware and firmware (for example, memory testing and firmware checksum compare); a test of the computer interfaces’ isolation functionality (for example, generating data flow on one port and checking that it is not received on another port); a test of the user interface – in particular tests of the user control mechanism (for example checking that the front panel push-buttons are not jammed); and a test of the anti-tampering mechanism (for example checking that the backup battery is functional). The evaluator shall verify that the TSS describes how the TOE ensures a shutdown upon a self-test failure or a failed anti-tampering function. If there are instances when a shutdown does not occur (e.g., a failure is deemed non-security relevant), those cases are identified and a rationale is provided explaining why the TOE’s ability to enforce its security policies is not affected. The evaluator shall check the TSS to verify that it describes the TOE behavior in case of selftest failure. The evaluator shall verify that the described TOE behavior includes shutting down the PSS functionality once the failure is detected. Guidance The evaluator shall verify that the user guidance: a. describes how the results of self-tests are indicated to the user; Assurance Activity Report v1.0 Page 50 HSL Secure KM Switch Switch b. c. provides the user with a clear indication of how to recognize a failed selftest; and details the appropriate actions to be completed in response to a failed selftest. The evaluator shall verify that the user / administrative guidance provide adequate information on TOE self-test failures, their causes and their indications. Test Test 4.14 Self-Test Pass and Fail Evaluator Note: See actual test below TSS Verification The evaluator shall verify that the TSS describes the self-testing that are performed on start up or on reset (if a reset function is available). CSC: Section 7.7 describes to power-up self-tests the TOE performs. The evaluator shall verify that the self-test covers at least the following: a) a basic integrity test of the TOE hardware and firmware (for example, memory testing and firmware checksum compare); b) a test of the computer interfaces’ isolation functionality (for example, generating data flow on one port and checking that it is not received on another port); c) a test of the user interface – in particular tests of the user control mechanism (for example checking that the front panel push-buttons are not jammed); and d) a test of the anti-tampering mechanism (for example checking that the backup battery is functional). CSC: It is stated in the ST, Section 7.7 bullet b, the self-testing function checks the integrity of the TOE microcontrollers firmware, the anti-tampering function, and the control functions, which satisfies bullets a, c and d above. It is additionally stated in bullet c of Section 7.7 in the ST the self-test function tests “computer ports isolation by running test packets at different interfaces and attempting to detect traffic at all other interfaces.” The evaluator shall verify that the TSS describes how the TOE ensures a shutdown upon a self-test failure or a failed anti-tampering function. If there are instances when a shutdown does not occur (e.g., a failure is deemed non-security relevant), those cases are identified and a rationale is provided explaining why the TOE’s ability to enforce its security policies is not affected. CSC: Section 7.7 (Self Tests) or Section 7.6 (Anti-Tampering) of the ST does not indicate any situations where the TOE does not become disabled on failure of a self-test or triggering the anti-tampering function. Both sections indicate how the TOE responds by sequentially blinking front panel LEDs. Assurance Activity Report v1.0 Page 51 HSL Secure KM Switch Switch The evaluator shall check the TSS to verify that it describes the TOE behavior in case of selftest failure. The evaluator shall verify that the described TOE behavior includes shutting down the PSS functionality once the failure is detected. CSC: Along with what was previously stated, Section 7.7 bullet a states when a self-test fails the TOE, “will disable normal operation while isolating all / or affected peripheral devices and connected computers.” Operational Guidance Verification The evaluator shall verify that the user guidance: a. describes how the results of self-tests are indicated to the user; b. provides the user with a clear indication of how to recognize a failed selftest; and c. details the appropriate actions to be completed in response to a failed selftest. CSC: Each User Guidance document provides the user with a clear indication of how to recognize a failed self-test, “after product boots up, the default active channel will be channel #1. This will be indicated by white color illumination of push-button #1.” As well as the appropriate actions to be completed if a failed self-test occurs. Table 19: Referenced documents Document Reference (see document references in Section 2.1) [C] Actions in response to failed selftest Page 19, bullet 1 & 2 The evaluator shall verify that the user / administrative guidance provide adequate information on TOE self-test failures, their causes and their indications. CSC: It is stated in each User Guidance Manual, “in case of self- test failure for any reason, including jammed buttons, the product will be inoperable.” It is further explained in above the indications of how to recognize a self-test failure. All information can be found in mapping above. Assurance Activity Report v1.0 Page 52 HSL Secure KM Switch Switch Testing Summary Test 4.14 Self-Test Pass and Fail In this test the evaluator shall cause a TOE selftest failure to verify that the TOE responds by disabling normal functions and providing proper user indications. The evaluator shall also attempt to remove / disconnect the anti-tampering battery to check that the TOE indicates that it has been tampered with. Test Setup Test 4.14 - Self-Test Pass and Fail Part E - ● Pressing two selections while the TOE is powering up renders the TOE unusable until the TOE is rebooted without any selections being depressed. Power up the TOE while card is inserted or button is pressed – self-test failed. TOE beeps loudly and all LEDs are illuminating. Removing the TOE anti-tampering battery and reinstalling it resulted in the same effect as opening the device, the TOE became unusable. All TOEs tested performed as expected. Assurance Activity Report v1.0 Page 53 HSL Secure KM Switch Switch 4.12 FTA_CIN_EXT.1 Extended: Continuous Indications FTA_CIN_EXT.1.1 The TSF shall display a continuous visual indication of the computer to which the user is currently connected, including on power up, [on reset]. Assurance Activity TSS The evaluator shall verify that the TSS describes how the switch behaves on power up. The TSS must indicate whether or not the TOE has a reset option and, if so, the TSS shall describe how the switch behaves when this option is exercised. Guidance The evaluator shall verify that the user guidance notes which computer port group will be connected on TOE power up or recovery from reset, if this is an option. Where a reset option is available, use of this feature must be described in the user guidance. Test Test 4.15 – Power Up Defaults, Continuous Indications and Single Control Evaluator Note: See actual test below TSS Verification The evaluator shall verify that the TSS describes how the switch behaves on power up. CSC: In Section 7.5, bullets i and j identify the visual indicators during the power-up and self-test sequences during power-up. The bullets state, “ i. The communication, configuration and integrity of the TOE front panel are being tested during power up self-testing. During power up until the TOE successfully passed the self-test, no channel is selected and therefore no TOE state provided to the user. j. After self-test passed at all times that the TOE is operative, front panel indications are provided and cannot be turned off or dimmed by the user in any way.” The TSS must indicate whether or not the TOE has a reset option and, if so, the TSS shall describe how the switch behaves when this option is exercised. CSC: Bullet k of Section 7.5 states all switches have a “Restore to Factory Default recessed switch” and the bullet further explains the behavior of the switch when the button is pressed during normal operation. Operational Guidance Verification The evaluator shall verify that the user guidance notes which computer port group will be connected on TOE power up or recovery from reset, if this is an option. Where a reset option is available, use of this feature must be described in the user guidance. CSC: Each User Manual describes the power up setup, in which it states which port group will be connected on TOE when powering up, “By default, after Assurance Activity Report v1.0 Page 54 HSL Secure KM Switch Switch product power-up, the active channel is #1. Product Restore-to-Default function is available via physical controls and/or keyboard shortcuts. When product boots after Restore-to-Default, the active channel will be #1 and settings will be reset to default erasing all user-set definitions.” Table 20: Referenced documents Document Reference Log Functions (see document references in Section 2.1) [C] Page 6, bullet 2 Testing Summary Test 4.15 – Power Up Defaults, Continuous Indications and Single Control In this test the evaluator shall verify that the TOE power up default settings are consistent with the user guidance. If the TOE defaults are affected by the TOE configuration, then each available configuration shall be tested. The evaluator shall also check that the TOE provides proper consistent indication of each peripheral device group selected. Indications shall be always on. Test Setup Test 4.15 – Power Up Defaults, Continuous Indications and Single Control Part E - ● All tested TOEs operated as specified in their corresponding User Guidance. HSL KM – Default after power up is PC 1 (image below) No TOE operated outside specification described in its corresponding user guidance. Assurance Activity Report v1.0 Page 55 HSL Secure KM Switch Switch 4.13 FAU_GEN.1: Audit Data Generation FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shutdown of the audit functions; b) All auditable events for the [not specified] level of audit; and c) [administrator login, administrator logout, and [assignment: all administrative functions claimed in FMT_MOF.1 and FMT_SMF.1]] FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [no other information]. Assurance Activity TSS The evaluator shall verify that the TSS describes the audit functionality including which events are audited, what information is saved in each record type, how the records are stored, the conditions in which audit records are overwritten, and the means by which the audit records may be read. Although the TOE may provide an interface for an administrator to view the audit records, this is not a requirement. Test The evaluator shall perform each of the auditable functions to succeed, and where possible, to fail. The evaluator shall use the means described in the TSS to access the audit records and verify that each of the events has been recorded, with all of the expected information. TSS Verification The evaluator shall verify that the TSS describes the audit functionality including which events are audited, what information is saved in each record type, how the records are stored, the conditions in which audit records are overwritten, and the means by which the audit records may be read. CSC: Section 7.8 of the ST describes what events are audited and their stored location. There are events stored in a critical log area and non-critical log area. Critical events include product registration information, anti-tampering arming event and all tampering events detected (may be more than one, last admin log-on information and last self-test failure information. The non-critical events are administrator log in and changes made, changes in administrator password, rejection of USB devices, self-test failures, CDF (black-list / white-list) and traffic rules uploading, and power up and down cycles. Assurance Activity Report v1.0 Page 56 HSL Secure KM Switch Switch The critical log is never overwritten or deleted. The non-critical log can store 32 lines of records. The oldest record is overwritten by new records when the log is full. The section describes three methods in which the audit records may be read or viewed. Although the TOE may provide an interface for an administrator to view the audit records, this is not a requirement. Operational Guidance Verification The evaluator shall verify that the guidance describes the audit functionality including which events are audited, what information is saved in each record type, how the records are stored, the conditions in which audit records are overwritten, and the means by which the audit records may be read. CSC: The Administrator Guide on pages 8-11, provide detailed descriptions and pictures of the events audited, the information saved and stored, along with the conditions of overwritten audit records as stated; “In general the log function records all black text events and the last 40 lines of green events. After 40 green events recoded, it will overwrite first green events.” Testing Summary Optional Test F.1.2 Audit Data Generation Test Setup Optional Test F.1.2 - Audit data generation Part E - ● As identified in each TOEs Administrator’s Guide the logs provide detailed data as needed. The image below is an example of the logs available from all the tested TOEs: Administrator logged on and dumped the log to Notepad. Assurance Activity Report v1.0 Page 57 HSL Secure KM Switch Switch Sample log recovered from Test C All TOEs tested provided this level of detail to the administrator. 4.14 FIA_UAU.2 User authentication before any action FIA_UAU.2.1 The TSF shall require each administrator to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Assurance Activity CSC: Optional Test F.1.3 Administrator authentication and functions access Test Steps Entered administrator mode Attempted to access the following administrative functions without administer logged on: a. Load KM settings; b. Download log; and c. Load USB filtration settings. Attempts shall fail (no access). Attempted to logon without proper credentials – logon attempt shall fail. Attempted to logon with proper credentials – logon Test Setup Optional Test F.1.3 – Administrator authentication and functions access Part E - ● As identified in each TOEs Administrator’s Guide, and administrator must input a username/password to access any functions defined in FMT_MOF.1. The image below is an example of the log in screen for the TOE: Actual Results Attempted to perform commands prior to logging on. Attempts failed as expected. a) Could not access loading options without a prior login and entering the terminal mode. b) Could not access log functions without a prior login. c) Could not access USB filtration options without prior login. Attempted to logon with user name “badadmin” (user does not exist) – verified. Log-on attempt failed as expected. Verified. Log-on successful. Assurance Activity Report v1.0 Page 58 HSL Secure KM Switch Switch attempt shall succeed. Checked the above listed administrative functions to assure that access is now possible. Checked that the failed and passed administrator logon attempts are properly logged. Verified. Terminal mode available only after administrator is authenticated. Verified. Both events were properly logged with cause, date and time. 4.15 FIA_UID.2 User identification before any action FIA_UID.2.1 The TSF shall require each administrator to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Assurance Activity CSC: Refer to FIA_UAU.2.1. As noted in FMT_MOF.1 below, Optional Test F.1.3 included identification and authentication when using management functions. 4.16 FMT_MOF.1 Management of security functions behavior FMT_MOF.1.1 The TSF will restrict the ability to [perform] the functions [modify TOE user authentication device filtering (CDF) whitelist and blacklist] to [the authorized administrators]. Assurance Activity TSS The evaluator shall verify that the TSS describes the mechanism for preventing nonadministrators from accessing the administrative functions stated above. Guidance The evaluator shall check the user and administrative guidance to verify that the administrative functions defined above are only available to identified administrators. Test The testing for this SFR is covered in Optional Test F.1.3 above. TSS Verification The evaluator shall verify that the TSS describes the mechanism for preventing nonadministrators from accessing the administrative functions stated above. CSC: The notes included in Section 6.1.9 state that logging on with administrator identification and authentication is required for management functions. Assurance Activity Report v1.0 Page 59 HSL Secure KM Switch Switch Section 7.5 requires a qualified administrator to successfully log-in to switch the TOE to CDF mode through loading any white-list/black-list or traffic rules. Operational Guidance Verification The evaluator shall check the user and administrative guidance to verify that the administrative functions defined above are only available to identified administrators. CSC: The fUSB Configuration Manual describes that “Configurable Device Filtering (CDF) mechanism is used with configuration permissions limited to authenticated administrators” on page 9. The Administrator guide describes on page 8 describes how to authenticate properly to the switch through the management PC. Testing Summary CSC: Refer to Optional Test F.1.3 in FIA_UAU.2 for test results. The test required Administrative access to define black-listed and whitelisted devices USB (CDF). All black-listed USB devices rejected by the TOE as expected. All whitelisted USB devices that were not black-listed as well were accepted by the TOE as expected. Assurance Activity Report v1.0 Page 60 HSL Secure KM Switch Switch 4.17 FMT_SMF.1 Management of security functions behavior FMT_SMF.1.1 The TOE shall be capable of performing the following management functions: a. TOE shall provide authorized administrators the option to assign whitelist and blacklist definitions for the TOE user authentication device qualification function, b. [Assignment: and the ability to define specific data flow rules for specific computer interfaces]. Assurance Activity TSS The evaluator shall check to ensure the TSS describes the various administrator and user TOE configurations and how they are used by the TOE. Guidance The evaluator shall check to make sure that every management function mandated in the ST for this requirement are described in the operational guidance and that the description contains the information required to perform the management duties associated with each management function. Test The testing for this SFR is covered in: FMT_SMF.1.1 a - Test F1 below. FMT_SMF.1.1 b - Test 4.5 Part 5 above. TSS Verification The evaluator shall check to ensure the TSS describes the various administrator and user TOE configurations and how they are used by the TOE. CSC: Section 7.4 of the ST states, “Traffic rules are only related to preventing DPP from being switched to the currently selected computer. While in this mode, the TOE may qualify any USB 1.1, 2.0 or 3.0 based on the following one or more criterions: USB Class, USB Sub-class, USB Protocol, USB device ID, USB Vendor ID, and USB Serial number.” Operational Guidance Verification The evaluator shall check to make sure that every management function mandated in the ST for this requirement are described in the operational guidance and that the description contains the information required to perform the management duties associated with each management function. CSC: The Configuration Manual for TOE (as defined in table 9 above), Page 18; describes where you select specific channels for the different USB devices. The “USB status LED will blink and turn off indicating the new settings are stored.” Assurance Activity Report v1.0 Page 61 HSL Secure KM Switch Switch Testing Summary CSC: Refer to Test 4.5 and F.1.3 for test results. The test required Administrative access to define black-listed and whitelisted devices USB (CDF). All black-listed USB devices rejected by the TOE as expected. Device LED provided proper indication for rejection. All white-listed USB devices that were not black-listed as well were accepted by the TOE as expected. Assurance Activity Report v1.0 Page 62 HSL Secure KM Switch Switch 4.18 FMT_SMR.1 Security roles FMT_SMR.1.1 The TSF will maintain the roles [users, administrators]. Assurance Activity Refer to the assurance activities of FMT_MOF.1.1 above. Testing Summary CSC: Refer to Test 4.5 for test results. The test required Administrative access to define black-listed and whitelisted devices USB (CDF). All black-listed USB devices rejected by the TOE as expected. Device LED provided proper indication for rejection. All white-listed USB devices that were not black-listed as well were accepted by the TOE as expected. Assurance Activity Report v1.0 Page 63 HSL Secure KM Switch Switch 4.19 FTA_ATH_EXT.1 User authentication device reset FTA_ATH_EXT.1.1 The TSF shall reset the power supplied to the user authentication device for at least one second when the user switches the device from one computer to another. Assurance Activity TSS The evaluator shall verify that the TSS describes how the TOE resets the power to the user authentication device. The TSS shall also describe the amount of capacitance in the TOE and how it will affect the voltage decrease on an average user authentication device. Capacitance shall be small enough to assure that low-power devices would reach less than 2.0 V during that one second power reset. Guidance The evaluator shall verify that the user guidance provides information about the prohibited use of user authentication devices with external power sources. Test The testing for this SFR is covered in: FMT_SMF.1.1 b - Test 4.5 Part 1 above. TSS Verification The evaluator shall verify that the TSS describes how the TOE resets the power to the user authentication device. CSC: Section 7.5, bullet k of the ST describes how the TOE resets power to the user authentication device when the user switches to a different computer. The bullet states in part, “Once the user switches the connected computer, the TOE resets the user authentication device through power supply switching (temporary power dip as defined by the referenced PP).” The bullet further details the technical details of the power supply switching. The TSS shall also describe the amount of capacitance in the TOE and how it will affect the voltage decrease on an average user authentication device. Capacitance shall be small enough to assure that low-power devices would reach less than 2.0 V during that one second power reset. CSC: Section 7.5, bullet k of the ST describes in the technical details the level of capacitance and the either the TOE supply or any voltage remaining in the capacitors is shorted to ground to ensure that less than 2.0V is reached. Operational Guidance Verification The evaluator shall verify that the user guidance provides information about the prohibited use of user authentication devices with external power sources. CSC: It is stated in the User Guidance Manuals, “do not connect any authentication device with an external power source to product.” Assurance Activity Report v1.0 Page 64 HSL Secure KM Switch Switch Table 21: Referenced documents Document Reference (see document references in Section 2.1) [C] Prohibited use of external power source Page 6, bullet 3 Testing Summary The testing for this SFR is covered in: FMT_SMF.1.1 b - Test 4.5 Part 1. Assurance Activity Report v1.0 Page 65 HSL Secure KM Switch Switch 4.20 ADV_FSP.1 Basic Functional Specification Assurance Activities: There are no specific assurance activities associated with these SARs. The functional specification documentation is provided to support the evaluation activities described in Section 4.2 and other activities described for AGD, and ATE SARs. The requirements on the content of the functional specification information are implicitly assessed by virtue of the other assurance activities being performed; if the evaluator is unable to perform an activity because the there is insufficient interface information, then an adequate functional specification has not been provided. Assurance Activity Report v1.0 Page 66 HSL Secure KM Switch Switch 4.21 AGD_OPE.1 Operational User Guidance Assurance Activities: Some of the contents of the operational guidance will be verified by the assurance activities in Section 4.2 and evaluation of the TOE according to the Common Evaluation Methodology (CEM). The following additional information is also required. The operational guidance shall contain instructions for configuring the TOE environment to support the functions of the TOE. These instructions shall include configuration of the TOE as well as configuration of the connected computers and peripheral devices. Operational Guidance Verification The operational guidance shall contain instructions for configuring the TOE environment to support the functions of the TOE. These instructions shall include configuration of the TOE as well as configuration of the connected computers and peripheral devices. CSC: All User Guidance have Before Installation procedures and Installation procedures that include configuration of the TOE and configuration of the connected computers and peripheral devices. Table 22: Referenced documents Document Reference Isolation (see document references in Section 2.1) [C] Page 19-21 4.22 AGD_PRE.1 Preparative Procedures Assurance Activities: The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses the computer platforms and peripheral devices claimed for the TOE in the ST. Operational Guidance Verification The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses the computer platforms and peripheral devices claimed for the TOE in the ST. CSC: User Guidance manuals have a ‘Equipment Requirement’ page which details the computer platforms and peripheral devices for the TOE’s claimed in the ST. Table 23: Referenced documents Document Reference (see document references in Section 2.1) [C] Assurance Activity Report v1.0 Computer platforms and peripheral devices claimed Page 12-13 Page 67 HSL Secure KM Switch Switch 4.23 ATE_IND.1 Independent Testing - Conformance Assurance Activities: The evaluator shall prepare a test plan and report documenting the testing aspects of the system. The test plan covers all of the testing actions contained in the CEM and the body of this PP’s Assurance Activities. While it is not necessary to have one test case per test listed in an Assurance Activity, the evaluator must document in the test plan that each applicable testing requirement in the PP is covered. The test plan identifies the platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification must address the differences between the tested platforms and the untested platforms and make an argument that the differences do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no affect; rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary. The test plan describes the composition of each platform to be tested and any setup that is necessary beyond what is contained in the AGD documentation. It should be noted that the evaluator is expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. This may include special test equipment or tools. For each piece of equipment or tool, an argument (not just an assertion) should be provided that the equipment or tool will not adversely affect the performance of the functionality by the TOE and its platform. The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results. The test report (which could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the report would show a “fail” and “pass” result (and the supporting details), and not just the “pass” result. Testing Summary While it is not necessary to have one test case per test listed in an Assurance Activity, the evaluator must document in the test plan that each applicable testing requirement in the PP is covered. CSC: The test cases conducted in testing were organized exactly as presented in the PP. For example, test case 4.1 in the actual testing replicates exactly test case 4.1 from the PP, including all test steps presented in the PP. The Test Report identifies which steps are specific to the switches tested and identifies how test tools were used during testing. The test plan describes the composition of each platform to be tested and any setup that is necessary beyond what is contained in the AGD documentation. It should be noted that the evaluator is expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. Assurance Activity Report v1.0 Page 68 HSL Secure KM Switch Switch CSC: Sections 3.2 and 3.3 of this document describe each platform tested, what tools and what setup was necessary for that platform. This may include special test equipment or tools. For each piece of equipment or tool, an argument (not just an assertion) should be provided that the equipment or tool will not adversely affect the performance of the functionality by the TOE and its platform. CSC: The Test Report identifies how test tools were used during testing in the annexes of the test report. The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results. The test report (which could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the report would show a “fail” and “pass” result (and the supporting details), and not just the “pass” result. CSC: The actual test cases executed are provided in a separate document. The testing is replicated from the PP along with all actual results from the testing. In this report, each of the assurance activities in the SFRs above provide a summarization of the testing conducted along with a sample of pictures of important test steps to show representation of how testing was conducted. Assurance Activity Report v1.0 Page 69 HSL Secure KM Switch Switch 4.24 ALC_CMC.1 Labeling of the TOE Assurance Activities: The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a web site advertising the TOE, the evaluator shall examine the information on the web site to ensure that the information in the ST is sufficient to distinguish the product. Additionally, the evaluator shall verify that the labels required by FPT_PHP.1 are present and intact, as follows: 1) 2) 3) The TOE is labeled with at least one unique identifying tamper-evident marking (such as unique serial number) that can be used to authenticate the device. Tamper evident labels have been placed in critical locations on the TOE enclosure to assure that any attempt to open the enclosure enough to gain access to its internal components will change at least one label to a tampered state. at least one tamper evident label is placed in a location that will be visible to the user operating the TOE. TSS Verification The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. CSC: In the ST, Table 2 in Section 1.3.2.1 identifies every switch in the evaluation along with a unique part number and unique evaluation version (33333-C4C4). Operational Guidance Verification Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. CSC: Each of the switches delivered to the user has a switch version number stamped on a plate. The version number is the same format in the ST. Additionally the samples delivered to the lab for testing were verified against the ST. The picture below is an example of the SM40NU-3 Switch with a version of 30333-00C4, which matches row 3 on table 2 of the ST for the switch. The test report contains pictures of all version of switches provided for testing. Assurance Activity Report v1.0 Page 70 HSL Secure KM Switch Switch If the vendor maintains a web site advertising the TOE, the evaluator shall examine the information on the web site to ensure that the information in the ST is sufficient to distinguish the product. CSC: The ST specifies in Section 1.4.1 “The accompanying User Guidance and Administrator Guidance can be downloaded from High Sec Labs website: http://highseclabs.com/page/?pid=23 at any time.” Testing Summary Additionally, the evaluator shall verify that the labels required by FPT_PHP.1 are present and intact, as follows: 1) The TOE is labeled with at least one unique identifying tamper-evident marking (such as unique serial number) that can be used to authenticate the device. 2) Tamper evident labels have been placed in critical locations on the TOE enclosure to assure that any attempt to open the enclosure enough to gain access to its internal components will change at least one label to a tampered state. at least one tamper evident label is placed in a location that will be visible to the user operating the TOE. 3) CSC: The picture provided in Test 4.13 for FPT_PHP shows an example of the tamper evident labels placed on the TOE. It clearly shows the tamper evident label is clearly visible and on a critical spot on the switch where two plastic covers come together. The following pictures are further examples of tamper evident labels clearly showing a serial number: Assurance Activity Report v1.0 Page 71 HSL Secure KM Switch Switch HSL SM40NU-3 KM TOE - Tamper Evident Label positioned at both sides covering the front panel and the top enclosure cover Assurance Activity Report v1.0 Page 72 HSL Secure KM Switch Switch 4.25 ALC_CMS.1 TOE CM Coverage Assurance Activities: The “evaluation evidence required by the SARs” in this PP is limited to the information in the ST coupled with the guidance provided to administrators and users under the AGD requirements. By ensuring that the TOE is specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component. Assurance Activity Report v1.0 Page 73 HSL Secure KM Switch Switch 5 Conclusions and Recommendations The overall verdict for the evaluation is PASS, hence, it is concluded that the TOE in its evaluated configuration meets all Peripheral Switch Protection Profile requirements. The evaluators recommend that the consumers of this product understand and use all of the appropriate secure configuration requirements recommended in each of the user guidance documents provided to ensure that the secure configuration is achieved. Assurance Activity Report v1.0 Page 74 HSL Secure KM Switch Switch 6 List of Evaluation Evidence 1. HSL Secure KM Security Target, version 3.14 2. HSL SECURE KM SWITCH 2/4/8 PORT USER MANUAL, Rev F 3. HSL KM Configuration Manual, Rev B 4. HSL fUSB Configuration Manual, Rev C 5. HSL Administrator Guide, Rev C 6. Isolation Documentation High Sec Labs Secure KVM Switch, KM, Isolator and Combiner KVM, version 3.01 7. Letter of Volatility – HSL Secure KM, Rev C Assurance Activity Report v1.0 Page 75 HSL Secure KM Switch Switch 7 Product Compliance Listing Entry Provided as a separate document Assurance Activity Report v1.0 Page 76 HSL Secure KM Switch Switch 8 List of Acronyms/Glossary of Terms Common Criteria specific terminology is defined in CC Part 1. Table 24 below identifies commonly used acronyms and terminology used in the ETR that requires clear definition. Table 24: Acronyms & terms Term Definition AC Access Control API Application Programming Interface ARC TOE Architecture CC Common Criteria CCEVS Common Criteria Evaluation Validation Scheme CEM Common Methodology for Information Technology Security Evaluation CLI Command Line Interface EAL Evaluation Assurance Level ETR Evaluation Technical Report FIPS Federal Information Processing Standards FSP Functional Specification FTP File Transfer Protocol GUI Graphical User Interface HTTP Hypertext Transfer Protocol HTTPS HTTP Secure IP Internet Protocol IT Information Technology ITSL IT Security Laboratory NIAP National Information Assurance Partnership PP Protection Profile SAR Security Assurance Requirement SFR Security Functional Requirement SSL Secure Socket Layer ST Security Target STCL Security Testing and Certification Laboratory TDS TOE Design TLS Transport Layer Security TOE Target of Evaluation TSF TOE Security Functionality TSFI TSF Interface Assurance Activity Report v1.0 Page 77 HSL Secure KM Switch Switch TSS TOE Summary Specification Assurance Activity Report v1.0 Page 78 HSL Secure KM Switch Switch 9 Rational for Products Selected 9.1 Overview The number of tests that the new PP requires is exceptionally high compared to other protection profiles. We think that in this case, it is a better approach to select the minimum number of products that properly representing the full set. Any additional products that will be tested will waste time and money and also would allow us to focus on the more meaningful tests. Duplication of tests on different product derivatives sharing same security implementations would not generate any security benefits here. 9.2 Rationale for test coverage of multiple TOE models The primary differences between the various evaluated products are:    The type of KVM – Isolator, Filter, Switch, KM and Combiner and MDR; Single versus dual-head models. Dual-head models are identical to single-head models but having extra instances of video boards; and Models with and without fUSB (DPP) function. All TOE models are sharing the same firmware and significant similarities in the hardware designs. The development and production processes of the different models are identical. Test Case Product model TOE Type Represented models E SM40NU-3 Secure KM Switch SM20N-3, SM40N-3, SM40NU3, SM80N-3, SM80NU-3 Table 25: TOE model used for testing Refer to the HSL Secure KVM Security Target document for a list of the claimed SFR’s. The Design Documentation describes a low-level breakdown of the TOE including firmware logic and circuitry. Review of this document shows how the circuitry is extended to include more ports for the 2, 4, and 8 port models. Because the number of ports on the KVM switch has no effect on the security threats associated with it, it is adequate to test a specific function on one product with arbitrary number of channels. Assurance Activity Report v1.0 Page 79 HSL Secure KM Switch Switch 9.3 Justification for Selection made by HSL The following paragraphs provide detailed explanation and rationale behind the selection of specific TOE models for testing. It should be noted that the particular PP requires the longest set of tests of any other PPs that exist today. The proper selection of products is therefore critical to assure that full features and risks would be covered on one hand and that the scope of testing effort would be manageable on the other hand. 9.3.1 Secure KM Switch (Group E) System Controller Functions Configuration utility Description 12 SM20N-3 2 ● ● HSL Secure SH KM 2-Port, No video, PP 3.0 32 SM40N-3 4 ● ● HSL Secure SH KM Switch 4-Port No video, PP 3.0 33 SM40NU-3 4 ● ● 45 SM80N-3 8 ● ● Same ● (d Firmware Model FUSB (DPP) N o Number of ports The model selected for testing is SM40NU-3. HSL Secure SH KM Switch 4-Port No video, w/fUSB, PP 3.0 HSL Secure SH KM Switch 8-port, PP 3.0 Table 26: KM models differences coverage The KM product line is sharing the same system controller board design with different number of channels. The only significant difference between models is the number of computer channels assembled on the board (2, 4 or 8). Note that the unique enclosure related security functions are already covered by other groups (2, 4 and 8 ports). One of the models (SM40NU-3 that was selected) got also fUSB function. In the tradeoff between that model and the 8-Port model we decided to select first as we feel that there are more security consequences to the fUSB option in a KM than to the number of channels. The number of channels would not add any significant information to the testing – it would just make it longer. Note that the configuration utility used to load displays configuration to all TOE models is identical (not evaluated but used for testing). Therefore the selection of the SM40NU-3 model for testing provides the best coverage of the four KM TOE models. All security functions are covered by this selected device. Assurance Activity Report v1.0 Page 80 HSL Secure KM Switch Switch 9.4 Summery Overall the current selection of products for each group provides good coverage of all required functions: 9.4.1 Number of ports / enclosures Ports Covered by Groups 4 E Table 27: Number of ports coverage 9.4.1 Operation Mode Op. Mode Covered by Groups KM E Table 28: Operation mode coverage 9.4.2 fUSB function Supported fUSB Covered by Groups Yes E Table 29: fUSB options coverage Assurance Activity Report v1.0 Page 81