Alliance

Security Guidance

The purpose of this document is to provide the reader with Swift's minimum set of security-related recommendations for
customers using Alliance Web Platform Server-Embedded, Alliance Access/Entry, Alliance Gateway, and SwiftNet Link.
This document also makes the link with the Swift Customer Security Controls Framework Detailed Description (CSCF
v2024).

12 January 2024

Link to this document: [Link]

Alliance Table of Contents
Security Guidance

Table of Contents

Preface............................................................................................................................................................... 4

Significant Changes..........................................................................................................................................6

1 Introduction..............................................................................................................................................7
1.1 Swift Network and the Local Environment............................................................................................... 7
1.2 Swift Architecture Types.......................................................................................................................... 8
1.3 Customer Responsibilities..................................................................................................................... 10

2 Overview of the Alliance Product Family............................................................................................ 12

2.1 Alliance Access......................................................................................................................................12
2.2 Alliance Entry.........................................................................................................................................14
2.3 Relationship Management Application (RMA)....................................................................................... 16
2.4 Alliance Gateway...................................................................................................................................17
2.5 SwiftNet Link..........................................................................................................................................18
2.6 SwiftNet PKI and HSM...........................................................................................................................19
2.7 Alliance Web Platform Server-Embedded............................................................................................. 19
2.8 Swift Web Access.................................................................................................................................. 19
2.9 SwiftNet Connectivity.............................................................................................................................21

3 Overview of Security Officer Roles, Responsibilities, and Tools..................................................... 22

3.1 SwiftNet Security Officer........................................................................................................................22
3.2 Alliance Security Officer.........................................................................................................................23
3.3 [Link] Administrator..........................................................................................................................24
3.4 Business Officer.....................................................................................................................................24
3.5 Other Applications' Security-Related Roles...........................................................................................24
3.6 Online and Offline Tools for Security Officers........................................................................................ 24

4 Architecture Recommendations.......................................................................................................... 26
4.1 Alliance Products within the Secure Zone............................................................................................. 26
4.2 Protecting the Secure Zone...................................................................................................................27
4.3 Operator Access to the Secure Zone.................................................................................................... 28
4.4 Separation from General Enterprise IT Services................................................................................... 29

5 Security Best Practices and Swift Security Recommendations....................................................... 30

5.1 Swift Security Roles and Responsibilities for Customers...................................................................... 31

12 January 2024 2
Alliance Table of Contents
Security Guidance

5.2 Local Network Security..........................................................................................................................41

5.3 Secure Local Server Environment.........................................................................................................47
5.4 Secure Local Client Environment.......................................................................................................... 55
5.5 Secure Local Application Environment..................................................................................................58
5.6 Other Security Recommendations.......................................................................................................109

6 Glossary................................................................................................................................................112

7 Swift Training....................................................................................................................................... 115

8 Support................................................................................................................................................. 116

Legal Notices................................................................................................................................................. 117

12 January 2024 3
Alliance Preface
Security Guidance

Preface
Purpose of this document
This document is issued for information purposes only. It is aimed at providing general guidance to
assist customers in protecting access to and use of their Alliance products (Alliance Web Platform
Server-Embedded, Alliance Access/Entry, Alliance Gateway, HSM, and SwiftNet Link). This
document also makes the link to the security controls documented in Swift Customer Security
Controls Framework (CSCF v2024).
The guidance in this document is not meant to be an exhaustive list of recommendations or to
replace well-structured policy, sound judgement, and compliance with the current best practices.
Furthermore, it does not address customer-specific infrastructure and configuration issues, or other
specific requirements that may apply to customers, considering, in particular, the technology used
and the customer's own security risk analysis.
The information in this document refers to the description of Alliance products at the date of this
document. As this document may not necessarily be updated along with subsequent changes to
the Alliance products, always refer to the latest available version of the relevant Service
Descriptions and other related documentation.

Related documentation and Knowledge Base articles

• Alliance Access Administration Guide: AIX Linux Windows
• Alliance Access Configuration Guide
• Alliance Access Installation Guide: AIX Linux Windows
• Alliance Access Security Guide
• Alliance Entry Installation Guide
• Alliance Entry Security Guide
• Alliance Gateway Administration and Operations Guide
• Alliance Gateway Installation Guide: AIX Linux Windows
• Alliance Gateway Security Guide
• Alliance Web Platform Server-Embedded Administration and Operations Guide
• Network Access Control Guide
• Network Configuration Tables Guide
• HSM Box Operations Guide
• Information for Hardening Supported Operating Systems
• Swift Customer Security Controls Framework Detailed Description
• Swift Customer Security Controls Policy
• Customer Security Programme Terms and Conditions
• Swift General Terms and Conditions
• Swift Glossary
• SwiftNet Link Installation Guide: AIX Linux Windows
• SwiftNet Link Service Description
• SwiftNet Service Description
• Information and guidelines for secure access to [Link] applications

12 January 2024 4
Alliance Preface
Security Guidance

• Guidelines on cryptographic algorithms (Knowledge Base article 5021566)

12 January 2024 5
Alliance Significant Changes
Security Guidance

Significant Changes
This section lists all significant changes to the content of this document since the following editions.
These tables do not include editorial changes that Swift makes to improve the usability and
comprehension of the document.

New and updated information since the July 2023 Location

edition

Renamed control 2.8A to 2.8 Throughout the document

CLA.01 Password Policy (CSCF Control 4.1) on page 73

Passwords must not contain the user name.

New and updated information since the October Location

2022 edition

For the security parameter WS Session Time Out, set Operator Session Confidentiality and Integrity (CSCF
the session time-out to a value lower than or equal to Control 2.6) on page 68
the default value, which is 600 seconds.

New and updated information since the October Location

2021 edition

Renamed control 1.4A to 1.4 Throughout the document

Renamed control 1.5A to 1.5

Additional information about Alliance Connect Virtual Swift Network and the Local Environment on page
7

12 January 2024 6
Alliance Introduction
Security Guidance

1 Introduction
This security guidance document gives an overview of the key security features and security
operator functions of the Alliance products, as well as a minimum set of customer security
recommendations that are designed to help customers protect their local environment. You can find
further guidance in the various guides referenced in this document.

1.1 Swift Network and the Local Environment

Swift Network
The Swift Network provides messaging services to the Swift customer community, and includes all
of the premises, infrastructure, software, products, and services owned and directly operated (and
controlled) by Swift and its personnel. The Swift environment applies strict security, confidentiality,
and integrity protections to customers' messages. Swift has controls and procedures in place to
protect message data from unauthorised disclosure, to guarantee message origin, to protect
against unauthorised changes to messages once the message enters the Swift environment, and
to detect the corruption of messages. In addition, content validation features can be used to ensure
that only validated messages are processed and delivered in the relevant sequence to the intended
recipient.

Connecting to the Swift Network

The connection to the Swift Network is done over the secure IP network (SIPN). The network is
accessible either over leased lines offered by a variety of Network Partners (multi-vendor model) or
by local Internet Service Providers (ISPs).
The connection to the Swift Network is protected and secured by multiple authentication factors in
the form of two state-of-the-art security devices:
• Alliance Connect, a dedicated and specialised physical VPN device offering Internet Protocol
Security (IPsec)-based authentication and encryption (AES), based on hardware-stored PKI
credentials (2048-bit RSA keys). These PKI credentials are generated locally, preserved in
hardware and managed under a dedicated Swift private PKI CA infrastructure.
As an alternative, Alliance Connect Virtual uses virtual VPN instances deployed in the public
cloud environment of a public cloud provider participating in the Swift Cloud Provider
Programme. In this case, IPsec authentication and encryption are also used and IPSec tunnels
use digital certificates that are based on a 4096-bit RSA-key. The credentials are generated and
stored in a Virtual Trust Platform Module from the cloud provider.
• A dedicated and specialised Hardware Security Module (HSM) providing 2048-bit RSA keys,
which generate PKI credentials that are used to sign and provide the proof of origin of Swift
transactions. These PKI credentials are generated locally, preserved in hardware, and managed
under a dedicated Swift private PKI CA infrastructure.
Local Alliance infrastructure
The scope of this document is the customer's local or remote (hosted or operated by a third party,
or both) Swift infrastructure. This includes the Swift-specific components managed by or for users,
including applications, network components, tokens, and other removable media, as well as the
supporting hardware. Examples of local Swift infrastructure set-up and components, depending on
the user's "Architecture Type" are: secure zone, messaging and communication interfaces, and
connectors.
The Alliance products covered in this document are Alliance Access/Entry, Alliance Gateway,
Alliance Web Platform Server-Embedded, SwiftNet Link, HSM, and Alliance Connect.

12 January 2024 7
Alliance Introduction
Security Guidance

Alliance Access is Swift's prime messaging interface. It is designed to connect customers' local
business applications to Swift messaging services and offers the possibility to define local business
workflows. Alliance Access enables customers to connect single or multiple destinations to Swift.
Alliance Entry is a lighter version of Alliance Access, which is limited to a single destination and
basic back-office integration.
Alliance Gateway is Swift's connectivity product that implements state-of-the-art security measures
to connect to the Swift Network. This includes HSM-based PKI cryptographic functions. Alliance
Gateway also provides centralised, automated, and high-throughput integration with various in-
house applications and service-specific interfaces. Swift has designed Alliance Gateway to enable
customers to concentrate the flow of messages between SwiftNet and remote financial applications
over IP or IBM MQ.
Alliance Web Platform Server-Embedded is the browser-based Graphical User Interface (GUI)
framework to the server products of the Alliance portfolio. It also provides access to Swift Web
Access services. Once installed, it is possible to add functional packages.
SwiftNet Link is Swift's mandatory software product for customers of SwiftNet services. SwiftNet
Link provides the minimal functionality for technical interoperability between customers that use
SwiftNet services.

SwiftNet Public Key Infrastructure

Security officers manage the SwiftNet PKI administration for one or more (if the PKI administration
has been delegated by another customer) registered customers (8-character business identifier
codes - BICs). Swift registers the first two security officers per customer (8-character BIC) as part
of the registration process. These security officers must organise the appropriate certification of
individuals or applications to access SwiftNet services.
The role of a security officer must be carefully organised within each institution. It is important to
have a good understanding of the different types of security officers, their related responsibilities,
and how to support separation of duties.

1.2 Swift Architecture Types

Within the Customer Security Programme, Swift has defined four reference architecture types that
assist customers in understanding which Alliance products are located within their local Alliance
infrastructure. Knowing your architecture type is also a prerequisite for correctly assessing
compliance of your local environment against the controls defined within the Swift Customer
Security Controls Framework, as the control requirements differ between architectures.
For customers using Alliance Access/Entry and/or Alliance Gateway, and SwiftNet Link products
described in this document, only architecture types A1 and A2 are applicable, as described below.
• Architecture A1 - Users owning the communication interface (and generally the
messaging interface)
The licences of Alliance Access/Entry, Alliance Web Platform Server-Embedded, Alliance
Gateway, HSM, and SwiftNet Link (SNL) are owned by the user. This architecture type also
includes cases where the user owns the licence of Alliance Gateway and SwiftNet Link only
(that is, no Alliance Access), and also includes hosted solutions where the customer has the
licences for Alliance Access/Entry, Alliance Gateway, and SwiftNet Link.

12 January 2024 8
Alliance Introduction
Security Guidance

Swift architecture - A1

General enterprise IT environment

Scope of security controls

Local SWIFT infrastructure

Back Office Data exchange

Alliance Access/Entry Alliance Gateway

RMA SWIFTNet Link

Alliance Web
HSM PKI
Platform SE
SWIFTNet
PKI

Back Office
Using Middleware
Client Data exchange
Middleware
Server Data exchange

End user Administrator

D1700001
General enterprise IT environment

Scope of security controls

Local SWIFT infrastructure

Back Office Data exchange

Alliance Gateway

RMA SWIFTNet Link

Alliance Web
HSM PKI
Platform SE PKI

SWIFTNet

Back Office
Using Middleware
Client Data exchange
Middleware
Server Data exchange

End user Administrator D1700002

• Architecture A2 - Partial stack without communication interface

The Alliance Access/Entry and Alliance Web Platform Server-Embedded applications are within
the customer's environment, but a Service Provider (for example, a service bureau, Alliance
Remote Gateway, or a Group Hub) owns the licence for Alliance Gateway, HSM, and SwiftNet
Link. This architecture type also includes hosted solutions of the messaging interface where the
customer has the licence for the Alliance Access/Entry interface.

12 January 2024 9
Alliance Introduction
Security Guidance

General enterprise IT environment

Scope of security controls

Data exchange Local SWIFT infrastructure

Back Office
Alliance Access/Entry Communication
Interface

RMA
SWIFTNet Link

Alliance Web
Platform SE HSM PKI
PKI
SWIFTNet
Back Office
Using Middleware
Service Provider
Client Data exchange
Middleware
Server Data exchange
End user Administrator

D1700003
Note According to the CSCF categorisation, the stand-alone Alliance Access application is
considered to be an A2 (Partial Stack) Architecture type. For more information, see
Standalone Alliance Access.
For more information about how to determine your CSP architecture type, see Knowledge Base
article 5022086.

1.3 Customer Responsibilities

As per the Swift General Terms and Conditions, the customer is and remains responsible at all
times for maintaining the confidentiality, integrity, availability, and security of traffic, message, and
configuration data on its Swift-related infrastructure and on that segment of its connection to Swift
for which Swift is not responsible under the Customer Security Programme Contractual
Documentation, including any segment of the connection of the customer through a Service
Provider such as a service bureau, Group Hub, or L2BA application provider. More generally, the
customer is and remains responsible at all times for protecting and securing its local environment,
including but not limited to all internet-facing systems, against potential compromises and cyber
attacks.
Swift, as a member-owned cooperative, has developed various security-related initiatives under the
Customer Security Programme, Shared Infrastructure Programme, and L2BA Application Providers
Programme for the collective benefit of its customers' community. These initiatives include the Swift
Customer Security Controls Framework Detailed Description and the Swift Customer Security
Controls Policy. They are designed to help Swift users improve cyber security and to facilitate
cyber security risk assessments by and amongst users directly. The Swift Information Sharing and
Analysis Centre (ISAC) aims to facilitate customers' access to security threat intelligence (typically,
malware details such as file hashes, indicators of compromise, and details on the modus operandi
used by cyber criminals) to help customers to better defend themselves. As in this document, Swift
also publishes general security guidance relating to specific Swift services and products to help
customers protect and secure their use of such Swift services and products. Customers must
ensure that they regularly check and always refer to the latest available information, data, and
other materials published by Swift. Customers acknowledge and agree that nothing in these
security-related initiatives constitutes any representation, warranty, or guarantee on the part of
Swift against the occurrence or prevention of compromises or cyber security incidents or other
similar events. Furthermore, nothing in such initiatives shall be construed or interpreted as Swift
taking or accepting any responsibility or liability for customers' roles and responsibilities and
obligations as set out in the Swift Contractual Documentation (typically, the responsibility for each
customer to duly protect and secure its Swift-related infrastructure and local environment).

12 January 2024 10
Alliance Introduction
Security Guidance

A cyber security incident can happen at any time. Each customer should develop its own incident
response plan. To assist customers, Swift has issued the Swift ISAC Security Bulletin 10047 "Cyber
Security Incident - Recovery roadmap", which aims to give customers some general advice on how
to respond to a cyber security incident.
Customers that engage with third parties (such as an external IT provider or a Cloud provider) to
host or operate in full or in part the user's own Swift infrastructure must be aware that they remain
responsible/accountable and must ensure that the related activities are protected, at a minimum, to
the same standard of care as if operated within the originating organisation. When hosting in the
Cloud, depending on the model, responsibilities are shared. For more information, see Appendix G
of the Swift Customer Security Controls Framework Detailed Description.

12 January 2024 11
Alliance Overview of the Alliance Product Family
Security Guidance

2 Overview of the Alliance Product Family

The Alliance product family is a set of software and security hardware components enabling
customers to access and use financial messaging services (that is, FIN, InterAct, FileAct, and Swift
Web Access (formerly Browse) with their counterparts).
This section provides a high-level view of the Alliance product portfolio.

Alliance Web Platform

Server-Embedded

Alliance VPN
SWIFT IP
MQHA Alliance box
Gateway SNL
SNL Network
Access/Entry
MQHA
SOAP

RAHA
AFT RMA
HSM

ADK IPLA WS

SWIFT mandated SWIFT network

Back office

D0540247
Customer responsibilities

The Alliance product family consists of three major components:

• the graphical user interface (GUI) offered by Alliance Web Platform Server-Embedded
• the messaging interface Alliance Access/Entry, which forms the heart of the local messaging
facilities
• the communication interfaces Alliance Gateway, SwiftNet Link, HSM, and Alliance Connect,
which enable technical connections to Swift, as well as offer an underlying state-of-the-art
secure connection to the Swift Network.
Alliance products have been designed in accordance with industry security best practices. Strict
software development life cycle and other security-related controls are applied to Alliance products
in the same way as to any other service delivered by Swift, including testing for OWASP Top 10
and CWE/SANS Top 25 vulnerabilities.

2.1 Alliance Access

Alliance Access is Swift's prime messaging interface, which is designed to connect customers'
business applications to Swift messaging services, and which can also support the manual
message/file life-cycle workflow. Alliance Access receives, processes, routes, and forwards
messages and files across the Swift network and across a variety of back-office applications.
Alliance Access provides various host adapters to connect to a range of back-office applications
that third parties or customers have developed. Alliance Access also includes capabilities for
customised integration with third parties. Swift has designed Alliance Access to communicate with
all SwiftNet messaging services and to handle the volumes of large financial institutions. Alliance
Access is a qualified FIN, InterAct, FileAct, and RMA interface.

12 January 2024 12
Alliance Overview of the Alliance Product Family
Security Guidance

Browser

File Transfer
MQ Alliance
SOAP Web Platform
Web Services Direct FileAct Server-Embedded
ADK

Application Back-office Desktop

Integration
Integration Application Access

Messaging Alliance Access Packages

Software
Profile Management

Monitoring
and System Management

Message Management
and Routing

Relationship Management

Communications Alliance Gateway

Software
Alliance Remote Gateway

Network Alliance Connect Alliance Gateway

Connection

FIN
InterAct SWIFTNet
D0540209

FileAct

2.1.1 Licence
The use of Alliance software is subject to valid licence keys (master and initialisation licence keys).
Secure Channel is used to distribute part 1 (left) and part 2 (right) of the licence keys.

2.1.2 Profile Management

Users must have a profile that defines the role and entitlements to access specific Alliance Access
functionalities. Swift refers to Alliance Access end users as operators.
Swift delivers Alliance Access with pre-defined operating profiles. The Alliance left security officer
(LSO) and right security officer (RSO) assign profiles to individual Alliance Access users within
their institution. The two independent security officers can modify and create new operator profiles
according to their institution's requirements.

12 January 2024 13
Alliance Overview of the Alliance Product Family
Security Guidance

It is possible to also grant specific permissions that allow performing certain administration tasks
(for example, configuration management or monitoring). With mutual approval, the LSO/RSO can
decide to create and approve additional security officers.

2.1.3 Monitoring and System Management

Customers can monitor their institution's Alliance Access activities. Customers can also customise
the view of monitored events and entities, and filter and create reports about specific items of
interest. Customers can monitor activities interactively on screen (using Alliance Web Platform
Server-Embedded) or from an external monitoring application (using command-line tools or event
distribution).

2.1.4 Message Management and Routing

Alliance Access offers comprehensive message management functionality through local workflows,
such as manual message creation, independent verification, validation and authorisation, repair
(modification), and consultation. Customers can also consult, verify, authorise, and modify
messages created by back-office applications.
Alliance Access provides customers with extensive message-routing functions, supporting MT, MX,
and FileAct messages.

2.1.5 Local Integration Capabilities

Alliance Access offers a variety of integration capabilities:
• Alliance Access Integration Platform (IPLA)
• Web services
• Alliance Access Developers Toolkit (ADK)
• RESTful APIs
Depending on the capability used, adapters support a number of connection methods, such as:
• File Transfer Host Adapter
• IBM MQ
• Simple Object Access Protocol (SOAP)
• Direct FileAct

2.1.6 Browser and Operator PC

Packages running on Alliance Web Platform Server-Embedded are thin-client Alliance Access GUI
applications that only require a browser on the operator's PC, such as Mozilla Firefox, Google
Chrome, or Microsoft Edge. The use of GUI packages does not require the installation of additional
Swift software on the operator's PC.

2.2 Alliance Entry

Alliance Entry is a Swift messaging interface that is designed to receive, process, route, and
forward messages and files across the Swift network and across a variety of back-office
applications.

12 January 2024 14
Alliance Overview of the Alliance Product Family
Security Guidance

Customers use Alliance Entry primarily in manual entry mode. Messages can also be prepared by
a back-office application and sent to Alliance Entry by file transfer. Swift has designed Alliance
Entry to communicate with all SwiftNet messaging services. Alliance Entry is a qualified FIN,
InterAct, FileAct, and RMA interface.

Browser
File Transfer

Back-office Alliance
Integration
Application Web Platform SE

Messaging Alliance Entry

Software
Profile Management

Monitoring
and System Management

Message Management

Relationship Management

Communications Alliance Gateway

Software
Alliance Remote Gateway

Network Alliance Connect Alliance Gateway

Connection

FIN
InterAct SWIFTNet
D0540199

FileAct

2.2.1 Licence
The use of Alliance software is subject to valid licence keys (master and initialisation licence keys).
Secure Channel is used to distribute part 1 (left) and part 2 (right) of the licence keys.

2.2.2 Profile Management

Users must have a profile that defines the role and entitlements to access specific Alliance Entry
functionalities. Alliance Entry refers to Alliance Entry end users as operators.

12 January 2024 15
Alliance Overview of the Alliance Product Family
Security Guidance

Alliance Entry delivers Alliance Entry with pre-defined operator profiles. The customer's left security
officer (LSO) and right security officer (RSO) assign profiles to their institution's individual Alliance
Entry users. The two independent security officers can modify and create new operator profiles
according to their institution's requirements.
It is possible to also grant specific permissions that allow certain administration tasks (for example,
configuration management or monitoring). With mutual approval, the LSO/RSO can decide to
create and approve additional security officers.

2.2.3 Monitoring and System Management

Customers can monitor their institution's Alliance Entry activities. Customers can also customise
the view of monitored events and entities, and filter and create reports about specific items of
interest. Customers can monitor activities interactively on screen (using Alliance Web Platform
Server-Embedded) or from an external local application (using command-line tools).

2.2.4 Message Management

Alliance Entry offers comprehensive message management functionality through local workflows,
such as manual message creation, independent verification, validation and authorisation, repair
(modification), and consultation. Customers can also consult, verify, authorise, and modify
messages created by back-office applications.

2.2.5 Local Integration Capabilities

Alliance Entry offers integration capabilities by means of the File Transfer Host Adapter.

2.2.6 Browser and Operator PC

Packages running on Alliance Web Platform Server-Embedded are thin-client Alliance Entry GUI
applications that only require a browser on the operator's PC, such as Mozilla Firefox, Google
Chrome, or Microsoft Edge. The use of GUI packages does not require the installation of additional
Swift software on the operator's PC.

2.3 Relationship Management Application (RMA)

Authorisations restrict the sending of messages between parties in a business relationship. When
using the RMA protocol to exchange authorisations, the party that creates the authorisation is the
one that receives the messages. In this way, you can restrict the messages that are sent to you,
and redirect unwanted traffic from correspondents and unknown correspondents to a different
queue. The RMA service is essential to ensure that the exchange of traffic complies with the
agreements of established business relationships.
For customers running Alliance products, this RMA application is provided in two flavours, either
embedded within Alliance Access/Entry or as a stand-alone application. As of January 2023, you
can also choose to manage relationships using Swift's central Relationship Management Portal.
For more information, see the Relationship Management Portal Getting Started.
You can use RMA to manage the authorisations for exchanging FIN and InterAct messages and
FileAct files. In the application service profile of the service, if the field RMAFeatureUsed is set to
"true", then the messages for that service require authorisation.

12 January 2024 16
Alliance Overview of the Alliance Product Family
Security Guidance

Swift mandates the use of Relationship Management for the FIN and FINplus live services (and
optionally for pilot services), for FIN messages that require authentication. For FIN Copy, InterAct,
and FileAct, the service administrator defines whether Relationship Management applies to their
service by means of the application service profile for the service in question.

Local authorisations
You can implement RMA for non-FIN services by using bootstrap (also known as local)
authorisations for services that are in a migration period, that is, existing services that originally did
not require authorisation. Implementing RMA for non-FIN services involves adding bootstrap
authorisations in the Alliance Access RMA data store. For bootstrap authorisations, no RMA
messages are exchanged over SwiftNet.
In particular, this is useful for an institution that has implemented RMA and that exchanges InterAct
or FileAct messages with a correspondent that has not implemented RMA at this point. It is also
useful for any institution that wants more control over the sending or receipt of messages for an
InterAct or FileAct service that currently does not require authorisation. In this scenario you can
also use local authorisations for unilateral filtering of messages and files.
Depending on the parameters that are defined for the RMA service in the application service
profile, you can create bootstrap authorisations to send or authorisations to receive. You cannot
add a bootstrap authorisation if the application service profile forbids it.

2.4 Alliance Gateway

Alliance Gateway is a software package that is installed on top of SwiftNet Link software, and
enables application-to-application communication. Using the SwiftNet messaging services InterAct
and FileAct, messages and files are typically exchanged between a customer application (client)
and a central application (server) over Swift's secure IP network (SIPN).
Alliance Gateway acts as a single window to Swift's secure IP network, enabling multiple
applications to concentrate their traffic to SwiftNet over Alliance Gateway. This avoids the need for
multiple physical connections to Swift's secure IP network within user organisations.
Alliance Gateway thereby becomes the sole software that accesses SwiftNet directly over SwiftNet
Link (except for applications using MI Channel).
Customers can use Alliance Gateway to concentrate the flow of messages between SwiftNet and
remote financial applications over Internet Protocol (IP) using the Remote API Host Adapter

12 January 2024 17
Alliance Overview of the Alliance Product Family
Security Guidance

(RAHA), or by means of the MQ Host Adapter (MQHA). Applications using MI Channel can be
used with SwiftNet Link and Alliance Gateway, but require the IBM MQ client software.

Browser
Back-office
Applications Web Platform SE

Messaging Alliance
Software Access/Entry

Communications Alliance
Software Gateway Application Interface

MQHA

RAHA

MI Channel SWIFTNet Interface

Configuration Adapter

Network
Connection

FIN
SWIFTNet InterAct
FileAct
D0340158

SWIFT WebAccess

2.5 SwiftNet Link

SwiftNet Link is a Swift software product that enables users to access and use the SwiftNet
messaging services, FIN, InterAct, and FileAct. SwiftNet Link embeds SwiftNet PKI software.
SwiftNet Link provides the following functionality:
• access and use of SwiftNet messaging services over the Swift Secure IP Network.
• technical interoperability between the requestor application and the Swift network, and between
the Swift Secure IP Network and the responder application, at the customer site.
• enables the management of PKI certificates through the Alliance Gateway GUI or other Vendor
applications connected to the Alliance Gateway by means of Remote API (RA).

12 January 2024 18
Alliance Overview of the Alliance Product Family
Security Guidance

2.6 SwiftNet PKI and HSM

SwiftNet Public Key Infrastructure (PKI) certificates are stored on Hardware Security Modules
(HSMs), and are accessed through SwiftNet Link.

SwiftNet Public Key Infrastructure (PKI)

SwiftNet PKI is a Swift service that provides certification services to entities that send and receive
messages or files over SwiftNet. These entities are typically end users, applications, and SwiftNet
interfaces that apply digital signatures and encryption. The certification services also include the
issuance and management of certificates.
A SwiftNet PKI Certificate Policy ID "[Link].2" identifies business certificates for which the
associated PKI security profile must be stored on an HSM. A customer must use certificates that
are stored in an HSM and that carry Certificate Policy ID "[Link].2" to sign live end-to-end FIN,
InterAct, and FileAct traffic. For more information, see the SwiftNet PKI Certificate Administration
Guide.

Hardware Security Module (HSM)

Hardware Security Modules (HSMs) are tamper-resistant devices that our customers use to
safestore their SwiftNet PKI private keys. The keys are generated inside the HSM and stored
encrypted on this device. The HSM performs sensitive cryptographic operations such as signing
the data that is sent over SwiftNet. Access and use of the HSM is through SwiftNet Link (SNL).

2.7 Alliance Web Platform Server-Embedded

Alliance Web Platform Server-Embedded is a generic platform that supports secure browser-based
user interfaces that are deployed as a front end to Alliance Access/Entry and Alliance Gateway.
The platform can support several hundreds of concurrent users within an institution and can be
accessed through standard web browsers from each user's system.
Alliance Web Platform Server-Embedded has been designed according to standard industry three-
tier architecture practices. This enables the customer to deploy the products according to best
practices, such as with separation between the front-end, application, and data layers.
Alliance Web Platform Server-Embedded includes the application server that the software requires
and provides a common set of services to all GUI packages deployed in it.
In addition, Alliance Web Platform Server-Embedded gives access to the Swift Web Access
services provided by Swift members on SwiftNet over the Swift Network.

2.8 Swift Web Access

Swift Web Access enables secure, browser-based access from an end user who uses a standard
browser, to a Service Provider's web server over Swift.
Swift Web Access provides strong user authentication to the Service Provider's application. It also
supports the use of non-repudiated transactions (security-sensitive exchanges) when used by the
Service Provider.
Swift Web Access users connect with their web browser to the Service Provider's web server over
HTTPS and browse through web pages. Some of these web pages may trigger the invocation of
secure transactions, performed either over HTTPS or by using InterAct or FileAct to exchange
messages and files within the session.

12 January 2024 19
Alliance Overview of the Alliance Product Family
Security Guidance

Swift Web Access supports several ways to connect to the Service Provider's application. The
supported set-ups are shown in the following diagram:

VPN
SAG

MV-SIPN
WebPlatform
HSM
User with browser, logged in through web platform (MV-SIPN)
->signing with certificate on HSM.

IdP

Service provider
VPN VPN

MV-SIPN

User with browser and personal token (MV-SIPN) Service provider operates
CUG Web application (MV-SPIN)
->signing with certificate on token.

NR

Internet

User with browser and personal token (internet)

->signing with certificate on token.

D1690001
As illustrated, users may access the Service Provider through Swift's Multi-Vendor Secure IP
Network (MV-SIPN) or through the Internet, depending on their Service Provider. All
communications transit the Swift network to access Identity Provider (IdP) authentication, Closed
User Group (CUG) access control, and optional non-repudiation (NR) services, before being
forwarded onto the Service Provider. The web application is connected to MV-SIPN.
Note Swift Web Access using InterAct or FileAct is only supported over MV-SIPN in
combination with Alliance Web Platform Server-Embedded with the Swift Web Access
GUI Package and certificates stored on HSM.

Access to a Swift Web Access service

You must verify with your Service Provider which connectivity options are available for the service
you want to use:

Connectivity option Details

Token-based access Swift Web Access services support token-based

access over MV-SIPN or from the Internet. For such
a service, the use of Alliance Web Platform Server-
Embedded is not necessary.

Alliance Web Platform SE This is the framework that hosts all the GUI software
packages for the Alliance products.
For services that do not support token-based access,
rather only HSM certificates, Swift typically supports
access to the service by means of Alliance Web
Platform Server-Embedded.

In this document, Swift provides security guidance for the connectivity option of using Alliance Web
Platform Server-Embedded for Swift Web Access services. The token-based access option is not

12 January 2024 20
Alliance Overview of the Alliance Product Family
Security Guidance

covered specifically in this document, but it is in the scope of the Swift Customer Security Controls
Framework.

Secure browsing
You are advised to review and implement (where possible) controls, to implement secure browsing
practices. These controls provide a non-exhaustive list of secure browsing practices.
You must follow secure browsing practices, such as:
• Separating general browsing from Swift Web Access, ideally by using different workstations.
• Not browsing sites other than Swift Web Accesss services when a session is open.
• Never following links in e-mails that pretend to direct the user to Swift Web Access. Be
suspicious of e-mails that appear to come from Swift, and never provide a token or GUI
password if requested. Swift never asks for any password in an e-mail or any other form of
communication.
• Ensuring security awareness for Swift Web Access end users, developing and maintaining
security-focussed behaviour among end users, and ensuring that end users are fully aware of
threats related to browsing (such as ensuring that user sessions cannot be taken over).
• Ensuring that users close the browser upon completion.
• Ensuring that no untrusted browser plug-ins can be installed on the workstation used for Swift
Web Access services.

2.9 SwiftNet Connectivity

Alliance Connect and Alliance Connect Virtual provide connectivity to SwiftNet.

Alliance Connect
The managed access solutions offered by Swift's Network Partners provide guaranteed bandwidths
and a high service availability level, while the standard Internet connectivity through an ISP
provides a cost-effective option. Leased lines use a Swift Network Partner's secure network to
connect to SwiftNet.
Alliance Connect uses a dedicated and specialised Swift-managed VPN box to establish a secure
and reliable channel over the Swift SIPN network. This channel uses Internet Protocol Security
(IPsec) technology, which ensures the authentication and encryption of customer data.

Alliance Connect Virtual

Alliance Connect Virtual uses software-based VPN instances, which are deployed in the public
cloud environment of a Cloud Provider participating in the Swift Cloud Provider Programme. It is
available with Internet based and pseudo leased line based connectivity options. The pseudo
leased line-based option uses native cloud based resources to connect the Cloud Provider access
network to the Network Partners in co-located datacentres (Cloud Exchanges), which then connect
to Swift over the private Network Partner network. Alliance Connect Virtual uses a dedicated and
specialised Swift-managed VPN instance to establish a secure and reliable channel over the Swift
Secure IP Network (SIPN). Similarly to the hardware-based solution, this channel uses IPSec
technology to ensure authentication and encryption of customer data.

12 January 2024 21
Alliance Overview of Security Officer Roles, Responsibilities, and Tools
Security Guidance

3 Overview of Security Officer Roles,

Responsibilities, and Tools
A security officer manages security matters for one customer (8-character business identifier code
(BIC)). Swift registers the first two security officers as part of the registration process.
There are various types of security officers. More information can be found in this chapter and in
the Security Officer Guide.

3.1 SwiftNet Security Officer

SwiftNet security officers
SwiftNet security officers are the officially registered and authorised representatives for all
communications with Swift regarding SwiftNet security. They control the security of their institution
(8-character BIC) by administering the entities, the certificates, and the roles for which they have
been appointed. A customer (8-character BIC) must have at least two security officers, unless
administered by another institution.
The main tasks of SwiftNet security officers can be summarised as follows:
• maintenance of the institution's PKI entities, also known as Distinguished Names (DNs)
• maintenance of the certificates related to the PKI entities
• maintenance of the Role-Based Access Control (RBAC) roles assigned to these entities
• maintenance of the available SwiftNet security officers

Shared security officers

Instead of appointing its own security officers, a customer (the administered institution) can decide
to appoint the security officers of another customer (the administering institution) to act as its duly
authorised security officers. Such appointed security officers are referred to as shared security
officers. They are responsible for managing, on behalf of the administered institution, the customer
entities and certificates of the administered institution (per 8-character BIC).
This is particularly useful if a customer operates multiple 8-character BICs. For more information,
see shared security officers in the SwiftNet PKI Certificate Administration Guide.

Online and offline SwiftNet security officers

There are two categories of security officers:
• Security officers who can administer the customer entities, certificates, and roles online (by
means of the SwiftNet Online Operations Manager)
• Security officers who can request SwiftNet PKI changes through a second, offline channel (that
is, Secure Channel, which is available on [Link]) when the SwiftNet Online Operations
Manager cannot be used
A single physical person can have both an offline and online SwiftNet security officer (SO) profile.
Each profile is managed separately.
Swift registers the first two security officers with both online and offline capabilities. The security
officers can subsequently register additional security officers of each category.

12 January 2024 22
Alliance Overview of Security Officer Roles, Responsibilities, and Tools
Security Guidance

3.2 Alliance Security Officer

Alliance security officers refers to the security officers of Alliance Access/Entry.

Left and right security officer

When you install an Alliance Access/Entry interface for the first time, two predefined operators are
created: one left security officer (LSO) and one right security officer (RSO).
The left security officer and the right security officer carry joint responsibility for the configuration
and the management of the security functions within Alliance. They control which users can sign in
to Alliance Access or Entry and what those users are permitted to do.
Swift has predefined the actions that Alliance security officers can perform within Swift. Alliance
security officers are not entitled to perform operational duties, such as sending and receiving
messages. This ensures that operational and security-related duties are kept strictly separate.

Secure Channel
Access to the Alliance licence keys (the master and initialisation licence keys), which are required
for the installation of Alliance software (Alliance Access/Entry and Alliance Gateway), can be
obtained by means of Secure Channel on [Link].
To access Secure Channel, Alliance security officers must first be registered on [Link] with
either the "Is Alliance LSO" or "Is Alliance RSO" role activated in their user profile. The master
password and initialisation keys are split into left and right parts. One of the related roles is required
to view the respective licence key.
An organisation should ensure that the appropriate separation of duties is present in the allocation
of left security officer (LSO) and right security officer (RSO) responsibilities, and that appropriate
procedures are in place to cater for either planned or unexpected absences of the LSO/RSO roles
(with separation remaining in place at all times).

Extra security officers

Alliance security officers (LSO/RSO) can create additional security officers in Alliance Access/Entry
if the security parameter Extra Sec Officer is set to Yes. Extra security officers perform the same
tasks as the LSO and RSO.
Details of the LSO, RSO, and the extra security officers are visible in Alliance Access/Entry: The
LSO is visible as left security officer, the RSO as right security officer, and the extra security officers
are visible with the name assigned during their creation. Only security officers can see other
security officers in the list of operators.
Note If the parameter Extra Sec Officer is set back to No after additional security officers
were already created, then these additional security officers will still remain visible to
the other security officers and will continue to exist.
Local security officers
The LSO and RSO can create local security officers that have access to only a limited subset of
Operator Profiles, Units, and Destinations. This limitation is imposed by the LSO and RSO to
provide separation of user management. For example, in the implementation of a Service Bureau,
the main LSO and RSO can create local security officers for an individual customer.
For the LSO and RSO to delegate Operator Profile subsets, the security configuration parameters
Restrict Delegation and Restrict Functions are set to Yes.
Restrict Delegation - if set to Yes, a local security officer who is adding a new operator can only
select operator profiles, units, and licensed destinations from a restricted list.

12 January 2024 23
Alliance Overview of Security Officer Roles, Responsibilities, and Tools
Security Guidance

Restrict Functions - if set to Yes, a local security officer with the appropriate entitlements can only
perform these functions on the operators that belong to a subset of the same units as the operator
performing the action.

3.3 [Link] Administrator

A [Link] administrator performs the following tasks:
• Alliance security officer set-up
• [Link] user administration: approves or rejects the registration requests of new [Link]
users, manages the profile of the registered users that are under their scope of control, and
grants or rejects access to specific applications.

3.4 Business Officer

A business officer performs the following tasks:
• represents the FIN Copy or SwiftNet Copy Central Institution towards Swift (only applicable in
the case of a FIN Copy or SwiftNet Copy provider)
• requests emergency FIN Copy or SwiftNet Copy mode changes and emergency withdrawals of
FIN Copy participants (only applicable in the case of a FIN Copy or SwiftNet Copy provider).

3.5 Other Applications' Security-Related Roles

In the Alliance Gateway and Alliance Web Platform applications, there are no dedicated security
officer roles. Swift provides by default one preconfigured account for each application:
• Alliance Gateway Administrator
• Alliance Web Platform Administrator
These administrator accounts are responsible to set up the initial configuration of the applications
and create additional users and profiles.
Logins with built-in Administrator application accounts should be restricted to those activities where
such accounts are specifically needed (for example, initial application configuration or
emergencies). Individual accounts are used instead for all day-to-day operations.

3.6 Online and Offline Tools for Security Officers

Security officers use online and offline tools to perform their duties.

Online tools
A tool is considered online when it is available on SwiftNet.

Offline tools
A tool is considered offline when it is only available on [Link], and not available through
SwiftNet.

Tool Type of tool Used by

SwiftNet Online Operations Manager Online SwiftNet security officers

12 January 2024 24
Alliance Overview of Security Officer Roles, Responsibilities, and Tools
Security Guidance

Tool Type of tool Used by

Secure Channel on [Link] Offline SwiftNet security officers as back-up to

SwiftNet Online Operations Manager

[Link] user administration tool: Identity Offline [Link] administrator

Management

12 January 2024 25
Alliance Architecture Recommendations
Security Guidance

4 Architecture Recommendations

4.1 Alliance Products within the Secure Zone

The Swift Customer Security Controls Framework defines the concept of a "secure zone", which is
a separated zone that protects the local Alliance infrastructure from compromises and attacks on
the broader enterprise environment.

Secure Zone Example (also see CSCF, Appendix B)

General Enterprise IT environment End User

Controlled
End User

Internet
Administrator

Server Environment
SWIFT Secure Zone

General IT Services Controlled

Jump IT
End user Administrator Server Services

Back Office (BO)

Alliance Access/Entry Alliance
Web Platform
BO with Middleware
SE
Client

Middleware Server
Alliance Gateway

SWIFT Network
Monitoring

D1700004
The following Alliance products, if applicable to you, should be included within the scope of your
secure zone:
• Alliance Access
• Alliance Entry
• Alliance Relationship Management Application (stand-alone offering if Alliance Access/Entry is
not installed)
• Alliance Web Platform SE
• Alliance Gateway
• SwiftNet Link and HSMs
As described in the CSCF, other non-Swift systems may optionally be included in the secure
zone. This chapter will focus only on Swift's Alliance products.

Separating the installation of Alliance products

Although Alliance products support installation co-hosted on the same (virtual) server, Swift
recommends installing Alliance Web Platform, Alliance Access, and Alliance Gateway on separate
servers, for security and resilience purposes, as per compliance with Swift Customer Security
Controls Framework control 1.1.d.1 Local Operator (end user and administrator) Access .

12 January 2024 26
Alliance Architecture Recommendations
Security Guidance

4.2 Protecting the Secure Zone

Sharing of layer 2 devices
Layer 2, or data link layer, devices (such as a network switch) may be shared between the secure
zone and other uses by using VLANs for separation/isolation purposes.

Secure zone firewalls

Transport layer stateful firewalls are used to create logical separation at the boundary of the secure
zone. A stateful firewall is a network firewall that tracks the operating state and characteristics of
each connection to make security decisions.
Per CSCF implementation guidelines, transport layer firewalls creating the secure zone boundary
should be physically or virtually dedicated to the protection of the secure zone. If a firewall is
shared to separate other zones, then care must be taken to ensure that a compromise of the
firewall does not affect the protection of the secure zone (such as deploying different firewall virtual
instances, dedicating one to the secure zone, formal risk assessment, or penetration testing).
These firewalls control communication to/from entities outside of the secure zone, including but not
limited to the following:
• back-office systems (if not part of the secure zone)
• middleware systems (if not part of the secure zone)
• SwiftNet
• operators (business users)
• administrative operators and system administrators (if not part of the secure zone)
• controlled internet access
Within the secure zone, the CSCF does not require additional firewalls between the components,
because these components are considered to reside in a trusted zone for communication.
However, this approach may be further enhanced, if wanted, by including additional firewalls
between the Alliance products in the secure zone to further separate the Alliance Gateway,
SwiftNet Link, and HSMs in a DMZ within the secure zone.
Physical or virtual firewalls are acceptable implementations for the secure zone.
The following are considerations for Firewall Management and Administration:
• Develop a repeatable firewall management process.
- Approve changes through a documented process.
- Begin with a "deny all" rule, and then add exceptions.
- Avoid using "any" firewall rules that allow excess flows.
- Test changes before implementing the rules for the production systems.
- Review rules regularly, and perform a complete review at least twice a year.
- Regularly remove unused rules.
- Review logs continuously for security events and to validate that firewall rules are working as
intended.
• Alert end users and administrators to changes that may affect them.
The CSCF provides guidance to construct the secure zone such that passwords and other
authenticators used within the secure zone are not stored in systems outside of the secure zone.
This also applies to the administrative credentials for the secure zone firewalls.

12 January 2024 27
Alliance Architecture Recommendations
Security Guidance

The firewall architecture ensures that:

• Administrative authentication to the firewall does not use the enterprise authentication system.
• Access is limited to only authorised users (for example, by means of a management VLAN).
• Encrypted communication channels are used to manage the firewall (no HTTP or Telnet).
• Mitigations are in place in case of a denial-of-service issue on the network.

Virtualisation
Virtualisation enables the co-hosting of systems, applications, and components on the same
physical hardware. It is a common industry practice and supported by Alliance products. The same
security requirements apply to the virtual infrastructure as for all other infrastructure components
(for example, access restrictions, logins, and installation of security updates).
The use of virtualisation technologies must not circumvent, bypass, or eliminate existing security
controls such as network intrusion-detection systems or separation of duties in system
administration. The fact that an administrator of the physical host can always take complete control
of the virtualised instances must be kept in mind when evaluating separation of duties.
As such, any implementation of virtualisation should be evaluated following a risk-based approach
before making the implementation operational.

4.3 Operator Access to the Secure Zone

The CSCF implementation guidelines provide multiple options for operator access into the secure
zone. The choice of which option to use depends on a number of factors, including the population
and location of operators needing access to the secure zone, the knowledge and ability of IT and
support staff, and the existing IT architecture.

Option A: Dedicated operator PCs within the secure zone

Operators can use dedicated PCs located within the secure zone. These PCs are only used for
secure zone purposes. Risky activities such as accessing internet or sending/receiving e-mails are
not performed on these PCs. Dedicated operator PCs must not be connected to the internet.
Support case evidence can be transferred through a jump server or other means, or even directly
through FileAct.
This option may be the best choice if:
• The number of operators needing access is limited.
• The IT organisation does not have the advanced security knowledge, experience, or capacity to
manage more complex security solutions.

Option B: Jump server within the secure zone

Operators can connect from their general-purpose PC to the secure zone by means of a jump
server. The jump server is located within a secure zone, optionally in the Swift Secure Zone (which
contains only Swift-related components as defined in CSCF control 1.1). The jump server is a
hardened environment that implements strong security practices, including but not limited to:
• Restricting access to only authorised operators.
• Removing any unnecessary software.
• Restricting risk activity (for example, sending/receiving e-mail).
• No internet access.
• Enabling logging.

12 January 2024 28
Alliance Architecture Recommendations
Security Guidance

• A dedicated jump server, different than the one used by end users, is recommended for use by
system administrators.
This option may be the best choice if:
• Network firewall rules or other controls can be created to control access to the jump server.
• There are many end users who require access.
• The IT organisation can implement the necessary controls and monitoring on the jump server
(see the CSCF).

Option C: Alliance Web Platform Server-Embedded (hosting browser-based GUIs)

Operators can directly and only connect to Alliance Web Platform Server-Embedded from their
general-purpose PC. Specific security controls must be implemented, including but not limited to:
• Restricted internet access on the operator PC (see the CSCF)
• Alliance Web Platform Server-Embedded is located within the secure zone and is logically
separated (for example, separate physical or virtual machines and separate access control lists)
from the messaging and communication interface
• Multi-factor authentication is implemented on Alliance Access and Alliance Gateway
This option may be the best choice if:
• Network firewall rules and potential other controls can be created to control access to the
browser-based GUI.
• There are many end users who require access.
• The IT organisation can effectively limit internet access on the operator PC.
System administrators (for example, operating system administrators) cannot use option C.
They must either use dedicated administrative workstations within the secure zone (option A) or
access through a dedicated jump server (option B).

4.4 Separation from General Enterprise IT Services

The CSCF implementation guidelines require users to separate enterprise authentication and the
supporting IT infrastructure from the secure zone. The architectural decisions related to this
separation differ significantly based on a user's current IT services environment. Refer to the CSCF
for additional information.

12 January 2024 29
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

5 Security Best Practices and Swift Security

Recommendations
Swift's products rely on a number of security features under the direct control and management of
Swift users. Customers should accordingly establish their own internal controls or procedures to
complement those of Swift.
This chapter lists the minimum set of recommendations that Swift advises to be implemented in
local Alliance environments. A reference is made to the CSCF security controls that are relevant for
each topic.
In some cases, there is an overlap in the recommendations made for more than one topic (for
example, the client and server environment). In such a case, the recommendations can be found in
both sections to highlight the importance in both domains.

Important Although the security recommendations in this document are mapped to the CSCF
controls, only implementing the recommendations within this document may not be
enough to fully comply with a particular CSCF control. An analysis should still be
conducted to determine if the requirements of the CSCF have been met, especially
before attesting to your compliance status.

This chapter covers six topics:

• Swift Security Roles and Responsibilities for Customers on page 31: recommendations that
help customers implement a diligent organisation to protect their assets.
• Local Network Security on page 41: recommendations that help secure the network
environment of the Alliance infrastructure.
• Secure Local Server Environment on page 47: recommendations that help secure the servers
that host Alliance software and the servers that they communicate with.
• Secure Local Client Environment on page 55: recommendations that help secure the PCs
used to connect to the servers that host Alliance software.
• Secure Local Application Environment on page 58: recommendations that help secure the
application. These are security features provided by the Alliance software. Users can and
should configure them correctly.
• Other Security Recommendations on page 109: recommendations by Swift that do not fit into
the above categories.
The recommendations are listed in tables that contain the following columns:
• ID: an identification number that can be used to refer to a specific recommendation
• Recommendation: the recommendation to be put in place
• Product: the component of the local Alliance infrastructure to which the recommendation
applies.
Where applicable, links are provided to the appropriate Alliance documentation. For any questions
regarding operating system or third-party application configuration, Swift recommends that you
contact your Vendor.

12 January 2024 30
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

5.1 Swift Security Roles and Responsibilities for

Customers
Security is everyone's responsibility. This section is focused mainly on the roles of the security
officers for the local Swift infrastructure, but it generally covers all staff using, managing, or
operating the local Swift Infrastructure.
Swift has defined a number of security officer types who should manage Swift security matters. An
overview of the security officer roles of the local Swift infrastructure is provided in Overview of
Security Officer Roles, Responsibilities, and Tools on page 22. Each customer must:
• Carefully allocate these different roles and responsibilities.
• Define the appropriate controls to support the effective implementation of the internal security
policies.
• Define the compliance with industry or regulatory security requirements.
In a typical organisation, the Chief Information Security Officer (CISO) defines the strategic
direction on information security. The CISO leads a team of experts to set the supporting policies,
processes, and controls. This serves as a framework against which Swift security will be organised.

Link with CSCF security controls

The CSCF security controls applicable to the Swift Security Roles and Responsibilities are
highlighted in the following diagram:

CSCF
1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4A 2.5A 2.6 2.7

2.8 2.9 2.10 2.11A 3.1 4.1 4.2 5.1 5.2 5.3A 5.4 6.1

6.2 6.3 6.4 6.5A 7.1 7.2 7.3A 7.4A

CSCF security control further detailed in this guide

CSCF security control relevant in this domain but covered in CSCF only
D1700005

Not relevant

The following CSCF controls have Alliance-specific security guidance (in addition to the CSCF
guidance) documented within this section:
• Logical Access Control (CSCF Control 5.1) on page 32
• Security Training and Awareness (CSCF Control 7.2) on page 40
The other relevant CSCF controls will not be discussed in depth in this document, but a high-level
context of how the controls relate to the Alliance products is provided below.
2.8 Critical Activity Outsourcing - Any outsourced critical activity related with the security
management and/or operation of the local Swift infrastructure is protected, at a minimum, to the
same standard of care as if operated within the originating organisation. This includes but is not
limited to the outsourcing of security officer activities, RMA, and Swift-related transaction
operations.

12 January 2024 31
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Customers that engage with third parties (such as an external IT provider or a Cloud provider) to
host or operate in full or in part the user's own Swift infrastructure must be aware that they remain
responsible/accountable and must ensure that the related activities are protected, at a minimum, to
the same standard of care as if operated within the originating organisation. When hosting in the
Cloud, depending on the model, responsibilities are shared. For more information, see Appendix G
of the Swift Customer Security Controls Framework Detailed Description.
5.3A Staff Screening - Individuals acting as security officers or operating the local Swift
infrastructure are security-screened before the initial employment in that role and periodically
thereafter.
7.1 Cyber Incident Response Planning - security officers and other roles in the local Swift
infrastructure play important roles in the cyber incident response plan. For more information, see
Cyber Security Incident Management (CSCF Control 7.1) on page 110.
7.4A Scenario Risk Assessment - Cyber risks related to people (such as Swift security officers and
other roles) operating the local Swift infrastructure are identified and assessed to improve incident
response preparedness and to increase the maturity of the organisation's security programme.
2.10 Application Hardening - The IT security team should apply the current Security Guidance to
ensure application hardening of the Swift-related software.
For more detailed implementation guidance, see Swift Customer Security Controls Framework.

5.1.1 Logical Access Control (CSCF Control 5.1)

A logical access control policy is documented for the local Swift infrastructure. All user accounts
(including the security officers) and application accounts in Alliance products are defined according
to the security principles of:
• need-to-know access - an individual only has access to confidential information required for
their job
• least privilege - an individual can only access the features required for their job.
• separation of duties - sensitive operations are performed by at least two individuals, each
responsible for a separate part of the task. In their absence, appropriate, separated back-ups
are in place to act on their behalf.
On the Windows platform, accounts for the installation and running of Alliance can be separated.
Implementation guidance related to logical access control is provided for each security-related role
in the following sections.

[Link] SwiftNet Security Officers

Swift creates the two initial SwiftNet security officers and grants them both online and offline
certificate administration capabilities with an institution-level scope. The initial security officers can
create additional security officers to whom they can grant specific roles.
An online SwiftNet security officer has access to online tools only. The online portal is called
SwiftNet Online Operations Manager (O2M), which provides the Local Registration Authority (LRA)
to manage certificates and assign RBAC roles. An online SwiftNet security officer must have a
Distinguished Name (DN) and a related SwiftNet PKI certificate.
An offline SwiftNet security officer has access to offline tools only. To submit an offline intervention
request to Swift, the security officer must be registered on [Link], have access to the Secure
Channel application by means of the appropriate [Link] permissions, have a valid Secure Code
Card for authentication, and must be known at Swift as an offline security officer.
The following online and offline tools are available for the various security-related tasks:

12 January 2024 32
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Task Online Tools Offline Tools

Certificate and entity Security module in SwiftNet Submit intervention requests to

administration Online Operations Manager Swift for limited functions through
Secure Channel on [Link]

RBAC administration Security module in SwiftNet Not applicable

Online Operations Manager

SwiftNet security officer SwiftNet Online Operations Secure Channel on

maintenance Manager (Online SwiftNet [Link] (Offline SwiftNet
security officers manage online security officers manage offline
SwiftNet security officers) security officers)

The profiles of the SwiftNet security officers (by means of RBAC roles for online security officers
and by means of a [Link] user profile for offline security officers) adhere to the principles of
need-to-know, least privilege, and separation of duties.
O2M and Secure Channel implement dual authorisation/four-eye features to enforce the separation
of duties.
It is important that customers carefully maintain their list of security officers (both online and offline),
and that they immediately revoke the security officer role when it is no longer valid.
For online security officers, this can be achieved by generating on a regular basis a security officer
role report on the SwiftNet Online Operations Manager, and by checking all DNs that have an
online security officer role. For these DNs, you should validate whether:
• You know which people own/use the DN.
• The people owning a DN still work for the institution.
• These people still need the security officer role.
For offline security officers, this activity can be managed from the "Manage Security Officer" section
in Secure Channel.

List of recommendations
ID Recommendation Product

SSO.01 The "need-to-know", "least privilege", and "separation of duties" principles O2M
are considered when defining Online SwiftNet security officers.
No business RBAC roles are assigned to the profiles of Online SwiftNet
security officers.

12 January 2024 33
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

SSO.02 A minimum of two online security officers are defined, unless administered O2M
by another institution (see Shared security officers on page 22), and a four-
eye authorisation scheme is used. Each has:
• A dedicated Distinguished Name (DN) and related valid SwiftNet PKI
Certificate
• RBAC roles and certificate management mandating a four-eye policy:
The corresponding two-eye RBAC roles are not assigned.
- [Link]//CertificateAdministration4eyes
- [Link]//Delegator//[Link]//Delegator4eyes
- [Link]//Delegator//[Link]//
CertificateAdministration4eyes
• Access to SwiftNet Online Operations Manager (O2M)
• A valid profile password

SSO.03 A minimum of two offline SwiftNet security officers is defined, unless Secure Channel
administered by another institution (see Shared security officers on page
22). Each has:
• A [Link] account under the appropriate 8-character BIC with the
"SwiftNet Live security officer" contact role and Secure Channel
application access
• A valid password
• An active secure code card (SCC) which contains highly confidential
information and is strictly for personal use only
Dual authorisation mode for security operations has been configured
on Secure Channel. This central setting will mandate four-eye policy for
offline requests. For more information, see change the authorisation
setting in the Secure Channel User Guide.

SSO.04 A procedure is in place to review at least annually the list of online O2M
(Security Officer Report on O2M) and offline ("Manage Security Profile" in
Secure Channel
Secure Channel) SwiftNet security officer and revoke when appropriate.
Customers must keep Swift informed of any changes to offline security
officer arrangements. For more information, see manage security profiles
in the Secure Channel User Guide.

SSO.05 An audit report that lists all past and ongoing offline SwiftNet security Secure Channel
officer activities in Secure Channel is generated and reviewed regularly (at
least annually, ideally more frequently).

SSO.06 A report on activity logs that lists all security management changes O2M (Activity
performed in the SwiftNet Online Operations Manager is generated and Log)
reviewed regularly (at least annually, ideally more frequently).

SSO.07 In case online or offline SwiftNet security officers are delegated to be O2M
administered by another institution, the same standard of care is applied
Secure Channel
as if operated within the originating institution.

You can separate PKI administration for the test environment by assigning security officers only the
"Lite Certificate Administrator LRA" and "Delegator Pilot" RBAC role. This will restrict the online

12 January 2024 34
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

security officer to managing only Alliance Lite2 certificates that can only sign pilot traffic and roles
for pilot services.
Best practice on PKI certificates administration by SwiftNet security officers is provided in PKI
Certificate Administration (SwiftNet Online Operations Manager and Alliance Gateway) on page
94.

[Link] Alliance Security Officers

Alliance security officers play a key role in configuring and managing the security functions within
Alliance Access/Entry. There are two security officers, a left security officer (LSO) and a right
security officer (RSO), which are created when the software is installed. They exercise dual control
over which users can sign in to Alliance Access/Entry and what they are allowed to do.
Typically, the left security officer's function resides in one department and the right security officer in
another department, with appropriate local back-up in place to cover for absences. With this set-up,
the creation of new profiles can be considered from business, IT/application, and other relevant
perspectives.
In addition, the Alliance security officers are defined in Secure Channel on [Link] to obtain the
Alliance licence details. It is recommended to align the Alliance security officers defined in Secure
Channel with the people acting as the LSO/RSO on the Alliance interface.

Extra security officers

To further strengthen the auditing of actions executed by LSO/RSO, it is possible to define
additional security operators in Alliance Access/Entry by assigning an operator the user type left
security officer or right security officer. Operations executed by LSO or RSO can be executed by
this extra security officer. There are two main advantages:
• Traceability of the human behind the LSO- or RSO-related activities: the extra security officers
log in with their specific user name and password.
• Resilience of operators performing security officer tasks.
To enable this feature, set the Alliance Access/Entry security parameter System - Extra sec
officer to Yes.
The term "security officers" refers to LSO, RSO, and to the extra security officers.
For all operators that are security officers, the Password Policy Type is set to Admin and the
Authentication Type has the same behaviour as for normal users, with the default value being
Password and TOTP.

The LSO/RSO operators are also subject to permanent disabling in case of multiple bad password
attempts or if they have not logged in for a configurable period of time. In case of an emergency
situation, where the LSO or RSO account is disabled, a break-glass procedure can be initiated to
unblock the situation. Follow the steps described in "Disabling a Security Officer" in the Alliance
Access Security Guide.

12 January 2024 35
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

List of recommendations
ID Recommendation Product

ASO.01 A minimum of two Alliance security officers are defined on [Link]. Each [Link]
has:
• a [Link] account under the appropriate 8-character BIC
• the "Is Alliance LSO" or "Is Alliance RSO" role assigned to their user
profile (not both, because this will enable the user to see the complete
master and initialisation password in the licence)
• access granted to the "Secure Channel" application (by means of the
[Link] user profile)
• a valid [Link] user password

ASO.02 A minimum of two Alliance security officers are defined on the Alliance Alliance
Access/Entry application (LSO/RSO or extra security officer). A single Access
individual does not have access to both the LSO and RSO accounts.
Alliance
Entry

ASO.03 Extra security officers are used next to the LSO/RSO, personal accounts
Alliance
enable easier tracking of actions performed by security officers.
Access
The initial LSO/RSO accounts are disabled.
Alliance
Entry

ASO.04 An internal procedure exists for the execution of the break-glass procedure. Alliance
Access
The steps are described in disabling a security officer in the Alliance Access
Security Guide. Alliance
Entry

ASO.05 A procedure is in place for the Alliance security officers to review on a Alliance
regular basis the operator profiles and operators defined on the system (for Access
example, to check for dormant users or to check the users which have their
Alliance
passwords expired, and to check with the business owner to confirm that
Entry
access is still required).

ASO.06 There is a generally approved and traceable workflow in place to track new Alliance
requests/updates of operators/profiles, as well as the integration with an exit Access
process (that is, when an employee changes roles or leaves the institution).
Alliance
Entry

ASO.07 In case the Alliance security officers roles (Alliance LSO, Alliance RSO, Alliance
extra security officers) are delegated to another institution, the same Access
standard of care as if operated within the originating institution is applied.
Alliance
Entry

Best practice on account management in Alliance Access/Entry by Alliance security officers is

provided in Logical Access Control on the Local Application Environment.

[Link] [Link] Administrators

Swift creates the two initial [Link] Administrators. A [Link] administrator can then delegate
the [Link] administrator contact role to another registered user.

12 January 2024 36
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

The user profiles on [Link] should adhere to the principles of need-to-know, least privilege, and
separation of duties.
The [Link] administrator can define the roles that require dual approval when these roles are
granted. As for now, dual approval only exists for granting or revoking the Alliance LSO/RSO roles
and [Link] administrators. It is strongly recommended to enforce dual approval for granting
these roles. It is important to maintain the proper separation of duties in the [Link] profiles.
The [Link] administrator can generate an audit report that contains all audit records for all
[Link] users in the scope of control of the administrator, for the indicated time period.
Alternatively, the audit report can be run for a single user. The maximum audit reporting period is
six months, if requested for all users. There is no time limit for single-user audit reports.

ID Recommendation Product

SCA.01 The "need-to-know", "least privilege", and "separation of duties" principles [Link]
are considered when defining users and standard profiles on [Link].

SCA.02 A minimum of two [Link] administrators are defined who administer the [Link]
users and permissions for your institution on [Link]. Each has a valid
[Link] user password.

SCA.03 [Link] accounts are reviewed at least annually (ideally more frequently) [Link]
and adjusted as required to enforce access security principles.

SCA.04 A procedure is in place for [Link] administrators to review on a regular [Link]

basis the list of dormant users (both normal and critical users) and track
whether access is still required (the User report can be used for this
purpose).
Expired profiles for normal users are disabled and will be deleted by Swift in
case of non-recovery within six months after profile expiry.
Expired profiles for critical users are never disabled or deleted. [Link]
administrators must remove the role from the profile before they can delete
the user profile.

SCA.05 An internal procedure is in place that alerts the [Link] administrator of [Link]
individuals leaving the company or moving internally.

SCA.06 Dual approval has been configured for granting/revoking Alliance LSO, [Link]
Alliance RSO, and [Link] administrator roles.

ASO.01 A minimum of two Alliance security officers are defined on [Link]. Each [Link]
has:
• a [Link] account under the appropriate 8-character BIC
• the "Is Alliance LSO" or "Is Alliance RSO" role assigned to their user
profile (not both, because this will allow the user to see the complete
master and initialisation password in the licence)
• access granted to the "Secure Channel" application (via the [Link]
user profile)
• a valid [Link] user password

SCA.08 A white list for authorised e-mail domain names has been configured on [Link]
[Link].

12 January 2024 37
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Other similar roles in [Link], yet limited to the management of end users for other [Link]
applications (for example, SwiftRef, Watch, or SEPAIO), must apply the same security controls
when practically applicable.
For more information, see the Identity Management Online Help.

[Link] Business Officers (FINCopy or SwiftNet Copy)

A business officer is a customer contact who represents the FINCopy or SwiftNet Copy Central
Institution towards Swift. Business officers can request emergency FINCopy or SwiftNet mode
changes, and emergency withdrawals of FINCopy or SwiftNet participants. A recommendation on
business officers is provided below:

ID Recommendation Product

SBO.01 A minimum of two business officers are defined, unless administered by

O2M
another institution (see Business Officers (FIN or SwiftNet Copy)). Each
business officer has: [Link]
• a [Link] account under the appropriate 8-character BIC with the "FIN
copy business officer" or "SwiftNet copy business officer" contact role
and Secure Channel application access
• a valid password
• an active secure code card (SCC) with them at all times

[Link] System Administrators

Operating systems usually feature an administrator account. This account is usually called
"administrator" on Windows systems, and "root" on UNIX/Linux systems. These are privileged
accounts, in that people acting as administrator are able to take complete and sole charge of the
system. If administrator/root credentials are stolen, then all application-level and server-level
defences can be compromised.
Swift recommends that access to such administrator-level operating system accounts is restricted
to the maximum extent possible. Instead, individual accounts with administrator-level privileges or
accounts with the ability to escalate to administrative access (such as 'sudo') are used.
Alliance software is usually installed using a specific operating system account. From this point on,
we will refer to this account as the "Alliance application owner".
The administrator and Alliance application owner are able to take complete and sole control of the
Alliance software. When securing your local Alliance infrastructure, you must treat Alliance
application owner accounts in the same way as you treat privileged accounts.
There is no real possibility to exercise four-eye control on operating system accounts. Therefore,
specific controls should be implemented to tightly control the use of the administrator or Alliance
application owner accounts in the local Alliance environment.
The administrator/root and Alliance application owner should adhere to the principles of need-to-
know, least privilege, and separation of duties.
Additional best practices guidance for the OS privileged accounts is provided in Operating System
Privileged Account Control (CSCF Control 1.2) on page 49.

12 January 2024 38
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

CSA.01 The administrator-level operating system accounts (administrator/root) and All

Alliance application owner are separated from the security officers functions.

[Link] Other Roles

Other technical and business roles include all staff having an account on the local Swift
infrastructure (for example, application administrators, business users, and so on). As defined in
the CSCF, all accounts must adhere to the principles of need-to-know, least privilege, and
separation of duties.
More detailed and specific information about logical access control applicable for Alliance
applications users is provided in Logical Access Control (CSCF Control 5.1) on page 82.

[Link] Organisation of the Security Officer Functions

The following table provides an overview of a typical organisation of the various security officer
functions. This is only an example of a good practice organisational set-up.

Function Role Area Comment

IT IT Security Business

Online SwiftNet ✔ Not to be

security officer combined with
the role of an
Alliance
Gateway
administrator

Offline SwiftNet ✔ Not to be

security officer combined with
the role of an
Alliance
Gateway
administrator

Alliance ✔ (LSO) ✔ (RSO) Not to be

security officer combined with
operational
duties, such as
sending and
receiving
messages, nor
with the
Alliance
administrator
role

Alliance ✔ (LSO) ✔ (RSO)

security officer
on [Link]

12 January 2024 39
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Function Role Area Comment

IT IT Security Business

[Link] ✔
administrator

Business officer ✔ ✔

Alliance Web ✔
Platform
Server-
Embedded
system
administrator

Alliance ✔
Gateway
system
administrator

Alliance Access ✔
system
administrator

HSM (account Admin ✔

owner)
Monitor ✔

Recover ✔

Operator ✔

HSM (PED Security officer ✔ (PED key

owners - keys
keys)
should be
stored in a safe)

Domain ✔

User ✔

5.1.2 Security Training and Awareness (CSCF Control 7.2)

To protect your local Swift infrastructure, it is important that your end users are aware of security
best practices and that they actively follow them.
Ensure that the people who have access to sensitive applications, data, PKI certificates, network,
security devices, and so on have an adequate knowledge level and are aware of the pertinent
cyber risks, best practice behaviours, and processes.

12 January 2024 40
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

UAW.01 Annual security awareness sessions are conducted for all staff members. All
In addition to CSCF examples, topics may include:
• protection from viruses, worms, Trojan horses, and other malicious
code - scanning and updating definitions
• unknown e-mail and attachments
• internet usage
• social engineering
• access control issues - address least privilege and separation of
duties
• individual accountability

UAW.02 Regular security and role-specific training sessions are conducted for All
Swift roles with privileged access. This applies and is not limited to
individuals having any of the following roles:
• operating system administrators (Administrator/root) and Alliance
software owner)
• security officers
• application administrators on Alliance interfaces
• HSM admin user
• [Link] administrators
The training is refreshed on a periodic basis.

UAW.03 Operators who have access to the local Swift infrastructure have an All
adequate level of Swift, security knowledge, and are aware of security
best practices and relevant security issues.
They are aware of their responsibilities regarding security threats and
practices.
This recommendation is particularly important for operators with
privileged access in local Swift Infrastructure.

UAW.04 Operators with access to system administrator accounts or Alliance OS

application owner accounts have the required operating system and
Alliance product knowledge and skills to perform their tasks.

For Swift-related products and services training, see Swift Smart, which is available to all users.

5.2 Local Network Security

The local network environment consists of the network devices (for example, routers, switches, and
firewalls) and connections used for the local Swift infrastructure.

12 January 2024 41
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Link with CSCF security controls

The CSCF security controls applicable to the local network environment are highlighted in the
following diagram:

CSCF
1.1 1.2 1.3A 1.4 1.5 2.1 2.2 2.3 2.4A 2.5A 2.6 2.7 2.8

2.9 2.10 2.11A 3.1 4.1 4.2 5.1 5.2 5.3A 5.4 6.1 6.2 6.3

6.4 6.5A 7.1 7.2 7.3A 7.4A

CSCF security control further detailed in this guide

CSCF security control relevant in this domain but covered in CSCF only

D1700006
Not relevant

The following CSCF controls have Alliance-specific security guidance (in addition to the CSCF
guidance) documented within this section:
• Swift Environment Protection (CSCF Control 1.1) on page 43
• Intrusion Detection (CSCF Control 6.5A) on page 46
The other relevant CSCF controls will not be discussed in depth in this document, but a high-level
context of how the controls relate to the Alliance products is provided below:
2.2 Security Updates - All network devices inside the secure zone are within the support life cycle
of the Vendor, have been upgraded with mandatory software updates, and have had security
updates promptly applied.
2.3 System Hardening - System hardening is conducted on the network supporting infrastructure
within the secure zone (for example, firewalls and routers).
2.8 Critical Activity Outsourcing - Outsourced network management operations supporting the
Alliance applications are considered a critical activity and must be protected, at a minimum, to the
same standard of care as if operated within the originating organisation.
3.1 Physical Security - All network devices used to define, protect, and manage the secure zone
hosting the Alliance applications are physically secured.
5.1 Logical Access Control - Access to network administrative tasks (including the administration of
firewalls and other sensitive network equipment) is restricted and assigned according to the
security principles of need-to-know access, least privilege, and separation of duties.
5.4 Physical and Logical Password Storage - Recorded passwords for privileged accounts of
network components are protected.
6.4 Logging and Monitoring - Capabilities to detect anomalous activity in the network within the
secure zone are implemented, and tools and process are in place to frequently store and review
logs.
7.3A Penetration Testing - Network penetration testing is conducted within the secure zone to
validate the operational security configuration and identify any security gaps.
7.4A Scenario Risk Assessment - Evaluation of risks within the local Swift infrastructure includes
risk scenarios targeting the supporting network components.
For more detailed implementation guidance, see the CSCF document.

12 January 2024 42
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

5.2.1 Swift Environment Protection (CSCF Control 1.1)

Network separation
The design of Alliance products provides the flexibility for customers to implement adequate
network separation in line with best practices. The concept of a secure zone hosting the Alliance
products is covered in Architecture Recommendations on page 26. In addition to the mandatory
boundary protection, customers can further control the communication between components in the
secure zone. A diagram and description are provided below.

Firewall
Alliance Web Platform
Server-Embedded

Firewall

Filtering Device
Alliance VPN
MQHA Alliance box
Gateway SNL
Access/Entry SWIFT IP
MQHA Network
SOAP
Firewall

RAHA
AFT RMA
Firewall

HSM
ADK IPLA WS

SWIFT mandated SWIFT network

Back office

D0540246
Customer responsibilities

Boundary protection
Transport layer stateful firewalls must be used to create logical separation at the boundary of the
secure zone. This is represented by the firewalls coloured in red in the diagram. As such,
customers must implement firewall rules between:
• the end user's browser and Alliance Web Platform Server-Embedded, allowing only HTTPS
traffic.
• Alliance Access/Entry and the back office, and between Alliance Gateway and the back office.
Regarding the "Filtering Device" shown in the above diagram, as per the Network Access Control
Guide, sections 2.3.1 and 2.5.1 through 2.5.3, the customer must secure the SwiftNet Link-VPN
connection. If SwiftNet Link connects to a network other than SIPN, then a mandatory filtering
device is required (such as a router with ACL or a firewall). For more information, see ID NET.07 in
this section.

Communication between components in the secure zone

Further security enhancements for the communication of components within the secure zone can
be achieved. This is represented by the firewalls coloured in blue in the diagram. The customers
can implement firewall rules between:
• Alliance Web Platform Server-Embedded and Alliance Access/Entry, which allow only SwTL (a
TCP-based Swift-proprietary transport protocol) based on Transport Layer Security (TLS), and
SOAP over HTTPS in the context of web services.

12 January 2024 43
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

• Alliance Web Platform Server-Embedded and Alliance Gateway, which allow only Swift
Transport Layer (SwTL, a TCP-based Swift-proprietary transport protocol) based on Transport
Layer Security (TLS).
• Alliance Access/Alliance Entry and Alliance Gateway, which allow only SwTL based on TLS.
As a general requirement, customers must ensure that their network (firewall) complies with the
Network Configuration Tables Guide, which strictly whitelists all flows required by the Swift
Network. Customers must also comply with the requirements for co-located and non-co-located
configurations, as described in the Network Access Control Guide. SwiftNet Link and Alliance
Gateway must only be installed and used on compliant networks.
In addition, management services (such as Remote Desktop) must not be accessible by means of
untrusted networks.
Information for Hardening Supported Operating Systems provides information regarding the
listeners used by Alliance products. This information can be used to configure host-based and
network-based firewalls.

ID Recommendation Product

NET.01 The network (firewall) complies with the Network Configuration SwiftNet Link
Tables Guide. It strictly whitelists all flows required by the Swift
network.

NET.02 Firewall rules are in place between the end user's browser and Alliance Web
Alliance Web Platform Server-Embedded, allowing only HTTPS. Platform Server-
Embedded

NET.03 Firewall rules are in place between Alliance Web Platform Alliance Gateway
Server-Embedded and Alliance Gateway, allowing only Swift
Alliance Web
Transport Layer (SwTL, a TCP-based Swift proprietary transport
Platform Server-
protocol) based on Transport Layer Security (TLS).
Embedded

NET.04 Firewall rules are in place between Alliance Web Platform Alliance Access/
Server-Embedded and Alliance Access/Entry, allowing only Swift Entry
Transport Layer (SwTL) based on TLS, and SOAP over HTTPS
Alliance Web
in the context of web services.
Platform Server-
Embedded

NET.05 Firewall rules are in place between the servers running Alliance Alliance Access/
products and the back-office applications. Entry
Alliance Gateway

NET.06 Firewall rules are in place to restrict remote login or access from All
your office automation LAN to the servers running Alliance
products.

NET.07 The link between SwiftNet Link and Alliance Connect (VPN SwiftNet Link
Boxes or VPN instances deployed in a public cloud environment)
Alliance Connect
is secured against any breach affecting its integrity or reliability.
A firewall remains a good practice, but can be replaced by
another mitigating control (such as a switch) as appropriate,
based on the customer-specific network set-up, security policies,
and risk appetite.

12 January 2024 44
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

NET.08 Management services are only accessible from dedicated All

operator PCs or by means of a jump server inside the secure
zone.

NET.09 The firewall rules and policies are regularly reviewed and All
adjusted.

NET.10 The firewall logs and other network devices logs are regularly All
monitored.

NET.11 A jump server is used to restrict access for the system All
administrators (for example, operating system administrators) to
the Alliance hosts. Alternatively, dedicated operator PCs (that is,
PCs located within the secure zone, and used only for secure
zone purposes) can be used as described in CSCF.
Note Swift does not give recommendations regarding
Vendors of jump servers.

Separation of Production and Test environments

It is a good security practice to separate Production and Test environments to reduce the risk of
unauthorised access, unauthorised changes, human errors, and so on. If not well protected, then
the testing environment can be a target for fraudulent activities (for example, using the test
environment to exchange live financial messages).
Swift provides various features to support the full separation of environments by customers. This
includes dedicated test messaging services, test BICs, Lite certificates, and so on.

ID Recommendation Product

CAD. Testing is not performed in the production environment. Alliance

01 Access/ Entry
Test systems are preferably fully separated from production systems
(that is, hardware and software, including separate HSMs) and Alliance
configured to only support test traffic (for example, by only using Lite Gateway
certificates and only configuring test logical terminals). This applies to
Alliance Web
all components of the local Alliance infrastructure used for the following
Platform
messaging services:
Server-
Embedded
• FIN
HSM
• FileAct
• InterAct SwiftNet Link

• WebAccess (including Browse)

If not fully separated, these systems must be maintained to the same
security level as the production systems.

CAD. Separate environments by using Lite certificates for signing test traffic O2M
02 (that is, test or development applications only use Lite certificates).

12 January 2024 45
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

5.2.2 Intrusion Detection (CSCF Control 6.5A)

Network intrusion detection systems
Network security devices, such as network intrusion detection systems and network behaviour
analysers, can be installed to detect malicious activity.

Ability to enable access logs for HTTP requests

A common defence strategy to detect intrusions is to log HTTP requests at the Application Server.
You can configure an Alliance Web Platform Server-Embedded instance to create the appropriate
logs. Once the configuration parameter [Link]:webAccessLogging is set, the
daily logs will be stored in <installRoot>/log.
From this location, your security monitoring tools can collect the information they need. This feature
is disabled by default.
Note Swift does not recommend specific Vendors of network intrusion detection systems.

ID Recommendation Product

NID.01 A network intrusion detection system is configured to detect anomalous Network (data
activity within the secure zone and at the boundary of the secure zone. exchange layer
and inside the
secure zone)

NID.02 Ensure that the configuration parameter Alliance Web

[Link]:webAccessLogging is set in Alliance Web Platform
Platform SE, for the ability to detect intrusions to HTTP requests at the Server-
application server and to define a monitoring process. Embedded

5.2.3 Other Security Best Practices

Connectivity
Swift provides various options to connect to the Swift Network. Customers can choose between
leased lines connections from Network Partners (multi-vendor model) or local Internet Service
Providers (ISPs).
Leased lines are not connected to the Internet and are therefore not subject to potential Denial of
Service (DoS) attacks. If a local ISP is chosen as a connectivity option, then protection against DoS
attacks should be implemented. Consult with your local ISP for more information.

ID Recommendation Product

CON.01 If a local ISP is used to connect to the Swift Network, then there is Alliance
additional protection in place against Denial of Service (DoS). Connect

Front-end reverse proxy

Alliance products run on top of several third-party products. Over time, vulnerabilities that could be
exploitable by attackers could be discovered in those products. Therefore, these products require
the regular installation of new updates or upgrades. Although Swift has developed Alliance Web
Platform Server-Embedded according to third-party specifications, the installation of updates on
systems running critical applications should be evaluated and tested by each customer. From the

12 January 2024 46
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

time that a vulnerability is discovered, until an update is installed, the system should be considered
at risk, and further mitigations should be implemented locally on the impacted system (for example,
increased monitoring).
The implementation of a reverse proxy or an application firewall as a front end to Alliance Web
Platform Server-Embedded is also an industry best practice against such risks. Alliance Web
Platform Server-Embedded supports such a configuration.

ID Recommendation Product

FRP.01 There is a reverse proxy or an application firewall as a front end to Alliance Web
Alliance Web Platform Server-Embedded. Platform
Server-
Embedded

5.3 Secure Local Server Environment

The local server environment consists of the servers that host Alliance products, and servers that
interact with the Alliance servers within the secure zone, and optionally, other servers that interact
but do not reside in the secure zone. These can be IBM MQ servers, Oracle database servers, or
other servers in the customer infrastructure. One compromised system can pose a threat for other
systems in the same network.

Link with CSCF security controls

The CSCF security controls applicable to the local server environment are highlighted in the
following diagram:

CSCF
1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4A 2.5A 2.6 2.7

2.8 2.9 2.10 2.11A 3.1 4.1 4.2 5.1 5.2 5.3A 5.4 6.1

6.2 6.3 6.4 6.5A 7.1 7.2 7.3A 7.4A

CSCF security control further detailed in this guide

CSCF security control relevant in this domain but covered in CSCF only
D1700007

Not Applicable

The following CSCF controls have Alliance-specific security guidance (in addition to the CSCF
guidance) documented within this section:
• Swift Environment Protection (CSCF Controls 1.1 and 1.4) on page 49
• Operating System Privileged Account Control (CSCF Control 1.2) on page 49
• Security Updates (CSCF Control 2.2) on page 52
• System Hardening (CSCF Control 2.3) on page 52
• Malware Protection (CSCF Control 6.1) on page 54

12 January 2024 47
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

• Logging and Monitoring (CSCF Control 6.4) on page 54

The other relevant CSCF controls will not be discussed in depth in this document, but a high-level
context of how the controls relate to the Alliance products is provided below:
2.5A External Transmission Data Protection - Swift-related sensitive data as per the customer's
internal data classification or applicable laws and regulations (including at a minimum: message
payloads, archives, passwords and other authenticators) is encrypted when data is taken out of the
secure zone (for example, back-ups and archives).
2.6 Operator Session Confidentiality and Integrity - The confidentiality and integrity of all interactive
sessions to operating systems hosting Alliance applications is safeguarded (for example, using a
cryptographic protocol such as ssh).
2.7 Vulnerability Scanning - Secure zone operating systems are scanned for vulnerabilities using
an up-to-date and reputable scanning tool.
2.8 Critical Activity Outsourcing - Outsourced security management and change management
operations of the hardware and operating system supporting the Alliance applications are
considered a critical activity and must be protected, at a minimum, to the same standard of care as
if operated within the originating organisation.
3.1 Physical Security - All hardware in the secure zone hosting or connecting to Alliance
applications are physically secured.
4.1 Password Policy - Careful consideration is given to the choice of passwords for administrator
accounts and the Alliance application owner accounts. The password policy for OS accounts is in
line with industry best practices, documented, communicated, and enforced.
4.2 Multi-factor Authentication - Multi-factor authentication is used for interactive user access to
jump servers and/or servers hosting Alliance software or applications that interact with this software
(for example, a hosted Oracle database).
5.1 Logical Access Control - Access to administrator-level and other operating system accounts is
restricted to the maximum extent possible and assigned according to the security principles of
need-to-know access, least privilege, and separation of duties.
5.4 Physical and Logical Password Storage - Recorded passwords for privileged accounts of
operating systems are securely stored and protected.
7.3A Penetration Testing - Penetration testing is conducted within the secure zone and on servers
hosting Alliance or related software.
7.4A Scenario Risk Assessment - Evaluation of the risks in the local Swift infrastructure includes
risk scenarios targeting the supporting operating systems.
For more detailed implementation guidance, see the CSCF document.

12 January 2024 48
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

5.3.1 Swift Environment Protection (CSCF Controls 1.1 and 1.4)

ID Recommendation Product

CIA.01 Server
All servers hosting Alliance applications are disconnected from the Internet,
hosting
except if the Swift product requires it (by means of VPN).
Alliance
Note Internet access from systems within the secure zone is highly Access/Entry
restricted and ideally blocked. If internet access is needed
Alliance
from within the secure zone, then access should be granted
Gateway
only to whitelisted URL destinations by means of a proxy with
content inspection and adequate blocking/filtering controls. Alliance Web
Connections are only permitted if initiated in the outbound Platform
direction. Server-
Embedded

CIA.02 Jump servers, which are used to remotely manage the operating systems Jump server
on which Alliance products are installed, do not have Internet access.

CIA.03 System administrators connect through a jump server or a dedicated Alliance

operator PC within a secure zone to servers hosting Alliance applications. Access/
Entry
Alliance
Gateway
Alliance Web
Platform
Server-
Embedded

CIA.04 The Alliance applications are not co-hosted All

Alliance Web Platform Server-Embedded is deployed on a different host
from Alliance Access/Entry or Alliance Gateway (especially is application
users are not connecting over a jump server).
Additionally, it is good practice for Alliance Access/Entry and Alliance
Gateway to be on separate hosts for resilience purposes.

5.3.2 Operating System Privileged Account Control (CSCF

Control 1.2)
There is limited need for the usage of the Administrator or root user account, because these types
of users have extensive privileges. Swift provides the option to install the software as a non-root
user. This requires the root user to perform some prerequisites before the installation can proceed,
however a non-root should then be used to install and own the software. In addition, on Windows,
Swift made it possible to start Alliance Access/Entry, Alliance Gateway, and Alliance Web Platform
Server-Embedded as a system service, which means that you do not need a named user to start
the services.
Alliance Access/Alliance Entry on Windows
• Windows Application Owner (Alliance Administrator)
Alliance Access/Alliance Entry requires a user account on Windows that is not part of the
Administrator group to be defined as the application owner. The application owner will become
the Alliance administrator.

12 January 2024 49
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Installation-related tasks
Only a user with Administration permissions on Windows can install, upgrade, or uninstall
Alliance Access/Alliance Entry. On the Windows platform, accounts for the installation and
running of Alliance can be separated.
Administration tasks
The application owner can perform specific actions on Alliance Access/Alliance Entry, for
example, install and uninstall an update, perform back-ups, export/import configuration data,
start/stop applications, and launch the Alliance Access/Alliance Entry tools.
Alliance Access on AIX or Linux
• AIX/Linux Application Owner (Alliance Administrator)
Alliance Access requires a non-root user account to be defined as the application owner. The
application owner will become the Alliance administrator.
Installation-related tasks
You can install Alliance Access either as root, or with the application owner account (non-root).
However, the root account must perform specific tasks before and after the installation, such as
create the Software Owner Account and execute additional tasks after a non-root installation.
Alliance Access cannot be completely removed using the non-root account.
Administration tasks
The application owner can perform specific actions on Alliance Access, for example, install and
uninstall an update, perform back-ups, export/import configuration data, start/stop applications,
and launch the Alliance Access tools.
An example that compares the roles of the Alliance Administrator and UNIX or Linux System
Administrator ("root") as applied to the system configuration, installation, and ongoing
maintenance of the Alliance Interface is provided in the Alliance Access Security Guide.

Alliance Gateway/SwiftNet Link

• Administrative privileges are no longer required to launch Alliance Gateway or SwiftNet Link.
Administrator privileges are required only for installation, upgrade, and uninstallation activities.
• On UNIX or Linux, the installation can be performed by root and non-root. The non-root account
will be the application owner and must have the required settings (the ulimit parameters and the
IPC resources).

Alliance Web Platform Server-Embedded

• Windows: You must have one user account on Windows that is not part of the Administrator
group. This account will be the application owner and will manage the Alliance Web Platform
Server-Embedded applications. However, installation and un-installation must be done by an
administrator.
• UNIX or Linux: The installation can be performed by root and non-root. The non-root account
will be the application owner and must have the required settings (the ulimit parameters and the
IPC resources).

12 January 2024 50
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

List of recommendations
ID Recommendation Product

OSP.01 Careful consideration is given to who is assigned the All

role of administrator or the role of Alliance application
owner.
The use of the administrator and Alliance application
owner accounts is tightly controlled (that is, by
limiting the number of people on a strict need-to-
know/need-to-change basis, and by monitoring
usage).

OSP.02 The administrator account and Alliance application All

owner account are not personal accounts. As such,
(SLA.06
there are procedures in place to:
used in
Security • Identify the specific individual who is logged in to
Best such an account
Practices
• Identify which commands are run on such an
Check
account.
Tool)

OSP.03 Ensure that Alliance application cannot be modified Alliance Access/

by a non-Alliance application owner. In this case, the Entry
software files should not have write-execute
Alliance
permission granted to others.
Gateway
Alliance Web
Platform Server-
Embedded
SwiftNet Link

OSP.04 A mechanism such as 'sudo' is used to ensure All

individual accountability when using privileged
accounts.

OSP.05 All
There is an emergency procedure to access the
servers with the administrator account or Alliance
application owner account. An emergency procedure
is helpful when the authorised people are unavailable
due to unexpected circumstances.
The emergency procedure is documented, and the
usage of the procedure is logged. Under no
circumstances should it allow a non-authorised
person to access the Alliance hosts unnoticed.

OSP.06 The Alliance applications are configured to run as a OS: All Windows
Windows service. systems hosting
Swift products
All products

12 January 2024 51
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

5.3.3 Security Updates (CSCF Control 2.2)

Operating system and other software
Operating systems and other software used by Alliance products (and all systems in the secure
zone), should be updated with the latest security updates that are made available by the Vendor.
Security updates contain corrective actions that prevent the successful exploitation of known
security vulnerabilities. The customer can contact their Vendor for more information and
recommendations. In the absence of established internal processes and timelines, Swift
recommends the use of Common Vulnerability Scoring System (CVSS) Version 3 as a guideline for
criticality, with the update deployment targets as defined in the CSCF.
For more information about CVSS, see Knowledge Base article 5021460.
Qualified operating systems (OS)
The operating systems for which the Alliance applications are supported are provided in the
following table:

Alliance software Operating systems

Alliance Access AIX, Red Hat Enterprise Linux, Windows

Alliance Entry Windows

Alliance Gateway/SwiftNet Link AIX, Red Hat Enterprise Linux, Windows

Alliance Web Platform SE AIX, Red Hat Enterprise Linux, Windows

A detailed overview of the related OS levels and the OS patches (updates) that are used to qualify
the Alliance products is provided in the OS Levels and Patches Baseline document.
Swift provides support for higher versions of these operating systems, as outlined in Knowledge
Base article 1212959.
Swift strongly recommends that minor updates are qualified by the customer as part of their regular
change management process.
The Alliance Product Family Compatibility Matrixes provides compatibility scenarios of the various
supported Alliance products against the related releases and operating systems.

ID Recommendation Product

SSP.01 The local server infrastructure (such as operating system and third-party All
software) is up-to-date with the latest security updates.

5.3.4 System Hardening (CSCF Control 2.3)

Operating system hardening
Operating system hardening can be used to make the configuration of Alliance servers more
secure. In most cases, operating system hardening uses the existing features of the operating
system.
Swift provides an updated OS hardening guide (Information for Hardening Supported Operating
Systems) with each annual update. This document provides guidance for implementing system

12 January 2024 52
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

hardening on all supported operating systems as well as the relevant CIS benchmarks that were
used to qualify the Alliance products.
Customers can also take advantage of third-party tools that are provided with the supported
operating systems. Some of the available tools are provided for reference below:
AIX
• Power SC (installable package, part of Enterprise Edition)
Red Hat Enterprise Linux
• OpenSCAP as part of Red Hat Enterprise Linux
• Several profiles available, including PCI-DSS
Windows
• SCAP Extensions for Microsoft System Center Configuration Manager
Note Swift does not certify any specific solution.

Process whitelisting tools

One of the potential defences against cyber threats is the use of tools that validate that only
whitelisted processes are started. To be able to deploy such tools on the servers hosting Alliance
products, you need to know which processes are used by each application.
Alliance Access/Entry
Swift provides a whitelist of files together with Alliance Access/Entry. These files contain a list of
executables and libraries that are part of the product. The files have the following names:
• saa_whitelist_embedded.txt for Alliance Access with embedded database
• saa_whitelist_hosted.txt for Alliance Access with hosted database
• sae_whitelist.txt for Alliance Entry

The whitelist files are stored in the $ALLIANCE/data directory.

SwiftNet Link
Swift provides together with the installation software a list of files that can be monitored by the
customer.
For SwiftNet Link, these files are listed in the snl_allowlist.txt file, located in the SWNET_HOME/
data directory.

Alliance Web Platform Server-Embedded

Swift provides together with the installation software a list of files that can be monitored by the
customer as part of the whitelist for Alliance Web Platform Server-Embedded.
The files used by Alliance Web Platform Server-Embedded are listed in the swp_whitelist.txt
file, located in the SWP_INSTALL_PATH/data directory.

List of recommendations
ID Recommendation Product

OSH.01 The operating systems and other software that are installed on the servers Operating
that host Alliance products are hardened and configured according to the system
third-party Vendor recommendations and security baselines.

12 January 2024 53
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

OSH.02 No other software is installed on Alliance servers, except for the software Operating
needed to operate, monitor, and secure Alliance products. system

OSH.03 A whitelisting process takes in account and monitors the files used by the Operating
Alliance products. system

5.3.5 Malware Protection (CSCF Control 6.1)

Security software, such as anti-malware, must be installed to prevent, detect, and remove
malicious software.
Swift has not qualified Alliance software with specific security software. It is the customer's
responsibility to test and assess any impact on performance as a result of installing security
software, as well as to keep their anti-virus and anti-malware services up-to-date.
Note Swift does not recommend specific Vendors of anti-malware software.

ID Recommendation Product

IDS.01 Security software is installed to protect against malicious software or other All
threats.

General recommendations for running Swift Interfaces with anti-malware software are provided in
Knowledge Base article 5020533.

5.3.6 Logging and Monitoring (CSCF Control 6.4)

Operating system activity logging

Operating systems enable you to log information that helps you identify certain users and the
commands they run. Actively monitoring such logs can help you capture malicious activity on your
systems. Furthermore, safestoring such log files can help you during forensic investigations.
A Security Information and Event Management (SIEM) system enables the gathering and analysis
of information from multiple hosts and applications in a central location. Customers that deploy
such a solution can consider integrating and analysing the logs of operating systems used for
Alliance products.
Note Swift does not give recommendations regarding Vendors of Security Information and
Event Management (SIEM) systems.

12 January 2024 54
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

SLG.01 Operating system log files are monitored and regularly reviewed. Such logs All
can contain and are not limited to:
• administrator-level operating system accounts activity log
• Alliance application owner activity log
• relevant Alliance application events distributed to the operating system
logs (for example, Alliance Access event logs stored in Syslog in CEF
format).

SLG.02 Operating system logs are stored on a remote system that cannot be All
accessed by the same operating system privileged account or by the same
individuals.

SLG.03 Log files are retained (safestored) for a least 12 months and are available for All
audits or forensic investigations.

SLG.04 Where possible, the operating system log files are integrated with a All
centralised logging system.

5.4 Secure Local Client Environment

The local client environment is composed of operator PCs that are used to access the components
within a secure zone (for example, Alliance applications, the servers hosting them, and firewalls)
and other devices located in the workplace environment and used for Swift operations (for
example, printers used for Swift transactions).
These can be hosts that have a browser installed to connect to Alliance Web Platform Server-
Embedded applications, or hosts that are used to remotely manage the operating systems on
which Alliance products are installed.
Link with CSCF security controls
The CSCF security controls applicable to the local client environment are highlighted in the
following diagram:

CSCF
1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4A 2.5A 2.6 2.7

2.8 2.9 2.10 2.11A 3.1 4.1 4.2 5.1 5.2 5.3A 5.4 6.1

6.2 6.3 6.4 6.5A 7.1 7.2 7.3A 7.4A

CSCF security control further detailed in this guide

CSCF security control relevant in this domain but covered in CSCF only
D1700008

Not Applicable

12 January 2024 55
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

The following CSCF control has Alliance-specific security guidance (in addition to the CSCF
guidance) documented within this section:
• Swift Environment Protection (CSCF Control 1.1 and 1.4) on page 57
The other relevant CSCF controls will not be discussed in depth in this document, but a high-level
context of how the controls relate to the Alliance products is provided below:
2.2 Security Update - All hardware and software of operator PCs (or jump servers) are within the
support life cycle of the Vendor, have been upgraded with mandatory software updates, and have
had security updates promptly applied.
2.3 System Hardening - Security hardening is conducted on all operator PCs (or jump servers).
2.5A External Transmission Data Protection - Sensitive Swift-related data leaving the dedicated
operator PC (or jump server) within the secure zone is encrypted.
2.6 Operator Session Confidentiality and Integrity - The confidentiality and integrity of all interactive
sessions to operator PC (or jump server) operating systems is safeguarded (for example, by using
a cryptographic protocol such as ssh). Operator sessions have an inactivity lock-out feature that
limits the session to the minimal time frame necessary to perform business-as-usual duties.
2.7A Vulnerability Scanning - Operator PC (or jump server) systems are scanned for vulnerabilities
using an up-to-date and, reputable scanning tool.
2.8 Critical Activity Outsourcing - Outsourced security management and change management
operations of operator PCs and other devices located in the workplace environment and used to
access the Alliance applications are considered a critical activity. They must be protected, at a
minimum, to the same standard of care as if operated within the originating organisation.
3.1 Physical Security - Operator PCs and other devices used for Swift operations are located in a
secure workplace environment and their access is restricted.
4.1 Password Policy - Operating system accounts used for login to operator PCs (or jump servers)
use passwords that are aligned to current industry standards or industry best practices and with
appropriate parameters such as length, complexity, validity, and the number of failed login
attempts.
4.2 Multi-factor Authentication - Multi-factor authentication is used for operating system
administrators at the secure zone boundary (jump-server) or at the dedicated operator PC login.
For end users, the prioritised order for implementing multi-factor authentication is on the individual
Alliance application (Alliance Web Platform SE, Alliance Access/Entry, and Alliance Gateway), at
the secure zone boundary (jump server) or at the dedicated operator PC login.
5.1 Logical Access Control - Access to operator PCs and other devices (for example, printers used
for Swift operations) in the workplace environment is assigned according to the security principles
of need-to-know access, least privilege, and separation of duties. The logical access control to
Alliance applications is covered in Logical Access Control (CSCF Control 5.1) on page 82.
5.4 Physical and Logical Password Storage - Recorded passwords for privileged accounts of
operator PCs are protected.
6.1 Malware Protection - Anti-malware services and their associated databases are up-to-date on
the client host infrastructure.
6.4 Logging and Monitoring - Capabilities to detect anomalous activity in the network within the
secure zone are implemented, and tools and process are in place to frequently store and review
logs.
7.3A Penetration Testing - Operator PCs are in the scope of regular penetration testing exercises
for the local Swift infrastructure.

12 January 2024 56
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

7.4A Scenario Risk Assessment - Evaluation of the risks in the local Swift infrastructure includes
risk scenarios targeting the operator PC (or jump server).
For more detailed implementation guidance, see the CSCF document.

5.4.1 Swift Environment Protection (CSCF Control 1.1 and 1.4)

Internet access
When a device can connect to the Internet, it is open to many additional security threats. If such a
device can also connect to the local Swift environment, then you are also exposing your Swift
environment to those threats.

ID Recommendation Product

SEP.01 Restrict internet access on the operator PCs that have a browser installed Operator PC
to connect to Alliance Web Platform Server-Embedded applications,
using one of the following options:
• Internet access using a remote desktop or virtualisation solution
• Internet access from the operator PC to only whitelisted URL
destinations by means of a proxy with content inspection, in
combination with adequate blocking/filtering controls and permitting
only outbound-initiated connections.
• No Internet access

5.4.2 Other Security Best Practices

Secure browser practices

Browsers must be running on the Windows operating system and must be configured with TLS 1.2
(or later) enabled.
In addition to technical security controls, operators must follow security best practices while
browsing and mailing on the local operator PC used to connect to Alliance applications.
Some general DOs and DON'Ts that are best practices for operating the local client environment
are provided below.

Do:
• Always restart your browser instance before and after accessing Alliance applications.
• Avoid installing browser plugins unless explicitly mandatory, trusted, and signed.
• Be suspicious of e-mails containing hyperlinks, documents with macros, or executable
attachments.
• If you suspect you have received a phishing e-mail impersonating Swift, then report this to Swift.

Do not:
• Browse the Internet from the PC where you access critical functionality, including Alliance.
• Browse any other site at the time you access Alliance Web Platform Server-Embedded
application up until you have ended your session.

12 January 2024 57
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

• Accept a pop-up asking you to download and install executables or download files or programs
from unknown websites or sources.
• Follow links in e-mails that would pretend to direct you to Alliance applications.
• Click a hyperlink contained in an e-mail, even if that URL seems perfectly valid from a business
perspective. Instead, once you confirmed the business need to visit that site, re-type the URL
within the browser as it was visible in the mail. If this hyperlink is too long, then hover over the
hyperlink to verify the domain name and to verify whether the communication between the
browser and the website is encrypted (that is, the link uses HTTPS). Phishing attacks can lead
to rogue sites that could steal information or infect your PC.

5.5 Secure Local Application Environment

The local application environment is composed of Alliance applications (Alliance Access/Entry,
Alliance Web Platform SE, Alliance Gateway, and SwiftNet Link) and associated security devices
(HSM Boxes and HSM Tokens) hosted in the secure zone.
Alliance products provide a number of security features designed to mitigate security threats. Most
of these features are enabled by default, while some are configurable to best suit the internal
security policies of customer organisations. Swift recommends configuring all features described in
this section.

Link with CSCF security controls

The CSCF security controls applicable to the local application environment are highlighted in the
following diagram:

CSCF
1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4A 2.5A 2.6 2.7

2.8 2.9 2.10 2.11A 3.1 4.1 4.2 5.1 5.2 5.3A 5.4 6.1

6.2 6.3 6.4 6.5A 7.1 7.2 7.3A 7.4A

CSCF security control further detailed in this guide

CSCF security control relevant in this domain but covered in CSCF only
D1700009

Not Applicable

The following CSCF controls have Alliance-specific security guidance (in addition to the CSCF
guidance) documented within this section:
• Internal Data Flow Security (CSCF Control 2.1) on page 59
• Security Updates (CSCF Control 2.2) on page 62
• Back-office Data Flow Security (CSCF Control 2.4A) on page 64
• Operator Session Confidentiality and Integrity (CSCF Control 2.6) on page 68
• Transaction Business Control (CSCF Control 2.9) on page 69
• Relationship Management Application (RMA) (CSCF Control 2.11A) on page 72

12 January 2024 58
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

• Password Policy (CSCF Control 4.1) on page 73

• Multi-factor Authentication (CSCF Control 4.2) on page 80
• Logical Access Control (CSCF Control 5.1) on page 82
• Token Management (CSCF Control 5.2) on page 99
• Software Integrity (CSCF Control 6.2) on page 101
• Database Integrity (CSCF Control 6.3) on page 102
• Logging and Monitoring (CSCF Control 6.4) on page 104
The other relevant CSCF controls will not be discussed in depth in this document, but a high-level
context of how the controls relate to the Alliance products is provided below:
1.1 Swift Environment Protection - Alliance applications are located in a separated secure zone
and protected from attacks in the general IT and external environment.
2.7A Vulnerability Scanning - Swift-related applications are scanned for known vulnerabilities using
an up-to-date and reputable scanning tool.
2.8 Critical Activity Outsourcing - Any outsourced operations and management activities of the
Alliance applications are considered a critical outsourcing activity and must be protected, at a
minimum, to the same standard of care as if operated within the originating organisation.
5.4A Physical and Logical Password Storage - Recorded passwords for accounts of Alliance
interfaces, O2M, and [Link] are protected.
7.4A Scenario Risk Assessment - Evaluation of the risks in the local Swift infrastructure includes
risk scenarios targeting the Alliance applications and associated security devices (such as HSM
boxes, HSM tokens, Remote PED Key, PED devices, and PED keys).
For more detailed implementation guidance, see the CSCF document.

5.5.1 Internal Data Flow Security (CSCF Control 2.1)

All data flows between Alliance products are protected by means of various security mechanisms
to support the confidentiality, integrity, and mutual authentication of the data flows. This includes
the following data flows:
• Alliance Web Platform Server-Embedded to Alliance Access/Entry
• Alliance Web Platform Server-Embedded to Alliance Gateway
• Alliance Access/Entry to Alliance Gateway
In addition, the communication between operator PCs and the Alliance products is protected to
support the confidentiality, integrity, and authentication of the connection.

12 January 2024 59
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

A high-level overview of the security mechanisms deployed between Alliance products and
operator PCs is provided below:

2FA Alliance Access

or
Alliance Entry

TLS Alliance TLS + LAU

TLS
Web
2FA Platform SE TLS
Operator

Alliance SWIFTNet
Link
Gateway

TLS

2FA HSM

D1700010
Security mechanisms
Between operator PC and Alliance applications
Connection and data flows between the operator PC and Alliance Web Platform SE, Alliance
Access/Entry, and Alliance Gateway are protected by means of the following security mechanisms:
• One-way Transport Layer Security (TLS) protocol for integrity, encryption, and authentication
from browser to Alliance Web Platform SE.
Alliance Web Platform Server-Embedded is authenticated using a TLS server certificate, which
can be self-signed or signed by a Certificate Authority (CA). Self-signed certificates provide
confidentiality and integrity protection, but not authentication (unless the certificates are
explicitly trusted by the operator PC browser). It is preferred that a trusted CA is used to provide
the server certificates, provided that the signing CA keys are well protected (for example, HSM
used for the CA's private key, four-eye needed for CA maintenance, and so on). Swift
recommends using a recognised CA or a CA under the customer's control.
• Multi-factor authentication (embedded 2FA, RADIUS, LDAP, or customer-hosted Identity
Provider (IdP)) to authenticate the operators in Alliance Access/Entry, Alliance Gateway, and
(embedded 2FA) Alliance Web Platform SE.
Between Alliance Web Platform SE and Alliance servers
Data flow between Alliance Web Platform SE and the Alliance Access/Entry or Alliance Gateway
interface are protected by means of a one-way TLS connection for confidentiality, integrity, and
authentication.
This includes the operator's user name and the password that are exchanged between Alliance
Web Platform SE and the Alliance server. Alliance Web Platform SE also authenticates the Alliance
backend server (Alliance Access/Entry and Alliance Gateway) using a TLS server certificate, which
can be self-signed or signed by a Certificate Authority (CA).
Between Alliance Access/Entry and Alliance Gateway
Alliance Gateway relies on SwiftNet Link and the HSM boxes to perform signing and verification of
messages using the SwiftNet Public Key Infrastructure. As a consequence, the connection

12 January 2024 60
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

between Alliance Access/Entry and Alliance Gateway must be secured to enable the secure
transmission of Swift messages.
Data flow between Alliance Access/Entry and Alliance Gateway is protected by means of one-way
TLS and Local Authentication (LAU) to guarantee confidentiality, integrity, and mutual
authentication.
It is recommended to keep the default value Data Encryption/Host Authentication in the
Alliance Gateway Connection Details window of Alliance Access/Entry when you add a Gateway
connection. This value provides two-way encryption of data sent between Alliance Access/Entry
and Alliance Gateway. In addition, Alliance Access/Entry checks the certificate of Alliance Gateway
to verify that it communicates with the Alliance Gateway that it expects.
Between SwiftNet Link and HSM

For daily operations, SwiftNet Link and HSM boxes communicate through TLS secured
connections. After a Hardware Security Module Box cluster is configured and registered,
cryptographic and key management operations are performed through a TLS connection between
the HSM client on the SwiftNet Link host and the HSM cluster. To secure these connections,
certificates are created and used on the SwiftNet Link (the client certificate) and on the HSM boxes
(the server certificate), which equates to two-way TLS.
The certificate on the Hardware Security Module Box is called the HSM cluster certificate.
Use of encryption for internal data flow
Use one of the recommended methods in Knowledge Base article 5021566 to ensure the integrity
and confidentiality of the data flow.
All customer local network traffic between Swift applications is encrypted using TLS one-way
authentication in combination with LAU, or two-way TLS. This ensures confidentiality and integrity
on the network and protects against replay attacks, which is a particular type of network attack that
maliciously or fraudulently repeats valid data transmission.
All Alliance products use a TLS version of at least 1.2 for TCP/IP connections. As of Release 7.6,
TLS 1.3 is also available.

List of recommendations
ID Recommendation Product

LSC.01 Certificates issued by a trusted Certificate Authority (CA) Browser

or a Certificate Authority under the customer's control are
Alliance Web Platform
used to secure the connections to the Alliance products.
Server-Embedded
Otherwise, self-signed certificates are explicitly trusted.
This applies to the following connections:
• between Browser and Alliance Web Platform SE
• between Alliance Web Platform SE and Alliance
Access/Entry
• between Alliance Web Platform SE and Alliance
Gateway

LSC.02 Ensure that the following certificates are not expired: All
• Alliance Web Platform SE certificate
• Alliance Access/Entry certificate
• Alliance Gateway certificate

12 January 2024 61
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

LSC.04 Data encryption/host authentication is used between Alliance Access/ Entry

Alliance Access/Entry and Alliance Gateway.
Alliance Gateway

Further reading
• Alliance Access Administration Guide - swrpc_keytool (AIX, Linux, Windows)
• Alliance Access Administration Guide Guide - saa_configconnection (AIX, Linux, Windows)
• Alliance Access Configuration Guide - Add an Alliance Gateway Connection
• Alliance Entry Administration Guide - swrpc_keytool
• Alliance Entry Administration Guide - saa_configconnection
• Alliance Entry Configuration Guide - Add an Alliance Gateway Connection
• Alliance Gateway Administration and Operations Guide - Manage Private Keys and Certificates
• Alliance Gateway Administration and Operations Guide - TLS Security
• Alliance Gateway Administration and Operations Guide - Local Authentication and Security
• Alliance Web Platform Server-Embedded Administration and Operations Guide

5.5.2 Security Updates (CSCF Control 2.2)

Swift software releases or updates

Alliance products software should be updated with the mandatory releases, before the mandatory
installation date.
Swift announces scheduled dates for general availability of new updates and releases through the
Release Overview, the Swift Release Timeline, or other relevant documentation.
A Software Version Check Tool checks the product version against SwiftNet and notifies you if an
outdated system is deployed. The software version check is performed automatically by the
application, which logs an event to indicate which product version is running and which version is
available on the Download Centre. Additionally, if the application is out of support, the Software
Version Check Tool notifies every user who connects to the application.

Swift security updates

Security updates contain corrective actions that prevent the successful exploitation of known
security vulnerabilities. Swift regularly provides updates that introduce only security changes to a
single Alliance application (for example, the security update provides security hotfixes and security
updates to Commercial off the Shelf (COTS) embedded products).
Alliance software should be updated with the latest security updates that are made available by
Swift in line with the Swift Customer Security Controls Framework, as follows:
• Cumulative and mandatory February security update - This type of security update is mandatory
and must be applied within two months or, in the case of a critical rating (9.0+ CVSS v3), one
month as from General Availability. For the latest information about Alliance application releases
and security updates, see SwiftNet and Alliance Release Policy.
• Quarterly security updates - Internal risk assessment process and timelines, or Common
Vulnerability Scoring System (CVSS) Version 3.

12 January 2024 62
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Severity Level CVSS Score Deployment Target

Critical 9.0+ Within one month of release of

the update

High 7.0 -8.9 Within three months of release of

the update

Low / Medium < 7.0 As soon as reasonably

practicable

With each security update, Swift provides a release letter for each product that describes which
security updates have been added, their CVSS v3 rating, and how to install them.

Security Best Practice Check Tool

The Security Best Practice Check Tool provides a report of configuration linked to the Security
Controls, to help you evaluate if Alliance or SwiftNet Link configurations are aligned with the
Customer Security Programme security guidelines.
The Security Best Practice Check Tool is packaged and installed with SwiftNet Link or Alliance on
the same server.
The Security Best Practice Check Tool report directory is only accessible by the authorised
SwiftNet Link or Alliance instance owner OS account. The report files are strictly protected at the
OS level and cannot be modified.
The report does not interpret the results of the security check, but rather displays the output of the
relevant configuration details.
The relevant Swift product must be fully up and running to execute all checks. If the product is not
operational, then certain checks, such as certificate checks, cannot be performed.

ID Recommendation Product

CTA.01 The Security Best Practice Check Tool is run regularly on Alliance Alliance
applications. The output is validated to ensure that security items are Access/
configured properly. Entry
Alliance Web
Platform
Server-
Embedded
Alliance
Gateway
SwiftNet Link

More information about the Security Best Practices Check Tool can be found in the respective
Security Guide or Release Letter for each product.
For a detailed output of the Security Best Practices Check Tool, see the following Knowledge Base
articles:
• For Alliance Access/Entry, see 5022116.
• For SwiftNet Link, see 5022173.
• For Alliance Web Platform Server-Embedded, see 5022174.

12 January 2024 63
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

• For Alliance Gateway, see 5022175.

Default distribution
Swift makes available all supported releases and security updates of Alliance applications on the
Download Centre.

ID Recommendation Product

SSP.01 The Alliance products and related embedded or hosted Oracle All
database are up-to-date with the latest security updates, aligned to
the assessed risk or CVSS, v3.

SSP.02 Recommended Alliance product releases or security updates are All

installed on a timely basis and for mandatory releases or cumulative
security updates, before the mandatory installation date.

5.5.3 Back-office Data Flow Security (CSCF Control 2.4A)

The data flows between back-office (or middleware) applications and Alliance Access, Alliance
Entry, or Alliance Gateway applications should be protected.

Back-office application
A back-office application is defined as a customer application that connects to the Alliance products
in one of the following ways:
• Customer application connected to Alliance Access or Alliance Entry
• Customer application connected to Alliance Gateway by means of the MQHA or RAHA adapter,
and the related message partner is configured in the appropriate mode (that is, as
recommended by the Vendor)
Customer applications using other ways of connectivity with Alliance Gateway and SwiftNet Link
products are considered as Messaging Interfaces and must meet the requirements of the Swift
Compatible Interface Programme of Swift and be in the scope of the CSCF.

12 January 2024 64
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Security mechanisms
Alliance products provide various confidentiality, integrity, and mutual authentication mechanisms to
protect the data flows exchanged with back-office applications. An overview of these security
mechanisms for each application and type of connector is provided below:
• Between back-office applications and Alliance Access

Confidentiality Authentication Integrity

File Transfer
p AES-GCM p LAU p LAU
p XML-DSig p XML-DSig
p AES-GCM p AES-GCM

MQ
p LAU p LAU
MQ Channel
p XML-DSig p XML-DSig
Encryption
p AES-GCM p AES-GCM
p PKI (for XML p PKI Alliance
Back-office format)
Applications
Access
SOAP
pTLS (AES-GCM) p LAU p LAU
p XML-DSig pTLS (AES-GCM)
p XML-DSig

Integration Platform
p XML-DSig p XML-DSig
Per customer demand Per customer demand Per customer demand

Direct FileAct
p AES-GCM p AES-GCM p AES-GCM
p LAU p LAU

D1700011
• Between back-office applications and Alliance Entry

Confidentiality Authentication Integrity

Alliance
File Transfer
Entry
AES-GCM AES-GCM AES-GCM
Back-office
LAU LAU
Applications
XML-DSig XML-DSig

Direct FileAct
AES-GCM AES-GCM AES-GCM
LAU LAU
D1700012

12 January 2024 65
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

• Between back-office applications and Alliance Gateway

Confidentiality Authentication Integrity

RAHA
p TLS p LAU p LAU
p TLS
Alliance
MQ
Gateway
MQ Channel p LAU p LAU
Back-office
Applications
Encryption

D1700013
Customers can use the security mechanism provided by Swift in combination with other internal
security mechanism as applicable (for example, using the MQ Channel encryption in the case that
IBM MQ solutions are used, SFTP for file transfer exchange, and so on).
Local Authentication (LAU)
Alliance Access/Entry and Alliance Gateway provide a Local Authentication mechanism to improve
the security of the message flow between customer back-office applications and Alliance Access/
Entry/Gateway. Local Authentication guarantees both the identity of the sending application and the
integrity of the message.
Local Authentication is based on a Keyed-Hash Message Authentication Code (HMAC) and the
SHA-256 hashing algorithm, providing strong assurance that the message has not been tampered
with in transit.
To use Local Authentication, both endpoints must share a secret key. This key is separated in two
parts, enabling dual control and the separation of duties between the two operators entering the
key.
For new message partners in Alliance Access/Entry and Alliance Gateway, Local Authentication is
selected by default. It will still be possible to deactivate LAU. A warning message will be displayed
and a security event will be logged in such a case.
XML Signature (XML-DSig)
XML-DSig is supported by Alliance Access/Entry, Alliance Gateway, and SwiftNet Link.
XML Signature (also called XMLDSig, XML-DSig, XML-Sig) defines an XML syntax for digital
signatures and is defined in the W3C recommendation XML Signature Syntax and Processing.
Alliance Gateway and SwiftNet Link can generate on request from your application, an XML DSIG
signature using SwiftNet PKI certificates that can then be included by your application to an XML
message that will be part of the payload. The application of your counterparty will then be able to
call its own Alliance Gateway/SwiftNet Link, asking for a verification of this signature. LAU based
on XML Digital Signature with a symmetric key can also authenticate your back office to Alliance
Access/Entry, and Alliance Access/Entry to your back office. It will also protect such XMLv2
parameters as message format, SwiftNet addressing, service, request type, header info, and so on,
from being changed in transit between your back-office application and Alliance Access/Entry.
XMLv2 file format removes the need for the binary header, and replaces it with the XML-DSig.
Transport Layer Security (TLS)

12 January 2024 66
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Transport Layer Security (TLS) is a cryptographic protocol used to provide communication security
between Alliance products and back-office applications.
All TCP/IP connections use at a minimum TLS version 1.2. The supported cryptographic algorithms
are:
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TCP/IP connections using TLS version 1.3 support the following cryptographic algorithms:
• TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256

AES-GCM
Direct FileAct, IBM MQ, and File Transfer message partners support AES-GCM, using a set of
symmetric key cryptographic block ciphers.

PKI certificates for IBM MQ

Alliance Access gives the option of using digital certificates issued by a Certification Authority (CA)
that is managed by the customer. This means that message partners that use Local Authentication
(LAU) can use asymmetric keys (PKI), instead of symmetric keys, to encrypt and decrypt
messages that are sent between the customer's back office and Alliance Access.

List of recommendations
ID Recommendation Product

LAU.01 The confidentiality of messages sent between the back office and Alliance Access/ Entry
Alliance products is protected.
(LSC.04 used in Alliance Gateway
Security Best This can be achieved using TLS, MQ-Channel encryption, SFTP, or
Practices Check another mechanism.
Tool)

LAU.02 The connection between the back office and Alliance products is Alliance Access/ Entry
mutually authenticated.
Alliance Gateway
This can be achieved using LAU (activated at the message partner
level), XML-DSig, or other authentication mechanisms such as TLS.

LAU.03 The integrity of messages sent between the back office and Alliance Alliance Access/ Entry
products is protected.
Alliance Gateway
This can be achieved using LAU (activated at the message partner
level), XML-DSig, or other protocols ensuring data integrity, such as
TLS.

Further reading
• Alliance Access Configuration Guide - Message Partner Configuration
• Developers Toolkit for Alliance Access Developer Guide
• Alliance Access Configuration Guide - SOAP and Local Authentication
• Alliance Access Configuration Guide - Local Authentication Trailer
• Alliance Entry Configuration Guide - Message Partner Configuration
• Alliance Entry Configuration Guide - Local Authentication Trailer

12 January 2024 67
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

• Alliance Gateway Administration and Operations Guide - Local Authentication and Security
• Alliance Gateway Security Guide - Local Authentication

5.5.4 Operator Session Confidentiality and Integrity (CSCF

Control 2.6)
Session management
Active Alliance applications sessions are kept confidential and are protected by a crytographic
protocol (for example, HTTPS).
The Alliance applications provide an inactivity lock-out feature, which can be configured to limit
operators' interactive sessions to the minimal timeframe necessary to perform business-as-usual
duties. This feature is not applicable for monitoring sessions in Alliance Access/Entry, to enable
continuous monitoring activity.
Note An operator session on Alliance Access Monitoring or Alliance Entry Monitoring never
expires. Therefore, if you add the Monitoring application to an Application Group that
contains other types of applications, then the operator sessions on those applications
will also remain active.

ID Recommendation Product

OSC.01 Sessions are not left open unattended. All Alliance Applications

OSC.02 For the security parameter Session Expiry Timeout, set Alliance Web Platform
the session time-out to a reasonable value (40 minutes or Server-Embedded
(SLA.03 used in
2400 seconds is recommended).
the Security Best
Practices Check
Tool)

OSC.03 For the security parameter WS Session Time Out, set the Alliance Access/ Entry
session time-out to a value less than or equal to the
(LOA.01 used in
default value, which is 600 seconds.
the Security Best
Practices Check
Tool)

OSC.04 For the security parameter SwiftNet User Disconnect Alliance Gateway
Timeout, set the session time-out to a reasonable value
(AGW.01 used in
(40 minutes or 2400 seconds is recommended).
the Security Best
Practices Check
Tool)

OSC.05 Limit the access to Alliance Access/Entry Monitoring only Alliance Access/ Entry
to the operators that need to perform monitoring activity
and restrict combination with other business or
administrative purposes.
This will avoid that for operator accessing the applications
for other purpose than monitoring, the respective session
will never expire.

12 January 2024 68
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

5.5.5 Transaction Business Control (CSCF Control 2.9)

[Link] Other Transaction Controls

This section provides a non-exhaustive list of mechanisms that can be used to prevent or detect
malicious activities.

Perform end-of-day/intra-day reconciliations or independent reconciliation against a secondary

source
If there are discrepancies between the messages recorded by the Swift Network and those
recorded by the customer, then this can be an indication of fraudulent activity.
Therefore, it is important to have a daily reconciliation process. In this process, all items in the end-
of-day statement (MT950 or MT940) are matched against the entity's accounting records (called
ledger items) for that day's value date.

End of day Value date

statements Reconciliation Ledger items
(MT 940 / 950) from the
for Nostro Back-Office
Accounts application(s)

D1700014
Consider implementing a process to issue and check confirmation messages (for example, to
check that the MT 900 and MT 910 confirmations match the transactions that have occurred on the
accounts or through potential online queries for intra-day Nostro reconciliation).
Finally, consider reconciling daily (and possibly intra-day) messages that are sent to/from the back
office and to/from the Swift Network. Those messages could be MT103/MT202 and related pacs.
008/09 messages.

Abnormal sessions and message flows

It is important to look for abnormal session/traffic patterns. For example, this could enable you to
detect payment activity that originated outside of normal business hours, or unusual session and
message activity, which can potentially indicate fraudulent activity.
Sophisticated tools exist for that purpose.
A simplified alternative is to use the MT081 Daily Check Report. This message lists the number of
sessions, as well as the date and time they were opened and closed. It is important to check these
reports for anomalies on a daily basis.
Another recommendation is to monitor the Event Journal in Alliance Access for logical terminal
login attempts (alarms can be configured).
For customers who have their logical terminals logged in for 24 hours, it is recommended that the
Alliance operator checks the Alliance Message File in the morning, to verify whether any payments
were sent during an unexpected time frame.

Calendar and Scheduled Operations

In Alliance Access/Entry customers can set up multiple calendars for a given year.

12 January 2024 69
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

The calendars can be used to schedule automatic operations (for example, connection to the Swift
network of logical terminals, emission profiles and reception profiles) or can be used as a security
mechanism to control the days of the week an operator is allowed to log in (for example, only
allowing access on work days, do not allow on holidays, and so on). When a calendar is assigned
to an operator profile, the operators will ONLY be allowed to log in on the days that are not defined
as holidays.
It is good practice to define different calendars for automatic operation scheduling and for
restricting operator access within the Alliance Access/Entry application.
Having multiple calendars defined for the same year enables, for example, logical terminals to have
their own calendar. This can be useful for logical terminals of customer branches, which are located
in different countries and have different working days or public holidays.

Operator login and logout

After a successful login, the GUI displays information concerning the previous successful login of
the operator. The operator must click Status in the lower-right corner of the window. The
information is provided so that the user can notice if somebody else has used their credentials.
A time zone is associated to the operator (through the operator definition).
An operator is only allowed to access the system during the time band (Start time and End time)
specified in the operator's profile. Once the time limit is reached, regardless of whether their
session is still active or not, the operator is signed off automatically.
In addition, if the calendar is assigned in the operator profile, the operator will be logged out
automatically when reaching a new day defined as a holiday in the calendar. This will happen even
when the operator is in an allowed time band (Start time and End time) that is defined in the
operator profile.

Identifying messages with human interaction

Alliance Access/Entry clearly indicates which messages have been processed in a fully automated
way, and which messages have experienced operator interaction during their lifetime in Alliance
Access/Entry. This includes not only messages created by an operator, but also messages
modified or completed by an operator.
In the message search GUI, two search criteria can be used for this purpose:
• a Touched by Human check box, which enables you to filter out those messages where a
human interaction took place.
• an Operator field to be used in combination with Touched by Human, to list only those
messages that a specific operator had interaction with.

Disconnecting from the Swift Network

Following the procedure to disconnect one or more logical terminals from the Swift network,
customers have two options for the Next Login field:
• No Restriction on next login: enables you to log in again using the logical terminal without
restriction.
• Restricted until: enables you to specify a date and time before which the next login is
forbidden for the selected logical terminals. The date and time specified must be within seven
days of the current date and time.
The Restricted until feature enables a customer to set a date and time before which it does not
expect to reconnect (for example, Monday at 0900 when logging out at the end of the week). FIN
will enforce the rule that no one can connect to the LT during that time period. This feature is valid
in case of manual disconnect of the logical terminals and could help against threat actors trying to
send messages outside business hours.

12 January 2024 70
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

CAUTION You cannot disable this restriction once it has been set. Use extra caution when
entering a Next Login date and time.

List of recommendations
ID Recommendation Product

REC.01 Perform a reconciliation between the messages that are sent to/ All
from the back office and to/from the Swift Network.

REC.02 Perform a check to detect abnormal sessions and message flows by Alliance Access/ Entry
means of tools, or manual checks based on the MT081/ Message
File/Event Journal.

REC.03 Limit the active SwiftNet sessions (FIN, InterAct, and FileAct) to Alliance Access/ Entry
specific business hours and days of the week. For scheduled
operations, this can be achieved through the definition and
assignment of a calendar to the Logical Terminals, Emission profiles
and Reception profiles.
Note This limitation is applicable for both modes of
operation: Manual and Automatic.

REC.04 Restrict the access of operators on Alliance Access/Entry to certain Alliance Access/ Entry
days of the week as per business needs. This can be achieved
through the definition and assignment of a calendar to the operator
profiles.
Note The calendar assigned to operator profiles can be
different than the one used for logical terminals, if
there is a business need.

REC.05 Assign the correct time zone to the operators (through the operator Alliance Access/ Entry
definition) accessing the Alliance Access/Entry from a different time
zone than the server's time zone.

REC.06 Alliance application accounts are restricted from login attempts that Alliance Access/ Entry
occur outside of expected role-specific operational hours.
The "Sign on" entitlement in Alliance Access/Entry operator profiles
can be used to limit access as per the business hours.

REC.07 Operators use the information provided in the GUI to ensure that no Alliance Access/ Entry
one else has used their credentials.

REC.08 Use the Touched by Human facility to identify those messages Alliance Access/ Entry
where a human interaction took place.

REC.09 During the disconnect of a logical terminal from the Swift network, Alliance Access/ Entry
use the Restricted until feature to set a date and time before which
it does not expect to reconnect.
Note This is valid only for the manual disconnect option.

REC.10 A process is in place to monitor anomalies in access behaviour (for All

example, connections outside normal business hours).

12 January 2024 71
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Further reading
• Alliance Access Relationship Management Guide
• Alliance Access Message Management Guide
• Alliance Access Configuration Guide
• Alliance Entry Relationship Management Guide
• Alliance Entry Message Management Guide
• Alliance Entry Configuration Guide

5.5.6 Relationship Management Application (RMA) (CSCF

Control 2.11A)
The Relationship Management Application (RMA) provides functions to manage authorisations for
a business relationship, which enables you to conduct business with trusted parties only.
When an institution consents to receive messages from a specific correspondent, that consent is
recorded in an authorisation in RMA. A correspondent can send you messages only when you
have authorised that correspondent to do so. This helps mitigate the risk of receiving unwanted
payments.
It is important to keep your RMA records up-to-date and in line with your actual business
relationships. By doing so, you will not receive messages from counterparties with which you do
not have a relationship. Under normal circumstances, messages for which an authorisation has
been revoked will be rejected centrally within 15 minutes of the acknowledgement of the revocation
message.
To assist you with monitoring your active messaging counterparties, Alliance Access, Alliance
Entry, and Alliance RMA offer the following reporting functionalities:
• R. Usage Count: the total number of times that the receiving part of the authorisation has been
used to perform an RMA check on the message.
• R. Last Usage: the timestamp when the receiving part of the authorisation was last used.

ID Recommendation Product

RMA.01 A procedure is in place to take an immediate, appropriate action once a Alliance

business relationship has been stopped (revoke or reject the relevant Access/
authorisations). Entry

RMA.02 A procedure is in place to review on a regular basis your RMA Alliance

authorisations. Access/
Entry

RMA.03 A procedure or workflow exists within the business teams to initiate an Alliance
RMA authorisation creation, removal, or update request to the RMA Access/
operators when a new business relationship over Swift has been Entry
established. This request is logged.

In addition, it is best practice to use Alliance operator profiles that support the separation of duties
for managing authorisation data (see Logical Access Control (CSCF Control 5.1)).

12 January 2024 72
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

5.5.7 Local Operator Authentication Methods - Password

Policy and Multi-factor Authentication (CSCF Controls 4.1
and 4.2)
To use Alliance products, users must have an account associated with a profile that defines the
user's role and entitlements to access the available functionality. To use such an account, users
must provide valid authentication credentials.
There are five possible authentication methods for users:
• Password (Local Authentication)
Operators can authenticate themselves with a user name and password
• Embedded Two-Factor Authentication (Password and TOTP)
This is the default authentication method. When logging in, the user provides their credentials
(user name, password, and TOTP)
• RADIUS One-Time Password
Alliance Access/Entry and Alliance Gateway can be configured to authenticate operators by
means of an Authentication Server (RADIUS).
• LDAP (Lightweight Directory Access Protocol) authentication
Alliance Access and Alliance Gateway can be configured to authenticate users by means of an
LDAP server.
• SAML-based Identity Providers (IdP)
An Identity Provider (IdP) is an entity that performs the authentication of an end user's identity. It
provides the appropriate authentication statements to downstream systems or Service
Providers, asserting that the end user authenticated to the IdP at a particular time, using a
particular method of authentication. A SAML-based IdP is a system entity that issues
authentication assertions in conjunction with an SSO profile of SAML. With Alliance Access,
Alliance Entry, Alliance Gateway, and Alliance Web Platform Server-Embedded, you can
configure a third-party IdP server to handle full authentication, using any multi-factor
authentication method.
Any of these user authentication methods can be configured individually.
Note Swift does not give recommendations regarding Vendors of RADIUS or LDAP servers.

Default authentication type for operators

When creating new operators in Alliance products (Alliance Access/Entry and Alliance Gateway),
note that the default authentication type is Password and TOTP.
Configurable restriction on the authentication types allowed
The security parameter Auth type available enables a security officer to restrict the list of available
authentication mechanisms available for Human operators inside Alliance Access/Entry.

[Link] Password Policy (CSCF Control 4.1)

Alliance Access and Alliance Entry
The Alliance Access and Alliance Entry security officers can modify certain security parameters
that help the customer to enforce their password policy. The full list of security parameters can be
found in the security parameters section of the Alliance Access or Alliance Entry Security Guides.

12 January 2024 73
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

These parameters can be accessed, modified, and approved using the Alliance Access and
Alliance Entry Configuration GUI, and are under four-eye control. If one security officer makes a
change to one of these parameters, then the other security officer must approve the change before
the change is applied.
The operators of Alliance Access are divided into two groups with distinct password policies:
• Normal users
• Admin users
This is displayed in the Password Policy Type field, which is read-only. The value gets changed
based on the entities selected in the operator profile.
Operators that have the Normal users password policy can only have the following entities defined
in their profile:
• Msg Creation
• Msg Approval
• Msg Modification
• Message File
• Monitoring
• Relationship mgmt.
• Access Control
• Correspondent Info
• Reporting

Important If any other entity is defined in an operator's profile, then the operator is automatically
considered an administrator and consequently the Admin users password policy is
applied to that operator from the next login.
The Admin users password applies as well to security officers.

A subset of password parameters is defined for each policy. For more information, see List of
recommendations.
Alliance Gateway
Several security configuration parameters are available to help enforce the customer's password
policy. An Alliance Gateway operator with the functions Manage Security Configuration Parameters
and Update a Configuration Parameter can modify these parameters.
Alliance Gateway requires passwords for the following operational entities:
• Alliance Gateway operators, including the Alliance Gateway Administrator operator
• SwiftNet users
• Virtual SwiftNet users
Note Although Alliance Gateway enables you to perform a password change for SwiftNet
users, the related password policy is defined by SwiftNet and enforced by SwiftNet
Link. Passwords for SwiftNet users are outside the scope of Alliance Gateway
password management. For more information, see the SwiftNet PKI Certificate
Administration Guide.
For more information, see List of recommendations.

12 January 2024 74
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Alliance Web Platform Server-Embedded

Several parameters are available to help enforce the customer's password policy in Alliance Web
Platform Server-Embedded. They can be modified by the application owner by means of
command-line tools or by Alliance Web Platform Server-Embedded administrator by means of the
GUI.
The locally defined user accounts are automatically locked when the account is not used for a
specific period of time.
For more information, see List of recommendations.

Password blacklist
Each Alliance application provides a blacklist file that can be used to establish rules to prevent the
use of specific characters, combinations of character strings, and/or particular words.
The password blacklist applies to passwords that are changed on a locally defined operator with
the Password or Password and TOTP authentication methods. It does not apply to operators
defined with other authentication types, such as LDAP or Radius one-time Password.
Alliance applications use as default a blacklisted password list that is defined at Swift. During
installation, an initial list of 500 blacklisted substrings will be activated. The password blacklist can
be modified using the following commands, but it should not be left empty:
• saa_blacklist command-line tool - for Alliance Access
• sae_blacklist command-line tool - for Alliance Entry
• sag_blacklist command - for Alliance Gateway
• [Link] perl command - for SwiftNet Link

An event is logged in each application whenever the respective command is run.

The list is used when passwords are changed, and it contains pattern occurrences that cannot be
part of a human operator password. For example, if "apple" is in the blacklist, then every password
that contains this occurrence is forbidden, even if the password complies with the applicable
password policy.

List of recommendations
The following tables provide the new rules for valid passwords and a list of recommended security
parameter configurations in Alliance products. This list is not exhaustive.
Alliance Access/Entry

ID Recommendation Product

USM.01 All user-defined passwords used in Alliance Access/Entry must be in line Alliance
with industry best practices. The application enforces below list of rules for Access/
operators with the "Normal users" password policy assigned: Entry
• Passwords and PINs should be configured using the parameters
specified in Knowledge Base articles 5021567 and 5022038.
• Disable Period - The number of calendar days after which a user is
disabled if there was no successful login. The check is done at server
startup and every hour. Changes to this parameter will take effect at
midnight or at the next restart of the servers. Recommended value: 120

12 January 2024 75
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

USM.02 All user-defined passwords used in Alliance Access must be in line with Alliance
industry best practices. The application enforces the following list of rules Access/
for operators with the "Admin users" password policy assigned: Entry
• Passwords and PINs should be configured using the parameters
specified in Knowledge Base articles 5021567 and 5022038.
• Admin Disable Period - The number of calendar days after which an
administrator is disabled if there was no successful login. Changes to
this parameter will take effect at midnight or at the next restart of the
servers. Recommended value: 120

USM.03 For the following security parameter, set the recommended value: Alliance
Access/
• User Strong Validation - Defines the number of character types
Entry
(uppercase, lowercase, number, or symbol) that a user password must
contain. Changes to this parameter become effective when an operator
changes the password. Recommended value: 4

USM.04 The Password Blacklist security feature is used to prevent the use of Alliance
specific characters, combinations of character strings, or of particular words Access/
in user-defined passwords. Entry
• Minimum Blacklist Size - Defines the minimum number of entries a
blacklist file must contain. Recommended value 500

12 January 2024 76
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Alliance Gateway

ID Recommendation Product

USN.01 By default, Alliance Gateway application enforces the following password Alliance
rules: Gateway
• US-ASCII (32-126) characters, including:
- A-Z
- a-z
- 0-9
- ~!@#$%^&*()_+`-={}|[]\:";'< >?,./
• At least one upper-case and one lower-case letter.
• At least one numeric character.
• At least one special character.
• The number of occurrences of the same character in the password must
be equal to or less than half the number of characters in the password,
minus one. For example, if the password is 15 characters long, then
there can be no more than six occurrences of the same character.
• The value supplied for a password cannot be the same as the operator
name or SwiftNet user name.
• A-Z
• a-z
• 0-9
• ~!@#$%^&*()_+`-={}|[]\:";'< >?,./
Additionally, a number of password-related parameters can be configured:
• SwiftNet Interface/Password Minimum Length - Determines the
minimum allowed length for a virtual SwiftNet User password.
Recommended value: 12.
• System/Password Minimum Length: - Determines the minimum allowed
length for an Operator password. Recommended value: 17.
• System/Password Minimum Length TOTP - Determines the minimum
allowed length for an Operator password when used in combination with
TOTP. Recommended value: 12.
All user-defined passwords used in Alliance Gateway must be in line with
industry best practices.

12 January 2024 77
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

USN.02 For the following security parameters, set the recommended value: Alliance
Gateway
• Maximum Number of Failed Login Attempts - Indicates the permitted
number of attempts to provide a valid password. For the Administrator,
the account is suspended for 10 minutes after the designated number of
failed attempts, Recommended value: 5
• System/ Password Validity Period - Controls the number of days that an
operator password can be used before it expires. Recommended value:
365
• SwiftNet Interface/Password Validity Period - Controls the number of
days that a SwiftNet user password can be used before it expires and
consequently must be changed. Recommended value: 90
• Enforce Application Passwords - Defines whether Alliance Gateway
enforces the use of application passwords for certificates configured in
relaxed mode or used through virtual SwiftNet users. Recommended
value: Yes
• Disable Period - Defines the number of days after which an operator or
virtual SwiftNet user who has not logged in successfully is disabled.
Recommended value: 120
This functionality does not apply to real SwiftNet users; expiry of the
underlying certificate controls their access to Alliance Gateway.
Additionally, the Alliance Gateway Administrator account can never be
disabled.

USN.03 The Password Blacklist security feature is used to prevent the use of Alliance
specific combinations of character strings, or of particular words in Gateway
passwords.

12 January 2024 78
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Alliance Web Platform Server-Embedded

ID Recommendation Product

CLA.01 By default, Alliance Web Platform SE application enforces below Alliance

password rules: Web
Platform
• Passwords must contain elements from each of the following sets:
Server-
- Uppercase (A - Z) Embedded
- Lowercase (a - z)
- Numeric (0 - 9)
- Special characters (! # $ % & ' ( ) * + , - . / : ; < = ? @ [ \ ] ^ _ ` { | }
~)
• Passwords must not be the same as the user name.
• Passwords must not contain the user name.
• Passwords must not contain (L-1)/2 occurrences (or more) of the
same character (where L is the length of the password).
• Successive passwords must not follow a sequence.
• Uppercase (A - Z)
• Lowercase (a - z)
• Numeric (0 - 9)
• Special characters (! # $ % & ' ( ) * + , - . / : ; < = ? @ [ \ ] ^ _ ` { | } ~)
• Minimum Password Length - Determines the minimum length of
passwords in number of characters if TOTP is not used.
Recommended value: 17
• Minimum Password Length for TOTP - Determines the minimum
length of passwords in number of characters when used with TOTP.
Recommended value: 12.
All user-defined passwords used in Alliance Web Platform SE must be in
line with industry best practices.

CLA.02 For the following security parameters, set the recommended value: Alliance
Web
• Password Expiration - Controls the number of days that a password
Platform
can be used before it expires and consequently must be changed.
Server-
Recommended value: 90
Embedded
• Password History Size - Number of passwords stored in the password
history. Recommended value: 8
• Dormant Disable Period - Defines the number of days after which a
user is set to dormant if there was no successful login. Recommended
value: 120

CLA.03 The Password Blacklist security feature is used to prevent the use of Alliance
specific characters, combinations of character strings, or of particular Web
words in user-defined passwords. Platform
Server-
The minimum size of the blacklist is controlled by means of the
Embedded
configuration parameter:
• Blacklist Size - Defines the minimum number of entries a blacklist file
must contain. Recommended value: 500

12 January 2024 79
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

For more best practice guidelines on password parameter settings, refer to Knowledge Base article
5021567.

[Link] Multi-factor Authentication (CSCF Control 4.2)

Alliance products support multi-factor authentication by means of the embedded Two-Factor
Authentication (2FA) solution (such as Time-based one-time Password (TOTP)) or integration with
a customer-managed RADIUS, LDAP, or SAML solution. You can also rely on your own Identity
Provider (IdP), which can redirect to a 2FA-enabled service.

Two-Factor Authentication (2FA)

Two-Factor Authentication (2FA) is a method of user authentication where at least two different
components are required to authenticate a user. Typically this is something you know (user name/
password) and something you have (for example, a one-time-password generator, a piece of
hardware, or a secret key).
Alliance Access/Entry, Alliance Gateway, and Alliance Web Platform Server-Embedded provide a
secure 2FA set-up using an off-the-shelf application that can be installed on a separate device,
such as a mobile phone or tablet.
Time-based one-time Passwords (TOTPs) are temporary passcodes, for use in authenticating
access to computer systems. The algorithm that generates each password uses the current time of
day as one of its time-based one-time factors, ensuring that each password is unique. With this
two-factor authentication, a user must enter their usual user name and password and the TOTP to
gain access.
If you choose to use RADIUS one-time passwords, then you need a secure, PIN-protected token
that generates one-time passwords and an authentication server that authenticates the one-time
passwords. You can use any authentication server that supports the RADIUS user authentication
protocol.
Two-Factor Authentication using LDAP can be achieved by enabling a feature or plug-in for the
LDAP server that provides TOTP or OTP, in addition to the fixed password.
You can also configure an Identity Provider (IdP) server to handle full authentication, whereby
customers can leverage 2FA solutions supported on their IdP systems. Alliance Access/Entry,
Alliance Gateway, and Alliance Web Platform Server-Embedded support IdP-based authentication
using the SAML 2.0 SSO profile.
As with the LDAP and Radius solution, Swift does not recommend a specific vendor of client TOTP
solutions. The solution selected for the TOTP second factor must be able to generate passwords of
(at least) eight digits, support SHA-256, and accept an activation code.
Note The PIN and RSA token would be a valid MFA solution.
A PIN (a credential that is checked on a hardware device that enforces a lock after a
number of invalid entries) is different from a password. If a PIN is checked by another
system than the token, then this credential would not be considered to be a PIN, but it
is effectively a "password" - and almost by definition, a weak password.
For more best practice guidelines on password and PIN parameter settings, refer to
Knowledge Base article 5021567.
For more information about the applicable security parameters and recommended values, see List
of recommendations.

[Link]
Swift has enforced the two-step authentication method on [Link].

12 January 2024 80
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

List of recommendations
ID Recommendation Product

MFA.01 At least a two-factor authentication method is used for Alliance Access/ Entry
authentication on Alliance products. The options are:
(USM.02 used in the Alliance Gateway
Security Best • Embedded Two-Factor Authentication (Password and TOTP).
Alliance Web Platform Server-
Practices Check This is valid for:
Embedded
Tool)
- All operators in Alliance Access including main LSO/RSO
and extra security officers
- All operators in Alliance Entry including main LSO/RSO and
extra security officers
- All operators in Alliance Gateway (except the default
application Administrator)
- All operators in Alliance Web Platform Server-Embedded
• RADIUS One-Time Password
• LDAP (Lightweight Directory Access Protocol) authentication
where a second factor is required at the single login, or at a later
stage.
• All operators in Alliance Access including main LSO/RSO and
extra security officers
• All operators in Alliance Entry including main LSO/RSO and
extra security officers
• All operators in Alliance Gateway (except the default application
Administrator)
• All operators in Alliance Web Platform Server-Embedded

MFA.02 For the following two-factor authentication security parameters, set Alliance Web Platform Server-
the recommended value: Embedded
• Auth type available - Enables a security officer to restrict the list
of available authentication mechanisms available for Human
operators inside Alliance Access/Entry. Accepted values:
Password; RADIUS one-time password; LDAP and Password
and TOTP.
Recommended value is to select one of the 2FA authentication
mechanisms.
• Two Factor Auth- Window - Controls the time span for which
generated Time-based one-time Passwords are accepted by
Alliance products. Each 'window' is a period of 30 seconds.
Recommended value: 3

MFA.03 For the following two-factor authentication security parameter, set Alliance Gateway
the recommended value:
• Two-factor Authentication Window - Controls the range of Time-
based one-time Password values accepted for a login attempt.
Recommended value: 3

12 January 2024 81
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

MFA.04 For the following two-factor authentication security parameters, set Alliance Web Platform Server-
the recommended value: Embedded
• Two-factor Auth for Alliance Web Platform - Enable two-factor
authentication support for Alliance Web Platform Server-
Embedded Administration GUI. Recommended value: True
Note Before enabling two-factor authentication, you
must ensure that operators have a valid means of
generating acceptable Time-based one-time
Passwords.
• Two-factor Authentication Window - This parameter controls the
time span for which generated Time-based one-time Passwords
are accepted for a login to the Alliance Web Platform Server-
Embedded Administration GUI. Recommended value: 3
• Two-factor Auth for Alliance Access/Entry - Enable two-factor
authentication support for the Alliance Access/Entry GUI.
Recommended value: True
• Two-factor Auth for Alliance Gateway Administration - Enable
two-factor authentication support for the Alliance Gateway
Administration GUI. Recommended value: True

MFA.05 The off-the-shelf application used for generating a Time-based one- All
time Password (TOTP) is not installed on the PC from which you
access Alliance Web Platform Server-Embedded.

The off-the-shelf application used for generating a Time-based one-time Password (TOTP) is not
installed on the PC from which you access Alliance Web Platform Server-Embedded.

Further reading
For more information about the user management and password policy on Alliance products, refer
to the following documents:
• Alliance Access Configuration Guide - User Management
• Alliance Access Security Guide - User Management
• Alliance Entry Configuration Guide - User Management
• Alliance Entry Security Guide - User Management
• Alliance Gateway Administration and Operations Guide - User Management
• Alliance Gateway Security Guide - Password Policy Management
• Alliance Web Platform Server-Embedded Administration and Operations Guide - User
Management

5.5.8 Logical Access Control (CSCF Control 5.1)

Alliance products are designed to support the security principles of:
• need-to-know: an individual only has access to confidential information required for their job.
• least privilege: an individual can only access the features required for their job.
• separation of duties: sensitive operations are performed by at least two individuals, each
responsible for a separate part of the task.

12 January 2024 82
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Applying these security principles properly is essential to restricting access to the Alliance
applications. It also reduces the opportunities for a malicious actor to use an account as part of an
attack.
Alliance products provide various security features that enable the customer to control how
operators and other systems communicate and interact with each Alliance application. There are
two main security features provided for this purpose:
• Embedded role-based access control features
The embedded access control features in Alliance applications enable the customer to perform
the following steps:
- Identification - identify each operator by a unique value, for accountability, and for the use of
standard naming conventions.
- Authentication - allow authenticated operators to access the application and/or have access
to information that only they have a legitimate need to know.
- Authorisation - grant necessary rights and privileges to carry out the requested actions
according to the principles of "least privileged" and "separation of duties".
• Security parameters
Security parameters can be used in addition to the embedded Role-Based Access Control to
enforce the "Authentication" and "Authorisation" steps. These security parameters can be
configured according to the customer business needs and apply globally to all operators in each
application.
For more information about Alliance product authentication, see Logical Access Control (CSCF
Control 5.1) on page 82. The authorisations are not enforced at the Alliance Web Platform Server-
Embedded level, but rather at the back-end server level (Access/Entry and Alliance Gateway).
More information about the "Authorisation" step for both security features in each application is
provided below.

[Link] Alliance Access Authorisation

Embedded role-based profiles and units
The Alliance Access application provides a large number of authorisation options to manage user
privileges, such as the separation of roles and units; four-eye control over critical security
operations; and six-eyes control for the sending of messages (creation, verification, and
authorisation). These features enable the application of the least-privilege and separation of duties
principle and thus reinforce application security.
Alliance Access consists of a number of entities. The security officers in your institution are
responsible for defining which entities that you can use. The security officers do this by creating
and assigning profiles to operators.
An operator profile defines:
• the entities that an operator is allowed to use
• the entitlements to use actions (functions) within a particular entity
• the permissions associated with an entitlement.
More information about access control defined per operator type in Alliance Access is provided
below.

12 January 2024 83
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Alliance security officers

Four-eye control on sensitive security operations performed by security officers is mandated by
default in Alliance Access. Such operations performed by security officers always require the
separation of duties (for example, creating and approving operators and security parameters).

Alliance application owner

To ensure that your Alliance Access works efficiently and in a secure manner, a user must be
assigned the role of Alliance application owner. This role is linked to the operating system user,
rather than an application operator. This user carries out various administration tasks on Alliance
Access (for example, troubleshooting, stop/start, archive/back-up, and upgrades). The name of this
account is specified during the installation or upgrade of Alliance Access. The Alliance application
owner can perform administration tasks on Alliance Access using the following facilities:
• the System Administration application on the Alliance Access server
• the command-line tools.
The use of the System Administration application is restricted to those people who know the
credentials for the Alliance application owner.
For more information about best security practices for the Alliance application owner, see
Operating System Privileged Account Control (CSCF Control 1.2) on page 49.
Other operator accounts
Alliance security officers can create various operator accounts according to the business needs. By
means of the operator profile entitlements and permissions, the customer can implement least
privilege and separation of duties where this is not mandated by default.
It is the responsibility of the Alliance security officer to carefully review the available entitlements
and permissions that are assigned to each operator. Each operator should be assigned the minimal
number of functions that enables them to perform their day-to-day activities.
The use of units can further help to separate message processing tasks between different groups
of operators. A unit is a logical grouping to which operators can belong, and to which messages
can also be assigned. A unit can correspond to a division, department, office, or some other
grouping within an organisation. If a message is assigned to a unit, then only operators who belong
to the same unit can display or modify the message.
The following table provides guidance on how to split specific permissions over two or more
operators. This list is not exhaustive.

Entity Operator A Operator B Operator C Risk

functions functions functions

Applic. Interface Add Partner Enable Mess. If an operator can

Partner solely create or
Mod Partner
modify and enable
Start session a message partner,
then they can fully
configure the
message partner to
read messages
from the directory
they want.

12 January 2024 84
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Entity Operator A Operator B Operator C Risk

functions functions functions

Applic. Interface Add Partner/First Add Partner/ If an operator has

part LAU Key Second part LAU access to both the
Key left and right parts
Add Partner/First
of a key, then they
part Session Key Add Partner/
would be able to
Second part
Mod Partner/First inject fraudulent
Session Key
part LAU Key messages that
Mod Partner/ have a correct
Mod Partner/First signature.
Second part LAU
part Session Key
Key
Mod Partner/
Second part
Session Key

Mesg Approval Create Message Approve Message/ Approve Message/ If an operator can
Mesg Creation Verify Authorise solely create/
Modify Message
Mesg Modification modify, approve,
and authorise a
message, then they
can send any
fraudulent
message that they
want to the Swift
Network.
When an operator
has the "create
message" in
combination with
the "bypass"
permission, the
operator can solely
create and send
out a fraudulent
message to the
Swift Network.

Entity Operator A Operator B Operator C Risk

functions functions functions

Relationship Mgmt Create Auth. Approve Auth. If an RMA operator

could approve their
Revoke Auth.
own actions, then
Accept Auth. the operator would
be able to manage
Reject Auth. authorisations with
Delete Auth. unwanted
counterparties.

12 January 2024 85
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Entity Operator A Operator B Operator C Risk

functions functions functions

Routing Add Rule Approve Schema If an operator can

solely modify and
Add Schema
approve a routing
Mod Rule schema, then they
can route all
Mod Schema messages as they
want, potentially
avoiding six-eyes
control.

SWIFT Interface Add LT Enable LT If an operator can

SWIFT Support solely add and
Modify LT Remove LT
approve an LT,
Disable LT then they can add
additional,
unwanted LTs that
can send
messages to Swift.

SWIFTNet Add EProf/RProf Enable EProf/RProf If an operator can

Interface solely add and
Modify EProf/RProf Remove EProf/
approve an
RProf
Disable EProf/ emission profile,
RProf then they can add
additional,
unwanted emission
profiles that can
send messages to
SwiftNet.

Integr. Platform Add/Rem Manage If an operator can

Component Component solely install an
IPLA component
and start it, then
they could install
and run malicious
software.

System System SWIFTNet Support If an operator can

Management Management - - SNL Handling solely modify the
Stop/Start connectivity to a
SWIFTNet Support
Component Gateway and apply
the new
configuration by
restarting the
required
components, then
they could redirect
traffic to the wrong
Gateway and
therefore get
access to
messages.

12 January 2024 86
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Security parameter
Because of the current security challenges, your security auditors will demand that LSO/RSOs
assign the right roles to the right people and ensure that the configuration of Alliance Access is well
controlled.
The security parameter System - 4 Eyes mechanism is enabled by default. Having this security
parameter set enforces the requirement that more than one person must change and enable
operators, message partners, and routing schemas.
Using this feature avoids the need to set up two operator profiles with mutually exclusive
permissions to implement an explicit separation of duties. With this feature, you need actions from
two different people to create/modify and enable the changes while they have the same profile.
Alliance Access tracks who created and who made the last modification to operators, message
partners, and routing schemas functions. As a result, the last modifier cannot perform certain
actions. If this is attempted, an error will be displayed.
The following tables provide examples of how this parameter enforces a four-eye policy for updates
to message partners, operators, and routing functions:

For message partners:

Previous action taken Next action authorised Next action NOT
authorised by the same
person (user account)

Add / Add as Update Enable

Delete

Update Update Delete

Enable

Enable Disable Delete

Disable Enable Delete

Update

For operators:
Previous action taken Next action authorised Next action NOT
authorised by the same
person (user account)

Add / Add as Update

Approve
Delete

Update Update Delete

Approve

Approve Update Delete

Disable

12 January 2024 87
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Previous action taken Next action authorised Next action NOT

authorised by the same
person (user account)

Enable Update Delete

Disable

Disable Enable Delete

Update

Note Approving an operator triggers the enabling of an operator. Approval is already subject
to four-eye verification by LSO and RSO or by users with the same profiles.
For routing schemas:
Previous action taken Next action authorised Next action NOT
authorised by the same
person (user account)

Add / Clone Update

Approve
Delete

Update Update Delete

Approve

Approve Update Activate

Delete

Activate Update Delete

For routing schemas, if an operator has the Mod Active Schema entitlement, then the operator can
modify a routing rule of an active schema without having to activate another routing schema.

[Link] Alliance Entry Authorisation

Embedded role-based profiles
The Alliance Entry application provides a large number of authorisation options to manage user
privileges, such as the separation of roles and duties, four-eye control over critical security
operations, and six-eye control for the sending of messages (creation, verification, and
authorisation). These features enable the application of the least-privilege and separation of duties
principle and thus reinforce application security.
Alliance Entry consists of a number of entities. The security officers in your institution are
responsible for defining which entities that you can use. The security officers do this by creating
and assigning profiles to operators.
An operator profile defines:
• the entities that an operator is allowed to use
• the entitlements to use actions (functions) within a particular entity

12 January 2024 88
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

• the permissions associated with an entitlement.

More information about access control defined per operator type in Alliance Entry is provided
below.
Alliance security officers
Four-eye control on sensitive security operations performed by security officers is mandated by
default in Alliance Entry. Such operations performed by security officers always require the
separation of duties (for example, approving operators and security parameters).

Alliance application owner

To ensure that your Alliance Entry works efficiently and in a secure manner, a user must be
assigned the role of Alliance administrator. This user carries out various administration tasks on
Alliance Entry (for example, troubleshooting, stop/start, archive/back-up, and upgrades). The name
of this account is specified during the installation or upgrade of Alliance Entry. The Alliance
administrator can perform administration tasks on Alliance Entry using the following facilities:
• the System Administration application on the Alliance Entry server
• the command-line tools.
The use of the System Administration application is restricted to those people who know the login
and password for the Alliance application owner. For more information about best security practices
for Alliance application owner see the section see Operating System Privileged Account Control
(CSCF Control 1.2) on page 49.

Other operator accounts

The customer can create various operator accounts according to their business needs. By means
of the operator profile entitlements and permissions, the customer can implement least privilege
and separation of duties where this is not mandated by default.
It is the customer's responsibility to carefully review the available entitlements and permissions that
are assigned to each operator. Each operator should be assigned the minimal number of functions
that enables them to perform their day-to-day routine.
The following table provides guidance on how to split specific permissions over two or more
operators. This list is not exhaustive.

Entity Operator A Operator B Operator C Risk

functions functions functions

Applic. Interface Add Partner Enable Mess. If an operator can

Partner solely create or
Mod Partner
modify and enable
Start session a message partner,
then they can fully
configure the
message partner to
read messages
from the directory
they want.

12 January 2024 89
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Entity Operator A Operator B Operator C Risk

functions functions functions

Applic. Interface Add Partner/First Add Partner/ If an operator has

part LAU Key Second part LAU access to both the
Key left and right parts
Add Partner/First
of a key, then they
part Session Key Add Partner/
would be able to
Second part
Mod Partner/First inject fraudulent
Session Key
part LAU Key messages that
Mod Partner/ have a correct
Mod Partner/First signature.
Second part LAU
part Session Key
Key
Mod Partner/
Second part
Session Key

Mesg Approval Create Message Approve Message/ Approve Message/ If an operator can
Mesg Creation Verify Authorise solely create/
Modify Message
Mesg Modification modify, approve,
and authorise a
message, then they
can send any
fraudulent
message that they
want to the Swift
Network.
When an operator
has the "create
message" in
combination with
the "bypass"
permission, the
operator can solely
create and send
out a fraudulent
message to the
Swift network.

Entity Operator A Operator B Operator C Risk

functions functions functions

Relationship Mgmt Create Auth. Approve Auth. If an RMA operator

could approve their
Revoke Auth.
own actions, then
Accept Auth. the operator would
be able to manage
Reject Auth. authorisations with
Delete Auth. unwanted
counterparties.

12 January 2024 90
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Entity Operator A Operator B Operator C Risk

functions functions functions

SWIFT Interface Add LT Enable LT If an operator can

SWIFT Support solely add and
Modify LT Remove LT
approve an LT,
Disable LT then they can add
additional,
unwanted LTs that
can send
messages to Swift.

SWIFTNet Add EProf/RProf Enable EProf/RProf If an operator can

Interface solely add and
Modify EProf/RProf Remove EProf/
approve an
RProf
Disable EProf/ emission profile,
RProf then they can add
additional,
unwanted emission
profiles that can
send messages to
SwiftNet.

System System SWIFTNet Support If an operator can

Management Management - - SNL Handling solely modify the
Stop/Start connectivity to a
SWIFTNet Support
Component Gateway and apply
the new
configuration by
restarting the
required
components, then
they could redirect
traffic to the wrong
Gateway and
therefore get
access to
messages.

Security parameter
Because of the current security challenges, your security auditors will insist on LSO/RSO assigning
the right roles to the right people and ensure that the configuration of Alliance Entry is well
controlled.
The security parameter System - 4 Eyes mechanism is set to enabled by default. Having this
security parameter set enforces the requirement that more than one person must change and
enable operators and message partners.
Using this feature avoids the need to set up two operator profiles with mutually exclusive
permissions to implement an explicit separation of duties. With this feature you need actions from
two different people to create/modify and enable the changes while they have the same role.
At the same time, Alliance Entry tracks who created and who made the last modification to
operators and message partners. The last modifier cannot enable the message partner. If this is
attempted, an error will be displayed. Additionally, keeping the last modifier tracked enables
changes to be better monitored.

12 January 2024 91
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

The following tables provide an example of how this parameter enforces a four-eye policy for
updates to message partners and operators functions:

For message partners:

Previous action taken Next action authorised Next action NOT
authorised by the same
person (user account)

Add / Add as Update Enable

Delete

Update Update Delete

Enable

Enable Disable Delete

Disable Enable Delete

Update

For operators:
Previous action taken Next action authorised Next action NOT
authorised by the same
person (user account)

Add / Add as Update

Approve
Delete

Update Update Delete

Approve

Approve Update Delete

Disable

Enable Update Delete

Disable

Disable Enable Delete

Update

[Link] Alliance Gateway Authorisation

The Alliance Gateway application provides an authorisation scheme to manage user privileges,
which allows applying the least-privilege and separation of duties principle. This is referred
alternatively as "dual authorisation" or a "four-eye" scheme.

Embedded role-based profiles and units

Alliance Gateway consists of a number of entities and functions that can be assigned to operator
profiles. When Alliance Gateway is installed, an operating profile called Administrator is created

12 January 2024 92
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

and assigned to an operator of that name, also created at installation. This profile includes all
Alliance Gateway operating profile functions and is used to create additional operators and profiles
as per the customer business needs, and in accordance with the security principles of need-to-
know access, least privilege, and separation of duties.
Customers can implement a four-eye principle for operations related to the management of
operators, SwiftNet user profiles (virtual SwiftNet users), and other entities. This approach
effectively ensures that one person acting alone cannot configure Alliance Gateway entities that
are ready to use. A second person must validate the action of the first person.
More information about access control defined per operator type in Alliance Gateway is provided
below.

Administrator
When you install Alliance Gateway, an application operator called Administrator is created with full
operating profile functions.
Therefore, the security of the Administrator operator password is critical. Also, if you lose the
Administrator password and do not have a second administrator defined, you must reinstall
Alliance Gateway.
Note You can reset this password. For more information, see Knowledge Base article
5024091.
The Administrator operator can create additional operators and assign them operating profiles with
suitable functions to enable them to fulfil their responsibilities.

Operators
The customer can create various operator accounts according to their business needs. By means
of the operator profile entitlements and permissions, the customer can implement least privilege
and separation of duties.
It is the customer's responsibility to carefully review the available operator profile functions that are
assigned to each operator. Each operator should be assigned the minimal number of functions that
enable them to perform their day-to-day routine.
Note An Alliance Gateway operator can only perform administrative tasks in Alliance
Gateway. It cannot exchange business messages over SwiftNet. SwiftNet business
applications are only available when logging into Alliance Gateway as a SwiftNet user.
For guidance on how to split specific permissions over two operators, see the section on dual
authorisation in the Alliance Gateway Administration and Operations Guide.

SwiftNet users
SwiftNet users may be the following:
• Individuals using the Swift Web Access GUI that runs in Alliance Web Platform Server-
Embedded
• Software applications that use Alliance Gateway to access SwiftNet to send and receive
messages and files.
Note SwiftNet users are not authorised to perform administrative tasks in Alliance Gateway.
They access SwiftNet business applications by means of the Swift Web Access GUI.
Each SwiftNet user is associated with a PKI certificate profile. Swift provides a Public Key
Infrastructure (PKI) service for issuing PKI certificates and assigning in the respective profile the
required Role-Based Access Control (RBAC) roles as per the customer's business needs.
For more information about certificate administration, see PKI Certificate Administration (SwiftNet
Online Operations Manager and Alliance Gateway) on page 94.

12 January 2024 93
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Virtual SwiftNet users

Each virtual SwiftNet user is linked with a SwiftNet user. As such, no profile needs to be managed
for virtual users in Alliance Gateway. Each virtual SwiftNet user is identified by its own credentials.
All applicable configuration parameters in Alliance Gateway apply to virtual SwiftNet users, not to
SwiftNet users.

[Link] Alliance Web Platform Server-Embedded

Alliance Web Platform Server-Embedded users connect to the Alliance Web Platform Server-
Embedded package from the web browser. Every Alliance Web Platform Server-Embedded user
has a profile attached to it.
There are two operator profiles provided by default in Alliance Web Platform Server-Embedded:
• Administrator: A user with the Administration profile can perform all operations within the
Alliance Web Platform Server-Embedded package.
• Monitoring: A user with the Monitoring profile can only perform operations that do not modify the
configuration of Alliance Web Platform Server-Embedded. Triggers implying modifications to the
Alliance Web Platform Server-Embedded configuration will not be visible for a monitoring user.
The profile drives the user operations that are allowed within the Alliance Web Platform Server-
Embedded package. The customers cannot create additional profiles.

[Link] PKI Certificate Administration (SwiftNet Online Operations

Manager and Alliance Gateway)
SwiftNet Public Key Infrastructure (PKI) is a Swift facility that provides certification services to
entities that send and receive messages or files over SwiftNet. These entities are typically users,
applications, and SwiftNet interfaces that apply digital signatures and encryption. The certification
services also include the issuance and management of certificates.
Note A user of a PKI certificate profile is called a SwiftNet user.
The following diagram shows the various states and transitions that an entity and the related
certificate can pass through.

Disable
Registered Ready for Certified Revoked Disabled*
certification Create
Certify Revoke Disable Delete
certificate

Recover
Delete Create Disable Deleted
Recover
certificate
Ready for
recovery
D1260001

* If the certificate is not already revoked, it must be revoked before it can be deleted.

Managing entities and their associated PKI certificates requires the execution of certain
administrative activities by SwiftNet security officers using the SwiftNet Online Operations
Manager, and subsequent actions from an operator with the relevant permissions in Alliance
Gateway.

12 January 2024 94
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

SwiftNet Online Operations Manager (O2M)

The SwiftNet Online Operations Manager is an application offered through Swift-managed
WebAccess services. It is designed to enable online SwiftNet security officers to manage the
customer entities (users and applications) and associated certificates, and to delegate Role-Based
Access Controls (RBAC) roles.
SwiftNet security officers use the following applications within O2M:
• Local Registration Application: to manage entities (such as register a new entity, set up a
SwiftNet certificate user for certification, revoke, set up a user for recovery, disabling, and
deleting).
• Role-Based Access Control application: to manage roles associated to a customer's entity
(such as granting or ungranting RBAC roles).
A SwiftNet security officer must apply the “need-to-know”, “least privilege”, and “separation of
duties” principles for the management of entities and the associated RBAC roles.
Security officers are responsible for regularly reviewing the list of certificates within their scope of
authority. Security officers must verify that all certificates in the list are still required and
appropriate, and if not the case, then the security officers must revoke or disable those certificates
that are no longer valid. The SwiftNet security officer must revoke a certificate when an end user
believes that the password has been compromised. The security officer must revoke and disable a
certificate when an end user or security officer has left the department or institution.
For more information about SwiftNet security officer best security practices, see Alliance Security
Officers on page 35.
PKI certificates
The core of the PKI solution is the private key and its associated certificate. A certificate on
SwiftNet is an electronic file signed by the SwiftNet Certification Authority. There is one PKI
certificate per SwiftNet user.
PKI certificates conform to the X509v3 standard format, and the type of certificate class used in a
local Swift infrastructure is one of the following:
• Business certificate: Customers can only use Business certificates to sign traffic sent on live
services. These certificates must be stored on a Hardware Security Module (HSM) device. They
are identified by policy ID [Link].2.
• Lite certificate: Customers can use Lite certificates only to sign traffic sent on Test and Training
or pilot services. Lite certificates cannot be used to sign traffic sent on live services. The policy
ID for Lite certificates is [Link].[Link].
Lite certificates enable customers to further enforce environment separation. For example, if
customers use Lite certificates in the Test and Training environment, it is not possible for a test
message to be sent from that environment over the live service by mistake. Although the policy that
protects the private keys and passwords for Business certificates is stronger than the policy that
protects Lite certificates, the cryptographic strength of Business and Lite certificates is equal.

Alliance Gateway
An Alliance Gateway operator with the permissions to manage SwiftNet certificates is responsible
for certificate management activities once a SwiftNet PKI profile is available for use on the Alliance
Gateway application. The certificate management activities on Alliance Gateway include
certification, certificate recovery, adoption, and certificate deletion for a SwiftNet user.
Draft SwiftNet certificates
A draft SwiftNet certificate is a concept that enables clear operational separation between an
Alliance Gateway operator or administrator and any SwiftNet user during the certification or

12 January 2024 95
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

certificate recovery process, thereby mitigating any risk of impersonation due to multiple people
knowing the certificate password.

Enhanced process

Security officer

R e yp e
+T
de

fer of
co

en ac
n

ce tio
tio

Nu n C
a
ris

mb /R
tho

er
Au

Certificate Name

End User
Gateway Admin

Creates ‘logical’ certificate ready

for certification

No impersonation
possible

Log in using authorisation code,

then choose initial password

D1700015
Requires Alliance Web Platform

Following is the procedure for using a draft SwiftNet certificate:

1. With a reference number provided by a SwiftNet security officer, a user in Alliance Gateway
with the operating profile function ‘Adopt a Certificate’ can pre-certify or pre-recover a SwiftNet
certificate. This action places the SwiftNet certificate in Draft status.
2. The SwiftNet user receives the profile name from an Alliance Gateway operator. The related
authorisation code is provided by a security officer. The SwiftNet user uses this authorisation
code as a password when logging in as a SwiftNet user (for example, to the Swift Web Access
application). When Alliance Gateway receives a login request from an operating profile that is
linked to a SwiftNet certificate in Draft status, Alliance Gateway requests the SwiftNet user to
provide an appropriate value for the password of the profile.

12 January 2024 96
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

List of Recommendations
Alliance Access/Entry, Alliance Gateway

ID Recommendation Product

AAS.01 The "need-to-know", "least privilege", and "separation of Alliance Access/ Entry
duties" principles are applied when defining operators and
Alliance Gateway
operator profiles in Alliance applications.
The embedded logical access control and security
parameters features can be used for this purpose.

AAS.02 The left and right security operators (LSO/RSO) are two Alliance Access/ Entry
independent individuals, with independent back-ups
identified in case of their absence.

AAS.03 Security officers or administrative application accounts are All

not combined with any Swift-related transaction operations
role (for example, the creation or modification of a
financial transaction message within Alliance Access/
Alliance Entry, accessing WebAccess services, and so
on).

AAS.04 Sensitive permissions of profiles assigned to a message Alliance Access/ Entry

partner (for example permissions related to currency and
amount) are restricted.

AAS.05 The SuperKey operator profile on the production system is Alliance Access/ Entry
removed.

AAS.06 The use of the System Administrationpplication is Alliance Access/ Entry

restricted to the Alliance Access/Entry administrator
(application owner) account.
The usage of the Alliance administrator account must be
traced.

AAS.07 Login with built-in Alliance Gateway Administrator Alliance Gateway

accounts is restricted to perform activities where such an
account is specifically needed (for example, the initial
application configuration, application upgrade, or
emergencies).
Individual accounts with well-separated profiles assigned
are used instead for all day-to-day operations.

AAS.08 Login with built-in Alliance Web Platform SE Administrator Alliance Web Platform
accounts is restricted to those activities where such an Server-Embedded
account is specifically needed (for example, the initial
application configuration or emergencies).
Individual accounts using the same built-in account profile
are used instead for all day-to-day operations.

AAS.09 The security parameter System - 4 Eyes is set to Alliance Access/ Entry
enabled to enforce the separation of duties for operators,
message partners, and routing rules.

12 January 2024 97
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

AAS.10 Assess the business need for any operator profile having Alliance Access
the "Routing/ Mod Active Schema" entitlement and adjust
if needed.
Careful consideration is given to who is assigned this
permission and the account activity is tightly controlled.

AAS.12 There is an emergency procedure to access the Alliance Access/ Entry

application with a privileged account (for example, the
Alliance Gateway
default Alliance Gateway Administrator or the Alliance
Web Platform SE Administrator). An emergency procedure Alliance Web Platform
is helpful when the authorised people are unavailable due Server-Embedded
to unexpected circumstances.
The emergency procedure is documented, and the usage
of the procedure is controlled and logged. Under no
circumstances should it allow a non-authorised person to
access the Alliance software unnoticed.

AAS.13 Logical access controls are regularly reviewed (at least All
annually, ideally more frequently).
When an employee changes roles or leaves the company,
their access rights are promptly modified or revoked.

AAS.14 The Alliance Gateway operators (having privileges related O2M

to PKI certificate management) and SwiftNet security
(SLA.08 used in Secure Channel
officers are different people.
the Security Best
Alliance Gateway
Practices Check
Tool)

O2M (SwiftNet Online Operations Manager)

ID Recommendation Product

CAD. The "need-to-know", "least privilege", and "separation of duties" principles O2M
03 are applied when defining SwiftNet users and PKI Certificates.

CAD. There is a generally approved and traceable workflow in place to track new O2M
04 certificate requests, as well as the integration with an exit process (that is,
when an employee changes roles or leaves the institution) for:
• the creation, modification, and deletion of User Certificates, as well as
the granting/ungranting of related RBAC roles
• the certification and recovery of SwiftNet Link Certificates
• the creation, modification, and deletion of Web Certificates.

CAD. The certificate is uniquely identifying the individual or application within a O2M
05 given entity (8-character BIC).
Use the User Name field to identify the end user, authenticated by the
certificate. This enables end users to be linked to and held accountable for
their actions.

CAD. The certificate class (for example, Business or Lite), Policy ID, and password O2M
06 policy (either human or application) is applied correctly.

12 January 2024 98
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

CAD. A procedure is in place for the SwiftNet security officers to review on a O2M
07 regular (monthly) basis the list of certificates within their scope. The report
functionality on O2M is used for that purpose.
They should check the entities/DNs in the SwiftNet Online Operations
Manager (O2M - role and certificate reports) and verify that:
• They know the purpose of that entity/DN and whether it is still required.
• They know where it is being used (which system, geographical location,
and so on).
• It still has the correct RBAC roles, and only the roles that are needed.
• The related certificate is still valid.

Further Reading
• Alliance Access Security Guide - Security Features of Alliance Access
• Alliance Access Configuration Guide - Units
• Alliance Entry Security Guide - Security Features of Alliance Entry
• Alliance Gateway Administration and Operations Guide - Operating Profiles
• Alliance Gateway Security Guide - Alliance Gateway Security Considerations

5.5.9 Token Management (CSCF Control 5.2)

Hardware Security Module (HSM)

Customer-specific SwiftNet signing and decryption private keys are stored inside the Hardware
Security Modules (HSMs). All signing and decryption operations are performed directly in the HSM,
without the private keys ever leaving this secure enclosure. Customer private keys are locally
generated.
HSMs are FIPS140-2-level 3 compliant devices and exist in one of two forms:
• LAN-connected device (HSM box)
• PC-connected USB token (HSM token)
See also Scope of Security Controls > Swift Hardware Security Modules (HSMs) in the Swift
Customer Security Controls Framework Detailed Description.

HSM Box
Sensitive HSM management operations require use of PIN Entry Devices (PED) and PED keys.
For more information, see the HSM Box Operations Guide.
User roles can be assigned to user accounts to control the types of tasks that the user may
perform, such as administering, operating, or monitoring the Hardware Security Module Box.
The Hardware Security Module Box has the following types of user roles:
• admin: can perform tasks, such as unlocking a certificate, initialising a partition, registering a
SwiftNet Link, and installing or upgrading the HSM software. Swift scripts use this account for
administration. The admin user may also ensure the security of the PIN Entry Device (PED)
keys, and manage the Hardware Security Module Box. HSM boxes 6.1 and up have by default
two administrators: admin, and admin2.

12 January 2024 99
Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

• operator: can perform system-level tasks, such as activating and deactivating a partition, and
restarting a Hardware Security Module Box. Some sensitive tasks the operator can perform will
require PED operations.
• recover: to reset the admin account if all administrators are locked, and to reset an Hardware
Security Module Box to default factory settings.
• monitor: to run SwiftNet Link commands swiftnet getconfig -T, swiftnet status - T,
and swiftnet getstatus -T
Additional accounts can be created and assigned the above roles. The only exception is the
recover role, because there can only be one recover account. Misuse of the recover account can
be damaging to the cluster, and potentially main message flow (MMF).
Swift recommends the creation of additional accounts with admin role privileges. This ensures that
you always have an admin account available to perform sensitive Hardware Security Module Box
commands, even if one admin account is locked out or its password is lost.
At a minimum, it is strongly advised to split access to the user role passwords from access to the
PED keys. This will enforce the four-eye principle.

Remote PED Workstation

Remote PED is used to manage a Hardware Security Module Box from a distant location. The
Remote PED Workstation is the Windows system where the Remote PED is physically connected.
This system requires the Remote PED Server software that enables the Hardware Security Module
Box to communicate with the Remote PED over TCP/IP. The Remote PED Workstation must be
accessible over a LAN or WAN from the SwiftNet Link.
Remote PED Workstation can be located within or outside the secure zone. In the latter case, the
following Swift's security requirements apply:
• A Remote PED workstation may be installed and operated outside of the secure zone, provided
that it is dedicated to that functionality, with no software installed except for the operating
system, the remote PED software, and security software, such as antivirus software and VPN.
• The remote PED workstation should be a dedicated device with no other purpose, and should
not be a general-purpose operator PC.

HSM Token
A Hardware Security Module Token (eToken 5110 by SafeNet) is a small, lightweight device that fits
on a key ring. It connects to the PC through a Universal Serial Bus (USB) port. The Hardware
Security Module Token is only supported with SwiftNet Link hosts on Windows systems. SwiftNet
Link supports the simultaneous connection of up to ten HSM tokens.
Each Hardware Security Module Token can store one certificate (user or application certificate) and
can handle a limited throughput.

List of recommendations
ID Recommendation Product

HSM.01 The PIN Entry Device (PED) and PED keys are securely stored. HSM

HSM.02 Physical access to the PED and PED keys is logged. HSM

HSM.03 The USB token is securely stored when it is not in use. HSM

HSM.04 The USB token is not left unsupervised when it is in use. HSM

12 January 2024 100

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

HSM.05 USB tokens are distributed and assigned appropriately, and are HSM
revoked when the person leaves the company.

HSM.06 The admin user is the sole owner of the SO/HSM Admin key. HSM

5.5.10 Software Integrity (CSCF Control 6.2)

Software integrity for Alliance products is integrated into each application.
Alliance Access, Alliance Entry, Alliance Web Platform SE, Alliance Gateway, and SwiftNet Link
provide a mechanism to verify that their own software has not been modified and is genuine.

Automatic integrity check

Alliance Access, Alliance Entry, Alliance Gateway, SwiftNet Link, and Alliance Web Platform SE
are configured to automatically run a software integrity check at startup.
In addition to the integrity check at startup, an integrity check runs automatically at regular
intervals.
Alliance Web Platform SE
The automated integrity check runs regularly in the background for all installed GUIs.
SwiftNet Link
Before starting, an integrity check is made against the installed packages. If the check fails, then
the SwiftNet Link application cannot be started. Otherwise, required subsystems are started.

Integrity check on demand

It is also possible to check the integrity of all executable files on demand. Instructions for running a
manual software integrity check can be found in the documentation of each product:
Alliance Access
• Interactive: Configuration Guide - Software Integrity Check
• Command Line: Administration Guide - "Checking the Alliance Access Software Files" (AIX
Linux Windows)
Alliance Entry
• Interactive: Configuration Guide - Software Integrity Check
• Command line: Administration Guide - Checking the Alliance Entry Software Files
Alliance Gateway
• Interactive: Administration and Operations Guide - Software Integrity Check
Alliance Web Platform SE

12 January 2024 101

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

The swp_integrity command-line tool executes a file integrity check (FLIC). For more
information, see:
• Command line: Administration and Operations Guide - File Integrity Check
SwiftNet Link
• Command line: SwiftNet Link Operations Guide - Security Guidelines

Code signing for Windows delivery

Alliance Access/Entry, Alliance Gateway, and Alliance Web Platform SE use code signing.
Code signing is used to verify that the deployed software is genuine. All Alliance .exe and .dll
files provided by Swift are digitally signed on the Windows platform. This signature (using the
SHA256 digest algorithm) is stored in the Digital Signature tab of the .exe or .dll file properties.
Customers can use off-the-shelf tools to verify or monitor these signatures.

List of recommendations
ID Recommendation Product

SWI.01 A software integrity check is regularly performed on the Alliance Alliance Access/
products. Entry
Alliance
Gateway
SwiftNet Link

SWI.02 The Alliance products are automatically configured to execute a Alliance Access/
software integrity check at startup. If it fails, then the product does not Entry
start. In such situation, check the related logs and contact Swift
Alliance
Customer Support.
Gateway

SWI.03 When downloading Alliance software, the checksum mentioned on Alliance Access/
[Link] is matched against the actual checksum of the file. Entry
Alliance
Gateway

SWI.04 Verify and monitor signatures provided in all executables and shared Alliance Access/
libraries provided by Swift, as part of Alliance products code signing. Entry
Alliance
Gateway
Alliance Web
Platform Server-
Embedded

For more information about checking the software integrity, see Knowledge Base article 5017861.

5.5.11 Database Integrity (CSCF Control 6.3)

Database integrity check functionality is integrated into messaging interfaces of Swift (Alliance
Access and Alliance Entry with an embedded or hosted database, and other Alliance products such
as Alliance Gateway and Alliance Web Platform Server-Embedded).

12 January 2024 102

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Database integrity checking ensures that any changes to data in the database are detected at the
next read or update of that record. It does not, however, protect against the deletion (accidental or
otherwise) of data records.
It is also possible to manually initiate a database integrity check. Instructions for running a manual
database integrity check can be found in the documentation of each product.

Alliance Access/Entry
Alliance maintains database files, each of which consists of a number of records. Each record
stores a particular piece of information. The integrity of this data is checked at various times to
ensure that no information has been corrupted or altered since being stored in the database. A
record-by-record "data integrity check" is performed on all data stored in an Alliance database,
whenever data is:
• read from a database
• modified in a database.
A new check value is calculated whenever a record is updated or a new record is added to a
database.
The integrity of the Alliance Access/Entry database is checked in the following ways:
• Automatic database integrity check on startup
• Automatic database integrity check: The integrity of the database is automatically checked
every time a record of the database is read or updated.
• Manual database integrity check
For more information, see:
• Interactive: Alliance Access Configuration Guide - Database Integrity Check
• Command line: Alliance Access Adminstration Guide - Checking the Alliance Access Database
(AIX Linux Windows)
• Interactive: Alliance Entry Configuration Guide - Database Integrity Check
• Command line: Alliance Entry Administration Guide - Checking the Alliance Entry Database

Alliance Gateway
The integrity of the Alliance Gateway database is checked in the following ways:
• Automatic database integrity check on startup: When an attempt is made to start Alliance
Gateway, the integrity of the Alliance Gateway database is automatically checked. How Alliance
Gateway reacts to a database integrity failure depends on the value of the Shutdown on
Database Tampering Detection configuration parameter.
• Automatic database integrity check at midnight: Every day at midnight, Alliance Gateway
checks the database integrity for all objects that contain a signature. If a failure is detected, then
the relevant event is logged and an alert is raised, but Alliance Gateway does not stop.
• Automatic database integrity check: The integrity of the database is automatically checked
every time a record of the database is read or updated. How Alliance Gateway reacts to a
database integrity failure depends on the value of the Shutdown on Database Tampering
Detection configuration parameter.
• Manual database integrity check: Swift highly recommends to periodically check the integrity of
the Alliance Gateway database, using the sag_system -- dbintegrity command. You can
run the sag_system -- dbintegrity check on the database integrity manually, irrespective of
Alliance Gateway's state.

12 January 2024 103

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

For more information, see:

• Interactive: Administration and Operations Guide - Database Integrity Check
• Command line: Administration and Operations Guide - Check the Alliance Gateway Database
Integrity

Default setting for security configuration parameter

A security configuration parameter is provided in Alliance Gateway named Shutdown on
Database Tampering Detection. The default value is Yes.

Alliance Web Platform Server-Embedded

The integrity of Alliance Web Platform Server-Embedded database is checked automatically on
startup and manually by running the command swp_dbasignature -verify or swp_config -
dbasignature. Tampered data in the Alliance Web Platform Server-Embedded database is
detected when the Alliance Web Platform Server-Embedded accesses the data, and is reported in
the event log.
For more information, see Administration and Operations Guide - Verify the Database Integrity.
List of recommendations
ID Recommendation Product

DBI.01 A database integrity check is regularly performed on the Alliance Alliance Access/
products. Entry
Alliance
Gateway
Alliance Web
Platform Server-
Embedded

DBI.02 Ensure that the new security configuration parameter Shutdown on Alliance
Database Tampering Detection is always set to Yes. Gateway

For information about checking the database integrity, see Knowledge Base article 5017861.

5.5.12 Logging and Monitoring (CSCF Control 6.4)

Alliance products provide logging and monitoring features that can be used to help with the
detection of anomalous actions and operations within the local Swift infrastructure.

[Link] Logging

Event Log
All Alliance products identify and record events about all successful and unsuccessful actions
performed by operators and by the system, in an Event Log. This data provides a detailed audit
trail of all actions performed in Alliance applications. In Alliance applications, it is possible to
configure an event to trigger an alarm if the event occurs.
Customers can use the event log for monitoring, audit, and investigation purposes by searching the
events stored in the application itself or distributing them to other centralised monitoring systems.

12 January 2024 104

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Event Journal
On Alliance Access and Alliance Entry, there is a Secure Configuration parameter (BSS/
Journalise Msg Text) that enables security officers to determine whether they want to journalise
the business payload. By default, this parameter is set to not include the business payload in the
Event Journal (Message Text Not Journalised).

Event Distribution to Monitoring Systems

Because it may become difficult to monitor all logs on each local system, customers can opt for a
Security Information and Event Management (SIEM) system. Such a system enables you to gather
and analyse information from multiple hosts and applications in a central location. Alliance
applications support different formats for distributing events to such SIEM or other monitoring
systems.
• Common Event Format (CEF)
You can receive output of events in the standardised Common Event Format (CEF) in Alliance
Access/Entry, Alliance Gateway, and Alliance Web Platform Server-Embedded.
Most centralised logging systems can retrieve the information in CEF format from the logs of the
operating system. It is possible, similar to event distribution using SNMP, to define for each
event type whether it should be distributed in CEF format to the local system log (syslog or
Windows Application Event log).
Alliance Access/Entry also provides the option to use JSON or formatted JSON in addition to
CEF, using the same formalisation of data.
• SNMP configuration
Alliance products can be configured to raise alarms when certain conditions are met. These
alerts can be forwarded to an SNMP server for centralised logging and monitoring.
- Alliance Access
Events can be forwarded to an SNMP system by adding a distribution list that contains an
SNMP server. When a distribution list is configured, it can be selected in the event
distribution for events that have an alarm "for information" or "for action".
- Alliance Gateway
Events can be forwarded to an SNMP system by configuring an SNMP server address.
When the server address is configured, events that are configured to be logged through
SNMP will be sent to the configured server.
- Alliance Web Platform Server-Embedded
Events can be forwarded to an SNMP system by configuring the SNMP Server
Communication parameter. When the server address is configured, you can modify the
SNMP Event Distribution parameter to indicate the severity of events that will be sent to
the SNMP server.
• Alarm Scripts
An operator with permission to change security parameters can configure Alliance Access to
collect all alarms and copy them to a file, from which they can be processed further. An alarm
script is used to collect the alarms and store them in a file, and Alliance Access runs the script
whenever an alarm occurs.
The Path of Script File security parameter specifies the full pathname of the directory that
contains the script to collect alarms.
• Sending MT999 messages to internal correspondents

12 January 2024 105

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Alliance Access can create MT999 messages based on events and send these to internal
correspondents. The customer can add internal correspondents to an event distribution list.
When the distribution list is configured, it can be selected in the event distribution for events that
have an alarm "for information" or "for action". This enables Alliance Access to route the MT 999
to the inbound queue of the preferred network that is assigned to the internal correspondent.
For example, if the network is APPLI, then Alliance Access routes the MT 999 to a predefined
exit point.
• Logging with Command Line
There are a number of Alliance commands that help you export the content of event from the
database of Alliance products.
- Alliance Access
You can use the saa_system readlog command to place events that belong to a specified
log into a text file.
You can use the saa_query command to run a query to export the contents of events in XML
format.
- Alliance Gateway
You can use the sag_system – readlog or sag_readlog command to generate an XML file
containing a copy of the events in the Alliance Gateway event log.
- Alliance Web Platform Sever-Embedded
You can run the swp_readlog or swp_config - readlog tool to enable access to
information stored in the event log of the Alliance Web Platform Server-Embedded database.
The content of the events is copied into an XML file.
The events of SwiftNet Link and HSM are embedded into the Alliance Gateway event log.
Note In addition, during operations, SwiftNet Link generates event logs, which you can use
to help in problem solving. The SwiftNet Link event logs are XML files that are named
in the format [Link] (where YYMMDD is the year/month/day), and the
XML style sheet is [Link].

[Link] Monitoring

Monitoring with GUI

The monitoring of Alliance applications activities can be performed by using the related Alliance
GUI package, Alliance application commands, or other external applications used by customers.
A description of each Alliance application GUI monitoring capability is provided below:
Alliance Access/Entry

12 January 2024 106

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

The Alliance Access/Entry Monitoring application is a GUI package that can help in monitoring
multiple Alliance Access/Entry instances. Using this package, operators can monitor and treat
events/alarms related to the following entities:
• FIN logical terminals
• SwiftNet profiles
• Message partners
• Queues
• Systems
• Operator sessions
• File transfers
• Events
Alliance Access enables the customer to add operators to an event distribution list. When the
distribution list is configured, it can be selected in the event distribution for events that have an
alarm "for information" or "for action". These events will appear for the configured operators in the
Monitoring application. This feature is not available in Alliance Entry.
If you do not have a centralised logging and monitoring application that offers logical intelligence
capabilities, then it is important to be vigilant to patterns, for example, multiple consequent invalid
login attempts.
Alliance Gateway
The Alliance Gateway Administration application is a GUI package that can help in monitoring
multiple Alliance Gateway instances. Using this package, operators are informed of the status of
various operational areas in a consolidated view, using the Alert page, such as:
• Processes
• Systems
• Last logins (for operators, virtual SwiftNet users, and SwiftNet certificates)
• Queues
• MI Channels message flow instances
• HSM status
The page provides information that helps operators identify the location of a problem and
determine the criticality of the problem.

Important The Activate Alert Monitoring parameter is set to Yes by default. This parameter can
be set to No. Only if alert monitoring is activated, Alliance Gateway will create alerts.

Another operating profile called Dashboard_Monitor is created during installation. This profile
includes all the functions required to monitor alerts and to use related parts of Alliance Gateway
Administration.
Alliance Web Platform Sever-Embedded

Monitoring with Command Line

Using the Alliance Web Platform Server-Embedded Administration, the operator can monitor the
following activities:
• Events
• User Sessions

12 January 2024 107

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

The "Instance Monitoring Overview" gives also an overview of the instances configured in Alliance
Web Platform Server-Embedded and the operational viability of each instance. This assists
operations staff in detecting any circumstance that requires their attention.
Alliance Web Platform Server-Embedded provides a "Monitoring user" profile that can only perform
operations that do not modify the configuration of Alliance Web Platform Server-Embedded.
There are a number of Alliance commands that help you monitor security-related processes:
• Alliance Access:
- You can use the saa_system status and saa_system dbintegrity commands to check
the status of the Alliance Access database and servers, and also to detect unauthorised
updates.
- You can use the saa_monitor command to extract selected monitoring information from
Alliance Access and to store this information in an external text file.
• Alliance Gateway:
- You can use the sag_system -- status and sag_system -- dbintegrity commands to
check the status of the Alliance Gateway database and servers, and also to detect
unauthorised updates.
- You can use the sag_monitor_and_stop command to check for specific information in the
Alliance Gateway Event Log and automatically stop Alliance Gateway under certain
conditions.
• Alliance Web Platform Server-Embedded:
- You can use the swp_dbasignature command to check the integrity of the database.
These commands can be launched either manually or from a scheduler application running outside
Alliance Access. These commands can be invoked locally from customer-developed scripts, or
remotely through agents running locally on the Access server and controlled remotely by
supervision systems.

Monitoring by means of external monitoring applications

Customers can configure their Alliance applications to send Alliance event logs in CEF, SNMP
traps, or alarm scripts to a central monitoring application.

List of recommendations
ID Recommendation Product

ALG.01 Application Event Logs are regularly reviewed. All

ALG.02 Application Event Logs are stored on a remote system that cannot be All
accessed by the same individuals.

ALG.03 Event Log files are safestored and available for audits or forensic All
investigations.

ALG.04 Where applicable, Alliance Event Log events are integrated with a Alliance Access/
centralised logging and monitoring system. Entry
Alliance
Gateway
Alliance Web
Platform Server-
Embedded

12 January 2024 108

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

ID Recommendation Product

ALG.05 Alarms are defined for security events. All

To capture security events, you configure alarms and operator
notifications for aspects such as (but not limited to): "invalid login
attempt", "integrity error", "LAU error", "checksum error", and "security
errors".

ALG.06 Ensure that the Alliance Access alarm script is owned by the software Alliance Access/
owner. Entry

ALG.07 In the case of the monitoring by means of GUI option, ensure that the Alliance
parameter Activate Alert Monitoring is set to Yes. Gateway

Further reading
• Alliance Access Configuration Guide - Event Log
• Alliance Access Security Guide - Event Log
• Alliance Entry Configuration Guide - Event Log
• Alliance Entry Security Guide - Event Log
• Alliance Gateway Administration and Operations Guide - Event Log
• Alliance Gateway Security Guide - Event Log
• Alliance Web Platform Server-Embedded Administration and Operations Guide - Event Log

5.6 Other Security Recommendations

This section provides additional security recommendations that are not necessarily linked with one
of the specific domains covered in other sections.

Link with CSCF security controls

The CSCF security control applicable to the other security recommendations section is highlighted
in the following diagram:

1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4A 2.5A 2.6 2.7

2.8 2.9 2.10 2.11A 3.1 4.1 4.2 5.1 5.2 5.3A 5.4 6.1

6.2 6.3 6.4 6.5A 7.1 7.2 7.3A 7.4A

CSCF security control further detailed in this guide

CSCF security control relevant in this domain but covered in CSCF only
D1700016

Not relevant

12 January 2024 109

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

The following CSCF control has Alliance-specific security guidance (in addition to the CSCF
guidance) documented within this section:
• Cyber Security Incident Management (CSCF Control 7.1) on page 110
In addition, recommendations are provided in Back-up and Resilience on page 110 for the local
Swift infrastructure, which is not in the scope of the CSCF.

5.6.1 Cyber Security Incident Management (CSCF Control 7.1)

A cyber security incident can happen in any institution. It is important to be well prepared and have
a clear incident response plan. The Cyber Security Incident - Recovery roadmap contains a
number of Swift guidelines on how to respond to a cyber security incident. Because each institution
has its own unique requirements, and there is no all-encompassing incident response plan, this
information is intended to help institutions create their own plan.
Although this action plan should be triggered only in case you are compromised, Swift
recommends that all of its members are familiar with this document in case a security incident
occurs at their side. Being prepared can reduce the operational, financial, and reputational impact
when an incident occurs.
Note The Cyber Security Incident - Recovery roadmap provides a non-exhaustive list of
steps or actions that a customer must follow in case of a cyber security breach.
Internal security policies, laws, and regulations must be followed as required in each
customer's jurisdiction.

List of recommendations
ID Recommendation Product

IMA.01 The customer has a sound and tested cyber security incident management All
process that includes information about who to contact, which channels to
use, and under what conditions to use them.

IMA.02 The Cyber Security Incident - Recovery roadmap is integrated or checked All
against in the internal cyber security processes and plans. As per their
roles, employees are aware and trained on the respective actions required
to be followed in case of a cyber security breach.

IMA.03 Regularly review and consume information shared by means of the Swift All
ISAC portal, and share evidence or indicators of compromise with Swift.

5.6.2 Back-up and Resilience

It is good practice to back up both data and software on a periodic basis. These back-ups must be
securely stored in a remote location. If a situation occurs that the data or software are corrupted,
then a recent back-up provides a starting point to restore the system.
The architecture of Alliance products enables a customer to achieve the availability and resilience
levels that are typically required for business-critical applications. The customer should carefully
consider availability and resilience objectives, and choose a deployment and configuration set-up
that meets those requirements. This equally implies that the supporting customer infrastructure,
upon which Alliance products rely and are built, must be set up to provide similar availability and
resilience levels.

12 January 2024 110

Alliance Security Best Practices and Swift Security Recommendations
Security Guidance

Back-ups
Customers should implement a back-up strategy to ensure that data can be retrieved in case it is
made unavailable. Alliance products provide import/export features designed for such purposes.
Back-ups must be encrypted and stored securely.
Confidentiality of the data stored in the back-ups should be ensured if the back-ups are stored
outside of the Swift Secure Zone. Implementation guidelines of control 2.5A External Transmission
Data Protection should be followed.

Resilience
Customers can set up a second operating site to ensure that activities are not interrupted (for
example, in the case of natural disaster). This recovery site should contain up-to-date configuration
data to ensure efficient failover.

List of recommendations
ID Recommendation Product

SBS.01 Back-ups of data and software are made frequently. The back-up All
policy and procedures are documented. The process to restore back-
ups is documented and is tested periodically.

SBS.02 Availability and resilience objectives, such as Recovery Time Objective All
(RTO) and Recovery Point Objective (RPO) are defined, considering
the business criticality of the services supported by the application.

SBS.03 IT continuity plans for the Alliance applications are documented, All
tested, and updated regularly to ensure that they are up-to-date and
effective. Testing of plans and relevant procedures for the restoration
of Alliance applications at the recovery site is performed at least
annually.

SBS.04 Ensure back-up people are identified especially for privileged accounts All
in the local Swift infrastructure to ensure the business continuity of
operations.

SBS.05 Sensitive Swift-related data leaving the secure zone as a result of All
back-ups, data replication for recovery, or further offline processing is
encrypted.

Further reading
• Alliance Access Administration Guide - Backing Up Data (AIX Linux Windows)
• Alliance Entry Administration Guide - Backing Up Data
• Alliance Gateway Administration and Operations Guide - Archive, Back Up, Copy, and Restore
Alliance Gateway Data
• Alliance Web Platform Server-Embedded Administration and Operations Guide
- Back Up the Database
- Restore and Resynchronise the Database
• SwiftNet Link Operations Guide - Backup and Restore for SwiftNet Link

12 January 2024 111

Alliance Glossary
Security Guidance

6 Glossary
Security term Definition

Auditability Every user of a system should be held accountable for their activities. This implies
that all actions can be audited, meaning that all relevant actions can be monitored,
and that any single action can be uniquely attributed to a known user, at a particular
time and date.

Availability The term availability implies that both the information and the systems used, for
example, to process, display, and print information are both accessible and usable
as and when required.
For user data, this means that information should be processed in a timely manner,
and stored in the correct place to be available to authorised users.
The availability (and integrity) of valid system and configuration data has a direct
influence on service availability. Also, all of the necessary components of a system
must be working to ensure service availability.

Common CVSS is an open industry standard for assessing the severity of software
Vulnerability vulnerabilities by assigning severity scores to these vulnerabilities, enabling the
Scoring System prioritisation of responses and resources in line with the threat.
(CVSS)

Confidentiality Confidentiality refers to information that is disclosed only to authorised people, at

authorised locations, and at authorised times.
For user data, this implies that confidential information is not disclosed to
unauthorised third parties. For system data, confidentiality refers to the secure
protection of sensitive operational data, such as password files and encryption
keys.

Integrity Integrity relates to information that may be relied upon to be consistent, complete,
accurate, valid, and useful. For user data, this implies that no information may be
altered by unauthorised people.
For system data, this term implies that no unauthorised changes are made to
programs, scripts, configuration files, log files, and so on, thus ensuring the integrity
of the complete system.

Jump Server A jump server is a (special-purpose) hardened computer on a network that is

commonly used to access ("jump to") a host inside a specific network zone. A jump
server limits such access to duly authenticated and authorised users only.

Local Local Authentication, abbreviated as LAU, provides integrity and authentication of

Authentication files exchanged between applications. Local Authentication requires that the
(LAU) sending and receiving entity use the same key to compute a Local Authentication
file signature.

12 January 2024 112

Alliance Glossary
Security Guidance

Security term Definition

Multi-Factor Multi-Factor Authentication is a method of user authentication where at least two

Authentication different components are required to authenticate a user. Following authentication
(MFA) factors can be selected:
• Knowledge factor (something the user knows). For example, a PIN or a
password
• Possession factor (something the user has). For example, an HSM token, a
Digipass, a mobile phone, or an RSA One Time Password device
• Human factor (something the user is). For example, finger print or any other
biometric

Operator End users or individuals requiring interactive access to the Swift application (for
example business transactions, monitoring, and access control). This includes
business users, security officers and application administrators responsible for
configuring and maintaining the application.

Relationship A filter that enables the user to limit the correspondents from which messages can
Management be received as well as the types of messages which can be received. The use of
Application (RMA) the Relationship Management Application mechanism is mandatory for the FIN
service. It is available on an optional basis for SCORE FileAct and Generic FileAct.

Transport Layer A cryptographic protocol that ensures confidentiality and integrity on the network
Security (TLS) and protects against replay attacks.

User Refers to an individual acting as:

• End users with interactive access to the Swift application (for example, for
business transactions, monitoring, and access control). This includes business
users, security officers and application administrators responsible for configuring
and maintaining the application.
or
• Operating System Administrators responsible for configuring, maintaining, and
conducting other privileged activities on the operating systems hosting the local
Swift infrastructure.

The following principles assist in ensuring the foundation of a secure system:

Security principle Definition

Need-to-know Information and resources should be made available strictly on a need-to-know or

need-to-have basis.
System set-up must ensure that operators only have access to the information,
files, and system resources necessary for their defined tasks. Access to other
system functions must be disabled.

Least privilege Users must only be granted the minimum level of privileges required for them to
perform their defined tasks.
System set-up must ensure that operator privileges are controlled in a way that
enables all privileges to be tailored to individual needs.

12 January 2024 113

Alliance Glossary
Security Guidance

Security principle Definition

Default deny By default, a person must be granted no privilege/no access on a system.

System set-up must ensure that non-required applications, software, or tools are
removed.

Accountability All user activity, such as access attempts and command usage, must be logged and
attributed to a known user.
Ideally, system activity (such as information about processes, network events, and
system errors) should also be logged.

For more information about definitions of Swift-specific terminology, see Swift Glossary.

12 January 2024 114

Alliance Swift Training
Security Guidance

7 Swift Training
Swift provides training about standards, products, and services to suit different needs. From
tailored training to self-paced e-learning modules on Swift Smart, a range of training options are
available for all Swift end users.

Swift Smart
Swift Smart is an interactive, cloud-based training service that offers a large variety of courses for
different levels of knowledge. The courses contain exercises and quizzes and are available in
multiple languages. The Swift Smart catalogue provides a list of courses that are organised into
these learning tracks:
• General knowledge
• Work with messages
• Deploy and manage Swift software solutions
• Security and audit
• Compliance and shared services
Swift Smart is accessible from the desktop or a mobile device. No installation is required.
Swift Smart is available to all connected Swift end users and registered Swift partners with a
[Link] account. For more information, see How to become a [Link] user.

Tailored training
A full range of tailored programmes is available to meet specific training needs. For more
information, visit the Training web page.

12 January 2024 115

Alliance Support
Security Guidance

8 Support
Support for Swift customers
By default, Swift Support is the single point of contact to report all problems and queries that relate
to Swift services and products. Swift Community Support is available to all Swift customers.
Individuals within a customer organisation must register on [Link] to use the Support service.
On top of the Swift Community Support, customers can purchase the Advanced Support and Care
Services.
For more information about the different services that Swift offers as part of the Swift Advanced
Support and Care Services and the procedure to order support, see Support and Care Services on
[Link].

Third-party software and hardware

Swift provides support for Swift services and products only. For example, Swift does not offer
support for the underlying hardware and software systems (operating system, third-party
messaging middleware) which are used in conjunction with the Swift product. In case of problems
or queries that relate to those third-party hardware or software systems, customers must contact
the responsible vendor.
Related information
For more information about Support services, see the Service Description related to the applicable
support package: Support documentation.

12 January 2024 116

Alliance Legal Notices
Security Guidance

Legal Notices
Copyright
Swift © 2024. All rights reserved.

Confidentiality
This publication contains Swift or third-party confidential information. Do not disclose this
publication outside your organisation without Swift’s prior written consent.

Disclaimer
Swift supplies this publication for information purposes only. The information in this publication may
change from time to time. You must always refer to the latest available version on [Link].
This document includes general guidelines or recommendations or interpretation of data.
Customers are solely and exclusively responsible for deciding any particular course of action or
omission and for implementing any actions or taking any decision based on the information in this
document. Swift disclaims all liability with regards to such actions or decisions and their
consequences. Nothing in this document shall be interpreted or construed as constituting any
obligation, representation or warranty on the part of Swift.
Translations
The English version of Swift documentation is the only official and binding version.

Trademarks
Swift is the trade name of S.W.I.F.T. SC. The following are registered trademarks of Swift: 3SKey,
Innotribe, MyStandards, Sibos, Swift, SwiftNet, Swift Institute, the Standards Forum logo, the Swift
logo, Swift GPI with logo, the Swift GPI logo, and UETR. Other product, service, or company
names in this publication are trade names, trademarks, or registered trademarks of their respective
owners.

12 January 2024 117