You are on page 1of 19

Connectivity

Alliance Web Platform

Security White Paper


The purpose of this white paper document is to provide customers with the overall view on the security aspects for
the Alliance Web Platform.

29 March 2013
Connectivity - Alliance Web Platform

Table of Contents
Preface .................................................................................................................................................3
1 Introduction ...............................................................................................................................4
2 Overview of Security Concepts ..............................................................................................6
2.1 Alliance Web Platform .............................................................................................................6
2.2 Key Security Features .............................................................................................................7
3 Customer Security Controls....................................................................................................9
3.1 Key Security Controls..............................................................................................................9
3.2 Migrating to Alliance Web Platform .......................................................................................11
3.3 Alliance Web Platform in an un-secure environment ............................................................11
4 Addressing Vulnerabilities ....................................................................................................12
4.1 Threats & Attacks ..................................................................................................................12
4.2 Addressing Security Threats .................................................................................................14
4.3 DOs and DONTs ...................................................................................................................15
5 SWIFT Consulting Services...................................................................................................16
6 Glossary ..................................................................................................................................17
Legal Notices ....................................................................................................................................19

2 Security White Paper


Preface
Purpose of this document
The purpose of this document is to provide the reader with an overview of the security features
for the Alliance Web Platform.

Intended audience
This document is intended for SWIFT infrastructure administrators, security specialists and
auditors.
The document is intended for both new customers planning to deploy Alliance interfaces with
Alliance Web Platform and to customers already using the Alliance fat client interfaces, such as
Workstation and WebStation, and planning migration to Alliance Web Platform.
Additionally, the information in this document also concerns the service providers of Browse
services on SWIFTNet.

Related documentation
Alliance 7.0 release overview
Alliance Web Platform Installation Guide
Alliance Web Platform Server-Embedded Installation Guide
Alliance Web Platform Administration Guide
Browse Implementation Guide for Service Providers

01 February 2013 3
Connectivity - Alliance Web Platform

1 Introduction
Alliance Web Platform is a Graphical User Interface (GUI) software for Alliance products. It
exposes functionality of Alliance Gateway, Access/Entry and Integrator to the end user via a
browser. Alliance Web Platform runs on an application server and as such offers a solution that
does not require additional SWIFT software to be installed on user desktops. It offers a light and
scalable solution with a low cost of ownership and a harmonised user experience across several
Alliance products.
Alliance Web Platform 7.0 delivers almost all existing server functionality, gradually replacing
Alliance Messenger, WebStation and Workstation. The Service GUI functionality of Alliance
WebStation and ADK GUI functionality of Alliance Access are the only functions that are not
available.
The different functionalities are delivered in GUI packages. Each package is associated with a
specified Alliance server product, concerns a specific type of functionality and has to be explicitly
installed on Web Platform.
SWIFTs Alliance products are built using industry-strength processes that help ensure best-in-
class quality, security and reliability: development life-cycle processes ensure that security and
availability are built in right from the start. To a large extend, these are the very same processes
used by SWIFT to deliver the FIN and SWIFTNet services on which the global financial
community relies on a daily basis. While the Alliance products are not in scope of SWIFTs SAS
70 Type 2 report, the processes referred to are the same (e.g., secure coding, change
management, problem & incident management). Therefore, Alliance product users can derive
assurance from the SAS 70 report. 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, the Alliance products as well as all underlying processes are part of SWIFTs Internal
Audit Universe and get reviewed in depth periodically.
This paper provides:
An overview of security concepts and mechanisms of Alliance Web Platform integration with
Alliance products (section 2)
a description of the customer controls SWIFT recommends for secure deployment of
Alliance Web Platform (section 3.1)
changes in customer security controls for customers moving to Alliance Web Platform from
Workstation and WebStation fat clients (section 3.2)
recommendations for deploying of Alliance Web Platform on a non-trusted network (section
3.3)
overview of the vulnerabilities of web-based applications as well as available security
controls and additional recommendations to strengthen protection against specific threats
(section 4)

4 Security White Paper


Figure 1 Alliance packages on Alliance Web Platform

01 February 2013 5
Connectivity - Alliance Web Platform

2 Overview of Security Concepts


Alliance Web Platform has been designed in accordance with industry practices for resiliency
and security. Strict software development life-cycle and other governance related controls are
equally applied on Alliance products as on any other service delivered by SWIFT. This section
provides a high level view of the Alliance Web Platform Security Architecture.

2.1 Alliance Web Platform


The Alliance Web Platform is a generic platform supporting secure browser-based user
interfaces that will be deployed centrally as a front-end to Alliance Access/Entry, Alliance
Gateway, Alliance Integrator, Browse and future new SWIFT products. They can be used by
possibly several hundreds of users within an institution and will be accessed through the users
standard web browser (Internet Explorer) installed on their individual PCs
Alliance Web Platform has been designed following standard industry 3-tier architecture
practices. This allows the segregation between front-end, application and data layers.
Alliance Web Platform is delivered in two flavours:
The first flavour requires a web application server (IBM WebSphere Application Server)
configured in a cluster, providing robust operational capacity such as load balancing and
resilience mechanisms
The second flavour, Alliance Web Platform Server-Embedded, includes the application
server that the software requires.
In addition, Alliance Web Platform allows accessing the Browse services provided by SWIFT
members on SWIFTNet.

2.1.1 Alliance Web Platform as GUI for Alliance servers


Alliance Web Platform (Figure 2) provides a common set of services to all GUI packages
deployed in it.
Alliance Web Platform manages its own data store (platform database) to persist configuration
and monitoring data. Management of the configuration data of the Alliance Web Platform and
basic GUI administration functions are performed via the Alliance Web Platform Administration
application. The Alliance Web Platform Administration package is accessed like any other GUI
package that is registered for Alliance Web Platform.
An Alliance Web Platform package is accessed by users using their browser. It will then interact
with a back-end server (such as Alliance Integrator, Access/Entry or Gateway) to provide the
services requested by the user.

Alliance Web Platform

Application Server Alliance


Platform DB Integrator
Platform
Browser JDBC
Alliance
WebPage Gateway
Administration
Application
HTTP-S
Alliance
Access/Entry
GUI Application

Figure 2: Alliance Web Platform overview

6 Security White Paper


2.1.2 Browse Application
Browse users use their browser to access Browse services over the SWIFT IP network, MV-
SIPN. These services are deployed and managed by service providers.
Customer Environment Service Provider

HTTP Concentrator

Alliance Web Platform

Application Server
Platform DB
Platform
Browse Service
Browser JDBC
Browse
(HTTP-S)

MV-SIPN
WebPage WebServer
Administration
Application
HTTP-S InterAct SWIFTNet (SNL)
SwTL Alliance FileAct Server
Gateway Application
Browse
Java plugin

Figure 3: Browse and the Alliance Web Platform


The service provider creates a Browse service in the form of a web application hosted by a web
server (the service providers web server). Service providers make these Browse services
available on the MV-SIPN.
Browse users browse over HTTPS through the web pages deployed on the service providers
web server (browse flow). This HTTPS type of traffic is handled by the browser and can be
concentrated through an HTTP Concentrator, such as NAT device or HTTP Proxy. This proxy is
included in the Alliance Web platform Server-Embedded flavour.
Information that requires more added-value processing (like validation or non-repudiation) is not
sent over the HTTPS flow but is exchanged, over SWIFTNet, with a SWIFTNet server application
deployed next to the service providers web server. An InterAct/FileAct primitive can be invoked
in a service providers web page using a JavaScript API (a JavaScript function swCall). The
primitive interacts with a Java applet to forward the primitive to the Browse application that
exchanges the primitive over SWIFTNet via Alliance Gateway.

2.2 Key Security Features


2.2.1 Authentication & Session
Access operators, Alliance Gateway operators, SWIFTNet users or Alliance Integrator users are
authenticated with a corresponding back-end server. Administrators that want to access the
Alliance Web Administration package are authenticated against the application servers user
registry.
Whenever the browser connects to perform a login, a new session is always established. This
session is identified by a session ID generated by the server and returned to the browser in the
form of a secure cookie.
To authenticate a user, Web Platform performs the validation of the user credentials against the
back-end server. Upon successful validation the platform generates a user context identifier that
is returned to the browser.
To authenticate a Web Platform administrator, Web Platform validates the credentials using the
application server mechanism. As for the user, upon successful validation the platform generates
a user context identifier that is returned to the browser.
The generated user context identifier is stored in the memory of the browser and every incoming
request from the browser carries this identifier as a parameter of every request to the application
server. The server will verify the context for every user request.

01 February 2013 7
Connectivity - Alliance Web Platform

2.2.2 Server Authentication and Confidentiality


All flows are encrypted using Secure Socket Layer (SSL) one-way authentication. This feature
ensures confidentiality over the wire and protects against replay attack.
The communication between an Alliance Web Platform package and the server is secured by
Secure Socket Layer ensuring confidentiality of the operator user/password exchanged between
Web Platform and the Alliance server.
HTTPS, using Secure Socket Layer, is enforced for the communication between the browser and
Alliance Web Platform. The browser is able to authenticate the application server with the
certificate deployed on the application server.

2.2.3 Alliance Authorisations


Alliance products provide a large panel of authorisations options, such as roles and units
segregation, 4-eye control over critical security operations, 6-eye control for message creation, to
manage user privileges. These features allow applying the least-privilege principle and thus
reinforcing the application security. These features are described in the Alliance User
documentation.
The authorisations are not enforced at the Alliance Web Platform level but at the back-end server
level (same as for authentication). This architecture minimises the impact of an attack on Alliance
Web Platform by mitigating the risk of the user authorisations modification.

2.2.4 Web Platform Authorisations


With the 7.0.40 version of Alliance Web Platform, a new profile has been created in addition to
the administrator user: the monitoring user.
The monitoring user is able to see the same configuration settings and parameters than the
administrator user but he cannot modify them.

8 Security White Paper


3 Customer Security Controls
In order to reduce total cost of ownership and to leverage use of existing customer infrastructure,
Alliance builds on security practices established by the customer itself.
This section lists the minimum set of controls that SWIFT recommends for customer
implementation and explains the changes in the security practices linked to the migration from
existing Alliance fat clients to Alliance Web Platform.

3.1 Key Security Controls


Alliance Web Platform is designed to be implemented in a secure customer environment. This
assumes that a set of controls is implemented by our customers.
Physical and logical security of the computer & network that is used to run the Alliance product is
a key element in maintaining a secure environment. The security of the infrastructure is not
specific to Alliance Web Platform but is valid for any critical business application at the customer
premises.

3.1.1 Customer Infrastructure


Customers must consider the recurring controls at the infrastructure level:

Secure Server Environment


Physical and logical protect the server running Alliance products.
Ensure that Operating Systems (OS) used by Alliance products are appropriately configured
according to the vendor recommendations and only install authorised and required software /
applications.
Ensure that the application server (i.e. IBM WebSphere) is appropriately configured based on the
recommendation by the vendor.
Ensure that all infrastructures are up to date with the latest security patches.

Secure Client environment


Manage firewall and web content filtering components facing the Internet. The firewall must not
allow any incoming connections towards the PC used to access Alliance Web Platform.
The client host infrastructure should feature up-to-date anti-virus, anti-malware services and
associated up-to-date databases to protect PC from infection.
Ensure that PC components are up to date with the latest security patches.
Physically protect the PC used to access the Alliance products. Ensure that only authorised
persons have physical and logical access to the PC.

3.1.2 Secure Browsing


The customer must ensure its end users are following secure browsing practices, such as:
1. Segregated general browsing from Alliance Web Platform either by using different Windows
accounts or, ideally, by using different PCs.
2. Not browsing other sites than Alliance Web Platform when an Alliance session is open.
3. Never following links in e-mails that would pretend to direct the user to Alliance Web
Platform.

01 February 2013 9
Connectivity - Alliance Web Platform

4. Security awareness for Alliance end users allowing to develop and maintain secure minded
behaviour in the user base and to ensure users are fully aware of threats related to
browsing (i.e. like ensuring that PC user sessions cannot be taken over).

3.1.3 Network Segregation


Alliance product design provides the flexibility for customer to implement adequate network
segregation in line with best practices. Alliance Web Platform could be implemented in a De-
Militarised Zone (DMZ). This allows the implementation of strong firewall rules:
between the end user browser and Alliance Web Platform allowing only HTTPS
between Alliance Web Platform and Alliance Gateway packages allowing only SWIFT
Transport Layer (SwTL is a TCP-based SWIFT proprietary transport protocol) based on
Secure Socket layer( SSL).
between Alliance Web Platform and Alliance Access/Entry or Integrator packages allowing
only SWIFT Transport Layer (SwTL) based on SSL or SOAP over HTTPS in the context of
web services.
In addition, all management services must not be accessible via un-trusted networks.

3.1.4 Front-end Reverse Proxy


Alliance Web Platform is running on top of several third party products. Over time, those products
could have vulnerabilities that could be exploitable by attackers.
Hence, these require the regular installation of new patches or upgrades. Although, SWIFT has
developed Alliance Web Platform following third party specifications; the installation of a patch on
system running critical application must be evaluated and tested by customers. During this
elapsed time, the system could be considered at risk.
An industry practice against such a common issue is the implementation of a reverse proxy or an
application firewall as a front-end to Alliance Web Platform. Alliance Web Platform supports such
a configuration 1.

3.1.5 Authentication
Server Side
Alliance Web Platform is authenticated using a SSL server certificate. This certificate could be
signed using a trusted third party. SWIFT recommends using a recognised Certification Authority
or a Certification Authority under the customers control.

Client Side
By default, an end user is authenticated towards the back-end Alliance servers using
UID/password. SWIFT recommends the selection of a strong password policy following industry
best practices. As already mentioned, the authentication is performed at the level of the target
hosts (e.g. Alliance Access, Alliance Gateway).
In addition, SWIFT provides for some Alliance products the option to use a One-Time-Password
(OTP) using hardware token or authentication via an LDAP server. These options should be
considered when using Alliance in a non-trusted environment.

1
CF Documentation - Configuration type 2 cluster with an HTTP server front-end.

10 Security White Paper


3.1.6 Account Management and Segregation of Duties
The least privilege principle and segregation of duties principles must always be considered
when defining user profiles. This is not specific to Alliance Web Platform, since those controls are
enforced at the Alliance server level.
For example for Alliance Access, SWIFT recommends implementing Segregation of Duties
between users authorised to create messages and users authorised to approve messages 2.
In addition, all actions performed via Alliance Web Platform must be adequately monitored in
order to maintain efficient accountability. This can be performed using the monitoring and logging
features provided by the Alliance back-end servers (e.g. Access, Gateway).

3.2 Migrating to Alliance Web Platform


The only change of security practices in customer SWIFT environment could be linked to the fact
that, unlike fat-clients architecture, users can access Alliance interfaces from any desktop with a
browser installed.
As additional control, firewalls provides customers network segregation to allow access to
Alliance Web Platform by dedicate desktops only.

3.3 Alliance Web Platform in an un-secure


environment
As already mentioned, Alliance products are designed to be implemented in a secure customer
environment.
When Alliance Web Platform is directly exposed to an insecure network such as Internet, security
risk is considered higher due to an increase in likelihood of existing attacks. This is inherent in
the usage of uncontrolled networks like the Internet. Even though the product allows such
deployment; this set-up is not recommended by SWIFT.
If you decided to operate Alliance Web Platform in such configuration, the following additional
controls are strongly recommended.

Segregated servers
In addition to the network segregation, SWIFT recommends that the Alliance Web Platform used
by external users is not also used for internal access. This limits the potential impact of
successful attacks on the externally exposed system. For example, packages developed to
manage Alliance Gateway, Access or Integrator must not be exposed to an insecure network.

Virtual Private Network


In addition, Virtual Private Network (VPN) using IPSec technology could always be used, this
creates an additional layer of security between the client and the server premises. In this context,
Alliance Web Platform is not directly exposed to a non-trusted network anymore.

2
to be sent over SWIFTNet

01 February 2013 11
Connectivity - Alliance Web Platform

4 Addressing Vulnerabilities
When deploying any web-based application in the institutions, customers have to be aware of the
vulnerabilities of this technology and of the means to address them.
This section gives an overview of the typical threats and attacks for web-based applications and
summarises the security features and controls available to mitigate security threats and attacks
likelihood and to limit the impact of successful attacks.
SWIFT has a logical intrusion test program which is scheduled and managed by Security Risk
Management. The purpose of these logical intrusion tests is to identify potential vulnerabilities
either in off the shelf technology; customized software or homemade development used to build
SWIFT products (e.g. Alliance) or services used either by internal or external customers.
Beyond normal OS, middleware or network devices vulnerabilities, a special focus of logical
intrusion test exercises at SWIFT is on application level vulnerabilities (either design or
implementation). This includes test of OWASP top10.
All intrusion test findings are analyzed using the risk management process and the related
identified actions are tracked using the security risk registry.
For reasons of confidentiality, SWIFT does not provide further details on its security measures
and related control activities, including intrusion testing. Our controls related to intrusion testing
are documented as part of our ISAE 3402 Type 2 report, sections 1.2.1.6 and 2.2.2.9. The ISAE
3402 report contains PricewaterhouseCoopers Independent Security Auditors Report on the
Operations of SWIFT in which they attest that they have obtained reasonable assurance that
SWIFT has adequate and effective controls in place to meet the control objectives specified in
SWIFT Security Control Policy.
You can receive a personalized copy of our ISAE 3402 Type 2 report by sending a request to
ISAE_3402@swift.com and specifying the names and e-mail addresses of the recipients.

4.1 Threats & Attacks


As such, the deployment of Alliance Web Platform does not introduce new threats. Any web
based application is exposed to attacks and those attacks must be considered when Alliance
Web Platform is deployed by a customer. The attacks that must be considered are the following:
end-user impersonation that affects message confidentiality and integrity;
Alliance Web Platform host attack due to third party software weaknesses (since
accessible to a larger community (i.e. the Internet)); and
Denial of Service (DoS) attack that affects service availability.
Currently, the most popular hacker techniques to achieve impersonation are:
Spyware - This technique is based on the installation of hardware or software on the
client system to get credentials in order to perform further attacks.
Phishing 3 - Creating a replica of an existing login page to fool a user so as to capture
financial information, or credential data (password, ...).
Sniffing - ability to view network traffic and to steal credentials, confidential information,
or other sensitive data.
Man-in-the-Middle - A man-in-the-middle 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 end user, and acts on it.

3
Phishing is the term coined by hackers who imitate legitimate companies in e-mails to entice people to share static passwords or
credit-card numbers.

12 Security White Paper


When the web application sends a message back, the attacker intercepts it, alters it, and
returns it to the browser. Both the browser and the web application never know that they
have been attacked.

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,
traceability of user actions plays an important role in order to limit the impact of malicious act.
For DoS attacks, unavailability impact must be evaluated by every institution.

01 February 2013 13
Connectivity - Alliance Web Platform

4.2 Addressing Security Threats


The following table provides for typical attacks, the controls that must be considered when deploying Alliance
Web Platform and Alliance servers. The controls highlighted in italic shall be put in place by the customer.
The controls highlighted in bold are features provided by the Alliance products; some of those features must
be appropriately configured by Alliance administrators.

Controls
Typical
Threat Access/Entry
attacks Alliance Web Customer
Gateway User
Platform infrastructure
Integrator

Strong Password
Key logger Session mechanism Policy[3.1.5]
Session [2.2.1] OTP [3.1.5] Secure Browsing
Steal password practices [3.1.2] Protection of the
guessing SSL Tunnel [2.3.2] system used by
or session Account
Phishing management Alliance product
Account [3.1.1]
Management [3.1.6]
Shoulder
surfing (7.0.40) Session
Mechanism [2.2.1]

Data Phishing SSL Tunnel Secure Browsing


SSL Tunnel [2.2.2]
eavesdropping Sniffing [2.2.2] practices [3.1.2]

Network
Activating and Segregation [3.1.3]
using dual
Server authorisation and Patch Management
Man-in-the- Secure Browsing
Data Tampering authentication segregation of duty [3.1.1]
Middle practices [3.1.2]
[3.1.5] procedures Logical and
[3.1.6] Physical control
[3.1.1]
VPN [4.2.3]

Reverse Proxy [3.1.4]


Network
Third party DMZ Segregation [3.1.3]
product
Weakness [3.1.3] Patch Management
[3.1.1]

Network
Segregation [3.1.3]
Server Segregation
Denial of Patch Management Patch Management [3.3]
Service (DoS) [3.1.1] [3.1.1] Protection of the
Reverse Proxy [3.1.4] system used by
Alliance product
[3.1.1]
VPN [3.3]

14 Security White Paper


4.3 DOs and DONTs
This section lists typical DOs and DONTs that SWIFT recommends to Alliance users. However,
this list does not intent to be exhaustive and Alliance Web Platform users should implement
complementary security measures where and when justified by their own security risk analysis.

DO
Install and manage a firewall facing the Internet, not accepting any incoming connections
towards the PCs where you run the browser accessing Alliance Web Platform.
Install and manage a local firewall on each PC, as well as anti-virus/anti-malware
continuously active and kept up to date with latest threats.
Restrict outgoing traffic of the PC to business critical sites (on top of legitimate sites
required for software updates).
Ensure the PC used for accessing Alliance is physically and logically accessible only by
person entitled to access this PC.
Ensure that only authorised and necessary software is installed on the PC used to access
Alliance products.
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) like shockwave,
QuickTime, RealPlayer, and many others. Reserve PCs to access sites of the same
criticality as Alliance and only access those sites from those PCs.
Reserve PCs to accessing internal sites of same criticality as Alliance and only access
these sites from these PCs.
Have end user management practices ensuring that only authorised end users are created
and the list of authorised end users are kept up to date as users change roles or leave the
company.
Have entitlement management practices ensuring that end users are only granted access to
Alliance functions on a need to know or need to have principle.
Always restart your browser instance before and after accessing Alliance Web Platform
application.
Be suspicious of e-mails that appear to come from SWIFT.

DONT
Browse the Internet from the PC where you access critical Alliance functionality.
Browse any other site at the time you access Alliance Web Platform application up until you
ended your session.
Write down any password.
Communicate your password to anyone, SWIFT will never ask you for such passwords.
Accept a pop up asking you to download and install executables.
Grant the administrator and message approval roles to same individuals.
Click a hyperlink contained in an email, 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 mail. Such phishing attack may lead
to rogue site that could steal information or infect your PC.

01 February 2013 15
Connectivity - Alliance Web Platform

5 SWIFT Consulting Services


SWIFT Consulting Services provides you with direct access to SWIFT technical experts who can
help you to review the current security policy around SWIFT and its implementation versus best
practice and recommendations.
To address the security-related requests, SWIFT offers Implementing Security Best Practices
consulting package aiming to provide you with independent review of the implemented policy
and identification of potential risk exposures.
As a part of the package, SWIFT experts will provide you with the following deliverables:
Review of the security policy with a focus on availability, confidentiality, integrity, and
traceability
Mitigation plan of most critical risk exposures with available technology
Recommendations to bring all dimensions of the security aspect in line with best
practice
Assessment of security vulnerabilities
For further details please contact your SWIFT Regional Account Manager or your nearest SWIFT
office.

16 Security White Paper


6 Glossary

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, print etc that 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.

Auditability Every user of a system must be held accountable for his/her activities. This implies
that all actions can be audited. That 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.

The following principles assist in ensuring the foundation of a secure system:

Security Principle Definition

Need-To-Know Information and resources should only be made available strictly on a need-to-know or
need-to-have basis.
System Set-up must ensure that operators only have access to the information, files
and system resources necessary for their defined tasks. Access to other system
functions must be disabled.

Least Privilege Users must only be granted the minimum level of privileges required for them to
perform their defined tasks.
Systems Set-up must ensure that operator privileges are controlled in a way which
allows all privileges to be tailored to individual needs.

Default Deny By default, a person must be granted no privilege / no access on a system.


Systems set-up must ensure that non-required application, software or tools are
removed.

01 February 2013 17
Connectivity - Alliance Web Platform

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.

18 Security White Paper


Legal Notices
Copyright
SWIFT 2013. All rights reserved.
You may copy this publication within your organisation. Any such copy must include these legal notices.

Confidentiality
This publication contains SWIFT or third-party confidential information. Do not disclose this publication outside your
organisation without the prior written consent 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: SWIFT, the SWIFT
logo, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or company names in this publication are
trade names, trademarks, or registered trademarks of their respective owners.

01 February 2013 19

You might also like