Alliance Lite2

Security White Paper

This security white paper provides a high-level description of Alliance Lite2 from a security perspective. This paper is for
SWIFT infrastructure administrators, security specialists, and auditors.
11 October 2013

Connectivity
Table of Contents
.Preface .............................................................................................................................................................................3
1 Introduction ....................................................................................................................................................... 4
2 Overview of Alliance Lite2 .......................................................................................................................... 5
2.1 Background and Business Context ........................................................................................................ 5
2.2 Governance ................................................................................................................................................ 6
3 Alliance Lite2 Key Security Aspects ...................................................................................................... 7
3.1 Direct Connection to SWIFTNet ............................................................................................................. 7
3.2 Browse ........................................................................................................................................................ 8
3.3 Central Infrastructure ................................................................................................................................ 9
3.4 Connectivity and Encryption .................................................................................................................. 10
3.5 PKI-based Security ................................................................................................................................. 10
3.6 Protection of Customer Information ..................................................................................................... 12
3.7 Additional Features ................................................................................................................................. 12
4 Building on Top of Customer's Security Infrastructure .............................................................. 13
4.1 Secure Environment ............................................................................................................................... 13
4.2 Secure Browsing Practices .................................................................................................................... 14
4.3 Secure Application .................................................................................................................................. 14
4.4 Secure Usage .......................................................................................................................................... 15
5 Addressing Threats ..................................................................................................................................... 17
5.1 Threats and Attacks ................................................................................................................................ 17
5.2 Security Threats ...................................................................................................................................... 17
5.3 DOs and DON'Ts .................................................................................................................................... 19
6 Glossary ............................................................................................................................................................ 21
.Legal Notices ...............................................................................................................................................................22
Alliance Lite2
2 Security White Paper
Preface
Purpose of the document
This security white paper provides a high-level description of Alliance Lite2 from a security
perspective.
Audience
This document is for the following audience:
SWIFT infrastructure administrators
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. This document is supplied for information purposes only. The
information in this paper may be superseded as a result of subsequent changes to Alliance
Lite2.
Significant changes
This version of the Security White Paper introduces the following changes:
New information Location
Channel certificate "Channel Certificates" on page 11
Connectivity and Encryption "Connectivity and Encryption" on page 10
PKI-based Security "PKI-based Security" on page 10
Related documentation
Alliance Lite2 Service Description
Alliance Lite2 Administration Guide
AutoClient Installation and User Guide
Preface
11 October 2013 3
1 Introduction
What is Alliance Lite2?
In the context of Alliance Lite2, SWIFT operates a central infrastructure that is directly
connected to SWIFTNet, and also provides an application server. Customers can connect to the
application server over the Internet or over the SWIFT secure IP network (SIPN) using Alliance
Connect VPN boxes.
SWIFTNet customers see Alliance Lite2 customers as no different from other customers who
use a direct connection to SWIFTNet. 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 provides the following security features:
two-factor authentication using 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 (4 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 security infrastructure
A generic security infrastructure that is exposed to the Internet must include firewalls, web
content filtering, anti-virus software, anti-malware software, as well as customer awareness and
practices. When connected to SWIFTNet through the Internet, the user's computer may be
directly exposed to Internet threats. Therefore, just like any other internet-connected user,
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.
Alliance Lite2
4 Security White Paper
2 Overview of Alliance Lite2
2.1 Background and Business Context
Service definition
Alliance Lite2 is a SWIFT service that provides easy, secure, and cost-effective access to
SWIFTNet. It is an evolution of the SWIFT Alliance Lite service. This service is complementary
to other, existing models that provide connectivity to SWIFT today, such as on-premises access
or service bureaux. The Alliance Lite2 service allows you to manually create and approve
messages. It also provides the capability of uploading and downloading files and messages
automatically.
D
1
3
7
0
0
0
5
SWIFTNet flows
Financial
Institutions
Alliance Lite2
Central Infrastructure
SWIFTNet Interface
Secure workflow
Secure server
AutoClient
Customer premises
Browser Interface
Network SWIFT Operating Centres
SWIFT
Community
SIPN
Internet
AND / OR AND / OR
VPN
box
From a security perspective, Alliance Lite2 shares many similarities with the current service
bureau access model:
Alliance Lite2 is a service from SWIFT that provides easy, secure, and low-cost access to
SWIFTNet.
Alliance Lite2 is easy to order, requires a limited amount of configuration changes, and is
easy to use.
Alliance Lite2 reduces the total cost of ownership (TCO) by reducing dramatically the
software footprint for Alliance users and by proposing a new pricing model.
Alliance Lite2 further reduces the TCO by building on customer security infrastructure and
security practices.
Alliance Lite2 supports manual operations through a browser-based screens. It also supports
integration with back-office applications through lightweight software called AutoClient, which
is used for automated file transfers.
Alliance Lite2 usage is transparent for customers that connect to SWIFTNet through direct
connection. Messages and files to or from Alliance Lite2 customers do not require any update
to the existing SWIFTNet infrastructure of the customer or their contractual agreements with
SWIFT.
For information about direct connection, see "Direct Connection to SWIFTNet" on page 7.
Overview of Alliance Lite2
11 October 2013 5
2.2 Governance
Definition
The Alliance Lite2 central infrastructure is built using industry-strength processes that help to
ensure best-in-class quality, security, and reliability: development life-cycle processes and
operational processes ensure that security and availability are built in right from the start.
To a large extent, these are the same processes used by SWIFT to deliver the FIN and
SWIFTNet services on which the global financial community relies on a daily basis. While
Alliance Lite2 is currently not in scope of SWIFT's ISAE 3402 Type 2 report, the processes
referred to are the same. These processes include physical and logical controls of the
operational environment, operational procedures, secure coding, change management, problem
management, and incident management. Therefore, Alliance Lite2 users can derive assurance
from the ISAE 3402 report to a certain extent.
The development process at SWIFT requires independent verification of quality and security.
Rigorous testing ensures quality and conformance with requirements including security
requirements. In addition, with a risk-based periodicity, SWIFT performs intrusion tests to
identify potential vulnerabilities in the off-the-shelf technology, customised software, or in-house
developed code that is used to build the Alliance products. This covers operating system,
middleware, network device, and application level vulnerabilities. Finally, Alliance Lite2 and all
its underlying processes are subject to SWIFT internal audit, and are periodically reviewed in
depth.
Alliance Lite2
6 Security White Paper
3 Alliance Lite2 Key Security Aspects
3.1 Direct Connection to SWIFTNet
Direct connection
D
1
3
7
0
0
0
6
Alliance Lite2
Customer
premises
SIPN
VPN
box
Network
Alliance
Access
Gateway
HSM
Alliance
Lite2
front-end
SWIFTNet
Messaging
SWIFT Operating Centres
SIPN
Financial
institutions
AND / OR
Internet
Alliance Lite2 is a way to connect to SWIFTNet. Alliance Lite2 does not affect the existing
security aspects of SWIFTNet. Customers that have a direct connection do not notice whether
their counterparts use Alliance Lite2.
PKI certificates
Like any other SWIFTNet customer, customers who access SWIFTNet through Alliance Lite2
are identified on SWIFTNet by standard SWIFTNet PKI certificates that are associated with their
BIC8. All SWIFTNet messages initiated by or intended for Alliance Lite2 are signed like any
message exchanged with SWIFTNet customers who use a direct connection. RMA
authorisation messages must also be exchanged with Alliance Lite2 customers when required
(such as on the FIN service).
The existing contractual framework for SWIFTNet messaging services, including liability,
continues to apply for messages exchanged between SWIFTNet customers who use a direct
connection or with Alliance Lite2 customers.
Customers can find more information about connection methods in the SWIFTNet 7.0 Service
Description.
Alliance Lite2 Key Security Aspects
11 October 2013 7
Contractual framework
Alliance Lite2 customers enter into a specific contractual framework with SWIFT. This
framework defines the specific roles and responsibilities of the parties.
For example, Alliance Lite2 customers are responsible for the following:
all signed messages sent to the Alliance Lite2 central infrastructure (and forwarded over
SWIFTNet)
downloading and, as applicable, acting upon SWIFTNet messages
3.2 Browse
What is Browse?
Browse 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
secure IP network and SWIFTNet. Browse is only for person-to-application use.
Services accessible through Browse
Alliance Lite2 offers access to the following Browse services to users who connect from a user's
desktop with a USB token provided by SWIFT or with a channel certificate :
Function Description
SWIFTNet Online Operations
Manager
Use the SWIFTNet Online Operations Manager to administer
the security and the routing through a SWIFT-managed
service available over Browse.
Other Browse services Connect to any other Browse service that Alliance Lite2
supports and to which the customer has subscribed.
Swift Certificate Centre
Alliance Lite2 also allows access to the SWIFT Certificate Centre on swift.com to manage PKI
certificates and their PKI credentials. Use the SWIFT Certificate Centre to activate tokens,
change the password that protects them, and to perform other token management operations.
Alliance Lite2
8 Security White Paper
3.3 Central Infrastructure
Overview
The Alliance Lite2 service provides access to SWIFTNet messaging services.
D
1
3
7
0
0
0
7
Customer
premises
AND / OR
SIPN
Network
VPN
box
SWIFTNet
Central
Infrastructure
Alliance Lite2 Central Infrastructure
S
i
t
e

2
S
i
t
e

1
Proxy
SWIFT Operating Centres
Proxy
Alliance
Access
Gateway
Alliance
Access
Gateway
Alliance
Lite2
front-end
Alliance
Lite2
front-end
Messaging
Internet
Note Currently only Site1 is operational.
SWIFT operates the Alliance Lite2 central infrastructure that implements the systems and
procedures that SWIFTNet customers with a direct connection normally use. This infrastructure
consists of a set of resilient hosts that implement a SWIFTNet configuration that uses the direct
connection method, and include Alliance Web Platform, Alliance Access, Alliance Gateway, and
SWIFTNet Link. Additionally, SWIFT has implemented an Internet-facing set of resilient systems
such as DMZ, reverse proxies, and web application servers. These systems support internet-
based access to the Alliance Lite2 central infrastructure. These systems are protected by a set
of in-depth defence controls, in line with industry practices.
Alliance Lite2 access to SWIFTNet does not introduce additional threats on the SWIFTNet
infrastructure itself. The Alliance Lite2 central infrastructure connects to SWIFTNet in a manner
equivalent to how other SWIFTNet customers connect to SWIFTNet, using components such as
Alliance Access, Alliance Gateway, SWIFTNet Link and HSM. To protect SWIFTNet and
SWIFTNet customers with a direct connection, specific protections against additional threats
introduced through Internet exposure (for example, distributed DoS, hackers) are built into the
Alliance Lite2 central infrastructure.
The Alliance Lite2 Infrastructure is implemented within a SWIFT operating centre (OPC). All
operational controls are similar to those that are used to provide the FIN service.
For more information about connection methods, see the SWIFTNet 7.0 Service Description.
Alliance Lite2 Key Security Aspects
11 October 2013 9
3.4 Connectivity and Encryption
Connecting to SWIFTNet
Customers connect to SWIFTNet over the secure IP network using Alliance Connect VPN
boxes or over the Internet.
3.4.1 Connection Security
Standard security measures
The connection between AutoClient and the SWIFT infrastructure deployed at the SWIFT
operating centre is secured with two-way SSL encryption (SSL v3.0/TLS v1.0) with a strong
encryption algorithm. An AutoClient uses token-based certificates (Windows only) or channel
certificates (all platforms) to establish a connection with the SWIFT infrastructure deployed at
the SWIFT operating centre, and to sign business messages and files for non-repudiation.
Additional security measures
In addition to the Secure Socket Layer security, Alliance Connect solutions support encryption
at the network layer. This option is mandatory for the use of channel certificates. For product
information, see "Alliance Connect Advantages" on page 10.
3.4.2 Alliance Connect Advantages
Network level security
The Alliance Connect VPN box cluster makes use of a proven mechanism that secures the
creation of a secure channel over the SWIFT network partner backbones or the Internet. This
channel uses Internet Protocol Security (IPsec) technology, which preserves the security of the
data that users 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 backbone access points.
IPsec is an end-to-end security solution that operates at the internet layer of the Internet
Protocol Suite, which is comparable to 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
3.5 PKI-based Security
Personal Key Infrastructure
Each Alliance Lite2 user or application 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 SWIFTNet. Only this identity is visible to other
SWIFTNet customers.
Alliance Lite2
10 Security White Paper
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.
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 specific Alliance
Lite2 identities.
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.
3.5.1 Token-based Certificates
Concept
A token-based certificate is a certificate that resides on a personal token.
A personal token, also called 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. The Alliance Lite2
user or application is authenticated through a 2048-bits PKI private key that is generated at
customer premises. This PKI credential is protected in the USB token and never leaves the
token. This is a FIPS 140-2, level 2 (or above), USB token. The USB token itself uses the
private PKI key to sign the most sensitive operations created by the user and sent to Alliance
Lite2 central infrastructure. The user must provide a password to use the USB token, once it is
activated. Multiple consecutive failed password attempts lock the USB token. 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. Alliance Lite2 supports personal tokens on Windows systems
only.
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.
Message exchanges are subject to non-repudiation of emission. Non-repudiation is based on
the PKI signature generated by the local USB token.
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 is required for browser-based access and to
Alliance Lite2.
3.5.2 Channel Certificates
Concept
A channel certificate is an encrypted, disk-based profile file that provides a means for SWIFT to
authenticate the identity of an application. The Alliance Lite2 application is authenticated
through a 2048-bits PKI private key that is generated at customer premises. Alliance Lite2
supports channel certificates as an alternative means to physical tokens for securing the
connection between AutoClient at customers' premises and SWIFT, and to allow non-
repudiation of signatures. Alliance Lite2 supports channel certificates on Windows, yet channel
certificates mandate the use of MV-SIPN connectivity. In addition, channel certificates are not
permitted for human-to-application flow, such as Browse services.
AutoClient uses channel certificates to establish the SSL connection and to sign requests for
non-repudiation. To prevent misuse of channel certificates, SWIFT ensures that channel
Alliance Lite2 Key Security Aspects
11 October 2013 11
certificates cannot be used outside the institution against which they are registered. To this
effect SWIFT verifies that the BIC8 of the channel certificate used matches with the VPN box of
the institution.
Message exchanges are subject to non-repudiation of emission. Non-repudiation is based on
the PKI signature generated by this channel certificate. This evidence is used in the context of a
dispute resolution between the Alliance Lite2 customer and SWIFT.
3.6 Protection of Customer Information
Message storage
SWIFT guarantees to European customers that, for intra-European traffic, their message and
file request data will be processed and stored in Europe only.
SWIFT may retrieve, use, and disclose traffic or message data from these Alliance Lite2 servers
only in any of the following circumstances:
when required for the provisioning of Alliance Lite2, as documented in the relevant SWIFT
contractual documentation
when permitted by the SWIFT Data Retrieval Policy
This does not affect any retrieval, use, and disclosure of traffic or message data of the Alliance
Lite2 customer as part of any other SWIFT services and products accessed through Alliance
Lite2 (for example, FIN or FileAct in a many-to-many environment, in a Member-Administered
Closed User Group or in SCORE), as permitted under the relevant contractual documentation.
3.7 Additional Features
3.7.1 Alliance Lite2 Security Officer Role
Role
The Alliance Lite2 administrator role provides access to a set of security management functions
that allow you to perform tasks like managing users, restricting counterparties, and managing
PKI credentials.
More specifically, these functions include:
creation and deletion of users (for example when a user changes role or leaves the
company)
key renewal: This is performed manually every two years for each USB token
key revocation, in case of lost USB token
allocation of entitlements to end users
management of whitelist of business accounts using RMA
Optionally, the user of maximum amount usable during message creation and approval
Alliance Lite2
12 Security White Paper
4 Building on Top of Customer's Security
Infrastructure
Introduction
To reduce total cost of ownership and to leverage use of existing customer infrastructure,
Alliance Lite2 builds on security practices established by the customer.
These security practices must be in line with industry security practices and typically include the
measures listed in this section.
4.1 Secure Environment
The customer must take the following security measures in line with the industry security
practices.
Operating system hardening
Harden the system used to access Alliance Lite2 and only install authorised and required
software or applications.
Firewall and web content filtering components
Manage firewall and web content filtering components facing the Internet. This firewall must not
allow any incoming connections towards the system used to access Alliance Lite2.
Antivirus, anti-malware services
Use up-to-date anti-virus software, anti-malware services, and associated up-to-date virus and
malware databases to protect the system from infection.
Security patches
Ensure that all infrastructure and components are updated with the latest security patches.
Physical and network access management
Protect the Alliance Lite2 from unauthorised physical and network access. The Alliance Lite2
user must use a firewall to shield the server from incoming Internet traffic, and from
unauthorised access over the internal network. The firewall must be both a physical one to
protect incoming traffic, and a PC-local one to ensure that only authorised programs
communicate with the outside.
Permission management
Ensure that only the people with the required permissions have physical and logical access to
the Alliance Access or Alliance Entry machine that contains the RACG component, and to the
backups.
Network-level segregation
Consider the secure IP network Alliance Connect product to help implement a strict segregation
at network level.
Building on Top of Customer's Security Infrastructure
11 October 2013 13
4.2 Secure Browsing Practices
Guidelines
The customer must ensure that their institution's users follow secure browsing practices. The
following list is not exhaustive:
Segregate general browsing from critical browsing either by using a different Windows
account, a different browser, or, ideally, by using different PCs.
Do not browse to other sites than Alliance Lite2 when an Alliance Lite2 session is open.
Never follow any suspicious links (for example, links in e-mails or other documents),
especially those pretending to direct 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 a
token password in an e-mail.
Raise security awareness for Alliance Lite2 users. Invest in the development and the
maintenance of secure-minded user behaviour and ensure that users are fully aware of the
threats related to Internet browsing.
4.3 Secure Application
Introduction
SWIFT offers key additional security features to help customers build a fully secure access to
Alliance Lite2.
Customer registration
Only registered customers can connect: customer registration on Alliance Lite2 is subject to the
same rules as on SWIFTNet.
SSL tunnel
Access to Alliance Lite2 is based on a mutual authenticated SSL v3.0 /TLS v1.0 connection
(also known as two-way SSL). The client-side and server-side certificates are issued by the
SWIFTNet PKI certificate authority.
Password protected USB token
Access to Alliance Lite2 requires the use of a password-protected USB token. This USB token
contains a PKI private key required to sign all business critical operations. Such access can also
be performed through MV-SIPN by using a VPN box FIPS 140-2 level2 and a channel
certificate.
Dual authorisation procedure
Pre-defined operator profiles enable dual authorisation through segregation of duties between
administrator, approver, and message entry functions.
User access restriction
Alliance Lite2 administrator can restrict user access to white-listed bank accounts as well as to
limit the allowed maximum amount per day.
Alliance Lite2
14 Security White Paper
Session mechanism with strong security setup
Use session mechanism with strong security setup (no local storage, limited life time, non-
deterministic, and so on).
Use of Local Authentication
Use local authentication (LAU) on AutoClient to ensure that all critical internal flows to or from
the AutoClient PC are protected against malicious changes, especially if the AutoClient files are
transferred through a network.
For more information about those options, see the Alliance Lite2 Service Description, section
"Security Features".
4.4 Secure Usage
Introduction
Consider implementing additional practices in the following categories.
Certificate use
Ensure that each user verifies the Alliance Lite2 server's SSL certificate authenticity during each
login to Alliance Lite2, as described in the Alliance Lite2 User Guide, section "Log in to Alliance
Lite2".
Implementation of dual authorisation
Implement dual authorisation for the most sensitive operations. Dual authorisation must be
implemented by Alliance Lite2 customers. This can be realised by relying on different people
that operate from different PCs, ideally.
White list of accounts and maximum account limit
Explicitly white list the business accounts, and possible maximum amounts, that are needed
when using Alliance Lite2.
Traffic reconciliation
Reconcile daily traffic for detecting any mismatch between authorised versus actual traffic (sent
or received).
Access management and account management
Implement access, account management, and segregation of duties to ensure that only required
people have access to the system and tokens used for Alliance Lite2.
Protection of the USB token
Physically protect the USB token, even when not used. When not in use, place the USB token
in a safe that is accessible only by authorised staff. While it is used, ensure that the USB token
is under the supervision of the authorised person.
USB token password policy
Ensure that the user-defined USB token password is sufficiently strong (password length,
complexity, renewal, and so on). The password must never be written down and must be known
only to its intended authorised user.
Building on Top of Customer's Security Infrastructure
11 October 2013 15
User management
Establish user management practices to ensure that only authorised users are defined on the
system. When users change roles or leave the company, the customer must update the list of
authorised users.
Alliance Lite2
16 Security White Paper
5 Addressing Threats
Introduction
When deploying the Alliance Lite2 application in an institution, customers must be aware of the
threats that they may be facing as well as how to address them.
This section gives an overview of typical threats and attacks, and summarises the security
features and controls available to reduce their likelihood, as well as to limit the impact of
successful attacks.
5.1 Threats and Attacks
Impersonation
Any web-based application is exposed to attacks that must be considered when a customer
deploys Alliance Lite2. The attacks that must be considered include user impersonation, which
affects confidentiality and integrity.
Currently, the most popular impersonation techniques that attackers use are as follows:
Spyware - The installation of hardware or software, usually by an unsuspecting user, on the
client system to get credentials, to perform further attacks.
Phishing - Creating a replica of an existing login page to fool the user so as to capture
financial information, or credential data (for example, password).
Sniffing - The ability to view network traffic and to steal credentials, confidential information,
or other sensitive data.
Man-in-the-middle - The attack occurs when the attacker intercepts a message sent between
the browser and the web application. The attacker then changes the message and forwards it
to the web application. The web application receives the message, trusts the message as
coming from the genuine user, and acts on it. When the web application sends a message
back, the attacker intercepts it, alters it, and returns it to the browser. Neither the browser nor
the web application knows that they have been attacked.
Man-in-the-browser - a form of threat related to the man-in-the-middle impersonation
technique. This technique uses a proxy Trojan horse that infects a web browser by taking
advantage of vulnerabilities in browser security to modify web pages, modify transaction
content, or insert additional transactions, all in a completely covert fashion, invisible to both
the user and host web application.
For all impersonation attacks, the highest impact is always on the highest user privilege. As a
consequence, the best way to limit the impact is to have application authorisations implemented
with the Need-to-know and Least privilege principles in mind. In addition, traceability of user
actions plays an important role in limiting the impact of malicious acts.
5.2 Security Threats
Threats table
The following table lists typical threats that the end user would encounter when using the
Internet. This table also provides some suggestions to mitigate these threats.
Addressing Threats
11 October 2013 17
Threat Typical attack Alliance Lite2 response User responsibility
Theft of
password
session or
private key (for
example,
spyware)
Session
guessing
Shoulder surfing
Key logger/
Spyware
Copy file
containing
private key
Phishing
Cross site
scripting
See "Session mechanism
with strong security setup" on
page 15.
See "Password protected
USB token" on page 14.
See "SSL tunnel" on page
14.
PKI Signing critical
operations. See "Password
protected USB token" on
page 14.
See "Access management
and account management"
on page 15.
See "USB token password
policy" on page 15.
Protection of the system
used for Alliance Lite2. See
"Secure Environment" on
page 13.
See "Protection of the USB
token" on page 15.
See "Secure Browsing
Practices" on page 14.
Manually checking SSL
certificate at login time. See
"Certificate use" on page 15.
Data
eavesdropping
(through
phishing or traffic
sniffing)
Phishing
Traffic
sniffing
See "SSL tunnel" on page 14. Manually checking SSL
certificate at login time. See
"Certificate use" on page 15.
Man-in-the-
middle attack
Phishing
Modifying an
operation
Injecting a
rogue
operation
SSL tunnel with mutual
authentication. See "SSL
tunnel" on page 14.
PKI signing critical
operations. See "Password
protected USB token" on
page 14.
See "Dual authorisation
procedure" on page 14.
See "Secure Browsing
Practices" on page 14.
Manually checking SSL
certificate at login time. See
"Certificate use" on page 15.
Activating and using dual
authorisation and
segregation of duty
procedures. See
"Implementation of dual
authorisation" on page 15.
Alliance Lite2
18 Security White Paper
Threat Typical attack Alliance Lite2 response User responsibility
Man-in-the-
browser attack
Malware infects
a PC after
visiting a rogue
site.
Local creation of
a rogue
operation
Cross-Site
Request Forgery
PKI Signing critical
operations. See "Password
protected USB token" on
page 14.
See "Dual authorisation
procedure" on page 14.
See "Secure Browsing
Practices" on page 14.
Logical protection of system
used for Alliance Lite2.
"Operating system
hardening" on page 13
"Firewall and web content
filtering components" on
page 13
Anti-Virus and Malware
counter measures. See
"Antivirus, anti-malware
services" on page 13.
Patching practices. See
"Security patches" on page
13.
Activating and using dual
authorisation and
segregation of duty
procedures. See
"Implementation of dual
authorisation" on page 15.
See "White list of accounts
and maximum account limit"
on page 15.
See "Traffic reconciliation"
on page 15.
5.3 DOs and DON'Ts
Introduction
This section lists typical DOs and DONT's that SWIFT recommends to Alliance Lite2 users.
However, these lists are not exhaustive and Alliance Lite2 users must implement
complementary security measures where and when justified by their own security risk analysis.
DO
Install and manage a firewall facing the Internet that does not accept any incoming
connections towards the Alliance Lite2 host.
Install and manage a local firewall on each PC where you run Alliance Lite2, as well as anti-
virus/anti-malware, and continuously leave these programs active and updated.
Restrict outgoing traffic from the PC to business-critical sites (on top of legitimate sites
required for software updates).
Addressing Threats
11 October 2013 19
Ensure that the PC used for accessing Alliance Lite2 is physically and logically accessible
only by persons who are entitled to access this PC.
Ensure that only authorised and required software is installed on the PC used to access
Alliance Lite2.
Ensure that all of the software running on the PC is regularly updated and patched including
Windows, Internet browser, the additional features (called plug-ins) such as Shockwave,
QuickTime, RealPlayer, and many others.
Ensure that each active USB token is safe-stored when not used.
Enforce user management practices that ensure that only authorised users are created and
that the list of authorised users is kept up-to-date as users change roles or leave the
company.
Implement entitlement management practices that ensure that users are only granted access
to Alliance Lite2 functions on a need to know or need to have principle. As an example, use
the capability to white list bank accounts and set a limit of max amount.
Assign two different authorising persons, who ideally use two different PCs, for the validation
and approval of outgoing messages and other critical operations, such as user management,
entitlement management, and PKI management.
Have two different authorised persons, who ideally use two different PCs, act as Alliance
Lite2 administrators.
Always restart your browser instance before and after accessing the Alliance Lite2.
DO NOT
Do not browse the Internet from the PC where you access Alliance Lite2.
Do not browse any other site from the time that you access Alliance Lite2 up until you end
your session on Alliance Lite2.
Do not use Admin account when browsing the Internet.
Do not leave your PC unattended when the USB token is plugged in.
Never write down any password, especially not the one to unlock the USB token.
Never communicate your password to anyone else, by any means. SWIFT never asks you
for your passwords.
Do not click a hyperlink contained in an e-mail, even if that URL seems perfectly valid from a
business perspective. Instead, once you confirmed the business need to visit that site, re-
type the URL within the browser as it was visible in the e-mail. A phishing attack may lead to
a rogue site that can steal information or infect your PC.
Be suspicious of e-mails that appear to come from SWIFT, and never provide the token
password if asked. SWIFT never asks for a token password in an e-mail.
Never accept a pop-up that asks you to download and install executables.
Do not delegate both administrator roles to a single person, who would then use the two
different USB tokens.
Do not grant the administrator and message approval roles to the same individual.
Alliance Lite2
20 Security White Paper
6 Glossary
Security terminology
Security term Definition
Integrity Integrity relates to information that may be relied upon to be consistent,
complete, accurate, valid, and useful.
For user data, this implies that no information may be altered by unauthorised
persons. For system data, this term implies that no unauthorised changes are
made to programs, scripts, configuration files, log files, and so on, thus
ensuring the integrity of the complete system.
Confidentiality Confidentiality refers to information that is disclosed only to authorised
persons, at authorised locations, and at authorised times.
For user data, this implies that confidential information is not disclosed to
unauthorised third parties. For system data, confidentiality refers to the secure
protection of sensitive operational data, such as password files and
encryption keys.
Availability The term availability implies that both the information and the systems used to
process, display, and print this information are both accessible and usable, as
and when required. For user data, this means that information must be
processed on time, and stored in the correct place, to be available to
authorised users.
The availability (and integrity) of valid system and configuration data has a
direct influence on service availability. Also, all of the necessary components
of a system must be working to ensure service availability.
Auditability Every user of a system must be held accountable for their activities. This
implies that all actions can be audited. This in turn means that all relevant
actions can be monitored, and that any one action can be uniquely attributed
to a known user, at a particular time and date.
Security principles
The following principles assist in ensuring the foundation of a secure system:
Security principle Definition
Need-to-Know Information and resources must be made available strictly on a need-to-know
or need-to-have basis.
The 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.
The 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 to a system.
The system set-up must ensure that non-required applications, software, or
tools are removed.
Accountability All user activities, such as access attempts and command usage, must be
logged and attributed to a known user.
Ideally, information about system activities such as processes, network
events, and system errors, must be logged.
Glossary
11 October 2013 21
Legal Notices
Copyright
SWIFT 2013. All rights reserved.
Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order expressly grants
you that right, in which case ensure you comply with any other applicable conditions.
Disclaimer
The information in this publication may change from time to time. You must always refer to the latest
available version.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: the SWIFT
logo, SWIFT, SWIFTNet, SWIFTReady, Accord, Sibos, 3SKey, Innotribe, the Standards Forum logo,
MyStandards, and SWIFT Institute. Other product, service, or company names in this publication are trade
names, trademarks, or registered trademarks of their respective owners.
Alliance Lite2
22 Security White Paper