Document Version 1.7 May 2023 Page 1 of 28
Thinklogical
TLX48 2RU Matrix Switch
Security Target
Document Version 1.7
Prepared by Thinklogical
Document Version 1.7 May 2023 Page 2 of 28
Table of Contents
1 SECURITY TARGET INTRODUCTION............................ERROR! BOOKMARK NOT DEFINED.
1.1 SECURITY TARGET AND TOE IDENTIFICATION...................................................................................3
1.2 SECURITY TARGET OVERVIEW ...........................................................................................................3
1.3 COMMON CRITERIA CONFORMANCE...................................................................................................5
1.4 CONVENTIONS .....................................................................................................................................5
2 TOE DESCRIPTION...............................................................................................................................6
2.1 SYSTEM TYPE AND OVERVIEW ...........................................................................................................6
2.2 TOE PHYSICAL BOUNDARIES ...........................................................................................................10
2.3 TOE LOGICAL BOUNDARIES .............................................................................................................11
3 SECURITY PROBLEM DEFINITION...............................................................................................12
3.1 SECURE USAGE ASSUMPTIONS..........................................................................................................12
3.2 THREATS............................................................................................................................................13
3.3 ORGANIZATIONAL SECURITY POLICIES ............................................................................................13
4 SECURITY OBJECTIVES...................................................................................................................14
4.1 SECURITY OBJECTIVES FOR THE TOE...............................................................................................14
4.2 SECURITY OBJECTIVES FOR THE ENVIRONMENT ..............................................................................14
5 SECURITY REQUIREMENTS ...........................................................................................................16
5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS .................................................................................16
5.1.1 User Data Protection (FDP) .....................................................................................................16
5.1.1.1 FDP_ETC.1 Export of user data without security attributes..............................................16
5.1.1.2 FDP_IFC.1 Subset information flow control .....................................................................16
5.1.1.3 FDP_IFF.1 Simple security attributes................................................................................16
5.1.1.4 FDP_ITC.1 Import of user data without security attributes...............................................17
5.2 TOE SECURITY ASSURANCE REQUIREMENTS...................................................................................17
5.2.1 Assurance Components..............................................................................................................17
6 TOE SUMMARY SPECIFICATION...................................................................................................18
6.1 TOE SECURITY FUNCTIONS ..............................................................................................................18
6.1.2 User Data Protection.................................................................................................................18
6.2 ASSURANCE MEASURES....................................................................................................................18
7 RATIONALE..........................................................................................................................................20
7.1 RATIONALE FOR SECURITY OBJECTIVES...........................................................................................20
7.2 RATIONALE FOR SECURITY OBJECTIVES FOR THE ENVIRONMENT ...................................................21
7.3 SECURITY REQUIREMENTS RATIONALE............................................................................................23
7.4 SECURITY ASSURANCE RATIONALE..................................................................................................24
7.5 RATIONALE FOR SATISFYING ALL DEPENDENCIES ...........................................................................24
7.6 TOE SECURITY FUNCTIONS RATIONALE ..........................................................................................25
8 USER ROLES.........................................................................................................................................26
9 ACRONYMS ..........................................................................................................................................26
Document Version 1.7 May 2023 Page 3 of 28
1 Security Target Introduction
1.1 Security Target and TOE Identification
Security Target Title: Thinklogical TLX48 2RU Matrix Switch
Security Target
ST Author: Thinklogical
TOE Identification: TLX48 2RU Matrix Switch Chassis (TLX-MSC-020048 Rev B)
TLX48 2RU Matrix Switch Data Input/Output Card, 24 Ports, SFP+, 10G
Multi-Mode (TLX-MSD-M00024 Rev A), Single-Mode (TLX-MSD-S00024 Rev A)
TLX48 2RU Matrix Switch Data Input/Output Card, 24 Ports, SFP+, 6G
Multi-Mode (TLX-MSD-MV0024 Rev A), Single-Mode (TLX-MSD-SV0024 Rev A)
Common Criteria Version: 3.1 Revision 5
Assurance Level: EAL4 + ALC_FLR.2
PP Identification: None
1.2 Security Target Overview
Thinklogical TLX48 2RU 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 TLX48 2RU provides reliability and signal integrity with high
performance 6.25Gbps and 10.3125Gbps capability. Scalable up to 48 x 48 bi-directional ports, this
highly robust KVM Matrix Switch is used with 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 24.
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.7 May 2023 Page 4 of 28
The following table outlines the required non-TOE systems or (devices) and their security requirements.
Table 1: System Security Requirements
Device Requirement
Management Device The management device will be in a secure location and manage TOE by either
the LAN or the Serial (RS232) connections that are physically secure.
TLX Transmitter
Extender
The TLX transmitter extender will be in a secure location
TLX Receiver
Extender
The TLX receive extender will be in a secure location
Velocity Transmitter
Extender
The Velocity transmitter extender will be in a secure location
Velocity Receiver
Extender
The Velocity receive extender will be in a secure location
Document Version 1.7 May 2023 Page 5 of 28
1.3 Common Criteria Conformance
Common Criteria Version: 3.1 Revision 5
Common Criteria: Part 2 and Part 3 conformant.
Assurance Level: EAL4 + ALC_FLR.2
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.
User Roles: User Roles are confined to three different types as follows: Administrator, Operator, System
user. Details can be found in Section 8.
Document Version 1.7 May 2023 Page 6 of 28
2 TOE Description
2.1 System Type and Overview
The TOE is a single matrix routing system, which provides connection of 48 optical inputs to any or all of
the 48 optical outputs. The TOE consists of 2 Data Input/Output Cards having 24 optical input and Output
ports each. The TOE supports any combination of legacy Velocity VX based IO cards or TLX IO cards.
The 2 data Input and Output Cards installed can be used to connect any of the 48 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 2 data Input and Output Cards connect to a 48 x 48 switch on the 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 (TLX48 2RU Matrix Switch Rev B)
2. 2 Data Input/Output Cards in any combination of the following:
TLX48 2RU Matrix Switch Data Input/Output Card, 24 Ports, SFP+, 10G Multi-Mode (TLX-MSD-
M00024 Rev A)
TLX48 2RU Matrix Switch Data Input/Output Card, 24 Ports, SFP+, 10G SingleMode (TLX-MSD-
S00024 Rev A)
TLX48 2RU Matrix Switch Data Input/Output Card, 24 Ports, SFP+, 6G Multi-Mode (TLX-MSD-
MV0024 Rev A)
TLX48 2RU Matrix Switch Data Input/Output Card, 24 Ports, SFP+, 6G Single-Mode (TLX-MSD-
SV0024 Rev A)
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 wired 10/100/1000BASE-
Document Version 1.7 May 2023 Page 7 of 28
TX LAN connection. The connection over the serial RS-232/console interface or a wired
10/100/1000BASE-TX LAN will be from a management interface/control CPU that is required to be in a
secure location and secure network.
The control CPU has no control software on it to setup or break connections or to modify the .csv partition
or restrict table files. Instead, the control CPU acts as a terminal emulator on the system controller
interfaces as described below.
Access to the system controller interfaces is defined by the user type which is described in section 8 User
Roles. Also, refer to Figure 2b below for a Typical TOE installation with user access.
Please note: For all API interfaces, the command API is described in the document:
Manual_TLX_Matrix_Switch_ASCII_API_V5
1) Control CPU connected to API RS-232 port
There is no proprietary software installed or running on the control CPU. The control CPU acts solely as a
“Terminal Emulator” when connected to the API RS232 port.
A control CPU connected to the RS232 port does not need to be authenticate and has no access to the
system controller operating/file system.
The control CPU can access the API as a “Terminal Emulator” however, there are no API commands that
exist which allow any user to log into or access the operating/file system to then affect the .csv files.
Further, the control CPU can generate API commands to setup and break connections but only those
allowed in the Restrict and Partition tables.
2) Control CPU connected to Console Port
There is no proprietary software installed or running on the control CPU. The control CPU acts solely as a
“Terminal Emulator” when connected to the Console port.
A control CPU connected to the Console port requires two levels of authentication to gain access to the
operating/file system and to the .csv files. Please refer to section 8 User Roles for more information.
To gain access to the .csv files, which resides on the TOE system controller card, the following security
levels are in place that must be met.
1) An Operator login is required consisting of a user name and password.
2) Then an Administrator login is required consisting of user name and password.
3) The .csv tables can then be accessed and altered but cannot take effect until the system is
rebooted.
3) Control CPU connected to Network Interface Port 17567
There is no proprietary software installed or running on the control CPU. The control CPU acts solely as a
“Terminal Emulator” when connected to the Network Interface Port 17567.
A control CPU connected to the Network Interface Port 17567 port does not need to be authenticate and
has no access to the system controller operating/file system.
Document Version 1.7 May 2023 Page 8 of 28
The control CPU can access the API as a “Terminal Emulator” however, there are no API commands that
exist which allow any user to log into or access the operating/file system to then affect the .csv files.
Further, the control CPU can generate API commands to setup and break connections but only those
allowed in the Restrict and Partition tables.
4) Control CPU connected to Network Interface SSH Port 22
There is no proprietary software installed or running on the control CPU. The control CPU acts solely as a
“Terminal Emulator” when connected to the Network Interface SSH Port 22
A control CPU connected to the Network Interface SSH Port 22 requires two levels of authentication to
gain access to the operating/file system and to the .csv files. Please refer to section 8 User Roles for
more information.
To gain access to the .csv files, which resides on the TOE system controller card, the following security
levels are in place that must be met.
1) An Operator login is required consisting of a user name and password.
2) Then an Administrator login is required consisting of user name and password.
3) The .csv tables can then be accessed and altered but cannot take effect until the system is
rebooted.
For the physical interfaces mentioned above, the diagram below shows all the logical interface running on
them.
Figure 1. TLX48_2RU logical interfaces
Document Version 1.7 May 2023 Page 9 of 28
The Thinklogical TLX48 2RU Matrix Switch is depicted in Figure 1a.
Figure 2a. Thinklogical TLX48 2RU Matrix Switch
Figure 2b. Typical TOE TLX48 2RU Matrix Switch Installation
Document Version 1.7 May 2023 Page 10 of 28
2.2 TOE Physical Boundaries
TOE Physical scope is as follows.
1) The TLX48 2RU Matrix Switch is a hardware device. TOE Physical Boundaries then correspond to the
physical boundaries of the device.
The TOE consists of the following hardware devices:
1. Thinklogical KVM Matrix Switch (TLX48 2RU Matrix Switch Rev B)
2. 2 Data Input/Output Cards in any combination of the following:
TLX48 2RU Matrix Switch Data Input/Output Card, 24 Ports, SFP+, 10G Multi-Mode (TLX-MSD-
M00024 Rev A)
TLX48 2RU Matrix Switch Data Input/Output Card, 24 Ports, SFP+, 10G SingleMode (TLX-MSD-
S00024 Rev A)
TLX48 2RU Matrix Switch Data Input/Output Card, 24 Ports, SFP+, 6G Multi-Mode (TLX-MSD-
MV0024 Rev A)
TLX48 2RU Matrix Switch Data Input/Output Card, 24 Ports, SFP+, 6G Single-Mode (TLX-MSD-
SV0024 Rev A)
The TOE is shipped out of the Thinklogical shipping department following our “Packaging and Shipping”
requirements document which requires tamper evident packaging.
Thinklogical uses preferred carriers unless specified by our customers. In those cases, we are required by
Purchase Order Flow Down Requirements to use the customers designated carriers.
Carriers that Thinklogical uses are industry leaders in ground, air, and rail and well-equipped to handle
Thinklogical needs and customer delivery expectations. All these carriers provide tracking, customer
support, and delivery confirmation.
Please see list below for the approved logistics services Thinklogical uses:
 Federal Express
 United Parcel Service
 TForce Freight
 BTX Global Logistics
2) Software/Firmware within the hardware device configures the data separation security policy.
The Software/Firmware revision is SFT-TLX248-01 [TLX48 2RU Firmware version 5.09.01]
The system software, which resides on the SD card, is always shipped installed on the system controller
card which is part of the Thinklogical KVM Matrix Switch (TLX48 2RU Matrix Switch Rev B) chassis.
The Administrator, Operator, or System user cannot download the system software. The Administrator
can request to get a software upgrade which is provided as a shipped 32GB SDHC Industrial Grade SD
card. The entire operating system is on the SD card. The SD card is formatted with the EXT4 journaling
file system. The operating system is CentOS 7 and is setup with the standard Centos 7 Linux based
directory structure. Within that directory structure are binary, shell script, and python files.
Document Version 1.7 May 2023 Page 11 of 28
For security, the SD card is placed into a tamper evident Security Bag for shipment. The Security Bag has
a self-sealing closure, a unique alphanumeric serial number with barcode, and a receipt to allow for
tracking purposes. When shipping the SD Card, the serial number receipt from the bag is sent to the
customer as a separate shipment. When the customer receives the SD card shipment, they can verify
that the Security bag serial number matches the receipt number indicating that the shipment has not been
tampered with.
3) Guidance documentation for TLX48 2RU Matrix Switch is a hardware device is the TLX48 2RU Product
Manual [Revision D, Nov 2022] and TLX48 2RU Quick Start Guide [TLX48_2RU_QSG Revision B]
Documentation is not shipped with the hardware but can be downloaded from the Thinklogical support
download section of the website as a pdf file (https://www.thinklogical.com/downloads). Documentation
for the matrix switches would include Product Manual and Quick Start Guide.
2.3 TOE Logical Boundaries
TOE logical boundaries include all software and firmware components inside the TLX48 2RU 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.7 May 2023 Page 12 of 28
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 control computer, 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 Administrators, Operators, and System users 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.7 May 2023 Page 13 of 28
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.7 May 2023 Page 14 of 28
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.7 May 2023 Page 15 of 28
Table 4: Security Objectives for the Environment
Security Objective for the Environment
OE.EMISSION The customer shall verify that the TOE meets the appropriate
national/regional requirements if those requirements for
conducted/radiated electromagnetic emissions fall outside the scope of
testing currently performed on the TOE. 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 Administrators, Operators, and System user shall be non-
hostile and follow all usage guidance.
Note: a similar objective exists in PSSPP.
OE.PHYSICAL The Switch, the control computer, 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.7 May 2023 Page 16 of 28
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
Document Version 1.7 May 2023 Page 17 of 28
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].
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 augmented with
ALC_FLR.2.
5.2.1 Assurance Components
The table below summarizes the components for EAL4 + ALC_FLR.2.
Table 6: TOE Security Assurance Requirements
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
ALC_FLR.2 Flaw remediation Procedures
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.1 Testing: basic design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing – sample
Document Version 1.7 May 2023 Page 18 of 28
Assurance Class Assurance Component
Vulnerability
assessment
AVA_VAN.3 Focused vulnerability analysis
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.1 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.
The TOE security functions (TSF) shall enforce the Data Separation SFP when exporting user data,
controlled under the SFP(s), outside of the TOE and the TSF shall export the user data without the user
data’s associated security attributes.
Also, the TSF shall enforce the Data Separation SFP when importing user data, controlled under the
SFP, from outside the TOE and ignore any security attributes associated with the user data when
imported from outside the TOE.
6.2 Assurance Measures
The assurance measures addressed in this section apply to the EAL4+ requirements augmented with
ALC_FLR.2 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
Document Version 1.7 May 2023 Page 19 of 28
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
ALC_FLR.2 Flaw remediation Thinklogical Remediation Plan and
Procedures Document
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
ATE_DPT.1 Testing: basic design 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.7 May 2023 Page 20 of 28
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.7 May 2023 Page 21 of 28
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.7 May 2023 Page 22 of 28
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.7 May 2023 Page 23 of 28
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.7 May 2023 Page 24 of 28
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 TOE Management system will be in a secure environment as the TOE.
Document Version 1.7 May 2023 Page 25 of 28
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
8 User Roles
TOE provides multiple user roles as defined in the following table.
Table 15: User Roles
Role Description
Administrator An Administrator has second level log in authentication. Therefore
the Administrator cannot directly log into the system until the
Operator has logged in. A user in this role has administrative rights
in the operating system. Administrative rights include the ability to
access .csv files and modify them, perform user access control of
switch, view log data, create and break connections. Administrator
cannot be deleted.
Operator An Operator has first level log in authentication. A user in this role
does not have administrative rights in the operating system.
Operator rights include the ability to view .csv files but cannot
modify them, cannot perform user access control of switch, cannot
view log data. Operator can create and break connections.
Operator cannot be deleted.
System User A System User has no authentication required. A user in this role
does not have any access to the switch operating system. A
System User cannot view or modify .csv files, cannot perform user
access control of switch, cannot view log data, cannot create and
break connections, and has no physical access to the switch or the
isolated physically secure network. The System User can only use
the TOE to receive a video signal from the source and send a
keyboard / mouse signal to the source.
Document Version 1.7 May 2023 Page 26 of 28
TOE provides multiple user role access as defined in the following table.
Table 16: User Role Access
Access Administrator Operator System
user
Comment
Login / authentication 2
nd
level / un
and pw
1
st
level /
un and
pw
None /
none
Administrator cannot directly log into
system but only after Operator login.
System user has no login.
Physical access –
API RS-232 Port
Yes Yes No Administrator and Operator will be
allowed in secure switch location
System user will not be allowed in
secure switch location.
Physical access –
Console Port
Yes Yes No Administrator and Operator will be
allowed in secure switch location
System user will not be allowed in
secure switch location.
Physical access –
Ethernet Port
Yes Yes No Administrator and Operator will
have access to Isolated physically
secure network.
System user will not have access to
Isolated physically secure network.
Logical access /
administrative -
NTP UDP – port 123
Yes No No Only Administrator can start NTP
services and can create, access,
and modify ntp.conf file.
Logical access /
administrative -
SNMP UDP – ports
161, 162
Yes No No Only Administrator can start SNMP
services and can create, access,
and modify snmpd.conf file.
Logical access /
administrative -
Remote SYSLOG
UDP – port 514
Yes Limited No Only Administrator has access to
view all log files.
Operator has limited access to view
log files
Logical access /
administrative -
SSH – port 22
Yes No No Only Administrator has access to
view and modify sshd.conf file.
Document Version 1.7 May 2023 Page 27 of 28
Logical access /
control -
UDP – port 17564
Yes Yes No Just status broadcast. There is no
TOE control over this interface.
Logical access /
control -
ICMP - ping
Yes No No Only Admin can ping.
Logical access /
control -
TCP – port 17567
Yes Yes No API access. No authentication
OS File System .csv
table Access – read
and write
Yes Limited No Only Administrator can modify .csv
table files.
Operator can view .csv files.
System user cannot gain access to
file system.
Matrix Switch
Connections
Yes Yes No Only Administrator and Operator
can make switch connections
through the API.
System user cannot make switch
connections since they do not have
access to physical system ports
because not allowed access to
secure switch location.
System user cannot make switch
connections since they do not have
access to isolated physically secure
network.
Document Version 1.7 May 2023 Page 28 of 28
9 Acronyms
CC Common Criteria
EAL Evaluation Assurance Level
IT Information Technology
SAR Security Assurance Requirement
SFR Security Functional Requirement
ST Security Target
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
TSFI TSF Interface
TSC TSF Scope of Control
TSS TOE Summary Specification
TSP TOE Security Policy
CSCS Customer Supplied Computer System