alliance lite2 security white paper

Alliance Lite2

Security White PaperThis security white paper provides a high-level description of Alliance Lite2 from a security perspective. This paper is forSWIFT 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

PrefacePurpose of the document

This security white paper provides a high-level description of Alliance Lite2 from a securityperspective.

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 andtechnical offerings of SWIFTNet. This document is supplied for information purposes only. Theinformation in this paper may be superseded as a result of subsequent changes to AllianceLite2.

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 IntroductionWhat is Alliance Lite2?

In the context of Alliance Lite2, SWIFT operates a central infrastructure that is directlyconnected to SWIFTNet, and also provides an application server. Customers can connect to theapplication server over the Internet or over the SWIFT secure IP network (SIPN) using AllianceConnect VPN boxes.

SWIFTNet customers see Alliance Lite2 customers as no different from other customers whouse a direct connection to SWIFTNet. For example, trust relationship and registrationprocedures 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 channelcertificates

• 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 thegeneric security infrastructure implemented at your institution.

Generic security infrastructure

A generic security infrastructure that is exposed to the Internet must include firewalls, webcontent filtering, anti-virus software, anti-malware software, as well as customer awareness andpractices. When connected to SWIFTNet through the Internet, the user's computer may bedirectly 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 whenusing the SWIFT secure IP network, SWIFT customers must consider implementing thepreviously listed application-level security features.

Alliance Lite2


2 Overview of Alliance Lite2

2.1 Background and Business ContextService definition

Alliance Lite2 is a SWIFT service that provides easy, secure, and cost-effective access toSWIFTNet. It is an evolution of the SWIFT Alliance Lite service. This service is complementaryto other, existing models that provide connectivity to SWIFT today, such as on-premises accessor service bureaux. The Alliance Lite2 service allows you to manually create and approvemessages. It also provides the capability of uploading and downloading files and messagesautomatically.

D1

37

00

05

SWIFTNet flows

Financial

Institutions

Alliance Lite2

Central Infrastructure

SWIFTNet Interface

Secure workflow

Secure server

AutoClient

Customer premises

Browser Interface

Network SWIFT Operating CentresSWIFT

Community

SIPN

Internet

AND / ORAND / OR

VPN

box

From a security perspective, Alliance Lite2 shares many similarities with the current servicebureau access model:

• Alliance Lite2 is a service from SWIFT that provides easy, secure, and low-cost access toSWIFTNet.

• Alliance Lite2 is easy to order, requires a limited amount of configuration changes, and iseasy to use.

• Alliance Lite2 reduces the total cost of ownership (TCO) by reducing dramatically thesoftware footprint for Alliance users and by proposing a new pricing model.

• Alliance Lite2 further reduces the TCO by building on customer security infrastructure andsecurity practices.

• Alliance Lite2 supports manual operations through a browser-based screens. It also supportsintegration with back-office applications through lightweight software called AutoClient, whichis used for automated file transfers.

• Alliance Lite2 usage is transparent for customers that connect to SWIFTNet through directconnection. Messages and files to or from Alliance Lite2 customers do not require any updateto the existing SWIFTNet infrastructure of the customer or their contractual agreements withSWIFT.

For information about direct connection, see "Direct Connection to SWIFTNet" on page 7.

Overview of Alliance Lite2

11 October 2013 5

2.2 GovernanceDefinition

The Alliance Lite2 central infrastructure is built using industry-strength processes that help toensure best-in-class quality, security, and reliability: development life-cycle processes andoperational 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 andSWIFTNet services on which the global financial community relies on a daily basis. WhileAlliance Lite2 is currently not in scope of SWIFT's ISAE 3402 Type 2 report, the processesreferred to are the same. These processes include physical and logical controls of theoperational environment, operational procedures, secure coding, change management, problemmanagement, and incident management. Therefore, Alliance Lite2 users can derive assurancefrom 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 securityrequirements. In addition, with a risk-based periodicity, SWIFT performs intrusion tests toidentify potential vulnerabilities in the off-the-shelf technology, customised software, or in-housedeveloped code that is used to build the Alliance products. This covers operating system,middleware, network device, and application level vulnerabilities. Finally, Alliance Lite2 and allits underlying processes are subject to SWIFT internal audit, and are periodically reviewed indepth.

Alliance Lite2


3 Alliance Lite2 Key Security Aspects

3.1 Direct Connection to SWIFTNetDirect connection

D1

37

00

06

Alliance Lite2

Customer

premises

SIPNVPN

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 existingsecurity aspects of SWIFTNet. Customers that have a direct connection do not notice whethertheir counterparts use Alliance Lite2.

PKI certificates

Like any other SWIFTNet customer, customers who access SWIFTNet through Alliance Lite2are identified on SWIFTNet by standard SWIFTNet PKI certificates that are associated with theirBIC8. All SWIFTNet messages initiated by or intended for Alliance Lite2 are signed like anymessage exchanged with SWIFTNet customers who use a direct connection. RMAauthorisation 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 directconnection or with Alliance Lite2 customers.

Customers can find more information about connection methods in the SWIFTNet 7.0 ServiceDescription.

Alliance Lite2 Key Security Aspects

11 October 2013 7

Contractual framework

Alliance Lite2 customers enter into a specific contractual framework with SWIFT. Thisframework 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 overSWIFTNet)

• downloading and, as applicable, acting upon SWIFTNet messages

3.2 BrowseWhat is Browse?

Browse is a SWIFTNet messaging service that enables secure access from a standard webbrowser to a service provider's web server and SWIFTNet server application over the SWIFTsecure 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'sdesktop with a USB token provided by SWIFT or with a channel certificate :

Function Description

SWIFTNet Online OperationsManager

Use the SWIFTNet Online Operations Manager to administerthe security and the routing through a SWIFT-managedservice available over Browse.

Other Browse services Connect to any other Browse service that Alliance Lite2supports 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 PKIcertificates 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


3.3 Central InfrastructureOverview

The Alliance Lite2 service provides access to SWIFTNet messaging services.

D1370007

Customer

premises

AND / OR

SIPN

Network

VPN

box

SWIFTNet

Central

Infrastructure

Alliance Lite2 Central Infrastructure

Sit

e 2

Sit

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 andprocedures that SWIFTNet customers with a direct connection normally use. This infrastructureconsists of a set of resilient hosts that implement a SWIFTNet configuration that uses the directconnection method, and include Alliance Web Platform, Alliance Access, Alliance Gateway, andSWIFTNet Link. Additionally, SWIFT has implemented an Internet-facing set of resilient systemssuch 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 setof in-depth defence controls, in line with industry practices.

Alliance Lite2 access to SWIFTNet does not introduce additional threats on the SWIFTNetinfrastructure itself. The Alliance Lite2 central infrastructure connects to SWIFTNet in a mannerequivalent to how other SWIFTNet customers connect to SWIFTNet, using components such asAlliance Access, Alliance Gateway, SWIFTNet Link and HSM. To protect SWIFTNet andSWIFTNet customers with a direct connection, specific protections against additional threatsintroduced through Internet exposure (for example, distributed DoS, hackers) are built into theAlliance Lite2 central infrastructure.

The Alliance Lite2 Infrastructure is implemented within a SWIFT operating centre (OPC). Alloperational 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.


11 October 2013 9

3.4 Connectivity and EncryptionConnecting to SWIFTNet

Customers connect to SWIFTNet over the secure IP network using Alliance Connect VPNboxes or over the Internet.

3.4.1 Connection Security

Standard security measures

The connection between AutoClient and the SWIFT infrastructure deployed at the SWIFToperating centre is secured with two-way SSL encryption (SSL v3.0/TLS v1.0) with a strongencryption algorithm. An AutoClient uses token-based certificates (Windows only) or channelcertificates (all platforms) to establish a connection with the SWIFT infrastructure deployed atthe 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 encryptionat the network layer. This option is mandatory for the use of channel certificates. For productinformation, 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 thecreation of a secure channel over the SWIFT network partner backbones or the Internet. Thischannel uses Internet Protocol Security (IPsec) technology, which preserves the security of thedata that users exchange on the infrastructure (for example, the SWIFT network partner'sbackbone). The IPsec session occurs between the VPN boxes at the customer's premises andVPN 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 InternetProtocol 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 IPpacket of a data stream

• establish mutual authentication between agents at the beginning of the session andnegotiation of cryptographic keys for use during the session

3.5 PKI-based SecurityPersonal 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 otherSWIFTNet customers.

Alliance Lite2


The customer has full control over the keys associated with the Alliance Lite2 identity. The keysassociated with the SWIFTNet identity are hosted in HSMs in the Alliance Lite2 centralinfrastructure.

When connecting to the Alliance Lite2 service, each Alliance Lite2 customer can have multipleend users. These end users can have different Alliance Lite2 role profiles and specific AllianceLite2 identities.

Alliance Lite2 role profiles include roles such as administrator, approver, and creator. Each ofthese 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 providesa means for SWIFT to authenticate the identity of a user or an application. The Alliance Lite2user or application is authenticated through a 2048-bits PKI private key that is generated atcustomer premises. This PKI credential is protected in the USB token and never leaves thetoken. This is a FIPS 140-2, level 2 (or above), USB token. The USB token itself uses theprivate PKI key to sign the most sensitive operations created by the user and sent to AllianceLite2 central infrastructure. The user must provide a password to use the USB token, once it isactivated. Multiple consecutive failed password attempts lock the USB token. The token ispersonal and must not be shared with another user. It is protected by a password that the ownerof the token must keep private. Alliance Lite2 supports personal tokens on Windows systemsonly.

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 tothe Alliance Lite2 central infrastructure at SWIFT.

Message exchanges are subject to non-repudiation of emission. Non-repudiation is based onthe PKI signature generated by the local USB token.

The liability of the Alliance Lite2 customer is bound to this non-repudiation evidence. Thisevidence is used in the context of a dispute resolution between the Alliance Lite2 customer andSWIFT.

Note The same USB token technology is required for browser-based access and toAlliance Lite2.

3.5.2 Channel Certificates

Concept

A channel certificate is an encrypted, disk-based profile file that provides a means for SWIFT toauthenticate the identity of an application. The Alliance Lite2 application is authenticatedthrough a 2048-bits PKI private key that is generated at customer premises. Alliance Lite2supports channel certificates as an alternative means to physical tokens for securing theconnection between AutoClient at customers' premises and SWIFT, and to allow non-repudiation of signatures. Alliance Lite2 supports channel certificates on Windows, yet channelcertificates mandate the use of MV-SIPN connectivity. In addition, channel certificates are notpermitted for human-to-application flow, such as Browse services.

AutoClient uses channel certificates to establish the SSL connection and to sign requests fornon-repudiation. To prevent misuse of channel certificates, SWIFT ensures that channel


11 October 2013 11

certificates cannot be used outside the institution against which they are registered. To thiseffect SWIFT verifies that the BIC8 of the channel certificate used matches with the VPN box ofthe institution.

Message exchanges are subject to non-repudiation of emission. Non-repudiation is based onthe PKI signature generated by this channel certificate. This evidence is used in the context of adispute resolution between the Alliance Lite2 customer and SWIFT.

3.6 Protection of Customer InformationMessage storage

SWIFT guarantees to European customers that, for intra-European traffic, their message andfile request data will be processed and stored in Europe only.

SWIFT may retrieve, use, and disclose traffic or message data from these Alliance Lite2 serversonly in any of the following circumstances:

• when required for the provisioning of Alliance Lite2, as documented in the relevant SWIFTcontractual 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 AllianceLite2 customer as part of any other SWIFT services and products accessed through AllianceLite2 (for example, FIN or FileAct in a many-to-many environment, in a Member-AdministeredClosed 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 functionsthat allow you to perform tasks like managing users, restricting counterparties, and managingPKI credentials.

More specifically, these functions include:

• creation and deletion of users (for example when a user changes role or leaves thecompany)

• 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


4 Building on Top of Customer's SecurityInfrastructure

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 themeasures listed in this section.

4.1 Secure Environment

The customer must take the following security measures in line with the industry securitypractices.

Operating system hardening

Harden the system used to access Alliance Lite2 and only install authorised and requiredsoftware or applications.

Firewall and web content filtering components

Manage firewall and web content filtering components facing the Internet. This firewall must notallow 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 andmalware 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 Lite2user must use a firewall to shield the server from incoming Internet traffic, and fromunauthorised access over the internal network. The firewall must be both a physical one toprotect incoming traffic, and a PC-local one to ensure that only authorised programscommunicate with the outside.

Permission management

Ensure that only the people with the required permissions have physical and logical access tothe Alliance Access or Alliance Entry machine that contains the RACG component, and to thebackups.

Network-level segregation

Consider the secure IP network Alliance Connect product to help implement a strict segregationat network level.

Building on Top of Customer's Security Infrastructure

11 October 2013 13

4.2 Secure Browsing PracticesGuidelines

The customer must ensure that their institution's users follow secure browsing practices. Thefollowing list is not exhaustive:

• Segregate general browsing from critical browsing either by using a different Windowsaccount, 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 tocome from SWIFT, and never provide the token password if asked. SWIFT never asks for atoken password in an e-mail.

• Raise security awareness for Alliance Lite2 users. Invest in the development and themaintenance of secure-minded user behaviour and ensure that users are fully aware of thethreats related to Internet browsing.

4.3 Secure ApplicationIntroduction

SWIFT offers key additional security features to help customers build a fully secure access toAlliance Lite2.

Customer registration

Only registered customers can connect: customer registration on Alliance Lite2 is subject to thesame 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 theSWIFTNet PKI certificate authority.

Password protected USB token

Access to Alliance Lite2 requires the use of a password-protected USB token. This USB tokencontains a PKI private key required to sign all business critical operations. Such access can alsobe performed through MV-SIPN by using a VPN box FIPS 140-2 level2 and a channelcertificate.

Dual authorisation procedure

Pre-defined operator profiles enable dual authorisation through segregation of duties betweenadministrator, approver, and message entry functions.

User access restriction

Alliance Lite2 administrator can restrict user access to white-listed bank accounts as well as tolimit the allowed maximum amount per day.

Alliance Lite2


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 fromthe AutoClient PC are protected against malicious changes, especially if the AutoClient files aretransferred through a network.

For more information about those options, see the Alliance Lite2 Service Description, section"Security Features".

4.4 Secure UsageIntroduction

Consider implementing additional practices in the following categories.

Certificate use

Ensure that each user verifies the Alliance Lite2 server's SSL certificate authenticity during eachlogin to Alliance Lite2, as described in the Alliance Lite2 User Guide, section "Log in to AllianceLite2".

Implementation of dual authorisation

Implement dual authorisation for the most sensitive operations. Dual authorisation must beimplemented by Alliance Lite2 customers. This can be realised by relying on different peoplethat 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 neededwhen using Alliance Lite2.

Traffic reconciliation

Reconcile daily traffic for detecting any mismatch between authorised versus actual traffic (sentor received).

Access management and account management

Implement access, account management, and segregation of duties to ensure that only requiredpeople 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 tokenin a safe that is accessible only by authorised staff. While it is used, ensure that the USB tokenis 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 knownonly 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 thesystem. When users change roles or leave the company, the customer must update the list ofauthorised users.

Alliance Lite2


5 Addressing ThreatsIntroduction

When deploying the Alliance Lite2 application in an institution, customers must be aware of thethreats 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 securityfeatures and controls available to reduce their likelihood, as well as to limit the impact ofsuccessful attacks.

5.1 Threats and AttacksImpersonation

Any web-based application is exposed to attacks that must be considered when a customerdeploys Alliance Lite2. The attacks that must be considered include user impersonation, whichaffects 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 theclient system to get credentials, to perform further attacks.

• Phishing - Creating a replica of an existing “login page” to fool the user so as to capturefinancial 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 betweenthe browser and the web application. The attacker then changes the message and forwards itto the web application. The web application receives the message, trusts the message ascoming from the genuine user, and acts on it. When the web application sends a messageback, the attacker intercepts it, alters it, and returns it to the browser. Neither the browser northe web application knows that they have been attacked.

• Man-in-the-browser - a form of threat related to the man-in-the-middle impersonationtechnique. This technique uses a proxy Trojan horse that infects a web browser by takingadvantage of vulnerabilities in browser security to modify web pages, modify transactioncontent, or insert additional transactions, all in a completely covert fashion, invisible to boththe user and host web application.

For all impersonation attacks, the highest impact is always on the highest user privilege. As aconsequence, the best way to limit the impact is to have application authorisations implementedwith the “Need-to-know” and “Least privilege” principles in mind. In addition, traceability of useractions plays an important role in limiting the impact of malicious acts.

5.2 Security ThreatsThreats table

The following table lists typical threats that the end user would encounter when using theInternet. 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 ofpasswordsession orprivate key (forexample,spyware)

Sessionguessing

Shoulder surfing

Key logger/Spyware

Copy filecontainingprivate key

Phishing

Cross sitescripting

• See "Session mechanismwith strong security setup" onpage 15.

• See "Password protectedUSB token" on page 14.

• See "SSL tunnel" on page14.

• PKI Signing criticaloperations. See "Passwordprotected USB token" onpage 14.

• See "Access managementand account management"on page 15.

• See "USB token passwordpolicy" on page 15.

• Protection of the systemused for Alliance Lite2. See"Secure Environment" onpage 13.

• See "Protection of the USBtoken" on page 15.

• See "Secure BrowsingPractices" on page 14.

• Manually checking SSLcertificate at login time. See"Certificate use" on page 15.

Dataeavesdropping(throughphishing or trafficsniffing)

• Phishing

• Trafficsniffing

See "SSL tunnel" on page 14. Manually checking SSLcertificate at login time. See"Certificate use" on page 15.

Man-in-the-middle attack

• Phishing

• Modifying anoperation

• Injecting arogueoperation

• SSL tunnel with mutualauthentication. See "SSLtunnel" on page 14.

• PKI signing criticaloperations. See "Passwordprotected USB token" onpage 14.

• See "Dual authorisationprocedure" on page 14.


• Manually checking SSLcertificate at login time. See"Certificate use" on page 15.

• Activating and using dualauthorisation andsegregation of dutyprocedures. See"Implementation of dualauthorisation" on page 15.

Alliance Lite2


Threat Typical attack Alliance Lite2 response User responsibility

Man-in-the-browser attack

Malware infectsa PC aftervisiting a roguesite.

Local creation ofa rogueoperation

Cross-SiteRequest Forgery

• PKI Signing criticaloperations. See "Passwordprotected USB token" onpage 14.

• See "Dual authorisationprocedure" on page 14.


• Logical protection of systemused for Alliance Lite2.

– "Operating systemhardening" on page 13

– "Firewall and web contentfiltering components" onpage 13

• Anti-Virus and Malwarecounter measures. See"Antivirus, anti-malwareservices" on page 13.

• Patching practices. See"Security patches" on page13.

• Activating and using dualauthorisation andsegregation of dutyprocedures. See"Implementation of dualauthorisation" on page 15.

• See "White list of accountsand maximum account limit"on page 15.

• See "Traffic reconciliation"on page 15.

5.3 DOs and DON'TsIntroduction

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 implementcomplementary 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 incomingconnections 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 sitesrequired for software updates).

Addressing Threats

11 October 2013 19

• Ensure that the PC used for accessing Alliance Lite2 is physically and logically accessibleonly by persons who are entitled to access this PC.

• Ensure that only authorised and required software is installed on the PC used to accessAlliance Lite2.

• Ensure that all of the software running on the PC is regularly updated and patched includingWindows, 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 andthat the list of authorised users is kept up-to-date as users change roles or leave thecompany.

• Implement entitlement management practices that ensure that users are only granted accessto Alliance Lite2 functions on a need to know or need to have principle. As an example, usethe 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 validationand 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 AllianceLite2 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 endyour 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 youfor your passwords.

• Do not click a hyperlink contained in an e-mail, even if that URL seems perfectly valid from abusiness 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 toa 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 tokenpassword 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 twodifferent USB tokens.

• Do not grant the administrator and message approval roles to the same individual.

Alliance Lite2


6 GlossarySecurity 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 unauthorisedpersons. For system data, this term implies that no unauthorised changes aremade to programs, scripts, configuration files, log files, and so on, thusensuring the integrity of the complete system.

Confidentiality Confidentiality refers to information that is disclosed only to authorisedpersons, at authorised locations, and at authorised times.

For user data, this implies that confidential information is not disclosed tounauthorised third parties. For system data, confidentiality refers to the secureprotection of sensitive operational data, such as password files andencryption keys.

Availability The term availability implies that both the information and the systems used toprocess, display, and print this information are both accessible and usable, asand when required. For user data, this means that information must beprocessed on time, and stored in the correct place, to be available toauthorised users.

The availability (and integrity) of valid system and configuration data has adirect influence on service availability. Also, all of the necessary componentsof a system must be working to ensure service availability.

Auditability Every user of a system must be held accountable for their activities. Thisimplies that all actions can be audited. This in turn means that all relevantactions can be monitored, and that any one action can be uniquely attributedto 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-knowor need-to-have basis.

The system set-up must ensure that operators only have access to theinformation, 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 themto perform their defined tasks.

The system set-up must ensure that operator privileges are controlled in away 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, ortools are removed.

Accountability All user activities, such as access attempts and command usage, must belogged and attributed to a known user.

Ideally, information about system activities such as processes, networkevents, 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 grantsyou 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 latestavailable 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 SWIFTlogo, 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 tradenames, trademarks, or registered trademarks of their respective owners.

Alliance Lite2


alliance lite2 security white paper

Documents

security specialists

security perspective

pkibased security

overview of alliance

secure environment

secure application

secure usage

central infrastructure