Professional Documents
Culture Documents
Al2 Sec Guid PDF
Al2 Sec Guid PDF
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
5 Addressing Vulnerabilities................................................................................................................... 29
5.1 Threats and Attacks...............................................................................................................................29
5.2 Addressing Security Threats................................................................................................................. 29
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.
08 November 2019 4
Alliance Lite2 Introduction
Security Guidance
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
Alliance Lite2 Introduction
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
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.
08 November 2019 7
Alliance Lite2 Key Security Aspects of Alliance Lite2
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.
AutoClient
or Direct Link
USB token Alliance Lite2
or channel certificate
Connection Server
to SWIFT
Secure workflow
USB token
SWIFTNet Interface
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
Alliance Lite2 Key Security Aspects of Alliance Lite2
Security Guidance
08 November 2019 9
Alliance Lite2 Key Security Aspects of Alliance Lite2
Security Guidance
08 November 2019 10
Alliance Lite2 Key Security Aspects of Alliance Lite2
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.
08 November 2019 11
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
Security Guidance
08 November 2019 12
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
Security Guidance
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
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
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.
ID Control Product
08 November 2019 14
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
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
08 November 2019 15
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
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.
ID Control Product
08 November 2019 16
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
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.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.
08 November 2019 17
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
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.
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.
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
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
Security Guidance
ID Control Product
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.
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.
08 November 2019 19
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
Security Guidance
ID Control Product
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).
Sessions are not left open unattended.
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.
ID Control Product
ALU.01 The client infrastructure is up to date with the latest security updates for All
the supported software versions.
08 November 2019 20
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
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).
08 November 2019 21
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
Security Guidance
ID Control Product
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.
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
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
Security Guidance
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.
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
intended authorised user.
ACC.02 Channel certificates are used with strict physical access control. Channel certificate
08 November 2019 23
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
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.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.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
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
Security Guidance
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
08 November 2019 25
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
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.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.
08 November 2019 26
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
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.
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
Alliance Lite2 Security Best Practices and SWIFT Security Recommendations
Security Guidance
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)
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.
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.
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
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
08 November 2019 30
Alliance Lite2 Security Controls Checklist
Security Guidance
ALQ.02 The left and right Customer Security Officers are two All
independent individuals, with independent backups
identified in case of their absence.
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.
swift.com administrators
08 November 2019 31
Alliance Lite2 Security Controls Checklist
Security Guidance
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.
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.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
Alliance Lite2 Security Controls Checklist
Security Guidance
08 November 2019 33
Alliance Lite2 Security Controls Checklist
Security Guidance
SLG.01 Operating system log files are monitored and regularly All
reviewed. Such logs can contain and are not limited to:
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
Alliance Lite2 Security Controls Checklist
Security Guidance
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.
Security Updates
Security Software
08 November 2019 35
Alliance Lite2 Security Controls Checklist
Security Guidance
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.
Security Updates
08 November 2019 36
Alliance Lite2 Security Controls Checklist
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).
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
Alliance Lite2 Security Controls Checklist
Security Guidance
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.
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
Alliance Lite2 Security Controls Checklist
Security Guidance
Channel Certificate
ACC.02 Channel certificates are used with strict physical access Channel
control. certificate
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
Alliance Lite2 Security Controls Checklist
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.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.06 The firewall rules and policies are regularly reviewed. All
08 November 2019 40
Alliance Lite2 Security Controls Checklist
Security Guidance
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.
08 November 2019 41
Alliance Lite2 Security Controls Checklist
Security Guidance
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.
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.
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.
08 November 2019 43
Alliance Lite2 Glossary
Security Guidance
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.
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