Al2 Sec Guid PDF

Alliance Lite2
Security Guidance
The purpose of this document is to provide the reader with an overview of the security features for Alliance Lite2. The
document also lists the minimum set of controls that SWIFT recommends for customer implementation on their
infrastructure for connecting to Alliance Lite2. The document also makes the link with SWIFT Customer Security Controls
Framework (CSCF v2020).
08 November 2019
Alliance Lite2 Table of Contents
Security Guidance
Table of Contents
1 Preface......................................................................................................................................................3
2 Introduction..............................................................................................................................................4
2.1 Customer Responsibilities....................................................................................................................... 4
2.2 Governance............................................................................................................................................. 5
3 Key Security Aspects of Alliance Lite2................................................................................................. 7

3.1 Connection to SWIFTNet.........................................................................................................................7
3.2 SWIFT WebAccess..................................................................................................................................7
3.3 Alliance Lite2 Central Infrastructure........................................................................................................ 8
3.4 Connectivity and Encryption.................................................................................................................... 9
3.5 PKI-based Security................................................................................................................................10
3.6 Alliance Lite2 Customer Security Officer Role.......................................................................................11
4 Security Best Practices and SWIFT Security Recommendations.....................................................12

4.1 SWIFT Security Governance for Customers......................................................................................... 12
4.2 Secure Local Server Environment......................................................................................................... 15
4.3 Secure Local Client Environment.......................................................................................................... 19
4.4 Secure Application Environment............................................................................................................21
4.5 Local Network Security..........................................................................................................................24
4.6 Other Security Recommendations.........................................................................................................25
5 Addressing Vulnerabilities................................................................................................................... 29
5.1 Threats and Attacks...............................................................................................................................29
5.2 Addressing Security Threats................................................................................................................. 29
6 Security Controls Checklist..................................................................................................................31
7 Glossary................................................................................................................................................. 43
Legal Notices................................................................................................................................................... 45
08 November 2019 2
Alliance Lite2 Preface
Security Guidance
1 Preface
Purpose of this document
This document is issued for information purposes only. It is aimed at providing the reader with an
overview of the security features of Alliance Lite2. For more information about Alliance Lite2, see
the Alliance Lite2 Service Description and other related documentation. This document also makes
the link to the security controls documented in SWIFT Customer Security Controls Framework
(CSCF v2020).
This document also includes general guidance that is designed to assist Alliance Lite2 customers
in protecting their access to and use of Alliance Lite2. It is not meant to be an exhaustive list of
recommendations nor to replace well-structured policy, sound judgement, and compliance with the
current best practices. Furthermore, it does not address customer-specific infrastructure and
configuration issues, or other specific requirements that may apply to customers considering, in
particular, the technology used and the customer’s own security risk analysis.
The information in this document refers to the description of Alliance Lite2 at the date of this
document. As this document may not necessarily be updated along with subsequent changes to
Alliance Lite2, always refer to the latest available version of the Alliance Lite2 Service Description
and Alliance Lite2 User Guide.
Audience
This document is intended for the following audience:
• local administrators of the customer infrastructure to connect to Alliance Lite2
• security specialists
• auditors
To get the most out of this document, the reader must be familiar with the current business and
technical offerings of SWIFTNet.
Related documentation
• Alliance Lite2 Service Description
• Alliance Lite2 User Guide
• Alliance Lite2 Administration Guide
• AutoClient User Guide
• SWIFTNet Online Operations Manager User Guide
• Security Officer Guide
• SWIFTNet Service Description
08 November 2019 3
Alliance Lite2 Introduction
Security Guidance
2 Introduction
This security guidance document gives an overview of the key security features and security
operator functions of Alliance Lite2, as well as a minimum set of customer security controls that are
designed to help customers protect their local environment. Further guidance can be found in the
various guides referenced in this document.
What is Alliance Lite2?

In the context of Alliance Lite2, SWIFT operates a central infrastructure that provides customers
with an application server that is itself connected to the SWIFT Network. Customers can connect to
the application server over the public Internet or over the SWIFT secure IP network (SIPN) using
Alliance Connect VPN boxes.
Customers of the SWIFT Network see Alliance Lite2 customers no differently than other customers
who use a direct connection to the SWIFT Network. For example, trust relationship and registration
procedures are the same for Alliance Lite2 customers as for any other customer.
Alliance Lite2 security features

The Alliance Lite2 service enables the following security features:
• two-factor authentication using Federal Information Processing Standard (FIPS)-compliant
password-protected USB tokens or channel certificates
• non-repudiation based on explicit PKI signing for the most sensitive operations
• central workflow for handling message creation and approval
• user entitlements allowing predefined profile assignment
• segregation of duties between administrator and operator roles
• dual authorisation (four-eyes) for the most sensitive operations
These features are specific to the Alliance Lite2 service, and are designed to complement the
generic security infrastructure implemented at your institution.
Generic customer security infrastructure

A generic customer security infrastructure that is exposed to the public Internet must include
firewalls, web content filtering, anti-virus software, anti-malware software, as well as customer
awareness and practices. Any computer connected to the public Internet is exposed to threats, so it
is important that such machines are up to date, with the latest security updates installed.
Therefore, as with any other public Internet-connected users, Alliance Lite2 customers must
consider complementing their (existing or newly deployed) security infrastructure with the
previously listed application-level security features. Even when using the SWIFT secure IP network,
SWIFT customers must consider implementing the previously listed application-level security
features.
2.1 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 traffic, message, and configuration data
on their local SWIFT systems, and on that segment of its connectivity for which SWIFT is not
responsible under the SWIFT Contractual Documentation.
08 November 2019 4
Security Guidance
In particular, the customer must ensure that it:

• Implements appropriate management principles to ensure that: (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, and applications
are fully segregated based on their criticality, (v) cyber-defence controls are implemented.
• 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 are used for malicious purposes or cyber-attacks.
• Operates backup procedures and handles backup media according to security practices no less
secure than those applied to its production systems and connectivity.
• Installs and uses only that official third-party software and equipment that is necessary to
access and use SWIFT services and products, and that it complies at all times with all proper
instructions and recommendations regarding their use (typically, the timely installation of all
critical security and application 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 a customer believes a security incident has occurred within their local environment, they should
immediately isolate themselves from the SWIFT Network and immediately inform SWIFT Support,
which will assist the customer on how to proceed. For more information on your reporting
obligations and reporting channel, consult the SWIFT General Terms and Conditions and the
SWIFT Support Service Descriptions.
2.2 Governance
The Alliance Lite2 central infrastructure is built using industry-strength processes that help ensure
best-in-class quality, security, and reliability. Development lifecycle processes ensure that security
and availability are built in right from the start.
To a large extent, these same processes have been used by SWIFT to deliver the FIN and
SWIFTNet services, on which the global financial community relies on a daily basis. Lite2 Third
Party assurance report (ISAE 3000) produced by SWIFT can be obtained following the instructions
on KB tip 2208810.
The development process at SWIFT requires the 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 to build Alliance Lite2. This covers operating system, middleware, network device,
and application-level vulnerabilities. Finally, Alliance Lite2 and all underlying processes are part of
SWIFT’s Internal Audit universe and are extensively reviewed on a regular and systematic basis.
Contractual framework
Alliance Lite2 customers enter into a specific contractual framework with SWIFT. This framework
defines the specific roles and responsibilities of the parties.
08 November 2019 5
Security Guidance
For example, Alliance Lite2 customers are responsible for the following:
• all signed messages sent to the Alliance Lite2 central infrastructure (and forwarded over the
SWIFT Network)
• downloading and, as applicable, acting upon messages received from the SWIFT Network
08 November 2019 6
Alliance Lite2 Key Security Aspects of Alliance Lite2
Security Guidance
3 Key Security Aspects of Alliance Lite2
3.1 Connection to SWIFTNet
Alliance Lite2 is a means of connecting to the SWIFT Network. Alliance Lite2 does not affect the
existing security aspects of the SWIFT Network.
PKI certificates
As with any other customer of the SWIFT Network, customers who access SWIFTNet through
Alliance Lite2 are identified on the SWIFT Network by standard SWIFTNet PKI certificates that are
associated with their BIC8. All messages initiated by or intended for Alliance Lite2 are signed in the
same way as any message exchanged over the SWIFT Network. RMA authorisation messages
must also be exchanged with Alliance Lite2 customers when required (such as on the FIN service).
The existing contractual framework for messaging services over the SWIFT Network, including
liability, continues to apply for messages exchanged between customers of the SWIFT Network,
regardless whether a customer has a direct connection or uses Alliance Lite2.
Customers can find more information about connection methods in the SWIFTNet Service
Description.
3.2 SWIFT WebAccess

SWIFT WebAccess is a SWIFTNet messaging service that enables secure access from a standard
web browser to a service provider's web server and SWIFTNet server application over the SWIFT
Network. SWIFT WebAccess is only for person-to-application use.
Services accessible through SWIFT WebAccess

Alliance Lite2 offers access to the following SWIFT WebAccess services to end-users who connect
from a desktop with a USB token provided by SWIFT:
08 November 2019 7
Security Guidance
Function Description
SWIFTNet Online Operations Manager Use the SWIFTNet Online Operations Manager to
administer security through a SWIFT-managed
service available over SWIFT WebAccess.
Other SWIFT WebAccess services Connect to any other SWIFT WebAccess service that
Alliance Lite2 supports and to which the customer
has subscribed.
3.3 Alliance Lite2 Central Infrastructure

The Alliance Lite2 service provides access to SWIFTNet messaging services.
AutoClient
or Direct Link
USB token Alliance Lite2
or channel certificate
Connection Server
to SWIFT
Secure workflow
USB token
SWIFTNet Interface
Browser AutoClient Internet or Alliance Lite2 All SWIFTNet flows Financial

Interface or Direct Link Alliance Connect Servers (FIN, MT, MX, InterAct, Institutions
FileAct, SWIFT WebAccess)
for automated VPN
flows
Alliance Lite2 Network SWIFT SWIFT Network SWIFT Community

Customer Premises Operating Centres
D1370003
SWIFT operates the Alliance Lite2 central infrastructure that implements the systems and
procedures that are normally used by customers of the SWIFT Network with a direct connection. In
addition, for Alliance Lite2 customers, SWIFT provides reverse proxies, web application firewalls
(WAFs), demilitarised zones (DMZs), and other security measures.
Alliance Lite2 access to the SWIFT Network does not introduce additional threats on the SWIFT
Network itself. The Alliance Lite2 central infrastructure connects to the SWIFT Network in a manner
equivalent to how other customers connect to the SWIFT Network, using components such as the
Messaging Interface, Communication Interface, SWIFTNet Link, and HSM. There are specific
protections against public Internet exposure (for example, distributed DoS) that are built into the
Alliance Lite2 central infrastructure.
The Alliance Lite2 central infrastructure is implemented within SWIFT operating centres. All
operational controls are similar to those that are used to provide the FIN and SWIFTNet service.
08 November 2019 8
Security Guidance
3.4 Connectivity and Encryption

Connecting to Alliance Lite2
Customers can connect to the Alliance Lite2 central services in one of two ways:
• over the SWIFT secure IP network (MV-SIPN) using Alliance Connect VPN boxes
• over the public Internet
The connection to the SWIFT network is then established from the Alliance Lite2 central servers.
3.4.1 Connection Security

Standard security measures
All communication between the user and the Alliance Lite2 servers is encrypted and protected by
two-way authenticated TLS sessions.
Alliance Lite2 uses token-based certificates or channel certificates (over MV-SIPN) to establish a
connection with the Alliance Lite2 services deployed at a SWIFT operating centre, and to sign
business messages and files for non-repudiation. User-based connections to Alliance Lite2 using a
browser are secured with a token-based certificate.
Additional security measures

In addition to Transport Layer Security, a customer can opt for Alliance Connect solutions that
provide encryption at the network layer through VPN boxes. This option becomes mandatory for the
use of channel certificates. For product information, see Advantages of Alliance Connect on page
9.
3.4.2 Advantages of Alliance Connect

Network-level security
The Alliance Connect VPN box cluster uses a proven mechanism that secures the creation of a
secure channel over the multi-vendor network partner backbones or the public Internet. This
channel uses Internet Protocol Security (IPsec) technology, which preserves the security of the
data that customers exchange on the infrastructure (for example, the SWIFT network partner's
backbone). The IPsec session occurs between the VPN boxes at the customer's premises and
VPN concentrators that are located in SWIFT's backbone access points.
IPsec is an end-to-end security solution that operates at layer 3 in the Open Systems
Interconnection (OSI) model. IPsec is a suite of protocols that have the following roles:
• secure Internet Protocol (IP) communications by authenticating and encrypting each IP packet
of a data stream
• establish mutual authentication between agents at the beginning of the session and negotiation
of cryptographic keys for use during the session
08 November 2019 9
Security Guidance
3.5 PKI-based Security

Public Key Infrastructure
Each Alliance Lite2 customer institution is identified by a BIC and has two identities:
• an Alliance Lite2 identity for access to the Alliance Lite2 central infrastructure
• a SWIFTNet identity for exchanging traffic over the SWIFT Network. Only this identity is visible
to other customers of the SWIFT Network.
The customer has full control over the keys associated with the Alliance Lite2 identity. The keys
associated with the SWIFTNet identity are hosted in HSMs in the Alliance Lite2 central
infrastructure.
3.5.1 Token-based Certificates

A token-based certificate is a certificate that resides on a personal token.
A personal token, also called a USB token or physical token, is a piece of hardware that provides a
means for SWIFT to authenticate the identity of a user or an application. AutoClient also uses these
token certificates to establish the TLS connection to the Alliance Lite2 central service. The Alliance
Lite2 user or AutoClient application is authenticated through a 2048-bit PKI private key that is
generated at the customer premises. This PKI credential is protected in the USB token and never
leaves the token. This is a FIPS 140-2, level 3, USB token. The USB token itself uses the private
PKI key to sign the most sensitive operations created by the user and sent to the Alliance Lite2
central infrastructure. The user must provide a password to use the USB token, once it is activated.
Multiple consecutive failed password attempts will permanently lock the USB token.
To unlock the USB token, it must be re-initialised using the provided SafeNet Tools, then re-certified
by the Alliance Lite2 Customer Security Officers. Both of the security officers (left and right) must
participate in this action. For more information, see the Alliance Lite2 User Guide.
The token is personal and must not be shared with another user. It is protected by a password that
the owner of the token must keep private.
In the context of Alliance Lite2, SWIFT uses token-based certificates to generate non-repudiation
evidence of the emission of a business message from an Alliance Lite2 customer to the Alliance
Lite2 central infrastructure at SWIFT.
The liability of the Alliance Lite2 customer is bound to this non-repudiation evidence. This evidence
is used in the context of a dispute resolution between the Alliance Lite2 customer and SWIFT.
Note The same USB token technology may be used for browser-based access and
AutoClient access to Alliance Lite2.
3.5.2 Channel Certificates

A channel certificate is an encrypted, disk-based certificate that provides a means for SWIFT to
authenticate the identity of an application. The AutoClient application is authenticated through a
2048-bit PKI private key that is generated at the customer premises. Alliance Lite2 supports
channel certificates as an alternative means to physical tokens for securing the connection
between AutoClient at the customer's premises and SWIFT, and to allow non-repudiation of
signatures. Alliance Lite2 supports channel certificates, yet channel certificates mandate the use
of Alliance Connect VPN boxes connectivity. In addition, channel certificates cannot be used
for human-to-application flows, such as manual message entry, administration, approval, and
SWIFT WebAccess services.
08 November 2019 10
Security Guidance
AutoClient also uses these channel certificates to establish the TLS connection to the Alliance Lite2
central service. To prevent the misuse of channel certificates, SWIFT ensures that channel
certificates cannot be used outside the institution for which they are registered. To this effect,
SWIFT verifies that the BIC8 of the channel certificate used matches the BIC8 of the VPN box of
the institution.
3.5.3 SWIFT Certificate Centre

Alliance Lite2 also requires access to the SWIFT Certificate Centre to manage SWIFT PKI
certificates and related PKI credentials. For information on activating tokens, changing the
password that protects them, and performing other token management operations, see SWIFT
Certificate Centre - Getting Started with Your Personal Token.
3.6 Alliance Lite2 Customer Security Officer Role

The Alliance Lite2 Customer Security Officer role provides access to a set of security management
functions that allow performing tasks such as managing end users, restricting counterparties, and
managing PKI credentials.
More specifically, these functions include:
• creation and deletion of end users (for example, when a user changes role or leaves the
company)
• key revocation, in the case of a lost USB token
• creation or re-creation of user or AutoClient USB tokens or AutoClient channel certificates (or
the distribution of credentials to the AutoClient system administrator)
08 November 2019 11
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
Security Guidance
4 Security Best Practices and SWIFT Security

Recommendations
Alliance Lite2 relies on several security features under the direct control and management of
customers. 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 access
Alliance Lite2 are important in maintaining a secure environment. The security of the infrastructure
is not specific to Alliance Lite2, but is valid for any critical business application at the customer
premises.
This section covers six topics:
• SWIFT Security Governance for Customers on page 12: controls that help customers
implement a diligent organisation to protect their assets.
• Secure Local Server Environment on page 15: controls that help secure the servers that host
the Alliance Lite2 AutoClient software and the customer applications that they communicate
with.
• Secure Local Client Environment on page 19: controls that help secure the workstations used
to connect to Alliance Lite2. There can be an overlap in the recommendations made for the
Local Client and Local Server environment. The controls can be found in both sections to
highlight the importance in both environments.
• Secure Application Environment on page 21: controls that help configure the Alliance Lite2
application and users securely.
• Local Network Security on page 24: controls that help secure the network environment of the
Alliance Lite2 infrastructure.
• Other Security Recommendations on page 25: controls that are recommended by SWIFT that
do not fit into 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 columns:
• ID: an identification number that can be used to refer to a specific control
• Control: the control to be put in place
• Product: the Alliance Lite2 product to which the control applies
Where applicable, links are provided to the appropriate SWIFT documentation. For any questions
regarding operating system or third-party application configuration, we recommend that you contact
your vendor.
4.1 SWIFT Security Governance for Customers

SWIFT has defined a number of security officer types who should manage SWIFT security matters.
Each customer will need to carefully allocate the different roles and responsibilities, and define the
appropriate controls to support the effective implementation of the security policies.
4.1.1 Alliance Lite2 Customer Security Officers

Alliance Lite2 is provisioned with two predefined Customer Security Officers per each 8-character
BIC: the left Customer Security Officer (left-cso) and the right Customer Security Officer (right-cso).
08 November 2019 12
Security Guidance
These security officers are mainly responsible for:

• the configuration of Alliance Lite2, and the creation, maintenance, and deletion of the business
users
• the generation of the initial activation codes for the personal certificates, and the handover of the
initial activation code to the intended user or AutoClient operator
• the generation of the initial activation code for the channel certificates, and the handover of the
initial activation code to the AutoClient administrator
• the assignment of Alliance Lite2 roles to business users
This role combines the security management responsibilities on SWIFTNet (certificate and Role
Based Access Control management) and on the Alliance Lite2 application.
Online and offline tools for Customer Security Officers

Alliance Lite2 Customer Security Officers, also called Customer Security Officers, have online and
offline capabilities to perform various security-related tasks. They always exercise dual
authorisation control over which users will be permitted to access Alliance Lite2 and which activities
they will be allowed to do.
The following online and offline tools are available:
Tool Type of tool Customer Security Officer scope
SWIFT Certificate Online The SWIFT Certificate Centre is a portal that is used by
Centre Customer Security Officers to activate their tokens. The usage
of this portal is not restricted to Customer Security Officers.
Also, the Alliance Lite2 operators will use the portal to manage
their token or PKI credentials stored on it.
SWIFTNet Online Online Customer Security Officers will use the SWIFTNet Online
Operations Manager Operations Manager to manage Distinguished Names (DNs)
(O2M) for each of the institution's Alliance Lite2 operators and their
RBAC roles.
One of the Customer Security Officers must create a DN for
each operator before creating the new operator in Alliance
Lite2. The operator can then be approved by the other
Customer Security Officer.
Secure Channel Offline This tool is to be used by the Customer Security Officers to
retrieve their initial activation codes, to manage secure code
cards, to manage the registration of a new Customer Security
Officer, and to submit SWIFTNet Offline interventions.
The profiles of the Alliance Lite2 Customer Security Officers adhere to 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 operations are performed by at least two individuals, each
responsible for a separate part of the task.
O2M/Secure Channel implement dual authorisation/four-eyes features to enforce the segregation of
duties for the security officers.
For backup purposes, SWIFT recommends the creation of an additional left security officer and an
additional right security officer. This means that your institution will have four operators with security
08 November 2019 13
Security Guidance
officer permissions. This is very useful when one of the two original customer security officers is
unavailable (for example, on holiday) or forgets his password.
It is important that customers carefully maintain their list of security officers and that they
immediately revoke the security officer role when it is no longer valid.
ID Control Product
ALQ.01 Two Alliance Lite2 Customer Security Officers are created by SWIFT. The All
customer can create any additional Customer Security Officers that are
required. A single individual does not have access to both of the security
officers’ accounts. For more information, see Knowledge Base tip
5017169.
ALQ.02 The left and right Customer Security Officers are two independent All
individuals, with independent backups identified in case of their absence.
ALQ.03 A procedure is in place to review on a regular basis the list of Customer Secure Channel
Security Officers (“Manage Security Officer” in Secure Channel) and
revoke when appropriate.
Note Customers must keep SWIFT informed of any changes to
Customer Security Officer arrangements.
For more information, see manage security profiles in the
Secure Channel User Guide and Knowledge Base tip
5017169.
ALQ.04 An audit report that lists all past and ongoing Customer Security Officer O2M and Secure
activities is downloaded on a regular basis from Secure Channel and Channel
O2M, reviewed, and safe-stored for a period of at least 12 months.
ALQ.05 A procedure is in place that alerts the Customer Security Officers of All
individuals leaving the company or moving internally.
4.1.2 swift.com Administrators

SWIFT creates the two initial swift.com administrators. A swift.com administrator can then delegate
the swift.com administrator contact role to another registered user.
swift.com mandates two-step authentication for a number of applications. A user needs to set up
two-step verification before they can access these applications. The administrator can force users
under their scope of control to set up two-step verification at their next login.
The swift.com administrator can generate an audit report that contains all audit records for all users
in the scope of control of the administrator, for the indicated time period. Alternatively, the audit
report can be run for a single user. The maximum audit reporting period is six months, if requested
for all users. There is no time limit for single-user audit reports.
ID Control Product
SCA.01 The "need-to-know", "least privilege", and "segregation of duties" swift.com

principles are considered when defining users and standard profiles on
swift.com.
08 November 2019 14
Security Guidance
ID Control Product
SCA.02 A minimum of two swift.com administrators are defined who manage the swift.com
users and permissions for your institution on swift.com. Each has a valid
swift.com user password.
SCA.03 swift.com accounts are reviewed annually and adjusted as required to swift.com
enforce access security principles.
SCA.04 A procedure is in place for swift.com administrators to review the list of swift.com
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 if not recovered 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 the swift.com administrator of swift.com
individuals leaving the company or moving internally.
SCA.06 Users define a seal that will be displayed every time they access the swift.com
swift.com login page. When users see this login-seal, they can safely enter
their credentials.
Dual approval has been configured for granting/revoking Alliance LSO,
Alliance RSO, and swift.com administrator roles.
SCA.08 A white list for authorised e-mail domain names has been configured on
swift.com
4.2 Secure Local Server Environment

This set of controls applies to securing your systems that host the AutoClient component of Alliance
Lite2. Customers must implement these security measures in line with the industry security
practices.
4.2.1 Physical Access Control

Physical access controls may deter or detect unauthorised access to your hardware. Data centres,
server rooms, individual server racks, or other controlled-access areas can be protected by various
security measures.
08 November 2019 15
Security Guidance
ID Control Product
ALS.01 Physical security controls are in place. They ensure that only authorised All
personnel can access the servers running AutoClient software.
• Host the servers in a data centre or, at a minimum, in a room with
limited and controlled access. The latter can be achieved by means of
access control cards, possibly combined with biometrics.
• Monitor the physical access.
• Physically lock and/or rack-mount the servers as appropriate.
• Lock up any backup material.
• Educate users on security best practices.
ALS.02 Physical access to the hosts running the AutoClient software is logged. All
These logs are available for audits and investigations, and should be
retained for a minimum of 12 months.
ALS.03 Physical access controls are regularly reviewed. When employees change All
roles or leave the company, their access rights are immediately modified.
ALS.04 For those customers who use USB tokens, other mass storage on the All
AutoClient PC is disabled, such as Firewire and Esata.
For those customers who use channel certificates, all mass storage ports
on the AutoClient PC are disabled, such as Firewire, Esata, and USB, to
the maximum extent possible while still supporting operations.
4.2.2 Logical Access Control

Operating systems usually feature an administrator account, the name of which is chosen by the
operator during installation. This is a privileged account, in that persons acting as administrator are
able to take complete and sole charge of the system. If administrator credentials are stolen, then all
application-level and server-level defences can be compromised.
The administrator account is not needed to run AutoClient on a day-to-day basis or to exchange
traffic. It is only used for configuring the software.
It is not possible to exercise four-eye control on operating system accounts. Therefore, specific
controls should be implemented to tightly control the use of the administrator or any other operating
system account that is used to install and maintain the AutoClient software.
ID Control Product
SLA.01 Careful consideration is given to whom is assigned the role of All

administrator or the role of application owner.
The use of the administrator and application owner accounts is tightly
controlled (that is, by limiting the number of people on a strict need-to-
know/need-to-change basis.
All employees with access to the administrator and application owner
accounts are vetted by a certified and/or trusted third party.
SLA.02 Employees with access to administrator accounts or application owner All

accounts have the required operating system skills to perform their tasks.
08 November 2019 16
Security Guidance
ID Control Product
SLA.03 Session locks are enforced: time-out after 15 minutes of inactivity (that is, All
if a session has been idle for more than 15 minutes, the user will be
required to re-authenticate to re-activate the terminal or session).
Sessions are not left open unattended.
SLA.04 A two-factor method is used for authentication on the operating system. All
SLA.05 Employees with access to administrator accounts or application owner All

accounts are aware about security best practices.
They receive sufficient security-related training, and this training is
refreshed on a periodic basis.
SLA.07 Careful consideration is given to the choice of passwords for administrator All
accounts and the application owner accounts.
A password policy is defined that is in line with industry best practices, for
example:
• A minimum password length of 12 characters
• Password complexity
- No blank passwords
- No default passwords
- Passwords are composed of at least three elements out of the
following sets: uppercase, lowercase, special characters, and
numbers.
• A history list length of eight non-reusable passwords.
• A maximum of 90 days after which a password must be changed
• A maximum of five failed login attempts before lockout.
• The same password is not reused on different services.
• Passwords governed by an emergency process are changed after use.
The password policy is documented, communicated, and enforced.
SLA.08 Logical access controls are regularly reviewed. All

Any account that is dormant must be disabled and immediately removed
from the system.
When employees change roles or leave the company, their access rights
are promptly modified.
4.2.3 Operating System Activity Logging

Operating systems allow you to log information that helps you identify certain users and the
commands they run. Actively monitoring such logs can help you identify malicious activity on your
systems. Furthermore, safe-storing such log files can help you during forensic investigations.
08 November 2019 17
Security Guidance
ID Control Product
SLG.01 Operating system log files are monitored and regularly reviewed. Such All
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 activity logs are stored on a remote system that cannot All
be accessed by the source 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 All
for audits or forensic investigations.
SLG.04 Where possible, the operating system log files are integrated with a
centralised logging system.
4.2.4 Operating System Hardening

Operating system hardening can be used to make the configuration of Alliance Lite2 servers more
secure. In most cases, operating system hardening uses the existing features of the operating
system.
ID Control Product
OSH.01 The operating system and other software that are installed on the servers All
that host the AutoClient software are configured according to the third-
party vendor recommendations and security baselines.
OSH.02 No other software is installed on AutoClient servers, except for the All
software needed to operate, monitor, and secure the AutoClient software.
OSH.03 A whitelisting process takes in account and monitors the files used by the
Alliance products.
4.2.5 Security Updates

Operating systems and other software used by AutoClient software, as well as back offices, should
be updated with the latest security updates that are made available by the vendor. Security updates
contain corrective actions that prevent the successful exploitation of known security vulnerabilities.
Customers can contact their vendor for more information and recommendations.
ID Control Product
SSP.01 The local infrastructure (such as operating system, software, and third- All
party software) is up to date with the latest security updates.
08 November 2019 18
Security Guidance
ID Control Product
SSP.02 Mandatory or recommended AutoClient releases or updates are installed All

on a timely basis, and for mandatory releases, before the mandatory
installation date.
4.2.6 Security Software

Security software, such as anti-virus, anti-malware, and host-based firewall and intrusion detection
systems, must be installed to prevent, detect, and remove malicious software.
Note SWIFT does not recommend specific vendors of security software.
ID Control Product
IDS.01 Security software is installed and is up to date to protect against malicious All
software or other threats.
Any file sent to or received from AutoClient is scanned.
IDS.02 An internal integrity check on the software and configuration data is All
running in the AutoClient 1.3 and later versions.
This feature is embedded within the AutoClient 1.3 and later versions, so
you are compliant with control 6.2 Software Integrity of the CSP roadshow
if you operate with one of these releases.
4.3 Secure Local Client Environment

This set of controls applies to securing your client environment.
These recommendations apply to all of the end-user PCs that connect to the Alliance Lite2 GUI.
4.3.1 Physical Access Control

Physical access controls may deter or detect unauthorised access to your hardware. Only genuine
software must be installed.
ID Control Product
ALP.01 Physical security controls are in place. They ensure that only authorised All
personnel can access the clients used to connect to the Alliance Lite2
GUI.

The end-user PCs used to connect to Alliance Lite2 should only be accessible by an authorised
user. Generic accounts must not be used (that is, one logical access is equal to a single physical
person).
08 November 2019 19
Security Guidance
ID Control Product
ALL.01 Logical access controls are regularly reviewed. All

When employees change roles or leave the company, their access rights
are promptly modified.
ALL.02 Session locks are enforced: time-out after 15 minutes of inactivity (that is, All
if a session has been idle for more than 15 minutes, the user will be
required to re-authenticate to re-activate the terminal or session).
4.3.3 Anti-virus and Anti-malware Services

Security software such as anti-virus, anti-malware, and host-based firewall and intrusion detection
systems can be installed to prevent, detect, and remove malicious software.
Note SWIFT does not recommend specific vendors of security software.
ID Control Product
ALM.01 Anti-virus and anti-malware services and their associated databases are All
installed and up to date on the client host infrastructure.
4.3.4 Security Updates

Operating systems and other authorised software (browsers and additional features such as Java
plug-ins) used in the user PCs should be updated with the latest security updates that are made
available by the vendor.
Security updates contain corrective actions that prevent the successful exploitation of known
security vulnerabilities. The customer can contact their vendor for more information and
recommendations.
ID Control Product
ALU.01 The client infrastructure is up to date with the latest security updates for All
the supported software versions.
4.3.5 Secure Browsing

Customers are advised to review and implement (where possible) controls, in order to implement
secure browsing practices. These controls provide a non-exhaustive list of secure browsing
practices
08 November 2019 20
Security Guidance
ID Control Product
ALB.01 The customer follows secure browsing practices, such as: Alliance Lite2 GUI
• Segregating general browsing from Alliance Lite2, ideally by using
different workstations.
• Ensuring that each user verifies the Alliance Lite2 server's TLS
certificate authenticity during each login to Alliance Lite2.
For more information, refer to the logging-in section of the Alliance
Lite2 User Guide.
• Not browsing sites other than Alliance Lite2 and SWIFT WebAccess
services when an Alliance Lite2 session is open.
• Restarting the browser instance before and after accessing the
Alliance Lite2 site.
• Never following links in e-mails that pretend to direct the user to
Alliance Lite2. Be suspicious of e-mails that appear to come from
SWIFT, and never provide the token password if asked. SWIFT never
asks for any password in an e-mail or any other form of
communication.
• Ensuring security awareness for Alliance Lite2 end users, developing
and maintaining security focused behaviour among end users, and
ensuring that end users are fully aware of threats related to browsing
(such as ensuring that user sessions cannot be taken over).
4.4 Secure Application Environment

The Alliance Lite2 product 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.
Two-factor authentication using FIPS-compliant password-protected USB tokens for the end users
is enabled by default inAlliance Lite2.

The Alliance Lite2 product 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 operations are performed by at least two individuals, each
responsible for a separate part of the task.
Alliance Lite2 offers a variety of default operator profiles and the option to request customised
operator profiles. These profiles can be used to restrict operator permissions and enforce the
segregation of duties.
When connecting to the Alliance Lite2 service, each Alliance Lite2 customer can have multiple end
users. These end users can have different Alliance Lite2 role profiles and permissions.
Alliance Lite2 role profiles include roles such as administrator, approver, and creator. Each of these
role profiles can be independently granted to Alliance Lite2 end users, typically by customer’s
administrators. Customers can also request to SWIFT the creation of customer roles, according to
the way that responsibilities are dispatched in the customer’s own institution.
08 November 2019 21
Security Guidance
ID Control Product
ALC.01 The "need-to-know", "least privilege", and "segregation of duties" All

principles are considered when defining operators and operator profiles.
ALC.02 Dual authorisation is implemented for the most sensitive operations All
(message processing, RMA management, and so on.).
The administrator and message approval roles are not granted to the
same individuals.
ALC.03 The “Msg_ALL” and “RMA_All” profiles are not assigned to operators in Alliance Lite2 GUI
the live production environment. These profiles can be used only for test
purposes in the test environment.
ALC.04 The application is configured in such a way that the transactions from AutoClient and GUI
AutoClient are manually approved on the GUI before they are released to
SWIFT.
This approach is highly recommended for STP (Straight Through
Processing) flows sent from back-office applications, if LAU or other
integrity mechanisms are not in place.
ALC.05 Administrator-level operating system accounts are not used to run All
AutoClient, or the browser on the PC where Alliance Lite2 is accessed/
used.
ALC.06 Logical access controls are regularly reviewed for the profiles and users All
defined in Alliance Lite2.
When an employee changes roles or leaves the company, or in the case of
dormant users, their access rights are promptly modified.
4.4.2 Confidentiality, Integrity, and Authentication

ID Control Product
ALI.01 The integrity of files between the back-office application and AutoClient is AutoClient
protected.
This can be achieved using Local Authentication (LAU) on AutoClient to
ensure that all critical internal flows to or from the AutoClient system are
protected against malicious changes, especially if the AutoClient files are
transferred through a network.
ALI.02 The exchange of files between the back-office application and AutoClient AutoClient
is protected using a security mechanism that provides authentication.
This can be achieved using LAU.
ALI.03 The transport of files between the back office and the AutoClient is AutoClient
encrypted. This can be achieved by using solutions such as SFTP.
08 November 2019 22
Security Guidance
4.4.3 USB Token

Access to Alliance Lite2 using the GUI or the AutoClient component requires the use of a
password-protected USB token. This USB token contains a PKI private key required to sign all
business-critical operations.
ID Control Product
ALT.01 The USB token is securely stored when it is not in use. USB token
ALT.02 The USB token is not left unsupervised when it is in use. USB token
ALT.03 USB tokens are distributed and assigned only to authorised operators. An USB token
operator's token is revoked upon changing jobs or leaving the company.
ALT.04 The user-defined USB token password must be sufficiently strong USB token
(password length, complexity, renewal, and so on, as per policy). The
password must never be written down and must be known only to its
intended authorised user.
4.4.4 Channel Certificate

Access to Alliance Lite2 can also be performed by the AutoClient using a channel certificate, if
combined with a connection over SIPN using an Alliance Connect VPN box, which is FIPS 140-2
level 2 certified.
ID Control Product
ACC.01 The user-defined channel certificate password must be sufficiently strong Channel certificate
(password length, complexity, renewal, and so on, as per policy). The
password must never be written down and must be known only to its
ACC.02 Channel certificates are used with strict physical access control. Channel certificate
4.4.5 Auditing and Monitoring

Alliance Lite2 provides monitoring features that can be used to ensure the performance and the
security of customers’ SWIFT infrastructure.
The status of the files uploaded to the AutoClient server can be tracked in the log. You can also
monitor the status of the transactions that you send from AutoClient to the Alliance Lite2 server, as
well as the payments received. For more information, see monitoring file transfers in the AutoClient
User Guide.
You can monitor the status of all transactions (transactions that you send from AutoClient and/or
transactions that you process manually in the GUI) using the Alliance Lite2 GUI component.
The Alliance Lite2 GUI allows you to search the messages/files exchanged with counterparties and
to generate a report of details or summary information of messages.
08 November 2019 23
Security Guidance
ID Control Product
ALA.01 A process is in place to monitor traffic anomalies (for example, AutoClient and GUI
transactions outside of normal business hours).
ALA.02 AutoClient log files are regularly reviewed. AutoClient
ALA.03 AutoClient log files are archived, safe-stored for a minimum period of 12 AutoClient
months, and available for audits or forensic investigations.
Customers should archive and retain the following log files for forensic investigations:
• autoclient_logs.log: A new file is created upon each startup and contains entries for each file
that is being sent, including the status of each of these files. The file is added to the
<installation directory>\logs folder.
• autoclient_trace.log: A new file is created upon each startup and contains tracing information.
The file is added to the <installation directory>\logs folder.
• configuration tool log files: Logs created by the configuration tool (ConfigTool.exe) in the
<installation directory>\configurationlogs folder.
• monitor log files: These logs are available in <installation directory>\monitorlogs folder.
Since the AutoClient monitor process runs for each user logged into the AutoClient system, one
log file will be created for each user running a monitor process.
Note A roll-over mechanism ensures that a maximum of ten files of five MB each are kept in
the system, therefore, timely archival is required.
4.5 Local Network Security
4.5.1 Connectivity
SWIFT provides various options to connect to the SWIFT Network. Customers can choose
between leased lines and DSL connections from Network Partners (multi-vendor model) or Internet
Service Providers (ISPs).
Connecting through MV-SIPN contributes to protecting SWIFT against Distributed Denial of Service
(DDoS) attacks for services such as those made available through Alliance Lite2, compared to
connecting via the public Internet directly.
ID Control Product
CON.01 If a local ISP is used to connect to the SWIFT Network, there is additional Alliance Lite2
protection in place against Denial of Service (DoS).
For customers connecting through a public Internet connection, SWIFT proposes a DDoS
mitigation solution. To benefit from this solution, additional firewall configuration is required. This
additional configuration limits the operational impact to your institution in the event that SWIFT is
subjected to a DDoS attack.
For additional information, see Knowledge Base tip 5019964.
08 November 2019 24
Security Guidance
4.5.2 Network Segregation

As a general requirement, customers must ensure that their network (firewall) complies with the
Connectivity to SWIFT - Network Configuration Tables Guide, which strictly whitelists all flows
required by the SWIFT Network.
SWIFT strongly recommends to use segregated environments where possible.
SWIFT strongly advises that you use a firewall between the Alliance Lite2 PCs where a channel
certificate or a token-based certificate is used (both the Alliance Lite2 Web interface (browser) and
the AutoClient) and the public Internet or the multi-vendor secure IP network (MV-SIPN). CSCF
implementation guideline requires dedicated a firewall to separate the Secure Zone (AutoClient
Server) from the General IT environment.
ID Control Product
ALN.01 A firewall facing the public Internet is installed and managed that does not AutoClient and
accept any incoming connections towards the systems used to access Alliance Lite2 GUI
Alliance Lite2, and from unauthorised access over the internal network.
The firewall must be both a physical one to restrict incoming traffic, and a
host-based one to ensure that only authorised programs communicate on
the network.
If an Alliance Connect solution is used to connect to Alliance Lite2, you
can ask SWIFT to disable public Internet access for all your users, only
allowing access through SWIFT's Virtual Private Network.
ALN.02 Outgoing traffic is restricted from systems used to access Alliance Lite2 to AutoClient and
business-critical sites, such as legitimate sites required for software Alliance Lite2 GUI
updates.
ALN.03 CSCF requires a dedicated firewall in place between the servers running AutoClient
AutoClient software and the back-office applications.
ALN.04 CSCF requires Jump Server or a dedicated PC for management of the AutoClient
AutoClient in the Secure Zone.
ALN.05 A Jump Server is used for access to management services through All
untrusted networks is prohibited.
ALN.06 The firewall rules and policies are regularly reviewed. All
ALN.07 The firewall logs are monitored. All
4.6 Other Security Recommendations
4.6.1 Relationship Management Application (RMA)

The Relationship Management Application (RMA) provides functions to manage authorisations for
a business relationship, which enables you to conduct business with trusted parties only.
When an institution consents to receive messages from a specific correspondent, that consent is
recorded in an authorisation in RMA. A correspondent can send you messages only when you
have authorised that correspondent to do so. This helps mitigate the risk of receiving unwanted
08 November 2019 25
Security Guidance
payments. The use of granular RMA authorisation option is recommended as it allows to further
limit the risk of unwanted transactions.
It is important to keep your RMA records constantly up to date and in line with your actual business
relationships. By doing so, you will not receive messages from counterparties with which you do not
have a relationship. Under normal circumstances, FIN messages for which an authorisation has
been revoked will be rejected within 15 minutes of the acknowledgement of the revocation
message.
ID Control Product
RMA.01 A procedure is in place to immediately remove an RMA authorisation Alliance Lite2 GUI
record once a business relationship has been stopped.
RMA.02 A procedure is in place to review on a regular basis your RMA Alliance Lite2 GUI
authorisation records.
RMA.03 A procedure/workflow exists within the business teams to initiate an RMA Alliance Lite2 GUI
authorisation creation request to the RMA operators when a new business
relationship over SWIFT has been established. This request is logged.
4.6.2 Detection Mechanisms

Mechanisms exist for detecting anomalies, which can help to identify malicious activities. This
selection of mechanisms is not exhaustive.
4.6.2.1 Reconciliation
If there are discrepancies between the messages recorded by the SWIFT Network and those
recorded by the entity, this can be an indication of fraudulent activity.
Therefore, it is important to have a daily bank reconciliation process. In this process, all items in the
end-of-day statement (MT950 or MT940) are matched against the entity's accounting records
(called ledger items) for that day’s value date.
ID Control Product
REC.01 Perform a reconciliation between the messages that are sent to/from the All
back office and to/from the SWIFT Network.
4.6.2.2 Abnormal Sessions and Message Flows

It is important to look for abnormal session/traffic patterns. For example, this might allow you to
detect payment activity originated outside of normal business hours, or unusual session and
message activity, which can potentially indicate fraudulent activity.
Sophisticated tools exist for that purpose, as described below.
08 November 2019 26
Security Guidance
A simplified alternative is to use the MT081 Daily Check Report. This message, which is visible in
the GUI and forwarded to the AutoClient, lists the number of sessions, as well as the date and time
they were opened and closed. It is important to check these reports for anomalies on a daily basis.
For customers who have sessions open for 24 hours, it is recommended that the Alliance operator
checks the Alliance Message File in the morning, to verify whether any payments were sent during
an unexpected timeframe.
ID Control Product
ASM.01 A check is performed to detect abnormal sessions and message flows by All
means of tools, or manual checks based on the MT081/Message File.
4.6.3 Resilience and Backup

The architecture of Alliance Lite2 enables a customer to achieve the availability and resilience
levels that are typically required for business-critical applications. The customer should carefully
consider availability and resilience objectives, and choose a deployment and configuration setup
that meets those requirements.
Resilience
Customers can set up several standby AutoClient instances. The standby instance can be located
in the same operating site or in a second operating site. This ensures that activities are not
interrupted (for example, in the case of natural disaster). For more information, see AutoClient
instances in the AutoClient User Guide.
Backups
Customers should implement a backup strategy to ensure that operations can be resumed in case
of system unavailability. It is good practice to back up the AutoClient software and configuration
files on a regular basis for possible local restore. In addition, customers must also plan to back up
their AutoClient messaging data.
These backups must be securely stored, ideally in a remote location. In the unlikely situation that
the software and/or data are corrupted, a recent backup provides a starting point to restore the
system.
ID Control Product
SBS.01 Backups of data and software are made frequently. The backup policy and AutoClient
procedures are documented. The process to restore backups is
documented and is tested periodically.
SBS.03 IT continuity plans for Alliance Lite2 are documented, tested, and updated AutoClient
regularly to ensure that they are up to date and effective. Testing of
continuity plans and related procedures for the restoration of business
activity is performed at least annually. For more information, see Glossary
on page 43.
08 November 2019 27
Security Guidance
4.6.4 User Security Awareness

To protect your infrastructure, it is important that your users are aware of security best practices
and that they actively follow them. Topics can be covered such as password management and
browsing practices, for example.
Ensure that the persons who have access to sensitive applications, data, certificates, network, and
so on have an adequate knowledge level and are aware of the pertinent cyber risks, best practice
behaviours, and processes.
ID Control Product
UAW.01 Annual security awareness sessions are conducted for all staff members. All
In addition to CSCF examples, topics may include:
• protection from viruses, worms, Trojan horses, and other malicious
code - scanning and updating definitions
• unknown e-mail and attachments
• internet usage
• social engineering
• access control issues - address least privilege and separation of duties
• individual accountability
• security awareness and knowledge acquired is measured (for example,
by means of quizzes or certifications)
4.6.5 Incident Management

If your infrastructure is impacted by a security threat, then corrective actions should be promptly
taken.
ID Control Product
IMA.01 The customer has a sound and tested cyber security incident All
management process that includes information on who to contact, which
channels to use, and under what conditions to use them.
IMA.02 If a critical security incident is detected within the environment, the server All
running AutoClient is immediately isolated and SWIFT is informed
accordingly.
08 November 2019 28
Alliance Lite2 Addressing Vulnerabilities
Security Guidance
5 Addressing Vulnerabilities
Before deploying any critical application within an institution, customers should 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 Lite2. It also
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.
5.1 Threats and Attacks

The use of Alliance Lite2 does not introduce new known threats. Any critical application can be
exposed to attacks, and those attacks should be equally considered when Alliance Lite2 is used by
a customer. Customers should 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 into categories in the order from most-trusted to least-trusted:
• system and network administrators
• Alliance Lite2 administrators and security officers
• Alliance Lite2 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, the traceability of user
actions plays an important role in limiting the impact of malicious acts.
5.2 Addressing Security Threats

The following table lists some typical threats that the end user may encounter when using the
public Internet. This table also provides some suggestions to mitigate these threats.
Typical threats Controls
Alliance Lite2 Customer infrastructure Users and processes
Impersonation Logical Access Control Secure Local Server Auditing and Monitoring
on page 21 Environment on page 15 on page 23
Confidentiality, Integrity, Logical Access Control Reconciliation on page 26
and Authentication on on page 16
page 22
USB Token on page 23
08 November 2019 29
Alliance Lite2 Addressing Vulnerabilities
Security Guidance
Typical threats Controls
Alliance Lite2 Customer infrastructure Users and processes
Message tampering Logical Access Control Secure Local Server Auditing and Monitoring
on page 21 Environment on page 15 on page 23
Confidentiality, Integrity, Network Segregation on Reconciliation on page 26
and Authentication on page 25
page 22
USB Token on page 23
Message eavesdropping Confidentiality, Integrity, Secure Local Server

and Authentication on Environment on page 15
page 22
Network Segregation on
Advantages of Alliance page 25
Connect on page 9
Third-party software Secure Local Server

weakness Environment on page 15
Security Updates on
page 18
page 25
Denial of Service (DoS) Security Updates on

page 18
Connectivity on page 24
page 25
08 November 2019 30
Alliance Lite2 Security Controls Checklist
Security Guidance
6 Security Controls Checklist

SWIFT Security Governance for Customers
Alliance Lite2 Customer Security Officers
ID Control Product Checked Date
ALQ.01 Two Alliance Lite2 Customer Security Officers are All

created by SWIFT. The customer can create any
additional Customer Security Officers that are required.
A single individual does not have access to both of the
security officers’ accounts. For more information, see
Knowledge Base tip 5017169.
ALQ.02 The left and right Customer Security Officers are two All
independent individuals, with independent backups
identified in case of their absence.
ALQ.03 A procedure is in place to review on a regular basis the Secure

list of Customer Security Officers (“Manage Security Channel
Officer” in Secure Channel) and revoke when
appropriate.
Note Customers must keep SWIFT informed of
any changes to Customer Security Officer
arrangements.
For more information, see manage
security profiles in the Secure Channel
User Guide and Knowledge Base tip
5017169.
ALQ.04 An audit report that lists all past and ongoing Customer O2M and
Security Officer activities is downloaded on a regular Secure
basis from Secure Channel and O2M, reviewed, and Channel
safe-stored for a period of at least 12 months.
ALQ.05 A procedure is in place that alerts the Customer All

Security Officers of individuals leaving the company or
moving internally.
swift.com administrators
SCA.01 The "need-to-know", "least privilege", and "segregation swift.com

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

who manage 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 annually and adjusted swift.com

as required to enforce access security principles.
08 November 2019 31
Security Guidance
SCA.04 A procedure is in place for swift.com administrators to swift.com

review 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 if not recovered within six months
after profile expiry.
SCA.05 An internal procedure is in place that alerts the swift.com

swift.com administrator of individuals leaving the
company or moving internally.
SCA.06 Users define a seal that will be displayed every time swift.com
they access the swift.com login page. When users see
this login-seal, they can safely enter their credentials.
Secure Local Server Environment

Physical Access Control
ALS.01 Physical security controls are in place. They ensure that All
only authorised personnel can access the servers
running AutoClient software.
• Host the servers in a data centre or, at a minimum,
in a room with limited and controlled access. The
latter can be achieved by means of access control
cards, possibly combined with biometrics.
• Monitor the physical access.
• Physically lock and/or rack-mount the servers as
appropriate.
• Lock up any backup material.
• Educate users on security best practices.
ALS.02 Physical access to the hosts running the AutoClient All

software is logged. These logs are available for audits
and investigations, and should be retained for a
minimum of 12 months.
ALS.03 Physical access controls are regularly reviewed. When All

employees change roles or leave the company, their
access rights are immediately modified.
ALS.04 For those customers who use USB tokens, other mass All
storage on the AutoClient PC is disabled, such as
Firewire and Esata.
For those customers who use channel certificates, all
mass storage ports on the AutoClient PC are disabled,
such as Firewire, Esata, and USB, to the maximum
extent possible while still supporting operations.
08 November 2019 32
Security Guidance
Logical Access Control
SLA.01 Careful consideration is given to whom is assigned the All

role of administrator or the role of application owner.
The use of the administrator and application owner
accounts is tightly controlled (that is, by limiting the
number of people on a strict need-to-know/need-to-
change basis.
All employees with access to the administrator and
application owner accounts are vetted by a certified
and/or trusted third party.
SLA.02 Employees with access to administrator accounts or All

application owner accounts have the required operating
system skills to perform their tasks.
SLA.03 Session locks are enforced: time-out after 15 minutes of All

inactivity (that is, if a session has been idle for more
than 15 minutes, the user will be required to re-
authenticate to re-activate the terminal or session).
SLA.04 A two-factor method is used for authentication on the All

operating system.
SLA.05 Employees with access to administrator accounts or All

application owner accounts are aware about security
best practices.
They receive sufficient security-related training, and this
training is refreshed on a periodic basis.
08 November 2019 33
Security Guidance
SLA.07 Careful consideration is given to the choice of All

passwords for administrator accounts and the
application owner accounts.
A password policy is defined that is in line with industry
best practices, for example:
• A minimum password length of 12 characters
• Password complexity
- No blank passwords
- No default passwords
- Passwords are composed of at least three
elements out of the following sets: uppercase,
lowercase, special characters, and numbers.
• A history list length of eight non-reusable passwords.
• A maximum of 90 days after which a password must
be changed
• A maximum of five failed login attempts before
lockout.
• The same password is not reused on different
services.
• Passwords governed by an emergency process are
changed after use.
The password policy is documented, communicated,
and enforced.
SLA.08 Logical access controls are regularly reviewed. All

Any account that is dormant must be disabled and
immediately removed from the system.
When employees change roles or leave the company,
their access rights are promptly modified.
Operating System Activity Logging
SLG.01 Operating system log files are monitored and regularly All
reviewed. Such logs can contain and are not limited to:
SLG.02 Operating system activity logs are stored on a remote All

system that cannot be accessed by the source operating
system privileged account or by the same individuals.
SLG.03 Log files are retained (safe-stored) for a least 12 months All
and are available for audits or forensic investigations.
08 November 2019 34
Security Guidance
SLG.04 The Windows administrator account is not a personal All

account. As such, there are procedures in place to:
• Identify the specific individual who is logged in to
such an account
• Log the commands run by this account
Operating System Hardening
OSH.01 The operating system and other software that are All
installed on the servers that host the AutoClient software
are configured according to the third-party vendor
recommendations and security baselines.
OSH.02 No other software is installed on AutoClient servers, All

except for the software needed to operate, monitor, and
secure the AutoClient software.
Security Updates
ID Control Product Created Date
SSP.01 The local infrastructure (such as operating system, All

software, and third-party software) is up to date with the
latest security updates.
SSP.02 Mandatory or recommended AutoClient releases or All

updates are installed on a timely basis, and for
mandatory releases, before the mandatory installation
date.
Security Software
IDS.01 Security software is installed and is up to date to protect All

against malicious software or other threats.
Any file sent to or received from AutoClient is scanned.
IDS.02 An internal integrity check on the software and All

configuration data is running in the AutoClient 1.3 and
later versions.
This feature is embedded within the AutoClient 1.3 and
later versions, so you are compliant with control 6.2
Software Integrity of the CSP roadshow if you operate
with one of these releases.
08 November 2019 35
Security Guidance
Secure Local Client Environment

Physical Access Control
ALP.01 Physical security controls are in place. They ensure that All
only authorised personnel can access the clients used
to connect to the Alliance Lite2 GUI.
ALL.01 Logical access controls are regularly reviewed. All

When employees change roles or leave the company,
their access rights are promptly modified.
ALL.02 Session locks are enforced: time-out after 15 minutes of All

inactivity (that is, if a session has been idle for more
than 15 minutes, the user will be required to re-
authenticate to re-activate the terminal or session).
Anti-virus and Anti-malware Services
ALM.01 Anti-virus and anti-malware services and their

associated databases are installed and up to date on
the client host infrastructure.
Security Updates
ALU.01 The client infrastructure is up to date with the latest All

security updates for the supported software versions.
08 November 2019 36
Security Guidance
Secure Browsing
ALB.01 The customer follows secure browsing practices, such Alliance Lite2
as: GUI
• Segregating general browsing from Alliance Lite2,
ideally by using different workstations.
• Ensuring that each user verifies the Alliance Lite2
server's TLS certificate authenticity during each login
to Alliance Lite2.
For more information, refer to the logging-in section
of the Alliance Lite2 User Guide.
• Not browsing sites other than Alliance Lite2 and
SWIFT WebAccess services when an Alliance Lite2
session is open.
• Restarting the browser instance before and after
accessing the Alliance Lite2 site.
• Never following links in e-mails that pretend to direct
the user to Alliance Lite2. Be suspicious of e-mails
that appear to come from SWIFT, and never provide
the token password if asked. SWIFT never asks for
any password in an e-mail or any other form of
communication.
• Ensuring security awareness for Alliance Lite2 end
users, developing and maintaining security focused
behaviour among end users, and ensuring that end
users are fully aware of threats related to browsing
(such as ensuring that user sessions cannot be
taken over).
Secure Application Environment

ALC.01 The "need-to-know", "least privilege", and "segregation All

of duties" principles are considered when defining
operators and operator profiles.
ALC.02 Dual authorisation is implemented for the most sensitive All

operations (message processing, RMA management,
and so on.).
The administrator and message approval roles are not
granted to the same individuals.
ALC.03 The “Msg_ALL” and “RMA_All” profiles are not assigned Alliance Lite2
to operators in the live production environment. These GUI
profiles can be used only for test purposes in the test
environment.
08 November 2019 37
Security Guidance
ALC.04 The application is configured in such a way that the AutoClient

transactions from AutoClient are manually approved on
the GUI before they are released to SWIFT.
This approach is highly recommended for STP (Straight
Through Processing) flows sent from back-office
applications, if LAU or other integrity mechanisms are
not in place.
ALC.05 Administrator-level operating system accounts are not All

used to run AutoClient, or the browser on the PC where
Alliance Lite2 is accessed/used.
ALC.06 Logical access controls are regularly reviewed for the All
profiles and users defined in Alliance Lite2.
When an employee changes roles or leaves the
company, or in the case of dormant users, their access
rights are promptly modified.
Confidentiality, Integrity, and Authentication
ALI.01 The integrity of files between the back-office application AutoClient

and AutoClient is protected.
This can be achieved using Local Authentication (LAU)
on AutoClient to ensure that all critical internal flows to
or from the AutoClient system are protected against
malicious changes, especially if the AutoClient files are
transferred through a network.
ALI.02 The exchange of files between the back-office AutoClient

application and AutoClient is protected using a security
mechanism that provides authentication.
This can be achieved using LAU.
ALI.03 The transport of files between the back office and the AutoClient
AutoClient is encrypted. This can be achieved by using
solutions such as SFTP.
USB Token
ALT.01 The USB token is securely stored when it is not in use. USB token
ALT.02 The USB token is not left unsupervised when it is in use. USB token
ALT.03 USB tokens are distributed and assigned only to USB token
authorised operators. An operators's token is revoked
upon changing jobs or leaving the company.
08 November 2019 38
Security Guidance
ALT.04 The user-defined USB token password must be USB token

sufficiently strong (password length, complexity,
renewal, and so on, as per policy). The password must
never be written down and must be known only to its
Channel Certificate
ACC.01 The user-defined channel certificate password must be Channel

sufficiently strong (password length, complexity, certificate
renewal, and so on, as per policy). The password must
never be written down and must be known only to its
ACC.02 Channel certificates are used with strict physical access Channel
control. certificate
Auditing and Monitoring
ALA.01 A process is in place to monitor traffic anomalies (for AutoClient and

example, transactions outside of normal business GUI
hours).
ALA.02 AutoClient log files are regularly reviewed. AutoClient
ALA.03 AutoClient log files are archived, safe-stored for a AutoClient

minimum period of 12 months, and available for audits
or forensic investigations.
Local Network Security

Connectivity
CON.01 If a local ISP is used to connect to the SWIFT Network, Alliance Lite2
there is additional protection in place against Denial of
Service (DoS).
08 November 2019 39
Security Guidance
Network Segregation
ALN.01 A firewall facing the public Internet is installed and AutoClient and
managed that does not accept any incoming Alliance Lite2
connections towards the systems used to access GUI
Alliance Lite2, and from unauthorised access over the
internal network.
The firewall must be both a physical one to restrict
incoming traffic, and a host-based one to ensure that
only authorised programs communicate on the network.
If an Alliance Connect solution is used to connect to
Alliance Lite2, you can ask SWIFT to disable public
Internet access for all your users, only allowing access
through SWIFT's Virtual Private Network.
ALN.02 Outgoing traffic is restricted from systems used to AutoClient and

access Alliance Lite2 to business-critical sites, such as Alliance Lite2
legitimate sites required for software updates. GUI
ALN.03 Strong firewall rules are in place between the servers AutoClient
running AutoClient software and the back-office
applications.
ALN.04 Strong firewall rules are in place to restrict remote login AutoClient
or access from your office automation LAN to the
servers running AutoClient software.
ALN.05 A Jump Server is used for access to management All

services through untrusted networks is prohibited.
ALN.06 The firewall rules and policies are regularly reviewed. All
ALN.07 The firewall logs are monitored. All
Other Security Recommendations

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

authorisation record once a business relationship has GUI
been stopped.
RMA.02 A procedure is in place to review on a regular basis your Alliance Lite2

RMA authorisation records. GUI
RMA.03 A procedure/workflow exists within the business teams Alliance Lite2

to initiate an RMA authorisation creation request to the GUI
RMA operators when a new business relationship over
SWIFT has been established. This request is logged.
08 November 2019 40
Security Guidance
Detection Mechanism - Reconciliation
REC.01 Perform a reconciliation between the messages that are All

sent to/from the back office and to/from the SWIFT
Network.
Detection Mechanism - Abnormal Sessions and Message Flows
ASM.01 A check is performed to detect abnormal sessions and All

message flows by means of tools, or manual checks
based on the MT081/Message File.
Resilience and Backup
SBS.01 Backups of data and software are made frequently. The AutoClient
backup policy and procedures are documented. The
process to restore backups is documented and is tested
periodically.
SBS.03 IT continuity plans for Alliance Lite2 are documented, AutoClient

tested, and updated regularly to ensure that they are up
to date and effective. Testing of continuity plans and
related procedures for the restoration of business
activity is performed at least annually. For more
information, see Glossary on page 43.
SBS.0x Sensitive SWIFT-related data leaving the secure zone AutoClient

as a result of backups, data replication for recovery, or
further off-line processing is encrypted.
08 November 2019 41
Security Guidance
User Security Awareness
UAW.01 Annual security awareness sessions are conducted for All

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 or
certifications)
Incident Management
IMA.01 The customer has a sound and tested cyber security All
incident management process that includes information
on who to contact, which channels to use, and under
what conditions to use them.
IMA.02 If a critical security incident is detected within the All

environment, the server running AutoClient is
immediately isolated and SWIFT is informed
accordingly.
08 November 2019 42
Alliance Lite2 Glossary
Security Guidance
7 Glossary
Security term Definition
Auditability Every user of a system should be held accountable for their activities. This implies that
all actions can be audited, meaning that all relevant actions can be monitored, and that
any single action can be uniquely attributed to a known user, at a particular time and
date.
Availability The term availability implies that both the information and the systems used, for
example, to process, display, and print information 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.
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.
Demilitarised zone A demilitarised zone is a physical or logical subnetwork that contains and exposes an
(DMZ) organisation's external-facing services to a larger and untrusted network, usually the
Internet. The purpose of a DMZ is to add an additional layer of security to an
organisation's local area network (LAN). An external network node can access only
what is exposed in the DMZ, while the rest of the organisation's network is firewalled.
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.
IT continuity plans IT continuity plans include the planning and strategy for recovering IT (and other
technical) systems after an incident or disaster, in order to minimise the effects and to
maintain or quickly resume mission-critical functions.
Web application A web application firewall is a firewall that filters, monitors, and blocks HTTP/S traffic to
firewall (WAF) and from a web application. A WAF differs from a regular firewall in that a WAF is able
to filter the content of specific web applications while regular firewalls serve as a safety
gate between servers. A WAF has the ability to filter and monitor for specific web
applications.
The following principles assist in ensuring the foundation of a secure system:
08 November 2019 43
Alliance Lite2 Glossary
Security Guidance
Security principle Definition
Need-to-know Information and resources should be made available strictly on a need-to-know or

need-to-have basis.
System set-up must ensure that operators only have access to the information, files,
and system resources necessary for their defined tasks. Access to other system
functions must be disabled.
Least privilege Users must only be granted the minimum level of privileges required for them to
perform their defined tasks.
System set-up must ensure that operator privileges are controlled in a way that 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 set-up must ensure that non-required applications, software, or tools are
removed.
Accountability All user activity, such as access attempts and command usage, must be logged and
attributed to a known user.
Ideally, system activity (such as information about processes, network events, and
system errors) should also be logged.
08 November 2019 44
Alliance Lite2 Legal Notices
Security Guidance
Legal Notices
Copyright
SWIFT © 2019. All rights reserved.
Confidentiality
This publication contains SWIFT or third-party confidential information. Do not disclose this
publication outside your organisation without SWIFT’s prior written consent.
Disclaimer
SWIFT supplies this publication for information purposes only. The information in this publication
may change from time to time. You must always refer to the latest available version on
www.swift.com.
This document includes general guidelines or recommendations or interpretation of data.
Customers are solely and exclusively responsible for deciding any particular course of action or
omission and for implementing any actions or taking any decision based on the information in this
document. SWIFT disclaims all liability with regards to such actions or decisions and their
consequences. Nothing in this document shall be interpreted or construed as constituting any
obligation, representation or warranty on the part of SWIFT.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. 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.
08 November 2019 45

Al2 Sec Guid PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Al2 Sec Guid PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Alliance Lite2

3 Key Security Aspects of Alliance Lite2................................................................................................. 7

4 Security Best Practices and SWIFT Security Recommendations.....................................................12

6 Security Controls Checklist..................................................................................................................31

What is Alliance Lite2?

Alliance Lite2 security features

Generic customer security infrastructure

2.1 Customer Responsibilities

In particular, the customer must ensure that it:

3 Key Security Aspects of Alliance Lite2

3.1 Connection to SWIFTNet

3.2 SWIFT WebAccess

Services accessible through SWIFT WebAccess

3.3 Alliance Lite2 Central Infrastructure

Browser AutoClient Internet or Alliance Lite2 All SWIFTNet flows Financial

Alliance Lite2 Network SWIFT SWIFT Network SWIFT Community

3.4 Connectivity and Encryption

3.4.1 Connection Security

Additional security measures

3.4.2 Advantages of Alliance Connect

3.5 PKI-based Security

3.5.1 Token-based Certificates

3.5.2 Channel Certificates

3.5.3 SWIFT Certificate Centre

3.6 Alliance Lite2 Customer Security Officer Role

4 Security Best Practices and SWIFT Security

4.1 SWIFT Security Governance for Customers

4.1.1 Alliance Lite2 Customer Security Officers

These security officers are mainly responsible for:

Online and offline tools for Customer Security Officers

Tool Type of tool Customer Security Officer scope

4.1.2 swift.com Administrators

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

4.2 Secure Local Server Environment

4.2.1 Physical Access Control

4.2.2 Logical Access Control

SLA.01 Careful consideration is given to whom is assigned the role of All

SLA.02 Employees with access to administrator accounts or application owner All

SLA.05 Employees with access to administrator accounts or application owner All

SLA.08 Logical access controls are regularly reviewed. All

4.2.3 Operating System Activity Logging

4.2.4 Operating System Hardening

4.2.5 Security Updates

SSP.02 Mandatory or recommended AutoClient releases or updates are installed All

4.2.6 Security Software

4.3 Secure Local Client Environment

4.3.1 Physical Access Control

4.3.2 Logical Access Control

ALL.01 Logical access controls are regularly reviewed. All

4.3.3 Anti-virus and Anti-malware Services

4.3.4 Security Updates

4.3.5 Secure Browsing

4.4 Secure Application Environment

4.4.1 Logical Access Control

ALC.01 The "need-to-know", "least privilege", and "segregation of duties" All

4.4.2 Confidentiality, Integrity, and Authentication

4.4.3 USB Token

4.4.4 Channel Certificate

4.4.5 Auditing and Monitoring

ALA.02 AutoClient log files are regularly reviewed. AutoClient

4.5 Local Network Security

4.5.2 Network Segregation

ALN.07 The firewall logs are monitored. All