Document Version 1.4 Jan 2016 Page 1 of 22 Thinklogical TLX640 Matrix Switch Security Target Document Version 1.4 T L X 6 4 0 Prepared by Thinklogical Document Version 1.4 Jan 2016 Page 2 of 22 Table of Contents 1 SECURITY TARGET INTRODUCTION...............................................................................3 1.1 SECURITY TARGET AND TOE IDENTIFICATION.......................................................................3 1.2 SECURITY TARGET OVERVIEW ...............................................................................................3 1.3 COMMON CRITERIA CONFORMANCE.......................................................................................4 1.4 CONVENTIONS ........................................................................................................................4 2 TOE DESCRIPTION .................................................................................................................5 2.1 SYSTEM TYPE AND OVERVIEW ...............................................................................................5 2.2 TOEPHYSICAL BOUNDARIES .................................................................................................7 2.3 TOE LOGICAL BOUNDARIES...................................................................................................7 3 SECURITY PROBLEM DEFINITION ...................................................................................8 3.1 SECURE USAGE ASSUMPTIONS ...............................................................................................8 3.2 THREATS.................................................................................................................................9 3.3 ORGANIZATIONAL SECURITYPOLICIES ..................................................................................9 4 SECURITY OBJECTIVES .....................................................................................................10 4.1 SECURITYOBJECTIVES FOR THE TOE...................................................................................10 4.2 SECURITYOBJECTIVES FOR THE ENVIRONMENT ...................................................................10 5 SECURITY REQUIREMENTS..............................................................................................12 5.1 TOESECURITYFUNCTIONAL REQUIREMENTS .....................................................................12 5.1.1 User Data Protection (FDP)........................................................................................12 5.1.1.1 FDP_ETC.1 Export of user data without security attributes.................................12 5.1.1.2 FDP_IFC.1 Subset information flow control ........................................................12 5.1.1.3 FDP_IFF.1 Simple security attributes ...................................................................12 5.1.1.4 FDP_ITC.1 Import of user data without security attributes..................................13 5.2 TOESECURITY ASSURANCE REQUIREMENTS.......................................................................13 5.2.1 ASSURANCE COMPONENTS.................................................................................................13 6 TOE SUMMARY SPECIFICATION.....................................................................................14 6.1 TOESECURITYFUNCTIONS..................................................................................................14 6.1.2 User Data Protection ...................................................................................................14 6.2 ASSURANCE MEASURES .......................................................................................................14 7 RATIONALE..............................................................................................................................16 7.1 RATIONALE FOR SECURITYOBJECTIVES...............................................................................16 7.2 RATIONALE FOR SECURITYOBJECTIVES FOR THE ENVIRONMENT ........................................17 7.3 SECURITY REQUIREMENTS RATIONALE ................................................................................19 7.4 SECURITY ASSURANCE RATIONALE......................................................................................20 7.5 RATIONALE FOR SATISFYINGALL DEPENDENCIES ................................................................20 7.6 TOESECURITYFUNCTIONS RATIONALE ..............................................................................21 8 ACRONYMS.............................................................................................................................22 Document Version 1.4 Jan 2016 Page 3 of 22 1 Security Target Introduction 1.1 Security Target and TOE Identification Security Target Title: Thinklogical TLX640 Matrix Switch Security Target ST Author: Thinklogical TOE Identification: TLX640 Matrix Switch Chassis (TLX-MSC-000640 Rev B) TLX640 Matrix Switch Data Input and Output Card, 20 Ports, SFP+, Multi-Mode (TLX-MSD-M00020 Rev C), Single Mode (TLX-MSD-S00020 Rev C) Velocity Matrix Switch 640 Data Input and Output Card, 20 Ports, SFP+, Multi- Mode (VXM-DIOR20 Rev A), Single-Mode (VXM-DIOS20 Rev A) Common Criteria Version: 3.1 Revision 4 Assurance Level: EAL4 PP Identification: None 1.2 Security Target Overview Thinklogical TLX640 Matrix Switch is a fiber optic switch that uses multi-mode or single-mode fiber optics to transmit and receive a digital video pulse stream without alteration or interpretation of the original signal. Embedded keyboard, mouse, USB 1.1, USB 2.0 (high speed up to 480 Mbps), and audio signals are also transmitted. The TLX640 provides reliability and signal integrity with high performance 6.25Gbps and 10.3125Gbps capability. Scalable up to a 640 x 640 port group, this highly robust KVM Matrix Switch is used with the Thinklogical™ Velocity extender series and the Thinklogical™ TLX extender series. The Switch includes pluggable cards which allow changing the number of supported ports in groups of 20. The TOE provides remote connections from a set of shared computers to a set of shared peripherals. The switching capability of the TOE is used to connect ports on a particular computer to a particular peripheral set. The corresponding electronic signal from a computer port is transformed into an optical signal by the Velocity and or TLX extender, transmitted through an optical fiber, switched by the KVM Matrix Switch to another optical fiber, and then transformed back to an electronic form by the Velocity and or TLX extender. The resulting signal is used by the shared peripherals. The TOE provides a capability to dynamically change the switching configuration to connect a particular computer to a particular peripheral set. The TOE enforces secure separation of information flows corresponding to different switched connections. The corresponding Data Separation Security Policy is the main security feature of the TOE. Document Version 1.4 Jan 2016 Page 4 of 22 1.3 Common Criteria Conformance Common Criteria: Part 2 and Part 3 conformant. Assurance Level: EAL4. 1.4 Conventions The notation, formatting, and conventions used in this ST are consistent with version 3.1 of the Common Criteria (CC). The CC allows several operations to be performed on functional requirements; refinement, selection, assignment, and iteration. The refinement operation is used to add detail to a requirement, and thus further restricts a requirement. Refinement of security requirements is denoted by bold text. Deleted words are denoted by strikethrough text. The selection operation is used to select one or more options provided by the CC in stating a requirement. Selections are denoted by italicized text. The assignment operation is used to assign a specific value to an unspecified parameter, such as the length of a password. Assignment is indicated by showing the value in square brackets, [Assignment_value]. The iteration operation is used when a component is repeated with varying operations. Iteration is denoted by showing the iteration number in parenthesis following the component identifier, (iteration_number). The CC paradigm also allows protection profile (PP) and security target authors extended components. In this ST, extended components will be indicated with the “_EXT” following the component name. Assumptions: TOE secure usage assumptions are given names beginning with “A.”-- e.g., A.ACCESS. Threats: Threats are given names beginning with “T.”-- e.g., T.COMINT. Policies: Organizational Security Policies are given names beginning with “P.”-- e.g., P.CRYPTOGRAPHY. Objectives: Security objectives for the TOE and the TOE environment are given names beginning with “O.” and “OE.”, respectively,—e.g., O.CRYPTOGRAPHY and OE.INSTAL. Document Version 1.4 Jan 2016 Page 5 of 22 2 TOE Description 2.1 System Type and Overview The TOE is a 640 x 640 routing system, which provides connection of 640 optical inputs located on the upper and lower card cage ports to any or all of the 640 optical outputs located on the same upper and lower card cage ports. The TOE consists of 32 Data Input and Output Cards having 20 optical input and output ports. The TOE supports any combination of legacy Velocity VX based IO cards or the new TLX IO cards. The 32 Data Input and Output Cards installed in the upper and lower card cages can be used to connect any of the 640 inputs, in one direction, to any output or multiple outputs. Any combination of Transmitter Port – forward channel to Receiver Port – forward channel or Receiver Port – back channel to Transmitter Port back channel are supported. Each of the 32 Data Input and Output Cards connects to each of eight 160x160 switch cards through a passive backplane. The TOE allows for remote operation of shared computers using sets of shared peripherals, dynamically connecting (switching) physical ports on a particular computer to a particular shared peripheral set. The TOE consists of the following hardware devices: 1. Thinklogical KVM Matrix Switch (TLX640 Matrix Switch) 2. 32 Data Input and Output Cards (any combination of VX or TLX IO Cards) . Each Transmitter and Receiver Port Group is composed of two ports: T port and R port. Two optical cables are then required to connect a Velocity and or TLX Transmitter or Receiver Extender to a Transmitter or Receiver Port Group on the Switch. One cable is used to transmit data from the Extender to the Switch; the other cable is used to transmit data from the Switch to the Extender. As a result, a bi- directional connection is established, where data can flow in both directions. All data types, including video, audio and serial data are converted to an optical form and transmitted in a single optical cable. The purpose of the Switch is to establish logical connections between Transmitter and Receiver Port Groups, while preserving Data Separation Security Function Policy (SFP). Data Separation Security Function Policy (SFP) states that data shall flow between Transmitter Port group A and Receiver Port group B if and only if a deliberate logical connection has been established to connect A to B. There shall be no data flow between any pair of Transmitter Port Groups or Receiver Port Groups. There shall be no data flow between Transmitter Port Groups or Receiver Port Groups and any other physical port on the Switch. The use of a restrict or partition table in the system overrides any deliberate logical connection established between Transmitter Port A and Receiver Port B since the restrict policy disallows connection of a higher priority input to a lower priority output and the partition policy disallows connection of an input from one partition going to the output of another partition. The TOE connections are first controlled by restrict and priority tables and then controlled, if not in conflict with the restrict or partition tables, over the serial RS-232/console interface or a 10/100/1000BASE-T LAN connection. The Thinklogical TLX640 Matrix Switch is depicted in Figure 1a. Document Version 1.4 Jan 2016 Page 6 of 22 Figure 1a. Thinklogical TLX640 Matrix Switch Document Version 1.4 Jan 2016 Page 7 of 22 Figure 2a. Typical TOE TLX640 Configuration 2.2 TOE Physical Boundaries TLX640 Matrix Switch is a hardware device. TOE Physical Boundaries then correspond to the physical boundaries of the device enclosure. 2.3 TOE Logical Boundaries TOE logical boundaries include all software and firmware components inside the TLX640 Matrix Switch. The following Security Functions are provided by the TOE  User Data Protection (enforces Data Separation SFP), This Security Target includes all product security features. There are no security features outside the scope of the evaluation. Document Version 1.4 Jan 2016 Page 8 of 22 3 Security Problem Definition This section describes the assumptions, threats, and policies that are relevant to both the TOE and the Operational Environment. Note: there is currently no Protection Profile directly applicable to the type of technology provided by the TOE. Peripheral Sharing Switch (PSS) For Human Interface Devices Protection Profile Version 1.2 (PSSPP) is applicable to the situation, where there is a single set of peripherals locally managing multiple computers. In the case of the TOE there are multiple sets of peripherals remotely managing multiple computers. The aim of this Security Target is to stay close to the requirements of the PSSPP generalizing them for the case of multiple sets of peripherals and remote connectivity. 3.1 Secure Usage Assumptions The TOE is physically protected and managed as required for the highest level of security classified data handled or transferred by the TOE. The following Table defines the Secure Usage Assumptions. Table 1: Secure Usage Assumptions Assumption Definition A.PHYSICAL The switch, the transmitters, the receivers, the optical connections from the Switch to the transmitters and receivers and the wired network connections from the Switch to the administrators are physically secure. Note: The TOE does not encrypt optical or wired network connections. Therefore, such connections need to be physically secured. Note: A similar assumption exists in PSSPP. In the case of PSSPP connections from the TOE to the set of peripherals and to the managed computers are short-distance local connections. Therefore, PSSPP does not raise questions regarding physical security of physical connections. In present case due to the long-distance nature of the connections, separate care must be given to physically securing optical and network connections. As an example, an outdoor optical connection may be subject to eavesdropping. A.EMISSION The TOE meets the appropriate national requirements (in the country where used) for conducted/radiated electromagnetic emissions. [In the United States, Part 15 of the FCC Rules for Class B digital devices. Note: a similar assumption exists in PSSPP. A.MANAGE The TOE is installed and managed in accordance with the manufacturer’s directions. Note: a similar assumption exists in PSSPP. A.NOEVIL The TOE users and administrators are non-hostile and follow all usage guidance. Note: a similar assumption exists in PSSPP. A hostile user could easily circumvent the security restrictions, by, e.g. switching to a classified Computer1, copying a file from Computer1 to a USB drive, then switching to an unclassified Computer2 and copying the file from the USB drive to Computer2. The Data Separation SFP may only be effective if the users do not intentionally violate the SFP. Document Version 1.4 Jan 2016 Page 9 of 22 Table 1: Secure Usage Assumptions (continued) Assumption Definition A.SCENARIO Vulnerabilities associated with attached devices are a concern of the application scenario and not of the TOE. Note: a similar assumption exists in PSSPP. The TOE is not intended to mitigate or protect against security vulnerabilities in the attached devices. 3.2 Threats The asset under attack is the information transiting the TOE. The threat agent is most likely people with TOE access that possess average expertise, with few resources, and moderate motivation. Another threat is a failure of the TOE or peripherals. The following Table defines the Threats to Security. Table 2: Threats Threat Definition T.INSTALL The TOE may be delivered and installed in a manner which violates the security policy. Note: a similar threat exists in PSSPP. T.ATTACK An attack on the TOE may violate the security policy. Note: a similar threat exists in PSSPP. T.RESIDUAL Residual data may be transferred between different port groups in violation of data separation security policy. Note: a similar threat exists in PSSPP. T.STATE State information may be transferred to a port group other than the intended one. Note: a similar threat exists in PSSPP 3.3 Organizational Security Policies There are no Organizational Security Policies claimed in this ST. Document Version 1.4 Jan 2016 Page 10 of 22 4 Security Objectives This section identifies the security objectives of the TOE and its supporting environment. The security objectives identify the responsibilities of the TOE and its environment in meeting the security needs. 4.1 Security Objectives for the TOE The following are the TOE Security Objectives. Table 3: Security Objectives for the TOE O.CONF The TOE shall not violate the confidentiality of information which it processes. Information generated within any peripheral set/computer connection shall not be accessible by any other peripheral set/computer connection. Note: a similar objective exists in PSSPP. O.CONNECT No information shall be shared between switched computers and peripheral sets via the TOE in violation of Data Separation SFP. Note: a similar objective exists in PSSPP. This ST adds the requirement that information shall not be shared between peripheral sets. 4.2 Security Objectives for the Environment All of the Secure Usage Assumptions are considered to be Security Objectives for the Environment. These Objectives are to be satisfied without imposing technical requirements on the TOE; they will not require the implementation of functions in the TOE hardware and/or software, but will be satisfied largely through application of procedural or administrative measures. Document Version 1.4 Jan 2016 Page 11 of 22 Table 4: Security Objectives for the Environment Security Objective for the Environment OE.EMISSION The TOE shall meet the appropriate national requirements (in the country where used) for conducted/radiated electromagnetic emissions. [In the United States, Part 15 of the FCC Rules for Class B digital devices. Note: a similar objective exists in PSSPP. OE.MANAGE The TOE shall be installed and managed in accordance with the manufacturer’s directions. Note: a similar objective exists in PSSPP. OE.NOEVIL The authorized user shall be non-hostile and follow all usage guidance. Note: a similar objective exists in PSSPP. OE.PHYSICAL The Switch, the transmitters, the receivers, the optical connections from the Switch to the transmitters and receivers and the wired network connections from the TOE to the administrators shall be physically secure. Note: The TOE does not encrypt optical or wired network connections. Therefore, such connections need to be physically secured. Note: A similar objective exists in PSSPP. In the case of PSSPP connections from the TOE to the peripheral sets and to the managed computers are short-distance local connections. Therefore, PSSPP does not raise questions regarding physical security of such connections. In the case of the TOE separate care must be given to physically securing optical and network connections. OE.SCENARIO Vulnerabilities associated with attached devices or their connections to the TOE, shall be a concern of the application scenario and not of the TOE. Note: a similar objective exists in PSSPP. The TOE does not mitigate vulnerabilities in attached devices. Document Version 1.4 Jan 2016 Page 12 of 22 5 Security Requirements This section defines the functional requirements for the TOE that are relevant to supporting the secure operation of the TOE, as well as the assurance requirements for the TOE. 5.1 TOE Security Functional Requirements Most of the TOE Security Functional Requirements are similar to those of PSSPP. The remaining FIA and FMT requirements are handled by the external management and user interface and are not part of the TOE. This external management computer commands the TOE by either the LAN or the Serial (RS232) connections that are physically secure. Table 5: TOE Security Functional Requirements TOE Security Functional Requirements FDP_ETC.1 Export of User Data Without Security Attributes FDP_IFC.1 Subset information flow control FDP_IFF.1 Simple security attributes FDP_ITC.1 Import of User Data Without Security Attributes 5.1.1 User Data Protection (FDP) 5.1.1.1 FDP_ETC.1 Export of user data without security attributes FDP_ETC.1.1 The TSF shall enforce the [Data Separation SFP] when exporting user data, controlled under the SFP, from outside of the TOE. FDP_ETC.1.2 The TSF shall export the user data without the user data's associated security attributes. 5.1.1.2 FDP_IFC.1 Subset information flow control FDP_IFC.1.1 The TSF shall enforce the [Data Separation SFP] on [the set of Transmitter and Receiver Port Groups, and the bi-directional flow of data and state information between the shared peripherals and the switched computers]. 5.1.1.3 FDP_IFF.1 Simple security attributes FDP_IFF.1.1 The TSF shall enforce the [Data Separation SFP] based on the following types of subject and information security attributes: [Transmitter and Receiver Port Groups (subjects), peripheral data and state information (objects), port group IDs, logical connections of Transmitter and Receiver Groups (attributes)]. FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [peripheral data and state information can only flow between Transmitter and Receiver port groups that have been previously logically connected by the administrator using the TOE management interface]. FDP_IFF.1.3 The TSF shall enforce a [Transmitter Port Group may be logically connected to multiple Receiver Port Groups, out of which bi-directional information flow will be established only with a single Primary Receiver Port Group selected by the administrator. The remaining Non-Primary Receiver port groups will only receive unidirectional multicast audio and video signals. Any Receiver Port Group may only be logically connected to a single Transmitter Port Group]. Document Version 1.4 Jan 2016 Page 13 of 22 FDP_IFF.1.4 The TSF shall explicitly authorize an information flow based on the following rules: [no additional rules]. FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following rules: [No data or state information flow shall be allowed between logically unconnected port groups. No data or state information flow shall be allowed between any two Receiver Port Groups. No data or state information flow shall be allowed between any two Transmitter Port Groups. No data or state information flow shall be allowed between any Receiver or Transmitter Port Group and any other non-optical physical port on the Switch]. 5.1.1.4 FDP_ITC.1 Import of user data without security attributes FDP_ITC.1.1 The TSF shall enforce the [Data Separation SFP] when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.1.2 The TSF shall ignore any security attributes associated with the user data when imported from outside the TOE. FDP_ITC.1.3 The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: [no additional rules]. 5.2 TOE Security Assurance Requirements This section defines the assurance requirements for the TOE as EAL4 requirements. 5.2.1 Assurance components The table below summarizes the components for EAL4. Table 6: TOE Security Assurance Requirements (EAL4) Assurance Class Assurance Component Life Cycle Support ALC_CMC.4 Product support, acceptance procedures and automation ALC_CMS.4 Problem tracking CM coverage ALC_DEL.1 Delivery procedures ALC_DVS.1 Identification of security measures ALC_LCD.1 Developer defined life-cycle model ALC_TAT.1 Well-defined development tools Development ADV_ARC.1 Security Architectural Description ADV_FSP.4 Complete functional specification ADV_IMP.1 Implementation of the TSF ADV_TDS.3 Basic modular design Guidance Documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative User guidance Tests ATE_COV.2 Analysis of coverage ATE_DPT.2 Testing: security enforcing modules ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample Vulnerability assessment AVA_VAN.3 Focused vulnerability analysis Document Version 1.4 Jan 2016 Page 14 of 22 6 TOE Summary Specification This section addresses IT security functions and the corresponding assurance measures. 6.1 TOE Security Functions The TOE includes the following Security Functions: 1. User Data Protection – this security function is used to enforce the Data Separation SFP. 6.1.2 User Data Protection The TOE logically connects Transmitter and Receiver Port Groups according to the current switching configuration. The data flows between a particular Transmitter Port Group and a set of Receiver Port Groups if and only if there is an active logical connection connecting these. If there are multiple Receiver Port Groups connected to a Transmitter Port Group, bi-directional information flow will be then established between the Primary Receiver Port Group and the Transmitter Port Group. The remaining Non-Primary Receiver Port Groups will receive uni-directional multi-cast video and audio signals from the Transmitter Port Group. 6.2 Assurance Measures The assurance measures addressed in this section apply to the EAL 4 requirements and are presented in the following table. Table 7: Assurance Measures Assurance Requirement Name Assurance Measure ALC_CMC.4 Product support, acceptance procedures and automation Thinklogical Product Support Plan and Procedures Thinklogical Acceptance Plan and Procedures ALC_CMS.4 Problem tracking CM coverage Thinklogical Configuration Management Plan and Procedures ALC_DEL.1 Delivery procedures Thinklogical Delivery Plan and Procedures ALC_DVS.1 Identification of security measures Thinklogical Security Measures Plan and Procedures ALC_LCD.1 Developer defined life-cycle model Thinklogical Life-Cycle Model Plan and Procedures ALC_TAT.1 Well-defined development tools Thinklogical Development Tools Plan and Procedures ADV_ARC.1 Security Architectural Description Thinklogical Security Architectural Description Document ADV_FSP.4 Complete functional specification Thinklogical Functional Specification Document ADV_IMP.1 Implementation of the TSF Thinklogical TSF implementation ADV_TDS.3 Basic modular design Thinklogical High-Level Design Document AGD_OPE.1 Operational user guidance Thinklogical Operational User Guidance AGD_PRE.1 Preparative User guidance Thinklogical Preparative User Guidance ATE_COV.2 Analysis of coverage Thinklogical Analysis of Coverage Document Document Version 1.4 Jan 2016 Page 15 of 22 ATE_DPT.2 Testing: security enforcing modules Thinklogical Testing Setup Document Thinklogical Security Enforcing Modules Testing Plan and Procedures Thinklogical Security Enforcing Modules Testing Report ATE_FUN.1 Functional testing Thinklogical Testing Setup Document Thinklogical Functional Testing Plan and Procedures Thinklogical Functional Testing Report ATE_IND.2 Independent testing – sample Thinklogical Testing Setup Document Lab Independent Testing Report AVA_VAN.3 Focused vulnerability analysis Thinklogical Testing Setup Document Lab Vulnerability Analysis Report Document Version 1.4 Jan 2016 Page 16 of 22 7 Rationale This section provides the rationale for the selection of the IT security requirements, objectives, assumptions, and threats. In particular, it shows that the IT security requirements are suitable to meet the security objectives, which in turn are shown to be suitable to cover all aspects of the TOE security environment. 7.1 Rationale for Security Objectives The following table provides mapping of threats to objectives and the corresponding rationale. Table 8: Security Objectives Rationale Threat Objective Rationale T.INSTALL The TOE may be delivered and installed in a manner which violates the security policy OE.MANAGE The TOE shall be installed and managed in accordance with the manufacturer’s directions. T.ATTACK An attack on the TOE may violate the security policy. O.CONF Information generated within any peripheral set/computer connection shall not be accessible by any other peripheral group/computer connection. Otherwise, the security policy is violated. T.RESIDUAL Residual data may be transferred between different port groups in violation of data separation security policy O.CONF O.CONNECT The requirement that information generated within any peripheral group/computer connection shall not be accessible by any other peripheral group/computer connection includes the residual information. No information shall be shared between switched computers and sets of peripherals via the TOE in violation of data separation security policy. This includes the residual information. T.STATE State information may be transferred to a port group other than the intended one. O.CONF O.CONNECT The requirement that information generated within any peripheral group/computer connection shall not be accessible by any other peripheral group/computer connection includes the state information. No information shall be shared between switched computers and sets of peripherals via the TOE in violation of data separation security policy. This includes the state information. Document Version 1.4 Jan 2016 Page 17 of 22 Table 9: Mapping of Threats to Security Objectives Objective O.CONF O.CONNECT OE.MANAGE T.INSTALL X T.ATTACK X T.RESIDUAL X X T.STATE X X 7.2 Rationale for Security Objectives for the Environment All of the Security Objectives for the Environment are considered to be Secure Usage Assumptions. These objectives on the environment do not contain any IT security requirements because they are non- IT related objectives. Thus, the CC does not mandate it map to any requirements. Mapping of Assumptions to the Security Objectives for the Environment including the corresponding rationale is provided below. Table 10: Security Objectives for the Environment Rationale Assumption Objective Rationale A.PHYSICAL The TOE, the optical connections from the TOE to the transmitters and receivers and the wired network connections from the TOE to the users are physically secure. OE.PHYSICAL The TOE shall be physically secure. The TOE is assumed to be protected from physical attack (i.e. theft, modification, reconfiguration, or eavesdropping). Physical attack could include unauthorized intruders into the TOE environment, but it does not include physical destructive actions that could be taken by an individual that is authorized to access the TOE environment. A.EMISSION The TOE meets the appropriate national requirements (in the country where used) for conducted/radiated electromagnetic emissions. [In the United States, Part 15 of the FCC Rules for Class B digital devices.] OE.EMISSION The TOE shall pass testing for conducted/radiated electromagnetic emissions, Part 15 of the FCC Rules for Class B digital devices. TOE chassis construction is such that emissions will be below that of the appropriate national requirements (in the country where used) for conducted/radiated electromagnetic emissions. [In the United States, Part 15 of the FCC Rules for Class B digital devices.] Document Version 1.4 Jan 2016 Page 18 of 22 Table 10: Security Objectives for the Environment Rationale (continued) Assumption Objective Rationale A.MANAGE The TOE is installed and managed in accordance with the manufacturer’s directions. OE.MANAGE The TOE shall be installed and managed in accordance with the manufacturer’s directions. Complying with Manufacturers documentation for installation and operation assures that the TOE is operating properly. A.NOEVIL The TOE users are non-hostile and follow all usage guidance. OE.NOEVIL The TOE users shall be non-hostile and follow all usage guidance. Correct usage of the TOE assures operation as expected. A.SCENARIO Vulnerabilities associated with attached devices are a concern of the application scenario and not of the TOE. OE.SCENARIO Vulnerabilities associated with attached devices shall be a concern of the application scenario and not of the TOE. Vulnerabilities associated with attached devices due to an application scenario are a concern of the application scenario and not that of the TOE. Document Version 1.4 Jan 2016 Page 19 of 22 7.3 Security Requirements Rationale This section demonstrates that the functional components selected for the TOE provide complete coverage of the defined TOE security objectives. Table 11: Security Requirements Rationale Objective Security Requirement Rationale O.CONF The TOE shall not violate the confidentiality of information which it processes. Information generated within any peripheral group/computer connection shall not be accessible by any other peripheral group/computer connection. FDP_ETC.1 (Export of User Data Without Security Attributes) FDP_IFC.1 (Subset Information Flow Control) FDP_IFF.1 (Simple Security Attributes) FDP_ITC.1 (Import of User Data Without Security Attributes) The TOE enforces Data Separation SFP on user data. No security attributes are added to data going to peripheral devices. The TOE enforces Data Separation SFP which is based on establishing logical connections between Transmitter and Receiver Port Groups. Information flow is only permitted between input and Receiver Port Groups that have been logically connected. When TOE inputs user data, no security attributes are imported. O.CONNECT No information shall be shared between switched computers and sets of peripherals via the TOE in violation of data separation security policy. FDP_ETC.1 (Export of User Data Without Security Attributes) FDP_IFC.1 (Subset Information Flow Control) FDP_IFF.1 (Simple Security Attributes) FDP_ITC.1 (Import of User Data Without Security Attributes) The TOE enforces Data Separation SFP on user data. No security attributes are added to data going to peripheral devices. The TOE enforces Data Separation SFP which is based on establishing logical connections between Transmitter and Receiver Port Groups. Information flow is only permitted between input and Receiver Port Groups that has been logically connected using the TOE management interface. When TOE inputs user data, no security attributes are imported. Document Version 1.4 Jan 2016 Page 20 of 22 Table 12: Mapping of TOE Security Objectives to Security Requirements Objective FDP_ ETC.1 FDP_ IFC.1 FDP_ IFF.1 FDP_ ITC.1 O.CONF X X X X O.CONNECT X X X X 7.4 Security Assurance Rationale EAL4 was chosen to provide moderate level of assurance that is consistent with good commercial practices. The EAL is consistent with the assurance measures claimed by competitive products as well as with the PSSPP. 7.5 Rationale for Satisfying all Dependencies Each functional requirement was analyzed to determine that all dependencies were satisfied. All requirements were then analyzed to determine that no additional dependencies were introduced as a result of completing each operation. All dependencies in this ST have been satisfied. Dependencies are illustrated in the table below. Table 13: Dependencies Functional Component Dependency FDP_ETC.1 FDP_IFC.1 FDP_IFC.1 FDP_IFF.1 FDP_IFF.1 FDP_IFC.1 ** FMT_MSA.3 FDP_ITC.1 FDP_IFC.1 ** FMT_MSA.3 ** Note: FMT_MSA.3 is dependent on the Management system and is not part of the TOE. Document Version 1.4 Jan 2016 Page 21 of 22 7.6 TOE Security Functions Rationale The following table provides a mapping between security functions and security functional requirements. Table 14: Mapping between security functions and security functional requirements Functional Component User Data Protection FDP_ETC.1 X FDP_IFC.1 X FDP_IFF.1 X FDP_ITC.1 X Document Version 1.4 Jan 2016 Page 22 of 22 8 Acronyms CC Common Criteria EAL Evaluation Assurance Level IT Information Technology SFP Security Function Policy PP Protection Profile PSSPP US Government Peripheral Sharing Switch (PSS) For Human Interface Devices Protection Profile Version 1.2 ST Security Target TOE Target of Evaluation TSF TOE Security Functions TSC TSF Scope of Control TSP TOE Security Policy CSCS Customer Supplied Computer System