SWIFT Alliance Security Guidance Checklist

Alliance
Security Guidance Checklist
The purpose of this document is to provide a checklist for the reader about SWIFT's minimum set of security-related
recommendations for customers using Release 7.3 and 7.4 products (Alliance Web Platform Server-Embedded, Alliance
Access/Entry, Alliance Gateway, and SWIFTNet Link). The document is also linked with SWIFT Customer Security
Controls Framework (CSCF V2019).
30 April 2019
Alliance Table of Contents
Table of Contents
1 SWIFT Security Roles and Responsibilities for Customers................................................................ 4

1.1 Logical Access Control (CSCF Control 5.1)............................................................................................ 4
1.2 Security Training and Awareness (CSCF Control 7.2).............................................................................9
2 Local Network Security......................................................................................................................... 11

2.1 SWIFT Environment Protection (CSCF Control 1.1)............................................................................. 11
2.2 Intrusion Detection (CSCF Control 6.5A).............................................................................................. 13
2.3 Other Security Best Practices................................................................................................................13
3 Secure Local Server Environment....................................................................................................... 14

3.2 Operating System Privileged Account Control (CSCF Control 1.2).......................................................15
3.3 Security Updates (CSCF Control 2.2)................................................................................................... 16
3.4 System Hardening (CSCF Control 2.3)................................................................................................. 16
3.5 Malware Protection (CSCF Control 6.1)................................................................................................ 16
3.6 Logging and Monitoring (CSCF Control 6.4)......................................................................................... 17
4 Secure Local Client Environment........................................................................................................ 18

5 Secure Local Application Environment...............................................................................................19

5.1 Internal Data Flow Security (CSCF Control 2.1)....................................................................................19
5.2 Security Updates (CSCF Control 2.2)................................................................................................... 19
5.3 Back-Office Data Flow Security (CSCF Control 2.4A)...........................................................................20
5.4 Operator Session Confidentiality and Integrity (CSCF Control 2.6A).................................................... 20
5.5 Transaction Business Control (CSCF Control 2.9A).............................................................................. 21
5.6 Local Operator Authentication Methods - Password Policy and Multi-factor Authentication (CSCF
Controls 4.1 and 4.2)............................................................................................................................. 23
5.7 Logical Access Control (CSCF Control 5.1).......................................................................................... 31
5.8 Token Management (CSCF Controls 5.2)..............................................................................................34
5.9 Software Integrity (CSCF Control 6.2)................................................................................................... 35
5.10 Database Integrity (CSCF Control 6.3)..................................................................................................35
5.11 Logging and Monitoring (CSCF Control 6.4)......................................................................................... 36
5.12 Security Best Practice Check Tool.........................................................................................................36
30 April 2019 2
Alliance Table of Contents
6 Other Security Recommendations.......................................................................................................37

6.1 Cyber Security Incident Management (CSCF Control 6.4)....................................................................37
6.2 Back-up and Resilience......................................................................................................................... 37
Legal Notices................................................................................................................................................... 39
30 April 2019 3
Alliance SWIFT Security Roles and Responsibilities for Customers
1 SWIFT Security Roles and Responsibilities for

Customers
1.1 Logical Access Control (CSCF Control 5.1)

SWIFTNet Security Officers
ID Recommendation Product Checked Date
SSO.01 The "need-to-know", "least privilege", and O2M

"segregation of duties" principles are
considered when defining Online SWIFTNet
security officers.
No business RBAC roles are assigned to the
profiles of Online SWIFTNet security officers.
SSO.02 A minimum of two online SWIFTNet security O2M

officers are defined, unless administered by
another institution (see Shared security
officers section in SWIFTNet Security
Officer), and a four-eyes 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.
- SWIFT.LRA//
CertificateAdministration4eyes
- SWIFT.RBAC//Delegator//
SWIFT.RBAC//Delegator4eyes
- SWIFT.RBAC//Delegator//
SWIFT.LRA//
CertificateAdministration4eyes
• Access to SWIFTNet Online Operations
Manager (O2M)
• A valid profile password
30 April 2019 4
SSO.03 A minimum of two offline SWIFTNet security Secure

officers is denied, unless administered by Channel
another institution (see Shared security
officers section in SWIFTNet Security
Officer). Each has:
• A swift.com 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 O2M

annually the list of online (Security Officer
Secure
Report on O2M) and offline ("Manage
Channel
Security Profile" in Secure Channel)
SWIFTNet security officer and revoke when
appropriate.
Note
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 Secure
offline SWIFTNet security officer activities in Channel
Secure Channel is generated and reviewed
regularly (at least annually, ideally more
frequently).
SSO.06 A report on activity logs that lists all security O2M (Activity
management changes performed in the Log)
SWIFTNet Online Operations Manager is
generated and reviewed regularly (at least
annually, ideally more frequently).
SSO.07 In case online or offline SWIFTNet security O2M

officers are delegated to be administered by
Secure
another institution, the same standard of care
Channel
is applied as if operated within the originating
institution.
30 April 2019 5
Alliance Security Officers
ASO.01 A minimum of two Alliance security officers swift.com

are defined on swift.com. Each has:
• a swift.com 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 swift.com user profile)
• a valid swift.com user password
ASO.02 A minimum of two Alliance security officers Alliance

are defined on the Alliance Access/Entry Access
application (LSO/RSO or extra security
Alliance Entry
officer). A single individual does not have
access to both the LSO and RSO accounts.
ASO.03 Extra security officers are used next to the Alliance

LSO/RSO, personal accounts allow for easier Access
tracking of actions performed by security
Alliance Entry
officers.
The initial LSO/RSO accounts are disabled.
ASO.04 An internal procedure exists for the execution Alliance

of the break-glass procedure. Access
The steps are described in disabling a Alliance Entry
security officer in the Alliance Access
Security Guide.
ASO.05 A procedure is in place for the Alliance Alliance

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

workflow in place to track new requests/ Access
updates of operators/profiles, as well as the
Alliance Entry
integration with an exit process (that is, when
an employee changes roles or leaves the
institution).
30 April 2019 6
ASO.07 In case the Alliance security officers roles Alliance

(Alliance LSO, Alliance RSO, extra security Access
officers) are delegated to another institution,
Alliance Entry
the same standard of care as if operated
within the originating institution is applied.
swift.com Administrators
ID Recommendations Product Checked Date
SCA.01 The "need-to-know", "least privilege", and swift.com

"segregation of duties" principles are
considered when defining users and standard
profiles on swift.com.
SCA.02 A minimum of two swift.com administrators swift.com

are defined who administer the users and
permissions for your institution on swift.com.
Each has a valid swift.com user password.
SCA.03 swift.com accounts are reviewed at least swift.com

annually (ideally more frequently) and
adjusted as required to enforce access
security principles.
SCA.04 A procedure is in place for swift.com swift.com

administrators to review on a regular 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. swift.com 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 swift.com

the swift.com administrator of individuals
leaving the company or moving internally.
SCA.06 Dual approval has been configured for swift.com

granting/revoking Alliance LSO, Alliance
RSO, and swift.com administrator roles.
30 April 2019 7
ASO.01 A minimum of two Alliance security officers swift.com

are defined on swift.com. Each has:
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 swift.com user profile)
• a valid swift.com user password
SCA.08 A white list for authorised e-mail domain swift.com

names has been configured on swift.com.
SCA.09 Each user defines a seal that is displayed swift.com

every time they access the swift.com login
page. When the user sees this login seal,
they can safely enter their credentials.
Business Officers (FIN or SWIFTNet Copy)
SBO.01 A minimum of two business officers are O2M

defined, unless administered by another
swift.com
institution (see Business Officers (FIN or
SWIFTNet Copy)). Each business officer has:
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
System Administrators
CSA.01 The administrator-level operating system All

accounts (administrator/root) and Alliance
application owner are segregated from the
security officers functions.
Other roles
More detailed and specific information on logical access control applicable for Alliance applications
users is provided in
30 April 2019 8
1.2 Security Training and Awareness (CSCF Control

7.2)
UAW.01 Annual security awareness sessions are All

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).
UAW.02 Regular security and role-specific training All

sessions are conducted for 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
• swift.com administrators
The training is refreshed on a periodic basis.
UAW.03 Operators who have access to the local All

SWIFT infrastructure have an 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.
30 April 2019 9
UAW.04 Operators with access to system OS

administrator accounts or Alliance application
owner accounts have the required operating
system and Alliance product knowledge and
skills to perform their tasks.
30 April 2019 10
Alliance Local Network Security
2 Local Network Security
2.1 SWIFT Environment Protection (CSCF Control 1.1)

NET.01 The network (firewall) complies with the SWIFTNet

Network Configuration Tables Guide. It strictly Link
whitelists all flows required by the SWIFT
network.
NET.02 Firewall rules are in place between the end Alliance Web
user's browser and Alliance Web Platform Platform
Server-Embedded, allowing only HTTPS. Server-
Embedded
NET.03 Firewall rules are in place between Alliance Alliance

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

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

servers running Alliance products and the Access/ Entry
back-office applications.
Alliance
Gateway
NET.06 Firewall rules are in place to restrict remote All

login or access from your office automation
LAN to the servers running Alliance products.
NET.07 Firewall rules are in place between SWIFTNet

SWIFTNet Link and Alliance Connect (VPN Link
Boxes).
Alliance
Connect
NET.08 Management services are only accessible All

from dedicated operator PCs or by means of
a jump server inside the secure zone.
NET.09 The firewall rules and policies are regularly All

reviewed and adjusted.
30 April 2019 11
NET.10 The firewall logs and other network devices All

logs are regularly monitored.
NET.11 A jump server is used to restrict access for All

the system 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.
Segregation of Production and Test environments
CAD.01 Testing is not performed in the production Alliance

environment. Access/ Entry
Test systems are preferably fully segregated Alliance
from production systems (that is, hardware Gateway
and software, including separate HSMs) and
Alliance Web
configured to only support test traffic (for
Platform
example, by only using Lite certificates and
Server-
only configuring test logical terminals). This
Embedded
applies to all components of the local Alliance
infrastructure used for the following HSM
messaging services:
SWIFTNet
• FIN Link
• FileAct
• InterAct
• WebAccess (including Browse)
If not fully segregated, these systems must
be maintained to the same security level as
the production systems.
CAD.02 Segregate environments by using Lite O2M

certificates for signing test traffic (that is, test
or development applications only use Lite
certificates).
30 April 2019 12
2.2 Intrusion Detection (CSCF Control 6.5A)

NID.01 A network intrusion detection system is Network (data

configured to detect anomalous activity within exchange
the secure zone and at the boundary of the layer and
secure zone. inside the
secure zone)
NID.02 Ensure that the configuration parameter Alliance Web

com.swift.swp.Platform:webAccessLoggin Platform
g is set in Alliance Web Platform SE, for the Server-
ability to detect intrusions to HTTP requests Embedded
at the application server and to define a
monitoring process.
2.3 Other Security Best Practices

Connectivity
CON.01 If a local ISP is used to connect to the SWIFT Alliance

Network, there is additional protection in Connect
place against Denial of Service (DoS).
Front-end reverse proxy
FRP.01 There is a reverse proxy or an application Alliance Web

firewall as a front end to Alliance Web Platform
Platform Server-Embedded. Server-
Embedded
30 April 2019 13
Alliance Secure Local Server Environment
3 Secure Local Server Environment

CIA.01 All servers hosting Alliance applications are Server

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

manage the operating systems on which
Alliance products are installed, do not have
Internet access.
CIA.03 System administrators connect through a Server

jump server or a dedicated operator PC hosting
within a secure zone to servers hosting Alliance
Alliance applications. Access/Entry
Alliance
Gateway
Alliance Web
Platform
Server-
Embedded
CIA.04 The Alliance applications are not co-hosted All

Alliance Web Platform SE 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 resiliency purpose.
30 April 2019 14
3.2 Operating System Privileged Account Control

(CSCF Control 1.2)
OSP.01 Careful consideration is given to who is All

assigned the 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 All

application owner account are not personal
(SLA.06(1))
accounts. As such, there are procedures in
place to:
• Identify the specific individual who is
logged in to such an account
• Identify which commands are run on such
an account.
OSP.03 Ensure that Alliance application cannot be Alliance

modified by a non-Alliance application owner. Access/ Entry
In this case, the software files should not
Alliance
have write-execute permission granted to
Gateway
others.
Alliance Web
Platform
Server-
Embedded
SWIFTNet
Link
OSP.04 A mechanism such as 'sudo' is used to All

ensure individual accountability when using
privileged accounts.
OSP.05 There is an emergency procedure to access All

the servers with the administrator account or
Alliance application owner account. An
emergency procedure is helpful when the
authorised 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-authorised person to access the Alliance
hosts unnoticed.
30 April 2019 15
OSP.06 The Alliance applications are configured to OS: All

run as a Windows service. Windows
systems
hosting
SWIFT
products
All products
(1) This is the ID used in the Security Best Practices Check Tool.
3.3 Security Updates (CSCF Control 2.2)

SSP.01 The local server infrastructure (such as All

operating system and third-party software) is
up to date with the latest security updates.
3.4 System Hardening (CSCF Control 2.3)

OSH.01 The operating systems and other software Operating

that are installed on the servers that host system
Alliance products are hardened and
configured according to the third-party vendor
recommendations and security baselines.
OSH.02 No other software is installed on Alliance Operating

servers, except for the software needed to system
operate, monitor, and secure Alliance
products.
OSH.03 A whitelisting process takes in account and Operating

monitors the files used by the Alliance system
products.
3.5 Malware Protection (CSCF Control 6.1)

IDS.01 Security software is installed to protect All

against malicious software or other threats.
30 April 2019 16
3.6 Logging and Monitoring (CSCF Control 6.4)

SLG.01 Operating system log files are monitored and All

regularly reviewed. Such logs 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 All

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 All

12 months and are available for audits or
forensic investigations.
SLG.04 Where possible, the operating system log All

files are integrated with a centralised logging
system.
30 April 2019 17
Alliance Secure Local Client Environment
4 Secure Local Client Environment

SEP.01 Restrict internet access on the operator PCs Operator PC

that have a browser installed 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
30 April 2019 18
Alliance Secure Local Application Environment
5 Secure Local Application Environment
5.1 Internal Data Flow Security (CSCF Control 2.1)

LSC.01 Certificates issued by a trusted Certificate Browser

Authority (CA) or a Certificate Authority under
Alliance Web
the customer's control are used to secure the
Platform
connections to the Alliance products.
Server-
Otherwise, self-signed certificates are
Embedded
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 All

expired:
• Alliance Web Platform SE certificate
• Alliance Access/Entry certificate
• Alliance Gateway certificate
LSC.04 Data encryption/host authentication is used Alliance

between Alliance Access/Entry and Alliance Access/ Entry
Gateway.
Alliance
Gateway
5.2 Security Updates (CSCF Control 2.2)

SSP.01 The Alliance products and related embedded All

or hosted Oracle database are up to date
with the latest security updates, aligned to the
assessed risk or CVSS, v.3.
SSP.02 Recommended Alliance product releases or All

security updates are installed on a timely
basis and for mandatory releases or
cumulative security updates, before the
mandatory installation date.
30 April 2019 19
5.3 Back-Office Data Flow Security (CSCF Control

2.4A)
LAU.01 The confidentiality of messages sent between Alliance

the back office and Alliance products is Access/ Entry
(LSC.04(1))
protected.
Alliance
This can be achieved using TLS, MQ- Gateway
Channel encryption, SFTP, or another
mechanism.
LAU.02 The connection between the back office and Alliance

Alliance products is mutually authenticated. Access/ Entry
This can be achieved using LAU (activated at Alliance
the message partner level), XML-DSig, or Gateway
other authentication mechanisms such as
TLS.
LAU.03 The integrity of messages sent between the Alliance

back office and Alliance products is Access/ Entry
protected.
Alliance
This can be achieved using LAU (activated at Gateway
the message partner level), XML-DSig, or
other protocols ensuring data integrity, such
as TLS.
(1) This is the ID used in the Security Best Practices Check Tool.
5.4 Operator Session Confidentiality and Integrity

(CSCF Control 2.6A)
OSC.01 Sessions are not left open unattended. All Alliance

Applications
OSC.02 For the security parameter Session Expiry Alliance Web

Timeout, set the session time-out to a small Platform
(SLA.03(1))
value (maximum of 15 minutes or 900 Server-
seconds). Embedded
OSC.03 For the security parameter WS Session Time Alliance

Out, set the session time-out to a small value Access/ Entry
(LOA.01(2))
(maximum of 15 minutes or 900 seconds).
OSC.04 For the security parameter SWIFTNet User Alliance

Disconnect Timeout, set the session time-out Gateway
(AGW.01(3))
to a small value (maximum 15 minutes or 900
seconds).
30 April 2019 20
OSC.05 Limit the access to Alliance Access/Entry Alliance

Monitoring only to the operators that need to Access/ Entry
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.
(1) This ID is used in the Security Best Practices Check Tool.

5.5 Transaction Business Control (CSCF Control 2.9A)

Relationship Management Application (RMA)
RMA.01 A procedure is in place to immediately Alliance

remove an RMA authorisation once a Access/ Entry
business relationship has been stopped.
RMA.02 A procedure is in place to review on a regular Alliance

basis your RMA records. Access/ Entry
RMA.03 A procedure or workflow exists within the Alliance

business teams to initiate an RMA Access/ Entry
authorisation creation, removal, or update
request to the RMA operators when a new
business relationship over SWIFT has been
established. This request is logged.
Other Transaction Controls
REC.01 Perform a reconciliation between the All

messages that are sent to/from the back
office and to/from the SWIFT Network.
REC.02 Perform a check to detect abnormal sessions Alliance

and message flows by means of tools, or Access/ Entry
manual checks based on the MT081/
Message File/Event Journal.
30 April 2019 21
REC.03 Limit the active SWIFTNet sessions (FIN, Alliance

InterAct, and FileAct) to specific business Access/ Entry
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 Alliance

Access/Entry to certain days of the week as Access/ Entry
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 Alliance

(through the operator definition) accessing Access/ Entry
the Alliance Access/Entry from a different
time zone than the server's time zone.
REC.06 Alliance application accounts are restricted Alliance

from login attempts that occur outside of Access/ Entry
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 Alliance

GUI to ensure that no one else has used their Access/ Entry
credentials.
REC.08 Use the Touched by Human facility to Alliance

identify those messages where a human Access/ Entry
interaction took place.
REC.09 During the disconnect of a logical terminal Alliance

from the SWIFT network, use the Restricted Access/ Entry
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 All

access behaviour (for example, connections
outside normal business hours).
30 April 2019 22
5.6 Local Operator Authentication Methods - Password

Policy and Multi-factor Authentication (CSCF
Controls 4.1 and 4.2)
Password Policy (CSCF Control 4.1)
Alliance Access/Entry
USM.01 All user-defined passwords used in Alliance Alliance

Access/Entry must be in line with industry Access/ Entry
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 Knowledge Base tips 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 Alliance

Access must be in line with industry best Access/ Entry
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 Knowledge Base tips 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 Alliance

recommended value: Access/ Entry
• User Strong Validation - Defines the
number of character types (uppercase,
lowercase, number, or symbol) that a user
password must contain. Changes to this
parameter become effective when an
operator changes the password.
30 April 2019 23
USM.04 The Password Blacklist security feature is Alliance

used to prevent the use of specific Access/ Entry
characters, combinations of character strings,
and/or of particular words in user-defined
passwords.
The minimum size of the blacklist is
controlled via the configuration parameter:
• Minimum Blacklist Size - Defines the
minimum number of entries a blacklist file
must contain. Recommended value 500
30 April 2019 24
Alliance Gateway
USN.01 By default, Alliance Gateway application Alliance

enforces the following password 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.
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.
30 April 2019 25
USN.02 For the following security parameters, set the Alliance

recommended value: 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,
• Password History Length - Determines
how many previously used passwords to
store in the history list. Alliance Gateway
prevents changing the password to one
that is currently in the list. The value will
be effective at the next password renewal.
• 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 Alliance

used to prevent the use of specific Gateway
characters, combinations of character strings,
and/or of particular words in passwords.
• Minimum Blacklist Size - Defines the
minimum number of entries a blacklist file
must contain. Recommended value: 500
30 April 2019 26
Alliance Web Platform SE
CLA.01 By default, Alliance Web Platform SE Alliance Web

application enforces below password rules: Platform
Server-
• Passwords must contain elements from
Embedded
each of the following sets:
- Uppercase (A - Z)
- Lowercase (a - z)
- Numeric (0 - 9)
- Special characters (! # $ % & ' ( ) * + ,
- . / : ; < = ? @ [ \ ] ^ _ ` { | } ~)
• Passwords must not be the same as 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.
• Minimum Password Length - Detemines
the minimum length of passwords in
number of characters if TOTP is not used.
• Mimimum 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 Alliance Web
recommended value: Platform
Server-
• Password Expiration - Controls the
Embedded
number of days that a password can be
used before it expires and consequently
must be changed. Recommended value:
90
• Password History Size - Number of
passwords stored in the password history.
• 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
30 April 2019 27
CLA.03 The Password Blacklist security feature is Alliance Web

used to prevent the use of specific Platform
characters, combinations of character strings, Server-
and/or of particular words in user-defined Embedded
passwords.
• Blacklist Size - Defines the minimum
number of entries a blacklist file must
contain. Recommended value: 500
Multi-factor authentication (CSCF Control 4.2)
MFA.01 At least a two-factor authentication method is Alliance

used for authentication on Alliance products. Access/ Entry
(USM.02(1))
The options are:
Alliance
• Embedded Two-Factor Authentication Gateway
(Password and TOTP). This is valid for:
Alliance Web
- All operators in Alliance Access Platform
including main LSO/RSO and extra Server-
security officers Embedded
- 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.
30 April 2019 28
MFA.02 For the following two-factor authentication Alliance

security parameters, set the recommended Access/ Entry
value:
• Auth type available - Allows 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 Alliance

security parameters, set the recommended Gateway
value:
• Two-factor Authentication Step Size -
Controls the length of time (in seconds)
for which a single Time-based one-time
Password value is valid. Recommended
value: 30
• Two-factor Authentication Window -
Controls the range of Time-based one-
time Password values accepted for a login
attempt. Recommended value: 3
• Two-factor Authentication Digits - Controls
the number of digits required for a Time-
based one-time Password value.
• Two-factor Authentication Hash Algorithm
- Controls the hash algorithm used to
generate a Time-based one-time
Password value. Minimum recommended
value: SHA256
30 April 2019 29
MFA.04 For the following two-factor authentication Alliance Web

security parameters, set the recommended Platform
value: Server-
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.
• Two-factor Auth for Alliance Gateway
Administration - Enable two-factor
authentication support for the Alliance
Gateway Administration GUI.
MFA.05 The off-the-shelf application used for All

generating a Time-based one-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.
30 April 2019 30
5.7 Logical Access Control (CSCF Control 5.1)

Alliance Acces/Entry, Alliance Gateway
AAS.01 The "need-to-know", "least privilege", and Alliance

"segregation of duties" principles are applied Access/ Entry
when defining operators and operator profiles
Alliance
in Alliance applications.
Gateway
The embedded logical access control and
security parameters features can be used for
this purpose.
AAS.02 The left and right security operators (LSO/ Alliance

RSO) are two independent individuals, with Access/ Entry
independent back-ups identified in case of
their absence.
AAS.03 Security officers or administrative application All

accounts are 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 Alliance

a message partner (for example permissions Access/ Entry
related to currency and amount) are
restricted.
AAS.05 The SuperKey operator profile on the Alliance

production system is removed. Access/ Entry
AAS.06 The use of the System Administration Alliance

application is restricted to the Alliance Access/ Entry
Access/Entry administrator (application
owner) account.
The usage of the Alliance administrator
account must be traced.
AAS.07 Login with built-in Alliance Gateway Alliance

Administrator accounts is restricted to Gateway
perform activities where such an account is
specifically needed (for example, the initial
application configuration, application
upgrade, or emergencies).
Individual accounts with well segregated
profiles assigned are used instead for all day-
to-day operations.
30 April 2019 31
AAS.08 Login with built-in Alliance Web Platform SE Alliance Web

Administrator accounts is restricted to those Platform
activities where such an account is Server-
specifically needed (for example, the initial Embedded
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 Alliance

set to enabled to enforce the segregation of Access/ Entry
duties for operators, message partners, and
routing rules.
AAS.10 Verify if the "Routing/ Mod Active Schema" Alliance

entitlement is assigned to any operator profile Access
and if there is a valid business need.
Careful consideration is given to who is
assigned this permission and the account
activity is tightly controlled.
AAS.11 The configuration parameter Enable Requires Alliance

Additional Operator is set to "Yes" in order Gateway
that an operator who added or updated an
entity cannot also enable that entity. Those
entities are of the type operator, operating
profile, and virtual SWIFTNet user.
In addition, ensure that the operating profile
does not include the function Allow
Unconditional Enable for <entity>.
AAS.12 There is an emergency procedure to access Alliance

the application with a privileged account (for Access/ Entry
example, the default Alliance Gateway
Alliance
Administrator or the Alliance Web Platform
Gateway
SE Administrator). An emergency procedure
is helpful when the authorised persons are
unavailable due 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 All

reviewed (at least annually, ideally more
frequently).
When an employee changes roles or leaves
the company, their access rights are promptly
modified or revoked.
30 April 2019 32
AAS.14 The Alliance Gateway operators (having O2M

privileges related to PKI certificate
(SLA.08(1)) Secure
management) and SWIFTNet security
Channel
officers are different persons.
Alliance
Gateway
O2M (SWIFTNet Online Operations Manager)
CAD.01 The "need-to-know", "least privilege", and O2M

"segregation of duties" principles are applied
when defining SWIFTNet users and PKI
Certificates.
CAD.02 There is a generally approved and traceable O2M

workflow in place to track new 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.03 The certificate is uniquely identifying the O2M

individual or application within a 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.04 The certificate class (for example, Business O2M

or Lite), Policy ID, and password policy (either
human or application) is applied correctly.
30 April 2019 33
CAD.05 A procedure is in place for the SWIFTNet O2M

security officers to review on a 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.
5.8 Token Management (CSCF Controls 5.2)

HSM.01 The PIN Entry Device (PED) and PED keys HSM
are securely stored.
HSM.02 Physical access to the PED and PED keys is HSM

logged.
HSM.03 The USB token is securely stored when it is HSM

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

it is in use.
HSM.05 USB tokens are distributed and assigned HSM

appropriately, and are revoked when the
person leaves the company.
HSM.06 The admin user is the sole owner of the HSM

SO/HSM Admin key.
30 April 2019 34
5.9 Software Integrity (CSCF Control 6.2)

SWI.01 A software integrity check is regularly Alliance

performed on the Alliance products. Access/ Entry
Alliance
Gateway
SWIFTNet
Link
SWI.02 The Alliance products are automatically Alliance

configured to execute a software integrity Access/ Entry
check at startup. If it fails, the product does
Alliance
not start. In such situation, check the related
Gateway
logs and contact SWIFT Customer Support.
SWI.03 When downloading Alliance software, the Alliance

checksum mentioned on swift.com is Access/ Entry
matched against the actual checksum of the
Alliance
file.
Gateway
SWI.04 Verify and monitor signatures provided in Alliance

all .exe and .dll files provided by SWIFT, Access/ Entry
as part of Alliance products code signing.
Alliance
Gateway
Alliance Web
Platform
Server-
Embedded
5.10 Database Integrity (CSCF Control 6.3)

DBI.01 A database integrity check is regularly Alliance

performed on the Alliance products. Access/ Entry
Alliance
Gateway
Alliance Web
Platform
Server-
Embedded
DBI.02 Ensure that the new security configuration Alliance

parameter Shutdown on Database Gateway
Tampering Detection is always set to Yes.
30 April 2019 35
5.11 Logging and Monitoring (CSCF Control 6.4)

ALG.01 Application Event Logs are regularly All

reviewed.
ALG.02 Application Event Logs are stored on a All

remote system that cannot be accessed by
the same individuals.
ALG.03 Event Log files are safe-stored and available All

for audits or forensic investigations.
ALG.04 Where applicable, Alliance Event Log events Alliance

are integrated with a centralised logging and Access/ Entry
monitoring system.
Alliance
Gateway
Alliance Web
Platform
Server-
Embedded
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 Alliance

is owned by the software owner. Access/ Entry
ALG.07 In the case of the monitoring via GUI option, Alliance

ensure that the parameter Activate Alert Gateway
Monitoring is set to Yes.
5.12 Security Best Practice Check Tool

CTA.01 The Security Best Practice Check Tool is run Alliance

regularly on Alliance applications. The output Access/ Entry
is validated to ensure that security items are
Alliance Web
configured properly.
Platform
Server-
Embedded
Alliance
Gateway
SWIFTNet
Link
30 April 2019 36
Alliance Other Security Recommendations
6 Other Security Recommendations
6.1 Cyber Security Incident Management (CSCF

Control 6.4)
IMA.01 The customer has a sound and tested cyber All

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 All

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 All

shared by means of the SWIFT ISAC portal,
and share evidence or indicators of
compromise with SWIFT.
6.2 Back-up and Resilience

SBS.01 Back-ups of data and software are made All

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 All

Recovery Time Objective (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 All

applications are documented, 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.
30 April 2019 37
Alliance Other Security Recommendations
SBS.04 Ensure back-up persons are identified All

especially for privileged accounts in the local
SWIFT infrastructure to ensure the business
continuity of operations.
SBS.05 Sensitive SWIFT-related data leaving the All

secure zone as a result of backups, data
replication for recovery, or further off-line
processing is encrypted.
30 April 2019 38
Alliance Legal Notices
Legal Notices
Copyright
SWIFT © 2019. All rights reserved.
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.
30 April 2019 39

SWIFT Alliance Security Guidance Checklist

Uploaded by

Copyright:

Available Formats

You might also like

SWIFT Alliance Security Guidance Checklist

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 Security Guidance Checklist

Uploaded by

Copyright:

Available Formats

Alliance

Security Guidance Checklist

1 SWIFT Security Roles and Responsibilities for Customers................................................................ 4

2 Local Network Security......................................................................................................................... 11

3 Secure Local Server Environment....................................................................................................... 14

4 Secure Local Client Environment........................................................................................................ 18

5 Secure Local Application Environment...............................................................................................19

6 Other Security Recommendations.......................................................................................................37

1 SWIFT Security Roles and Responsibilities for

1.1 Logical Access Control (CSCF Control 5.1)

ID Recommendation Product Checked Date

SSO.01 The "need-to-know", "least privilege", and O2M

SSO.02 A minimum of two online SWIFTNet security O2M

ID Recommendation Product Checked Date

SSO.03 A minimum of two offline SWIFTNet security Secure

SSO.04 A procedure is in place to review at least O2M

SSO.07 In case online or offline SWIFTNet security O2M

Alliance Security Officers

ID Recommendation Product Checked Date

ASO.01 A minimum of two Alliance security officers swift.com

ASO.02 A minimum of two Alliance security officers Alliance

ASO.03 Extra security officers are used next to the Alliance

ASO.04 An internal procedure exists for the execution Alliance

ASO.05 A procedure is in place for the Alliance Alliance

ASO.06 There is a generally approved and traceable Alliance

ID Recommendation Product Checked Date

ASO.07 In case the Alliance security officers roles Alliance

ID Recommendations Product Checked Date

SCA.01 The "need-to-know", "least privilege", and swift.com

SCA.02 A minimum of two swift.com administrators swift.com

SCA.03 swift.com accounts are reviewed at least swift.com

SCA.04 A procedure is in place for swift.com swift.com

SCA.05 An internal procedure is in place that alerts swift.com

SCA.06 Dual approval has been configured for swift.com

ID Recommendations Product Checked Date

ASO.01 A minimum of two Alliance security officers swift.com

SCA.08 A white list for authorised e-mail domain swift.com

SCA.09 Each user defines a seal that is displayed swift.com

Business Officers (FIN or SWIFTNet Copy)

ID Recommendation Product Checked Date

SBO.01 A minimum of two business officers are O2M

ID Recommendation Product Checked Date

CSA.01 The administrator-level operating system All

1.2 Security Training and Awareness (CSCF Control

UAW.01 Annual security awareness sessions are All

UAW.02 Regular security and role-specific training All

UAW.03 Operators who have access to the local All

ID Recommendation Product Checked Date

UAW.04 Operators with access to system OS

2 Local Network Security

2.1 SWIFT Environment Protection (CSCF Control 1.1)

NET.01 The network (firewall) complies with the SWIFTNet

NET.03 Firewall rules are in place between Alliance Alliance

NET.04 Firewall rules are in place between Alliance Alliance

NET.05 Firewall rules are in place between the Alliance

NET.06 Firewall rules are in place to restrict remote All

NET.07 Firewall rules are in place between SWIFTNet

NET.08 Management services are only accessible All

NET.09 The firewall rules and policies are regularly All