Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 1 of 104
Copyright © THALES Norway AS
XOmail 22
Security Target
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 2 of 104
Copyright © THALES Norway AS
DOCUMENT CHANGE HISTORY
Revision Date Description
4-public 14.11.2022 Initial public version
– 4-public
Written by SE Team
CHTE
Checked by QA
Manager
TBO
Approved by PDA
ØYJ
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 3 of 104
Copyright © THALES Norway AS
Table of Contents
TABLE OF CONTENTS........................................................................................................ 3
LIST OF FIGURES................................................................................................................ 4
LIST OF TABLES ................................................................................................................. 4
1. SECURITY TARGET INTRODUCTION (ASE_INT) ....................................................... 6
1.1 SECURITY TARGET REFERENCE................................................................................. 6
1.2 TOE REFERENCE...................................................................................................... 6
1.3 REFERENCED DOCUMENTS........................................................................................ 6
1.4 TOE OVERVIEW ........................................................................................................ 7
1.5 TOE DESCRIPTION ................................................................................................... 9
2. CONFORMANCE CLAIMS (ASE_CCL) .......................................................................25
3. SECURITY PROBLEM DEFINITION (ASE_SPD).........................................................26
3.1 ASSETS...................................................................................................................26
3.2 THREAT AGENTS ......................................................................................................26
3.3 THREATS.................................................................................................................27
3.4 ORGANISATIONAL SECURITY POLICY..........................................................................31
3.5 ASSUMPTIONS .........................................................................................................35
4. EXTENDED COMPONENTS DEFINITION (ASE_ECD) ...............................................37
5. SECURITY OBJECTIVES (ASE_OBJ).........................................................................38
5.1 SECURITY OBJECTIVES FOR THE TOE .......................................................................38
5.2 IT SECURITY OBJECTIVES FOR THE TOE ENVIRONMENT .............................................39
5.3 NON-IT SECURITY OBJECTIVES FOR THE TOE ENVIRONMENT .....................................40
6. SECURITY REQUIREMENTS (ASE_REQ) ..................................................................41
6.1 TOE SECURITY REQUIREMENTS ................................................................................41
6.2 TOE SECURITY ASSURANCE REQUIREMENTS .............................................................55
7. TOE SUMMARY SPECIFICATION (ASE_TSS)............................................................57
7.1 TOE SECURITY FUNCTIONS ......................................................................................57
8. RATIONALE .................................................................................................................63
8.1 SECURITY OBJECTIVES RATIONALE............................................................................63
8.2 SECURITY REQUIREMENTS RATIONALE.......................................................................79
8.3 TOE SUMMARY SPECIFICATION RATIONALE................................................................90
8.4 PP RATIONALE.......................................................................................................100
9. NOTES........................................................................................................................101
9.1 NOTATION .............................................................................................................101
9.2 ABBREVIATION AND ACRONYMS...............................................................................101
9.3 TERMINOLOGY .......................................................................................................102
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 4 of 104
Copyright © THALES Norway AS
List of Figures
Figure 1-1 XOmail Server configurations, with a common security core.Error! Bookmark not defined.
Figure 1-2 XOmail in a Messaging as a Service configuration ............................................................. 10
Figure 1-3: XOmail Broadcaster and Afloat for Naval deployment ....................................................... 11
Figure 1-4 XOmail ACP 145 Interface overview.................................................................................... 13
Figure 1-5 Central Archive system context ........................................................................................... 15
Figure 1-6: MMHS Servers in a Partitioned Operation Mode system ................................................... 16
Figure 1-7: XOmail servers in different roles in an MLS environment................................................... 17
Figure 1-8 Datacentre deployment view with connected services ........................................................ 18
Figure 1-9 STANAG 4406 messaging................................................................................................... 18
Figure 1-10 XOmail Server network and protocol options .................................................................... 19
Figure 1-11: XOmail Server Reference Monitor.................................................................................... 22
List of Tables
Table 1-1: TOE Supported operating systems........................................................................................ 8
Table 1-2: Central Archive supported DBMSs ........................................................................................ 8
Table 1-3: XOmail Server interfaces ..................................................................................................... 21
Table 6-1: Auditable Events .................................................................................................................. 45
Table 6-2: EAL4 augmented with ALC_FLR.3 ...................................................................................... 56
Table 8-1: TOE threats coverage .......................................................................................................... 64
Table 8-2: TOE Environment threats coverage..................................................................................... 65
Table 8-3: Assumptions coverage......................................................................................................... 67
Table 8-4: Policies coverage ................................................................................................................. 68
Table 8-5: Security objectives satisfaction ............................................................................................ 81
Table 8-6: Functional requirements dependency check ....................................................................... 89
Table 8-7: Functional requirements satisfaction.................................................................................... 92
Table 9-1 Acronyms ............................................................................................................................ 102
Table 9-2 Terminology......................................................................................................................... 104
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 5 of 104
Copyright © THALES Norway AS
Foreword
This document is the Security Target for XOmail Server. The document describes the operating environment
and IT product requirements, as well as security functionality implemented in the IT product.
The document was prepared on behalf of
Forsvarsmateriell IKT-kapasiteter
Postboks 800 Postmottak,
2617 Lillehammer
Norway
By:
THALES Norway AS
Postboks 744 Sentrum
0106 Oslo
Norway
Telephone: (+47) 22 63 83 00
E-Mail: XOmail@thales.no
Internet: http://www.thales.no
Copyright notice:
The information contained in this document is proprietary to Thales Norway AS.
You are free to copy and redistribute the document as long as it is unmodified.
THALES Norway AS has made every attempt to ensure that the information in this document is
correct and complete. However, THALES Norway AS assumes no liability for errors, or for any
damage that may result from the use of this document or any product that it accompanies.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 6 of 104
Copyright © THALES Norway AS
1. SECURITY TARGET INTRODUCTION (ASE_INT)
1.1 SECURITY TARGET REFERENCE
Title: XOmail 22 Security Target
Version: See Change History, page 2
Date: See Change History, page 2
Document id: See footer.
1.2 TOE REFERENCE
TOE name: XOmail Server 22
TOE version: 22.2.0
Assurance level: EAL4 augmented with ALC_FLR.3
CC Identification: Version 3.1 Revision 5
1.3 REFERENCED DOCUMENTS
[1] 712 27734 AXAA EO XOmail Installation and Configuration Guide
[2] 739 20529 ABAA EO XOmail User’s Guide
[3] 739 20561 ABAA EO XOmail Administrator’s Guide
[4] ESD-TR-75-306 Bell & La Padula: Secure Computer Systems: Unified Exposition and
Multics Interpretation.
[5] FOR 2019-05-03 nr 560 Forskrift om virksomheters arbeid med forebyggende sikkerhet.
(Norwegian regulations supporting the National Security Act [10]).
[6] CCMB-2017-04-001 Common Criteria for Information Technology Security Evaluation,
April 2017, Version 3.1 revision 5, Part 1 (also known as part 1 of the
ISO/IEC 15408 Evaluation Criteria).
[7] CCMB-2017-04-002 Common Criteria for Information Technology Security Evaluation,
April 2017, Version 3.1 revision 5, Part 2 (also known as part 2 of the
ISO/IEC 15408 Evaluation Criteria).
[8] CCMB-2017-04-003 Common Criteria for Information Technology Security Evaluation,
April 2017, Version 3.1 revision 5, Part 3 (also known as part 3 of the
ISO/IEC 15408 Evaluation Criteria).
[9] C-M(2002)49 Security Within the North Atlantic Treaty Organisation
(NATO), 17. June 2002.
[10] LOV 2018-06-01 nr 24 Lov om nasjonal sikkerhet (Norwegian Security Act)
[11] STANAG 4406 Ed. 2 Military Message Handling System Edition 2, NATO C3 Board, 2005
[12] RFC 6477 Registration of Military Message Handling System (MMHS) Header Fields
for Use in Internet Mail, January 2012
[13] Open Group (X/Open) API to Electronic Mail (X.400), Issue 3, May 1996
[14] Open Group (X/Open) OSI-Abstract-Data Manipulation API (XOM), Issue 3, May 1996
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 7 of 104
Copyright © THALES Norway AS
[15] NIST FIPS PUB 180-4 Secure Hash Standard, NIST, August 2015
1.4 TOE OVERVIEW
XOmail is a family of turn-key software products tailored for formal military messaging, information handling
and transfer in modern C4ISR solutions.
The TOE is the XOmail Server, the main building block of the XOmail product family. The XOmail Server
provides secure message handling, transfer, storage, and administration functionality.
The TOE can be deployed in the product configurations below. Multiple configurations may be deployed to a
single instance of the TOE.
XOmail Enterprise
Dedicated to meet specific needs for military message handling in strategic and tactical networks at any
scale, from autonomous nodes to large-scale Messaging as a Service deployments.
XOmail Enterprise is available with a number of options:
- XOmail SMTP Interface
Provides the functionality of the standalone XOmail SMTP XD (shown below).
- XOmail ACP 127 Interface
Provides the functionality of the standalone XOmail
ACP 127 XD (shown below).
- XOmail ACP 145 Interface
Provides the functionality of the standalone
XOmail ACP 145 XD (shown below)
- XOmail Central Archive
Assured automatic storage of all messages.
XOmail Afloat
Functionality tailored for surface vessels and submarines.
XOmail Broadcaster
Broadcast, Ship-Shore and Maritime Rear Link through
STANAG 4406, STANAG 5066
and ACP 127.
XOmail SMTP XD
Provides interoperability with Battle Force E-mail and standard Internet Mail.
XOmail ACP 127 XD
Automatic gateway between ACP 127 and STANAG 4406.
XOmail ACP 145 XD
Implements NATO standard for connecting networks with different security policies and PKI implementations,
allowing communication between nations and between national systems and NATO. Unlike the other
components, the ACP 145 XD is deployed on a separate instance of the TOE.
XOmail Clients (TOE Environment)
Figure 1-1 XOmail product family
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 8 of 104
Copyright © THALES Norway AS
XOmail Admin and XOmail Web Admin clients (TOE Environment) are provided for local or remote
administration of the XOmail Server (TOE). The Admin Clients provide the management interfaces required
for configuring the XOmail Server.
The XOmail MS Client and XOmail Web Client (TOE Environment) provide thick client and web interfaces for
end users.
1.4.1 MAJOR SECURITY FEATURES OF THE TOE
The XOmail Server software (TOE) enforces controlled message and information flow according to military
requirements with integrated multi-level security and mandatory access control. The TOE provides priority
handling for messaging, ensuring flash message traffic is delivered with minimal delay even with heavy traffic
or congestion.
The TOE preserves message security through consistent interpretation of security labels across all
supported messaging protocols, and supports use of digital signatures to ensure message integrity.
The TOE ensures all users are authenticated, and provides user management functions such as automated
logout, lockout, and verification. The TOE provides fine grained access control for messaging operations and
administrative commands, with complete accountability of all operations.
1.4.2 REQUIRED NON-TOE HARDWARE, SOFTWARE AND FIRMWARE
The TOE runs on standard 64bit PC platforms, on physical or virtualized environments.
The TOE supports the following operating systems:
Application Operating systems
XOmail Server Windows Server 2016
Windows Server 2019
Windows Server 2022
Table 1-1: TOE Supported operating systems
The XOmail Central Archive requires an external DBMS. The following databases are supported:
PostgreSQL 15.0 (recommended)
PostgreSQL 14.5
Oracle Database 19
Table 1-2: Central Archive supported DBMSs
Refer to the manufacturer’s documentation for additional information.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 9 of 104
Copyright © THALES Norway AS
1.5 TOE DESCRIPTION
XOmail is leading in its ability to be deployed on both strategic as well as tactical low-bandwidth unreliable
networks, in army, naval and joint systems, ranging from the troop and vehicle level, up to naval vessels and
large scale “Messaging as a Service” installations in national and joint headquarters.
The XOmail product family has been developed in close cooperation with military customers in several
countries, and has been continuously updated through more than 30 years of operational history. XOmail
has been selected by several European NATO member countries for their nationwide messaging service, for
NATO missions and NATO systems.
The backbone of XOmail is the implementation of the widely accepted NATO STANAG 4406 messaging
standard, as well as seamless integration with legacy ACP 127 systems, tactical network protocols, and
Internet Mail (SMTP) based systems.
The XOmail Server provides backbone messaging infrastructure, gateways and message storage. The TOE
functionality can be extended through the use of APIs, which allow third-party applications access to the
messaging infrastructure.
The TOE is accessed by user and administration clients, which provide user interfaces for messaging and
day-to-day management. The clients are not part of the TOE.
1.5.1 THE XOMAIL COMPONENTS
XOmail Server is available in multiple configurations, each of which is deployable as components of the
XOmail product family. Each component contains a shared security core provided by the TOE. All
components except the ACP 145 Gateway may be configured in parallel on a TOE node.
1.5.1.1 Core Functionality
The TOE has the following main characteristics and functionality:
 Military messaging system built according to STANAG 4406 Ed. 1 and Ed. 2 military extensions.
 Multi-Level Security and Priority attributes embedded at every level of the system.
 Local and remote administration and supervision.
 ACP133 Ed. D Directory Service supporting military messaging. Integrates with an external master
Directory Service or acts as a standalone or intermediate Directory Service. Optimized tactical
directory shadowing protocol for low-bandwidth unreliable networks.
 Support for integration with a wide range of platform services: PKI, Antivirus, Monitoring and
Supervision and software management systems.
 Message integrity protection using S/MIME over STANAG 4406 Ed 2 and E-Mail networks.
Integration with third-party Public Key Infrastructures to support certificate validation, including
revocation lists and validation of certificate chains.
 Automated printing of messages.
 Tailored for high-availability requirements.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 10 of 104
Copyright © THALES Norway AS
1.5.1.2 XOmail Enterprise
This is the messaging component of the XOmail product family. It supports military messaging for strategic
and tactical systems, with required features for security, military workflow, priority handling, STANAG 4406
Ed. 1 and Ed. 2 communications and gateways to other systems and networks.
Depending on operational requirements, the XOmail Military Messaging System can be deployed as centrally
managed light-weight autonomous nodes across geographical locations, or as strategic large scale
Messaging as a Service. XOmail Enterprise scales from single user nodes to datacentre clusters serving up
to 100.000 users. Tailored management interfaces and integration with platform services simplify
management of the system.
Navy HQ
Navy HQ and gateways to
naval domain
Joint Headquarters
Army HQs and bases
Air Force HQs and airbases
Strategic network
MMHS user locations
XOmail Enterprise
Cluster installation
Figure 1-2 XOmail in a Messaging as a Service configuration
Messaging functions are tailored to the needs of large organisations. The system differentiates strictly
between official messages (to organisational departments and roles) and personal messages (to individual
users).
Additional specialized functions:
 Advanced rule based message distribution mechanisms.
 SIC handling.
 Customer extensible through industry standard Application Program Interfaces, allowing access to
the messaging services provided by the TOE.
 Basegram addressing
Basegram addressing is used to provide an alternative recipient for an addressee that is currently
unreachable or with limited bandwidth. A typical use of this function is to allow naval vessels to have
low priority traffic delivered to a shore-side mailbox until a high bandwidth channel is available.
 P_MUL gateway
The P_MUL protocol is designed for use in tactical limited bandwidth environments. The protocol is
defined in STANAG 4406 Annex E. See also Section 1.5.10.4.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 11 of 104
Copyright © THALES Norway AS
 DMP gateway
DMP is an extremely low overhead protocol for use in tactical communications. The protocol is
defined in STANAG 4406 Annex E. See also Section 1.5.10.3.
 MCCIS Gateway
Support for the MCCIS protocol.
 X.25 protocol support
The X.25 protocol is used to interface X.25-based networks or radio equipment.
1.5.1.3 XOmail Broadcaster
XOmail Broadcaster provides functions to support shore-based Maritime Radio centres. This includes
Broadcast transmission and Ship-Shore reception, broadcast monitoring, automatic Traffic List and Re-run
handling, as well as gateways to ACP 127 based circuits used for Maritime Rear Links (MRL) and/or national
Tape Relay networks (TARE). The Broadcaster includes a full STANAG 4406 server for communication with
national or NATO-wide networks, and is BRASS compliant, including Enhancement One (BRASS EO).
An overview of the XOmail Broadcaster is shown in Figure 1-3.
A single XOmail Broadcaster node may handle a number of Broadcasters and Ship-Shore channels. The
Broadcast Unit handles the transmission (broadcast) of messages to ships. The Ship-Shore Unit handles
incoming messages from ships.
Figure 1-3: XOmail Broadcaster and Afloat for Naval deployment
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 12 of 104
Copyright © THALES Norway AS
Broadcast Unit:
The system offers two filtering functions for reducing broadcast load:
 Screening
All messages are subject to automatic screening. Expired messages are discarded and suspected
duplicates are halted.
 Vetting
Messages may be stopped for manual review to determine the relevance in the current situation.
Other special Broadcast Unit functions include:
 Broadcast Schedules
Ships may maintain reduced radio watch. A broadcast schedule can be established to ensure that
messages are only sent during watch hours. Broadcast schedules can also be used for sharing a
broadcaster, e.g. by allowing certain types of traffic (such as NATO only) during certain periods of
the day.
 Automatic Re-runs
To ensure that all called stations will receive a message, transmission re-runs can be defined.
 Traffic List generation
Broadcast Units log all broadcasted messages in Traffic Lists. The ship side uses these Traffic Lists
to determine whether all broadcast messages are received or not.
Ship-Shore Unit:
A Ship-Shore Unit handles incoming messages from ships. In addition, a Ship-Shore Unit provides
functionality for automatic and manual aerial switching as well as reception quality assessment and control.
A number of Ship-Shore Units can be defined on one XOmail Maritime Gateway.
The ship uses Working Channels for sending messages to the Maritime Gateway. A channel link must be
established before a message can be sent. Channel establishment is either performed automatically using
CARB procedures, or manually by an operator. In addition, an Aerial Select Channel can be used for
directing/controlling the antenna used for receiving messages from ships.
1.5.1.4 XOmail Afloat
XOmail Afloat is a Military Message Handling System (MMHS) tailored for surface and sub-surface
(submarine) naval vessels. XOmail Afloat provides Broadcast reception, Ship-Shore transmission, Inter-Ship
traffic and re-Broadcast. XOmail Afloat integrates with existing ACP 127 and STANAG 4406 infrastructures.
XOmail Afloat increases overall combat effectiveness through automated message handling and integration
with command and control systems.
The Afloat Ship-Shore unit provides detailed control over message transmission and channel utilization on
ships.
 Ship channel handling
ACP 127 channel administration, including monitoring of ACP 127 channels for broadcasters,
cryptographic device support with communications keying and crypto synchronization. Automated
and manual control over message retransmissions.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 13 of 104
Copyright © THALES Norway AS
 Transmission Pool
Afloat messaging often requires strict control over communication means. The transmission pool
allows authorized operators detailed control over messages to be transmitted.
 CARB on ships
XOmail automates execution of CARB procedures on the ship side when transmitting ACP127
messages from ship to shore, thereby reducing the operator work load.
 Ship-to-ship communication
XOmail provides formal and free text ship-to-ship messaging over ACP 127 channels.
1.5.1.5 XOmail ACP 145 Interface
The NATO STANAG 4406 based ACP 145 Gateway connects networks with different security policies
nationally or in multilateral operations. The XOmail ACP 145 Interface provides nations with complete
flexibility in terms of national messaging implementation, by having national-specific gateway functions on
one side and ACP 145 specific functions on the other.
Figure 1-4 XOmail ACP 145 Interface overview
1.5.1.6 XOmail SMTP Interface
XOmail SMTP Interface offers seamless integration of COTS email solutions and allows integration with a
wide range of SMTP-based messaging applications and specialized systems that may use SMTP services.
The XOmail SMTP Interface provides interoperability with modern and legacy military messaging systems as
well as Microsoft Exchange and other email systems. The system also connects military SMTP-based
products such as Battle-Force Email.
The XOmail SMTP Gateway is a multi-purpose gateway, and provides configurability for use with a range of
scenarios. XOmail SMTP Gateway can be configured to carry STANAG 4406 protocol elements into military
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 14 of 104
Copyright © THALES Norway AS
headers according to RFC 6477, and supports First Line of Text “Classification:” labels. Hence, the gateway
can provide alternative routes for military messaging through an SMTP network. See also Section 1.5.10.
The SMTP Gateway also provides a limited IMAP4 server for basic person to person messaging using
civilian E-mail clients such as Microsoft Outlook.
1.5.1.7 XOmail ACP 127 Interface
XOmail ACP 127 Interface provides interoperability with legacy ACP 127 systems and allows the step-wise
deployment of a modern STANAG 4406 system. ACP 127 Interface is implemented according to ACP 127
NATO SUPP-3 (A and B), ACP 127(G) and STANAG 4406 Annex D, extended with automated functions that
greatly reduce the need for manual interactions.
The XOmail ACP 127 Interface is normally configured standalone, on a dedicated installation of XOmail
Server, but the ACP 127 Interface may also be enabled with other XOmail components on the same XOmail
Server instance.
Detailed features:
 Connects to networks such as NATO AIFS and teleprinters
 Supports use of multiple channels to a single destination to increase throughput.
 Logging of traffic into Channel List logs
 Automated procedures for important Abbreviated SVCs
 Automatic sectioning and de-sectioning of long messages.
 Syntax checking and Security Label conversions.
 Surveillance functions.
1.5.1.8 XOmail Central Archive
XOmail Central Archive provides functionality for storing all messages within a system, in one central
location. The archive provides long-term storage of messages and powerful mechanisms that allow
authorised users to search and retrieve archived messages. The typical use of the Central Archive is to
archive all messages that originate within the system, along with all messages received from external
systems via gateways. Optionally, filtering mechanisms can limit the number of messages to be archived.
Metadata for the archived messages are stored in an SQL database for improved search performance.
Oracle and PostgreSQL are currently supported. The TOE handles access control for search and retrieval.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 15 of 104
Copyright © THALES Norway AS
XOmail
Central
Archive
XOmail
Server
XOmail
Server
XOmail
Server
File system SQL Database
Store message attributes and
message events (SQL)
Search message attributes
(SQL)
Message and message events for archiving
Search requests and results (users)
Store/retrieve messages as files
Figure 1-5 Central Archive system context
1.5.2 THE XOMAIL CLIENTS
In addition to the TOE, XOmail provides the clients listed below. The clients are used to access the TOE.
 XOmail MS Client
End-user messaging client
 XOmailWEB
End-user messaging clients, web-based.
 XOmail Admin
Administrative interface
 XOmail Web Admin
Administrative interface for managing large-scale datacentre installations, web-based.
1.5.3 NON-TOE XOMAIL SERVER FUNCTIONALITY
The component below is also provided by the XOmail Server, but shall not be used in a certified
configuration. The function is contained in a package that must be explicitly enabled during installation.
 POP3 client access
XOmail provides experimental support for the POP3 protocol.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 16 of 104
Copyright © THALES Norway AS
Also note that the following client is part of the XOmail product family, but is not part of the TOE and only
indirectly interfaces the TOE:
 XOmail Sign & Label Add-In for Outlook
The Sign & Label Add-In for Outlook provides support for STANAG 4406 Ed 2 compatible security
labels and S/MIME digital signatures. The Add-In is intended for use in SMTP-based networks that
interface MMHS networks via an XOmail SMTP Gateway, and is not directly connected to the
XOmail Server.
1.5.4 TOE DEPLOYMENT IN A MULTI-LEVEL SECURITY CONFIGURATION
NATO Secret WAN
National Secret WAN
XOmail Server
or other STANAG 4406
compatible system
Gateway
Gateway XOmail Server
or other STANAG 4406
compatible system
NATO + National
Secret LAN
XOmail Client
XOmail Client
XOmailWEB
XOmailWEB
XOmail Admin Client
XOmail Web Admin Client
National Users
Clearance:
<Nation> SECRET
NATO SECRET
NATO Users
Clearance:
NATO SECRET
XOmail Servers
Figure 1-6: MMHS Servers in a Partitioned Operation Mode system
Figure 1-6 shows a high level overview of the Partitioned Operation Mode. In this scenario XOmail Server
mediates all information flow between the NATO and National security domains, and enforces separation of
information in the different security domains.
The XOmail Server may serve client logons from both the National Secret LAN and the NATO Secret LAN. In
addition it is able to communicate with the MMHS Servers (XOmail Server or other STANAG 4406
compatible system), located in the WANs. XOmail Server may also exchange messages with external
systems through gateways such as ACP 127.
In the
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 17 of 104
Copyright © THALES Norway AS
Figure 1-6 scenario, the firewall has been configured to allow connections to XOmail from both the National
Secret LAN and the NATO Secret LAN, and Administrators from the National Secret LAN. XOmail may be
configured to allow some users to connect only from the National Secret LAN, while others may connect from
both. Users will only be allowed to access information they have been explicitly authorized for. In this
scenario, users from the allied NATO nation will be unable to access National classified messages.
Figure 1-7 shows how XOmail may support information flow in a multi-level security environment. This
scenario shows the XOmail Server in two different roles, as security gateway (the server marked MLS), and
as individual MMHS Servers. An operational scenario would also require border protection measures with
firewalls and network monitoring.
The security gateway ensures that only messages labelled restricted or lower may pass between the two
networks. Messages marked secret, or higher, are blocked
- when sent from the secret network, and
- when sent from the restricted network.
The first rule preserves confidentiality, while the second rule ensures that an attacker cannot inject
incorrectly labelled secret messages into the secret LAN from the less trusted LAN. These rules are
configurable.
Messages may be marked with additional categories (caveats), such as national eyes only. A national
restricted LAN may exchange messages with a NATO restricted LAN, using the XOmail Server to ensure
that national eyes only messages do not propagate outside the national network. Security label mapping is
available by using the XOmail ACP 145 Interface.
National Secret
National Restricted
XOmail Server
(National Secret)
XOmail Server
(Multi-Level)
National
Restricted
National
Restricted
National
Secret
National
Secret
XOmail Server
(National Restricted)
Figure 1-7: XOmail servers in different roles in an MLS environment
XOmail also supports the use of the RELEASABLE TO caveat, allowing specific messages to be marked
releasable to additional security domains than the originating policy. Typical use is sharing of information to
coalition and mission partners, e.g. NATO CONFIDENTIAL REL TO SWE.
1.5.5 DATACENTRE CONFIGURATION (MESSAGING AS A SERVICE)
The XOmail Server may be deployed as a cluster in a datacentre configuration to provide MMHS services to
a large user base or to provide high-availability properties. The datacentre configuration provides operators
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 18 of 104
Copyright © THALES Norway AS
and administrators with a common interface for accessing and managing the entire cluster. In a datacentre
configuration the TOE would normally be installed on a set of virtual machines, integrating the capabilities of
both XOmail and the underlying virtualization platform to provide a high-availability solution, with automated
error recovery, integrated monitoring and efficient management for large installations.
XOmail Enterprise
cluster
ACP127
(Serial)
Legacy MMHS
(e.g. ACP 127)
XOmail
w/ACP 127 Interface
XOmailWEB
XOmail Client
Traffic Operators
Domain Controller
Directory
service
PKI + HSM
AV/malware analysis
XOmail Web Admin
XOmail Admin Client
System
Administrators
Figure 1-8 Datacentre deployment view with connected services
1.5.6 TOE EXTERNAL INTERFACES
The Military Messaging component of the XOmail Server implements a STANAG 4406 compliant MMHS
system, compatible with STANAG 4406 Ed1 and STANAG 4406 Ed2 systems.
XOmail Server
XOmail clients
STANAG 4406
compliant system
Message
submit
Message transfer
Figure 1-9 STANAG 4406 messaging
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 19 of 104
Copyright © THALES Norway AS
The TOE is highly adaptable, and may support a wide range of communication channels, ranging from
unreliable tactical HF networks, to gigabit Ethernet.
LAN
High speed LAN
XOmail Server
E.g. HF radio
Low bandwidth or unreliable
Networks (e.g. ACP 127,
DMP, P_Mul)
High latency networks
(e.g. P_Mul)
E.g. STANAG 4406
SMTP GW
Client specific protocols
XOmail Client XOmail Admin
Crypto
Equipment
Crypto setup/handling
E.g. Broadcaster
Figure 1-10 XOmail Server network and protocol options
It is assumed that the TOE Environment provides sufficient protection of the communication channels used
by the TOE. This may include physical protection or use of approved cryptographic equipment.
1.5.7 CLIENT INTERFACES
The XOmail Server requires authentication and authorization for access to its client interfaces.
It is possible to configure the server to limit Mail Client logons to a set of specific hosts, from a set of specific
subnets, or from any host.
The XOmail MS Client is considered a dumb client that:
 Is available for all personnel that have user accounts (given that the account has not been locked).
 Is limited to accessing only the information allowed by the server. The server applies Mandatory
Access Control and Discretionary Access Control to enforce confidentiality of information, based on
the active user’s security clearance and storage access. The client presents the security label that is
associated with the displayed information.
 Sends requests to the server in order to store, retrieve, delete or create data. The server verifies that
the operation is allowed for that user in his/her current environment.
The XOmail MS Client supports labelling of information upon presentation, but the label is always retrieved
from the Server, or from the user that creates the data.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 20 of 104
Copyright © THALES Norway AS
TOE end users may access the TOE using Web clients. The XOmail Web Client provides general formal
messaging functions, while tailored clients are also available. The web clients are thin clients that:
 Are available for all personnel that have user accounts on the TOE (unless the account has been
locked).
 Are limited to accessing only the information allowed by the server. The server applies Mandatory
Access Control and Discretionary Access Control to enforce confidentiality of information, based on
the active user’s security clearance and storage access. The client presents the security label that is
associated with the displayed information.
 Send requests to the server in order to store, retrieve, delete or create data. The server verifies that
the operation is allowed for that user in his/her current environment.
 Provide no local storage, except caching while in use.
The web clients supports labelling of information upon presentation, but the label is always retrieved from the
Server, or from the user that creates the data.
The XOmail Admin and XOmail Web Admin are thin clients that:
 Are available for personnel with the appropriate administrative rights (given that the user account
has not been locked). See 1.5.7.1 for details on how administrative rights are assigned.
 Presents only the XOmail configuration data that the server allows it to present. The server ensures
this by not sending data that the client is not allowed to present.
 Does not present message data.
 Hides commands the administrator is not authorized to use, based on role and command access
restrictions (ACLs).
 Sends requests to the server in order to store, retrieve, delete or create data. The server verifies that
the operation is allowed for that user in his/her current environment.
 Does not store classified data or configuration data locally.
To ensure information integrity and confidentiality, all traffic between the TOE and the clients must be
protected from tampering and monitoring. This can be solved using network encryption or physical
protection.
Messaging traffic (e.g. XOmail MS Client) should be separated from administrative traffic (XOmail Admin).
This can be solved through physical separation or encryption.
1.5.7.1 Administrator access control
There are four administrator roles in XOmail: Administrator, Network Administrator, Security Administrator
and Primary Security Administrator. Only administrators have access to the XOmail Admin Client and
XOmail Web Admin Client.
An administrator’s User Template defines the set of commands available to all administrators based on that
template. The command ACL grants and denies access to commands available in every command group,
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 21 of 104
Copyright © THALES Norway AS
e.g. it is possible to grant read only access the “Department Template” command group, while denying
access to New, Save and Delete operations.
The maximum command access that is possible to configure for any given User Template is determined from
the administrator role that is set for the User Template. E.g. it will only be possible to grant access to network
management tasks to Network Administrators and Security Administrators.
Only Security Administrators and the Primary Security Administrator are allowed to modify security
parameters, e.g. user clearance and command ACLs.
1.5.8 XOMAIL SERVER
Logical interface Description
MMHS Servers Message transfer
 Encode/decode according to protocol definitions (e.g. STANAG
4406, Internet Mail)
 Message integrity and authentication
ACP 127 channels Message transfer
 Encode/decode according to ACP 127 channel procedures
XOmail MS Client Messaging operations
XOmailWEB client interface Messaging operations
XOmail Admin Configuration, management and supervision
XOmail Web Admin interface Configuration, management and supervision
ACP 133 channels
(Address Directory)
Directory services
Third party LDAP clients View address directory
Third party Internet Mail
clients via SMTP+IMAP4
(e.g. Outlook)
Messaging operations
ICAP (Antivirus) Submit messages to an antivirus server for inspection.
Windows Event Log Audit export, e.g. for Microsoft SCOM
Application Programming
Interfaces (ch 1.5.9)
Message transfer, message operations, export from Central Archive
Table 1-3: XOmail Server interfaces
Table 1-3 shows the logical interfaces for information flow on the XOmail Server. Each session may use
multiple interfaces simultaneously. The figure shows that classified information and possibly other TOE
assets may be transported on all these interfaces. It should be noted that there is not a one-to-one
relationship between logical interfaces and actual XOmail Server interfaces. The logical interfaces shown in
the table are a result of assumed function and the expected use.
The TOE can be configured to trust the security attributes associated with the incoming information.
Otherwise, all such information will be classified with a configurable maximum value (system high).
The figure also shows important security functionality that is implemented in the logical interfaces, in addition
to the encoding that is most commonly used on the interfaces.
APIs are described in ch 1.5.9.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 22 of 104
Copyright © THALES Norway AS
1.5.8.1 XOmail Server security
Figure 1-11: XOmail Server Reference Monitor
The core security functions of the XOmail Server are realized in a reference monitor. The reference monitor
is tamperproof (as protected by OS mechanisms) and it is always invoked when subjects request access to
objects. A schematic overview of the reference monitor is shown in Figure 1-11.
All information conveyed between internal TOE components are labelled with a security label and a priority.
The security label is used for access control by the reference monitor, based on the Bell & LaPadula
multilevel security policy model [4]. The priority attribute ensures that higher priority messages are always
given precedence in queues or assigned reserved resources.
Other security mechanisms, as described in Section 7.1, are located in separate software processes. Each
security function may be included in several software processes if implemented as a library.
1.5.8.2 OS responsibilities
The TOE relies on authentication mechanisms provided by the Operating System. The responsibility of the
TOE is to ensure that authentication is performed before any other operation. The Operating System is
responsible for performing the actual authentication and to provide secure storage of the authentication
tokens.
The TOE relies on the Operating System to provide an API to the cryptographic functions and Public Key
Infrastructure required for S/MIME digital signatures. The TOE depends on the Windows Crypto API (CAPI)
standardised interface to third party PKI components:
 X.509 certificate lookup
 X.509 certificate chain validation
 Secure use of cryptographic tokens (private keys).
The TOE does not store cryptographic tokens for S/MIME messaging, but relies on accessing the tokens
through the Crypto API. The TOE Environment must ensure appropriate secure storage of cryptographic
tokens, e.g. in the CAPI database, on smart cards or HSMs.
Subjects Objects
Security Parameter
Database
Audit
Reference
Monitor (Policy)
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 23 of 104
Copyright © THALES Norway AS
1.5.9 API FRAMEWORK
XOmail provides a standard API defined by X/Open for accessing the messaging infrastructure [13-14], i.e.
API to Electronic Mail (MA-API).
Additionally, XOmail provides the XOmail Simplified API (XOsapi), based on MA-API, for a simplified, easy-
to-use interface to the send and the receive functionality of the XOmail Server.
On computers not running XOmail Server, the XOmail RemoteAccess is installed to provide a low level
communication stack which handles communication towards a remote XOmail Server.
The SMTP Gateway and the Web Client and Web Admin Client REST interfaces may also be used as API’s
for messaging and monitoring.
XOmail Central Archive supports export of messages in PDF format. This provides seamless export to
customer specific archives or communication journals. This is a local API, accessed using a C++ library
functions (DLL).
1.5.10 GATEWAYS
All interfaces used to implement gateway functions are optional and are selected during installation of the
XOmail Server. Multiple gateways may be enabled at a single instance of XOmail if required.
1.5.10.1 SMTP Interface
The SMTP gateway connects MMHS and tactical networks with Battle Force E-mail and commercial Internet
Email systems.
The SMTP Gateway can be connected to commercial off the shelf SMTP-based email systems, as well as
Battle-Force Email products implementing the SMTP protocol.
The SMTP Gateway also supports the SMTP based MIP Message Exchange Mechanism. MIP messages
are received through an SMTP server which accepts messages on the Internet Mail Format with MIP
extensions.
To support MMHS functionality inside the SMTP domain, the SMTP gateway implements MMHS attributes
as Internet Message Format extensions according to RFC 6477 [12]. The Internet Message Format and
SMTP protocol does not have native support for message security labels and other MMHS attributes. No
automated handling based on these attributes can be expected, but the information can still be transported
across SMTP networks.
MMHS attributes may be exported as a human readable text attachment inside the Internet Message
domain, to allow users of standard email clients like Microsoft Outlook and Mozilla Thunderbird the ability to
easily access these attributes.
1.5.10.2 ACP 127 Interface
The ACP 127 Gateway is described in 1.5.1.7.
1.5.10.3 DMP Interface
The DMP gateway allows messages to be sent and received through the DMP protocol defined in STANAG
4406 Annex E. DMP is an ultra-low overhead messaging protocol for use in unreliable, limited and high-
latency channels such as HF radio.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 24 of 104
Copyright © THALES Norway AS
To save bandwidth only critical messaging attributes are transported. Other attributes are either
reconstructed on the receiving side or discarded.
The DMP interface can be enabled for XOmail Enterprise, XOmail Broadcaster and XOmail Afloat.
1.5.10.4 P_MUL Interface
The P_MUL protocol (ACP 142) provides a connection-less and bandwidth-optimized channel for
transporting STANAG 4406 messages. It is designed for unreliable networks (e.g. radio links) with reduced
bandwidth and high latency. P_MUL has a higher overhead than the DMP protocol, but supports all of the
STANAG 4406 attributes.
P_MUL is defined in STANAG 4406 Annex E.
The P_MUL interface can be enabled for XOmail Enterprise, XOmail Broadcaster and XOmail Afloat.S/MIME
Security Services
The XOmail Server provides the ability to ensure the integrity of MMHS messages transmitted between
servers through use of S/MIME digital signatures. These signatures are supported for STANAG 4406 Ed2
messages and messages over the SMTP Gateway, and may be generated by the authorizing user (personal
signatures) or on behalf of the organization by a server or gateway node (gateway or department signature).
The TOE does not store or manage cryptographic keys, and does not generate message signatures. The
XOmail Server relies on the Cryptographic API (CAPI) in Windows to provide cryptographic functions, X.509
certificate validation, certificate path validation and revocation checks. Private Keys may reside on a
hardware token (smart card), an HSM or in a software based storage.
The XOmail Server implements cryptographic hash functions to generate the message digests used for
S/MIME operations. The TOE Environment operates on message digests rather than the actual message
payloads. This reduces the risk for disclosure or modification of classified information.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 25 of 104
Copyright © THALES Norway AS
2. CONFORMANCE CLAIMS (ASE_CCL)
The Security Target and TOE conforms to the Common Criteria for Information Technology Security
Evaluation standard, version 3.1 revision 5, parts 2 and 3 [6-8].
The Security Target does not claim conformance to a Protection Profile.
Part 2 conformant, with the Security Functional Requirements included below. The Security Target does not
declare extended security requirements.
Part 3 conformant to EAL 4 augmented with ALC_FLR.3.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 26 of 104
Copyright © THALES Norway AS
3. SECURITY PROBLEM DEFINITION (ASE_SPD)
In the following sub-chapters the TOE security problem definition will be described.
First, a list of assets and threat agents are described. These lists support identification of the threats to be
countered by the TOE. The assets in the system are objects for which the TOE shall ensure confidentiality,
integrity and availability, whereas threat agents are the subjects that may perform actions later identified as
threats.
Based on the operating environment, the list of threat agents and the TOE itself (including assets), a list of
threats can be identified. The identified threats are listed in 3.3. All threats are listed with a description of the
threat, the involved threat agents, the affected assets and a description of unwanted outcome from a
possible attack. In 3.4, the organisational security policy with which the TOE must comply is described.
Last, a list of assumptions regarding the TOE use and its operating environment is given. It is important to
note that the operating environment is essential for ensuring parts of the TOE security functionality. This is
further described in each assumption.
3.1 ASSETS
AS.AUDIT The log data gathered by the TOE and OS that are part of the audit trail.
AS.AUTH_DATA Authentication credentials supplied from a subject to the TOE.
AS.CLASSIFIED_INFO Information classified according to a specific security policy. The information is
assigned a hierarchical classification level (HCL) and optionally a set of non-
hierarchical categories (NHC).
AS.CONFIG_EXT TOE configuration data that is stored within the control of the OS. This includes
configuration files for which the OS controls the access.
AS.CONFIG_SS TOE configuration data that is stored in the SS, except that covered by
AS.SEC_CFG.
AS.PROPER_OP Proper operation of the TOE is considered an asset as it is important for
authorized users to get access to the system as needed.
AS.SEC_CFG TOE security configuration. This includes
- clearance settings for users and departments,
- clearance settings and other security settings for external channels used by the
TOE,
- labelling of structures within SS,
- ACLs for structures within SS,
3.2 THREAT AGENTS
TA.ADM Authenticated authorized administrators of XOmail. These threat agents may
unintentionally perform unauthorized actions. Administrators that have not
authenticated, or perform actions from applications other than the Admin Client are
considered TA.INTERNAL.
TA.DEVELOPER The TOE developer may unintentionally compromise the TOE security.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 27 of 104
Copyright © THALES Norway AS
TA.EXTERNAL Personnel with no authorized access to the TOE environment. These threat agents
may attempt to gain access to classified information and may have “unlimited”
resources supporting them.
TA.INTERNAL Personnel with authorized access to the TOE environment. These threat agents
may try to perform unauthorized actions. Furthermore, such threat agents may be
specially trained to perform the unauthorized actions and may have “unlimited”
resources supporting them.
TA.SYSTEM_ERROR Hardware or software failures or transmission errors may cause information to be
modified, injected or deleted by accident.
TA.USER Authenticated authorized users of the TOE. These threat agents may intentionally
or unintentionally perform unauthorized actions. Users that have not authenticated,
or perform actions from applications other than the XOmail MS Client are
considered TA.INTERNAL.
3.3 THREATS
The threats are divided into two groups based on who meets them. The first group, named TT, is comprised
by the threats met by the TOE itself. The second group, named TE, is comprised by the threats met by the
TOE environment.
3.3.1 THREATS MET BY THE TOE
TT.ADM_ERROR Improper administration results in a security policy violation.
Threat agents TA.ADM.
Asset AS.CLASSIFIED_INFO, AS.CONFIG_SS, AS.SEC_CFG.
Unwanted outcome Unauthorized personnel get access to, change, or delete classified information
because of unintentional improper administration of the TOE.
TT.AUDIT_FAILURE An attacker may cause audit records to be lost or modified. Attackers may
also cause audit overflow, so that important audit records seemingly
disappear.
Threat agents TA.INTERNAL, TA.EXTERNAL
Asset AS.AUDIT
Unwanted outcome The TOE is unable to store audit data or provide necessary audit data to the
IT environment, or the audit becomes useless because of the inability to
separate important audit records from other records. The latter is the case if
the audit is overflowed.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 28 of 104
Copyright © THALES Norway AS
TT.COM_INTEGRITY The integrity of transmitted information may be compromised due to deliberate
or accidental insertion or modification. New information may be inserted onto
the network, or existing traffic modified in transit. An attacker may modify the
security label, priority, recipients, originators or other attributes of the message
and its data.
Threat agents TA.INTERNAL, TA.EXTERNAL, TA.SYSTEM_ERROR
Asset AS.CLASSIFIED_INFO
Unwanted outcome Invalid or forged information is mistakenly trusted. Classified information is
modified or new information is generated.
TT.DOS An attacker may cause system resource exhaustion, resulting in delayed
message handling or the inability of authorized users to access system
resources.
Valid message traffic may also cause denial of service conditions when high
traffic conditions cause system resources to be exhausted.
Threat agents TA.USER, TA.INTERNAL, TA.EXTERNAL
Asset AS.PROPER_OP
Unwanted outcome Authorized users are prevented from using the system or system performance
is degraded. High priority message traffic is queued.
TT.FAULTS The TOE crashes or deadlocks due to software or hardware errors.
Threat agents TA.DEVELOPER, TA.SYSTEM_ERROR
Asset AS.PROPER_OP
Unwanted outcome Authorized users are prevented from accessing the TOE.
TT.MASQUERADE An attacker tries to masquerade as a trusted entity in order to by mistake be
trusted with classified information.
Threat agents TA.INTERNAL, TA.EXTERNAL
Asset AS.CLASSIFIED_INFO, AS.CONFIG_SS, AS.SEC_CFG
Unwanted outcome Classified information is sent/made available to an entity that is not authorized
for the data.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 29 of 104
Copyright © THALES Norway AS
TT.MONITORING An attacker monitors activities and actions performed on classified
information. Such activities and actions include authentication and creating,
viewing, modifying and deleting classified information. The monitoring
activities can be performed at multiple levels, like screen monitoring or
network monitoring.
Threat agents TA.INTERNAL, TA.EXTERNAL
Asset AS.CLASSIFIED_INFO, AS.AUTH_DATA
Unwanted outcome Based on the monitoring activities, attackers can make assumptions of the
type of information sent, and possibly even the content of the information sent.
Statistical methods can be used to make such assumptions.
Also determining normal traffic load, and possible divergence from this can
give attackers valuable information. Possibly, the attacker can draw
conclusions that would be considered classified information based on traffical
patterns.
TT.REPLAY A malicious process or user gains access by replaying authentication data.
Threat agents TA.INTERNAL, TA.EXTERNAL
Asset AS.CLASSIFIED_INFO, AS.CONFIG_SS, AS.SEC_CFG
Unwanted outcome Unauthorized personnel get access to classified information by replaying the
authentication data provided by an authorized user or administrator.
TT.UNATTENDED A malicious user may gain unauthorized access to an unattended session.
Threat agents TA.ADM, TA.USER and TA.INTERNAL
Asset AS.CLASSIFIED_INFO, AS.CONFIG_SS, AS.SEC_CFG
Unwanted outcome Unauthorized personnel get access to the specified assets.
TT.UNAUTH_ACCESS Unauthorized access to identified assets may occur. Methods of attack
covered by this threat are brute force attacks, session hijacking, authentication
data cracking, privilege escalation and social engineering.
Threat agents TA.ADM, TA.USER, TA.INTERNAL and TA.EXTERNAL
Asset AS.CLASSIFIED_INFO, AS.CONFIG_SS, AS.SEC_CFG
Unwanted outcome Unauthorized personnel get access to classified information.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 30 of 104
Copyright © THALES Norway AS
3.3.2 THREATS MET BY THE TOE ENVIRONMENT
TE.AUDIT_FAILURE An attacker may cause audit records to be lost or modified.
Threat agents TA.INTERNAL, TA.EXTERNAL
Asset AS.AUDIT
Unwanted outcome Audit records are prevented from being recorded, or an attacker is able to
alter the information before it is placed in the audit trail.
TE.DELIVERY An attacker may try to replace parts (or the complete) TOE with a malicious
version.
Threat agents TA.INTERNAL, TA.EXTERNAL.
Asset AS.AUDIT, AS.CLASSIFIED_INFO, AS.CONFIG_EXT, AS.CONFIG_SS,
AS.PROPER_OP, AS.SEC_CFG
Unwanted outcome Unauthorized personnel get unauthorized access to classified information
because a compromised version of the TOE is used to maintain the assets.
TE.DOS An attacker block authorized users from system resources via a resource
exhaustion denial of service attack.
Threat agents TA.ADM, TA.USER, TA.INTERNAL, TA.EXTERNAL.
Asset AS.PROPER_OP.
Unwanted outcome Authorized users do not get access to necessary information that they have
clearance for.
TE.IMPROPER_INST The TOE is installed and/or configured in a manner that undermines security.
Threat agents TA.ADM, TA.USER, TA.INTERNAL, TA.EXTERNAL.
Asset AS.CLASSIFIED_INFO, AS.CONFIG_EXT, AS.CONFIG_SS
Unwanted outcome The TOE is installed in a manner that eases the process of gaining
unauthorized access to classified information.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 31 of 104
Copyright © THALES Norway AS
TE.POOR_DESIGN Unintentional or intentional errors in the design of the TOE may exist. Such
design flaws includes: inability to adequately separate information based on
SP, HCL or NHC and inability to associate correct security attributes with the
users.
Threat agents TA.DEVELOPER
Asset AS.AUDIT, AS.AUTH_DATA, AS.CONFIG_EXT, AS.CONFIG_SS,
AS.CLASSIFIED_INFO, AS.SEC_CFG.
Unwanted outcome The developer has failed in designing the TOE in a secure manner thereby
undermining its ability to protect assets against attacks.
TE.POOR_IMPL The developer has failed in implementing the TOE according to the design or
security flaws are present in the TOE.
Threat agents TA.DEVELOPER
Asset AS.AUDIT, AS.AUTH_DATA, AS.CONFIG_EXT, AS.CONFIG_SS,
AS.CLASSIFIED_INFO, AS.SEC_CFG.
Unwanted outcome Attackers get access to classified information, audit data or configuration data.
Attackers may conceal unauthorized access and other attacks.
TE.UNATTENDED A malicious user may gain unauthorized access to an unattended session.
Threat agents TA.ADM, TA.USER and TA.INTERNAL
Asset AS.AUDIT, AS.CLASSIFIED_INFO, AS.CONFIG_EXT, AS.CONFIG_SS,
AS.SEC_CFG.
Unwanted outcome Unauthorized personnel get access to the specified assets.
3.4 ORGANISATIONAL SECURITY POLICY
The TOE is compliant with the applicable parts of:
Norwegian security policy Norwegian Security Act [10] with supplementary Regulations [5].
NATO security policy C-M(2002)49 Security Within the North Atlantic Treaty Organisation
(NATO) [9]
The following is a summary of security policy statements from the Norwegian security policy and NATO
security policy which are related to the TOE and/or TOE environment.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 32 of 104
Copyright © THALES Norway AS
P.ACCOUNTABILITY The objective of the policy for accounting is to provide sufficient
information to be able to investigate a deliberate or accidental disclosure,
loss or modification of classified information and to support determination
of implications of a security breach.
Norwegian security
policy
Norwegian Security Act [10]: §6-2, §6-4,
Norwegian Information Security Regulations [5]: §49.
NATO security
policy
NATO security policy [9]:
 Enclosure B: §16
 Enclosure E: §§14-16, §§17-23
 Enclosure F: §11, §12.i
P.CLASSIFICATION The objective of the policy for classification of information is to determine
who is responsible for security classification of information, which security
classifications to be used, handling of re-classification, and time-limitations
of classifications.
Norwegian security
policy
Norwegian Security Act [10]: §5-1, §5-2, §5-3
Norwegian Information Security Regulations [5]: §28
NATO security
policy
NATO security policy [9]:
 Enclosure B: §§16-19
 Enclosure E: §3, §5
P.CLEAR Under exceptional operational circumstances, classified information may
be transmitted in clear text provided each occasion is properly authorised.
NATO security
policy
NATO security policy [9]:
 Enclosure F: §21
P.DAC A discretionary access control policy based on identity and need-to-know
of the user, process and/or groups to which they belong, shall be enforced.
Norwegian security
policy
Norwegian Information Security Regulations [5]: §15, §49
NATO security
policy
NATO security policy [9]:
 Enclosure B: §9.b, §11, §16, §20
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 33 of 104
Copyright © THALES Norway AS
 Enclosure C
 Enclosure F : §12.a, §12.b
P.INTEGRITY Classified information shall be protected against alteration and introduction
of false information.
Norwegian security
policy
Norwegian Information Security Regulations [5]: §49
NATO security
policy
NATO security policy [9]:
 Enclosure B: §2
 Enclosure F: §§3-4, §12.c, §12.d
P.INTERFACE_CONTROL Different information systems can be connected on the following conditions:
1. It shall only be used services and protocols, and administration of these,
which are necessary to fulfil the functional requirements of the system.
2. Each of the connected information systems shall have a protection
against other information systems, and the security in each of the
systems shall be based on mechanisms in that system.
3. Security measures shall be implemented on different levels in the
system, to avoid that the protection is based on only one component.
4. Access according to need-to-know shall be implemented mutually
between the connected systems.
Norwegian security
policy
Norwegian Information Security Regulations [5]: §55
NATO security
policy
NATO security policy [9]:
 Enclosure F: §12.f
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 34 of 104
Copyright © THALES Norway AS
P.MAC A mandatory access control policy based on hierarchical classification
levels and non-hierarchical categories shall be enforced. Information shall
not be allowed to flow from a higher security level to a lower security level
or between non-comparable security levels.
All individuals, civilian and military, who require access to, or whose duties
or functions may afford access to information classified CONFIDENTIAL /
KONFIDENSIELT or above, shall be appropriately cleared and briefed
before such access is authorised.
Norwegian security
policy
Norwegian Security Act [10]: §5-4
Norwegian Information Security Regulations [5]: §15, §34, §49
NATO security
policy
NATO security policy [9]:
 Enclosure A: Article 3
 Enclosure B : §9.b, §11, §12
 Enclosure C.
 Enclosure F: §7
P.MARKING The objective of the policy for marking of classified information is to
determine who is responsible for the marking, and details on how the
marking shall be done.
Norwegian security
policy
Norwegian Security Act [10]: §§5-1 – 5-3
Norwegian Information Security Regulations [5]: §28
NATO security
policy
NATO security policy [9]:
 Enclosure B: §19
 Enclosure E: §3, §7, §§10-12, §13
P.PROTECTION Classified information, stored or transmitted, shall be protected against
loss of confidentiality, integrity or availability. A balanced set of security
measures (physical, personnel, security of information and INFOSEC)
shall be implemented.
Protective measures and procedures to prevent, detect, and recover from
the loss or compromise of information shall be enforced.
Norwegian security
policy
Norwegian Information Security Regulations [5]: §22, §27, §34, §49
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 35 of 104
Copyright © THALES Norway AS
NATO security
policy
NATO security policy [9]:
 Enclosure B: §2, §16, §22
 Enclosure D.
 Enclosure E: §§1-2, §5
 Enclosure F : §§3-4, §8, §12.f, §12.h, §16-20
3.5 ASSUMPTIONS
The following assumptions must be ensured by the TOE environment.
3.5.1 PHYSICAL ASPECTS OF THE OPERATIONAL ENVIRONMENT
A.PHYSICAL The hardware on which XOmail runs is protected from unauthorized physical
modification.
A.PHYSICAL_LOC The hardware on which XOmail runs is located where only authorized personnel
have access.
3.5.2 PERSONNEL ASPECTS OF THE OPERATIONAL ENVIRONMENT
A.ADM_TRAINING All administrators know how to administrate the TOE in a secure manner.
Administration of the TOE in a secure manner means that each administrator must
know all consequences of all administrative tasks that are performed. Furthermore,
each administrator knows all his/her responsibilities with regards to TOE
administration. Administrator training shall be based on XOmail Administrator’s
Guide [3].
A.AUDIT_REVIEW Administrator personnel review audit logs on a regular basis.
A.CONFIDENCE Administrators or developers will not intentionally compromise the TOE security.
A.INVALIDATE Proper disposal of authentication data and associated privileges is performed after
access is removed (job termination, change in responsibility). Proper disposal
means that the authentication data cannot be used to authenticate towards any
part of the TOE.
A.NOTIFY Administrators and users notify the proper authority of any security issues that
impact their systems. This will minimize the potential for loss or compromise of
data.
A.USR_TRAINING All users know how to use the TOE in a secure manner. To use the TOE in a
secure manner each user must know the consequences of each available
operation. It is also assumed that the user training ensures that the user always
labels information correctly. User training shall be based on XOmail User’s Guide
[2].
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 36 of 104
Copyright © THALES Norway AS
A.TIME_SOURCE The Operating System (TOE Environment) provides a reliable time source for use
by the TOE.
3.5.3 ASSUMPTIONS FOR THE IT-ENVIRONMENT
A.ARCHIVE_DB The TOE Environment ensures the database used for the Central Archive is
configured as required by the TOE guidance documentation, and protected
appropriately for the sensitivity level of the stored information.
A.NETWORK The network connections used between separate parts of the TOE and for external
communication are protected from unauthorized disclosure and modification.
A.OS The TOE runs on an operating system evaluated at an appropriate level for the
organizational policies of the TOE Environment. The OS protects the TOE from
unauthorized modifications and provide vital security mechanisms like auditing and
authentication.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 37 of 104
Copyright © THALES Norway AS
4. EXTENDED COMPONENTS DEFINITION (ASE_ECD)
No extended components are defined.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 38 of 104
Copyright © THALES Norway AS
5. SECURITY OBJECTIVES (ASE_OBJ)
5.1 SECURITY OBJECTIVES FOR THE TOE
O.ACCESS_HIST The TOE maintains information related to previous attempts for a user to establish
a session. This information is displayable to authorized administrators.
O.AUDIT The TOE uses its internal secure database (SS), as well as OS audit mechanisms
to record security related information. When OS audit mechanisms are used, the
TOE provides the OS with all necessary information, including the identity of the
user that caused the event.
The audit trail shall contain information that is sufficient to reconstruct sequences
of events, i.e. the event shall include the event time, the event type, who was
responsible for the event, and the outcome of the event.
O.AUTO_LOGOUT The TOE provides an automatic logout mechanism for the XOmail MS Client. The
mechanism terminates client sessions after a configurable period of inactivity.
O.CMD_ACL The TOE provides means for restricting access to administrative commands for
each user or group of users. This can be used to restrict the administrative right
given to the role that the users belong to.
O.CMD_LOG The TOE provides means for recording administrative commands.
O.DAC The TOE ensures Discretionary Access Control by controlling access to resources
based on the identity of users and groups of users.
O.FLASH The TOE reserves resources to ensure delivery of STANAG 4406 FLASH
messages within prescribed time limits.
O.ID_AUTH A user is identified and authenticated before given access to classified information.
Authentication mechanisms include verification of the provided username and
password, or use of single sign-on mechanisms supported by the OS, such as
Kerberos.
O.LABELLING The TOE ensures that information is labelled with the correct human-readable
label when exported out of TSC.
O.LOCK The TOE provides a locking mechanism that makes it possible to prevent users
from logging on, even if they have a valid account. The locking mechanism works
on accounts, and can be activated both manually and automatically. Automatic
locking is activated when the user has provided a configurable number of invalid
authentication tokens.
O.MANAGE The TOE allows administrators to effectively, accurately and securely manage the
TOE and its security functions.
O.MAC The TOE ensures Mandatory Access Control by controlling access to resources
based on security clearance of users and resources.
O.MAC_INTEGRITY The TOE allows authorized security administrators to specify the security
clearance of users and resources.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 39 of 104
Copyright © THALES Norway AS
O.MESSAGING The TOE provides secure messaging functions. This implies that messages with
incorrect security marks will be rejected, while correctly formatted messages are
accepted. The TOE will furthermore be able to convert security marks to and from
all supported security mark representations.
O.MSG_INTEGRITY The TOE provides means for ensuring the integrity of STANAG 4406 Ed 2
messages sent between the TOE and other STANAG 4406 Ed 2 compliant MMHS
systems.
The TOE provides means for ensuring the integrity of Internet Mail (SMTP)
messages sent between the TOE and other compliant Internet Mail systems.
O.RECOVER The TOE will ensure preservation of a secure state in the event of a secure
component failure. Upon restart after an abnormal termination, the state may not
be a secure state, and the TOE shall use the current state to recover to a secure
state.
O.REUSE The TOE ensures secure reuse of resources. Secure reuse implies that it is not
possible to retrieve information stored during a previous use of the resource by
other subjects or by the same subject at a different security label.
O.ROLE_MNG When template “Permit” flag is set, only administrators with the same, or a more
privileged level can associate users with that template.
However, for templates where the Permit flag is not set, only Security
Administrators can associate other users with that template, thereby prohibiting
use of that template for non-“Security Administrators”.
O.ROLES The TOE assigns each user to a specific role. The TOE will define roles named
Normal, Administrator, Network Administrator, Security Administrator and Primary
Security Adminstrator. The role Normal has no administrative rights, while the role
Administrator and Network Administrator have administrative rights except security
settings. The roles Security Administrator and Primary Security Adminstrator have
all administrative rights. For all roles it is possible to limit the privileges, except for
the user assigned Primary Security Adminstrator role which will always have all
privileges. Furthermore, all defined users are associated with one of the defined
roles above.
O.SCHEDULING The TOE queues and processes information according to its associated priority.
O.SELF_TEST The TOE database performs a self-test during start-up. The system will not be
operable before the database consistency check passes.
5.2 IT SECURITY OBJECTIVES FOR THE TOE ENVIRONMENT
OE.ACCOUNTABLE Those responsible for the TOE will ensure that the product is configured such that
only the group of users for which the system was accredited may access the
system, and furthermore that each individual user is assigned a unique user
identification.
OE.AUDIT The OS will perform auditing as specified in GPOSPP and as required by
organizational policies. The audit shall contain information that is sufficient to
reconstruct sequences of events, i.e. the event shall include the event time, the
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 40 of 104
Copyright © THALES Norway AS
event type, who was responsible for the event, and the outcome of the event.
The OS is able to receive audit events from XOmail through its defined logging
and management interfaces. Audit events from XOmail may be considered
classified information. The operating system will protect the audit data according to
the relevant organizational policies.
OE.ID_AUTH A user is identified and authenticated before given access to the OS that the TOE
runs on. The platform provides support for single sign-on authentication if required
by the TOE.
OE.NETWORK Those responsible for the TOE will ensure that networks that are used for
communication between separate parts of the TOE and for external
communication are protected. The protection is implemented by means of data
encryption or physical protection.
OE.PLATFORM Those responsible for the TOE will ensure that the Operating System and third
party applications used with the TOE are securely installed and managed. In
particular, this includes the database server required by Central Archive, PKI
services, third party applications accessing the TOE API, and network
management services (e.g. MS SCOM).
OE.PKI The TOE environment will provide mechanisms for management and protection of
cryptographic keys, signing and verifying digests, as well as certificate distribution
and validation.
OE.TRAF_SEPARATION The TOE environment will ensure that TOE administrative network traffic can be
separated from other TOE network traffic.
OE.TIME_SOURCE The Operating System provides a reliable time source for use by the TOE.
5.3 NON-IT SECURITY OBJECTIVES FOR THE TOE ENVIRONMENT
NOE.ADM_TRUST Those responsible for the TOE will ensure that administrators of the system are
trustworthy.
NOE.INSTALL Those responsible for the TOE will ensure that the TOE is installed, managed and
operated according to the TOE guidance documentation. This requires users and
administrators to be properly trained.
NOE.PHYSICAL Those responsible for the TOE will ensure that security relevant components of the
TOE are protected from physical attack that might compromise the IT-security.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 41 of 104
Copyright © THALES Norway AS
6. SECURITY REQUIREMENTS (ASE_REQ)
The IT security requirements are standard CC requirements, with minor adaptations. Any deviations from the
CC standard requirements have been marked with blue and italic text.
6.1 TOE SECURITY REQUIREMENTS
6.1.1 TOE SECURITY FUNCTIONAL REQUIREMENTS
The following subchapters present the security functional requirements for the TOE.
6.1.1.1 Class FAU: Security audit
FAU_ARP.1
Security alarms.
FAU_ARP.1.1
The TSF shall take the following actions upon detection of a potential security violation:
a) Warm start on selected events
b) Cold start on selected events
FAU_GEN.1
Audit data generation.
FAU_GEN.1.1
The TOE shall be able to generate audit records of the following auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the basic level of audit, as listed in Table 6-1.
c) Message operations on the offline journal are not audited.
FAU_GEN.1.2
The TOE shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or failure)
of the event;
b) For each audit event type, based on the auditable event definitions of the functional components
included in the ST, message identifier for selected audit event types.
FAU_GEN.2
User identity association
FAU_GEN.2.1
The TOE shall be able to associate each auditable event with the identity of the user that caused the
event.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 42 of 104
Copyright © THALES Norway AS
TOE Requirement Event Note
FAU_ARP.1 Actions taken due to imminent security
violations
FAU_GEN.1 N/A
FAU_GEN.2 N/A
FAU_SAA.1 An alarm is raised when alarm events for a
given alarm type occurs more than once
within the given period.
FAU_SAR.1 Reading of information from the audit
records.
FAU_SAR.2 Unsuccessful attempts to read information
from the audit records.
FAU_STG.1 N/A
FAU_STG.3 An alarm is raised when the available disk
space falls below a given limit.
FAU_STG.4 N/A When the disk is full, it is
not possible to store
auditable events.
FDP_ACC.2 N/A
FDP_ACF.1 All requests to perform an operation on an
object covered by the SFP.
FDP_ETC.2 All attempts to export information.
FDP_IFC.2 N/A
FDP_IFF.2 All decisions on requests for information flow.
FDP_ITC.2 All attempts to import user data, including any
security attributes.
FDP_RIP.2 N/A
FDP_UIT.1 The identity of any user or subject using the
data exchange mechanisms.
The identity of any user or subject attempting
to use the user data exchange mechanisms,
but who are unauthorised to do so.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 43 of 104
Copyright © THALES Norway AS
TOE Requirement Event Note
A reference to the names or other indexing
information useful in identifying the user data
that was transmitted or received. This could
include security attributes associated with the
user data.
FIA_AFL.1 The reaching of the threshold for the
unsuccessful authentication attempts and the
actions (e.g. disabling of a user) taken and
the subsequent, if appropriate, restoration to
the normal state (e.g. re-enabling of a user).
FIA_ATD.1 N/A
FIA_UAU.2 All use of the authentication mechanism.
FIA_UAU.5 The result of each activated mechanism
together with the final decision.
FIA_UAU.6 All reauthentication attempts.
FIA_UID.2 All use of the user identification mechanism,
including the user identity provided.
Unknown user names are
not logged, in order to
protect passwords from
inadvertent disclosure.
FIA_USB.1 Success and failure of binding of user
security attributes to a subject (e.g. success
or failure to create a subject).
This operation is performed
in conjunction with the login
process, and is not logged
separately.
FMT_MSA.1 All modifications of the values of security
attributes.
FMT_MSA.3 a) Modifications of the default setting of
permissive or restrictive rules;
b) All modifications of the initial values of
security attributes.
FMT_MTD.1 All modifications to the values of TSF data.
FMT_SMF.1 Use of the management functions.
FMT_SMR.1 Modifications to the group of users that are
part of a role.
FPT_FLS.1 Failure of the TSF.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 44 of 104
Copyright © THALES Norway AS
TOE Requirement Event Note
FPT_RCV.1 a) The fact that a failure or service
discontinuity occurred.
Auditing may not be
available in this event (audit
storage is full). Startup is
guaranteed to be logged via
FPT_RCV.2.
FPT_RCV.2 a) The fact that a failure or service
discontinuity occurred;
b) Resumption of the regular operation;
c) Type of failure or service discontinuity
FPT_RCV.4 a) If possible, the inability to return to a
secure state after failure of a security
function;
b) If possible, the detection of a failure of a
security function.
FPT_TDC.1 a) Use of the TSF data consistency
mechanisms.
b) Identification of which TSF data have
been interpreted.
c) Detection of modified TSF data.
This requirement defines
“TSF data” as “object
security labels”
a) The mechanisms
cannot be bypassed.
Specific logging is not
considered to be
informative.
b) The TSF data is
invariant (security
labels), and are always
included in log data.
c) Any invalid security
labels are specifically
handled. The IT
environment protective
measures are used to
ensure TSF data
integrity.
FPT_TST.1 Execution of the TSF self tests and the
results of the tests.
FRU_FLT.2 Any failure detected by the TSF.
FRU_PRS.1 Priority level of each transmitted message.
Reception of FLASH messages.
Unhandled FLASH messages.
The guidance for
FRU_PRS.1 suggests that
invocation of the scheduling
security function may be
audited. This is both
infeasible and unnecessary
in the TOE, as priority is an
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 45 of 104
Copyright © THALES Norway AS
TOE Requirement Event Note
integral low-level part of the
implementation.
FTA_SSL.3 Termination of an interactive session by the
session locking mechanism.
FTA_TSE.1 All attempts at establishment of a user
session.
Table 6-1: Auditable Events
FAU_SAA.1
Potential violation analysis
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 TSP.
FAU_SAA.1.2
The TSF shall enforce the following rules for monitoring audited events:
a) Accumulation or combination of alarms known to indicate a potential security violation;
b) None
FAU_SAR.1
Audit review
FAU_SAR.1.1
The TSF shall provide authorized users with the capability to read all audit information from the TOE
audit records.
FAU_SAR.1.2
The TSF shall provide the audit records in a manner suitable for the authorized user to interpret the
information.
FAU_SAR.2
Restricted 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.1
Protected audit trail storage
FAU_STG.1.1
The TSF shall protect the stored audit records from unauthorized deletion.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 46 of 104
Copyright © THALES Norway AS
FAU_STG.1.2
The TSF shall be able to prevent unauthorized modifications to the audit records in the audit trail.
FAU_STG.3
Action in case of possible audit data loss
FAU_STG.3.1
The TSF shall generate an alarm if the audit trail storage exceeds 80% utilization or a configurable
limit.
FAU_STG.4
Prevention of audit data loss
FAU_STG.4.1
The TSF shall shut down the system if the audit trail is full.
6.1.1.2 Class FCO: Communication
FCO_NRO.1
Selective proof of origin
FCO_NRO.1.1
The TSF shall be able to generate evidence of origin for transmitted STANAG 4406 and Internet Mail
messages at the request of none (disabled), the message releaser (optional), or at all times
(required).
FCS_NRO.1.2
The TSF shall be able to relate the subject name and address of the originator of the information, and
the message’s S/MIME SignedAttributes and the message payload (STANAG 4406: P2 content,
Internet Mail: Message bodyparts.) of the information to which the evidence applies.
FCO_NRO.1.3
The TSF shall provide a capability to verify the evidence of origin of information to the message
releaser and recipient given that a message signature is present.
FCO_NRR.1
Non-repudiation of receipt
FCO_NRR.1.1
The TOE shall be able to generate evidence of receipt for received STANAG 4406 and Internet Mail
messages at the request of the message releaser.
FCO_NRR.1.2
The TSF shall be able to relate the subject name and address of the originator of the information, and
the message’s S/MIME SignedAttributes and the message payload (STANAG 4406: P2 content,
Internet Mail: Message bodyparts) of the information to which the evidence applies.
FCO_NRR.1.3
The TSF shall provide a capability to verify the evidence of receipt of information to message releaser
and recipient given that a signed recieipt has been generated.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 47 of 104
Copyright © THALES Norway AS
6.1.1.3 Class FCS: Cryptographic support
FCS_COP.1
Cryptographic operation
FCS_COP.1.1
The TSF shall perform generate message digests in accordance with a specified cryptographic
algorithm and cryptographic key sizes hash function lengths as shown in the table below that meet
the following: NIST FIPS PUB 180-4 Secure Hash Standard [15]
SHA-1 160-bit
SHA-2 256-bit, 384-bit, 512-bit
Table 6-2 Supported digest algorithms
6.1.1.4 Class FDP: User data protection
FDP_ACC.2
Complete access control
FDP_ACC.2.1
The TSF shall enforce the DAC on all user created data in the internal database and all operations
among subjects and objects covered by the SFP.
FDP_ACC.2.2
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 TSF.
FDP_ACF.1
Access control functions
FDP_ACF.1.1
The TSF shall enforce the DAC to objects based on the following: subject identifier, object ownership.
FDP_ACF.1.2
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed: Use of Command ACLs and Storage ACL.
FDP_ACF.1.3
The TSF shall explicitly authorize access of subjects to objects based on the following additional
rules:
a) XOMAIL_SA
If the subject is connected as the Primary Security Administrator user, all XOmail
administrative access is allowed.
Note: This applies only to the Primary Security Administrator user, not to all users with SA
role.
b) XOMAIL_ROOT
If the subject is the XOmail system user, user access to all database objects is allowed.
FDP_ACF.1.4
The TSF shall explicitly deny access of subjects to objects based on the following additional rules:
none.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 48 of 104
Copyright © THALES Norway AS
FDP_ETC.2
Export of user data with security attributes
FDP_ETC.2.1
The TSF shall enforce the DAC and the MAC when exporting user data, controlled under the SFP(s),
outside of the TSC.
FDP_ETC.2.2
The TSF shall export the user data with the user data’s associated security attributes.
FDP_ETC.2.3
The TSF shall ensure that the security attributes, when exported outside the TSC, are unambiguously
associated with the exported user data.
FDP_ETC.2.4
The TSF shall enforce the following rules when user data is exported from the TSC:
a) Convert security label from internal representation into the representation required by the
export medium.
FDP_IFC.2
Complete information flow control
FDP_IFC.2.1
The TSF shall enforce the MAC as stated in B&L [4] on all subjects, all information, and all operations
that cause that information to flow to and from non-trusted subjects covered by the SFP.
FDP_IFC.2.2
The TSF shall ensure that all operations that cause any information in the TSC to flow to and from any
subject in the TSC are covered by an information flow control SFP.
FDP_IFF.2
Hierarchical security attributes
FDP_IFF.2.1
The TSF shall enforce the MAC as stated in B&L [4] based on the following types of subject and
information security attributes: subject security clearance (max HCL, NHC, SP), object hierarchical
classification level (HCL), object non-hierarchical categories (NHC) and object security policy (SP).
FDP_IFF.2.2
The TSF shall permit an information flow between a controlled subject and controlled information via a
controlled operation if the following rules, based on the ordering relationships between security
attributes hold:
a) Read operation: Subject clearance must dominate object label (S >= O).
b) Write operation: Object label must dominate subject clearance (O >= S).
c) RW operation: Subject clearance must be equal to object label (S == O).
FDP_IFF.2.3
The TSF shall enforce the following additional flow control SFP rules: none.
FDP_IFF.2.4
The TSF shall provide the following additional SFP capabilities: none.
FDP_IFF.2.5
The TSF shall explicitly authorise an information flow based on the following rules:
a) The Non-Hierarchical category CLEAR shall allow communication of classified information via
unsecured communication channels. Information shall be marked CLEAR (according to the
interface protocol used), and the original label shall not be transmitted. On reception, CLEAR
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 49 of 104
Copyright © THALES Norway AS
info shall be marked with a hierarchical security label corresponding to Confidential, and the
non-hierarchical security category CLEAR.
b) Trusted subjects are allowed to bypass the MAC rules of FDP_IFF.2.2.
FDP_IFF.2.6
The TSF shall explicitly deny information flow based on the following rules: none.
FDP_IFF.2.7
The TSF shall enforce the following relationships for any two valid information flow control security
attributes:
a) There exists an ordering function that, given two valid security attributes, determines if the
security attributes are equal, if one security attribute is greater than the other, or if the two
security attributes are incomparable; and
b) There exists a ”least upper bound” in the set of security attributes, such that, given any two
security attributes, there is a valid security attribute that is greater than or equal to the two
valid security attributes; and
c) There exists a ”greatest lower bound” in the set of security attributes, such that, given any two
valid security attributes, there is a valid security attribute that is not greater than the two valid
security attributes.
FDP_ITC.2
Import of user data with security attributes
FDP_ITC.2.1
The TSF shall enforce the DAC and the MAC when importing user data, controlled under the SFP,
from outside of the TSC.
FDP_ITC.2.2
The TSF shall use the security attributes associated with the imported user data.
FDP_ITC.2.3
The TSF shall ensure that the protocol used provides for the unambiguous association between the
security attributes and the user data received.
FDP_ITC.2.4
The TSF shall ensure that interpretation of the security attributes of the imported user data is as
intended by the source of the user data.
FDP_ITC.2.5
The TSF shall enforce the following rules when importing user data controlled under the SFP from
outside the TSC:
a) If no label is present:
The message shall be set to the highest label of the channel.
b) If the label is invalid:
ACP: The message shall be trapped.
Other channels: The message shall be discarded and alarm shall be generated.
c) If the channel is tagged as “System-High”, the label shall be set to the highest allowed, and
the original label shall be kept as an informative label.
d) If the label exceeds the bounds defined for the channel, the message shall be rejected, and
an alarm shall be generated.
e) If Security Review & Release is activated for the channel, an authorized user shall specify the
resulting security label.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 50 of 104
Copyright © THALES Norway AS
Note: ACP127 message traffic is handled differently because ACP communication channels may
be unreliable and message corruption is common. Messages containing errors are trapped for
manual inspection by a designated traffic operator.
FDP_RIP.2
Full residual information protection
FDP_RIP.2.1
The TSF shall ensure that any previous information content of a resource is made unavailable upon
the allocation of the resource to all objects.
FDP_UIT.1
Data exchange integrity
FDP_UIT.1.1
The TSF shall enforce the DAC to transmit user data in a manner protected from modification and
insertion errors.
FDP_UIT.1.2
The TSF shall be able to determine on receipt of user data, whether modification or insertion has
occurred.
6.1.1.5 Class FIA: Identification and authentication
FIA_AFL.1
Authentication failure handling
FIA_AFL.1.1
The TSF shall detect when an administrator configurable positive integer within 0 and 999999
unsuccessful authentication attempts occur related to client logons for all users.
FIA_AFL.1.2
When the defined number of unsuccessful authentication attempts has been surpassed, the TSF shall
lock the user account, e.g. the user shall not be able to authenticate until an administrator unlocks the
user account.
FIA_ATD.1
User attribute definition
FIA_ATD.1.1
The TSF shall maintain the following list of security attributes belonging to individual users:
a) User identifier
b) User clearance
c) User template (group)
Each user belongs to a user template. The following security attributes are determined by the
user template:
1) User command access
2) Administrator role.
3) Command ACLs
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 51 of 104
Copyright © THALES Norway AS
d) Message storage access lists.
FIA_UAU.2
Timing of authentication
FIA_UAU.2.1
The TSF shall require each user to be successfully authenticated before allowing any other TSF-
mediated actions on behalf of that user.
FIA_UAU.5
Multiple authentication mechanisms
FIA_UAU.5.1
The TSF shall provide verification of username and password to support user authentication.
FIA_UAU.5.2
The TSF shall authenticate any user’s claimed identify according to the following rules:
a) Use OS password verification mechanisms to verify the username and password.
b) Use Kerberos to authenticate user using a Kerberos ticket provided by the OS.
FIA_UAU.6
Re-authenticating
FIA_UAU.6.1
The TSF shall reauthenticate the user under the conditions:
a) when requested by an administrator
b) when an administrator triggers an administrative command that requires reauthentication to
be performed.
FIA_UID.2
Timing of identification
FIA_UID.2.1
The TSF shall require each user to identify itself before allowing any other TSF-mediated actions on
behalf of that user.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 52 of 104
Copyright © THALES Norway AS
FIA_USB.1
User-subject binding
FIA_USB.1.1
The TSF shall associate the following user security attributes with subjects acting on behalf of that
user: User identifier, User Clearance, User Command Access.
FIA_USB.1.2
The TSF shall enforce the following rules on the initial association of user security attributes with
subjects acting on the behalf of users:
a) Initial User identifier shall be identical to OS user identifier with the same username
b) Initial User Clearance shall be set from the User Template that the user creation is based on
FIA_USB.1.3
The TSF shall enforce the following rules governing changes to the user security attributes associated
with subjects acting on the behalf of users:
a) Users shall be logged out when User Clearance has been changed
b) Users shall be logged out when User Command Access has been changed.
6.1.1.6 Class FMT: Security management
FMT_MSA.1
Management of security attributes
FMT_MSA.1.1
The TSF shall enforce the MAC and the DAC to restrict the ability to change_default, query, modify or
delete the security attributes:
a) Subject security clearance,
b) Subject administrator access levels,
c) Subject and object ACLs (e.g. command access),
d) Template Permit flag.
to the Security Administrator role.
The following exceptions exist:
a) The Administrator role may query and modify department ACLs if sufficient command access
is available for the user.
b) A user may grant other users read access to objects owned by the user (the user’s own
storage).
FMT_MSA.3
Static attribute initialization
FMT_MSA.3.1
The TSF shall enforce the MAC and DAC to provide configurable default values for security attributes
that are used to enforce the SFP.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 53 of 104
Copyright © THALES Norway AS
FMT_MSA.3.2
The TSF shall allow the Security Administrator role to specify alternative initial values to override the
default values when an object or information is created.
FMT_MTD.1
Management of TSF data
FMT_MTD.1.1
The TSF shall restrict the ability to query, modify, and delete the system configuration to the
Administrator, Network Administrator and Security Administrator roles.
FMT_SMF.1
Specification of Management Functions
FMT_SMF.1.1
The TSF shall be capable of performing the following security management functions: TOE security
data maintenance.
FMT_SMR.1
Security roles
FMT_SMR.1.1
The TSF shall maintain the roles User, Administrator, Network Administrator and Security
Administrator.
FMT_SMR.1.2
The TSF shall be able to associate users with roles.
6.1.1.7 Class FPT: Protection of the TSF
FPT_FLS.1
Fail secure
FPT_FLS.1.1
The TSF shall preserve a secure state when the following types of failures occur: all.
FPT_RCV.1
Manual Recovery
FPT_RCV.1.1
After audit storage has been exhausted the TSF shall enter a maintenance mode where the ability to
return to a secure state is provided.
FPT_RCV.2
Automated recovery
FPT_RCV.2.1
When automated recovery from abnormal termination is not possible, the TSF shall enter a
maintenance mode where the ability to return to a secure state is provided.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 54 of 104
Copyright © THALES Norway AS
FPT_RCV.2.2
For all failures except abnormal termination, the TSF shall ensure the return of the TOE to a secure
state using automated procedures.
FPT_RCV.4
Function recovery
FPT_RCV.4.1
The TSF shall ensure that all SFs have the property that the SF either completes successfully, or for
the indicated failure scenarios, recovers to a consistent and secure state.
FPT_TDC.1
Inter-TSF basic TSF data consistency
FPT_TDC.1.1
The TSF shall provide the capability to consistently interpret object security labels when shared
between the TSF and another trusted IT product.
FPT_TDC.1.2
The TSF shall use the rules defined for the communication channel when interpreting the TSF data
from another trusted IT product.
Note 1: The interpretation will depend on which protocol is used by the originator.
FPT_TST.1
TSF testing
FPT_TST.1.1
The TSF shall run a suite of self-tests during initial start-up to demonstrate the correct operation of the
TSF.
FPT_TST.1.2
The TSF shall provide authorized users with a capability to verify the integrity of TSF data.
FPT_TST.1.3
The TSF shall provide authorized users with the capability to verify the integrity of stored TSF
executable code, including installed patches.
6.1.1.8 Class FRU: Resource utilisation
FRU_FLT.2
Limited fault tolerance
FRU_FLT.2.1
The TSF shall ensure the operation of all the TOE’s capabilities when the following failures occur:
a) Abnormal termination of a TOE software module
FRU_PRS.1
Limited priority of service
FRU_PRS.1.1
The TSF shall assign a priority to each subject in the TSF.
FRU_PRS.1.2
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 55 of 104
Copyright © THALES Norway AS
The TSF shall ensure that each access to the following resources shall be mediated on the basis of the
subjects’ assigned priority:
 Secure DBMS
 Inter-Process Communication handled by the reference monitor.
 Message processing resources specifically reserved for FLASH traffic.
6.1.1.9 Class FTA: TOE access
FTA_SSL.3
TSF-initiated termination
FTA_SSL.3.1
The TSF shall terminate an interactive session after a configurable period of user inactivity.
Note: The requirement applies to the XOmail MS Client only.
FTA_TSE.1
TOE session establishment
FTA_TSE.1.1
The TSF shall be able to deny session establishment based on the following attributes:
- the lock attribute for users and administrators,
- the ip address, subnet address or hostname of the client
- the authentication tokens provided
6.2 TOE SECURITY ASSURANCE REQUIREMENTS
The security assurance requirements for the TOE are selected according to EAL4 augmented with
ALC_FLR.3 (systematic flaw remediation).
From CC Part 3:
EAL4 provides assurance by a full security target and an analysis of the SFRs in that ST, using a
functional and complete interface specification, guidance documentation, a description of the basic
modular design of the TOE, and a subset of the implementation, to understand the security
behaviour.
The analysis is supported by independent testing of the TSF, evidence of developer testing based
on the functional specification and TOE design, selective independent confirmation of the developer
test results, and a vulnerability analysis (based upon the functional specification, TOE design,
implementation representation, security architecture description and guidance evidence
provided) demonstrating resistance to penetration attackers with an Enhanced-Basic attack
potential.
EAL4 also provides assurance through the use of development environment controls and additional
TOE configuration management including automation, and evidence of secure delivery
procedures.
EAL4 is considered appropriate for the TOE when placed in an operational environment with the properties
and policies described by the security problem definition in Chapter 3. The security problem definition has
been selected according to operational environments for classified networked information systems in military
organizations.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 56 of 104
Copyright © THALES Norway AS
The ALC_FLR.3 component has been included to provide assurance for the developer’s procedures for
handling and patching security flaws discovered in the TOE.
Assurance Class Assurance components
ADV: Development
ADV_ARC.1 Security architecture description
ADV_FSP.4 Complete functional specification
ADV_IMP.1 Implementation representation of the TSF
ADV_TDS.3 Basic modular design
AGD: Guidance documents
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
ALC: Life-cycle support
ALC_CMC.4 Production support, acceptance procedures and
automation
ALC_CMS.4 Problem tracking CM coverage
ALC_DEL.1 Delivery procedures
ALC_DVS.1 Identification of security measures
ALC_FLR.3 Systematic flaw remediation
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
ASE: Security Target evaluation
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
ASE_OBJ.2 Security objectives
ASE_REQ.2 Derived security requirements
ASE_SPD.1 Security problem definition
ASE_TSS.1 TOE summary specification
ATE: Tests
ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: basic design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing – sample
AVA: Vulnerability assessment AVA_VAN.3 Focused vulnerability analysis
Table 6-3: EAL4 augmented with ALC_FLR.3
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 57 of 104
Copyright © THALES Norway AS
7. TOE SUMMARY SPECIFICATION (ASE_TSS)
This describes the security functions provided by the TOE to meet the security functional requirements
specified. Furthermore a statement of assurance measures specifies the assurance measures of the TOE
that are claimed to satisfy the stated assurance requirements.
7.1 TOE SECURITY FUNCTIONS
7.1.1 SF.AUDIT
Audit data is stored in the TOE secure database (SS) and through OS auditing mechanisms.
The following operator-initiated operations are auditable:
1) Message operations performed by users.
 Show
 Print
 Delete
 Change
Does not apply to Draft messages
 Accept
 Send
 Refuse
 Change Label
 Release from Security Review
 Release from Vetting
 Reroute
 Resend
 Copy
 Forward
 Reply
 Export message
 Export attachment
 Import message
 Create from message
 Restore deleted message
 Result from message signature validation
2) Message reception and transmission.
3) Message signed, validated, or re-signed by a traffic operator or gateway
4) Reception of files from centralized management.
5) FLASH message reception and transmission.
6) All administrator commands.
7) Whether each operation or command succeeded or was denied.
8) User login attempts, both successful and failed, and logout.
9) User lockout after a number of unsuccessful logins.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 58 of 104
Copyright © THALES Norway AS
10) All changes to a user’s command access.
11) System failures.
12) Self-tests and self-test results.
13) Start-up and shutdown of the XOmail Server.
Note that the audit functions cannot be disabled,
and are started before any auditable events can be performed.
The TOE associates a user identity with all records where applicable.
It is possible for the Security Administrators and Primary Security Administrator to configure alarm
descriptors for each alarm type. The alarm descriptors include e.g. alarm severity level, and whether
successive alarm events in a configurable period shall raise the corresponding alarm.
Additionally, Security Administrators and Primary Security Administrator may configure specific auditable
events to be reported to the operating system or via SNMP, in addition to the secure database. Alarms may
also be configured to be stored on the file system. External files and databases are protected by OS DAC.
MAC is enforced when printing alarms.
The XOmail audit logs are stored in the XOmail database and protected by SF.DAC and SF.MAC. DAC is
evaluated for each audit log (e.g. system log), and MAC is evaluated for each record. A user must pass both
mechanisms to gain access to audit records.
It is possible to add audit records until the hard disk is full. An alarm will be issued when disk utilization
exceeds a configurable limit. When the hard disk is full, XOmail will shut down. The TOE can be started
manually after sufficient disk space has been made available in the TOE environment. If an error occurred
during shutdown, recovery is handled by SF.DB_SELF_TEST.
When the TOE has initiated the auditing via an OS system call, the responsibility for correct audit handling is
transferred to the OS.
7.1.2 SF.AUTHENTICATION
The SF ensures that only authenticated users get access to TOE services and data held within the TOE. If
correct authentication tokens can be provided, the SF associates a role and a security clearance with the
user. The TOE supports both user-password authentication and single sign-on mechanisms such as
Kerberos.
7.1.3 SF.AUTO_LOGOUT
The SF ensures that XOmail MS Client sessions can be terminated after a period of inactivity. The length of
the period of inactivity is configurable.
7.1.4 SF.CLEAR
A CLEAR policy offers the opportunity for (authorized) users, forcibly and deliberately, to initiate the
transmission of classified messages over a communication channel, despite its rejection by the basic
Communication Policy (“Sending Sufficiency”).
The CLEAR policy has three major components:
 The CLEAR-MARKING policy which enables the marking of a message in order for the Communication
policy to recognize it
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 59 of 104
Copyright © THALES Norway AS
 The CLEAR-SENDING policy, which recognizes a CLEAR message, and allows its transmission. This
policy is essentially a part of the Communication Policy (“Sending Exception”)
 The CLEAR-RECEPTION policy which recognizes a cleared message upon reception, and enforces that
such a message is hierarchically labelled as “CONFIDENTIAL”, and non-hierarchically labelled as
“Clear”
7.1.5 SF.COMMAND_ACCESS
Administrative access is configurable on a User Template basis. For every operation on an Admin Main
Object or Admin Object it is possible to grant or deny access for users based on the User Template currently
edited. Role assignments furthermore apply some restrictions on how command access can be configured.
7.1.6 SF.COMMUNICATION_SECURITY
The interfaces to external channels perform the following security functions:
 Correct labelling of incoming and outgoing messages.
 Evaluate needs for Secure Associations
The TOE ensures that classified information is sent on secure lines only. It is the responsibility of system
administrators to define which lines are secure. See XOmail Administrator’s Guide[3] for details. Note
that SF.CLEAR provides a controlled override of this policy.
 Provision of a Secure Association Service based on network status and/or manual settings by Security
Administrators.
7.1.7 SF.DAC
The Discretionary Access Control (DAC) is always invoked when a subject requests access to tables. If an
ACL is defined for the table, that ACL is used for identifying the allowable types of access. If an ACL does
not exist, only the table owner is allowed to access the table and its content.
Every user must furthermore be explicitly authorized before being given access to the XOmail MS Client,
XOmail Web Client, Admin Client or Web Admin Client. The Discretionary Access Control (DAC) is inhibited
for the XOmail system user.
Finally, SF.DAC enforces access control for message storage access and traffic operator commands.
A subject must pass both MAC and DAC to access an object.
7.1.8 SF.DB_SELF_TEST
During XOmail start-up, the system database performs a self-test. The test includes a check for whether the
database was cleanly shut down, or not. If the database was not cleanly shut down, an internal check for
consistency is performed. The check is algorithmic, i.e. for each field it is evaluated whether the value is
correct or incorrect. The function also corrects incorrect values, and ensures that XOmail enters a secure
state upon startup.
7.1.9 SF.EXECUTION_DOMAINS
The TOE will ensure that execution domains are separated, by using both TSF and OS mechanisms. The
OS is responsible for keeping processes separated, and for zeroing memory for processes when created
and disk space when allocated. The TOE explicitly classifies processes as trusted or untrusted.
Communication between the two classes is brokered by a reference monitor. The TOE will prevent
inadvertent disclosure of information by zeroing new database objects.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 60 of 104
Copyright © THALES Norway AS
7.1.10 SF.MESSAGE_INTEGRITY
The TOE supports S/MIME digital signatures in STANAG 4406 Ed 2. By digitally signing STANAG 4406 Ed 2
messages, the TOE provides server to server message integrity protection, non-repudiation of origin, and
non-repudiation of receipt.
The TOE also provides a capability for either server-side (organizational or department level) signatures, or
personal signatures. When personal signatures are used, the TOE prepares the message for signature,
while the signing operation is performed by the client (non-TOE) on behalf of the user. The TOE relies on the
TOE Environment to support the signing operations and the secure storage of cryptographic keys.
Incoming digitally signed messages are verified by the TOE when delivered to recipient storages, or in
gateway operations. Outgoing military messages may be digitally signed before transmission depending on
the system’s configured security policy.
The TOE also supports re-signing messages when conversions or traffic operator handling invalidates the
message signature.
When requested by an originator, the TOE will generate a delivery report or read receipt. If required by
configuration, these will be signed, ensuring non-repudiation of receipt.
The TOE can be configured to interface external systems or use protocols without support for digital
signatures. The TOE will verify signatures before transmission of messages on these channels, and will sign
incoming messages.
The security function is configurable and optional, and applies to the STANAG 4406 Ed 2 protocol and the
SMTP Gateway.
7.1.11 SF.LABEL_TRANSFORM
During their lifetime messages may be converted between different format representations. Within XOmail
four different formats exists, i.e. a human-readable format, the ACP127 format, the STANAG 4406 format
and the XOmail internal storage format. The value set for security classification need not be the same for the
four different format representations.
There exists a predefined and unambiguous way to transform the security label between these four
representations. This transformation is performed by a trusted function. The transformation handles cases
with syntactical or semantic errors in a security label, and cases where a security label cannot be
represented in the target format. These result in the transformation not taking place with a subsequent failure
in processing.
7.1.12 SF.LABELLING
On the ACP127-interface and STANAG 4406 interface, messages may arrive without labelling or with a label
that is not possible to determine. In these cases the messages shall be trapped (ACP), discarded (STANAG
4406, invalid label) or labelled with maximum label for the current channel (STANAG 4406, without label).
7.1.13 SF.LOCK
All user accounts can be locked. The TSF supports both manual and automatic locking. A user with the
Administrator, Network Administrator or Security Administrator role initiates the manual locking. The
automatic locking is initiated by a succession of unsuccessful logon attempts.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 61 of 104
Copyright © THALES Norway AS
This function is a separate function from the locking mechanism implemented in the operating system, and
allows for users to be locked out from the TOE while still being allowed to use the operation system in the
TOE environment.
7.1.14 SF.MAC
The Mandatory Access Control (MAC) implements access rights according to hierarchical classification level
(HCL), non-hierarchical category (NHC) and security policy (SP). For MAC evaluation, SP is handled in the
same way as the NHC. A subject must pass both MAC and DAC to access an object.
7.1.15 SF.PRIORITY
The TOE integrates support for priority across all levels of its implementation, to ensure timely delivery of
messages according to their precedence. Priority attributes are embedded in communication between
modules within the TOE (including the secure DBMS) and in all messages sent onto the network, including to
the Mail Client. Non-message processing (e.g. administrator sessions) is given a default (low or normal)
priority in the TOE
The TOE reference monitor queues and processes internal communication according to priority.
FLASH messages are handled specially by the TOE, with reserved resources to ensure immediate
processing of STANAG 4406 messages even under heavy load.
7.1.16 SF.ROLES
TOE users are assigned a role designating the type of administrative access. There are four defined roles:
User (no administrator access), Administrator, Network Administrator and Security Administrator. Every
authenticated used is associated with a role during logon.
An additional role, the Primary Security Administrator is provided as a built in role for initial configuration. The
Primary Security Administrator may be locked after initial configuration (SF.LOCK).
An administrator role is required to access the Admin Client and Web Admin Client. Additionally, the user
must be explicitly granted access to commands. The role defines the set of commands that may be enabled
for the user.
7.1.17 SF.SECURE_STATE_RECOVERY
Security functions of the XOmail system are designed so that they either succeed and lead to a new secure
state, or fail and then return to the previous secure state.
When a software fault is detected, the TOE restores operation by restarting the affected software module,
the entire TOE or the operating system.
Upon fatal failure of the XOmail system, the system is automatically shut down and the current state is
preserved for later use. The secure state is restored via the SF.DB_SELF_TEST security function.
7.1.18 SF.SUBNET_RESTRICTION
XOmail MS Client and XOmail Web Client logons may be restricted to be from a specific IP address, a
specific hostname, or specific IP subnets only. These restrictions can be configured on a per-storage and
per-user basis. That is, a user may have access to storages according to ACLs, but
SF.SUBNET_RESTRICTION restricts the locations from which the storage can be accessed.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 62 of 104
Copyright © THALES Norway AS
7.1.19 SF.VALIDATE
The validate security function provides the ability to verify the integrity of both TSF data and TSF executable
code. The validation mechanism produces checksums that must be compared with the developer provided
checksums. SF.VALIDATE also validates the signature of core configuration files, such as the security policy
definitions (part of TSF data).
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 63 of 104
Copyright © THALES Norway AS
8. RATIONALE
The rationale demonstrates that threats, assumptions and policies form a basis for the definition of security
objectives. Likewise, it is demonstrated that the chosen security requirements cover all security objectives,
and that security functions in the TOE or its environment fully cover the security requirements.
8.1 SECURITY OBJECTIVES RATIONALE
In the following subsections every security objective is correlated with identified threats and assumptions. It
is furthermore shown that all identified threats are covered by a security objective.
The following three tables (Table 8-1, Table 8-3 and Table 8-4) demonstrate that all threats, assumption and
policies are covered by a security objective. Some threats are fully covered by a single security objective,
while others need more than one security objective to be fully covered.
Threats
TT.ADM_ERROR
TT.AUDIT_FAILURE
TT.COM_INTEGRITY
TT.DOS
TT.FAULTS
TT.MASQUERADE
TT.MONITORING
TT.REPLAY
TT.UNATTENDED
TT.UNAUTH_ACCESS
Security objectives
O.ACCESS_HIST X X X X
O.AUDIT X X X X X X
O.AUTO_LOGOUT X
O.CMD_ACL X X
O.CMD_LOG X X X X X X
O.DAC X X
O.FLASH X
O.ID_AUTH X X X X
O.LABELLING X
O.LOCK X
O.MAC X X
O.MAC_INTEGRITY X
O.MANAGE X
O.MESSAGING X
O.MSG_INTEGRITY X
O.RECOVER X X X
O.REUSE X X
O.ROLE_MNG X X
O.ROLES X X
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 64 of 104
Copyright © THALES Norway AS
Threats
TT.ADM_ERROR
TT.AUDIT_FAILURE
TT.COM_INTEGRITY
TT.DOS
TT.FAULTS
TT.MASQUERADE
TT.MONITORING
TT.REPLAY
TT.UNATTENDED
TT.UNAUTH_ACCESS
Security objectives
O.SCHEDULING X
O.SELF_TEST X X
OE.ACCOUNTABLE X
OE.AUDIT X X
OE.ID_AUTH
OE.NETWORK X X X X X
OE.PKI X
OE.PLATFORM X
OE.TRAF_SEPARATION X
OE.TIME_SOURCE
NOE.ADM_TRUST X
NOE.INSTALL X
NOE.PHYSICAL X X X X X
Table 8-1: TOE threats coverage
Threats
TE.AUDIT_FAILURE
TE.DELIVERY
TE.DOS
TE.IMPROPER_INST
TE.POOR_DESIGN
TE.POOR_IMPL
TE.UNATTENDED
Security objectives
O.ACCESS_HIST
O.AUDIT
O.AUTO_LOGOUT
O.CMD_ACL
O.CMD_LOG
O.DAC
O.FLASH
O.ID_AUTH
O.LABELLING
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 65 of 104
Copyright © THALES Norway AS
Threats
TE.AUDIT_FAILURE
TE.DELIVERY
TE.DOS
TE.IMPROPER_INST
TE.POOR_DESIGN
TE.POOR_IMPL
TE.UNATTENDED
Security objectives
O.LOCK
O.MAC
O.MAC_INTEGRITY
O.MANAGE
O.MESSAGING
O.MSG_INTEGRITY
O.RECOVER X X
O.REUSE
O.ROLE_MNG
O.ROLES
O.SCHEDULING
O.SELF_TEST
OE.ACCOUNTABLE
OE.AUDIT X X X
OE.ID_AUTH
OE.NETWORK X X X
OE.PKI
OE.PLATFORM
OE.TRAF_SEPARATION X X
OE.TIME_SOURCE
NOE.ADM_TRUST X
NOE.INSTALL X X
NOE.PHYSICAL X X X X
Table 8-2: TOE Environment threats coverage
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 66 of 104
Copyright © THALES Norway AS
Assuptions
and
policies
A.ADM_TRAINING
A.ARCHIVE_DB
A.AUDIT_REVIEW
A.CONFIDENCE
A.INVALIDATE
A.NETWORK
A.NOTIFY
A.PHYSICAL
A.PHYSICAL_LOC
A.OS
A.USR_TRAINING
A.TIME_SOURCE
Security objectives
O.ACCESS_HIST
O.AUDIT
O.AUTO_LOGOUT
O.CMD_ACL
O.CMD_LOG
O.DAC
O.FLASH
O.ID_AUTH X
O.LABELLING
O.LOCK
O.MANAGE
O.MAC
O.MAC_INTEGRITY
O.MESSAGING
O.MSG_INTEGRITY
O.RECOVER
O.REUSE
O.ROLE_MNG
O.ROLES
O.SCHEDULING
O.SELF_TEST
OE.ACCOUNTABLE X X X
OE.AUDIT X
OE.ID_AUTH X
OE.NETWORK X X X
OE.PKI
OE.PLATFORM X X
OE.TRAF_SEPARATION X
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 67 of 104
Copyright © THALES Norway AS
Assuptions
and
policies
A.ADM_TRAINING
A.ARCHIVE_DB
A.AUDIT_REVIEW
A.CONFIDENCE
A.INVALIDATE
A.NETWORK
A.NOTIFY
A.PHYSICAL
A.PHYSICAL_LOC
A.OS
A.USR_TRAINING
A.TIME_SOURCE
Security objectives
OE.TIME_SOURCE X
NOE.ADM_TRUST X X
NOE.INSTALL X X X X X
NOE.PHYSICAL X X
Table 8-3: Assumptions coverage
Assuptions
and
policies
P.ACCOUNTABILITY
P.CLASSIFICATION
P.CLEAR
P.DAC
P.INTEGRITY
P.INTERFACE_CONTROL
P.MAC
P.MARKING
P.PROTECTION
Security objectives
O.ACCESS_HIST X
O.AUDIT X
O.AUTO_LOGOUT
O.CMD_ACL
O.CMD_LOG X
O.DAC X
O.FLASH
O.ID_AUTH X
O.LABELLING X
O.LOCK
O.MANAGE
O.MAC X X X
O.MAC_INTEGRITY X
O.MESSAGING
O.MSG_INTEGRITY X
O.RECOVER
O.REUSE
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 68 of 104
Copyright © THALES Norway AS
Assuptions
and
policies
P.ACCOUNTABILITY
P.CLASSIFICATION
P.CLEAR
P.DAC
P.INTEGRITY
P.INTERFACE_CONTROL
P.MAC
P.MARKING
P.PROTECTION
Security objectives
O.ROLE_MNG
O.ROLES X
O.SCHEDULING
O.SELF_TEST
OE.ACCOUNTABLE X
OE.AUDIT X
OE.ID_AUTH
OE.NETWORK X X
OE.PKI X
OE.PLATFORM X
OE.TRAF_SEPARATION
OE.TIME_SOURCE
NOE.ADM_TRUST
NOE.INSTALL X X
NOE.PHYSICAL X
Table 8-4: Policies coverage
8.1.1 THREATS MET BY THE TOE
TT.ADM_ERROR
Objectives covering this threat:
 O.AUDIT, O.CMD_LOG, OE.AUDIT
Knowing that security relevant actions are audited makes this a less likely occurrence, as administrators
know that they can be held accountable for their actions. The intention is that administrators perhaps will
think twice/double check before initiating a command when knowing that the command is audited.
Auditing will also make it possible to identify and correct unwanted operations.
 O.CMD_ACL
Command ACLs allows administrative access to be tailored for each administrative role. Restricting
access to commands reduces the risk of administrative errors.
 O.DAC
Restricting access to objects reduces the probability of and effect of administrative errors.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 69 of 104
Copyright © THALES Norway AS
 O.MAC
Restricting access to objects reduces the probability of and effect of administrative errors.
 O.MANAGE
Means for an effective management of the TOE reduces the possibility of unintentional administrator
errors.
 O.ROLE_MNG
Managing role associations makes it possible to avoid wrong role associations.
 O.ROLES
Roles categorizes administrative responsibilities. Well-defined responsibilities reduce the possibility of
administrative errors.
 OE.ACCOUNTABLE
Those responsible for the TOE will ensure that administrative privileges are granted only to those users
who are authorized. The scope of administrative privileges are limited to the user’s actual needs. This
limits the probability and impact of administrative errors.
 NOE.ADM_TRUST
Ensuring that administrators are trustworthy is an essential countermeasure for unintentional
administrative errors. Trustworthy personnel improve the quality of the work performed.
 NOE.INSTALL
Administrator training and organizational procedures ensure that the TOE is administered according to
the TOE guidance documentation.
TT.AUDIT_FAILURE
Objectives covering this threat:
 O.ACCESS_HIST
Access history is useful when audit failure already has occurred. It can help determining from where and
by whom a possible attack was performed. Other reasons for audit failure may also be determined from
the access history.
 O.AUDIT
The objective shall prevent audit failures. Audit failures include audit overflow, erroneous audit data and
missing audit records.
 O.CMD_LOG
Logging administrative commands will ensure that it is possible to detect actions that may lead to audit
failure.
TT.COM_INTEGRITY
Objectives covering this threat:
 O.MSG_INTEGRITY
The objective ensures integrity of message content, and discovery of integrity violations.
 OE.NETWORK
The objective ensures integrity of messages transmitted over the network.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 70 of 104
Copyright © THALES Norway AS
 OE.PKI
The objective supports the operation of O.MSG_INTEGRITY.
 NOE.PHYSICAL
The objective ensures integrity by restricting physical access.
TT.DOS
Objectives covering this threat:
 O.AUDIT
Audit logs can be used to detect possible DOS attacks so that proper measures can be applied in an
early stage of an attack.
 O.CMD_LOG
The command log can in certain situations reveal by whom and from where a DOS attack was launched.
Having identified by whom and from where the attack is coming, it is considerably easier to assign
countermeasures.
 O.FLASH
FLASH message traffic is given priority over other traffic, even when the server experiences heavy load
or network congestion.
 O.RECOVER
The objective covers recovery from possible DOS attacks.
 O.SELF_TEST.
Ensuring that a database self-test is being performed during start-up reduces the chances of the TOE
entering an unknown state after a DoS attack.
 O.SCHEDULING
The TOE queues and processes messages in an order according to priority. This ensures that higher
priority traffic is given precedence during network congestion and heavy load.
 OE.NETWORK.
The objective reduces the possibility of DoS attacks against the TOE as it becomes considerably more
difficult for attackers to gain access to the network the TOE resides in. The network protection will also to
a certain degree prevent external subjects from accessing the computer equipment hosting the TOE.
 NOE.PHYSICAL
The objective reduces the possibility for DOS attacks met by the TOE as it becomes considerably more
difficult to send data resulting in TOE resource exhaustion. The physical protection prevents
unauthorized sources from accessing computer equipment hosting the TOE, thereby complicating the
DoS attack. Other channels than physical access to the TOE must be used.
TT.FAULTS
 O.RECOVER
The TOE is able to recover from software faults by restarting failed modules, the entire TOE, or the
operating system of the MMHS Server.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 71 of 104
Copyright © THALES Norway AS
TT.MASQUERADE
Objectives covering this threat:
 O.ACCESS_HIST
The objective will provide means for detection of entity masquerading. The objective itself is not to detect
masquerading, but to provide evidence of access that can be used in forensic analysis.
 O.AUDIT
Auditing operations issued during a masquerade attack can help both in determining from where and by
whom the attack was launched. It may also to a certain degree help in reversing actions performed as
part of the attack.
 O.CMD_LOG
Logging commands issued during a masquerade attack can help both in determining from where and by
whom the attack was launched. It may also to a certain degree help in reversing actions performed as
part of the attack.
 O.ID_AUTH
Authentication mechanisms complicates a masquerade attack.
 O.REUSE.
Managed reuse of resources prevents attackers from being able to retrieve information that later can be
used in a masquerade attack.
TT.MONITORING
Objectives covering this threat:
 OE.NETWORK
Monitoring by intercepting the network traffic between two distinct TOE locations is prevented through
cryptographic protection or physical barriers.
 OE.TRAF_SEPARATION
Monitoring of administrative traffic is significantly more difficult when traffic separation is implemented, as
only administrators will have access through the administrative network.
 NOE.PHYSICAL
Monitoring the physical assets of the TOE are prevented through physical access restrictions.
TT.REPLAY
Objectives covering this threat:
 O.ACCESS_HIST
The objective will ease the detection of successful replayed authentication attempts. The objective itself
does not perform detection of authentication replays; it only provides evidence for access. This evidence
must be crosschecked with authorized user.
 O.AUDIT
Auditing operations issued during a replay attack can help both in determining from where and by whom
the attack was launched. It may also to a certain degree help in reversing actions performed as part of
the attack.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 72 of 104
Copyright © THALES Norway AS
 O.CMD_LOG
Command log can be used to detect replay of administrative commands. Once detected it is
considerably easier to assign countermeasures for an attack.
 O.ID_AUTH
Because users need to be identified and authorized to perform security relevant action within the TOE
replaying information is made more difficult.
 O.REUSE
Proper reuse of resources prevents attackers from being able to retrieve information that can be
replayed.
 OE.NETWORK
Network protection measures prevents attackers from retrieving or injecting information.
 NOE.PHYSICAL
Physical protection of the TOE prevents attackers from being able to retrieving or injecting information.
TT.UNATTENDED
Objectives covering this threat:
 O.AUTO_LOGOUT
The objective provides means for minimizing the probability of someone finding an unattended session
as sessions are terminated automatically after a configurable period of user inactivity.
 O.ID_AUTH
Together with O.AUTO_LOGOUT this objective ensures that unattended sessions can be made
unavailable to unauthorized personnel.
TT.UNAUTH_ACCESS
Objectives covering this threat:
 O.ACCESS_HIST
The access history can help determining that unauthorized access has occurred. It can furthermore be
used to determine from where and by whom the unauthorized access was obtained.
 O.AUDIT
Audit logs can help determining that unauthorized access has occurred. It can furthermore be used to
determine from where and by whom the unauthorized access was obtained.
 O.CMD_ACL
Command ACLs provide means for restricting each user’s access to perform administrative actions.
Unauthorized access can be obtained by performing administrative actions that in turn provide access to
the system. Restricting access to administrative tasks reduces the likelihood for unauthorized
administrators gaining access to the TOE via intentional malicious TOE administration. Roles provide
default command ACLs.
 O.CMD_LOG
The command log can help determining that unauthorized access has occurred. It can furthermore be
used to determine from where and by whom the unauthorized access was obtained.
 O.DAC
The objective is to perform DAC in order to avoid unauthorized access. DAC is performed for access to
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 73 of 104
Copyright © THALES Norway AS
all database records. Initially this ensures that only the owner has access to records stored within the
table. It is furthermore possible to add an ACL to the table definition so that access for other entities can
be controlled.
 O.ID_AUTH
Requiring users to identify themselves and provide valid authentication tokens before being allowed
access to TOE assets prevents (in combination with O.DAC) unauthorized access to that information.
 O.LABELLING
The objective ensures that information is labelled, so that it can be handled according to its classification.
Improper handling of classified information may result in unauthorized access.
 O.LOCK
Locking the user account after a given number of logon attempts reduces the chances of a successful
brute force attack. The TOE will lock accounts after a configurable number of unsuccessful logon
attempts.
 O.MAC
The objective shall enforce the separation of data based on HCL, and NHC and SP. MAC is performed
whenever access to subjects and object is requested.
 O.MAC_INTEGRITY
In order to dynamically change clearance and sensitivity label, there must be functions to maintain this
information. Dynamic change of clearance and sensitivity labels is necessary because the authenticated
resources (e.g. users) change over time, and objects do not necessary have the same sensitivity label
over time. This security objective covers the need for functions to maintain the integrity of data used in
MAC so that unauthorized access based on old clearance/classification data is not given.
 O.MESSAGING
To ensure unambiguous and correct information security labelling the TOE rejects all security marks that
cannot be unambiguously converted into internal representation. Furthermore, the TOE rejects
messages that have security marks outside the restrictions set by the system configuration, which in turn
ensures that the system can only store information that it has clearance for.
 O.RECOVER
The objective is to preserve a state in case of a system failure, so that XOmail can perform secure
recovery and thereby avoid entering an insecure state allowing unauthorized access to TOE assets upon
start-up.
 O.ROLE_MNG
The objective shall ensure that roles and role-belongings can be managed so that role assignments can
be performed on an as-needed basis, and changed according to changing needs.
 O.ROLES
The roles contain predefined access restrictions for administrative tasks, thereby providing a default set
of available administrative commands. This reduces the chance of an attacker to successfully perform an
unauthorized administrative task, thereby allowing the attacker or a third party access to TOE assets.
 O.SELF_TEST
Performing a database self-test ensures that corrupt ownership, ACLs and security parameters do not
lead to unauthorized access to TOE assets.
 OE.AUDIT
The audit can help determining that unauthorized access has occurred. It can furthermore be used to
determine from where and by whom the unauthorized access was obtained.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 74 of 104
Copyright © THALES Norway AS
 OE.PLATFORM
By securing systems and applications that are tightly connected to the TOE, the risk of unauthorized
access to TOE information is reduced. In particular, the Central Archive platform and services needs to
be secured in order to protect archived messages from being disclosed.
 OE.NETWORK
The network protection prevents external sources from accessing the network connected to the TOE.
This in turn complicates the process of gaining unauthorized access to the TOE equipment and TOE’s
assets.
 NOE.PHYSICAL
The physical protection prevents external sources from accessing the computer equipment hosting the
TOE. This in turn complicates the process of gaining access to the TOE’s assets.
8.1.2 THREATS MET BY THE TOE ENVIRONMENT
TE.AUDIT_FAILURE
Objectives covering this threat:
 OE.AUDIT
The objective is to prevent audit records from being lost or modified.
TE.DELIVERY
Objectives covering this threat:
 NOE.INSTALL
Secure delivery routines can prevent attackers from compromising the TOE with viruses and other
malicious software. Secure operation of the TOE cannot be ensured if the TOE is tampered with before
being installed in a controlled environment.
TE.DOS
Objectives covering this threat:
 O.RECOVER
The objective covers recovery from an abnormal termination due to denial of service attacks on the OS
that the TOE runs on. It is ensured that the TOE does not enter an unsecure state upon startup.
 OE.AUDIT
The audit can be used to detect possible DOS attacks so that proper measures can be applied in an
early stage of the attack.
 OE.NETWORK
The objective reduces the possibility for DOS attacks met by the TOE host as it becomes more difficult to
send data to the host. The network protection will to a certain degree prevent external sources from
accessing the computer equipment hosting the TOE.
 NOE.PHYSICAL
The objective reduces the possibility for DOS attacks met by the TOE environment as it becomes more
difficult to send data resulting in TOE environment resource exhaustion. The physical protection will to a
certain degree prevent unauthorized sources from accessing the computer equipment hosting the TOE,
thereby complicating the DOS attack. Channels other that physical attack must be used.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 75 of 104
Copyright © THALES Norway AS
TE.IMPROPER_INST
Objectives covering this threat:
 NOE.ADM_TRUST
The administrator must be trusted to install the TOE correctly. The objective addresses the need for
administrators that in a correct and secure manner performs proper installation of the TOE.
 NOE.INSTALL
The objective seeks to eliminate improper installation and improper initial configuration of the TOE.
TE.POOR_DESIGN
Objectives covering this threat:
 OE.NETWORK
The objective ensures that only trusted personnel have access to the TOE, thereby reducing the set of
possible threat agents.
 OE.TRAF_SEPARATION
Separating different types of network traffic reduces the set of threat agents being able to exploit
potential flaws.
 NOE.PHYSICAL
The objective ensures that only trusted personnel have access to the TOE, thereby reducing the set of
possible threat agents.
TE.POOR_IMPL
Objectives covering this threat:
 O.RECOVER
The objective covers recovery from an abnormal termination due to implementation errors in the TOE. It
is ensured that the TOE does not enter an insecure state upon start-up.
 OE.NETWORK
The objective ensures that only trusted personnel have access to the TOE, thereby reducing the set of
possible threat agents.
 OE.TRAF_SEPARATION
Separating different types of network traffic reduces the set of threat agents being able to exploit
potential flaws.
 NOE.PHYSICAL
The objective ensures that only trusted personnel have access to the TOE, thereby reducing the set of
possible threat agents.
TE.UNATTENDED
Objectives covering this threat:
 OE.AUDIT
The audit can help determining that access via unattended sessions has occurred. It can furthermore be
used to determine from where and by whom the access was obtained.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 76 of 104
Copyright © THALES Norway AS
 NOE.PHYSICAL
The objective addresses the need for the physical protection of the TOE environment to avoid
exploitation of an unattended session.
8.1.3 ASSUMPTIONS
A.ADM_TRAINING
Objectives covering this assumption:
 OE.ACCOUNTABLE
All administrator shall be aware that they are accountable for their actions. Consequently the
administrators must bear in mind his/her responsibilities at all time during administration of the TOE.
 NOE.INSTALL
Secure installation, management and operation of the TOE require administrators to be properly trained.
A.ARCHIVE_DB
Objectives covering this assumption:
 OE.NETWORK
The objective ensures security for information transmitted between the TOE and the Central Archive
Database Server when these are not located on the same physical hardware.
 OE.PLATFORM
The objective ensures that the Central Archive database is securely configured and managed.
A.AUDIT_REVIEW
Objectives covering this assumption:
 OE.ACCOUNTABLE
Holding users of the TOE accountable for their actions means that the audit must be regularly, reviewed
to detect inconsistencies or abnormal patterns and traces.
 NOE.INSTALL
Administrators perform audit reviews.
A.CONFIDENCE
Objectives covering this assumption:
 NOE.ADM_TRUST
The objective ensures trustworthy administrators which results in confidence that the system will not
intentionally be misconfigured.
A.INVALIDATE
Objectives covering this assumption:
 NOE.ADM_TRUST
Trust in administrative personnel is essential to ensure proper invalidation of authentication data.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 77 of 104
Copyright © THALES Norway AS
 NOE.INSTALL
Keeping user access updated is an integral part of the secure management of the TOE.
A.NETWORK
Objectives covering this assumption:
 OE.NETWORK
The objective ensures that protection of the network that TOE use for communication, is pointed out as a
responsibility of the TOE owners.
 OE.TRAF_SEPARATION
The objective provides additional protection for TOE management traffic.
A.NOTIFY
Objectives covering this assumption:
 NOE.INSTALL
Handling security issues are required for the secure management and operation of the TOE.
A.PHYSICAL
Objectives covering this assumption:
 NOE.PHYSICAL
The TOE owners are responsible for implementing and maintaining sufficient physical protection for the
system.
A.PHYSICAL_LOC
Objectives covering this assumption:
 NOE.PHYSICAL
The TOE owners are responsible for restricting access to the areas where XOmail is used.
A.OS
Objectives covering this assumption:
 O.ID_AUTH
The identification and authentication mechanisms of the TOE rely on basic mechanisms in the OS.
Authentication tokens are only defined and protected by the OS, and the TOE shall not be able to
maintain identities that do not exist in the OS.
 OE.AUDIT
The objective describes use of OS audit mechanisms to store auditable events performed by the TOE.
 OE.ID_AUTH
The objective identifies the need for user identification and authentication in the OS that the TOE runs
on. The assumption A.OS covers this, as the OS need to be evaluated.
 OE.NETWORK
The objective identifies the need for protection of network communication. The OS may provide lower
layer protocol security mechanisms.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 78 of 104
Copyright © THALES Norway AS
 OE.PLATFORM
The objective identifies the need for securely configuring and managing the platform the TOE runs on.
A.USR_TRAINING
Objectives covering this assumption:
 OE.ACCOUNTABLE
All users shall be aware that they are accountable for their actions. Consequently the users must bear in
mind their responsibilities at all time during administration of the TOE.
 NOE.INSTALL
The secure management and operation of the TOE requires users to be properly trained.
A.TIME_SOURCE
Objectives covering this assumption:
 OE.TIME_SOURCE
The OE provides a reliable time source for use by the TOE.
8.1.4 POLICIES
P.ACCOUNTABILITY
The objective of the policy for accounting is to provide sufficient information to be able to investigate a
deliberate or accidental compromise of accountable information and assess the damage arising from the
compromise. This calls for a unique identification of the users (O.ID_AUTH, OE.ACCOUNTABLE) and
logging of sensitive events (O.ACCESS_HIST, O.AUDIT, O.CMD_LOG, OE.AUDIT). The user identification
will appear in the log records.
P.CLASSIFICATION
The classification of information is done by the originator (O.MAC).
P.CLEAR
The CLEAR procedures allows exceptions in the mandatory access control mechanisms (O.MAC) for
authorised users to send classified messages in clear on unsecure lines.
P.DAC
The TOE ensures Discretionary Access Control (O.DAC) by controlling access to resources based on the
identity of users and groups of users.
P.INTEGRITY
The TOE shall be able to ensure integrity of message data (O.MSG_INTEGRITY, OE.NETWORK, OE.PKI).
P.INTERFACE_CONTROL
The TOE, the host computer and computer network must be installed and configured in accordance with the
policy for the system (NOE.INSTALL).
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 79 of 104
Copyright © THALES Norway AS
P.MAC
The TOE ensures Mandatory Access Control (O.MAC) based on user clearances and object security
classifications.
The TOE allows authorized security administrators (O.ROLES) to specify the security clearance of users and
resources (O.MAC_INTEGRITY).
P.MARKING
The TOE ensures that information is labelled with the correct human-readable label (O.LABELLING).
P.PROTECTION
Those responsible for the TOE will ensure that the TOE is installed, managed and operated in a manner that
maintains security (NOE.INSTALL, NOE.PHYSICAL), that network communication to/from the TOE is
protected (OE.NETWORK), and that the operating system and services tightly connected to the TOE is
appropriately protected (OE.PLATFORM).
8.2 SECURITY REQUIREMENTS RATIONALE
8.2.1 REQUIREMENTS ARE APPROPRIATE
The following table (Table 8-5) show that requirements are appropriate to cover TOE security objectives.
Objective
O.ACCESS_HIST
O.AUDIT
O.AUTO_LOGOUT
O.CMD_ACL
O.CMD_LOG
O.DAC
O.FLASH
O.ID_AUTH
O.LABELLING
O.LOCK
O.MAC
O.MAC_INTEGRITY
O.MANAGE
O.MESSAGING
O.MSG_INTEGRITY
O.RECOVER
O.REUSE
O.ROLE_MNG
O.ROLES
O.SELF_TEST
O.SCHEDULING
Req
.
FAU_ARP.1 X X
FAU_GEN.1 X X
FAU_GEN.2 X X
FAU_SAA.1 X
FAU_SAR.1 X
FAU_SAR.2 X
FAU_STG.1 X
FAU_STG.3 X
FAU_STG.4 X
FCO_NRO.1 X
FCO_NRR.1 X
FCS_COP.1 X
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 80 of 104
Copyright © THALES Norway AS
Objective
O.ACCESS_HIST
O.AUDIT
O.AUTO_LOGOUT
O.CMD_ACL
O.CMD_LOG
O.DAC
O.FLASH
O.ID_AUTH
O.LABELLING
O.LOCK
O.MAC
O.MAC_INTEGRITY
O.MANAGE
O.MESSAGING
O.MSG_INTEGRITY
O.RECOVER
O.REUSE
O.ROLE_MNG
O.ROLES
O.SELF_TEST
O.SCHEDULING
Req
.
FDP_ACC.2 X X
FDP_ACF.1 X X X
FDP_ETC.2 X X X
FDP_IFC.2 X X
FDP_IFF.2 X X
FDP_ITC.2 X X
FDP_RIP.2 X
FDP_UIT.1 X
FIA_AFL.1 X
FIA_ATD.1 X X X
FIA_UAU.2 X X X
FIA_UAU.5 X
FIA_UAU.6 X X
FIA_UID.2 X X X
FIA_USB.1 X X X
FMT_MSA.1 X X X
FMT_MSA.3 X
FMT_MTD.1 X
FMT_SMF.1 X X
FMT_SMR.1 X X
FPT_FLS.1 X
FPT_RCV.1 X
FPT_RCV.2 X X
FPT_RCV.4 X
FPT_TDC.1 X X
FPT_TST.1 X
FRU_FLT.2 X
FRU_PRS.1 X X
FTA_SSL.3 X
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 81 of 104
Copyright © THALES Norway AS
Objective
O.ACCESS_HIST
O.AUDIT
O.AUTO_LOGOUT
O.CMD_ACL
O.CMD_LOG
O.DAC
O.FLASH
O.ID_AUTH
O.LABELLING
O.LOCK
O.MAC
O.MAC_INTEGRITY
O.MANAGE
O.MESSAGING
O.MSG_INTEGRITY
O.RECOVER
O.REUSE
O.ROLE_MNG
O.ROLES
O.SELF_TEST
O.SCHEDULING
Req
.
FTA_TSE.1 X X
Table 8-5: Security objectives satisfaction
8.2.1.1 O.ACCESS_HIST
Requirements covering this objective:
 FAU_GEN.1
The TOE is required to maintain an access history list i.e. a list of successful and unsuccessful session
establishment attempts. Authorized administrators may access this list.
 FAU_GEN.2
The TOE associates user identities for the events.
Note: If the username is unknown to the system, it should not be logged in order to prevent unintentional
logging of user password.
8.2.1.2 O.AUDIT
Requirements covering this objective:
 FAU_GEN.1
The TOE is responsible for recording audit data or initiating OS audit system calls when auditable events
occur within the TSC.
 FAU_GEN.2
The TOE provides user identities for events. The user identity for each event conforms to the owner of
the software process that caused the event. When TOE audit mechanisms are initiated, the user identity
must be specified by the TOE.
 FAU_SAA.1
The audit records are required by the TSF self-monitoring introduced by this requirement.
 FAU_SAR.1
The TOE audit must be possible to read and interpret for the authorized TOE administrators.
 FAU_SAR.2
It must be possible to restrict access to the audit so that only authorized TOE administrators are allowed
access.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 82 of 104
Copyright © THALES Norway AS
 FAU_STG.1
The audit must be protected against unauthorized deletion or modification.
 FAU_STG.3
The TOE issues alarms to ensure that administrators are warned before the audit storage is exhausted.
 FAU_STG.4
The TOE implements means to ensure that auditing is always available as long as the system is running.
 FPT_RCV.1
If the audit trail storage is exhausted, the TOE will shut down to preserve a secure state.
8.2.1.3 O.AUTO_LOGOUT
Requirements covering this objective:
 FTA_SSL.3.
The TOE is responsible for providing mechanisms that are capable of automatically terminate sessions
after a configurable period of user inactivity.
 FIA_USB.1
The TOE is responsible for automatic logout of the user when the user clearance or user command
access has been changed.
8.2.1.4 O.CMD_ACL
Requirements covering this objective:
 FDP_ACF.1.
For the TOE to be able to restrict access to commands based on user identity, the DAC mechanisms
must be implemented.
 FIA_UAU.2.
For the TOE to be able to restrict access to administrative commands, it must require all users to identify
and authenticate themselves before access to administrative functions can be given. The FIA_UAU.2
ensures that authentication is performed before users are given access to administrative commands.
 FIA_UID.2.
For the TOE to be able to enforce the ACL for administrative commands, each administrator must be
identified before performing any other action. The identification is used to determine whether the user is
allowed to perform the command.
 FIA_USB.1
Command access restrictions rely heavily on the TOE’s ability to associate user identity with subjects
acting on behalf of users. Accordingly, FIA_USB.1 is necessary for correct command access restriction
functionality.
 FMT_MSA.1
The requirement restricts access to the management of command ACLs. Only security administrators
are allowed to change the command ACLs of user templates.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 83 of 104
Copyright © THALES Norway AS
8.2.1.5 O.CMD_LOG
Requirements covering this objective:
 FIA_UAU.2.
In order to perform recording of administrative commands and associate user identification with each of
the records, all users must identify and authenticate. The FIA_UAU.2 ensures authentication of all users
before administrative commands can be performed.
 FIA_UID.2.
Each entry in the command log must be associated with the user that caused the command. Therefore it
is necessary for administrators to identify themselves before any other action is performed.
 FIA_USB.1.
Command log functionality relies heavily on the TOE’s ability to associate user identity with subjects
acting on behalf of users. Accordingly, FIA_USB.1 is necessary for correct command log functionality.
8.2.1.6 O.DAC
Requirements covering this objective:
 FDP_ACC.2.
Requires DAC to be performed on database objects and database subjects.
 FDP_ACF.1.
Specifies how DAC shall be applied on database objects and database subjects.
 FDP_ETC.2.
Requires the TOE to perform DAC during export to outside the TSC.
 FDP_ITC.2.
Requires the TOE to perform DAC during import from outside the TSC.
 FIA_ATD.1.
Requires security attributes to be maintained for each individual user. Some of the security attributes are
necessary for DAC operation.
 FTA_TSE.1
Requires the TOE to perform DAC based on the client host address, and authentication tokens.
8.2.1.7 O.FLASH
Requirements covering this objective:
 FRU_PRS.1.
Ensures that FLASH messages are given priority above other message traffic.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 84 of 104
Copyright © THALES Norway AS
8.2.1.8 O.ID_AUTH
Requirements covering this objective:
 FIA_UAU.2.
Ensures that unauthorized users are not given access to the TOE’s assets.
 FIA_UAU.5.
Specifies authentication methods that shall be present in the TOE.
 FIA_UAU.6.
Requires administrators to reauthenticate themselves if this is required to perform an administrative
command. Allows administrators to force any user or administrator to reauthenticate.
 FIA_UID.2.
FIA_UID.2 allows the user to receive an error message upon failed identification before being
successfully identified. The error message reveals no assets, nor will it give assistance in finding a
correct identification.
8.2.1.9 O.LABELLING
Requirements covering this objective:
 FDP_ETC.2.
Upon export outside TSC information is labelled with a human-readable label representation of
internal information label.
8.2.1.10 O.LOCK
Requirements covering this objective:
 FAU_ARP.1
The requirement implements automatic lockout of users upon selected potential security violations.
 FIA_AFL.1.
Describes the conditions for automatic locking of user accounts (setting of the lock-attribute).
 FTA_TSE.1.
The TOE is required to be able to deny users access based on a lock-attribute.
8.2.1.11 O.MAC
Requirements covering this objective:
 FDP_ETC.2.
Requires the TOE to perform MAC during export to outside the TSC.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 85 of 104
Copyright © THALES Norway AS
 FDP_IFC.2.
Requires MAC to be performed on all non-trusted subjects and all information.
 FDP_IFF.2.
Describes how MAC and MAC support-functions shall be realized. The TOE is required to ensure that
access to resources is given based on clear rules for clearance and label comparison.
 FDP_ITC.2.
Requires the TOE to perform MAC during import from outside the TSC.
 FIA_ATD.1.
Requires security attributes to be maintained for each individual user. Some of the security attributes are
necessary for MAC operation.
 FPT_TDC.1.
The TOE’s ability to perform MAC correctly relies on its ability to assign object label and subject
clearance upon importing data from other trusted IT products. FPT_TDC.1 addresses the requirements
that ensure TSF data consistency.
8.2.1.12 O.MAC_INTEGRITY
Requirements covering this objective:
 FMT_MSA.1.
The TOE is required to enforce MAC and DAC to restrict the ability to read or write object and subject
security attributes. This in turn ensures that unauthorized personnel cannot violate the integrity of the
MAC security attributes.
 FMT_MSA.3.
The TOE is required to provide default values for security attributes and additionally let Security
Administrators override the default settings. This allows Security Administrator to maintain integrity of
MAC security attributes.
 FMT_SMF.1.
Management functions that ensure integrity of MAC security attributes must be well defined.
8.2.1.13 O.MANAGE
Requirements covering this objective:
 FIA_UAU.6
Specifies that administrators may be required to reauthenticate to perform specific administrative
commands when required by the configured security policy.
 FMT_MSA.1.
Enforcing MAC and DAC to restrict ability to modify security attributes support secure and error free
management.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 86 of 104
Copyright © THALES Norway AS
 FMT_MTD.1.
Being able to allow only administrators to read or write TOE configuration data minimises the effort
necessary for TOE owners to accomplish secure and effective management of the TOE.
 FMT_SMF.1.
Management functions that ensure secure, efficient and accurate management of the TOE must be well
defined.
8.2.1.14 O.MESSAGING
Requirements covering this objective:
 FDP_ACC.2.
Enforcing DAC ensures that message can be created, viewed, modified or deleted only by those
explicitly granted access to the TOE.
 FDP_ACF.1.
The DAC mechanisms must be implemented as specified in this requirement in order to have it applied
to the message handling.
 FDP_IFC.2.
Enforcing MAC ensures that message can be created, viewed, modified or deleted only by those
explicitly granted clearance for that type of information.
 FDP_IFF.2.
The MAC mechanisms must be implemented as specified in this requirement in order to have it applied
to the message handling.
 FPT_TDC.1.
The requirements in FPT_TDC.1 ensure that the TOE must reject all messages that do not have a valid
security mark that can be verified against internal rules.
8.2.1.15 O.MSG_INTEGRITY
Requirements covering this objective:
 FDP_UIT.1
The TOE is able to digitally sign messages to allow separate instances of the TOE or third party MMHS
implementations to verify the integrity of the transmitted messages. The TOE is able to verify the integrity
of digitally signed messages exchanged between separate TOEs or the TOE and other MMHS products.
 FCO_NRO.1
The TOE is able to generate proof of origin through the use of digital signatures.
 FCO_NRR.1
The TOE is able to generate proof of receipt through the use of digital signatures.
 FCS_COP.1
The TOE generates message digests to support the above SFRs.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 87 of 104
Copyright © THALES Norway AS
8.2.1.16 O.RECOVER
Requirements covering this objective:
 FAU_ARP.1
The TOE performs automated recovery actions upon detection of potential security violations.
 FPT_FLS.1.
The TOE is required to preserve a secure state in the case of any failure. The preserved secure state
can later be used to recover from the failure.
 FPT_RCV.2
This requirement ensures that automated recovery is performed, and that the TOE does not start in an
insecure state.
 FPT_RCV.4
This requirement ensures that TSF shall either succeed and enter a new secure state, or fail and return
to another secure state.
 FRU_FLT.2
The TOE is able to recover from software faults.
8.2.1.17 O.REUSE
Requirements covering this objective:
 FDP_RIP.2
Ensures that all informational content of a resource is unrecoverable upon reuse of that resource.
8.2.1.18 O.ROLE_MNG
Requirements covering this objective:
 FMT_SMR.1
Defines requirements to the TOE on how the roles shall be managed.
8.2.1.19 O.ROLES
Requirements covering this objective:
 FIA_ATD.1
Requires the TOE to use roles.
 FMT_SMR.1
Defines the roles that the TOE shall maintain and associate users with.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 88 of 104
Copyright © THALES Norway AS
8.2.1.20 O.SELF_TEST
Requirements covering this objective:
 FPT_RCV.2
The TOE is required to evaluate the need for, and if needed perform an automated recovery upon start-
up.
 FPT_TST.1.
The TOE is required to run a database integrity check during start-up.
8.2.1.21 O.SCHEDULING
 FRU_PRS.1.
The TOE associates priority attributes with all TOE internal communication, based on message
precedence levels to ensure correct scheduling according to priority.
8.2.2 FUNCTIONAL SECURITY REQUIREMENTS DEPENDENCIES
The table shows each component’s direct dependencies to other components. This demonstrates that the
set of security requirements form a mutually supportive and consistent whole.
TOE Requirement Dependency Included
FAU_ARP.1 FAU_SAA.1 Yes
FAU_GEN.1 FPT_STM.1 No
FAU_GEN.2 FAU_GEN.1, FIA_UID.1 (via
FIA_UID.2)
Yes
FAU_SAA.1 FAU_GEN.1 Yes
FAU_SAR.1 FAU_GEN.1 Yes
FAU_SAR.2 FAU_SAR.1 Yes
FAU_STG.1 FAU_GEN.1 Yes
FAU_STG.3 FAU_STG.1 Yes
FAU_STG.4 FAU_STG.1 Yes
FDP_ACC.2 FDP_ACF.1 Yes
FDP_ACF.1. FDP_ACC.1, FMT_MSA.3 Yes
FDP_ETC.2 FDP_ACC.1, FDP_IFC.1 Yes
FDP_IFC.2 FDP_IFF.1 Yes
FDP_IFF.2 FDP_IFC.1, FMT_MSA.3 Yes
FDP_ITC.2 FDP_ACC.1, FDP_IFC.1, FPT_TDC.1,
(FTP_ITC.1 or FTP_TRP.1)
No
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 89 of 104
Copyright © THALES Norway AS
TOE Requirement Dependency Included
FDP_RIP.2 N/A
FDP_UIT.1 FDP_ACC.1 or FDP_IFC.1 (both
included)
FTP_ITC.1 is not included, as the
trusted channel is the responsibility of
the TOE Environment
(OE.NETWORK).
Partial
FIA_AFL.1 FIA_UAU.2 Yes
FIA_ATD.1 N/A
FIA_UAU.2 FIA_UID.1 (via FIA_UID.2) Yes
FIA_UAU.5 N/A
FIA_UAU.6 N/A
FIA_UID.2 N/A
FIA_USB.1 FIA_ATD.1 Yes
FMT_MSA.1 FDP_ACC.1, FDP_IFC.1,
FMT_SMF.1, FMT_SMR.1
Yes
FMT_MSA.3 FMT_MSA.1, FMT_SMR.1 Yes
FMT_MTD.1 FMT_SMF.1, FMT_SMR.1 Yes
FMT_SMF.1 Yes
FMT_SMR.1 FIA_UID.1 (via FIA_UID.2) Yes
FPT_FLS.1 N/A
FPT_RCV.1 AGD_OPE.1 Yes
FPT_RCV.2 AGD_OPE.1 Yes
FPT_RCV.4 N/A
FPT_TDC.1 N/A
FPT_TST.1 (FPT_AMT.1) No
FRU_FLT.2 FPT_FLS.1 Yes
FRU_PRS.1 N/A
FTA_SSL.3 N/A
FTA_TSE.1 N/A
Table 8-6: Functional requirements dependency check
Dependencies are met with the following exceptions:
FAU_GEN.1 depends on FPT_STM.1 to provide reliable timestamps. This service is provided by the TOE
Environment through the Operating System, fulfilled by OE.TIME_SOURCE.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 90 of 104
Copyright © THALES Norway AS
FDP_ITC.2 specifies that either FTP_ITC.1 or FTP_TRP.1 must be present. Given that only OS-
authenticated users can perform import, the physical protection of the TOE environment, and the integrity
protection of the network, none of these requirements are considered necessary for secure operation.
FPT_TST.1 specifies that FPT_AMT.1 must be present. This dependency is not considered necessary to
fulfil as the OS provides an abstract machine that can be used. The OS performs abstract machine testing.
8.2.3 TOE SECURITY ASSURANCE REQUIREMENTS RATIONALE
The TOE meets the assurance requirements for EAL4 augmented by ALC_FLR.3.
The TOE stresses assurance from best practice development practices. Through review of vendor-supplied
evidence and independent testing the Assurance Requirements confirm the implementation of these
practices.
The selected assurance level ensures the TOE fulfills national requirements for use in military and
governmental networks, handling and separating information as specified in the TOE Overview and TOE
Description. In particular, mediation of information flow between national, international and inter-
organizational security domains operating at equal or similar sensitivity levels, such as national SECRET,
NATO SECRET and Mission SECRET.
8.3 TOE SUMMARY SPECIFICATION RATIONALE
8.3.1 TOE SECURITY FUNCTIONAL REQUIREMENTS SATISFACTION
This chapter demonstrates that the TOE Security Functions completely implement the TOE Security
Functional Requirements.
Table 8-7 shows that each Security Functional Requirement is covered by at least one TOE Security
Function and vice versa.
The table is followed by a rationale demonstrating that each SFR is completely implemented by one or more
TSFs.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 91 of 104
Copyright © THALES Norway AS
Security
function
SF.AUDIT
SF.AUTHENTICATION
SF.AUTO_LOGOUT
SF.CLEAR
SF.COMMAND_ACCESS
SF.COMMUNICATION_SECURIT
Y
SF.DAC
SF.DB_SELF_TEST
SF.EXECUTION_DOMAIN
S
SF.MESSAGE_INTEGRITY
SF.LABELLING
SF.LABEL_TRANSFORM
SF.LOCK
SF.MAC
SF.PRIORITY
SF.ROLES
SF.SECURE_STATE_RECOVER
Y
SF.SUBNET_RESTRICTION
SF.VALIDATE
Req.
FAU_ARP.1 X
FAU_GEN.1 X
FAU_GEN.2 X
FAU_SAA.1 X
FAU_SAR.1 X X X
FAU_SAR.2 X X X
FAU_STG.1 X X X
FAU_STG.3 X
FAU_STG.4 X
FCO.NRO.1 X
FCO_NRR.1 X
FCS_COP.1 X
FDP_ACC.2 X
FDP_ACF.1 X
FDP_ETC.2 X X X
FDP_IFC.2 X
FDP_IFF.2 X X
FDP_ITC.2 X X X X
FDP_RIP.2 X
FDP_UIT.1 X X
FIA_AFL.1 X
FIA_ATD.1 X
FIA_UAU.2 X
FIA_UAU.5 X
FIA_UAU.6 X X
FIA_UID.2 X
FIA_USB.1 X X
FMT_MSA.1 X X X
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 92 of 104
Copyright © THALES Norway AS
Security
function
SF.AUDIT
SF.AUTHENTICATION
SF.AUTO_LOGOUT
SF.CLEAR
SF.COMMAND_ACCESS
SF.COMMUNICATION_SECURIT
Y
SF.DAC
SF.DB_SELF_TEST
SF.EXECUTION_DOMAIN
S
SF.MESSAGE_INTEGRITY
SF.LABELLING
SF.LABEL_TRANSFORM
SF.LOCK
SF.MAC
SF.PRIORITY
SF.ROLES
SF.SECURE_STATE_RECOVER
Y
SF.SUBNET_RESTRICTION
SF.VALIDATE
Req.
FMT_MSA.3 X X
FMT_MTD.1 X
FMT_SMF.1 X
FMT_SMR.1 X
FPT_FLS.1 X
FPT_RCV.1 X X
FPT_RCV.2 X
FPT_RCV.4 X
FPT_TDC.1 X X
FPT_TST.1 X X
FRU_FLT.2 X
FRU_PRS.1 X
FTA_SSL.3 X
FTA_TSE.1 X X X
Table 8-7: Functional requirements satisfaction
8.3.1.1 FAU_ARP.1
This requirement is enforced by the following security functions:
 SF.SECURE_STATE_RECOVERY
The TOE performs recovery actions upon detection of potential security violations.
8.3.1.2 FAU_GEN.1
This requirement is enforced by the following security functions:
 SF.AUDIT
The TOE audit trail satisfies the FAU_GEN.1 list of auditable events.
8.3.1.3 FAU_GEN.2
This requirement is enforced by the following security functions:
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 93 of 104
Copyright © THALES Norway AS
 SF.AUDIT
The TOE is required to associate a user identity with all audit records where applicable.
8.3.1.4 FAU_SAA.1
This requirement is enforced by the following security functions:
 SF.AUDIT
The TOE can be configured for each alarm type to raise an alarm when successive alarm events occur
in a configurable period.
8.3.1.5 FAU_SAR.1
This requirement is enforced by the following security functions:
 SF.AUDIT
The TOE allows the audit information to be read by authorized and sufficiently cleared administrators.
 SF.DAC
The audit logs stored in the XOmail database is protected by DAC. This will enable authorised users to
read audit records.
 SF.MAC
The audit logs stored in the XOmail database is protected by MAC. This will enable authorised users to
read audit records for which the user has proper clearance.
8.3.1.6 FAU_SAR.2
This requirement is enforced by the following security functions:
 SF.AUDIT
The TOE restricts audit information to authorized administrators.
 SF.DAC
The audit logs stored in the XOmail database is protected by DAC. This will ensure that only authorised
users get read access to audit records.
 SF.MAC
The audit logs stored in the XOmail database is protected by MAC. This will ensure that users only get
read access according to the users clearance and the audit records security classification.
8.3.1.7 FAU_STG.1
This requirement is enforced by the following security functions:
 SF.AUDIT
The TOE protects audit records from modification and unauthorized deletion.
 SF.DAC
The audit logs stored in the XOmail database is protected by DAC. This will ensure that only authorised
users get delete access to audit records.
 SF.MAC
The audit logs stored in the XOmail database is protected by MAC. This will ensure that users only get
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 94 of 104
Copyright © THALES Norway AS
delete access according to the users clearance and the audit records security classification.
8.3.1.8 FAU_STG.3
This requirement is enforced by the following security functions:
 SF.AUDIT
The TOE will issue alarms to warn the system administrators when the audit storage nears exhaustion.
8.3.1.9 FAU_STG.4
This requirement is enforced by the following security functions:
 SF.AUDIT
The TOE will suspend the operation when audit trail is full i.e. the hard disk is full.
8.3.1.10 FCO_NRO.1
 SF.MESSAGE_INTEGRITY
The TOE supports non-repudiation of origin for the specified messaging protocols.
8.3.1.11 FCO_NRR.1
 SF.MESSAGE_INTEGRITY
The TOE supports non-repudiation of receipt for the specified messaging protocols.
8.3.1.12 FCS_COP.1
This requirement is enforced by the following security functions:
 SF.MESSAGE_INTEGRITY
The TOE generates message digests using the specified algorithms.
8.3.1.13 FDP_ACC.2
This requirement is enforced by the following security functions:
 SF.DAC
The TOE is required to apply DAC within the TSC.
8.3.1.14 FDP_ACF.1
This requirement is enforced by the following security functions:
 SF.DAC
The requirement describes how DAC shall be applied.
8.3.1.15 FDP_ETC.2
This requirement is enforced by the following security functions:
 SF.DAC
The TOE is required to apply DAC during export of information from the TSC.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 95 of 104
Copyright © THALES Norway AS
 SF.LABEL_TRANSFORM
The TOE is required to convert internal label representation to a representation that unambiguously can
be associated with the exported data. The exported representation is defined by the export medium.
 SF.MAC
The TOE is required to apply MAC during export of information from the TSC.
8.3.1.16 FDP_IFC.2
This requirement is enforced by the following security functions:
 SF.MAC
The TOE is required to apply MAC within the TSC.
8.3.1.17 FDP_IFF.2
This requirement is enforced by the following security functions:
 SF.CLEAR
Requires the TOE to allow CLEAR-marking of information. The requirements of FDP_IFF.2 specify how
to handle CLEAR-marked information.
 SF.MAC
The requirements specify how MAC shall be applied.
8.3.1.18 FDP_ITC.2
This requirement is enforced by the following security functions:
 SF.DAC
The TOE is required to apply DAC during import of information into the TSC.
 SF.LABELLING
The TOE is required to assign a label during import of information into the TSC if correct label cannot be
determined. This security function covers cases where either label is not readable, or where label does
not exist.
 SF.LABEL_TRANSFORM
The TOE is required to ensure that interpretation of security label information is as intended by the
source of the user data. This covers potentially converting the label information into the internal
representation.
 SF.MAC
The TOE is required to apply MAC during import of information into the TSC.
8.3.1.19 FDP_RIP.2
This requirement is enforced by the following security functions:
 SF.EXECUTION_DOMAINS.
Different execution domains may over time reuse system resources. It is therefore necessary that
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 96 of 104
Copyright © THALES Norway AS
information is made unavailable upon allocation of all new system resources. FDP_RIP.2 specifies such
requirements for the TOE.
8.3.1.20 FDP_UIT.1
This requirement is enforced by the following security functions:
 SF.AUDIT.
The security function performs auditing of message traffic (i.e. “use of the data exchange mechanism”).
 SF.MESSAGE_INTEGRITY.
The security function provides integrity verification of specific message types and generates the
necessary verification data for sent messages.
8.3.1.21 FIA_AFL.1
This requirement is enforced by the following security functions:
 SF.LOCK.
Requirements for account locking are specified in the FIA_AFL.1.
8.3.1.22 FIA_ATD.1
This requirement is enforced by the following security functions:
 SF.AUTHENTICATION.
The authentication mechanism shall assign security attributes to the user’s subjects. FIA_ATD.1
specifies the security attributes available to the authentication mechanism.
8.3.1.23 FIA_UAU.2
This requirement is enforced by the following security functions:
 SF.AUTHENTICATION.
Users are required to be authenticated.
8.3.1.24 FIA_UAU.5
This requirement is enforced by the following security functions:
 SF.AUTHENTICATION
FIA_UAU.5 specifies how the authentication mechanisms shall work.
8.3.1.25 FIA_UAU.6
This requirement is enforced by the following security functions:
 SF.AUTHENTICATION
FIA_UAU.6 specifies when reauthentication may be triggered.
 SF.COMMAND_ACCESS
FIA_UAU.6 specifies requirements for command access ACLs.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 97 of 104
Copyright © THALES Norway AS
8.3.1.26 FIA_UID.2
This requirement is enforced by the following security functions:
 SF.AUTHENTICATION
FIA_UID.1 specifies when the TOE shall require the users to identify themselves.
8.3.1.27 FIA_USB.1
This requirement is enforced by the following security functions:
 SF.DAC
For the TOE to be able to perform DAC, it is required that user identity of subjects acting on behalf of
users have the correct user security attributes associated. This is part of the DAC functionality; user
identity must be associated with all subjects acting on behalf of a user.
 SF.MAC
Requirements defined in FIA_USB.1 ensure that the necessary security attributes for MAC functionality
are associated with the subjects acting on behalf of the users.
8.3.1.28 FMT_MSA.1
This requirement is enforced by the following security functions:
 SF.DAC
The TOE is required to apply DAC on the management functions for security attributes.
 SF.MAC
The TOE is required to apply MAC on the management functions for security attributes.
 SF.COMMAND_ACCESS
The SF provides management of administrators’ command access. Command access is restricted by an
administrator access level, as well as access to individual commands. Only Security Administrators are
allowed to manage command ACLs.
8.3.1.29 FMT_MSA.3
This requirement is enforced by the following security functions:
 SF.DAC
FMT_MSA.3 specifies how new objects and subjects shall be initialized with regards to security
attributes relevant for DAC functionality.
 SF.MAC
FMT_MSA.3 specifies how new objects and subjects shall be initialized with regards to security
attributes relevant for MAC functionality.
8.3.1.30 FMT_MTD.1
This requirement is enforced by the following security functions:
 SF.ROLES
The requirements describe how role belonging shall put restrictions on access to administrative tasks.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 98 of 104
Copyright © THALES Norway AS
8.3.1.31 FMT_SMF.1
The requirement enforces the following security functions:
 SF.AUDIT
The requirement defines the management functions for which execution must be logged.
8.3.1.32 FMT_SMR.1
This requirement is enforced by the following security functions:
 SF.ROLES
Requirements defining the available roles.
8.3.1.33 FPT_FLS.1
This requirement is enforced by the following security functions:
 SF.SECURE_STATE_RECOVERY
The TOE is required to preserve a secure state in the occurrence of a failure.
8.3.1.34 FPT_RCV.1
 SF.AUDIT
The security function ensures the TOE is shut down safely then the audit trail is full.
 SF.SECURE_STATE_RECOVERY
The security function ensures the system can be restarted when sufficient storage space has been made
available for the audit trail.
8.3.1.35 FPT_RCV.2
This requirement is enforced by the following security functions:
 SF.DB_SELF_TEST
This security function covers the automatic and manual recovery functions required by FPT_RCV.2.
8.3.1.36 FPT_RCV.4
This requirement is enforced by the following security functions:
 SF.SECURE_STATE_RECOVERY
This security function ensures that all SFs ends in a new secure state as required by FPT_RCV.4.
8.3.1.37 FPT_TDC.1
This requirement is enforced by the following security functions:
 SF.COMMUNICATION_SECURITY.
During sending and reception of messages, the TOE must handle security attributes according to the
requirements specified in the FPT_TDC.1.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 99 of 104
Copyright © THALES Norway AS
 SF.LABEL_TRANSFORM.
FPT_TDC.1 address requirements concerning the unambiguous representation of security labels and
the possibility to convert to/from internal representation.
8.3.1.38 FPT_TST.1
This requirement is enforced by the following security functions:
 SF.DB_SELF_TEST.
The requirements of FPT_TST.1 specify the features of the database self test.
 SF.VALIDATE.
The TOE is required to be able to perform validation of the TSF data and executable code.
8.3.1.39 FRU_FLT.2
This requirement is enforced by the following security functions:
 SF.SECURE_STATE_RECOVERY.
The TOE is able to recover from software faults.
8.3.1.40 FRU_PRS.1
This requirement is enforced by the following security functions:
 SF.PRIORITY.
The TOE ensures that all TOE internal communication is assigned a priority based on a user selected
precedence or . The TOE processes information based on its priority. The highest priority levels are
processed in part by dedicated resources to prevent delays.
8.3.1.41 FTA_SSL.3
This requirement is enforced by the following security functions:
 SF.AUTO_LOGOUT
The TOE is required to provide means for session termination after a period of user inactivity.
8.3.1.42 FTA_TSE.1
This requirement is enforced by the following security functions:
 SF.COMMUNICATION_SECURITY
Communications security is enforced with the requirements for the TOE to be able to restrict access
based on attributes defined in FTA_TSE.1.
 SF.LOCK
FTA_TSE.1 requires the TOE to be able to deny session establishment based on the lock attribute.
 SF.SUBNET_RESTRICTION
FTA_TSE.1 requires the TOE to be able to deny session establishment based on IP address, subnet
address or hostname of the client initiating the connection.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 100 of 104
Copyright © THALES Norway AS
8.4 PP RATIONALE
Not applicable
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 101 of 104
Copyright © THALES Norway AS
9. NOTES
9.1 NOTATION
The following notation is used for detailing Security Functional Requirements:
 Bold text is used for minor changes to the standard requirement text, to improve language or
readability.
 Italic text is used to show where assignments or selections have been made by the developer.
 Strikethrough is used to show where requirement text or irrelevant assignment text has been
removed from requirements.
Iteration of security requirements is done by adding an abbreviation to the requirement. The title of each
related chapter will contain a short description or reference. Example:
FMT_MTS.1/ADM Management of TSF Data (System Administrators)
FMT_MTD.1/SYS Management of TSF Data (System partition API)
9.2 ABBREVIATION AND ACRONYMS
Acronym Extended
ACL Access Control List
ACP Allied Communication Publication
ASN.1 Abstract Syntax Notation number One
B&L Bell & La Padula Security model
CCIS Command Control Information System
CM Configuration Management
CORBA Common Object Request Broker Architecture
COTS Commercial Off The Shelf
C4ISR Command, Control, Communications, Computers, Intelligence,
Surveillance and Reconnaissance
DAC Discretionary Access Control
DoS Denial Of Service
DMP Direct Message Profile
HCL Hierarchical Classification Level (e.g. RESTRICTED)
IEC International Electrotechnical Commission
ISO International Organization for Standardization
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
MAC Mandatory Access Control
MHS Message Handling System
MIP Multilateral Interoperability Programme
ML Multi-Level
MMHS Military Message Handling System
MTA Message Transfer Agent
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 102 of 104
Copyright © THALES Norway AS
NATO North Atlantic Treaty Organization
NHC Non-Hierarchical Category (e.g. CLEAR)
OS Operating System
SA Security Administrator
SFP Security Functional Policy
SIC Subject Indicator Code
SL Single Level
SMTP Simple Mail Transfer Protocol (RFC 5321)
SP Security Policy
SS Secure Storage
ST Security Target
STANAG NATO Standardization Agreement
TOE Target of Evaluation (defined in chapter 1.2)
TSC TSF Scope of Control
TSF TOE Security Functions
TSP TOE Security Policy
WAN Wide Area Network
Table 9-1 Acronyms
9.3 TERMINOLOGY
Admin Main Object The main configurable objects of the system. These objects are visible in the
top level of the administration client’s navigation tree for a given Message
Server.
Admin Object Configurable objects of the system. These objects are identified with leaves
in the static parts of the administration client’s navigation tree.
Administrator The least privileged administrator role. Can administer all parts of the TOE,
except for the Network Management parts, security parameters and Security
Administrator restricted User Templates. Administrator access can be further
limited using Command Access parameters in the User Template.
Clearance Each user is assigned a clearance indicating the maximum security
classification of information the user is allowed to access.
Client computer A computer running any the XOmail MS Client, XOmail Web Client, XOmail
Admin Client or XOmail Web Admin Client. The clients, the operating system
and the computer hardware/firmware are not part of the TOE.
Command Access ACLs for administrative commands. Access to each command can be
controlled on a per User Template basis.
FLASH message Informally: Covers messages with precedence levels FLASH and
OVERRIDE. Time-critical military message that must be delivered and
handled within defined time limits.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 103 of 104
Copyright © THALES Norway AS
Message precedence The military precedence level of a message conveys information from the
originator to the recipient and is used by the TOE to automatically select the
appropriate level of service. The following precedence levels are part of
STANAG 4406: [11, B.101]
 Override (highest)
 Flash
 Immediate
 Priority
 Routine
 Deferred (lowest)
MMHS Server An MMHS Server is a deployed instance of the TOE, connected to a
network. The MMHS Server consists of the TOE, the operating system, and
the hardware platform.
The XOmail clients and API applications may be co-located on the same
node as the XOmail Server, or access the TOE through the network.
The MMHS Server may also be deployed on a virtual machine.
Network Administrator Administrator with extended privileges compared to the Administrator role.
This role has access to administration of Network Management parameters.
Other than this, the same limitations are valid as for Administrator.
Non-resident processes Software processes that run temporarily during TOE operation.
Normal The ordinary user role. Users belonging to this role have no administrative
access.
XOmail System User The service account for the TOE. This is a non-administrative user defined
in the operating system as described in XOmail Installation and
Configuration Guide [1].
Primary Security
Administrator
Specialized administrator role intended for initial configuration of the TOE.
Can administer all parts of the TOE. Command access limitations will not be
applied.
Resident processes Software processes that are started during TOE start-up and remains
running until TOE shutdown.
Security Administrator The most privileged administrator role. Can administer all parts of the TOE.
Command access limitations can however be applied.
Security Attribute CC definition:
Characteristics of subjects, users, objects, information, and/or
resources that are used for the enforcement of the TSP.
XOmail context:
Subject and object HCLs, NHCs and SPs.
Single Level object Object that is able to handle information at a single security label equal to its
own security label.
Social engineering The use of persuasion and/or deception to gain access to information
systems.
Target of Evaluation
(TOE)
An IT product or system and its associated guidance documentation that is
the subject of an evaluation.
Classification
OPEN
Classification Document Title Radical – Business Id Revision DTC Language
Entity Cage
Code
Thales Cage
Code
PAGE
OPEN XOmail 22 Security Target 739 20802 SC
4-
public
305 EN N4244 0026 104 of 104
Copyright © THALES Norway AS
Template Upon creation all System Units are based on a template. The new System
Unit remains associated with a template during its whole lifetime, and some
attributes will remain pure template attributes. Templates must be created
for Users, Departments, Message Servers and Directory Servers.
Trusted object Object that is allowed to override security policies.
Trusted subject Subject that is allowed to override security policies. The subject is allowed to
handle information with different security labels.
XOmail The XOmail MMHS software product family, including Server, XOmail MS
Client, XOmail Admin Client, Web Client and XOmail Web Admin Client,
XOmail plugins to other software and supporting software.
XOmail Admin Client Covers the XOmail Admin Client. The Admin Client is used for configuring
the server and inspecting and monitoring messaging traffic.
XOmail Web Admin The web based management clients are used to manage a cluster of
XOmail Servers in a datacentre configuration. These allow bulk
management of users and storages and monitoring capability for all XOmail
Servers in the cluster.
XOmail MS Client The XOmail MS Client provides end users with access to personal and
formal message handling and supervision.
XOmail Server The XOmail Server software
XOmailWEB Web based clients for end users with access to personal and formal
message handling and supervision. Web clients may also be tailored for
specific operator roles, or integrated as part of connected systems.
Table 9-2 Terminology