Public
SDoT SDD
Security Target Lite
Document name: SDoT_SDDv1.3i_SecurityTargetLite
Document version: V 1.1
Version date: 06.11.2024
Author: INFODAS GmbH
Number of pages: 87
DMS Version 0.10
Issued by: INFODAS GmbH
Rhonestraße 2
50765 Cologne, Germany
Legal: All rights reserved.
Passing on and duplication of this document as well as utilisation and
communication of its contents are only permitted with the express consent
of INFODAS GmbH.
Contraventions will be prosecuted in court and will result in damages.
Public
SDoT SDD
ST Security Target Lite
i Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Table of Contents
Table of Contents....................................................................................................................................................... i
List of Figures ...........................................................................................................................................................iv
List of Tables..............................................................................................................................................................v
Abbreviations............................................................................................................................................................vi
General .......................................................................................................................................................................ix
1 ST Introduction (ASE_INT.1) .....................................................................................................................10
1.1 ST Reference ........................................................................................................... 10
1.2 TOE reference.......................................................................................................... 10
1.3 TOE overview........................................................................................................... 10
1.3.1 TOE definition and operational usage ................................................................. 10
1.3.2 Major Security Features of the TOE .................................................................... 12
1.3.3 TOE Type................................................................................................................ 15
1.3.4 Required non-TOE Hardware (HW)/Software (SW)/Firmware (FW)............... 15
1.4 TOE description ....................................................................................................... 16
1.4.1 TOE Description – Physical Scope....................................................................... 17
1.4.2 TOE Description – Logical Scope......................................................................... 17
2 Conformance claims (ASE_CCL.1)...........................................................................................................22
2.1 CC conformance claim ............................................................................................ 22
2.2 PP Claim................................................................................................................... 22
2.3 Package Claim ......................................................................................................... 22
2.4 Conformance Rationale .......................................................................................... 22
3 Security Problem Definition (ASE_SPD.1) ............................................................................................23
3.1 Introduction.............................................................................................................. 23
3.2 Assets....................................................................................................................... 23
3.2.1 Primary Assets ...................................................................................................... 23
3.2.2 Secondary Assets.................................................................................................. 23
3.3 Subjects and external entities................................................................................ 24
3.4 Threats ..................................................................................................................... 24
3.5 Assumptions ............................................................................................................ 27
3.6 Organisational Security Policies............................................................................ 29
4 Security Objectives (ASE_OBJ.2).............................................................................................................30
Public
SDoT SDD
ST Security Target Lite
ii Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
4.1 Security Objectives for the TOE............................................................................. 30
4.2 Security Objectives for the Operational Environment ......................................... 32
4.3 Rationale between SPD and security objectives.................................................. 34
4.4 Rationale Threats.................................................................................................... 37
4.4.1 T.REVEAL_PA ........................................................................................................ 37
4.4.2 T.REVEAL_SA_TO_UNAUTH............................................................................... 37
4.4.3 T.MALICIOUS_CODE............................................................................................. 38
4.4.4 T.AUTH ................................................................................................................... 38
4.4.5 T.MISCONFIG......................................................................................................... 38
4.4.6 T.AUDIT_CONTROL............................................................................................... 38
4.4.7 T.AUDIT_COLLAPSE ............................................................................................. 39
4.4.8 T.AUDIT_ACCESS.................................................................................................. 39
4.5 Rationale OSPs........................................................................................................ 39
4.5.1 OSP.ADMINS ......................................................................................................... 39
4.5.2 OSP.AUDIT............................................................................................................. 39
4.6 Rationale Assumptions........................................................................................... 39
4.6.1 A.DIFF_NET............................................................................................................ 40
4.6.2 A.TRUSTW_ONLY ................................................................................................. 40
4.6.3 A.ACCESS............................................................................................................... 40
4.6.4 A.TRUSTW_STAFF................................................................................................ 40
4.6.5 A.CRYPTO_UNIT.................................................................................................... 40
4.6.6 A.CRYPTO_UNIT_USER ....................................................................................... 40
4.6.7 A.PKI ....................................................................................................................... 40
4.6.8 A.NTP_SERVER..................................................................................................... 40
4.6.9 A.L4_PLATFORM................................................................................................... 40
4.6.10 A.DEDICATED_ADMIN_NET ................................................................................ 41
4.6.11 A.HIGH_AVAILABILITY.......................................................................................... 41
4.6.12 A.BOOT ................................................................................................................... 41
5 Definition of Security Function Policies (SFPs)....................................................................................42
6 Extended components definition (ASE_ECD.1) ....................................................................................47
6.1 Class FPT: Protection of the TSF........................................................................... 47
6.1.1 TSF integrity checks (FPT_INC)........................................................................... 47
Public
SDoT SDD
ST Security Target Lite
iii Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
7 Statement of security requirements (ASE_REQ.2)..............................................................................48
7.1 Security functional requirements.......................................................................... 48
7.1.1 User Data Protection (FDP) .................................................................................. 49
7.1.2 Identification and authentication (FIA)................................................................. 57
7.1.3 Cryptographic support (FCS)................................................................................ 58
7.1.4 Security management (FMT)................................................................................ 61
7.1.5 Protection of the TSF (FPT).................................................................................. 65
7.1.6 Security audit (FAU) .............................................................................................. 66
7.2 Dependency Rationale............................................................................................ 69
7.3 Security assurance requirements rationale ......................................................... 72
7.4 Security Functional Requirements Rationale....................................................... 75
7.4.1 OT.SANITISED ....................................................................................................... 76
7.4.2 OT.COMM............................................................................................................... 76
7.4.3 OT.USER_AUTHENTICATION .............................................................................. 76
7.4.4 OT.ROLE_SEPARATION........................................................................................ 77
7.4.5 OT.FOUR_EYES..................................................................................................... 77
7.4.6 OT.AUDIT_LOG...................................................................................................... 77
7.4.7 OT.AUDIT_PROTECT............................................................................................. 78
7.4.8 OT.SECURE_STATE .............................................................................................. 78
8 TOE Summary Specification (ASE_TSS.1).............................................................................................80
8.1 TOE Security Functions .......................................................................................... 80
8.1.1 SF_PR: Protocol Response .................................................................................. 80
8.1.2 SF_CP: Channel Protection.................................................................................. 81
8.1.3 SF_DP: Data Protection........................................................................................ 81
8.1.4 SF_AA: Authentication and Authorisation........................................................... 81
8.1.5 SF_AT: Audit Trail ................................................................................................. 82
8.1.6 SF_SP: Self Protection ......................................................................................... 82
8.2 TOE Summary Specification Rationale ................................................................. 84
9 Bibliography ..................................................................................................................................................86
Public
SDoT SDD
ST Security Target Lite
iv Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
List of Figures
Figure 1: SDoT SDD located between SRC and DST networks.....................................................................13
Figure 2: Logical scope of the TOE ..........................................................................................................................17
Public
SDoT SDD
ST Security Target Lite
v Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
List of Tables
Table 1 Main functionalities of each compartment............................................................................................14
Table 2 Required non-TOE HW/SW/FW components of SDoT SDD..........................................................16
Table 3 SDoT SDD scope of delivery......................................................................................................................16
Table 4 Primary assets................................................................................................................................................23
Table 5 Secondary assets...........................................................................................................................................24
Table 6 Subjects.............................................................................................................................................................24
Table 7 Threats...............................................................................................................................................................26
Table 8 Assumptions ....................................................................................................................................................28
Table 9 OSPs...................................................................................................................................................................29
Table 10 Security Objectives for the TOE .............................................................................................................31
Table 11 Security Objectives for the Operational Environment....................................................................33
Table 12 Security Objective for the TOE coverage............................................................................................34
Table 13 Security Objective for the Operational Environment Coverage..................................................36
Table 14 audit access control SFP ..........................................................................................................................42
Table 15 admin access control SFP........................................................................................................................42
Table 16 data from SRC SFP .....................................................................................................................................43
Table 17 HTTP response SFP ...................................................................................................................................43
Table 18 ICAP header SFP .........................................................................................................................................44
Table 19 ICAP response SFP.....................................................................................................................................45
Table 20 NTP synchronize SFP................................................................................................................................46
Table 21 dual control admin SFP.............................................................................................................................46
Table 22 SFRs of the TOE...........................................................................................................................................49
Table 23 auditable events ..........................................................................................................................................67
Table 24 Dependencies between the Security Functional Requirements (SFRs) for the TOE ..........72
Table 25 Security Assurance Requirements (SARs).........................................................................................74
Table 26 Coverage of the Security Objectives for the TOE by SFRs ...........................................................76
Table 27 TSS Rationale Overview ...........................................................................................................................85
Public
SDoT SDD
ST Security Target Lite
vi Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Abbreviations
ASE
Assurance Class in the CC Standard referring to the Security
Target Evaluation
CA Certification Authority
CC Common Criteria for Information Technology Security Evaluation
CCL
Refers to the assurance family “Conformance claims” in the
assurance class ASE
CEM
Common Criteria for Information Technology Security Evaluation,
Evaluation methodology
CPU Central Processing Unit
DVD Digital Versatile Disc
EAL Evaluation Assurance Level
FAU SFRs belonging to the functional class “Security Audit”
FCO SFRs belonging to the functional class “Communication”
FDP SFRs belonging to the functional class “User Data Protection”
FIA
SFRs belonging to the functional class “Identification and
authentication”
FMT SFRs belonging to the functional class “Security management”
FPT SFRs belonging to the functional class “Protection of the TSF”
FSD Field Structured Data
FW Firmware
GUI Graphical User Interface
HDD Hard Disk Drive
HMAC Hash Message Authentication Code
HTTP / S Hypertext Transfer Protocol / Secure
HW Hardware
/ICAP Internet Content Adaptation Protocol
Public
SDoT SDD
ST Security Target Lite
vii Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
INT
Refers to the assurance family “ST introduction” of the assurance
class ASE
IP Internet Protocol
L2H Low-to-high
L4 Implementation of microkernel L4
L4Linux Modified kernel of Linux running on top of L4
L4Re L4 Runtime environment
LCD Liquified Crystal Display
NTP Network Time Protocol
OBJ
Refers to the assurance family “Security objectives” of the
assurance class ASE
OSP Organisational Security Policy
RAM Random Access Memory
REQ
Refers to the assurance family “Security requirements” of the
assurance class ASE
RNG Random Number Generator
RTF Rich Text Format
SAR Security Assurance Requirement
SDoT Security Inter-Domain Transition
SFP Security Function Policy
SFR Security Functional Requirement
SMTP Simple Mail Transfer Protocol
SMTP MTA SMTP Message/Mail Transfer Agent
SPD
Refers to the assurance family “Security problem definition” of
the assurance class ASE
SSD Solid State Drive
ST Security Target
SW Software
Public
SDoT SDD
ST Security Target Lite
viii Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
TCP Transmission Control Protocol
TLS Transport Layer Security
TOE Target of Evaluation
TSF TOE Security Function
TSS
Refers to the assurance family “TOE summary specification” of
the assurance class ASE
UDP User Datagram Protocol
UEFI Unified Extensible Firmware Interface
Public
SDoT SDD
ST Security Target Lite
ix Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
General
Revision History:
Version Date Application Note Author
V 1.0 26.08.2024 First Release of lite version based on full ST in
accordance with [AIS_35] and supporting document
[MC_ST_LITE].
INFODAS GmbH
V 1.1 06.11.2024 Update with changes based on comments from BSI. INFODAS GmbH
Public
SDoT SDD
ST Security Target Lite
10 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
1 ST Introduction (ASE_INT.1)
This chapter provides an unambiguous identification of the main characteristics of this Security
1
Target and the TOE in scope of the security certification process. Some information in TOE overview
2
and in TOE description contain confidential information which are reduced in the public version of
3
this security target (ST Light). This security target was created considering of BSI.
4
1.1 ST Reference
Title: SDoT SDD Security Target Lite
5
Version: V 1.1
6
Date: 06.11.2024
7
Author: INFODAS GmbH
8
1.2 TOE reference
Product name: SDoT SDD (SDoT Software Data Diode)
9
TOE name (long): SDoT SDD SW
10
TOE name (short): SDoT SDD
11
TOE version: 1.3i
12
Developer name: INFODAS GmbH
13
Certification ID: BSI-DSZ-CC-1193
14
1.3 TOE overview
The TOE version 1.3i refers to the use case for the deployment to the international free market.
15
Hereby, 1.3i describes a mnemonic convention which exact configuration is identified as the
16
following revision: 1.3.1360.33832 P3. This version number is equivalent to 1.3.3.1360.33832. This
17
Security Target defines the security objectives for, and security requirements of the SDoT SDD of
18
INFODAS GmbH. Further, this security target defines the security objectives of the operational
19
environment for the TOE. The following subsections give an overview of the TOE, its usage and major
20
security features, the TOE type, and lists all required non-TOE Hardware, non-TOE
21
Software/Firmware.
22
1.3.1 TOE definition and operational usage
The SDoT SDD belongs to the SDoT Cross Domain Solution product family of INFODAS GmbH. The
23
SDoT SDD serves as boundary protection device between IP Networks with different demands on
24
the level of protection needed. These two IP networks are identified as Source (SRC) and Destination
25
(DST). The SDoT SDD ensures that there is no data leakage from DST to SRC but data from SRC to
26
DST can always pass the TOE.
27
Originally, the terms Source and Destination were identified as LOW and HIGH for protection of
28
sensitive information in the higher classified network HIGH. In a high-level view, however, the terms
29
SRC for identifying the network LOW and DST for describing the network HIGH is used.
30
Public
SDoT SDD
ST Security Target Lite
11 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
The reason for re-defining the terms used is that the use case of a unidirectional system will not be
31
restricted in only one direction. The SDoT SDD can be used for the use case that no sensitive data
32
unintentionally flow out of systems to be protected, as well as for the use case that malicious code
33
unintentionally flows into the system to be protected. An example of the latter could be industrial
34
plants that is able to export system data but are not allowed to inject anything malicious
35
unintentionally.
36
The SDoT SDD is technologically realized on basis of the SDoT Security Gateway, which was
37
recently certified through the CC-evaluation. The SDoT Security Gateway already can function as a
38
diode. The already proven technology in the SDoT Security Gateway also provides several security
39
mechanisms of the SDoT Diode.
40
As it is shown in Figure 1, the product SDoT SDD comprises the:
41
1. SDoT SDD Platform (HW with Crypto Unit, FW, OS),
42
2. SDoT SDD SW covering the software and compartment allocation of the OS, or in the short
43
form SDoT SDD which is the TOE and
44
3. SDoT Adminstation.
45
More information about the non-TOE parts of SDoT SDD will be given in 1.3.4. Therefore, the TOE is
46
an application delivered together with a set of software and hardware components to the customer.
47
The underlying micro kernel operating system with its separation mechanism is part of the TOE
48
environment. Nonetheless, the configuration and type of usage of the separation mechanism of the
49
L4 micro kernel OS is part of the security assessment. All hardware and software which are needed
50
to securely operate the TOE in accordance with the TOE assumptions, and in accordance with the
51
assumptions of the TOE operational environment, are in scope of delivery, see Table 3. The
52
hardware parts and software parts besides the TOE are partially customized for SDoT SDD to ensure
53
that the TOE operates properly as intended with the dedicated delivery parts only.
54
It is the nature of communication protocols that some protocol responses must be allowed. Simple
55
HTTP responses regarding the status code of HTTP requests from SRC must be sent back by DST
56
interface. These responses are analysed and sanitised by the TOE, so that the response code does
57
not contain any confidential information. SMTP responses to SMTP emails coming from SRC are
58
also analysed and, if required, sanitised.
59
The protocols TCP and UDP do not transfer any protocol responses from DST to SRC. In case of TCP,
60
the connection of the TCP sender terminates at the SRC network interface of the TOE. The SRC
61
interface of the TOE acknowledges local receipt of data by sending an ACK-package to the TCP
62
sender after an ACK-package was received from DST.
63
The TOE can synchronise its system time with a target server in DST. From the other side, a system
64
in SRC can directly synchronise its system time with the TOE. That means the system in SRC and
65
the target server in DST can synchronise its time via the TOE without direct connection.
66
The TOE only accepts connection attempts coming from SRC. Hence, the TOE ensures that only
67
unidirectional data flow from SRC to DST is possible. Any connection attempt from DST is blocked
68
by the TOE. This leads to the main security function of the TOE that any information flow of payload
69
data from DST to SRC is not possible.
70
Public
SDoT SDD
ST Security Target Lite
12 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
1.3.2 Major Security Features of the TOE
In short, the major security function of the TOE is to provide the mechanism that no data flow from
71
DST to SRC is possible. During all kind of data transfer from SRC to DST, no data or information
72
located in DST may flow to SRC.
73
The TOE is running on a L4Re operating system which provides the capability to run independent
74
systems in isolated parts, called compartments. Splitting the system into compartments makes it
75
possible to implement logically separated subsystems of the TOE. The system hosting the TOE uses
76
an UEFI-based secure boot mechanism to ensure that only authentic software is running on the
77
system. Therefore, the TOE runs on a platform system which provides strong separation, and
78
isolation mechanisms for each compartment. Further, the platform provides an instrument for
79
restricting the communication between each compartment by means of controlling and monitoring
80
capabilities.
81
The TOE includes six compartments for different purposes. These are:
82
• DI_GUI,
83
• DI_HGH,
84
• DI_CFG,
85
• DI_L2H,
86
• DI_LOW, and
87
• DI_ADT.
88
The security mechanisms of the TOE are implemented on the compartments DI_GUI, DI_CFG, and
89
DI_ADT. The TOE collects and checks audit data to identify and provides audit data protection
90
mechanisms. The TOE performs management functions on configuration data in DI_CFG.
91
Authentication of administrators and auditor of the TOE is provided by the DI_GUI which
92
communicates via secure TLS connection to the SDoT Adminstation. Cryptographic Key Generation
93
and Key Storage are provided by a certified Crypto Unit. However, the secure TLS connection itself
94
and the certified Crypto Unit are not scope of the current TOE. The following figure depicts the TOE
95
with its IT environment.
96
Public
SDoT SDD
ST Security Target Lite
13 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Figure 1: SDoT SDD located between SRC and DST networks
The information flow from SRC to DST is under control of the compartment DI_L2H which has no
97
direct link to the networks SRC and DST networks.
98
Outside of the TOE the SDoT SDD provides security mechanisms which include the SDoT
99
Adminstation and a dedicated cryptographic unit. These parts outside of the TOE are the operational
100
environment of the TOE. Further, it is recommended that the operator of the TOE considers using a
101
firewall which is located between the SDoT SDD and the network SRC.
102
The SDoT Adminstation allows the administrator or the auditor to fulfil their responsibility and role
103
as such. The SDoT Adminstation is connected to the TOE via the compartment DI_GUI through a
104
dedicated administration network.
105
The following table outlines the main functionalities of each compartment:
106
Compartment Description
DI_GUI • Provides the GUIs for administrating and auditing purposes of
the TOE.
• Performs the signature verification to establish the secure TLS
connection to the SDoT Adminstation for administrative
Public
SDoT SDD
ST Security Target Lite
14 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
purposes. TLS is only used to ensure that the correct roles log
on to the TOE within the dedicated admin network. Only user
roles trusted by the operational environment of the admin
network are allowed to have access to the admin network.
• Serves as Syslog Relay to distribute the Syslog data.
• Serves as a Network Time Protocol Daemon, ensuring
synchronization of the TOE system time with the target server
in the admin network, or alternatively, provides time for client
in the admin network.
DI_CFG • Responsible for the communication with the Crypto Unit for
cryptographic purposes.
• Provides functionalities for the administration of the TOE.
• Synchronizes internal system time between all of
compartments
DI_ADT • Includes mechanisms for logging security relevant events.
DI_L2H • Direct forwarding (transfer) of messages from SRC
• Analysis and sanitisation of protocol responses (of HTTP
requests and SMTP emails originally coming from SRC
network) and forwarding sanitised protocol responses back to
the SRC network.
DI_HGH • Includes proxies for SMTP, HTTP, UDP and TCP for
communication with the TOE environment within the DST (IP
network with higher level of data protection or higher level of
confidentiality).
• Serves as Syslog Relay to distribute the Syslog data.
• Serves as a Network Time Protocol Daemon, ensuring
synchronization of the TOE system time with the target server
in DST, or alternatively, provides time for client in DST.
DI_LOW • Includes proxies for SMTP, HTTP, UDP and TCP for
communication with the TOE environment within the SRC (IP
network with lower level of data protection or lower level of
confidentiality).
• Serves as a Network Time Protocol Daemon, ensuring
synchronization of the TOE system time with the target server
in SRC, or alternatively, provides time for client in SRC.
Table 1 Main functionalities of each compartment
The major security features of the TOE are summarised as follows:
107
• Message flow is only possible from SRC to DST i.e., messages coming from DST are not
108
accepted and blocked by the TOE.
109
Public
SDoT SDD
ST Security Target Lite
15 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
• Analysis and sanitisation of protocol responses (of HTTP requests and SMTP emails
110
originally coming from SRC) and forwarding these sanitised responses to SRC. The
111
response includes only a 3-digit code number with a pre-defined corresponding
112
message and pre-defined header.
113
• The TOE only accepts connections on configured ports. For each port, only correct
114
communication according to the configured protocol is accepted by the TOE.
115
• The TOE provides secure auditing mechanisms of logs and secure administration
116
capabilities.
117
• The TOE provides mechanisms for authentication.
118
• The TOE can preserve of a secure state in case of appearance of compromising events.
119
• The TOE regularly checks the integrity of its binary and configuration files.
120
1.3.3 TOE Type
The TOE (SDoT SDD SW) is the software for the product SDoT Software Data Diode (hardware and
121
software) of INFODAS GmbH.
122
1.3.4 Required non-TOE Hardware (HW)/Software (SW)/Firmware
(FW)
Besides the TOE the SDoT SDD consists of the following parts:
123
• Underlying platform (hardware and operating system) of the TOE.
124
• Crypto Unit which provides cryptographic support. This is a server smartcard
125
integrated into the SDoT SDD server hardware.
126
• SDoT Adminstation including hardware and software parts.
127
• Smartcard Reader for authentication purposes at the SDoT Adminstation.
128
• Smartcards for cryptographic support and authentication.
129
Besides the hardware and operating systems, there are several software components which belong
130
to the TOE environment (cf. Figure 1 and Figure 2). The following table provides an overview of all
131
required non-TOE hardware and non-TOE software components which are needed to securely
132
operate the TOE. In addition, all components required by SDoT SDD for its secure use are listed
133
below.
134
Required non-TOE HW/SW/FW components of SDoT SDD
Underlying Platform of the
TOE:
Hardware
Firmware/OS
Hardware of server appliance with Crypto Unit, CPU, RAM, HDDs,
LC display, and physical interfaces.
Installed on the server appliance: UEFI Boot loader, Crypto Unit,
L4Re microkernel OS, L4/Linux, BusyBox
Public
SDoT SDD
ST Security Target Lite
16 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
SDoT Adminstation (SDoT
AAC)
Machine (laptop computer) with CentOS.
Smartcard Reader Smartcard Reader of renowned manufacturer Reiner SCT of type
CyberJack Secoder or CyberJack RFID
Smartcards Smartcard with certificate for initialisation purposes and empty
user smartcards which must be initialised for authentication
purposes.
Table 2 Required non-TOE HW/SW/FW components of SDoT SDD
1.4 TOE description
The following table shows the delivery parts of the SDoT SDD where the TOE belongs to. Following
135
to that, the subsections provide a description of the physical and logical boundaries of the TOE.
136
Name Description Medium
HW, FW, OS, Crypto
Unit of SDoT SDD
Comprises all Hardware and FW/OS
Parts on which the TOE is running
Hardware with installed
Crypto Unit and FW/OS of
SDoT SDD
SDoT Adminstation Laptop Computer for administration
of SDoT SDD
Hardware with installed
FW/OS for administration
purposes
TOE Installation ISO Software for installation of the TOE
on the SDoT SDD
DVD
SDoT Adminstation ISO Software for installation of the
SDoT Adminstation SW
DVD
Guidance
Documentation
Manual for SDoT SDD:
SDoT SDD-1.3-I-UM-DE/EN-1.6
Manual for administration:
SDoT AAC-1.6-I-UM-DE-1.9
Product information sheet:
SDoT SDD-1.3-I-PI-DE-0.11
All guidance documents are
provided digitally via E-Mail in
Portable Document Format
Smartcards Provides key material for first
initialisation and further smartcards
for authentication purposes on the
SDoT Stations
Smartcard
Table 3 SDoT SDD scope of delivery
Public
SDoT SDD
ST Security Target Lite
17 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
1.4.1 TOE Description – Physical Scope
The TOE is the main software component of the SDoT SDD. Therefore, there are no physical parts
137
of the SDoT SDD in scope of the TOE. The reader may refer to Table 3 above for information about
138
the physical parts of the SDoT SDD.
139
1.4.2 TOE Description – Logical Scope
Figure 1 shows an overview of the separated compartments which are part of the TOE. The following
140
Figure 2 shows the logical scope of the TOE within the compartments and gives an overview of non-
141
TOE components of the product:
142
Figure 2: Logical scope of the TOE
As shown in Figure 2 the system platform required by the TOE provides multiple environments for
143
the implementation of compartments with strong separation mechanisms. Each compartment
144
represents an isolated security domain with its own underlying L4Linux. The microkernel
145
architecture provides control mechanisms to restrict the communication between the
146
compartments.
147
The TOE environment within the SDoT SDD platform includes the SDoT Adminstation and a
148
dedicated Crypto Unit. For a better overview of the SDoT SDD a short description of all components
149
is given in the following.
150
SDoT Adminstation (non-TOE):
151
The SDoT Adminstation is based on a CentOS architecture. The functionalities for local
152
administration and local auditing of the SDoT Adminstation are provided by a GUI through a common
153
browser. Configuration parameters and audit data are managed within the administration GUI of the
154
TOE which communicates via TLS with the SDoT Adminstation. The secure TLS connection itself is
155
not in the scope of the TOE.
156
Public
SDoT SDD
ST Security Target Lite
18 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
User SC for authentication called “user smartcard” is used with a dedicated smartcard reader and is
157
included in the scope of delivery.
158
The SDoT Adminstation is connected to the TOE via a dedicated administration network in the DST
159
domain and can only be used by administrators and auditors.
160
Crypto Unit (non-TOE):
161
The Crypto Unit includes the internal server smartcard as signing unit as well as for the secure key
162
storage from company Atos IT Solutions and Services GmbH, see [Atos_ST]. Certified functionalities
163
installed on the Crypto Unit (available to compartment DI_CFG) are:
164
• Function for generating long term keys for signatures
165
• Functions for creating signatures
166
• Random number generation
167
• Tamper protection and side channel protection of the cryptographic operations of the
168
crypto unit
169
• Functions for secure storage of checksum values
170
• Functions for secure storage of keys
171
In the following, the compartments which build the TOE are outlined:
172
COMPARTMENT DI_GUI
173
The web-based administration GUI and audit GUI are displayed by a common web browser installed
174
on the SDoT Adminstation (non-TOE). With administration GUI and audit GUI the configuration data
175
and audit data of the TOE can be managed. Further, DI_GUI conducts signature verification to
176
establish a secure TLS connection with the SDoT Adminstation for administrative tasks. The
177
signature verification mechanism is within the TOE's scope, while the secure TLS connection does
178
not.
179
The audit keys are generated during installation process of TOE. The generated audit keys are
180
therefore parts of TOE.
181
Beside these, the DI_GUI acts as Network Time Protocol Daemon to provide or get the TOE system
182
time as well as Syslog Relay to distribute the Syslog data.
183
COMPARTMENT DI_CFG
184
This is where the main configuration of the TOE is managed, and monitoring tasks are performed.
185
This is the only compartment with a connection to the Crypto Unit which provides hardware based
186
cryptographic mechanisms used by the TOE. The administration agent is called by the web server
187
of DI_GUI after a TLS connection was initiated from the SDoT Adminstation.
188
The main administration agent can enable the maintenance mode either by a user who is logged in
189
through the administration GUI on an SDoT Adminstation or the maintenance mode is activated by a
190
security event. In maintenance mode the components of the TOE which are responsible for
191
forwarding messages will not accept any data. Further, the main administration agent communicates
192
with the respective administration agents in each compartment of the TOE. Every administration
193
agent is responsible for the administration of its compartment the agent is belonging to. Similarly,
194
each administration agent monitors the processes of the TOE within the respective compartment, i.e.
195
restarting of stopped or crashed processes are done by the respective agent.
196
Public
SDoT SDD
ST Security Target Lite
19 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
As mentioned above, cryptographic support from the Crypto Unit is forwarded to DI_CFG which is
197
the only compartment with connection to the Crypto Unit.
198
The TOE supports a functionality called HA-mode (High Availability mode) of the SDoT SDD. Here, a
199
cluster of redundantly designed SDoT SDDs (nodes) are operated, whereby each of these nodes
200
fully implements the TOE. The node that currently accepts and processes the incoming data in
201
operational mode is called the primary node. The other nodes are called secondary nodes.
202
From an operational point of view, high availability is an important aspect for uninterruptible
203
operation. Communication between primary and secondary nodes take place via a separate network,
204
the so-called heartbeat network. All nodes have a heartbeat network interface. The network
205
interfaces are bound to the DI_CFG of each node. The heartbeat network is physically decoupled
206
from any other networks in SDoT Diode.
207
Heartbeat communication is completely decoupled from the data flow between the SRC and DST
208
networks, since this communication only takes place between the administration agents in the resp.
209
DI_CFG of the two nodes (point-to-point connection), there are no network coupling elements in
210
between, and no other network interface is connected in the DI_CFG.
211
If the primary node fails or if the connectivity of the primary node with IT systems of the DST network
212
is lost, the system automatically switches to a functioning secondary node. For this purpose, the
213
administration agents in each of the nodes monitor each other by cyclically requesting status
214
information of the other agents via the heartbeat connection. If the primary node fails or is no longer
215
accessible, one of the secondary nodes become the new primary node. The reader may also refer to
216
the Guidance Documents for further description of the HA functionality.
217
In the context of the SDoT Diode evaluation, it is important to clarify that high availability is not part
218
of the evaluation scope.
219
COMPARTMENT DI_ADT
220
This compartment provides functions for logging security relevant events. Only the audit agent
221
within DI_ADT has access to logged audit data of the audit storage. Further, the audit agent monitors
222
the audit storage capacity to avoid any potential overflow of the audit storage. DI_ADT
223
communicates with DI_GUI which establishes the TLS connection for displaying the relevant
224
information on the SDoT Adminstation.
225
The audit agent is responsible to record security relevant events on the TOE, related to writing
226
entries into the audit trail. The audit agent in DI_ADT is responsible to generate alarms, i.e. e-mails.
227
The SMTP-MTA of the TOE sends then the e-mails to a list of receivers. The list is configurable and
228
integrity protected stored in DI_CFG with checksums stored in the Crypto Unit.
229
Further, the audit agent covers the following tasks:
230
• Generate new audit trails if the current audit trail exceeds a pre-defined size,
231
• Generate new audit trails daily,
232
• Monitor the storage capacity of the storage device to prevent an audit trail overflow.
233
COMPARTMENT DI_L2H
234
All messages being sent from SRC to DST are received by DI_L2H. This compartment receives the
235
messages from one of the proxies within the DI_LOW. The process only forwards these messages
236
towards the DST network.
237
Public
SDoT SDD
ST Security Target Lite
20 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
In the opposite direction (from DST to SRC), DI_L2H accepts only HTTP and SMTP responses (ICAP-
238
response protocols from HTTP-Proxy and SMTP-MTA in DI_HGH) initiated through already
239
established connection of the corresponding requests (ICAP-request protocols from HTTP-Proxy
240
and SMTP-MTA in DI_LOW) coming from the SRC network.
241
Incoming HTTP responses of HTTP requests contain a 3-digit status code. This status code indicates
242
whether the request could be processed correctly by the HTTP server. In this way, it can be
243
recognized on the SRC network whether the data on the DST network could be processed correctly.
244
DI_L2H sanitises the HTTP response only containing the outgoing status code and the
245
corresponding configured string. Especially the HTTP body will be deleted.
246
In case of SMTP the receipt of the mail is confirmed by DI_HGH. What happens later with the mail,
247
however, is not reported to the SRC network. This SMTP response contain a 3-digit status code and
248
a corresponding string is sent via ICAP to DI_L2H. This process analyses the response and
249
subsequently sanitises the response.
250
The protocols TCP and UDP do not transfer any protocol information to the SRC network.
251
COMPARTMENT DI_HGH
252
The DI_HGH provides proxy support for the following types of protocols:
253
• SMTP
254
• HTTP
255
• UDP
256
• TCP
257
The proxies perform the following tasks which controls all data flow in the DST network.
258
• accepting messages coming from compartment DI_L2H and forwarding these to the DST
259
network. These messages originally come from the SRC network.
260
• accepting HTTP responses coming from the DST network over the connection already
261
established for the forwarding of the corresponding requests originally coming from the
262
SRC network.
263
• except NTP calls to the NTP server at the compartment DI_HGH, denying any new
264
connection attempts from the DST network.
265
Also, the above-mentioned proxies support the non-TOE functionality for mutually authenticated
266
TLS connection with IT systems of the operational environment of the TOE in the DST network. For
267
synchronising TOE system time DI_HGH also acts as Network Time Protocol Daemon with the target
268
server in DST. Furthermore DI_HGH serves as Syslog Relay to distribute the Syslog data.
269
COMPARTMENT DI_LOW
270
DI_LOW provides proxy support for the following types of protocols:
271
• SMTP
272
• HTTP
273
• UDP
274
• TCP
275
The proxies perform the following tasks which controls all data flow in the SRC network.
276
• accepting messages coming from the SRC network and forwarding these messages to
277
DI_L2H.
278
Public
SDoT SDD
ST Security Target Lite
21 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
• accepting sanitised responses (HTTP, SMTP) from compartment DI_L2H and
279
forwarding these to the SRC network.
280
Also, the above-mentioned proxies support the non-TOE functionality for mutually authenticated
281
TLS connection with IT systems of the operational environment of the TOE within the SRC network.
282
Furthermore, DI_LOW acts as Network Time Protocol server for time synchronisation for systems
283
in SRC.
284
Public
SDoT SDD
ST Security Target Lite
22 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
2 Conformance claims (ASE_CCL.1)
2.1 CC conformance claim
This Security Target claims conformance to
285
• Common Criteria for Information Technology Security Evaluation, Part 1: Intro-duction
286
and general model, Version 3.1, Revision 5, April 2017, CCMB-2017-04-002 (cf.
287
[CC_Part1])
288
• Common Criteria for Information Technology Security Evaluation, Part 2: Security
289
functional components, Version 3.1, Revision 5, April 2017, CCMB-2017-04-002 (cf.
290
[CC_Part2])
291
• Common Criteria for Information Technology Security Evaluation, Part 3: Security
292
assurance components, Version 3.1, Revision 5, April 2017, CCMB-2017-04-003 (cf.
293
[CC_Part3])
294
in the following way
295
• Part 2 extended
296
• Part 3 conformant
297
The Common Criteria for Information Technology Security Evaluation, Evaluation methodology,
298
Version 3.1, Revision 5, April 2017, CCMB-2017-04-004 (cf. [CEM]) must be considered.
299
2.2 PP Claim
This Security Target does not claim conformance to any existing Protection Profile nor to any
300
existing security functional requirement package.
301
2.3 Package Claim
The assurance packages claimed by the TOE is EAL5 augmented by ALC_FLR.2 and AVA_VAN.5 to
302
the Evaluation Assurance Level EAL5+.
303
2.4 Conformance Rationale
Since the current Security Target does not claim conformance to any existing Protection Profile, a
304
Conformance Rationale is not necessary.
305
Public
SDoT SDD
ST Security Target Lite
23 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
3 Security Problem Definition (ASE_SPD.1)
3.1 Introduction
This chapter introduces the relevant assets which are protected by the TOE and/or its operational
306
environment. Following to that, the subjects and external entities interacting with the TOE are
307
described. Table 8 in section 3.5 outlines the assumptions which describe the security attributes of
308
the TOE operational environment to achieve the intended level of security. Possible threats which
309
must be effectively averted by the TOE, its operational environment, or a combination of both are
310
listed in 3.4, Table 7. The relevant organisational security policies (OSPs) are described in 3.6, Table
311
9.
312
3.2 Assets
In this section the primary assets and secondary assets of the TOE are introduced and categorised
313
into its protective objectives; integrity (I), authenticity (A), and confidentiality (C).
314
3.2.1 Primary Assets
The following primary assets are protected by the TOE and/or its operational environment:
315
# Assets Description Protective
Objective
1. DATA_IN_PROT All confidential data within the network
environment to be protected.
If the use case defines that the network
environment of SRC should be protected against
malicious transmission into the network SRC
and against unwanted intrusion of any type of
data, then the confidential data in SRC must be
considered as main asset.
If the use case defines that the network
environment of DST should be protected against
unintentional transmission of confidential
information from DST, then the confidential data
in DST must be considered as main asset.
C
Table 4 Primary assets
3.2.2 Secondary Assets
For an effective protection of the primary assets the following secondary assets must also be
316
protected by the TOE and/or its operational environment:
317
# Assets Description Protective
Objective
Public
SDoT SDD
ST Security Target Lite
24 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
1. TOE_CFG The integrity of the configuration data of the
TOE shall be protected.
I
2. TOE_SW The integrity of program files of the TOE shall
be protected.
I
3. AUDIT_DATA The confidentiality and integrity of all data of
the audit trail shall be protected. Unauthorised
access shall be effectively prevented.
C, I
4. KEY_DATA The confidentiality, integrity and authenticity of
cryptographic key data shall be protected.
C, I, A
Table 5 Secondary assets
3.3 Subjects and external entities
External entities and subjects that may act as threat agent and perform operations on objects are
318
the following:
319
# Subjects and External
Entities
Description
1. Human Attacker This threat agent could be in both DST- and in SRC network
with the intention to leak protected data from DST to SRC.
2. Non-educated human user This threat agent resides within dedicated admin network.
The non-educated human user may unintentionally
misconfigure the TOE.
3. IT environment The IT environment defines all components outside of the
TOE and outside of the SDoT SDD.
4. Users with the role
Administrator or Auditor
Authorised persons with access to administrating and
auditing functionalities of the TOE.
Table 6 Subjects
3.4 Threats
Any user of the TOE may act as threat agent. This section describes the threats which must be
320
countered by the TOE independently, by its operational environment, or in combination of the two.
321
# Threats Description
1. T.REVEAL_PA Adverse action: Where DST is the network to be protected
against unwanted transmission out of DST, the threat agent
tries to transfer confidential information from DST to a user
(human or IT-system) in SRC network. In the case where
Public
SDoT SDD
ST Security Target Lite
25 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
SRC is the network to be protected, the threat agent tries to
inject malicious data or program files in SRC.
Nonetheless which use case is relevant, in both cases the
goal of the threat agent is to perform data flow from DST
back to SRC.
Threat agent: Human Attacker, IT environment
Asset: DATA_IN_PROT
2. T.REVEAL_SA_TO_UNAUTH Adverse action: The threat agent tries to export or deliver
secondary assets, namely, the TOE configuration data, TOE
program files, audit trail, or cryptographic key data from
TOE to unauthorized user(s) or other IT-system(s) outside
of the TOE or outside of the SDoT SDD.
Threat agent: Human Attacker, IT environment
Asset: TOE_CFG, TOE_SW, AUDIT_DATA, KEY_DATA
3. T.MALICIOUS_CODE Adverse action: A human attacker bypasses the security
functionality of the TOE by importing malicious code into
the TOE so that data can pass against the unidirectional
data flow in the TOE.
Threat agent: Human Attacker, IT environment
Asset: TOE_CFG, TOE_SW
4. T.AUTH Adverse action: An attacker tries to get unauthorised access
to the TOE by bypassing the TOEs authentication
mechanisms. The attacker may pretend to be an authorised
user of the TOE.
Threat agent: Human attacker
Asset: DATA_IN_PROT, TOE_CFG, TOE_SW, KEY_DATA,
AUDIT_DATA
5. T.MISCONFIG Adverse action: A non-educated administrator or auditor
may configure the TOE in an un-intended way. The same
holds for careless administrators.
Threat agent: Administrators and Auditor of the TOE.
Asset: DATA_IN_PROT, TOE_CFG
6. T.AUDIT_CONTROL Adverse action: A human attacker or an IT system, modifies
the audit records of the TOE, so that security incidents or
illegal actions can remain undetected.
Threat agent: Human attacker, IT environment
Asset: AUDIT_DATA
Public
SDoT SDD
ST Security Target Lite
26 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
7. T.AUDIT_COLLAPSE Adverse action: A human attacker or an IT system in the
network area to be protected manipulates the audit trail of
the TOE, to produce an audit overflow or produce a huge
amount of audit data, to make an analysis of audit logs
become increasingly unfeasible.
Threat agent: Human attacker, IT environment
Asset: DATA_IN_PROT, AUDIT_DATA
8. T.AUDIT_ACCESS Adverse action: A human attacker or an IT system from
outside the dedicated admin network tries to gain access to
confidential information from the data records of the audit
trail via a connected network.
Threat agent: Human attacker, IT environment
Asset: DATA_IN_PROT, AUDIT_DATA
Table 7 Threats
Public
SDoT SDD
ST Security Target Lite
27 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
3.5 Assumptions
This section of the SPD describes the security aspects of the operational environment in which the
322
TOE is assumed to be operated.
323
# Assumptions Description
1. A.TRUSTW_ONLY It is assumed that if other components besides the TOE
connect the SRC- and DST network, these do not violate the
security policy of the TOE.
2. A.DIFF_NET It is assumed that the TOE is connected to two different and
separated networks, which are connected to each other only
according to A.TRUSTW_ONLY.
3. A.ACCESS It is assumed that all access to the TOE, and its physical
environment is restricted to authorised persons only. These
include administrators and auditor.
4. A.TRUSTW_STAFF It is assumed that the administrators and the auditors of the
TOE, as well as the privileged users of the underlying
platform, and operational environment are well trained and
follow all policies.
5. A.CRYPTO_UNIT It is assumed that state-of-the-art cryptographic
mechanisms are used. The Crypto Unit which is in scope of
delivery of the TOE SDoT SDD ensure that evaluated
cryptographic operations are used. Further, the Random Bit
Generator of the Crypto Unit is used to securely obtain
random numbers. Further, keys used for audit data
protection are generated by the Crypto Unit.
6. A.CRYPTO_UNIT_USER It is assumed that the private key of privileged users of the
TOE is stored on the users’ personal smart card.
7. A.PKI It is assumed that a trustworthy PKI is available to the TOE.
8. A.NTP_SERVER It is assumed that the operator of the TOE uses a reliable
NTP server for generating trustworthy time stamps.
9. A.L4_PLATFORM The TOE runs on a L4Re which is a minimalised operating
system with a microkernel architecture providing kernel
separation properties. The L4Re is providing an own
compartment for each logical separated part of the TOE.
Within each compartment an own L4Linux, which is a para-
virtualised Linux kernel within the provided hypervisor of
L4Re, is running without privileges, and execute the
processes of the TOE. Further, it is assumed that the process
Public
SDoT SDD
ST Security Target Lite
28 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
separation properties of the L4Linux Kernel are properly
used.
10. A.DEDICATED_ADMIN_NET It is assumed that the physical admin network interface is
connected only to a dedicated network for administration
purposes. Further, it is assumed that the network is protected
and the access to this network is restricted to authorised
users only.
11. A.HIGH_AVAILABILITY It is assumed that the physical HA network interface is only
connected to a dedicated, secure HA network and that access
to this interface is restricted to authorised users.
The physically separated network is the only connection via
the SDoT SDD's heartbeat interface, which is designed to
operate a cluster of redundant SDoT SDDs.
In addition, it is assumed that the HA network is implemented
in a protected operational environment. The security of the
HA network can be achieved by restricting access to its
components to authorised users only and/or by using
suitable network encryption (e.g. a suitable Layer 2 or 3
VPN).
12. A.BOOT It is assumed that the TOE uses the secure start-up and
initialisation mechanisms provided by the UEFI based secure
boot process of the SDoT SDD platform. Further, it is
assumed that the administrators follow the Guidance
Documents to not modify the pre-configured BIOS-settings.
Table 8 Assumptions
Public
SDoT SDD
ST Security Target Lite
29 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
3.6 Organisational Security Policies
This section describes the Organisational Security Policies (OSPs). The TOE, its operational
324
environment, or a combination of the two shall comply with the following OSPs as security rules,
325
procedures or guidelines imposed (or presumed to be imposed) now and/or in future by an actual or
326
hypothetical organisation in the operational environment (cf. A6.3 of [CC_Part1]).
327
# OSPs Description
1. OSP.ADMINS The organisation operating the TOE shall ensure that at least
two different persons have the role of administrator. Only
configuration changes, which are mutually approved by two
administrators of the TOE, shall be accepted.
2. OSP.AUDIT Regarding TOE audit at least one auditor is needed. Due to the
role separation, the auditor shall not be the administrator at the
same time. The auditor is obligated to check the audit logs in
regular time intervals. The time intervals must be defined in a
meaningful manner by the organisation operating the TOE.
Table 9 OSPs
Public
SDoT SDD
ST Security Target Lite
30 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
4 Security Objectives (ASE_OBJ.2)
This chapter describes the security objectives for the TOE and the security objectives for the
328
operational environment of the TOE.
329
4.1 Security Objectives for the TOE
The TOE must comply with the following security objectives
330
# Objective for the TOE Description
1. OT.SANITISED
The TOE shall allow a message flow only from SRC to DST, i.e.,
any attempts to transfer messages from DST to SRC shall
always be blocked by the TOE. Only HTTP- and SMTP responses
of HTTP- and SMTP requests from DST, which are defined by
the TOE-external DST systems, can pass the TOE to SRC after
successful sanitisation of the protocol response.
2. OT.COMM
The TOE shall allow only pre-defined communication channels
from SRC- to DST network, which have following fixed
configuration parameters: entry port, protocol, and destination,
namely, host or -IP address.
3.
OT.USER_AUTHENTIC
ATION
The TOE shall authenticate all privileged users of the TOE before
any actions on the TOE can be performed.
4.
OT.ROLE_SEPARATIO
N
The TOE shall be able to separate the role of the administrators
and auditor of the TOE.
5. OT.FOUR_EYES
Changes to configuration data of the TOE shall only be possible
by strictly following the dual control mechanisms enforced by
the TOE and supported by the operational environment.
6. OT.AUDIT_LOG
The TOE shall log all security relevant events which enables the
auditor to track all the security relevant events. Each audit log
entry shall include details about the event. In case of a critical
security relevant event, the TOE shall additionally send an alarm
email to a configurable list of privileged users to report this
event.
7. OT.AUDIT_PROTECT
The TOE shall provide mechanism to ensure confidentiality and
integrity of the audit trail. Further, the TOE shall provide
mechanisms to protect audit records against event loss or
saturation of the storage device. These mechanisms can consist
of sending an alarm email to a configurable list of privileged
users and changing mode of the TOE from operational- to
maintenance.
8. OT.SECURE_STATE After the initialisation process the TOE shall be constantly in a
secure state. Additionally, the TOE shall always be able to
Public
SDoT SDD
ST Security Target Lite
31 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
protect check its integrity and configuration. If it is, for any
reason, not possible to operate in the secure sate, the TOE shall
block all network traffic trying to pass the TOE by means of
changing the mode from “Operational” to “Maintenance”. Further
the TOE shall send an alarm message to configured privileged
users.
Table 10 Security Objectives for the TOE
Public
SDoT SDD
ST Security Target Lite
32 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
4.2 Security Objectives for the Operational Environment
The operational environment must comply with the following security objectives:
331
# Objective for the Operational
Environment
Description
1. OE.DIFF_NET The TOE shall be connected between two different and
separated networks. The two networks can be identified as
DST and SRC.
2. OE.TRUSTW_ONLY If besides the TOE, there are other connections between the
two, DST- and SRC network, these are established using
trustworthy components only and do not violate the
security policy of the TOE.
3. OE.ACCESS All access to the TOE and its physical operational
environment is restricted to authorised persons only. These
include the auditor and administrators.
4. OE.TRUSTW_STAFF The operational environment shall ensure that all
privileged users of the TOE are trusted by the organisation
operating the TOE.
5. OE.CRYPTO_UNIT The operational environment shall ensure that the TOE is
operated with IT systems which are capable of properly
administrating and auditing of the TOE is sufficiently
cryptographically supported by hardware related security
mechanisms.
Since generation of cryptographic keys are not in scope of
the TOE, the operational environment shall ensure that
state-of-the-art cryptographic mechanisms are used. The
Crypto Unit and Smartcards which are in scope of delivery
of the SDoT SDD ensure that adequate cryptographic
operations are used.
If TLS is used for communication to external systems, the
operational environment shall ensure that the digital
signature for TLS used by the web server and
communication proxies is generated by the Crypto Unit.
Further, it shall be ensured that keys used for audit data
protection is generated by the Crypto Unit.
6. OE.CRYPTO_UNIT_USER The organization operating the TOE shall ensure that the
private key of privileged users of the TOE is stored on the
users’ personal smart card.
Public
SDoT SDD
ST Security Target Lite
33 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
7. OE.PKI The operator of the TOE shall use a trustworthy PKI for
digital signing certificates and generating and
administrating CAs.
8. OE.NTP_SERVER The operator of the TOE shall use a trustworthy NTP server
which is capable to reliably synchronise the time between
all components in the operational environment of the TOE.
9. OE.L4_PLATTFORM The operational environment regarding the operating
system on which the TOE is running shall be an L4Re
microkernel OS where each logically separated part of the
TOE runs in a dedicated compartment. Within each
compartment an own L4Linux, which is a para-virtualised
Linux kernel within the provided hypervisor of L4Re, shall
be used without privileges, and execute the processes of
the TOE. The process separation properties of the L4Linux
Kernel shall be properly used.
10. OE.DEDICATED_ADMIN_NET The TOE shall be connected to a dedicated network for
administration purposes via a specified physical
administration interface. The dedicated administration
network shall be an isolated network. The connection via
the administration network shall be secure and in a
protected operating environment.
11. OE.HIGH_AVAILABILITY In case of usage of High Availability variant of SDoT SDD,
the TOE shall be connected to a physically separated
network consisting of redundant SDoT SDDs cluster via
the specified HA interface only. The connection shall be
secure, and the heartbeat network shall be in a protected
operating environment.
12. OE.BOOT The TOE shall use the secure start-up and initialisation
mechanisms provided by the UEFI based secure boot
process of the SDoT SDD platform.
Table 11 Security Objectives for the Operational Environment
Public
SDoT SDD
ST Security Target Lite
34 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
4.3 Rationale between SPD and security objectives
The following two tables provides the security objectives coverage for the TOE and the security objectives
332
coverage for the operational environment of the TOE.
333
Objectives
for
the
TOE
OT.SANITISED
OT.COMM
OT.USER_AUTHENTICATION
OT.ROLE_SEPARATION
OT.FOUR_EYES
OT.AUDIT_LOG
OT.AUDIT_PROTECT
OT.SECURE_STATE
Threats
T.REVEAL_PA x x x x x x
T.REVEAL_SA_TO_UNA
UTH
x x
T.MALICIOUS_CODE x
T.AUTH
T.MISCONFIG x x x x x
T.AUDIT_CONTROL x x
T.AUDIT_COLLAPSE x
T.AUDIT_ACCESS x
OSPs
OSP.ADMINS x x
OSP.AUDIT x
Table 12 Security Objective for the TOE coverage
Public
SDoT SDD
ST Security Target Lite
35 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Objectives
for
the
op.
environment
OE.DIFF_NET
OE.TRUSTW_ONLY
OE.ACCESS
OE.TRUSTW_STAFF
OE.CRYPTO_UNIT
OE.CRYPTO_UNIT_USER
OE.PKI
OE.L4_PLATTFORM
OE.NTP_SERVER
OE.DEDICATED_ADMIN_NET
OE.HIGH_AVAILABILITY
OE.BOOT
Threats
T.REVEAL_PA x x x x
T.REVEAL_SA_TO_
UNAUTH
x x x x
T.MALICIOUS_CODE x
T.AUTH x
T.MISCONFIG x x
T.AUDIT_CONTROL x x
T.AUDIT_COLLAPSE
T.AUDIT_ACCESS x x
OSPs
OSP.ADMINS x x
OSP.AUDIT x x
Assumptions
A.DIFF_NET x
A.TRUSTW_ONLY x x
A.ACCESS x
A.TRUSTW_STAFF x
A.CRYPTO_UNIT x
A.CRYPTO_UNIT_U
SER
x
A.PKI x
Public
SDoT SDD
ST Security Target Lite
36 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Objectives
for
the
op.
environment
OE.DIFF_NET
OE.TRUSTW_ONLY
OE.ACCESS
OE.TRUSTW_STAFF
OE.CRYPTO_UNIT
OE.CRYPTO_UNIT_USER
OE.PKI
OE.L4_PLATTFORM
OE.NTP_SERVER
OE.DEDICATED_ADMIN_NET
OE.HIGH_AVAILABILITY
OE.BOOT
A.L4_PLATFORM x
A.NTP_SERVER x
A.DEDICATED_ADMI
N_NET
x
A.HIGH_AVAILABILI
TY
x
A.BOOT x
Table 13 Security Objective for the Operational Environment Coverage
Public
SDoT SDD
ST Security Target Lite
37 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
In the following subsections a more detailed justification of the security objectives coverage related to the
334
SPD is given.
335
4.4 Rationale Threats
The following subsections provide a rational on how threats are encountered by the TOE or by the
336
operational environment of the TOE.
337
4.4.1 T.REVEAL_PA
Potential data flow from the DST network to a user (human or IT-System) within the SRC network is
338
countered by a combination of several objectives for the TOE and objectives for the operational
339
environment of the TOE.
340
OT.SANITISED addresses T.REVEAL_PA with the corresponding unidirectional data transfer from SRC- to
341
DST network and sanitising mechanism which sanitises HTTP and SMTP protocol responses sent from
342
DST- to SRC network.
343
OT.COMM ensures that only communication channels with fixed configured parameter can be used for data
344
transfer from SRC- to DST network. Therefore, this objective prevents any other arbitrary communication
345
channel for data transfer from SRC- to DST network or vice versa.
346
OT.USER_AUTHENTICATION addresses T.REVEAL_PA by ensuring that only authorised and
347
authenticated users can access and change configuration of the TOEs security related functionalities.
348
OT.FOUR_EYES ensures that no single administrator of the TOE is able to maliciously misconfigure the
349
TOE, which may lead to any security flaw or leakage of confidential information.
350
OT.AUDIT_LOG enables the auditor to track all changes to the TOE configuration, and identify the
351
corresponding auditors. This objective for the TOE addresses T.REVEAL_PA by motivating the user to not
352
make any light-minded change to the TOE configuration and avoid any misconfiguration of the TOE.
353
OT.SECURE_STATE counters T.REVEAL_PA in the case where after TOE initialisation a secure state cannot
354
be achieved. Here, the TOE will block all traffic and no confidential information can be passed from DST-
355
to SRC network.
356
OE.DIFF_NET, OE.TRUSTW_STAFF and OE.TRUSTW_ONLY support OT.SANITISED by ensuring that all
357
data to be sent between DST- and SRC network have to pass the sanitising mechanism since, there are
358
only trustworthy connection between DST- and SRC network. Further, the organisation operating the TOE
359
ensures that only trustworthy personnel have privileged user roles.
360
Further, OE.DEDICATED_ADMIN_NET supports OT.SANITISED to ensure that the TOE is only configured
361
through a dedicated admin network which supports to protect the configuration of the TOE.
362
4.4.2 T.REVEAL_SA_TO_UNAUTH
OT.SECURE_STATE and OT.AUDIT_PROTECT ensure that the TOE is able to protect own- software,
363
configuration data and integrity, as well as the audit trail against threat, which tries to expose, export or
364
deliver them to unauthorised user or IT-system outside of the TOE. This is supported by
365
OE.TRUSTW_STAFF, OE.TRUSTW_ONLY, and OE.ACCESS to ensure that there are only trustworthy
366
connection between DST- and SRC network and trustworthy personnel accessing the TOE.
367
OE.DEDICATED_ADMIN_NET supports to counter the threat by providing a dedicated and trusted
368
administration network.
369
Public
SDoT SDD
ST Security Target Lite
38 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
4.4.3 T.MALICIOUS_CODE
OT.SECURE_STATE ensures that the TOE is in a secure state after the initialisation process. Periodically
370
performed integrity checks help to verify the current state and help detect any unsigned code.
371
Further, OE.BOOT helps to mitigate the risk of T.MALICIOUS_CODE in the presence of secure boot
372
mechanisms which only allows authentic software to be executed. Additionally, OE.BOOT requires the
373
administrators to keep the securely pre-configures settings of the used BIOS.
374
4.4.4 T.AUTH
OE.DEDICATED_ADMIN_NET counters the threat by providing a dedicated administration network.
375
4.4.5 T.MISCONFIG
OT.FOUR_EYES addresses T.MISCONFIG by avoiding that an administrator could unintentionally
376
misconfigure the TOE by means of enforcing the dual control mechanism.
377
OT.ROLE_SEPARATION limits the privileges of a single user, i.e. administrator is not able to misconfigure
378
the TOE in a way that the configuration change is not logged and not detected by the auditor.
379
OE.ACCESS counters the threat by ensuring that only auditors and administrators have physical access to
380
the TOE.
381
OE.DEDICATED_ADMIN_NET supports to counter the threat by providing a dedicated and trusted
382
administration network.
383
OT.COMM ensures that only allowed protocols are used to avoid any bypass of sanitization mechanisms
384
of the TOE if a threat agent tries to perform any misconfiguration. Fixed and pre-defined communication
385
configuration parameters such as entry port, protocol, and destination, namely, host or -IP address counter
386
the threat so, that it is not possible to choose any other arbitrary parameter.
387
OT.AUDIT_LOG ensures that each configuration change is logged into the audit trail and the identity of the
388
user who is triggering any configuration change is logged. This may limit errors due to misconfiguration of
389
the TOE to a minimum and encourage the user to be more careful. The auditor can analyse the audit trail
390
and detect any possible misconfiguration and replace by a safe and good known configuration.
391
OT.AUDIT_PROTECT ensures that logged configurations are cryptographically protected against
392
manipulation.
393
4.4.6 T.AUDIT_CONTROL
OT.AUDIT_PROTECT counters the threat by protecting the audit data against any attempt of bypassing,
394
deactivating, or manipulating the audit data.
395
OT.ROLE_SEPARATION ensures that only the auditor is able to remove records from the audit trail.
396
OE.ACCESS supports to counter the threat by ensuring that only auditors and administrators have physical
397
access to the TOE.
398
OE.DEDICATED_ADMIN_NET supports to counter the threat by providing a dedicated and trusted
399
administration network.
400
Public
SDoT SDD
ST Security Target Lite
39 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
4.4.7 T.AUDIT_COLLAPSE
OT.AUDIT_PROTECT counters T.AUDIT_COLLAPSE directly by preventing audit overflows.
401
OT.AUDIT_PROTECT requires the TOE to provide mechanisms to protect audit records against event loss
402
or saturation of the storage device.
403
4.4.8 T.AUDIT_ACCESS
OT.ROLE_SEPARATION counters T.AUDIT_ACCESS by ensuring that a privileged user with other user role
404
than the auditor cannot move audit records.
405
OE.DEDICATED_ADMIN_NET supports to counter the threat by providing a dedicated and trusted
406
administration network and OE.ACCESS ensures that only authorised persons have physical access to the
407
TOE and its operational environment.
408
4.5 Rationale OSPs
The following describes how OSPs are enforced by the TOE or by the operational environment of the TOE.
409
4.5.1 OSP.ADMINS
This policy addresses the objective OT.ROLE_SEPARATION about the ability of the TOE to distinguish the
410
administrator role from the auditor, which is assigned to at least two specific persons which are not auditors
411
at the same time. Moreover, the objective OT.FOUR_EYES is also addressed to fulfil dual control process
412
by TOE configuration changes by administrators.
413
The objective OE.TRUSTW_STAFF ensures that the TOE environment is responsible that all privileged
414
users of the TOE are trusted by the organisation operating the TOE.
415
OE.ACCESS ensures that access to the TOE and its physical operational environment is restricted to
416
authorised persons only. These include the auditor and administrators.
417
4.5.2 OSP.AUDIT
This policy addresses the objective OT.ROLE_SEPARATION about the ability of the TOE to distinguish the
418
auditor role from the administrator, which is assigned to specific persons which are not administrators at
419
the same time.
420
The objective OE.TRUSTW_STAFF ensures that the TOE environment is responsible that all privileged
421
users of the TOE are trusted by the organisation operating the TOE.
422
OE.ACCESS ensures that access to the TOE and its physical operational environment is restricted to
423
authorised persons only. These include the auditor and administrators.
424
4.6 Rationale Assumptions
In this section the correspondence between the assumptions, and the objectives for the TOE, or its
425
operational environment is demonstrated.
426
Public
SDoT SDD
ST Security Target Lite
40 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
4.6.1 A.DIFF_NET
The security objective for the operational environment of the TOE OE.DIFF_NET corresponds to the
427
assumption A.DIFF_NET by requiring the TOE to be connected between two different and separated
428
networks.
429
4.6.2 A.TRUSTW_ONLY
OE.TRUSTW_ONLY requires that the TOE is the only connection between the DST- and the SRC network.
430
OE.DIFF_NET supports OE.TRUSTW_ONLY because it requires that the TOE is connected to two different
431
and separated networks.
432
4.6.3 A.ACCESS
This assumption is directly covered by the objective OE.ACCESS which requires that all access to the TOE
433
and its physical operational environment is restricted to authorised users only.
434
4.6.4 A.TRUSTW_STAFF
OE.TRUSTW_STAFF covers the assumption A.TRUSTW_STAFF by requiring that all users of the TOE are
435
trusted by the organisation operating the TOE.
436
4.6.5 A.CRYPTO_UNIT
OE.CRYPTO_UNIT addresses A.CRYPTO_UNIT which ensures that all needed cryptographic support is
437
derived from the cryptographic units which are delivered together with the TOE.
438
4.6.6 A.CRYPTO_UNIT_USER
A.CRYPTO_UNIT_USER is directly addressed by OE.CRYPTO_UNIT_USER.
439
4.6.7 A.PKI
The assumption A.PKI is covered by the objective OE.PKI which requires the operator of the TOE to use a
440
trustworthy PKI.
441
4.6.8 A.NTP_SERVER
The assumption A.NTP_SERVER is covered by the objective OE.NTP_SERVER which requires the operator
442
of the TOE to use a trustworthy NTP server.
443
4.6.9 A.L4_PLATFORM
The assumption A.L4_PLATFORM is covered by the objective OE.L4_PLATTFORM which requires the TOE
444
to run on a L4Re microkernel OS which provides dedicated logical separation mechanisms for each
445
compartment.
446
Public
SDoT SDD
ST Security Target Lite
41 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
4.6.10 A.DEDICATED_ADMIN_NET
The assumption A.DEDICATED_ADMIN_NET is covered by the objective OE.DEDICATED_ADMIN_NET
447
which requires that the TOE is connected to the SDoT Adminstation only through a dedicated network for
448
administration purposes in a protected operating environment. Further, the objective requires that the
449
dedicated admin network is a physically isolated network.
450
4.6.11 A.HIGH_AVAILABILITY
The assumption A.HIGH_AVAILABILITY is addressed by OE.HIGH_AVAILABILITY which requires that if the
451
TOE will be operated in the HA-variant, the operational environment ensures that the physically separated
452
and protected network via the Heartbeat interface is the only used connection.
453
4.6.12 A.BOOT
The assumption A.BOOT is directly addressed by OE.BOOT which requires that the TOE uses the secure
454
start-up and boot mechanisms provided by the underlying platform. Further, the administrators of the TOE
455
are required to use the securely pre-configured BIOS settings.
456
Public
SDoT SDD
ST Security Target Lite
42 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
5 Definition of Security Function Policies (SFPs)
audit access control SFP
Type Name Remark
Subject • User See
FDP_ACF.1.1/AuditAccess
FCS_COP.1/ECDSA/AdminTL
S
Object • AUDIT_DATA
Security Attributes • users X509 signature
Operation • Read/Delete audit records See
FDP_ACF.1.2/AuditAccess
Condition/Rule • Certificate is signed by the
configured AuditCA
• Title field in Distinguished
Name contains “auditor”.
Table 14 audit access control SFP
admin access control SFP
Type Name Remark
Subject • User See
FDP_ACF.1.1/AdminAccess
FCS_COP.1/ECDSA/AdminTL
S
Object • TOE_CFG
Security Attributes • users X509 signature
Operation • all possible operation of the
subject.
See
FDP_ACF.1.2/AdminAccess
Condition/Rule • Certificate is signed by the
configured AdminCA
• Title field in Distinguished
Name contains “sifi-admin”.
Table 15 admin access control SFP
data from SRC SFP
Type Name Remark
Subject • Systems in SRC sending data
• Systems in DST receiving
data
• DATA_IN_SRC
See
FDP_IFF.1.1/DataFromSRC
Information • Content of data
Security Attribute • The domain from which the
data is coming
Operation • permit an information flow
between a controlled subjects
and controlled information via
a controlled operation
See
FDP_IFF.1.2/DataFromSRC
Condition/Rule • Data is received via a
supported protocol at a
configured port for the
protocol.
Public
SDoT SDD
ST Security Target Lite
43 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
• The destination address
corresponds to the allowed
destination addresses for the
incoming port.
Table 16 data from SRC SFP
HTTP response SFP
Type Name Remark
Subject • HTTP-PROXY_HIGH,
• HTTP-PROXY_LOW,
• DATA_IN_DST
See
FDP_IFF.1.1/HTTP
Information • HTTP_response
Security Attributes • The domain from which the
HTTP_response is coming
• Transfer Protocol
• Mode of operation
Operation permit an information flow
between a controlled subjects
and controlled information via
a controlled operation
See
FDP_IFF.1.2/HTTP
Condition/Rule • Source of HTTP_response
is DST
• HTTP_response is
transferred via HTTP(S)
• Mode of operation is
“Operational”
• HTTP_response must be an
answer to a request from
network SRC.
See
FDP_IFF.1.2/HTTP
HTTP sanitisation rule:
• The http body is sanitised
such that it only contains the
status line,
• The status line is sanitised
based on the received status
code (a three-number digit):
a) The status code is
matched against a
configured list of allowed
status codes
b) The status message is
replaced by a fixed text
from the configured list.
• Header Elements
a) Content-Length: 0
b) Date
See
FDP_IFF.1.3/HTTP
Table 17 HTTP response SFP
Public
SDoT SDD
ST Security Target Lite
44 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
ICAP header SFP
Type Name Remark
Subject • SMTP-MTA_HIGH
• SMTP-MTA_LOW
• TCP-RELAY_HIGH
• TCP-RELAY_LOW
• UDP-RELAY_HIGH
• UDP-RELAY_LOW
• DATA_IN_DST
FDP_IFF.1.1/ICAP
Information • ICAP_response
Security Attributes • Mode of operation
• Protocol state
Condition/Rule • Mode of operation is
"operational"
• Message is a response to a ICAP
request
FDP_IFF.1.2/ICAP
Operation • permit an information flow
between a controlled subjects
and controlled information via a
controlled operation
FDP_IFF.1.2/ICAP
• Remove all headers FDP_IFF.1.3/ICAP
Table 18 ICAP header SFP
ICAP response SFP
Type Name Remark
Subject • SMTP-MTA_HIGH
• SMTP-MTA_LOW
• TCP-RELAY_HIGH
• TCP-RELAY_LOW
• UDP-RELAY_HIGH
• UDP-RELAY_LOW
• DATA_IN_DST
FDP_IFF.1.1/ICAP
Information • ICAP-response
Security Attributes • Mode of operation
• Protocol state
Condition/Rule • Mode of operation is
"operational"
• Message is a response to a ICAP
request
FDP_IFF.1.2/ICAP
Public
SDoT SDD
ST Security Target Lite
45 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
ICAP response SFP
Operation • permit an information flow
between a controlled subjects
and controlled information via a
controlled operation
FDP_IFF.1.2/ICAP
• Parse the Response-Line into
"Response code" (three digits)
and "Response string"
• Check that the "Response code"
is between "100" and "999"
(inclusive) Replace with default
if fails
• Check the "Response string"
against hard coded list. Replace
with default (based on the
"Response code" (full or first
digit)) if fails
• Remove any other content of the
ICAP response
FDP_IFF.1.3/ICAP
Table 19 ICAP response SFP
NTP synchronize SFP
Type Name Remark
Subject • NTP services in DST or in SRC
• NTP service and hosts in
Admin Net
• NTP clients in DST or in SRC
See
FDP_IFF.1.1/NTP
Information • TOE system time
Security Attributes • Origin of time reference
Operation • permit an information flow
between a controlled subjects
and controlled information via
a controlled operation
See
FDP_IFF.1.2/NTP
Condition/Rule NTP synchronize rule:
The time can be synchronized
between SRC and DST using the TOE
by one of the following ways:
• The system time of the TOE is
optionally synchronized via:
a) the NTP Server in
subsystem DI_HGH to a
NTP Service in network
DST.
b) the NTP Server in
subsystem DI_GUI to a
See
FDP_IFF.1.3/NTP
Public
SDoT SDD
ST Security Target Lite
46 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
NTP Service in Admin
Net.
c) the NTP Server in
subsystem DI_LOW to a
NTP Service in Network
SRC
• The system time of the TOE is
optionally provided via:
a) the NTP Server in
subsystem DI_HGH to
hosts in network DST
b) the NTP Server in
subsystem DI_GUI to
hosts in Admin Net
c) the NTP Server in
subsystem DI_LOW to
hosts in network SRC.
Table 20 NTP synchronize SFP
dual control admin SFP
Type Name Remark
Subject • User trying to modify the TOE
general configuration
The TOE enforces dual
control mechanisms which
ensures that changes to the
general TOE configuration
must be confirmed by a
second administrator.
Object • general TOE configuration -
Security Attribute • user_role User role
Operation • modify, add or delete general
TOE configuration
See
FMT_MTD.1/AdminModify
Condition/Rule • user_role = administrator
Table 21 dual control admin SFP
Public
SDoT SDD
ST Security Target Lite
47 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
6 Extended components definition (ASE_ECD.1)
6.1 Class FPT: Protection of the TSF
6.1.1 TSF integrity checks (FPT_INC)
Family Behaviour
457
The family defines the requirements for the self-testing of the TSF with respect to integrity checks of TSF
458
data. Examples are the integrity of general TOE configuration data and TSF executable code. The actions
459
to be taken by the TOE as the result of self-testing are defined in other families.
460
Application Note: The other families of the class FPT do not provide a family which only refers to periodic
461
integrity checks during start-up, during operation or upon request of an authorised user. In the following,
462
the family FPT_INC TSF Integrity Checks will be defined in accordance with the style used in the Common
463
Criteria Part 2, cf. sections 6 and 7 in [CC_Part2].
464
Component Levelling
465
FPT_INC.1 TSF Integrity, provides the ability to verify the integrity of TSF data and TSF itself. This test may
466
be performed at start-up, periodically, at the request of the authorised user, or when other conditions are
467
met.
468
Management FPT_INC.1
469
a) management of the conditions under which TSF self-testing occurs, such as during initial
470
start-up, regular interval, or under specified conditions.
471
b) management of the time interval if appropriate.
472
Audit: FPT_INC.1
473
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
474
PP/ST:
475
a) Basic: Execution of the TSF self-tests and the results of the tests.
476
FPT_INC.1 TSF Integrity
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_INC.1.1 The TSF shall run a suite of integrity checks [selection: during initial start-up,
periodically during normal operation, at the request of the authorised user, at the
conditions [assignment: conditions under which integrity check should occur]] to
demonstrate the integrity of [selection: [assignment: parts of TSF data, parts of
TSF], the TSF, the TSF data].
FPT_INC.1.2 The TSF shall provide authorised users with the capability to verify the integrity
of [selection: [assignment: parts of TSF data], TSF data].
FPT_INC.1.3 The TSF shall provide authorised users with the capability to verify the integrity
of [selection: [assignment: parts of TSF], TSF].
Public
SDoT SDD
ST Security Target Lite
48 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
7 Statement of security requirements (ASE_REQ.2)
This section defines the security functional requirements according to [CC_Part2] and the security
477
assurance requirements (SARs) from [CC_Part3], which apply for the TOE.
478
7.1 Security functional requirements
The following table outlines the Security Functional Requirements (SFRs) for the TOE:
479
# User Data Protection (FDP)
1. FDP_ACC.2/AuditAccess Complete access control
2. FDP_ACC.2/AdminAccess Complete access control
3. FDP_ACF.1/AuditAccess Security attribute based access control
4. FDP_ACF.1/AdminAccess Security attribute based access control
5. FDP_ETC.1/AuditKeys Export of user data without security attributes
6. FDP_IFC.2/DataFromSRC Subset information flow control
7. FDP_IFC.2/HTTP Complete information flow control
8. FDP_IFC.2/ICAP Complete information flow control
9. FDP_IFC.2/NTP Complete information flow control
10. FDP_IFF.1/DataFromSRC Simple security attributes
11. FDP_IFF.1/HTTP Simple security attributes
12. FDP_IFF.1/ICAP Simple security attributes
13. FDP_IFF.1/NTP Simple security attributes
14. FDP_ITC.1/Keys/AdminTLS Import of user data without security attributes
Identification and authentication (FIA)
15. FIA_UAU.2 User authentication before any action
16. FIA_UID.2 User identification before any action
Cryptographic support (FCS)
17. FCS_CKM.1/AES/Audit Cryptographic key generation
18. FCS_CKM.1/HMAC/Audit Cryptographic key generation
19. FCS_CKM.2/AES/Audit Cryptographic key distribution
20. FCS_CKM.2/HMAC/Audit Cryptographic key distribution
21. FCS_CKM.4 Cryptographic key destruction
22. FCS_COP.1/ECDSA/AdminTLS Cryptographic operation
23. FCS_COP.1/AES/Audit Cryptographic operation
24. FCS_COP.1/HMAC/Audit Cryptographic operation
25. FCS_COP.1/SHA2/Audit Cryptographic operation
26. FCS_COP.1/SHA2/Integrity Cryptographic operation
Security management (FMT)
27. FMT_MSA.1/AdminCA Management of security attributes
28. FMT_MSA.1/OpMode Management of security attributes
29. FMT_MSA.3 Static attribute initialisation
30. FMT_MTD.1/AdminAccess Management of TSF data
31. FMT_MTD.1/AdminModify Management of TSF data
32. FMT_MTD.1/AuditAccess Management of TSF data
33. FMT_MTD.1/AuditDelete Management of TSF data
34. FMT_MTD.3 Secure TSF data
Public
SDoT SDD
ST Security Target Lite
49 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
35. FMT_SMF.1 Specification of management functions
36. FMT_SMR.2 Restrictions on security roles
Protection of the TSF (FPT)
37. FPT_STM.1 Reliable time stamps
38. FPT_INC.1 TSF integrity
39. FPT_RCV.1 Manual recovery
Security audit (FAU)
40. FAU_ARP.1 Security audit automatic response
41. FAU_GEN.1 Audit data generation
42. FAU_GEN.2 User identity association
43. FAU_SAA.1 Security audit analysis
44. FAU_SAR.1 Security audit review
45. FAU_SAR.2 Restricted audit review
46. FAU_STG.2 Guarantees of audit data availability
47. FAU_STG.4 Prevention of audit data loss
Table 22 SFRs of the TOE
The following styles of marking operations are applied:
480
• Assignments are denoted in bold.
481
• Selections are marked in italic underlined.
482
• Iterations are marked by adding a “/” and short name to the SFR identification.
483
• Refinements indicating additions are marked in bold and italic underlined.
484
• Refinements indicating removals are marked as crossed out.
485
7.1.1 User Data Protection (FDP)
FDP_ACC Access control policy
FDP_ACC.2/AuditAccess Complete access control
Hierarchical to: FDP_ACC.1 Subset access control
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.2.1/AuditAccess The TSF shall enforce the audit access control SFP on users,
AUDIT_DATA and all operations among subjects and objects covered
by the SFP.
FDP_ACC.2.2/AuditAccess The TSF shall ensure that all operations between any subject
controlled by the TSF and any object controlled by the TSF are
covered by an access control SFP.
FDP_ACC.2/AdminAccess Complete access control
Hierarchical to: FDP_ACC.1 Subset access control
Dependencies: FDP_ACF.1 Security attribute based access control
Public
SDoT SDD
ST Security Target Lite
50 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FDP_ACC.2.1/AdminAccess The TSF shall enforce the admin access control SFP on users,
TOE_CFG, and all operations among subjects and objects covered by
the SFP.
FDP_ACC.2.2/AdminAccess The TSF shall ensure that all operations between any subject
controlled by the TSF and any object controlled by the TSF are
covered by an access control SFP.
FDP_ACF Access control functions
FDP_ACF.1/AuditAccess Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1/AuditAccess The TSF shall enforce the audit access control SFP to objects based
on the following:
1. Subject: user
2. Object: AUDIT_DATA
3. Security Attributes: users X509 signature.
FDP_ACF.1.2/AuditAccess The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
operation: Read/Delete audit records
condition:
1. Certificate is signed by the configured AuditCA
2. Title field in Distinguished Name contains “auditor”.
FDP_ACF.1.3/AuditAccess The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: none.
FDP_ACF.1.4/AuditAccess The TSF shall explicitly deny access of subjects to objects based on
the following additional rules: none.
FDP_ACF.1/AdminAccess Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1/AdminAccess The TSF shall enforce the admin access control SFP to objects based
on the following:
1. Subject: user
2. Object: TOE_CFG
Public
SDoT SDD
ST Security Target Lite
51 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
3. Security Attributes: users X509 signature.
FDP_ACF.1.2/AdminAccess The TSF shall enforce the following rules to determine if an operation
among controlled subject and controlled objects is allowed:
operation:
1. all possible operation of the subject.
condition:
1. Certificate is signed by the configured AdminCA
2. Title field in Distinguished Name contains “sifi-admin”.
FDP_ACF.1.3/AdminAccess The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: none.
FDP_ACF.1.4/AdminAccess The TSF shall explicitly deny access of subjects to objects based on
the following additional rules: none.
FDP_ETC Export from the TOE
FDP_ETC.1/AuditKeys Export of user data without security attributes
Hierarchical to:
No other components
Dependencies:
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_ETC.1.1/AuditKeys The TSF shall enforce the audit access control SFP when exporting
user data, controlled under the SFP(s) the keys used to protect the
confidentiality and integrity of the Audit Trail, outside of the TOE.
FDP_ETC.1.2/AuditKeys The TSF shall export the user data without the user data's associated
security attributes
Application Note: FDP_ETC.1.2/AuditKeys is crossed out because there are no user data’s associated
security attributes to be considered.
FDP_IFC Information flow control policy
FDP_IFC.2/DataFromSRC Complete information flow control
Hierarchical to: FDP_IFC.1 Subset information flow control
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.2.1/DataFromSRC The TSF shall enforce the data from SRC SFP on Systems in SRC
sending data, Systems in DST receiving data, DATA_IN_SRC, Content
of data and all operations that cause that information to flow to and
from subjects covered by the SFP.
Public
SDoT SDD
ST Security Target Lite
52 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FDP_IFC.2.2/DataFromSRC The TSF shall ensure that all operations that cause any information in
the TOE to flow to and from any subject in the TOE are covered by an
information flow control SFP.
FDP_IFC.2/HTTP Complete information flow control
Hierarchical to: FDP_IFC.1 Subset information flow control
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.2.1/HTTP The TSF shall enforce the HTTP response SFP on HTTP-
PROXY_HIGH, HTTP-PROXY_LOW, DATA_IN_DST, HTTP_response
and all operations that cause that information to flow to and from
subjects covered by the SFP.
FDP_IFC.2.2/HTTP The TSF shall ensure that all operations that cause any information in
the TOE to flow to and from any subject in the TOE are covered by an
information flow control SFP.
FDP_IFC.2/ICAP Complete information flow control
Hierarchical to: FDP_IFC.1 Subset information flow control
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.2.1/ICAP The TSF shall enforce the ICAP header SFP and ICAP response SFP
on SMTP-MTA_HIGH, SMTP-MTA_LOW, TCP-RELAY_HIGH, TCP-
RELAY_LOW, UDP-RELAY_HIGH, UDP-RELAY_LOW, DATA_IN_DST,
ICAP_response and all operations that cause that information to flow
to and from subjects covered by the SFP.
FDP_IFC.2.2/ICAP The TSF shall ensure that all operations that cause any information in
the TOE to flow to and from any subject in the TOE are covered by an
information flow control SFP.
FDP_IFC.2/NTP Complete information flow control
Hierarchical to: FDP_IFC.1 Subset information flow control
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.2.1/NTP The TSF shall enforce the NTP synchronize SFP on NTP services in
DST or in SRC, NTP service and hosts in Admin Net, NTP clients in DST
or in SRC, TOE system time and all operations that cause that
information to flow to and from subjects covered by the SFP.
FDP_IFC.2.2/NTP The TSF shall ensure that all operations that cause any information in
the TOE to flow to and from any subject in the TOE are covered by an
information flow control SFP.
Public
SDoT SDD
ST Security Target Lite
53 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FDP_IFF Information flow control functions
FDP_IFF.1/DataFromSRC Simple security attributes
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1/DataFromSRC The TSF shall enforce the data from SRC SFP based on the following
types of subjects and information security attributes:
Subjects:
1. Systems in SRC sending data
2. Systems in DST receiving data
3. DATA_IN_SRC
Information:
1. Content of data
Security Attribute:
1. The domain from which the data is coming
FDP_IFF.1.2/DataFromSRC The TSF shall permit an information flow between a controlled
subjects and controlled information via a controlled operation if the
following rules hold:
1. Data is received via a supported protocol at a configured port
for the protocol.
2. The destination address corresponds to the allowed
destination addresses for the incoming port.
FDP_IFF.1.3/DataFromSRC The TSF shall enforce the none.
FDP_IFF.1.4/DataFromSRC The TSF shall explicitly authorise an information flow based on the
following rules: none
FDP_IFF.1.5/DataFromSRC The TSF shall explicitly deny an information flow based on the
following rules: none
Application Note: The supported protocols are SMTP, HTTP, TCP and UDP
FDP_IFF.1/HTTP Simple security attributes
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Public
SDoT SDD
ST Security Target Lite
54 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FDP_IFF.1.1/HTTP The TSF shall enforce the HTTP response SFP based on the following
types of subjects and information security attributes:
Subjects:
1. HTTP-PROXY_HIGH,
2. HTTP-PROXY_LOW,
3. DATA_IN_DST
Information:
1. HTTP_response
Security Attributes:
1. The domain from which the HTTP_response is coming
2. Transfer Protocol
3. Mode of operation
FDP_IFF.1.2/HTTP The TSF shall permit an information flow between a controlled
subjects and controlled information via a controlled operation if the
following rules hold:
1. Source of HTTP_response is DST
2. HTTP_response is transferred via HTTP(S)
3. Mode of operation is “Operational”
4. HTTP_response must be an answer to a request from
network SRC.
FDP_IFF.1.3/HTTP The TSF shall enforce the HTTP sanitisation rule:
1. The http body is sanitised such that it only contains the status
line,
2. The status line is sanitised based on the received status code
(a three-number digit):
a. The status code is matched against a configured list
of allowed status codes
b. The status message is replaced by a fixed text from
the configured list.
3. Header Elements
a. Content-Length: 0
b. Date
FDP_IFF.1.4/HTTP The TSF shall explicitly authorise an information flow based on the
following rules: none
FDP_IFF.1.5/HTTP The TSF shall explicitly deny an information flow based on the
following rules: none
FDP_IFF.1/ICAP Simple security attributes
Hierarchical to: No other components.
Public
SDoT SDD
ST Security Target Lite
55 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Dependencies:
FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1/ICAP The TSF shall enforce the ICAP header SFP and the ICAP response
SFP based on the following types of subjects and information security
attributes:
Subjects:
1. SMTP-MTA_HIGH
2. SMTP-MTA_LOW
3. TCP-RELAY_HIGH
4. TCP-RELAY_LOW
5. UDP-RELAY_HIGH
6. UDP-RELAY_LOW
7. DATA_IN_DST
Information:
1. ICAP_response
Security Attributes:
1. Mode of operation
2. Protocol state
FDP_IFF.1.2/ICAP The TSF shall permit an information flow between a controlled
subjects and controlled information via a controlled operation if the
following rules hold:
1. Mode of operation is “Operational”.
2. Message is a response to an ICAP request
FDP_IFF.1.3/ICAP The TSF shall enforce the ICAP header SFP:
1. Remove all headers
and the ICAP response SFP:
1. Parse the Response-Line into "Response code" (three digits)
and "Response string"
2. Check that the "Response code" is between "100" and "999"
(inclusive) Replace with default if fails
3. Check the "Response string" against hard coded list. Replace
with default (based on the "Response code" (full or first digit))
if fails
4. Remove any other content of the ICAP response
FDP_IFF.1.4/ICAP
The TSF shall explicitly authorise an information flow based on the
following rules: none
FDP_IFF.1.5/ICAP
The TSF shall explicitly deny an information flow based on the
following rules: none
FDP_IFF.1/NTP Simple security attributes
Public
SDoT SDD
ST Security Target Lite
56 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Hierarchical to:
No other components.
Dependencies:
FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1/NTP The TSF shall enforce the NTP synchronize SFP based on the
following types of subjects and information security attributes:
Subjects:
1. NTP services in DST or in SRC
2. NTP service and hosts in Admin Net
3. NTP clients in DST or in SRC
Information:
1. TOE system time
Security Attributes:
1. Origin of time reference
FDP_IFF.1.2/NTP The TSF shall permit an information flow between a controlled
subjects and controlled information via a controlled operation if the
following rules hold: none
FDP_IFF.1.3/NTP The TSF shall enforce the NTP synchronize rule:
The time can be synchronized between SRC and DST using the TOE by
one of the following ways:
1. The system time of the TOE is optionally synchronized via:
a. the NTP Server in subsystem DI_HGH to a NTP
Service in network DST.
b. the NTP Server in subsystem DI_GUI to a NTP
Service in Admin Net.
c. the NTP Server in subsystem DI_LOW to a NTP
Service in Network SRC
2. The system time of the TOE is optionally provided via:
a. the NTP Server in subsystem DI_HGH to hosts in
network DST
b. the NTP Server in subsystem DI_GUI to hosts in
Admin Net
c. the NTP Server in subsystem DI_LOW to hosts in
network SRC.
FDP_IFF.1.4/NTP
The TSF shall explicitly authorise an information flow based on the
following rules: none
FDP_IFF.1.5/NTP
The TSF shall explicitly deny an information flow based on the
following rules: none
FDP_ITC Import from outside of the TOE
FDP_ITC.1/Keys/AdminTLS Import of user data without security attributes
Public
SDoT SDD
ST Security Target Lite
57 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_MSA.3 Static attribute initialisation
FDP_ITC.1.1/Keys/AdminTLS The TSF shall enforce the admin access control SFP when importing
user data, controlled under the SFP ECDSA Keys for AdminTLS in
accordance with PKCS#12, from outside of the TOE.
FDP_ITC.1.2/Keys/AdminTLS The TSF shall ignore any security attributes associated with the user
data when imported from outside the TOE.
FDP_ITC.1.3/Keys/AdminTLS The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TOE:
1. The Key must be defined on one of the following curves:
secp384r1, brainpoolP384r1, and brainpoolP512r1
Application Note: FDP_ITC.1.2/Keys/AdminTLS crossed out because there are no security attributes
associated with user data
7.1.2 Identification and authentication (FIA)
FIA_UAU User authentication
FIA_UAU.2 User authentication before any action
Hierarchical to: FIA_UAU.1 Timing of authentication
Dependencies: FIA_UID.2 Timing of identification
FIA_UAU.2.1 The TSF shall require each privileged user to be successfully
authenticated before allowing any other TSF-mediated actions
on behalf of that user.
FIA_UID Timing of identification
FIA_UID.2 Timing of identification
Hierarchical to: FIA_UID.1 Timing of identification
Dependencies: No dependencies
FIA_UID.2.1 The TSF shall require each privileged user to be successfully
identified before allowing any other TSF-mediated actions on
behalf of that user.
Public
SDoT SDD
ST Security Target Lite
58 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Application Note: TSF mediated actions can only be accessed via the AuditGUI or the AdminGUI.
The AuditGUI and the AdminGUI can only be accessed via TLS with mutual authentication. The
user role is determined by its title field within the Distinguished Name of the user’s certificate.
7.1.3 Cryptographic support (FCS)
FCS_CKM Cryptographic key management
FCS_CKM.1/AES/Audit Cryptographic key generation
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1/AES/Audit The TSF shall generate cryptographic keys for Advanced Encryption
Standard in accordance with a specified cryptographic key generation
algorithm direct generation from a PTG.2 and specified cryptographic
key sizes 256 bits that meet the following: NIST SP 800-133 Rev. 2
Application Note: This SFR is partially fulfilled by the TOE environment (the installer and crypto unit).
FCS_CKM.1/HMAC/Audit Cryptographic key generation
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1/HMAC/Audit The TSF shall generate cryptographic keys for HMAC-SHA-384 in
accordance with a specified cryptographic key generation algorithm
direct generation from a PTG.2 and specified cryptographic key sizes
384 bits that meet the following: NIST SP 800-133 Rev. 2.
Application Note: This SFR is partially fulfilled by the TOE environment (the installer and crypto unit).
FCS_CKM.2/AES/Audit Cryptographic key distribution
Hierarchical to: No other components
Dependencies: [FDP_ITC.1 Import of user data without security attributes,
or FDP_ITC.2 Import of user data with security attributes,
or FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
Public
SDoT SDD
ST Security Target Lite
59 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FCS_CKM.2.1/AES/Audit The TSF shall distribute cryptographic keys in accordance with a
specified cryptographic key distribution method Inter-Compartment
Key Copy via MNGT Interface that meets the following: MNGT
Protocol.
Application Note: The MNGT Interface is specified in the FSP part of the ADV Doxy-documentation.
FCS_CKM.2/HMAC/Audit Cryptographic key distribution
Hierarchical to: No other components
Dependencies: [FDP_ITC.1 Import of user data without security attributes,
or FDP_ITC.2 Import of user data with security attributes,
or FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.2.1/HMAC/Audit The TSF shall distribute cryptographic keys in accordance with a
specified cryptographic key distribution method Inter-Compartment
Key Copy via MNGT Interface that meets the following: MNGT
Protocol.
Application Note: The MNGT Interface is specified in the FSP part of the ADV Doxy-documentation.
FCS_CKM.4 Cryptographic key destruction
Hierarchical to: No other components
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method overwriting the key
with zeros that meets the following: none.
Application Note: This SFR refers to the keys in ephemeral memory and not to the keys stored for long-
term storage on the smart card.
FCS_COP.1/ECDSA/AdminTL
S
Cryptographic operation
Hierarchical to: No other components
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
Public
SDoT SDD
ST Security Target Lite
60 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FCS_COP.1.1/ECDSA/AdminT
LS
The TSF shall perform digital signature verification in accordance with
a specified cryptographic algorithm ECDSA and cryptographic key
sizes 384 Bit and 512 Bit that meet the following: signature verification
as specified in ANSI X9.62 with keys based on the ECC domain
parameters secp384r1, brainpoolP384r1, and brainpoolP512r1 with
sha2 according to curve size as sub function.
Application Note: Although the establishment of the secure TLS connection itself is not within the scope
of the TOE, for evaluation purposes, information about cryptographic procedures is considered. As
already mentioned in the introductory part in Table 1: In this SFR TLS is only used to ensure that the
correct roles log on to the TOE within the dedicated admin network.
The TLS supports the following:
TLS-Version 1.3, 1.2
Cipher Suites 1.3 TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
Cipher Suites 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Signature Algorithms ecdsa_brainpoolP512r1tls13_sha512
ecdsa_brainpoolP384r1tls13_sha384
ecdsa_secp384r1_sha384
Supported Groups brainpoolP512r1
brainpoolP384r1
secp384r1
Permitted signature algorithms of
the client certificate
ECDSA_with_SHA512
ECDSA_with_SHA384
ECDSA_with_SHA256
Certificate Verification Mutually Mandatory
FCS_COP.1/AES/Audit Cryptographic operation
Hierarchical to: No other components
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/AES/Audit The TSF shall perform encryption and decryption in accordance with
a specified cryptographic algorithm AES in GCM mode and
cryptographic key sizes 256 Bit that meet the following: FIPS 197
and SP800-38D.
Public
SDoT SDD
ST Security Target Lite
61 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FCS_COP.1/HMAC/Audit Cryptographic operation
Hierarchical to: No other components
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/HMAC/Audit The TSF shall perform hash-based message authentication code in
accordance with a specified cryptographic algorithm HMAC-SHA2
and cryptographic key sizes 384 Bit that meet the following: RFC
2104.
FCS_COP.1/SHA2/Audit Cryptographic operation
Hierarchical to: No other components
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/SHA2/Audit The TSF shall perform Hash value calculation in accordance with a
specified cryptographic algorithm SHA-384 and cryptographic key
size none that meet the following: FIPS 180-4.
Application Note: The cryptographic algorithm specified here is SHA-384.
FCS_COP.1/SHA2/Integrity Cryptographic operation
Hierarchical to: No other components
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/SHA2/Integrity The TSF shall perform Hash value calculation in accordance with a
specified cryptographic algorithm SHA-384 and cryptographic key
size none that meet the following: FIPS 180-4.
Application Note: The cryptographic algorithm specified here is SHA-384.
7.1.4 Security management (FMT)
FMT_MSA Management of security attributes
Public
SDoT SDD
ST Security Target Lite
62 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FMT_MSA.1/AdminCA Management of security attributes
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset
information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1Specification of Management Functions
FMT_MSA.1.1/AdminCA The TSF shall enforce the admin access control SFP to restrict
the ability to change accepted values of the security attributes
AdminCA to Administrators.
FMT_MSA.1/OpMode Management of security attributes
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset
information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1Specification of Management Functions
FMT_MSA.1.1/OpMode The TSF shall enforce the admin access control SFP to restrict
the ability to modify the security attributes mode of operation to
Administrators.
FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other components
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1 The TSF shall enforce the admin access control SFP, audit access
control SFP, data from SRC SFP, dual control admin SFP, HTTP
response SFP, ICAP header SFP, ICAP response SFP, and NTP
synchronize SFP to provide fixed default values for security
attributes that are used to enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the no one to specify alternative initial values
to override the default values when an object or information is
created.
Application Note: Security Attributes, as mentioned in FDP_IFF and FDP_ACF, are not configurable.
FMT_MTD Management of TSF data
FMT_MTD.1/AdminAccess Management of TSF data
Public
SDoT SDD
ST Security Target Lite
63 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1/AdminAccess The TSF shall restrict the ability to access the TOE_CFG to
administrators of the TOE.
FMT_MTD.1/AdminModify Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1/AdminModify The TSF shall restrict the ability to modify the TOE_CFG to two
different administrators under dual control.
FMT_MTD.1/AuditAccess Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1/AuditAccess The TSF shall restrict the ability to access the audit trail to
auditors.
FMT_MTD.1/AuditDelete Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1/AuditDelete The TSF shall restrict the ability to delete or move the audit data
to auditors.
FMT_MTD.3 Secure TSF data
Hierarchical to: No other components.
Dependencies: FMT_MTD.1 Management of TSF data
FMT_MTD.3.1 The TSF shall ensure that only secure values are accepted for the
TOE_CFG.
FMT_SMF Specification of Management Functions
FMT_SMF.1 Specification of Management Functions
Public
SDoT SDD
ST Security Target Lite
64 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
Hierarchical to: No other components
Dependencies: No dependencies
FMT_SMF.1.1 The TSF shall be capable of performing the following
management functions:
General management of TOE_CFG
Management of security notifications:
- Define receiver of notifications regarding security
events
- Define rules for monitoring audited events regarding
security violations.
Operation mode management:
- Change the mode of the TOE from “Operational” to
“Maintenance”
- Change the mode of the TOE from “Maintenance” to
“Operational”
Audit functions and audit trail management:
- Create audit record archives of the TOE to be able to
export the archive.
Application Note: Management of User IDs, credentials for authentication, authorised user roles are
provided by a CA of the TOE environment. Identification and authentication mechanisms for human
users are provided by certificates.
FMT_SMR Security management roles
FMT_SMR.2 Restriction on security roles
Hierarchical to: FMT_SMR.1 Security roles
Dependencies: FIA_UID.2 Timing of identification
FMT_SMR.2.1 The TSF shall maintain the roles: administrator and auditor.
FMT_SMR.2.2 The TSF shall be able to associate users with roles.
FMT_SMR.2.3 The TSF shall ensure that the conditions Administrator and
auditor roles are strictly separated, are satisfied.
Application Note: Users are associated to the respective roles with a CA outside the TOE.
Public
SDoT SDD
ST Security Target Lite
65 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
7.1.5 Protection of the TSF (FPT)
FPT_STM Time stamp
FPT_STM.1 Reliable time stamps
Hierarchical to: No other components
Dependencies: No dependencies
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
Application Note: The reliability is achieved by synchronising with an NTP-Server which is an
assumption to the operational environment of the TOE. Nonetheless, the TOE implements the
protocol for time synchronisation.
FPT_INC TSF integrity checks
FPT_INC.1 TSF integrity
Hierarchical to: No other components
Dependencies: No dependencies
FPT_INC.1.1 The TSF shall run a suite of integrity checks during initial start-up,
periodically during normal operation to demonstrate the integrity
of general configuration data and stored TSF executable code.
FPT_INC.1.2 The TSF shall provide authorised users with the capability to verify
the integrity of general configuration data.
FPT_INC.1.3 The TSF shall provide authorised users with the capability to verify
the integrity of stored TSF executable code.
FPT_RCV Trusted recovery
FPT_RCV.1 Manual recovery
Hierarchical to: No other components.
Dependencies: AGD_OPE.1 Operational user guidance
FPT_RCV.1.1 After, refer to list in Application Note, the TSF shall enter a
maintenance mode where the ability to return to a secure state is
provided.
Application Note: The maintenance mode can also be activated by an administrator under dual
control. The following lists the events for entering the maintenance mode by the TOE
- SmartCard as CryptoUnit is non-responsive
Public
SDoT SDD
ST Security Target Lite
66 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
- Not all compartments could be reached
- Webserver certificate on SmartCard invalid
- Error from audit check
- Audit not available
- Configuration integrity fail
- Time has been manipulated
- TPM-Error
- System not initializied
- CryptoUnit not ready
- Problems while initializing at least one process, when changing in operational mode
- Integrity check failed
- Full storage
7.1.6 Security audit (FAU)
FAU_ARP Security audit automatic response
FAU_ARP.1 Security alarms
Hierarchical to: No other components
Dependencies: FAU_SAA.1 Potential violation analysis
FAU_ARP.1.1 The TSF shall take the following actions:
- send an e-mail to a configurable list of recipients
- report into the audit-trail
- place an indicator of any potential security violation on
the Audit GUI
upon detection of a potential security violation.
FAU_GEN Security audit data generation
FAU_GEN.1 Audit data generation
Hierarchical to: No other components
Dependencies: FPT_STM.1 Reliable time stamps
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 not Specified level of audit; and
c) See Table 23.
,FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information:
Public
SDoT SDD
ST Security Target Lite
67 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
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, the
information in Table 23
Application Note:
For all the auditable events for the TOE, see 8.1.5.1 The following table gives an overview of
auditable events and information available in the audit trail.
Auditable events in the
TOE
Available information in audit record
Changes to the TOE
configuration and
parameters
Value of changed TOE configuration and parameter before and after
the change was made, i.e.
- start and stop of the TOEs system
- change of mode of operation
- administration activities
- message transfer and sanitisation of HTTP and SMTP
responses
- authentication against the TOE
- alarm
Processing data
messages
The following audit data are recorded while processing the data of
a message:
- origin,
- destination,
- time of transfer,
- the data which can uniquely identify the message
Table 23 auditable events
FAU_GEN.2 User identity association
Hierarchical to: No other components
Dependencies FAU_GEN.1 Audit data generation
FIA_UID.2 Timing of identification
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF
shall be able to associate each auditable event with the identity of
the user that caused the event.
FAU_SAA Security audit analysis
FAU_SAA.1 Potential violation analysis
Hierarchical to: No other components
Dependencies FAU_GEN.1 Audit data generation
Public
SDoT SDD
ST Security Target Lite
68 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FAU_SAA.1.1 The TSF shall be able to apply a set of rules in monitoring the
audited events and based upon these rules indicate a potential
violation of the enforcement of the SFRs.
FAU_SAA.1.2 The TSF shall enforce the following rules for monitoring audited
events:
a) Accumulation or combination of auditable events:
- Underflow of audit storage capacity
- Upcoming expiration of certificates
- Errors during self-tests.
known to indicate a potential security violation;
b) none
Application Note: The TSF examines not only the validity of GUI certificates but also any other key
materials, which are imported and stored in the key storage. If any of the certificates expires or
will expire soon, there is a corresponding entry in the audit and alarm email for privileged users.
FAU_SAR Security audit review
FAU_SAR.1 Audit review
Hierarchical to: No other components
Dependencies: FAU_GEN.1 Audit data generation
FAU_SAR.1.1 The TSF shall provide auditors with the capability to read all audit
information from the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the
user to interpret the information.
FAU_SAR.2 Restricted audit review
Hierarchical to: No other components
Dependencies: FAU_SAR.1 Audit review
FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records,
except those users that have been granted explicit read access.
FAU_STG Security audit event storage
FAU_STG.2 Guarantees of audit data availability
Hierarchical to: FAU_STG.1 Protected audit trail storage
Dependencies: FAU_GEN.1 Audit data generation
Public
SDoT SDD
ST Security Target Lite
69 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FAU_STG.2.1 The TSF shall protect the stored audit records in the audit trail from
unauthorised deletion.
FAU_STG.2.2 The TSF shall be able to prevent unauthorised modifications to the
stored audit records in the audit trail.
Application Note:
The TOE protects the authenticity and integrity of the audit records with an HMAC using sha384
in accordance to RFC 2104.
FAU_STG.2.3 The TSF shall ensure that all stored audit records will be
maintained when the following conditions occur: audit storage
exhaustion, failure, attack
FAU_STG.4 Prevention of audit data loss
Hierarchical to: FAU_STG.3 Action in case of possible audit data loss
Dependencies: FAU_STG.1 Protected audit trail storage
FAU_STG.4.1 The TSF shall prevent audited events, except those taken by the
authorised user with special rights and
1. inform a configurable list of recipients (E-Mail Addresses
of administrators and auditors) by an alarm message and
2. inform the auditor by an audit record and an alarm counter
on the audit GUI, if the audit trail exceeds 80% of the total
capacity of the audit trail storage device;
3. preserve a secure state (maintenance mode), if the audit
trail exceeds 95% of the total capacity of the audit trail
storage device and inform the administrators and the
auditors by an audit record in which no data can be
forwarded from SRC- to DST network;
4. prevent the change of the TOE configuration and send an
alarm email to the administrators, if 99% of the total
capacity of the audit trail storage device is full.
7.2 Dependency Rationale
The dependency rationale for Security Functional Requirements shows that the basis for mutual support
486
including the internal consistency between in sec. 7.1 defined Security Functional Requirements are
487
satisfied. The following table provides an overview showing that all dependencies between the chosen
488
Security Functional Components are analysed, and non-dissolved dependencies are sufficiently explained.
489
# SFR Dependencies Support of the Dependencies
1. FDP_ACC.2
FDP_ACF.1 Security attribute
based access control
Fulfilled by FDP_ACF.1
Public
SDoT SDD
ST Security Target Lite
70 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
# SFR Dependencies Support of the Dependencies
2. FDP_ACF.1
FDP_ACC.1
Subset access control
FMT_MSA.3
Static attribute initialisation
Fulfilled by FDP_ACC.2 which
is hierarchical
Fulfilled by FMT_MSA.3
3. FDP_ETC.1
[FDP_ACC.1 Subset access
control, or
FDP_IFC.1 Subset information
flow control]
Fulfilled by FDP_ACC.2 which
is hierarchical
Fulfilled by FDP_IFC.2 which
is hierarchical
4. FDP_IFC.2
FDP_IFF.1
Simple security attributes
Fulfilled by FDP_IFF.1
5. FDP_IFF.1
FDP_IFC.1 Subset information
flow control
FMT_MSA.3
Static attribute initialisation
Fulfilled by FDP_IFC.2 which
is hierarchical
Fulfilled by FMT_MSA.3
6. FDP_ITC.1
[FDP_ACC.1 Subset access
control, or
FDP_IFC.1 Subset information
flow control]
FMT_MSA.3 Static attribute
initialisation
Fulfilled by FDP_ACC.2 which
is hierarchical
Fulfilled by FDP_IFC. 2 which
is hierarchical
Fulfilled by FMT_MSA.3
7. FIA_UAU.2
FIA_UID.1
Timing of identification
Fulfilled by FIA_UID.2 which is
hierarchical
8. FIA_UID.2 No dependencies n.a.
9.
FCS_CKM.1FCS_CK
M.1FCS_CKM.1FCS_
CKM.1
[FCS_CKM.2 Cryptographic key
distribution, or
FCS_COP.1 Cryptographic
operation]
FCS_CKM.4 Cryptographic key
destruction
Fulfilled by FCS_COP.1 and
FCS_CKM.4
10. FCS_CKM.2
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data
with security attributes, or
FCS_CKM.1 Cryptographic key
generation]
FCS_CKM.4 Cryptographic key
destruction
Fulfilled by FDP_ITC.1 and
FCS_CKM.4
Public
SDoT SDD
ST Security Target Lite
71 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
# SFR Dependencies Support of the Dependencies
11. FCS_CKM.4
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data
with security attributes, or
FCS_CKM.1 Cryptographic key
generation]
Fulfilled by FDP_ITC.1 and
FCS_CKM.1FCS_CKM.1
12. FCS_COP.1
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data
with security attributes, or
FCS_CKM.1 Cryptographic key
generation]
FCS_CKM.4 Cryptographic key
destruction
Fulfilled by the Crypto Unit in
the operational environment.
13. FMT_MSA.1
[FDP_ACC.1
Subset access control, or
FDP_IFC.1 Subset information
flow control]
FMT_SMR.1
Security roles
FMT_SMF.1
Specification of Management
Functions
Fulfilled by FDP_ACC.2 which
is hierarchical
Fulfilled by FMT_SMR.2
which is hierarchical to
FMT_SMR.1
Fulfilled by FMT_SMF.1
14. FMT_MSA.3
FMT_MSA.1
Management of security
attributes
FMT_SMR.1
Security roles
Fulfilled by FMT_MSA.1
Fulfilled by FMT_SMR.2
which is hierarchical to
FMT_SMR.1
15. FMT_MTD.1
FMT_SMR.1
Security roles
FMT_SMF.1
Specification of Management
Functions
Fulfilled by FMT_SMR.2
which is hierarchical to
FMT_SMR.1
Fulfilled by FMT_SMF.1
16. FMT_MTD.3
FMT_MTD.1
Management of TSF data
Fulfilled by FMT_MTD.1
17. FMT_SMF.1 No dependencies n.a.
18. FMT_SMR.2
FIA_UID.2
Timing of identification
Fulfilled by FIA_UID.2
Public
SDoT SDD
ST Security Target Lite
72 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
# SFR Dependencies Support of the Dependencies
19. FPT_STM.1 No dependencies n.a.
20. FPT_INC.1 No dependencies n.a.
21. FPT_RCV.1
AGD_OPE.1 Operational user
guidance
n.a.
22. FAU_ARP.1
FAU_SAA.1
Potential violation analysis
Fulfilled by FAU_SAA.1
23. FAU_GEN.1
FPT_STM.1
Reliable time stamps
Fulfilled by FPT_STM.1
24. FAU_GEN.2
FAU_GEN.1
Audit data generation
FIA_UID.2
Timing of identification
Fulfilled by FAU_GEN.1
Fulfilled by FIA_UID.2
25. FAU_SAA.1
FAU_GEN.1
Audit data generation
Fulfilled by FAU_GEN.1
26. FAU_SAR.1
FAU_GEN.1
Audit data generation
Fulfilled by FAU_GEN.1
27. FAU_SAR.2
FAU_SAR.1
Audit review
Fulfilled by FAU_SAR.1
28. FAU_STG.2
FAU_GEN.1
Audit data generation
Fulfilled by FAU_GEN.1
29. FAU_STG.4
FAU_STG.1
Protected audit trail storage
Fulfilled by FAU_STG.2 which
is hierarchical to FAU_STG.1
Table 24 Dependencies between the Security Functional Requirements (SFRs) for the TOE
7.3 Security assurance requirements rationale
The assurance level for evaluation of the TOE, its life cycle and operating environment are chosen as the
490
pre-defined assurance level EAL5 augmented with the following assurance components in accordance
491
with [CC_Part3]:
492
• ALC_FLR.2 Flaw reporting procedures.
493
• AVA_VAN.5 Advanced methodical vulnerability analysis
494
This corresponds to a total assurance level EAL5+. EAL5 is the highest level at which it is likely to be
495
economically to retrofit the existing product line of INFODAS GmbH.
496
The Level EAL5 augmented with ALC_FLR.2 was chosen to permit INFODAS GmbH as a developer to gain
497
maximum assurance from positive security engineering based on good commercial development practices
498
Public
SDoT SDD
ST Security Target Lite
73 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
which, though rigorous, do not require substantial specialist knowledge, skills, and other resources. The
499
selection of the component ACL_FLR.2 provides additional assurance of the TOE that potential security
500
flaws can be tracked and corrected by the developer.
501
Using AVA_VAN.5 component as augmentation for the level EAL5 allows to confirm that the TOE’s security
502
measures provide the uppermost level of protection against the high attack potential.
503
Augmented assurance components are marked in bold in the following table:
504
Assurance class Assurance Family Assurance Component
Development
ADV_ARC ADV_ARC.1 Security architecture
description
ADV_FSP ADF_FSP.5 Complete semi-formal
functional specification with additional
error information
ADV_IMP ADV_IMP.1 Implementation
representation of the TSF
ADV_INT ADV_INT.2 Well-structured internals
ADV_TDS ADV_TDS.4 Semiformal modular design
Guidance documents
AGD_OPE AGD_OPE.1 Operational user guidance
AGD_PRE AGD_PRE.1 Preparative procedures
Life-cycle support
ALC_CMC ALC_CMC.4 Production support,
acceptance procedures and automation
ALC_CMS ALC_CMS.5 Development tools CM
coverage
ALC_DEL ALC_DEL.1 Delivery procedures
ALC_DVS ALC_DVS.1 Identification of security
measures
ALC_FLR ALC_FLR.2 Flaw reporting procedures
ALC_LCD ALC_LCD.1 Developer defined life-cycle
model
ALC_TAT ALC_TAT.2 Compliance with
implementation standards
Security target evaluation ASE_CCL ASE_CCL.1 Conformance claims
Public
SDoT SDD
ST Security Target Lite
74 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
ASE_ECD ASE_ECD.1 Extended components
definition
ASE_INT ASE_INT.1 ST introduction
ASE_OBJ ASE_OBJ.2 Security objectives
ASE_REQ ASE_REQ.2 Derived security
requirements
ASE_SPD ASE_SPD.1 Security problem definition
ASE_TSS ASE_TSS.1 TOE summary specification
Tests
ATE_COV ATE_COV.2 Analysis of coverage
ATE_DPT ATE_DPT.3 Testing: modular design
ATE_FUN ATE_FUN.1 Functional testing
ATE_IND ATE_IND.2 Independent testing –
sample
Vulnerability assessment
AVA_VAN AVA_VAN.5 Advanced methodical
vulnerability analysis
Table 25 Security Assurance Requirements (SARs)
Public
SDoT SDD
ST Security Target Lite
75 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
7.4 Security Functional Requirements Rationale
The following subsections provide an overview regarding the coverage of Security Objectives for the TOE by
505
Security Functional Requirements and a rational of the chosen Security Assurance Requirements. The
506
following table shows an overview for the tracing of SFRs back to the security objectives for the TOE.
507
# SFRs
OT.SANITISED
OT.COMM
OT.USER_AUTHENTICATION
OT.ROLE_SEPARATION
OT.FOUR_EYES
OT.AUDIT_LOG
OT.AUDIT_PROTECT
OT.SECURE_STATE
1. FDP_ACC.2/AuditAccess x x x
2. FDP_ACC.2/AdminAccess x x
3. FDP_ACF.1/AuditAccess x x x
4. FDP_ACF.1/AdminAccess x x
5. FDP_ETC.1/AuditKeys x x
6. FDP_IFC.2/DataFromSRC x x
7. FDP_IFC.2/HTTP x
8. FDP_IFC.2/ICAP x
9. FDP_IFC.2/NTP x
10. FDP_IFF.1/DataFromSRC x x
11. FDP_IFF.1/HTTP x
12. FDP_IFF.1/ICAP x
13. FDP_IFF.1/NTP x
14. FDP_ITC.1/Keys/AdminTLS x x
15. FIA_UAU.2 x
16. FIA_UID.2 x
17. FCS_CKM.1/AES/Audit x
18. FCS_CKM.1/HMAC/Audit x
19. FCS_CKM.2/AES/Audit x
20. FCS_CKM.2/HMAC/Audit x
21. FCS_CKM.4 x
22. FCS_COP.1/ECDSA/AdminTLS x
23. FCS_COP.1/AES/Audit x
24. FCS_COP.1/HMAC/Audit x
25. FCS_COP.1/SHA2/Audit x
26. FCS_COP.1/SHA2/Integrity x
27. FMT_MSA.1/AdminCA x x x
28. FMT_MSA.1/OpMode x x x
29. FMT_MSA.3 x
30. FMT_MTD.1/AdminAccess x x
31. FMT_MTD.1/AdminModify x x
32. FMT_MTD.1/AuditAccess x
33. FMT_MTD.1/AuditDelete x x
34. FMT_MTD.3 x
35. FMT_SMF.1 x x x
36. FMT_SMR.2 x
Public
SDoT SDD
ST Security Target Lite
76 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
# SFRs
OT.SANITISED
OT.COMM
OT.USER_AUTHENTICATION
OT.ROLE_SEPARATION
OT.FOUR_EYES
OT.AUDIT_LOG
OT.AUDIT_PROTECT
OT.SECURE_STATE
37. FPT_STM.1 x
38. FPT_INC.1 x
39. FPT_RCV.1 x
40. FAU_ARP.1 x
41. FAU_GEN.1 x
42. FAU_GEN.2 x
43. FAU_SAA.1 x
44. FAU_SAR.1 x
45. FAU_SAR.2 x x
46. FAU_STG.2 x
47. FAU_STG.4 x
Table 26 Coverage of the Security Objectives for the TOE by SFRs
7.4.1 OT.SANITISED
OT.SANITISED is fulfilled by FDP_IFC.2/HTTP, FDP_IFC.2/ICAP, FDP_IFC.2/NTP, FDP_IFF.1/HTTP,
508
FDP_IFF.1/ICAP, FDP_IFF.1/NTP . These SFRs make sure that only data which comply to HTTP
509
response SFP, ICAP header SFP, ICAP response SFP, and NTP synchronize SFP are allowed to be
510
sent from DST- to SRC network.
511
512
7.4.2 OT.COMM
The SRFs, FDP_IFC.2/DataFromSRC and FDP_IFF.1/DataFromSRC address the security objective
513
OT.COMM about information flow through secure and defined communication channels from SRC-
514
to DST network.
515
7.4.3 OT.USER_AUTHENTICATION
The security objective OT.USER_AUTHENTICATION aims to ensure that all users of the TOE are
516
authenticated before any other action can be performed.
517
This objective is mainly achieved by FIA_UID.2 and FIA_UAU.2 which require that all users are
518
identified and authenticated considering the application note in FIA_UID.2.
519
FDP_ACC.2/AuditAccess and FDP_ACF.1/AuditAccess enforce the audit access control SFP in order
520
to identification and authentication of auditors to access, read, delete the audit trail.
521
FDP_ACC.2/AdminAccess and FDP_ACF.1/AdminAccess enforce the admin access control SFP in
522
order to identification and authentication of auditors to access and read the General TOE
523
configuration.
524
Public
SDoT SDD
ST Security Target Lite
77 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
FDP_ETC.1/AuditKeys enforces the audit access control SFP for identification and authentication of
525
auditors to export the audit keys via AuditGUI using TLS connection.
526
Secure import of the cryptographic keys from outside of the TOE is ensured via
527
FDP_ITC.1/Keys/AdminTLS.
528
The destruction of the keys at ephemeral memory, when they are no longer needed, is fulfilled via
529
FCS_CKM.4.
530
FCS_COP.1/ECDSA/AdminTLS makes it possible to perform signature verification to authenticate
531
the user via the secure TLS connection.
532
FMT_MSA.1/AdminCA and FMT_MSA.1/OpMode ensure that only Administrators permitted to
533
access and change the security attributes in the TOE.
534
535
7.4.4 OT.ROLE_SEPARATION
The security objective OT.ROLE_SEPARATION aims to ensure that the TOE can separate the role of
536
all administrators and auditor or the TOE. This is achieved by the following SFRs:
537
FMT_SMR.2 assures that the roles of administrator and auditor are separated and there is no
538
possibility of simultaneous log-in. FMT_SMF.1 provides functionalities which give access to general
539
configuration of user IDs, credentials for authentication and authorised user roles.
540
FMT_MTD.1/AuditAccess, FMT_MTD.1/AuditDelete, FDP_ACF.1/AuditAccess,
541
FDP_ACC.2/AuditAccess with FAU_SAR.2 achieve the security objective by assuring that only the
542
role of the auditor is able to read or delete audit records from the audit trail.
543
FDP_ETC.1/AuditKeys enforces the audit access control SFP in order to identification and
544
authorisation of auditors to export the audit keys via Audit-GUI.
545
FMT_MTD.1/AdminAccess, FMT_MTD.1/AdminModify, FMT_MSA.1/AdminCA,
546
FMT_MSA.1/OpMode, FDP_ACC.2/AdminAccess, FDP_ACF.1/AdminAccess achieve the security
547
objective by assuring that only the role of the respective administrator is able to read or
548
delete/modify general TOE configuration data as well as TOE’s security attributes.
549
550
7.4.5 OT.FOUR_EYES
FMT_MTD.1/AdminAccess ensure that only the administrator can have the access to the TOE
551
configuration and FMT_MTD.1/AdminModify ensures that the administrator can make the
552
corresponding change only under dual control through second administrator.
553
554
7.4.6 OT.AUDIT_LOG
This security objective aims that the TOE logs all changes to configuration data where the auditor
555
can track all changes and identify the user. FAU_GEN.1 is achieving this objective by requiring the
556
TOE to provide audit records for all changes made on the TOE configuration with time data and user
557
data. FAU_GEN.2 ensures that each individual user who made any change is tracked. FPT_STM.1
558
ensures that the TOE obtains reliable time stamps which added to the audit record. FMT_SMF.1
559
assures the configuration capability of the addressees of the warning notification.
560
561
Public
SDoT SDD
ST Security Target Lite
78 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
7.4.7 OT.AUDIT_PROTECT
This security objective is achieved by FDP_ACC.2/AuditAccess, FDP_ACF.1/AuditAccess and
562
FMT_MTD.1/AuditDelete which ensures that only the auditor can delete or move audit records from
563
the audit trail. FAU_STG.2 provides the protection of stored audit records from modification and from
564
unauthorised removal from the audit trail. Further, FAU_STG.2 requires that stored audit records
565
are maintained if the audit storage is full or a failure of the storage occurs.
566
FCS_COP.1/HMAC/Audit, FCS_COP.1/AES/Audit, FCS_COP.1/SHA2/Audit,
567
FCS_CKM.1/AES/Audit, FCS_CKM.1/HMAC/Audit, FCS_CKM.2/AES/Audit,
568
FCS_CKM.2/HMAC/Audit addresses the cryptographic algorithms used to protect the integrity and
569
confidentiality of the audit records.
570
FAU_SAR.1 requires that the TOE provides mechanisms that auditors can read the audit records and
571
FAU_SAR.2 ensures that only users who have been granted access have read access to the records.
572
FAU_STG.4 reduces the risk of losing audit records by providing alerting mechanisms to be able to
573
detect exhaustions of the storage.
574
575
7.4.8 OT.SECURE_STATE
OT.SECURE_STATE has the objective that after initialisation process the TOE is constantly in a
576
secure state FAU_ARP.1, enables the TOE to detect potential insecure states, and if so, enter the
577
maintenance mode.
578
FDP_IFC.2/DataFromSRC and FDP_IFF.1/DataFromSRC support the TOE to enforce the data from
579
SRC SFP to perform correctly under operational mode, which prevents bypassing the secure data
580
transfer path.
581
FCS_COP.1/SHA2/Integrity addresses the cryptographic algorithms used to check the integrity of
582
the TOE’s general configuration data.
583
FAU_SAA.1 corresponds to the TOE monitoring and detection ability of critical security events
584
concerning audit storage capacity and upcoming certificate expiration as well as errors during self-
585
tests.
586
FPT_INC.1 addresses performing self-test of the TOE during initial start-up and periodically whilst
587
operational mode. This functionality enables the TOE to check up the integrity of the general
588
configuration. If any failure is detected, the TOE changes its mode from operational to maintenance.
589
Regarding to manual recovery, FPT_RCV.1 ensures that the TOE can return to a secure state again.
590
FDP_ITC.1/Keys/AdminTLS enforces the admin access control SFP to protect the TOE when the
591
keys (as part of secondary assets) are imported from the outside of the TOE. Beside that these keys
592
shall fulfil pre-defined elliptic curves requirements.
593
FMT_MSA.1/AdminCA also enforces the admin access control SFP to restrict ability for change of
594
accepted values of AdminCA to administrators.
595
FMT_MSA.1/OpMode enforces the admin access control SFP to restrict the ability to modify
596
security attributes mode of operation, as part of general configuration of the TOE, to administrator
597
to protect secure operation.
598
FMT_MSA.3 ensures that through enforcing all defined security function policies for the TOE to
599
provide fixed default values for security attributes for the TOE.
600
Public
SDoT SDD
ST Security Target Lite
79 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
To protect the TOE Security Functionality FMT_MTD.3 ensures that only secure values for the TOE
601
configuration and the TOE software are accepted.
602
FMT_SMF.1 ensures the management ability of general configuration, audit functions, security
603
notifications, as well as mode of operation of the TOE.
604
The focus of the SDoT SDD is on the aspect of confidentiality, i.e. it prevents sensitive information
605
from flowing from the network DST to the network SRC. From an operational perspective,
606
availability is also a very important aspect for uninterrupted operation. However, high availability is
607
not a primary security function. Despite this, it must be ensured that when configuration changes
608
are made on the primary node of the high availability variant, the configuration data on the
609
secondary nodes is synchronized with integrity, since manipulation could negatively affect the
610
security functionality of a node.
611
Public
SDoT SDD
ST Security Target Lite
80 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
8 TOE Summary Specification (ASE_TSS.1)
This section describes the security mechanisms of the TOE and how these meet the SFRs.
612
8.1 TOE Security Functions
8.1.1 SF_PR: Protocol Response
The TOE provides unidirectional protocol transfer from SRC- to DST network and protocol status
613
responding mechanisms to SRC network which is the main security functionality of the TOE. The
614
following subsections will describe the main security properties of SF_PR.
615
8.1.1.1 SF_PR.1
The TOE enforces the HTTP- and ICAP response SFPs as well as ICAP header SFP for messages
616
which is sent between two different and separated networks. The TOE allows only a unidirectional
617
message flow from SRC- to DST network. No message flow from DST- to SRC network is possible.
618
Except for time synchronisation purposes (NTP), there shall not exist any other open port at the
619
interface between the TOE compartment, DI_HGH and DST network.
620
8.1.1.2 SF_PR.2
The TOE enforces the data from SRC SFP for all protocol data units coming from SRC network. In
621
accordance with FDP_IFF.1/DataFromSRC the only supported communication protocols are the
622
following: SMTP, HTTP, UDP, and TCP. Also, within the TOE only the following configured set of
623
communication protocols is supported: SMTP, HTTP, UDP and TCP.
624
8.1.1.3 SF_PR.3
The TOE being in maintenance mode does not let pass any message. The component of the TOE
625
which is responsible for forwarding the messages and sanitising the responses do not accept
626
messages and responses in maintenance mode. The components that are responsible for
627
administration and logging respectively auditing are not influenced in their functionality by this state
628
change.
629
8.1.1.4 SF_PR.4
There is no confidential information stored longer than needed in the memory. The memory is
630
zeroised after the message data and all security critical data was processed by the TOE.
631
8.1.1.5 SFRs addressed by SF_PR
632
The security function SF_PR addresses the requirements of the following SFRs:
633
FDP_IFC.2/DataFromSRC, FDP_IFC.2/HTTP, FDP_IFC.2/ICAP, FDP_IFC.2/NTP Subset information
634
flow control; FDP_IFF.1/DataFromSRC, FDP_IFF.1/HTTP, FDP_IFF.1/ICAP, FDP_IFF.1/NTP
635
Simple security attributes; and FMT_SMF.1 Specification of Management Functions and.
636
Public
SDoT SDD
ST Security Target Lite
81 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
8.1.2 SF_CP: Channel Protection
The TOE supports several mechanisms to provide security functionalities related to covert channel
637
protection. The following security properties of the TOE are included:
638
8.1.2.1 SF_CP
The TOE enforces HTTP response SFP, ICAP header SFP, ICAP response SFP and NTP synchronize
639
SFP on all protocol data units which are sent from DST- to SRC network. The TOE sanitises any
640
protocol responses sent in direction of SRC network. A sanitised response only contains a known
641
status code and a pre-configured corresponding string which shortly describes the status code.
642
8.1.2.2 SFRs addressed by SF_CP
The security function SF_CP addresses the requirements of the following SFRs: FDP_IFF.1/HTTP,
643
FDP_IFF.1/ICAP, FDP_IFF.1/NTP Simple security attributes.
644
8.1.3 SF_DP: Data Protection
The TOE protects TSF data from modification with periodic integrity checks. These are general
645
configuration data, audit parameters, and public certificates. These parameters are integrity
646
protected with a fingerprint value, for cross-checking with known answer stored on the server
647
smartcard. The parameter values are transferred encrypted between the SDoT Adminstation and
648
the TOE via a dedicated admin network over a mutually authenticated TLS connection. However, the
649
secure TLS connection itself is not within the scope of the TOE. The Crypto Unit provides the
650
cryptographic support for signature generation.
651
Further, the TOE imports only the message data which are sent through the communication
652
protocols SMTP, HTTP, UDP and TCP.
653
8.1.3.1 SFRs addressed by SF_DP
The security function SF_DP addresses the requirements of the following SFRs: FDP_IFC.2/HTTP,
654
FDP_IFC.2/ICAP Subset information flow control FDP_IFF.1/HTTP, FDP_IFF.1/ICAP Simple
655
security attributes.
656
8.1.4 SF_AA: Authentication and Authorisation
The TOE includes security functionalities to provide authentication and authorisation mechanisms
657
which addresses the related SFRs. The TOE supports a secure channel initiated by the SDoT
658
Adminstation within a dedicated admin network. Based on Admin TLS connection establishment, the
659
authentication and authorisation can be performed.
660
SFRs addressed by SF_AA
661
FAU_SAR.2 Restricted audit review, FDP_ACC.2/AuditAccess Subset access control,
662
FDP_ACC.2/AdminAccess Subset access control, FDP_ACF.1/AuditAccess Security attribute based
663
access control, FDP_ACF.1/AdminAccess Security attribute based access control,
664
FDP_ETC.1/AuditKeys Export of user data without security attributes, FIA_UAU.2 User
665
authentication before any action, FIA_UID.2 Timing of identification, FMT_MSA.1/AdminCA,
666
FMT_MSA.1/OpMode Management of security attributes, FMT_MTD.1/AdminAccess,
667
FMT_MTD.1/AdminModify, Management of TSF data, FMT_MTD.1/AuditAccess Management of
668
Public
SDoT SDD
ST Security Target Lite
82 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
TSF data, FDP_IFF.1/HTTP, FDP_IFF.1/ICAP, FDP_ITC.1/Keys/AdminTLS Import of user data
669
without security attributes, FDP_IFF.1/NTP Simple security attributes, FMT_MTD.1/AuditDelete
670
Management of TSF data, FMT_SMF.1 Specification of Management Functions, FMT_SMR.2
671
Restriction on security roles, FCS_CKM.4 Cryptographic key destruction,
672
FCS_COP.1/ECDSA/AdminTLS Cryptographic operation.
673
8.1.5 SF_AT: Audit Trail
The TOE includes security functionalities to meet the requirements addressed in the related SFRs
674
as listed in 8.1.5.2.
675
Upon detection of a potential security violation the TOE takes the following actions:
676
a. The TOE sends an e-mail to a configurable list of addressees
677
b. Generates an audit entry into the audit trail
678
c. Indicates the potential security violation on the audit GUI
679
For each auditable event resulting from an action of the authenticated human user, the TOE
680
associates the audit record unambiguously with the user role who performed any auditable action.
681
All audited records are provided by the TOE in a manner suitable for the auditor to interpret the
682
information. Audit information are displayed in a human readable presentation on the audit GUI. Only
683
the user with the role of the auditor has read access to the audit records.
684
8.1.5.1 Auditable Events
685
• Not available in ST-Lite version
686
8.1.5.2 SFRs addressed by SF_AT
FDP_ACF.1/AuditAccess Security attribute based access control, FDP_ETC.1/AuditKeys Export of
687
user data without security attributes, FAU_ARP.1 Security alarms, FAU_GEN.1 Audit data
688
generation, FAU_GEN.2 User identity association, FAU_SAA.1 Potential violation analysis,
689
FAU_SAR.1 Audit review, FAU_SAR.2 Restricted audit review, FAU_STG.2 Guarantees of audit data
690
availability, FAU_STG.4 Prevention of audit data loss, FDP_ACC.2/AuditAccess Subset access
691
control, FMT_MSA.3 Static attribute initialisation, FMT_MTD.1/AuditAccess, Management of TSF
692
data, FMT_MTD.1/AuditDelete, Management of TSF data, FMT_SMF.1 Specification of
693
Management Functions, FMT_SMR.2 Restriction on security roles, FPT_STM.1 Reliable time
694
stamps, FCS_COP.1/AES/Audit, FCS_COP.1/HMAC/Audit, and FCS_COP.1/SHA2/Audit
695
Cryptographic operation, FCS_CKM.1/AES/Audit, FCS_CKM.1/HMAC/Audit, Cryptographic key
696
generation, and FCS_CKM.2/AES/Audit, FCS_CKM.2/HMAC/Audit.
697
8.1.6 SF_SP: Self Protection
The TOE includes several functionalities to provide self-protection mechanisms. The TOE enforces
698
the policy dual control admin SFP on all users attempting to change the general TOE configuration
699
The TOE enforces that two different users of role administrator are required to be able to change
700
(modify, insert, delete) the general TOE configuration.
701
The TOE ensures that no message flow from SRC- to DST network is possible in maintenance mode.
702
Public
SDoT SDD
ST Security Target Lite
83 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
The factory settings of all processes, i.e. after installation or after reset to default values, must be
703
strictly defined. If a process cannot start because of problems with the actual configuration data, i.e.
704
there are missing or erroneous values, the process will start with the factory settings.
705
The TOE provides a function to manage the mode of operation, for instance to put the TOE into
706
maintenance mode and back to operational mode.
707
The TOE provides authorised users with the capability to verify the integrity of general configuration
708
data and public certificates. The TOE provides authorised users the capability to verify the integrity
709
of stored TSF executable code. Further, the TOE cicely triggers integrity checks which are
710
automatically performed and during each restart of the TOE the integrity checks are performed.
711
Cryptographic references are securely stored in the Crypto Unit within the operational environment
712
of the TOE, which is included in the scope of delivery.
713
8.1.6.1 SFRs addressed by SF_SP
FDP_IFF.1/HTTP, FDP_IFF.1/ICAP, , FDP_IFF.1/NTP Simple security attributes, FMT_MSA.3 Static
714
attribute initialisation, FMT_MTD.1/AdminModify Management of TSF data, FPT_INC.1 TSF
715
integrity, FCS_COP.1/SHA2/Integrity Cryptographic operation, FPT_RCV.1 Manual recovery,
716
FMT_MTD.3 Secure TSF data, and FMT_SMF.1 Specification of Management Functions.
717
Public
SDoT SDD
ST Security Target Lite
84 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
8.2 TOE Summary Specification Rationale
The following table provides an overview of the demonstration in 8.1 regarding the coverage of the
718
SFRs by the TSFs.
719
# SFRs TSFs
1. FDP_ACC.2/AuditAccess SF_AA, SF_AT
2. FDP_ACC.2/AdminAccess SF_AA,
3. FDP_ACF.1/AuditAccess SF_AA, SF_AT
4. FDP_ACF.1/AdminAccess SF_AA
5. FDP_ETC.1/AuditKeys SF_AA, SF_AT
6. FDP_IFC.2/DataFromSRC SF_PR
7. FDP_IFC.2/HTTP SF_DP, SF_PR
8. FDP_IFC.2/ICAP SF_DP, SF_PR
9. FDP_IFC.2/NTP SF_PR
10. FDP_IFF.1/DataFromSRC SF_PR
11. FDP_IFF.1/HTTP SF_AA, SF_SP, SF_DP, SF_CP, SF_PR
12. FDP_IFF.1/ICAP SF_AA, SF_SP, SF_DP, SF_CP, SF_PR
13. FDP_IFF.1/NTP SF_AA, SF_SP, SF_CP, SF_PR
14. FDP_ITC.1/Keys/AdminTLS SF_AA
15. FIA_UAU.2 SF_AA
16. FIA_UID.2 SF_AA
17. FCS_CKM.1/AES/Audit SF_AT
18. FCS_CKM.1/HMAC/Audit SF_AT
19. FCS_CKM.2/AES/Audit SF_AT
20. FCS_CKM.2/HMAC/Audit SF_AT
21. FCS_CKM.4 SF_AA
22. FCS_COP.1/ECDSA/AdminTLS SF_AA
23. FCS_COP.1/AES/Audit SF_AT
24. FCS_COP.1/HMAC/Audit SF_AT
25. FCS_COP.1/SHA2/Audit SF_AT
26. FCS_COP.1/SHA2/Integrity SF_SP
27. FMT_MSA.1/AdminCA SF_AA
28. FMT_MSA.1/OpMode SF_AA
29. FMT_MSA.3 SF_AT, SF_SP
30. FMT_MTD.1/AdminAccess SF_AA
31. FMT_MTD.1/AdminModify SF_AA, SF_SP
32. FMT_MTD.1/AuditAccess SF_AA, SF_AT
33. FMT_MTD.1/AuditDelete SF_AA, SF_AT
34. FMT_MTD.3 SF_SP
35. FMT_SMF.1 SF_AA, SF_AT, SF_SP, SF_PR
36. FMT_SMR.2 SF_AA, SF_AT
37. FPT_STM.1 SF_AT
38. FPT_INC.1 SF_SP
39. FPT_RCV.1 SF_SP
40. FAU_ARP.1 SF_AT
Public
SDoT SDD
ST Security Target Lite
85 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
41. FAU_GEN.1 SF_AT
42. FAU_GEN.2 SF_AT
43. FAU_SAA.1 SF_AT
44. FAU_SAR.1 SF_AT
45. FAU_SAR.2 SF_AA, SF_AT
46. FAU_STG.2 SF_AT
47. FAU_STG.4 SF_AT
Table 27 TSS Rationale Overview
Public
SDoT SDD
ST Security Target Lite
86 Versions-Nr.: V 1.1
Versions-Datum: 06.11.2024
9 Bibliography
Criteria and methodology interpretation
720
[CC_Part1] Common Criteria for Information Technology Security Evaluation, Part 1:
721
Introduction and general model, Version 3.1, Revision 5, April 2017, CCMB-
722
2017-04-002
723
[CC_Part2] Common Criteria for Information Technology Security Evaluation, Part 2:
724
Security functional components, Version 3.1, Revision 5, April 2017,
725
CCMB-2017-04-002
726
[CC_Part3] Common Criteria for Information Technology Security Evaluation, Part 3:
727
Security assurance components, Version 3.1, Revision 5, April 2017,
728
CCMB-2017-04-003
729
[CEM] Common Criteria for Information Technology Security Evaluation,
730
Evaluation methodology, Version 3.1, Revision 5, April 2017, CCMB-2017-
731
04-004
732
[AIS_41] Application Notes and Interpretation of the Scheme (AIS), AIS 41, Version
733
2, 31.01.11, Certification body of the BSI in the context of the certification
734
scheme
735
[AIS_35] Application Notes and Interpretation of the Scheme (AIS), AIS 35, Version
736
2, 12.11.11, Öffentliche Fassung eines Security Target (ST-lite)
737
[MC_ST_LITE] Common Criteria Recognition Arrangement, Management Committee,
738
Policies and Procedures, ST sanitising for publication, Version 1.0, April
739
2006, CCDB-2006-04-004
740
Technical references
741
[Atos_ST] Security Target „CardOS V5.3 QES“, Atos IT Solutions and Services GmbH,
742
Version 1.0, Revision 1.61, 07/2014
743
[Atos_CC] Certification Report for the Target „CardOS V5.3 QES V1.0“ from Atos IT
744
Solutions and Services GmbH, Cert-ID: BSI-DSZ-CC-0921-2014,
745
Maintainance Report BSI-DSZ-CC-0921-2014-MA-0
746