SWIFT Alliance Messaging Hub Security Guidance

Alliance Messaging Hub
Security Guidance
This document provides the reader with an overview of the security features for Alliance Messaging Hub (AMH). The
document also lists the minimum set of recommended security controls for AMH implementations and their mapping
against controls mentioned in the SWIFT Customer Security Controls Framework (CSCF v2019).
31 May 2019
Alliance Messaging Hub - Security Guidance Table of Contents
Table of Contents
Table of Contents ............................................................................................................................... 3
Preface ................................................................................................................................................ 3
1 Introduction............................................................................................................................... 4
1.1 Alliance Messaging Hub ......................................................................................................... 4
1.2 Customer Responsibilities ...................................................................................................... 6
1.3 Governance ............................................................................................................................ 6
2 Overview of Alliance Messaging Hub .................................................................................... 7
3 Security Recommendations .................................................................................................... 8
3.1 Secure Server Environment.................................................................................................... 8
3.1.1 Physical Access Control ............................................................................................... 8
3.1.2 Internet Access ............................................................................................................. 9
3.1.3 Logical Access Control ................................................................................................. 9
3.1.4 System Activity Logging ............................................................................................. 11
3.1.5 Operating System Hardening ..................................................................................... 11
3.1.6 Security Updates ........................................................................................................ 11
3.1.7 Security Software ....................................................................................................... 12
3.1.8 Backup and Resiliency ............................................................................................... 13
3.2 Secure Client Environment ................................................................................................... 13
3.2.1 Physical Security ........................................................................................................ 13
3.2.2 Internet Access ........................................................................................................... 13
3.2.3 Secure Browsing ........................................................................................................ 14
3.2.4 Anti-virus and Anti-malware........................................................................................ 14
3.2.5 Security Updates ........................................................................................................ 14
3.3 Application Security .............................................................................................................. 15
3.3.1 User Authentication and Session Management ......................................................... 15
3.3.2 Authorisation Schemes ............................................................................................... 17
3.3.3 System Configuration ................................................................................................. 18
3.3.4 Server Authentication and Confidentiality .................................................................. 19
3.3.5 Database Integrity ...................................................................................................... 20
3.3.6 Integrity of the Message Flow ..................................................................................... 21
3.3.7 Auditing and Monitoring .............................................................................................. 21
3.3.8 File Level Integrity Checks (AMH 4.0) ........................................................................ 22
3.4 Local Network Security ......................................................................................................... 22
3.4.1 Network Segregation .................................................................................................. 22
3.5 Other Security Recommendations ........................................................................................ 23
3.5.1 Reconciliation ............................................................................................................. 23
3.5.2 User Security Awareness ........................................................................................... 23
3.5.3 Incident Management ................................................................................................. 24
4 Addressing Vulnerabilities .................................................................................................... 25
4.1 Threats and Attacks .............................................................................................................. 25
4.2 Addressing Security Threats ................................................................................................. 25
5 Mapping Security Controls Against Security Guidance Recommendations................... 27
6 Glossary .................................................................................................................................. 34
Legal Notices .................................................................................................................................... 35
31 May 2019 3
Alliance Messaging Hub - Security Guidance Preface
Preface
Purpose of this document
This document is issued for information purpose only. It is aimed at providing the reader with
an overview of the security features for all releases of Alliance Messaging Hub (AMH). For
more information about AMH, consult the relevant Service Descriptions and other related
documentation.
This document also includes general guidance designed to assist Alliance customers in
protecting their access to and use of Alliance Messaging Hub. The list of recommendations in
this document is not exhaustive nor do they replace a well-structured policy, sound judgment or
compliance with the latest best practices. Furthermore, it does not address customer-specific
infrastructure and configuration issues, or other specific requirements that may apply to
customer considering in particular the technology used and the customer’s own security risk
analysis.
The information in this document refers to the description of AMH at the date of this document.
As this document may not necessarily be updated along with subsequent changes to AMH,
always refer to the latest available version of the Alliance Messaging Hub Service Description
and other related documentation.
Related documentation
 Alliance Messaging Hub Service Description
 Alliance Messaging Hub Installation Guide
 Alliance Messaging Hub Configuration Guide
 SWIFT General Terms and Conditions
31 May 2019 3
Alliance Messaging Hub - Security Guidance Introduction
1 Introduction
This security guidance document gives an overview of the key security features for all releases
of the Alliance Messaging Hub (AMH), as well as a minimum set of customer security controls
of the Customer Security Controls Framework (CSCF v2019), designed to help customers
protect their local environment. Further guidance can be found in the different guides
referenced in this security guidance document.
It is important to understand that this document is only a guide containing general guidance
designed to assist users in protecting their local infrastructure connecting to the SWIFT
network. It is neither meant to be an exhaustive list of recommendations nor to replace well-
structured policy, sound judgment or compliance with the then current best practices.
Furthermore, it does not address customer-specific infrastructure and configuration issues, or
other specific requirements that may apply to customers.
1.1 Alliance Messaging Hub

Alliance Messaging Hub (AMH) is a flexible, multi-network, high-volume financial messaging
solution. It offers advanced features to integrate with the customer’s application landscape, using
SWIFT MT, ISO and proprietary message standards, and exchange messages over both SWIFT
and non-SWIFT networks. The AMH configuration options, complemented with the embedded
workflow orchestration engine and message transformation module, make it possible to tailor the
message processing to the customer’s specific needs.
Its architecture and deployment options allow for scaling in function of message processing needs,
while meeting high availability objectives in line with business requirements.
AMH comes with a web interface for both business users and IT users, each having access to the
set of functions and message types in line with their functional needs and data access rights.
31 May 2019 4
Figure 1: Alliance Messaging Hub logical view
The Alliance Messaging Hub offers the following security features (this list is not exhaustive):
 User authentication via username/password mechanism or integration with external LDAP
and/or Single Sign On infrastructure (LDAP, SAML) or two-factor authentication with TOTP.
 Authorisation schemes: RBAC and data driven access rights, allowing for configurable and
fine- grained segregation of duties.
 Change approval mechanism (4 or 6 eyes) for key user management configuration
 LAU-key based message integrity verification for backend connectors
 Ability to secure connections with external components (e.g. MQ, DB) and/or between internal
components (e.g. AMH Web Interface, Control Centre, PowerSearch, External trigger)
 Configurable workflow, facilitating 6-eyes principle for message processing
 Audit trail for configuration changes and monitoring
31 May 2019 5
1.2 Customer Responsibilities

As mentioned in SWIFT General Terms and Conditions, the customer is responsible at all
times for maintaining the confidentiality, integrity, and availability of messages, and
configuration data on its local SWIFT systems, and on that segment of its connectivity for
which SWIFT is not responsible under the SWIFT Contractual Documentation.
In particular, the customer must ensure the following:
 Customer implements appropriate management principles to ensure (i) only authorised users
are created and remain on customer systems; (ii) users are granted physical or logical access
to SWIFT services and products on a need-to-know or need-to-have basis only; (iii) all
messages or files sent over SWIFT have been duly authorised; (iv) networks, systems,
applications are fully segregated based on their criticality; (v) cyber defence controls are
implemented.
 Customer implements appropriate and regularly re-assessed controls to avoid that malicious
code is exchanged through SWIFT services and products (typically, the scanning of messages
sent or received with state-of-the-art and up-to-date virus and malware scanning software) and
to avoid that any components or infrastructure used by the customer for the purpose of using
SWIFT services and products be used for malicious purposes or cyber-attacks.
 Customer operates backup procedures and handles backup media according to security
practices no less secure than those applied to its production systems and connectivity.
 Customer installs and uses only that third-party software and equipment that is necessary to
access and use SWIFT services and products, and it complies at all times with all proper
instructions and recommendations regarding their use (typically, the timely installation of all
critical updates and updates).
The customer must also ensure that its operational environment has been configured for
increased resilience in order to minimise any downtime in the event of a failure of its primary
systems or connection. The customer will, in particular, comply with the latest principles for
increased resilience issued by SWIFT.
If customers believe they have identified a vulnerability threat within their local environment,
customers should immediately isolate them from the SWIFT Network and immediately inform
SWIFT thereof. For more information on your reporting obligations and reporting channel,
please consult SWIFT General Terms and Conditions and see the service description related
to the applicable support package.
1.3 Governance
SWIFT’s Alliance Messaging Hub (AMH) is designed and built using industry-strength
processes that help ensure best-in-class quality, security and reliability: development life-cycle
processes ensure that security and availability are built in right from the start.
To a large extent, these are the very same processes used by SWIFT to deliver the FIN and
SWIFTNet services on which the global financial community relies on a daily basis. While AMH
is not in scope of SWIFT’s ISAE 3402 Type 2 report, their processes are the same (that is,
secure coding, penetration testing, change management, problem & incident management).
Therefore, AMH users can to a certain extent derive assurance from the ISAE 3402 report.
The development process at SWIFT requires independent verification of quality and security.
Rigorous testing ensures quality and conformance with requirements including security
requirements. In addition, with a risk-based periodicity, SWIFT performs penetration tests to
identify potential vulnerabilities in off-the-shelf technology, customised software or in-house
developed code that is used within AMH, focussing on application level vulnerabilities. Finally,
the AMH as well as all underlying processes are part of SWIFT’s Internal Audit Universe and
get reviewed in-depth on a regular systematic basis.
31 May 2019 6
Alliance Messaging Hub - Security Guidance Overview of Alliance Messaging Hub
2 Overview of Alliance Messaging Hub

Alliance Messaging Hub (AMH) has been designed in accordance with industry practices for
resiliency and security. Strict software development life-cycle and other governance related
controls are equally applied to AMH as to any other service delivered by SWIFT, including
testing for OWASP Top 10 and CWE/SANS Top 25 vulnerabilities. This section provides a high
level overview of AMH.
Below picture depicts an AMH deployment, including the main connections between the
various system components and external components.
Figure 2: AMH deployment view.
Alliance Messaging Hub main components include:

 AMH Server, a J2EE application deployed on an application server and relying on an
external Oracle database for storage, offering message processing services and hosting
a few Web Services.
 A web-based user interface.
 Connectors to integrate with Backend applications
 Connectors to integrate with SWIFT and SIX FinanceIP networks, relying on AMH-
external gateways (e.g. Alliance Gateway) and network-specific encryption components
(for example SASS)
 Optional modules for service monitoring (Control Centre), message search
(PowerSearch) and remote operations (External Trigger)
Note that the database server, the network-specific gateways and network security
components are not provided with the AMH application, though are prerequisites to run the
application.
31 May 2019 7
Alliance Messaging Hub - Security Guidance Security Recommendations
3 Security Recommendations
SWIFT’s products rely on a number of security features under direct control and management
of SWIFT users. User organisations, also referred to as customers, should accordingly
establish their own internal controls or procedures to complement those of SWIFT.
Both the physical and logical security of the computers and network that are used to run
Alliance Messaging Hub (AMH) are important in maintaining a secure environment. The
security of the infrastructure is not specific to AMH but is valid for any critical business
application at customer premises.
Five different topics are covered in this document:
 Secure Server Environment: controls that help secure the servers that host AMH
software and the servers that they communicate with.
 Secure Client Environment: controls that help secure the workstations used to connect
to the servers that host AMH software.
 Application Security: controls that help secure the application. These are security
features provided by the AMH. Users can and should configure them correctly.
 Network Security: controls that help secure the network environment of the Alliance
infrastructure.
 Other recommendations: controls that are recommended by SWIFT that do not fit in the
above categories.
This section lists the minimum set of controls that SWIFT recommends for customer
implementation. The controls are listed in a table and have the following rows:
 ID: an identification number that can be used to refer to a specific control
 Control: the control to put in place
Where applicable, links are provided to the appropriate AMH documentation. For any questions
regarding operating system or third party application configuration, we recommend the
customer to contact their vendor.
3.1 Secure Server Environment

This set of controls applies to securing your server environment. The server environment
consists of the servers that host Alliance Messaging Hub and servers that interact with those
servers. These can include Oracle Database servers, MQ Servers, Alliance Gateway, SASS,
AGI, encryption software, or other servers in the customer infrastructure. One compromised
system can pose a threat for other systems in the same network.
3.1.1 Physical Access Control

Physical access controls may deter or detect unauthorised access to your hardware. Data
centres, server rooms or individual server racks can be protected by different security
measures.
Access to physical resources can be logged. Audit logs can identify who accessed which
assets at which time. They can be used during audits and investigation.
Keep the “least privilege” methodology in mind when assigning access rights. An individual
should only be able to access the features required for their specific job. Access rights can
change due to employees changing roles or leaving the company.
ID Control
SPA.01 Physical security controls are in place. They ensure that only authorised personnel can
access the servers running Alliance Messaging Hub.
31 May 2019 8
ID Control
SPA.02 Physical access to the hosts running Alliance Messaging Hub is logged. These logs are
available for audits and investigations.
SPA.03 Physical access controls are regularly reviewed.

When an employee changes roles or leaves the company their access rights are
immediately modified.
3.1.2 Internet Access

When a device can connect to the Internet, it is open to many more security threats. If such a
device can also connect to the SWIFT environment, you are also exposing your SWIFT
environment to those threats.
ID Control
CIA.01 All servers hosting Alliance Messaging Hub are disconnected from the Internet, except if
the SWIFT product requires it (via VPN).
CIA.04 The Alliance Messaging Hub is not co-hosted.
3.1.3 Logical Access Control

Operating system
Operating systems have an OS administrator account. This account is usually called
‘administrator’ on Windows systems, and ‘root’ on UNIX and Linux systems. Persons acting as
administrator are able to take complete control of the system.
Application server
As from AMH 4.0 Alliance Messaging Hub software runs on an application server that is
delivered as part of the application. Before AMH 4.0 Alliance Messaging Hub software had to
be deployed within an application server, provided by the Customer.
Authorised application server users can take control of the application server and the
applications deployed within the application server. Such users are able to take complete
control of the system.
Database
Alliance Messaging Hub software requires access to the database for storing configuration
data, message data and other run-time data. This database environment is provided by the
customer. Database systems have the notion of administrator accounts, within this document
referred at as ‘DBA-accounts’, which are able to take complete control of the database and its
content. Access rights must be set up so that only the Alliance Messaging Hub software can
access the application data.
Access control
The OS administrator account, the application server users, and the DBA accounts are
privileged accounts, on which there is no real ability to exercise 4-eyes control. Therefore
specific controls must be implemented to tightly control the use of privileged accounts.
Keep the “least privilege” principle in mind when assigning access rights. An individual should
only be able to access the features required for their specific job. Access rights can change
due to employees changing roles or leaving the company.
It is the customer responsibility to protect access to the operating system, database and
31 May 2019 9
application server. Additionally, each access and/or operation on the infrastructure component
must be adequately logged, and evidence kept for auditing purposes.
Alliance Messaging Hub relies on a customer-provided Oracle database to store data such as
message data, user profiles, security settings and configuration data. The AMH data is stored
in a dedicated Oracle scheme.
Note Physical and host-based firewalls can restrict connectivity to the Alliance hosts.
Strong firewall rules tighten logical access controls. Firewalls are covered in
section 3.4.1.
Further Reading
 Alliance Messaging Hub Installation Guide
ID Control
SLA.01 Careful consideration is put into who is assigned the role of administrator of the operating
system, application server and database.
SLA.02 Employees with administrative access to the operating system, the application server or
the database have the required skills to perform their tasks, on the respective
infrastructure component.
SLA.03 Employees with access to OS administrator accounts, application server accounts and
DBA Accounts are aware about security best practices.
They receive sufficient security awareness training.
SLA.04 For administrator account, the application server accounts and the DBA account there
are procedures in place to:
 Identify who is logged in on such an account
 Identify which commands are run on such an account
This information is securely stored and available for audits and investigations.
SLA.05 Careful consideration is given to the choice of passwords for privileged accounts. The
password policy is in line with industry best practices. For example:
 Minimum password length
 Password complexity
 Number of days after which a password must be changed
 The same password is not reused on multiple hosts
 Passwords are changed after use
 The password policy is documented and enforced.
SLA.06 Logical access controls are regularly reviewed.

When an employee changes roles or leaves the company their access rights are
immediately modified.
SLA.07 There is an emergency procedure to access the servers with the administrator account,
the application server account and the DBA account. An emergency procedure is helpful
when the authorized persons 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-authorized person to access the Alliance
hosts unnoticed.
SLA.08 Sessions are not left open unattended.
SLA.09 A multi-factor protocol is used for authentication.
31 May 2019 10
3.1.4 System Activity Logging

Operating systems can often log information that helps to identify users and the commands
they run. Actively monitoring such logs may help to identify malicious activity on the systems.
Safe storing log files on a remote server can help in forensic investigations.
Application servers and databases might offer similar logging capabilities.
A Security Information and Event Management (SIEM)1 system allows gathering and analysing
information from multiple hosts and applications in a central location. The customer can
consider such a solution.
ID Control
SLG.01 Operating system log files are monitored and regularly reviewed. Such logs can contain
and are not limited to:
• administrator-level operating system accounts activity log
• Alliance Messaging Hub application owner activity log
• Relevant Messaging Hub application events distributed to the operating system logs
(for example, Alliance Messaging Hub event logs stored in Syslog in CEF format).
SLG.02 Operating system logs are stored on a remote system that cannot be accessed by the
same operating system privileged account or by the same individuals.
SLG.03 Log files are retained (safe-stored) for a least 12 months and are available for audits or
forensic investigations.
SLG.04 Where possible, the operating system log files are integrated with a centralised logging
system.
3.1.5 Operating System Hardening

Operating system hardening can be used to make the configuration of the Alliance Messaging
Hub servers more secure. In most cases operating system hardening uses the existing
features of the operating system.
ID Control
SSH.01 The operating systems and other software that are installed on the servers which host
Alliance Messaging Hub are configured according to the vendor recommendations and
security baselines.
SSH.02 Only authorised and required software is installed on the servers which host Alliance
Messaging Hub.
3.1.6 Security Updates

Operating systems, application servers and any other software used by Alliance Messaging
Hub should be updated with the latest security updates that are made available by the vendor.
Security updates contain corrective actions that prevent successful exploitation of known
security vulnerabilities. The customer can contact their vendor for more information and
1 SWIFT does not give recommendations regarding vendors of Security Information and Event Management (SIEM)
systems.
31 May 2019 11
recommendations.
Alliance Messaging Hub security updates can be downloaded from the SWIFT Download
Centre.
SWIFT notifies its customers of the availability of new security updates when applicable.
ID Control
SSP.01 The Alliance Messaging Hub and related embedded or hosted Oracle database are up to
date with the latest security updates, aligned to the assessed risk or Common
Vulnerability Scoring System (CVSS), Version 3.
SSP.02 Recommended Alliance Messaging Hub releases or security updates are installed on a
timely basis and for mandatory releases or cumulative security updates, before the
mandatory installation date.
Security update checker tool (AMH 4.0)

The Security Best Practice Check Tool performs a series of security checks to help you to
evaluate if Alliance or SWIFTNet Link configurations are aligned with the Customer Security
Programme security guidelines (specifically those guidelines related to the control 2.2 Security
Updates). 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 can run only when
the relevant SWIFT product is running. The Security Best Practice Check Tool supports
multiple processes running for the same instance of SWIFTNet Link or Alliance on the same
host, for different instances of SWIFTNet Link or Alliance on the same host, or for different
SWIFTNet Link and Alliance products on the same host.
The Security Best Practice Check Tool report directory is only accessed by the authorized
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 security check. The relevant SWIFT product must be fully up and running in order to
execute all checks. If the product is not operational, certain checks, such as certificate checks,
cannot be performed.
3.1.7 Security Software

Security software such as anti-virus, integrity protection software, anti-malware and intrusion
detection systems can be installed to prevent, detect and remove malicious software.
Although SWIFT has not qualified Alliance Messaging Hub with security software, the use of
such software, if properly configured and maintained will not have an operational impact on
Alliance Messaging Hub software.
It is the customer’s responsibility to test and assess any impact on performance as a result of
installing security software.
ID Control
SSS.01 Security software is installed to protect against malicious software or other threats.
File Level Integrity Checks (AMH 4.0)

To implement the CSP Control 6.2 “Software Integrity”, AMH 4.0 will provide embedded File
Level Integrity Checks (FLIC). AMH provides FLIC to ensure that code and file tampering is
detected. FLIC requires a FLIC administrator password. This password is configured during the
initial installation.
31 May 2019 12
3.1.8 Backup and Resiliency

It is good practice to back up both data and software on a periodic basis. In the unlikely
situation the data and/or software are corrupted, a recent back-up provides a starting point to
restore the system.
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.
The architecture of Alliance Messaging Hub, allows achieving the availability and resiliency
levels that are typically required for business critical applications. The customer must carefully
consider availability and resiliency objectives and choose a deployment and configuration
setup that meets those requirements. This also implies that the supporting customer
infrastructure, on which AMH relies and builds upon, must be set up to provide similar
availability and resiliency levels.
ID Control
SBS.01 Back-ups of data and software are made frequently. The back-up 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 (RTO) and
Recovery Point Objective (RPO) are defined, considering the business criticality of the
services supported by the application.
SBS.03 The AMH deployment and configuration is defined in function of the availability and
resiliency objectives. Testing is performed to demonstrate the setup allows meeting those
objectives. Such testing precedes using the AMH application for production purposes.
SBS.04 Sensitive SWIFT-related data leaving the secure zone as a result of backups, data
replication for recovery or further off-line processing is encrypted.
3.2 Secure Client Environment

This set of controls applies to securing your client environment.
These recommendations apply to all the hosts that connect to Alliance Messaging Hub hosts.
These can be hosts that have a browser installed to connect to Alliance Messaging Hub, or
hosts that are used to remotely manage the Alliance Messaging Hub server environment.
ID Control
OSC.03 A 15-minute lock-out is recommended for end user sessions.
3.2.1 Physical Security

Physical access controls may deter or detect unauthorised access to your hardware.
ID Control
CPS.01 Only authorised individuals have physical access to the client systems.

When a device can connect to the Internet, it is open to many more security threats. If such a
31 May 2019 13
device can also connect to the SWIFT environment, you are also exposing your SWIFT
environment to those threats.
ID Control
CIA.02 Jump servers, which are used to remotely manage the operating systems on which
Alliance products are installed, do not have Internet access.
CIA.03 System administrators connect through a jump server or a dedicated Operator PC within a
secure zone to servers hosting Alliance Messaging Hub.
3.2.3 Secure Browsing

Customers are advised to review and implement where possible controls in order to implement
secure browsing practices. These controls give a non-exhaustive list of secure browsing
practices.
ID Control
CSB.01 The customer follows secure browsing practices, such as:

Segregated general browsing from user access to Alliance Messaging Hub either by
using different Windows accounts or, ideally, by using different PCs.
Not browsing other sites than Alliance Messaging Hub when an Alliance session is open
Never following links in e-mails that pretend to direct the user to Alliance Messaging
Hub. These may be phishing attempts.
Security awareness for Alliance end users allowing to develop and maintain secure
minded behaviour in the user base and to ensure users are fully aware of threats related
to browsing, such as ensuring that PC user sessions cannot be taken over.
Restart your browser instance before and after accessing Alliance Messaging Hub.
CSB.02 There are no unsupported browsers used to access Alliance Messaging Hub.
Avoid installing browsers plugins unless explicitly mandatory, trusted and signed.
3.2.4 Anti-virus and Anti-malware

Security software such as anti-virus, anti-malware and intrusion detection systems can be
installed to prevent, detect and remove malicious software.
ID Control
CAV.01 Anti-virus, anti-malware services and associated databases are up-to-date on the client
host infrastructure.
3.2.5 Security Updates

Operating systems and other software used by Alliance Messaging Hub should be updated
with the latest security updates that are made available by the vendor. Security updates
contain corrective actions that prevent successful exploitation of known security vulnerabilities.
The customer can contact their vendor for more information and recommendations.
ID Control
CSP.01 The client infrastructure is up-to-date with the latest security updates.
31 May 2019 14
3.3 Application Security

Alliance Messaging Hub provides 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 policies of customer institutions.
SWIFT recommends configuring all features described in this section.
3.3.1 User Authentication and Session Management

Whenever the browser connects to perform a login, a new session is established. That session
is identified by a security token which is verified by the server for each subsequent user
request. Unused sessions time out after a configurable time, avoiding that such sessions are
kept open.
Alliance Messaging Hub supports the following authentication mechanisms:
 Local Authentication with two-factor authentication
 LDAP Authentication
 Single Sign On Authentication
Local Authentication with Two-Factor Authentication

Users can authenticate themselves with a username and password, stored hashed and
encrypted in the AMH database.
AMH Security Officers can configure password policies, enforcing complexity of user defined
passwords. Distinct policies can apply for distinct AMH user groups.
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 (such as
username/password) and something you have (such as a smartphone or hardware token
running a one-time-password generator).
AMH 3.6 and higher

As from AMH 3.6, it is possible to configure 2FA as an embedded solution based on TOTP
technology. It enables a 2FA set-up using an off-the-shelf application that can be installed on a
mobile phone, tablet, or workstation.
LDAP Authentication
Alliance Messaging Hub allows you to authenticate users via an LDAP server.
Setting up and maintaining the authentication server is the customer’s responsibility.

Information on how to configure Alliance Messaging Hub to connect to an external LDAP
system for user authentication can be found in the user documentation.
The connection between AMH and the LDAP server should be secured using TLS.
Single Sign On Authentication

Single sign-on (SSO) is a property of access control of multiple related, but independent
software systems. With this property a user logs in once and gains access to all systems
without being prompted to log in again at each of them. AMH offers integration capabilities with
such SSO infrastructures, for example using SAML.
Setting up and maintaining the SSO infrastructures is the customer’s responsibility.
Recommendations and controls in this section equally apply for the SSO infrastructure on
which AMH relies.
Proprietary two-factor authentication can be implemented by integrating AMH whith an external
authentication system via the SSO functionality of AMH.
31 May 2019 15
Personal token (AMH 4.0)

Personal tokens, also called security tokens or authentication tokens, are small USB-based
hardware devices that an operator/user carries for authentication purposes.
The personal token and the PIN or password needed to access its content add an extra level of
security (two-factor authentication)
Personal tokens contain a pair of public/private keys that can be used for cryptographic
operations.
Identity Provider authentication with SAML (AMH 4.0)

Alliance Messaging Hub introduces Identity Provider authentication for users using the Alliance
Messaging Hub GUI. The benefit of this model of authentication is that Customers have a
solution based on a centrally managed Identity and Access Management system, typically one
already used throughout the company. Unlike LDAP, this solution uses the latest state of the
art technology which outsources the whole identification and authentication rather than just
validating credentials. The Security Assertion Markup Language (SAML) technology allows you
to deploy federated authentication, Single Sign-on with full flexibility on the number and type of
authentication technologies including more than two factors, biometric tools, and many others.
In this way Customers now have a solution to implement any type of multi-factor authentication
deployed within their institution.
Further reading
 AMH Configuration Guide, section “AMH Security”
ID Control
USM.01 All user-defined passwords used in Alliance Messaging Hub must be in line with
industry best practices. The application enforces below list of rules for operators with
the "Normal users" password policy assigned:
• Passwords and PINs should be configured using the parameters specified in the
latest versions of SWIFT Knowledge Base TIP 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 start-up and every
hour. Changes to this parameter will take effect at midnight or at the next restart
of the servers. Recommended value: 120.
USM.02 All user-defined passwords used in Alliance Messaging Hub must be in line with
industry best practices. The application enforces the following list of rules for operators
with the "Admin users" password policy assigned:
• Passwords and PINs should be configured using the parameters specified in the
latest versions of SWIFT Knowledge Base TIP 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 The connections with external systems used for authentication (LDAP and SSO
infrastructure) are secured.
OSC.02 For the security parameter Session Expiry Timeout, set the session time-out to a small
value (maximum of 15 minutes or 900 seconds).
MFA.01 At least a two-factor authentication method is used for authentication on Alliance
products. The options are:
• Embedded Two-Factor Authentication (Password and TOTP). This is valid for:

- All operators in Alliance Messaging Hub including main LSO/RSO and extra
31 May 2019 16
ID Control
security officers
• LDAP (Lightweight Directory Access Protocol) authentication where a second factor
is required at the single login, or at a later stage.
• Personal Token (AMH 4.0): requiring a hardware device and a PIN or password.
• Identity Provider authentication with SAML (AMH 4.0)
3.3.2 Authorisation Schemes

Alliance Messaging Hub is designed to support the following principles:
 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.
 segregation of duties sensitive processes are performed by at least two individuals,
each responsible for a separate part of the process.
Alliance Messaging Hub has a configurable user access security model that is based on the
roles users have in an organisation. It bundles functional security, which determines which
actions the users are allowed to perform, and data security, which determines the data which
the users are allowed to access.
The authorisation model consists of the following main components:
 Security Profiles: a set of functions within the application that is typically granted
together. Alliance Messaging Hub provides configuration packages, that immediately
instantiate a number of security profiles (e.g. Security Officer, Administrator,
Operator…)
 Messaging Profiles: a set of functions granted on individual messages types.
 Data profiles: set of financial Institutions (Parties) and departments (Data owner)
meant to restrict the access to message data based on the characteristics of the
message.
 User groups: group of user that shares the same access rights and authentication
mechanisms.
 Roles: concept to link the above profiles and groups, facilitating user management.
By proper allocation of roles to the user groups, segregation of duties is enforced
and message data user-access can be restricted.
Segregation of duties on message data can be configured using the authorization model
explained above, in combination with a workflow supporting manual handling and the
corresponding approval functions. Examples include:
 Authorise and Release
 Repair and Authorisation of the changed message, including a change log
 Manual entry and Verification/Rekey, e.g. in function of amount limits.
Change approval is a security mechanism that requires changes made by one person to be
authorised by one (or more) other users. The change does not take effect till the approval is
provided and hence implements the segregation of duties principle. It is offered for the main
configuration objects that steer the authorisation model, and hence require at least two
Security Officers to intervene to change user access rights.
At installation, Alliance Messaging Hub provisions a so-called ‘AMH system user’, which has
broad system access not steered by the above mentioned configuration. Its prime role is to
facilitate initial system setup, such as assigning Security Officer access rights. Yet, the system
user access is not meant for normal system operation and must therefore be disabled after
initial system setup.
Further reading
 AMH Configuration Guide, section “The User Security Model”
 AMH Installation Guide, section “Main Actors”
31 May 2019 17
ID Control
AAS.01 The "need-to-know", "least privilege", and "segregation of duties" principles are applied
when defining operators and operator profiles in Alliance applications.
The embedded logical access control and security parameters features can be used for
this purpose.
AAS.02 The AMH Security Operators are two independent individuals, with independent back-ups
identified in case of their absence.
AAS.03 Until AMH 3.7

The system user must be deactivated after initial system setup. An emergency procedure
exists to re-activate the user in case dysfunctions would require investigations that cannot
be achieved with end user-defined user access rights.
The emergency procedure requires the creation of a SWIFT Support case and the usage
of the procedure is logged. Under no circumstances should it allow a non-authorized
person to access the Alliance software unnoticed.
As an alternative, split the system user password in two, then store each part of the
password in a separate vault.
AMH 3.7 and higher
The system user is deactivated. An emergency procedure exists to re-activate the user in
case dysfunctions would require investigations that cannot be achieved with end-user
defined user access rights.
The emergency procedure requires the creation of a SWIFT Support case and the usage
of the procedure is logged. Under no circumstances should it allow a non-authorized
person to access the Alliance software unnoticed.
3.3.3 System Configuration

Alliance Messaging Hub is a highly configurable system, not only in how access rights can be
set up, but also in the way message data must be processed. This configuration is stored in an
Oracle database provided by the customer, and can be set up directly through the user
interface. Some configuration artefacts are set up in thereto dedicated designer tools
(Workflow designer, Transformation designer) and can subsequently be uploaded to Alliance
Messaging Hub. Changes to the configuration may induce security risks.
Alliance Messaging Hub provides functionality (Configuration Manager) to stage configuration

data from one environment (e.g. used for User Acceptance Testing) towards another
environment (e.g. the production environment). This allows for significant automation and
controls, while limiting the risk of unintentional or malicious misconfiguration through user
interface access.
Note that some functionality is steered by application properties that can be defined at
deployment time and are stored on file system. Those properties should be treated as
installation properties. Access to those properties should be limited following the Secure Server
environment guidelines (See section 3.1).
Further reading
 AMH Configuration Guide, section “Stage the Configuration” and section “Configuration
Management”)
ID Control
ASC.01 Configuration data is managed in thereto designed third party configuration management
tools, ensuring full visibility and audit on changes.
31 May 2019 18
ID Control
ASC.02 Automated deployment procedures to upload configuration data on target Alliance

Messaging Hub instances are implemented, avoiding direct manual changes.
Those procedures are documented and kept current as processes change.
ASC.03 Direct access rights to configuration data on production systems is limited. Similarly,
access rights to components (e.g. file system, MQ, configuration management tool) used
to automate the configuration deployment are limited.
ASC.04 Configuration changes, especially on production systems, are monitored, leveraging on

the AMH configuration Audit Log (see also 3.3.7).
ASC.05 Access to configuration data stored on the file system is restricted following the Secure
Server Environment guidelines (See 3.1)
3.3.4 Server Authentication and Confidentiality

All customer local network traffic can be encrypted using Transport Layer Security (TLS). This
feature 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 or delays
valid data transmission.
Alliance Messaging Hub allows protecting client and server connections using TLS. Alliance
Messaging Hub can be configured to use self-signed certificates and certificates signed by a
trusted Certificate Authority (CA). SWIFT recommends using certificates signed by a Certificate
Authority.
Connectivity between Alliance components

The communication between an Alliance Messaging Hub server, as deployed within the
Application Server, and other Alliance components or modules (e.g. Control Centre,
PowerSearch Module, External Trigger, SWIFT Alliance Gateway) must be secured by
Transport Layer Security, ensuring the confidentiality of data exchanged.
The Control Centre, an optional AMH module, connects as client to Alliance Messaging Hub.
User credentials are forwarded towards the monitored Alliance Messaging Hub hosts and
authenticated by those hosts, following regular authentication schemes. It is the customer’s
responsibility to secure the exchanges between the Control Centre and Alliance Messaging
Hub, using two-way Transport Layer Security (TLS) and, as of Alliance Messaging Hub 3.6,
also with a reverse proxy or other similar mechanism, preventing end-users to use the AMH
External API.
Alliance Messaging Hub connects as a client to PowerSearch, an optional AMH module.
Alliance Messaging Hub integrates with Elastic Search, using the Elastic Search proprietary
Shield security plugin, offering authentication, authorisation and transport layer security.
The External Trigger, a standalone Java Application, connects as client to Alliance Messaging
Hub. The username and password used to establish the connection are stored in a property file
and are encrypted at first usage. It is the customer’s responsibility to secure the exchanges
between the External Trigger and Alliance Messaging Hub, using two-way Transport Layer
Security (TLS).
Alliance Messaging Hub connects as a client to SWIFT Alliance Gateway. The connection is
established in relaxed mode, and secured using the SWIFT proprietary SwTL protocol.
Connectivity from customer infrastructure to AMH components

HTTPS can be enforced for the communication between the browser and the Application
Server that hosts Alliance Messaging Hub. The browser is able to authenticate the application
server with the certificate deployed on the application server.
31 May 2019 19
HTTPS can be enforced on Web Service integration, connecting external applications to the
Application Server that hosts Alliance Messaging Hub. Dedicated AMH users must be defined
through which WebService calls should be authenticated.
It is strongly recommended to configure the transport security for all the connections towards
Alliance Messaging Hub.
Connectivity from AMH components to customer infrastructure

The communication between an Alliance Messaging Hub server, as deployed within the
Application Server, and the customer infrastructure, including the Oracle database, the
MQ/JMS infrastructure and LDAP system, can equally be secured by Transport Layer Security,
ensuring the confidentiality of data exchanged.
ID Control
LSC.01 Certificates provided by a trusted Certificate Authority (CA) or a Certificate Authority under
the customer’s control are used to secure all connections supporting Transport Layer
Security.
LSC.02 Transport security relies on TLS following KB TIP 5021566.
LSC.03 Data encryption with host authentication is enabled to secure all the connection towards
Alliance Messaging Hub.
LSC.04 Integration between back-office applications and Alliance Messaging Hub, typically relying
on MQ/JMS, communicate via encrypted channels.
LSC.05 External Trigger access is limited to authorised users, and connections secured using
TLS.
LSC.06 Client connections established for Web Services and/or External Trigger rely on dedicated
AMH users.
3.3.5 Database Integrity

Before AMH 3.6
Alliance Messaging Hub uses a database to store sensitive data such as messages, user
configuration and security settings. Database integrity has as goal to protect against
unexpected modification of records stored within the database.
The customer is responsible for the management and the integrity of its AMH database.
Detailed guidance for this can be obtained from the database vendor.
ID Control
DBI.01 A database integrity check is regularly performed on the Alliance Massaging Hub.
DBI.02 Ensure that the new security configuration parameter Shutdown on Database
Tampering Detection is always set to Yes on Alliance Gateway.
DBI.03 Database security features are implemented for detection and prevention of unauthorized
access of users other than the AMH application user.
DBI.04 Database integrity is ensured as per database vendor guidelines.
DBI.05 Database access for any users other than the AMH application user are monitored,
logged, and responsive procedures are put in place to react on unauthorized actions by
authenticated users.
31 May 2019 20
AMH 3.6 and higher

Alliance Messaging Hub uses a database to store sensitive data such as messages, user
configuration and security settings. Database integrity has as goal to protect against
unexpected modification of records stored within the database.
The customer is responsible for the management and the integrity of its AMH database. With
the Database Integrity feature, AMH calculates a keyed hash on the content of the record and
stores this as a seal on the data. When the record is handled by AMH, the seal is verified. In
case of unauthorised modification to the data, the seal will allow detection of tampering and
alerts will be raised.
ID Control
DBI.01 A database integrity check is regularly performed on the Alliance Massaging Hub
3.3.6 Integrity of the Message Flow

Alliance Messaging Hub provides a local authentication (LAU) mechanism to improve the
security of message flow between customer local applications and Alliance Messaging Hub.
Local authentication guarantees both the identity of the sending application, as well as 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 in transit.
To use local authentication, both endpoints need to share a secret key. The key is stored
encrypted in the Alliance Messaging Hub database.
Further reading
 AMH MQ JMS Host Connectivity Guide
 AMH File System Host Connectivity Guide

ID Control
LAU.01 The connections between the back-office applications and Alliance Messaging Hub are
(LSC.03) authenticated.
This can be achieved using LAU (configured on the AMH Backend Configuration) or any
other client authentication mechanisms.
LAU.02 The integrity of messages sent between the back-office and Alliance Messaging Hub is
protected.
This can be achieved using LAU or any other protocols ensuring data integrity such as
TLS.
LAU.03 Distinct LAU keys are used for each distinct connection flow.
3.3.7 Auditing and Monitoring

Alliance Messaging Hub logs configuration changes in the configuration audit log. Changes
can be consulted at all times in the audit history of the configuration object, including who
made the change and when the change was made.
Secondly, Alliance Messaging Hub logs events that occur within the application (not limited to
31 May 2019 21
configuration changes) in the application logging module, and writes this logging to database
and/or to the file system. Logging written to the database can be consulted within the AMH
User Interface. Email notifications can be setup to notify specific user groups in case specific
events would occur.
For performance tuning exercises, it is possible to expose metrics via JMX. It is recommended
to disable JMX monitoring on production systems.
Finally, on each individual message, a full history is kept of its lifecycle within the application.
This history can be visualised and/or exchanged with external applications for long term
archiving.
ID Control
ALG.01 Application logs are regularly reviewed.
ALG.02 Application Event Logs are stored on a remote system that cannot be accessed by the
same individuals.
ALG.03 Application Log files are safe stored and available for audits or forensic investigations.
ALG.04 Where applicable, Alliance Event Log events are integrated with a centralised logging
and monitoring system.
ALG.05 Alarms are defined for security events.

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 Messaging Hub alarm script is owned by the software owner.
3.3.8 File Level Integrity Checks (AMH 4.0)

To Implement the CSP Control 6.2 “Software Integrity”, AMH 4.0 will provide embedded File
Level Integrity Checks (FLIC). AMH provides FLIC to ensure that code and file tampering is
detected. FLIC requires a FLIC administrator password. This password is configured during the
initial installation.
3.4 Local Network Security

3.4.1 Network Segregation
As a general rule Alliance Messaging Hub and related infrastructure must be located in a
secure zone that is separated from general IT infrastructure.
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. In
case a firewall is shared to separate other zones, care must be taken to ensure that
compromise of the firewall should 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).
Alliance product design provides the flexibility for customers to implement adequate network
segregation in line with best practices. SWIFT recommends installing Alliance Messaging Hub
in a secure zone. This allows the implementation of strong firewall rules on a dedicated firewall
ensuring:
 between the end-user’s browser and Alliance Messaging Hub, allowing only HTTPS
31 May 2019 22
 between the end-user’s browser and Alliance ControlCentre, allowing only HTTPS
 between Alliance Messaging Hub and Alliance Gateway packages, allowing only SWIFT
Transport Layer (SwTL, a TCP-based SWIFT proprietary transport protocol) based on
Transport Layer Security (TLS)
 between the ControlCentre and Alliance Messaging Hub, allowing only HTTPS
 between Alliance Messaging Hub and PowerSearch, allowing only HTTPS
 between the External Trigger and Alliance Messaging Hub, allowing only HTTPS
 between distinct Alliance Messaging Hub nodes, allowing only HTTPS
Similarly, network traffic between Alliance Messaging Hub and customer infrastructure (e.g.
Oracle database, MQ/JMS) can also be restricted by firewall rules.
ID Control
NET.01 The network (firewall) complies with the Network Configuration Tables Guide. It strictly
whitelists all flows required by the SWIFT network.
NET.02 Strong firewall rules are in place between the end-user’s browser and Alliance
ControlCentre, allowing only HTTPS
NET.03 Strong firewall rules are in place between Alliance Messaging Hub and Alliance Gateway
packages, allowing only SWIFT Transport Layer (SwTL, a TCP-based SWIFT
proprietary transport protocol) based on Transport Layer Security (TLS).
NET.04 Strong firewall rules are in place between the External Trigger and the Alliance
Messaging Hub, allowing only HTTPS, allowing only SWIFT Transport Layer (SwTL)
based on TLS, or SOAP over HTTPS in the context of web services.
NET.05 Strong firewall rules are in place between the Alliance Messaging Hub and PowerSearch,
allowing only HTTPS
NET.06 Strong firewall rules are in place between the servers running Alliance Messaging Hub
and the middleware used for integrating back-office applications. For example MQ or
other JMS implementations.
NET.08 Management services are only accessible from dedicated operator PCs or by means of a
jump server inside the secure zone.
3.5 Other Security Recommendations

3.5.1 Reconciliation
If there are discrepancies between the messages sent to the SWIFT Network and those which
you intended to send, this can be an indication of fraudulent activity.
ID Control
REC.01 A reconciliation is performed between the messages that are sent to/from the back- office
and to/from the SWIFT Network.
3.5.2 User Security Awareness

In order to protect your infrastructure it is important that your users are aware of security best
practices and actively follow them. Topics which can be covered are, for example, password
management and browsing practices.
31 May 2019 23
ID Control
UAW.01 Annual security awareness sessions are conducted for all staff members. 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
Security awareness and knowledge acquired is measured (for example, by means of
quizzes, certifications, and so on).
3.5.3 Incident Management

In case your infrastructure is impacted by a security threat then correct actions need to be
taken in a prompt way.
ID Control
IMA.01 The customer has a sound and tested cyber security incident management process that
includes information on 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 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 ISAC portal,
and share evidence or indicators of compromise with SWIFT.
31 May 2019 24
Alliance Messaging Hub - Security Guidance Addressing Vulnerabilities
4 Addressing Vulnerabilities
Before deploying any critical application within an institution, customers must be aware of the
technology’s vulnerabilities and the means to address them.
This section gives an overview of the typical threats and attacks for Alliance Messaging Hub
and summarises the security features and controls available to mitigate security threats, and
the likelihood of attacks, as well as methods to limit the impact of successful attacks.
4.1 Threats and Attacks

The deployment of Alliance Messaging Hub does not introduce new threats. Any critical
application may be exposed to attacks, and those attacks must be equally considered when
Alliance Messaging Hub is deployed by a customer. Customer must consider the following
threats:
 end-user impersonation
 message tampering
 message eavesdropping
 third party software weaknesses
 Denial of Service (DoS) attacks affecting service
availability Threat agents can be divided in categories from most
to less trusted:
 system and network administrators
 Alliance Messaging Hub administrators and security officers
 Alliance Messaging Hub operators
 anyone on the customer network
Impact
For all impersonation attacks, the highest impact is always equal to the highest user privilege.
As a consequence, the best way to limit the impact is to have application authorisations
implemented with the “Need-to-know” and “least privilege” principles in mind. In addition,
traceability of user actions plays an important role in limiting the impact of malicious acts.
For DoS attacks, the impact of unavailability must be evaluated by every institution.
4.2 Addressing Security Threats

The following table provides the controls that must be considered for typical attacks when
deploying Alliance Messaging Hub. The controls highlighted in italics should be put in place by
the customer. The controls highlighted in bold are features provided by the Alliance Messaging
Hub; those features must be appropriately configured by Alliance administrators.
Controls
Typical attacks Customer
Alliance Messaging Hub Users and processes
infrastructure
Authentication mechanism [3.3.1] Physical controls [3.1.1] Secure browsing [3.2.3]
Authorisation schemes [3.3.2] Privileged account Auditing and monitoring
Impersonation management [3.1.2] [3.3.7]
Server authentication [3.3.4]
Integrity mechanisms [3.3.5] Reconciliation [3.5.1]
Authorisation schemes [3.3.2] Physical controls [3.1.1] Auditing and monitoring

Server authentication [3.3.4] Privileged account [3.3.7]
Message
Integrity mechanisms [3.3.5] management [3.1.2] Reconciliation [3.5.1]
tampering
System Configuration [3.3.3] Network segregation
[3.4.1]
31 May 2019 25
Alliance Messaging Hub - Security Guidance Addressing Vulnerabilities
Controls
Typical attacks Customer
Alliance Messaging Hub Users and processes
infrastructure
TLS encryption [3.3.4] Physical controls [3.1.1]
Privileged account
Message
management [3.1.2]
eavesdropping
Network segregation
[3.4.1]
Physical controls [3.1.1]
Privileged account
management [3.1.2]
Third-party
Anti-virus [3.1.6, 3.2.4]
software
weakness Update management
[3.2.5]
Network segregation
[3.4.1]
Update management
[3.1.5]
Denial of Anti-virus [3.1.6, 3.2.4]
Service (DoS) Network segregation
[3.4.1]
31 May 2019 26
Alliance Messaging Hub - Security Guidance Mapping Security Controls Against Security Guidance Recommendations
5 Mapping Security Controls Against

Security Guidance Recommendations
Introduction
SWIFT’s Customer Security Controls Framework details a set of 29 security controls to help
SWIFT users secure their local SWIFT environment. 19 of these 29 security controls are
mandatory and establish a security baseline for the entire community. The remaining 10
controls are advisory and based on good practice that SWIFT recommends users implement in
their local environments. Advisory control numbers are suffixed by the letter 'A'.
Over time, mandatory controls may change due to the evolving threat landscape, and some
advisory controls may become mandatory.
The scope of the framework is the local SWIFT environment. However, they reflect good
security practice and it is appropriate to implement them beyond the in-scope environment into
the broader end-to-end transaction chain.
Note The scope of the framework is the local SWIFT environment. However, they
reflect good security practice and it is appropriate to implement them beyond the
in-scope environment into the broader end-to-end transaction chain.
The table below maps each security control (product-agnostic) from the SWIFT Customer
Security Controls Framework against related recommendations defined for the Alliance
Messaging Hub (AMH) product in this document. The paragraphs titled ‘Complementary
requirements’ highlight aspects from the security controls that are new requirements
complementing the existing security recommendations.
SWIFT Security Control Alliance Messaging Hub Security Guidance

1.1 SWIFT Environment Protection 3.1 Secure Server Environment
Control: A segregated secure zone 3.1.4 Operating System Hardening
safeguards the user’s SWIFT Applicable control: SSH.02 (Only authorised and required software is
infrastructure from compromises installed)
and attacks on the broader
enterprise and external
environment.
Applicable control: CIA.01 (block internet access)
Applicable control: CSB.01
Note: In the CSCF, restricted internet access is accepted, providing that:

- Any required Internet access is permitted only if initiated in the outbound
direction.
- Internet access is only granted to whitelisted URL destinations (for example,
site for downloading security patches) via a proxy with content inspection
and adequate blocking/filtering controls. General browsing is not permitted.

3.3.2 3.3.1 User authentication and session management
Applicable control: USM.03
3.4 Local Network Security

3.4.1 Network Segregation
Applicable control: NET.01, NET.02, NET.03, NET.04, NET.05,
NET.06, NET.07
31 May 2019 27
Note: In the CSCF, following network configurations requirements apply:

- Network ACLs or host-based firewalls restrict traffic on a host-by-host basis
within the secure zone.
- Individual hardware or network-based firewalls between the components in
the secure zone can optionally be used.
Complementary requirements2:
- Protections of the secure zone (boundary protection & communication
between components in the secure zone).
- Access to the secure zone (local operator access vs. remote operator
access).
- Segregation from General Enterprise IT Services.
- Virtualisation.
1.2 Operating System 3.1 Secure Server Environment
Privileged Account Control 3.1.2 Logical Access Control
Control: Access to administrator-level Applicable control: SLA.01
operating system accounts is restricted to
the maximum extent possible. Usage is
Complementary requirements:
controlled, monitored, and only permitted
- Further tightening of the operating system privileged account control
for relevant activities such as software
installation and configuration,
maintenance, and emergency activities.
At all other times, an account with least
privilege access is used.
1.3A Virtualisation Platform Complementary requirements2
Protection
Virtualisation.
Control: Secure virtualisation platform,

virtualised machines and supporting
virtual infrastructure (e.g. firewalls) to the
same level as physical systems.
2.1 Internal Data Flow Security 3.3 Application Security
Control: Confidentiality, integrity, and 3.3.4 Server Authentication and Confidentiality
authentication mechanisms are Applicable control: LSC.01, LSC.02, LSC.03, LSC.05
implemented to protect SWIFT-related
application-to-application and operator-
to-application data flows.
2.2 Security Updates 3.1 Secure Server Environment
Control: All hardware and software 3.1.5 Security Patches
inside the secure zone and on operator Applicable control: SSP.01, SSP.02
PCs are within the support lifecycle of the
vendor, have been upgraded with
mandatory software updates, and have 3.2 Secure Client Environment
had security updates promptly applied. 3.2.3 Secure Browsing
3.2.5 Security Patches
Applicable control: CSP.01
- Support availability.
Security update deployment policy based in a risk assessment process
and/or recommended on the Common Vulnerability Scoring System (CVSS),
Version 3.
2.3 System Hardening Secure Server Environment
Control: Security hardening is conducted 3.1.4 Operating System Hardening
2 Requirements included in the SWIFT Customer Security Controls Framework that complement the existing SWIFT
recommendations and which are not yet specifically addressed in the product-specific AMH security guidance.
31 May 2019 28
on all in-scope components. Applicable control: SSH.01
- Operator PCs and supporting infrastructure within the secure zone are
included in the scope.
- All in-scope systems are hardened in accordance with a hardening
standard/guide (vendor, industry or local) but can be overruled by
application-specific configuration requirements to maintain a proper
operational state.
Documented follow-up of the implementation deviations.
2.4A Back-Office Data Flow Security 3.3 Application Security
Control: Confidentiality, integrity, and 3.3.4 Server Authentication and Confidentiality
mutual authentication mechanisms are Applicable control: LSC.04
implemented to protect data flows
between back-office (or middleware) 3.3.7 Integrity of the message flow
applications and connecting SWIFT Applicable control: LAU.01, LAU.02, LAU.03
infrastructure components.
- Mutual authentication of the data flows between back-office systems (or
middleware systems) and directly connected SWIFT infrastructure
components.
2.5A. External Transmission New security requirement.
Data Protection
Control: Sensitive SWIFT-related data
leaving the secure zone is encrypted.
2.6. Operator Session Confidentiality 3.1 Secure Server Environment
and Integrity 3.1.2 Logical Access Control
Control: The confidentiality and integrity Applicable control: SLA.08
of interactive operator sessions
connecting into the secure zone are
safeguarded. 3.3 Application Security
3.3.1 User authentication and session management
Applicable control: OSC.02
- Enhanced the scope (sessions to SWIFT-related applications & OS).
- All interactive sessions are protected by a cryptographic protocol (for
example, ssh, https).
2.7A. Vulnerability Scanning New security requirement.
Control: Secure zone and operator PC
systems are scanned for vulnerabilities
using an up-to-date, reputable scanning
tool.
2.8A Critical Activity Outsourcing New security requirement.
Control: Critical outsourced activities are
protected, at a minimum, to the same
standard of care as if operated within the
originating organisation.
2.9A. Transaction Business Controls 3.5 Other Security Recommendations

Control: Implement RMA controls and 3.5.1 Reconciliation
transaction detection, prevention and Applicable control: REC.01
validation controls to restrict transaction
activity to within the expected bounds or
normal business. Complementary requirements:
Relationship Management Application (RMA)
- Restriction of the transactions and active SWIFTNet FIN sessions outside of
31 May 2019 29
normal business hours.

- Have a process in place to issue and check confirmation messages.
- Monitor uncharacteristic transactions.
2.10A Application Hardening 3.3.4 Server Authentication and Confidentiality
Control: All messaging interfaces (for
example, Alliance Access, Alliance This control exists for users of the Alliance Messaging Hub to comply
Messaging Hub and equivalent) and with the AMH Security Guidance.
communication interfaces (for example,
Alliance Gateway and equivalent)
products within the secure zone are
SWIFT-certified. Security hardening is
conducted and maintained on all in-
scope components.
3.1. Physical Security 3.1 Secure Server Environment
Control: Physical security controls are in 3.1.1 Physical Access Control
place to protect access to sensitive Applicable control: SPA.01, SPA.02, SPA.03
equipment, hosting sites, and storage.

3.2.1 Physical Security
Applicable control: CPS.01

Applicable control: ALG.06
- Security of the Workplace Environment.
- Security for Remote Workers (for example, teleworkers, "on call" duties).
- Additional requirements on the security of the Server Environment.
4.1 Password Policy 3.1 Secure Server Environment
Control: All application and operating 3.1.2 Logical Access Control
system accounts enforce passwords with Applicable control: SLA.05
appropriate parameters such as length,
complexity, validity and the number of
failed login attempts. 3.3 Application Security
Applicable control: USM.01
- Enhanced the scope (log-in to Operator PC (or jump server); secure zone: all
application and operating system accounts).
- Password policy established and aligned to current industry standards or
industry best practices and defines specified criteria. For good practice
guidelines, see KB tip 5021567.
- Password policy developed in consideration to of known password-based
vulnerabilities in the computing environment (that is, LAN Manager
password hash).
- Effectiveness of the password policy is reviewed at least annually.
- Passwords for secure zone systems are stored only within the zone as
described in the guidance for the design of the secure zone.
4.2. Multi-factor Authentication 3.1 Secure Server Environment
Control: Multi-factor authentication is 3.1.2 Logical Access Control
used for interactive user access to Applicable control: SLA.09
SWIFT-related applications and operating
system accounts.
31 May 2019 30
Applicable control: MFA.01
- Multi-factor authentication with Operator PC and to jump server.
- Prioritised order for implementing multi-factor authentication for OS admin
and end-users.
- Multi-factor authentication implemented for remote user administrative
access.
5.1. Logical Access Control 3.1 Secure Server Environment
Control: Accounts are defined according 3.1.2 Logical Access Control
to the security principles of need-to-know Applicable control: SLA.06, SLA.07
access, least privilege, and segregation
of duties.
3.3.2 Authorisation Schemes
Applicable control: AAS.01, AAS.02, AAS.03, AAS.04, AAS.05
3.3.3 System configuration
Applicable control: ASC.03, ASC.05
- Enhanced the scope (all operator accounts (for example, operating systems,
applications)).
5.2. Token Management New security requirement (applicable if connected hardware authentication
tokens are used for SWIFT operations).
Control: Connected
hardware
authentication tokens are managed
appropriately during issuance,
revocation, use, and storage.
5.3A. Personnel Vetting Process 3.1 Secure Server Environment
Control: Staff operating the local SWIFT 3.1.2 Logical Access
infrastructure are vetted prior to initial Control Applicable
employment in that role and periodically
thereafter. control: SLA.01
- Personnel Vetting Process.
5.4. Physical and Logical Password New security requirement.
Storage
Control: Any recorded passwords for
privileged accounts are stored in a
protected physical or logical location, with
access restricted on a need-to-know
basis.
6.1. Malware Protection 3.1 Secure Server Environment
Control: Anti-malware software from 3.1.6 Security Software
a reputable vendor is installed and Applicable control: SSS.01
kept up- to-date on all systems.
3.2.4 Anti-virus and Anti-malware
Applicable control: CAV.01
- On-access anti-malware scanning (also known as real-time or background
scanning) is performed on all in-scope systems. On-demand full scanning is
scheduled at least on weekly basis for servers and on daily basis for operator
31 May 2019 31
PCs.
- Anti-malware software from a reputable vendor is installed on all computing
platforms and updated in line with the scanning frequency.
- Ensure that the transfer of any file content does not contain any kind of
virus or other data that may create risks for the sender, for SWIFT, or for the
receiver.
6.2 Software Integrity 3.3 Application Security
Control: A software integrity check is 3.3.6 Software integrity
performed at regular intervals on Applicable control: SWI.01,SWI.02
messaging interface, communication
interface, and other SWIFT-related
applications.
6.3 Database Integrity 3.3 Application Security
Control: A database integrity check is 3.3.5 Database integrity
performed at regular intervals on Applicable control: DBI.01,DBI.02,DBI.03,DBI.04,DBI.05
databases that record SWIFT
transactions.
6.4 Logging and Monitoring 3.1 Secure Server Environment
Control: Capabilities to detect 3.1.2 Logical Access Control
anomalous activity are implemented, Applicable control: SLA.04
and a process or tool is in place to
frequently store and review logs.
3.1.3 System Activity Logging
Applicable control: SLG.01, SLG.02, SLG.03, SLG.04

3.3.3 System Configuration
Applicable control: ASC.04

Applicable control: ALG.01, ALG.02, ALG.03, ALG.04, ALG.05
- Enhanced the scope (Operator PC (or jump server): operating system, data
exchange layer: network, database, all server applications and OS).
- Retention period of audit logs.
- Types of log files to collect and monitor.
6.5A Intrusion Detection 3.1 Secure Server Environment
Control: Intrusion detection is 3.1.6 Security Software
implemented to detect unauthorised Applicable control: SSS.01
network access and anomalous
activity.
7.1. Cyber Incident Response Planning 3.1 Secure Server Environment
Control: The organisation has a 3.1.7 Backup and Resilience
defined and tested cyber incident Applicable control: SBS.01, SBS.02, SBS.03
response plan.

3.5.3 Incident Management
Applicable control: IMA.01, IMA.02
- The organisation has a defined cyber incident response plan which is
reviewed on annual basis, and tested at least every two years.
- Provided steps to be included in the plan in case of cyber incidents that
compromise the confidentiality, integrity, or availability of SWIFT services
and products.
31 May 2019 32
- The organisation has a documented plan for the timely sharing of threat
information to intelligence-sharing organisations, law enforcement/local
regulators (as required in each customers' jurisdiction), and to SWIFT.
- The organisation has the capability to consume threat intelligence shared by
SWIFT.
7.2. Security Training and Awareness 3.1 Secure Local Server Environment
Control: Annual security awareness 3.1.2 Logical Access Control
sessions are conducted for all staff Applicable control: SLA.02, SLA.03
members, including role-specific
training for SWIFT roles with
privileged access. 3.2 Secure Client Environment

3.5.2 User Security Awareness
Applicable control: UAW.01
- Frequency of the training and security awareness sessions.
7.3A. Penetration Testing New security requirement.
Control: Application, host, and
network penetration testing is
conducted within the secure zone and
on operator PCs.
7.4A. Scenario Risk Assessments New security requirement.
Control: Scenario-driven risk
assessments are conducted regularly
to improve incident response
preparedness and to increase the
maturity of the organisation’s security
programme.
31 May 2019 33
Alliance Messaging Hub - Security Guidance Glossary
6 Glossary
Security Term Definition
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 persons.
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.
Confidentiality Confidentiality refers to information that is disclosed only to authorised persons, 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.
Availability The term availability implies that both the information and the systems used to process,
display, print etc. that information be 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 so as 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.
Auditability Every user of a system must be held accountable for his/her activities. This implies that
all actions can be audited. That means that all relevant actions can be monitored, and
that any one action can be uniquely attributed to a known user, at a particular time and
date.
The following principles assist in ensuring the foundation of a secure system:
Security Principle Definition

Need-To-Know Information and resources should only be made available strictly on a need-to-know or
need-to-have basis.
System configuration 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.
Systems configuration must ensure that operator privileges are controlled in a way that
allows all privileges to be tailored to individual needs.
Default Deny By default, a person must be granted no privilege / no access on a system.
System configuration 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.
31 May 2019 34
Alliance Messaging Hub - Security Guidance Legal Notices
Legal Notices
Copyright
SWIFT © 2019. All rights reserved.
You may copy this publication within your organisation. Any such copy must include these legal
notices.
Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order
expressly grants you that right, in which case ensure you comply with any other applicable
conditions.
Disclaimer
The information in this publication may change from time to time. You must always refer to the
latest available version.
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. SCRL. The following are registered trademarks of
SWIFT: 3SKey, Innotribe, MyStandards, Sibos, SWIFT, SWIFTNet, SWIFT Institute, the
Standards Forum logo, the SWIFT logo and UETR. Other product, service, or company names
in this publication are trade names, trademarks, or registered trademarks of their respective
owners.
31 May 2019 35

SWIFT Alliance Messaging Hub Security Guidance

Uploaded by

Copyright:

Available Formats

SWIFT Alliance Messaging Hub Security Guidance

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SWIFT Alliance Messaging Hub Security Guidance

Uploaded by

Copyright:

Available Formats

What security recommendations are provided for the secure server environment?

What security recommendations are provided for the secure server environment?

What security recommendations are provided for the secure client environment?

What security recommendations are provided for the secure client environment?

Alliance Messaging Hub

1.1 Alliance Messaging Hub

Figure 1: Alliance Messaging Hub logical view

1.2 Customer Responsibilities

2 Overview of Alliance Messaging Hub

Figure 2: AMH deployment view.

Alliance Messaging Hub main components include:

3.1 Secure Server Environment

3.1.1 Physical Access Control

SPA.03 Physical access controls are regularly reviewed.

3.1.2 Internet Access

CIA.04 The Alliance Messaging Hub is not co-hosted.

3.1.3 Logical Access Control

SLA.06 Logical access controls are regularly reviewed.

3.1.4 System Activity Logging

3.1.5 Operating System Hardening

3.1.6 Security Updates

Security update checker tool (AMH 4.0)

3.1.7 Security Software

File Level Integrity Checks (AMH 4.0)

3.1.8 Backup and Resiliency

3.2 Secure Client Environment

OSC.03 A 15-minute lock-out is recommended for end user sessions.

3.2.1 Physical Security

3.2.2 Internet Access

3.2.3 Secure Browsing

CSB.01 The customer follows secure browsing practices, such as:

3.2.4 Anti-virus and Anti-malware

3.2.5 Security Updates

3.3 Application Security

3.3.1 User Authentication and Session Management

Local Authentication with Two-Factor Authentication

AMH 3.6 and higher

Setting up and maintaining the authentication server is the customer’s responsibility.

Single Sign On Authentication

Personal token (AMH 4.0)

Identity Provider authentication with SAML (AMH 4.0)

• Embedded Two-Factor Authentication (Password and TOTP). This is valid for:

3.3.2 Authorisation Schemes

AAS.03 Until AMH 3.7

3.3.3 System Configuration

Alliance Messaging Hub provides functionality (Configuration Manager) to stage configuration

ASC.02 Automated deployment procedures to upload configuration data on target Alliance

ASC.04 Configuration changes, especially on production systems, are monitored, leveraging on

3.3.4 Server Authentication and Confidentiality

Connectivity between Alliance components

Connectivity from customer infrastructure to AMH components

Connectivity from AMH components to customer infrastructure

LSC.02 Transport security relies on TLS following KB TIP 5021566.

3.3.5 Database Integrity

DBI.04 Database integrity is ensured as per database vendor guidelines.

AMH 3.6 and higher

3.3.6 Integrity of the Message Flow

3.3.7 Auditing and Monitoring

ALG.01 Application logs are regularly reviewed.

ALG.05 Alarms are defined for security events.